From alanb at openjdk.org  Mon May  1 05:52:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 May 2023 05:52:22 GMT
Subject: RFR: 8302496: Runtime.exit incorrectly says it never throws an
 exception
In-Reply-To: <v08MOHlrPawxX2WKpwTYQH7aKtYRlNY7DG9zT1JRVR0=.afab9388-7cc5-40b0-aabe-5eee5cfb3ce7@github.com>
References: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
 <eVY0HhKjkKGrMMfVlfQLWvmbesi3l9ENunDAjEx9eJ8=.f2b97ad1-5cde-4b68-936f-64250e765a59@github.com>
 <v08MOHlrPawxX2WKpwTYQH7aKtYRlNY7DG9zT1JRVR0=.afab9388-7cc5-40b0-aabe-5eee5cfb3ce7@github.com>
Message-ID: <0OBEeBkxeo5tz3O_fb9lTZ64fHMHglG1H78g5bRS7wo=.e4d29694-2409-4eee-9ab8-14ea5e93f06f@github.com>

On Fri, 28 Apr 2023 21:44:58 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Runtime.java line 146:
>> 
>>> 144:      * If a security manager is present and its {@link SecurityManager#checkExit checkExit}
>>> 145:      * method disallows exiting with the specified status, throws {@link SecurityException}.
>>> 146:      * Otherwise, this method blocks indefinitely; it neither returns nor throws an exception
>> 
>> The SM is not long for this world.  So I'm in two minds about it making a farewell appearance in the first paragraph of the method description when we know we will have to remove this text very soon.  If we really need to change this now then maybe it could be reduced to "When a security manager is not set, this method never returns ..." so that the distraction of checkExit is not in the first paragraph.
>
> Yeah I had some misgivings mentioning the SM first, but if it's not mentioned, then the assertions in the rest of the text become hedged and uncertain. The SM, checkExit, and whether the exit value is allowed all have to be mentioned somewhere anyway. It would be awkward to try to wedge all of this into a subordinate or parenthetical clause of some other sentence.
> 
> Even though we know the SM is on the way out, it's still part of Java SE 21, and it ought to be specified correctly. When the SM is actually removed, we'll have to revisit these specs anyway. Choosing different wording now won't make the future change any easier or harder.

One thing you could do is reduce the words down to something like "Unless denied exiting by the security manager, this method blocks indefinitely ..." to avoid complicating the first paragraph with something that only arises with a niche execution mode. If needed, a later paragraph could have this detail, or just leave it to the existing @throws text where the permission check is specified.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13706#discussion_r1181399806

From alanb at openjdk.org  Mon May  1 05:52:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 May 2023 05:52:22 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <-LR0qy8lzfy0N6sksIJNnVxAIesh0yQmRNYrG5pvG2I=.52637aed-bbc2-4ea8-a134-d148c91f2953@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>
 <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>
 <Fo_R8bXjDqPZslPylTg16uSKoFPM_iwU83wEoZRPkqA=.2106178e-4a13-4598-a67d-04ebd77a1d8c@github.com>
 <-LR0qy8lzfy0N6sksIJNnVxAIesh0yQmRNYrG5pvG2I=.52637aed-bbc2-4ea8-a134-d148c91f2953@github.com>
Message-ID: <i0XyFn3kpnJqqy6hxGuWxIv1c8iB7QO7SI4Eci63vAA=.2227898b-3ef3-4169-b36f-a3cbafc60512@github.com>

On Sun, 30 Apr 2023 18:53:40 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> It seems that letting jlink do the linking is also a requirement for user provided modules (.jmods) that contain native libraries (as is the case for instance with jextract). We don't know about those libraries when building the JDK.

For now yes, but if there are further steps to have it create a single executable then the classes/resources will also be included. So I think pure Java modules will also be in this picture, eventually.

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

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1529373589

From liach at openjdk.org  Mon May  1 09:07:55 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 1 May 2023 09:07:55 GMT
Subject: RFR: 8306455: Wrong majorVersion for multiple attributes in
 Classfile API
In-Reply-To: <mSyXLLN7qBVlAVaiYrvFSyAb8QAm-g9TAZ-ZSL_oiZI=.ec069d21-00c2-4343-adb6-01de938ddfc6@github.com>
References: <mSyXLLN7qBVlAVaiYrvFSyAb8QAm-g9TAZ-ZSL_oiZI=.ec069d21-00c2-4343-adb6-01de938ddfc6@github.com>
Message-ID: <DjH_bq3mU7Yo8cIlbW10MsGMg5K-QwJ0HeLgv5hBxps=.504328cd-56d6-4418-8aa8-d7abf87ff129@github.com>

On Wed, 19 Apr 2023 14:31:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Spotted the typo for BootstrapMethods, and another review over the API exposed the typo on PermittedSubclasses.

@asotona Would you mind reviewing this?

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

PR Comment: https://git.openjdk.org/jdk/pull/13536#issuecomment-1529491342

From jlaskey at openjdk.org  Mon May  1 12:10:55 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 1 May 2023 12:10:55 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v2]
In-Reply-To: <5Gfuey8swtt5kH7aGU7aQNwU80KcoCFJ2hZxxGO2tnk=.75eb7117-299b-449a-b3a2-6ef27de44ac0@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <osNSUyEj1mUrULK9eKwnO1SQqg1OLygKUKCFfoS_lwc=.f8c3e61b-6200-42f3-80cc-51334e4e7502@github.com>
 <FPr8Cf00YVgejbm80QLSH1qAmPHoM-RCJcS4IxXPAC4=.8eada591-9902-4c1d-9260-a0637c2407db@github.com>
 <5Gfuey8swtt5kH7aGU7aQNwU80KcoCFJ2hZxxGO2tnk=.75eb7117-299b-449a-b3a2-6ef27de44ac0@github.com>
Message-ID: <NL3FV21KmTjIP3oQAvy-XDPtz3dyFKG5yPHmvW__pYE=.690ba017-641c-4e0b-af15-0c8ae94371da@github.com>

On Thu, 27 Apr 2023 18:00:38 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/native/libjli/java.c line 590:
>> 
>>> 588:         CHECK_EXCEPTION_NULL_LEAVE(mainID);
>>> 589:         (*env)->CallVoidMethod(env, mainObject, mainID);
>>> 590:         break;
>> 
>> This calls into LauncherHelper to get the "main type", then calls the static or new/instance method. I'm wondering if you tried have a single entry point in LauncherHelper instead. I think the only downside might be that the trampoline would show up in stack traces but @Hidden could hide that.
>
> Good idea. If @hidden doesn't work then we can eat the trace entries.

Many dependencies (ex. JDI) on main being the first frame. Will set up a separate RFE witch should include using the LauncherHelper in the source code launcher.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1181532559

From jlaskey at openjdk.org  Mon May  1 13:06:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 1 May 2023 13:06:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Flexible Main Methods
 and Anonymous Main Classes (Preview) [v8]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Anonymous main classes renamed to unnamed classes
 - Add test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/a09a0a1b..ff7cd4c7

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

  Stats: 314 lines in 14 files changed: 151 ins; 135 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From jvernee at openjdk.org  Mon May  1 13:17:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 1 May 2023 13:17:27 GMT
Subject: Integrated: 8303002: Reject packed structs from linker
In-Reply-To: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
References: <7USKvbFzmmi7JWK2OpNi4p-JGLLLzGZUL_FqjE72jNM=.8ec33082-9300-4990-893c-d70744cc7003@github.com>
Message-ID: <gFTMXVlUxpTdpTFdK3QXGCa_7dUz4VpeVlyip8HZqsc=.a1cd9ec3-9cb6-46e1-be62-b38dc3e6fd1e@github.com>

On Thu, 23 Mar 2023 18:11:18 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch adds checks in AbstractLinker to reject packed structs and structs with excess padding (e.g. unnamed bitfields), since both of those are currently not supported, and the ABI/spec seems too vague to base support on.

This pull request has now been integrated.

Changeset: 1de1a388
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1de1a38859c696cd5f3f6efa51809bff9c127953
Stats:     161 lines in 11 files changed: 146 ins; 0 del; 15 mod

8303002: Reject packed structs from linker
8300784: Specify exactly how padding should be presented to the linker
8304803: NPE thrown during downcall classification under Linux/x64
8303524: Check FunctionDescriptor byte order when linking

Reviewed-by: mcimadamore

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

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

From jvernee at openjdk.org  Mon May  1 13:28:57 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 1 May 2023 13:28:57 GMT
Subject: Integrated: 8301703: java.base
 jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes
In-Reply-To: <BmO-X6PnCnCN17VYHwgLxBtDS0ztCjsbUylkyGCnwwI=.0950f5df-c91e-49d1-a9d8-3df18640f2cb@github.com>
References: <BmO-X6PnCnCN17VYHwgLxBtDS0ztCjsbUylkyGCnwwI=.0950f5df-c91e-49d1-a9d8-3df18640f2cb@github.com>
Message-ID: <28fvrfEAFqW50l6tA79GbRpR17wmC80trRvZJVwqxIM=.2b987292-fa2d-4d9e-a8b6-b0f7b5b1a2a2@github.com>

On Thu, 30 Mar 2023 17:11:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Rewrite BindingSpecializer to use the new class file API.
> 
> Note: There is a big try/catch/finally block generated in the `specialize` method that currently uses labels. I looked at replacing this with a call to `CodeBuilder::trying` but it would require threading the nested code builders through all the `emit*` methods, which currently access the 'global' CodeBuilder instance attached to the BindingSpecializer instance. Since there didn't really seem to be a big benefit to this, I've kept that try/catch/finally block as is, using labels.
> 
> The current implementation could also use `CheckClassAdapter` to do additional verification on the generated bytecode (ahead of the VM's verifier). I'm not sure if the new API has a replacement for that?

This pull request has now been integrated.

Changeset: b39a9bff
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b39a9bffda0440b1617a802ceb70bf12e075a779
Stats:     406 lines in 1 file changed: 23 ins; 146 del; 237 mod

8301703: java.base jdk.internal.foreign.abi.BindingSpecializer uses ASM to generate classes

Reviewed-by: mcimadamore, asotona

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

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

From jvernee at openjdk.org  Mon May  1 13:50:56 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 1 May 2023 13:50:56 GMT
Subject: RFR: 8305093: Linker cache should not take layout names into
 account [v5]
In-Reply-To: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
References: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
Message-ID: <nl7xJcPsDYPw9772YPfN3FnzZIJz9pg4_72RAnsnqew=.946cc6d0-d4c9-44d6-a0d2-2d6dbe18d4f5@github.com>

> Strip names from the function descriptors used in linkage requests. The names are not important for classification, and this will allow the cached MethodHandle/UpcallStubFactory to be shared across linkage request with the same structure, but with layouts that have different names.
> 
> I also have another implementation that avoids copying all the layouts, and instead re-implemented equals and hashCode in the LinkRequest wrapper: https://github.com/openjdk/jdk/compare/pr/13079...JornVernee:jdk:NoNameCache But, this seems too complex. Linking code is not very performance sensitive, so I instead went with a simpler approach in this patch.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 47 commits:

 - Merge branch 'master' into NoNameCache2
 - Use orElseGet
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - Undo changes to MemberDeleted.java
 - Merge branch 'master' into NoNameCache2
 - use al instead of ValueLayout.ADDRESS
 - re-add spuriously removed blank line
 - stripNames based caching
 - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
   
   rename has_port
 - rename has_port
 - Merge pull request #2 from JornVernee/WSL_BB
   
   account for missing functional in WSL in TestByteBuffer
 - ... and 37 more: https://git.openjdk.org/jdk/compare/b39a9bff...57ea4eba

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

Changes: https://git.openjdk.org/jdk/pull/13562/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13562&range=04
  Stats: 91 lines in 2 files changed: 86 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13562.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13562/head:pull/13562

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

From jvernee at openjdk.org  Mon May  1 14:01:55 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 1 May 2023 14:01:55 GMT
Subject: Integrated: 8305093: Linker cache should not take layout names into
 account
In-Reply-To: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
References: <nOzHw28Ftxw1Iy1pYBHZf14Gr8OYQWAZ6ZE79Sngk4o=.0f42bf48-c65a-4861-9a73-7bc3d4903e57@github.com>
Message-ID: <SjjHEp5u3V71K53YaFvcJ1SDOdRaLDN1jpevYIbIIl4=.c2d2c443-b7f3-4fe5-83c1-c24fec261db5@github.com>

On Thu, 20 Apr 2023 17:23:08 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Strip names from the function descriptors used in linkage requests. The names are not important for classification, and this will allow the cached MethodHandle/UpcallStubFactory to be shared across linkage request with the same structure, but with layouts that have different names.
> 
> I also have another implementation that avoids copying all the layouts, and instead re-implemented equals and hashCode in the LinkRequest wrapper: https://github.com/openjdk/jdk/compare/pr/13079...JornVernee:jdk:NoNameCache But, this seems too complex. Linking code is not very performance sensitive, so I instead went with a simpler approach in this patch.

This pull request has now been integrated.

Changeset: 67dd8414
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67dd8414321677e3fc41fa1470c857c0afaa4259
Stats:     91 lines in 2 files changed: 86 ins; 1 del; 4 mod

8305093: Linker cache should not take layout names into account

Reviewed-by: mcimadamore

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

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

From jvernee at openjdk.org  Mon May  1 14:12:57 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 1 May 2023 14:12:57 GMT
Subject: RFR: 8305201: Improve error message for GroupLayouts that are too
 large on SysV [v4]
In-Reply-To: <DwY-xanY3TwoY2JPGLFPQg3bOqI70N1j5tAKv60AIxw=.f892d52c-a641-4275-9619-a8bffc4378b5@github.com>
References: <DwY-xanY3TwoY2JPGLFPQg3bOqI70N1j5tAKv60AIxw=.f892d52c-a641-4275-9619-a8bffc4378b5@github.com>
Message-ID: <M6GT94kyFbq7fDBZf9G0MyLA98Nve44K_FpQSacaBug=.96605e7b-54ab-4deb-b74b-be97208a6d14@github.com>

> Using for instance a struct layout that contains an unbounded array will produce the exception from the JBS issue.
> 
> This patch checks for the case where a GroupLayout is too large more explicitly, and reports the issue using a more informative exception.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits:

 - Merge branch 'master' into GroupLayoutTooLarge
 - Undo changes to MemberDeleted.java
 - Merge branch 'master' into GroupLayoutTooLarge
 - Add test. Use toIntExact
 - improve error message for too large structs
 - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
   
   rename has_port
 - rename has_port
 - Merge pull request #2 from JornVernee/WSL_BB
   
   account for missing functional in WSL in TestByteBuffer
 - account for missing mincore on WSL in TestByteBuffer
 - Merge branch 'master' into PR_21_V2
 - ... and 35 more: https://git.openjdk.org/jdk/compare/67dd8414...848f7dbe

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

Changes: https://git.openjdk.org/jdk/pull/13581/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13581&range=03
  Stats: 27 lines in 2 files changed: 24 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13581.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13581/head:pull/13581

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

From erikj at openjdk.org  Mon May  1 14:21:23 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 1 May 2023 14:21:23 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <qoIFJlMJYKqo5Mrd_NONJ-lwV3pENmRrSJ0cmzzEDEw=.2e5141ab-0f4d-40ca-b35c-f207df87e533@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com>
 <fswwIoriIC-x9zeS5I9FU_fZ74upHRtagKJhjyM8P6E=.2993cede-0fe1-4f1b-859b-c1a9d2cacc4e@github.com>
 <qoIFJlMJYKqo5Mrd_NONJ-lwV3pENmRrSJ0cmzzEDEw=.2e5141ab-0f4d-40ca-b35c-f207df87e533@github.com>
Message-ID: <SrKfBBjz5JhkeUY3WB5xNkyQW3Bh2VCq0wkRvBFcIa8=.caa353b5-d80f-4ef6-993b-6b9b49b8029a@github.com>

On Fri, 28 Apr 2023 23:25:17 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>>> I pulled this PR and had a go at building it. For me it failed with errors like this:
>>> 
>>> ```
>>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_clock_init(): error: undefined reference to 'clock_getres'
>>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::Linux::fast_thread_cpu_time(int): error: undefined reference to 'clock_gettime'
>>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(): error: undefined reference to 'clock_gettime'
>>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::thread_cpu_time(Thread*): error: undefined reference to 'clock_gettime'
>>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::current_thread_cpu_time(bool): error: undefined reference to 'clock_gettime'
>>> /home/erik/git/jdk/build/linux-x64/images/static-libs/lib/libjvm.a(os_linux.o):os_linux.cpp:function os::init_2(): error: undefined reference to 'clock_getres'
>>> ```
>>> 
>>> I haven't dug any deeper to try to figure this out. Is this something you recognize?
>> 
>> Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build:
>> 
>> 
>> /usr/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o /.../build/linux-x86_64-server-slowdebug/jdk/bin/javastatic /.../linux-x86_64-server-slowdebug/support/native/java.base/java/main.o  -Wl,--whole-archive /.../linux-x86_64-server-slowdebug/images/static-libs/lib/libattach.a ... /.../linux-x86_64-server-slowdebug/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a
>> 
>> 
>> `clock_getres` and the other related symbols are provided by `libc`. For `libc`, we don't static link with. We still use `libc.so`.
>> 
>> 
>> $ ldd jdk/bin/javastatic
>> 	linux-vdso.so.1 (0x00007fff8b17a000)
>> 	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f0845321000)
>> 	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f0845140000)
>> 	/lib64/ld-linux-x86-64.so.2 (0x00007f084888d000)
>> 
>> 
>> 
>> $ objdump -Tw /lib/x86_64-linux-gnu/libc.so.6 | grep clock_getres
>> 00000000000cf260 g    DF .text	0000000000000069  GLIBC_2.17  clock_getres
>> 00000000000cf260 g    DF .text	0000000000000069 (GLIBC_2.2.5) clock_getres
>> 
>> $ nm jdk/bin/javastatic | grep clock_gettime
>>                  U clock_gettime at GLIBC_2.17
>> $ nm jdk/bin/javastatic | grep clock_getres
>>                  U clock_getres at GLIBC_2.17
>
>> Erik, could you please share your `support/native/java.base/java/BUILD_LAUNCHER_javastatic_static_link.cmdline`? This generated .cmdline file contains the static linking command. Here is the linking command from my build:
> 
> I can't see any significant difference. I'm using a devkit created using the devkit makefiles. 
> 
> 
> .../devkit-linux_x64-gcc11.2.0-OL6.4+1.0.tar.gz/x86_64-linux-gnu-to-x86_64-linux-gnu/bin/gcc -Wl,-z,defs -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack -Wl,--hash-style=gnu -m64 -static-libstdc++ -static-libgcc -Wl,-rpath,$ORIGIN/. -Wl,--export-dynamic -o .../build/linux-x64/jdk/bin/javastatic /home/erik/git/jdk/build/linux-x64/support/native/java.base/java/main.o -Wl,--whole-archive .../build/linux-x64/images/static-libs/lib/libattach.a ... .../build/linux-x64/images/static-libs/lib/libjvm.a -Wl,--no-whole-archive -lpthread -ldl -lm -l:libstdc++.a

> Based on the above finding, I pushed a change to use $(JVM_LIBS) for the linking command. @erikj79 could you please see if that resolves the clock_* symbol issues in your environment?

Yes, it built cleanly with that change.

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

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1529742147

From jvernee at openjdk.org  Mon May  1 14:24:24 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 1 May 2023 14:24:24 GMT
Subject: Integrated: 8305201: Improve error message for GroupLayouts that are
 too large on SysV
In-Reply-To: <DwY-xanY3TwoY2JPGLFPQg3bOqI70N1j5tAKv60AIxw=.f892d52c-a641-4275-9619-a8bffc4378b5@github.com>
References: <DwY-xanY3TwoY2JPGLFPQg3bOqI70N1j5tAKv60AIxw=.f892d52c-a641-4275-9619-a8bffc4378b5@github.com>
Message-ID: <vs6ipiCJ313d0UTqypPKC7W14jN4hOAo6C9sGDkERoc=.3311f8a5-d946-4ccb-a0e6-58cffa3bd740@github.com>

On Fri, 21 Apr 2023 14:25:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Using for instance a struct layout that contains an unbounded array will produce the exception from the JBS issue.
> 
> This patch checks for the case where a GroupLayout is too large more explicitly, and reports the issue using a more informative exception.

This pull request has now been integrated.

Changeset: 7d07d195
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7d07d19523658cb8034121af6569fbbe92c9afd1
Stats:     27 lines in 2 files changed: 24 ins; 0 del; 3 mod

8305201: Improve error message for GroupLayouts that are too large on SysV

Reviewed-by: mcimadamore

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

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

From liach at openjdk.org  Mon May  1 14:56:27 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 1 May 2023 14:56:27 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v11]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with a check to the class data. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> [^1]: single abstract method

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

 - Renames
 - Merge branch 'master' into explore/mhp-iface
 - Consolidate iteration over public methods
 - Define MH proxy class in a dynamic module
 - Fix test that depend on WrapperInstance
 - Require an original lookup in constructor arguments to prevent unintended instantiation
 - pass interface info via condy,
   drop explicit ea flags
   initialize benchmark work variable randomly
   benchmarks just need 1 fork
 - Nuke WrapperInstance
 - Merge branch 'master' into explore/mhp-iface
 - Whitespace, cleanup, rename benchmarks to be informative
 - ... and 14 more: https://git.openjdk.org/jdk/compare/9cce7b2d...f5d0ef0a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/0bfda844..f5d0ef0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=09-10

  Stats: 299166 lines in 2802 files changed: 256995 ins; 23751 del; 18420 mod
  Patch: https://git.openjdk.org/jdk/pull/13197.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13197/head:pull/13197

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

From rriggs at openjdk.org  Mon May  1 15:41:24 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 May 2023 15:41:24 GMT
Subject: Integrated: 8304915: Create jdk.internal.util.Architecture enum and
 apply
In-Reply-To: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
References: <7m7tWvmLzDchLaIvsJDDT0zrQaT4KaYPkZM87F2qrjs=.94301c48-a73d-4fd4-9cec-64754e574a97@github.com>
Message-ID: <Mshw3zu0Y7m5vC_WzR1yglfIVTEywpQ36pezORYCA8c=.7a6252cf-eb6a-44a3-8fb7-10f31c6cab90@github.com>

On Wed, 5 Apr 2023 15:58:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Define an internal jdk.internal.util.Architecture enumeration and static methods to replace uses of the system property `os.arch`.
> The enumeration values are defined to match those used in the build.
> The initial values are: `X64, X86, AARCH64, RISCV64, S390, PPC64`
> Note that `amd64` and `x86_64` in the build are represented by `X64`.
> The value of the system property `os.arch` is unchanged.
> 
> The API is similar to the jdk.internal.util.OperatingSystem enum created by #[12931](https://git.openjdk.org/jdk/pull/12931).
> Uses in `java.base` and a few others are included but other modules will be done in separate PRs.

This pull request has now been integrated.

Changeset: f00a748b
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f00a748bc5b708d4f8f277d075859b058f9d575c
Stats:     411 lines in 7 files changed: 343 ins; 57 del; 11 mod

8304915: Create jdk.internal.util.Architecture enum and apply

Reviewed-by: erikj, mdoerr, amitkumar

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

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

From rriggs at openjdk.org  Mon May  1 16:15:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 May 2023 16:15:02 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record [v4]
In-Reply-To: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
Message-ID: <9wvnN3stZCbaQFmgdYUqqRw5GH5WI8X0vYCylLg_o9A=.93cd7128-5a5e-4f56-aed7-28bbce0d82b2@github.com>

> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
> Add `OperatingSystem.version()` to return the version of the running OS.
> Replace uses of os.version in java.base.
> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Merge branch '8304915-arch-enum' into 8306678-os-version
 - Correct comment on isPPC64() and refer to isLittleEndian() instead of mentioning PPC64LE
 - Simplify initialization in ClassLoaderHelper and fix VersionTest.
 - Revert changes to MacOsX sun.nio.fs.BsdFileStore; the version check is being removed in another PR.
 - Review comment updates
 - Simplify exception handling
 - Simplify version parsing
 - 8306678: Replace use of os.version with an internal Version record
 - Use and test of "s390" verified by reviewer.
 - Merge branch 'master' into 8304915-arch-enum
 - ... and 17 more: https://git.openjdk.org/jdk/compare/0f3828dd...995750aa

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

Changes: https://git.openjdk.org/jdk/pull/13584/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13584&range=03
  Stats: 691 lines in 12 files changed: 609 ins; 65 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13584/head:pull/13584

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

From smarks at openjdk.org  Mon May  1 16:24:53 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 1 May 2023 16:24:53 GMT
Subject: RFR: 8302496: Runtime.exit incorrectly says it never throws an
 exception
In-Reply-To: <0OBEeBkxeo5tz3O_fb9lTZ64fHMHglG1H78g5bRS7wo=.e4d29694-2409-4eee-9ab8-14ea5e93f06f@github.com>
References: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
 <eVY0HhKjkKGrMMfVlfQLWvmbesi3l9ENunDAjEx9eJ8=.f2b97ad1-5cde-4b68-936f-64250e765a59@github.com>
 <v08MOHlrPawxX2WKpwTYQH7aKtYRlNY7DG9zT1JRVR0=.afab9388-7cc5-40b0-aabe-5eee5cfb3ce7@github.com>
 <0OBEeBkxeo5tz3O_fb9lTZ64fHMHglG1H78g5bRS7wo=.e4d29694-2409-4eee-9ab8-14ea5e93f06f@github.com>
Message-ID: <F9Kcn9jdxeFjQw-bExPswiIHSea8VTyGxKqPeH-Cm64=.37f2886b-fac8-42cb-bb35-e41dcbad7166@github.com>

On Mon, 1 May 2023 05:33:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Yeah I had some misgivings mentioning the SM first, but if it's not mentioned, then the assertions in the rest of the text become hedged and uncertain. The SM, checkExit, and whether the exit value is allowed all have to be mentioned somewhere anyway. It would be awkward to try to wedge all of this into a subordinate or parenthetical clause of some other sentence.
>> 
>> Even though we know the SM is on the way out, it's still part of Java SE 21, and it ought to be specified correctly. When the SM is actually removed, we'll have to revisit these specs anyway. Choosing different wording now won't make the future change any easier or harder.
>
> One thing you could do is reduce the words down to something like "Unless denied exiting by the security manager, this method blocks indefinitely ..." to avoid complicating the first paragraph with something that only arises with a niche execution mode. If needed, a later paragraph could have this detail, or just leave it to the existing @throws text where the permission check is specified.

OK, that works. I'll develop an update.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13706#discussion_r1181688244

From rriggs at openjdk.org  Mon May  1 16:30:23 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 May 2023 16:30:23 GMT
Subject: RFR: 8306678: Replace use of os.version with an internal Version
 record [v5]
In-Reply-To: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
Message-ID: <aknhy40ndcuXVv3BXQk7ZqEMyL0NLCaZ83xHN5WAcOA=.8be25483-d985-4d7e-9861-25a2b16f08b0@github.com>

> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
> Add `OperatingSystem.version()` to return the version of the running OS.
> Replace uses of os.version in java.base.
> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.

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

 - Merge branch 'master' into 8306678-os-version
 - Merge branch '8304915-arch-enum' into 8306678-os-version
 - Correct comment on isPPC64() and refer to isLittleEndian() instead of mentioning PPC64LE
 - Simplify initialization in ClassLoaderHelper and fix VersionTest.
 - Revert changes to MacOsX sun.nio.fs.BsdFileStore; the version check is being removed in another PR.
 - Review comment updates
 - Simplify exception handling
 - Simplify version parsing
 - 8306678: Replace use of os.version with an internal Version record
 - Use and test of "s390" verified by reviewer.
 - ... and 18 more: https://git.openjdk.org/jdk/compare/f00a748b...1b5bd0f1

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

Changes: https://git.openjdk.org/jdk/pull/13584/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13584&range=04
  Stats: 285 lines in 6 files changed: 268 ins; 10 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13584.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13584/head:pull/13584

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

From jwaters at openjdk.org  Mon May  1 16:48:27 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 1 May 2023 16:48:27 GMT
Subject: RFR: 8307163: JLONG_FORMAT_SPECIFIER should be updated on Windows
Message-ID: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>

Windows no longer uses I64d anywhere in their newer compilers, instead using the conforming lld specifiers. Minor cleanup here in JLI code to reflect that

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

Commit messages:
 - JLONG_FORMAT_SPECIFIER should be updated on Windows

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

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

From jvernee at openjdk.org  Mon May  1 16:48:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 1 May 2023 16:48:30 GMT
Subject: RFR: 8304888: Add dedicated VMProps for linker and fallback linker
 [v4]
In-Reply-To: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
References: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
Message-ID: <x4ODnhgyEawHnMJNv7FQTQbUpv67dQsISF4_wWOihIM=.c63a6897-e530-4943-885c-ec6462837a43@github.com>

> This patch adds a dedicated jtreg property to check which CABI is being used by the JDK, which can be used both to check whether the foreign linker is supported, and whether the fallback linker is being used. (and, possibly it can also be use to check for a particular ABI in case we want to add ABI specific tests).
> 
> Checking whether the foreign linker is supported currently requires using an unwieldy expression that checks if we are running on a platform that has a foreign linker port. Checking for the fallback linker currently uses `vm.flavor != "zero"` which is not always correct, since the fallback linker can also be used on other platforms which are not `zero`.
> 
> To initialize the property, VMProps directly reads `jdk.internal.foreig.CABI::current()`. Since this class is in an internal package, `--add-exports` flags are added as javac flags and VM flags for the extra prop definitions class.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:

 - UNKNOWN -> UNSUPPORTED + fix TestLinker on FALLBACK
 - Merge branch 'master' into VMProps
 - Merge branch 'master' into VMProps
 - use only jdk.CABI property
 - use extra props to check for linker
 - Add fallbackLinker vmprop
 - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
   
   rename has_port
 - rename has_port
 - Merge pull request #2 from JornVernee/WSL_BB
   
   account for missing functional in WSL in TestByteBuffer
 - account for missing mincore on WSL in TestByteBuffer
 - ... and 36 more: https://git.openjdk.org/jdk/compare/7d07d195...272478b6

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

Changes: https://git.openjdk.org/jdk/pull/13429/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13429&range=03
  Stats: 129 lines in 50 files changed: 41 ins; 8 del; 80 mod
  Patch: https://git.openjdk.org/jdk/pull/13429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13429/head:pull/13429

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

From jvernee at openjdk.org  Mon May  1 16:58:24 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 1 May 2023 16:58:24 GMT
Subject: RFR: 8304888: Add dedicated VMProps for linker and fallback linker
 [v3]
In-Reply-To: <V5QWHauI0ClkgkAR7z_ggUUk4_m3S3XD8JaFsISWrao=.d3ec8b03-b0ea-4dc8-baa8-d5136e7298ff@github.com>
References: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
 <V5QWHauI0ClkgkAR7z_ggUUk4_m3S3XD8JaFsISWrao=.d3ec8b03-b0ea-4dc8-baa8-d5136e7298ff@github.com>
Message-ID: <AGNumJk-NCNGjl9FlUy-DRkZqHlqFxz9KTt23A1dOoA=.5f67f0cb-ebc1-4f8b-a416-a4d1e4f4fc4a@github.com>

On Fri, 28 Apr 2023 12:59:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds a dedicated jtreg property to check which CABI is being used by the JDK, which can be used both to check whether the foreign linker is supported, and whether the fallback linker is being used. (and, possibly it can also be use to check for a particular ABI in case we want to add ABI specific tests).
>> 
>> Checking whether the foreign linker is supported currently requires using an unwieldy expression that checks if we are running on a platform that has a foreign linker port. Checking for the fallback linker currently uses `vm.flavor != "zero"` which is not always correct, since the fallback linker can also be used on other platforms which are not `zero`.
>> 
>> To initialize the property, VMProps directly reads `jdk.internal.foreig.CABI::current()`. Since this class is in an internal package, `--add-exports` flags are added as javac flags and VM flags for the extra prop definitions class.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 44 commits:
> 
>  - Merge branch 'master' into VMProps
>  - use only jdk.CABI property
>  - use extra props to check for linker
>  - Add fallbackLinker vmprop
>  - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
>    
>    rename has_port
>  - rename has_port
>  - Merge pull request #2 from JornVernee/WSL_BB
>    
>    account for missing functional in WSL in TestByteBuffer
>  - account for missing mincore on WSL in TestByteBuffer
>  - Merge branch 'master' into PR_21_V2
>  - 8305369: Issues in zero-length memory segment javadoc section
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/b827ce83...8a6df30e

Thanks for the reveiw. I've added a comment that explains the property.

During testing after the merge I noticed that the `@requires` tags were checking against `"UNKNOWN"` while they should have been checking against `"UNSUPPORTED"`.

I've fixed this and re-tested on the following configurations:

- Windows/x64, tests full port
- Windows/x86, tests UNSUPPORTED (I also needed to fix an unrelated issues in one of the native test libraries for this to work. That is not included in this patch)
- Linux/x64 with CABI set to FALLBACK
- Linux/x64/zero (also FALLBACK)

For the latter two to pass, I had to fix an issue in `TestLinker` as well, where some test cases brought in by the merge with master were failing on the fallback linker, since it doesn't support by-value unions. The fix conditionally adds those test cases only when we are not running on the fallback linker.

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

PR Comment: https://git.openjdk.org/jdk/pull/13429#issuecomment-1529932049

From mark.yagnatinsky at barclays.com  Mon May  1 17:12:43 2023
From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com)
Date: Mon, 1 May 2023 17:12:43 +0000
Subject: a plea for blocking peek
Message-ID: <MN2PR12MB36161B757A4D48C39A5A4D79F96E9@MN2PR12MB3616.namprd12.prod.outlook.com>

I'm not sure if this I'm breaking etiquette for this list but I'm going to risk resending my first message because it got zero replies.  If it was simply too long, please let me know and I'll attempt a shorter version.

Here's like to original:
https://mail.openjdk.org/pipermail/core-libs-dev/2023-April/104931.html

From: Yagnatinsky, Mark : Markets Pre Trade
Sent: Thursday, April 27, 2023 12:28 PM
To: core-libs-dev at openjdk.org
Subject: RE: blocking peek for blocking queues

Someone said this is the right list for this, so forwarding from jdk-dev with a small tweak

I'd like to make a case for adding a blocking variant of peek() to BlockingQueue.
This has apparently been suggested before:
https://bugs.openjdk.org/browse/JDK-6653412
At the time, the verdict was that the proposed use case for a blocking peek was not very compelling, but " If a compelling use case is available, we may reconsider and reopen this RFE"
For one thing, that use case was inherently racy, and ideally the standard library should not be encouraging races.
And for another thing, this was before the invention of default methods, so a new interface would be needed.
I'd like to present what might be a more sympathetic use case, where a blocking peek actually makes it easier to avoid races.
(This is not hypothetical; I've spent all day trying to cope with the lack of a blocking peek.  I think I succeeded, but it was tough.)

Let's start at the beginning.  The game known as "multithreaded programming" can be played on 3 difficulty levels: easy, medium, and hard.
Easy mode is when the JDK happens to have a high-level tool (e.g., a Collection or an Executor or something) such as DelayQueue that does exactly what you want.
Sadly, the JDK is finite, and even Maven Central is finite, so this not guaranteed to happen, though it's nice when it does.
At the other extreme is hard mode, when every nanosecond counts and you must resort to the sorts of mental gymnastics that were involved when String.hashCode was re-worked to avoid re-computing hash codes equal to zero.

This email is about the medium difficulty level.  In this mode, you must glue together two or three collections to get what you want.
To be concrete, suppose we want to glue a map together with a blocking queue, since that's a simplified version of what I was doing.  (In particular I was using a DelayQueue and a HashMap.)
Since we're not playing on hard mode, we're going to allow ourselves to guard the entire data structure by one giant lock whenever it seems convenient, without worrying about performance.
In fact, let's give a name to this lock.  Since I'm not feeling very creative right now, let's call it LOCK.  Similarly, let's call our compound data structure STRUCT.
My usual heuristic to "win" (that is, to make sure my code is correct, or at least non-racy) on medium difficulty goes something like this.
First, figure out whether there is any way for STRUCT to be "invalid".
For instance, maybe "it's valid if and only if every entry in the queue has a corresponding entry in the map".
One could then write a brief comment in the code explaining what "valid" means, or perhaps even write an "isValid()" method for testing purposes.
Once we've decided what it means for STRUCT to be "valid" (aka, non-corrupt), we can try to maintain the following invariant:
EITHER some thread holds the LOCK, and no other thread is using STRUCT right now,
OR ELSE the LOCK  is not held by any thread, and thus STRUCT is currently in a valid state.
Sometimes the invariant above is a bit too strong, and it's convenient to weaken it slightly.  So we can instead consider the following rule:
RULE: we must never mutate STRUCT unless we hold the LOCK.
If we uphold the invariant, then we must be following the rule, but not vice versa.
(The rule doesn't forbid queries without the lock; it only forbids writes.)

Finally, we come to the point.  The lack of a blocking peek in BlockingQueue has forced me to break the above "weakened" rule.
I had to invent a new much weaker rule, something like "please carefully think through all possible interleaved executions; if they all work, great!".
What went wrong?  Well, one of the methods I wanted on STRUCT was basically "call take() on the queue, and then do things with the result".
The trouble is that you can't usually afford to hold a lock while calling take(), since it can block forever, and in the meantime you've "locked out" anyone who could have added something and thus unblocked you.
Thus, I split my method into two pieces: In PART_ONE we call take() without the LOCK, and once take() returns I grab the lock right away and run PART_TWO.
But notice that this breaks the RULE from the previous paragraph: I mutated the STRUCT without holding the LOCK.
This means my method is not atomic: it's possible for some other thread to observe that PART_ONE is done but PART_TWO is not started.
Typically this means that other threads can now observe the STRUCT in an invalid (aka corrupt/broken) state.

Now, suppose we had a blocking peek.  How does that help?  In that case, we would still break our method into two pieces.
To avoid confusion, let's call them PART_A and PART_B.  In PART_A we call blockingPeek() without holding the LOCK.
Note that we completely ignore the return value from peek; for all we care, the return type is "void" instead of "T".
This breaks the "invariant" from a few paragraphs ago since we're technically "using" the STRUCT but it respects the "rule" since we're not mutating it.
Once peek returns, PART_B begins.  Here, we grab the lock, and do a non-blocking poll() on the queue.
It's might return "null" if someone raced us to get the lock.  But from our perspective that's okay: it's just like a spurious wakeup from a raw wait() call.
The reason it's okay is that we haven't done anything yet, so we can just call blockingPeek() again and hope for better luck next time.
Similarly we don't care if poll() returns a different item than blockingPeek() originally did, since we never looked at what peek() returned.
The rest of PART_B is basically PART_TWO from the "peek-less" world.
Note that this way, our method appears atomic to other threads, since PART_A doesn't actually do anything; all the work happens in PART_B, which is guarded by the LOCK.

Thoughts?

This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com.
__________________________________________________________________________________ 
If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. 
__________________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230501/da85388f/attachment-0001.htm>

From rriggs at openjdk.org  Mon May  1 18:07:28 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 May 2023 18:07:28 GMT
Subject: Integrated: 8306678: Replace use of os.version with an internal
 Version record
In-Reply-To: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
References: <7WZZmgWnPCd2eRSUDi8V7tfUr4i8vrsHqpLMnjiCrgg=.eb419610-f2f0-480e-8a8e-3d31c6966c3a@github.com>
Message-ID: <vPCfLM0JD3-qpefTvw31spR7ozSJur1gP9DTJfMPIDg=.a650e9ec-1fe4-4f3b-95bd-5cf9e5b93c12@github.com>

On Fri, 21 Apr 2023 16:44:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Create an internal Version record to hold and compare versions of the form (major, minor, micro).
> Add `OperatingSystem.version()` to return the version of the running OS.
> Replace uses of os.version in java.base.
> Subsequent PRs will apply to uses in other modules including, jdk.jlink, jdk.jpackage, and java.desktop.

This pull request has now been integrated.

Changeset: 6acf032d
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6acf032db891875c6a7403a18d5dc7c552fb4c11
Stats:     285 lines in 6 files changed: 268 ins; 10 del; 7 mod

8306678: Replace use of os.version with an internal Version record

Reviewed-by: mchung

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

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

From alanb at openjdk.org  Mon May  1 18:23:36 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 May 2023 18:23:36 GMT
Subject: RFR: 8304888: Add dedicated VMProps for linker and fallback linker
 [v4]
In-Reply-To: <x4ODnhgyEawHnMJNv7FQTQbUpv67dQsISF4_wWOihIM=.c63a6897-e530-4943-885c-ec6462837a43@github.com>
References: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
 <x4ODnhgyEawHnMJNv7FQTQbUpv67dQsISF4_wWOihIM=.c63a6897-e530-4943-885c-ec6462837a43@github.com>
Message-ID: <XmI91uoN53mIzHuNAn8GUMLuZKjLPxeSPuG4ScgVmPM=.e74651a7-ccb2-40bf-b45f-b345933ef382@github.com>

On Mon, 1 May 2023 16:48:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds a dedicated jtreg property to check which CABI is being used by the JDK, which can be used both to check whether the foreign linker is supported, and whether the fallback linker is being used. (and, possibly it can also be use to check for a particular ABI in case we want to add ABI specific tests).
>> 
>> Checking whether the foreign linker is supported currently requires using an unwieldy expression that checks if we are running on a platform that has a foreign linker port. Checking for the fallback linker currently uses `vm.flavor != "zero"` which is not always correct, since the fallback linker can also be used on other platforms which are not `zero`.
>> 
>> To initialize the property, VMProps directly reads `jdk.internal.foreig.CABI::current()`. Since this class is in an internal package, `--add-exports` flags are added as javac flags and VM flags for the extra prop definitions class.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
> 
>  - UNKNOWN -> UNSUPPORTED + fix TestLinker on FALLBACK
>  - Merge branch 'master' into VMProps
>  - Merge branch 'master' into VMProps
>  - use only jdk.CABI property
>  - use extra props to check for linker
>  - Add fallbackLinker vmprop
>  - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
>    
>    rename has_port
>  - rename has_port
>  - Merge pull request #2 from JornVernee/WSL_BB
>    
>    account for missing functional in WSL in TestByteBuffer
>  - account for missing mincore on WSL in TestByteBuffer
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/7d07d195...272478b6

I looked at the update (comment on VMProps. cabi, update to TestLinker, and s/UNKNOWN/UnSUPPORTED). Looks okay to me.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13429#pullrequestreview-1407895449

From naoto at openjdk.org  Mon May  1 18:41:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 1 May 2023 18:41:15 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v9]
In-Reply-To: <w_VQMDXdJScfmyacC0Mxsq4ZshVvw8vLNEcw62YbH1I=.4296584d-da35-4b67-8914-ac26aeef1873@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <w_VQMDXdJScfmyacC0Mxsq4ZshVvw8vLNEcw62YbH1I=.4296584d-da35-4b67-8914-ac26aeef1873@github.com>
Message-ID: <PFk-zQYQzdekhawmb67jT4W-J6Yn-qPaZJD5GD2SoQE=.437a18f0-b8cc-45a2-8399-b0c4fc8c4403@github.com>

On Fri, 28 Apr 2023 05:47:24 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
>> 
>> CSR: https://bugs.openjdk.org/browse/JDK-8303531
>> 
>> Tests: XML SQE and JCK tests passed.
>
> Joe Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8303530
>  - Update based on the review meeting on 4/5. Added (duplicated) definitions in jaxp.properties; Rewrote Property Precedence with samples; Other updates.
>  - update javadoc as discussed in the review meeting; add a sample configuration file jaxp.properties; update impl and tests accordingly.
>  - continue support stax.properties at the impl level, though dropped from the spec
>  - change prefix from jdk to java
>  - change prefix from jdk to java; rm zip file that accidentally checked in
>  - update config file description; add a general scope and order section; move value definition for external properties to class description
>  - clean up tests; fix copy&paste error.
>  - 8303530: Add system property for custom JAXP configuration file

Regarding the new unit tests, it looks like there are a lot of boilerplate codes. Can they be shared?

src/java.xml/share/classes/jdk/xml/internal/SecuritySupport.java line 234:

> 232:                     }
> 233:                     firstTimeCustom = false;
> 234:                 }

Is it possible if `firstTime` and `firstTimeCustom` differ? Would it be possible to get rid of `firstTimeCustom` and move this piece into `firstTime` block?

src/java.xml/share/classes/jdk/xml/internal/SecuritySupport.java line 253:

> 251:                 return true;
> 252:             } catch (IOException e) {
> 253:                 // ignore file not found error

How could "file not found" occur assuming `SecuritySupport.doesFileExist(f)` returns true?

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

PR Review: https://git.openjdk.org/jdk/pull/12985#pullrequestreview-1406630394
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1180861488
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1180862384

From stsypanov at openjdk.org  Mon May  1 18:41:49 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 1 May 2023 18:41:49 GMT
Subject: Integrated: 8300818: Reduce complexity of padding with
 DateTimeFormatter
In-Reply-To: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
Message-ID: <vmBhZBCZsystY0HpWSr_90JiNpQJMUId-wHpeFGQoRE=.6819c403-e38c-4ccc-b422-170d8afc7a45@github.com>

On Sat, 21 Jan 2023 21:01:48 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>   .appendLiteral("Date:")
>   .padNext(20, ' ')
>   .append(DateTimeFormatter.ISO_DATE)
>   .toFormatter();
> String text = dtf.format(LocalDateTime.now());

This pull request has now been integrated.

Changeset: 561ec9c5
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/561ec9c5a06e5baeb0cf72463d14d1d720facb13
Stats:     84 lines in 2 files changed: 83 ins; 0 del; 1 mod

8300818: Reduce complexity of padding with DateTimeFormatter

Reviewed-by: redestad, rriggs

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

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

From jvernee at openjdk.org  Mon May  1 18:54:20 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 1 May 2023 18:54:20 GMT
Subject: RFR: 8307164: TestSegmentCopy times out (mainline)
Message-ID: <TJv9o5TXATf6PARMaj0RDYNvvX_DGRjlOKxxbBETkn0=.c3bb9323-4c5b-467f-92d7-98ca3e2ff589@github.com>

Port of: https://github.com/openjdk/panama-foreign/pull/827

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

Commit messages:
 - 8303831: TestSegmentCopy times out

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

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

From jrose at openjdk.org  Mon May  1 21:03:27 2023
From: jrose at openjdk.org (John R Rose)
Date: Mon, 1 May 2023 21:03:27 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v11]
In-Reply-To: <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
Message-ID: <gEXReveQQhF6qnmA3qrCTacfm7s00WrkMG4BpeJwPhI=.1192dd8c-1d83-41dd-b6b2-886a5939154b@github.com>

On Mon, 1 May 2023 14:56:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with a check to the class data. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:
> 
>  - Renames
>  - Merge branch 'master' into explore/mhp-iface
>  - Consolidate iteration over public methods
>  - Define MH proxy class in a dynamic module
>  - Fix test that depend on WrapperInstance
>  - Require an original lookup in constructor arguments to prevent unintended instantiation
>  - pass interface info via condy,
>    drop explicit ea flags
>    initialize benchmark work variable randomly
>    benchmarks just need 1 fork
>  - Nuke WrapperInstance
>  - Merge branch 'master' into explore/mhp-iface
>  - Whitespace, cleanup, rename benchmarks to be informative
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/c839bed1...f5d0ef0a

I wonder if we should, in this API point, try harder to avoid spinning so many HCs.

I?ve been thinking a lot about Leyden lately, and HCs are (in their current usage) a problem for Leyden, because they are hard to characterize in static analysis; they tend to behave like opaque ?live objects? even if they are mostly just customized code.  I have a number of possible fixes in mind, but the common thread is to try to make fewer of them, one per ?code shape? if possible.  (Whatever ?code shape? ends up being!)

I think you could do this by having the HC have a final non-static field for each required MH (one per overload point); each os an asType adaptation of the original MH.  The actual code of each HC implementation method would be a single invokeVirtual of a strongly typed `MH::invokeExact` call.  This is the code shape in the current PR (see the `createTemplate` method) *except* that I am saying that the MH in question should come from `getfield` not `ldc/condy`.

HC fields are supposed to fold up; if they don?t we can help them in this case.  (That is, constant folding of the MH pointer should not be a roadblock; that?s on the JIT to fix by adjusting the `TrustFinalFields` logic.)

The only other method that needs adjustment is `<init>`.  That needs a series of `asType` calls (on `ldc/MethodType`) followed by `putField`.

I see that the error-checking logic in `<init>` is hand-coded assembly code.  Please, let?s not do that.  The code should call a consolidated helper method that handles all error logic, out of line.  The helper method should also be split into (a) parts that run every time, and (b) parts that almost never run, which make and throw an exception.

One reason to avoid assembly is readability/maintainability.  Another reason is that the JIT actually prefers smaller methods bodies, which is why I say you should code that stuff out of line (in as maintainable Java helper).

So the HC should look like:


__Hidden class HC implements IFace {
private final MethodHandle mh1,  mh2?;

HC(Lookup lookup, MethodHandle target) {
  SomeHelperClass.checkAccess(lookup, IFace.class);
  mh1 = target.asType(LDC[ methodType( mh1Info.desc) ]);
  //init mh2...
}

@Override R1 iFaceMethod(A1a a1a, ?) {
  return (R1) mh1.invokeExact(a1a, ?);  //lowers to invokeBasic
}

//declare mh2...
}


It shouldn?t be necessary to have a class-data for the HC, in this case.  This would make the HC more shareable and support pregeneration in Leyden.

Did I miss a problem with this approach?

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1530257003

From jlu at openjdk.org  Mon May  1 21:19:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 1 May 2023 21:19:25 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v2]
In-Reply-To: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
Message-ID: <1_a3GJ3Fkn4UK_ti_JjK1BFRu9ijs5-wHzqz-9WDCYU=.69a0e95e-1d87-4870-b2cf-ff56604e1640@github.com>

> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
> 
> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
> 
> 
> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
> - Will not case fold variant subtags
> - Will not case fold private use subtags prefixed by "lvariant"
> 
> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Adjust specification to elaborate on JDK Variant special cases
 - Use ILE over IAE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13679/files
  - new: https://git.openjdk.org/jdk/pull/13679/files/25be34d9..91e84efe

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

  Stats: 42 lines in 3 files changed: 19 ins; 7 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/13679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13679/head:pull/13679

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

From jkuhn at openjdk.org  Mon May  1 21:40:38 2023
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Mon, 1 May 2023 21:40:38 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v11]
In-Reply-To: <gEXReveQQhF6qnmA3qrCTacfm7s00WrkMG4BpeJwPhI=.1192dd8c-1d83-41dd-b6b2-886a5939154b@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
 <gEXReveQQhF6qnmA3qrCTacfm7s00WrkMG4BpeJwPhI=.1192dd8c-1d83-41dd-b6b2-886a5939154b@github.com>
Message-ID: <JsenJzacOb7PiWDUOVPlFzl8bcnkD0MrxJCppkfJMFI=.fc5ca34b-09e7-466a-98b1-5a0bf59edcaa@github.com>

On Mon, 1 May 2023 21:00:40 GMT, John R Rose <jrose at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:
>> 
>>  - Renames
>>  - Merge branch 'master' into explore/mhp-iface
>>  - Consolidate iteration over public methods
>>  - Define MH proxy class in a dynamic module
>>  - Fix test that depend on WrapperInstance
>>  - Require an original lookup in constructor arguments to prevent unintended instantiation
>>  - pass interface info via condy,
>>    drop explicit ea flags
>>    initialize benchmark work variable randomly
>>    benchmarks just need 1 fork
>>  - Nuke WrapperInstance
>>  - Merge branch 'master' into explore/mhp-iface
>>  - Whitespace, cleanup, rename benchmarks to be informative
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/48d60d79...f5d0ef0a
>
> I wonder if we should, in this API point, try harder to avoid spinning so many HCs.
> 
> I?ve been thinking a lot about Leyden lately, and HCs are (in their current usage) a problem for Leyden, because they are hard to characterize in static analysis; they tend to behave like opaque ?live objects? even if they are mostly just customized code.  I have a number of possible fixes in mind, but the common thread is to try to make fewer of them, one per ?code shape? if possible.  (Whatever ?code shape? ends up being!)
> 
> I think you could do this by having the HC have a final non-static field for each required MH (one per overload point); each os an asType adaptation of the original MH.  The actual code of each HC implementation method would be a single invokeVirtual of a strongly typed `MH::invokeExact` call.  This is the code shape in the current PR (see the `createTemplate` method) *except* that I am saying that the MH in question should come from `getfield` not `ldc/condy`.
> 
> HC fields are supposed to fold up; if they don?t we can help them in this case.  (That is, constant folding of the MH pointer should not be a roadblock; that?s on the JIT to fix by adjusting the `TrustFinalFields` logic.)
> 
> The only other method that needs adjustment is `<init>`.  That needs a series of `asType` calls (on `ldc/MethodType`) followed by `putField`.
> 
> I see that the error-checking logic in `<init>` is hand-coded assembly code.  Please, let?s not do that.  The code should call a consolidated helper method that handles all error logic, out of line.  The helper method should also be split into (a) parts that run every time, and (b) parts that almost never run, which make and throw an exception.
> 
> One reason to avoid assembly is readability/maintainability.  Another reason is that the JIT actually prefers smaller methods bodies, which is why I say you should code that stuff out of line (in as maintainable Java helper).
> 
> So the HC should look like:
> 
> 
> __Hidden class HC implements IFace {
> private final MethodHandle mh1,  mh2?;
> 
> HC(Lookup lookup, MethodHandle target) {
>   SomeHelperClass.checkAccess(lookup, IFace.class);
>   mh1 = target.asType(LDC[ methodType( mh1Info.desc) ]);
>   //init mh2...
> }
> 
> @Override R1 iFaceMethod(A1a a1a, ?) {
>   return (R1) mh1.invokeExact(a1a, ?);  //lowers to invokeBasic
> }
> 
> //declare mh2...
> }
> 
> 
> It shouldn?t be necessary to have a class-data for the HC, in this case.  This would make the HC more shareable and support pregeneration in Leyden.
> 
> Did I miss a problem with this approach?

@rose00  I was also thinking about if we should spin an own instance for every `MethodHandle`.

An other evaluation criteria is: How do other approaches behave, and what constrains do they have?  
Some alternatives are: lambda (interface is statically known) or invoking `LambdaMetaFactory` with `MethodHandles::invokeExact` as target.
If the type is not statically known, then a lambda can't be used, making it unlikely for the JIT to inline the invokeinterface call as well.

Final fields of hidden classes (and records) are already trusted by the JIT.
But for the JIT to constant fold, it has to inline the invokeinterface target.

So considering the use case of `MethodHandleProxies.asInterfaceInstance` should be taken into account.

------

About checking stuff & helper methods:

A problem with classes that are possibly defined in user modules is:  
Where should we put the check methods?  
If the hidden class can see it, then user code could use it, and this either requires adding a public method as part of the API, or just write it in bytecode in the same class.

This is also done in `java.lang.reflect.Proxy` - the checks if the proxy should release its lookup are written in bytecode.  
Maybe it might be useful to add such an `assertOriginalLookupOf(Lookup l, Class<?> lookupClass)` somewhere.

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1530336013

From jiangli at openjdk.org  Mon May  1 21:57:20 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 1 May 2023 21:57:20 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <Fo_R8bXjDqPZslPylTg16uSKoFPM_iwU83wEoZRPkqA=.2106178e-4a13-4598-a67d-04ebd77a1d8c@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <yk-I2N6h2l7wEgkcHeBAt46OSbDrDxt-P8QgC7pTO_o=.8fa9c1ee-604d-4b97-bcd4-c70355c9564f@github.com>
 <eoIorjwEtpPHUF-IYyAToOMQAeQ6HZNvccYvCT0zCwI=.61a939e7-089e-410b-8361-c3eea99969fd@github.com>
 <Fo_R8bXjDqPZslPylTg16uSKoFPM_iwU83wEoZRPkqA=.2106178e-4a13-4598-a67d-04ebd77a1d8c@github.com>
Message-ID: <7jnvkVtSNboXfFD3ij19fWwDACENTUbFfBYf4_RCoP8=.21fc70f5-0470-4f4a-8770-b8aee9744e09@github.com>

On Sun, 30 Apr 2023 18:34:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > The build is already capable of producing .a files and this patch is building on top of that build feature. The current .a file creation is used by the downstream graal build which needs it for nativeimage.
> 
> Also builds on recent changes to remove duplicate symbol names. It's good that the PR demonstrates that these can be linked to create "javastatic" but having it copy into the run-time image created by jlink is probably not the eventual outcome.
> 
> A possible direction on this is for the build to create a set of packaged modules with the .a files, then have an alternative image builder in jlink that integrates with the native linker. Combined with other parts in Jiangli's slides/proposal, it would mean that jlink could produce a single executable that would work for both the JDK or any set of modules.

The comment from @AlanBateman helped me realize that I should be more specific (in my earlier comment regarding "withdraw the current PR first and extract the .a part into a new PR") about the needed fixes/enhancements related to .a part:

- Create libjvm.a as well when building static-libs-image target, include it in 'images/static-libs/lib'
- Filter out "external" .o files (those are the .o files included from different JDK libraries and needed when creating the .so shared library only) from .a libraries
- For libjvm.a specifically, exclude operator_new.o
- Handle long arguments case for static build in make/common/NativeCompilation.gmk
- Ensure zlib and freetype are bundled when building the static-libs-image target, i.e. libzlib.a and libfreetype.a are included in 'images/static-libs/lib'

It's probably best to create a separate enhancement/bug for those (will create shortly) and continue using JDK-8303796 for the broader discussion/effort.

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

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1530368068

From jiangli at openjdk.org  Mon May  1 21:57:21 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 1 May 2023 21:57:21 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
In-Reply-To: <SrKfBBjz5JhkeUY3WB5xNkyQW3Bh2VCq0wkRvBFcIa8=.caa353b5-d80f-4ef6-993b-6b9b49b8029a@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <_gIwWxLooIGNt-PhNASB-dj32BvyljayoyLXOkNLXYA=.e90e720f-5618-4330-a2d3-91a102bd546f@github.com>
 <fswwIoriIC-x9zeS5I9FU_fZ74upHRtagKJhjyM8P6E=.2993cede-0fe1-4f1b-859b-c1a9d2cacc4e@github.com>
 <qoIFJlMJYKqo5Mrd_NONJ-lwV3pENmRrSJ0cmzzEDEw=.2e5141ab-0f4d-40ca-b35c-f207df87e533@github.com>
 <SrKfBBjz5JhkeUY3WB5xNkyQW3Bh2VCq0wkRvBFcIa8=.caa353b5-d80f-4ef6-993b-6b9b49b8029a@github.com>
Message-ID: <p1epafdQlU8EXdL6R9xnhki4CBiXmgVGjPwTzt9WW48=.8da45b49-96ad-4149-84d9-1c6065b3b4fc@github.com>

On Mon, 1 May 2023 14:03:10 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > Based on the above finding, I pushed a change to use $(JVM_LIBS) for the linking command. @erikj79 could you please see if that resolves the clock_* symbol issues in your environment?
> 
> Yes, it built cleanly with that change.

Thanks for confirm.

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

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1530369506

From jrose at openjdk.org  Mon May  1 22:15:22 2023
From: jrose at openjdk.org (John R Rose)
Date: Mon, 1 May 2023 22:15:22 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v11]
In-Reply-To: <JsenJzacOb7PiWDUOVPlFzl8bcnkD0MrxJCppkfJMFI=.fc5ca34b-09e7-466a-98b1-5a0bf59edcaa@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
 <gEXReveQQhF6qnmA3qrCTacfm7s00WrkMG4BpeJwPhI=.1192dd8c-1d83-41dd-b6b2-886a5939154b@github.com>
 <JsenJzacOb7PiWDUOVPlFzl8bcnkD0MrxJCppkfJMFI=.fc5ca34b-09e7-466a-98b1-5a0bf59edcaa@github.com>
Message-ID: <wgKlj6dzO_2pz_eO89EqOIG7JahD5H85psKy-0wKblg=.8db85922-cb89-4c35-b59f-9622b3bbccc8@github.com>

On Mon, 1 May 2023 21:37:07 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

> `assertOriginalLookupOf`

Yes, that?s the sort of thing I?d expect.  It could go into a `jdk.internal.reflect` class.  Now that we have modules, JDK platform code can use public APIs not accessible to normal users.  Also, the static helper method I?m thinking of would not be a security problem; it just checks inputs, and cannot be overridden by an attacker to capture those inputs.

> But for the JIT to constant fold, it has to inline the invokeinterface target.

That happens due to type profiling and type inference.  It?s reasonably common.  That is one reason to make as few classes as possible, since profiling and inferencing overflows quickly when there are many implementation classes.  Having just one HC means that, if the user is passing only ?that sort? of interface impl (a MH proxy) then it will inline, as long as there is only one HC (with many instances).

I haven?t looked at the proxy code lately but I imagine that it minimizes the number of spun classes for similar reasons.

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1530415350

From liach at openjdk.org  Mon May  1 22:36:27 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 1 May 2023 22:36:27 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v11]
In-Reply-To: <gEXReveQQhF6qnmA3qrCTacfm7s00WrkMG4BpeJwPhI=.1192dd8c-1d83-41dd-b6b2-886a5939154b@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
 <gEXReveQQhF6qnmA3qrCTacfm7s00WrkMG4BpeJwPhI=.1192dd8c-1d83-41dd-b6b2-886a5939154b@github.com>
Message-ID: <KpQ5T-5hYCba5WSvC2Fwe7r6j9ct8_6OPMv9l9kgOEk=.16e6acf3-fa8a-4000-8142-1ca5b58c56c0@github.com>

On Mon, 1 May 2023 21:00:40 GMT, John R Rose <jrose at openjdk.org> wrote:

> I think you could do this by having the HC have a final non-static field for each required MH (one per overload point); each os an asType adaptation of the original MH. The actual code of each HC implementation method would be a single invokeVirtual of a strongly typed MH::invokeExact call. This is the code shape in the current PR (see the createTemplate method) except that I am saying that the MH in question should come from getfield not ldc/condy.

This was the implementation up to [953fcc9f](https://git.openjdk.org/jdk/pull/13197/files/953fcc9fdb4bb80389c770b585d5f9b4d3936947) (webrev 0). It had an invocation performance of 2ns/op as opposed to Proxy's 6ns/op, but the condy implementation has 0.41ns/op.

I indeed can move the argument validation (with a jdk.internal object instance, will add to wrapperInstanceType and wrapperInstanceTarget to avoid method clashes) and marker interface into jdk.internal.access.invoke package and export it to the HC's module (thanks to mandy for the patch). And moving `asType` to the constructor is viable too; we just need to propagate the thrown `WrongMethodTypeException` to the caller.

So assuming the methodhandle-in-field approach has good performance, we will probably generate something like:

package jdk.MHProxy5;
import sun.invoke.empty.Empty;
import sun.invoke.WrapperInstance;
//...
final /*synthetic*/ class Iface$MHProxy implements Iface, WrapperInstance {
    final MethodHandle originalMh, mh1, mh2, ...;
    // no access worries, in a non-open module, users cannot call
    Iface$MHProxy(MethodHandle originalMh, MethodHandle mh) {
        this.originalMh = originalMh; // possibly didn't bind caller
        this.mh1 = mh.asType(/*ldc MethodType */);
        //...
    }
    // Iface implementations
    public R singleMethod(P0 p0, ...) { try { return mh1.invokeExact(p0, ...); /* explicit descriptor */ } catch ... (rethrow, wrap throw)
    // ...
    // WrapperInstance implementations
    public Class<?> wrapperType(Empty empty) { return Iface$MHProxy.class; } // unused Empty parameter prevents method clash
    public MethodHandle wrapperTarget(Empty empty) {return originalMh;}
}


For proxy code, I think they look up the set of interfaces and generate one class in one module for each set, which is close to the single-class + module implementation outlined above.

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1530438142

From jvernee at openjdk.org  Mon May  1 22:36:28 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 1 May 2023 22:36:28 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v11]
In-Reply-To: <gEXReveQQhF6qnmA3qrCTacfm7s00WrkMG4BpeJwPhI=.1192dd8c-1d83-41dd-b6b2-886a5939154b@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
 <gEXReveQQhF6qnmA3qrCTacfm7s00WrkMG4BpeJwPhI=.1192dd8c-1d83-41dd-b6b2-886a5939154b@github.com>
Message-ID: <nSM6OSZNpXf5UMXQRLz60zSySTcjGByzgyVoCcIlJBM=.1006d5c8-87a6-4073-b01b-2b387150b84d@github.com>

On Mon, 1 May 2023 21:00:40 GMT, John R Rose <jrose at openjdk.org> wrote:

> HC fields are supposed to fold up; if they don?t we can help them in this case. (That is, constant folding of the MH pointer should not be a roadblock; that?s on the JIT to fix by adjusting the TrustFinalFields logic.)

The issue with this is that constant folding of a field only happens when to holder object is also constant, which is not necessarily the case. For the non-constant case, we have to rely on type profiling to get optimal performance.

(recapping) Let's say we have a call site to a method `foo` in interface `I`. But, the receiver value we see at this call site is only ever an instance of a class `C`. The JIT can see from the profile of that call site that we only ever see a receiver of type `C`, and then do a guarded inline of `C::foo`, giving us optimal performance. This works because the type `C` has a 1-to-1 mapping with the implementation that we inline into the call site.

However, in the case of method handles, there is no 1-to-1 mapping between the type of the receiver, `MethodHandle`, and the target method. Instead, the target method depends on a particular receiver _instance_. So, to make type profiling work, we need to introduce a 1-to-1 mapping with a type, hence we define a hidden class HC per method handle instance, where the MH instance is constant for that particular class. This creates the 1-to-1 mapping. Type profiling works for the HC type we define, we inline `HC::foo`, and find that: hey, in HC::foo's implementation, the target MH is constant, so we can inline through that as well. Giving us once again, optimal performance.

I've considered in the past that we could add _instance_ based profiling for MethodHandles, so that we can once again get a 1-to-1 mapping between a profile and a method we want to inline. But it wouldn't work in the case of MHP::asInterfaceInstance. Since profiles are tied to a BCI, it wouldn't work if we create multiple instances of the same HC for different MH instances, since the profile of the `invokeExact` call site we generate in the HC would be polluted by the different MH instances. (unless we implement: https://bugs.openjdk.org/browse/JDK-8015416)

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1530442581

From jkuhn at openjdk.org  Mon May  1 22:36:29 2023
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Mon, 1 May 2023 22:36:29 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v11]
In-Reply-To: <wgKlj6dzO_2pz_eO89EqOIG7JahD5H85psKy-0wKblg=.8db85922-cb89-4c35-b59f-9622b3bbccc8@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
 <gEXReveQQhF6qnmA3qrCTacfm7s00WrkMG4BpeJwPhI=.1192dd8c-1d83-41dd-b6b2-886a5939154b@github.com>
 <JsenJzacOb7PiWDUOVPlFzl8bcnkD0MrxJCppkfJMFI=.fc5ca34b-09e7-466a-98b1-5a0bf59edcaa@github.com>
 <wgKlj6dzO_2pz_eO89EqOIG7JahD5H85psKy-0wKblg=.8db85922-cb89-4c35-b59f-9622b3bbccc8@github.com>
Message-ID: <0N9x0c_ywA2IZPBeaMSdu7V8Ji9V7Uu2NUS5DcIFrjk=.fd8aceb4-8849-4805-98eb-caf7d4ed2b04@github.com>

On Mon, 1 May 2023 22:11:58 GMT, John R Rose <jrose at openjdk.org> wrote:

> JDK platform code

Yes. This works if the class is in a non-user module. Otherwise exporting an internal package would expose that to user-code as well.  
`java.lang.reflect.Proxy` does need to inject the proxy class into user-packages if one interface is non-public, so it could not use that.

> I haven?t looked at the proxy code lately but I imagine that it minimizes the number of spun classes for similar reasons.

Yes, it caches the proxy class with the tuple `(ClassLoader, interfaces)`. The order of the interfaces matters.

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1530446571

From naoto at openjdk.org  Mon May  1 22:45:17 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 1 May 2023 22:45:17 GMT
Subject: RFR: 8298087: XML Schema Validation reports an required attribute
 twice via ErrorHandler [v2]
In-Reply-To: <Jhzib_IGDFmp8vo_qyCCQuGsabPnROYa8_Nfff9LulA=.eba8df2e-124e-4640-971c-2f9c7bab7e74@github.com>
References: <FTLJmbYCPPkZvFFFNZcRZGiDdc6osG9HZ3TRB024XZc=.745f57ce-fd72-4572-9aa0-d78036eb9dfa@github.com>
 <Jhzib_IGDFmp8vo_qyCCQuGsabPnROYa8_Nfff9LulA=.eba8df2e-124e-4640-971c-2f9c7bab7e74@github.com>
Message-ID: <T89bLwBsUqf33Sn_rFWqbeI7XEnLrOFayZV1FGI4ESc=.841b0f12-dfc4-4900-b555-fc9c2b2220f5@github.com>

On Sat, 29 Apr 2023 01:32:23 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Fix a copy n paste error in XMLSchemaValidator. When the patch was applied while updating to Xerces 2.12.2, the original code was not removed, resulting in reporting validation error twice.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   removing the line that changed locale. It's not necessary as the concern was the number of errors reported

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13722#pullrequestreview-1408193651

From jvernee at openjdk.org  Mon May  1 22:47:25 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 1 May 2023 22:47:25 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v11]
In-Reply-To: <nSM6OSZNpXf5UMXQRLz60zSySTcjGByzgyVoCcIlJBM=.1006d5c8-87a6-4073-b01b-2b387150b84d@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
 <gEXReveQQhF6qnmA3qrCTacfm7s00WrkMG4BpeJwPhI=.1192dd8c-1d83-41dd-b6b2-886a5939154b@github.com>
 <nSM6OSZNpXf5UMXQRLz60zSySTcjGByzgyVoCcIlJBM=.1006d5c8-87a6-4073-b01b-2b387150b84d@github.com>
Message-ID: <aBSl3pzfJGY6jLpYHjK9Sh2qOqEqvRyrnzFvUE_tWTw=.cb76ca37-334c-44d9-bccc-c7696e30012b@github.com>

On Mon, 1 May 2023 22:25:31 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Type profiling works for the HC type we define, we inline `HC::foo`, and find that: hey, in HC::foo's implementation, the target MH is constant, so we can inline through that as well. Giving us once again, optimal performance.

My fear is that, without this, people will keep reaching for LambdaMetafactory instead, which does have the ability to give you a type per MethodHandle instance.

Maybe a compromise is to let the current `asInterfaceInstance` share the classes (using MH instance fields), but we add a `asUniqueInterfaceInstance` (name tbd) which does guarantee a 1-to-1 mapping between a type and a MH instance (which would allow inlining).

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1530476940

From jiangli at openjdk.org  Mon May  1 22:50:27 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 1 May 2023 22:50:27 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
 [v2]
In-Reply-To: <VwR0TLPzfG4luNZFUlvEzvlmMxgUEhp2rHnqvv2ad0A=.a617fcd6-4cc9-4c7c-9f2d-389ea05a62b3@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <VwR0TLPzfG4luNZFUlvEzvlmMxgUEhp2rHnqvv2ad0A=.a617fcd6-4cc9-4c7c-9f2d-389ea05a62b3@github.com>
Message-ID: <wNbNKD_vAbe67iaDHRYEhHseMjWxQRwXxzgKua77kL4=.9984ea2c-15e0-40b9-8391-68bf1c520881@github.com>

On Sat, 29 Apr 2023 03:57:53 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Initial implementation for supporting building a fully statically linked (with a desired set of JDK native libraries and libjvm) Java launcher executable, which is named as 'javastatic'.
>> 
>> In this PR, the support is only added for the linux platform. Both gcc and clang can be supported. For current demo/testing purpose, the bin/javastatic is statically linked with awt headless and other common JDK native libraries. The current PR doesn't fully handle creating the bundle for a static JDK image, which can be supported later.
>> 
>> To build the statically linked executable:
>> 
>> 1. Configure the JDK build with --with-static-java=yes
>> 2. Build static-java-image, e.g. 'make jdk-image static-java-image'
>> 
>>  The 'javastatic' binary created by the static-java-image target is not runnable. The runtime issues will be handled separately.
>> 
>> Following is a summary of the changes in this PR:
>> 
>> - Add make/autoconf/static-java.m4 for defining STATIC_JAVA_SETUP. Add STATIC_JAVA_SETUP to make/autoconf/configure.ac.
>> 
>> - Changes in make/Main.gmk
>> ? - Add HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and DeclareHotspotStaticLibsRecipe for building libjvm static library.
>> ? - Add static-java-image for creating the fully statically linked standard Java launcher binary, bin/javastatic. The build process also places libjvm.a into the 'static-libs' image lib/ directory.
>> 
>> - Add make/StaticLink.gmk, which contains the main support for creating the fully statically linked Java launcher binary.
>> 
>> - Setup LDFLAGS_CXX_STATIC_JDK based on $TOOLCHAIN_TYPE in make/autoconf/flags-ldflags.m4.
>> 
>> - Always use bundled libraries for zlib, freetype, etc for static build support. The related changes are in make/autoconf/lib-bundled.m4 and make/autoconf/lib-freetype.m4. Building the bundled zlib, freetype and etc libraries ensures those libraries are included in the JDK binary bundle. It decouples the assumptions/requirements of the static Java image build process from the assumptions/requirements of the JDK build process. A post process that builds the static Java image can use those bundled libraries provided by JDK binary if needed.
>> 
>> - When building a fully statically linked java launcher executable, the --whole-archive linker option is used for the JDK/VM static libraries to make sure it links every object (.o) file provided by those static libraries. As a result, we need to remove any duplicate object files from the different JDK/VM static libraries. To do that, STATIC_LIB_EXCLUDE_OBJS is added and used in make/common/NativeCompilation.gmk. STATIC_LIB_EXCLUDE_OBJS contains the list of object files that need to be filtered out when creating a specific static library. STATIC_LIB_EXCLUDE_OBJS is defined for JDK/VM static libraries that may contain object files from other libraries (those are needed when building shared libraries), and those object files are added to the STATIC_LIB_EXCLUDE_OBJS. See make/hotspot/lib/CompileJvm.gmk, make/modules/java.base/lib/CoreLibraries.gmk and make/modules/java.desktop/lib/Awt2dLibraries.gmk.
>> 
>> - In make/common/NativeCompilation.gmk, move the code handling long arguments so that it can be used for the static build support as well.
>> 
>> - In make/hotspot/lib/CompileJvm.gmk, it specifies to exclude operator_new.o from the libjvm static library. See details in the comment added in CompileJvm.gmk.
>> 
>> Thanks manc for a bug fix for JAVASTATIC_OBJECT_DIR in StaticLink.gmk.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use $(JVM_LIBS), which includes -lrt on Linux currently.

> 

Created https://bugs.openjdk.org/browse/JDK-8307194 for the need static library (.a handling) enhancements.

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

PR Comment: https://git.openjdk.org/jdk/pull/13709#issuecomment-1530481290

From liach at openjdk.org  Tue May  2 00:27:19 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 May 2023 00:27:19 GMT
Subject: RFR: 8302822:
 Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
 [v2]
In-Reply-To: <fxHYBHo3_h3etEN1EkAS0IHDJMxwWfXR3eyQb6KwbVA=.1bb0a133-c5a4-490f-af8f-66e4f1d41d4e@github.com>
References: <1sDlqlKVNOobyFy71f7ud5uL8_WcMPi1qKNa4ltxFQ0=.63cffbd7-e11a-4d7d-9362-cf215a7584ce@github.com>
 <fxHYBHo3_h3etEN1EkAS0IHDJMxwWfXR3eyQb6KwbVA=.1bb0a133-c5a4-490f-af8f-66e4f1d41d4e@github.com>
Message-ID: <flxUz0Mb3lROi1cG1pgjWYsGmlWSr97OZJHWqjvGjfc=.1c4662b1-35c8-498c-b923-774a71f215bc@github.com>

On Wed, 15 Mar 2023 02:37:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Make the repositories volatile like in Class
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into generic-info-thread-safe
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into generic-info-thread-safe
>  - 8302822: Method/Field/Constructor/RecordComponent::getGenericInfo() is not thread safe

keep-alive. Using volatile to ensure correctness of program order is still better than reading `null` on the second non-volatile read at return.

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

PR Comment: https://git.openjdk.org/jdk/pull/12643#issuecomment-1530666323

From stuart.marks at oracle.com  Tue May  2 00:44:28 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Mon, 1 May 2023 17:44:28 -0700
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>

Hi R?mi,

Thanks for trying out the latest build!

I'll make sure this gets mentioned in the release note for Sequenced Collections. 
We'll also raise this issue when we talk about this feature in the Quality Outreach 
program.

s'marks

On 4/29/23 3:46 AM, Remi Forax wrote:
> I've several repositories that now fails to compile with the latest jdk21, which introduces sequence collections.
> 
> The introduction of a common supertype to existing collections is *not* a source compatible change because of type inference.
> 
> Here is a simplified example:
> 
>    public static void m(List<Supplier<? extends Map<String, String>>> factories) {
>    }
> 
>    public static void main(String[] args) {
>      Supplier<LinkedHashMap<String,String>> supplier1 = LinkedHashMap::new;
>      Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>      var factories = List.of(supplier1, supplier2);
>      m(factories);
>    }
> 
> 
> This example compiles fine with Java 20 but report an error with Java 21:
>    SequencedCollectionBug.java:28: error: method m in class SequencedCollectionBug cannot be applied to given types;
>      m(factories);
>      ^
>    required: List<Supplier<? extends Map<String,String>>>
>    found:    List<Supplier<? extends SequencedMap<String,String>>>
>    reason: argument mismatch; List<Supplier<? extends SequencedMap<String,String>>> cannot be converted to List<Supplier<? extends Map<String,String>>>
> 
> 
> 
> Apart from the example above, most of the failures I see are in the unit tests provided to the students, because we are using a lot of 'var' in them so they work whatever the name of the types chosen by the students.
> 
> Discussing with a colleague, we also believe that this bug is not limited to Java, existing Kotlin codes will also fail to compile due to this bug.
> 
> Regards,
> R?mi

From sspitsyn at openjdk.org  Tue May  2 01:09:40 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 2 May 2023 01:09:40 GMT
Subject: Withdrawn: 8297286: runtime/vthread tests crashing after JDK-8296324
In-Reply-To: <Q9aSWyhdNcS73UVmoosyrDRJZnqqAPk_G99quTgutxA=.76691773-e4c2-4190-bc6d-e54d11f1ae33@github.com>
References: <Q9aSWyhdNcS73UVmoosyrDRJZnqqAPk_G99quTgutxA=.76691773-e4c2-4190-bc6d-e54d11f1ae33@github.com>
Message-ID: <sDrOLLMLBjkbSjguzd2wfQA9ae8zZhFTUUlDwCD1xHQ=.c4357e76-0391-4279-b164-0037f6117b69@github.com>

On Wed, 23 Nov 2022 00:24:28 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> This problem has two sides.
> One is that the `VirtualThread::run() `cashes the field `notifyJvmtiEvents` value.
> It caused the native method `notifyJvmtiUnmountBegin()` not called after the field `notifyJvmtiEvents`
> value has been set to `true` when an agent library is loaded into running VM.
> The fix is to get rid of this cashing.
> Another is that enabling `notifyJvmtiEvents` notifications needs a synchronization.
> Otherwise, a VTMS transition start can be missed which will cause some asserts to fire.
> The fix is to use a JvmtiVTMSTransitionDisabler helper for sync.
> 
> Testing:
> The originally failed tests are passed now:
> 
> runtime/vthread/RedefineClass.java
> runtime/vthread/TestObjectAllocationSampleEvent.java 
> 
> In progress:
> Run the tiers 1-6 to make sure there are no regression.

This pull request has been closed without being integrated.

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

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

From joehw at openjdk.org  Tue May  2 03:15:23 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 2 May 2023 03:15:23 GMT
Subject: Integrated: 8298087: XML Schema Validation reports an required
 attribute twice via ErrorHandler
In-Reply-To: <FTLJmbYCPPkZvFFFNZcRZGiDdc6osG9HZ3TRB024XZc=.745f57ce-fd72-4572-9aa0-d78036eb9dfa@github.com>
References: <FTLJmbYCPPkZvFFFNZcRZGiDdc6osG9HZ3TRB024XZc=.745f57ce-fd72-4572-9aa0-d78036eb9dfa@github.com>
Message-ID: <a2RU7Bu2h5dZFKNZIobYY1MTpeLkxTaiMS1VvRJzEec=.c93f7936-6cad-48be-abec-0467a1478696@github.com>

On Fri, 28 Apr 2023 17:08:10 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Fix a copy n paste error in XMLSchemaValidator. When the patch was applied while updating to Xerces 2.12.2, the original code was not removed, resulting in reporting validation error twice.

This pull request has now been integrated.

Changeset: 2179a8f2
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2179a8f2d622f832aa21eb7f48e8ab055bc55731
Stats:     129 lines in 2 files changed: 123 ins; 4 del; 2 mod

8298087: XML Schema Validation reports an required attribute twice via ErrorHandler

Reviewed-by: naoto

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

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

From smarks at openjdk.org  Tue May  2 04:37:10 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 2 May 2023 04:37:10 GMT
Subject: RFR: 8302496: Runtime.exit incorrectly says it never throws an
 exception [v2]
In-Reply-To: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
References: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
Message-ID: <kisNIrI5UhA9wGcqjTni8xscM3q2rXcdghpmaCZvLLo=.4b9e6f3d-5a15-47c4-adc5-33d2016f1df9@github.com>

> Textual specification clarifications.

Stuart Marks has updated the pull request incrementally with two additional commits since the last revision:

 - Rewording per suggestions.
 - Use new link syntax.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13706/files
  - new: https://git.openjdk.org/jdk/pull/13706/files/3ee052a5..d2b89bfc

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

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

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

From smarks at openjdk.org  Tue May  2 04:48:07 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 2 May 2023 04:48:07 GMT
Subject: RFR: 8302496: Runtime.exit incorrectly says it never throws an
 exception [v3]
In-Reply-To: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
References: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
Message-ID: <mcYJ87l7vwNQXgnuS_yrogBpkPd7evL7RE2IgzeEIjg=.62fc4420-b207-4b42-bd5c-e0e49c7d60fd@github.com>

> Textual specification clarifications.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Update Runtime.halt.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13706/files
  - new: https://git.openjdk.org/jdk/pull/13706/files/d2b89bfc..3e36b28d

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

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

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

From smarks at openjdk.org  Tue May  2 04:48:09 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 2 May 2023 04:48:09 GMT
Subject: RFR: 8302496: Runtime.exit incorrectly says it never throws an
 exception [v3]
In-Reply-To: <F9Kcn9jdxeFjQw-bExPswiIHSea8VTyGxKqPeH-Cm64=.37f2886b-fac8-42cb-bb35-e41dcbad7166@github.com>
References: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
 <eVY0HhKjkKGrMMfVlfQLWvmbesi3l9ENunDAjEx9eJ8=.f2b97ad1-5cde-4b68-936f-64250e765a59@github.com>
 <v08MOHlrPawxX2WKpwTYQH7aKtYRlNY7DG9zT1JRVR0=.afab9388-7cc5-40b0-aabe-5eee5cfb3ce7@github.com>
 <0OBEeBkxeo5tz3O_fb9lTZ64fHMHglG1H78g5bRS7wo=.e4d29694-2409-4eee-9ab8-14ea5e93f06f@github.com>
 <F9Kcn9jdxeFjQw-bExPswiIHSea8VTyGxKqPeH-Cm64=.37f2886b-fac8-42cb-bb35-e41dcbad7166@github.com>
Message-ID: <4WNmLftIl2Cnpr5LXT3iG5tJ-XA109h4-I2w3AwGFO8=.1bcfd922-2551-4e71-81f4-32e84ec474a4@github.com>

On Mon, 1 May 2023 16:11:59 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> One thing you could do is reduce the words down to something like "Unless denied exiting by the security manager, this method blocks indefinitely ..." to avoid complicating the first paragraph with something that only arises with a niche execution mode. If needed, a later paragraph could have this detail, or just leave it to the existing @throws text where the permission check is specified.
>
> OK, that works. I'll develop an update.

Updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13706#discussion_r1182076579

From jpai at openjdk.org  Tue May  2 05:51:14 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 May 2023 05:51:14 GMT
Subject: RFR: 8305919: java/lang/Thread/virtual/HoldsLock.java#id0 failed, 
 ThreadInfo.getLockInfo() return null
In-Reply-To: <MtBAN1ez9E7I6qLsShNHUgiiGZGx852oyNgSosTNhPE=.4d5ab352-6503-433c-aee0-d711e3fe4918@github.com>
References: <MtBAN1ez9E7I6qLsShNHUgiiGZGx852oyNgSosTNhPE=.4d5ab352-6503-433c-aee0-d711e3fe4918@github.com>
Message-ID: <lDLf6i8Q6kGXlqka50YUAiyr83WT1gSCSqdJIsF3GOw=.c04a57d9-7cf4-4d38-97ea-c42e4f79a03e@github.com>

On Sun, 30 Apr 2023 18:18:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> HoldsLock.java#id0 has been failing intermittently recently due to threads left over from previous tests terminating. HoldsLock.java#id1 doesn't fail as it runs in /othervm mode. The test uses ThreadMXBean::getAllThreadIds to get the ID of all threads and calls ThreadMXBean::getThreadInfo on each thread. If a thread from a previous test terminates then getThreadInfo returns null and the test fails.
> 
> The test can be trivially fixed to check for null but looking at it afresh, the test can be simplified to use existing test infrastructure and to just call ThreadMXBean::getThreadInfo on the carrier. The test can also be renamed to make it clearer that it is testing a carrier threads wait for a virtual thread. The old test includes a disabled test for Thread.holdsLock but there is further VM work required before that is useful and it would be better to develop new tests at part of that work.

Hello Alan, these change look good to me.

> The test uses ThreadMXBean::getAllThreadIds to get the ID of all threads and calls ThreadMXBean::getThreadInfo on each thread. If a thread from a previous test terminates then getThreadInfo returns null and the test fails.

The test was problem listed only in `-Xcomp` but it wasn't clear why this issue would affect only `-Xcomp`, but then reading through the JBS issue, I can see that this failure was reproduced even without `-Xcomp` after the problem listing was done.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13738#pullrequestreview-1408429834

From alanb at openjdk.org  Tue May  2 06:07:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 May 2023 06:07:16 GMT
Subject: RFR: 8302496: Runtime.exit incorrectly says it never throws an
 exception [v3]
In-Reply-To: <mcYJ87l7vwNQXgnuS_yrogBpkPd7evL7RE2IgzeEIjg=.62fc4420-b207-4b42-bd5c-e0e49c7d60fd@github.com>
References: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
 <mcYJ87l7vwNQXgnuS_yrogBpkPd7evL7RE2IgzeEIjg=.62fc4420-b207-4b42-bd5c-e0e49c7d60fd@github.com>
Message-ID: <IZXu79UTL_G1cCjXD0Oq-mjSzaekfLrGHCh6WX8PV6s=.4a14d52e-3a23-4ea0-adca-b0a79028e6e9@github.com>

On Tue, 2 May 2023 04:48:07 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Textual specification clarifications.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update Runtime.halt.

Updated version, and the wording of halt's description, looks okay.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13706#pullrequestreview-1408441782

From john.hendrikx at gmail.com  Tue May  2 06:46:48 2023
From: john.hendrikx at gmail.com (John Hendrikx)
Date: Tue, 2 May 2023 08:46:48 +0200
Subject: a plea for blocking peek
In-Reply-To: <MN2PR12MB36161B757A4D48C39A5A4D79F96E9@MN2PR12MB3616.namprd12.prod.outlook.com>
References: <MN2PR12MB36161B757A4D48C39A5A4D79F96E9@MN2PR12MB3616.namprd12.prod.outlook.com>
Message-ID: <c8823dc7-8a0f-5750-7d32-3b10d5182b2e@gmail.com>

Hi,

I think it would help if you describe your problem a bit more directly.? 
Currently there is a lot of mention of difficulty levels, usual 
approaches and "winning", which really doesn't help to ascertain what 
you are trying to achieve. For a good re-evaluation of your request, you 
are going to need to show some (pseudo) code so people can see if this 
indeed is a good use case, or that there is an elegant alternative solution.

It's really hard to glean from your post what you are trying to do.? It 
seems like you have a queue and a map.? Items you get from the queue 
need to be verified against the map.? The lock seems to protect the map 
structure against concurrent modification, and for some reason getting 
the lock after `take` isn't good enough.

--John

On 01/05/2023 19:12, mark.yagnatinsky at barclays.com wrote:
>
> I?m not sure if this I?m breaking etiquette for this list but I?m 
> going to risk resending my first message because it got zero replies.? 
> If it was simply too long, please let me know and I?ll attempt a 
> shorter version.
>
> Here?s like to original:
>
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-April/104931.html
>
> *From:* Yagnatinsky, Mark : Markets Pre Trade
> *Sent:* Thursday, April 27, 2023 12:28 PM
> *To:* core-libs-dev at openjdk.org
> *Subject:* RE: blocking peek for blocking queues
>
> Someone said this is the right list for this, so forwarding from 
> jdk-dev with a small tweak
>
> I?d like to make a case for adding a blocking variant of peek() to 
> BlockingQueue.
>
> This has apparently been suggested before:
>
> https://bugs.openjdk.org/browse/JDK-6653412
>
> At the time, the verdict was that the proposed use case for a blocking 
> peek was not very compelling, but ?If a compelling use case is 
> available,we may reconsider and reopen this RFE?
>
> For one thing, that use case was inherently racy, and ideally the 
> standard library should not be encouraging races.
>
> And for another thing, this was before the invention of default 
> methods, so a new interface would be needed.
>
> I?d like to present what might be a more sympathetic use case, where a 
> blocking peek actually makes it easier to avoid races.
>
> (This is not hypothetical; I?ve spent all day trying to cope with the 
> lack of a blocking peek.? I think I succeeded, but it was tough.)
>
> Let?s start at the beginning.? The game known as ?multithreaded 
> programming? can be played on 3 difficulty levels: easy, medium, and hard.
>
> Easy mode is when the JDK happens to have a high-level tool (e.g., a 
> Collection or an Executor or something) such as DelayQueue that does 
> exactly what you want.
>
> Sadly, the JDK is finite, and even Maven Central is finite, so this 
> not guaranteed to happen, though it?s nice when it does.
>
> At the other extreme is hard mode, when every nanosecond counts and 
> you must resort to the sorts of mental gymnastics that were involved 
> when String.hashCode was re-worked to avoid re-computing hash codes 
> equal to zero.
>
> This email is about the medium difficulty level.? In this mode, you 
> must glue together two or three collections to get what you want.
>
> To be concrete, suppose we want to glue a map together with a blocking 
> queue, since that?s a simplified version of what I was doing.? (In 
> particular I was using a DelayQueue and a HashMap.)
>
> Since we?re not playing on hard mode, we?re going to allow ourselves 
> to guard the entire data structure by one giant lock whenever it seems 
> convenient, without worrying about performance.
>
> In fact, let?s give a name to this lock. Since I?m not feeling very 
> creative right now, let?s call it LOCK.? Similarly, let?s call our 
> compound data structure STRUCT.
>
> My usual heuristic to ?win? (that is, to make sure my code is correct, 
> or at least non-racy) on medium difficulty goes something like this.
>
> First, figure out whether there is any way for STRUCT to be ?invalid?.
>
> For instance, maybe ?it?s valid if and only if every entry in the 
> queue has a corresponding entry in the map?.
>
> One could then write a brief comment in the code explaining what 
> ?valid? means, or perhaps even write an ?isValid()? method for testing 
> purposes.
>
> Once we?ve decided what it means for STRUCT to be ?valid? (aka, 
> non-corrupt), we can try to maintain the following invariant:
>
> EITHER some thread holds the LOCK, and no other thread is using STRUCT 
> right now,
>
> OR ELSE the LOCK ?is not held by any thread, and thus STRUCT is 
> currently in a valid state.
>
> Sometimes the invariant above is a bit too strong, and it?s convenient 
> to weaken it slightly.? So we can instead consider the following rule:
>
> RULE: we must never mutate STRUCT unless we hold the LOCK.
>
> If we uphold the invariant, then we must be following the rule, but 
> not vice versa.
>
> (The rule doesn?t forbid queries without the lock; it only forbids 
> writes.)
>
> Finally, we come to the point.? The lack of a blocking peek in 
> BlockingQueue has forced me to break the above ?weakened? rule.
>
> I had to invent a new much weaker rule, something like ?please 
> carefully think through all possible interleaved executions; if they 
> all work, great!?.
>
> What went wrong?? Well, one of the methods I wanted on STRUCT was 
> basically ?call take() on the queue, and then do things with the result?.
>
> The trouble is that you can?t usually afford to hold a lock while 
> calling take(), since it can block forever, and in the meantime you?ve 
> ?locked out? anyone who could have added something and thus unblocked you.
>
> Thus, I split my method into two pieces: In PART_ONE we call take() 
> without the LOCK, and once take() returns I grab the lock right away 
> and run PART_TWO.
>
> But notice that this breaks the RULE from the previous paragraph: I 
> mutated the STRUCT without holding the LOCK.
>
> This means my method is not atomic: it?s possible for some other 
> thread to observe that PART_ONE is done but PART_TWO is not started.
>
> Typically this means that other threads can now observe the STRUCT in 
> an invalid (aka corrupt/broken) state.
>
> Now, suppose we had a blocking peek.? How does that help?? In that 
> case, we would still break our method into two pieces.
>
> To avoid confusion, let?s call them PART_A and PART_B.? In PART_A we 
> call blockingPeek() without holding the LOCK.
>
> Note that we completely ignore the return value from peek; for all we 
> care, the return type is ?void? instead of ?T?.
>
> This breaks the ?invariant? from a few paragraphs ago since we?re 
> technically ?using? the STRUCT but it respects the ?rule? since we?re 
> not mutating it.
>
> Once peek returns, PART_B begins.? Here, we grab the lock, and do a 
> non-blocking poll() on the queue.
>
> It?s might return ?null? if someone raced us to get the lock.? But 
> from our perspective that?s okay: it?s just like a spurious wakeup 
> from a raw wait() call.
>
> The reason it?s okay is that we haven?t done anything yet, so we can 
> just call blockingPeek() again and hope for better luck next time.
>
> Similarly we don?t care if poll() returns a different item than 
> blockingPeek() originally did, since we never looked at what peek() 
> returned.
>
> The rest of PART_B is basically PART_TWO from the ?peek-less? world.
>
> Note that this way, our method appears atomic to other threads, since 
> PART_A doesn?t actually do anything; all the work happens in PART_B, 
> which is guarded by the LOCK.
>
> Thoughts?
>
> This message is for information purposes only. It is not a 
> recommendation, advice, offer or solicitation to buy or sell a product 
> or service, nor an official confirmation of any transaction. It is 
> directed at persons who are professionals and is intended for the 
> recipient(s) only. It is not directed at retail customers. This 
> message is subject to the terms at: 
> https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.
>
> For important disclosures, please see: 
> https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html 
> regarding marketing commentary from Barclays Sales and/or Trading 
> desks, who are active market participants; 
> https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html 
> regarding our standard terms for Barclays Corporate and Investment 
> Bank where we trade with you in principal-to-principal wholesale 
> markets transactions; and in respect to Barclays Research, including 
> disclosures relating to specific issuers, see: 
> http://publicresearch.barclays.com.
> __________________________________________________________________________________ 
>
> If you are incorporated or operating in Australia, read these 
> important disclosures: 
> https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
> __________________________________________________________________________________
> For more details about how we use personal information, see our 
> privacy notice: 
> https://www.cib.barclays/disclosures/personal-information-use.html.
> __________________________________________________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230502/004d5387/attachment-0001.htm>

From alanb at openjdk.org  Tue May  2 07:25:28 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 May 2023 07:25:28 GMT
Subject: RFR: 8305919: java/lang/Thread/virtual/HoldsLock.java#id0 failed, 
 ThreadInfo.getLockInfo() return null
In-Reply-To: <lDLf6i8Q6kGXlqka50YUAiyr83WT1gSCSqdJIsF3GOw=.c04a57d9-7cf4-4d38-97ea-c42e4f79a03e@github.com>
References: <MtBAN1ez9E7I6qLsShNHUgiiGZGx852oyNgSosTNhPE=.4d5ab352-6503-433c-aee0-d711e3fe4918@github.com>
 <lDLf6i8Q6kGXlqka50YUAiyr83WT1gSCSqdJIsF3GOw=.c04a57d9-7cf4-4d38-97ea-c42e4f79a03e@github.com>
Message-ID: <fNxx0Wo3mV8EMxxpqKTbo0ON31ltVN9MHn4BaZ3yCEA=.f1fb5ff2-5793-4c2d-84c6-e4fab83ef46f@github.com>

On Tue, 2 May 2023 05:48:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The test was problem listed only in `-Xcomp` but it wasn't clear why this issue would affect only `-Xcomp`, but then reading through the JBS issue, I can see that this failure was reproduced even without `-Xcomp` after the problem listing was done.

Right, not specific to -Xcomp, it's more about the test runs in agentvm mode so it's possible to get interference from tests that ran previously in the same VM.

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

PR Comment: https://git.openjdk.org/jdk/pull/13738#issuecomment-1531003740

From alanb at openjdk.org  Tue May  2 07:25:29 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 May 2023 07:25:29 GMT
Subject: Integrated: 8305919: java/lang/Thread/virtual/HoldsLock.java#id0
 failed, ThreadInfo.getLockInfo() return null
In-Reply-To: <MtBAN1ez9E7I6qLsShNHUgiiGZGx852oyNgSosTNhPE=.4d5ab352-6503-433c-aee0-d711e3fe4918@github.com>
References: <MtBAN1ez9E7I6qLsShNHUgiiGZGx852oyNgSosTNhPE=.4d5ab352-6503-433c-aee0-d711e3fe4918@github.com>
Message-ID: <mCfoCPTsixGc3vw3LpZg6Dn1BFU_pnLuSr0SjEFz9NM=.d198229d-d67a-4368-839f-b136a660ab02@github.com>

On Sun, 30 Apr 2023 18:18:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> HoldsLock.java#id0 has been failing intermittently recently due to threads left over from previous tests terminating. HoldsLock.java#id1 doesn't fail as it runs in /othervm mode. The test uses ThreadMXBean::getAllThreadIds to get the ID of all threads and calls ThreadMXBean::getThreadInfo on each thread. If a thread from a previous test terminates then getThreadInfo returns null and the test fails.
> 
> The test can be trivially fixed to check for null but looking at it afresh, the test can be simplified to use existing test infrastructure and to just call ThreadMXBean::getThreadInfo on the carrier. The test can also be renamed to make it clearer that it is testing a carrier threads wait for a virtual thread. The old test includes a disabled test for Thread.holdsLock but there is further VM work required before that is useful and it would be better to develop new tests at part of that work.

This pull request has now been integrated.

Changeset: 86f97fe7
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86f97fe70c9b55d196876e1e144f26a576492ebe
Stats:     292 lines in 4 files changed: 96 ins; 194 del; 2 mod

8305919: java/lang/Thread/virtual/HoldsLock.java#id0 failed, ThreadInfo.getLockInfo() return null

Reviewed-by: jpai

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

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

From viktor.klang at oracle.com  Tue May  2 08:08:23 2023
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 2 May 2023 08:08:23 +0000
Subject: a plea for blocking peek
In-Reply-To: <c8823dc7-8a0f-5750-7d32-3b10d5182b2e@gmail.com>
References: <MN2PR12MB36161B757A4D48C39A5A4D79F96E9@MN2PR12MB3616.namprd12.prod.outlook.com>
 <c8823dc7-8a0f-5750-7d32-3b10d5182b2e@gmail.com>
Message-ID: <MW4PR10MB577412C72C6275FEAD9A42C2FF6F9@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi,

I think the conversation also becomes a bit more difficult since the topic seems to be around DelayQueue?which has slightly different semantics than typical BlockingQueue implementations.

For instance, peek() returns the element with the lowest expiry (possibly in the future)?so you cannot really use the blocking peek() for much else than observing the lowest expiry?and the only difference to the non-blocking peek() would be that you can block the reader for as long as the queue is empty without A) removing the element and B) doing busy-waiting with some form of back-off policy which might ending up sleeping for too long.

Since queues tend to spend their time being either full or empty (since there's typically either a faster consumption than production or vice versa), I can understand the need to be notified when the queue is no longer empty. With that said, in the case of DelayQueue, it still doesn't mean that the result of a blocking peek() means that the element is consumable at that point. So the question is what you'd use the information for?

When composing multiple data structures, especially concurrent ones, I find it easier to reason about the problem space starting with the interaction pattern from the outside (who consumes and who produces), as the less coordination needed the better in terms of throughput (Amdahl's Law & Universal Scalability Law) etc, and if you can design for single-reader or single-writer (or both!) you can get away with much more performant implementations since the coordination need is much lower.


________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of John Hendrikx <john.hendrikx at gmail.com>
Sent: Tuesday, 2 May 2023 08:46
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>; mark.yagnatinsky at barclays.com <mark.yagnatinsky at barclays.com>
Subject: Re: a plea for blocking peek


Hi,

I think it would help if you describe your problem a bit more directly.  Currently there is a lot of mention of difficulty levels, usual approaches and "winning", which really doesn't help to ascertain what you are trying to achieve. For a good re-evaluation of your request, you are going to need to show some (pseudo) code so people can see if this indeed is a good use case, or that there is an elegant alternative solution.

It's really hard to glean from your post what you are trying to do.  It seems like you have a queue and a map.  Items you get from the queue need to be verified against the map.  The lock seems to protect the map structure against concurrent modification, and for some reason getting the lock after `take` isn't good enough.

--John

On 01/05/2023 19:12, mark.yagnatinsky at barclays.com<mailto:mark.yagnatinsky at barclays.com> wrote:

I?m not sure if this I?m breaking etiquette for this list but I?m going to risk resending my first message because it got zero replies.  If it was simply too long, please let me know and I?ll attempt a shorter version.



Here?s like to original:

https://mail.openjdk.org/pipermail/core-libs-dev/2023-April/104931.html



From: Yagnatinsky, Mark : Markets Pre Trade
Sent: Thursday, April 27, 2023 12:28 PM
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
Subject: RE: blocking peek for blocking queues



Someone said this is the right list for this, so forwarding from jdk-dev with a small tweak



I?d like to make a case for adding a blocking variant of peek() to BlockingQueue.

This has apparently been suggested before:

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

At the time, the verdict was that the proposed use case for a blocking peek was not very compelling, but ? If a compelling use case is available,we may reconsider and reopen this RFE?

For one thing, that use case was inherently racy, and ideally the standard library should not be encouraging races.

And for another thing, this was before the invention of default methods, so a new interface would be needed.

I?d like to present what might be a more sympathetic use case, where a blocking peek actually makes it easier to avoid races.

(This is not hypothetical; I?ve spent all day trying to cope with the lack of a blocking peek.  I think I succeeded, but it was tough.)



Let?s start at the beginning.  The game known as ?multithreaded programming? can be played on 3 difficulty levels: easy, medium, and hard.

Easy mode is when the JDK happens to have a high-level tool (e.g., a Collection or an Executor or something) such as DelayQueue that does exactly what you want.

Sadly, the JDK is finite, and even Maven Central is finite, so this not guaranteed to happen, though it?s nice when it does.

At the other extreme is hard mode, when every nanosecond counts and you must resort to the sorts of mental gymnastics that were involved when String.hashCode was re-worked to avoid re-computing hash codes equal to zero.



This email is about the medium difficulty level.  In this mode, you must glue together two or three collections to get what you want.

To be concrete, suppose we want to glue a map together with a blocking queue, since that?s a simplified version of what I was doing.  (In particular I was using a DelayQueue and a HashMap.)

Since we?re not playing on hard mode, we?re going to allow ourselves to guard the entire data structure by one giant lock whenever it seems convenient, without worrying about performance.

In fact, let?s give a name to this lock.  Since I?m not feeling very creative right now, let?s call it LOCK.  Similarly, let?s call our compound data structure STRUCT.

My usual heuristic to ?win? (that is, to make sure my code is correct, or at least non-racy) on medium difficulty goes something like this.

First, figure out whether there is any way for STRUCT to be ?invalid?.

For instance, maybe ?it?s valid if and only if every entry in the queue has a corresponding entry in the map?.

One could then write a brief comment in the code explaining what ?valid? means, or perhaps even write an ?isValid()? method for testing purposes.

Once we?ve decided what it means for STRUCT to be ?valid? (aka, non-corrupt), we can try to maintain the following invariant:

EITHER some thread holds the LOCK, and no other thread is using STRUCT right now,

OR ELSE the LOCK  is not held by any thread, and thus STRUCT is currently in a valid state.

Sometimes the invariant above is a bit too strong, and it?s convenient to weaken it slightly.  So we can instead consider the following rule:

RULE: we must never mutate STRUCT unless we hold the LOCK.

If we uphold the invariant, then we must be following the rule, but not vice versa.

(The rule doesn?t forbid queries without the lock; it only forbids writes.)



Finally, we come to the point.  The lack of a blocking peek in BlockingQueue has forced me to break the above ?weakened? rule.

I had to invent a new much weaker rule, something like ?please carefully think through all possible interleaved executions; if they all work, great!?.

What went wrong?  Well, one of the methods I wanted on STRUCT was basically ?call take() on the queue, and then do things with the result?.

The trouble is that you can?t usually afford to hold a lock while calling take(), since it can block forever, and in the meantime you?ve ?locked out? anyone who could have added something and thus unblocked you.

Thus, I split my method into two pieces: In PART_ONE we call take() without the LOCK, and once take() returns I grab the lock right away and run PART_TWO.

But notice that this breaks the RULE from the previous paragraph: I mutated the STRUCT without holding the LOCK.

This means my method is not atomic: it?s possible for some other thread to observe that PART_ONE is done but PART_TWO is not started.

Typically this means that other threads can now observe the STRUCT in an invalid (aka corrupt/broken) state.



Now, suppose we had a blocking peek.  How does that help?  In that case, we would still break our method into two pieces.

To avoid confusion, let?s call them PART_A and PART_B.  In PART_A we call blockingPeek() without holding the LOCK.

Note that we completely ignore the return value from peek; for all we care, the return type is ?void? instead of ?T?.

This breaks the ?invariant? from a few paragraphs ago since we?re technically ?using? the STRUCT but it respects the ?rule? since we?re not mutating it.

Once peek returns, PART_B begins.  Here, we grab the lock, and do a non-blocking poll() on the queue.

It?s might return ?null? if someone raced us to get the lock.  But from our perspective that?s okay: it?s just like a spurious wakeup from a raw wait() call.

The reason it?s okay is that we haven?t done anything yet, so we can just call blockingPeek() again and hope for better luck next time.

Similarly we don?t care if poll() returns a different item than blockingPeek() originally did, since we never looked at what peek() returned.

The rest of PART_B is basically PART_TWO from the ?peek-less? world.

Note that this way, our method appears atomic to other threads, since PART_A doesn?t actually do anything; all the work happens in PART_B, which is guarded by the LOCK.



Thoughts?

This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html.

For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com.
__________________________________________________________________________________
If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html.
__________________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230502/4c174be1/attachment-0001.htm>

From forax at openjdk.org  Tue May  2 09:33:29 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 2 May 2023 09:33:29 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v11]
In-Reply-To: <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
Message-ID: <Lwu-ellF2LiH8xeofvsAyBACm1Wo9CpAylDeTDPqVgY=.71ab19dc-a558-401d-8f21-9fb27cca90d3@github.com>

On Mon, 1 May 2023 14:56:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with a check to the class data. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:
> 
>  - Renames
>  - Merge branch 'master' into explore/mhp-iface
>  - Consolidate iteration over public methods
>  - Define MH proxy class in a dynamic module
>  - Fix test that depend on WrapperInstance
>  - Require an original lookup in constructor arguments to prevent unintended instantiation
>  - pass interface info via condy,
>    drop explicit ea flags
>    initialize benchmark work variable randomly
>    benchmarks just need 1 fork
>  - Nuke WrapperInstance
>  - Merge branch 'master' into explore/mhp-iface
>  - Whitespace, cleanup, rename benchmarks to be informative
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/c212c27d...f5d0ef0a

This is the method/class specialization problem all other again.
As Jorn said, we should use the same strategy as with the lambda metafactory, one hidden class per method handle, given that otherwise it's too easy to have profile pollution. This implementation already cache the bytecode so specializing different method handles with the same interfaces + classloader reuse the same bytecode.

I really hope that with Valhalla specialized generics, we will be able share more by specializing the same proxy class with different method handles, each one acting as a constant. So one class for all, but one species per method handle.

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1531164433

From dholmes at openjdk.org  Tue May  2 09:38:17 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 2 May 2023 09:38:17 GMT
Subject: RFR: 8307163: JLONG_FORMAT_SPECIFIER should be updated on Windows
In-Reply-To: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>
References: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>
Message-ID: <JmR5nCWyIkm-P4NT4r8jyeIfNEeA6-Afi9DGfxJK8mo=.86b11e98-5324-4e43-bbdd-75f7db445a2c@github.com>

On Mon, 1 May 2023 16:25:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Windows no longer uses I64d anywhere in their newer compilers, instead using the conforming lld specifiers. Minor cleanup here in JLI code to reflect that

The VM still uses PRId64.

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

PR Review: https://git.openjdk.org/jdk/pull/13740#pullrequestreview-1408752394

From mdoerr at openjdk.org  Tue May  2 09:51:47 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 2 May 2023 09:51:47 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v25]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <IFv5eY7cNJCI9X-hyL17huLJxjun9vNrLeVNhSiAK6M=.5dc745a9-b434-475d-9021-82f94f6bbb08@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:

 - Adaptation for JDK-8303002.
 - Merge remote-tracking branch 'origin' into PPC64_Panama
 - Revert unintended formatting changes. Fix comment.
 - Enable remaining foreign tests.
 - Adaptations for JDK-8304265.
 - Merge remote-tracking branch 'origin' into PPC64_Panama
 - Adaptation for JDK-8305668
 - Merge remote-tracking branch 'origin' into PPC64_Panama
 - Move ABIv2CallArranger out of linux subdirectory. ABIv1/2 does match the AIX/linux separation.
 - Adaptation for JDK-8303022.
 - ... and 20 more: https://git.openjdk.org/jdk/compare/860bf9b3...f5e22be0

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

Changes: https://git.openjdk.org/jdk/pull/12708/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=24
  Stats: 2465 lines in 69 files changed: 2348 ins; 1 del; 116 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12708/head:pull/12708

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

From mcimadamore at openjdk.org  Tue May  2 10:16:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 2 May 2023 10:16:15 GMT
Subject: RFR: 8307164: TestSegmentCopy times out (mainline)
In-Reply-To: <TJv9o5TXATf6PARMaj0RDYNvvX_DGRjlOKxxbBETkn0=.c3bb9323-4c5b-467f-92d7-98ca3e2ff589@github.com>
References: <TJv9o5TXATf6PARMaj0RDYNvvX_DGRjlOKxxbBETkn0=.c3bb9323-4c5b-467f-92d7-98ca3e2ff589@github.com>
Message-ID: <-DFAdKvOmpmghpJiL0tliLRSFQOHkZBdYatoX7lik9s=.b3e4ac08-49eb-4b95-9dc1-ea0a2a04e13f@github.com>

On Mon, 1 May 2023 17:02:11 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Port of: https://github.com/openjdk/panama-foreign/pull/827

Looks good (already reviewed on panama repo)

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13741#pullrequestreview-1408810285

From mcimadamore at openjdk.org  Tue May  2 10:19:19 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 2 May 2023 10:19:19 GMT
Subject: RFR: 8304888: Add dedicated VMProps for linker and fallback linker
 [v4]
In-Reply-To: <x4ODnhgyEawHnMJNv7FQTQbUpv67dQsISF4_wWOihIM=.c63a6897-e530-4943-885c-ec6462837a43@github.com>
References: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
 <x4ODnhgyEawHnMJNv7FQTQbUpv67dQsISF4_wWOihIM=.c63a6897-e530-4943-885c-ec6462837a43@github.com>
Message-ID: <T0e9gNF7MU2cGKUe892cg95zeZ9M-LC78HksTScR1h8=.94ee18e0-248a-485e-ae07-883d3db4a66b@github.com>

On Mon, 1 May 2023 16:48:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds a dedicated jtreg property to check which CABI is being used by the JDK, which can be used both to check whether the foreign linker is supported, and whether the fallback linker is being used. (and, possibly it can also be use to check for a particular ABI in case we want to add ABI specific tests).
>> 
>> Checking whether the foreign linker is supported currently requires using an unwieldy expression that checks if we are running on a platform that has a foreign linker port. Checking for the fallback linker currently uses `vm.flavor != "zero"` which is not always correct, since the fallback linker can also be used on other platforms which are not `zero`.
>> 
>> To initialize the property, VMProps directly reads `jdk.internal.foreig.CABI::current()`. Since this class is in an internal package, `--add-exports` flags are added as javac flags and VM flags for the extra prop definitions class.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
> 
>  - UNKNOWN -> UNSUPPORTED + fix TestLinker on FALLBACK
>  - Merge branch 'master' into VMProps
>  - Merge branch 'master' into VMProps
>  - use only jdk.CABI property
>  - use extra props to check for linker
>  - Add fallbackLinker vmprop
>  - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
>    
>    rename has_port
>  - rename has_port
>  - Merge pull request #2 from JornVernee/WSL_BB
>    
>    account for missing functional in WSL in TestByteBuffer
>  - account for missing mincore on WSL in TestByteBuffer
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/7d07d195...272478b6

test/jdk/java/foreign/SafeFunctionAccessTest.java line 27:

> 25:  * @test
> 26:  * @enablePreview
> 27:  * @requires jdk.CABI != "UNSUPPORTED"

what about the name `jdk.native.abi` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13429#discussion_r1182359992

From mcimadamore at openjdk.org  Tue May  2 10:24:18 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 2 May 2023 10:24:18 GMT
Subject: RFR: 8304888: Add dedicated VMProps for linker and fallback linker
 [v4]
In-Reply-To: <x4ODnhgyEawHnMJNv7FQTQbUpv67dQsISF4_wWOihIM=.c63a6897-e530-4943-885c-ec6462837a43@github.com>
References: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
 <x4ODnhgyEawHnMJNv7FQTQbUpv67dQsISF4_wWOihIM=.c63a6897-e530-4943-885c-ec6462837a43@github.com>
Message-ID: <Eeon06kO6AM1j_yGekIRJDu4PdpbfcwZZHb9_hBAE4g=.819f9c84-d31e-4871-a764-0190274c57bd@github.com>

On Mon, 1 May 2023 16:48:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds a dedicated jtreg property to check which CABI is being used by the JDK, which can be used both to check whether the foreign linker is supported, and whether the fallback linker is being used. (and, possibly it can also be use to check for a particular ABI in case we want to add ABI specific tests).
>> 
>> Checking whether the foreign linker is supported currently requires using an unwieldy expression that checks if we are running on a platform that has a foreign linker port. Checking for the fallback linker currently uses `vm.flavor != "zero"` which is not always correct, since the fallback linker can also be used on other platforms which are not `zero`.
>> 
>> To initialize the property, VMProps directly reads `jdk.internal.foreig.CABI::current()`. Since this class is in an internal package, `--add-exports` flags are added as javac flags and VM flags for the extra prop definitions class.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
> 
>  - UNKNOWN -> UNSUPPORTED + fix TestLinker on FALLBACK
>  - Merge branch 'master' into VMProps
>  - Merge branch 'master' into VMProps
>  - use only jdk.CABI property
>  - use extra props to check for linker
>  - Add fallbackLinker vmprop
>  - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
>    
>    rename has_port
>  - rename has_port
>  - Merge pull request #2 from JornVernee/WSL_BB
>    
>    account for missing functional in WSL in TestByteBuffer
>  - account for missing mincore on WSL in TestByteBuffer
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/7d07d195...272478b6

Looks good - I'm not too much of a fan of "CABI" as a property name - but that's a minor nit. I think the improvements in the jtreg test headers are very nice.

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13429#pullrequestreview-1408821318

From jvernee at openjdk.org  Tue May  2 10:46:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 2 May 2023 10:46:21 GMT
Subject: Integrated: 8307164: TestSegmentCopy times out (mainline)
In-Reply-To: <TJv9o5TXATf6PARMaj0RDYNvvX_DGRjlOKxxbBETkn0=.c3bb9323-4c5b-467f-92d7-98ca3e2ff589@github.com>
References: <TJv9o5TXATf6PARMaj0RDYNvvX_DGRjlOKxxbBETkn0=.c3bb9323-4c5b-467f-92d7-98ca3e2ff589@github.com>
Message-ID: <AWCEFDN5NCJsXUcu33w67F4JYdVv3URneH2cAA0uLTY=.dbc3a233-e97f-4d85-810d-f765f056f64e@github.com>

On Mon, 1 May 2023 17:02:11 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Port of: https://github.com/openjdk/panama-foreign/pull/827

This pull request has now been integrated.

Changeset: 1532a1b0
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1532a1b0bd72f37b77540af51368271ef80e17d2
Stats:     140 lines in 1 file changed: 28 ins; 42 del; 70 mod

8307164: TestSegmentCopy times out (mainline)

Reviewed-by: mcimadamore

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

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

From duke at openjdk.org  Tue May  2 10:56:22 2023
From: duke at openjdk.org (Thomas Wuerthinger)
Date: Tue, 2 May 2023 10:56:22 GMT
Subject: RFR: 8292914: Introduce a system property that enables stable
 names for lambda proxy classes [v7]
In-Reply-To: <rK_umEglSEjyEjAgxHfww3PSisFb7t92T3qhbs1DGv0=.9fa7902d-cb66-4ac9-a55b-a24b3de27b49@github.com>
References: <pYF675FND8BK8SUHFnvstPMcoKTcW81zs7yGCli5Mxo=.aac8b180-6101-4320-aa73-7e640952afaf@github.com>
 <suniyTACMBrKty-xNRWXFtaXRS5TguagZGHWqYbHzlk=.d965d64e-6daa-4844-a2af-0959045ad9e5@github.com>
 <rK_umEglSEjyEjAgxHfww3PSisFb7t92T3qhbs1DGv0=.9fa7902d-cb66-4ac9-a55b-a24b3de27b49@github.com>
Message-ID: <ytx3dcgsrb5z7rbsZF-TrtV_rC9hNniknSfl5LS-gxw=.f2b5bb57-f231-435e-a495-627abd4859aa@github.com>

On Wed, 15 Feb 2023 20:31:14 GMT, Brian Goetz <briangoetz at openjdk.org> wrote:

>> Strahinja Stanojevic has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove address from lambda class names in test on the 32-bit architecture too
>
> David Llloyd's proposed solution is dramatically less intrusive, so it should be preferred over the one here.

@briangoetz

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

PR Comment: https://git.openjdk.org/jdk/pull/10024#issuecomment-1531266718

From asotona at openjdk.org  Tue May  2 11:00:14 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 2 May 2023 11:00:14 GMT
Subject: RFR: 8306455: Wrong majorVersion for multiple attributes in
 Classfile API
In-Reply-To: <mSyXLLN7qBVlAVaiYrvFSyAb8QAm-g9TAZ-ZSL_oiZI=.ec069d21-00c2-4343-adb6-01de938ddfc6@github.com>
References: <mSyXLLN7qBVlAVaiYrvFSyAb8QAm-g9TAZ-ZSL_oiZI=.ec069d21-00c2-4343-adb6-01de938ddfc6@github.com>
Message-ID: <mc-CzFxdRvBub28WwdanLc0-sD9RgDGAZRKE-Wo-pEE=.ec7b2e54-7e8a-422f-a2a0-b7909a00197d@github.com>

On Wed, 19 Apr 2023 14:31:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Spotted the typo for BootstrapMethods, and another review over the API exposed the typo on PermittedSubclasses.

BootstrapMethods is a good catch, however I would rather recommend to remove the `AttributeMapper::validSince` from the API completely. 

Classfile API has no use of it and it does not perform any checks based on this value. Also the value itself is related to the major version only, so it does not allow to model preview features.

PermittedSubclasses attribute is a preview part of JDK 15, see: https://openjdk.org/jeps/360

Real model of attributes and features versioning would have to be more complex and linked with some form of validation.

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

Changes requested by asotona (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13536#pullrequestreview-1408870000

From jvernee at openjdk.org  Tue May  2 11:05:21 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 2 May 2023 11:05:21 GMT
Subject: RFR: 8304888: Add dedicated VMProps for linker and fallback linker
 [v4]
In-Reply-To: <T0e9gNF7MU2cGKUe892cg95zeZ9M-LC78HksTScR1h8=.94ee18e0-248a-485e-ae07-883d3db4a66b@github.com>
References: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
 <x4ODnhgyEawHnMJNv7FQTQbUpv67dQsISF4_wWOihIM=.c63a6897-e530-4943-885c-ec6462837a43@github.com>
 <T0e9gNF7MU2cGKUe892cg95zeZ9M-LC78HksTScR1h8=.94ee18e0-248a-485e-ae07-883d3db4a66b@github.com>
Message-ID: <OBKTZoMeHXxavaQ52MFXRYF9zM6o2yGvpOBYtU0fiOw=.c39cc52a-f56e-481f-b5a0-f5deb5e06c93@github.com>

On Tue, 2 May 2023 10:16:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - UNKNOWN -> UNSUPPORTED + fix TestLinker on FALLBACK
>>  - Merge branch 'master' into VMProps
>>  - Merge branch 'master' into VMProps
>>  - use only jdk.CABI property
>>  - use extra props to check for linker
>>  - Add fallbackLinker vmprop
>>  - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
>>    
>>    rename has_port
>>  - rename has_port
>>  - Merge pull request #2 from JornVernee/WSL_BB
>>    
>>    account for missing functional in WSL in TestByteBuffer
>>  - account for missing mincore on WSL in TestByteBuffer
>>  - ... and 36 more: https://git.openjdk.org/jdk/compare/7d07d195...272478b6
>
> test/jdk/java/foreign/SafeFunctionAccessTest.java line 27:
> 
>> 25:  * @test
>> 26:  * @enablePreview
>> 27:  * @requires jdk.CABI != "UNSUPPORTED"
> 
> what about the name `jdk.native.abi` ?

Not so sure. The CABI is really the linker kind, not the underlying ABI ('CABI' is probably a misnomer at this point, since we no longer use it for anything else besides selecting the linker implementation). It can also be `FALLBACK` which is not an ABI.

If CABI is bad, I think `jdk.foreign.linker` would be better as a property name

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13429#discussion_r1182397282

From jlahoda at openjdk.org  Tue May  2 11:58:20 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 2 May 2023 11:58:20 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v2]
In-Reply-To: <2i5j2tzClvDQt_beMcwfEp3wzhWx0KYz-6WKUUERwVY=.2d9def45-999a-4be4-8b6f-d69302da35cb@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
 <2i5j2tzClvDQt_beMcwfEp3wzhWx0KYz-6WKUUERwVY=.2d9def45-999a-4be4-8b6f-d69302da35cb@github.com>
Message-ID: <bFAMKGpqyAqloMJF4wHmnqEPu6YN3WEdqDiiJoihWOE=.d7f2d7a9-3789-4653-8209-2b00ad0987e1@github.com>

On Fri, 28 Apr 2023 19:30:43 GMT, Neal Gafter <duke at openjdk.org> wrote:

> Building a map or hash table will be faster than sequential search.

I agree it there will be usecases (and maybe even a majority of usecases) where using some kind of hash-based structure would work better than this patch. However, as Remi points out:
 - we cannot generally create a hash map just from the labels, as the inputs may be arbitrary subtypes of the label types. This means the hash-based structure would be (in a sense) a cache
 - the queries may be (massively) concurrent
 - the hash-based structure should not prevent class unloading (as the input classes may generally originate in arbitrary ClassLoaders)

And while a lot of this may not be an issue for a majority of usecases, there must be some support for the minority usecases.

There may be also be a subset of the usecases where VM's ability to see through the code an optimize it would have more impact than having clever code that's more difficult to understand. This may need much more testing to see if it is possible to distinguish these various cases.

The current proposal improves the performance, but does not preclude improvements in the future - this is a runtime part, which we can adjust over time, as needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/9779#issuecomment-1531339312

From liach at openjdk.org  Tue May  2 12:00:18 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 May 2023 12:00:18 GMT
Subject: RFR: 8306455: Wrong majorVersion for multiple attributes in
 Classfile API
In-Reply-To: <mSyXLLN7qBVlAVaiYrvFSyAb8QAm-g9TAZ-ZSL_oiZI=.ec069d21-00c2-4343-adb6-01de938ddfc6@github.com>
References: <mSyXLLN7qBVlAVaiYrvFSyAb8QAm-g9TAZ-ZSL_oiZI=.ec069d21-00c2-4343-adb6-01de938ddfc6@github.com>
Message-ID: <oK8Kz_Wv3PBiTEi49M2_nYg_l9NoyhYpCrY3acYJWnw=.2fdcb5d2-a7f4-4e93-87ce-94577ea6f7a9@github.com>

On Wed, 19 Apr 2023 14:31:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Spotted the typo for BootstrapMethods, and another review over the API exposed the typo on PermittedSubclasses.

Agree; we should remove this validsince. I change PermittedSubclasses for Record uses its release major version than its preview major version.

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

PR Comment: https://git.openjdk.org/jdk/pull/13536#issuecomment-1531342798

From jwaters at openjdk.org  Tue May  2 12:23:23 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 2 May 2023 12:23:23 GMT
Subject: RFR: 8307163: JLONG_FORMAT_SPECIFIER should be updated on Windows
 [v2]
In-Reply-To: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>
References: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>
Message-ID: <mnFaRiB8So9CTnN--vpQKXEPjbWNhVVltH_BvzWCBAU=.ee0e4203-0f8b-4dfd-b916-a73994341fc7@github.com>

> Windows no longer uses I64d anywhere in their newer compilers, instead using the conforming lld specifiers. Minor cleanup here in JLI code to reflect that

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  HotSpot should also use lld instead of I64d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13740/files
  - new: https://git.openjdk.org/jdk/pull/13740/files/0ae02e70..c7ccfc74

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

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

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

From jwaters at openjdk.org  Tue May  2 12:23:43 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 2 May 2023 12:23:43 GMT
Subject: RFR: 8307163: JLONG_FORMAT_SPECIFIER should be updated on Windows
In-Reply-To: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>
References: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>
Message-ID: <d3ANVFpuNftH6q66c2yZuJfD5FdG9gB1iIFcCrrHtvY=.8561cea6-fa48-49de-9c3c-3a7a565d2c53@github.com>

On Mon, 1 May 2023 16:25:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Windows no longer uses I64d anywhere in their newer compilers, instead using the conforming lld specifiers. Minor cleanup here in JLI code to reflect that

Is the globalDefinitions declaration what you're referring to? In any case, the Microsoft Visual C compiler from version 2019 typedef's PRId64 as lld, and recommends using it over the older I64d specifier, so HotSpot should also have its declarations updated as well

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

PR Comment: https://git.openjdk.org/jdk/pull/13740#issuecomment-1531381881

From ysatowse at openjdk.org  Tue May  2 12:45:49 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Tue, 2 May 2023 12:45:49 GMT
Subject: Integrated: 8305505: NPE in javazic compiler
In-Reply-To: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
References: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
Message-ID: <zXCUyO0j-zq_Mqlm8DmuX0lLKEja39A0HX8AoHvpxic=.e0c5d1a4-231a-4282-850e-117873821848@github.com>

On Tue, 18 Apr 2023 05:08:35 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  
> With this minor change, the javazic compiler (Main.java) can produce the HTML files that display given time zone data correctly.

This pull request has now been integrated.

Changeset: 544bd260
Author:    Yoshiki Sato <ysatowse at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/544bd260b6eb7bc7cf79a3739cc94bad658d7d15
Stats:     5 lines in 1 file changed: 1 ins; 1 del; 3 mod

8305505: NPE in javazic compiler

Reviewed-by: naoto

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

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

From jvernee at openjdk.org  Tue May  2 13:13:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 2 May 2023 13:13:30 GMT
Subject: RFR: 8304888: Add dedicated VMProps for linker and fallback linker
 [v5]
In-Reply-To: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
References: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
Message-ID: <2ejULzLiIRl3wxr3DTtD80tQvhHolswu6gFrN9k-J9U=.c078c718-4190-47ed-8b9a-7e1fa35e8920@github.com>

> This patch adds a dedicated jtreg property to check which CABI is being used by the JDK, which can be used both to check whether the foreign linker is supported, and whether the fallback linker is being used. (and, possibly it can also be use to check for a particular ABI in case we want to add ABI specific tests).
> 
> Checking whether the foreign linker is supported currently requires using an unwieldy expression that checks if we are running on a platform that has a foreign linker port. Checking for the fallback linker currently uses `vm.flavor != "zero"` which is not always correct, since the fallback linker can also be used on other platforms which are not `zero`.
> 
> To initialize the property, VMProps directly reads `jdk.internal.foreig.CABI::current()`. Since this class is in an internal package, `--add-exports` flags are added as javac flags and VM flags for the extra prop definitions class.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  jdk.CABI -> jdk.foreign.linker

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13429/files
  - new: https://git.openjdk.org/jdk/pull/13429/files/272478b6..a3947c55

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

  Stats: 81 lines in 48 files changed: 2 ins; 2 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/13429.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13429/head:pull/13429

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

From jvernee at openjdk.org  Tue May  2 13:13:33 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 2 May 2023 13:13:33 GMT
Subject: RFR: 8304888: Add dedicated VMProps for linker and fallback linker
 [v4]
In-Reply-To: <x4ODnhgyEawHnMJNv7FQTQbUpv67dQsISF4_wWOihIM=.c63a6897-e530-4943-885c-ec6462837a43@github.com>
References: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
 <x4ODnhgyEawHnMJNv7FQTQbUpv67dQsISF4_wWOihIM=.c63a6897-e530-4943-885c-ec6462837a43@github.com>
Message-ID: <akinUt69f7tJdHAsELRY0r4HCeayhg6iTN_Z1D31mkI=.caef77dd-d4ee-40f5-827e-3aefbecd2a90@github.com>

On Mon, 1 May 2023 16:48:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch adds a dedicated jtreg property to check which CABI is being used by the JDK, which can be used both to check whether the foreign linker is supported, and whether the fallback linker is being used. (and, possibly it can also be use to check for a particular ABI in case we want to add ABI specific tests).
>> 
>> Checking whether the foreign linker is supported currently requires using an unwieldy expression that checks if we are running on a platform that has a foreign linker port. Checking for the fallback linker currently uses `vm.flavor != "zero"` which is not always correct, since the fallback linker can also be used on other platforms which are not `zero`.
>> 
>> To initialize the property, VMProps directly reads `jdk.internal.foreig.CABI::current()`. Since this class is in an internal package, `--add-exports` flags are added as javac flags and VM flags for the extra prop definitions class.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
> 
>  - UNKNOWN -> UNSUPPORTED + fix TestLinker on FALLBACK
>  - Merge branch 'master' into VMProps
>  - Merge branch 'master' into VMProps
>  - use only jdk.CABI property
>  - use extra props to check for linker
>  - Add fallbackLinker vmprop
>  - Merge pull request #3 from JornVernee/IsForeignLinkerSupported
>    
>    rename has_port
>  - rename has_port
>  - Merge pull request #2 from JornVernee/WSL_BB
>    
>    account for missing functional in WSL in TestByteBuffer
>  - account for missing mincore on WSL in TestByteBuffer
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/7d07d195...272478b6

I went with the `jdk.CABI -> jdk.foreign.linker` name change. Re-tested. Will integrate soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/13429#issuecomment-1531445789

From duke at openjdk.org  Tue May  2 13:25:28 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 2 May 2023 13:25:28 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v11]
In-Reply-To: <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
Message-ID: <YDY4W2zRpFLbAFvfKFeCUw8gH6SUpB7lwbdpR0YMUF0=.338780be-25ef-4de9-af9f-af6869b7a9f2@github.com>

On Mon, 1 May 2023 14:56:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with a check to the class data. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:
> 
>  - Renames
>  - Merge branch 'master' into explore/mhp-iface
>  - Consolidate iteration over public methods
>  - Define MH proxy class in a dynamic module
>  - Fix test that depend on WrapperInstance
>  - Require an original lookup in constructor arguments to prevent unintended instantiation
>  - pass interface info via condy,
>    drop explicit ea flags
>    initialize benchmark work variable randomly
>    benchmarks just need 1 fork
>  - Nuke WrapperInstance
>  - Merge branch 'master' into explore/mhp-iface
>  - Whitespace, cleanup, rename benchmarks to be informative
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/10df4e16...f5d0ef0a

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 225:

> 223:             proxy = lookup.findConstructor(lookup.lookupClass(), methodType(void.class, Lookup.class))
> 224:                           .invoke(lookup);
> 225:             assert proxy.getClass().getModule().isNamed() : proxy.getClass() + " " + proxy.getClass().getModule();

This?`assert` should?be?moved after?the?`try`?statement.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1182537580

From simonis at openjdk.org  Tue May  2 13:26:31 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 2 May 2023 13:26:31 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v4]
In-Reply-To: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
Message-ID: <uD_A_HqCbyYCyOffqEmAWOWfLK1O1uMcEW-1ZroZ2Q4=.6c9accf3-df67-4ae0-a3e9-1688a2e5a2cf@github.com>

> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
> 
> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
> 
> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
> 
> Returns:
> the non-negative number of array elements when deserializing an array of the class, otherwise -1
> 
> but currently returns a negative value if the array length is negative.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Throw StreamCorruptedException instead of InvalidClassException and handle negative array size in checkArray() as well

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13540/files
  - new: https://git.openjdk.org/jdk/pull/13540/files/4bc579e6..4762023a

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

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

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

From simonis at openjdk.org  Tue May  2 13:26:36 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 2 May 2023 13:26:36 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v3]
In-Reply-To: <V0VBjNN703US-CGtwAM0wIeUaLlibviunbdmTu_5Gwg=.3dd83c8a-7b19-4794-bc72-9fcc8f66e9e0@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <oJ8ZXUlfXgCGsf2GUdqu9lqihPWAP9-L1JslWzGmc0s=.cbf6ded7-1c9e-4425-a570-ff3be20c8eda@github.com>
 <V0VBjNN703US-CGtwAM0wIeUaLlibviunbdmTu_5Gwg=.3dd83c8a-7b19-4794-bc72-9fcc8f66e9e0@github.com>
Message-ID: <yDm0LkKRM2WYDUU2RIOgBDKezS3uLF7gHUbYen9j7xY=.e0186c74-5408-4d02-9c96-94c10bdbae04@github.com>

On Thu, 27 Apr 2023 21:24:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volker Simonis has updated the pull request with a new target base 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 JDK-8306461
>>  - Simplified exception message and fixed test to check the correct message
>>  - Addresed review comments of @turbanoff, @shipilev and @RogerRiggs
>>  - 8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions
>
> Thanks for the investigation.
> 
> On the question of the exception thrown IllegalObjectException vs StreamCorruptedExeception, I'd lean toward StreamCorruptedException, including for the current PR; as that is more indicative of the issue raised.
> 
> As for addressing the existing uses of checkArray that would throw NAE, I would rather see a single fix in checkArray than adding code in multiple other places.  A fix in checkArray would cover future uses as well as current uses. The existing code that is checking len < 0 before calling checkArray can continue to do so to maintain compatibility on the exception thrown. Though a change would be unlikely to break user code it is better to avoid that. (It might cause changes existing tests).
> 
> Handling it in a separate PR may be reasonable but it too will require a CSR (change in behavior from throwning NAE to SCE) and the cause and behavior change are generally the same as the current PR.  If handled in a single PR/CSR and release note will have a more coherent and singular explanation.

Hi @RogerRiggs,

I have now updated both, `checkArray()` and `readArray()` to throw a `StreamCorruptedException("Array length is negative")` in the case of a negative array size. I've also changed the signature of `ObjectInputStream::checkArray()` and `JavaObjectInputStreamAccess::checkArray` to throw an `ObjectStreamException` instead of an `InvalidClassException` because `ObjectStreamException` is the super class of both `InvalidClassException` and `StreamCorruptedException`. Finally I've updated the test with an extra case of a `PriorityQueue` with a negative element size in order to test `checkArray()`.

OK now? Once we read consensus here I'll update the CSR accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/13540#issuecomment-1531464609

From liach at openjdk.org  Tue May  2 13:48:31 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 May 2023 13:48:31 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v11]
In-Reply-To: <YDY4W2zRpFLbAFvfKFeCUw8gH6SUpB7lwbdpR0YMUF0=.338780be-25ef-4de9-af9f-af6869b7a9f2@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
 <YDY4W2zRpFLbAFvfKFeCUw8gH6SUpB7lwbdpR0YMUF0=.338780be-25ef-4de9-af9f-af6869b7a9f2@github.com>
Message-ID: <trEHD17nOfi-QWVkTt-5wMl0-PXaOBpS_GA9AccZhdA=.6da20d2f-9c55-4a87-bf06-c17e6d8da641@github.com>

On Tue, 2 May 2023 13:19:55 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:
>> 
>>  - Renames
>>  - Merge branch 'master' into explore/mhp-iface
>>  - Consolidate iteration over public methods
>>  - Define MH proxy class in a dynamic module
>>  - Fix test that depend on WrapperInstance
>>  - Require an original lookup in constructor arguments to prevent unintended instantiation
>>  - pass interface info via condy,
>>    drop explicit ea flags
>>    initialize benchmark work variable randomly
>>    benchmarks just need 1 fork
>>  - Nuke WrapperInstance
>>  - Merge branch 'master' into explore/mhp-iface
>>  - Whitespace, cleanup, rename benchmarks to be informative
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/856693aa...f5d0ef0a
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 225:
> 
>> 223:             proxy = lookup.findConstructor(lookup.lookupClass(), methodType(void.class, Lookup.class))
>> 224:                           .invoke(lookup);
>> 225:             assert proxy.getClass().getModule().isNamed() : proxy.getClass() + " " + proxy.getClass().getModule();
> 
> This?`assert` should?be?moved after?the?`try`?statement.

No different; we always rethrow any `Error` so an `AssertionError` will be thrown normally. We do not intend to continue normal execution if the try block fails.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1182572029

From mark.yagnatinsky at barclays.com  Tue May  2 13:50:59 2023
From: mark.yagnatinsky at barclays.com (mark.yagnatinsky at barclays.com)
Date: Tue, 2 May 2023 13:50:59 +0000
Subject: a plea for blocking peek
In-Reply-To: <MW4PR10MB577412C72C6275FEAD9A42C2FF6F9@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <MN2PR12MB36161B757A4D48C39A5A4D79F96E9@MN2PR12MB3616.namprd12.prod.outlook.com>
 <c8823dc7-8a0f-5750-7d32-3b10d5182b2e@gmail.com>
 <MW4PR10MB577412C72C6275FEAD9A42C2FF6F9@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <MN2PR12MB3616A38E876EF89ED8F013D4F96F9@MN2PR12MB3616.namprd12.prod.outlook.com>

Thanks both for responding!  Re: DelayQueue peek() being special: you're right, I missed that.
So my original proposal would not solve my problem.
I really want to "block until poll() would return non-null"
Let's pretend that's what blockingPeek() would do, though maybe the name is no longer suitable.

Re: John H: good point that I did not really explain what I'm trying to do.
Basically I wanted a "keyed" DelayQueue with one added feature:
AFTER inserting something into the queue, I discover that the initial delay is too soon and should be postponed.
(Use case: imagine something should happen at least once per hour.
So we set a timer for one hour and worry if the timer goes off.
We need to be able to reset the timer if it happens ahead of schedule, or we'll worry for no reason.)
The way I wanted to implement this is to store the "real" expiration in a map.
This involves enforcing the invariant that the queue and map remain "in sync".
Thus I prefer to hold a lock if I'm mutating either the queue or the map, so that changes appear atomic to other threads.

Hope that's clearer now.

From: Viktor Klang <viktor.klang at oracle.com>
Sent: Tuesday, May 2, 2023 4:08 AM
To: John Hendrikx <john.hendrikx at gmail.com>; core-libs-dev at openjdk.org; Yagnatinsky, Mark : Markets Pre Trade <mark.yagnatinsky at barclays.com>
Subject: Re: a plea for blocking peek


CAUTION: This email originated from outside our organisation - viktor.klang at oracle.com<mailto:viktor.klang at oracle.com> Do not click on links, open attachments, or respond unless you recognize the sender and can validate the content is safe.
Hi,

I think the conversation also becomes a bit more difficult since the topic seems to be around DelayQueue-which has slightly different semantics than typical BlockingQueue implementations.
For instance, peek() returns the element with the lowest expiry (possibly in the future)-so you cannot really use the blocking peek() for much else than observing the lowest expiry-and the only difference to the non-blocking peek() would be that you can block the reader for as long as the queue is empty without A) removing the element and B) doing busy-waiting with some form of back-off policy which might ending up sleeping for too long.
Since queues tend to spend their time being either full or empty (since there's typically either a faster consumption than production or vice versa), I can understand the need to be notified when the queue is no longer empty. With that said, in the case of DelayQueue, it still doesn't mean that the result of a blocking peek() means that the element is consumable at that point. So the question is what you'd use the information for?

When composing multiple data structures, especially concurrent ones, I find it easier to reason about the problem space starting with the interaction pattern from the outside (who consumes and who produces), as the less coordination needed the better in terms of throughput (Amdahl's Law & Universal Scalability Law) etc, and if you can design for single-reader or single-writer (or both!) you can get away with much more performant implementations since the coordination need is much lower.


________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of John Hendrikx <john.hendrikx at gmail.com<mailto:john.hendrikx at gmail.com>>
Sent: Tuesday, 2 May 2023 08:46
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org> <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>; mark.yagnatinsky at barclays.com<mailto:mark.yagnatinsky at barclays.com> <mark.yagnatinsky at barclays.com<mailto:mark.yagnatinsky at barclays.com>>
Subject: Re: a plea for blocking peek


Hi,

I think it would help if you describe your problem a bit more directly.  Currently there is a lot of mention of difficulty levels, usual approaches and "winning", which really doesn't help to ascertain what you are trying to achieve. For a good re-evaluation of your request, you are going to need to show some (pseudo) code so people can see if this indeed is a good use case, or that there is an elegant alternative solution.

It's really hard to glean from your post what you are trying to do.  It seems like you have a queue and a map.  Items you get from the queue need to be verified against the map.  The lock seems to protect the map structure against concurrent modification, and for some reason getting the lock after `take` isn't good enough.

--John
On 01/05/2023 19:12, mark.yagnatinsky at barclays.com<mailto:mark.yagnatinsky at barclays.com> wrote:


I'm not sure if this I'm breaking etiquette for this list but I'm going to risk resending my first message because it got zero replies.  If it was simply too long, please let me know and I'll attempt a shorter version.



Here's like to original:

https://mail.openjdk.org/pipermail/core-libs-dev/2023-April/104931.html<https://clicktime.symantec.com/15t5jYTFmaQc4V1t88CUj?h=LBFB_Nq9tTnZigIGSEGdtPI-yf5pM2QRYu75ZQPdMrc=&u=https://mail.openjdk.org/pipermail/core-libs-dev/2023-April/104931.html>



From: Yagnatinsky, Mark : Markets Pre Trade
Sent: Thursday, April 27, 2023 12:28 PM
To: core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>
Subject: RE: blocking peek for blocking queues



Someone said this is the right list for this, so forwarding from jdk-dev with a small tweak



I'd like to make a case for adding a blocking variant of peek() to BlockingQueue.

This has apparently been suggested before:

https://bugs.openjdk.org/browse/JDK-6653412<https://clicktime.symantec.com/15t5eiFyJxj1eYBxaZoL7?h=8xuZNSBOobjYTAnKJmm6Y3zyDdQB80zgAhmGgE74pOQ=&u=https://bugs.openjdk.org/browse/JDK-6653412>

At the time, the verdict was that the proposed use case for a blocking peek was not very compelling, but " If a compelling use case is available,we may reconsider and reopen this RFE"

For one thing, that use case was inherently racy, and ideally the standard library should not be encouraging races.

And for another thing, this was before the invention of default methods, so a new interface would be needed.

I'd like to present what might be a more sympathetic use case, where a blocking peek actually makes it easier to avoid races.

(This is not hypothetical; I've spent all day trying to cope with the lack of a blocking peek.  I think I succeeded, but it was tough.)



Let's start at the beginning.  The game known as "multithreaded programming" can be played on 3 difficulty levels: easy, medium, and hard.

Easy mode is when the JDK happens to have a high-level tool (e.g., a Collection or an Executor or something) such as DelayQueue that does exactly what you want.

Sadly, the JDK is finite, and even Maven Central is finite, so this not guaranteed to happen, though it's nice when it does.

At the other extreme is hard mode, when every nanosecond counts and you must resort to the sorts of mental gymnastics that were involved when String.hashCode was re-worked to avoid re-computing hash codes equal to zero.



This email is about the medium difficulty level.  In this mode, you must glue together two or three collections to get what you want.

To be concrete, suppose we want to glue a map together with a blocking queue, since that's a simplified version of what I was doing.  (In particular I was using a DelayQueue and a HashMap.)

Since we're not playing on hard mode, we're going to allow ourselves to guard the entire data structure by one giant lock whenever it seems convenient, without worrying about performance.

In fact, let's give a name to this lock.  Since I'm not feeling very creative right now, let's call it LOCK.  Similarly, let's call our compound data structure STRUCT.

My usual heuristic to "win" (that is, to make sure my code is correct, or at least non-racy) on medium difficulty goes something like this.

First, figure out whether there is any way for STRUCT to be "invalid".

For instance, maybe "it's valid if and only if every entry in the queue has a corresponding entry in the map".

One could then write a brief comment in the code explaining what "valid" means, or perhaps even write an "isValid()" method for testing purposes.

Once we've decided what it means for STRUCT to be "valid" (aka, non-corrupt), we can try to maintain the following invariant:

EITHER some thread holds the LOCK, and no other thread is using STRUCT right now,

OR ELSE the LOCK  is not held by any thread, and thus STRUCT is currently in a valid state.

Sometimes the invariant above is a bit too strong, and it's convenient to weaken it slightly.  So we can instead consider the following rule:

RULE: we must never mutate STRUCT unless we hold the LOCK.

If we uphold the invariant, then we must be following the rule, but not vice versa.

(The rule doesn't forbid queries without the lock; it only forbids writes.)



Finally, we come to the point.  The lack of a blocking peek in BlockingQueue has forced me to break the above "weakened" rule.

I had to invent a new much weaker rule, something like "please carefully think through all possible interleaved executions; if they all work, great!".

What went wrong?  Well, one of the methods I wanted on STRUCT was basically "call take() on the queue, and then do things with the result".

The trouble is that you can't usually afford to hold a lock while calling take(), since it can block forever, and in the meantime you've "locked out" anyone who could have added something and thus unblocked you.

Thus, I split my method into two pieces: In PART_ONE we call take() without the LOCK, and once take() returns I grab the lock right away and run PART_TWO.

But notice that this breaks the RULE from the previous paragraph: I mutated the STRUCT without holding the LOCK.

This means my method is not atomic: it's possible for some other thread to observe that PART_ONE is done but PART_TWO is not started.

Typically this means that other threads can now observe the STRUCT in an invalid (aka corrupt/broken) state.



Now, suppose we had a blocking peek.  How does that help?  In that case, we would still break our method into two pieces.

To avoid confusion, let's call them PART_A and PART_B.  In PART_A we call blockingPeek() without holding the LOCK.

Note that we completely ignore the return value from peek; for all we care, the return type is "void" instead of "T".

This breaks the "invariant" from a few paragraphs ago since we're technically "using" the STRUCT but it respects the "rule" since we're not mutating it.

Once peek returns, PART_B begins.  Here, we grab the lock, and do a non-blocking poll() on the queue.

It's might return "null" if someone raced us to get the lock.  But from our perspective that's okay: it's just like a spurious wakeup from a raw wait() call.

The reason it's okay is that we haven't done anything yet, so we can just call blockingPeek() again and hope for better luck next time.

Similarly we don't care if poll() returns a different item than blockingPeek() originally did, since we never looked at what peek() returned.

The rest of PART_B is basically PART_TWO from the "peek-less" world.

Note that this way, our method appears atomic to other threads, since PART_A doesn't actually do anything; all the work happens in PART_B, which is guarded by the LOCK.



Thoughts?

This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html<https://clicktime.symantec.com/15t69hRg4epa8D9VqvCDq?h=-3mwRiHllHKu-mx5mhLnv52Z_4IbikUQWio278f4PQQ=&u=https://www.cib.barclays/disclosures/web-and-email-disclaimer.html>.

For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html<https://clicktime.symantec.com/15t64sEPc38yiGKaJMo5D?h=oMRxaXIQ3u-OAjHOHoIJ12Q6Xvd18bfr8Zh7uBGFxyU=&u=https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html> regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html<https://clicktime.symantec.com/15t5pNeYEC6CURqofgbdM?h=JL4FUcCyPdlJHc30zVvoYnr_RofP7sC0WpF38usDgyc=&u=https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html> regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com<https://clicktime.symantec.com/15t5Zt4grM3REbN331QBV?h=9z3-VRvLZpe8YmOkBXvpzPozW6VCrzt2JEDDz4eDybA=&u=http://publicresearch.barclays.com>.
__________________________________________________________________________________
If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html<https://clicktime.symantec.com/15t5uCqpgomntNfjDEzmy?h=2EajesTPX5m7Ra4igt5cBHjbTC0CCpozqCRCa3Bg6BM=&u=https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html>.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html<https://clicktime.symantec.com/15t5z3379RTPJKVekoPvb?h=eF4fDVda50ewe9_uCtYec7foCfszmYGuh4HlJUcCsbU=&u=https://www.cib.barclays/disclosures/personal-information-use.html>.
__________________________________________________________________________________

This message is for information purposes only. It is not a recommendation, advice, offer or solicitation to buy or sell a product or service, nor an official confirmation of any transaction. It is directed at persons who are professionals and is intended for the recipient(s) only. It is not directed at retail customers. This message is subject to the terms at: https://www.cib.barclays/disclosures/web-and-email-disclaimer.html. 

For important disclosures, please see: https://www.cib.barclays/disclosures/sales-and-trading-disclaimer.html regarding marketing commentary from Barclays Sales and/or Trading desks, who are active market participants; https://www.cib.barclays/disclosures/barclays-global-markets-disclosures.html regarding our standard terms for Barclays Corporate and Investment Bank where we trade with you in principal-to-principal wholesale markets transactions; and in respect to Barclays Research, including disclosures relating to specific issuers, see: http://publicresearch.barclays.com.
__________________________________________________________________________________ 
If you are incorporated or operating in Australia, read these important disclosures: https://www.cib.barclays/disclosures/important-disclosures-asia-pacific.html.
__________________________________________________________________________________
For more details about how we use personal information, see our privacy notice: https://www.cib.barclays/disclosures/personal-information-use.html. 
__________________________________________________________________________________
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230502/dd6475c1/attachment-0001.htm>

From mcimadamore at openjdk.org  Tue May  2 13:55:20 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 2 May 2023 13:55:20 GMT
Subject: RFR: 8304888: Add dedicated VMProps for linker and fallback linker
 [v4]
In-Reply-To: <akinUt69f7tJdHAsELRY0r4HCeayhg6iTN_Z1D31mkI=.caef77dd-d4ee-40f5-827e-3aefbecd2a90@github.com>
References: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
 <x4ODnhgyEawHnMJNv7FQTQbUpv67dQsISF4_wWOihIM=.c63a6897-e530-4943-885c-ec6462837a43@github.com>
 <akinUt69f7tJdHAsELRY0r4HCeayhg6iTN_Z1D31mkI=.caef77dd-d4ee-40f5-827e-3aefbecd2a90@github.com>
Message-ID: <uJd2StAPeP5Aajh5LEZpdyai5lL7kIb8q_8ZsfHxgpo=.5421ff6d-bcf5-4f68-8ccb-2bbd3b0004cd@github.com>

On Tue, 2 May 2023 13:07:37 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I went with the `jdk.CABI -> jdk.foreign.linker` name change. Re-tested. Will integrate soon.

Looks good (if we wanted to be 100% explicit, then it would have been jdk.foreign.system.linker/jdk.foreign.native.linker - but what you picked is better than what it replaces).

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

PR Comment: https://git.openjdk.org/jdk/pull/13429#issuecomment-1531518773

From jvernee at openjdk.org  Tue May  2 13:59:34 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 2 May 2023 13:59:34 GMT
Subject: Integrated: 8304888: Add dedicated VMProps for linker and fallback
 linker
In-Reply-To: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
References: <dodIf7OuCPmI1AnU2z5i6D1S10FiKm2UWHdj-nlqcDU=.55e0555f-ffc1-4bb3-ac7d-080bd71440b2@github.com>
Message-ID: <J7D3L-c9Lf3m5ruLWgKJdTeqcXpAmvYeh963D9LLy6M=.b1d93520-9d10-473d-87c1-f8600728ca11@github.com>

On Tue, 11 Apr 2023 17:28:06 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch adds a dedicated jtreg property to check which CABI is being used by the JDK, which can be used both to check whether the foreign linker is supported, and whether the fallback linker is being used. (and, possibly it can also be use to check for a particular ABI in case we want to add ABI specific tests).
> 
> Checking whether the foreign linker is supported currently requires using an unwieldy expression that checks if we are running on a platform that has a foreign linker port. Checking for the fallback linker currently uses `vm.flavor != "zero"` which is not always correct, since the fallback linker can also be used on other platforms which are not `zero`.
> 
> To initialize the property, VMProps directly reads `jdk.internal.foreig.CABI::current()`. Since this class is in an internal package, `--add-exports` flags are added as javac flags and VM flags for the extra prop definitions class.

This pull request has now been integrated.

Changeset: a8bf2acb
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a8bf2acb7db63b508ef169e42a27b9c99178cbb1
Stats:     129 lines in 50 files changed: 41 ins; 8 del; 80 mod

8304888: Add dedicated VMProps for linker and fallback linker

Reviewed-by: alanb, mcimadamore

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

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

From forax at openjdk.org  Tue May  2 14:00:27 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 2 May 2023 14:00:27 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v2]
In-Reply-To: <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
Message-ID: <I2onL10Ro48dfUZASSphE5PkWvaVQoWa4l2-EoxSZ5c=.dfe9629e-9b4f-46ff-8fa1-9404142da1f0@github.com>

On Tue, 17 Jan 2023 15:55:40 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.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Adding comments
>  - Improving performance
>  - Merge branch 'master' into JDK-8291966
>  - 8291966: SwitchBootstrap.typeSwitch could be faster

Also there is a lot of use cases where the type switch is called only with instances of the same class, for those scenarii, the VM should be able to fully remove the type switch and inline the body of the corresponding case like this is done with a virtual call.

I don't think there is a way currently to explain to the VM that the a hash map really acts as a cache so if the key is a constant then the value is a constant too (this optimization is also missing when JITing ClassValue.get()).

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

PR Comment: https://git.openjdk.org/jdk/pull/9779#issuecomment-1531526385

From mchhipa at openjdk.org  Tue May  2 14:03:22 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Tue, 2 May 2023 14:03:22 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v4]
In-Reply-To: <_E56xvqH_R4JnPX6PyDs1FrPOwDRYpmuWxpJuhtDza4=.b210bfb2-fbec-4cb5-b606-0585076943c1@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <pC4U4hXLT4yWyOrZ3uSxaGBlnEfcBP2uJl1g95SoNkg=.fcdb924f-5639-42ce-bb6d-b636a905e6de@github.com>
 <_E56xvqH_R4JnPX6PyDs1FrPOwDRYpmuWxpJuhtDza4=.b210bfb2-fbec-4cb5-b606-0585076943c1@github.com>
Message-ID: <toOvyiDRSJmSLba-i0_mzJ_gyiJdTYg9HpLW28OVs2Q=.d3627596-5a5e-4a96-bb0f-ee73d6fb6eb5@github.com>

On Fri, 28 Apr 2023 18:43:32 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented the review comments.
>
> test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
> 
> missed the original copyright year, e.g. 2014, 2023,

Added the copyright year and added the JDK version information in Data files.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1182592044

From jvernee at openjdk.org  Tue May  2 14:06:29 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 2 May 2023 14:06:29 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v24]
In-Reply-To: <f7PQLu5FhSRrfOSJcxm6CjglKWEWm49qXQhLpgDxQm0=.6221dde9-e21f-4a74-9a7d-a1bb331dc3ff@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <Vr9eU-MocRqojzzn5eDc29rLeIHY8vDHHrJClAQUGNc=.f8a666a5-7722-4d51-bba2-6abefde3d711@github.com>
 <f7PQLu5FhSRrfOSJcxm6CjglKWEWm49qXQhLpgDxQm0=.6221dde9-e21f-4a74-9a7d-a1bb331dc3ff@github.com>
Message-ID: <qfWb-BTPd8c7EkaiREWiJVnUDv7UX_mOLWw5eghdCvQ=.2a54a941-8f5b-4ac8-a533-dc993ef2488e@github.com>

On Thu, 27 Apr 2023 12:59:33 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert unintended formatting changes. Fix comment.
>
> Adapted for JDK21, now. All tests have passed. My IDE had changed the formatting which is reverted, now. (I've kept the minor formatting changes in TestDontRelease.java because it looks better.)

@TheRealMDoerr I think you already noticed but I have been integrating some followup patches after the JEP was integrated. I've also just integrated: https://github.com/openjdk/jdk/pull/13429 which looks like it has create a merge conflict. The good news is that it should no longer be needed to enable each test on PPC explicitly, as this now happens automatically as a result of adding the `LINUX_PPC_64_LE` constant to the CABI enum.

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

PR Comment: https://git.openjdk.org/jdk/pull/12708#issuecomment-1531528368

From jvernee at openjdk.org  Tue May  2 14:06:34 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 2 May 2023 14:06:34 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v25]
In-Reply-To: <IFv5eY7cNJCI9X-hyL17huLJxjun9vNrLeVNhSiAK6M=.5dc745a9-b434-475d-9021-82f94f6bbb08@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <IFv5eY7cNJCI9X-hyL17huLJxjun9vNrLeVNhSiAK6M=.5dc745a9-b434-475d-9021-82f94f6bbb08@github.com>
Message-ID: <jXWpTI3ZeWf4N-_aUTtHu-kmYfgZKTQGIT8BAYmPJCY=.198b808c-6e26-456a-bb20-92c284ca39a0@github.com>

On Tue, 2 May 2023 09:51:47 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:
> 
>  - Adaptation for JDK-8303002.
>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>  - Revert unintended formatting changes. Fix comment.
>  - Enable remaining foreign tests.
>  - Adaptations for JDK-8304265.
>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>  - Adaptation for JDK-8305668
>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>  - Move ABIv2CallArranger out of linux subdirectory. ABIv1/2 does match the AIX/linux separation.
>  - Adaptation for JDK-8303022.
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/860bf9b3...f5e22be0

On another note, how are you coming along with finding another reviewer? I (still) think it would be good to get someone that is familiar with PPC (particularly the ABI) as a second reviewer.

test/jdk/java/foreign/TestHFA.java line 31:

> 29:  * @summary Test passing of Homogeneous Float Aggregates.
> 30:  * @enablePreview
> 31:  * @requires ((os.arch == "amd64" | os.arch == "x86_64") & sun.arch.data.model == "64") | os.arch == "aarch64" | os.arch == "ppc64le" | os.arch == "riscv64"

This should also check for `jdk.foreign.linker != "UNSUPPORTED"` now.

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

PR Comment: https://git.openjdk.org/jdk/pull/12708#issuecomment-1531534791
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1182592089

From mchhipa at openjdk.org  Tue May  2 14:09:18 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Tue, 2 May 2023 14:09:18 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v4]
In-Reply-To: <jjAm97rPEHzRGIeP7e3HVt8N6AzWu4Z39mofx3UPMO4=.dbb2f64b-a035-460f-a2cb-acd0ae97de13@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <pC4U4hXLT4yWyOrZ3uSxaGBlnEfcBP2uJl1g95SoNkg=.fcdb924f-5639-42ce-bb6d-b636a905e6de@github.com>
 <jjAm97rPEHzRGIeP7e3HVt8N6AzWu4Z39mofx3UPMO4=.dbb2f64b-a035-460f-a2cb-acd0ae97de13@github.com>
Message-ID: <e80iDDLFQESn_VYqiLm2iGY0veF7HoDaJvdlx0hZ4DU=.d952d700-ec76-424c-826d-8eb04c81c314@github.com>

On Sat, 29 Apr 2023 16:15:58 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Implemented the review comments.
>
> test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 85:
> 
>> 83: 
>> 84:         // Generates the Java Pseudo code for base64 encoded string that can be cut & pasted into the test
>> 85:         final StringBuilder sb = new StringBuilder();
> 
> Can you please explain the purpose of the following code in the `setup` method?.  This appears to be what you used to generate the _JDK**X**GregorianCalendarAndDurationSerData.java_ files.  I don't see why this would be needed in a setup method. 
> 
> Providing a method, along with comments of how to use it, to create byte arrays make sense, just not in a setup method.

This is added in setup method to create the serialized data with current JDK version (JDK under test). In addition to serialized data generated with old JDK version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1182597550

From asotona at openjdk.org  Tue May  2 14:15:27 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 2 May 2023 14:15:27 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v10]
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <76DeLp-sOfzFX5zpxfxAcaiEO1WV7kwf5ovvkteKHNI=.3b0146d2-b2f5-434e-b197-ef9d7c1b93c2@github.com>

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

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

 - Merge branch 'master' into JDK-8305990-debug-info-strip-fail
 - Update StackCounter.java
 - added comments to StackCounter about maxStack upper bounds calculation for JSR/RET instructions
 - fixed stack counting of JSR instructions
 - implemented StackCounter
 - Making some BufWriter fields final
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/classfile/Opcode.java
   
   Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
 - fixed ClassPrinterImpl
 - DiscontinuedInstruction implementation + test
 - ... and 2 more: https://git.openjdk.org/jdk/compare/9ce19553...f132f737

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13478/files
  - new: https://git.openjdk.org/jdk/pull/13478/files/42b96b2c..f132f737

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

  Stats: 285823 lines in 2346 files changed: 252875 ins; 16769 del; 16179 mod
  Patch: https://git.openjdk.org/jdk/pull/13478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13478/head:pull/13478

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

From mdoerr at openjdk.org  Tue May  2 14:24:39 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 2 May 2023 14:24:39 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v26]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <6T74cq3nirARNZCJzJrDyqKifUbmzEg2Ky8hW3Tfh6U=.4bf0350a-380c-4d01-a179-4b66f7d99ddf@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:

 - Merge remote-tracking branch 'origin' into PPC64_Panama
 - Prepare for JDK-8304888. (Revert test changes.)
 - Adaptation for JDK-8303002.
 - Merge remote-tracking branch 'origin' into PPC64_Panama
 - Revert unintended formatting changes. Fix comment.
 - Enable remaining foreign tests.
 - Adaptations for JDK-8304265.
 - Merge remote-tracking branch 'origin' into PPC64_Panama
 - Adaptation for JDK-8305668
 - Merge remote-tracking branch 'origin' into PPC64_Panama
 - ... and 22 more: https://git.openjdk.org/jdk/compare/a8bf2acb...e4ddbda0

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

Changes: https://git.openjdk.org/jdk/pull/12708/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=25
  Stats: 2395 lines in 27 files changed: 2348 ins; 0 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12708/head:pull/12708

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

From mchhipa at openjdk.org  Tue May  2 14:26:34 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Tue, 2 May 2023 14:26:34 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v5]
In-Reply-To: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
Message-ID: <3OX_2O8ThlpCnX5nXCPZW0o9tdOlOJztzel5X7nK8mo=.e43ffc9c-bd02-48d3-a08e-9892cdd2f399@github.com>

> Test is updated to create the binary files during test execution.

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  1. Added JDK version in Data files.
  2. Updated copyright year.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13537/files
  - new: https://git.openjdk.org/jdk/pull/13537/files/f867ba2e..1ddb5e69

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

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

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

From mdoerr at openjdk.org  Tue May  2 14:38:28 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 2 May 2023 14:38:28 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v25]
In-Reply-To: <jXWpTI3ZeWf4N-_aUTtHu-kmYfgZKTQGIT8BAYmPJCY=.198b808c-6e26-456a-bb20-92c284ca39a0@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <IFv5eY7cNJCI9X-hyL17huLJxjun9vNrLeVNhSiAK6M=.5dc745a9-b434-475d-9021-82f94f6bbb08@github.com>
 <jXWpTI3ZeWf4N-_aUTtHu-kmYfgZKTQGIT8BAYmPJCY=.198b808c-6e26-456a-bb20-92c284ca39a0@github.com>
Message-ID: <qCtoX8xNhqAQUtf1BGy0UPCwip6rtixk7z6p3DC0WrY=.5e300b7f-9d80-47bb-b4b2-7411b8237ebc@github.com>

On Tue, 2 May 2023 14:01:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> On another note, how are you coming along with finding another reviewer? I (still) think it would be good to get someone that is familiar with PPC (particularly the ABI) as a second reviewer.

Second Review is in progress. I have merged your recent changes and all tests are passing. Your updates made my PR much smaller :-)
Do you have for more changes to wait for or would you prefer to have this PR integrated soon?

Off topic: I have read parts of the Big Endian ABI and we will need a solution for "An aggregate or union smaller than one doubleword in size is padded so that it appears in the least significant bits of the doubleword. All others are padded, if necessary, at their tail." The tail padding seems to be tricky for Big Endian as we currently access the wrong bytes. I think it could be solved by dirty hacks (shifting) in the backend, but that doesn't sound like a good solution. Do you have a good idea for that? Maybe shift or pad in Java?

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

PR Comment: https://git.openjdk.org/jdk/pull/12708#issuecomment-1531594500

From jvernee at openjdk.org  Tue May  2 14:51:29 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 2 May 2023 14:51:29 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v25]
In-Reply-To: <qCtoX8xNhqAQUtf1BGy0UPCwip6rtixk7z6p3DC0WrY=.5e300b7f-9d80-47bb-b4b2-7411b8237ebc@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <IFv5eY7cNJCI9X-hyL17huLJxjun9vNrLeVNhSiAK6M=.5dc745a9-b434-475d-9021-82f94f6bbb08@github.com>
 <jXWpTI3ZeWf4N-_aUTtHu-kmYfgZKTQGIT8BAYmPJCY=.198b808c-6e26-456a-bb20-92c284ca39a0@github.com>
 <qCtoX8xNhqAQUtf1BGy0UPCwip6rtixk7z6p3DC0WrY=.5e300b7f-9d80-47bb-b4b2-7411b8237ebc@github.com>
Message-ID: <OmgTFwwV_RoFVd65XnMgw3gYujmg3N9v2aq6mif35uA=.ac6eac0d-1075-490d-acd1-e7beb01aae8a@github.com>

On Tue, 2 May 2023 14:35:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Do you have for more changes to wait for or would you prefer to have this PR integrated soon?

I don't have anything else in the pipeline at the moment.

> Off topic: I have read parts of the Big Endian ABI and we will need a solution for "An aggregate or union smaller than one doubleword in size is padded so that it appears in the least significant bits of the doubleword. All others are padded, if necessary, at their tail." The tail padding seems to be tricky for Big Endian as we currently access the wrong bytes. I think it could be solved by dirty hacks (shifting) in the backend, but that doesn't sound like a good solution. Do you have a good idea for that? Maybe shift or pad in Java?

In general the assumption of the linker is that any layouts it is given are correct for the given platform/ABI. i.e. it is up to the user to specify the correct padding (and this is where jextract can help out a lot). We do also check that layouts are 'canonical' now (see https://github.com/openjdk/jdk/pull/13164 & [1]). I think this already guarantees that the necessary trailing padding is present (constraint 3)? Did you see the discussion at [2] ? I think we already have Big Endian covered?

[1]: https://github.com/openjdk/jdk/blob/a8bf2acb7db63b508ef169e42a27b9c99178cbb1/src/java.base/share/classes/java/lang/foreign/Linker.java#L200-L209)
[2]: https://github.com/openjdk/panama-foreign/pull/806#discussion_r1122138401

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

PR Comment: https://git.openjdk.org/jdk/pull/12708#issuecomment-1531615390

From rgiulietti at openjdk.org  Tue May  2 15:45:33 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 2 May 2023 15:45:33 GMT
Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded
 double streams to RandomGenerator [v8]
In-Reply-To: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
Message-ID: <zLv8HBm-LXu-iW4iw24eHQcm3LkPyAgkr-oHJbQpS0U=.637d91a7-d009-4636-bc78-eaaa001202f1@github.com>

> The `default` method `nextDouble(double origin, double bound)` in `java.util.random.RandomGenerator` aims at generating a uniformly and spatially equidistributed random `double` in the left-closed and right-open range [`origin`, `bound`). It does so by applying the affine transform `origin + (bound - origin) * r` to a uniformly and spatially equidistributed random `double` `r` in the range [0, 1).
> 
> Since floating-point arithmetic suffers from small but noticeable rounding errors, this ends up slightly deforming the distribution of `r` when applying the affine transform.

Raffaello Giulietti has updated the pull request incrementally with two additional commits since the last revision:

 - Added tests.
 - Align code comment with @implSpec.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12719/files
  - new: https://git.openjdk.org/jdk/pull/12719/files/bc0021cd..b867d275

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

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

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

From mdoerr at openjdk.org  Tue May  2 15:52:31 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 2 May 2023 15:52:31 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v26]
In-Reply-To: <6T74cq3nirARNZCJzJrDyqKifUbmzEg2Ky8hW3Tfh6U=.4bf0350a-380c-4d01-a179-4b66f7d99ddf@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <6T74cq3nirARNZCJzJrDyqKifUbmzEg2Ky8hW3Tfh6U=.4bf0350a-380c-4d01-a179-4b66f7d99ddf@github.com>
Message-ID: <pEdSldJ_0NK_nTuU6_NORGeszCyKpaIcPxRXsXVrido=.f96ab89c-5ea8-4287-809f-7c9dfba491a5@github.com>

On Tue, 2 May 2023 14:24:39 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 32 commits:
> 
>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>  - Prepare for JDK-8304888. (Revert test changes.)
>  - Adaptation for JDK-8303002.
>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>  - Revert unintended formatting changes. Fix comment.
>  - Enable remaining foreign tests.
>  - Adaptations for JDK-8304265.
>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>  - Adaptation for JDK-8305668
>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/a8bf2acb...e4ddbda0

> In general the assumption of the linker is that any layouts it is given are correct for the given platform/ABI. i.e. it is up to the user to specify the correct padding (and this is where jextract can help out a lot). We do also check that layouts are 'canonical' now (see #13164 & [1]). I think this already guarantees that the necessary trailing padding is present (constraint 3)? Did you see the discussion at [2] ? I think we already have Big Endian covered?

I had seen that discussion. It appears to work for the TestMiniStruct I had uploaded (passed a structure consisting of 3 bytes). However, I'm getting failures when passing larger structs which have a size >8, but not divisible by 8. E.g. 17 tests of TestDowncallScope are failing. The guarantee was not hit.

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

PR Comment: https://git.openjdk.org/jdk/pull/12708#issuecomment-1531709856

From lancea at openjdk.org  Tue May  2 16:30:30 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 2 May 2023 16:30:30 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v4]
In-Reply-To: <e80iDDLFQESn_VYqiLm2iGY0veF7HoDaJvdlx0hZ4DU=.d952d700-ec76-424c-826d-8eb04c81c314@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <pC4U4hXLT4yWyOrZ3uSxaGBlnEfcBP2uJl1g95SoNkg=.fcdb924f-5639-42ce-bb6d-b636a905e6de@github.com>
 <jjAm97rPEHzRGIeP7e3HVt8N6AzWu4Z39mofx3UPMO4=.dbb2f64b-a035-460f-a2cb-acd0ae97de13@github.com>
 <e80iDDLFQESn_VYqiLm2iGY0veF7HoDaJvdlx0hZ4DU=.d952d700-ec76-424c-826d-8eb04c81c314@github.com>
Message-ID: <-46y0a0q_fNPvz8y4odsx1u5hnDIDPbg32ypRa3gu_E=.67c0d1e8-47d1-4013-814f-9c0642bf9b6c@github.com>

On Tue, 2 May 2023 14:05:03 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 85:
>> 
>>> 83: 
>>> 84:         // Generates the Java Pseudo code for base64 encoded string that can be cut & pasted into the test
>>> 85:         final StringBuilder sb = new StringBuilder();
>> 
>> Can you please explain the purpose of the following code in the `setup` method?.  This appears to be what you used to generate the _JDK**X**GregorianCalendarAndDurationSerData.java_ files.  I don't see why this would be needed in a setup method. 
>> 
>> Providing a method, along with comments of how to use it, to create byte arrays make sense, just not in a setup method.
>
> This is added in setup method to create the serialized data with current JDK version (JDK under test). In addition to serialized data generated with old JDK version.

Sorry, I still disagree with this.  Your comment in the test is as follows:

`// Generates the Java Pseudo code for base64 encoded string that can be cut & pasted into the test`

Which is what the method does and to facilitate it, as an example print it out so that it can be copied and pasted

` System.out.println(sb);`

Again, there is no reason to include this code in the setup method, it should be segmented out into its own method with instructions with how to create the encoded string

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1182779682

From rriggs at openjdk.org  Tue May  2 16:30:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 2 May 2023 16:30:31 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v4]
In-Reply-To: <uD_A_HqCbyYCyOffqEmAWOWfLK1O1uMcEW-1ZroZ2Q4=.6c9accf3-df67-4ae0-a3e9-1688a2e5a2cf@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <uD_A_HqCbyYCyOffqEmAWOWfLK1O1uMcEW-1ZroZ2Q4=.6c9accf3-df67-4ae0-a3e9-1688a2e5a2cf@github.com>
Message-ID: <_ukE-dTBAJjWmPj-7bYMLRMuvjjJq316RcAbPJdFXSE=.6f832b0f-8ff8-438c-bfb3-3453e25cd040@github.com>

On Tue, 2 May 2023 13:26:31 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw StreamCorruptedException instead of InvalidClassException and handle negative array size in checkArray() as well

Look good, thanks for fixing checkArray().

test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 77:

> 75:        byte[] serializedData = baos.toByteArray();
> 76: 
> 77:        // Find the right location to modify, looking for the first instance of TC_ENDBLOCKDATA

The comment should probably mention TC_BLOCKDATA, not TC_END...

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13540#pullrequestreview-1409399775
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1182740104

From simonis at openjdk.org  Tue May  2 16:54:32 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 2 May 2023 16:54:32 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v4]
In-Reply-To: <_ukE-dTBAJjWmPj-7bYMLRMuvjjJq316RcAbPJdFXSE=.6f832b0f-8ff8-438c-bfb3-3453e25cd040@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <uD_A_HqCbyYCyOffqEmAWOWfLK1O1uMcEW-1ZroZ2Q4=.6c9accf3-df67-4ae0-a3e9-1688a2e5a2cf@github.com>
 <_ukE-dTBAJjWmPj-7bYMLRMuvjjJq316RcAbPJdFXSE=.6f832b0f-8ff8-438c-bfb3-3453e25cd040@github.com>
Message-ID: <CKO2tggoDVNC6hQka_204WBng04O9mJ4yG7nfXL4Cls=.300c2da2-ed8b-4242-95a9-a11b8f442131@github.com>

On Tue, 2 May 2023 15:52:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Throw StreamCorruptedException instead of InvalidClassException and handle negative array size in checkArray() as well
>
> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 77:
> 
>> 75:        byte[] serializedData = baos.toByteArray();
>> 76: 
>> 77:        // Find the right location to modify, looking for the first instance of TC_ENDBLOCKDATA
> 
> The comment should probably mention TC_BLOCKDATA, not TC_END...

Doh! Fixed two comments but forgot the third one. Will fix.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1182803335

From simonis at openjdk.org  Tue May  2 17:06:58 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 2 May 2023 17:06:58 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v5]
In-Reply-To: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
Message-ID: <thubH1DC-WyI2sjvhRo1L-xeqNNn33Ms95g9joRsz98=.bb8e4576-f3ff-41e9-aa5d-6c0ba603441e@github.com>

> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
> 
> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
> 
> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
> 
> Returns:
> the non-negative number of array elements when deserializing an array of the class, otherwise -1
> 
> but currently returns a negative value if the array length is negative.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Fixed comment in 'buildPriorityQueuePayload()'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13540/files
  - new: https://git.openjdk.org/jdk/pull/13540/files/4762023a..e351073e

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

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

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

From shade at openjdk.org  Tue May  2 17:07:04 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 2 May 2023 17:07:04 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v4]
In-Reply-To: <uD_A_HqCbyYCyOffqEmAWOWfLK1O1uMcEW-1ZroZ2Q4=.6c9accf3-df67-4ae0-a3e9-1688a2e5a2cf@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <uD_A_HqCbyYCyOffqEmAWOWfLK1O1uMcEW-1ZroZ2Q4=.6c9accf3-df67-4ae0-a3e9-1688a2e5a2cf@github.com>
Message-ID: <p3N89VA4hBAxqCqXz390TUqONkkIAh8gK8nrCDykvPc=.60dccb47-ffc7-4430-8651-b61389b901d1@github.com>

On Tue, 2 May 2023 13:26:31 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Throw StreamCorruptedException instead of InvalidClassException and handle negative array size in checkArray() as well

`StreamCorruptedException` looks better. I have a few nitpicks.

test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 46:

> 44:     private static byte[] buildArrayPayload() throws IOException {
> 45:          // Serialize to bytes
> 46:         ByteArrayOutputStream baos = new ByteArrayOutputStream();

Suggestion:

    private static byte[] buildArrayPayload() throws IOException {
        // Serialize to bytes
        ByteArrayOutputStream baos = new ByteArrayOutputStream();

test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 106:

> 104: 
> 105:     public static void main(String[] args) throws Exception {
> 106:         try {

Test code nits, we can probably `try-with-resources` this thing to make it cleaner and make sure nothing unexpectedly bad is happening on "close" paths.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13540#pullrequestreview-1409425435
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1182757260
PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1182813958

From simonis at openjdk.org  Tue May  2 17:30:23 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 2 May 2023 17:30:23 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v4]
In-Reply-To: <p3N89VA4hBAxqCqXz390TUqONkkIAh8gK8nrCDykvPc=.60dccb47-ffc7-4430-8651-b61389b901d1@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <uD_A_HqCbyYCyOffqEmAWOWfLK1O1uMcEW-1ZroZ2Q4=.6c9accf3-df67-4ae0-a3e9-1688a2e5a2cf@github.com>
 <p3N89VA4hBAxqCqXz390TUqONkkIAh8gK8nrCDykvPc=.60dccb47-ffc7-4430-8651-b61389b901d1@github.com>
Message-ID: <siVCIp-M1_02xNeVbXj77rA-IA69litEcMX-pumjX10=.2fb82f1c-eca4-471f-84ab-0f41452530a6@github.com>

On Tue, 2 May 2023 16:06:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Throw StreamCorruptedException instead of InvalidClassException and handle negative array size in checkArray() as well
>
> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 46:
> 
>> 44:     private static byte[] buildArrayPayload() throws IOException {
>> 45:          // Serialize to bytes
>> 46:         ByteArrayOutputStream baos = new ByteArrayOutputStream();
> 
> Suggestion:
> 
>     private static byte[] buildArrayPayload() throws IOException {
>         // Serialize to bytes
>         ByteArrayOutputStream baos = new ByteArrayOutputStream();

You're right. An for some strange reason the same comment  in `buildPriorityQueuePayload()` is correctly indented but the following code was not. So fixed that as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1182841247

From simonis at openjdk.org  Tue May  2 18:02:41 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 2 May 2023 18:02:41 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v6]
In-Reply-To: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
Message-ID: <efpV0T3_1LhUOc_J1aZ1YfIFrTm-ZehOfgipyY2HhLs=.a25064c1-cfc3-443a-b85c-f4f35948d87b@github.com>

> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
> 
> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
> 
> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
> 
> Returns:
> the non-negative number of array elements when deserializing an array of the class, otherwise -1
> 
> but currently returns a negative value if the array length is negative.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Using try-with-resources and some formatting changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13540/files
  - new: https://git.openjdk.org/jdk/pull/13540/files/e351073e..da07109e

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

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

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

From simonis at openjdk.org  Tue May  2 18:02:45 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 2 May 2023 18:02:45 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v4]
In-Reply-To: <p3N89VA4hBAxqCqXz390TUqONkkIAh8gK8nrCDykvPc=.60dccb47-ffc7-4430-8651-b61389b901d1@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <uD_A_HqCbyYCyOffqEmAWOWfLK1O1uMcEW-1ZroZ2Q4=.6c9accf3-df67-4ae0-a3e9-1688a2e5a2cf@github.com>
 <p3N89VA4hBAxqCqXz390TUqONkkIAh8gK8nrCDykvPc=.60dccb47-ffc7-4430-8651-b61389b901d1@github.com>
Message-ID: <kNBz2tGcRro_8K3vLNloT-b3HJxdoXGx1Ds4iuifuGU=.f5c6f7ef-3845-49ff-89c7-249acef8e493@github.com>

On Tue, 2 May 2023 16:59:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Throw StreamCorruptedException instead of InvalidClassException and handle negative array size in checkArray() as well
>
> test/jdk/java/io/ObjectInputStream/NegativeArraySizeTest.java line 106:
> 
>> 104: 
>> 105:     public static void main(String[] args) throws Exception {
>> 106:         try {
> 
> Test code nits, we can probably `try-with-resources` this thing to make it cleaner and make sure nothing unexpectedly bad is happening on "close" paths.

OK, here we go...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13540#discussion_r1182871096

From jlu at openjdk.org  Tue May  2 18:34:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 2 May 2023 18:34:11 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v3]
In-Reply-To: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
Message-ID: <_KbXcqAr67ajBB1dGA4ers6_Sk9OhGk6O8uL3h_NzdE=.f6ba0b87-55b0-40e6-a4f8-8a025822244d@github.com>

> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
> 
> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
> 
> 
> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
> - Will not case fold variant subtags
> - Will not case fold private use subtags prefixed by "lvariant"
> 
> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.

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

  Add distinction between legacy and grandfathered to spec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13679/files
  - new: https://git.openjdk.org/jdk/pull/13679/files/91e84efe..63fe500e

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

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

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

From joehw at openjdk.org  Tue May  2 19:17:14 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 2 May 2023 19:17:14 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v10]
In-Reply-To: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
Message-ID: <wYLd3jCZg01iNxcb_b6T9VxiQygNffYdNBul56V_JBg=.1a9afb05-620c-4e27-b71c-5d4dc900fa8d@github.com>

> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8303531
> 
> Tests: XML SQE and JCK tests passed.

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

  update to address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12985/files
  - new: https://git.openjdk.org/jdk/pull/12985/files/5f889bb9..e5119fd0

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

  Stats: 101 lines in 4 files changed: 34 ins; 30 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/12985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12985/head:pull/12985

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

From smarks at openjdk.org  Tue May  2 19:23:16 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 2 May 2023 19:23:16 GMT
Subject: RFR: 8302496: Runtime.exit incorrectly says it never throws an
 exception [v3]
In-Reply-To: <IZXu79UTL_G1cCjXD0Oq-mjSzaekfLrGHCh6WX8PV6s=.4a14d52e-3a23-4ea0-adca-b0a79028e6e9@github.com>
References: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
 <mcYJ87l7vwNQXgnuS_yrogBpkPd7evL7RE2IgzeEIjg=.62fc4420-b207-4b42-bd5c-e0e49c7d60fd@github.com>
 <IZXu79UTL_G1cCjXD0Oq-mjSzaekfLrGHCh6WX8PV6s=.4a14d52e-3a23-4ea0-adca-b0a79028e6e9@github.com>
Message-ID: <d9s8L-1ThLglZU_LIpzgBDCbdZ7eXLGaZjRR9Xqhzo0=.77bde6c3-cf00-4a2a-9afb-036c4f9cdedb@github.com>

On Tue, 2 May 2023 06:04:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update Runtime.halt.
>
> Updated version, and the wording of halt's description, looks okay.

@AlanBateman Great. Can you take a look at the CSR [JDK-8307081](https://bugs.openjdk.org/browse/JDK-8307081) as well? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13706#issuecomment-1532020349

From jrose at openjdk.org  Tue May  2 19:26:20 2023
From: jrose at openjdk.org (John R Rose)
Date: Tue, 2 May 2023 19:26:20 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v11]
In-Reply-To: <KpQ5T-5hYCba5WSvC2Fwe7r6j9ct8_6OPMv9l9kgOEk=.16e6acf3-fa8a-4000-8142-1ca5b58c56c0@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
 <gEXReveQQhF6qnmA3qrCTacfm7s00WrkMG4BpeJwPhI=.1192dd8c-1d83-41dd-b6b2-886a5939154b@github.com>
 <KpQ5T-5hYCba5WSvC2Fwe7r6j9ct8_6OPMv9l9kgOEk=.16e6acf3-fa8a-4000-8142-1ca5b58c56c0@github.com>
Message-ID: <Q6lqx1tAWrbZN-qfQFrRo-mgaUHxD5ccgKyiZG1d1nY=.f13421a4-d410-40ef-9dcd-7a5da7a4ec8c@github.com>

On Mon, 1 May 2023 22:23:11 GMT, Chen Liang <liach at openjdk.org> wrote:

> It had an invocation performance of 2ns/op as opposed to Proxy's 6ns/op, but the condy implementation has 0.41ns/op.

Good, so let?s take the win relative to 6ns/op metric.

The condy implementation devotes a whole class to a single MH, so it can go faster.  But if you use more than exactly one MH, the extra classes will pollute the same type profiles that provide 0.41ns/op, if you use more than one MH.  I think that?s too brittle a performance curve.  Let?s be more economical with our spinning of classes.  That should provide a smoother performance curve (scaling towards use cases with more receivers) and (with fewer, more regular classes, with no class-data) be more friendly to Leyden as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1532025066

From joehw at openjdk.org  Tue May  2 19:30:27 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 2 May 2023 19:30:27 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v9]
In-Reply-To: <tii6-GGgEZTZiTOmh83uN4qrUaK1WXvmJJTfxD5oHvA=.e3048ff2-e0e6-4f3f-b1fd-8533ce5264ab@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <w_VQMDXdJScfmyacC0Mxsq4ZshVvw8vLNEcw62YbH1I=.4296584d-da35-4b67-8914-ac26aeef1873@github.com>
 <tii6-GGgEZTZiTOmh83uN4qrUaK1WXvmJJTfxD5oHvA=.e3048ff2-e0e6-4f3f-b1fd-8533ce5264ab@github.com>
Message-ID: <5xZSLQcCJqMOwtUwEgxOqjg13QYOEnp_HS1iFKWnVZQ=.89beff60-235d-4e6a-bdd6-9dfafe20d4a1@github.com>

On Sun, 30 Apr 2023 07:27:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8303530
>>  - Update based on the review meeting on 4/5. Added (duplicated) definitions in jaxp.properties; Rewrote Property Precedence with samples; Other updates.
>>  - update javadoc as discussed in the review meeting; add a sample configuration file jaxp.properties; update impl and tests accordingly.
>>  - continue support stax.properties at the impl level, though dropped from the spec
>>  - change prefix from jdk to java
>>  - change prefix from jdk to java; rm zip file that accidentally checked in
>>  - update config file description; add a general scope and order section; move value definition for external properties to class description
>>  - clean up tests; fix copy&paste error.
>>  - 8303530: Add system property for custom JAXP configuration file
>
> src/java.xml/share/classes/module-info.java line 61:
> 
>> 59:  * By default, the <a href="#Factories">JAXP Factories</a> will look for a
>> 60:  * configuration file called {@code jaxp.properties} in the {@code conf} directory
>> 61:  * of the Java installation and use the entries if any to customize the behavior
> 
> "of the Java installation" should probably say the run-time image, or maybe just change this to use ${java.home}/conf as it is used in other API docs.

changed to ${java.home}/conf

> src/java.xml/share/classes/module-info.java line 74:
> 
>> 72:  * <h3 id="CF_SP">User-defined Configuration File</h3>
>> 73:  * A user-defined configuration file can be set outside of the JDK by using the
>> 74:  * system property {@code java.xml.config.file}.
> 
> "can be set out of the JDK" needs to be re-phrased. Maybe this sentence can be restructured to say that a system property can be set on the command line to specify the location of a configuration file on the file system. Adding "command line" would be helpful because "system property" is too overloaded in these docs.

Updated. Note it can also be set through the System API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1182965219
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1182965936

From joehw at openjdk.org  Tue May  2 19:30:19 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 2 May 2023 19:30:19 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v9]
In-Reply-To: <fnyLl2iOgGVDKb12U9zrej7-SEjK2_RxYAdW2jeucA8=.4b8ea8d9-a305-40a5-8c1b-4fbf2429aa7b@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <w_VQMDXdJScfmyacC0Mxsq4ZshVvw8vLNEcw62YbH1I=.4296584d-da35-4b67-8914-ac26aeef1873@github.com>
 <tii6-GGgEZTZiTOmh83uN4qrUaK1WXvmJJTfxD5oHvA=.e3048ff2-e0e6-4f3f-b1fd-8533ce5264ab@github.com>
 <fnyLl2iOgGVDKb12U9zrej7-SEjK2_RxYAdW2jeucA8=.4b8ea8d9-a305-40a5-8c1b-4fbf2429aa7b@github.com>
Message-ID: <1I219vxR0joKlSO2Yo3sPEzrD29mWoh_xSYcC2UTiLU=.81ad6084-e199-459d-8399-ce38e7e10ef1@github.com>

On Sun, 30 Apr 2023 07:53:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.xml/share/classes/module-info.java line 33:
>> 
>>> 31:  * JAXP supports the use of a configuration file for the
>>> 32:  * <a href="#LookupMechanism">Factory Lookup Mechanism</a> and
>>> 33:  * setting properties that have defined corresponding system properties.
>> 
>> The first sentence of the module description lists the 4 XML APIs and their acronyms. It is immediately followed by a section with title "JAXP Configuration File" which suggests that this is a configuration file for the first API that is listed (JAXP). As I understand it, properties for the streaming API can also be defined in this file. So it might be that a bit more setup is needed in the opening text to make it clearer that this is the configuration file for all of the APIs.
>
> One other thing to say on this is that jaxp.properties has "XML Library (java.xml) Configuration File" at the top of the file, maybe that could be used in the module description instead of "JAXP Configuration File".

Changed the opening statement and also the naming of config file as above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1182964917

From joehw at openjdk.org  Tue May  2 19:33:21 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 2 May 2023 19:33:21 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v9]
In-Reply-To: <tii6-GGgEZTZiTOmh83uN4qrUaK1WXvmJJTfxD5oHvA=.e3048ff2-e0e6-4f3f-b1fd-8533ce5264ab@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <w_VQMDXdJScfmyacC0Mxsq4ZshVvw8vLNEcw62YbH1I=.4296584d-da35-4b67-8914-ac26aeef1873@github.com>
 <tii6-GGgEZTZiTOmh83uN4qrUaK1WXvmJJTfxD5oHvA=.e3048ff2-e0e6-4f3f-b1fd-8533ce5264ab@github.com>
Message-ID: <88Dh8Bx6CSBRb7iFYCcsXnO-Ky1GOix_5hLkAxok9X4=.df8a8d0f-189b-46a7-9a8b-242a0d7516dd@github.com>

On Sun, 30 Apr 2023 07:40:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8303530
>>  - Update based on the review meeting on 4/5. Added (duplicated) definitions in jaxp.properties; Rewrote Property Precedence with samples; Other updates.
>>  - update javadoc as discussed in the review meeting; add a sample configuration file jaxp.properties; update impl and tests accordingly.
>>  - continue support stax.properties at the impl level, though dropped from the spec
>>  - change prefix from jdk to java
>>  - change prefix from jdk to java; rm zip file that accidentally checked in
>>  - update config file description; add a general scope and order section; move value definition for external properties to class description
>>  - clean up tests; fix copy&paste error.
>>  - 8303530: Add system property for custom JAXP configuration file
>
> src/java.xml/share/classes/module-info.java line 264:
> 
>> 262:  * </li>
>> 263:  * <li><p>
>> 264:  *      Properties set using the corresponding System properties;
> 
> Can you confirm that this means system properties set on the command line with -Dkey=value or System.setProperty(key, value)?  
> 
> (I understand that the catalog feature "RESOLVE" property helps to explain it but I'm concerned that "system property" is ambiguous throughout).

Yes. Took it as granted "system property" is well-understood. If it can still be confusing, added a section "Properties and System Properties" to make it clearer what "system property" meant throughout the document.

> src/java.xml/share/classes/module-info.java line 332:
> 
>> 330:  * @implNote
>> 331:  *
>> 332:  * <h2 id="ConfigurationFile">JAXP Configuration File</h2>
> 
> I thin this means there are two anchors with the same name and two sections in the module description with the same title. I understand this is SE vs. JDK specific properties but this could easily go over the headers of someone reading this. I think it would be better if "Implementation Specific Features and Properties" were the first section of the implNote. It can start by saying that the JAXP Configuration file (link to the description at the top) can also be used for JDK/implementation specific properties.

Removed. Incorporated with the sub-section "configuration file" within the "Implementation Specific Features and Properties" section.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1182968075
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1182968959

From joehw at openjdk.org  Tue May  2 19:39:17 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 2 May 2023 19:39:17 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v9]
In-Reply-To: <PFk-zQYQzdekhawmb67jT4W-J6Yn-qPaZJD5GD2SoQE=.437a18f0-b8cc-45a2-8399-b0c4fc8c4403@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <w_VQMDXdJScfmyacC0Mxsq4ZshVvw8vLNEcw62YbH1I=.4296584d-da35-4b67-8914-ac26aeef1873@github.com>
 <PFk-zQYQzdekhawmb67jT4W-J6Yn-qPaZJD5GD2SoQE=.437a18f0-b8cc-45a2-8399-b0c4fc8c4403@github.com>
Message-ID: <1uxfst2LaLunDgp0QtY57ipKsqdGT0Djw6nJYWDnfxY=.ce42390b-c360-43ce-b54e-4ca326d27bc8@github.com>

On Mon, 1 May 2023 18:25:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Regarding the new unit tests, it looks like there are a lot of boilerplate codes. Can they be shared?

Multiple tests per a processor, and separate test per each processor, if that's what you meant, they unfortunately can not be run within one test since the config file is defined to be loaded once only.

> src/java.xml/share/classes/jdk/xml/internal/SecuritySupport.java line 234:
> 
>> 232:                     }
>> 233:                     firstTimeCustom = false;
>> 234:                 }
> 
> Is it possible if `firstTime` and `firstTimeCustom` differ? Would it be possible to get rid of `firstTimeCustom` and move this piece into `firstTime` block?

Removed firstTimeCustom and related code. Also reversed the order of stax and jaxp.properties as we're making jaxp.properties the preferred one.

> src/java.xml/share/classes/jdk/xml/internal/SecuritySupport.java line 253:
> 
>> 251:                 return true;
>> 252:             } catch (IOException e) {
>> 253:                 // ignore file not found error
> 
> How could "file not found" occur assuming `SecuritySupport.doesFileExist(f)` returns true?

Changed the comment. Yeah, it's not possible, a try block was needed only because a method called required it.

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

PR Comment: https://git.openjdk.org/jdk/pull/12985#issuecomment-1532038269
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1182972527
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1182973569

From emcmanus at openjdk.org  Tue May  2 19:54:14 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Tue, 2 May 2023 19:54:14 GMT
Subject: RFR: 8303919: Instant.ofEpochMilli says it can throw an exception
 that it can't [v2]
In-Reply-To: <KZTI-vNW52nDDiFr1qtbUBxKGGr6To04RWa7PMpcIjU=.38d302c5-15d6-446e-97d0-6f87f7ff0f77@github.com>
References: <KZTI-vNW52nDDiFr1qtbUBxKGGr6To04RWa7PMpcIjU=.38d302c5-15d6-446e-97d0-6f87f7ff0f77@github.com>
Message-ID: <4hSmM2ZdnTq8PeWyS0_R1WTFiffCy-8o1m2Bgo_epkg=.07d5f58f-ded7-4fc1-8559-57e44976e05e@github.com>

> Instant.ofEpochMilli says this:
> 
> 
> @throws DateTimeException if the instant exceeds the maximum or minimum instant
> 
> 
> But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE` it does not throw. That's already implicitly tested in [`TestInstant`](https://github.com/openjdk/jdk/blob/a9dba565688a29bef8626488c47519008dcadbe8/test/jdk/java/time/test/java/time/TestInstant.java#L84), which calls it with both those values.

Eamonn McManus has updated the pull request with a new target base 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 ofepochmilli
 - 8303919: Instant.ofEpochMilli javadoc bug
   
   Instant.ofEpochMilli says this:
   
   ```
   @throws DateTimeException if the instant exceeds the maximum or minimum instant
   ```
   
   But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE`
   it does not throw. That's already implicitly tested in
   [`TestInstant`](https://github.com/openjdk/jdk/blob/a9dba565688a29bef8626488c47519008dcadbe8/test/jdk/java/time/test/java/time/TestInstant.java#L84),
   which calls it with both those values.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12958/files
  - new: https://git.openjdk.org/jdk/pull/12958/files/a902d216..4ef7b053

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

  Stats: 437214 lines in 4534 files changed: 333479 ins; 64197 del; 39538 mod
  Patch: https://git.openjdk.org/jdk/pull/12958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12958/head:pull/12958

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

From joehw at openjdk.org  Tue May  2 20:16:15 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 2 May 2023 20:16:15 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v11]
In-Reply-To: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
Message-ID: <qI282STKG_sL2MFdI-DYw9NP0P2-veK7mkNWmfenQhc=.9f72d3de-acc9-464f-a08d-e9b9c02eac9a@github.com>

> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8303531
> 
> Tests: XML SQE and JCK tests passed.

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

  address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12985/files
  - new: https://git.openjdk.org/jdk/pull/12985/files/e5119fd0..474d3470

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=09-10

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

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

From joehw at openjdk.org  Tue May  2 20:16:24 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 2 May 2023 20:16:24 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v9]
In-Reply-To: <tii6-GGgEZTZiTOmh83uN4qrUaK1WXvmJJTfxD5oHvA=.e3048ff2-e0e6-4f3f-b1fd-8533ce5264ab@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <w_VQMDXdJScfmyacC0Mxsq4ZshVvw8vLNEcw62YbH1I=.4296584d-da35-4b67-8914-ac26aeef1873@github.com>
 <tii6-GGgEZTZiTOmh83uN4qrUaK1WXvmJJTfxD5oHvA=.e3048ff2-e0e6-4f3f-b1fd-8533ce5264ab@github.com>
Message-ID: <0cpMgITY9xAf529rcqRf5JdiqS89HtPBz3Jza4x1dT4=.0da865d1-7b86-4eb4-9e81-67cc7235b7b8@github.com>

On Sun, 30 Apr 2023 07:37:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Wang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8303530
>>  - Update based on the review meeting on 4/5. Added (duplicated) definitions in jaxp.properties; Rewrote Property Precedence with samples; Other updates.
>>  - update javadoc as discussed in the review meeting; add a sample configuration file jaxp.properties; update impl and tests accordingly.
>>  - continue support stax.properties at the impl level, though dropped from the spec
>>  - change prefix from jdk to java
>>  - change prefix from jdk to java; rm zip file that accidentally checked in
>>  - update config file description; add a general scope and order section; move value definition for external properties to class description
>>  - clean up tests; fix copy&paste error.
>>  - 8303530: Add system property for custom JAXP configuration file
>
> src/java.xml/share/classes/module-info.java line 257:
> 
>> 255:  * the {@link javax.xml.XMLConstants#FEATURE_SECURE_PROCESSING FEATURE_SECURE_PROCESSING}
>> 256:  * (hereafter referred to FSP), and the default values. The order of precedence
>> 257:  * for the configuration sources is defined as follows, with earlier ones overriding the later:
> 
> "using the API properties" is bit confusing. I think you mean that properties can be set via the APIs. 
> 
> ".. and the default values". I think it would be clearer to say that properties have default values when not set by previous four ways.

Updated accordingly in additional commits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1183005119

From naoto at openjdk.org  Tue May  2 20:28:22 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 2 May 2023 20:28:22 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v3]
In-Reply-To: <_KbXcqAr67ajBB1dGA4ers6_Sk9OhGk6O8uL3h_NzdE=.f6ba0b87-55b0-40e6-a4f8-8a025822244d@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <_KbXcqAr67ajBB1dGA4ers6_Sk9OhGk6O8uL3h_NzdE=.f6ba0b87-55b0-40e6-a4f8-8a025822244d@github.com>
Message-ID: <uwvlNKFjdHtV7Ux6lQhlPZcFUzqWBDcZ6UxKRT87q5g=.2e5688be-dc4e-4115-b6f0-c5df3accbdb7@github.com>

On Tue, 2 May 2023 18:34:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
>> 
>> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
>> 
>> 
>> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
>> - Will not case fold variant subtags
>> - Will not case fold private use subtags prefixed by "lvariant"
>> 
>> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add distinction between legacy and grandfathered to spec

Looks good. Some minor comments follow:

src/java.base/share/classes/java/util/Locale.java line 1809:

> 1807:      * <p>Legacy tags with canonical replacements are as follows:
> 1808:      *
> 1809:      * <table class="striped" id="legacy_tags_replacement">

Maybe `id="legacy_tags` attribute added to the above paragraph that starts with "This implements..." is clearer.

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 415:

> 413:         // Illegal tags
> 414:         if (!parse(tag, null).wellFormed) {
> 415:             throw new IllformedLocaleException("Ill formed tag");

May include additional information by providing `sts` and retrieving the info from it.

test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 48:

> 46:  * grandfathered, and irregular. For more info, see the following,
> 47:  * <a href="https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1">Tag Syntax</a>).
> 48:  * In addition, the method is tested to ensure that IllegalArgumentException and

`IllformedLocaleException`?

test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 55:

> 53:     @ParameterizedTest
> 54:     @MethodSource("wellFormedTags")
> 55:     public void TestWellFormedTags(String tag, String foldedTag) {

Nit: method name should start with a lowercase char

test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 56:

> 54:     @MethodSource("wellFormedTags")
> 55:     public void TestWellFormedTags(String tag, String foldedTag) {
> 56:         assertEquals(foldedTag, Locale.caseFoldLanguageTag(tag), String.format("Folded %s", tag));

Would it be helpful if both the expected and the result are recorded?

test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 65:

> 63:             Locale.caseFoldLanguageTag(tag);
> 64:             throw new RuntimeException("$$$ Failure: ill formed tags should throw IAE");
> 65:         } catch (IllegalArgumentException ignored) {}

`IllformedLocaleException`? Or if the test passes with this version of impl, should the test throw an RuntimeException? Also instead of try-catch, `assertThrows()` can be used.

test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 72:

> 70:         try {
> 71:             Locale.caseFoldLanguageTag(null);
> 72:             throw new RuntimeException("$$$ Failure: NPE should be thrown when tag is null");

`assertThrows()` can be used here as well

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

PR Review: https://git.openjdk.org/jdk/pull/13679#pullrequestreview-1409713684
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1182938431
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1182940287
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1182943088
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183004084
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183002010
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183006073
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183013804

From liach at openjdk.org  Tue May  2 21:05:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 May 2023 21:05:29 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v11]
In-Reply-To: <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <F3ZPenxUflPuB6QkDeZk38gpc35TMlbNER2hZfFISCc=.69b6dd37-9c2f-49f8-ae1a-5e36ecff43bb@github.com>
Message-ID: <3a9zwhU_m1v5aRcTL6ww9pvkjNQkbxua00NLqUshvU4=.67664502-7d80-406e-aca0-da9393c7ec93@github.com>

On Mon, 1 May 2023 14:56:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with a check to the class data. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 24 additional commits since the last revision:
> 
>  - Renames
>  - Merge branch 'master' into explore/mhp-iface
>  - Consolidate iteration over public methods
>  - Define MH proxy class in a dynamic module
>  - Fix test that depend on WrapperInstance
>  - Require an original lookup in constructor arguments to prevent unintended instantiation
>  - pass interface info via condy,
>    drop explicit ea flags
>    initialize benchmark work variable randomly
>    benchmarks just need 1 fork
>  - Nuke WrapperInstance
>  - Merge branch 'master' into explore/mhp-iface
>  - Whitespace, cleanup, rename benchmarks to be informative
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/a52adfb8...f5d0ef0a

1. About moving the checker method to another existing class: Security Manager denies calls to conditionally-exported java.base internal packages, should I spin a utility class in a new module on initialization and export that module to the generated proxy classes, or pass a live methodhandle to the validation method to the class?
2. Another question for Project Leyden: does it aim to further reduce the number of LambdaForm-compiled invoker classes generated as well, especially customized LambdaForms?

I think I will try add a benchmark that measures the cold-start and creation performance for the proxies, especially for the shared-class implementation; at least the proxy-based implementation has negligible creation performance compared to the dedicated-class implementation last I tested. Also as a side note, class definition does bring a huge creation-time overhead: it takes 25000 ns to create a dedicated instance, but only 20ns to create a shared instance. The dedicated-class implementation has no advantage besides the blazingly-fast invocation performance for non-constant instances.

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1532146903

From liach at openjdk.org  Tue May  2 21:22:16 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 2 May 2023 21:22:16 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v12]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <tLyEmO003UOcRBn2MnpkWjm2acr_8pJ8c5N7w6JQbHg=.ff06b695-6256-4e5d-984f-b9f1b0f93aee@github.com>

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with a check to the class data. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> [^1]: single abstract method

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Minor cleanup, attempt to migrate lookup validation blocked by security manager

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/f5d0ef0a..27dc803d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=10-11

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

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

From forax at openjdk.org  Tue May  2 21:28:24 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 2 May 2023 21:28:24 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v12]
In-Reply-To: <tLyEmO003UOcRBn2MnpkWjm2acr_8pJ8c5N7w6JQbHg=.ff06b695-6256-4e5d-984f-b9f1b0f93aee@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <tLyEmO003UOcRBn2MnpkWjm2acr_8pJ8c5N7w6JQbHg=.ff06b695-6256-4e5d-984f-b9f1b0f93aee@github.com>
Message-ID: <kW10sCpi49zJwfaGLyTQ70AnuIX4NrFguMRpb4OQ1Ns=.30436393-9c00-47a1-85d3-9b4105dcccf1@github.com>

On Tue, 2 May 2023 21:22:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with a check to the class data. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup, attempt to migrate lookup validation blocked by security manager

I disagree for two reasons
- the first is inlining, 2ns/op vs 6ns/op is not very relevant, what is relevant is that in case you have full inlining of the callee inside the caller code and not in the other case. As Cliff Click said, inlining is the mother of all optimizations, without inlining there is a bunch of other optimizations that can not be applied. Moreover, in a lot of cases where proxies are used (Spring, CDI, Logger, etc), proxies are composed, if each call through a proxy is not inlined the performance difference is massive.
- second is control, as a user i've the control on the profile pollution that occurs because of the use of the proxy interface while i've no control on the profile pollution dues to the proxy implementation which depend on how others parts / libraries of the application are also using proxies.

And I don't buy the Leyden argument, the condensers of Leyden act at jlink time. A condenser is free to use a different strategy or not that the one used at runtime. Currently, GraalVM AOT, the closest existing thing to Leyden is using two entrypoints, one for the classical JDK and one for Graal AOT. Why not using the two entrypoints strategy for MHProxies.asInterfaceInstance() when Leyden will be implemented ?

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1532173983

From jlu at openjdk.org  Tue May  2 21:42:09 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 2 May 2023 21:42:09 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v4]
In-Reply-To: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
Message-ID: <JqYHi4dOGc0oRt20NEND3YoDlNQ8kL6lldvfwtSax5Y=.781701ae-d52c-44c4-88a0-8a075cfb7465@github.com>

> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
> 
> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
> 
> 
> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
> - Will not case fold variant subtags
> - Will not case fold private use subtags prefixed by "lvariant"
> 
> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.

Justin Lu has updated the pull request incrementally with four additional commits since the last revision:

 - Review comment: Replace wellFormed with parseSts to pass errorMsg to exception
 - Review comment: Adjust method names
 - Review comment: Use assertThrows and correct IAE to ILE
 - Review comment: improve legacy_tags id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13679/files
  - new: https://git.openjdk.org/jdk/pull/13679/files/63fe500e..34ccd3be

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

  Stats: 27 lines in 3 files changed: 5 ins; 7 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13679/head:pull/13679

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

From jlu at openjdk.org  Tue May  2 21:42:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 2 May 2023 21:42:14 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v3]
In-Reply-To: <uwvlNKFjdHtV7Ux6lQhlPZcFUzqWBDcZ6UxKRT87q5g=.2e5688be-dc4e-4115-b6f0-c5df3accbdb7@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <_KbXcqAr67ajBB1dGA4ers6_Sk9OhGk6O8uL3h_NzdE=.f6ba0b87-55b0-40e6-a4f8-8a025822244d@github.com>
 <uwvlNKFjdHtV7Ux6lQhlPZcFUzqWBDcZ6UxKRT87q5g=.2e5688be-dc4e-4115-b6f0-c5df3accbdb7@github.com>
Message-ID: <JXDGHb8J5cPDu9NLp10-nWBGJTFCSJWVJP_Jk0OLZ_I=.1c4873cc-eb19-423c-8aa7-ee178c1ad1ea@github.com>

On Tue, 2 May 2023 18:59:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add distinction between legacy and grandfathered to spec
>
> src/java.base/share/classes/java/util/Locale.java line 1809:
> 
>> 1807:      * <p>Legacy tags with canonical replacements are as follows:
>> 1808:      *
>> 1809:      * <table class="striped" id="legacy_tags_replacement">
> 
> Maybe `id="legacy_tags` attribute added to the above paragraph that starts with "This implements..." is clearer.

Thanks for the review and helpful comments, I have addressed this comment and the other ones you left.

> src/java.base/share/classes/sun/util/locale/LanguageTag.java line 415:
> 
>> 413:         // Illegal tags
>> 414:         if (!parse(tag, null).wellFormed) {
>> 415:             throw new IllformedLocaleException("Ill formed tag");
> 
> May include additional information by providing `sts` and retrieving the info from it.

Good point, I have updated it so that it provides the sts error message with the exception.

For example,
`Ill formed tag: Invalid subtag: xabadadoo`

> test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 56:
> 
>> 54:     @MethodSource("wellFormedTags")
>> 55:     public void TestWellFormedTags(String tag, String foldedTag) {
>> 56:         assertEquals(foldedTag, Locale.caseFoldLanguageTag(tag), String.format("Folded %s", tag));
> 
> Would it be helpful if both the expected and the result are recorded?

Junit assertEquals provides the actual result in the failure, so no need to record it.

Example failure:
`org.opentest4j.AssertionFailedError: Folded ABC ==> expected: <ab> but was: <abc>`

> test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 65:
> 
>> 63:             Locale.caseFoldLanguageTag(tag);
>> 64:             throw new RuntimeException("$$$ Failure: ill formed tags should throw IAE");
>> 65:         } catch (IllegalArgumentException ignored) {}
> 
> `IllformedLocaleException`? Or if the test passes with this version of impl, should the test throw an RuntimeException? Also instead of try-catch, `assertThrows()` can be used.

The test does not pass like this, I had forgotten to re run the test after originally switching IAE to IFE in the method itself. (and hence why I did not catch that it is not updated in the test). 

I have switched all the IAE to IFE in the test, and also used assertThrows() as recommended

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183074736
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183074304
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183074241
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183074141

From rriggs at openjdk.org  Tue May  2 21:46:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 2 May 2023 21:46:18 GMT
Subject: RFR: 8303919: Instant.ofEpochMilli says it can throw an exception
 that it can't [v2]
In-Reply-To: <4hSmM2ZdnTq8PeWyS0_R1WTFiffCy-8o1m2Bgo_epkg=.07d5f58f-ded7-4fc1-8559-57e44976e05e@github.com>
References: <KZTI-vNW52nDDiFr1qtbUBxKGGr6To04RWa7PMpcIjU=.38d302c5-15d6-446e-97d0-6f87f7ff0f77@github.com>
 <4hSmM2ZdnTq8PeWyS0_R1WTFiffCy-8o1m2Bgo_epkg=.07d5f58f-ded7-4fc1-8559-57e44976e05e@github.com>
Message-ID: <aly3begEJ7F82pKyjnV2oXGORXUmpRYwIk7jRjSK_io=.b172e57c-a0c6-4940-8d2e-814dadf74152@github.com>

On Tue, 2 May 2023 19:54:14 GMT, Eamonn McManus <emcmanus at openjdk.org> wrote:

>> Instant.ofEpochMilli says this:
>> 
>> 
>> @throws DateTimeException if the instant exceeds the maximum or minimum instant
>> 
>> 
>> But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE` it does not throw. That's already implicitly tested in [`TestInstant`](https://github.com/openjdk/jdk/blob/a9dba565688a29bef8626488c47519008dcadbe8/test/jdk/java/time/test/java/time/TestInstant.java#L84), which calls it with both those values.
>
> Eamonn McManus has updated the pull request with a new target base 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 ofepochmilli
>  - 8303919: Instant.ofEpochMilli javadoc bug
>    
>    Instant.ofEpochMilli says this:
>    
>    ```
>    @throws DateTimeException if the instant exceeds the maximum or minimum instant
>    ```
>    
>    But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE`
>    it does not throw. That's already implicitly tested in
>    [`TestInstant`](https://github.com/openjdk/jdk/blob/a9dba565688a29bef8626488c47519008dcadbe8/test/jdk/java/time/test/java/time/TestInstant.java#L84),
>    which calls it with both those values.

Looks good to me.  Thanks

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12958#pullrequestreview-1409931977

From smarks at openjdk.org  Tue May  2 23:22:27 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 2 May 2023 23:22:27 GMT
Subject: Integrated: 8302496: Runtime.exit incorrectly says it never throws an
 exception
In-Reply-To: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
References: <Idv-y5y7g1Eh92gXWdnLUcmj4qHqjd4oY0m_V0JgOOs=.72594a6e-06d0-47c2-846b-95bc2b7687af@github.com>
Message-ID: <qcSslAYua27Sf_wz3Y3UiyrsJVyY6JWsritxDxG8lm0=.6ba37a94-54cd-41d2-a699-08c61b708873@github.com>

On Thu, 27 Apr 2023 23:06:42 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Textual specification clarifications.

This pull request has now been integrated.

Changeset: 05b9b582
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05b9b5821db0e0d5d998a1bd8574aa6021878c9e
Stats:     32 lines in 2 files changed: 6 ins; 2 del; 24 mod

8302496: Runtime.exit incorrectly says it never throws an exception

Reviewed-by: alanb

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

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

From emcmanus at openjdk.org  Tue May  2 23:29:20 2023
From: emcmanus at openjdk.org (Eamonn McManus)
Date: Tue, 2 May 2023 23:29:20 GMT
Subject: Integrated: 8303919: Instant.ofEpochMilli says it can throw an
 exception that it can't
In-Reply-To: <KZTI-vNW52nDDiFr1qtbUBxKGGr6To04RWa7PMpcIjU=.38d302c5-15d6-446e-97d0-6f87f7ff0f77@github.com>
References: <KZTI-vNW52nDDiFr1qtbUBxKGGr6To04RWa7PMpcIjU=.38d302c5-15d6-446e-97d0-6f87f7ff0f77@github.com>
Message-ID: <wVOLyUOC32B3PVFw32YYGSscWyZ93ptBL20t-sIVDrU=.46f0ff87-7b60-4267-bfa2-1208fe6314be@github.com>

On Thu, 9 Mar 2023 19:49:29 GMT, Eamonn McManus <emcmanus at openjdk.org> wrote:

> Instant.ofEpochMilli says this:
> 
> 
> @throws DateTimeException if the instant exceeds the maximum or minimum instant
> 
> 
> But that can't happen. Even given `Long.MIN_VALUE` or `Long.MAX_VALUE` it does not throw. That's already implicitly tested in [`TestInstant`](https://github.com/openjdk/jdk/blob/a9dba565688a29bef8626488c47519008dcadbe8/test/jdk/java/time/test/java/time/TestInstant.java#L84), which calls it with both those values.

This pull request has now been integrated.

Changeset: 74667e3d
Author:    Eamonn McManus <emcmanus at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74667e3d56a0e6780363359b69007770f5678d8e
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8303919: Instant.ofEpochMilli says it can throw an exception that it can't

Reviewed-by: rriggs

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

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

From rriggs at openjdk.org  Wed May  3 00:45:11 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 3 May 2023 00:45:11 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage
Message-ID: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>

Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.

It is recommended to remove os version checks that apply only to Mac versions before 10.15.
Mac OS X 10.15 is the oldest version supported.

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

Commit messages:
 - Merge branch 'master' into 8304914-os-jpackage
 - Merge branch '8306678-os-version' into 8304914-os-jpackage
 - Merge branch '8304915-arch-enum' into 8306678-os-version
 - Correct comment on isPPC64() and refer to isLittleEndian() instead of mentioning PPC64LE
 - Simplify initialization in ClassLoaderHelper and fix VersionTest.
 - Revert changes to MacOsX sun.nio.fs.BsdFileStore; the version check is being removed in another PR.
 - Review comment updates
 - 8304914: Use OperatingSystem, Architecture, and Version in jpackage
 - In jdk.jpackage replace Platform with OperatingSystem and Architecture
 - Simplify exception handling
 - ... and 21 more: https://git.openjdk.org/jdk/compare/561ec9c5...505ad721

Changes: https://git.openjdk.org/jdk/pull/13586/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13586&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304914
  Stats: 237 lines in 23 files changed: 41 ins; 132 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/13586.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13586/head:pull/13586

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

From dholmes at openjdk.org  Wed May  3 02:13:19 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 May 2023 02:13:19 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v12]
In-Reply-To: <8Ak5D6_aeb2o7uOQKF3TZMQsgcA-gCDniHnI-7ZWnMs=.371ccce9-902e-4a03-a7c7-efe4907693fe@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <PVpzrnUNYUw9j-v5-l6-V_10Que9IXNlsXhcEuiXP-A=.22b21bed-b619-4a84-b737-9ac46d34374c@github.com>
 <8Ak5D6_aeb2o7uOQKF3TZMQsgcA-gCDniHnI-7ZWnMs=.371ccce9-902e-4a03-a7c7-efe4907693fe@github.com>
Message-ID: <3gqRFtwQcW6Ow0F63J_UMg1GvDP47feo2h8xiPbs9P8=.dd2f3429-f288-4e33-9859-239c501c2181@github.com>

On Thu, 27 Apr 2023 09:40:46 GMT, Aleksey Shipilev <shade 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 26 commits:
>> 
>>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>>  - Fix Amazon copyright
>>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>>  - Drop nanos_to_nanos_bounded
>>  - Handle overflows
>>  - More review comments
>>  - Adjust test times
>>  - Windows again
>>  - Windows fixes: align(...) is only for power-of-two alignments
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/35e7bc21...da8f0f8c
>
> All right, thank you all! 
> I plan to integrate this some time today/tomorrow.

@shipilev - did this slip off the radar? :)

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

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1532373001

From jiangli at openjdk.org  Wed May  3 02:16:08 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 02:16:08 GMT
Subject: RFR: 8307194: Enhance static-libs-image
Message-ID: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>

This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries:

- Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib';
- For libjvm.a specifically, exclude operator_new.o;
- Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files;
- Handle long arguments case for static build in make/common/NativeCompilation.gmk;
- Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS;

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

Commit messages:
 - Remove unused $$($1_EXTRA_ARGS) from DeclareHotspotLibsRecipe.
 - 8307194: Enhance static-libs-image

Changes: https://git.openjdk.org/jdk/pull/13768/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307194
  Stats: 146 lines in 6 files changed: 100 ins; 34 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/13768.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768

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

From jiangli at openjdk.org  Wed May  3 02:18:17 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 02:18:17 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
 [v2]
In-Reply-To: <WJrg2ht4gDlj8g3hH8pyGgd5iS7RvVnr26RxZCCm5ds=.d531092e-227e-4e3f-8a5c-834e9b70530e@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <WJrg2ht4gDlj8g3hH8pyGgd5iS7RvVnr26RxZCCm5ds=.d531092e-227e-4e3f-8a5c-834e9b70530e@github.com>
Message-ID: <yIsqPjAWTYesCvgCj_OvHgnvB6x1IThQ4KcTZBg0Ef4=.93713b7e-b4d4-4d07-88b6-374f4a89cab3@github.com>

On Fri, 28 Apr 2023 19:32:40 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This is the same list as the LIBJLI_EXTRA_FILES above. Would be good to avoid the duplication.

@erikj79 Addressed in the extracted https://github.com/openjdk/jdk/pull/13768, which contains .a related changes only (without linking 'javastatic' part), thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1183188806

From jiangli at openjdk.org  Wed May  3 03:03:21 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 03:03:21 GMT
Subject: RFR: 8303796: Optionally build fully statically linked JDK image
 [v2]
In-Reply-To: <WJrg2ht4gDlj8g3hH8pyGgd5iS7RvVnr26RxZCCm5ds=.d531092e-227e-4e3f-8a5c-834e9b70530e@github.com>
References: <kLPxRLMhIMfdZ_DcZC27CtSPTRJnixyqI8EpbB54wQU=.c6f428a7-08b3-47bb-9500-8b680afb101c@github.com>
 <WJrg2ht4gDlj8g3hH8pyGgd5iS7RvVnr26RxZCCm5ds=.d531092e-227e-4e3f-8a5c-834e9b70530e@github.com>
Message-ID: <nGYDyny4Se87LJQeBzTSwDFYyJzbP4wA4l4vYt1IshA=.db235941-36e9-44d5-aa95-b083c2c38f89@github.com>

On Fri, 28 Apr 2023 19:34:40 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use $(JVM_LIBS), which includes -lrt on Linux currently.
>
> make/modules/java.desktop/lib/Awt2dLibraries.gmk line 228:
> 
>> 226:     # static libraries cause linking errors due to duplicate symbols.
>> 227:     LIBAWT_XAWT_STATIC_EXCLUDE_OBJS := \
>> 228:       debug_assert.o debug_util.o debug_trace.o debug_mem.o systemScale.o
> 
> Can this list be derived dynamically in some way? If they are all in the same directory, maybe we could base it on that instead of having to maintain an explicit list?

With additional testing, I found 'debug_assert.o debug_util.o debug_trace.o debug_mem.o' are no longer included when building libawt_xawt,  using JDK head code base. We no longer need to be filtered out those for libawt_xawt.a. They were needed for JDK 11.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13709#discussion_r1183201634

From jpai at openjdk.org  Wed May  3 06:00:22 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 May 2023 06:00:22 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v17]
In-Reply-To: <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
Message-ID: <J8EHjjHHWlJsedu925wS2MtO_RFH15QW36fB3yIpiWo=.bc96b994-fb57-4d20-b4ad-adc7a63ad0b2@github.com>

On Wed, 29 Mar 2023 01:40:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup test - rename method and update code comment as suggested by Alan
>  - Rename KNOWN_ENDIANNESS to PLATFORM_PROPERTIES

Keep open.

There's work going on in the jlink and other areas to use the newer APIs for OS name and architecture detection. Specifically for jlink there's a draft PR https://github.com/openjdk/jdk/pull/13585 which along with other changes also updates the `CDSPluginTest` to stop relying on using os.name=windows on a Linux system. I plan to refresh this current PR once those changes are merged.

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

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1532484466

From asotona at openjdk.org  Wed May  3 06:38:29 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 3 May 2023 06:38:29 GMT
Subject: Integrated: 8306729: Add nominal descriptors of modules and packages
 to Constants API
In-Reply-To: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
References: <RSCumyAfCdL8y7Y92Nhbhntt4aaHXuWRLEUl5pW_v7g=.4f692cce-c08b-42c2-815d-05726bc99212@github.com>
Message-ID: <_hoEMLVOzryD7WNPpQPT0KGxetf0F5GGQUDMstj1ghY=.5a8521df-ff3b-4d27-9b20-f4eb8e803b03@github.com>

On Mon, 24 Apr 2023 11:59:03 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Constants API already provides models for all loadable constants to help programs manipulating class files and modelling bytecode instructions. However no models of module and package constants are provided by Constants API. Every program manipulating class files must implement own models and validation of modules and packages constants.
> 
> This pul request adds `java.lang.constant.ModuleDesc` and `java.lang.constant.PackageDesc` to the Constants API. 
> 
> Classfile API will follow up and remove its internal implementations of `PackageDesc` and `ModuleDesc`. 
> 
> Please review this pull request and attached CSR.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: c8f37564
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c8f37564bf0983f449195434378479e1adfc1466
Stats:     467 lines in 8 files changed: 467 ins; 0 del; 0 mod

8306729: Add nominal descriptors of modules and packages to Constants API

Reviewed-by: mchung

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

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

From dholmes at openjdk.org  Wed May  3 07:30:14 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 May 2023 07:30:14 GMT
Subject: RFR: 8307163: JLONG_FORMAT_SPECIFIER should be updated on Windows
In-Reply-To: <d3ANVFpuNftH6q66c2yZuJfD5FdG9gB1iIFcCrrHtvY=.8561cea6-fa48-49de-9c3c-3a7a565d2c53@github.com>
References: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>
 <d3ANVFpuNftH6q66c2yZuJfD5FdG9gB1iIFcCrrHtvY=.8561cea6-fa48-49de-9c3c-3a7a565d2c53@github.com>
Message-ID: <LegJftvewcIhCPs0D7Q_XbxCiWZ9AbHxnsAUc6au8SQ=.0baec0dc-2e8c-4a68-8121-7a304e852988@github.com>

On Tue, 2 May 2023 12:21:01 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Is the globalDefinitions declaration what you're referring to? 

Yes. I'm not clear on the background to all these PRI* format modifiers - all seems rather convoluted.

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

PR Comment: https://git.openjdk.org/jdk/pull/13740#issuecomment-1532570837

From dholmes at openjdk.org  Wed May  3 07:30:16 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 May 2023 07:30:16 GMT
Subject: RFR: 8307163: JLONG_FORMAT_SPECIFIER should be updated on Windows
 [v2]
In-Reply-To: <mnFaRiB8So9CTnN--vpQKXEPjbWNhVVltH_BvzWCBAU=.ee0e4203-0f8b-4dfd-b916-a73994341fc7@github.com>
References: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>
 <mnFaRiB8So9CTnN--vpQKXEPjbWNhVVltH_BvzWCBAU=.ee0e4203-0f8b-4dfd-b916-a73994341fc7@github.com>
Message-ID: <LzJ3fY3ZMD_m1cFkCc4T4eEXbz119IM_GeaIjskOhRU=.5cc32caa-db7c-4d16-acf8-f1e0105fd01d@github.com>

On Tue, 2 May 2023 12:23:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Windows no longer uses I64d anywhere in their newer compilers, instead using the conforming lld specifiers. Minor cleanup here in JLI code to reflect that
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HotSpot should also use lld instead of I64d

src/hotspot/share/utilities/globalDefinitions_visCPP.hpp line 105:

> 103: 
> 104: // Formatting.
> 105: #define FORMAT64_MODIFIER "ll"

Interesting - this seems un-needed and should be replaced in its one use by `INT64_FORMAT_X_0` - but separate PR I think.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13740#discussion_r1183326100

From mcimadamore at openjdk.org  Wed May  3 08:39:23 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 3 May 2023 08:39:23 GMT
Subject: RFR: 8307181: MemoryLayout.structLayout uses undocumented strict
 alignment constraints
Message-ID: <I5NuEcy2evM0wVayIlCoElaemGmUpcmzEPA4jeWNSU0=.aba6eaf6-7717-4dfe-af64-52f0ecfdb36b@github.com>

This patch adds documentation for the behavior of the `MemoryLayout::structLayout` factory.

This factory throws an `IllegalArgumentException` if one of the member layouts passed to it occurs at an offset within the struct that is not aligned.

As part of this patch, I've also added some api notes on how to use this factory when unaligned elements are present.

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

Commit messages:
 - Initial push

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

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

From shade at openjdk.org  Wed May  3 09:43:39 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 May 2023 09:43:39 GMT
Subject: RFR: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity [v12]
In-Reply-To: <8Ak5D6_aeb2o7uOQKF3TZMQsgcA-gCDniHnI-7ZWnMs=.371ccce9-902e-4a03-a7c7-efe4907693fe@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
 <PVpzrnUNYUw9j-v5-l6-V_10Que9IXNlsXhcEuiXP-A=.22b21bed-b619-4a84-b737-9ac46d34374c@github.com>
 <8Ak5D6_aeb2o7uOQKF3TZMQsgcA-gCDniHnI-7ZWnMs=.371ccce9-902e-4a03-a7c7-efe4907693fe@github.com>
Message-ID: <TtXAFGV4FQDBojYcwLjJDNx7w7bk4OiwAiRtC7YDwS0=.ffee64c2-26dc-4a4e-860f-f53130342325@github.com>

On Thu, 27 Apr 2023 09:40:46 GMT, Aleksey Shipilev <shade 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 26 commits:
>> 
>>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>>  - Fix Amazon copyright
>>  - Merge branch 'master' into JDK-83050920-thread-sleep-subms
>>  - Drop nanos_to_nanos_bounded
>>  - Handle overflows
>>  - More review comments
>>  - Adjust test times
>>  - Windows again
>>  - Windows fixes: align(...) is only for power-of-two alignments
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/35e7bc21...da8f0f8c
>
> All right, thank you all! 
> I plan to integrate this some time today/tomorrow.

> @shipilev - did this slip off the radar? :)

The radar was off during the long weekend :)
I think I have enough time in the next two weeks to deal with the fallout from this change, if any.

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

PR Comment: https://git.openjdk.org/jdk/pull/13225#issuecomment-1532728641

From shade at openjdk.org  Wed May  3 09:43:42 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 3 May 2023 09:43:42 GMT
Subject: Integrated: 8305092: Improve Thread.sleep(millis,
 nanos) for sub-millisecond granularity
In-Reply-To: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
References: <88xqouhTj1HznQ0QCINhC08Q1xPTwvl61ze3Vc4Wrpk=.41740e2c-8115-4e67-a375-d0386e2b436f@github.com>
Message-ID: <ikEqZMC07INLWRqNticMmu91IzL6fIuYsFCZXr74HmI=.f399d5a2-b69a-4030-bc24-3af846feecf4@github.com>

On Wed, 29 Mar 2023 11:28:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Java API has the `Thread.sleep(millis, nanos)` method exposed to users. The documentation for that method clearly says the precision and accuracy are dependent on the underlying system behavior. However, it always rounds up `nanos` to 1ms when doing the actual sleep. This means users cannot do the micro-second precision sleeps, even when the underlying platform allows it. Sub-millisecond sleeps are useful to build interesting primitives, like the rate limiters that run with >1000 RPS.
> 
> When faced with this, some users reach for more awkward APIs like `java.util.concurrent.locks.LockSupport.parkNanos`. The use of that API for sleeps is not in line with its intent, and while it "seems to work", it might have interesting interactions with other uses of `LockSupport`. Additionally, these "sleeps" are no longer visible to monitoring tools as "normal sleeps", e.g. as `Thread.sleep` events. Therefore, it would be prudent to improve current `Thread.sleep(millis, nanos)` for sub-millisecond granularity. 
> 
> Fortunately, the underlying code is almost ready for this, at least on POSIX side. I skipped Windows paths, because its timers are still no good. Note that on both Linux and MacOS timers oversleep by about 50us. I have a few ideas how to improve the accuracy for them, which would be a topic for a separate PR.
> 
> Additional testing:
>   - [x] New regression test
>   - [x] New benchmark
>   - [x] Linux x86_64 `tier1`
>   - [x] Linux AArch64 `tier1`

This pull request has now been integrated.

Changeset: fcb280a4
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fcb280a48bf9f562e6c0982c1d7a0076ee2e736e
Stats:     254 lines in 11 files changed: 226 ins; 9 del; 19 mod

8305092: Improve Thread.sleep(millis, nanos) for sub-millisecond granularity

Reviewed-by: dholmes, alanb

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

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

From jwaters at openjdk.org  Wed May  3 11:18:18 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 3 May 2023 11:18:18 GMT
Subject: RFR: 8307163: JLONG_FORMAT_SPECIFIER should be updated on Windows
In-Reply-To: <LegJftvewcIhCPs0D7Q_XbxCiWZ9AbHxnsAUc6au8SQ=.0baec0dc-2e8c-4a68-8121-7a304e852988@github.com>
References: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>
 <d3ANVFpuNftH6q66c2yZuJfD5FdG9gB1iIFcCrrHtvY=.8561cea6-fa48-49de-9c3c-3a7a565d2c53@github.com>
 <LegJftvewcIhCPs0D7Q_XbxCiWZ9AbHxnsAUc6au8SQ=.0baec0dc-2e8c-4a68-8121-7a304e852988@github.com>
Message-ID: <ZazPAnLLkFhKjQuN-O0zGzO0sGbRqQCoOBo_y4Aw2Jc=.918b3a2f-a554-405a-a5ff-c3ffcd20f7fe@github.com>

On Wed, 3 May 2023 07:27:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Is the globalDefinitions declaration what you're referring to?
> 
> Yes. I'm not clear on the background to all these PRI* format modifiers - all seems rather convoluted.

Ah, I see. PRId64 (the 64 bit signed format specifier) used to be %I64d on Windows for a while, but Microsoft has long since replaced them with the proper %lld format specifier a while ago, and strongly encourages C and C++ code on Windows to do the same: https://learn.microsoft.com/en-us/cpp/c-runtime-library/format-specification-syntax-printf-and-wprintf-functions?view=msvc-170

It's not a critical issue, but it still is better to replace the outdated formatting in native and HotSpot code which we define ourselves (as opposed to directly using PRId64) to use what Microsoft themselves have changed the specifier to

I've also just noticed that we should probably also change jlong from __int64 to long long in Windows specific JNI as well to go along with this change

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

PR Comment: https://git.openjdk.org/jdk/pull/13740#issuecomment-1532852631

From asotona at openjdk.org  Wed May  3 12:10:08 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 3 May 2023 12:10:08 GMT
Subject: RFR: 8303669: SelectVersion indexes past the end of the argv array
Message-ID: <D2zcOZqRQkhsvO7q8bs0m1Ut9JDS-fx4EK64ENVOkXQ=.cc815a28-826d-442a-acd8-8cfbef9deaf0@github.com>

libjli/java.c's SelectVersion method receives argc and argv but ignores argc in some circumstances an instead checks if *argv == 0 in its while loop, which results in a segmentation fault if the provided array is not NULL terminated. 

This patch counts down argc in the while loops instead of looking for zero termination.

Please review.

Thank you,
Adam

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

Commit messages:
 - 8303669: SelectVersion indexes past the end of the argv array

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

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

From forax at univ-mlv.fr  Wed May  3 13:12:43 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 3 May 2023 15:12:43 +0200 (CEST)
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
Message-ID: <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>

Another example sent to me by a fellow French guy,

    final Deque<String> nestedDequeue = new ArrayDeque<>();
    nestedDequeue.addFirst("C");
    nestedDequeue.addFirst("B");
    nestedDequeue.addFirst("A");

    final List<String> nestedList = new ArrayList<>();
    nestedList.add("D");
    nestedList.add("E");
    nestedList.add("F");

    final List<Collection<String>> list = Stream.of(nestedDequeue, nestedList).toList();

This one is cool because no 'var' is involved and using collect(Collectors.toList()) instead of toList() solves the inference problem.

R?mi

----- Original Message -----
> From: "Stuart Marks" <stuart.marks at oracle.com>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Tuesday, May 2, 2023 2:44:28 AM
> Subject: Re: The introduction of Sequenced collections is not a source compatible change

> Hi R?mi,
> 
> Thanks for trying out the latest build!
> 
> I'll make sure this gets mentioned in the release note for Sequenced
> Collections.
> We'll also raise this issue when we talk about this feature in the Quality
> Outreach
> program.
> 
> s'marks
> 
> On 4/29/23 3:46 AM, Remi Forax wrote:
>> I've several repositories that now fails to compile with the latest jdk21, which
>> introduces sequence collections.
>> 
>> The introduction of a common supertype to existing collections is *not* a source
>> compatible change because of type inference.
>> 
>> Here is a simplified example:
>> 
>>    public static void m(List<Supplier<? extends Map<String, String>>> factories) {
>>    }
>> 
>>    public static void main(String[] args) {
>>      Supplier<LinkedHashMap<String,String>> supplier1 = LinkedHashMap::new;
>>      Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>>      var factories = List.of(supplier1, supplier2);
>>      m(factories);
>>    }
>> 
>> 
>> This example compiles fine with Java 20 but report an error with Java 21:
>>    SequencedCollectionBug.java:28: error: method m in class SequencedCollectionBug
>>    cannot be applied to given types;
>>      m(factories);
>>      ^
>>    required: List<Supplier<? extends Map<String,String>>>
>>    found:    List<Supplier<? extends SequencedMap<String,String>>>
>>    reason: argument mismatch; List<Supplier<? extends SequencedMap<String,String>>>
>>    cannot be converted to List<Supplier<? extends Map<String,String>>>
>> 
>> 
>> 
>> Apart from the example above, most of the failures I see are in the unit tests
>> provided to the students, because we are using a lot of 'var' in them so they
>> work whatever the name of the types chosen by the students.
>> 
>> Discussing with a colleague, we also believe that this bug is not limited to
>> Java, existing Kotlin codes will also fail to compile due to this bug.
>> 
>> Regards,
> > R?mi

From erikj at openjdk.org  Wed May  3 13:37:15 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 3 May 2023 13:37:15 GMT
Subject: RFR: 8307194: Enhance static-libs-image
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com>

On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries:
> 
> - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib';
> - For libjvm.a specifically, exclude operator_new.o;
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files;
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk;
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS;

The current target user of the .a libraries is GraalVM, so we should check with them that the changes to the contents of the `.a` files isn't impacting them in a bad way. @dougxc what do you think?

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

PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1533040157

From erikj at openjdk.org  Wed May  3 13:46:17 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 3 May 2023 13:46:17 GMT
Subject: RFR: 8307194: Enhance static-libs-image
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <lIaBWWkS6cfUvkcZ5XUHkppKMvIjXg857tsIEzZ4Fgo=.81f03101-4480-487a-b881-ad5d46d378ee@github.com>

On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries:
> 
> - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib';
> - For libjvm.a specifically, exclude operator_new.o;
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files;
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk;
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS;

make/StaticLibsImage.gmk line 61:

> 59:   $(eval TARGETS += $$(COPY_STATIC_LIBS_libjvm)) \
> 60: )
> 61: 

Won't this fail if we were building more than one variant? Perhaps only put `$(JVM_VARIANT_MAIN)` in the static image to avoid problems?

make/modules/java.base/lib/CoreLibraries.gmk line 168:

> 166:   # The duplicate objects in different static libraries cause linking
> 167:   # errors due to duplicate symbols.
> 168:   LIBJLI_STATIC_EXCLUDE_OBJS := $(subst .c,.o,$(LIBJLI_EXTRA_FILE_LIST))

Should probably use `$(OBJ_SUFFIX)` instead of `.o`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1183706646
PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1183702610

From pminborg at openjdk.org  Wed May  3 13:51:20 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 3 May 2023 13:51:20 GMT
Subject: RFR: 8307181: MemoryLayout.structLayout uses undocumented strict
 alignment constraints
In-Reply-To: <I5NuEcy2evM0wVayIlCoElaemGmUpcmzEPA4jeWNSU0=.aba6eaf6-7717-4dfe-af64-52f0ecfdb36b@github.com>
References: <I5NuEcy2evM0wVayIlCoElaemGmUpcmzEPA4jeWNSU0=.aba6eaf6-7717-4dfe-af64-52f0ecfdb36b@github.com>
Message-ID: <w5cj1Ox_S4ChkRWOOKjPE8-TN5BzYeoz2jjt440z5Wk=.61199bb0-f50e-4ee1-94dd-a5d04d6dbd95@github.com>

On Wed, 3 May 2023 08:31:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds documentation for the behavior of the `MemoryLayout::structLayout` factory.
> 
> This factory throws an `IllegalArgumentException` if one of the member layouts passed to it occurs at an offset within the struct that is not aligned.
> 
> As part of this patch, I've also added some api notes on how to use this factory when unaligned elements are present.

Isn't this true also for sequence layouts where, for example, the second element might be misaligned for `sequenceLayout(2, structLayout(JAVA_INT, JAVA_SHORT))`? Or, is this already covered?

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

PR Comment: https://git.openjdk.org/jdk/pull/13770#issuecomment-1533063034

From dnsimon at openjdk.org  Wed May  3 14:01:22 2023
From: dnsimon at openjdk.org (Doug Simon)
Date: Wed, 3 May 2023 14:01:22 GMT
Subject: RFR: 8307194: Enhance static-libs-image
In-Reply-To: <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com>
Message-ID: <nJXdax5tEXk6bml6g0uH8N-3UkIYeMAwd5YqLfMWLyQ=.766e4937-03de-419f-9921-1040b62da603@github.com>

On Wed, 3 May 2023 13:34:12 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> The current target user of the .a libraries is GraalVM, so we should check with them that the changes to the contents of the `.a` files isn't impacting them in a bad way. @dougxc what do you think?

Thanks for the heads up - I've asked the GraalVM Native Image team to look at this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1533078913

From mchhipa at openjdk.org  Wed May  3 14:12:33 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 3 May 2023 14:12:33 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v6]
In-Reply-To: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
Message-ID: <fhDJZ45cjHcgp2v9yZe4MFzBGmZxZV-wg4iyQad39fU=.e0a8da91-86cf-4bef-b608-28f9b41cdc5c@github.com>

> Test is updated to create the binary files during test execution.

Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:

  Move the pseudo code generation part from setup() to seperate methods.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13537/files
  - new: https://git.openjdk.org/jdk/pull/13537/files/1ddb5e69..b690e77b

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

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

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

From mchhipa at openjdk.org  Wed May  3 14:15:16 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 3 May 2023 14:15:16 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v4]
In-Reply-To: <-46y0a0q_fNPvz8y4odsx1u5hnDIDPbg32ypRa3gu_E=.67c0d1e8-47d1-4013-814f-9c0642bf9b6c@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <pC4U4hXLT4yWyOrZ3uSxaGBlnEfcBP2uJl1g95SoNkg=.fcdb924f-5639-42ce-bb6d-b636a905e6de@github.com>
 <jjAm97rPEHzRGIeP7e3HVt8N6AzWu4Z39mofx3UPMO4=.dbb2f64b-a035-460f-a2cb-acd0ae97de13@github.com>
 <e80iDDLFQESn_VYqiLm2iGY0veF7HoDaJvdlx0hZ4DU=.d952d700-ec76-424c-826d-8eb04c81c314@github.com>
 <-46y0a0q_fNPvz8y4odsx1u5hnDIDPbg32ypRa3gu_E=.67c0d1e8-47d1-4013-814f-9c0642bf9b6c@github.com>
Message-ID: <nnAzhM5GUD_WzBwGJ6OBCwzlDB4nNaWk33XZpWy9nOE=.c0836d98-6158-4ffc-b9a3-d284e0e96769@github.com>

On Tue, 2 May 2023 16:27:25 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> This is added in setup method to create the serialized data with current JDK version (JDK under test). In addition to serialized data generated with old JDK version.
>
> Sorry, I still disagree with this.  Your comment in the test is as follows:
> 
> `// Generates the Java Pseudo code for base64 encoded string that can be cut & pasted into the test`
> 
> Which is what the method does and to facilitate it, as an example print it out so that it can be copied and pasted
> 
> ` System.out.println(sb);`
> 
> Again, there is no reason to include this code in the setup method, it should be segmented out into its own method with instructions with how to create the encoded string

Hi Lance, Initially I misunderstood the comment. Now I move the pseudo code generation code to separate methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1183746563

From mcimadamore at openjdk.org  Wed May  3 14:20:16 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 3 May 2023 14:20:16 GMT
Subject: RFR: 8307181: MemoryLayout.structLayout uses undocumented strict
 alignment constraints
In-Reply-To: <w5cj1Ox_S4ChkRWOOKjPE8-TN5BzYeoz2jjt440z5Wk=.61199bb0-f50e-4ee1-94dd-a5d04d6dbd95@github.com>
References: <I5NuEcy2evM0wVayIlCoElaemGmUpcmzEPA4jeWNSU0=.aba6eaf6-7717-4dfe-af64-52f0ecfdb36b@github.com>
 <w5cj1Ox_S4ChkRWOOKjPE8-TN5BzYeoz2jjt440z5Wk=.61199bb0-f50e-4ee1-94dd-a5d04d6dbd95@github.com>
Message-ID: <XbKUOj7gi8L2N7QI9HEDO9VeXaRAVkvyCTkl6ZkAGW8=.e3fa5b88-ae6d-4b66-a5f4-f6a2a434347f@github.com>

On Wed, 3 May 2023 13:48:11 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> Isn't this true also for sequence layouts where, for example, the second element might be misaligned for `sequenceLayout(2, structLayout(JAVA_INT, JAVA_SHORT))`? Or, is this already covered?

That case already has some javadoc text:

https://cr.openjdk.org/~pminborg/panama/21/v2/javadoc/api/java.base/java/lang/foreign/MemoryLayout.html#sequenceLayout(long,java.lang.foreign.MemoryLayout)

(both factories throw if the alignment of the element layout is bigger than its size). It seems like I only forgot to add extra doc for structs.

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

PR Comment: https://git.openjdk.org/jdk/pull/13770#issuecomment-1533109597

From jvernee at openjdk.org  Wed May  3 14:24:18 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 3 May 2023 14:24:18 GMT
Subject: RFR: 8307181: MemoryLayout.structLayout uses undocumented strict
 alignment constraints
In-Reply-To: <I5NuEcy2evM0wVayIlCoElaemGmUpcmzEPA4jeWNSU0=.aba6eaf6-7717-4dfe-af64-52f0ecfdb36b@github.com>
References: <I5NuEcy2evM0wVayIlCoElaemGmUpcmzEPA4jeWNSU0=.aba6eaf6-7717-4dfe-af64-52f0ecfdb36b@github.com>
Message-ID: <HuOr-EPs-sbncCc7_lu-jPBIYKYnVT1jg6cXrhsMYa4=.06977276-23c4-4085-86ed-982296588576@github.com>

On Wed, 3 May 2023 08:31:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds documentation for the behavior of the `MemoryLayout::structLayout` factory.
> 
> This factory throws an `IllegalArgumentException` if one of the member layouts passed to it occurs at an offset within the struct that is not aligned.
> 
> As part of this patch, I've also added some api notes on how to use this factory when unaligned elements are present.

Nice api note!

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 743:

> 741:      * overflows.
> 742:      * @throws IllegalArgumentException if a member layouts in {@code elements} occurs at an offset (relative to the start
> 743:      * of the struct layout) which is not compatible with its alignment constraint.

Suggestion:

     * @throws IllegalArgumentException if a member layout in {@code elements} occurs at an offset (relative to the start
     * of the struct layout) which is not compatible with its alignment constraint.

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13770#pullrequestreview-1411008792
PR Review Comment: https://git.openjdk.org/jdk/pull/13770#discussion_r1183756362

From mcimadamore at openjdk.org  Wed May  3 14:24:20 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 3 May 2023 14:24:20 GMT
Subject: RFR: 8307181: MemoryLayout.structLayout uses undocumented strict
 alignment constraints
In-Reply-To: <XbKUOj7gi8L2N7QI9HEDO9VeXaRAVkvyCTkl6ZkAGW8=.e3fa5b88-ae6d-4b66-a5f4-f6a2a434347f@github.com>
References: <I5NuEcy2evM0wVayIlCoElaemGmUpcmzEPA4jeWNSU0=.aba6eaf6-7717-4dfe-af64-52f0ecfdb36b@github.com>
 <w5cj1Ox_S4ChkRWOOKjPE8-TN5BzYeoz2jjt440z5Wk=.61199bb0-f50e-4ee1-94dd-a5d04d6dbd95@github.com>
 <XbKUOj7gi8L2N7QI9HEDO9VeXaRAVkvyCTkl6ZkAGW8=.e3fa5b88-ae6d-4b66-a5f4-f6a2a434347f@github.com>
Message-ID: <RbViLBaELu0ouW6ZS3TE3zm9Zz1YG0RkGdIY-VUSc5I=.f12c0b95-36f4-43a4-8638-736826578a9b@github.com>

On Wed, 3 May 2023 14:17:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > Isn't this true also for sequence layouts where, for example, the second element might be misaligned for `sequenceLayout(2, structLayout(JAVA_INT, JAVA_SHORT))`? Or, is this already covered?
> 
> That case already has some javadoc text:
> 
> https://cr.openjdk.org/~pminborg/panama/21/v2/javadoc/api/java.base/java/lang/foreign/MemoryLayout.html#sequenceLayout(long,java.lang.foreign.MemoryLayout)
> 
> (both factories throw if the alignment of the element layout is bigger than its size). It seems like I only forgot to add extra doc for structs.

Actually, now that I look at it, it seems that the exception we raise is not correct. I think we need to throw if the element size is not a multiple of the alignment. That is, the size determines the stride, so that has to be a multiple of the alignment, otherwise it won't work.

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

PR Comment: https://git.openjdk.org/jdk/pull/13770#issuecomment-1533114938

From jvernee at openjdk.org  Wed May  3 14:29:31 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 3 May 2023 14:29:31 GMT
Subject: RFR: 8307181: MemoryLayout.structLayout uses undocumented strict
 alignment constraints
In-Reply-To: <RbViLBaELu0ouW6ZS3TE3zm9Zz1YG0RkGdIY-VUSc5I=.f12c0b95-36f4-43a4-8638-736826578a9b@github.com>
References: <I5NuEcy2evM0wVayIlCoElaemGmUpcmzEPA4jeWNSU0=.aba6eaf6-7717-4dfe-af64-52f0ecfdb36b@github.com>
 <w5cj1Ox_S4ChkRWOOKjPE8-TN5BzYeoz2jjt440z5Wk=.61199bb0-f50e-4ee1-94dd-a5d04d6dbd95@github.com>
 <XbKUOj7gi8L2N7QI9HEDO9VeXaRAVkvyCTkl6ZkAGW8=.e3fa5b88-ae6d-4b66-a5f4-f6a2a434347f@github.com>
 <RbViLBaELu0ouW6ZS3TE3zm9Zz1YG0RkGdIY-VUSc5I=.f12c0b95-36f4-43a4-8638-736826578a9b@github.com>
Message-ID: <XNk0m6vHY45FOJGt26pEy6YxREMwVhftC3tbFSLfxhs=.8f5204d5-18bb-4fe7-811e-46b3bbd86dbd@github.com>

On Wed, 3 May 2023 14:20:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Actually, now that I look at it, it seems that the exception we raise is not correct. I think we need to throw if the element size is not a multiple of the alignment. That is, the size determines the stride, so that has to be a multiple of the alignment, otherwise it won't work.

Hmm, I guess the current check/assertion doesn't work out if we have an element layout which has a size that is not a multiple of its alignment constraint (i.e. it lacks trailing padding). For instance a struct of size 12, with alignment 8. The second element of a sequence with that struct layout would not be aligned.

I think we went back-and-forth on the need to enforce trailing padding in the `structLayout` factory a few times.

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

PR Comment: https://git.openjdk.org/jdk/pull/13770#issuecomment-1533124172

From mcimadamore at openjdk.org  Wed May  3 14:57:16 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 3 May 2023 14:57:16 GMT
Subject: RFR: 8307181: MemoryLayout.structLayout uses undocumented strict
 alignment constraints
In-Reply-To: <XNk0m6vHY45FOJGt26pEy6YxREMwVhftC3tbFSLfxhs=.8f5204d5-18bb-4fe7-811e-46b3bbd86dbd@github.com>
References: <I5NuEcy2evM0wVayIlCoElaemGmUpcmzEPA4jeWNSU0=.aba6eaf6-7717-4dfe-af64-52f0ecfdb36b@github.com>
 <w5cj1Ox_S4ChkRWOOKjPE8-TN5BzYeoz2jjt440z5Wk=.61199bb0-f50e-4ee1-94dd-a5d04d6dbd95@github.com>
 <XbKUOj7gi8L2N7QI9HEDO9VeXaRAVkvyCTkl6ZkAGW8=.e3fa5b88-ae6d-4b66-a5f4-f6a2a434347f@github.com>
 <RbViLBaELu0ouW6ZS3TE3zm9Zz1YG0RkGdIY-VUSc5I=.f12c0b95-36f4-43a4-8638-736826578a9b@github.com>
 <XNk0m6vHY45FOJGt26pEy6YxREMwVhftC3tbFSLfxhs=.8f5204d5-18bb-4fe7-811e-46b3bbd86dbd@github.com>
Message-ID: <UZ84Nb1WzzGSPPfcSGJ5BJDVIq2no0seFgPfxcAOWmE=.b6e98e78-2fa0-47cf-b58d-9a3de05b9381@github.com>

On Wed, 3 May 2023 14:26:03 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> > Actually, now that I look at it, it seems that the exception we raise is not correct. I think we need to throw if the element size is not a multiple of the alignment. That is, the size determines the stride, so that has to be a multiple of the alignment, otherwise it won't work.
> 
> Hmm, I guess the current check/assertion doesn't work out if we have an element layout which has a size that is not a multiple of its alignment constraint (i.e. it lacks trailing padding). For instance a struct of size 12, with alignment 8. The second element of a sequence with that struct layout would not be aligned.
> 
> I think we went back-and-forth on the need to enforce trailing padding in the `structLayout` factory a few times.

I think the rationale is: we can't enforce, in general, that a layout size is a multiple of its alignment. Because, for instance, we might want to construct "hyper-aligned" layouts (e.g. a struct layout aligned at page boundary. That's fine.

But I think when you use a layout as a sequence element, then we should check that the thing makes sense - e.g. that the element layout has a size that is indeed a multiple of the alignment. Otherwise it just seems like a "bad" sequence.

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

PR Comment: https://git.openjdk.org/jdk/pull/13770#issuecomment-1533182343

From mcimadamore at openjdk.org  Wed May  3 14:57:16 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 3 May 2023 14:57:16 GMT
Subject: RFR: 8307181: MemoryLayout.structLayout uses undocumented strict
 alignment constraints
In-Reply-To: <UZ84Nb1WzzGSPPfcSGJ5BJDVIq2no0seFgPfxcAOWmE=.b6e98e78-2fa0-47cf-b58d-9a3de05b9381@github.com>
References: <I5NuEcy2evM0wVayIlCoElaemGmUpcmzEPA4jeWNSU0=.aba6eaf6-7717-4dfe-af64-52f0ecfdb36b@github.com>
 <w5cj1Ox_S4ChkRWOOKjPE8-TN5BzYeoz2jjt440z5Wk=.61199bb0-f50e-4ee1-94dd-a5d04d6dbd95@github.com>
 <XbKUOj7gi8L2N7QI9HEDO9VeXaRAVkvyCTkl6ZkAGW8=.e3fa5b88-ae6d-4b66-a5f4-f6a2a434347f@github.com>
 <RbViLBaELu0ouW6ZS3TE3zm9Zz1YG0RkGdIY-VUSc5I=.f12c0b95-36f4-43a4-8638-736826578a9b@github.com>
 <XNk0m6vHY45FOJGt26pEy6YxREMwVhftC3tbFSLfxhs=.8f5204d5-18bb-4fe7-811e-46b3bbd86dbd@github.com>
 <UZ84Nb1WzzGSPPfcSGJ5BJDVIq2no0seFgPfxcAOWmE=.b6e98e78-2fa0-47cf-b58d-9a3de05b9381@github.com>
Message-ID: <5cNEuCt54LyF66M7ZMY5MvJPN6XN7UTJ9xKIE7AjZf4=.f7f8adf1-ca35-45c8-8f4b-57584943a8d4@github.com>

On Wed, 3 May 2023 14:54:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Actually, now that I look at it, it seems that the exception we raise is not correct. I think we need to throw if the element size is not a multiple of the alignment. That is, the size determines the stride, so that has to be a multiple of the alignment, otherwise it won't work.

If that's ok, I'd like to address this other issue in a separate PR/CSR, for clarity.

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

PR Comment: https://git.openjdk.org/jdk/pull/13770#issuecomment-1533184599

From Stuart.SHARPE at natwestmarkets.com  Wed May  3 16:54:53 2023
From: Stuart.SHARPE at natwestmarkets.com (SHARPE, Stuart (Commercial & Institutional CDIO))
Date: Wed, 3 May 2023 16:54:53 +0000
Subject: Time difference calculation bug
Message-ID: <LO2P265MB337698E3B54595B9627229B28A6C9@LO2P265MB3376.GBRP265.PROD.OUTLOOK.COM>

Hello,



I believe I have discovered a bug in java.time. I've searched Jira and couldn't find any existing similar issue.



Consider the following code:



    var t1 = Instant.parse("2023-05-03T10:00:00.000999Z");

    var t2 = Instant.parse("2023-05-03T10:00:01.000Z");

    var t3 = Instant.parse("2023-05-03T10:00:01.001Z");



    System.out.println(MILLIS.between(t1, t2));

    System.out.println(MILLIS.between(t1, t3));



This prints:



    1000

    1000



Given that t3 is exactly one millisecond later than t2, it does not seem reasonable that they can both be 1000 milliseconds later than t1.



The JavaDoc for between() states "The calculation returns a whole number, representing the number of complete units between the two temporals."



Assuming I have understood this correctly, I think MILLIS.between(t1, t3) is correct but MILLIS.between(t1, t2) should return 999.



Regards



Stuart Sharpe



This communication and any attachments are confidential and intended solely for the addressee. If you are not the intended recipient please advise us immediately and delete it. Unless specifically stated in the message or otherwise indicated, you may not duplicate, redistribute or forward this message and any attachments are not intended for distribution to, or use by any person or entity in any jurisdiction or country where such distribution or use would be contrary to local law or regulation. NatWest Markets Plc, NatWest Markets N.V., NatWest Markets Securities Japan Limited and/or NatWest Markets Securities Inc. (collectively "NatWest Markets") accepts no responsibility for any changes made to this message after it was sent.

This communication, where prepared by the sales and trading desk or desk strategists, may be marketing material, desk strategy and/or trader commentary. It is not a product of the research department. This material may constitute an invitation to consider entering into a derivatives transaction under U.S. CFTC Regulations sections 1.71 and 23.605, where applicable, but is not a binding offer to buy/sell any financial instrument. The views of the author may differ from others at NatWest Markets.

Unless otherwise specifically indicated, the contents of this communication and its attachments are for information purposes only and should not be regarded as an offer or solicitation to buy or sell a product or service, confirmation of any transaction, a valuation, indicative price or an official statement. Trading desks may have a position or interest that is inconsistent with any views expressed in this message. In evaluating the information contained in this message, you should know that it could have been previously provided to other clients and/or internal NatWest Markets personnel, who could have already acted on it.

NatWest Markets cannot provide absolute assurances that all electronic communications (sent or received) are secure, error free, not corrupted, incomplete or virus free and/or that they will not be lost, mis-delivered, destroyed, delayed or intercepted/decrypted by others. Therefore NatWest Markets disclaims all liability with regards to electronic communications (and the contents therein) if they are corrupted, lost destroyed, delayed, incomplete, mis-delivered, intercepted, decrypted or otherwise misappropriated by others.

Any electronic communication that is conducted within or through NatWest Markets systems will be subject to being archived, monitored and produced to regulators and in litigation in accordance with NatWest Markets? policy and local laws, rules and regulations. Unless expressly prohibited by local law, electronic communications may be archived in countries other than the country in which you are located, and may be treated in accordance with the laws and regulations of the country of each individual included in the entire chain.

Copyright ? NatWest Markets Plc. All rights reserved. See https://www.nwm.com/disclaimer for further risk disclosure (the agency arrangements referred to in the further risk disclosure between NatWest Markets Plc and NatWest Markets N.V. are not applicable to branches of NatWest Markets N.V.).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230503/19f55510/attachment-0001.htm>

From sgehwolf at openjdk.org  Wed May  3 17:00:26 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 3 May 2023 17:00:26 GMT
Subject: RFR: 8307194: Enhance static-libs-image
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <Gz33_F_gbVJGR8lNaJr7h25Zu5Fv3E8phQQ4TBZnOVs=.31d0aea3-84fd-4fbb-863e-a9da9d8ad3e3@github.com>

On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries:
> 
> - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib';
> - For libjvm.a specifically, exclude operator_new.o;
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files;
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk;
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS;

@jianglizhou How does the produced image look like after this patch? I.e. what's the contents of `build/*/images/static-libs`?

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

PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1533385050

From naoto at openjdk.org  Wed May  3 17:01:17 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 May 2023 17:01:17 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v4]
In-Reply-To: <JqYHi4dOGc0oRt20NEND3YoDlNQ8kL6lldvfwtSax5Y=.781701ae-d52c-44c4-88a0-8a075cfb7465@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <JqYHi4dOGc0oRt20NEND3YoDlNQ8kL6lldvfwtSax5Y=.781701ae-d52c-44c4-88a0-8a075cfb7465@github.com>
Message-ID: <KVUbTsPAXu01uVF6XAXA7yuds4o_2nOLQYO5m_9HzVk=.377a559f-750e-4e40-88a2-27e997d1e447@github.com>

On Tue, 2 May 2023 21:42:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
>> 
>> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
>> 
>> 
>> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
>> - Will not case fold variant subtags
>> - Will not case fold private use subtags prefixed by "lvariant"
>> 
>> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.
>
> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Review comment: Replace wellFormed with parseSts to pass errorMsg to exception
>  - Review comment: Adjust method names
>  - Review comment: Use assertThrows and correct IAE to ILE
>  - Review comment: improve legacy_tags id

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 411:

> 409: 
> 410:     public static String caseFoldTag(String tag) {
> 411:         LanguageTag parsedTag = parse(tag, null);

I think we don't need to create a field `parseSts` but provide a local one here and use it in `parse(tag, sts), as that parse status is only referred to within this method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183964205

From naoto at openjdk.org  Wed May  3 17:01:20 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 May 2023 17:01:20 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v3]
In-Reply-To: <JXDGHb8J5cPDu9NLp10-nWBGJTFCSJWVJP_Jk0OLZ_I=.1c4873cc-eb19-423c-8aa7-ee178c1ad1ea@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <_KbXcqAr67ajBB1dGA4ers6_Sk9OhGk6O8uL3h_NzdE=.f6ba0b87-55b0-40e6-a4f8-8a025822244d@github.com>
 <uwvlNKFjdHtV7Ux6lQhlPZcFUzqWBDcZ6UxKRT87q5g=.2e5688be-dc4e-4115-b6f0-c5df3accbdb7@github.com>
 <JXDGHb8J5cPDu9NLp10-nWBGJTFCSJWVJP_Jk0OLZ_I=.1c4873cc-eb19-423c-8aa7-ee178c1ad1ea@github.com>
Message-ID: <a7Ue4tDB-6MoO6RrHhvaUbfYhn-1y_6kxltLrFPxshY=.507753fe-b680-4aeb-bdbf-242dd220bb63@github.com>

On Tue, 2 May 2023 21:36:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 56:
>> 
>>> 54:     @MethodSource("wellFormedTags")
>>> 55:     public void TestWellFormedTags(String tag, String foldedTag) {
>>> 56:         assertEquals(foldedTag, Locale.caseFoldLanguageTag(tag), String.format("Folded %s", tag));
>> 
>> Would it be helpful if both the expected and the result are recorded?
>
> Junit assertEquals provides the actual result in the failure, so no need to record it.
> 
> Example failure:
> `org.opentest4j.AssertionFailedError: Folded ABC ==> expected: <ab> but was: <abc>`

Ah, ok then

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183965230

From sgehwolf at openjdk.org  Wed May  3 17:08:15 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 3 May 2023 17:08:15 GMT
Subject: RFR: 8307194: Enhance static-libs-image
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <FzWi7GoZ0xR4YCPgwGvRgCfYotdI-7Qqqvz2sviG53o=.3012efbe-dead-4449-af08-bc29d84554a9@github.com>

On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries:
> 
> - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib';
> - For libjvm.a specifically, exclude operator_new.o;
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files;
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk;
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS;

make/Main.gmk line 1060:

> 1058:   symbols-image: $(LIBS_TARGETS) $(LAUNCHER_TARGETS)
> 1059: 
> 1060:   static-libs-image: hotspot-static-libs $(STATIC_LIBS_TARGETS)

Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it.

Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1183974910

From mcimadamore at openjdk.org  Wed May  3 17:52:29 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 3 May 2023 17:52:29 GMT
Subject: RFR: 8307375: Alignment check on layouts used as sequence element is
 not correct
Message-ID: <sPoNFTqvdKTSkVRlpG2Kxqhx6aueV0ukgwUv9lHQCWg=.f9a35c3a-7501-45d5-abb2-a1bac7804bf7@github.com>

This patch fixes `Utils::checkElementAlignment` to do the right thing for _all_ layouts.

The current implementation is broken, as it only works correctly when the input layout is a value layout.
Since value layouts have a size that is a power of two (and size all layouts have alignment that is also a power of two), then verifying that `size > alignment` works well.

But if the input layout is some other layout (e.g. a `StructLayout`), this "power of two" assumption no longer holds. E.g. we can have a layout whose size is 48, and whose alignment is 32. While 48 is clearly bigger than 32, such a layout is still not suitable to be used as an element layout in a sequence.

The fix is to provide two overloads for `Utils::checkElementAlignment` - one which works on `ValueLayout` and another which works on any `MemoryLayout`. The `ValueLayout` version works as before (so performance is not affected).
The `MemoryLayout` variant would perform a full check using the `%` operator. Currently we only use this when creating a new sequence layout and when creating a stream out of a memory segment, so I'm not worried about potential performance regressions.

I've fixed the javadoc so that the various `@throws` clauses in the affected methods reflect the correct behavior.

Finally, I've made the existing alignment/layout tests a bit more robust, by also adding pair-wise combinations of layouts, wrapped in a struct/union. This does generate illegal layout cases which would not have been detected w/o this patch.

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

Commit messages:
 - Fix javadoc for MemorySegment::elements
 - Initial push

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

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

From mcimadamore at openjdk.org  Wed May  3 17:54:18 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 3 May 2023 17:54:18 GMT
Subject: RFR: 8307181: MemoryLayout.structLayout uses undocumented strict
 alignment constraints [v2]
In-Reply-To: <I5NuEcy2evM0wVayIlCoElaemGmUpcmzEPA4jeWNSU0=.aba6eaf6-7717-4dfe-af64-52f0ecfdb36b@github.com>
References: <I5NuEcy2evM0wVayIlCoElaemGmUpcmzEPA4jeWNSU0=.aba6eaf6-7717-4dfe-af64-52f0ecfdb36b@github.com>
Message-ID: <8Tf6H9GaQwtSTj14hTB83llVOU4G0d_MDmxSLOqGT-s=.19d7d4c0-0f86-4dfd-9fc3-f12ea9c91174@github.com>

> This patch adds documentation for the behavior of the `MemoryLayout::structLayout` factory.
> 
> This factory throws an `IllegalArgumentException` if one of the member layouts passed to it occurs at an offset within the struct that is not aligned.
> 
> As part of this patch, I've also added some api notes on how to use this factory when unaligned elements are present.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/foreign/MemoryLayout.java
  
  Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13770/files
  - new: https://git.openjdk.org/jdk/pull/13770/files/592a3db6..3be3a685

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

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

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

From jiangli at openjdk.org  Wed May  3 17:58:25 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 17:58:25 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v2]
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <0T3QYhW2lCL0cut65awn0zF2_xsBu57OhgeBfG13Mbk=.31927d2d-876b-4e8d-8ad1-8642ff0cfb3f@github.com>

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries:
> 
> - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib';
> - For libjvm.a specifically, exclude operator_new.o;
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files;
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk;
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS;

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Update based on @erikj79 review comments and suggestions:
  - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk.
  - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13768/files
  - new: https://git.openjdk.org/jdk/pull/13768/files/f8be9e95..f74b576d

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

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

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

From jiangli at openjdk.org  Wed May  3 17:58:27 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 17:58:27 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v2]
In-Reply-To: <lIaBWWkS6cfUvkcZ5XUHkppKMvIjXg857tsIEzZ4Fgo=.81f03101-4480-487a-b881-ad5d46d378ee@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <lIaBWWkS6cfUvkcZ5XUHkppKMvIjXg857tsIEzZ4Fgo=.81f03101-4480-487a-b881-ad5d46d378ee@github.com>
Message-ID: <FzeV8KfQOT15ch4-SQksr8UfODWktkE_DZnZOVAt3dY=.0c83878b-311c-4bef-beef-af3b1194568b@github.com>

On Wed, 3 May 2023 13:42:03 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update based on @erikj79 review comments and suggestions:
>>   - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk.
>>   - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk.
>
> make/StaticLibsImage.gmk line 61:
> 
>> 59:   $(eval TARGETS += $$(COPY_STATIC_LIBS_libjvm)) \
>> 60: )
>> 61: 
> 
> Won't this fail if we were building more than one variant? Perhaps only put `$(JVM_VARIANT_MAIN)` in the static image to avoid problems?

Changed to copy for $(JVM_VARIANT_MAIN) only, as suggested. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184061602

From jiangli at openjdk.org  Wed May  3 18:15:13 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 18:15:13 GMT
Subject: RFR: 8307194: Enhance static-libs-image
In-Reply-To: <Gz33_F_gbVJGR8lNaJr7h25Zu5Fv3E8phQQ4TBZnOVs=.31d0aea3-84fd-4fbb-863e-a9da9d8ad3e3@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <Gz33_F_gbVJGR8lNaJr7h25Zu5Fv3E8phQQ4TBZnOVs=.31d0aea3-84fd-4fbb-863e-a9da9d8ad3e3@github.com>
Message-ID: <2SPZE-0hNv2CIMD9vVZynRUmk-bw8QCquiDELC2QzDE=.e66960f0-f4ff-4740-99d6-44abe1d8071b@github.com>

On Wed, 3 May 2023 16:57:04 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> @jianglizhou How does the produced image look like after this patch? I.e. what's the contents of `build/*/images/static-libs`?

With the changes in this patch, `build/*/images/static-libs` will contain the `libjvm.a` in addition to the JDK `.a` static libraries.

For the following JDK static libraries (`.a`), the duplicate `.o` files are excluded to avoid linking failures when the the JDK static libraries are linked with:

- For `libjli.a`: Not include `inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o` (compiled from `zlib` sources) if `zlib` is built as JDK bundled. When `zlib` is built as bundled, the extra source files from it are compiled and the produced object files are linked into `libjli`. That's intended for the shared library, `libjli.so`, but that's problematic for `libjli.a`. It's not an issue when `zlib` is not bundled, as the extra sources are not included for `libjli` in that case.
- For `libawt_xawt.a` and `libawt_head.a`: Not include `systemScale.o`, since it's provided in `libawt.a`.

I'll add these details in the PR description as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1533494769

From erikj at openjdk.org  Wed May  3 18:37:16 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 3 May 2023 18:37:16 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v2]
In-Reply-To: <0T3QYhW2lCL0cut65awn0zF2_xsBu57OhgeBfG13Mbk=.31927d2d-876b-4e8d-8ad1-8642ff0cfb3f@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <0T3QYhW2lCL0cut65awn0zF2_xsBu57OhgeBfG13Mbk=.31927d2d-876b-4e8d-8ad1-8642ff0cfb3f@github.com>
Message-ID: <K8VArcZe4yKgNJw_0xkAij7-HHxJ6mA-CxPZUE3XJTY=.a14dcf65-d25f-4e57-be5e-7576f8370046@github.com>

On Wed, 3 May 2023 17:58:25 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries:
>> 
>> - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib';
>> - For libjvm.a specifically, exclude operator_new.o;
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files;
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk;
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS;
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update based on @erikj79 review comments and suggestions:
>   - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk.
>   - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk.

make/Main.gmk line 261:

> 259: endef
> 260: 
> 261: $(foreach v, $(JVM_VARIANTS), $(eval $(call DeclareHotspotStaticLibsRecipe,$v)))

If we are only using the libjvm.a from the main variant, we don't need to generate top level rules for all variants, or we could at least limit the dependency declaration at line 1109 to only need the main variant.

make/StaticLibsImage.gmk line 56:

> 54:     DEST := $(STATIC_LIBS_IMAGE_DIR)/lib, \
> 55:     FILES := $(filter %$(STATIC_LIBRARY_SUFFIX), \
> 56:         $(call FindFiles, $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/libjvm/objs/static))))

I would recommend using `wildcard` instead of `FindFiles` as the files are expected to be in a single directory (no recursive directory searching needed). We also try to put the closing double braces on a new line matching the initial eval in indentation.

Suggestion:

    FILES := $(wildcard $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/libjvm/objs/static/*$(STATIC_LIBRARY_SUFFIX)), \
))

make/StaticLibsImage.gmk line 57:

> 55:     FILES := $(filter %$(STATIC_LIBRARY_SUFFIX), \
> 56:         $(call FindFiles, $(HOTSPOT_OUTPUTDIR)/variant-$(JVM_VARIANT_MAIN)/libjvm/objs/static))))
> 57: $(eval TARGETS += $$(COPY_STATIC_LIBS_libjvm))

No need for eval around this assignment.
Suggestion:

TARGETS += $(COPY_STATIC_LIBS_libjvm)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184105236
PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184103554
PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184099771

From erikj at openjdk.org  Wed May  3 18:37:19 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 3 May 2023 18:37:19 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v2]
In-Reply-To: <FzWi7GoZ0xR4YCPgwGvRgCfYotdI-7Qqqvz2sviG53o=.3012efbe-dead-4449-af08-bc29d84554a9@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <FzWi7GoZ0xR4YCPgwGvRgCfYotdI-7Qqqvz2sviG53o=.3012efbe-dead-4449-af08-bc29d84554a9@github.com>
Message-ID: <YiqQPgB_kCzSfCpTIiYKdak9hbtmF85TnnwONq9-e0o=.ac8e2f03-56af-4a6d-b6c8-b3285ff38567@github.com>

On Wed, 3 May 2023 17:05:29 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update based on @erikj79 review comments and suggestions:
>>   - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk.
>>   - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk.
>
> make/Main.gmk line 1060:
> 
>> 1058:   symbols-image: $(LIBS_TARGETS) $(LAUNCHER_TARGETS)
>> 1059: 
>> 1060:   static-libs-image: hotspot-static-libs $(STATIC_LIBS_TARGETS)
> 
> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it.
> 
> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both?

I'm hoping to get input from the graal team on the impact of this change. The exact usage of the new libjvm.a file is still under discussion so I share you concern about changing things for the current static libs usecase before we fully understand where this is going.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184107079

From jiangli at openjdk.org  Wed May  3 18:43:16 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 18:43:16 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v2]
In-Reply-To: <YiqQPgB_kCzSfCpTIiYKdak9hbtmF85TnnwONq9-e0o=.ac8e2f03-56af-4a6d-b6c8-b3285ff38567@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <FzWi7GoZ0xR4YCPgwGvRgCfYotdI-7Qqqvz2sviG53o=.3012efbe-dead-4449-af08-bc29d84554a9@github.com>
 <YiqQPgB_kCzSfCpTIiYKdak9hbtmF85TnnwONq9-e0o=.ac8e2f03-56af-4a6d-b6c8-b3285ff38567@github.com>
Message-ID: <D1U10iiO7vJHFxmcM1_eRvdB2A43OXy4-301zssm3Xo=.a4564f59-dace-4274-8e38-94dd41f29616@github.com>

On Wed, 3 May 2023 18:33:56 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> make/Main.gmk line 1060:
>> 
>>> 1058:   symbols-image: $(LIBS_TARGETS) $(LAUNCHER_TARGETS)
>>> 1059: 
>>> 1060:   static-libs-image: hotspot-static-libs $(STATIC_LIBS_TARGETS)
>> 
>> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it.
>> 
>> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both?
>
> I'm hoping to get input from the graal team on the impact of this change. The exact usage of the new libjvm.a file is still under discussion so I share you concern about changing things for the current static libs usecase before we fully understand where this is going.

> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it.
> 
> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both?

Good questions. I had similar thoughts when making the makefile changes. Here's my reasoning with the current approach in this PR:

The `images/static-libs/lib` would provide a super set of the JDK/VM static libraries (in a JDK binary/release) for downstream developers to produce their desired final static image. With the addition of the `libjvm.a` and potentially bundled `libzlib.a` and `libfreetype.a` included in `static-libs-image` output, users could select the needed subset of the static libraries for their linking step (e.g. via jlink based on the needed modules) to produce the final image. 

If these changes are cumbersome for `graal-builder-image` usages, using `hotspot-static-libs` directly for producing `libjvm.a` as you suggested could be doable. Or, we could try using a new make target for producing the `.a` superset. There might be potential concerns/issues with the differences between `graal-builder-image` support and Java static image support, i.e. it might be a good idea to explore unified solution for both if possible. @dougxc and others related to GraalVM Native Image are on this review thread. It's a good idea to collect the thoughts together.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184113709

From sgehwolf at openjdk.org  Wed May  3 18:54:15 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 3 May 2023 18:54:15 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v2]
In-Reply-To: <D1U10iiO7vJHFxmcM1_eRvdB2A43OXy4-301zssm3Xo=.a4564f59-dace-4274-8e38-94dd41f29616@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <FzWi7GoZ0xR4YCPgwGvRgCfYotdI-7Qqqvz2sviG53o=.3012efbe-dead-4449-af08-bc29d84554a9@github.com>
 <YiqQPgB_kCzSfCpTIiYKdak9hbtmF85TnnwONq9-e0o=.ac8e2f03-56af-4a6d-b6c8-b3285ff38567@github.com>
 <D1U10iiO7vJHFxmcM1_eRvdB2A43OXy4-301zssm3Xo=.a4564f59-dace-4274-8e38-94dd41f29616@github.com>
Message-ID: <lQachp5KZeetWQYBnW53t_Pf7DFt7KddHXQ-GLzoUUQ=.bdd12040-f270-478d-ba84-f176bd4a404c@github.com>

On Wed, 3 May 2023 18:40:52 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> I'm hoping to get input from the graal team on the impact of this change. The exact usage of the new libjvm.a file is still under discussion so I share you concern about changing things for the current static libs usecase before we fully understand where this is going.
>
>> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it.
>> 
>> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both?
> 
> Good questions. I had similar thoughts when making the makefile changes. Here's my reasoning with the current approach in this PR:
> 
> The `images/static-libs/lib` would provide a super set of the JDK/VM static libraries (in a JDK binary/release) for downstream developers to produce their desired final static image. With the addition of the `libjvm.a` and potentially bundled `libzlib.a` and `libfreetype.a` included in `static-libs-image` output, users could select the needed subset of the static libraries for their linking step (e.g. via jlink based on the needed modules) to produce the final image. 
> 
> If these changes are cumbersome for `graal-builder-image` usages, using `hotspot-static-libs` directly for producing `libjvm.a` as you suggested could be doable. Or, we could try using a new make target for producing the `.a` superset. There might be potential concerns/issues with the differences between `graal-builder-image` support and Java static image support, i.e. it might be a good idea to explore unified solution for both if possible. @dougxc and others related to GraalVM Native Image are on this review thread. It's a good idea to collect the thoughts together.

GraalVM native-image has it's own `libjvm.a` shim which would likely conflict or produce undesirable results. So I'd prefer the approach where `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For new uses-cases needing that, we could add a new top-level target (like `graal-builder-image`) which would produce such an image. As one of the [Mandrel](https://github.com/graalvm/mandrel) maintainers, I'm not sure any post-build filtering via `jlink` or the like would be ideal for us. I'll see if I can test this on a mandrel build tomorrow...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184123989

From jiangli at openjdk.org  Wed May  3 19:11:28 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 19:11:28 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v3]
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <2F3flYLZ6fDkLmUEgEGjwbFpflTPWHCtBmgFowmXq2o=.c465f39d-d798-4266-8851-867155a64d30@github.com>

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries:
> 
> - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib';
> - For libjvm.a specifically, exclude operator_new.o;
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files;
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk;
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS;

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Update make/StaticLibsImage.gmk
  
  Thanks
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13768/files
  - new: https://git.openjdk.org/jdk/pull/13768/files/f74b576d..1f62842e

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

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

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

From jiangli at openjdk.org  Wed May  3 19:19:33 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 19:19:33 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v4]
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <b6py708QcWmjt0p8BX-65KtDr2sIxeu24A0FexezJfQ=.fa3ed728-f675-48ce-9ff2-09a7dc6871fb@github.com>

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries:
> 
> - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib';
> - For libjvm.a specifically, exclude operator_new.o;
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files;
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk;
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS;

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Update make/StaticLibsImage.gmk
  
  thanks
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13768/files
  - new: https://git.openjdk.org/jdk/pull/13768/files/1f62842e..e65aee25

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

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

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

From rriggs at openjdk.org  Wed May  3 19:28:20 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 3 May 2023 19:28:20 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v4]
In-Reply-To: <JqYHi4dOGc0oRt20NEND3YoDlNQ8kL6lldvfwtSax5Y=.781701ae-d52c-44c4-88a0-8a075cfb7465@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <JqYHi4dOGc0oRt20NEND3YoDlNQ8kL6lldvfwtSax5Y=.781701ae-d52c-44c4-88a0-8a075cfb7465@github.com>
Message-ID: <aTioAsSNxFpiEeH7BxcNrw-v_pSQdlIHIX8BSoJPBk4=.efeab225-50b9-4be6-ae4b-46ae8e8f286b@github.com>

On Tue, 2 May 2023 21:42:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
>> 
>> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
>> 
>> 
>> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
>> - Will not case fold variant subtags
>> - Will not case fold private use subtags prefixed by "lvariant"
>> 
>> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.
>
> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Review comment: Replace wellFormed with parseSts to pass errorMsg to exception
>  - Review comment: Adjust method names
>  - Review comment: Use assertThrows and correct IAE to ILE
>  - Review comment: improve legacy_tags id

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 34:

> 32: package sun.util.locale;
> 33: 
> 34: import java.util.*;

Wild card imports are discouraged. It may be useful to update your ide settings to avoid automatic conversions.

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 423:

> 421:         }
> 422:         // Non-legacy tags
> 423:         StringBuilder bldr = new StringBuilder();

Presize the StringBuilder with the current length to avoid a reallocation.

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 429:

> 427:         boolean privUseVarFound = false;
> 428:         for (int i = 0; i < subtags.length; i++) {
> 429:             if (privUseVarFound) {

The following block of code might be easier to read if subtags[i] was put in a local.

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 446:

> 444:                 } else if (subtags[i].equals(PRIVUSE_VARIANT_PREFIX)) {
> 445:                     privUseVarFound = true;
> 446:                 }

These flags can become true but inside the loop cannot become false again.
Is that correct?  For example, I think there can be multiple extension singletons.

test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 75:

> 73: 
> 74:     private static Stream<Arguments> wellFormedTags() {
> 75:         return Stream.of(

There are no test cases with multiple singleton extensions either as valid or invalid tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1184028514
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1184130544
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1184133074
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1184143730
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1184159147

From jlu at openjdk.org  Wed May  3 19:37:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 3 May 2023 19:37:25 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v5]
In-Reply-To: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
Message-ID: <tiGqRoewK33MgQBMnudKX81qMCwdw3H_pkbg-UMM-as=.321267cf-9c03-431e-9ba7-8737ae6b417f@github.com>

> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
> 
> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
> 
> 
> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
> - Will not case fold variant subtags
> - Will not case fold private use subtags prefixed by "lvariant"
> 
> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.

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

  Review comment: parseSts should be local

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13679/files
  - new: https://git.openjdk.org/jdk/pull/13679/files/34ccd3be..f0762efe

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

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

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

From roger.riggs at oracle.com  Wed May  3 19:58:02 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 3 May 2023 15:58:02 -0400
Subject: Time difference calculation bug
In-Reply-To: <LO2P265MB337698E3B54595B9627229B28A6C9@LO2P265MB3376.GBRP265.PROD.OUTLOOK.COM>
References: <LO2P265MB337698E3B54595B9627229B28A6C9@LO2P265MB3376.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <b0002f2b-17db-64f9-44da-d7a956c72ed2@oracle.com>

Hi,

The seconds and nano-seconds are computed separately.
The representation of Instant holds seconds and nanoseconds separately.

The computation is performed on the nano-seconds of the Instant and 
truncated to milliseconds.
The value of 0.000999 becomes 0 when truncated to MILLIS.

Regards, Roger

On 5/3/23 12:54 PM, SHARPE, Stuart (Commercial & Institutional CDIO) wrote:
>
> Hello,
>
> I believe I have discovered a bug in java.time. I've searched Jira and 
> couldn't find any existing similar issue.
>
> Consider the following code:
>
> ??? var t1 = Instant.parse("2023-05-03T10:00:00.000999Z");
>
> ??? var t2 = Instant.parse("2023-05-03T10:00:01.000Z");
>
> ??? var t3 = Instant.parse("2023-05-03T10:00:01.001Z");
>
> ????System.out.println(MILLIS.between(t1, t2));
>
> System.out.println(MILLIS.between(t1, t3));
>
> This prints:
>
> ??? 1000
>
> ??? 1000
>
> Given that t3 is exactly one millisecond later than t2, it does not 
> seem reasonable that they can both be 1000 milliseconds later than t1.
>
> The JavaDoc for between() states "The calculation returns a whole 
> number, representing the number of complete units between the two 
> temporals."
>
> Assuming I have understood this correctly, I think MILLIS.between(t1, 
> t3) is correct but MILLIS.between(t1, t2) should return 999.
>
> Regards
>
> Stuart Sharpe
>
>
> This communication and any attachments are confidential and intended 
> solely for the addressee. If you are not the intended recipient please 
> advise us immediately and delete it. Unless specifically stated in the 
> message or otherwise indicated, you may not duplicate, redistribute or 
> forward this message and any attachments are not intended for 
> distribution to, or use by any person or entity in any jurisdiction or 
> country where such distribution or use would be contrary to local law 
> or regulation. NatWest Markets Plc, NatWest Markets N.V., NatWest 
> Markets Securities Japan Limited and/or NatWest Markets Securities 
> Inc. (collectively "NatWest Markets") accepts no responsibility for 
> any changes made to this message after it was sent.
> This communication, where prepared by the sales and trading desk or 
> desk strategists, may be marketing material, desk strategy and/or 
> trader commentary. It is not a product of the research department. 
> This material may constitute an invitation to consider entering into a 
> derivatives transaction under U.S. CFTC Regulations sections 1.71 and 
> 23.605, where applicable, but is not a binding offer to buy/sell any 
> financial instrument. The views of the author may differ from others 
> at NatWest Markets.
> Unless otherwise specifically indicated, the contents of this 
> communication and its attachments are for information purposes only 
> and should not be regarded as an offer or solicitation to buy or sell 
> a product or service, confirmation of any transaction, a valuation, 
> indicative price or an official statement. Trading desks may have a 
> position or interest that is inconsistent with any views expressed in 
> this message. In evaluating the information contained in this message, 
> you should know that it could have been previously provided to other 
> clients and/or internal NatWest Markets personnel, who could have 
> already acted on it.
> NatWest Markets cannot provide absolute assurances that all electronic 
> communications (sent or received) are secure, error free, not 
> corrupted, incomplete or virus free and/or that they will not be lost, 
> mis-delivered, destroyed, delayed or intercepted/decrypted by others. 
> Therefore NatWest Markets disclaims all liability with regards to 
> electronic communications (and the contents therein) if they are 
> corrupted, lost destroyed, delayed, incomplete, mis-delivered, 
> intercepted, decrypted or otherwise misappropriated by others.
> Any electronic communication that is conducted within or through 
> NatWest Markets systems will be subject to being archived, monitored 
> and produced to regulators and in litigation in accordance with 
> NatWest Markets? policy and local laws, rules and regulations. Unless 
> expressly prohibited by local law, electronic communications may be 
> archived in countries other than the country in which you are located, 
> and may be treated in accordance with the laws and regulations of the 
> country of each individual included in the entire chain.
> Copyright ? NatWest Markets Plc. All rights reserved. See 
> https://www.nwm.com/disclaimer for further risk disclosure (the agency 
> arrangements referred to in the further risk disclosure between 
> NatWest Markets Plc and NatWest Markets N.V. are not applicable to 
> branches of NatWest Markets N.V.).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230503/4c076a91/attachment-0001.htm>

From rriggs at openjdk.org  Wed May  3 20:06:27 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 3 May 2023 20:06:27 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture, and Version in jlink
Message-ID: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>

Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.

Neither os.name nor os.arch should be assumed to be changeable; 
one test case is removed because it assumes os.name can be changed on the command line.

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

Commit messages:
 - Merge branch 'master' into 8304913-os-arch-jlink
 - Minor cleanup
 - Merge branch 'master' into 8304913-os-arch-jlink
 - 8304913: Use OperatingSystem, Architecture, and Version in jlink
 - Simplify exception handling
 - Simplify version parsing
 - 8306678: Replace use of os.version with an internal Version record
 - Use and test of "s390" verified by reviewer.
 - Merge branch 'master' into 8304915-arch-enum
 - Merge branch 'master' into 8304915-arch-enum
 - ... and 16 more: https://git.openjdk.org/jdk/compare/fc76687c...8b14b48e

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

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

From liach at openjdk.org  Wed May  3 20:10:27 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 May 2023 20:10:27 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v12]
In-Reply-To: <tLyEmO003UOcRBn2MnpkWjm2acr_8pJ8c5N7w6JQbHg=.ff06b695-6256-4e5d-984f-b9f1b0f93aee@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <tLyEmO003UOcRBn2MnpkWjm2acr_8pJ8c5N7w6JQbHg=.ff06b695-6256-4e5d-984f-b9f1b0f93aee@github.com>
Message-ID: <RWnJKrVum2rb-JdvCihZEO0ljj8KiE8k_QBuW0vyQFo=.695f4cf1-ef84-40fc-98cf-9061209ce345@github.com>

On Tue, 2 May 2023 21:22:16 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with a check to the class data. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup, attempt to migrate lookup validation blocked by security manager

Also, looking at #10024, should the proxy classes generated have stable names, such as by incorporating the name of the interface in the module/package name?

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1533665503

From jiangli at openjdk.org  Wed May  3 20:25:13 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 20:25:13 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v5]
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <qN5_kQ60XksR5_6wCtn1o6VS2lBdhZH6W86IQaG2YMs=.dd92f142-d6e1-49b5-8472-87882188b132@github.com>

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries:
> 
> - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib';
> - For libjvm.a specifically, exclude operator_new.o;
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files;
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk;
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS;

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13768/files
  - new: https://git.openjdk.org/jdk/pull/13768/files/e65aee25..84861990

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

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

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

From jiangli at openjdk.org  Wed May  3 20:25:17 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 20:25:17 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v2]
In-Reply-To: <K8VArcZe4yKgNJw_0xkAij7-HHxJ6mA-CxPZUE3XJTY=.a14dcf65-d25f-4e57-be5e-7576f8370046@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <0T3QYhW2lCL0cut65awn0zF2_xsBu57OhgeBfG13Mbk=.31927d2d-876b-4e8d-8ad1-8642ff0cfb3f@github.com>
 <K8VArcZe4yKgNJw_0xkAij7-HHxJ6mA-CxPZUE3XJTY=.a14dcf65-d25f-4e57-be5e-7576f8370046@github.com>
Message-ID: <YH6oKWVHwVa_9U5Fuisd-Np301BcDRoLdIGMP0cVHfM=.ae6760ea-7da0-4554-af51-4299dd57040b@github.com>

On Wed, 3 May 2023 18:31:56 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update based on @erikj79 review comments and suggestions:
>>   - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk.
>>   - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk.
>
> make/Main.gmk line 261:
> 
>> 259: endef
>> 260: 
>> 261: $(foreach v, $(JVM_VARIANTS), $(eval $(call DeclareHotspotStaticLibsRecipe,$v)))
> 
> If we are only using the libjvm.a from the main variant, we don't need to generate top level rules for all variants, or we could at least limit the dependency declaration at line 1109 to only need the main variant.

Changed to define/use the `libjvm.a` rule for the main variant only as suggested, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184217800

From jlu at openjdk.org  Wed May  3 20:32:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 3 May 2023 20:32:25 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v6]
In-Reply-To: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
Message-ID: <Qxg9rAUPtzUYyt21mKIpZQfIiqvVnF-kadcA7PndHIM=.03290dc4-fe07-43cc-800f-0524cc67acc9@github.com>

> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
> 
> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
> 
> 
> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
> - Will not case fold variant subtags
> - Will not case fold private use subtags prefixed by "lvariant"
> 
> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.

Justin Lu has updated the pull request incrementally with three additional commits since the last revision:

 - Review: SBldr should be pre allocated with input tag
 - Review: drop wwildcard import and replace subtags[i] with subtag
 - Review: Include multiple singleton extensions in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13679/files
  - new: https://git.openjdk.org/jdk/pull/13679/files/f0762efe..96781281

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

  Stats: 34 lines in 2 files changed: 18 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13679/head:pull/13679

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

From jlu at openjdk.org  Wed May  3 20:32:27 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 3 May 2023 20:32:27 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v5]
In-Reply-To: <tiGqRoewK33MgQBMnudKX81qMCwdw3H_pkbg-UMM-as=.321267cf-9c03-431e-9ba7-8737ae6b417f@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <tiGqRoewK33MgQBMnudKX81qMCwdw3H_pkbg-UMM-as=.321267cf-9c03-431e-9ba7-8737ae6b417f@github.com>
Message-ID: <ikUettB9vhj_Ik3U0a_us4E5bikitH_-fhszLjH7szw=.e57a7f01-fc18-4b60-9d19-9f69b5bd96e4@github.com>

On Wed, 3 May 2023 19:37:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
>> 
>> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
>> 
>> 
>> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
>> - Will not case fold variant subtags
>> - Will not case fold private use subtags prefixed by "lvariant"
>> 
>> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment: parseSts should be local

Hi @RogerRiggs, thanks for the review. 

I have dropped the wildcard import (and disabled it on IntellJ for the future), made subtags[i] a local var, added tests with multiple extension singletons, and pre allocated the string builder.

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

PR Comment: https://git.openjdk.org/jdk/pull/13679#issuecomment-1533690524

From jlu at openjdk.org  Wed May  3 20:32:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 3 May 2023 20:32:29 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v4]
In-Reply-To: <aTioAsSNxFpiEeH7BxcNrw-v_pSQdlIHIX8BSoJPBk4=.efeab225-50b9-4be6-ae4b-46ae8e8f286b@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <JqYHi4dOGc0oRt20NEND3YoDlNQ8kL6lldvfwtSax5Y=.781701ae-d52c-44c4-88a0-8a075cfb7465@github.com>
 <aTioAsSNxFpiEeH7BxcNrw-v_pSQdlIHIX8BSoJPBk4=.efeab225-50b9-4be6-ae4b-46ae8e8f286b@github.com>
Message-ID: <wavaeHtsMoXxkI6OpTOMfaTpQwiEaSVdZBhYWhsUIFM=.a6a59919-5ca2-4375-b8d6-437ea54d1f6f@github.com>

On Wed, 3 May 2023 19:13:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Review comment: Replace wellFormed with parseSts to pass errorMsg to exception
>>  - Review comment: Adjust method names
>>  - Review comment: Use assertThrows and correct IAE to ILE
>>  - Review comment: improve legacy_tags id
>
> src/java.base/share/classes/sun/util/locale/LanguageTag.java line 446:
> 
>> 444:                 } else if (subtags[i].equals(PRIVUSE_VARIANT_PREFIX)) {
>> 445:                     privUseVarFound = true;
>> 446:                 }
> 
> These flags can become true but inside the loop cannot become false again.
> Is that correct?  For example, I think there can be multiple extension singletons.

That was intentional as the booleans represent if a private prefix, singleton prefix, or "lvariant" has been found in general (not that the current position is the suffix of one of those prefixes).

Consider if there is a multiple extension singleton (eg: `a-BBB-CCC-DDD`)

Once singletonFound is set to `true`, it is assumed all further subtags should be lowercased unless it is a private use prefixed by "lvariant". Thus it would be folded to `a-bbb-ccc-ddd` as expected.

Did that address your point?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1184224520

From Stuart.SHARPE at natwestmarkets.com  Wed May  3 20:47:02 2023
From: Stuart.SHARPE at natwestmarkets.com (SHARPE, Stuart (Commercial & Institutional CDIO))
Date: Wed, 3 May 2023 20:47:02 +0000
Subject: Time difference calculation bug
In-Reply-To: <b0002f2b-17db-64f9-44da-d7a956c72ed2@oracle.com>
References: <LO2P265MB337698E3B54595B9627229B28A6C9@LO2P265MB3376.GBRP265.PROD.OUTLOOK.COM>
 <b0002f2b-17db-64f9-44da-d7a956c72ed2@oracle.com>
Message-ID: <LO2P265MB33760D6EEC2CF1677F327C348A6C9@LO2P265MB3376.GBRP265.PROD.OUTLOOK.COM>

Hi Roger,

Thanks for the reply.

I must admit I am struggling to understand your explanation. I can't see how the choice of internal representation would affect the result in this way. I also don't see anything in the JavaDoc that describes values being truncated prior to the calculation, and even if it did, the results are not consistent - if that was the expected behaviour, the results from my previous example would have been 1000 and 1001, would they not?

The part I quoted from the JavaDoc seems quite clear: it should return the number of whole units (millis in this case) between the two temporals. The number of milliseconds between 10:00:00.000999 and 10:00:01.000 is 999.001, which is 999 whole units. 

I think the below illustration makes it clearer that there is something wrong. The output values are all what I would expect as per the JavaDoc apart from the result for t2 = 10:00:01.000.

    var t1 = Instant.parse("2023-05-03T10:00:00.000999Z");
    var t2 = Instant.parse("2023-05-03T10:00:00.995Z");
    
    for(int i=0; i<10; i++) {
      System.out.println(ChronoUnit.MILLIS.between(t1, t2));
      t2 = t2.plusMillis(1);
    }

This prints:

994
995
996
997
998
1000
1000
1001
1002
1003

I'm fully prepared to accept that I've missed something, but at the moment I can't understand what that is.

Regards,

Stuart


From: core-libs-dev <core-libs-dev-retn at openjdk.org> On Behalf Of Roger Riggs
Sent: 03 May 2023 20:58
To: core-libs-dev at openjdk.org
Subject: Re: Time difference calculation bug


Hi,

The seconds and nano-seconds are computed separately.? 
The representation of Instant holds seconds and nanoseconds separately.

The computation is performed on the nano-seconds of the Instant and truncated to milliseconds.
The value of 0.000999 becomes 0 when truncated to MILLIS.

Regards, Roger
On 5/3/23 12:54 PM, SHARPE, Stuart (Commercial & Institutional CDIO) wrote:
Hello,
?
I believe I have discovered a bug in java.time. I've searched Jira and couldn't find any existing similar issue. 
?
Consider the following code:
?
??? var t1 = Instant.parse("2023-05-03T10:00:00.000999Z");
??? var t2 = Instant.parse("2023-05-03T10:00:01.000Z");
??? var t3 = Instant.parse("2023-05-03T10:00:01.001Z");
??? 
????System.out.println(MILLIS.between(t1, t2));
??? System.out.println(MILLIS.between(t1, t3));
?
This prints:
?
??? 1000
??? 1000
?
Given that t3 is exactly one millisecond later than t2, it does not seem reasonable that they can both be 1000 milliseconds later than t1.
?
The JavaDoc for between() states "The calculation returns a whole number, representing the number of complete units between the two temporals."
?
Assuming I have understood this correctly, I think MILLIS.between(t1, t3) is correct but MILLIS.between(t1, t2) should return 999.
?
Regards
?
Stuart Sharpe
?


This communication and any attachments are confidential and intended solely for the addressee. If you are not the intended recipient please advise us immediately and delete it. Unless specifically stated in the message or otherwise indicated, you may not duplicate, redistribute or forward this message and any attachments are not intended for distribution to, or use by any person or entity in any jurisdiction or country where such distribution or use would be contrary to local law or regulation. NatWest Markets Plc, NatWest Markets N.V., NatWest Markets Securities Japan Limited and/or NatWest Markets Securities Inc. (collectively "NatWest Markets") accepts no responsibility for any changes made to this message after it was sent.

This communication, where prepared by the sales and trading desk or desk strategists, may be marketing material, desk strategy and/or trader commentary. It is not a product of the research department. This material may constitute an invitation to consider entering into a derivatives transaction under U.S. CFTC Regulations sections 1.71 and 23.605, where applicable, but is not a binding offer to buy/sell any financial instrument. The views of the author may differ from others at NatWest Markets.

Unless otherwise specifically indicated, the contents of this communication and its attachments are for information purposes only and should not be regarded as an offer or solicitation to buy or sell a product or service, confirmation of any transaction, a valuation, indicative price or an official statement. Trading desks may have a position or interest that is inconsistent with any views expressed in this message. In evaluating the information contained in this message, you should know that it could have been previously provided to other clients and/or internal NatWest Markets personnel, who could have already acted on it.

NatWest Markets cannot provide absolute assurances that all electronic communications (sent or received) are secure, error free, not corrupted, incomplete or virus free and/or that they will not be lost, mis-delivered, destroyed, delayed or intercepted/decrypted by others. Therefore NatWest Markets disclaims all liability with regards to electronic communications (and the contents therein) if they are corrupted, lost destroyed, delayed, incomplete, mis-delivered, intercepted, decrypted or otherwise misappropriated by others.

Any electronic communication that is conducted within or through NatWest Markets systems will be subject to being archived, monitored and produced to regulators and in litigation in accordance with NatWest Markets? policy and local laws, rules and regulations. Unless expressly prohibited by local law, electronic communications may be archived in countries other than the country in which you are located, and may be treated in accordance with the laws and regulations of the country of each individual included in the entire chain.

Copyright ? NatWest Markets Plc. All rights reserved. See https://www.nwm.com/disclaimer for further risk disclosure (the agency arrangements referred to in the further risk disclosure between NatWest Markets Plc and NatWest Markets N.V. are not applicable to branches of NatWest Markets N.V.).

From scolebourne at joda.org  Wed May  3 21:32:35 2023
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 3 May 2023 22:32:35 +0100
Subject: Time difference calculation bug
In-Reply-To: <LO2P265MB33760D6EEC2CF1677F327C348A6C9@LO2P265MB3376.GBRP265.PROD.OUTLOOK.COM>
References: <LO2P265MB337698E3B54595B9627229B28A6C9@LO2P265MB3376.GBRP265.PROD.OUTLOOK.COM>
 <b0002f2b-17db-64f9-44da-d7a956c72ed2@oracle.com>
 <LO2P265MB33760D6EEC2CF1677F327C348A6C9@LO2P265MB3376.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <CACzrW9DYS-0JGWoJCdAiSNbsUjEa3k8ofVpEYxrNv3sPQjX8Yg@mail.gmail.com>

This looks like a bug from the description below, although it is surprising
that it isn't caught by tests.
Stephen

On Wed, 3 May 2023, 21:47 SHARPE, Stuart (Commercial & Institutional CDIO),
<Stuart.SHARPE at natwestmarkets.com> wrote:

> Hi Roger,
>
> Thanks for the reply.
>
> I must admit I am struggling to understand your explanation. I can't see
> how the choice of internal representation would affect the result in this
> way. I also don't see anything in the JavaDoc that describes values being
> truncated prior to the calculation, and even if it did, the results are not
> consistent - if that was the expected behaviour, the results from my
> previous example would have been 1000 and 1001, would they not?
>
> The part I quoted from the JavaDoc seems quite clear: it should return the
> number of whole units (millis in this case) between the two temporals. The
> number of milliseconds between 10:00:00.000999 and 10:00:01.000 is 999.001,
> which is 999 whole units.
>
> I think the below illustration makes it clearer that there is something
> wrong. The output values are all what I would expect as per the JavaDoc
> apart from the result for t2 = 10:00:01.000.
>
>     var t1 = Instant.parse("2023-05-03T10:00:00.000999Z");
>     var t2 = Instant.parse("2023-05-03T10:00:00.995Z");
>
>     for(int i=0; i<10; i++) {
>       System.out.println(ChronoUnit.MILLIS.between(t1, t2));
>       t2 = t2.plusMillis(1);
>     }
>
> This prints:
>
> 994
> 995
> 996
> 997
> 998
> 1000
> 1000
> 1001
> 1002
> 1003
>
> I'm fully prepared to accept that I've missed something, but at the moment
> I can't understand what that is.
>
> Regards,
>
> Stuart
>
>
> From: core-libs-dev <core-libs-dev-retn at openjdk.org> On Behalf Of Roger
> Riggs
> Sent: 03 May 2023 20:58
> To: core-libs-dev at openjdk.org
> Subject: Re: Time difference calculation bug
>
>
> Hi,
>
> The seconds and nano-seconds are computed separately.
> The representation of Instant holds seconds and nanoseconds separately.
>
> The computation is performed on the nano-seconds of the Instant and
> truncated to milliseconds.
> The value of 0.000999 becomes 0 when truncated to MILLIS.
>
> Regards, Roger
> On 5/3/23 12:54 PM, SHARPE, Stuart (Commercial & Institutional CDIO) wrote:
> Hello,
>
> I believe I have discovered a bug in java.time. I've searched Jira and
> couldn't find any existing similar issue.
>
> Consider the following code:
>
>     var t1 = Instant.parse("2023-05-03T10:00:00.000999Z");
>     var t2 = Instant.parse("2023-05-03T10:00:01.000Z");
>     var t3 = Instant.parse("2023-05-03T10:00:01.001Z");
>
>     System.out.println(MILLIS.between(t1, t2));
>     System.out.println(MILLIS.between(t1, t3));
>
> This prints:
>
>     1000
>     1000
>
> Given that t3 is exactly one millisecond later than t2, it does not seem
> reasonable that they can both be 1000 milliseconds later than t1.
>
> The JavaDoc for between() states "The calculation returns a whole number,
> representing the number of complete units between the two temporals."
>
> Assuming I have understood this correctly, I think MILLIS.between(t1, t3)
> is correct but MILLIS.between(t1, t2) should return 999.
>
> Regards
>
> Stuart Sharpe
>
>
>
> This communication and any attachments are confidential and intended
> solely for the addressee. If you are not the intended recipient please
> advise us immediately and delete it. Unless specifically stated in the
> message or otherwise indicated, you may not duplicate, redistribute or
> forward this message and any attachments are not intended for distribution
> to, or use by any person or entity in any jurisdiction or country where
> such distribution or use would be contrary to local law or regulation.
> NatWest Markets Plc, NatWest Markets N.V., NatWest Markets Securities Japan
> Limited and/or NatWest Markets Securities Inc. (collectively "NatWest
> Markets") accepts no responsibility for any changes made to this message
> after it was sent.
>
> This communication, where prepared by the sales and trading desk or desk
> strategists, may be marketing material, desk strategy and/or trader
> commentary. It is not a product of the research department. This material
> may constitute an invitation to consider entering into a derivatives
> transaction under U.S. CFTC Regulations sections 1.71 and 23.605, where
> applicable, but is not a binding offer to buy/sell any financial
> instrument. The views of the author may differ from others at NatWest
> Markets.
>
> Unless otherwise specifically indicated, the contents of this
> communication and its attachments are for information purposes only and
> should not be regarded as an offer or solicitation to buy or sell a product
> or service, confirmation of any transaction, a valuation, indicative price
> or an official statement. Trading desks may have a position or interest
> that is inconsistent with any views expressed in this message. In
> evaluating the information contained in this message, you should know that
> it could have been previously provided to other clients and/or internal
> NatWest Markets personnel, who could have already acted on it.
>
> NatWest Markets cannot provide absolute assurances that all electronic
> communications (sent or received) are secure, error free, not corrupted,
> incomplete or virus free and/or that they will not be lost, mis-delivered,
> destroyed, delayed or intercepted/decrypted by others. Therefore NatWest
> Markets disclaims all liability with regards to electronic communications
> (and the contents therein) if they are corrupted, lost destroyed, delayed,
> incomplete, mis-delivered, intercepted, decrypted or otherwise
> misappropriated by others.
>
> Any electronic communication that is conducted within or through NatWest
> Markets systems will be subject to being archived, monitored and produced
> to regulators and in litigation in accordance with NatWest Markets? policy
> and local laws, rules and regulations. Unless expressly prohibited by local
> law, electronic communications may be archived in countries other than the
> country in which you are located, and may be treated in accordance with the
> laws and regulations of the country of each individual included in the
> entire chain.
>
> Copyright ? NatWest Markets Plc. All rights reserved. See
> https://www.nwm.com/disclaimer for further risk disclosure (the agency
> arrangements referred to in the further risk disclosure between NatWest
> Markets Plc and NatWest Markets N.V. are not applicable to branches of
> NatWest Markets N.V.).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230503/4802c697/attachment.htm>

From jiangli at openjdk.org  Wed May  3 21:43:19 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 3 May 2023 21:43:19 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v5]
In-Reply-To: <lQachp5KZeetWQYBnW53t_Pf7DFt7KddHXQ-GLzoUUQ=.bdd12040-f270-478d-ba84-f176bd4a404c@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <FzWi7GoZ0xR4YCPgwGvRgCfYotdI-7Qqqvz2sviG53o=.3012efbe-dead-4449-af08-bc29d84554a9@github.com>
 <YiqQPgB_kCzSfCpTIiYKdak9hbtmF85TnnwONq9-e0o=.ac8e2f03-56af-4a6d-b6c8-b3285ff38567@github.com>
 <D1U10iiO7vJHFxmcM1_eRvdB2A43OXy4-301zssm3Xo=.a4564f59-dace-4274-8e38-94dd41f29616@github.com>
 <lQachp5KZeetWQYBnW53t_Pf7DFt7KddHXQ-GLzoUUQ=.bdd12040-f270-478d-ba84-f176bd4a404c@github.com>
Message-ID: <anNnabYAdjXJmgNLGDwnNrILn3wP_2xol719TlJMDWE=.b2450038-7710-4888-aecd-dcf07d85ef4c@github.com>

On Wed, 3 May 2023 18:51:54 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>>> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it.
>>> 
>>> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both?
>> 
>> Good questions. I had similar thoughts when making the makefile changes. Here's my reasoning with the current approach in this PR:
>> 
>> The `images/static-libs/lib` would provide a super set of the JDK/VM static libraries (in a JDK binary/release) for downstream developers to produce their desired final static image. With the addition of the `libjvm.a` and potentially bundled `libzlib.a` and `libfreetype.a` included in `static-libs-image` output, users could select the needed subset of the static libraries for their linking step (e.g. via jlink based on the needed modules) to produce the final image. 
>> 
>> If these changes are cumbersome for `graal-builder-image` usages, using `hotspot-static-libs` directly for producing `libjvm.a` as you suggested could be doable. Or, we could try using a new make target for producing the `.a` superset. There might be potential concerns/issues with the differences between `graal-builder-image` support and Java static image support, i.e. it might be a good idea to explore unified solution for both if possible. @dougxc and others related to GraalVM Native Image are on this review thread. It's a good idea to collect the thoughts together.
>
> GraalVM native-image has it's own `libjvm.a` shim which would likely conflict or produce undesirable results. So I'd prefer the approach where `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For new uses-cases needing that, we could add a new top-level target (like `graal-builder-image`) which would produce such an image. As one of the [Mandrel](https://github.com/graalvm/mandrel) maintainers, I'm not sure any post-build filtering via `jlink` or the like would be ideal for us. I'll see if I can test this on a mandrel build tomorrow...

@jerboaa, thanks for the info.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184317386

From dholmes at openjdk.org  Wed May  3 21:55:19 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 3 May 2023 21:55:19 GMT
Subject: RFR: 8306946:
 jdk/test/lib/process/ProcessToolsStartProcessTest.java fails with
 "wrong number of lines in OutputAnalyzer output" [v3]
In-Reply-To: <tNl8lFnAbvB4l5jQ4k4578XXedv8ZJy8_1_0yukTA5U=.5367ccb5-3f9e-4ab5-b4a0-2f6f69325048@github.com>
References: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>
 <tNl8lFnAbvB4l5jQ4k4578XXedv8ZJy8_1_0yukTA5U=.5367ccb5-3f9e-4ab5-b4a0-2f6f69325048@github.com>
Message-ID: <Y1B-FXz3zuGnY5GA1uHxlHNwWTv_nNlXL7_Gu4rofSI=.aad789af-ddd2-4caa-b369-6581c041a99b@github.com>

On Thu, 27 Apr 2023 16:35:59 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The ProcessTools.startProcess (...) has been updated to completely read streams after process has been completed.
>> The test was updated to run 5 times with different number of lines and line sizes.
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   move buffers registration before pumping start point

Okay I _think_ I understand the changes now. I have one small suggestion below but otherwise this seems okay.

Thanks.

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

> 188:                     } catch (TimeoutException e) {
> 189:                         // continue execution, so wait() give a chance to write
> 190:                     } catch (InterruptedException | ExecutionException e) {

Probably also need to catch `CancellationException` here for good measure.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13683#pullrequestreview-1411942808
PR Review Comment: https://git.openjdk.org/jdk/pull/13683#discussion_r1184323176

From lmesnik at openjdk.org  Thu May  4 00:23:21 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 4 May 2023 00:23:21 GMT
Subject: RFR: 8306946:
 jdk/test/lib/process/ProcessToolsStartProcessTest.java fails with
 "wrong number of lines in OutputAnalyzer output" [v4]
In-Reply-To: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>
References: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>
Message-ID: <q1mQXyLwNHg5zTbyf0PZ0vHl5E6PfoATxTnNP9HstaQ=.f5efd7c3-edc9-49f4-a67a-b2d762ca939e@github.com>

> The ProcessTools.startProcess (...) has been updated to completely read streams after process has been completed.
> The test was updated to run 5 times with different number of lines and line sizes.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  catching Cancellation exception

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13683/files
  - new: https://git.openjdk.org/jdk/pull/13683/files/d02b889a..8f350c8f

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

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

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

From lmesnik at openjdk.org  Thu May  4 01:14:23 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 4 May 2023 01:14:23 GMT
Subject: Integrated: 8306946:
 jdk/test/lib/process/ProcessToolsStartProcessTest.java fails with
 "wrong number of lines in OutputAnalyzer output"
In-Reply-To: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>
References: <ISIK6xDSGNSO7Usnt3OXUMae1vVH0RnRjvIz4m3hVts=.1770f58f-1a6a-4dfe-8f27-99d8fa5d1018@github.com>
Message-ID: <I_bRar7hyvHzZNp8oxJjnIaZHF9zfrQtDRZC6zr9wGE=.45431660-547e-438f-bd79-f9204893bee4@github.com>

On Thu, 27 Apr 2023 01:06:23 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The ProcessTools.startProcess (...) has been updated to completely read streams after process has been completed.
> The test was updated to run 5 times with different number of lines and line sizes.

This pull request has now been integrated.

Changeset: 64ac9a05
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64ac9a05e85020d24e33ba55cffa1bd9b269218a
Stats:     63 lines in 2 files changed: 29 ins; 18 del; 16 mod

8306946: jdk/test/lib/process/ProcessToolsStartProcessTest.java fails with "wrong number of lines in OutputAnalyzer output"

Reviewed-by: dholmes

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

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

From dholmes at openjdk.org  Thu May  4 06:30:15 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 May 2023 06:30:15 GMT
Subject: RFR: 8303669: SelectVersion indexes past the end of the argv array
In-Reply-To: <D2zcOZqRQkhsvO7q8bs0m1Ut9JDS-fx4EK64ENVOkXQ=.cc815a28-826d-442a-acd8-8cfbef9deaf0@github.com>
References: <D2zcOZqRQkhsvO7q8bs0m1Ut9JDS-fx4EK64ENVOkXQ=.cc815a28-826d-442a-acd8-8cfbef9deaf0@github.com>
Message-ID: <w2-ncuJhESk8KmTBQBbR-NC0x91mBy6_z06sJTOQmTM=.1fc2f4b0-2106-4b67-b9ce-0113acae3e2a@github.com>

On Wed, 3 May 2023 12:03:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> libjli/java.c's SelectVersion method receives argc and argv but ignores argc in some circumstances an instead checks if *argv == 0 in its while loop, which results in a segmentation fault if the provided array is not NULL terminated. 
> 
> This patch counts down argc in the while loops instead of looking for zero termination.
> 
> Please review.
> 
> Thank you,
> Adam

src/java.base/share/native/libjli/java.c line 1212:

> 1210:     *pret = 0;
> 1211: 
> 1212:     while (argc > 0 && *(arg = *argv) == '-') {

AFAICS this loop terminates at line 1388 and nowhere in the loop body does argc get modified. ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13775#discussion_r1184588025

From alanb at openjdk.org  Thu May  4 06:50:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 May 2023 06:50:16 GMT
Subject: RFR: 8303669: SelectVersion indexes past the end of the argv array
In-Reply-To: <D2zcOZqRQkhsvO7q8bs0m1Ut9JDS-fx4EK64ENVOkXQ=.cc815a28-826d-442a-acd8-8cfbef9deaf0@github.com>
References: <D2zcOZqRQkhsvO7q8bs0m1Ut9JDS-fx4EK64ENVOkXQ=.cc815a28-826d-442a-acd8-8cfbef9deaf0@github.com>
Message-ID: <qgw04AuRgUj6Tqt1Dv9oEdvU97PkG2oqg7WVCVC_43w=.72dd5a00-8d95-4348-b5f2-4390bf0539fa@github.com>

On Wed, 3 May 2023 12:03:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> libjli/java.c's SelectVersion method receives argc and argv but ignores argc in some circumstances an instead checks if *argv == 0 in its while loop, which results in a segmentation fault if the provided array is not NULL terminated. 
> 
> This patch counts down argc in the while loops instead of looking for zero termination.
> 
> Please review.
> 
> Thank you,
> Adam

I think this bug report is a reminder that we need to figure out if JLI was documented at some point, it's surprising to have something outside of the JDK using it directly.

Also are you planning to add a test for this?

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

PR Comment: https://git.openjdk.org/jdk/pull/13775#issuecomment-1534173309

From asotona at openjdk.org  Thu May  4 07:22:16 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 4 May 2023 07:22:16 GMT
Subject: RFR: 8303669: SelectVersion indexes past the end of the argv array
In-Reply-To: <w2-ncuJhESk8KmTBQBbR-NC0x91mBy6_z06sJTOQmTM=.1fc2f4b0-2106-4b67-b9ce-0113acae3e2a@github.com>
References: <D2zcOZqRQkhsvO7q8bs0m1Ut9JDS-fx4EK64ENVOkXQ=.cc815a28-826d-442a-acd8-8cfbef9deaf0@github.com>
 <w2-ncuJhESk8KmTBQBbR-NC0x91mBy6_z06sJTOQmTM=.1fc2f4b0-2106-4b67-b9ce-0113acae3e2a@github.com>
Message-ID: <c8GqPT9Gfp_Urdt8_8ZvJiHsWdmHPH-fowgzacrZZQA=.85deecec-6016-463b-b005-3818e005ee6e@github.com>

On Thu, 4 May 2023 06:26:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> libjli/java.c's SelectVersion method receives argc and argv but ignores argc in some circumstances an instead checks if *argv == 0 in its while loop, which results in a segmentation fault if the provided array is not NULL terminated. 
>> 
>> This patch counts down argc in the while loops instead of looking for zero termination.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> src/java.base/share/native/libjli/java.c line 1212:
> 
>> 1210:     *pret = 0;
>> 1211: 
>> 1212:     while (argc > 0 && *(arg = *argv) == '-') {
> 
> AFAICS this loop terminates at line 1388 and nowhere in the loop body does argc get modified. ??

Reference to argc is passed down to GetOpt, where it is updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13775#discussion_r1184633184

From asotona at openjdk.org  Thu May  4 09:17:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 4 May 2023 09:17:05 GMT
Subject: RFR: 8303669: SelectVersion indexes past the end of the argv array
 [v2]
In-Reply-To: <D2zcOZqRQkhsvO7q8bs0m1Ut9JDS-fx4EK64ENVOkXQ=.cc815a28-826d-442a-acd8-8cfbef9deaf0@github.com>
References: <D2zcOZqRQkhsvO7q8bs0m1Ut9JDS-fx4EK64ENVOkXQ=.cc815a28-826d-442a-acd8-8cfbef9deaf0@github.com>
Message-ID: <ywo2zms31sKW-lu900w0M0xElHHIIN6cIcNE4vLeYDE=.d26b0a95-eb8c-445d-ad33-26c3c71851a9@github.com>

> libjli/java.c's SelectVersion method receives argc and argv but ignores argc in some circumstances an instead checks if *argv == 0 in its while loop, which results in a segmentation fault if the provided array is not NULL terminated. 
> 
> This patch counts down argc in the while loops instead of looking for zero termination.
> 
> Please review.
> 
> Thank you,
> Adam

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

  added test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13775/files
  - new: https://git.openjdk.org/jdk/pull/13775/files/2c46bb40..395cf2e7

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

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

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

From asotona at openjdk.org  Thu May  4 09:18:13 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 4 May 2023 09:18:13 GMT
Subject: RFR: 8303669: SelectVersion indexes past the end of the argv array
In-Reply-To: <qgw04AuRgUj6Tqt1Dv9oEdvU97PkG2oqg7WVCVC_43w=.72dd5a00-8d95-4348-b5f2-4390bf0539fa@github.com>
References: <D2zcOZqRQkhsvO7q8bs0m1Ut9JDS-fx4EK64ENVOkXQ=.cc815a28-826d-442a-acd8-8cfbef9deaf0@github.com>
 <qgw04AuRgUj6Tqt1Dv9oEdvU97PkG2oqg7WVCVC_43w=.72dd5a00-8d95-4348-b5f2-4390bf0539fa@github.com>
Message-ID: <Lg3FmGrmWglcqvqg9_nDIhrdeVNUjpgNRnlnHy2dEpM=.f44f204e-6a48-4bc2-baab-34d41bfb4141@github.com>

On Thu, 4 May 2023 06:47:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Also are you planning to add a test for this?

I've added code to `exeJliLaunchTest.c` (executed by `JliLaunchTest`) to test non null terminated arguments.

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

PR Comment: https://git.openjdk.org/jdk/pull/13775#issuecomment-1534369861

From mcimadamore at openjdk.org  Thu May  4 09:47:26 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 4 May 2023 09:47:26 GMT
Subject: Integrated: 8307181: MemoryLayout.structLayout uses undocumented
 strict alignment constraints
In-Reply-To: <I5NuEcy2evM0wVayIlCoElaemGmUpcmzEPA4jeWNSU0=.aba6eaf6-7717-4dfe-af64-52f0ecfdb36b@github.com>
References: <I5NuEcy2evM0wVayIlCoElaemGmUpcmzEPA4jeWNSU0=.aba6eaf6-7717-4dfe-af64-52f0ecfdb36b@github.com>
Message-ID: <9Qxp8q0mJmGhQekKdAGktYGEfVkrKa7XS2rq8We-uwA=.1dd43ccb-c141-46c3-ae70-d7990918fc97@github.com>

On Wed, 3 May 2023 08:31:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds documentation for the behavior of the `MemoryLayout::structLayout` factory.
> 
> This factory throws an `IllegalArgumentException` if one of the member layouts passed to it occurs at an offset within the struct that is not aligned.
> 
> As part of this patch, I've also added some api notes on how to use this factory when unaligned elements are present.

This pull request has now been integrated.

Changeset: cecf817f
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cecf817f5ed8e6ca290f8da0f07f694f35ec4c7e
Stats:     22 lines in 1 file changed: 22 ins; 0 del; 0 mod

8307181: MemoryLayout.structLayout uses undocumented strict alignment constraints

Reviewed-by: jvernee

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

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

From dholmes at openjdk.org  Thu May  4 09:51:23 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 4 May 2023 09:51:23 GMT
Subject: RFR: 8303669: SelectVersion indexes past the end of the argv array
 [v2]
In-Reply-To: <c8GqPT9Gfp_Urdt8_8ZvJiHsWdmHPH-fowgzacrZZQA=.85deecec-6016-463b-b005-3818e005ee6e@github.com>
References: <D2zcOZqRQkhsvO7q8bs0m1Ut9JDS-fx4EK64ENVOkXQ=.cc815a28-826d-442a-acd8-8cfbef9deaf0@github.com>
 <w2-ncuJhESk8KmTBQBbR-NC0x91mBy6_z06sJTOQmTM=.1fc2f4b0-2106-4b67-b9ce-0113acae3e2a@github.com>
 <c8GqPT9Gfp_Urdt8_8ZvJiHsWdmHPH-fowgzacrZZQA=.85deecec-6016-463b-b005-3818e005ee6e@github.com>
Message-ID: <aRkPUd-lw4eDsj109qe5hrlrhgHBononB-UNC0BRPxc=.e16da93a-1ff1-47d5-acd1-a42db2aa70b0@github.com>

On Thu, 4 May 2023 07:19:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/native/libjli/java.c line 1212:
>> 
>>> 1210:     *pret = 0;
>>> 1211: 
>>> 1212:     while (argc > 0 && *(arg = *argv) == '-') {
>> 
>> AFAICS this loop terminates at line 1388 and nowhere in the loop body does argc get modified. ??
>
> Reference to argc is passed down to GetOpt, where it is updated.

Ah I see - ouch!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13775#discussion_r1184794133

From duke at openjdk.org  Thu May  4 10:10:17 2023
From: duke at openjdk.org (Paul Woegerer)
Date: Thu, 4 May 2023 10:10:17 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v5]
In-Reply-To: <lQachp5KZeetWQYBnW53t_Pf7DFt7KddHXQ-GLzoUUQ=.bdd12040-f270-478d-ba84-f176bd4a404c@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <FzWi7GoZ0xR4YCPgwGvRgCfYotdI-7Qqqvz2sviG53o=.3012efbe-dead-4449-af08-bc29d84554a9@github.com>
 <YiqQPgB_kCzSfCpTIiYKdak9hbtmF85TnnwONq9-e0o=.ac8e2f03-56af-4a6d-b6c8-b3285ff38567@github.com>
 <D1U10iiO7vJHFxmcM1_eRvdB2A43OXy4-301zssm3Xo=.a4564f59-dace-4274-8e38-94dd41f29616@github.com>
 <lQachp5KZeetWQYBnW53t_Pf7DFt7KddHXQ-GLzoUUQ=.bdd12040-f270-478d-ba84-f176bd4a404c@github.com>
Message-ID: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com>

On Wed, 3 May 2023 18:51:54 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>>> Could we decouple `hotspot-static-libs` from `static-libs-image` somehow, please? `static-libs-image` is used by the `graal-builder-image` target and it would be good if it didn't include hotspot static libs as they are not needed for it.
>>> 
>>> Would it be sufficient to just use `hotspot-static-libs` directly? Like: `make static-libs-image hotspot-static-libs`? Failing that, could we introduce a new target that produces both?
>> 
>> Good questions. I had similar thoughts when making the makefile changes. Here's my reasoning with the current approach in this PR:
>> 
>> The `images/static-libs/lib` would provide a super set of the JDK/VM static libraries (in a JDK binary/release) for downstream developers to produce their desired final static image. With the addition of the `libjvm.a` and potentially bundled `libzlib.a` and `libfreetype.a` included in `static-libs-image` output, users could select the needed subset of the static libraries for their linking step (e.g. via jlink based on the needed modules) to produce the final image. 
>> 
>> If these changes are cumbersome for `graal-builder-image` usages, using `hotspot-static-libs` directly for producing `libjvm.a` as you suggested could be doable. Or, we could try using a new make target for producing the `.a` superset. There might be potential concerns/issues with the differences between `graal-builder-image` support and Java static image support, i.e. it might be a good idea to explore unified solution for both if possible. @dougxc and others related to GraalVM Native Image are on this review thread. It's a good idea to collect the thoughts together.
>
> GraalVM native-image has it's own `libjvm.a` shim which would likely conflict or produce undesirable results. So I'd prefer the approach where `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For new uses-cases needing that, we could add a new top-level target (like `graal-builder-image`) which would produce such an image. As one of the [Mandrel](https://github.com/graalvm/mandrel) maintainers, I'm not sure any post-build filtering via `jlink` or the like would be ideal for us. I'll see if I can test this on a mandrel build tomorrow...

As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736.

Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1184786403

From asotona at openjdk.org  Thu May  4 11:27:17 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 4 May 2023 11:27:17 GMT
Subject: RFR: 8304937: BufferedFieldBuilder.Model missing
 writeTo(DirectClassBuilder)
In-Reply-To: <Dtm7oPGvT5GfxpBgOFDSRgtDsLsKLaaIL8Amip1bhuw=.e9aa02b1-9022-4d8a-82a1-8fa00ab2a407@github.com>
References: <Dtm7oPGvT5GfxpBgOFDSRgtDsLsKLaaIL8Amip1bhuw=.e9aa02b1-9022-4d8a-82a1-8fa00ab2a407@github.com>
Message-ID: <Hqh_hzaTtnQAyPAjC3-rDejHNuP1IAtHQuL8rafK7JI=.7278db32-5ecb-478d-b9b0-08dad76c6b6d@github.com>

On Sun, 26 Mar 2023 20:35:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this simple patch to Classfile API that fixes a missing override that otherwise affects usage of chained class transforms. A test is included, that it fails on the missing method without this patch.
> 
> Please review a few other patches fixing bugs affecting normal usage of the Classfile API as well:
> #13167 #13021 #12996
> 
> I am trying to write a test for my in-progress patch to unify parameter mapping in core reflection in anticipation of #9862, however this bug prevents me from dropping method Signature and MethodParameters attributes with chained class transforms.

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13187#pullrequestreview-1412885846

From jpai at openjdk.org  Thu May  4 12:32:18 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 4 May 2023 12:32:18 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink
In-Reply-To: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
Message-ID: <9s9nwIkHGhJyvUKAv2Ruqd6SNWDC1jlwHaLB3P0x0jk=.8192fd7a-4c73-4ee5-a8de-c190da16a764@github.com>

On Fri, 21 Apr 2023 17:06:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
> 
> Neither os.name nor os.arch should be assumed to be changeable; 
> one test case is removed because it assumes os.name can be changed on the command line.

src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java line 575:

> 573:         if (Files.exists(binDir.resolve("java")) ||
> 574:             Files.exists(binDir.resolve("java.exe"))) {
> 575:             return new DefaultExecutableImage(root, retrieveModules(root), Platform.runtime());

Hello Roger, I couldn't find any usages of this (existing) `public static ExecutableImage getExecutableImage(Path root)` in the code. Maybe we could remove it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1184944478

From jpai at openjdk.org  Thu May  4 12:32:19 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 4 May 2023 12:32:19 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink
In-Reply-To: <9s9nwIkHGhJyvUKAv2Ruqd6SNWDC1jlwHaLB3P0x0jk=.8192fd7a-4c73-4ee5-a8de-c190da16a764@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
 <9s9nwIkHGhJyvUKAv2Ruqd6SNWDC1jlwHaLB3P0x0jk=.8192fd7a-4c73-4ee5-a8de-c190da16a764@github.com>
Message-ID: <vooxJw6nsnbGTjyDs7YmXYLd4vJePCdDhlBxQJRcR9U=.9b4a3895-8946-43e4-9ca4-db7e7c9faabf@github.com>

On Thu, 4 May 2023 12:27:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
>> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
>> 
>> Neither os.name nor os.arch should be assumed to be changeable; 
>> one test case is removed because it assumes os.name can be changed on the command line.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java line 575:
> 
>> 573:         if (Files.exists(binDir.resolve("java")) ||
>> 574:             Files.exists(binDir.resolve("java.exe"))) {
>> 575:             return new DefaultExecutableImage(root, retrieveModules(root), Platform.runtime());
> 
> Hello Roger, I couldn't find any usages of this (existing) `public static ExecutableImage getExecutableImage(Path root)` in the code. Maybe we could remove it?

If we do remove this method, the `private static Set<String> retrieveModules(Path root)` method in this same class will become unused too, so can be removed too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1184946521

From jpai at openjdk.org  Thu May  4 12:39:23 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 4 May 2023 12:39:23 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink
In-Reply-To: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
Message-ID: <ChbnjkazjvHdVA12WsVCzEdbM8EFP6QpllxUlS5U6Po=.42a0eea2-2489-41a6-989a-58ea464e3f22@github.com>

On Fri, 21 Apr 2023 17:06:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
> 
> Neither os.name nor os.arch should be assumed to be changeable; 
> one test case is removed because it assumes os.name can be changed on the command line.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 64:

> 62:      */
> 63:     public boolean is64Bit() {
> 64:         return (Architecture.is64bit());

Nit - the enclosing `()` aren't needed.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 71:

> 69:      */
> 70:     public static Platform runtime() {
> 71:         return new Platform(OperatingSystem.current(), Architecture.current());

Should we create a single `private static final Platform`, in this class, to represent the current platform, and keep returning it instead of creating a new instance on each call?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1184952486
PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1184954303

From jpai at openjdk.org  Thu May  4 12:48:20 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 4 May 2023 12:48:20 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale
In-Reply-To: <urKhB25OcB0cL8GsImcRZhD_yALNP8Hz1lXTwFJmDbo=.5318961c-5bbe-4be3-8811-af22b1415a83@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
 <urKhB25OcB0cL8GsImcRZhD_yALNP8Hz1lXTwFJmDbo=.5318961c-5bbe-4be3-8811-af22b1415a83@github.com>
Message-ID: <c1CnRKSe5YdKdoKPmrNSjk63PI-52h0k6QKHByrhw0A=.f58d3fd9-de9a-4980-84b7-9b373d045387@github.com>

On Sun, 29 Jan 2023 23:54:21 GMT, Glavo <duke at openjdk.org> wrote:

>> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
>> 
>> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
>> * The jimage command cannot obtain the help information of the `list` mode.
>
> There are some similar hidden dangers in OpenJDK. I hope to clean them up.
> 
> These hidden dangers are scattered in many modules. Should I solve them in multiple PRs?

Hello @Glavo, I see you reopened this PR, so I'm guessing you are still interested in pursuing this further. Are you considering updating this PR to implement Alan's suggestion to do similar changes in `JImageTask.java` and `JlinkTask.java` to use `Locale.ROOT` or update this proposed change to use `Locale.ENGLISH`?

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

PR Comment: https://git.openjdk.org/jdk/pull/12281#issuecomment-1534716229

From jvernee at openjdk.org  Thu May  4 13:10:15 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 4 May 2023 13:10:15 GMT
Subject: RFR: 8307375: Alignment check on layouts used as sequence element
 is not correct
In-Reply-To: <sPoNFTqvdKTSkVRlpG2Kxqhx6aueV0ukgwUv9lHQCWg=.f9a35c3a-7501-45d5-abb2-a1bac7804bf7@github.com>
References: <sPoNFTqvdKTSkVRlpG2Kxqhx6aueV0ukgwUv9lHQCWg=.f9a35c3a-7501-45d5-abb2-a1bac7804bf7@github.com>
Message-ID: <GSVGy_hUiG26xom-ZsJCEbwx-_ZVXxt3uXOKfrdlS6E=.12fa8380-ea06-449d-a550-a16126de0fc0@github.com>

On Wed, 3 May 2023 17:44:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes `Utils::checkElementAlignment` to do the right thing for _all_ layouts.
> 
> The current implementation is broken, as it only works correctly when the input layout is a value layout.
> Since value layouts have a size that is a power of two (and size all layouts have alignment that is also a power of two), then verifying that `size > alignment` works well.
> 
> But if the input layout is some other layout (e.g. a `StructLayout`), this "power of two" assumption no longer holds. E.g. we can have a layout whose size is 48, and whose alignment is 32. While 48 is clearly bigger than 32, such a layout is still not suitable to be used as an element layout in a sequence.
> 
> The fix is to provide two overloads for `Utils::checkElementAlignment` - one which works on `ValueLayout` and another which works on any `MemoryLayout`. The `ValueLayout` version works as before (so performance is not affected).
> The `MemoryLayout` variant would perform a full check using the `%` operator. Currently we only use this when creating a new sequence layout and when creating a stream out of a memory segment, so I'm not worried about potential performance regressions.
> 
> I've fixed the javadoc so that the various `@throws` clauses in the affected methods reflect the correct behavior.
> 
> Finally, I've made the existing alignment/layout tests a bit more robust, by also adding pair-wise combinations of layouts, wrapped in a struct/union. This does generate illegal layout cases which would not have been detected w/o this patch.

Marked as reviewed by jvernee (Reviewer).

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 179:

> 177:     public static void checkElementAlignment(ValueLayout layout, String msg) {
> 178:         // Fast-path: if both size and alignment are powers of two, we can just
> 179:         // check if one is greater than the other.

Maybe we could add an `assert` here to check that the size is actually a power of two as well. Theoretically there are some value layouts for which is not the case (`long double` is 12 bytes on certain systems).

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

PR Review: https://git.openjdk.org/jdk/pull/13784#pullrequestreview-1413047960
PR Review Comment: https://git.openjdk.org/jdk/pull/13784#discussion_r1184986370

From raffaello.giulietti at oracle.com  Thu May  4 13:23:52 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Thu, 4 May 2023 15:23:52 +0200
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>

Without changing the semantics at all, you could also write

	final List<Collection<String>> list = 
Stream.<Collection<String>>of(nestedDequeue, nestedList).toList();

to "help" type inference.




On 2023-05-03 15:12, forax at univ-mlv.fr wrote:
> Another example sent to me by a fellow French guy,
> 
>      final Deque<String> nestedDequeue = new ArrayDeque<>();
>      nestedDequeue.addFirst("C");
>      nestedDequeue.addFirst("B");
>      nestedDequeue.addFirst("A");
> 
>      final List<String> nestedList = new ArrayList<>();
>      nestedList.add("D");
>      nestedList.add("E");
>      nestedList.add("F");
> 
>      final List<Collection<String>> list = Stream.of(nestedDequeue, nestedList).toList();
> 
> This one is cool because no 'var' is involved and using collect(Collectors.toList()) instead of toList() solves the inference problem.
> 
> R?mi
> 
> ----- Original Message -----
>> From: "Stuart Marks" <stuart.marks at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Sent: Tuesday, May 2, 2023 2:44:28 AM
>> Subject: Re: The introduction of Sequenced collections is not a source compatible change
> 
>> Hi R?mi,
>>
>> Thanks for trying out the latest build!
>>
>> I'll make sure this gets mentioned in the release note for Sequenced
>> Collections.
>> We'll also raise this issue when we talk about this feature in the Quality
>> Outreach
>> program.
>>
>> s'marks
>>
>> On 4/29/23 3:46 AM, Remi Forax wrote:
>>> I've several repositories that now fails to compile with the latest jdk21, which
>>> introduces sequence collections.
>>>
>>> The introduction of a common supertype to existing collections is *not* a source
>>> compatible change because of type inference.
>>>
>>> Here is a simplified example:
>>>
>>>     public static void m(List<Supplier<? extends Map<String, String>>> factories) {
>>>     }
>>>
>>>     public static void main(String[] args) {
>>>       Supplier<LinkedHashMap<String,String>> supplier1 = LinkedHashMap::new;
>>>       Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>>>       var factories = List.of(supplier1, supplier2);
>>>       m(factories);
>>>     }
>>>
>>>
>>> This example compiles fine with Java 20 but report an error with Java 21:
>>>     SequencedCollectionBug.java:28: error: method m in class SequencedCollectionBug
>>>     cannot be applied to given types;
>>>       m(factories);
>>>       ^
>>>     required: List<Supplier<? extends Map<String,String>>>
>>>     found:    List<Supplier<? extends SequencedMap<String,String>>>
>>>     reason: argument mismatch; List<Supplier<? extends SequencedMap<String,String>>>
>>>     cannot be converted to List<Supplier<? extends Map<String,String>>>
>>>
>>>
>>>
>>> Apart from the example above, most of the failures I see are in the unit tests
>>> provided to the students, because we are using a lot of 'var' in them so they
>>> work whatever the name of the types chosen by the students.
>>>
>>> Discussing with a colleague, we also believe that this bug is not limited to
>>> Java, existing Kotlin codes will also fail to compile due to this bug.
>>>
>>> Regards,
>>> R?mi

From liach at openjdk.org  Thu May  4 13:27:26 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 May 2023 13:27:26 GMT
Subject: Integrated: 8304937: BufferedFieldBuilder.Model missing
 writeTo(DirectClassBuilder)
In-Reply-To: <Dtm7oPGvT5GfxpBgOFDSRgtDsLsKLaaIL8Amip1bhuw=.e9aa02b1-9022-4d8a-82a1-8fa00ab2a407@github.com>
References: <Dtm7oPGvT5GfxpBgOFDSRgtDsLsKLaaIL8Amip1bhuw=.e9aa02b1-9022-4d8a-82a1-8fa00ab2a407@github.com>
Message-ID: <iLA8Mwz-k5H07E7k2rhInILs1LbzEhzONOBSJehauCA=.7c897361-d1a8-4c50-875e-b42e5aceb2a4@github.com>

On Sun, 26 Mar 2023 20:35:20 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this simple patch to Classfile API that fixes a missing override that otherwise affects usage of chained class transforms. A test is included, that it fails on the missing method without this patch.
> 
> Please review a few other patches fixing bugs affecting normal usage of the Classfile API as well:
> #13167 #13021 #12996
> 
> I am trying to write a test for my in-progress patch to unify parameter mapping in core reflection in anticipation of #9862, however this bug prevents me from dropping method Signature and MethodParameters attributes with chained class transforms.

This pull request has now been integrated.

Changeset: dc4096ce
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc4096ce136c867e0806070a2d7c8b4efef5294c
Stats:     86 lines in 2 files changed: 85 ins; 0 del; 1 mod

8304937: BufferedFieldBuilder.Model missing writeTo(DirectClassBuilder)

Reviewed-by: asotona

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

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

From ethan at mccue.dev  Thu May  4 13:32:31 2023
From: ethan at mccue.dev (Ethan McCue)
Date: Thu, 4 May 2023 09:32:31 -0400
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
 <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
Message-ID: <CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com>

I guess this a good time to ask, ignoring the benefit part of a cost
benefit analysis, what mechanisms do we have to measure the number of
codebases relying on type inference this will break?

Iirc Adoptium built/ran the unit tests of a bunch of public repos, but it's
also a bit shocking if the jtreg suite had nothing for this.

On Thu, May 4, 2023, 9:27 AM Raffaello Giulietti <
raffaello.giulietti at oracle.com> wrote:

> Without changing the semantics at all, you could also write
>
>         final List<Collection<String>> list =
> Stream.<Collection<String>>of(nestedDequeue, nestedList).toList();
>
> to "help" type inference.
>
>
>
>
> On 2023-05-03 15:12, forax at univ-mlv.fr wrote:
> > Another example sent to me by a fellow French guy,
> >
> >      final Deque<String> nestedDequeue = new ArrayDeque<>();
> >      nestedDequeue.addFirst("C");
> >      nestedDequeue.addFirst("B");
> >      nestedDequeue.addFirst("A");
> >
> >      final List<String> nestedList = new ArrayList<>();
> >      nestedList.add("D");
> >      nestedList.add("E");
> >      nestedList.add("F");
> >
> >      final List<Collection<String>> list = Stream.of(nestedDequeue,
> nestedList).toList();
> >
> > This one is cool because no 'var' is involved and using
> collect(Collectors.toList()) instead of toList() solves the inference
> problem.
> >
> > R?mi
> >
> > ----- Original Message -----
> >> From: "Stuart Marks" <stuart.marks at oracle.com>
> >> To: "Remi Forax" <forax at univ-mlv.fr>
> >> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> >> Sent: Tuesday, May 2, 2023 2:44:28 AM
> >> Subject: Re: The introduction of Sequenced collections is not a source
> compatible change
> >
> >> Hi R?mi,
> >>
> >> Thanks for trying out the latest build!
> >>
> >> I'll make sure this gets mentioned in the release note for Sequenced
> >> Collections.
> >> We'll also raise this issue when we talk about this feature in the
> Quality
> >> Outreach
> >> program.
> >>
> >> s'marks
> >>
> >> On 4/29/23 3:46 AM, Remi Forax wrote:
> >>> I've several repositories that now fails to compile with the latest
> jdk21, which
> >>> introduces sequence collections.
> >>>
> >>> The introduction of a common supertype to existing collections is
> *not* a source
> >>> compatible change because of type inference.
> >>>
> >>> Here is a simplified example:
> >>>
> >>>     public static void m(List<Supplier<? extends Map<String, String>>>
> factories) {
> >>>     }
> >>>
> >>>     public static void main(String[] args) {
> >>>       Supplier<LinkedHashMap<String,String>> supplier1 =
> LinkedHashMap::new;
> >>>       Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
> >>>       var factories = List.of(supplier1, supplier2);
> >>>       m(factories);
> >>>     }
> >>>
> >>>
> >>> This example compiles fine with Java 20 but report an error with Java
> 21:
> >>>     SequencedCollectionBug.java:28: error: method m in class
> SequencedCollectionBug
> >>>     cannot be applied to given types;
> >>>       m(factories);
> >>>       ^
> >>>     required: List<Supplier<? extends Map<String,String>>>
> >>>     found:    List<Supplier<? extends SequencedMap<String,String>>>
> >>>     reason: argument mismatch; List<Supplier<? extends
> SequencedMap<String,String>>>
> >>>     cannot be converted to List<Supplier<? extends Map<String,String>>>
> >>>
> >>>
> >>>
> >>> Apart from the example above, most of the failures I see are in the
> unit tests
> >>> provided to the students, because we are using a lot of 'var' in them
> so they
> >>> work whatever the name of the types chosen by the students.
> >>>
> >>> Discussing with a colleague, we also believe that this bug is not
> limited to
> >>> Java, existing Kotlin codes will also fail to compile due to this bug.
> >>>
> >>> Regards,
> >>> R?mi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230504/815127e2/attachment-0001.htm>

From mcimadamore at openjdk.org  Thu May  4 15:03:22 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 4 May 2023 15:03:22 GMT
Subject: RFR: 8307375: Alignment check on layouts used as sequence element
 is not correct [v2]
In-Reply-To: <sPoNFTqvdKTSkVRlpG2Kxqhx6aueV0ukgwUv9lHQCWg=.f9a35c3a-7501-45d5-abb2-a1bac7804bf7@github.com>
References: <sPoNFTqvdKTSkVRlpG2Kxqhx6aueV0ukgwUv9lHQCWg=.f9a35c3a-7501-45d5-abb2-a1bac7804bf7@github.com>
Message-ID: <NZG6KsvXMCIJotHT0A7i3cPOnUlhQVp3ZIe2RFD4R7c=.cac57807-4505-48bf-983f-94a4e535dfca@github.com>

> This patch fixes `Utils::checkElementAlignment` to do the right thing for _all_ layouts.
> 
> The current implementation is broken, as it only works correctly when the input layout is a value layout.
> Since value layouts have a size that is a power of two (and size all layouts have alignment that is also a power of two), then verifying that `size > alignment` works well.
> 
> But if the input layout is some other layout (e.g. a `StructLayout`), this "power of two" assumption no longer holds. E.g. we can have a layout whose size is 48, and whose alignment is 32. While 48 is clearly bigger than 32, such a layout is still not suitable to be used as an element layout in a sequence.
> 
> The fix is to provide two overloads for `Utils::checkElementAlignment` - one which works on `ValueLayout` and another which works on any `MemoryLayout`. The `ValueLayout` version works as before (so performance is not affected).
> The `MemoryLayout` variant would perform a full check using the `%` operator. Currently we only use this when creating a new sequence layout and when creating a stream out of a memory segment, so I'm not worried about potential performance regressions.
> 
> I've fixed the javadoc so that the various `@throws` clauses in the affected methods reflect the correct behavior.
> 
> Finally, I've made the existing alignment/layout tests a bit more robust, by also adding pair-wise combinations of layouts, wrapped in a struct/union. This does generate illegal layout cases which would not have been detected w/o this patch.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments (add assert for power of two)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13784/files
  - new: https://git.openjdk.org/jdk/pull/13784/files/1f2fd4b0..682bfaf1

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

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

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

From liach at openjdk.org  Thu May  4 15:22:23 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 May 2023 15:22:23 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v10]
In-Reply-To: <76DeLp-sOfzFX5zpxfxAcaiEO1WV7kwf5ovvkteKHNI=.3b0146d2-b2f5-434e-b197-ef9d7c1b93c2@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <76DeLp-sOfzFX5zpxfxAcaiEO1WV7kwf5ovvkteKHNI=.3b0146d2-b2f5-434e-b197-ef9d7c1b93c2@github.com>
Message-ID: <4zQefGheS82TFz9Nenrb0Uy2hMJSngu6jPRANi_T1hQ=.fec3c97e-a7a7-47c8-a7a4-dfb4758e0f52@github.com>

On Tue, 2 May 2023 14:15:27 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API didn't handle transformations of class files version 50 and below correctly. 
>> 
>> Proposed fix have two parts: 
>> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
>> 2. StackMapTable attribute is not generated for class file versions below 50.
>> 
>> StackMapsTest is also extended to test this patch.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8305990-debug-info-strip-fail
>  - Update StackCounter.java
>  - added comments to StackCounter about maxStack upper bounds calculation for JSR/RET instructions
>  - fixed stack counting of JSR instructions
>  - implemented StackCounter
>  - Making some BufWriter fields final
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/AbstractInstruction.java
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Update src/java.base/share/classes/jdk/internal/classfile/Opcode.java
>    
>    Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com>
>  - fixed ClassPrinterImpl
>  - DiscontinuedInstruction implementation + test
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/995f6608...f132f737

Also, has brian reviewed the DiscontinuedInstruction API changes?

src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 109:

> 107:         maxLocals = isStatic ? 0 : 1;
> 108:         for (var cd : methodDesc.parameterList()) {
> 109:             maxLocals += TypeKind.fromDescriptor(cd.descriptorString()).slotSize();

Suggestion:

            maxLocals += TypeKind.from(cd).slotSize();

src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 310:

> 308:                         var mDesc = MethodTypeDesc.ofDescriptor(nameAndType.type().stringValue());
> 309:                         for (var arg : mDesc.parameterList()) {
> 310:                             stack(-TypeKind.fromDescriptor(arg.descriptorString()).slotSize());

Suggestion:

                            stack(-TypeKind.from(arg).slotSize());

src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 315:

> 313:                             stack(-1);
> 314:                         }
> 315:                         stack(TypeKind.fromDescriptor(mDesc.returnType().descriptorString()).slotSize());

Suggestion:

                        stack(TypeKind.from(mDesc.returnType()).slotSize());

src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java line 378:

> 376:                 bcs.bci,
> 377:                 methodName,
> 378:                 methodDesc.parameterList().stream().map(ClassDesc::displayName).collect(Collectors.joining(","))));

Suggestion:

                methodDesc.displayDescriptor());

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

PR Review: https://git.openjdk.org/jdk/pull/13478#pullrequestreview-1413358082
PR Review Comment: https://git.openjdk.org/jdk/pull/13478#discussion_r1185172984
PR Review Comment: https://git.openjdk.org/jdk/pull/13478#discussion_r1185174342
PR Review Comment: https://git.openjdk.org/jdk/pull/13478#discussion_r1185174639
PR Review Comment: https://git.openjdk.org/jdk/pull/13478#discussion_r1185176343

From roger.riggs at oracle.com  Thu May  4 16:10:19 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Thu, 4 May 2023 12:10:19 -0400
Subject: Time difference calculation bug
In-Reply-To: <LO2P265MB33760D6EEC2CF1677F327C348A6C9@LO2P265MB3376.GBRP265.PROD.OUTLOOK.COM>
References: <LO2P265MB337698E3B54595B9627229B28A6C9@LO2P265MB3376.GBRP265.PROD.OUTLOOK.COM>
 <b0002f2b-17db-64f9-44da-d7a956c72ed2@oracle.com>
 <LO2P265MB33760D6EEC2CF1677F327C348A6C9@LO2P265MB3376.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <71bd9a7f-6f85-fa6e-e11d-904d548e43d3@oracle.com>

Hi,

I created a Jira issue:
8307466 <https://bugs.openjdk.org/browse/JDK-8307466> java.time.Instant 
Time difference calculation bug

The root cause of the bug is in the cod that manages the representation 
of Instant as seconds and nanoseconds.
The borrow/carry logic between the seconds and nanoseconds is suspect in 
Instant.until(Instant end, ChronoUnit unit).

Thanks for the bug report, Roger


On 5/3/23 4:47 PM, SHARPE, Stuart (Commercial & Institutional CDIO) wrote:
> Hi Roger,
>
> Thanks for the reply.
>
> I must admit I am struggling to understand your explanation. I can't see how the choice of internal representation would affect the result in this way. I also don't see anything in the JavaDoc that describes values being truncated prior to the calculation, and even if it did, the results are not consistent - if that was the expected behaviour, the results from my previous example would have been 1000 and 1001, would they not?
>
> The part I quoted from the JavaDoc seems quite clear: it should return the number of whole units (millis in this case) between the two temporals. The number of milliseconds between 10:00:00.000999 and 10:00:01.000 is 999.001, which is 999 whole units.
>
> I think the below illustration makes it clearer that there is something wrong. The output values are all what I would expect as per the JavaDoc apart from the result for t2 = 10:00:01.000.
>
>      var t1 = Instant.parse("2023-05-03T10:00:00.000999Z");
>      var t2 = Instant.parse("2023-05-03T10:00:00.995Z");
>      
>      for(int i=0; i<10; i++) {
>        System.out.println(ChronoUnit.MILLIS.between(t1, t2));
>        t2 = t2.plusMillis(1);
>      }
>
> This prints:
>
> 994
> 995
> 996
> 997
> 998
> 1000
> 1000
> 1001
> 1002
> 1003
>
> I'm fully prepared to accept that I've missed something, but at the moment I can't understand what that is.
>
> Regards,
>
> Stuart
>
>
> From: core-libs-dev<core-libs-dev-retn at openjdk.org>  On Behalf Of Roger Riggs
> Sent: 03 May 2023 20:58
> To:core-libs-dev at openjdk.org
> Subject: Re: Time difference calculation bug
>
>
> Hi,
>
> The seconds and nano-seconds are computed separately.
> The representation of Instant holds seconds and nanoseconds separately.
>
> The computation is performed on the nano-seconds of the Instant and truncated to milliseconds.
> The value of 0.000999 becomes 0 when truncated to MILLIS.
>
> Regards, Roger
> On 5/3/23 12:54 PM, SHARPE, Stuart (Commercial & Institutional CDIO) wrote:
> Hello,
>   
> I believe I have discovered a bug in java.time. I've searched Jira and couldn't find any existing similar issue.
>   
> Consider the following code:
>   
>  ??? var t1 = Instant.parse("2023-05-03T10:00:00.000999Z");
>  ??? var t2 = Instant.parse("2023-05-03T10:00:01.000Z");
>  ??? var t3 = Instant.parse("2023-05-03T10:00:01.001Z");
>      
>  ????System.out.println(MILLIS.between(t1, t2));
>  ??? System.out.println(MILLIS.between(t1, t3));
>   
> This prints:
>   
>  ??? 1000
>  ??? 1000
>   
> Given that t3 is exactly one millisecond later than t2, it does not seem reasonable that they can both be 1000 milliseconds later than t1.
>   
> The JavaDoc for between() states "The calculation returns a whole number, representing the number of complete units between the two temporals."
>   
> Assuming I have understood this correctly, I think MILLIS.between(t1, t3) is correct but MILLIS.between(t1, t2) should return 999.
>   
> Regards
>   
> Stuart Sharpe
>   
>
>
> This communication and any attachments are confidential and intended solely for the addressee. If you are not the intended recipient please advise us immediately and delete it. Unless specifically stated in the message or otherwise indicated, you may not duplicate, redistribute or forward this message and any attachments are not intended for distribution to, or use by any person or entity in any jurisdiction or country where such distribution or use would be contrary to local law or regulation. NatWest Markets Plc, NatWest Markets N.V., NatWest Markets Securities Japan Limited and/or NatWest Markets Securities Inc. (collectively "NatWest Markets") accepts no responsibility for any changes made to this message after it was sent.
>
> This communication, where prepared by the sales and trading desk or desk strategists, may be marketing material, desk strategy and/or trader commentary. It is not a product of the research department. This material may constitute an invitation to consider entering into a derivatives transaction under U.S. CFTC Regulations sections 1.71 and 23.605, where applicable, but is not a binding offer to buy/sell any financial instrument. The views of the author may differ from others at NatWest Markets.
>
> Unless otherwise specifically indicated, the contents of this communication and its attachments are for information purposes only and should not be regarded as an offer or solicitation to buy or sell a product or service, confirmation of any transaction, a valuation, indicative price or an official statement. Trading desks may have a position or interest that is inconsistent with any views expressed in this message. In evaluating the information contained in this message, you should know that it could have been previously provided to other clients and/or internal NatWest Markets personnel, who could have already acted on it.
>
> NatWest Markets cannot provide absolute assurances that all electronic communications (sent or received) are secure, error free, not corrupted, incomplete or virus free and/or that they will not be lost, mis-delivered, destroyed, delayed or intercepted/decrypted by others. Therefore NatWest Markets disclaims all liability with regards to electronic communications (and the contents therein) if they are corrupted, lost destroyed, delayed, incomplete, mis-delivered, intercepted, decrypted or otherwise misappropriated by others.
>
> Any electronic communication that is conducted within or through NatWest Markets systems will be subject to being archived, monitored and produced to regulators and in litigation in accordance with NatWest Markets? policy and local laws, rules and regulations. Unless expressly prohibited by local law, electronic communications may be archived in countries other than the country in which you are located, and may be treated in accordance with the laws and regulations of the country of each individual included in the entire chain.
>
> Copyright ? NatWest Markets Plc. All rights reserved. Seehttps://urldefense.com/v3/__https://www.nwm.com/disclaimer__;!!ACWV5N9M2RV99hQ!MLQn8Js2bYD_SSNi8IZD4ZmvsmT1g50e8lC1K3OnEP8KmswmXw2V7Yu8eXSxUP0yqpLlY0owu7LR6X2oZxrYueaalvFmtjI$   for further risk disclosure (the agency arrangements referred to in the further risk disclosure between NatWest Markets Plc and NatWest Markets N.V. are not applicable to branches of NatWest Markets N.V.).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230504/677270a8/attachment-0001.htm>

From asotona at openjdk.org  Thu May  4 16:19:04 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 4 May 2023 16:19:04 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v11]
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <GCGqTY2WFItzQskhXUniB2WzT2-mEoHAjUiNPiAwyOU=.e55479cd-3ad5-47c9-80c6-459f5c18436e@github.com>

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

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

  Apply suggestions from code review
  
  Thanks for review.
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13478/files
  - new: https://git.openjdk.org/jdk/pull/13478/files/f132f737..6fbd2719

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=09-10

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

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

From asotona at openjdk.org  Thu May  4 16:19:28 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 4 May 2023 16:19:28 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v10]
In-Reply-To: <4zQefGheS82TFz9Nenrb0Uy2hMJSngu6jPRANi_T1hQ=.fec3c97e-a7a7-47c8-a7a4-dfb4758e0f52@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <76DeLp-sOfzFX5zpxfxAcaiEO1WV7kwf5ovvkteKHNI=.3b0146d2-b2f5-434e-b197-ef9d7c1b93c2@github.com>
 <4zQefGheS82TFz9Nenrb0Uy2hMJSngu6jPRANi_T1hQ=.fec3c97e-a7a7-47c8-a7a4-dfb4758e0f52@github.com>
Message-ID: <e8ONbWPL7kQVPk1qUv29ciIaOF1kpeL4kuYVzP67IPU=.cfcabba3-b7d8-4bbd-9dc8-2bb148ab15dd@github.com>

On Thu, 4 May 2023 15:19:02 GMT, Chen Liang <liach at openjdk.org> wrote:

> Also, has brian reviewed the DiscontinuedInstruction API changes?

https://mail.openjdk.org/pipermail/classfile-api-dev/2023-April/000292.html

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

PR Comment: https://git.openjdk.org/jdk/pull/13478#issuecomment-1535028314

From lmesnik at openjdk.org  Thu May  4 16:20:08 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 4 May 2023 16:20:08 GMT
Subject: RFR: 8307307: Improve ProcessTools.java to don't try to run Virtual
 wrapper for incompatible processes
Message-ID: <4XAvxExcDJxNOATuaxhHZvWcpBvt2Zhd2Bd7wuYqN1c=.86016870-ea81-423e-8f71-c44bfd2a8bad@github.com>

The ProcessTools has some support of jtreg thread factory functionality.
It tries to run the new process using virtual thread to run `main()` method.
This fix updates it to skip the java runs where no main class is involved and more correctly process options which has 2nd argument.
Also is sets `main.wrapper` property to allow launched process understand id any wrappers is used.

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

Commit messages:
 - 8307307: Improve ProcessTools.java to don't try to run Virtual wrapper for incompatible processes

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

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

From naoto at openjdk.org  Thu May  4 18:14:20 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 May 2023 18:14:20 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v6]
In-Reply-To: <Qxg9rAUPtzUYyt21mKIpZQfIiqvVnF-kadcA7PndHIM=.03290dc4-fe07-43cc-800f-0524cc67acc9@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <Qxg9rAUPtzUYyt21mKIpZQfIiqvVnF-kadcA7PndHIM=.03290dc4-fe07-43cc-800f-0524cc67acc9@github.com>
Message-ID: <eEFHECn-wQdg-Ypybbzc-kxYM-52dYylulWqhRKATTI=.a529b8f4-dbd4-4578-912c-07b63732a058@github.com>

On Wed, 3 May 2023 20:32:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
>> 
>> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
>> 
>> 
>> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
>> - Will not case fold variant subtags
>> - Will not case fold private use subtags prefixed by "lvariant"
>> 
>> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.
>
> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Review: SBldr should be pre allocated with input tag
>  - Review: drop wwildcard import and replace subtags[i] with subtag
>  - Review: Include multiple singleton extensions in test

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13679#pullrequestreview-1413649585

From rriggs at openjdk.org  Thu May  4 18:35:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 4 May 2023 18:35:19 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v6]
In-Reply-To: <Qxg9rAUPtzUYyt21mKIpZQfIiqvVnF-kadcA7PndHIM=.03290dc4-fe07-43cc-800f-0524cc67acc9@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <Qxg9rAUPtzUYyt21mKIpZQfIiqvVnF-kadcA7PndHIM=.03290dc4-fe07-43cc-800f-0524cc67acc9@github.com>
Message-ID: <E0T1GNjpHVoNA58hrRoSrkoRlDXr2JnKOCEJ_o2R6ks=.3aada262-d316-4ca3-9b74-f55faf601f28@github.com>

On Wed, 3 May 2023 20:32:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
>> 
>> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
>> 
>> 
>> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
>> - Will not case fold variant subtags
>> - Will not case fold private use subtags prefixed by "lvariant"
>> 
>> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.
>
> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Review: SBldr should be pre allocated with input tag
>  - Review: drop wwildcard import and replace subtags[i] with subtag
>  - Review: Include multiple singleton extensions in test

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13679#pullrequestreview-1413697034

From sgehwolf at openjdk.org  Thu May  4 19:15:15 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 4 May 2023 19:15:15 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v5]
In-Reply-To: <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <FzWi7GoZ0xR4YCPgwGvRgCfYotdI-7Qqqvz2sviG53o=.3012efbe-dead-4449-af08-bc29d84554a9@github.com>
 <YiqQPgB_kCzSfCpTIiYKdak9hbtmF85TnnwONq9-e0o=.ac8e2f03-56af-4a6d-b6c8-b3285ff38567@github.com>
 <D1U10iiO7vJHFxmcM1_eRvdB2A43OXy4-301zssm3Xo=.a4564f59-dace-4274-8e38-94dd41f29616@github.com>
 <lQachp5KZeetWQYBnW53t_Pf7DFt7KddHXQ-GLzoUUQ=.bdd12040-f270-478d-ba84-f176bd4a404c@github.com>
 <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com>
Message-ID: <efZdJV-6YqzpSkSPpZiNkOLBfL-Wy-Mo9dU1pCMZXKk=.137f5eda-ed24-4d23-b83a-72d62066c562@github.com>

On Thu, 4 May 2023 09:40:31 GMT, Paul Woegerer <duke at openjdk.org> wrote:

>> GraalVM native-image has it's own `libjvm.a` shim which would likely conflict or produce undesirable results. So I'd prefer the approach where `static-libs-image` wouldn't produce hotspot `libjvm.a` as part of it. For new uses-cases needing that, we could add a new top-level target (like `graal-builder-image`) which would produce such an image. As one of the [Mandrel](https://github.com/graalvm/mandrel) maintainers, I'm not sure any post-build filtering via `jlink` or the like would be ideal for us. I'll see if I can test this on a mandrel build tomorrow...
>
> As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736.
> 
> Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same.

> [...] I'll see if I can test this on a mandrel build tomorrow...

@jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1185416553

From jiangli at openjdk.org  Thu May  4 19:25:18 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 4 May 2023 19:25:18 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v5]
In-Reply-To: <efZdJV-6YqzpSkSPpZiNkOLBfL-Wy-Mo9dU1pCMZXKk=.137f5eda-ed24-4d23-b83a-72d62066c562@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <FzWi7GoZ0xR4YCPgwGvRgCfYotdI-7Qqqvz2sviG53o=.3012efbe-dead-4449-af08-bc29d84554a9@github.com>
 <YiqQPgB_kCzSfCpTIiYKdak9hbtmF85TnnwONq9-e0o=.ac8e2f03-56af-4a6d-b6c8-b3285ff38567@github.com>
 <D1U10iiO7vJHFxmcM1_eRvdB2A43OXy4-301zssm3Xo=.a4564f59-dace-4274-8e38-94dd41f29616@github.com>
 <lQachp5KZeetWQYBnW53t_Pf7DFt7KddHXQ-GLzoUUQ=.bdd12040-f270-478d-ba84-f176bd4a404c@github.com>
 <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com>
 <efZdJV-6YqzpSkSPpZiNkOLBfL-Wy-Mo9dU1pCMZXKk=.137f5eda-ed24-4d23-b83a-72d62066c562@github.com>
Message-ID: <XkSeb7tk3ExnnFhjeoasAeRo95BdO_9YZTlQKNUHrps=.f7061b93-a2bb-4446-82d4-7f6544e53f83@github.com>

On Thu, 4 May 2023 19:12:14 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736.
>> 
>> Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same.
>
>> [...] I'll see if I can test this on a mandrel build tomorrow...
> 
> @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you?

@jerboaa Thanks very much for testing with mandrel. Based on yours and @olpaw's feedback, I'll refactor this PR to not use the existing `static-libs-image` target for including hotspot `libjvm.a`. I'll also reflect that in the bug & PR titles as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1185426052

From jiangli at openjdk.org  Thu May  4 19:35:39 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 4 May 2023 19:35:39 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v5]
In-Reply-To: <efZdJV-6YqzpSkSPpZiNkOLBfL-Wy-Mo9dU1pCMZXKk=.137f5eda-ed24-4d23-b83a-72d62066c562@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <FzWi7GoZ0xR4YCPgwGvRgCfYotdI-7Qqqvz2sviG53o=.3012efbe-dead-4449-af08-bc29d84554a9@github.com>
 <YiqQPgB_kCzSfCpTIiYKdak9hbtmF85TnnwONq9-e0o=.ac8e2f03-56af-4a6d-b6c8-b3285ff38567@github.com>
 <D1U10iiO7vJHFxmcM1_eRvdB2A43OXy4-301zssm3Xo=.a4564f59-dace-4274-8e38-94dd41f29616@github.com>
 <lQachp5KZeetWQYBnW53t_Pf7DFt7KddHXQ-GLzoUUQ=.bdd12040-f270-478d-ba84-f176bd4a404c@github.com>
 <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com>
 <efZdJV-6YqzpSkSPpZiNkOLBfL-Wy-Mo9dU1pCMZXKk=.137f5eda-ed24-4d23-b83a-72d62066c562@github.com>
Message-ID: <iiAN4S9GuhGEJlIXFhmV1w65KcVCRmu5WUlyDMHCQ2o=.424ce196-c51c-4fbf-8ebf-cd5b1bd0eeb5@github.com>

On Thu, 4 May 2023 19:12:14 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736.
>> 
>> Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same.
>
>> [...] I'll see if I can test this on a mandrel build tomorrow...
> 
> @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you?

> As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736.
> 
> Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same.

@olpaw Thanks for the input. Could you also please take a look of the changes that excludes the object files from the following static libraries from Graal native image usage perspective?

- For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled. 
- For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1185436692

From ecaspole at openjdk.org  Thu May  4 20:25:43 2023
From: ecaspole at openjdk.org (Eric Caspole)
Date: Thu, 4 May 2023 20:25:43 GMT
Subject: RFR: 8307483: New micros for j.u.c.LockSupport
Message-ID: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>

These micros were developed while investigating JDK-8305670 by myself and Sergey Kuksenko. The order of thread creation was important in that bug, so there are 2 JMH for creating sleepers before and after the worker threads.

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

Commit messages:
 - 8307483: New micros for j.u.c.LockSupport

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

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

From rriggs at openjdk.org  Thu May  4 20:37:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 4 May 2023 20:37:31 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v2]
In-Reply-To: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
Message-ID: <8-KhwX0trUkvczzmmsYVivQgyuy_G94MejWHC1C_0Ow=.5836e402-9162-49ce-9ffd-19c26063005a@github.com>

> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
> 
> Neither os.name nor os.arch should be assumed to be changeable; 
> one test case is removed because it assumes os.name can be changed on the command line.

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

 - Remove unused static methods in DefaultImageBuilder
 - Merge branch 'master' into 8304913-os-arch-jlink
 - Merge branch 'master' into 8304913-os-arch-jlink
 - Minor cleanup
 - Merge branch 'master' into 8304913-os-arch-jlink
 - 8304913: Use OperatingSystem, Architecture, and Version in jlink
 - Simplify exception handling
 - Simplify version parsing
 - 8306678: Replace use of os.version with an internal Version record
 - Use and test of "s390" verified by reviewer.
 - ... and 18 more: https://git.openjdk.org/jdk/compare/0c6529d2...5bf9a506

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

Changes: https://git.openjdk.org/jdk/pull/13585/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13585&range=01
  Stats: 156 lines in 7 files changed: 16 ins; 110 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/13585.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13585/head:pull/13585

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

From mcimadamore at openjdk.org  Thu May  4 20:53:32 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 4 May 2023 20:53:32 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <2yJRhrPzbNeYBsrEdaC6xv3ng7kv5LI9IEP20zkoUgc=.b38576ed-a819-404b-9cea-b78b65e24b04@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

The compiler changes look good - I like howthe code got simpler by adding the main class wrapper at parser time. As I suggested elsewhere, do we want to change `Pretty` so that the AST of an unnamed class is rendered like if the unnamed class wasn't there (e.g. so that the output is like the source where the AST comes from) ?

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13689#pullrequestreview-1413902695

From james.laskey at oracle.com  Thu May  4 20:56:22 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 4 May 2023 20:56:22 +0000
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <2yJRhrPzbNeYBsrEdaC6xv3ng7kv5LI9IEP20zkoUgc=.b38576ed-a819-404b-9cea-b78b65e24b04@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
 <2yJRhrPzbNeYBsrEdaC6xv3ng7kv5LI9IEP20zkoUgc=.b38576ed-a819-404b-9cea-b78b65e24b04@github.com>
Message-ID: <C0A39153-4582-43D4-92BF-550D3FC9FF49@oracle.com>

I suppose that?s a possibility. But is it more informative to have the class print with the synthetic flag?

?

> On May 4, 2023, at 5:54 PM, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:
> 
> ?On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:
> 
>>> Add flexible main methods and anonymous main classes to the Java language.
>> 
>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>> - Anonymous main classes renamed to unnamed classes
>> - Add test
> 
> The compiler changes look good - I like howthe code got simpler by adding the main class wrapper at parser time. As I suggested elsewhere, do we want to change `Pretty` so that the AST of an unnamed class is rendered like if the unnamed class wasn't there (e.g. so that the output is like the source where the AST comes from) ?
> 
> -------------
> 
> Marked as reviewed by mcimadamore (Reviewer).
> 
> PR Review: https://git.openjdk.org/jdk/pull/13689#pullrequestreview-1413902695

From dcubed at openjdk.org  Thu May  4 21:13:37 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 4 May 2023 21:13:37 GMT
Subject: RFR: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on
 windows-x64
Message-ID: <P1UmpZvoKKktKi7q53mOBS9MOu3kZjt99oU9swg42U4=.7635133c-ca0a-4dce-9757-126ea59dae55@github.com>

Trivial fixes to ProblemList a few tests:
- [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
- [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64
- [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64

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

Commit messages:
 - get rid of extra blank line.
 - 8307491: ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64
 - 8307490: ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64
 - 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64

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

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

From darcy at openjdk.org  Thu May  4 21:24:14 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 4 May 2023 21:24:14 GMT
Subject: RFR: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java
 on windows-x64
In-Reply-To: <P1UmpZvoKKktKi7q53mOBS9MOu3kZjt99oU9swg42U4=.7635133c-ca0a-4dce-9757-126ea59dae55@github.com>
References: <P1UmpZvoKKktKi7q53mOBS9MOu3kZjt99oU9swg42U4=.7635133c-ca0a-4dce-9757-126ea59dae55@github.com>
Message-ID: <EY3NbZcRqVFRbEAUPmX2P0Av05zMpFltxvfV6gd52Jw=.33eb040d-d6f3-4e72-a6cb-6079dc17ea8e@github.com>

On Thu, 4 May 2023 20:49:26 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList a few tests:
> - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
> - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64
> - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13816#pullrequestreview-1413942638

From dcubed at openjdk.org  Thu May  4 21:35:39 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 4 May 2023 21:35:39 GMT
Subject: RFR: 8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java
 on windows-x64
In-Reply-To: <EY3NbZcRqVFRbEAUPmX2P0Av05zMpFltxvfV6gd52Jw=.33eb040d-d6f3-4e72-a6cb-6079dc17ea8e@github.com>
References: <P1UmpZvoKKktKi7q53mOBS9MOu3kZjt99oU9swg42U4=.7635133c-ca0a-4dce-9757-126ea59dae55@github.com>
 <EY3NbZcRqVFRbEAUPmX2P0Av05zMpFltxvfV6gd52Jw=.33eb040d-d6f3-4e72-a6cb-6079dc17ea8e@github.com>
Message-ID: <bNAIHHKnuD_dPNv3KMdXkhdTujoTAPHtnYFYZlRgq98=.92a37688-c068-49e7-b63e-feae4a7b78e1@github.com>

On Thu, 4 May 2023 21:21:38 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Trivial fixes to ProblemList a few tests:
>> - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
>> - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64
>> - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy - Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/13816#issuecomment-1535438955

From dcubed at openjdk.org  Thu May  4 21:35:40 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Thu, 4 May 2023 21:35:40 GMT
Subject: Integrated: 8307489: ProblemList
 jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
In-Reply-To: <P1UmpZvoKKktKi7q53mOBS9MOu3kZjt99oU9swg42U4=.7635133c-ca0a-4dce-9757-126ea59dae55@github.com>
References: <P1UmpZvoKKktKi7q53mOBS9MOu3kZjt99oU9swg42U4=.7635133c-ca0a-4dce-9757-126ea59dae55@github.com>
Message-ID: <pMB1azRoke_aMHgRzPADeFvcOEuEt7vEvbyY3wFcYLo=.b4ff8a70-1c09-4c81-923e-b48325b282e9@github.com>

On Thu, 4 May 2023 20:49:26 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> Trivial fixes to ProblemList a few tests:
> - [JDK-8307489](https://bugs.openjdk.org/browse/JDK-8307489) ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
> - [JDK-8307490](https://bugs.openjdk.org/browse/JDK-8307490) ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64
> - [JDK-8307491](https://bugs.openjdk.org/browse/JDK-8307491) ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64

This pull request has now been integrated.

Changeset: 111858f3
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/111858f3ff86a15666537df515375fa04ffef048
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8307489: ProblemList jdk/incubator/vector/LoadJsvmlTest.java on windows-x64
8307490: ProblemList sun/security/pkcs11/Cipher/TestKATForGCM.java on linux-x64 and macosx-x64
8307491: ProblemList sanity/client/SwingSet/src/EditorPaneDemoTest.java on linux-x64

Reviewed-by: darcy

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

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

From duke at openjdk.org  Thu May  4 22:08:27 2023
From: duke at openjdk.org (Chris Hennick)
Date: Thu, 4 May 2023 22:08:27 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v19]
In-Reply-To: <wmegzqOmGYmmSpapSq1N2yIsBWcKTXCYDFpUQLwDYrs=.8a7ed0df-4849-4656-a52f-8f99a4963516@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <wmegzqOmGYmmSpapSq1N2yIsBWcKTXCYDFpUQLwDYrs=.8a7ed0df-4849-4656-a52f-8f99a4963516@github.com>
Message-ID: <MlxlnQU0lDmPWrRUn39pEunlHD8M40pVkvyKcG_Jon0=.58d428d8-d44b-4b3a-b9f2-274a22543fe2@github.com>

On Thu, 6 Apr 2023 18:07:29 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.
>
> Chris Hennick has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into patch-1
>  - Merge branch 'master' of https://git.openjdk.org/jdk into patch-1
>  - Merge branch 'master' into patch-1
>  - Update copyright date in RandomNext.java
>  - Update copyright date in RandomGeneratorNext.java
>  - Update copyright date in RandomGeneratorExponentialGaussian.java
>  - Update copyright date in RandomSupport.java
>  - Add parameter to enable/disable fixed PRNG seed
>  - Rewrite Javadoc
>  - Simplify Javadoc description
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/08fbb7bb...2470c00a

@JimLaskey @jddarcy Keep open

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

PR Comment: https://git.openjdk.org/jdk/pull/8131#issuecomment-1535469030

From stuart.marks at oracle.com  Thu May  4 22:45:51 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Thu, 4 May 2023 15:45:51 -0700
Subject: [External] : The introduction of Sequenced collections is not a
 source compatible change
In-Reply-To: <CAEK75Eqq36wRodc=_n-6jsxAMJ2GTF-uPX-6DB2cVVWBTkPwSA@mail.gmail.com>
References: <CAEK75Eqq36wRodc=_n-6jsxAMJ2GTF-uPX-6DB2cVVWBTkPwSA@mail.gmail.com>
Message-ID: <7c4b0336-36f0-0af1-427b-6d983bcbc92c@oracle.com>

The introduction of Sequenced Collections in JDK 21+20 did make a difference in this 
specific case. One can compile R?mi's example on JDK 21+19 successfully, but it will 
fail on JDK 21+20.

Here's R?mi's example:

 ??? public static void m(List<Supplier<? extends Map<String, String>>> factories) {
 ??? }

 ??? public static void main(String[] args) {
 ??????? Supplier<LinkedHashMap<String,String>> supplier1 = LinkedHashMap::new;
 ??????? Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
 ??????? var factories = List.of(supplier1, supplier2);
 ??????? m(factories);
 ??? }

The type of 'factories' is inferred to be a List of the /something/ which is the 
common supertype (least upper bound, or LUB) of the arguments. It's pretty easy to 
see this in an IDE or in jshell. In JDK 21+19 factories is inferred to have this type:

 ??? List<Supplier<? extends Map<String,String>>>

whereas in JDK 21+20 it's inferred to have this type:

 ??? List<Supplier<? extends SequencedMap<String,String>>>

R?mi's example carefully defined the parameter of the m() method so that it matches 
the first (and compiles successfully) but does not match the second (and so fails 
with a compilation error).

This isn't a bug in type inference or in Sequenced Collections. It's a consequence 
of a few phenomena: 1) the result of type inference depends on the exact inputs 
given; 2) the result of type inference depends on the current type hierarchy; 3) 
it's possible to write source code that implicitly depends on a specific result of 
type inference. Sequenced Collections changed the type hierarchy, so inference gave 
different results, and the example depended on getting a specific result under JDK 
21+19.

When you changed the code to List.of(supplier1), this changed the inputs to type 
inference, so it got a different result:

List<Supplier<LinkedHashMap<String,String>>>

This doesn't match the parameter of the m() method, so this gives a compilation 
error on all versions of the system.

As you observed, changing the declaration of m() to be:

 ??? public static void m(List<? extends Supplier<? extends Map<String, String>>> 
factories)

This lets the examples compile on JDK 21+19 and JDK 21+20, whether List.of() is 
given one or both arguments. This change broadens the set of types accepted by m(), 
reducing its specific dependency on a specific arrangement of the type hierarchy. 
It's also probably a good idea in general, as we recommend using wildcard variance 
(? extends T) consistently in order to increase the flexibility of methods. For 
example, I might have a MySupplier functional interface that adds some features to 
the built-in Supplier interface:

 ??? interface MySupplier<T> extends Supplier<T> {
 ??????? // more features
 ??? }

If the suppliers were declared as instances of MySupplier instead, R?mi's example 
would fail even on JDK 21+19. So yes, in a sense, this doesn't have much to do with 
the introduction of Sequenced Collections.

s'marks



On 5/2/23 5:09 AM, Blaise B. wrote:
>
> Hello,
>
> I've tested the example provided by R?mi, and it looks like the compile-time error 
> has little to do with the integration of Sequenced Collections into mainline.
> By changing the "factories" list to contain only one element instead of two, the 
> code does not compile even in previous jdk versions (tested on jdk 17, 18, 19, 20, 
> 21):
>
> ? ? ? ?import java.util.*;
> ? ? ? ?import java.util.function.Supplier;
>
> ? ? ? ?public class SequencedCollectionsTest {
>
> ? ? ? ? ? ? ?public static void m(List<Supplier<? extends Map<String, String>>> 
> factories) {
> ? ? ? ? ? ? ?}
>
> ? ? ? ? ? ? ?public static void main(String[] args) {
> ?Supplier<LinkedHashMap<String,String>> supplier1 = LinkedHashMap::new;
> ?Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>
> ? ? ? ? ? ? ? ? ? ? ? ?//var factories = List.of(supplier1, supplier2);
> ? ? ? ? ? ? ? ? ? ? ? ?var factories = List.of(supplier1);
>
> ? ? ? ? ? ? ? ? ? ? ? ?m(factories);
> ? ? ? ? ? ? ?}
> ? ? ? }
>
> It all only compiles on all versions when I change the signature of the method m() to:
>
> ? ? ? ? ? public static void m(List<? extends Supplier<? extends Map<String, 
> String>>> factories) {
> ? ? ? ? ? }
>
> So unless there are more other cases of failing compiles, it seems to me like 
> something was actually fixed in the latest jdk21 build, and that the integration 
> of Sequenced Collections was just coincidence.
>
> Hope this helps.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230504/edcec4d3/attachment-0001.htm>

From liach at openjdk.org  Thu May  4 23:36:16 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 4 May 2023 23:36:16 GMT
Subject: RFR: 8307149: MethodHandles.arrayConstructor can be cached
Message-ID: <kv9jhsDXlC0UFfuu5ZAjPRXan95MAGR5P8FNSOqcCuA=.bfee7128-8de3-437b-a019-d78135e057f2@github.com>

This patch migrates `MethodHandles::arrayConstructor`, added in Java 9 as a hotfix to the incorrect constructor found on arrays via Lookup, to share the array access caching features. The result is that calling `MethodHandles.arrayConstructor` to create method handles is much faster.

Oracle JDK 20:

Benchmark                                             Mode  Cnt   Score   Error  Units
MethodHandlesArrayConstructor.createWithAnewarray     avgt   15   2.739 ? 0.058  ns/op
MethodHandlesArrayConstructor.createWithMethodHandle  avgt   15   3.313 ? 0.041  ns/op
MethodHandlesArrayConstructor.methodHandleCreation    avgt   15  61.874 ? 0.397  ns/op


This patch:

Benchmark                                             Mode  Cnt  Score   Error  Units
MethodHandlesArrayConstructor.createWithAnewarray     avgt   15  3.067 ? 0.026  ns/op
MethodHandlesArrayConstructor.createWithMethodHandle  avgt   15  3.699 ? 0.042  ns/op
MethodHandlesArrayConstructor.methodHandleCreation    avgt   15  1.447 ? 0.004  ns/op

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

Commit messages:
 - bug
 - 8307149: MethodHandles.arrayConstructor can be cached

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

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

From javalists at cbfiddle.com  Fri May  5 01:26:27 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Thu, 4 May 2023 18:26:27 -0700
Subject: [External] : The introduction of Sequenced collections is not a
 source compatible change
In-Reply-To: <7c4b0336-36f0-0af1-427b-6d983bcbc92c@oracle.com>
References: <CAEK75Eqq36wRodc=_n-6jsxAMJ2GTF-uPX-6DB2cVVWBTkPwSA@mail.gmail.com>
 <7c4b0336-36f0-0af1-427b-6d983bcbc92c@oracle.com>
Message-ID: <2445589A-75AB-4914-8ACC-978E6860ECC4@cbfiddle.com>

This is an interesting issue, and it raises the question of how such issues are resolved.

My impression is that historically source code compatibility was given a high weight.
Is that not the case now?

Although the example may be carefully constructed, my understanding is that the problem
surfaced with programs that were not intentionally constructed to show this problem.

This issue is more general than the examples in your compatibility analysis report,
which I believe are limited to fixed sets of class names and method names.

Although you say that this issue does not represent a ?bug? in type inference, I can?t help but
wonder whether a more flexible type system could handle this change without breaking
source compatibility.

If so, then a case could be made to delay the introduction of Sequenced Collections until the
type system can handle it without source incompatibility. Java has survived for many years
without Sequenced Collections. I don?t see a need to rush them out the door.

Being able to compatibly add new common supertypes would be valuable.

There are many other reasons for improving the type system. Of particular interest to me is
the mismatch between the current subtyping rules for parameterized types and the needs
of immutable collection types. (I understand that JDK did not go down this path, but
others have and will.)



> On May 4, 2023, at 3:45 PM, Stuart Marks <stuart.marks at oracle.com> wrote:
> 
> The introduction of Sequenced Collections in JDK 21+20 did make a difference in this specific case. One can compile R?mi's example on JDK 21+19 successfully, but it will fail on JDK 21+20.
> 
> Here's R?mi's example:
> 
>     public static void m(List<Supplier<? extends Map<String, String>>> factories) {
>     }
> 
>     public static void main(String[] args) {
>         Supplier<LinkedHashMap<String,String>> supplier1 = LinkedHashMap::new;
>         Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>         var factories = List.of(supplier1, supplier2);
>         m(factories);
>     }
> 
> The type of 'factories' is inferred to be a List of the something which is the common supertype (least upper bound, or LUB) of the arguments. It's pretty easy to see this in an IDE or in jshell. In JDK 21+19 factories is inferred to have this type:
> 
>     List<Supplier<? extends Map<String,String>>>
> 
> whereas in JDK 21+20 it's inferred to have this type:
> 
>     List<Supplier<? extends SequencedMap<String,String>>>
> 
> R?mi's example carefully defined the parameter of the m() method so that it matches the first (and compiles successfully) but does not match the second (and so fails with a compilation error).
> 
> This isn't a bug in type inference or in Sequenced Collections. It's a consequence of a few phenomena: 1) the result of type inference depends on the exact inputs given; 2) the result of type inference depends on the current type hierarchy; 3) it's possible to write source code that implicitly depends on a specific result of type inference. Sequenced Collections changed the type hierarchy, so inference gave different results, and the example depended on getting a specific result under JDK 21+19.
> 
> When you changed the code to List.of(supplier1), this changed the inputs to type inference, so it got a different result:
> 
>     List<Supplier<LinkedHashMap<String,String>>>
> 
> This doesn't match the parameter of the m() method, so this gives a compilation error on all versions of the system.
> 
> As you observed, changing the declaration of m() to be:
> 
>     public static void m(List<? extends Supplier<? extends Map<String, String>>> factories)
> 
> This lets the examples compile on JDK 21+19 and JDK 21+20, whether List.of() is given one or both arguments. This change broadens the set of types accepted by m(), reducing its specific dependency on a specific arrangement of the type hierarchy. It's also probably a good idea in general, as we recommend using wildcard variance (? extends T) consistently in order to increase the flexibility of methods. For example, I might have a MySupplier functional interface that adds some features to the built-in Supplier interface:
> 
>     interface MySupplier<T> extends Supplier<T> {
>         // more features
>     }
> 
> If the suppliers were declared as instances of MySupplier instead, R?mi's example would fail even on JDK 21+19. So yes, in a sense, this doesn't have much to do with the introduction of Sequenced Collections.
> 
> s'marks
> 
> 
> 
> 
> 
> On 5/2/23 5:09 AM, Blaise B. wrote:
>> 
>> Hello,
>> 
>> I've tested the example provided by R?mi, and it looks like the compile-time error has little to do with the integration of Sequenced Collections into mainline.
>> By changing the "factories" list to contain only one element instead of two, the code does not compile even in previous jdk versions (tested on jdk 17, 18, 19, 20, 21):
>> 
>>        import java.util.*;
>>        import java.util.function.Supplier;
>> 
>>        public class SequencedCollectionsTest {
>> 
>>              public static void m(List<Supplier<? extends Map<String, String>>> factories) {
>>              }
>> 
>>              public static void main(String[] args) {
>>                        Supplier<LinkedHashMap<String,String>> supplier1 = LinkedHashMap::new;
>>                        Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>> 
>>                        //var factories = List.of(supplier1, supplier2);
>>                        var factories = List.of(supplier1);
>> 
>>                        m(factories);
>>              }
>>       }
>> 
>> It all only compiles on all versions when I change the signature of the method m() to:
>> 
>>           public static void m(List<? extends Supplier<? extends Map<String, String>>> factories) {
>>           }
>> 
>> So unless there are more other cases of failing compiles, it seems to me like something was actually fixed in the latest jdk21 build, and that the integration of Sequenced Collections was just coincidence.
>> 
>> Hope this helps.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230504/72e522d0/attachment-0001.htm>

From joe.darcy at oracle.com  Fri May  5 02:38:16 2023
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 4 May 2023 19:38:16 -0700
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
 <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
 <CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com>
Message-ID: <46167980-41fe-e214-9b67-ce0c5ca8c032@oracle.com>

A few comments on the general compatibility policy for the JDK. 
Compatibility is looked after by the Compatibility and Specification 
Review (CSR) process ( Compatibility & Specification Review). 
Summarizing the approach,

> The general compatibility policy for exported APIs implemented in the 
> JDK is:
>
> ??? * Don't break binary compatibility (as defined in the Java 
> Language Specification) without sufficient cause.
> ??? * Avoid introducing source incompatibilities.
> ??? * Manage behavioral compatibility changes.

https://wiki.openjdk.org/display/csr/Main

None of binary, source, and behavioral compatibly are absolutes and 
judgement is used to assess the cost/benefits of changes. For example, 
strict source compatibility would preclude, say, introducing new public 
types in the java.lang package since the implicit import of types in 
java.lang could conflict with a same-named type *-imported from another? 
package.

When a proposed change is estimated to be sufficiently disruptive, we 
conduct a corpus experiment to evaluate the impact on the change on many 
public Java libraries. Back in Project Coin in JDK 7, that basic 
approach was used to help quantify various language design choices and 
the infrastructure to run such experiments has been built-out in the 
subsequent releases.

HTH,

-Joe
CSR Group Lead

On 5/4/2023 6:32 AM, Ethan McCue wrote:
> I guess this a good time to ask, ignoring the benefit part of a cost 
> benefit analysis, what mechanisms do we have to measure the number of 
> codebases relying on type inference this will break?
>
> Iirc Adoptium built/ran the unit tests of a bunch of public repos, but 
> it's also a bit shocking if the jtreg suite had nothing for this.
>
> On Thu, May 4, 2023, 9:27 AM Raffaello Giulietti 
> <raffaello.giulietti at oracle.com> wrote:
>
>     Without changing the semantics at all, you could also write
>
>     ? ? ? ? final List<Collection<String>> list =
>     Stream.<Collection<String>>of(nestedDequeue, nestedList).toList();
>
>     to "help" type inference.
>
>
>
>
>     On 2023-05-03 15:12, forax at univ-mlv.fr wrote:
>     > Another example sent to me by a fellow French guy,
>     >
>     >? ? ? final Deque<String> nestedDequeue = new ArrayDeque<>();
>     >? ? ? nestedDequeue.addFirst("C");
>     >? ? ? nestedDequeue.addFirst("B");
>     >? ? ? nestedDequeue.addFirst("A");
>     >
>     >? ? ? final List<String> nestedList = new ArrayList<>();
>     >? ? ? nestedList.add("D");
>     >? ? ? nestedList.add("E");
>     >? ? ? nestedList.add("F");
>     >
>     >? ? ? final List<Collection<String>> list =
>     Stream.of(nestedDequeue, nestedList).toList();
>     >
>     > This one is cool because no 'var' is involved and using
>     collect(Collectors.toList()) instead of toList() solves the
>     inference problem.
>     >
>     > R?mi
>     >
>     > ----- Original Message -----
>     >> From: "Stuart Marks" <stuart.marks at oracle.com>
>     >> To: "Remi Forax" <forax at univ-mlv.fr>
>     >> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>     >> Sent: Tuesday, May 2, 2023 2:44:28 AM
>     >> Subject: Re: The introduction of Sequenced collections is not a
>     source compatible change
>     >
>     >> Hi R?mi,
>     >>
>     >> Thanks for trying out the latest build!
>     >>
>     >> I'll make sure this gets mentioned in the release note for
>     Sequenced
>     >> Collections.
>     >> We'll also raise this issue when we talk about this feature in
>     the Quality
>     >> Outreach
>     >> program.
>     >>
>     >> s'marks
>     >>
>     >> On 4/29/23 3:46 AM, Remi Forax wrote:
>     >>> I've several repositories that now fails to compile with the
>     latest jdk21, which
>     >>> introduces sequence collections.
>     >>>
>     >>> The introduction of a common supertype to existing collections
>     is *not* a source
>     >>> compatible change because of type inference.
>     >>>
>     >>> Here is a simplified example:
>     >>>
>     >>>? ? ?public static void m(List<Supplier<? extends Map<String,
>     String>>> factories) {
>     >>>? ? ?}
>     >>>
>     >>>? ? ?public static void main(String[] args) {
>     >>> ?Supplier<LinkedHashMap<String,String>> supplier1 =
>     LinkedHashMap::new;
>     >>> ?Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>     >>>? ? ? ?var factories = List.of(supplier1, supplier2);
>     >>>? ? ? ?m(factories);
>     >>>? ? ?}
>     >>>
>     >>>
>     >>> This example compiles fine with Java 20 but report an error
>     with Java 21:
>     >>>? ? ?SequencedCollectionBug.java:28: error: method m in class
>     SequencedCollectionBug
>     >>>? ? ?cannot be applied to given types;
>     >>>? ? ? ?m(factories);
>     >>>? ? ? ?^
>     >>>? ? ?required: List<Supplier<? extends Map<String,String>>>
>     >>>? ? ?found:? ? List<Supplier<? extends
>     SequencedMap<String,String>>>
>     >>>? ? ?reason: argument mismatch; List<Supplier<? extends
>     SequencedMap<String,String>>>
>     >>>? ? ?cannot be converted to List<Supplier<? extends
>     Map<String,String>>>
>     >>>
>     >>>
>     >>>
>     >>> Apart from the example above, most of the failures I see are
>     in the unit tests
>     >>> provided to the students, because we are using a lot of 'var'
>     in them so they
>     >>> work whatever the name of the types chosen by the students.
>     >>>
>     >>> Discussing with a colleague, we also believe that this bug is
>     not limited to
>     >>> Java, existing Kotlin codes will also fail to compile due to
>     this bug.
>     >>>
>     >>> Regards,
>     >>> R?mi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230504/4ff82806/attachment.htm>

From liangchenblue at gmail.com  Fri May  5 02:47:14 2023
From: liangchenblue at gmail.com (-)
Date: Thu, 4 May 2023 21:47:14 -0500
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <46167980-41fe-e214-9b67-ce0c5ca8c032@oracle.com>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
 <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
 <CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com>
 <46167980-41fe-e214-9b67-ce0c5ca8c032@oracle.com>
Message-ID: <CABe8uE2n2ozgJzRk_N-a2Pq37FTBJtWJhuxKUT6KG+2hR0TZLg@mail.gmail.com>

In addition, in the CSR of sequenced collection, it already
anticipated some other form of source incompatibility:
If a class implements List and Deque at the same time, the return type
of reversed() must extend both interfaces as well.

This alone would be a greater source incompatibility than this type
interference already; however, both are binarily compatible:
Java doesn't care about generics at runtime, and for default
reversed() overrides, reversed ()Ljava/util/List; and reversed
()Ljava/util/Deque; are distinct methods; code calling reversed via
List or Deque interfaces will get the reversed version of respective
interfaces, which are functionally correct as well.

I personally would consider this type inference usage moot. It is same
as adding another method addAll(List<String>) when there is already
addAll(String[]): existing addAll(null) calls will break, but this is
not a valid argument against adding a List<String> variant of addAll.

On Thu, May 4, 2023 at 9:38?PM Joseph D. Darcy <joe.darcy at oracle.com> wrote:
>
> A few comments on the general compatibility policy for the JDK. Compatibility is looked after by the Compatibility and Specification Review (CSR) process ( Compatibility & Specification Review). Summarizing the approach,
>
> The general compatibility policy for exported APIs implemented in the JDK is:
>
>     * Don't break binary compatibility (as defined in the Java Language Specification) without sufficient cause.
>     * Avoid introducing source incompatibilities.
>     * Manage behavioral compatibility changes.
>
> https://wiki.openjdk.org/display/csr/Main
>
> None of binary, source, and behavioral compatibly are absolutes and judgement is used to assess the cost/benefits of changes. For example, strict source compatibility would preclude, say, introducing new public types in the java.lang package since the implicit import of types in java.lang could conflict with a same-named type *-imported from another  package.
>
> When a proposed change is estimated to be sufficiently disruptive, we conduct a corpus experiment to evaluate the impact on the change on many public Java libraries. Back in Project Coin in JDK 7, that basic approach was used to help quantify various language design choices and the infrastructure to run such experiments has been built-out in the subsequent releases.
>
> HTH,
>
> -Joe
> CSR Group Lead
>
> On 5/4/2023 6:32 AM, Ethan McCue wrote:
>
> I guess this a good time to ask, ignoring the benefit part of a cost benefit analysis, what mechanisms do we have to measure the number of codebases relying on type inference this will break?
>
> Iirc Adoptium built/ran the unit tests of a bunch of public repos, but it's also a bit shocking if the jtreg suite had nothing for this.
>
> On Thu, May 4, 2023, 9:27 AM Raffaello Giulietti <raffaello.giulietti at oracle.com> wrote:
>>
>> Without changing the semantics at all, you could also write
>>
>>         final List<Collection<String>> list =
>> Stream.<Collection<String>>of(nestedDequeue, nestedList).toList();
>>
>> to "help" type inference.
>>
>>
>>
>>
>> On 2023-05-03 15:12, forax at univ-mlv.fr wrote:
>> > Another example sent to me by a fellow French guy,
>> >
>> >      final Deque<String> nestedDequeue = new ArrayDeque<>();
>> >      nestedDequeue.addFirst("C");
>> >      nestedDequeue.addFirst("B");
>> >      nestedDequeue.addFirst("A");
>> >
>> >      final List<String> nestedList = new ArrayList<>();
>> >      nestedList.add("D");
>> >      nestedList.add("E");
>> >      nestedList.add("F");
>> >
>> >      final List<Collection<String>> list = Stream.of(nestedDequeue, nestedList).toList();
>> >
>> > This one is cool because no 'var' is involved and using collect(Collectors.toList()) instead of toList() solves the inference problem.
>> >
>> > R?mi
>> >
>> > ----- Original Message -----
>> >> From: "Stuart Marks" <stuart.marks at oracle.com>
>> >> To: "Remi Forax" <forax at univ-mlv.fr>
>> >> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> >> Sent: Tuesday, May 2, 2023 2:44:28 AM
>> >> Subject: Re: The introduction of Sequenced collections is not a source compatible change
>> >
>> >> Hi R?mi,
>> >>
>> >> Thanks for trying out the latest build!
>> >>
>> >> I'll make sure this gets mentioned in the release note for Sequenced
>> >> Collections.
>> >> We'll also raise this issue when we talk about this feature in the Quality
>> >> Outreach
>> >> program.
>> >>
>> >> s'marks
>> >>
>> >> On 4/29/23 3:46 AM, Remi Forax wrote:
>> >>> I've several repositories that now fails to compile with the latest jdk21, which
>> >>> introduces sequence collections.
>> >>>
>> >>> The introduction of a common supertype to existing collections is *not* a source
>> >>> compatible change because of type inference.
>> >>>
>> >>> Here is a simplified example:
>> >>>
>> >>>     public static void m(List<Supplier<? extends Map<String, String>>> factories) {
>> >>>     }
>> >>>
>> >>>     public static void main(String[] args) {
>> >>>       Supplier<LinkedHashMap<String,String>> supplier1 = LinkedHashMap::new;
>> >>>       Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>> >>>       var factories = List.of(supplier1, supplier2);
>> >>>       m(factories);
>> >>>     }
>> >>>
>> >>>
>> >>> This example compiles fine with Java 20 but report an error with Java 21:
>> >>>     SequencedCollectionBug.java:28: error: method m in class SequencedCollectionBug
>> >>>     cannot be applied to given types;
>> >>>       m(factories);
>> >>>       ^
>> >>>     required: List<Supplier<? extends Map<String,String>>>
>> >>>     found:    List<Supplier<? extends SequencedMap<String,String>>>
>> >>>     reason: argument mismatch; List<Supplier<? extends SequencedMap<String,String>>>
>> >>>     cannot be converted to List<Supplier<? extends Map<String,String>>>
>> >>>
>> >>>
>> >>>
>> >>> Apart from the example above, most of the failures I see are in the unit tests
>> >>> provided to the students, because we are using a lot of 'var' in them so they
>> >>> work whatever the name of the types chosen by the students.
>> >>>
>> >>> Discussing with a colleague, we also believe that this bug is not limited to
>> >>> Java, existing Kotlin codes will also fail to compile due to this bug.
>> >>>
>> >>> Regards,
>> >>> R?mi

From liach at openjdk.org  Fri May  5 02:53:18 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 May 2023 02:53:18 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v11]
In-Reply-To: <GCGqTY2WFItzQskhXUniB2WzT2-mEoHAjUiNPiAwyOU=.e55479cd-3ad5-47c9-80c6-459f5c18436e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <GCGqTY2WFItzQskhXUniB2WzT2-mEoHAjUiNPiAwyOU=.e55479cd-3ad5-47c9-80c6-459f5c18436e@github.com>
Message-ID: <eNS31_a27NgKfDF-wlHaQ7zasU_xB7uqbtemOTUBlVk=.7e2780d6-a304-4342-8f6a-1088d9a0bd2c@github.com>

On Thu, 4 May 2023 16:19:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API didn't handle transformations of class files version 50 and below correctly. 
>> 
>> Proposed fix have two parts: 
>> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
>> 2. StackMapTable attribute is not generated for class file versions below 50.
>> 
>> StackMapsTest is also extended to test this patch.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Thanks for review.
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

Since we want an option to toggle stackmap generation, will you add it to the Classfile options as a temporary measure, before we keep track of these options in a stateful object (with hierarchy resolver etc.) like brian envisioned?

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

PR Comment: https://git.openjdk.org/jdk/pull/13478#issuecomment-1535631393

From joe.darcy at oracle.com  Fri May  5 04:08:35 2023
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 4 May 2023 21:08:35 -0700
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <CABe8uE2n2ozgJzRk_N-a2Pq37FTBJtWJhuxKUT6KG+2hR0TZLg@mail.gmail.com>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
 <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
 <CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com>
 <46167980-41fe-e214-9b67-ce0c5ca8c032@oracle.com>
 <CABe8uE2n2ozgJzRk_N-a2Pq37FTBJtWJhuxKUT6KG+2hR0TZLg@mail.gmail.com>
Message-ID: <df447921-ebc1-e683-70f0-54da9b6621d0@oracle.com>

PS And as a general policy, over the releases we've done more to 
preserve source compatibility when possible for language changes.

For example, there were many source compatibility breakages when 
"assert" was added as a keyword back in JDK 1.4; the current keyword 
management policies (https://openjdk.org/jeps/8223002), including 
contextual keywords (JLS ?3.9) and hyphenated-keywords, mitigate the 
impact of analogous changes today.

-Joe

On 5/4/2023 7:47 PM, - wrote:
> In addition, in the CSR of sequenced collection, it already
> anticipated some other form of source incompatibility:
> If a class implements List and Deque at the same time, the return type
> of reversed() must extend both interfaces as well.
>
> This alone would be a greater source incompatibility than this type
> interference already; however, both are binarily compatible:
> Java doesn't care about generics at runtime, and for default
> reversed() overrides, reversed ()Ljava/util/List; and reversed
> ()Ljava/util/Deque; are distinct methods; code calling reversed via
> List or Deque interfaces will get the reversed version of respective
> interfaces, which are functionally correct as well.
>
> I personally would consider this type inference usage moot. It is same
> as adding another method addAll(List<String>) when there is already
> addAll(String[]): existing addAll(null) calls will break, but this is
> not a valid argument against adding a List<String> variant of addAll.
>
> On Thu, May 4, 2023 at 9:38?PM Joseph D. Darcy <joe.darcy at oracle.com> wrote:
>> A few comments on the general compatibility policy for the JDK. Compatibility is looked after by the Compatibility and Specification Review (CSR) process ( Compatibility & Specification Review). Summarizing the approach,
>>
>> The general compatibility policy for exported APIs implemented in the JDK is:
>>
>>      * Don't break binary compatibility (as defined in the Java Language Specification) without sufficient cause.
>>      * Avoid introducing source incompatibilities.
>>      * Manage behavioral compatibility changes.
>>
>> https://wiki.openjdk.org/display/csr/Main
>>
>> None of binary, source, and behavioral compatibly are absolutes and judgement is used to assess the cost/benefits of changes. For example, strict source compatibility would preclude, say, introducing new public types in the java.lang package since the implicit import of types in java.lang could conflict with a same-named type *-imported from another  package.
>>
>> When a proposed change is estimated to be sufficiently disruptive, we conduct a corpus experiment to evaluate the impact on the change on many public Java libraries. Back in Project Coin in JDK 7, that basic approach was used to help quantify various language design choices and the infrastructure to run such experiments has been built-out in the subsequent releases.
>>
>> HTH,
>>
>> -Joe
>> CSR Group Lead
>>
>> On 5/4/2023 6:32 AM, Ethan McCue wrote:
>>
>> I guess this a good time to ask, ignoring the benefit part of a cost benefit analysis, what mechanisms do we have to measure the number of codebases relying on type inference this will break?
>>
>> Iirc Adoptium built/ran the unit tests of a bunch of public repos, but it's also a bit shocking if the jtreg suite had nothing for this.
>>
>> On Thu, May 4, 2023, 9:27 AM Raffaello Giulietti <raffaello.giulietti at oracle.com> wrote:
>>> Without changing the semantics at all, you could also write
>>>
>>>          final List<Collection<String>> list =
>>> Stream.<Collection<String>>of(nestedDequeue, nestedList).toList();
>>>
>>> to "help" type inference.
>>>
>>>
>>>
>>>
>>> On 2023-05-03 15:12, forax at univ-mlv.fr wrote:
>>>> Another example sent to me by a fellow French guy,
>>>>
>>>>       final Deque<String> nestedDequeue = new ArrayDeque<>();
>>>>       nestedDequeue.addFirst("C");
>>>>       nestedDequeue.addFirst("B");
>>>>       nestedDequeue.addFirst("A");
>>>>
>>>>       final List<String> nestedList = new ArrayList<>();
>>>>       nestedList.add("D");
>>>>       nestedList.add("E");
>>>>       nestedList.add("F");
>>>>
>>>>       final List<Collection<String>> list = Stream.of(nestedDequeue, nestedList).toList();
>>>>
>>>> This one is cool because no 'var' is involved and using collect(Collectors.toList()) instead of toList() solves the inference problem.
>>>>
>>>> R?mi
>>>>
>>>> ----- Original Message -----
>>>>> From: "Stuart Marks" <stuart.marks at oracle.com>
>>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>>>> Sent: Tuesday, May 2, 2023 2:44:28 AM
>>>>> Subject: Re: The introduction of Sequenced collections is not a source compatible change
>>>>> Hi R?mi,
>>>>>
>>>>> Thanks for trying out the latest build!
>>>>>
>>>>> I'll make sure this gets mentioned in the release note for Sequenced
>>>>> Collections.
>>>>> We'll also raise this issue when we talk about this feature in the Quality
>>>>> Outreach
>>>>> program.
>>>>>
>>>>> s'marks
>>>>>
>>>>> On 4/29/23 3:46 AM, Remi Forax wrote:
>>>>>> I've several repositories that now fails to compile with the latest jdk21, which
>>>>>> introduces sequence collections.
>>>>>>
>>>>>> The introduction of a common supertype to existing collections is *not* a source
>>>>>> compatible change because of type inference.
>>>>>>
>>>>>> Here is a simplified example:
>>>>>>
>>>>>>      public static void m(List<Supplier<? extends Map<String, String>>> factories) {
>>>>>>      }
>>>>>>
>>>>>>      public static void main(String[] args) {
>>>>>>        Supplier<LinkedHashMap<String,String>> supplier1 = LinkedHashMap::new;
>>>>>>        Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>>>>>>        var factories = List.of(supplier1, supplier2);
>>>>>>        m(factories);
>>>>>>      }
>>>>>>
>>>>>>
>>>>>> This example compiles fine with Java 20 but report an error with Java 21:
>>>>>>      SequencedCollectionBug.java:28: error: method m in class SequencedCollectionBug
>>>>>>      cannot be applied to given types;
>>>>>>        m(factories);
>>>>>>        ^
>>>>>>      required: List<Supplier<? extends Map<String,String>>>
>>>>>>      found:    List<Supplier<? extends SequencedMap<String,String>>>
>>>>>>      reason: argument mismatch; List<Supplier<? extends SequencedMap<String,String>>>
>>>>>>      cannot be converted to List<Supplier<? extends Map<String,String>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Apart from the example above, most of the failures I see are in the unit tests
>>>>>> provided to the students, because we are using a lot of 'var' in them so they
>>>>>> work whatever the name of the types chosen by the students.
>>>>>>
>>>>>> Discussing with a colleague, we also believe that this bug is not limited to
>>>>>> Java, existing Kotlin codes will also fail to compile due to this bug.
>>>>>>
>>>>>> Regards,
>>>>>> R?mi

From ethan at mccue.dev  Fri May  5 04:50:56 2023
From: ethan at mccue.dev (Ethan McCue)
Date: Fri, 5 May 2023 00:50:56 -0400
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <df447921-ebc1-e683-70f0-54da9b6621d0@oracle.com>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
 <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
 <CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com>
 <46167980-41fe-e214-9b67-ce0c5ca8c032@oracle.com>
 <CABe8uE2n2ozgJzRk_N-a2Pq37FTBJtWJhuxKUT6KG+2hR0TZLg@mail.gmail.com>
 <df447921-ebc1-e683-70f0-54da9b6621d0@oracle.com>
Message-ID: <CA+NR86iEcoPn754gd-h=4ibkTyPDaY_UthP23ExY0eBPvruqRw@mail.gmail.com>

For those who are tracking but didn't click through to find it, here was
the writeup of the compatibility analysis for sequenced collections as of
9/20/22.

https://bugs.openjdk.org/secure/attachment/100811/compatibility-20220920.html

Bug page:

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




On Fri, May 5, 2023 at 12:08?AM Joseph D. Darcy <joe.darcy at oracle.com>
wrote:

> PS And as a general policy, over the releases we've done more to
> preserve source compatibility when possible for language changes.
>
> For example, there were many source compatibility breakages when
> "assert" was added as a keyword back in JDK 1.4; the current keyword
> management policies (https://openjdk.org/jeps/8223002), including
> contextual keywords (JLS ?3.9) and hyphenated-keywords, mitigate the
> impact of analogous changes today.
>
> -Joe
>
> On 5/4/2023 7:47 PM, - wrote:
> > In addition, in the CSR of sequenced collection, it already
> > anticipated some other form of source incompatibility:
> > If a class implements List and Deque at the same time, the return type
> > of reversed() must extend both interfaces as well.
> >
> > This alone would be a greater source incompatibility than this type
> > interference already; however, both are binarily compatible:
> > Java doesn't care about generics at runtime, and for default
> > reversed() overrides, reversed ()Ljava/util/List; and reversed
> > ()Ljava/util/Deque; are distinct methods; code calling reversed via
> > List or Deque interfaces will get the reversed version of respective
> > interfaces, which are functionally correct as well.
> >
> > I personally would consider this type inference usage moot. It is same
> > as adding another method addAll(List<String>) when there is already
> > addAll(String[]): existing addAll(null) calls will break, but this is
> > not a valid argument against adding a List<String> variant of addAll.
> >
> > On Thu, May 4, 2023 at 9:38?PM Joseph D. Darcy <joe.darcy at oracle.com>
> wrote:
> >> A few comments on the general compatibility policy for the JDK.
> Compatibility is looked after by the Compatibility and Specification Review
> (CSR) process ( Compatibility & Specification Review). Summarizing the
> approach,
> >>
> >> The general compatibility policy for exported APIs implemented in the
> JDK is:
> >>
> >>      * Don't break binary compatibility (as defined in the Java
> Language Specification) without sufficient cause.
> >>      * Avoid introducing source incompatibilities.
> >>      * Manage behavioral compatibility changes.
> >>
> >> https://wiki.openjdk.org/display/csr/Main
> >>
> >> None of binary, source, and behavioral compatibly are absolutes and
> judgement is used to assess the cost/benefits of changes. For example,
> strict source compatibility would preclude, say, introducing new public
> types in the java.lang package since the implicit import of types in
> java.lang could conflict with a same-named type *-imported from another
> package.
> >>
> >> When a proposed change is estimated to be sufficiently disruptive, we
> conduct a corpus experiment to evaluate the impact on the change on many
> public Java libraries. Back in Project Coin in JDK 7, that basic approach
> was used to help quantify various language design choices and the
> infrastructure to run such experiments has been built-out in the subsequent
> releases.
> >>
> >> HTH,
> >>
> >> -Joe
> >> CSR Group Lead
> >>
> >> On 5/4/2023 6:32 AM, Ethan McCue wrote:
> >>
> >> I guess this a good time to ask, ignoring the benefit part of a cost
> benefit analysis, what mechanisms do we have to measure the number of
> codebases relying on type inference this will break?
> >>
> >> Iirc Adoptium built/ran the unit tests of a bunch of public repos, but
> it's also a bit shocking if the jtreg suite had nothing for this.
> >>
> >> On Thu, May 4, 2023, 9:27 AM Raffaello Giulietti <
> raffaello.giulietti at oracle.com> wrote:
> >>> Without changing the semantics at all, you could also write
> >>>
> >>>          final List<Collection<String>> list =
> >>> Stream.<Collection<String>>of(nestedDequeue, nestedList).toList();
> >>>
> >>> to "help" type inference.
> >>>
> >>>
> >>>
> >>>
> >>> On 2023-05-03 15:12, forax at univ-mlv.fr wrote:
> >>>> Another example sent to me by a fellow French guy,
> >>>>
> >>>>       final Deque<String> nestedDequeue = new ArrayDeque<>();
> >>>>       nestedDequeue.addFirst("C");
> >>>>       nestedDequeue.addFirst("B");
> >>>>       nestedDequeue.addFirst("A");
> >>>>
> >>>>       final List<String> nestedList = new ArrayList<>();
> >>>>       nestedList.add("D");
> >>>>       nestedList.add("E");
> >>>>       nestedList.add("F");
> >>>>
> >>>>       final List<Collection<String>> list = Stream.of(nestedDequeue,
> nestedList).toList();
> >>>>
> >>>> This one is cool because no 'var' is involved and using
> collect(Collectors.toList()) instead of toList() solves the inference
> problem.
> >>>>
> >>>> R?mi
> >>>>
> >>>> ----- Original Message -----
> >>>>> From: "Stuart Marks" <stuart.marks at oracle.com>
> >>>>> To: "Remi Forax" <forax at univ-mlv.fr>
> >>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> >>>>> Sent: Tuesday, May 2, 2023 2:44:28 AM
> >>>>> Subject: Re: The introduction of Sequenced collections is not a
> source compatible change
> >>>>> Hi R?mi,
> >>>>>
> >>>>> Thanks for trying out the latest build!
> >>>>>
> >>>>> I'll make sure this gets mentioned in the release note for Sequenced
> >>>>> Collections.
> >>>>> We'll also raise this issue when we talk about this feature in the
> Quality
> >>>>> Outreach
> >>>>> program.
> >>>>>
> >>>>> s'marks
> >>>>>
> >>>>> On 4/29/23 3:46 AM, Remi Forax wrote:
> >>>>>> I've several repositories that now fails to compile with the latest
> jdk21, which
> >>>>>> introduces sequence collections.
> >>>>>>
> >>>>>> The introduction of a common supertype to existing collections is
> *not* a source
> >>>>>> compatible change because of type inference.
> >>>>>>
> >>>>>> Here is a simplified example:
> >>>>>>
> >>>>>>      public static void m(List<Supplier<? extends Map<String,
> String>>> factories) {
> >>>>>>      }
> >>>>>>
> >>>>>>      public static void main(String[] args) {
> >>>>>>        Supplier<LinkedHashMap<String,String>> supplier1 =
> LinkedHashMap::new;
> >>>>>>        Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
> >>>>>>        var factories = List.of(supplier1, supplier2);
> >>>>>>        m(factories);
> >>>>>>      }
> >>>>>>
> >>>>>>
> >>>>>> This example compiles fine with Java 20 but report an error with
> Java 21:
> >>>>>>      SequencedCollectionBug.java:28: error: method m in class
> SequencedCollectionBug
> >>>>>>      cannot be applied to given types;
> >>>>>>        m(factories);
> >>>>>>        ^
> >>>>>>      required: List<Supplier<? extends Map<String,String>>>
> >>>>>>      found:    List<Supplier<? extends SequencedMap<String,String>>>
> >>>>>>      reason: argument mismatch; List<Supplier<? extends
> SequencedMap<String,String>>>
> >>>>>>      cannot be converted to List<Supplier<? extends
> Map<String,String>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> Apart from the example above, most of the failures I see are in the
> unit tests
> >>>>>> provided to the students, because we are using a lot of 'var' in
> them so they
> >>>>>> work whatever the name of the types chosen by the students.
> >>>>>>
> >>>>>> Discussing with a colleague, we also believe that this bug is not
> limited to
> >>>>>> Java, existing Kotlin codes will also fail to compile due to this
> bug.
> >>>>>>
> >>>>>> Regards,
> >>>>>> R?mi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230505/b80124fd/attachment-0001.htm>

From liach at openjdk.org  Fri May  5 04:56:33 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 May 2023 04:56:33 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers class
 initialization
Message-ID: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>

Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.

A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.

Current problems:
- [ ] The lazy var handle is quite slow on the first invocation.
   - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
   - After that, the lazy handle has a performance on par with the regular var handle.
- [ ] The class-loading-based test is not in a unit test
   - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading


Benchmark                                            Mode  Cnt       Score        Error  Units
VarHandleLazyStaticInvocation.initializedInvocation  avgt   30       0.769 ?      0.003  ns/op
VarHandleLazyStaticInvocation.lazyInvocation         avgt   30       0.767 ?      0.002  ns/op
VarHandleLazyStaticCreation.eagerInitialize            ss   10  348580.000 ? 115234.161  ns/op
VarHandleLazyStaticCreation.lazyInitialize             ss   10  961670.000 ? 154813.238  ns/op

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

Commit messages:
 - copyright year
 - Benchmarks. lazy initialize is SLOW
 - nuke meaningless overrides
 - make static field var handles lazy and fix NPE in isAccessModeSupported

Changes: https://git.openjdk.org/jdk/pull/13821/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291065
  Stats: 509 lines in 9 files changed: 418 ins; 17 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

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

From alanb at openjdk.org  Fri May  5 06:04:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 May 2023 06:04:24 GMT
Subject: RFR: 8306927: Collator treats "v" and "w" as the same letter for
 Swedish language locale.
In-Reply-To: <sIYV7T_b2c09kkNhHYWB6x_gAGpCFQi6KXl4VddE0zk=.5e5cae16-4c4c-4cde-99e6-9580fd641db1@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
 <x8j-huGlphor_LDELRncZ2hwghZhBpli5S96RYQmy98=.04857585-5b8f-4e34-89c9-76a7aff1a120@github.com>
 <sIYV7T_b2c09kkNhHYWB6x_gAGpCFQi6KXl4VddE0zk=.5e5cae16-4c4c-4cde-99e6-9580fd641db1@github.com>
Message-ID: <U2Z51rEV30UFhHU52hcSS6FqZGM8_zyzp8_9DN0bdpM=.6ac433ce-0edc-45c8-8d77-59cf647b36ec@github.com>

On Thu, 27 Apr 2023 12:32:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The rule was changed in 2006, the year Jave SE 6 was released. Though it looks like very much a corner case, it goes all the way back. I wonder if a CSR is needed?
>
>> The rule was changed in 2006, the year Jave SE 6 was released. Though it looks like very much a corner case, it goes all the way back. I wonder if a CSR is needed?
> 
> We don't file a CSR for such a locale data change. These sorts of changes happen in the CLDR upgrade all the time, as well as other i18n-related data changes (currency, timezone, etc.)

@naotoj I know we don't usually create CSRs for changes to locale data but changing the sorting order looks significant, it might need further discussion.

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

PR Comment: https://git.openjdk.org/jdk/pull/13677#issuecomment-1535743951

From jlahoda at openjdk.org  Fri May  5 06:14:45 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 5 May 2023 06:14:45 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v9]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <VE0hqJV3MlHHbr7R-F6KAx0jowVUqSfh9IkpsKP-7Uk=.b0608601-8950-4735-bfe7-cf0aa4a816e3@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

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

 - Updating MatchException javadoc.
 - Merge branch 'master' into JDK-8300543
 - Reverting use of record patterns in enhanced for loop.
 - Cleanup: reflecting review feedback.
 - Merge branch 'master' into JDK-8300543
 - Reflecting review changes.
 - Adding test.
 - Removing redundant continue, as noted on the review.
 - Replacing use of mutable callsite with a mutable state.
 - Reflecting review feedback.
 - ... and 32 more: https://git.openjdk.org/jdk/compare/a87262ef...79bbd717

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

Changes: https://git.openjdk.org/jdk/pull/13074/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=08
  Stats: 4262 lines in 159 files changed: 2025 ins; 1722 del; 515 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

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

From aturbanov at openjdk.org  Fri May  5 06:51:19 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 5 May 2023 06:51:19 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage
In-Reply-To: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
Message-ID: <kW1gDbqRlBBcEEy4o6aYgxbuoDc1Job5rjKjAWi_PiI=.f884cf55-c250-4ca0-96cd-2de5ab330343@github.com>

On Fri, 21 Apr 2023 17:28:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
> 
> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
> Mac OS X 10.15 is the oldest version supported.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/AddLauncherArguments.java line 134:

> 132:                 CLIOptions.LAUNCHER_AS_SERVICE));
> 133: 
> 134:         if (OperatingSystem.isWindows())  {

Suggestion:

        if (OperatingSystem.isWindows()) {

src/jdk.jpackage/share/classes/jdk/jpackage/internal/AddLauncherArguments.java line 144:

> 142:         }
> 143: 
> 144:         if (OperatingSystem.isLinux())  {

Suggestion:

        if (OperatingSystem.isLinux()) {

src/jdk.jpackage/share/classes/jdk/jpackage/internal/ValidOptions.java line 106:

> 104: 
> 105:         put(CLIOptions.FILE_ASSOCIATIONS.getId(),
> 106:             (OperatingSystem.isMacOS()) ?  USE.ALL : USE.INSTALL);

Suggestion:

            (OperatingSystem.isMacOS()) ? USE.ALL : USE.INSTALL);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1185750234
PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1185750325
PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1185750040

From aturbanov at openjdk.org  Fri May  5 07:12:17 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 5 May 2023 07:12:17 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage
In-Reply-To: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
Message-ID: <p0rYPl0HyCsXb9rBLKl0b8XSl_0YJLcq3NoL8h23Nl8=.3370a60a-18a2-4d58-844b-98290df24825@github.com>

On Fri, 21 Apr 2023 17:28:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
> 
> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
> Mac OS X 10.15 is the oldest version supported.

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacAppImageBuilder.java line 613:

> 611:     public static void addNewKeychain(Map<String, ? super Object> params)
> 612:                                     throws IOException, InterruptedException {
> 613:         if (OperatingSystem.version().compareTo(new Version(10,12)) < 0) {

Suggestion:

        if (OperatingSystem.version().compareTo(new Version(10, 12)) < 0) {

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacPkgBundler.java line 325:

> 323:             xml.writeAttribute("require-scripts", "false");
> 324:             xml.writeAttribute("hostArchitectures",
> 325:                     (OperatingSystem.isMacOS() && Architecture.isAARCH64()) ? "arm64" : "x86_64");

Seems `OperatingSystem.isMacOS()` check is redundant

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1185763621
PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1185764656

From asotona at openjdk.org  Fri May  5 07:52:17 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 5 May 2023 07:52:17 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v11]
In-Reply-To: <eNS31_a27NgKfDF-wlHaQ7zasU_xB7uqbtemOTUBlVk=.7e2780d6-a304-4342-8f6a-1088d9a0bd2c@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <GCGqTY2WFItzQskhXUniB2WzT2-mEoHAjUiNPiAwyOU=.e55479cd-3ad5-47c9-80c6-459f5c18436e@github.com>
 <eNS31_a27NgKfDF-wlHaQ7zasU_xB7uqbtemOTUBlVk=.7e2780d6-a304-4342-8f6a-1088d9a0bd2c@github.com>
Message-ID: <ArSxZLO_n29plNUQqvwWl4_uzdpLhoBGyt11w4laI7k=.2b0b489c-07cd-4133-9655-2949364b0c33@github.com>

On Fri, 5 May 2023 02:50:45 GMT, Chen Liang <liach at openjdk.org> wrote:

> Since we want an option to toggle stackmap generation, will you add it to the Classfile options as a temporary measure, before we keep track of these options in a stateful object (with hierarchy resolver etc.) like brian envisioned?

I would prefer to separate multi-state stackmap generation option into a new RFE (or join it with the Brians proposal) and do not delay this fix by discussions about exact number and naming conventions of the option. Current boolean option handles the critical use cases and here proposed default (generate when mandatory) allows seamlessly transform various class versions.

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

PR Comment: https://git.openjdk.org/jdk/pull/13478#issuecomment-1535868523

From alanb at openjdk.org  Fri May  5 08:15:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 May 2023 08:15:19 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v9]
In-Reply-To: <1I219vxR0joKlSO2Yo3sPEzrD29mWoh_xSYcC2UTiLU=.81ad6084-e199-459d-8399-ce38e7e10ef1@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <w_VQMDXdJScfmyacC0Mxsq4ZshVvw8vLNEcw62YbH1I=.4296584d-da35-4b67-8914-ac26aeef1873@github.com>
 <tii6-GGgEZTZiTOmh83uN4qrUaK1WXvmJJTfxD5oHvA=.e3048ff2-e0e6-4f3f-b1fd-8533ce5264ab@github.com>
 <fnyLl2iOgGVDKb12U9zrej7-SEjK2_RxYAdW2jeucA8=.4b8ea8d9-a305-40a5-8c1b-4fbf2429aa7b@github.com>
 <1I219vxR0joKlSO2Yo3sPEzrD29mWoh_xSYcC2UTiLU=.81ad6084-e199-459d-8399-ce38e7e10ef1@github.com>
Message-ID: <gA2qUanp3A8uN-hFTEOv7thSJ3slpMHX7rH6vR1AaDQ=.1d7f1c0e-9ac3-4447-82cc-6d9b3ee04181@github.com>

On Tue, 2 May 2023 19:26:38 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> One other thing to say on this is that jaxp.properties has "XML Library (java.xml) Configuration File" at the top of the file, maybe that could be used in the module description instead of "JAXP Configuration File".
>
> Changed the opening statement and also the naming of config file as above.

I've looked through the updated proposal but I think the intro is going to take a few iterations to get to something that is easy to read. I had hoped the intro would provide an overview of the APIs in the module and establish the terminology that is needed to read further. The existing text isn't great but it does name the APIs in the module so the reader knows there are several APIs for processing XML. With the update, the names of the APIs in the module is lost, and in its place, the text switches to "XML library" and talks about factories and processors. I understand the focus of this PR is to introduce a system property to allow for configuration file but it's changing important API docs that introduce the APIs. 

My view is that we have to create a new introduction that provides a summary of the APIs in the module and a short summary of some concepts. We can't have API docs talk about "factories" and "processors" without defining them. This intro/setup is needed before diving into the configuration, which we might title "Configuring factories and processors" with a summary of the various ways that they can be configured. I think the text from the "Property Precedence" section will need to move into the section on Configuration as it is hard to list the various ways to configure without also talking about precedence.

Once you have a good introduction and seciton on Configuration then I think the other sections will follow without too much work.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1185814343

From jens at lidestrom.se  Fri May  5 09:15:26 2023
From: jens at lidestrom.se (=?UTF-8?Q?Jens_Lidestr=c3=b6m?=)
Date: Fri, 5 May 2023 11:15:26 +0200
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <8241fc87-c1d2-28f8-05d0-a4d2d62dd983@lidestrom.se>

I want contribute an observation of a tangential fact about this example. This might be interesting reminder in a discussion of the tricky parts of type inference.


### The fact

The reason that this example does not compile with Sequenced collections is a limitation in the type inference algorithm:

Type constraints that are inferred from instance method calls do not influence inference of types in the receiver type expression.

### In the given example

1. `List<Collection<String>> list =` is the target type of `.toList()` so this could influence inference of its type parameters.

2. But the inferred type parameters of `.toList()` does not influence the inference of types for its receiver expression, `Stream.of(nestedDequeue, nestedList)`.

If not for this fact the type of `Stream.of(nestedDequeue, nestedList)` could be inferred to be `Stream<Collection>`, but with the current algorithm it will be inferred to be `Stream<SequencedCollection>`, leading to the source incompatibility.

Static method calls don't have this limitation. This is a bit weird, because instance method mostly act like static method, but with an implicit receiver argument. I don't know if there are any strong technical reasons to why there is a difference here.

Using a static `toList` method the given example looks like this, and type checks also with Sequenced collections:

```
List<Collection<String>> list = toList(Stream.of(nestedDequeue, nestedList));

public static <T> List<T> toList(Stream<T> s) {
     return s.toList();
}
```

(One can change the type of `list` to `List<Iterable<String>>` to experiment with this even without Sequenced collections`.)

It would be interesting to have a discussion about whether this limitation could be overcome at some other time.

Regards,
Jens Lidestr?m

PS: Type inference algorithms are soooo much fun, aren't they?


On 2023-05-03 15:12, forax at univ-mlv.fr wrote:
> Another example sent to me by a fellow French guy,
>
>      final Deque<String> nestedDequeue = new ArrayDeque<>();
>      nestedDequeue.addFirst("C");
>      nestedDequeue.addFirst("B");
>      nestedDequeue.addFirst("A");
>
>      final List<String> nestedList = new ArrayList<>();
>      nestedList.add("D");
>      nestedList.add("E");
>      nestedList.add("F");
>
>      final List<Collection<String>> list = Stream.of(nestedDequeue, nestedList).toList();
>
> This one is cool because no 'var' is involved and using collect(Collectors.toList()) instead of toList() solves the inference problem.
>
> R?mi
>
> ----- Original Message -----
>> From: "Stuart Marks" <stuart.marks at oracle.com>
>> To: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Sent: Tuesday, May 2, 2023 2:44:28 AM
>> Subject: Re: The introduction of Sequenced collections is not a source compatible change
>
>> Hi R?mi,
>>
>> Thanks for trying out the latest build!
>>
>> I'll make sure this gets mentioned in the release note for Sequenced
>> Collections.
>> We'll also raise this issue when we talk about this feature in the Quality
>> Outreach
>> program.
>>
>> s'marks
>>
>> On 4/29/23 3:46 AM, Remi Forax wrote:
>>> I've several repositories that now fails to compile with the latest jdk21, which
>>> introduces sequence collections.
>>>
>>> The introduction of a common supertype to existing collections is *not* a source
>>> compatible change because of type inference.
>>>
>>> Here is a simplified example:
>>>
>>>     public static void m(List<Supplier<? extends Map<String, String>>> factories) {
>>>     }
>>>
>>>     public static void main(String[] args) {
>>>       Supplier<LinkedHashMap<String,String>> supplier1 = LinkedHashMap::new;
>>>       Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>>>       var factories = List.of(supplier1, supplier2);
>>>       m(factories);
>>>     }
>>>
>>>
>>> This example compiles fine with Java 20 but report an error with Java 21:
>>>     SequencedCollectionBug.java:28: error: method m in class SequencedCollectionBug
>>>     cannot be applied to given types;
>>>       m(factories);
>>>       ^
>>>     required: List<Supplier<? extends Map<String,String>>>
>>>     found:    List<Supplier<? extends SequencedMap<String,String>>>
>>>     reason: argument mismatch; List<Supplier<? extends SequencedMap<String,String>>>
>>>     cannot be converted to List<Supplier<? extends Map<String,String>>>
>>>
>>>
>>>
>>> Apart from the example above, most of the failures I see are in the unit tests
>>> provided to the students, because we are using a lot of 'var' in them so they
>>> work whatever the name of the types chosen by the students.
>>>
>>> Discussing with a colleague, we also believe that this bug is not limited to
>>> Java, existing Kotlin codes will also fail to compile due to this bug.
>>>
>>> Regards,
>>> R?mi


From asotona at openjdk.org  Fri May  5 09:25:18 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 5 May 2023 09:25:18 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v11]
In-Reply-To: <GCGqTY2WFItzQskhXUniB2WzT2-mEoHAjUiNPiAwyOU=.e55479cd-3ad5-47c9-80c6-459f5c18436e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <GCGqTY2WFItzQskhXUniB2WzT2-mEoHAjUiNPiAwyOU=.e55479cd-3ad5-47c9-80c6-459f5c18436e@github.com>
Message-ID: <AzWuzYX_XSMCZSXruY7aMOs4NUZf1pOPX_9nGCB76vE=.b199171f-c854-4da1-8256-cb1012a37dbb@github.com>

On Thu, 4 May 2023 16:19:04 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API didn't handle transformations of class files version 50 and below correctly. 
>> 
>> Proposed fix have two parts: 
>> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
>> 2. StackMapTable attribute is not generated for class file versions below 50.
>> 
>> StackMapsTest is also extended to test this patch.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Thanks for review.
>   
>   Co-authored-by: liach <7806504+liach at users.noreply.github.com>

I'm considering to adjust current default stackmap generation behaviour from "when mandatory" to "by class file version".
It will try to generate stackmaps also for class version 50 with failover to basic stack counter (exactly following JVMS-4.10).
Later it will allow us to add only third option "always" to satisfy also the very specific use cases going beyond the JVMS boundaries.

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

PR Comment: https://git.openjdk.org/jdk/pull/13478#issuecomment-1535976554

From jpai at openjdk.org  Fri May  5 09:33:22 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 09:33:22 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <PFx1nZamLhK4hMdqWpfrNYU867GRQfLIhJHXNKOtlZg=.0d310ee2-bca5-40f1-9ed4-f40c28ebbd51@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 139:

> 137:     public static Method findMainMethod(Class<?> mainClass) throws NoSuchMethodException {
> 138:         try {
> 139:             Method mainMethod = mainClass.getMethod("main", String[].class);

Hello Jim, I think this specific line is trying to find a `public static void main(String[])` method from the launched class. In the current form of this implementation, this has the potential of returning a non-static `public void main(String[])` from here. I think a `isStatic(mainMethod)` would be needed here before returning this method as the found method.

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 142:

> 140: 
> 141:             if (mainMethod.getDeclaringClass() != mainClass) {
> 142:                 System.err.println("WARNING: static main in super class will be deprecated.");

Similarly, this warning would have to be logged only if the method is `static`. Furthermore, do you think we should include the declaring class in the log message to provide some context on what's causing this warning? Something like:
> WARNING: static main(String[]) in super class foo.bar.Parent will be deprecated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185882851
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185885497

From jpai at openjdk.org  Fri May  5 09:42:23 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 09:42:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <y3v3m2IK2ftt0qwfe6wcoU2uGakneHJ96JI25D65QTk=.822e0b64-2a70-4170-af91-c9a432e3054a@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 152:

> 150: 
> 151:             List<Method> mains = new ArrayList<>();
> 152:             gatherMains(mainClass, mainClass, mains);

The `try` block above is there to find `public static void main(String[])` in the launched class. When it's not found, then we gather the potential main methods (as listed in the JEP). The implementation of `gatherMains(...)`, in its current form starts gathering the main methods from `refc.getSuperclass()`, where `refc` in this case is the `mainClass`, which is the launched class.

So if I'm reading this correctly, then I think it's going to completely skip the launched class for looking any potential main methods and instead start looking for them in the launched class' super hierarchy.

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 158:

> 156:             }
> 157: 
> 158:             mains.sort(MainMethodFinder::compareMethods);

Perhaps skip the call to `sort` and just return the found main method if `mains.size() == 1`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185890136
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185892782

From jpai at openjdk.org  Fri May  5 09:48:24 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 09:48:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <C7voJ4xJR6Ci5ZQJEUhIe_erfY18b9yPyvh-sIhtkWs=.fd5d02af-71b5-435c-8d33-3345042fa524@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 70:

> 68:                         correctArgs(method) &&
> 69:                         // Only statics in the declaring class
> 70:                         (!isStatic(method) || declc == refc)

Should this also exclude `abstract` and `native` methods named `main`?

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 134:

> 132: 
> 133:     /**
> 134:      * {@return priority main method or null if none found}

I think this javadoc is perhaps outdated? The current implementation of this method throws a `NoSuchMethodException` when it can't find any eligible main method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185896198
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185898281

From jpai at openjdk.org  Fri May  5 09:55:23 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 09:55:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <R3xsNOfuMNqZ8xiwQ3AOwhIFFi7oOlvikW_FPI9axU8=.edf5c6fa-1db7-4192-8f78-20a0a02ef41a@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 872:

> 870:         Method mainMethod = null;
> 871:         try {
> 872:             mainMethod = MainMethodFinder.findMainMethod(mainClass);

The `MainMethodFinder.findMainMethod(...)` throws a `NoSuchMethodException` when it can't find the regular `public static void main(String[])` or, when preview is enabled, any other eligible main methods. That will now mean that the next line here which catches a `NoSuchMethodException` can potentially end up aborting with a (very confusing) error message about JavaFX application. We should perhaps change that catch block to something like:

} catch (NoSuchMethodException nsme) {
   if (!PreviewFeatures.isEnabled()) {
                  // invalid main or not FX application, abort with an error
            abort(null, "java.launcher.cls.error4", mainClass.getName(),
                  JAVAFX_APPLICATION_CLASS_NAME);
   } else {
       // abort with something more clear error?
   }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185905158

From jpai at openjdk.org  Fri May  5 10:00:41 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 10:00:41 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <G9xRuFXqN1UwWrR8rI0AIyakHTbwOl5JqjIwJkls3jk=.cd1a8983-5b55-4c91-a738-05682bdca80a@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 893:

> 891:          * findMainMethod (above) will choose the correct method, based
> 892:          * on its name and parameter type, however, we still have to
> 893:          * ensure that the method is static (non-preview) and returns a void.

I think it's probably going to be easier to read and maintain if we moved these checks for `static` and `void` return type into the `MainMethodFinder.findMainMethod(...)` itself. 
What I mean is once we return from the `findMainMethod(...)`, I think the callers, like this code here, shouldn't have to do additional checks to know if this main method is valid and can be used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185908021

From jpai at openjdk.org  Fri May  5 10:10:24 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 10:10:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <0IFuexmcfMhpT8nlQ02H-NNhUWzOvzdyMaklwlMR93k=.c674102a-00f1-4a26-ac87-8cd121ceb10f@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 419:

> 417:     private static boolean isStatic(Method method) {
> 418:         return method != null && Modifier.isStatic(method.getModifiers());
> 419:     }

It looks like these new methods aren't being used.

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 440:

> 438:             int mods = mainMethod.getModifiers();
> 439:             boolean isStatic = Modifier.isStatic(mods);
> 440:             boolean isPublic = Modifier.isStatic(mods);

This looks like a typo. This should have been `Modifier.isPublic(mods);`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185918190
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185917271

From jpai at openjdk.org  Fri May  5 10:18:23 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 10:18:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <A0WrdmSrfwGua2Vy4XExnCJGGTcYBIt4p2xBmIX6fjA=.53b3b5ba-3cb5-47cf-b154-81936df4530c@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 457:

> 455:             if (isStatic) {
> 456:                 if (noArgs) {
> 457:                     mainMethod.invoke(appClass);

Given that `Method.invoke(...)` on a static method ignores the `obj` param that's passed to it, perhaps pass `null`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185924903

From jpai at openjdk.org  Fri May  5 10:25:21 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 10:25:21 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
Message-ID: <8Q_VdzphUbJgaiyTigSlBztROntOa5lz0oeMhrMcvRU=.2ce70574-d520-49be-91de-e2059c6062ce@github.com>

On Mon, 1 May 2023 13:06:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Anonymous main classes renamed to unnamed classes
>  - Add test

test/jdk/tools/launcher/InstanceMainTest.java line 33:

> 31: public class InstanceMainTest extends TestHelper {
> 32: 
> 33:     @Test

Does this compile? I don't see imports for this annotation and this is launched as a `@run main ....`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1185930904

From amaembo at gmail.com  Fri May  5 10:27:22 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Fri, 5 May 2023 12:27:22 +0200
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CAE+3fjamrrrOUo4sb19ZRqg-5+g1=rPpo=eW9Eg=J7r2G0s0vA@mail.gmail.com>

Hello!

Such kind of incompatibility happens every single time the new
supertype is introduced for two types. E.g., consider:

import java.lang.invoke.MethodType;
import java.util.List;
import java.io.Serializable;

class Main {
  void test() {
    MethodType mt = MethodType.methodType(void.class);
    List<Serializable> list = List.of(mt, 1).subList(0,1);
  }
}

Compilable in Java 11, not compilable in Java 12+

Test.java:8: error: incompatible types: List<INT#1> cannot be
converted to List<Serializable>
    List<Serializable> list = List.of(mt, 1).subList(0,1);
                                                    ^
  where INT#1 is an intersection type:
    INT#1 extends Object,Serializable,Constable
1 error

I don't think that such a compatibility issue was even mentioned in
Java 12 release notes.

With best regards,
Tagir Valeev.

On Wed, May 3, 2023 at 3:13?PM <forax at univ-mlv.fr> wrote:
>
> Another example sent to me by a fellow French guy,
>
>     final Deque<String> nestedDequeue = new ArrayDeque<>();
>     nestedDequeue.addFirst("C");
>     nestedDequeue.addFirst("B");
>     nestedDequeue.addFirst("A");
>
>     final List<String> nestedList = new ArrayList<>();
>     nestedList.add("D");
>     nestedList.add("E");
>     nestedList.add("F");
>
>     final List<Collection<String>> list = Stream.of(nestedDequeue, nestedList).toList();
>
> This one is cool because no 'var' is involved and using collect(Collectors.toList()) instead of toList() solves the inference problem.
>
> R?mi
>
> ----- Original Message -----
> > From: "Stuart Marks" <stuart.marks at oracle.com>
> > To: "Remi Forax" <forax at univ-mlv.fr>
> > Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Sent: Tuesday, May 2, 2023 2:44:28 AM
> > Subject: Re: The introduction of Sequenced collections is not a source compatible change
>
> > Hi R?mi,
> >
> > Thanks for trying out the latest build!
> >
> > I'll make sure this gets mentioned in the release note for Sequenced
> > Collections.
> > We'll also raise this issue when we talk about this feature in the Quality
> > Outreach
> > program.
> >
> > s'marks
> >
> > On 4/29/23 3:46 AM, Remi Forax wrote:
> >> I've several repositories that now fails to compile with the latest jdk21, which
> >> introduces sequence collections.
> >>
> >> The introduction of a common supertype to existing collections is *not* a source
> >> compatible change because of type inference.
> >>
> >> Here is a simplified example:
> >>
> >>    public static void m(List<Supplier<? extends Map<String, String>>> factories) {
> >>    }
> >>
> >>    public static void main(String[] args) {
> >>      Supplier<LinkedHashMap<String,String>> supplier1 = LinkedHashMap::new;
> >>      Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
> >>      var factories = List.of(supplier1, supplier2);
> >>      m(factories);
> >>    }
> >>
> >>
> >> This example compiles fine with Java 20 but report an error with Java 21:
> >>    SequencedCollectionBug.java:28: error: method m in class SequencedCollectionBug
> >>    cannot be applied to given types;
> >>      m(factories);
> >>      ^
> >>    required: List<Supplier<? extends Map<String,String>>>
> >>    found:    List<Supplier<? extends SequencedMap<String,String>>>
> >>    reason: argument mismatch; List<Supplier<? extends SequencedMap<String,String>>>
> >>    cannot be converted to List<Supplier<? extends Map<String,String>>>
> >>
> >>
> >>
> >> Apart from the example above, most of the failures I see are in the unit tests
> >> provided to the students, because we are using a lot of 'var' in them so they
> >> work whatever the name of the types chosen by the students.
> >>
> >> Discussing with a colleague, we also believe that this bug is not limited to
> >> Java, existing Kotlin codes will also fail to compile due to this bug.
> >>
> >> Regards,
> > > R?mi

From jpai at openjdk.org  Fri May  5 10:56:24 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 10:56:24 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v2]
In-Reply-To: <8-KhwX0trUkvczzmmsYVivQgyuy_G94MejWHC1C_0Ow=.5836e402-9162-49ce-9ffd-19c26063005a@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
 <8-KhwX0trUkvczzmmsYVivQgyuy_G94MejWHC1C_0Ow=.5836e402-9162-49ce-9ffd-19c26063005a@github.com>
Message-ID: <hHxHiXRWszns9PNQ4u31NCQqRRdI6jp2ggkYeH0rx_A=.5a5a3416-c9e9-4bd0-ae62-50e4bfe14327@github.com>

On Thu, 4 May 2023 20:37:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
>> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
>> 
>> Neither os.name nor os.arch should be assumed to be changeable; 
>> one test case is removed because it assumes os.name can be changed on the command line.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Remove unused static methods in DefaultImageBuilder
>  - Merge branch 'master' into 8304913-os-arch-jlink
>  - Merge branch 'master' into 8304913-os-arch-jlink
>  - Minor cleanup
>  - Merge branch 'master' into 8304913-os-arch-jlink
>  - 8304913: Use OperatingSystem, Architecture, and Version in jlink
>  - Simplify exception handling
>  - Simplify version parsing
>  - 8306678: Replace use of os.version with an internal Version record
>  - Use and test of "s390" verified by reviewer.
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/0c6529d2...5bf9a506

These latest changes look OK to me.

I have very limited knowledge of this area, so it would be good to wait for another review.

src/jdk.jlink/share/classes/jdk/tools/jlink/builder/ImageBuilder.java line 86:

> 84:      */
> 85:     public default Platform getTargetPlatform() {
> 86:         throw new UnsupportedOperationException("Builder does not define getTargetPlatform");

I think it is OK to change this implementation to now throw this exception, since this is an internal interface (from what I can see in the module definition).

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13585#pullrequestreview-1414571255
PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1185954316

From alanb at openjdk.org  Fri May  5 11:22:23 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 May 2023 11:22:23 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v2]
In-Reply-To: <8-KhwX0trUkvczzmmsYVivQgyuy_G94MejWHC1C_0Ow=.5836e402-9162-49ce-9ffd-19c26063005a@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
 <8-KhwX0trUkvczzmmsYVivQgyuy_G94MejWHC1C_0Ow=.5836e402-9162-49ce-9ffd-19c26063005a@github.com>
Message-ID: <U2T_M40ZqkRPzPk_Q5PEZx3i4qTY3EUvEQriopsuYyg=.38d406f6-d5ed-4815-bcb0-2c05a24477bd@github.com>

On Thu, 4 May 2023 20:37:31 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
>> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
>> 
>> Neither os.name nor os.arch should be assumed to be changeable; 
>> one test case is removed because it assumes os.name can be changed on the command line.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits:
> 
>  - Remove unused static methods in DefaultImageBuilder
>  - Merge branch 'master' into 8304913-os-arch-jlink
>  - Merge branch 'master' into 8304913-os-arch-jlink
>  - Minor cleanup
>  - Merge branch 'master' into 8304913-os-arch-jlink
>  - 8304913: Use OperatingSystem, Architecture, and Version in jlink
>  - Simplify exception handling
>  - Simplify version parsing
>  - 8306678: Replace use of os.version with an internal Version record
>  - Use and test of "s390" verified by reviewer.
>  - ... and 18 more: https://git.openjdk.org/jdk/compare/0c6529d2...5bf9a506

src/jdk.jlink/share/classes/jdk/tools/jlink/builder/DefaultImageBuilder.java line 180:

> 178:             try {
> 179:                 this.platform = Platform.parsePlatform(value);
> 180:             } catch (IllegalArgumentException ile) {

What is "ile", can we rename it to "iae"?

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java line 254:

> 252:                 case WINDOWS -> new String[]{"jvm.dll"};
> 253:                 case MACOS -> new String[]{"libjvm.dylib", "libjvm.a"};
> 254:                 default -> new String[]{"libjvm.so", "libjvm.a"};

If you line up the -> then it might be clearer to the eyes.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/plugins/ExcludeVMPlugin.java line 256:

> 254:                 default -> new String[]{"libjvm.so", "libjvm.a"};
> 255:             };
> 256:         } catch (IllegalArgumentException ile) {

Confusing to name it "ile" here too.

test/jdk/tools/jlink/plugins/CDSPluginTest.java line 102:

> 100:            System.out.println("    stdout: " + out.getStdout());
> 101:            out.shouldMatch("Error: Cannot generate CDS archives: target image platform linux-.*is different from runtime platform windows-.*");
> 102:            out.shouldHaveExitValue(1);

Good to see this part of the test going away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1185970733
PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1185972077
PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1185971652
PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1185975906

From forax at univ-mlv.fr  Fri May  5 11:14:46 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Fri, 5 May 2023 13:14:46 +0200 (CEST)
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <46167980-41fe-e214-9b67-ce0c5ca8c032@oracle.com>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
 <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
 <CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com>
 <46167980-41fe-e214-9b67-ce0c5ca8c032@oracle.com>
Message-ID: <1907607213.49439971.1683285286489.JavaMail.zimbra@univ-eiffel.fr>

Hi Joe, 
in this peculiar case, there are several reasons to be worried compared to other potential breaking changes that has appeared in the past (see the message of Tagir for an example). 

Unlike other changes 
- this one touch the collection API, and those interfaces/types are widely used, 
- we know that the source compatibility changes occurs mostly if 'var' or the "new" inference algorithm (the one from Java 8), so this is likely that most of the issues will be found in Java 11+ source code, 
- this changes may also affect all typed languages based on the JVM, not only Java. Corpus of codes in Groovy, Kotlin and Scala also need to be checked. In case of Kotlin and Scala, 'var' is the default behavior but they have their own collections (or type system around collections in case of Kotlin), so knowing the real impact of this change is hard here. 

The problem of using a corpus experiment is that the corpus may not represent the current state of the Java ecosystem, or at least the one that may be impacted. 
In my case, on my own repositories (public and private), i had only one occurrence of the issue in the main source codes because many of those repositories are not using 'var' or even the stream API but on the corpus of the unit tests we give to students to check their implementations, little less than a third of those JUnit classes had source compatibility issues because those tests are using 'var' and different collections heavily. 

And the situation is a little worst than that because in between now and the time people will use Java 21, a lot of codes will be written using Java 11 and 17 and may found incompatible later. 

A source incompatibility issue is not a big deal, as said in this thread, most of the time, explicitly fixing the type argument instead of inferring it make the code compile again. 
So the house is not burning, but we should raise awareness of this issue given that it may have a bigger impact than other source incompatible changes that occur previously. 

R?mi 

> From: "joe darcy" <joe.darcy at oracle.com>
> To: "Ethan McCue" <ethan at mccue.dev>, "Raffaello Giulietti"
> <raffaello.giulietti at oracle.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "Stuart Marks" <stuart.marks at oracle.com>,
> "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Friday, May 5, 2023 4:38:16 AM
> Subject: Re: The introduction of Sequenced collections is not a source
> compatible change

> A few comments on the general compatibility policy for the JDK. Compatibility is
> looked after by the Compatibility and Specification Review (CSR) process (
> Compatibility & Specification Review). Summarizing the approach,

>> The general compatibility policy for exported APIs implemented in the JDK is:

>> * Don't break binary compatibility (as defined in the Java Language
>> Specification) without sufficient cause.
>> * Avoid introducing source incompatibilities.
>> * Manage behavioral compatibility changes.
> [ https://wiki.openjdk.org/display/csr/Main |
> https://wiki.openjdk.org/display/csr/Main ]

> None of binary, source, and behavioral compatibly are absolutes and judgement is
> used to assess the cost/benefits of changes. For example, strict source
> compatibility would preclude, say, introducing new public types in the
> java.lang package since the implicit import of types in java.lang could
> conflict with a same-named type *-imported from another package.

> When a proposed change is estimated to be sufficiently disruptive, we conduct a
> corpus experiment to evaluate the impact on the change on many public Java
> libraries. Back in Project Coin in JDK 7, that basic approach was used to help
> quantify various language design choices and the infrastructure to run such
> experiments has been built-out in the subsequent releases.

> HTH,

> -Joe
> CSR Group Lead
> On 5/4/2023 6:32 AM, Ethan McCue wrote:

>> I guess this a good time to ask, ignoring the benefit part of a cost benefit
>> analysis, what mechanisms do we have to measure the number of codebases relying
>> on type inference this will break?

>> Iirc Adoptium built/ran the unit tests of a bunch of public repos, but it's also
>> a bit shocking if the jtreg suite had nothing for this.

>> On Thu, May 4, 2023, 9:27 AM Raffaello Giulietti < [
>> mailto:raffaello.giulietti at oracle.com | raffaello.giulietti at oracle.com ] >
>> wrote:

>>> Without changing the semantics at all, you could also write

>>> final List<Collection<String>> list =
>>> Stream.<Collection<String>>of(nestedDequeue, nestedList).toList();

>>> to "help" type inference.

>>> On 2023-05-03 15:12, [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] wrote:
>>> > Another example sent to me by a fellow French guy,

>>> > final Deque<String> nestedDequeue = new ArrayDeque<>();
>>> > nestedDequeue.addFirst("C");
>>> > nestedDequeue.addFirst("B");
>>> > nestedDequeue.addFirst("A");

>>> > final List<String> nestedList = new ArrayList<>();
>>> > nestedList.add("D");
>>> > nestedList.add("E");
>>> > nestedList.add("F");

>>>> final List<Collection<String>> list = Stream.of(nestedDequeue,
>>> > nestedList).toList();

>>>> This one is cool because no 'var' is involved and using
>>> > collect(Collectors.toList()) instead of toList() solves the inference problem.

>>> > R?mi

>>> > ----- Original Message -----
>>>>> From: "Stuart Marks" < [ mailto:stuart.marks at oracle.com |
>>> >> stuart.marks at oracle.com ] >
>>> >> To: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>>>> Cc: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.java.net |
>>> >> core-libs-dev at openjdk.java.net ] >
>>> >> Sent: Tuesday, May 2, 2023 2:44:28 AM
>>>>> Subject: Re: The introduction of Sequenced collections is not a source
>>> >> compatible change

>>> >> Hi R?mi,

>>> >> Thanks for trying out the latest build!

>>> >> I'll make sure this gets mentioned in the release note for Sequenced
>>> >> Collections.
>>> >> We'll also raise this issue when we talk about this feature in the Quality
>>> >> Outreach
>>> >> program.

>>> >> s'marks

>>> >> On 4/29/23 3:46 AM, Remi Forax wrote:
>>> >>> I've several repositories that now fails to compile with the latest jdk21, which
>>> >>> introduces sequence collections.

>>> >>> The introduction of a common supertype to existing collections is *not* a source
>>> >>> compatible change because of type inference.

>>> >>> Here is a simplified example:

>>> >>> public static void m(List<Supplier<? extends Map<String, String>>> factories) {
>>> >>> }

>>> >>> public static void main(String[] args) {
>>> >>> Supplier<LinkedHashMap<String,String>> supplier1 = LinkedHashMap::new;
>>> >>> Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>>> >>> var factories = List.of(supplier1, supplier2);
>>> >>> m(factories);
>>> >>> }


>>> >>> This example compiles fine with Java 20 but report an error with Java 21:
>>> >>> SequencedCollectionBug.java:28: error: method m in class SequencedCollectionBug
>>> >>> cannot be applied to given types;
>>> >>> m(factories);
>>> >>> ^
>>> >>> required: List<Supplier<? extends Map<String,String>>>
>>> >>> found: List<Supplier<? extends SequencedMap<String,String>>>
>>> >>> reason: argument mismatch; List<Supplier<? extends SequencedMap<String,String>>>
>>> >>> cannot be converted to List<Supplier<? extends Map<String,String>>>



>>> >>> Apart from the example above, most of the failures I see are in the unit tests
>>> >>> provided to the students, because we are using a lot of 'var' in them so they
>>> >>> work whatever the name of the types chosen by the students.

>>> >>> Discussing with a colleague, we also believe that this bug is not limited to
>>> >>> Java, existing Kotlin codes will also fail to compile due to this bug.

>>> >>> Regards,
>>> >>> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230505/f91ee2f5/attachment.htm>

From jlaskey at openjdk.org  Fri May  5 11:56:23 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 11:56:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v3]
In-Reply-To: <aXXmw3MI3RKxzdvKBAgRPBfnEiQJWodtbizzX9k9m9I=.18eb38ed-3591-4b65-bd33-1eb7df7d982a@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <_6xSHusevGR4RDMupHM5YlVpM1X2CgcHmc-jtLGE3uA=.6f8f53ab-86d3-4556-a551-7530074dffc0@github.com>
 <aXXmw3MI3RKxzdvKBAgRPBfnEiQJWodtbizzX9k9m9I=.18eb38ed-3591-4b65-bd33-1eb7df7d982a@github.com>
Message-ID: <aGCkmAjy0Spx9uRPsdQUevkzlhdlaHN29IOLDoSWfr0=.511d6ed1-9c3d-4fd6-a769-eb3564ac4272@github.com>

On Thu, 27 Apr 2023 20:51:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'master' into 8306112
>>  - PreviewFeatures.isEnabled()
>>  - Clean up isPreview
>>  - Missing exception
>>  - Corrections
>>  - Update VM.java
>>  - Clean up testing
>>  - Update TestJavacTaskScanner.java
>>  - Merge branch 'master' into 8306112
>>  - Clean up
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/96cdf93b...53a5321d
>
> test/jdk/tools/launcher/OnrampMainTest.java line 31:
> 
>> 29:  * @run main OnrampMainTest
>> 30:  */
>> 31: public class OnrampMainTest extends TestHelper {
> 
> Should more tests be added for inherited methods?

Test added

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186003544

From qamai at openjdk.org  Fri May  5 12:21:21 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 5 May 2023 12:21:21 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v6]
In-Reply-To: <hzuMOVojyS3HN_2Zw6GAW2pabc9ad1hBDqUbuCdOs1U=.835c02fd-dfc5-44eb-af87-b1c6b45fe41b@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>
 <hzuMOVojyS3HN_2Zw6GAW2pabc9ad1hBDqUbuCdOs1U=.835c02fd-dfc5-44eb-af87-b1c6b45fe41b@github.com>
Message-ID: <INdi5tArM_sLrfwotOXJRv4osMCHu31ruY0E_v68f7s=.2763ab0d-6c47-4ee0-a2b3-d3eeb08188d3@github.com>

On Thu, 6 Apr 2023 01:45:37 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   style
>
> test/hotspot/jtreg/compiler/vectorapi/TestVectorSlice.java line 466:
> 
>> 464:     @IR(counts = {IRNode.VECTOR_SLICE, "17"})
>> 465:     static void testB128(byte[][] dst, byte[] src1, byte[] src2) {
>> 466:         var species = ByteVector.SPECIES_128;
> 
> Suggest to define the species as a "`private static final`" field of this test class. It may make the intrinsification fail if the species is not a constant to the compiler.

This local is final and is loaded from a `static final` field so it should be equivalent to referring to `ByteVector.SPECIES_128` directly

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1186024843

From qamai at openjdk.org  Fri May  5 12:25:19 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 5 May 2023 12:25:19 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v6]
In-Reply-To: <OUYSIb3zl-YY_pNjOE0kmZe__-Gstt65QYoVDFQu-PY=.ba9ea3bd-0e31-48b8-a445-a7a9897d69f9@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>
 <OUYSIb3zl-YY_pNjOE0kmZe__-Gstt65QYoVDFQu-PY=.ba9ea3bd-0e31-48b8-a445-a7a9897d69f9@github.com>
Message-ID: <URKqtxikD8Da3ZQPlzw-_Pc_yEkH1-puCJT0DB7okKs=.b947c402-2324-450c-9b66-df5697082e5b@github.com>

On Tue, 11 Apr 2023 19:03:21 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   style
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ShortVector.java line 2295:
> 
>> 2293:                 // to be performant
>> 2294:                 @ForceInline
>> 2295:                 public ShortVector apply(ShortVector v1, ShortVector v2, int o) {
> 
> Have you considered matching the corresponding IR during GVN to produce VectorSlice nodes rather than going through VM intrinsic?

I have thought about this but it will require C2 to track the values of individual elements in a vector and constant fold vector loads from stable fields, both of which are not available as of right now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1186028378

From qamai at openjdk.org  Fri May  5 12:31:26 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 5 May 2023 12:31:26 GMT
Subject: RFR: 8303762: [vectorapi] Intrinsification of Vector.slice [v6]
In-Reply-To: <bi-qNEB_S_qnREy0zAw_E2crQmZeEXPWOsrvC93Incg=.89660de8-6f9f-4b03-81d5-d057fe8487ec@github.com>
References: <uChb9T7MpJCsrPVNUDMpyd3g1nGaEAOlc36gCFVmEQI=.2a9264de-b228-4d6f-a565-554520b43da4@github.com>
 <mvjXG43i2H0ULxXam6DzZR6SPrVjyth_x4Fu7CTjmE0=.04f5e64d-54bd-4556-bc46-212552526853@github.com>
 <PAUHwGpESblYnLoyYRyy5dUyIWlxqmkJM3xE1nQ8I38=.2ec7a5ed-b72f-43d4-b1bb-3e7c72b19d7d@github.com>
 <bi-qNEB_S_qnREy0zAw_E2crQmZeEXPWOsrvC93Incg=.89660de8-6f9f-4b03-81d5-d057fe8487ec@github.com>
Message-ID: <ASpcRwbbHKQFcHCAJ9VpArbCksDVyuCPUE7luHVADjw=.768991d5-e14f-4b9f-896a-09fc31dcd84e@github.com>

On Tue, 25 Apr 2023 11:59:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/share/opto/vectorIntrinsics.cpp line 1914:
>> 
>>> 1912:   if (vector_klass->const_oop() == NULL || elem_klass->const_oop() == NULL ||
>>> 1913:       !vlen->is_con() || !origin_type->is_con()) {
>>> 1914:     if (C->print_intrinsics()) {
>> 
>> Hi @merykitty , your inline expander is not handling non-constant origin case, this will introduce performance regressions w.r.t to existing implementation.
>
> You can extend expander to generate IR corresponding to fallback implementation to handle non-constant origin case.

Yes it seems that `ForceInline` is not respected if intrinsification fails, which results in regressions. I will try to look at both approaches, I kind of like falling back to Java code more since it is cleaner and avoids duplication between Hotspot intrinsic kit and Java implementation, though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12909#discussion_r1186033536

From asotona at openjdk.org  Fri May  5 12:39:31 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 5 May 2023 12:39:31 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v12]
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <Es1-TECuoYm4AFMqGm2tSDX0uIon5GoYa7df4YwSkUs=.3e18ff76-1e1d-4b04-b764-d2194c906f0e@github.com>

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

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

  implemented failover stackmap generation for class version 50
  fixed StackMapGenerator error debug print + added clone constructor to SplitConstantPool
  adjusted and extended related tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13478/files
  - new: https://git.openjdk.org/jdk/pull/13478/files/6fbd2719..795314a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=10-11

  Stats: 54 lines in 5 files changed: 31 ins; 11 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/13478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13478/head:pull/13478

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

From mcimadamore at openjdk.org  Fri May  5 13:06:23 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 May 2023 13:06:23 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <vpmIVtqoZltiq3roT4VTJs8RNp5SaV8E_CcgUitztZg=.91847552-17ea-441b-b2b5-8c49963d1554@github.com>

On Fri, 5 May 2023 04:48:09 GMT, Chen Liang <liach at openjdk.org> wrote:

> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
> 
> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
> 
> Current problems:
> - [ ] The lazy var handle is quite slow on the first invocation.
>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>    - After that, the lazy handle has a performance on par with the regular var handle.
> - [ ] The class-loading-based test is not in a unit test
>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
> 
> 
> Benchmark                                            Mode  Cnt       Score        Error  Units
> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30       0.769 ?      0.003  ns/op
> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30       0.767 ?      0.002  ns/op
> VarHandleLazyStaticCreation.eagerInitialize            ss   10  348580.000 ? 115234.161  ns/op
> VarHandleLazyStaticCreation.lazyInitialize             ss   10  961670.000 ? 154813.238  ns/op

src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 74:

> 72:     @Override
> 73:     public boolean isAccessModeSupported(AccessMode accessMode) {
> 74:         var directTarget = this.directTarget;

Why is this not defined in the superclass, and then use `asDirect` (as done in other cases) ?

src/java.base/share/classes/java/lang/invoke/VarHandles.java line 110:

> 108:         }
> 109:         else {
> 110:             if (UNSAFE.shouldBeInitialized(refc)) {

This seems unrelated to the issue this PR is really about (if I understand correctly). Would it make sense to address this as part of another PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1186067149
PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1186068196

From liach at openjdk.org  Fri May  5 13:06:24 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 May 2023 13:06:24 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization
In-Reply-To: <vpmIVtqoZltiq3roT4VTJs8RNp5SaV8E_CcgUitztZg=.91847552-17ea-441b-b2b5-8c49963d1554@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <vpmIVtqoZltiq3roT4VTJs8RNp5SaV8E_CcgUitztZg=.91847552-17ea-441b-b2b5-8c49963d1554@github.com>
Message-ID: <m8hIMcObAklUJxarpfTAO5wWj98gR0tbKSITmwjX4Ag=.02bc505f-f42d-4d6f-82c8-baa8b3b4a1d3@github.com>

On Fri, 5 May 2023 13:00:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30       0.769 ?      0.003  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30       0.767 ?      0.002  ns/op
>> VarHandleLazyStaticCreation.eagerInitialize            ss   10  348580.000 ? 115234.161  ns/op
>> VarHandleLazyStaticCreation.lazyInitialize             ss   10  961670.000 ? 154813.238  ns/op
>
> src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 74:
> 
>> 72:     @Override
>> 73:     public boolean isAccessModeSupported(AccessMode accessMode) {
>> 74:         var directTarget = this.directTarget;
> 
> Why is this not defined in the superclass, and then use `asDirect` (as done in other cases) ?

I aim to avoid eager evaluation of directTarget (which is lazy in LazyStaticVarHandle, computing it requires initializing the holder class). This code path checks a stable field, so it should allow constant-folding when the direct target is available.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1186070262

From mcimadamore at openjdk.org  Fri May  5 13:06:28 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 May 2023 13:06:28 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization
In-Reply-To: <vpmIVtqoZltiq3roT4VTJs8RNp5SaV8E_CcgUitztZg=.91847552-17ea-441b-b2b5-8c49963d1554@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <vpmIVtqoZltiq3roT4VTJs8RNp5SaV8E_CcgUitztZg=.91847552-17ea-441b-b2b5-8c49963d1554@github.com>
Message-ID: <ztJEnwiepyNPLQmzylR7cpLknidTS2CrdnFS7xjWDtY=.c9801025-d550-4695-97c2-4add8281605e@github.com>

On Fri, 5 May 2023 13:01:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30       0.769 ?      0.003  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30       0.767 ?      0.002  ns/op
>> VarHandleLazyStaticCreation.eagerInitialize            ss   10  348580.000 ? 115234.161  ns/op
>> VarHandleLazyStaticCreation.lazyInitialize             ss   10  961670.000 ? 154813.238  ns/op
>
> src/java.base/share/classes/java/lang/invoke/VarHandles.java line 110:
> 
>> 108:         }
>> 109:         else {
>> 110:             if (UNSAFE.shouldBeInitialized(refc)) {
> 
> This seems unrelated to the issue this PR is really about (if I understand correctly). Would it make sense to address this as part of another PR?

Also, perhaps @PaulSandoz knows more history on this one (I believe this code predates FFM).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1186069095

From mcimadamore at openjdk.org  Fri May  5 13:15:16 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 May 2023 13:15:16 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization
In-Reply-To: <m8hIMcObAklUJxarpfTAO5wWj98gR0tbKSITmwjX4Ag=.02bc505f-f42d-4d6f-82c8-baa8b3b4a1d3@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <vpmIVtqoZltiq3roT4VTJs8RNp5SaV8E_CcgUitztZg=.91847552-17ea-441b-b2b5-8c49963d1554@github.com>
 <m8hIMcObAklUJxarpfTAO5wWj98gR0tbKSITmwjX4Ag=.02bc505f-f42d-4d6f-82c8-baa8b3b4a1d3@github.com>
Message-ID: <3g-wsxTEx-IEX9iIBls_6dVygFQb8NRmKPsWoLfmlDc=.2cecd46f-b626-4db6-9853-a382587dbff8@github.com>

On Fri, 5 May 2023 13:03:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 74:
>> 
>>> 72:     @Override
>>> 73:     public boolean isAccessModeSupported(AccessMode accessMode) {
>>> 74:         var directTarget = this.directTarget;
>> 
>> Why is this not defined in the superclass, and then use `asDirect` (as done in other cases) ?
>
> I aim to avoid eager evaluation of directTarget (which is lazy in LazyStaticVarHandle, computing it requires initializing the holder class). This code path checks a stable field, so it should allow constant-folding when the direct target is available.

I see - so, since this is just a "query" you would like to avoid initialization just for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1186079374

From liach at openjdk.org  Fri May  5 13:15:18 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 May 2023 13:15:18 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization
In-Reply-To: <ztJEnwiepyNPLQmzylR7cpLknidTS2CrdnFS7xjWDtY=.c9801025-d550-4695-97c2-4add8281605e@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <vpmIVtqoZltiq3roT4VTJs8RNp5SaV8E_CcgUitztZg=.91847552-17ea-441b-b2b5-8c49963d1554@github.com>
 <ztJEnwiepyNPLQmzylR7cpLknidTS2CrdnFS7xjWDtY=.c9801025-d550-4695-97c2-4add8281605e@github.com>
Message-ID: <-6fIj8xnpnnmp6e8ZqQUpysApcO6_LJBLMOvCXsDw88=.8663ecd6-c7a6-4ed1-8162-d081a7484efd@github.com>

On Fri, 5 May 2023 13:02:05 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/VarHandles.java line 110:
>> 
>>> 108:         }
>>> 109:         else {
>>> 110:             if (UNSAFE.shouldBeInitialized(refc)) {
>> 
>> This seems unrelated to the issue this PR is really about (if I understand correctly). Would it make sense to address this as part of another PR?
>
> Also, perhaps @PaulSandoz knows more history on this one (I believe this code predates FFM).

Eh? I am not sure what you mean here. This is the essence of the patch, where the "TODO" above is fixed: lookup.findStaticVarHandle now creates lazy varhandle if the defining class of the field is not initialized.

The fixing of IndirectVarHandle.isAccessModeSupported is a side effect, because the override of `getMethodHandle` in `IndirectVarHandle` appears to me as a no-op; turns out it exists due to NPE in isAccessModeSupported, which IMO should be fixed as it's a public API.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1186075452

From mcimadamore at openjdk.org  Fri May  5 13:15:19 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 May 2023 13:15:19 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization
In-Reply-To: <-6fIj8xnpnnmp6e8ZqQUpysApcO6_LJBLMOvCXsDw88=.8663ecd6-c7a6-4ed1-8162-d081a7484efd@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <vpmIVtqoZltiq3roT4VTJs8RNp5SaV8E_CcgUitztZg=.91847552-17ea-441b-b2b5-8c49963d1554@github.com>
 <ztJEnwiepyNPLQmzylR7cpLknidTS2CrdnFS7xjWDtY=.c9801025-d550-4695-97c2-4add8281605e@github.com>
 <-6fIj8xnpnnmp6e8ZqQUpysApcO6_LJBLMOvCXsDw88=.8663ecd6-c7a6-4ed1-8162-d081a7484efd@github.com>
Message-ID: <bOr3So-Dj599gRA36s08-bFZ5FEZkWVqYPb8PQbQLbg=.0248cdf3-f509-4a7e-b52f-27cf709da887@github.com>

On Fri, 5 May 2023 13:08:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also, perhaps @PaulSandoz knows more history on this one (I believe this code predates FFM).
>
> Eh? I am not sure what you mean here. This is the essence of the patch, where the "TODO" above is fixed: lookup.findStaticVarHandle now creates lazy varhandle if the defining class of the field is not initialized.
> 
> The fixing of IndirectVarHandle.isAccessModeSupported is a side effect, because the override of `getMethodHandle` in `IndirectVarHandle` appears to me as a no-op; turns out it exists due to NPE in isAccessModeSupported, which IMO should be fixed as it's a public API.

> This seems unrelated to the issue this PR is really about (if I understand correctly). Would it make sense to address this as part of another PR?

Actually I realize I was confused as I came to this PR looking at this: https://bugs.openjdk.org/browse/JDK-8307508
And not realizing that this PR is about initialization (and, as a side-fix, it also addresses the access mode issue). I will leave to you whether to split or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1186077002

From duke at openjdk.org  Fri May  5 13:29:18 2023
From: duke at openjdk.org (Andy-Tatman)
Date: Fri, 5 May 2023 13:29:18 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: <9_jQnv5QwvqtYgnrbdKZu-HMI1WvT61AmJpWWsiDbyA=.5b631013-da40-4c83-9148-afe9b489760c@github.com>
References: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
 <K-vP8vrWjuyUpU1rC5GnePZmzb5A_NCW2aiLjOI5TlY=.80309645-8031-4d82-a2be-157b78d21bdb@github.com>
 <r1YnlgqY3dpeK4Cy62dcl1OUVo9h6toSaeq48e9Jh84=.ec64f374-c469-42c1-a796-bfa7308d7fdc@github.com>
 <Wz_Ky5w_qBUdBE7zsC9pRMH3XEdHXQyti4Tk2dammPA=.932f5719-dc8d-4c87-9a8a-40397f38ae2f@github.com>
 <5OfkgMk9QSD9KVNidbMkk1xpargpO2NNIolCDOGCWQ4=.40fb9ce2-ad17-48ed-aa3e-35cabf82a146@github.com>
 <9_jQnv5QwvqtYgnrbdKZu-HMI1WvT61AmJpWWsiDbyA=.5b631013-da40-4c83-9148-afe9b489760c@github.com>
Message-ID: <lBpzSm--zVUOzQCZtsj7ermWHTgGBEw4ut1n6Qg7nT8=.fbae994e-d10c-493d-ab77-a0f04af09569@github.com>

On Sat, 22 Apr 2023 01:26:08 GMT, Chen Liang <liach at openjdk.org> wrote:

> > I would be happy to fill out the CSR, but unfortunately I don't think I am able to currently as I'm not an author on OpenJDK and as such don't have a JBS account. (I reported the bug through the Oracle site, rather than through bugs.openjdk.org .) Would you be able to help out with this?
> 
> You can provide text for the Summary, Problem, Solution, and Specification parts of the CSR in this GitHub pull request, and I can help create a CSR for you with your provided contents. See https://wiki.openjdk.org/display/csr/Fields+of+a+CSR+Request

@liach 
My suggestion for the CSR (on the assumption this is indeed the way we decide to go): 

Summary:
Reject interactions with the bit at position Integer.MAX_VALUE in BitSet. 
This solves issues relating to the overflow of length(), as well as inconsistencies between 1 and 2 parameter versions of the methods set, clear, flip and get.

Problem:
BitSet.length() returns a negative value when Integer.MAX_VALUE is set, such as by using the set(int) method or by passing large arrays to a BitSet constructor. 
This also causes the get(fromIndex, toIndex) method to always return the empty BitSet when passed with valid parameters, regardless of the value of fromIndex and toIndex.

Furthermore, there is a discrepancy between bits that are accessible in a method such as set(int) and a method such as set(int,int). In the second method, because the method goes up to BUT NOT INCLUDING toIndex, it can never access the Integer.MAX_VALUE bit, while the first method can. 

Solution:
Prevent accessing the Integer.MAX_VALUE bit, such as by throwing an exception if methods try to access Integer.MAX_VALUE, such as in set(Integer.MAX_VALUE). 
For the methods that take in arrays and return a BitSet such as valueOf(longs[] longs),
these should specifically check and set the Integer.MAX_VALUE bit to 0 to avoid length() overflowing when wordsInUse refers to the word that contains the Integer.MAX_VALUE bit.

Specification:
length() returns a non-negative number.

In the methods set(int bitIndex), set(int bitIndex, int value), clear(int bitIndex), flip(int bitIndex) and get(int bitIndex), bitIndex must be smaller than Integer.MAX_VALUE. If Integer.MAX_VALUE is used, a IndexOutOfRangeException should be raised.

valueOf(...) ignores bits from bitIndex Integer.MAX_VALUE onwards (inclusive).

Risk:
Low.
Existing users who could set this bit would likely have already encounterd the bug with get(int,int) and length(). 

The change in valueOf(...)'s specifcation already reflects the functionality of the methods, the only change is that it now also applies to the bit at Integer.MAX_VALUE.

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

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1536259258

From duke at openjdk.org  Fri May  5 13:29:20 2023
From: duke at openjdk.org (Andy-Tatman)
Date: Fri, 5 May 2023 13:29:20 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
References: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
Message-ID: <aCbA46IEX05LN3C5wq7-Ts7iIsje_iKVqmwTyXiCkqY=.c6bf19ed-0604-4e04-beb9-96d535f49aa7@github.com>

On Fri, 7 Apr 2023 12:22:03 GMT, Andy-Tatman <duke at openjdk.org> wrote:

> See https://bugs.java.com/bugdatabase/view_bug?bug_id=8305734

I was first in favour of just doing the suggested fix in the commit, but given that functions such as get(int **, int**) can't access this bit anyway, I agree it might make more sense to block this bit outright.

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

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1536261548

From liach at openjdk.org  Fri May  5 13:37:36 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 5 May 2023 13:37:36 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
References: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
Message-ID: <jzXG5yIsEq_WUNCguKxV4XJNVfJNcAJWjyb3CG9tD9s=.ecd0c79c-f842-4bfc-8708-efaa6a6840a6@github.com>

On Fri, 7 Apr 2023 12:22:03 GMT, Andy-Tatman <duke at openjdk.org> wrote:

> See https://bugs.java.com/bugdatabase/view_bug?bug_id=8305734

A CSR has been created at https://bugs.openjdk.org/browse/JDK-8307539. You might have to use `/csr` in a comment to make the jdk dukebot update the info.

Note: The specification changes is usually the actual changes to the Javadoc or method signatures, as rendered in a patch file. I will update the specification once you added the `@throws IndexOutOfBoundsException if index is equal to Integer.MAX_VALUE` etc. Javadoc to the methods you propose to change (commited to this pull request)

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

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1536271234

From dfuchs at openjdk.org  Fri May  5 13:52:18 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 5 May 2023 13:52:18 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more VirtualThread
 friendly
Message-ID: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>

Several Handlers class use monitors to synchronize when formatting / publishing LogRecords.
When logging within a VirtualThread, holding this monitor can cause the carrier thread to be pinned.
Handlers could use jdk.internal.misc.InternalLock, in a similar way to some java.io classes (such as PrintStream) to avoid pinning the carrier thread.

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

Commit messages:
 - 8307535

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

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

From dfuchs at openjdk.org  Fri May  5 13:57:18 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 5 May 2023 13:57:18 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly
In-Reply-To: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
Message-ID: <muuGxgh_6Q578YJd2Do4qtvQ5m_Ge8PcTr8O5uwb3Qo=.0827ef9f-d0aa-4798-8cd5-70c6d7096b78@github.com>

On Fri, 5 May 2023 13:43:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Several Handlers class use monitors to synchronize when formatting / publishing LogRecords.
> When logging within a VirtualThread, holding this monitor can cause the carrier thread to be pinned.
> Handlers could use jdk.internal.misc.InternalLock, in a similar way to some java.io classes (such as PrintStream) to avoid pinning the carrier thread.

Something I was wondering:

Use of InternalLock can be disabled with `-Djdk.io.useMonitors=true`

But should we have a property to force the use of InternalLock (when enabled) even in the presence of custom handlers subclasses? We could use `-Djdk.io.useMonitors=false` to mean that - or introduce a new system property specific to `java.util.logging.Handlers`. For instance `-Djdk.logging.disableMonitors=true`? That could be helpful for applications that do heavy logging and use their own custom handlers.

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

PR Comment: https://git.openjdk.org/jdk/pull/13832#issuecomment-1536297097

From rriggs at openjdk.org  Fri May  5 13:59:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 5 May 2023 13:59:37 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v3]
In-Reply-To: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
Message-ID: <O6F5e_dRzOz4AX-Cigy4Hxq0lfFDcydWspCv-F4ZLsM=.ac479437-5dac-472c-9184-97d29292c3eb@github.com>

> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
> 
> Neither os.name nor os.arch should be assumed to be changeable; 
> one test case is removed because it assumes os.name can be changed on the command line.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Source code cleanup suggested by reviewers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13585/files
  - new: https://git.openjdk.org/jdk/pull/13585/files/5bf9a506..cfc404c1

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

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

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

From alanb at openjdk.org  Fri May  5 14:04:23 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 May 2023 14:04:23 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v5]
In-Reply-To: <iiAN4S9GuhGEJlIXFhmV1w65KcVCRmu5WUlyDMHCQ2o=.424ce196-c51c-4fbf-8ebf-cd5b1bd0eeb5@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <FzWi7GoZ0xR4YCPgwGvRgCfYotdI-7Qqqvz2sviG53o=.3012efbe-dead-4449-af08-bc29d84554a9@github.com>
 <YiqQPgB_kCzSfCpTIiYKdak9hbtmF85TnnwONq9-e0o=.ac8e2f03-56af-4a6d-b6c8-b3285ff38567@github.com>
 <D1U10iiO7vJHFxmcM1_eRvdB2A43OXy4-301zssm3Xo=.a4564f59-dace-4274-8e38-94dd41f29616@github.com>
 <lQachp5KZeetWQYBnW53t_Pf7DFt7KddHXQ-GLzoUUQ=.bdd12040-f270-478d-ba84-f176bd4a404c@github.com>
 <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com>
 <efZdJV-6YqzpSkSPpZiNkOLBfL-Wy-Mo9dU1pCMZXKk=.137f5eda-ed24-4d23-b83a-72d62066c562@github.com>
 <iiAN4S9GuhGEJlIXFhmV1w65KcVCRmu5WUlyDMHCQ2o=.424ce196-c51c-4fbf-8ebf-cd5b1bd0eeb5@github.com>
Message-ID: <hjTintlIZDaX51ji3MWEvnfi1n-Xyd4u-yV87gn6gCw=.eb85f4be-ad48-45b7-8982-f436f6f82ddb@github.com>

On Thu, 4 May 2023 19:32:45 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>>> [...] I'll see if I can test this on a mandrel build tomorrow...
>> 
>> @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you?
>
>> As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736.
>> 
>> Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same.
> 
> @olpaw Thanks for the input. Could you also please take a look of the changes that excludes the object files from the following static libraries from Graal native image usage perspective?
> 
> - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled. 
> - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a.

At first glance, static-libs-image create libjvm.a in the same directory as the other lib .a files make sense but I don't know how that works if --with-jvm-variants is used to create more more than one libjvm. Might have to think whether this combination make sense or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1186134127

From rriggs at openjdk.org  Fri May  5 14:12:21 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 5 May 2023 14:12:21 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v2]
In-Reply-To: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
Message-ID: <PEKg9keUFr1YbZ2wRIq-CjOGGi-vr6fduph5XVIcEhE=.74f584e9-450f-494a-ba5c-555a73d9b4d1@github.com>

> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
> 
> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
> Mac OS X 10.15 is the oldest version supported.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Minor source code style cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13586/files
  - new: https://git.openjdk.org/jdk/pull/13586/files/505ad721..5657da10

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

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

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

From rriggs at openjdk.org  Fri May  5 14:13:23 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 5 May 2023 14:13:23 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v3]
In-Reply-To: <ChbnjkazjvHdVA12WsVCzEdbM8EFP6QpllxUlS5U6Po=.42a0eea2-2489-41a6-989a-58ea464e3f22@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
 <ChbnjkazjvHdVA12WsVCzEdbM8EFP6QpllxUlS5U6Po=.42a0eea2-2489-41a6-989a-58ea464e3f22@github.com>
Message-ID: <wKM6lWgzGkfSG0uR6_wucMDM1LpzWCSQf4-UeqJAKUU=.5acaa895-dfc7-43e8-918f-80bce773fa71@github.com>

On Thu, 4 May 2023 12:36:32 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Source code cleanup suggested by reviewers
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 71:
> 
>> 69:      */
>> 70:     public static Platform runtime() {
>> 71:         return new Platform(OperatingSystem.current(), Architecture.current());
> 
> Should we create a single `private static final Platform`, in this class, to represent the current platform, and keep returning it instead of creating a new instance on each call?

The method is only called once and the object created is lightweight, it doesn't add much to retain a copy.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1186144818

From jpai at openjdk.org  Fri May  5 14:17:24 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 14:17:24 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v3]
In-Reply-To: <O6F5e_dRzOz4AX-Cigy4Hxq0lfFDcydWspCv-F4ZLsM=.ac479437-5dac-472c-9184-97d29292c3eb@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
 <O6F5e_dRzOz4AX-Cigy4Hxq0lfFDcydWspCv-F4ZLsM=.ac479437-5dac-472c-9184-97d29292c3eb@github.com>
Message-ID: <lAI9ODGvNyiMxlVxMDIXFjbwaFzPofucQEBRGBkhgLA=.0a48feea-5d79-4e43-a292-11b91519a36a@github.com>

On Fri, 5 May 2023 13:59:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
>> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
>> 
>> Neither os.name nor os.arch should be assumed to be changeable; 
>> one test case is removed because it assumes os.name can be changed on the command line.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Source code cleanup suggested by reviewers

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13585#pullrequestreview-1414880806

From jpai at openjdk.org  Fri May  5 14:17:26 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 5 May 2023 14:17:26 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v3]
In-Reply-To: <wKM6lWgzGkfSG0uR6_wucMDM1LpzWCSQf4-UeqJAKUU=.5acaa895-dfc7-43e8-918f-80bce773fa71@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
 <ChbnjkazjvHdVA12WsVCzEdbM8EFP6QpllxUlS5U6Po=.42a0eea2-2489-41a6-989a-58ea464e3f22@github.com>
 <wKM6lWgzGkfSG0uR6_wucMDM1LpzWCSQf4-UeqJAKUU=.5acaa895-dfc7-43e8-918f-80bce773fa71@github.com>
Message-ID: <vSHkknt3XQPkk8mmlvR9fDo_ZAeflUAi7cHquo5dqV8=.b4572f4f-548d-4e12-8b5f-d23ebc1ca7e8@github.com>

On Fri, 5 May 2023 14:10:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 71:
>> 
>>> 69:      */
>>> 70:     public static Platform runtime() {
>>> 71:         return new Platform(OperatingSystem.current(), Architecture.current());
>> 
>> Should we create a single `private static final Platform`, in this class, to represent the current platform, and keep returning it instead of creating a new instance on each call?
>
> The method is only called once and the object created is lightweight, it doesn't add much to retain a copy.

That sounds reasonable to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1186149633

From alanb at openjdk.org  Fri May  5 14:43:23 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 May 2023 14:43:23 GMT
Subject: RFR: 8307483: New micros for j.u.c.LockSupport
In-Reply-To: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
References: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
Message-ID: <MPCS9xNA6fkUt-z01pnXcd4cpXYzsTFH9LAmM4tFm8w=.a54f610c-1095-4b18-bb45-36562881d5d1@github.com>

On Thu, 4 May 2023 20:17:11 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> These micros were developed while investigating JDK-8305670 by myself and Sergey Kuksenko. The order of thread creation was important in that bug, so there are 2 JMH for creating sleepers before and after the worker threads.

test/micro/org/openjdk/bench/java/util/concurrent/UnparkBenchSleepersAfter.java line 131:

> 129:         public void run() {
> 130:             my_thread = Thread.currentThread();
> 131:             while (!done) {

You might want to re-check IdleThread. From a quick look I would have expected "done" to be volatile. Also "my_thread" as it is set in the run with plain access.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1186169006

From duke at openjdk.org  Fri May  5 14:53:17 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 5 May 2023 14:53:17 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly
In-Reply-To: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
Message-ID: <1jAH1Osj4nzoOzzoZ8dTfbt7JC4tpWZ3Grf0It9jc2g=.92ea670d-23d0-4e33-8886-53e726b91aec@github.com>

On Fri, 5 May 2023 13:43:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Several Handlers class use monitors to synchronize when formatting / publishing LogRecords.
> When logging within a VirtualThread, holding this monitor can cause the carrier thread to be pinned.
> Handlers could use jdk.internal.misc.InternalLock, in a similar way to some java.io classes (such as PrintStream) to avoid pinning the carrier thread.

I'm just an author, not a reviewer, but I'm also the creator of the `jboss-logmanager` project, which is based heavily on subclassing many of the `java.util.logging` APIs.

One thing I noticed is that the setters for filter/formatter/level etc. still use synchronized; I guess that user-based subclasses could still depend on this, and handlers which use the internal lock don't care. But if this is the case, then in the internal lock case, synchronization isn't actually needed at all, so this could be tested for and optimized in this case. Otherwise it might be useful to leave a comment that explains the situation, since it's not obvious?

I didn't see anything else that looked like a red flag with this change so it's a non-binding +1 from me, for whatever it is worth, other than the above observation.

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

PR Comment: https://git.openjdk.org/jdk/pull/13832#issuecomment-1536377319

From mdoerr at openjdk.org  Fri May  5 15:00:10 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 5 May 2023 15:00:10 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v27]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <a1r27iK06jUE3-hb6-vXWaOpPGcAeov_5TZC3sSl6Io=.cc90db44-c8da-419d-9cf9-7f6a228e75eb@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Add test case for passing a double value in a GP register. Use better instructions for moving between FP and GP reg. Improve comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/e4ddbda0..754a19a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=25-26

  Stats: 110 lines in 4 files changed: 88 ins; 2 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12708/head:pull/12708

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

From jlaskey at openjdk.org  Fri May  5 15:17:23 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 15:17:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <PFx1nZamLhK4hMdqWpfrNYU867GRQfLIhJHXNKOtlZg=.0d310ee2-bca5-40f1-9ed4-f40c28ebbd51@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
 <PFx1nZamLhK4hMdqWpfrNYU867GRQfLIhJHXNKOtlZg=.0d310ee2-bca5-40f1-9ed4-f40c28ebbd51@github.com>
Message-ID: <RGKtTY66shAVBNXOd8sTf_SPkZtqS_c_J_xPs_vtsHM=.dbd38a99-ac48-42d8-82f7-dddebb8d2bc2@github.com>

On Fri, 5 May 2023 09:28:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Anonymous main classes renamed to unnamed classes
>>  - Add test
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 139:
> 
>> 137:     public static Method findMainMethod(Class<?> mainClass) throws NoSuchMethodException {
>> 138:         try {
>> 139:             Method mainMethod = mainClass.getMethod("main", String[].class);
> 
> Hello Jim, I think this specific line is trying to find a `public static void main(String[])` method from the launched class. In the current form of this implementation, this has the potential of returning a non-static `public void main(String[])` from here. I think a `isStatic(mainMethod)` would be needed here before returning this method as the found method.

The problem with modifying behaviour that has existed since JDK 1.0 is that it has to be compatible in unexpected ways. If you look at the code modification:


-            mainMethod = mainClass.getMethod("main", String[].class);
+           mainMethod = MainMethodFinder.findMainMethod(mainClass);


you can see that nothing has really changed. The mainMethod was always possibly non-static and the caller produced an appropriate error message if that was the case. There is the rub.  If I didn't do it the way I have, I would also have to modify 130+ tests that expect to fail with a "method is not static" message as oppose to a "method not found" error message (there are other related issues to args and return types). After spending several days wading through a handful of these ancient tests, I realized I did not have time to complete the modifications necessary before targeting. And, there is also the issue of what happens to tests and expectations downstream. For a preview feature, behaviour has to remain the same when preview is not enabled.

I was also hopeful to be able to unify the _java launcher_ and the _source code launcher_. Similar problem with error messaging, though the tests for the source code launcher are fewer and newer. 

Unifying the launchers would also introduce another downstream issue. Since launching would occur from Java code, addition frames appear on the stack. Seems there are a several tests, tools and debuggers that rely on "main" being the first frame (even if hidden by printStackTrace). Ugh.

Before the next cycle, I hope to unify the messaging, have someone clean up the tests and figure out a scheme that unifies the launching.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186216248

From jlaskey at openjdk.org  Fri May  5 15:24:50 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 15:24:50 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <PFx1nZamLhK4hMdqWpfrNYU867GRQfLIhJHXNKOtlZg=.0d310ee2-bca5-40f1-9ed4-f40c28ebbd51@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
 <PFx1nZamLhK4hMdqWpfrNYU867GRQfLIhJHXNKOtlZg=.0d310ee2-bca5-40f1-9ed4-f40c28ebbd51@github.com>
Message-ID: <6Rr-jSur-o5l60DNHYg-1GoZS7LO9Fc8S9d83Zs4Q7g=.58c21be6-a3b0-48be-9fff-74ad1c1f43dd@github.com>

On Fri, 5 May 2023 09:30:54 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Anonymous main classes renamed to unnamed classes
>>  - Add test
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 142:
> 
>> 140: 
>> 141:             if (mainMethod.getDeclaringClass() != mainClass) {
>> 142:                 System.err.println("WARNING: static main in super class will be deprecated.");
> 
> Similarly, this warning would have to be logged only if the method is `static`. Furthermore, do you think we should include the declaring class in the log message to provide some context on what's causing this warning? Something like:
>> WARNING: static main(String[]) in super class foo.bar.Parent will be deprecated.

Yes this is an oversight on my part.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186223626

From jlaskey at openjdk.org  Fri May  5 15:28:23 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 15:28:23 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <y3v3m2IK2ftt0qwfe6wcoU2uGakneHJ96JI25D65QTk=.822e0b64-2a70-4170-af91-c9a432e3054a@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
 <y3v3m2IK2ftt0qwfe6wcoU2uGakneHJ96JI25D65QTk=.822e0b64-2a70-4170-af91-c9a432e3054a@github.com>
Message-ID: <cYUTlEko14g4NHZAyuNvud-ttBiNsdKtzGLCwWjFvLA=.b85426a1-9965-49ff-bb06-eec72e4b3046@github.com>

On Fri, 5 May 2023 09:39:07 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Anonymous main classes renamed to unnamed classes
>>  - Add test
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 158:
> 
>> 156:             }
>> 157: 
>> 158:             mains.sort(MainMethodFinder::compareMethods);
> 
> Perhaps skip the call to `sort` and just return the found main method if `mains.size() == 1`?

Likely negligible difference since it's interpreted code, but what the hey.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186227774

From jlaskey at openjdk.org  Fri May  5 15:50:26 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 15:50:26 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <C7voJ4xJR6Ci5ZQJEUhIe_erfY18b9yPyvh-sIhtkWs=.fd5d02af-71b5-435c-8d33-3345042fa524@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
 <C7voJ4xJR6Ci5ZQJEUhIe_erfY18b9yPyvh-sIhtkWs=.fd5d02af-71b5-435c-8d33-3345042fa524@github.com>
Message-ID: <McxWY5003NdIXyU_nvdLI_J4LR33I4BLGzH9CnE8UyM=.98843605-fbda-4f7f-9e67-219afecff815@github.com>

On Fri, 5 May 2023 09:43:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Anonymous main classes renamed to unnamed classes
>>  - Add test
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 70:
> 
>> 68:                         correctArgs(method) &&
>> 69:                         // Only statics in the declaring class
>> 70:                         (!isStatic(method) || declc == refc)
> 
> Should this also exclude `abstract` and `native` methods named `main`?

abstract would be overshadowed by its implementation and native is fair game.

> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 134:
> 
>> 132: 
>> 133:     /**
>> 134:      * {@return priority main method or null if none found}
> 
> I think this javadoc is perhaps outdated? The current implementation of this method throws a `NoSuchMethodException` when it can't find any eligible main method.

Changing

> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 152:
> 
>> 150: 
>> 151:             List<Method> mains = new ArrayList<>();
>> 152:             gatherMains(mainClass, mainClass, mains);
> 
> The `try` block above is there to find `public static void main(String[])` in the launched class. When it's not found, then we gather the potential main methods (as listed in the JEP). The implementation of `gatherMains(...)`, in its current form starts gathering the main methods from `refc.getSuperclass()`, where `refc` in this case is the `mainClass`, which is the launched class.
> 
> So if I'm reading this correctly, then I think it's going to completely skip the launched class for looking any potential main methods and instead start looking for them in the launched class' super hierarchy.

It doesn't skip, it just adds the super members first. However, I should move the `gatherMains` to the end since the sort pushes the best candidate to the top  and (was originally taking the last one with an opposite sort order). The sort order is

- static trumps non-static
- public trumps protected/package-protected
- arguments trumps no arguments
- depth in hierarchy

Let's say we have a hierarchy of `B` inherits from `A`.  If `B` contains `public void main()` and `A` contains `public void main(String... args)`,  `A`'s `main` trumps `B` `main` since it has  arguments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186247702
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186249703
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186245072

From mcimadamore at openjdk.org  Fri May  5 16:02:35 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 5 May 2023 16:02:35 GMT
Subject: Integrated: 8307375: Alignment check on layouts used as sequence
 element is not correct
In-Reply-To: <sPoNFTqvdKTSkVRlpG2Kxqhx6aueV0ukgwUv9lHQCWg=.f9a35c3a-7501-45d5-abb2-a1bac7804bf7@github.com>
References: <sPoNFTqvdKTSkVRlpG2Kxqhx6aueV0ukgwUv9lHQCWg=.f9a35c3a-7501-45d5-abb2-a1bac7804bf7@github.com>
Message-ID: <qst_WX0UzT7chck5SQO8anexA_HAfvyQ2T380VWKKnA=.2e7d547f-8314-4550-b9de-b6c58c4dc7a5@github.com>

On Wed, 3 May 2023 17:44:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes `Utils::checkElementAlignment` to do the right thing for _all_ layouts.
> 
> The current implementation is broken, as it only works correctly when the input layout is a value layout.
> Since value layouts have a size that is a power of two (and size all layouts have alignment that is also a power of two), then verifying that `size > alignment` works well.
> 
> But if the input layout is some other layout (e.g. a `StructLayout`), this "power of two" assumption no longer holds. E.g. we can have a layout whose size is 48, and whose alignment is 32. While 48 is clearly bigger than 32, such a layout is still not suitable to be used as an element layout in a sequence.
> 
> The fix is to provide two overloads for `Utils::checkElementAlignment` - one which works on `ValueLayout` and another which works on any `MemoryLayout`. The `ValueLayout` version works as before (so performance is not affected).
> The `MemoryLayout` variant would perform a full check using the `%` operator. Currently we only use this when creating a new sequence layout and when creating a stream out of a memory segment, so I'm not worried about potential performance regressions.
> 
> I've fixed the javadoc so that the various `@throws` clauses in the affected methods reflect the correct behavior.
> 
> Finally, I've made the existing alignment/layout tests a bit more robust, by also adding pair-wise combinations of layouts, wrapped in a struct/union. This does generate illegal layout cases which would not have been detected w/o this patch.

This pull request has now been integrated.

Changeset: 47422be2
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/47422be2d1d74e5e1b4b6c8e1a75e134e4f6aaf5
Stats:     85 lines in 6 files changed: 61 ins; 0 del; 24 mod

8307375: Alignment check on layouts used as sequence element is not correct

Reviewed-by: jvernee

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

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

From jlaskey at openjdk.org  Fri May  5 16:02:39 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 16:02:39 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <R3xsNOfuMNqZ8xiwQ3AOwhIFFi7oOlvikW_FPI9axU8=.edf5c6fa-1db7-4192-8f78-20a0a02ef41a@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
 <R3xsNOfuMNqZ8xiwQ3AOwhIFFi7oOlvikW_FPI9axU8=.edf5c6fa-1db7-4192-8f78-20a0a02ef41a@github.com>
Message-ID: <J8kxyHI9Xwf3yE_McDMbO3xgx-imO3T1BSo1Q0cAp6w=.0b6f193f-063c-40fd-8ca3-dfddb3587952@github.com>

On Fri, 5 May 2023 09:52:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Anonymous main classes renamed to unnamed classes
>>  - Add test
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 872:
> 
>> 870:         Method mainMethod = null;
>> 871:         try {
>> 872:             mainMethod = MainMethodFinder.findMainMethod(mainClass);
> 
> The `MainMethodFinder.findMainMethod(...)` throws a `NoSuchMethodException` when it can't find the regular `public static void main(String[])` or, when preview is enabled, any other eligible main methods. That will now mean that the next line here which catches a `NoSuchMethodException` can potentially end up aborting with a (very confusing) error message about JavaFX application. We should perhaps change that catch block to something like:
> 
> } catch (NoSuchMethodException nsme) {
>    if (!PreviewFeatures.isEnabled()) {
>                   // invalid main or not FX application, abort with an error
>             abort(null, "java.launcher.cls.error4", mainClass.getName(),
>                   JAVAFX_APPLICATION_CLASS_NAME);
>    } else {
>        // abort with something more clear error?
>    }

Not convinced that anything has changed or that the message is confusing.

> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 893:
> 
>> 891:          * findMainMethod (above) will choose the correct method, based
>> 892:          * on its name and parameter type, however, we still have to
>> 893:          * ensure that the method is static (non-preview) and returns a void.
> 
> I think it's probably going to be easier to read and maintain if we moved these checks for `static` and `void` return type into the `MainMethodFinder.findMainMethod(...)` itself. 
> What I mean is once we return from the `findMainMethod(...)`, I think the callers, like this code here, shouldn't have to do additional checks to know if this main method is valid and can be used.

I agree, but from my early commentary we have to hold off until later.

> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 419:
> 
>> 417:     private static boolean isStatic(Method method) {
>> 418:         return method != null && Modifier.isStatic(method.getModifiers());
>> 419:     }
> 
> It looks like these new methods aren't being used.

Remnants - removing

> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 440:
> 
>> 438:             int mods = mainMethod.getModifiers();
>> 439:             boolean isStatic = Modifier.isStatic(mods);
>> 440:             boolean isPublic = Modifier.isStatic(mods);
> 
> This looks like a typo. This should have been `Modifier.isPublic(mods);`

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186258290
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186259446
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186261107
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186259830

From jlaskey at openjdk.org  Fri May  5 16:08:22 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 16:08:22 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v8]
In-Reply-To: <A0WrdmSrfwGua2Vy4XExnCJGGTcYBIt4p2xBmIX6fjA=.53b3b5ba-3cb5-47cf-b154-81936df4530c@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <bhO7D2g1qxLRU-Fo0x_k3DXMwE4sdba3QNAs-tAS8Xk=.239d464f-bdcb-4064-a9a4-0393cd4e7a40@github.com>
 <A0WrdmSrfwGua2Vy4XExnCJGGTcYBIt4p2xBmIX6fjA=.53b3b5ba-3cb5-47cf-b154-81936df4530c@github.com>
Message-ID: <K13hX3nRLojC9OmU33jAODsRp-OCi21G8jzIxpzRgD0=.7ec1cca9-5fdf-4a5a-8532-5f7a3c95fb5c@github.com>

On Fri, 5 May 2023 10:15:02 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Anonymous main classes renamed to unnamed classes
>>  - Add test
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 457:
> 
>> 455:             if (isStatic) {
>> 456:                 if (noArgs) {
>> 457:                     mainMethod.invoke(appClass);
> 
> Given that `Method.invoke(...)` on a static method ignores the `obj` param that's passed to it, perhaps pass `null`?

Nostalgia and a useful reminder.

> test/jdk/tools/launcher/InstanceMainTest.java line 33:
> 
>> 31: public class InstanceMainTest extends TestHelper {
>> 32: 
>> 33:     @Test
> 
> Does this compile? I don't see imports for this annotation and this is launched as a `@run main ....`

Same package

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186263733
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186265984

From jlaskey at openjdk.org  Fri May  5 16:18:42 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 16:18:42 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v9]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <rElTo20q1b4P1lhrIdl69ZO4ALKt9UW03bS7gVH9iyg=.9c8497f9-8687-497a-94e7-37f3b9563607@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Recommended changes #2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/ff7cd4c7..788b4e5a

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

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

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

From dfuchs at openjdk.org  Fri May  5 16:38:14 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 5 May 2023 16:38:14 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly
In-Reply-To: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
Message-ID: <qSMnw6r3Cc8mDcEHs-mtdWjEj6xcwZXkKxjP1vKB0u8=.a4c7f3f6-1a2a-49b1-b8c2-e3fda5ae938e@github.com>

On Fri, 5 May 2023 13:43:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Several Handlers class use monitors to synchronize when formatting / publishing LogRecords.
> When logging within a VirtualThread, holding this monitor can cause the carrier thread to be pinned.
> Handlers could use jdk.internal.misc.InternalLock, in a similar way to some java.io classes (such as PrintStream) to avoid pinning the carrier thread.

Thanks for your observations David! 

Use of synchronization in these handler classes has two purposes: one is visibility. Since Handlers are used by multiple (logging) threads, and potentially configured from different threads (e.g. main thread), it is important that changes to configuration made by one thread are visible to other threads. To achieve this - getter and setter use the synchronized keyword - and from my analysis - it didn't seem required to change these to use a Lock, especially since these methods just set or get fields, without calling out methods on other objects (that may further down the road cause the thread to park).

Another use of synchronization is to ensure consistency. Publish uses synchronization for instance, to make sure that there is no concurrent publication of records, which could cause an inconsistent state in the output. In some cases, changing some of the fields during publication is also not desirable - and that is why setEncoding/setOutputStream have  been changed to also use the same lock than publish() is using.

Your question pushed me to double check that I got the logic right - which made me noticed I missed some updates in SocketHandler. So it's doubly appreciated :-) 

I could - for consistency - change the logic to alter every use of synchronized (including any getter/setter) to use the internal lock if present - but it didn't seem necessary, and I choose to minimize my changes. If you or other reviewers think that it would be better to switch all uses of synchronized to consider using the internal lock if present, I can do that.

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

PR Comment: https://git.openjdk.org/jdk/pull/13832#issuecomment-1536498908

From dfuchs at openjdk.org  Fri May  5 16:38:13 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 5 May 2023 16:38:13 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v2]
In-Reply-To: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
Message-ID: <cjZXKytFsV8FD2JoRdcFrBL520clsHSiEIIbdx2frgg=.f93c59ea-497c-49de-b747-5177ab87bffe@github.com>

> Several Handlers class use monitors to synchronize when formatting / publishing LogRecords.
> When logging within a VirtualThread, holding this monitor can cause the carrier thread to be pinned.
> Handlers could use jdk.internal.misc.InternalLock, in a similar way to some java.io classes (such as PrintStream) to avoid pinning the carrier thread.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Missed changes to SocketHandler.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13832/files
  - new: https://git.openjdk.org/jdk/pull/13832/files/257588ad..39646ce0

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

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

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

From jiangli at openjdk.org  Fri May  5 16:45:35 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 5 May 2023 16:45:35 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v6]
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <OTlIbdMlYO2YbzYfyygWPmT6cAq6FSQ27qBSfVwV3Hk=.2ed86889-b369-44d9-8b06-884498fb6652@github.com>

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries:
> 
> - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib';
> - For libjvm.a specifically, exclude operator_new.o;
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files;
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk;
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS;

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw:
    - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a.
    - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a.
    - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib.
  - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now:
    - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk.
    - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13768/files
  - new: https://git.openjdk.org/jdk/pull/13768/files/84861990..e49d7b4e

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

  Stats: 78 lines in 4 files changed: 64 ins; 8 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13768.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768

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

From jiangli at openjdk.org  Fri May  5 16:48:12 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 5 May 2023 16:48:12 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v6]
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <OTlIbdMlYO2YbzYfyygWPmT6cAq6FSQ27qBSfVwV3Hk=.ef941af5-7c02-4b07-9324-dcc82a357b0c@github.com>

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries:
> 
> - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib';
> - For libjvm.a specifically, exclude operator_new.o;
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files;
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk;
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS;

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw:
    - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a.
    - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a.
    - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib.
  - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now:
    - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk.
    - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13768/files
  - new: https://git.openjdk.org/jdk/pull/13768/files/84861990..e49d7b4e

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

  Stats: 78 lines in 4 files changed: 64 ins; 8 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13768.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768

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

From jiangli at openjdk.org  Fri May  5 16:48:13 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 5 May 2023 16:48:13 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v6]
In-Reply-To: <efZdJV-6YqzpSkSPpZiNkOLBfL-Wy-Mo9dU1pCMZXKk=.137f5eda-ed24-4d23-b83a-72d62066c562@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <FzWi7GoZ0xR4YCPgwGvRgCfYotdI-7Qqqvz2sviG53o=.3012efbe-dead-4449-af08-bc29d84554a9@github.com>
 <YiqQPgB_kCzSfCpTIiYKdak9hbtmF85TnnwONq9-e0o=.ac8e2f03-56af-4a6d-b6c8-b3285ff38567@github.com>
 <D1U10iiO7vJHFxmcM1_eRvdB2A43OXy4-301zssm3Xo=.a4564f59-dace-4274-8e38-94dd41f29616@github.com>
 <lQachp5KZeetWQYBnW53t_Pf7DFt7KddHXQ-GLzoUUQ=.bdd12040-f270-478d-ba84-f176bd4a404c@github.com>
 <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com>
 <efZdJV-6YqzpSkSPpZiNkOLBfL-Wy-Mo9dU1pCMZXKk=.137f5eda-ed24-4d23-b83a-72d62066c562@github.com>
Message-ID: <PKpC6-DU8dF1CMCarCEVAwfgUqLG-akTNX608VhrjlE=.0268cc91-681a-4dea-ad3b-ae03ee8839c3@github.com>

On Thu, 4 May 2023 19:12:14 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> As @jerboaa mentioned, for GraalVM native-image we produce our own `libjvm.a` as part of building GraalVM (every native image gets statically linked to that library). See https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/mx_substratevm.py#L1378 and `com.oracle.svm.native.jvm.{posix,windows}` in https://github.com/oracle/graal/blob/f1c1d710625ac84559a6ef69c4068c9d8c2c9f8b/substratevm/mx.substratevm/suite.py#L736.
>> 
>> Having a hot-spot variant of `libjvm.a` next to the other static libraries might complicate things for us. Ideally the output files produced by target `static-libs-image` should remain the same.
>
>> [...] I'll see if I can test this on a mandrel build tomorrow...
> 
> @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you?

> @jerboaa Thanks very much for testing with mandrel. Based on yours and @olpaw's feedback, I'll refactor this PR to not use the existing `static-libs-image` target for including hotspot `libjvm.a`.

Updated PR to decouple building libjvm.a from static-libs-image target. Add a java-static-libs-image target for building the static library super set, which includes JDK .a static libraries and hotspot libjvm.a.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1186300461

From jiangli at openjdk.org  Fri May  5 16:52:22 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 5 May 2023 16:52:22 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v7]
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com>

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/VM static libraries:
> 
> - Create libjvm.a together with other JDK static libraries when building 'static-libs-image' (or 'static-libs-bundles') target, include it in 'images/static-libs/lib';
> - For libjvm.a specifically, exclude operator_new.o;
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from .a libraries; That's to avoid linker errors due to the duplicate symbols problems from the related .o files;
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk;
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS;

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Fix whitespace error in make/StaticJvmLibsImage.gmk.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13768/files
  - new: https://git.openjdk.org/jdk/pull/13768/files/e49d7b4e..2cb786ab

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

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

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

From jiangli at openjdk.org  Fri May  5 16:53:35 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 5 May 2023 16:53:35 GMT
Subject: RFR: 8307194: Enhance static-libs-image [v7]
In-Reply-To: <PKpC6-DU8dF1CMCarCEVAwfgUqLG-akTNX608VhrjlE=.0268cc91-681a-4dea-ad3b-ae03ee8839c3@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <FzWi7GoZ0xR4YCPgwGvRgCfYotdI-7Qqqvz2sviG53o=.3012efbe-dead-4449-af08-bc29d84554a9@github.com>
 <YiqQPgB_kCzSfCpTIiYKdak9hbtmF85TnnwONq9-e0o=.ac8e2f03-56af-4a6d-b6c8-b3285ff38567@github.com>
 <D1U10iiO7vJHFxmcM1_eRvdB2A43OXy4-301zssm3Xo=.a4564f59-dace-4274-8e38-94dd41f29616@github.com>
 <lQachp5KZeetWQYBnW53t_Pf7DFt7KddHXQ-GLzoUUQ=.bdd12040-f270-478d-ba84-f176bd4a404c@github.com>
 <8PLZSKy3BqQJtO70vyqRrc3uCnbbipqF9Jjv1ILTKyo=.9366d45f-f471-47aa-a59e-88e65cf6e2af@github.com>
 <efZdJV-6YqzpSkSPpZiNkOLBfL-Wy-Mo9dU1pCMZXKk=.137f5eda-ed24-4d23-b83a-72d62066c562@github.com>
 <PKpC6-DU8dF1CMCarCEVAwfgUqLG-akTNX608VhrjlE=.0268cc91-681a-4dea-ad3b-ae03ee8839c3@github.com>
Message-ID: <pfbV1ltSClcC_vgU83PEdRpHUD3J7GSmrzx9MPTzgLY=.b98fa107-b08d-4574-a9c6-2ce33a251aa1@github.com>

On Fri, 5 May 2023 16:43:46 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>>> [...] I'll see if I can test this on a mandrel build tomorrow...
>> 
>> @jianglizhou So I've tested this with a mandrel build and it doesn't break terribly, but a graalvm build after this patch has *two* `libjvm.a` which a) doesn't make sense, b) the hotspot version is **very** large (> 1 GB on my system), so unnecessarily bloats the install. I remain of the opinion that the hotspot `libjvm.a` should only get generated for a new make target (not change the old `static-libs-image` target). Do you think that would be a workable solution for you?
>
>> @jerboaa Thanks very much for testing with mandrel. Based on yours and @olpaw's feedback, I'll refactor this PR to not use the existing `static-libs-image` target for including hotspot `libjvm.a`.
> 
> Updated PR to decouple building libjvm.a from static-libs-image target. Add a java-static-libs-image target for building the static library super set, which includes JDK .a static libraries and hotspot libjvm.a.

> At first glance, static-libs-image create libjvm.a in the same directory as the other lib .a files make sense but I don't know how that works if --with-jvm-variants is used to create more more than one libjvm. Might have to think whether this combination make sense or not.

We now use a java-static-libs-image target for building all JDK and hotspot .a static libraries.

@erikj79 Suggested building libjvm.a for $(JVM_VARIANT_MAIN) for now. I think that's a good starting point. The PR has been updated accordingly.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1186308007

From naoto at openjdk.org  Fri May  5 16:55:30 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 5 May 2023 16:55:30 GMT
Subject: RFR: 8306927: Collator treats "v" and "w" as the same letter for
 Swedish language locale.
In-Reply-To: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
Message-ID: <H0aWZy8oYIqAbd9UD8PLn1uUxEAPq0oxhnVbQolT8hE=.4a0e70ae-2a97-439e-8e49-6511eb274f29@github.com>

On Wed, 26 Apr 2023 20:42:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the collation rules for Swedish to the modern one, which is aligned with the CLDR's default collation rules. Since it is changing the existing behavior, a release note has also been drafted: https://bugs.openjdk.org/browse/JDK-8306948

I created an enhancement for Collator to support multiple tables: [JDK-8307547](https://bugs.openjdk.org/browse/JDK-8307547) that would require a CSR where we can discuss the default

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

PR Comment: https://git.openjdk.org/jdk/pull/13677#issuecomment-1536525383

From duke at openjdk.org  Fri May  5 17:09:19 2023
From: duke at openjdk.org (David M. Lloyd)
Date: Fri, 5 May 2023 17:09:19 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly
In-Reply-To: <qSMnw6r3Cc8mDcEHs-mtdWjEj6xcwZXkKxjP1vKB0u8=.a4c7f3f6-1a2a-49b1-b8c2-e3fda5ae938e@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <qSMnw6r3Cc8mDcEHs-mtdWjEj6xcwZXkKxjP1vKB0u8=.a4c7f3f6-1a2a-49b1-b8c2-e3fda5ae938e@github.com>
Message-ID: <mwCQWxyRAuu6BbFvStxX91dA5iHQPn1TfIZOe5ZtlqE=.93329ded-98ae-4276-8cfc-74a30748403e@github.com>

On Fri, 5 May 2023 16:31:18 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thanks for your observations David!
> 
> Use of synchronization in these handler classes has two purposes: one is visibility. Since Handlers are used by multiple (logging) threads, and potentially configured from different threads (e.g. main thread), it is important that changes to configuration made by one thread are visible to other threads. To achieve this - getter and setter use the synchronized keyword - and from my analysis - it didn't seem required to change these to use a Lock, especially since these methods just set or get fields, without calling out methods on other objects (that may further down the road cause the thread to park).

I believe this is not strictly accurate: the fields I referred to (specifically `filter`, `formatter`, `logLevel`, `errorManager`, and `encoding`) are all `volatile`. There's also a note:


    // We're using volatile here to avoid synchronizing getters, which
    // would prevent other threads from calling isLoggable()
    // while publish() is executing.
    // On the other hand, setters will be synchronized to exclude concurrent
    // execution with more complex methods, such as StreamHandler.publish().
    // We wouldn't want 'level' to be changed by another thread in the middle
    // of the execution of a 'publish' call.


So, `synchronized` on these methods does not affect their atomicity (they're already all simple volatile writes) nor the visibility of the values which are written (again, volatile). The only effect it has then is to serialize access to these fields with respect to publication or other accesses - something which is explicitly bypassed when using the internal lock with publication (in the case, since the publication lock and the access lock for these fields would not be the same lock. Thus, when the internal lock is used, acquiring the monitor on these methods has no purpose, which is why I made the suggestion. It is in the end just an optimization though.

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

PR Comment: https://git.openjdk.org/jdk/pull/13832#issuecomment-1536542516

From vromero at openjdk.org  Fri May  5 17:11:28 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 May 2023 17:11:28 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v9]
In-Reply-To: <rElTo20q1b4P1lhrIdl69ZO4ALKt9UW03bS7gVH9iyg=.9c8497f9-8687-497a-94e7-37f3b9563607@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <rElTo20q1b4P1lhrIdl69ZO4ALKt9UW03bS7gVH9iyg=.9c8497f9-8687-497a-94e7-37f3b9563607@github.com>
Message-ID: <Oof-ANXv-2H1R-R_8LpgrFtT4CAlJZdeMufGqbv8G4s=.06d1bcd0-5eea-4c84-839f-3b422515c0a7@github.com>

On Fri, 5 May 2023 16:18:42 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Recommended changes #2

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 138:

> 136:      * @param mainClass main class
> 137:      *
> 138:      * @throws NoSuchMethodException when not and preview and no method found

wording here? `when not and preview`?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3999:

> 3997:         Name name = names.fromString(simplename);
> 3998:         JCModifiers anonMods = F.at(primaryPos)
> 3999:                 .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC|Flags.UNNAMED_CLASS, List.nil());

I wonder if testing if a class has flags: `Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC` should be enough to know if it is unnamed or not and we don't need to use the new `UNNAMED_CLASS` flag

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186299301
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186323116

From jlaskey at openjdk.org  Fri May  5 17:31:27 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 17:31:27 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v10]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <eitzFKM5aVarsQ9hRKdVxxxuYA_GbTLnGgCpBtGvICs=.7f576b1b-4b2f-43e6-90d6-96deff997ff2@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/788b4e5a..0c8add65

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

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

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

From jlaskey at openjdk.org  Fri May  5 17:31:30 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 17:31:30 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v9]
In-Reply-To: <Oof-ANXv-2H1R-R_8LpgrFtT4CAlJZdeMufGqbv8G4s=.06d1bcd0-5eea-4c84-839f-3b422515c0a7@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <rElTo20q1b4P1lhrIdl69ZO4ALKt9UW03bS7gVH9iyg=.9c8497f9-8687-497a-94e7-37f3b9563607@github.com>
 <Oof-ANXv-2H1R-R_8LpgrFtT4CAlJZdeMufGqbv8G4s=.06d1bcd0-5eea-4c84-839f-3b422515c0a7@github.com>
Message-ID: <bPXSzL8v3HwRKq6i7MwckEnsMNUMOhSB_JOBTbApHTc=.07edf14b-a80e-4e64-9a61-bde003b6c5bb@github.com>

On Fri, 5 May 2023 16:42:43 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Recommended changes #2
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 138:
> 
>> 136:      * @param mainClass main class
>> 137:      *
>> 138:      * @throws NoSuchMethodException when not and preview and no method found
> 
> wording here? `when not and preview`?

oops - never on a Friday

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186337652

From forax at openjdk.org  Fri May  5 17:31:31 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 5 May 2023 17:31:31 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v9]
In-Reply-To: <Oof-ANXv-2H1R-R_8LpgrFtT4CAlJZdeMufGqbv8G4s=.06d1bcd0-5eea-4c84-839f-3b422515c0a7@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <rElTo20q1b4P1lhrIdl69ZO4ALKt9UW03bS7gVH9iyg=.9c8497f9-8687-497a-94e7-37f3b9563607@github.com>
 <Oof-ANXv-2H1R-R_8LpgrFtT4CAlJZdeMufGqbv8G4s=.06d1bcd0-5eea-4c84-839f-3b422515c0a7@github.com>
Message-ID: <HY5gi99B-bfxgJg2oHaeDql-zD9ow4B6imdLROFTc0E=.2a7f4556-dd92-45b9-91c5-1e18da78c788@github.com>

On Fri, 5 May 2023 17:08:35 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Recommended changes #2
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3999:
> 
>> 3997:         Name name = names.fromString(simplename);
>> 3998:         JCModifiers anonMods = F.at(primaryPos)
>> 3999:                 .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC|Flags.UNNAMED_CLASS, List.nil());
> 
> I wonder if testing if a class has flags: `Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC` should be enough to know if it is unnamed or not and we don't need to use the new `UNNAMED_CLASS` flag

`Flags.MANDATED` on a class is currently enough to know if it's a unnamed class or not, but it's not enough for classes not produced by javac.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186335538

From aefimov at openjdk.org  Fri May  5 17:32:17 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 5 May 2023 17:32:17 GMT
Subject: RFR: 8302845: Replace finalizer usage in JNDI DNS provider with
 Cleaner
Message-ID: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>

JNDI `DnsClient` has a finalize method to close its internal datagram channel selector.
 The change proposed here replaces it with a cleaner to close the selector once the `DnsClient`
  instance becomes phantom reachable. 

The change was tested with `jdk-tier1` to `jdk-tier3` test sets which showed no failures.

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

Commit messages:
 - 8302845: Replace finalizer usage in JNDI DNS provider with Cleaner

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

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

From vromero at openjdk.org  Fri May  5 17:38:25 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 May 2023 17:38:25 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v9]
In-Reply-To: <HY5gi99B-bfxgJg2oHaeDql-zD9ow4B6imdLROFTc0E=.2a7f4556-dd92-45b9-91c5-1e18da78c788@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <rElTo20q1b4P1lhrIdl69ZO4ALKt9UW03bS7gVH9iyg=.9c8497f9-8687-497a-94e7-37f3b9563607@github.com>
 <Oof-ANXv-2H1R-R_8LpgrFtT4CAlJZdeMufGqbv8G4s=.06d1bcd0-5eea-4c84-839f-3b422515c0a7@github.com>
 <HY5gi99B-bfxgJg2oHaeDql-zD9ow4B6imdLROFTc0E=.2a7f4556-dd92-45b9-91c5-1e18da78c788@github.com>
Message-ID: <H9cXhq6cNnxrjtOrj5j62pd3KCMMpOQOHFYz0EcsG1M=.2651a416-fdca-4c26-8b3f-d2468ab2f9f0@github.com>

On Fri, 5 May 2023 17:22:03 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3999:
>> 
>>> 3997:         Name name = names.fromString(simplename);
>>> 3998:         JCModifiers anonMods = F.at(primaryPos)
>>> 3999:                 .Modifiers(Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC|Flags.UNNAMED_CLASS, List.nil());
>> 
>> I wonder if testing if a class has flags: `Flags.FINAL|Flags.MANDATED|Flags.SYNTHETIC` should be enough to know if it is unnamed or not and we don't need to use the new `UNNAMED_CLASS` flag
>
> `Flags.MANDATED` on a class is currently enough to know if it's a unnamed class or not, but it's not enough for classes not produced by javac.

good point

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186346149

From forax at openjdk.org  Fri May  5 17:50:21 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 5 May 2023 17:50:21 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v9]
In-Reply-To: <H9cXhq6cNnxrjtOrj5j62pd3KCMMpOQOHFYz0EcsG1M=.2651a416-fdca-4c26-8b3f-d2468ab2f9f0@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <rElTo20q1b4P1lhrIdl69ZO4ALKt9UW03bS7gVH9iyg=.9c8497f9-8687-497a-94e7-37f3b9563607@github.com>
 <Oof-ANXv-2H1R-R_8LpgrFtT4CAlJZdeMufGqbv8G4s=.06d1bcd0-5eea-4c84-839f-3b422515c0a7@github.com>
 <HY5gi99B-bfxgJg2oHaeDql-zD9ow4B6imdLROFTc0E=.2a7f4556-dd92-45b9-91c5-1e18da78c788@github.com>
 <H9cXhq6cNnxrjtOrj5j62pd3KCMMpOQOHFYz0EcsG1M=.2651a416-fdca-4c26-8b3f-d2468ab2f9f0@github.com>
Message-ID: <fsPFJ4Zb1p0Kt8MyFX4mGrzvRHYErSVbLIwMduKDjxc=.15bc9531-efa7-4010-b79a-bdb9b85463cc@github.com>

On Fri, 5 May 2023 17:35:33 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> `Flags.MANDATED` on a class is currently enough to know if it's a unnamed class or not, but it's not enough for classes not produced by javac.
>
> good point

Just to be clear, here, Flags.UNNAMED_CLASS is needed because an an unnamed class must have a main(), which is tested later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186357338

From weijun at openjdk.org  Fri May  5 18:04:40 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 5 May 2023 18:04:40 GMT
Subject: RFR: 8305972: Update XML Security for Java to 3.0.2
Message-ID: <1zYN33Y3nwKPeCulbHHO_AHb1WFMJAigLq2lrqP0Rk4=.ad73d909-5f2b-4f12-9b99-1ff61de453f6@github.com>

Update XML Security for Java to 3.0.2. Some change to tests:

1. No more Xalan. One test case is singled out to demonstrate how to use a special configuration.
2. EdDSA does not support `KeyValue`. Use X.509 certificate instead.

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

Commit messages:
 - the change

Changes: https://git.openjdk.org/jdk/pull/13840/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13840&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305972
  Stats: 1145 lines in 41 files changed: 845 ins; 203 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/13840.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13840/head:pull/13840

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

From alanb at openjdk.org  Fri May  5 18:16:22 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 May 2023 18:16:22 GMT
Subject: RFR: 8302845: Replace finalizer usage in JNDI DNS provider with
 Cleaner
In-Reply-To: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
References: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
Message-ID: <Aj9ZiPtaW6FvECRxUwPmVOuE12ksIWpgp1OfD7DdzVE=.0edbb4f4-cb0c-477c-a861-d14ee42501fd@github.com>

On Fri, 5 May 2023 17:25:38 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> JNDI `DnsClient` has a finalize method to close its internal datagram channel selector.
>  The change proposed here replaces it with a cleaner to close the selector once the `DnsClient`
>   instance becomes phantom reachable. 
> 
> The change was tested with `jdk-tier1` to `jdk-tier3` test sets which showed no failures.

src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 163:

> 161:         }
> 162:         // register a cleaning action to close the channel
> 163:         // selector when this DNS client becomes phantom reachable

The change looks okay, it's just the comment here isn't quite right, it should say "to close the Selector when ...".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13837#discussion_r1186377852

From vromero at openjdk.org  Fri May  5 18:18:24 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 May 2023 18:18:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v10]
In-Reply-To: <eitzFKM5aVarsQ9hRKdVxxxuYA_GbTLnGgCpBtGvICs=.7f576b1b-4b2f-43e6-90d6-96deff997ff2@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <eitzFKM5aVarsQ9hRKdVxxxuYA_GbTLnGgCpBtGvICs=.7f576b1b-4b2f-43e6-90d6-96deff997ff2@github.com>
Message-ID: <WKWir8XgHl8-b2f-J3dx5UheFhGIjlIOUHbdhGMPqe4=.0a5c9c08-c1c8-4476-bbda-655cf8db42b0@github.com>

On Fri, 5 May 2023 17:31:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Typo

src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 466:

> 464:         } catch (ClassNotFoundException e) {
> 465:             throw new Fault(Errors.CantFindClass(mainClassName));
> 466:         } catch (NoSuchMethodException e) {

`getDeclaredConstructor` can also throw a NSME but this error message would still say that the main method couldn't be found unless at this point we are sure that the class must have a no-args constructor

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186379230

From jlaskey at openjdk.org  Fri May  5 18:32:30 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 18:32:30 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v10]
In-Reply-To: <WKWir8XgHl8-b2f-J3dx5UheFhGIjlIOUHbdhGMPqe4=.0a5c9c08-c1c8-4476-bbda-655cf8db42b0@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <eitzFKM5aVarsQ9hRKdVxxxuYA_GbTLnGgCpBtGvICs=.7f576b1b-4b2f-43e6-90d6-96deff997ff2@github.com>
 <WKWir8XgHl8-b2f-J3dx5UheFhGIjlIOUHbdhGMPqe4=.0a5c9c08-c1c8-4476-bbda-655cf8db42b0@github.com>
Message-ID: <pQvR3GdNCRDZGCEyqcn9Q_nW__MF3POeYU9b5h93UGs=.d8524d19-a3f0-4b1d-9351-fb28a37f4fe5@github.com>

On Fri, 5 May 2023 18:15:20 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/launcher/Main.java line 466:
> 
>> 464:         } catch (ClassNotFoundException e) {
>> 465:             throw new Fault(Errors.CantFindClass(mainClassName));
>> 466:         } catch (NoSuchMethodException e) {
> 
> `getDeclaredConstructor` can also throw a NSME but this error message would still say that the main method couldn't be found unless at this point we are sure that the class must have a no-args constructor

I was avoiding moving things so not to change behaviour when not in preview, but I think I really need to break it down into separate try blocks; get method, get constructor, execute method. Let me attempt.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1186390633

From dfuchs at openjdk.org  Fri May  5 18:38:28 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 5 May 2023 18:38:28 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v3]
In-Reply-To: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
Message-ID: <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>

> Several Handlers class use monitors to synchronize when formatting / publishing LogRecords.
> When logging within a VirtualThread, holding this monitor can cause the carrier thread to be pinned.
> Handlers could use jdk.internal.misc.InternalLock, in a similar way to some java.io classes (such as PrintStream) to avoid pinning the carrier thread.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Use locks consistently

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13832/files
  - new: https://git.openjdk.org/jdk/pull/13832/files/39646ce0..282c6e1b

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

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

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

From dfuchs at openjdk.org  Fri May  5 18:38:29 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 5 May 2023 18:38:29 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v2]
In-Reply-To: <cjZXKytFsV8FD2JoRdcFrBL520clsHSiEIIbdx2frgg=.f93c59ea-497c-49de-b747-5177ab87bffe@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <cjZXKytFsV8FD2JoRdcFrBL520clsHSiEIIbdx2frgg=.f93c59ea-497c-49de-b747-5177ab87bffe@github.com>
Message-ID: <dv1NQUxC450l_TBn-6ZfwOf4d7UOMpm0X_tPqDx1y_E=.453cc560-37f2-49b9-ab53-297017c8b41d@github.com>

On Fri, 5 May 2023 16:38:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Several Handlers class use monitors to synchronize when formatting / publishing LogRecords.
>> When logging within a VirtualThread, holding this monitor can cause the carrier thread to be pinned.
>> Handlers could use jdk.internal.misc.InternalLock, in a similar way to some java.io classes (such as PrintStream) to avoid pinning the carrier thread.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missed changes to SocketHandler.java

Hmm... You're right. Let's use locks consistently then.

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

PR Comment: https://git.openjdk.org/jdk/pull/13832#issuecomment-1536627949

From aefimov at openjdk.org  Fri May  5 19:08:27 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 5 May 2023 19:08:27 GMT
Subject: RFR: 8302845: Replace finalizer usage in JNDI DNS provider with
 Cleaner [v2]
In-Reply-To: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
References: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
Message-ID: <yuVhZpEYsNmlLkY3tskcXQAR5B0Efa1XRBqek8-7P7A=.d8eec4d1-e7a4-4b85-b89b-39db19cf1707@github.com>

> JNDI `DnsClient` has a finalize method to close its internal datagram channel selector.
>  The change proposed here replaces it with a cleaner to close the selector once the `DnsClient`
>   instance becomes phantom reachable. 
> 
> The change was tested with `jdk-tier1` to `jdk-tier3` test sets which showed no failures.

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  fix comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13837/files
  - new: https://git.openjdk.org/jdk/pull/13837/files/01840ad9..757d242c

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

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

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

From aefimov at openjdk.org  Fri May  5 19:08:29 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 5 May 2023 19:08:29 GMT
Subject: RFR: 8302845: Replace finalizer usage in JNDI DNS provider with
 Cleaner [v2]
In-Reply-To: <Aj9ZiPtaW6FvECRxUwPmVOuE12ksIWpgp1OfD7DdzVE=.0edbb4f4-cb0c-477c-a861-d14ee42501fd@github.com>
References: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
 <Aj9ZiPtaW6FvECRxUwPmVOuE12ksIWpgp1OfD7DdzVE=.0edbb4f4-cb0c-477c-a861-d14ee42501fd@github.com>
Message-ID: <zC5Hxjd884Gx-rghawUc0VDe67B99ZHVAHsqbVqoisc=.1abe08a0-da57-4046-8091-8b697c930929@github.com>

On Fri, 5 May 2023 18:13:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix comment
>
> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 163:
> 
>> 161:         }
>> 162:         // register a cleaning action to close the channel
>> 163:         // selector when this DNS client becomes phantom reachable
> 
> The change looks okay, it's just the comment here isn't quite right, it should say "to close the Selector when ...".

Thanks Alan. Fixed the comment in 757d242c66cdd5f12ce695a4c80ce5700eb66b4e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13837#discussion_r1186417356

From jlaskey at openjdk.org  Fri May  5 19:17:53 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 5 May 2023 19:17:53 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v11]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <PEDl2CubsBtg07DWA95iAhBtPMThJA3VIwcLoS__XvE=.9d33b7b4-39c1-44be-932e-c8569c0223d5@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Refactor source code launcher

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/0c8add65..b91e75aa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=09-10

  Stats: 76 lines in 2 files changed: 43 ins; 22 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

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

From alanb at openjdk.org  Fri May  5 19:30:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 May 2023 19:30:15 GMT
Subject: RFR: 8302845: Replace finalizer usage in JNDI DNS provider with
 Cleaner [v2]
In-Reply-To: <yuVhZpEYsNmlLkY3tskcXQAR5B0Efa1XRBqek8-7P7A=.d8eec4d1-e7a4-4b85-b89b-39db19cf1707@github.com>
References: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
 <yuVhZpEYsNmlLkY3tskcXQAR5B0Efa1XRBqek8-7P7A=.d8eec4d1-e7a4-4b85-b89b-39db19cf1707@github.com>
Message-ID: <7K3HEjL-ZvehmVs2xSb1IYH7-zAeJvLfIV-4lxPOfRU=.51de3cbe-b2d0-4859-b8f1-251833d1b598@github.com>

On Fri, 5 May 2023 19:08:27 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> JNDI `DnsClient` has a finalize method to close its internal datagram channel selector.
>>  The change proposed here replaces it with a cleaner to close the selector once the `DnsClient`
>>   instance becomes phantom reachable. 
>> 
>> The change was tested with `jdk-tier1` to `jdk-tier3` test sets which showed no failures.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comment

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13837#pullrequestreview-1415346229

From vromero at openjdk.org  Fri May  5 20:16:26 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 5 May 2023 20:16:26 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v11]
In-Reply-To: <PEDl2CubsBtg07DWA95iAhBtPMThJA3VIwcLoS__XvE=.9d33b7b4-39c1-44be-932e-c8569c0223d5@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <PEDl2CubsBtg07DWA95iAhBtPMThJA3VIwcLoS__XvE=.9d33b7b4-39c1-44be-932e-c8569c0223d5@github.com>
Message-ID: <V6L8UNgbBplOvV8Tbw9bR_Msn-bGHMOnjuHjqvQSwDw=.893c3270-4664-4e59-8b8e-a40fae1b1e39@github.com>

On Fri, 5 May 2023 19:17:53 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactor source code launcher

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13689#pullrequestreview-1415400703

From erikj at openjdk.org  Fri May  5 20:46:22 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 5 May 2023 20:46:22 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v7]
In-Reply-To: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com>
Message-ID: <rIFR8lzb8zKI5f0h_VcaherfoEEtQqeX2C0UyApAqeE=.bb53bbe4-4bf6-4c22-9bff-a2b357397cce@github.com>

On Fri, 5 May 2023 16:52:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries
>> 
>> - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>>  
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace error in make/StaticJvmLibsImage.gmk.

With this solution, the build will produce a different static-libs bundle and image depending on the make target called, but the output name is exactly the same. That isn't ok. If you run one target after the other, the behavior becomes strange and unpredictable. If these are different deliverables, they need to be that all the way through, with a separate image and bundle with their own make targets.

If we go with two separate deliverables, then to me it makes more sense that "static-libs-image" is the complete image with all the static libs and if graal needs a specialized subset of this, then that's something graal specific. The graal-builder-image is already meant just for their consumption (which is a combination of the jdk-image and the current static-libs-image). Having graal builds having to change the target they call is inconvenient for them, but for us to be forced to maintain unintuitive build targets is also bad.

All of that said, I think we can get away with a smaller subset of targets and deliverables. AFAIK, graal needs the combined `graal-builder-image` as input to their build anyway, so they should not have any dependency on what the target `static-libs-image` produces. Given that I propose the following behavior:

`make static-libs-image` produces `images/static-libs` with all .a (including libjvm.a).
`make static-libs-graal-image` produces `images/static-libs-graal` with all .a except libjvm.a.
`make graal-builder-image` produces `images/graal-builder-image` like today, but depends on and uses `static-libs-graal-image` instead of `static-libs-image`.
`make static-libs-bundles` depends on and uses `static-libs-image` like today, so will contain libjvm.a, which is new behavior.

Further I would like to suggest that libjvm.a gets put in the variant subdir under lib, just like libjvm.so does today (e.g. lib/server/libjvm.a). That way you can support building libjvm.a for all variants without worry. It will also get libjvm.a out of the way to cause less trouble for a graal build that uses the static-libs-bundles as input. This goes against what I suggested before, to just use JVM_VARIANT_MAIN, but I think this makes for a cleaner long term solution given the goals of the hermetic java effort.

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

PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1415436469

From roger.riggs at oracle.com  Fri May  5 21:38:39 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 5 May 2023 17:38:39 -0400
Subject: Time difference calculation bug
In-Reply-To: <71bd9a7f-6f85-fa6e-e11d-904d548e43d3@oracle.com>
References: <LO2P265MB337698E3B54595B9627229B28A6C9@LO2P265MB3376.GBRP265.PROD.OUTLOOK.COM>
 <b0002f2b-17db-64f9-44da-d7a956c72ed2@oracle.com>
 <LO2P265MB33760D6EEC2CF1677F327C348A6C9@LO2P265MB3376.GBRP265.PROD.OUTLOOK.COM>
 <71bd9a7f-6f85-fa6e-e11d-904d548e43d3@oracle.com>
Message-ID: <66989ec7-e728-90c8-9d05-471ba02b4686@oracle.com>

Hi,

The PR with the fix is out for review: 
https://github.com/openjdk/jdk/pull/13846

Thanks for the issue report and followup.

A possible workaround is to convert to millis and subtract, for example,

 ??? long diff = t2.toEpochMillis() - t1.toEpochMillis();

Thank you, Roger


On 5/4/23 12:10 PM, Roger Riggs wrote:
> Hi,
>
> I created a Jira issue:
> 8307466 <https://bugs.openjdk.org/browse/JDK-8307466> 
> java.time.Instant Time difference calculation bug
>
> The root cause of the bug is in the code that manages the 
> representation of Instant as seconds and nanoseconds.
> The borrow/carry logic between the seconds and nanoseconds is suspect 
> in Instant.until(Instant end, ChronoUnit unit).
>
> Thanks for the bug report, Roger
>
>
> On 5/3/23 4:47 PM, SHARPE, Stuart (Commercial & Institutional CDIO) wrote:
>> Hi Roger,
>>
>> Thanks for the reply.
>>
>> I must admit I am struggling to understand your explanation. I can't see how the choice of internal representation would affect the result in this way. I also don't see anything in the JavaDoc that describes values being truncated prior to the calculation, and even if it did, the results are not consistent - if that was the expected behaviour, the results from my previous example would have been 1000 and 1001, would they not?
>>
>> The part I quoted from the JavaDoc seems quite clear: it should return the number of whole units (millis in this case) between the two temporals. The number of milliseconds between 10:00:00.000999 and 10:00:01.000 is 999.001, which is 999 whole units.
>>
>> I think the below illustration makes it clearer that there is something wrong. The output values are all what I would expect as per the JavaDoc apart from the result for t2 = 10:00:01.000.
>>
>>      var t1 = Instant.parse("2023-05-03T10:00:00.000999Z");
>>      var t2 = Instant.parse("2023-05-03T10:00:00.995Z");
>>      
>>      for(int i=0; i<10; i++) {
>>        System.out.println(ChronoUnit.MILLIS.between(t1, t2));
>>        t2 = t2.plusMillis(1);
>>      }
>>
>> This prints:
>>
>> 994
>> 995
>> 996
>> 997
>> 998
>> 1000
>> 1000
>> 1001
>> 1002
>> 1003
>>
>> I'm fully prepared to accept that I've missed something, but at the moment I can't understand what that is.
>>
>> Regards,
>>
>> Stuart
>>
>>
>> From: core-libs-dev<core-libs-dev-retn at openjdk.org>  On Behalf Of Roger Riggs
>> Sent: 03 May 2023 20:58
>> To:core-libs-dev at openjdk.org
>> Subject: Re: Time difference calculation bug
>>
>>
>> Hi,
>>
>> The seconds and nano-seconds are computed separately.
>> The representation of Instant holds seconds and nanoseconds separately.
>>
>> The computation is performed on the nano-seconds of the Instant and truncated to milliseconds.
>> The value of 0.000999 becomes 0 when truncated to MILLIS.
>>
>> Regards, Roger
>> On 5/3/23 12:54 PM, SHARPE, Stuart (Commercial & Institutional CDIO) wrote:
>> Hello,
>>   
>> I believe I have discovered a bug in java.time. I've searched Jira and couldn't find any existing similar issue.
>>   
>> Consider the following code:
>>   
>>  ??? var t1 = Instant.parse("2023-05-03T10:00:00.000999Z");
>>  ??? var t2 = Instant.parse("2023-05-03T10:00:01.000Z");
>>  ??? var t3 = Instant.parse("2023-05-03T10:00:01.001Z");
>>      
>>  ????System.out.println(MILLIS.between(t1, t2));
>>  ??? System.out.println(MILLIS.between(t1, t3));
>>   
>> This prints:
>>   
>>  ??? 1000
>>  ??? 1000
>>   
>> Given that t3 is exactly one millisecond later than t2, it does not seem reasonable that they can both be 1000 milliseconds later than t1.
>>   
>> The JavaDoc for between() states "The calculation returns a whole number, representing the number of complete units between the two temporals."
>>   
>> Assuming I have understood this correctly, I think MILLIS.between(t1, t3) is correct but MILLIS.between(t1, t2) should return 999.
>>   
>> Regards
>>   
>> Stuart Sharpe
>>   
>>
>>
>> This communication and any attachments are confidential and intended solely for the addressee. If you are not the intended recipient please advise us immediately and delete it. Unless specifically stated in the message or otherwise indicated, you may not duplicate, redistribute or forward this message and any attachments are not intended for distribution to, or use by any person or entity in any jurisdiction or country where such distribution or use would be contrary to local law or regulation. NatWest Markets Plc, NatWest Markets N.V., NatWest Markets Securities Japan Limited and/or NatWest Markets Securities Inc. (collectively "NatWest Markets") accepts no responsibility for any changes made to this message after it was sent.
>>
>> This communication, where prepared by the sales and trading desk or desk strategists, may be marketing material, desk strategy and/or trader commentary. It is not a product of the research department. This material may constitute an invitation to consider entering into a derivatives transaction under U.S. CFTC Regulations sections 1.71 and 23.605, where applicable, but is not a binding offer to buy/sell any financial instrument. The views of the author may differ from others at NatWest Markets.
>>
>> Unless otherwise specifically indicated, the contents of this communication and its attachments are for information purposes only and should not be regarded as an offer or solicitation to buy or sell a product or service, confirmation of any transaction, a valuation, indicative price or an official statement. Trading desks may have a position or interest that is inconsistent with any views expressed in this message. In evaluating the information contained in this message, you should know that it could have been previously provided to other clients and/or internal NatWest Markets personnel, who could have already acted on it.
>>
>> NatWest Markets cannot provide absolute assurances that all electronic communications (sent or received) are secure, error free, not corrupted, incomplete or virus free and/or that they will not be lost, mis-delivered, destroyed, delayed or intercepted/decrypted by others. Therefore NatWest Markets disclaims all liability with regards to electronic communications (and the contents therein) if they are corrupted, lost destroyed, delayed, incomplete, mis-delivered, intercepted, decrypted or otherwise misappropriated by others.
>>
>> Any electronic communication that is conducted within or through NatWest Markets systems will be subject to being archived, monitored and produced to regulators and in litigation in accordance with NatWest Markets? policy and local laws, rules and regulations. Unless expressly prohibited by local law, electronic communications may be archived in countries other than the country in which you are located, and may be treated in accordance with the laws and regulations of the country of each individual included in the entire chain.
>>
>> Copyright ? NatWest Markets Plc. All rights reserved. Seehttps://urldefense.com/v3/__https://www.nwm.com/disclaimer__;!!ACWV5N9M2RV99hQ!MLQn8Js2bYD_SSNi8IZD4ZmvsmT1g50e8lC1K3OnEP8KmswmXw2V7Yu8eXSxUP0yqpLlY0owu7LR6X2oZxrYueaalvFmtjI$   for further risk disclosure (the agency arrangements referred to in the further risk disclosure between NatWest Markets Plc and NatWest Markets N.V. are not applicable to branches of NatWest Markets N.V.).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230505/94d4d9c2/attachment.htm>

From lancea at openjdk.org  Fri May  5 22:03:21 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 5 May 2023 22:03:21 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v6]
In-Reply-To: <fhDJZ45cjHcgp2v9yZe4MFzBGmZxZV-wg4iyQad39fU=.e0a8da91-86cf-4bef-b608-28f9b41cdc5c@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <fhDJZ45cjHcgp2v9yZe4MFzBGmZxZV-wg4iyQad39fU=.e0a8da91-86cf-4bef-b608-28f9b41cdc5c@github.com>
Message-ID: <7XeeodEv7RbZQqqbenSrqFrNpOrPY9Svh1xm9smxlCg=.fd871670-0d4d-42a5-add2-e4c73d931290@github.com>

On Wed, 3 May 2023 14:12:33 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Test is updated to create the binary files during test execution.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move the pseudo code generation part from setup() to seperate methods.

Sorry for the delay but lots of tasks are getting time sliced in this week :-) 

I think you are getting closer.  There is still some cleanup that can be done and more comments added for future maintainers.  

As we look at creating or updating tests, we want to try to improve their readability and documentation.

Please see below for some examples of where we can look to improve the test

test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 67:

> 65:      * @throws IOException
> 66:      * @throws ClassNotFoundException
> 67:      */

Please either use block comments or add the in the correct javadoc

test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 73:

> 71:         XMLGregorianCalendar xmlGregorianCalendar = dtf.newXMLGregorianCalendar(EXPECTED_CAL);
> 72:         //Serialize the given xmlGregorianCalendar
> 73:         final ByteArrayOutputStream baos = new ByteArrayOutputStream();

You could probably use try-with-resources for the streams that are created.  I am not convinced we need to use `final`

test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 117:

> 115: 
> 116:     /**
> 117:      *Provide data for JDK version and Gregorian Calendar serialized bytes

I would suggest adding a comment for the parameters that are being created by the DataProvider

test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 129:

> 127: 
> 128:     /**
> 129:      *Provide data for JDK version and serialized Gregorian Calendar Base64 encoded string

Nit space should be before comment starts

test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 167:

> 165:      * @throws IOException
> 166:      * @throws ClassNotFoundException
> 167:      */

See above regarding using a block comment or using the proper javadoc comment format.   Either way, please define what the param values are used for

test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 232:

> 230:      * JDK<version>GregorianCalendarAndDurationSerData.java files.
> 231:      * @param baos
> 232:      */

I think there needs to be a general comment describing how these methods are used to create the JDK<version>GregorianCalendarAndDurationSerData.java files.  There should also be a description/comment for the methods defined in GregorianCalendarAndDurationSerData.java

We need to try and put ourselves in the place of a future maintainer who needs to understand how to  create a version of one of these files.

You could probably also create a method which generates a JDK<version>GregorianCalendarAndDurationSerData.java file to save the developer from multiple cut an pastes.

At a minimum, there really should be a step by step guide

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

PR Review: https://git.openjdk.org/jdk/pull/13537#pullrequestreview-1415412426
PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1186516525
PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1186471437
PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1186517342
PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1186473297
PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1186518064
PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1186522549

From maurizio.cimadamore at oracle.com  Sat May  6 00:41:46 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Sat, 6 May 2023 01:41:46 +0100
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
 <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
Message-ID: <5c4261b1-09af-675e-ed23-34c7cb69379b@oracle.com>

Another way to help inference, in cases like this would be to break up 
the method chain - as follows:

final Stream<Collection<String>> stream = Stream.of(nestedDequeue, 
nestedList);
final List<Collection<String>> list = stream.toList();

In the above rewriting, now the target type Stream<Collection<String>> 
"drives" inference for Stream::of - meaning that inference will pick the 
"correct" supertype.

The problem with the original example is that the target type applies to 
the Stream::toList() call, and the call to Stream::of is type-checked in 
a bottom-up fashion, w/o any influence from the target-type.

This is, unfortunately, a known limitation of the inference scheme 
specified in the JLS and implemented by javac.

So, in a way, both the `var` example and this one are similar in spirit, 
as they both try to compute the least upper bound between two 
collections, in a situation where no target type is available: in one 
case, trivially, because the target is `var`; in the other case because 
the target doesn't "flow" to the method call that would require it the most.

Maurizio

On 04/05/2023 14:23, Raffaello Giulietti wrote:
> Without changing the semantics at all, you could also write
>
> ????final List<Collection<String>> list = 
> Stream.<Collection<String>>of(nestedDequeue, nestedList).toList();
>
> to "help" type inference.
>
>
>
>
> On 2023-05-03 15:12, forax at univ-mlv.fr wrote:
>> Another example sent to me by a fellow French guy,
>>
>> ???? final Deque<String> nestedDequeue = new ArrayDeque<>();
>> ???? nestedDequeue.addFirst("C");
>> ???? nestedDequeue.addFirst("B");
>> ???? nestedDequeue.addFirst("A");
>>
>> ???? final List<String> nestedList = new ArrayList<>();
>> ???? nestedList.add("D");
>> ???? nestedList.add("E");
>> ???? nestedList.add("F");
>>
>> ???? final List<Collection<String>> list = Stream.of(nestedDequeue, 
>> nestedList).toList();
>>
>> This one is cool because no 'var' is involved and using 
>> collect(Collectors.toList()) instead of toList() solves the inference 
>> problem.
>>
>> R?mi
>>
>> ----- Original Message -----
>>> From: "Stuart Marks" <stuart.marks at oracle.com>
>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>> Sent: Tuesday, May 2, 2023 2:44:28 AM
>>> Subject: Re: The introduction of Sequenced collections is not a 
>>> source compatible change
>>
>>> Hi R?mi,
>>>
>>> Thanks for trying out the latest build!
>>>
>>> I'll make sure this gets mentioned in the release note for Sequenced
>>> Collections.
>>> We'll also raise this issue when we talk about this feature in the 
>>> Quality
>>> Outreach
>>> program.
>>>
>>> s'marks
>>>
>>> On 4/29/23 3:46 AM, Remi Forax wrote:
>>>> I've several repositories that now fails to compile with the latest 
>>>> jdk21, which
>>>> introduces sequence collections.
>>>>
>>>> The introduction of a common supertype to existing collections is 
>>>> *not* a source
>>>> compatible change because of type inference.
>>>>
>>>> Here is a simplified example:
>>>>
>>>> ??? public static void m(List<Supplier<? extends Map<String, 
>>>> String>>> factories) {
>>>> ??? }
>>>>
>>>> ??? public static void main(String[] args) {
>>>> ????? Supplier<LinkedHashMap<String,String>> supplier1 = 
>>>> LinkedHashMap::new;
>>>> ????? Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>>>> ????? var factories = List.of(supplier1, supplier2);
>>>> ????? m(factories);
>>>> ??? }
>>>>
>>>>
>>>> This example compiles fine with Java 20 but report an error with 
>>>> Java 21:
>>>> ??? SequencedCollectionBug.java:28: error: method m in class 
>>>> SequencedCollectionBug
>>>> ??? cannot be applied to given types;
>>>> ????? m(factories);
>>>> ????? ^
>>>> ??? required: List<Supplier<? extends Map<String,String>>>
>>>> ??? found:??? List<Supplier<? extends SequencedMap<String,String>>>
>>>> ??? reason: argument mismatch; List<Supplier<? extends 
>>>> SequencedMap<String,String>>>
>>>> ??? cannot be converted to List<Supplier<? extends 
>>>> Map<String,String>>>
>>>>
>>>>
>>>>
>>>> Apart from the example above, most of the failures I see are in the 
>>>> unit tests
>>>> provided to the students, because we are using a lot of 'var' in 
>>>> them so they
>>>> work whatever the name of the types chosen by the students.
>>>>
>>>> Discussing with a colleague, we also believe that this bug is not 
>>>> limited to
>>>> Java, existing Kotlin codes will also fail to compile due to this bug.
>>>>
>>>> Regards,
>>>> R?mi

From duke at openjdk.org  Sat May  6 00:46:29 2023
From: duke at openjdk.org (duke)
Date: Sat, 6 May 2023 00:46:29 GMT
Subject: Withdrawn: 8303891: Zip64SizeTest could use a sparse file
In-Reply-To: <Rti2XEASmPioIeLeNxJncUQwR4tuCzhUBo2DVwvvgZ8=.1daaa86d-98c6-46bf-a9d1-8099a0079f8e@github.com>
References: <Rti2XEASmPioIeLeNxJncUQwR4tuCzhUBo2DVwvvgZ8=.1daaa86d-98c6-46bf-a9d1-8099a0079f8e@github.com>
Message-ID: <tQcAymjrxngYUTl_AAHmD2LoNYG3fJVh5lZHmqrJ76k=.e1c26db7-cf4a-4bb6-8d70-1de15793d737@github.com>

On Thu, 9 Mar 2023 12:06:52 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR suggests we use a sparse file when the Zip64SizeTest writes a ZIP file with a 5GB entry.
> 
> The size requirement of this test is known to cause problems in some builds, see [JDK-8259866](https://bugs.openjdk.org/browse/JDK-8259866)
> 
> Using a sparse file reduces the disk space requirements of running the test from 5GB to 12K and also reduces the runtime from ~35 seconds to ~3 seconds on my Macbook Pro.

This pull request has been closed without being integrated.

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

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

From rriggs at openjdk.org  Sat May  6 01:23:28 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 6 May 2023 01:23:28 GMT
Subject: RFR: 8307466: java.time.Instant calculation bug in until and between
 methods
Message-ID: <TbOVsPh3u2tsHDgnDl6bg7DM7zDW7A0KTcM3PpMODfQ=.c27d4486-6c5d-4828-9d31-83ce21a7d26b@github.com>

The implementation of java.time.Instant.until(I2, ChronoUnit) in some cases did not correctly borrow or carry from the nanos to the seconds when computing using ChronoUnit.MILLIS or ChronoUnit.MICROS.
The errant computation was introduced by [JDK-8273369](https://bugs.openjdk.org/browse/JDK-8273369).

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

Commit messages:
 - 8307466: java.time.Instant calculation bug in until and between methods

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

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

From duke at openjdk.org  Sat May  6 02:08:09 2023
From: duke at openjdk.org (Chang Peng)
Date: Sat, 6 May 2023 02:08:09 GMT
Subject: RFR: 8307523: [vectorapi] Optimize MaskFromLongBenchmark.java
Message-ID: <32EIbtPLqejQLdpxMJTXaXuQ35FqT3zcw7pCcLaMXqM=.280bd95e-42ba-424c-8a53-730e08eb6c32@github.com>

To avoid dead code elimination, a use-point laneIsSet() is added in each benchmark method in MaskFromLongBenchmark.java.

However, currently laneIsSet() [1] is implemented by toLong(). So it may generate a fromLong-toLong pair [2], making this benchmark to be noneffective after inlining laneIsSet() into the outer method. The assembly of maskFromLong_byte128 benchmark on SVE2 is shown in [3]. We cannot see the bdep instruction used by fromLong on AArch64 [4]. So, in this case, we cannot measure fromLong()'s performance by using this benchmark.

This patch uses trueCount() [5] instead of toLong() to measure the fromLong()'s performance effectively. After this patch, we can see the bdep instruction in the hot loop [6] of maskFromLong_byte128 benchmark.

[1]: https://github.com/openjdk/jdk/blob/96fa2751e8bbc05d6d064d80c07720cc9db05c54/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java#L70
[2]: https://github.com/openjdk/jdk/blob/ff368d504e9101e11c7182185f56255f429d31e3/src/hotspot/share/opto/vectornode.cpp#L1736
[3]: https://gist.github.com/changpeng1997/467f6056f78d99c055030fa5888b6baa
[4]: https://github.com/openjdk/jdk/blob/787832a58677205c9a11ae100dd8a2fbddb30a4a/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp#L1099
[5]: https://docs.oracle.com/en/java/javase/16/docs/api/jdk.incubator.vector/jdk/incubator/vector/VectorMask.html#trueCount()
[6]: https://gist.github.com/changpeng1997/79bea0a9f80530bec89978950897000d

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

Commit messages:
 - 8307523: [vectorapi] Optimize MaskFromLongBenchmark.java

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

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

From qamai at openjdk.org  Sat May  6 02:25:13 2023
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 6 May 2023 02:25:13 GMT
Subject: RFR: 8307523: [vectorapi] Optimize MaskFromLongBenchmark.java
In-Reply-To: <32EIbtPLqejQLdpxMJTXaXuQ35FqT3zcw7pCcLaMXqM=.280bd95e-42ba-424c-8a53-730e08eb6c32@github.com>
References: <32EIbtPLqejQLdpxMJTXaXuQ35FqT3zcw7pCcLaMXqM=.280bd95e-42ba-424c-8a53-730e08eb6c32@github.com>
Message-ID: <Ax0ANAhPe3IT2RZl5DdtE4fmBq9sHtDc04xdE3Za0DU=.701e687d-76cb-4c96-ac54-ac1d0c4dc78f@github.com>

On Sat, 6 May 2023 02:01:20 GMT, Chang Peng <duke at openjdk.org> wrote:

> To avoid dead code elimination, a use-point laneIsSet() is added in each benchmark method in MaskFromLongBenchmark.java.
> 
> However, currently laneIsSet() [1] is implemented by toLong(). So it may generate a fromLong-toLong pair [2], making this benchmark to be noneffective after inlining laneIsSet() into the outer method. The assembly of maskFromLong_byte128 benchmark on SVE2 is shown in [3]. We cannot see the bdep instruction used by fromLong on AArch64 [4]. So, in this case, we cannot measure fromLong()'s performance by using this benchmark.
> 
> This patch uses trueCount() [5] instead of toLong() to measure the fromLong()'s performance effectively. After this patch, we can see the bdep instruction in the hot loop [6] of maskFromLong_byte128 benchmark.
> 
> [1]: https://github.com/openjdk/jdk/blob/96fa2751e8bbc05d6d064d80c07720cc9db05c54/src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractMask.java#L70
> [2]: https://github.com/openjdk/jdk/blob/ff368d504e9101e11c7182185f56255f429d31e3/src/hotspot/share/opto/vectornode.cpp#L1736
> [3]: https://gist.github.com/changpeng1997/467f6056f78d99c055030fa5888b6baa
> [4]: https://github.com/openjdk/jdk/blob/787832a58677205c9a11ae100dd8a2fbddb30a4a/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp#L1099
> [5]: https://docs.oracle.com/en/java/javase/16/docs/api/jdk.incubator.vector/jdk/incubator/vector/VectorMask.html#trueCount()
> [6]: https://gist.github.com/changpeng1997/79bea0a9f80530bec89978950897000d

Storing into a boolean array should be safer as `trueCount` can be implemented as `bitCount(toLong())`. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13851#issuecomment-1536988490

From darcy at openjdk.org  Sat May  6 02:44:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 6 May 2023 02:44:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v65]
In-Reply-To: <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
Message-ID: <nAe_DBQxds8A45LkLzTNlflVBLc09_E1Dnhtj4cUjZ4=.2d01b306-25a5-4217-91dc-b64c439f1bef@github.com>

On Thu, 27 Apr 2023 17:21:23 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR recommendations

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 123:

> 121:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 122:     public static final int MAX_INDY_CONCAT_ARG_SLOTS;
> 123:     static { MAX_INDY_CONCAT_ARG_SLOTS = 200; }

I think this deserve a comment such as "use static initialize block to avoid MAX_INDY_CONCAT_ARG_SLOTS being treating as a constant for constant folding," assuming that is the intention here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1186599844

From darcy at openjdk.org  Sat May  6 02:57:20 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 6 May 2023 02:57:20 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v65]
In-Reply-To: <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
Message-ID: <0lyLXXpOtSz0C8DvkpexUAyj3IPrqUkP4WuLHrw_30c=.512031ec-bacb-4918-a4be-6054a684fddb@github.com>

On Thu, 27 Apr 2023 17:21:23 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR recommendations

src/java.base/share/classes/java/lang/StringTemplate.java line 427:

> 425:      * {@link StringTemplate}. To accommodate concatenation, values are converted to strings
> 426:      * as if invoking {@link String#valueOf(Object)}.
> 427:      * @implNote {@link StringTemplate#STR} is statically imported implicitly into every

IMO the remark regarding  STR being auto-imported works better as an apiNote rather than an implNote.

Regarding interning, I think an implSpec of "may or may not be interned" provides maximum flexibility to the implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1186601013

From duke at openjdk.org  Sat May  6 03:32:15 2023
From: duke at openjdk.org (ExE Boss)
Date: Sat, 6 May 2023 03:32:15 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of [v2]
In-Reply-To: <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
 <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
Message-ID: <2-TjdtQLn78HOT5PtRmftnRIHcYsnlqNsExEgpAQDKo=.4fad7a15-2845-4e95-a5d3-dd08b089fe29@github.com>

On Sun, 23 Apr 2023 23:44:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch adding two new convenience methods that allows easier access to MethodTypeDesc instances and its associated CSR as well. This is a necessity to allow #13186 to reduce array copies in a few scenarios; the implementation of the two methods will be updated there.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306698/1/java.base/java/lang/constant/MethodTypeDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update method type and specification, update tests

Marked as reviewed by ExE-Boss at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/13599#pullrequestreview-1415644657

From scolebourne at openjdk.org  Sat May  6 06:58:13 2023
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Sat, 6 May 2023 06:58:13 GMT
Subject: RFR: 8307466: java.time.Instant calculation bug in until and
 between methods
In-Reply-To: <TbOVsPh3u2tsHDgnDl6bg7DM7zDW7A0KTcM3PpMODfQ=.c27d4486-6c5d-4828-9d31-83ce21a7d26b@github.com>
References: <TbOVsPh3u2tsHDgnDl6bg7DM7zDW7A0KTcM3PpMODfQ=.c27d4486-6c5d-4828-9d31-83ce21a7d26b@github.com>
Message-ID: <WvMbNSXjTxsK1RpufGWpZsWjXW4GiB4y7zFRYsv8-MA=.38795546-de05-4fbd-a34d-de77adde9deb@github.com>

On Fri, 5 May 2023 21:28:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The implementation of java.time.Instant.until(I2, ChronoUnit) in some cases did not correctly borrow or carry from the nanos to the seconds when computing using ChronoUnit.MILLIS or ChronoUnit.MICROS.
> The errant computation was introduced by [JDK-8273369](https://bugs.openjdk.org/browse/JDK-8273369).

Marked as reviewed by scolebourne (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/13846#pullrequestreview-1415731468

From dfuchs at openjdk.org  Sat May  6 09:53:18 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Sat, 6 May 2023 09:53:18 GMT
Subject: RFR: 8302845: Replace finalizer usage in JNDI DNS provider with
 Cleaner [v2]
In-Reply-To: <yuVhZpEYsNmlLkY3tskcXQAR5B0Efa1XRBqek8-7P7A=.d8eec4d1-e7a4-4b85-b89b-39db19cf1707@github.com>
References: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
 <yuVhZpEYsNmlLkY3tskcXQAR5B0Efa1XRBqek8-7P7A=.d8eec4d1-e7a4-4b85-b89b-39db19cf1707@github.com>
Message-ID: <bIBaynnQ4JHCS9nyuCB4lwXJeSXEWUm9Yi__wNCEIOM=.bcfbef5f-2297-4fb5-aab9-b39ce9d00521@github.com>

On Fri, 5 May 2023 19:08:27 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> JNDI `DnsClient` has a finalize method to close its internal datagram channel selector.
>>  The change proposed here replaces it with a cleaner to close the selector once the `DnsClient`
>>   instance becomes phantom reachable. 
>> 
>> The change was tested with `jdk-tier1` to `jdk-tier3` test sets which showed no failures.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comment

Changes requested by dfuchs (Reviewer).

src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 165:

> 163:         // when this DNS client becomes phantom reachable
> 164:         Selector sel = udpChannelSelector;
> 165:         CleanerFactory.cleaner().register(this, () -> {

I believe this is not quite right. The Cleanable returned by the `register` method should be saved in a final field. And close() below should call `Cleanable::clean` instead of `udpChannelSelector.close()`

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

PR Review: https://git.openjdk.org/jdk/pull/13837#pullrequestreview-1415750869
PR Review Comment: https://git.openjdk.org/jdk/pull/13837#discussion_r1186672907

From alanb at openjdk.org  Sat May  6 12:50:14 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 6 May 2023 12:50:14 GMT
Subject: RFR: 8302845: Replace finalizer usage in JNDI DNS provider with
 Cleaner [v2]
In-Reply-To: <bIBaynnQ4JHCS9nyuCB4lwXJeSXEWUm9Yi__wNCEIOM=.bcfbef5f-2297-4fb5-aab9-b39ce9d00521@github.com>
References: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
 <yuVhZpEYsNmlLkY3tskcXQAR5B0Efa1XRBqek8-7P7A=.d8eec4d1-e7a4-4b85-b89b-39db19cf1707@github.com>
 <bIBaynnQ4JHCS9nyuCB4lwXJeSXEWUm9Yi__wNCEIOM=.bcfbef5f-2297-4fb5-aab9-b39ce9d00521@github.com>
Message-ID: <Zb9RlVfqcV-weLLdpjbnHrtay1j_8zbGNg0_zyczdOc=.6cdafb69-fa5e-4eff-8ca2-c06486278af9@github.com>

On Sat, 6 May 2023 09:50:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I believe this is not quite right. The Cleanable returned by the `register` method should be saved in a final field. And close() below should call `Cleanable::clean` instead of `udpChannelSelector.close()`

Selector::close is idempotent so it doesn't really matter but your approach would mean the cleanable is deregistered when the API is used correctly, which is good thing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13837#discussion_r1186692874

From alanb at openjdk.org  Sat May  6 13:43:19 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 6 May 2023 13:43:19 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v3]
In-Reply-To: <O6F5e_dRzOz4AX-Cigy4Hxq0lfFDcydWspCv-F4ZLsM=.ac479437-5dac-472c-9184-97d29292c3eb@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
 <O6F5e_dRzOz4AX-Cigy4Hxq0lfFDcydWspCv-F4ZLsM=.ac479437-5dac-472c-9184-97d29292c3eb@github.com>
Message-ID: <HpqLy4R5mJ0B4fAYz1ZgKxR13daL1MoiRQDMu-DAJNw=.394eb43c-8ddf-4ef4-94db-ef865dc4e076@github.com>

On Fri, 5 May 2023 13:59:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
>> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
>> 
>> Neither os.name nor os.arch should be assumed to be changeable; 
>> one test case is removed because it assumes os.name can be changed on the command line.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Source code cleanup suggested by reviewers

Aside from one confusing comment, this change looks okay.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 53:

> 51: 
> 52:         archName = platformString.substring(index + 1);
> 53:         // Unalias Jmod architecture "amd64" to "x86_64"

"Jmod architecture" is confusing here, it's the architecture component of the ModuleTarget attribute.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13585#pullrequestreview-1415778171
PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1186699156

From liach at openjdk.org  Sat May  6 17:03:13 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 6 May 2023 17:03:13 GMT
Subject: RFR: 8307575: Migrate the serialization constructor accessors to
 Method Handles
Message-ID: <avFjVaHBj3-NeBLAP04SmKoBrfwEMsUz60qCfGeuSMk=.d89f252a-10f3-4c2d-8cb4-5dbeeee051d1@github.com>

Apparently method handle linking doesn't impose extra checks on constructor invocation, so the special logic for the serialization constructor to call superclass constructor in MagicAccessorImpl can be removed altogether with old core reflection implementation.

Serialization and sun.reflect.ReflectionFactory tests pass. May be worth to think about the long-term treatment of ReflectionFactory.newConstructorForSerialization, as creating partial object is inherently unsafe, and behavior of `newConstructorForSerialization(ArrayList.class, String.class.getDeclaredConstructor(String.class))` etc. (which is accepted for now) may have unpredictable side effects.

#1830 has a similar patch; this one doesn't touch proxies and updates to the new post-JEP 416 reflection implementation.

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

Commit messages:
 - 8307575: Migrate the serialization constructor accessors to Method Handles

Changes: https://git.openjdk.org/jdk/pull/13853/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13853&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307575
  Stats: 126 lines in 8 files changed: 53 ins; 40 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/13853.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13853/head:pull/13853

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

From liach at openjdk.org  Sat May  6 18:23:27 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 6 May 2023 18:23:27 GMT
Subject: RFR: 8299505: findVirtual on array classes incorrectly restricts the
 receiver type
Message-ID: <Mzve--7vLKag1ieybf8aCSQp3uBJ_g9aSmyrevTNhtA=.591264e8-1219-4c1b-86fd-acc75edfd553@github.com>

The access hack for array class clone is only applied to `checkAccess` but missing before call to `restrictProtectedReceiver`, causing the array receiver type to be incorrectly replaced by the lookupClass type. This patch fixes that and adds a test to ensure an original lookup resolves `clone` for both array classes (public) and Object (inherited protected) correctly, and restores the old MethodHandlesGeneralTest from [JDK-8001105](https://bugs.openjdk.org/browse/JDK-8001105) which ensures correctness for publicLookup (which is already correct).

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

Commit messages:
 - 8299505: findVirtual on array classes incorrectly restricts the receiver type

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

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

From mdoerr at openjdk.org  Sat May  6 19:38:36 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Sat, 6 May 2023 19:38:36 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v28]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <9hDHgeACLaNP0lLQ7lXtWN07t6h4DDF5a9aaOTdvyMI=.932783da-eb49-4b9b-843b-fc564c6ffc41@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  libTestHFA: Add explicit type conversion to avoid build warning.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/754a19a0..74586ab8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=26-27

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

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

From rgiulietti at openjdk.org  Sat May  6 21:20:17 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sat, 6 May 2023 21:20:17 GMT
Subject: RFR: 8307466: java.time.Instant calculation bug in until and
 between methods
In-Reply-To: <TbOVsPh3u2tsHDgnDl6bg7DM7zDW7A0KTcM3PpMODfQ=.c27d4486-6c5d-4828-9d31-83ce21a7d26b@github.com>
References: <TbOVsPh3u2tsHDgnDl6bg7DM7zDW7A0KTcM3PpMODfQ=.c27d4486-6c5d-4828-9d31-83ce21a7d26b@github.com>
Message-ID: <hwx8pMRMxNAvetu5EhvBAFd4O5K9NGm7PJFV_J3ntAU=.8992176e-edd0-421e-8142-135afb3b6594@github.com>

On Fri, 5 May 2023 21:28:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The implementation of java.time.Instant.until(I2, ChronoUnit) in some cases did not correctly borrow or carry from the nanos to the seconds when computing using ChronoUnit.MILLIS or ChronoUnit.MICROS.
> The errant computation was introduced by [JDK-8273369](https://bugs.openjdk.org/browse/JDK-8273369).

src/java.base/share/classes/java/time/Instant.java line 1173:

> 1171:     private long microsUntil(Instant end) {
> 1172:         long microsDiff = Math.multiplyExact(end.seconds - seconds, MICROS_PER_SECOND);
> 1173:         long nanosDiff = end.nanos - nanos;

FWIW, `nanosDiff` could be declared `int` to slightly speed up the division later in the code, while still not risking overflows.

Similarly in `millisUntil()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13846#discussion_r1186747228

From liach at openjdk.org  Sun May  7 03:38:41 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 7 May 2023 03:38:41 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v13]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <w2viEJUAR525f62dijoyioMovcxZ1A_w-5lk7FyngKc=.25315411-83db-4650-8534-e6c39865f3f5@github.com>

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with a check to the class data. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> [^1]: single abstract method

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

 - Revert to shared-class implementation, found a way to deal with security manager
 - Merge branch 'master' into explore/mhp-iface
 - Minor cleanup, attempt to migrate lookup validation blocked by security manager
 - Renames
 - Merge branch 'master' into explore/mhp-iface
 - Consolidate iteration over public methods
 - Define MH proxy class in a dynamic module
 - Fix test that depend on WrapperInstance
 - Require an original lookup in constructor arguments to prevent unintended instantiation
 - pass interface info via condy,
   drop explicit ea flags
   initialize benchmark work variable randomly
   benchmarks just need 1 fork
 - ... and 17 more: https://git.openjdk.org/jdk/compare/ef4310b3...8b971172

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/27dc803d..8b971172

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=11-12

  Stats: 19933 lines in 566 files changed: 15121 ins; 2015 del; 2797 mod
  Patch: https://git.openjdk.org/jdk/pull/13197.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13197/head:pull/13197

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

From liach at openjdk.org  Sun May  7 03:43:28 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 7 May 2023 03:43:28 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v14]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <zdWE3RsjArnb1o7KvQvAbLNAfZpVJSwmvij162nqThw=.ede48b44-1e4b-4cb7-bdaf-ae5ebf7ed296@github.com>

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It implements proxies with one hidden class for each requested interface and replaced WrapperInstance inheritance with a check to the class data. This can avoid unexpected passing of `instanceof`, and avoids the nasty problem of exporting a JDK interface to a dynamic module to ensure access.
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's generated hidden classes has call performance on par with those of lambda expressions; the creation performance is slightly less than that of LambdaMetafactory: https://jmh.morethan.io/?gist=fcb946d83ee4ac7386901795ca49b224
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable. Tests in `jdk/java/lang/invoke` and `jdk/java/lang/reflect` pass.
> 
> [^1]: single abstract method

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  stupid faults

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/8b971172..af36da3c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13197&range=12-13

  Stats: 208 lines in 3 files changed: 1 ins; 16 del; 191 mod
  Patch: https://git.openjdk.org/jdk/pull/13197.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13197/head:pull/13197

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

From liach at openjdk.org  Sun May  7 04:26:34 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 7 May 2023 04:26:34 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v15]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <KfQkNkjvoWwITn5Vl1JL162bQffqUFHkZFtGtQErxXM=.eabab291-3b64-4bf7-a5ee-07c384aa0855@github.com>

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's faster than old implementation in general.
> 
> 
> Benchmark                                                          Mode  Cnt      Score      Error  Units
> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.483 ?    0.025  ns/op
> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.264 ?    0.006  ns/op
> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.773 ?    0.040  ns/op
> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     16.754 ?    0.411  ns/op
> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.609 ?    1.598  ns/op
> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt   15      0.424 ?    0.024  ns/op
> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt   15      1.936 ?    0.008  ns/op
> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt   15      1.766 ?    0.014  ns/op
> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt   15      0.414 ?    0.005  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt   15      0.271 ?    0.006  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt   15      0.263 ?    0.004  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt   15      0.266 ?    0.005  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt   15      0.262 ?    0.003  ns/op
> MethodHandleProxiesAsIFInstanceCall.direct                         avgt   15      0.264 ?    0.005  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt   15     18.000 ?    0.181  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createCallLambda             avgt   15  17624.673 ? 2404.853  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createInterfaceInstance      avgt   15     17.554 ?    0.748  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createLambda                 avgt   15  16860.341 ? 1270.982  ns/op
> MethodHandleProxiesSuppl.testInstanceTarget                        avgt   15      0.405 ?    0.006  ns/op
> MethodHandleProxiesSuppl.testInstanceType                          avgt   15      0.343 ?    0.005  ns/op
> MethodHandleProxiesSuppl.testIsWrapperInstance                     avgt   15      0.375 ?    0.021  ns/op
> 
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable.
> 
> [^1]: single abstract method

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Fix tabs, and tests about modules and constructor access

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/af36da3c..836d9d0b

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

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

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

From mchung at openjdk.org  Sun May  7 08:27:18 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Sun, 7 May 2023 08:27:18 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v3]
In-Reply-To: <O6F5e_dRzOz4AX-Cigy4Hxq0lfFDcydWspCv-F4ZLsM=.ac479437-5dac-472c-9184-97d29292c3eb@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
 <O6F5e_dRzOz4AX-Cigy4Hxq0lfFDcydWspCv-F4ZLsM=.ac479437-5dac-472c-9184-97d29292c3eb@github.com>
Message-ID: <gYqiVql-BXympkbhKI_Gz04CMpQSnZV3Vh544tNEKdA=.200dd76d-6708-4b65-acff-36d7f0177ab9@github.com>

On Fri, 5 May 2023 13:59:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
>> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
>> 
>> Neither os.name nor os.arch should be assumed to be changeable; 
>> one test case is removed because it assumes os.name can be changed on the command line.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Source code cleanup suggested by reviewers

I suggest to remove `Platform::is64Bit` and simply call `Architecture::is64bit`.  Otherwise, looks fine.

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13585#pullrequestreview-1415865569

From mchung at openjdk.org  Sun May  7 09:33:17 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Sun, 7 May 2023 09:33:17 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v3]
In-Reply-To: <O6F5e_dRzOz4AX-Cigy4Hxq0lfFDcydWspCv-F4ZLsM=.ac479437-5dac-472c-9184-97d29292c3eb@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
 <O6F5e_dRzOz4AX-Cigy4Hxq0lfFDcydWspCv-F4ZLsM=.ac479437-5dac-472c-9184-97d29292c3eb@github.com>
Message-ID: <NsUfBEXi00PFwf9zUFqn-4D1IJ69sylIOCZFv66A-VA=.61842734-625f-49c0-8da3-1a1bd15c7a47@github.com>

On Fri, 5 May 2023 13:59:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
>> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
>> 
>> Neither os.name nor os.arch should be assumed to be changeable; 
>> one test case is removed because it assumes os.name can be changed on the command line.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Source code cleanup suggested by reviewers

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 64:

> 62:      */
> 63:     public boolean is64Bit() {
> 64:         return Architecture.is64bit();

`Platform::is64Bit` tests if the target architecture is 64-bit but `Architecture.is64bit()` tests the runtime architecture.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1186816949

From liach at openjdk.org  Sun May  7 13:05:21 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 7 May 2023 13:05:21 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v15]
In-Reply-To: <KfQkNkjvoWwITn5Vl1JL162bQffqUFHkZFtGtQErxXM=.eabab291-3b64-4bf7-a5ee-07c384aa0855@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <KfQkNkjvoWwITn5Vl1JL162bQffqUFHkZFtGtQErxXM=.eabab291-3b64-4bf7-a5ee-07c384aa0855@github.com>
Message-ID: <t5mdjQv6e9w54D9btMb2SDWRj_ysAdYgJlIWg4u-iVk=.f3cfa068-fb0a-4ee1-a719-c3db0a640018@github.com>

On Sun, 7 May 2023 04:26:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's faster than old implementation in general.
>> 
>> 
>> Benchmark                                                          Mode  Cnt      Score      Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.483 ?    0.025  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.264 ?    0.006  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.773 ?    0.040  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     16.754 ?    0.411  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.609 ?    1.598  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt   15      0.424 ?    0.024  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt   15      1.936 ?    0.008  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt   15      1.766 ?    0.014  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt   15      0.414 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt   15      0.271 ?    0.006  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt   15      0.263 ?    0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt   15      0.266 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt   15      0.262 ?    0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt   15      0.264 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt   15     18.000 ?    0.181  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallLambda             avgt   15  17624.673 ? 2404.853  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createInterfaceInstance      avgt   15     17.554 ?    0.748  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createLambda                 avgt   15  16860.341 ? 1270.982  ns/op
>> MethodHandleProxiesSuppl.testInstanceTarget                        avgt   15      0.405 ?    0.006  ns/op
>> MethodHandleProxiesSuppl.testInstanceType                          avgt   15      0.343 ?    0.005  ns/op
>> MethodHandleProxiesSuppl.testIsWrapperInstance                     avgt   15      0.375 ?    0.021  ns/op
>> 
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable.
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix tabs, and tests about modules and constructor access

Moved the implementation back to shared-class. The dedicated-class implementation will probably be offered from another API instead.

The test failure is caused by lookup class definer defining classes in a different module, which breaks the `assert(Reflection::is_same_class_package(lookup_k, ik))` assertion. Since I know little to none C++, might need someone's help to further tweak that part.

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

PR Comment: https://git.openjdk.org/jdk/pull/13197#issuecomment-1537436920

From liach at openjdk.org  Sun May  7 13:34:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 7 May 2023 13:34:54 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
Message-ID: <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>

> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
> 2. Does not allow future expansion to support SAM[^1] abstract classes
> 3. Slow (in fact, very slow)
> 
> This patch addresses all 3 problems:
> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
> 3. This patch's faster than old implementation in general.
> 
> 
> Benchmark                                                          Mode  Cnt      Score      Error  Units
> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.483 ?    0.025  ns/op
> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.264 ?    0.006  ns/op
> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.773 ?    0.040  ns/op
> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     16.754 ?    0.411  ns/op
> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.609 ?    1.598  ns/op
> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt   15      0.424 ?    0.024  ns/op
> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt   15      1.936 ?    0.008  ns/op
> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt   15      1.766 ?    0.014  ns/op
> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt   15      0.414 ?    0.005  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt   15      0.271 ?    0.006  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt   15      0.263 ?    0.004  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt   15      0.266 ?    0.005  ns/op
> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt   15      0.262 ?    0.003  ns/op
> MethodHandleProxiesAsIFInstanceCall.direct                         avgt   15      0.264 ?    0.005  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt   15     18.000 ?    0.181  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createCallLambda             avgt   15  17624.673 ? 2404.853  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createInterfaceInstance      avgt   15     17.554 ?    0.748  ns/op
> MethodHandleProxiesAsIFInstanceCreate.createLambda                 avgt   15  16860.341 ? 1270.982  ns/op
> MethodHandleProxiesSuppl.testInstanceTarget                        avgt   15      0.405 ?    0.006  ns/op
> MethodHandleProxiesSuppl.testInstanceType                          avgt   15      0.343 ?    0.005  ns/op
> MethodHandleProxiesSuppl.testIsWrapperInstance                     avgt   15      0.375 ?    0.021  ns/op
> 
> 
> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable.
> 
> [^1]: single abstract method

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Remove assertion, no longer true with teleport definition in MHP

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13197/files
  - new: https://git.openjdk.org/jdk/pull/13197/files/836d9d0b..bd21e68e

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

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

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

From liach at openjdk.org  Sun May  7 13:36:16 2023
From: liach at openjdk.org (Chen Liang)
Date: Sun, 7 May 2023 13:36:16 GMT
Subject: RFR: 8307575: Migrate the serialization constructor accessors to
 Method Handles [v2]
In-Reply-To: <avFjVaHBj3-NeBLAP04SmKoBrfwEMsUz60qCfGeuSMk=.d89f252a-10f3-4c2d-8cb4-5dbeeee051d1@github.com>
References: <avFjVaHBj3-NeBLAP04SmKoBrfwEMsUz60qCfGeuSMk=.d89f252a-10f3-4c2d-8cb4-5dbeeee051d1@github.com>
Message-ID: <eJguOKvsmtcMCtVsbhufMqRLxFyRfAvBjq-cq_Tf3rs=.29134497-8bdf-4f04-8e59-0af8cb7bcd97@github.com>

> Apparently method handle linking doesn't impose extra checks on constructor invocation, so the special logic for the serialization constructor to call superclass constructor in MagicAccessorImpl can be removed altogether with old core reflection implementation.
> 
> Serialization and sun.reflect.ReflectionFactory tests pass. May be worth to think about the long-term treatment of ReflectionFactory.newConstructorForSerialization, as creating partial object is inherently unsafe, and behavior of `newConstructorForSerialization(ArrayList.class, String.class.getDeclaredConstructor(String.class))` etc. (which is accepted for now) may have unpredictable side effects.
> 
> #1830 has a similar patch; this one doesn't touch proxies and updates to the new post-JEP 416 reflection implementation.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Remove invalid assertion (via sun.reflect.ReflectionFactory)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13853/files
  - new: https://git.openjdk.org/jdk/pull/13853/files/64a8f518..3a0393a9

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

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

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

From rriggs at openjdk.org  Sun May  7 17:58:26 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sun, 7 May 2023 17:58:26 GMT
Subject: RFR: 8307466: java.time.Instant calculation bug in until and
 between methods [v2]
In-Reply-To: <TbOVsPh3u2tsHDgnDl6bg7DM7zDW7A0KTcM3PpMODfQ=.c27d4486-6c5d-4828-9d31-83ce21a7d26b@github.com>
References: <TbOVsPh3u2tsHDgnDl6bg7DM7zDW7A0KTcM3PpMODfQ=.c27d4486-6c5d-4828-9d31-83ce21a7d26b@github.com>
Message-ID: <m3_pYsA5l-v4NzHlIdgM-650MYEONnA_xcQavH6-xs4=.ff1b8804-7f77-4a32-b9b2-2b194291aae1@github.com>

> The implementation of java.time.Instant.until(I2, ChronoUnit) in some cases did not correctly borrow or carry from the nanos to the seconds when computing using ChronoUnit.MILLIS or ChronoUnit.MICROS.
> The errant computation was introduced by [JDK-8273369](https://bugs.openjdk.org/browse/JDK-8273369).

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Slight perf improvement using int instead of long for local nanosDiff

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13846/files
  - new: https://git.openjdk.org/jdk/pull/13846/files/8deb8df7..46d4918a

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

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

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

From dholmes at openjdk.org  Mon May  8 06:01:15 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 8 May 2023 06:01:15 GMT
Subject: RFR: 8307483: New micros for j.u.c.LockSupport
In-Reply-To: <MPCS9xNA6fkUt-z01pnXcd4cpXYzsTFH9LAmM4tFm8w=.a54f610c-1095-4b18-bb45-36562881d5d1@github.com>
References: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
 <MPCS9xNA6fkUt-z01pnXcd4cpXYzsTFH9LAmM4tFm8w=.a54f610c-1095-4b18-bb45-36562881d5d1@github.com>
Message-ID: <FVilKBI3w8Ok8vMoW5uvKxotCrN64xhPEz7a7sSsj7M=.352c508a-a5e8-45c1-bfb5-80c5c6c44dbf@github.com>

On Fri, 5 May 2023 14:31:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> These micros were developed while investigating JDK-8305670 by myself and Sergey Kuksenko. The order of thread creation was important in that bug, so there are 2 JMH for creating sleepers before and after the worker threads.
>
> test/micro/org/openjdk/bench/java/util/concurrent/UnparkBenchSleepersAfter.java line 131:
> 
>> 129:         public void run() {
>> 130:             my_thread = Thread.currentThread();
>> 131:             while (!done) {
> 
> You might want to re-check IdleThread. From a quick look I would have expected "done" to be volatile. Also "my_thread" as it is set in the run with plain access.

Yes `done` must be volatile. Surprised this even worked as expected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1187052047

From sgehwolf at openjdk.org  Mon May  8 08:52:27 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 8 May 2023 08:52:27 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v7]
In-Reply-To: <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com>
Message-ID: <VW1QrapIow7dJlwFg8t6k5zjTAwQYBWsN1yPbq1_7VM=.ccf9b5d7-4648-4a64-bf6f-571c556cb9b9@github.com>

On Fri, 5 May 2023 16:52:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries
>> 
>> - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>>  
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitespace error in make/StaticJvmLibsImage.gmk.

Seems fine to me, but I'm not an expert in on the build files. Thanks for the implementing the suggestion.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1416396939

From sgehwolf at openjdk.org  Mon May  8 09:00:22 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 8 May 2023 09:00:22 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v7]
In-Reply-To: <rIFR8lzb8zKI5f0h_VcaherfoEEtQqeX2C0UyApAqeE=.bb53bbe4-4bf6-4c22-9bff-a2b357397cce@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com>
 <rIFR8lzb8zKI5f0h_VcaherfoEEtQqeX2C0UyApAqeE=.bb53bbe4-4bf6-4c22-9bff-a2b357397cce@github.com>
Message-ID: <2BVvV9m8bI-UzZXpX1GEPwoStZ6pHZBn4JuAMRQk978=.54246fe4-57b8-4372-bfc4-6b63823fa9a2@github.com>

On Fri, 5 May 2023 20:43:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> All of that said, I think we can get away with a smaller subset of targets and deliverables. AFAIK, graal needs the combined `graal-builder-image` as input to their build anyway, so they should not have any dependency on what the target `static-libs-image` produces. Given that I propose the following behavior:
> 
> `make static-libs-image` produces `images/static-libs` with all .a (including libjvm.a). `make static-libs-graal-image` produces `images/static-libs-graal` with all .a except libjvm.a. `make graal-builder-image` produces `images/graal-builder-image` like today, but depends on and uses `static-libs-graal-image` instead of `static-libs-image`. `make static-libs-bundles` depends on and uses `static-libs-image` like today, so will contain libjvm.a, which is new behavior.

Sure, that should work too as long as there is a way to a) build the static libs only needed for graal some way b) keep `graal-builder-image` working as it does today. FWIW, we use `a)` at adoptium so as to be able to have a combination to build mandrel from. Not all users will want to have JDK + static libs so only the ones needing them should need to download them.

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

PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1538008209

From shade at openjdk.org  Mon May  8 09:26:31 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 8 May 2023 09:26:31 GMT
Subject: RFR: 8307483: New micros for j.u.c.LockSupport
In-Reply-To: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
References: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
Message-ID: <v4DLofUrA0bhYkc4bsFbQ6EZV6cu9pRhDwWpMR0CTmA=.cc3a24d9-5b8e-42b9-9c5a-4ae7acb60120@github.com>

On Thu, 4 May 2023 20:17:11 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> These micros were developed while investigating JDK-8305670 by myself and Sergey Kuksenko. The order of thread creation was important in that bug, so there are 2 JMH for creating sleepers before and after the worker threads.

Cursory style reviews.

test/micro/org/openjdk/bench/java/util/concurrent/UnparkBenchSleepersAfter.java line 90:

> 88: 
> 89: 
> 90:     ExecutorService exec;

Suggestion:

    IdleThread[] idleThreads;

    ExecutorService exec;

test/micro/org/openjdk/bench/java/util/concurrent/UnparkBenchSleepersAfter.java line 99:

> 97:         for (int i = 0; i < workers; i++) { // warmup exec
> 98:             exec.submit(() ->
> 99:             {

Suggestion:

            exec.submit(() -> {

test/micro/org/openjdk/bench/java/util/concurrent/UnparkBenchSleepersAfter.java line 113:

> 111:         for(int i=0; i < idle_threads.length; i++) {
> 112:             new Thread(idle_threads[i] = new IdleThread()).start();
> 113:         }

These `idleThreads` are not actually `Thread`-s, they are `Runnable`-s.

Suggestion:

        for(int i = 0; i < idles; i++) {
            Runnable r = new IdleRunnable();
            idleRunnables[i] = r;
            new Thread(r).start();
        }

test/micro/org/openjdk/bench/java/util/concurrent/UnparkBenchSleepersAfter.java line 118:

> 116:     @TearDown
> 117:     public void tearDown() {
> 118:         for(IdleThread it : idle_threads) {

Suggestion:

        for (IdleThread it : idle_threads) {

test/micro/org/openjdk/bench/java/util/concurrent/UnparkBenchSleepersAfter.java line 126:

> 124:     public static class IdleThread implements Runnable {
> 125:         boolean done = false;
> 126:         Thread my_thread;

Suggestion:

        Thread myThread;

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

PR Review: https://git.openjdk.org/jdk/pull/13815#pullrequestreview-1416443702
PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1187224644
PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1187224912
PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1187226283
PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1187226379
PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1187226532

From shade at openjdk.org  Mon May  8 09:26:32 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 8 May 2023 09:26:32 GMT
Subject: RFR: 8307483: New micros for j.u.c.LockSupport
In-Reply-To: <FVilKBI3w8Ok8vMoW5uvKxotCrN64xhPEz7a7sSsj7M=.352c508a-a5e8-45c1-bfb5-80c5c6c44dbf@github.com>
References: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
 <MPCS9xNA6fkUt-z01pnXcd4cpXYzsTFH9LAmM4tFm8w=.a54f610c-1095-4b18-bb45-36562881d5d1@github.com>
 <FVilKBI3w8Ok8vMoW5uvKxotCrN64xhPEz7a7sSsj7M=.352c508a-a5e8-45c1-bfb5-80c5c6c44dbf@github.com>
Message-ID: <zW1LM8BfJzQLB3M6oR68tfDrXcwITzzeVUz2RMvuKXw=.78079063-fa08-4a79-9a75-eb09eaf5903f@github.com>

On Mon, 8 May 2023 05:58:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/util/concurrent/UnparkBenchSleepersAfter.java line 131:
>> 
>>> 129:         public void run() {
>>> 130:             my_thread = Thread.currentThread();
>>> 131:             while (!done) {
>> 
>> You might want to re-check IdleThread. From a quick look I would have expected "done" to be volatile. Also "my_thread" as it is set in the run with plain access.
>
> Yes `done` must be volatile. Surprised this even worked as expected.

Same as we saw with `isAlive` before: `LockSupport.park` implicitly provides a compiler barrier. This `done` should be at least "opaque" to carry the same effect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1187227417

From mcimadamore at openjdk.org  Mon May  8 09:35:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 May 2023 09:35:33 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
Message-ID: <bZgoi5WAcBpw0AmBqKz22efZ4PP_W1Cxp5V1G6GHrzs=.91d1d5ad-7d6c-4bae-8409-62e3dab28869@github.com>

On Sun, 7 May 2023 13:34:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's faster than old implementation in general.
>> 
>> 
>> Benchmark                                                          Mode  Cnt      Score      Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.483 ?    0.025  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.264 ?    0.006  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.773 ?    0.040  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     16.754 ?    0.411  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.609 ?    1.598  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt   15      0.424 ?    0.024  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt   15      1.936 ?    0.008  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt   15      1.766 ?    0.014  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt   15      0.414 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt   15      0.271 ?    0.006  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt   15      0.263 ?    0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt   15      0.266 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt   15      0.262 ?    0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt   15      0.264 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt   15     18.000 ?    0.181  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallLambda             avgt   15  17624.673 ? 2404.853  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createInterfaceInstance      avgt   15     17.554 ?    0.748  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createLambda                 avgt   15  16860.341 ? 1270.982  ns/op
>> MethodHandleProxiesSuppl.testInstanceTarget                        avgt   15      0.405 ?    0.006  ns/op
>> MethodHandleProxiesSuppl.testInstanceType                          avgt   15      0.343 ?    0.005  ns/op
>> MethodHandleProxiesSuppl.testIsWrapperInstance                     avgt   15      0.375 ?    0.021  ns/op
>> 
>> 
>> Additionally, an obsolete `ProxyForMethodHandle` test was removed, for it's no longer applicable.
>> 
>> [^1]: single abstract method
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove assertion, no longer true with teleport definition in MHP

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 342:

> 340: 
> 341:             // individual handle fields
> 342:             clb.withField(ORIGINAL_TARGET_NAME, CD_MethodHandle, ACC_PRIVATE | ACC_FINAL);

Would a @Stable field help here? E.g if the returned functional interface instance is stored in a `static final` field, it should enable better performance?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1187237878

From duke at openjdk.org  Mon May  8 10:04:24 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 8 May 2023 10:04:24 GMT
Subject: RFR: 8307483: New micros for j.u.c.LockSupport
In-Reply-To: <zW1LM8BfJzQLB3M6oR68tfDrXcwITzzeVUz2RMvuKXw=.78079063-fa08-4a79-9a75-eb09eaf5903f@github.com>
References: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
 <MPCS9xNA6fkUt-z01pnXcd4cpXYzsTFH9LAmM4tFm8w=.a54f610c-1095-4b18-bb45-36562881d5d1@github.com>
 <FVilKBI3w8Ok8vMoW5uvKxotCrN64xhPEz7a7sSsj7M=.352c508a-a5e8-45c1-bfb5-80c5c6c44dbf@github.com>
 <zW1LM8BfJzQLB3M6oR68tfDrXcwITzzeVUz2RMvuKXw=.78079063-fa08-4a79-9a75-eb09eaf5903f@github.com>
Message-ID: <CGrg719xG5p69oMVCGiPV4eua0cU7_GnvVIwIYAyGu4=.a944b674-93b0-4865-9220-d2a774088a8f@github.com>

On Mon, 8 May 2023 09:21:54 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Yes `done` must be volatile. Surprised this even worked as expected.
>
> Same as we saw with `isAlive` before: `LockSupport.park` implicitly provides a compiler barrier. This `done` should be at least "opaque" to carry the same effect.

Yes, `park()` and `unpark()` having release and acquire semantics is not documented [here](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/concurrent/locks/LockSupport.html#park()), and the documentation for `LockSupport` explicitly says "Reliable usage requires the use of volatile (or atomic) variables to control when to park or unpark. Orderings of calls to these methods are maintained with respect to volatile variable accesses, but not necessarily non-volatile variable accesses."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1187264285

From duke at openjdk.org  Mon May  8 10:41:29 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 8 May 2023 10:41:29 GMT
Subject: RFR: JDK-8133773: clarify specification of Spliterator.tryAdvance
Message-ID: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>

Attempting to make the "at-most once" nature, of invoking the supplied action to tryAdvance, clearer in the JavaDoc.

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

Commit messages:
 - JDK-8133773: clarify specification of Spliterator.tryAdvance

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

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

From mcimadamore at openjdk.org  Mon May  8 10:49:26 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 May 2023 10:49:26 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <bZgoi5WAcBpw0AmBqKz22efZ4PP_W1Cxp5V1G6GHrzs=.91d1d5ad-7d6c-4bae-8409-62e3dab28869@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bZgoi5WAcBpw0AmBqKz22efZ4PP_W1Cxp5V1G6GHrzs=.91d1d5ad-7d6c-4bae-8409-62e3dab28869@github.com>
Message-ID: <GCnfBNVUPeVmqAE4WtBp8RHzhr1a2xuDfE98tqxiDGg=.331c452e-ed0d-465a-9b41-bf81c7b104d0@github.com>

On Mon, 8 May 2023 09:32:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove assertion, no longer true with teleport definition in MHP
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 342:
> 
>> 340: 
>> 341:             // individual handle fields
>> 342:             clb.withField(ORIGINAL_TARGET_NAME, CD_MethodHandle, ACC_PRIVATE | ACC_FINAL);
> 
> Would a @Stable field help here? E.g if the returned functional interface instance is stored in a `static final` field, it should enable better performance?

(actually, not sure - as the class is saved in a class value cache, so probably adding stable won't make any difference).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1187300990

From mcimadamore at openjdk.org  Mon May  8 11:18:25 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 May 2023 11:18:25 GMT
Subject: RFR: 8307615: Linker::nativeLinker should not be restricted
 (mainline)
In-Reply-To: <8owRB5GDdEv2aRLKJO3NHtMNoXnmCf3Pd2GfwUtO-Go=.f6234082-15f1-4f3e-ba69-22818a86e984@github.com>
References: <8owRB5GDdEv2aRLKJO3NHtMNoXnmCf3Pd2GfwUtO-Go=.f6234082-15f1-4f3e-ba69-22818a86e984@github.com>
Message-ID: <aBEtGvJnelaOetwEYzRu79lGL_g2vK_Mi3ftSZTiqZA=.0fe0b2bd-b8fb-4ea6-be19-b88394af8273@github.com>

On Mon, 8 May 2023 11:10:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Port of: https://git.openjdk.org/panama-foreign/pull/831

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 86:

> 84:     }
> 85: 
> 86:     private final MethodHandle downcallHandle0(Class<?> callerClass, FunctionDescriptor function, Option... options) {

This method is different from the PR in the panama repo. Here I wanted to try and perform the restricted method check only once.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13863#discussion_r1187321353

From mcimadamore at openjdk.org  Mon May  8 11:18:23 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 May 2023 11:18:23 GMT
Subject: RFR: 8307615: Linker::nativeLinker should not be restricted (mainline)
Message-ID: <8owRB5GDdEv2aRLKJO3NHtMNoXnmCf3Pd2GfwUtO-Go=.f6234082-15f1-4f3e-ba69-22818a86e984@github.com>

Port of: https://git.openjdk.org/panama-foreign/pull/831

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

Commit messages:
 - Cleanup code so that restricted method check is shared
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/13863/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13863&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307615
  Stats: 128 lines in 11 files changed: 65 ins; 17 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/13863.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13863/head:pull/13863

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

From jpai at openjdk.org  Mon May  8 11:58:27 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 May 2023 11:58:27 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v5]
In-Reply-To: <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>
Message-ID: <JaHJFI_N3kV-l-1lZySph5dihc1k7QE9aUksfceL-Lk=.a4f17690-c38d-4d6a-b717-2d2bf6db807b@github.com>

On Mon, 24 Apr 2023 12:18:55 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small optimization in private split().
>   Added tests to compare String and Pattern implementations, in particular for one char regex.

src/java.base/share/classes/java/lang/String.java line 3254:

> 3252:      *    <li> If the <i>limit</i> is positive then the pattern will be applied
> 3253:      *    at most <i>limit</i>&nbsp;-&nbsp;1 times, the array's length will be
> 3254:      *    no greater than 2 &centerdot; <i>limit</i> - 1, and the array's last

Hello Raffaello, when this is rendered, it looks like:

<img width="464" alt="centerdot" src="https://user-images.githubusercontent.com/143523/236816797-b8e0f64a-74a7-4d90-bf06-0350a023f24b.png">

I had to read up what `centerdot` is and from what I understand, it's used in mathematical notation for multiplication sign https://en.wikipedia.org/wiki/Interpunct#In_mathematics_and_science. 

However, I don't remember seeing similar usage in our API docs for multiplication symbol. I think, `*` has been widely(?) used in our API docs. Should we use `*` here too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1187358239

From jpai at openjdk.org  Mon May  8 12:11:15 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 May 2023 12:11:15 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v5]
In-Reply-To: <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>
Message-ID: <ZHPbhpQ57-R3j03Sk-jQyPpu4Y5uiQSaQL4o6X-QB8w=.8aba991b-38a2-4d0d-a23c-b7822cc3cecc@github.com>

On Mon, 24 Apr 2023 12:18:55 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small optimization in private split().
>   Added tests to compare String and Pattern implementations, in particular for one char regex.

Overall, the changes look OK to me. I have a comment about the javadoc which I've added inline.

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

PR Comment: https://git.openjdk.org/jdk/pull/13305#issuecomment-1538250225

From rgiulietti at openjdk.org  Mon May  8 12:11:17 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 8 May 2023 12:11:17 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v5]
In-Reply-To: <JaHJFI_N3kV-l-1lZySph5dihc1k7QE9aUksfceL-Lk=.a4f17690-c38d-4d6a-b717-2d2bf6db807b@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>
 <JaHJFI_N3kV-l-1lZySph5dihc1k7QE9aUksfceL-Lk=.a4f17690-c38d-4d6a-b717-2d2bf6db807b@github.com>
Message-ID: <c2G-q_PVEbMZvVcmdcRPcVv-z0Q7Zj7CKs18quphVZo=.b7c8eddb-189e-4c37-b298-e45fb0959637@github.com>

On Mon, 8 May 2023 11:55:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Small optimization in private split().
>>   Added tests to compare String and Pattern implementations, in particular for one char regex.
>
> src/java.base/share/classes/java/lang/String.java line 3254:
> 
>> 3252:      *    <li> If the <i>limit</i> is positive then the pattern will be applied
>> 3253:      *    at most <i>limit</i>&nbsp;-&nbsp;1 times, the array's length will be
>> 3254:      *    no greater than 2 &centerdot; <i>limit</i> - 1, and the array's last
> 
> Hello Raffaello, when this is rendered, it looks like:
> 
> <img width="464" alt="centerdot" src="https://user-images.githubusercontent.com/143523/236816797-b8e0f64a-74a7-4d90-bf06-0350a023f24b.png">
> 
> I had to read up what `centerdot` is and from what I understand, it's used in mathematical notation for multiplication sign https://en.wikipedia.org/wiki/Interpunct#In_mathematics_and_science. 
> 
> However, I don't remember seeing similar usage in our API docs for multiplication symbol. I think, `*` has been widely(?) used in our API docs. Should we use `*` here too?
> 
> Same applies to the new javadoc on `Pattern` class.

The HTML named entity `&centerdot;` is rendered correctly by the javadoc tool. However, IntelliJ IDEA currently does not recognize it (https://youtrack.jetbrains.com/issue/IDEA-316843). I could replace it by the equivalent `&#xB7;`, which is recognized by IDEA, but which is much less readable in source code.
So, unless there are other reason to prefer `*`, I'd like to stick with `&centerdot;`.

WDYT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1187369355

From rgiulietti at openjdk.org  Mon May  8 12:19:19 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 8 May 2023 12:19:19 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v5]
In-Reply-To: <c2G-q_PVEbMZvVcmdcRPcVv-z0Q7Zj7CKs18quphVZo=.b7c8eddb-189e-4c37-b298-e45fb0959637@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>
 <JaHJFI_N3kV-l-1lZySph5dihc1k7QE9aUksfceL-Lk=.a4f17690-c38d-4d6a-b717-2d2bf6db807b@github.com>
 <c2G-q_PVEbMZvVcmdcRPcVv-z0Q7Zj7CKs18quphVZo=.b7c8eddb-189e-4c37-b298-e45fb0959637@github.com>
Message-ID: <qcXAua9MciT5NmhdT-qi8USmlBDUQU0o0hHI_d0RQW4=.349f577b-146a-4439-8b2f-bf59e6e6398e@github.com>

On Mon, 8 May 2023 12:08:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/String.java line 3254:
>> 
>>> 3252:      *    <li> If the <i>limit</i> is positive then the pattern will be applied
>>> 3253:      *    at most <i>limit</i>&nbsp;-&nbsp;1 times, the array's length will be
>>> 3254:      *    no greater than 2 &centerdot; <i>limit</i> - 1, and the array's last
>> 
>> Hello Raffaello, when this is rendered, it looks like:
>> 
>> <img width="464" alt="centerdot" src="https://user-images.githubusercontent.com/143523/236816797-b8e0f64a-74a7-4d90-bf06-0350a023f24b.png">
>> 
>> I had to read up what `centerdot` is and from what I understand, it's used in mathematical notation for multiplication sign https://en.wikipedia.org/wiki/Interpunct#In_mathematics_and_science. 
>> 
>> However, I don't remember seeing similar usage in our API docs for multiplication symbol. I think, `*` has been widely(?) used in our API docs. Should we use `*` here too?
>> 
>> Same applies to the new javadoc on `Pattern` class.
>
> The HTML named entity `&centerdot;` is rendered correctly by the javadoc tool. However, IntelliJ IDEA currently does not recognize it (https://youtrack.jetbrains.com/issue/IDEA-316843). I could replace it by the equivalent `&#xB7;`, which is recognized by IDEA, but which is much less readable in source code.
> So, unless there are other reason to prefer `*`, I'd like to stick with `&centerdot;`.
> 
> WDYT?

Alternatively, one could remove the multiplication sign altogether...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1187376851

From jvernee at openjdk.org  Mon May  8 12:22:16 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 8 May 2023 12:22:16 GMT
Subject: RFR: 8307615: Linker::nativeLinker should not be restricted
 (mainline)
In-Reply-To: <8owRB5GDdEv2aRLKJO3NHtMNoXnmCf3Pd2GfwUtO-Go=.f6234082-15f1-4f3e-ba69-22818a86e984@github.com>
References: <8owRB5GDdEv2aRLKJO3NHtMNoXnmCf3Pd2GfwUtO-Go=.f6234082-15f1-4f3e-ba69-22818a86e984@github.com>
Message-ID: <KQjJOmK2qxMVVx4l7x8mUb_wcUNR2dlGtt5Mk2pr4rw=.512cb0ad-edb0-442e-b871-9138b5ec407e@github.com>

On Mon, 8 May 2023 11:10:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Port of: https://git.openjdk.org/panama-foreign/pull/831

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 78:

> 76:         SharedUtils.checkSymbol(symbol);
> 77:         return downcallHandle(function, options).bindTo(symbol);
> 78:     }

This doesn't look quite right, as `downcallHandle` is being called twice? (forgot to push?).

I suggest calling `Reflection::ensureNativeAccess` immediately in each overload, and then delegating to `downcallHandle0` which doesn't check the access.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13863#discussion_r1187378482

From jpai at openjdk.org  Mon May  8 12:23:17 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 May 2023 12:23:17 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v5]
In-Reply-To: <qcXAua9MciT5NmhdT-qi8USmlBDUQU0o0hHI_d0RQW4=.349f577b-146a-4439-8b2f-bf59e6e6398e@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>
 <JaHJFI_N3kV-l-1lZySph5dihc1k7QE9aUksfceL-Lk=.a4f17690-c38d-4d6a-b717-2d2bf6db807b@github.com>
 <c2G-q_PVEbMZvVcmdcRPcVv-z0Q7Zj7CKs18quphVZo=.b7c8eddb-189e-4c37-b298-e45fb0959637@github.com>
 <qcXAua9MciT5NmhdT-qi8USmlBDUQU0o0hHI_d0RQW4=.349f577b-146a-4439-8b2f-bf59e6e6398e@github.com>
Message-ID: <Q-naRJ6IkIze3PA9uCVkqlK-laLUsp_zelVWO5y7Sm4=.19e586b1-7939-40dd-98ae-7de7c1a080e8@github.com>

On Mon, 8 May 2023 12:15:57 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> The HTML named entity `&centerdot;` is rendered correctly by the javadoc tool. However, IntelliJ IDEA currently does not recognize it (https://youtrack.jetbrains.com/issue/IDEA-316843). I could replace it by the equivalent `&#xB7;`, which is recognized by IDEA, but which is much less readable in source code.
>> So, unless there are other reason to prefer `*`, I'd like to stick with `&centerdot;`.
>> 
>> WDYT?
>
> Alternatively, one could remove the multiplication sign altogether...

> I could replace it by the equivalent `&#xB7;`

I just locally used this as a replacement to `centerdot` and regenerated the javadocs. The generated javadoc HTML looks the same like the screenshot in my previous comment.

My only concern here is that this notation isn't used previously in any of our APIs and since it's part of a "regular" (non mathemical) sentence, it might be hard to understand what it is. I think it is relatable when it's part of some larger mathematical formula/explanation.

I just did a quick search of `centerdot` in the JDK source to see if it's been used in any API documentation currently and didn't find any such cases. So I still think using `*` would be clearer.

Having said that, if there are no objections from Roger or any other reviewers, it's OK with me too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1187380898

From jpai at openjdk.org  Mon May  8 12:23:16 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 May 2023 12:23:16 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v5]
In-Reply-To: <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>
Message-ID: <KHk0KmGgACnbUii2U3JUDbs4u4LxiTmzTiMGMaXDKFo=.91e91019-1069-46d7-a98e-fdf9e2f2c907@github.com>

On Mon, 24 Apr 2023 12:18:55 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Small optimization in private split().
>   Added tests to compare String and Pattern implementations, in particular for one char regex.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13305#pullrequestreview-1416695992

From jpai at openjdk.org  Mon May  8 12:26:25 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 May 2023 12:26:25 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v5]
In-Reply-To: <Q-naRJ6IkIze3PA9uCVkqlK-laLUsp_zelVWO5y7Sm4=.19e586b1-7939-40dd-98ae-7de7c1a080e8@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>
 <JaHJFI_N3kV-l-1lZySph5dihc1k7QE9aUksfceL-Lk=.a4f17690-c38d-4d6a-b717-2d2bf6db807b@github.com>
 <c2G-q_PVEbMZvVcmdcRPcVv-z0Q7Zj7CKs18quphVZo=.b7c8eddb-189e-4c37-b298-e45fb0959637@github.com>
 <qcXAua9MciT5NmhdT-qi8USmlBDUQU0o0hHI_d0RQW4=.349f577b-146a-4439-8b2f-bf59e6e6398e@github.com>
 <Q-naRJ6IkIze3PA9uCVkqlK-laLUsp_zelVWO5y7Sm4=.19e586b1-7939-40dd-98ae-7de7c1a080e8@github.com>
Message-ID: <8roPLmDraJbd9uQ1bnmEDHeaGroNsMu9rQ9rWj8qf9I=.44bf0032-89a4-4aba-9bb1-1fa9db781ab2@github.com>

On Mon, 8 May 2023 12:20:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alternatively, one could remove the multiplication sign altogether...
>
>> I could replace it by the equivalent `&#xB7;`
> 
> I just locally used this as a replacement to `centerdot` and regenerated the javadocs. The generated javadoc HTML looks the same like the screenshot in my previous comment.
> 
> My only concern here is that this notation isn't used previously in any of our APIs and since it's part of a "regular" (non mathemical) sentence, it might be hard to understand what it is. I think it is relatable when it's part of some larger mathematical formula/explanation.
> 
> I just did a quick search of `centerdot` in the JDK source to see if it's been used in any API documentation currently and didn't find any such cases. So I still think using `*` would be clearer.
> 
> Having said that, if there are no objections from Roger or any other reviewers, it's OK with me too.

> Alternatively, one could remove the multiplication sign altogether...

Do you mean rewording it to something like:

> the array's length will be no greater than 2 times <i>limit</i> - 1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1187383612

From rgiulietti at openjdk.org  Mon May  8 12:33:25 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 8 May 2023 12:33:25 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v5]
In-Reply-To: <8roPLmDraJbd9uQ1bnmEDHeaGroNsMu9rQ9rWj8qf9I=.44bf0032-89a4-4aba-9bb1-1fa9db781ab2@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>
 <JaHJFI_N3kV-l-1lZySph5dihc1k7QE9aUksfceL-Lk=.a4f17690-c38d-4d6a-b717-2d2bf6db807b@github.com>
 <c2G-q_PVEbMZvVcmdcRPcVv-z0Q7Zj7CKs18quphVZo=.b7c8eddb-189e-4c37-b298-e45fb0959637@github.com>
 <qcXAua9MciT5NmhdT-qi8USmlBDUQU0o0hHI_d0RQW4=.349f577b-146a-4439-8b2f-bf59e6e6398e@github.com>
 <Q-naRJ6IkIze3PA9uCVkqlK-laLUsp_zelVWO5y7Sm4=.19e586b1-7939-40dd-98ae-7de7c1a080e8@github.com>
 <8roPLmDraJbd9uQ1bnmEDHeaGroNsMu9rQ9rWj8qf9I=.44bf0032-89a4-4aba-9bb1-1fa9db781ab2@github.com>
Message-ID: <HOZlfhFT_NLPtVTJf0q-e7shqTT6XD1tBjotWAZIa-Q=.95e4a413-134d-465c-8f52-20fa3458ba96@github.com>

On Mon, 8 May 2023 12:23:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> I could replace it by the equivalent `&#xB7;`
>> 
>> I just locally used this as a replacement to `centerdot` and regenerated the javadocs. The generated javadoc HTML looks the same like the screenshot in my previous comment.
>> 
>> My only concern here is that this notation isn't used previously in any of our APIs and since it's part of a "regular" (non mathemical) sentence, it might be hard to understand what it is. I think it is relatable when it's part of some larger mathematical formula/explanation.
>> 
>> I just did a quick search of `centerdot` in the JDK source to see if it's been used in any API documentation currently and didn't find any such cases. So I still think using `*` would be clearer.
>> 
>> Having said that, if there are no objections from Roger or any other reviewers, it's OK with me too.
>
>> Alternatively, one could remove the multiplication sign altogether...
> 
> Do you mean rewording it to something like:
> 
>> the array's length will be no greater than 2 times <i>limit</i> - 1

I mean the usual juxtaposition in maths to signify multiplication, like in _a_ _b_ instead of _a_?_b_

> the array's length will be no greater than 2 _limit_ - 1

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1187390214

From jlaskey at openjdk.org  Mon May  8 12:51:08 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 8 May 2023 12:51:08 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v65]
In-Reply-To: <nAe_DBQxds8A45LkLzTNlflVBLc09_E1Dnhtj4cUjZ4=.2d01b306-25a5-4217-91dc-b64c439f1bef@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
 <nAe_DBQxds8A45LkLzTNlflVBLc09_E1Dnhtj4cUjZ4=.2d01b306-25a5-4217-91dc-b64c439f1bef@github.com>
Message-ID: <YJrw2TYcIl3YSbBUhC8lZkj80rjtMCCRbdxd9wK8sqM=.2b8176bd-a66d-4256-b407-9b9ea7529f01@github.com>

On Sat, 6 May 2023 02:42:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   CSR recommendations
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 123:
> 
>> 121:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 122:     public static final int MAX_INDY_CONCAT_ARG_SLOTS;
>> 123:     static { MAX_INDY_CONCAT_ARG_SLOTS = 200; }
> 
> I think this deserve a comment such as "use static initialize block to avoid MAX_INDY_CONCAT_ARG_SLOTS being treating as a constant for constant folding," assuming that is the intention here.

Changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1187407224

From jlaskey at openjdk.org  Mon May  8 12:53:16 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 8 May 2023 12:53:16 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v65]
In-Reply-To: <0lyLXXpOtSz0C8DvkpexUAyj3IPrqUkP4WuLHrw_30c=.512031ec-bacb-4918-a4be-6054a684fddb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
 <0lyLXXpOtSz0C8DvkpexUAyj3IPrqUkP4WuLHrw_30c=.512031ec-bacb-4918-a4be-6054a684fddb@github.com>
Message-ID: <u3aYXVcsp34hfkaxT-GO3Q5czUxnrxeSis416oflJQI=.8685258b-3c9d-404f-a98d-c6a512c044a0@github.com>

On Sat, 6 May 2023 02:53:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   CSR recommendations
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 427:
> 
>> 425:      * {@link StringTemplate}. To accommodate concatenation, values are converted to strings
>> 426:      * as if invoking {@link String#valueOf(Object)}.
>> 427:      * @implNote {@link StringTemplate#STR} is statically imported implicitly into every
> 
> IMO the remark regarding  STR being auto-imported works better as an apiNote rather than an implNote.
> 
> Regarding interning, I think an implSpec of "may or may not be interned" provides maximum flexibility to the implementation.

Changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1187409617

From coffeys at openjdk.org  Mon May  8 13:23:25 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Mon, 8 May 2023 13:23:25 GMT
Subject: RFR: 8305950: Have -XshowSettings option display tzdata version
Message-ID: <134CrUZw5fSJ5ejfxcGwvuKDR_J160WLH4N8uurVrt8=.d43aa8ec-c8a8-4463-8dc6-b31e04c69ac6@github.com>

minor enhancement to have -XshowSettings launcher option display the version of tzdata installed in the JDK

example output of the new tzdata info :


....
Locale settings:
    default locale = English
    default display locale = English
    default format locale = English
    tzdata version = 2023c
    available locales = , af, af_NA, af_ZA, af_ZA_#Latn, agq, agq_CM, agq_CM_#Latn,
    ......

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

Commit messages:
 - 8305950

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

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

From simonis at openjdk.org  Mon May  8 13:25:21 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 8 May 2023 13:25:21 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v6]
In-Reply-To: <efpV0T3_1LhUOc_J1aZ1YfIFrTm-ZehOfgipyY2HhLs=.a25064c1-cfc3-443a-b85c-f4f35948d87b@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <efpV0T3_1LhUOc_J1aZ1YfIFrTm-ZehOfgipyY2HhLs=.a25064c1-cfc3-443a-b85c-f4f35948d87b@github.com>
Message-ID: <cJuS2IAtus-CQp8W8-9CjgZpjAK_WmdO4_4_NtcQxvs=.2153e917-839c-41d2-99f2-4efa35407f34@github.com>

On Tue, 2 May 2023 18:02:41 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using try-with-resources and some formatting changes

I've created [JDK-8307621](https://bugs.openjdk.org/browse/JDK-8307621) to track the release note for this issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/13540#issuecomment-1538354022

From rriggs at openjdk.org  Mon May  8 13:40:22 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 May 2023 13:40:22 GMT
Subject: RFR: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions [v6]
In-Reply-To: <efpV0T3_1LhUOc_J1aZ1YfIFrTm-ZehOfgipyY2HhLs=.a25064c1-cfc3-443a-b85c-f4f35948d87b@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
 <efpV0T3_1LhUOc_J1aZ1YfIFrTm-ZehOfgipyY2HhLs=.a25064c1-cfc3-443a-b85c-f4f35948d87b@github.com>
Message-ID: <yofLtblsKiNT9_aHTUEudj7Cx9WVmFVyxnReO0VSDXM=.fab6bbef-5218-42ef-8ab4-e0bfbc40477d@github.com>

On Tue, 2 May 2023 18:02:41 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
>> 
>> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
>> 
>> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
>> 
>> Returns:
>> the non-negative number of array elements when deserializing an array of the class, otherwise -1
>> 
>> but currently returns a negative value if the array length is negative.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using try-with-resources and some formatting changes

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13540#pullrequestreview-1416821576

From rriggs at openjdk.org  Mon May  8 13:42:22 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 May 2023 13:42:22 GMT
Subject: RFR: 8305950: Have -XshowSettings option display tzdata version
In-Reply-To: <134CrUZw5fSJ5ejfxcGwvuKDR_J160WLH4N8uurVrt8=.d43aa8ec-c8a8-4463-8dc6-b31e04c69ac6@github.com>
References: <134CrUZw5fSJ5ejfxcGwvuKDR_J160WLH4N8uurVrt8=.d43aa8ec-c8a8-4463-8dc6-b31e04c69ac6@github.com>
Message-ID: <SOgBuNqTNCC2OBb_TQca-qpWyWGpcSP_ky82okt6IL4=.fe2769f7-0007-4c68-b6d1-efa87bd1445a@github.com>

On Mon, 8 May 2023 13:14:34 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> minor enhancement to have -XshowSettings launcher option display the version of tzdata installed in the JDK
> 
> example output of the new tzdata info :
> 
> 
> ....
> Locale settings:
>     default locale = English
>     default display locale = English
>     default format locale = English
>     tzdata version = 2023c
>     available locales = , af, af_NA, af_ZA, af_ZA_#Latn, agq, agq_CM, agq_CM_#Latn,
>     ......

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13865#pullrequestreview-1416824863

From rriggs at openjdk.org  Mon May  8 13:48:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 May 2023 13:48:15 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v5]
In-Reply-To: <HOZlfhFT_NLPtVTJf0q-e7shqTT6XD1tBjotWAZIa-Q=.95e4a413-134d-465c-8f52-20fa3458ba96@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>
 <JaHJFI_N3kV-l-1lZySph5dihc1k7QE9aUksfceL-Lk=.a4f17690-c38d-4d6a-b717-2d2bf6db807b@github.com>
 <c2G-q_PVEbMZvVcmdcRPcVv-z0Q7Zj7CKs18quphVZo=.b7c8eddb-189e-4c37-b298-e45fb0959637@github.com>
 <qcXAua9MciT5NmhdT-qi8USmlBDUQU0o0hHI_d0RQW4=.349f577b-146a-4439-8b2f-bf59e6e6398e@github.com>
 <Q-naRJ6IkIze3PA9uCVkqlK-laLUsp_zelVWO5y7Sm4=.19e586b1-7939-40dd-98ae-7de7c1a080e8@github.com>
 <8roPLmDraJbd9uQ1bnmEDHeaGroNsMu9rQ9rWj8qf9I=.44bf0032-89a4-4aba-9bb1-1fa9db781ab2@github.com>
 <HOZlfhFT_NLPtVTJf0q-e7shqTT6XD1tBjotWAZIa-Q=.95e4a413-134d-465c-8f52-20fa3458ba96@github.com>
Message-ID: <6fR6-OsgcCJlJHMTWrEZoHKvG_DYdoOlCyGMUf0C1NI=.718d8b07-d5c2-4001-9d84-3844926ab811@github.com>

On Mon, 8 May 2023 12:30:45 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>>> Alternatively, one could remove the multiplication sign altogether...
>> 
>> Do you mean rewording it to something like:
>> 
>>> the array's length will be no greater than 2 times <i>limit</i> - 1
>
> I mean the usual juxtaposition in maths to signify multiplication, like in _a_ _b_ instead of _a_?_b_
> 
>> the array's length will be no greater than 2 _limit_ - 1

I would replace center-dot with either with "times" or "*" as being easier to read and more familiar in the javadoc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1187467577

From rriggs at openjdk.org  Mon May  8 13:53:24 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 May 2023 13:53:24 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v5]
In-Reply-To: <6fR6-OsgcCJlJHMTWrEZoHKvG_DYdoOlCyGMUf0C1NI=.718d8b07-d5c2-4001-9d84-3844926ab811@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>
 <JaHJFI_N3kV-l-1lZySph5dihc1k7QE9aUksfceL-Lk=.a4f17690-c38d-4d6a-b717-2d2bf6db807b@github.com>
 <c2G-q_PVEbMZvVcmdcRPcVv-z0Q7Zj7CKs18quphVZo=.b7c8eddb-189e-4c37-b298-e45fb0959637@github.com>
 <qcXAua9MciT5NmhdT-qi8USmlBDUQU0o0hHI_d0RQW4=.349f577b-146a-4439-8b2f-bf59e6e6398e@github.com>
 <Q-naRJ6IkIze3PA9uCVkqlK-laLUsp_zelVWO5y7Sm4=.19e586b1-7939-40dd-98ae-7de7c1a080e8@github.com>
 <8roPLmDraJbd9uQ1bnmEDHeaGroNsMu9rQ9rWj8qf9I=.44bf0032-89a4-4aba-9bb1-1fa9db781ab2@github.com>
 <HOZlfhFT_NLPtVTJf0q-e7shqTT6XD1tBjotWAZIa-Q=.95e4a413-134d-465c-8f52-20fa3458ba96@github.com>
 <6fR6-OsgcCJlJHMTWrEZoHKvG_DYdoOlCyGMUf0C1NI=.718d8b07-d5c2-4001-9d84-3844926ab811@github.com>
Message-ID: <shSxpn25mwVvVN2OzrbTF7ol5BLUOXRpnUy_Tu4mj0M=.1f8fd3d0-cc39-4918-8369-b43e4c104120@github.com>

On Mon, 8 May 2023 13:45:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I mean the usual juxtaposition in maths to signify multiplication, like in _a_ _b_ instead of _a_?_b_
>> 
>>> the array's length will be no greater than 2 _limit_ - 1
>
> I would replace center-dot with either with "times" or "*" as being easier to read and more familiar in the javadoc.

In java.lang.Math I see both "*" and "&times;" used to indicate multiplication.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1187472309

From rgiulietti at openjdk.org  Mon May  8 14:04:29 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 8 May 2023 14:04:29 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v5]
In-Reply-To: <shSxpn25mwVvVN2OzrbTF7ol5BLUOXRpnUy_Tu4mj0M=.1f8fd3d0-cc39-4918-8369-b43e4c104120@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <tjWx6Dqn8BF1BCGqLWYf8h_ox98Jol1y5NkO_UfacmU=.b6b8c2c4-29bc-4328-8cd1-629b76266e87@github.com>
 <JaHJFI_N3kV-l-1lZySph5dihc1k7QE9aUksfceL-Lk=.a4f17690-c38d-4d6a-b717-2d2bf6db807b@github.com>
 <c2G-q_PVEbMZvVcmdcRPcVv-z0Q7Zj7CKs18quphVZo=.b7c8eddb-189e-4c37-b298-e45fb0959637@github.com>
 <qcXAua9MciT5NmhdT-qi8USmlBDUQU0o0hHI_d0RQW4=.349f577b-146a-4439-8b2f-bf59e6e6398e@github.com>
 <Q-naRJ6IkIze3PA9uCVkqlK-laLUsp_zelVWO5y7Sm4=.19e586b1-7939-40dd-98ae-7de7c1a080e8@github.com>
 <8roPLmDraJbd9uQ1bnmEDHeaGroNsMu9rQ9rWj8qf9I=.44bf0032-89a4-4aba-9bb1-1fa9db781ab2@github.com>
 <HOZlfhFT_NLPtVTJf0q-e7shqTT6XD1tBjotWAZIa-Q=.95e4a413-134d-465c-8f52-20fa3458ba96@github.com>
 <6fR6-OsgcCJlJHMTWrEZoHKvG_DYdoOlCyGMUf0C1NI=.718d8b07-d5c2-4001-9d84-3844926ab811@github.com>
 <shSxpn25mwVvVN2OzrbTF7ol5BLUOXRpnUy_Tu4mj0M=.1f8fd3d0-cc39-4918-8369-b43e4c104120@github.com>
Message-ID: <42RufxwA08SHfVrKpMdUfyGrBnTs87JXPUPmuW8E984=.0fcbdeea-bdb5-4bd9-adb0-8b864d292666@github.com>

On Mon, 8 May 2023 13:50:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I would replace center-dot with either with "times" or "*" as being easier to read and more familiar in the javadoc.
>
> In java.lang.Math I see both "*" and "&times;" used to indicate multiplication.

Just replaced with `&times;`, as used in the javadoc of `Double.toString(double)`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13305#discussion_r1187483393

From rgiulietti at openjdk.org  Mon May  8 14:04:27 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 8 May 2023 14:04:27 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v6]
In-Reply-To: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
Message-ID: <m3KqhIm0Hy0y8sh4tzUQAET2XIsQenCBgvsjMizUccE=.8ec6bd3d-97b4-48da-bbdd-0ab98c0e347c@github.com>

> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.

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

  Replaced HTML named entity &centerdot; with &times; in Javadoc.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13305/files
  - new: https://git.openjdk.org/jdk/pull/13305/files/e7f0980b..bd84b100

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

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

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

From rriggs at openjdk.org  Mon May  8 14:08:22 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 May 2023 14:08:22 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v6]
In-Reply-To: <m3KqhIm0Hy0y8sh4tzUQAET2XIsQenCBgvsjMizUccE=.8ec6bd3d-97b4-48da-bbdd-0ab98c0e347c@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <m3KqhIm0Hy0y8sh4tzUQAET2XIsQenCBgvsjMizUccE=.8ec6bd3d-97b4-48da-bbdd-0ab98c0e347c@github.com>
Message-ID: <KX_cFurNbCNvFTz7qJ6xolj0I2Ns3ayssVV9FnABnRs=.969568be-8529-4b3a-8d49-8c5274174207@github.com>

On Mon, 8 May 2023 14:04:27 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced HTML named entity &centerdot; with &times; in Javadoc.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13305#pullrequestreview-1416875250

From forax at openjdk.org  Mon May  8 14:12:37 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 8 May 2023 14:12:37 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <GCnfBNVUPeVmqAE4WtBp8RHzhr1a2xuDfE98tqxiDGg=.331c452e-ed0d-465a-9b41-bf81c7b104d0@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bZgoi5WAcBpw0AmBqKz22efZ4PP_W1Cxp5V1G6GHrzs=.91d1d5ad-7d6c-4bae-8409-62e3dab28869@github.com>
 <GCnfBNVUPeVmqAE4WtBp8RHzhr1a2xuDfE98tqxiDGg=.331c452e-ed0d-465a-9b41-bf81c7b104d0@github.com>
Message-ID: <L9JnCeE-y5yYNTYozXkVHVTKdsgVsyiB8V09QZbxB5E=.19d0e9de-aed4-4940-a719-a42bbcd7cc1f@github.com>

On Mon, 8 May 2023 10:46:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 342:
>> 
>>> 340: 
>>> 341:             // individual handle fields
>>> 342:             clb.withField(ORIGINAL_TARGET_NAME, CD_MethodHandle, ACC_PRIVATE | ACC_FINAL);
>> 
>> Would a @Stable field help here? E.g if the returned functional interface instance is stored in a `static final` field, it should enable better performance?
>
> (actually, not sure - as the class is saved in a class value cache, so probably adding stable won't make any difference).

The class is loaded as a hidden class, so all final fields are truly final (unlike classes but like records), so @Stable is not needed.

The class value cache only change performance if the cache was used in a hot path. And currently a class value cache is not considered as a cache by the JIT, i.e. the JIT does not know that if the key is a constant, the value is a constant.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1187495168

From mcimadamore at openjdk.org  Mon May  8 14:15:26 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 May 2023 14:15:26 GMT
Subject: RFR: 8307411: Test java/foreign/channels/TestAsyncSocketChannels.java
 failed: IllegalStateException: Already closed
Message-ID: <qwKabj-rS5kyj6x6I4IBje-xScTq20c6zrcM_V5as9Y=.695987b5-2a9a-4024-b2ff-7cd720b0c14e@github.com>

This is a tricky intermittent failure on one of our async file channel test.

While the logic of the test is a bit hard to follow, I believe the test is supposed to work as follows:

* in the main thread, we submit an initial async write on a buffer
* the completion handler of the async op will submit another async write after one completes
* before/after each write we increment/decrement an atomic counter
* in the main thread waits 20 secs, to make sure the write buffers are full and that there are some async writes actually awaiting for OS to serve them
* we then try to close the test arena - this would fail as there are pending OS writes, and we keep the arena locked to prevent JVM crashes
* then the main test will set the `continueWriting` flag to false (which will cause the handler to stop submitting new write requests).
* the main thread will then read what's left (so that the buffers will empty and the OS can serve the outstanding writes)
* when there's no outstanding writes left, the main thread will close the test scope.

I think, after many hours spent staring the test that, when working as intended, the test logic is correct. Each write is only submitted after the previous one finished, and the test can only end when we see the number of outstanding write to reach 0. For this to happen, we need to execute the handler once when `continueWriting` is set to false (which will cause an asymmetric decrement of the counter from the handler, which will match the asymmetric increment outside the handler, in the main test thread).

When trying to reduce the timeout which ensures that write buffers are full, I started hitting the same exception as the one described in the bug report. After some digging, I found that the exception was **not** caused (as I thought) by some bad synchronization logic which allowed the main test to close the arena before the handlers were actually finished with it. Instead, the failure is caused by the test assertion which checks that the test arena cannot be closed:


assertMessage(expectThrows(ISE, () -> drop.close()), "Session is acquired by"); 


This check is bogus: it assumes that the buffers are indeed full, and that some OS write operation cannot progress. In that case, the underlying arena will be kept alive (as the implementation wants to avoid a JVM crash triggered by an OS write on an already freed region of memory).

But, if the buffer is not full at this stage, there is nothing keeping the test arena alive: note that the completion handler executes **after** the arena acquire/release in `IOUtils`. So, if all write operations complete normally, `drop::close` will actually succeed!

At this point it's a coint toss as to whether we'll see a message because the copletion handler tries to allocate on an already closed arena, or if we see a message complaining about `drop::close` not failing as expected.

While there are other ways to fix this, I think a simple fix is to actually remove the assertion on `drop::close`. Note that if there's a bug in the keepalive logic of the arena, the test would still fail (but with a JVM crash). And, by avoiding a spurious call to `drop::close` we make sure that the test always runs as intended whether or not the OS buffers are full.

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

Commit messages:
 - Initial push

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

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

From jpai at openjdk.org  Mon May  8 14:16:34 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 8 May 2023 14:16:34 GMT
Subject: RFR: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern [v6]
In-Reply-To: <m3KqhIm0Hy0y8sh4tzUQAET2XIsQenCBgvsjMizUccE=.8ec6bd3d-97b4-48da-bbdd-0ab98c0e347c@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
 <m3KqhIm0Hy0y8sh4tzUQAET2XIsQenCBgvsjMizUccE=.8ec6bd3d-97b4-48da-bbdd-0ab98c0e347c@github.com>
Message-ID: <s5sWWrQ09DuCKkb264-bOAVmFTPIXRJwVp8z39zfOFM=.2080ad61-3c7f-4b8b-938d-88947d962648@github.com>

On Mon, 8 May 2023 14:04:27 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced HTML named entity &centerdot; with &times; in Javadoc.

Thank you for the update Raffaello. This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13305#pullrequestreview-1416889917

From mcimadamore at openjdk.org  Mon May  8 14:23:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 May 2023 14:23:10 GMT
Subject: RFR: 8307615: Linker::nativeLinker should not be restricted
 (mainline) [v2]
In-Reply-To: <8owRB5GDdEv2aRLKJO3NHtMNoXnmCf3Pd2GfwUtO-Go=.f6234082-15f1-4f3e-ba69-22818a86e984@github.com>
References: <8owRB5GDdEv2aRLKJO3NHtMNoXnmCf3Pd2GfwUtO-Go=.f6234082-15f1-4f3e-ba69-22818a86e984@github.com>
Message-ID: <nkBBBlW7J0wMdTWGTtbNF00XOMQFkuy7-9XOMu4evKM=.16c35bc1-a22f-45f0-ab53-1b764b9d6e48@github.com>

> Port of: https://git.openjdk.org/panama-foreign/pull/831

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13863/files
  - new: https://git.openjdk.org/jdk/pull/13863/files/ff787daf..41e18900

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

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

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

From mcimadamore at openjdk.org  Mon May  8 14:23:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 May 2023 14:23:12 GMT
Subject: RFR: 8307615: Linker::nativeLinker should not be restricted
 (mainline) [v2]
In-Reply-To: <KQjJOmK2qxMVVx4l7x8mUb_wcUNR2dlGtt5Mk2pr4rw=.512cb0ad-edb0-442e-b871-9138b5ec407e@github.com>
References: <8owRB5GDdEv2aRLKJO3NHtMNoXnmCf3Pd2GfwUtO-Go=.f6234082-15f1-4f3e-ba69-22818a86e984@github.com>
 <KQjJOmK2qxMVVx4l7x8mUb_wcUNR2dlGtt5Mk2pr4rw=.512cb0ad-edb0-442e-b871-9138b5ec407e@github.com>
Message-ID: <d9nRQzNGRs10v_HXqu0JSKdqNF7sal9iy36cVHxpHeA=.c864e535-4f30-4227-aa2f-6dc3819bb9cc@github.com>

On Mon, 8 May 2023 12:17:44 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comment
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 78:
> 
>> 76:         SharedUtils.checkSymbol(symbol);
>> 77:         return downcallHandle(function, options).bindTo(symbol);
>> 78:     }
> 
> This doesn't look quite right, as `downcallHandle` is being called twice? (forgot to push?).
> 
> I suggest calling `Reflection::ensureNativeAccess` immediately in each overload, and then delegating to `downcallHandle0` which doesn't check the access.

Just a mistake on my part - fixed now

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13863#discussion_r1187503634

From rriggs at openjdk.org  Mon May  8 14:53:41 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 May 2023 14:53:41 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v4]
In-Reply-To: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
Message-ID: <cb6Od5Adh_1Y2rQ5a7FoaaMGBSB6QmpRYChzc3AKR9c=.80488616-3ad8-4e17-b7a4-a029d12741d4@github.com>

> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
> 
> Neither os.name nor os.arch should be assumed to be changeable; 
> one test case is removed because it assumes os.name can be changed on the command line.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Correct Platform.is64Bit() to report address size of the architecture enum, not the running system

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13585/files
  - new: https://git.openjdk.org/jdk/pull/13585/files/cfc404c1..db56d702

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

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

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

From rgiulietti at openjdk.org  Mon May  8 14:54:47 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 8 May 2023 14:54:47 GMT
Subject: Integrated: 8305486: Add split() variants that keep the delimiters to
 String and j.u.r.Pattern
In-Reply-To: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
References: <yCk3iIO0h55nTrA0xtUVOOAEEEkV7BApRKb36B4Lvn0=.13cc9cb9-945a-4dc9-bd38-7151cdec4a91@github.com>
Message-ID: <-i-UzEOpQCWu8Tig2eYv4it9Wc9jqzNSHGulzWxJFM8=.8a4b3cc5-480f-44ff-a6d0-35a1189fbdbd@github.com>

On Mon, 3 Apr 2023 17:43:55 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Add `split()` overloads to `String` and `java.util.regex.Pattern` that, in addition to the substrings returned by current `split()` variants, also return the delimiters matching the regular expression.

This pull request has now been integrated.

Changeset: 93ee19f5
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/93ee19f58aa8c436c2960d171ba4646a374aa2e3
Stats:     360 lines in 3 files changed: 335 ins; 1 del; 24 mod

8305486: Add split() variants that keep the delimiters to String and j.u.r.Pattern

Reviewed-by: jpai, rriggs

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

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

From simonis at openjdk.org  Mon May  8 14:59:44 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 8 May 2023 14:59:44 GMT
Subject: Integrated: 8306461: ObjectInputStream::readObject() should handle
 negative array sizes without throwing NegativeArraySizeExceptions
In-Reply-To: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
References: <oQs-Uq-VE3quqxYEEE4Ns9_i78PZ9A9rwao0LpmjVXY=.4be717d1-7d3e-4b0a-9d7e-7d491410e2b5@github.com>
Message-ID: <B8mU1uADpLy1SnkNF_TYf4W4zV8ocDtRqpZSKXGAvAU=.603b488c-6a72-4493-8c68-88ed30d842d9@github.com>

On Wed, 19 Apr 2023 16:47:33 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> This issue was reported by: Yakov Shafranovich ([yakovsh at amazon.com](mailto:yakovsh at amazon.com))
> 
> Currently, `ObjectInputStream::readObject()` doesn't explicitly checks for a negative array length in the deserialization stream. Instead it calls `j.l.r.Array::newInstance(..)` with the negative length which results in a `NegativeArraySizeException`. NegativeArraySizeException is an unchecked exception which is neither declared in the signature of `ObjectInputStream::readObject()` nor mentioned in its API specification. It is therefore not obvious for users of `ObjectInputStream::readObject()` that they may have to handle `NegativeArraySizeException`s. It would therefor be better if a negative array length in the deserialization stream would be automatically wrapped in an `InvalidClassException` which is a checked exception (derived from `IOException` via `ObjectStreamException`) and declared in the signature of `ObjectInputStream::readObject()`.
> 
> If we do the negative array length check in `ObjectInputStream::readObject()` before filtering, this will then also fix `ObjectInputFilter.FilterInfo::arrayLength()` which is defined as:
> 
> Returns:
> the non-negative number of array elements when deserializing an array of the class, otherwise -1
> 
> but currently returns a negative value if the array length is negative.

This pull request has now been integrated.

Changeset: 4116b109
Author:    Volker Simonis <simonis at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4116b109f004c9552db7448f2942a11d5dfe3cdc
Stats:     155 lines in 3 files changed: 149 ins; 0 del; 6 mod

8306461: ObjectInputStream::readObject() should handle negative array sizes without throwing NegativeArraySizeExceptions

Co-authored-by: Yakov Shafranovich <yakovsh at amazon.com>
Reviewed-by: shade, rriggs

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

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

From aefimov at openjdk.org  Mon May  8 15:15:21 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 8 May 2023 15:15:21 GMT
Subject: RFR: 8302845: Replace finalizer usage in JNDI DNS provider with
 Cleaner [v3]
In-Reply-To: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
References: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
Message-ID: <uCQ6Or1Cc7wHUbc0CxhNymPxMI2oHq7cSG876prIFLk=.5e98b9f5-c5b6-4a59-94ef-38ee1a35d544@github.com>

> JNDI `DnsClient` has a finalize method to close its internal datagram channel selector.
>  The change proposed here replaces it with a cleaner to close the selector once the `DnsClient`
>   instance becomes phantom reachable. 
> 
> The change was tested with `jdk-tier1` to `jdk-tier3` test sets which showed no failures.

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Use cleanable to close the selector in DnsClient::close

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13837/files
  - new: https://git.openjdk.org/jdk/pull/13837/files/757d242c..3a139b27

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

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

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

From aefimov at openjdk.org  Mon May  8 15:15:23 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 8 May 2023 15:15:23 GMT
Subject: RFR: 8302845: Replace finalizer usage in JNDI DNS provider with
 Cleaner [v2]
In-Reply-To: <Zb9RlVfqcV-weLLdpjbnHrtay1j_8zbGNg0_zyczdOc=.6cdafb69-fa5e-4eff-8ca2-c06486278af9@github.com>
References: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
 <yuVhZpEYsNmlLkY3tskcXQAR5B0Efa1XRBqek8-7P7A=.d8eec4d1-e7a4-4b85-b89b-39db19cf1707@github.com>
 <bIBaynnQ4JHCS9nyuCB4lwXJeSXEWUm9Yi__wNCEIOM=.bcfbef5f-2297-4fb5-aab9-b39ce9d00521@github.com>
 <Zb9RlVfqcV-weLLdpjbnHrtay1j_8zbGNg0_zyczdOc=.6cdafb69-fa5e-4eff-8ca2-c06486278af9@github.com>
Message-ID: <eP5rlgHnizhAfh202Gn80kvR1lHbuwThxuidxEQOrUA=.b6f5b26d-319e-4f17-8dc5-f8ccf369cd91@github.com>

On Sat, 6 May 2023 12:47:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/jdk.naming.dns/share/classes/com/sun/jndi/dns/DnsClient.java line 165:
>> 
>>> 163:         // when this DNS client becomes phantom reachable
>>> 164:         Selector sel = udpChannelSelector;
>>> 165:         CleanerFactory.cleaner().register(this, () -> {
>> 
>> I believe this is not quite right. The Cleanable returned by the `register` method should be saved in a final field. And close() below should call `Cleanable::clean` instead of `udpChannelSelector.close()`
>
>> I believe this is not quite right. The Cleanable returned by the `register` method should be saved in a final field. And close() below should call `Cleanable::clean` instead of `udpChannelSelector.close()`
> 
> Selector::close is idempotent so it doesn't really matter but your approach would mean the cleanable is deregistered when the API is used correctly, which is good thing.

Thanks for the comments, implemented suggestions in 3a139b272b25d52b8be9593cee3aec3f373c12ff - new final field is added to save `Cleaner.Cleanable` instance for later use in `DnsClient::close` to close the selector and deregister the cleanable action.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13837#discussion_r1187563091

From jvernee at openjdk.org  Mon May  8 15:18:30 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 8 May 2023 15:18:30 GMT
Subject: RFR: 8307615: Linker::nativeLinker should not be restricted
 (mainline) [v2]
In-Reply-To: <nkBBBlW7J0wMdTWGTtbNF00XOMQFkuy7-9XOMu4evKM=.16c35bc1-a22f-45f0-ab53-1b764b9d6e48@github.com>
References: <8owRB5GDdEv2aRLKJO3NHtMNoXnmCf3Pd2GfwUtO-Go=.f6234082-15f1-4f3e-ba69-22818a86e984@github.com>
 <nkBBBlW7J0wMdTWGTtbNF00XOMQFkuy7-9XOMu4evKM=.16c35bc1-a22f-45f0-ab53-1b764b9d6e48@github.com>
Message-ID: <kUlhoxAviXRldXZHiP1BPbl8W-t5cs5hFDbhtyfxuP8=.8e142e40-019d-4a41-b623-34ae862257ad@github.com>

On Mon, 8 May 2023 14:23:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Port of: https://git.openjdk.org/panama-foreign/pull/831
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comment

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13863#pullrequestreview-1417001836

From naoto at openjdk.org  Mon May  8 16:02:32 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 8 May 2023 16:02:32 GMT
Subject: RFR: 8307466: java.time.Instant calculation bug in until and
 between methods [v2]
In-Reply-To: <m3_pYsA5l-v4NzHlIdgM-650MYEONnA_xcQavH6-xs4=.ff1b8804-7f77-4a32-b9b2-2b194291aae1@github.com>
References: <TbOVsPh3u2tsHDgnDl6bg7DM7zDW7A0KTcM3PpMODfQ=.c27d4486-6c5d-4828-9d31-83ce21a7d26b@github.com>
 <m3_pYsA5l-v4NzHlIdgM-650MYEONnA_xcQavH6-xs4=.ff1b8804-7f77-4a32-b9b2-2b194291aae1@github.com>
Message-ID: <jwtFOye4BzVBaj1OGxIo_3bkt7T3Atj4HXSyNR6L9zg=.df3415c7-594c-43fb-bb2a-4eaff0425c7d@github.com>

On Sun, 7 May 2023 17:58:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The implementation of java.time.Instant.until(I2, ChronoUnit) in some cases did not correctly borrow or carry from the nanos to the seconds when computing using ChronoUnit.MILLIS or ChronoUnit.MICROS.
>> The errant computation was introduced by [JDK-8273369](https://bugs.openjdk.org/browse/JDK-8273369).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Slight perf improvement using int instead of long for local nanosDiff

Looks good. Thanks for fixing the regression.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13846#pullrequestreview-1417076490

From jvernee at openjdk.org  Mon May  8 16:08:35 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 8 May 2023 16:08:35 GMT
Subject: RFR: 8307411: Test
 java/foreign/channels/TestAsyncSocketChannels.java failed:
 IllegalStateException: Already closed
In-Reply-To: <qwKabj-rS5kyj6x6I4IBje-xScTq20c6zrcM_V5as9Y=.695987b5-2a9a-4024-b2ff-7cd720b0c14e@github.com>
References: <qwKabj-rS5kyj6x6I4IBje-xScTq20c6zrcM_V5as9Y=.695987b5-2a9a-4024-b2ff-7cd720b0c14e@github.com>
Message-ID: <HtZILqou2pvRfi-jeG79r8SGCSHhgDnTogyIE84aZgc=.f56874fb-3bd1-45ac-9896-5ed4e504f448@github.com>

On Mon, 8 May 2023 13:46:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a tricky intermittent failure on one of our async file channel test.
> 
> While the logic of the test is a bit hard to follow, I believe the test is supposed to work as follows:
> 
> * in the main thread, we submit an initial async write on a buffer
> * the completion handler of the async op will submit another async write after one completes
> * before/after each write we increment/decrement an atomic counter
> * in the main thread waits 20 secs, to make sure the write buffers are full and that there are some async writes actually awaiting for OS to serve them
> * we then try to close the test arena - this would fail as there are pending OS writes, and we keep the arena locked to prevent JVM crashes
> * then the main test will set the `continueWriting` flag to false (which will cause the handler to stop submitting new write requests).
> * the main thread will then read what's left (so that the buffers will empty and the OS can serve the outstanding writes)
> * when there's no outstanding writes left, the main thread will close the test scope.
> 
> I think, after many hours spent staring the test that, when working as intended, the test logic is correct. Each write is only submitted after the previous one finished, and the test can only end when we see the number of outstanding write to reach 0. For this to happen, we need to execute the handler once when `continueWriting` is set to false (which will cause an asymmetric decrement of the counter from the handler, which will match the asymmetric increment outside the handler, in the main test thread).
> 
> When trying to reduce the timeout which ensures that write buffers are full, I started hitting the same exception as the one described in the bug report. After some digging, I found that the exception was **not** caused (as I thought) by some bad synchronization logic which allowed the main test to close the arena before the handlers were actually finished with it. Instead, the failure is caused by the test assertion which checks that the test arena cannot be closed:
> 
> 
> assertMessage(expectThrows(ISE, () -> drop.close()), "Session is acquired by"); 
> 
> 
> This check is bogus: it assumes that the buffers are indeed full, and that some OS write operation cannot progress. In that case, the underlying arena will be kept alive (as the implementation wants to avoid a JVM crash triggered by an OS write on an already freed region of memory).
> 
> But, if the buffer is not full at this stage, there is nothing keeping the test arena alive: note that the completion handler executes **after** the arena acquire/release in `IOUtils`. So, if all write operations complete normally, `drop::close` will actually succeed!
> 
> At this point it's a coint toss as to whether we'll see a message because the copletion handler tries to allocate on an already closed arena, or if we see a message complaining about `drop::close` not failing as expected.
> 
> While there are other ways to fix this, I think a simple fix is to actually remove the assertion on `drop::close`. Note that if there's a bug in the keepalive logic of the arena, the test would still fail (but with a JVM crash). And, by avoiding a spurious call to `drop::close` we make sure that the test always runs as intended whether or not the OS buffers are full.

Great detective work, thanks! I think the fix is good. We already have other tests that try to detect acquire/release issue.

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13866#pullrequestreview-1417085971

From mcimadamore at openjdk.org  Mon May  8 16:21:20 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 8 May 2023 16:21:20 GMT
Subject: RFR: 8307629: FunctionDescriptor::toMethodType should allow sequence
 layouts (mainline)
Message-ID: <koQn_E0_0GarZg2x0ceqYyoeLCBzBzUkDU_RMiHNyMA=.effecbe6-eaae-45aa-92b6-2d2a295e21b2@github.com>

This is a port of: https://git.openjdk.org/panama-foreign/pull/830

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

Commit messages:
 - Initial push

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

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

From jvernee at openjdk.org  Mon May  8 16:44:18 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 8 May 2023 16:44:18 GMT
Subject: RFR: 8307629: FunctionDescriptor::toMethodType should allow
 sequence layouts (mainline)
In-Reply-To: <koQn_E0_0GarZg2x0ceqYyoeLCBzBzUkDU_RMiHNyMA=.effecbe6-eaae-45aa-92b6-2d2a295e21b2@github.com>
References: <koQn_E0_0GarZg2x0ceqYyoeLCBzBzUkDU_RMiHNyMA=.effecbe6-eaae-45aa-92b6-2d2a295e21b2@github.com>
Message-ID: <BPgANS_vSrtePJ3_LgiYgO5Yv4t2YuSxsRg-7OFr02A=.4031ad06-9d80-4353-853d-eb7e8729be0d@github.com>

On Mon, 8 May 2023 16:10:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a port of: https://git.openjdk.org/panama-foreign/pull/830

(already reviewed in the panama-foreign repo)

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

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13869#pullrequestreview-1417136947

From rriggs at openjdk.org  Mon May  8 16:51:15 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 May 2023 16:51:15 GMT
Subject: RFR: 8307466: java.time.Instant calculation bug in until and
 between methods [v2]
In-Reply-To: <m3_pYsA5l-v4NzHlIdgM-650MYEONnA_xcQavH6-xs4=.ff1b8804-7f77-4a32-b9b2-2b194291aae1@github.com>
References: <TbOVsPh3u2tsHDgnDl6bg7DM7zDW7A0KTcM3PpMODfQ=.c27d4486-6c5d-4828-9d31-83ce21a7d26b@github.com>
 <m3_pYsA5l-v4NzHlIdgM-650MYEONnA_xcQavH6-xs4=.ff1b8804-7f77-4a32-b9b2-2b194291aae1@github.com>
Message-ID: <FYVo7OYrDHPzyR7Rq59nzNXiWqfFyuOGfhmrHnV7aUE=.30772bf7-8897-45d5-8b35-f531d17c8f96@github.com>

On Sun, 7 May 2023 17:58:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The implementation of java.time.Instant.until(I2, ChronoUnit) in some cases did not correctly borrow or carry from the nanos to the seconds when computing using ChronoUnit.MILLIS or ChronoUnit.MICROS.
>> The errant computation was introduced by [JDK-8273369](https://bugs.openjdk.org/browse/JDK-8273369).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Slight perf improvement using int instead of long for local nanosDiff

Please review the CSR. [8307578](https://bugs.openjdk.org/browse/JDK-8307578)
Suggestions on a clear description are appreciated.

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

PR Comment: https://git.openjdk.org/jdk/pull/13846#issuecomment-1538714386

From psandoz at openjdk.org  Mon May  8 18:44:24 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 8 May 2023 18:44:24 GMT
Subject: RFR: JDK-8133773: clarify specification of Spliterator.tryAdvance
In-Reply-To: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
References: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
Message-ID: <IceU_prBwAnUd36A4d6yYTbgsrxyecT3p8-DL_o9rEI=.6d25e29c-be9b-4ff3-971e-9cbeb2d552ee@github.com>

On Mon, 8 May 2023 10:32:48 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Attempting to make the "at-most once" nature, of invoking the supplied action to tryAdvance, clearer in the JavaDoc.

src/java.base/share/classes/java/util/Spliterator.java line 307:

> 305:      * an exception.
> 306:      *
> 307:      * @param action The action which will be invoked at-most once

If you want to align with the language specified in `Consumer` i recommend:
Suggestion:

     * @param action The action whose operation is performed at-most once

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13860#discussion_r1187767008

From duke at openjdk.org  Mon May  8 19:07:17 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 8 May 2023 19:07:17 GMT
Subject: RFR: JDK-8133773: clarify specification of Spliterator.tryAdvance
 [v2]
In-Reply-To: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
References: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
Message-ID: <CnoxNvzRN3G-CR6kx_w0hScOKjDlUUS772Fa_vBxfxw=.fbd55c64-b6aa-4c89-b446-ac8f208c9ad7@github.com>

> Attempting to make the "at-most once" nature, of invoking the supplied action to tryAdvance, clearer in the JavaDoc.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/util/Spliterator.java
  
  Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13860/files
  - new: https://git.openjdk.org/jdk/pull/13860/files/51d5a070..50f23a91

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

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

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

From duke at openjdk.org  Mon May  8 19:07:17 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 8 May 2023 19:07:17 GMT
Subject: RFR: JDK-8133773: clarify specification of Spliterator.tryAdvance
In-Reply-To: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
References: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
Message-ID: <Dpm26g2iMxMFW93UI3M4WtbMZ84jJiy0QmxNXX-Fhtk=.015efee9-96bd-4837-a84b-8087b8863182@github.com>

On Mon, 8 May 2023 10:32:48 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Attempting to make the "at-most once" nature, of invoking the supplied action to tryAdvance, clearer in the JavaDoc.

@PaulSandoz Great suggestion, thank you Paul!

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

PR Comment: https://git.openjdk.org/jdk/pull/13860#issuecomment-1538890082

From rgiulietti at openjdk.org  Mon May  8 19:08:29 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 8 May 2023 19:08:29 GMT
Subject: RFR: 8307466: java.time.Instant calculation bug in until and
 between methods [v2]
In-Reply-To: <m3_pYsA5l-v4NzHlIdgM-650MYEONnA_xcQavH6-xs4=.ff1b8804-7f77-4a32-b9b2-2b194291aae1@github.com>
References: <TbOVsPh3u2tsHDgnDl6bg7DM7zDW7A0KTcM3PpMODfQ=.c27d4486-6c5d-4828-9d31-83ce21a7d26b@github.com>
 <m3_pYsA5l-v4NzHlIdgM-650MYEONnA_xcQavH6-xs4=.ff1b8804-7f77-4a32-b9b2-2b194291aae1@github.com>
Message-ID: <XRoeP2h8juXm-xRJOujPyTdPsb_hmDRLmieFuLdWuv0=.f1ff3730-bcac-44c8-8c2a-abc4c6ee394a@github.com>

On Sun, 7 May 2023 17:58:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The implementation of java.time.Instant.until(I2, ChronoUnit) in some cases did not correctly borrow or carry from the nanos to the seconds when computing using ChronoUnit.MILLIS or ChronoUnit.MICROS.
>> The errant computation was introduced by [JDK-8273369](https://bugs.openjdk.org/browse/JDK-8273369).
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Slight perf improvement using int instead of long for local nanosDiff

I think that the explanation of the old code failing to properly consider carries and borrows, in the "Problem" section, is quite clear.

For the record, I added a more math-oriented comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/13846#issuecomment-1538894644

From jlaskey at openjdk.org  Mon May  8 19:13:47 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 8 May 2023 19:13:47 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v66]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <q4SwaaWMYKvgNUafmFVdnuH4ZbvRWQ6sUBbiccMQ6ag=.18c6b403-544a-417b-ad05-a7901ecf97df@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Requested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/fb406d23..53f6280d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=65
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=64-65

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

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

From jlu at openjdk.org  Mon May  8 19:44:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 8 May 2023 19:44:36 GMT
Subject: RFR: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention [v7]
In-Reply-To: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
Message-ID: <7qqZaTSP8VtDTWDH8EmulPNC6VZBW1_-dQNT1eMd8D0=.23d1342d-6df9-4a8f-bfc0-a24cf700c738@github.com>

> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
> 
> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
> 
> 
> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
> - Will not case fold variant subtags
> - Will not case fold private use subtags prefixed by "lvariant"
> 
> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.

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

 - Adjust file name to match class name
 - Merge branch 'master' into JDK-8159337-Langtags-RFC5646
 - Review: SBldr should be pre allocated with input tag
 - Review: drop wwildcard import and replace subtags[i] with subtag
 - Review: Include multiple singleton extensions in test
 - Review comment: parseSts should be local
 - Review comment: Replace wellFormed with parseSts to pass errorMsg to exception
 - Review comment: Adjust method names
 - Review comment: Use assertThrows and correct IAE to ILE
 - Review comment: improve legacy_tags id
 - ... and 14 more: https://git.openjdk.org/jdk/compare/23ccc4b0...4795fb77

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13679/files
  - new: https://git.openjdk.org/jdk/pull/13679/files/96781281..4795fb77

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

  Stats: 341635 lines in 3619 files changed: 284475 ins; 34553 del; 22607 mod
  Patch: https://git.openjdk.org/jdk/pull/13679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13679/head:pull/13679

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

From jiangli at openjdk.org  Mon May  8 19:48:23 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 8 May 2023 19:48:23 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v7]
In-Reply-To: <2BVvV9m8bI-UzZXpX1GEPwoStZ6pHZBn4JuAMRQk978=.54246fe4-57b8-4372-bfc4-6b63823fa9a2@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com>
 <rIFR8lzb8zKI5f0h_VcaherfoEEtQqeX2C0UyApAqeE=.bb53bbe4-4bf6-4c22-9bff-a2b357397cce@github.com>
 <2BVvV9m8bI-UzZXpX1GEPwoStZ6pHZBn4JuAMRQk978=.54246fe4-57b8-4372-bfc4-6b63823fa9a2@github.com>
Message-ID: <oZE6EqxKgAW5zxITQm0PnmwSkSO14W48jyqLHM6Wz_I=.24e187c0-d4bb-4d1c-aebe-2e2c6328397e@github.com>

On Mon, 8 May 2023 08:57:37 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > All of that said, I think we can get away with a smaller subset of targets and deliverables. AFAIK, graal needs the combined `graal-builder-image` as input to their build anyway, so they should not have any dependency on what the target `static-libs-image` produces. Given that I propose the following behavior:
> > `make static-libs-image` produces `images/static-libs` with all .a (including libjvm.a). `make static-libs-graal-image` produces `images/static-libs-graal` with all .a except libjvm.a. `make graal-builder-image` produces `images/graal-builder-image` like today, but depends on and uses `static-libs-graal-image` instead of `static-libs-image`. `make static-libs-bundles` depends on and uses `static-libs-image` like today, so will contain libjvm.a, which is new behavior.
> 
> Sure, that should work too as long as there is a way to a) build the static libs only needed for graal some way b) keep `graal-builder-image` working as it does today. FWIW, we use `a)` at adoptium so as to be able to have a combination to build mandrel from. Not all users will want to have JDK + static libs so only the ones needing them should need to download them.

Thanks @erikj79 @jerboaa. We can go with what @erikj79 suggested then. I'll revise the PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1538945606

From rriggs at openjdk.org  Mon May  8 20:10:17 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 May 2023 20:10:17 GMT
Subject: RFR: 8307466: java.time.Instant calculation bug in until and
 between methods [v2]
In-Reply-To: <XRoeP2h8juXm-xRJOujPyTdPsb_hmDRLmieFuLdWuv0=.f1ff3730-bcac-44c8-8c2a-abc4c6ee394a@github.com>
References: <TbOVsPh3u2tsHDgnDl6bg7DM7zDW7A0KTcM3PpMODfQ=.c27d4486-6c5d-4828-9d31-83ce21a7d26b@github.com>
 <m3_pYsA5l-v4NzHlIdgM-650MYEONnA_xcQavH6-xs4=.ff1b8804-7f77-4a32-b9b2-2b194291aae1@github.com>
 <XRoeP2h8juXm-xRJOujPyTdPsb_hmDRLmieFuLdWuv0=.f1ff3730-bcac-44c8-8c2a-abc4c6ee394a@github.com>
Message-ID: <UH_3BiSr_gZrKm6ZcNLsfAxlPFTcpDyY8a9_HfaXMNM=.988b769e-3360-47e5-afd4-58662e657e87@github.com>

On Mon, 8 May 2023 19:05:43 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Slight perf improvement using int instead of long for local nanosDiff
>
> I think that the explanation of the old code failing to properly consider carries and borrows, in the "Problem" section, is quite clear.
> 
> For the record, I added a more math-oriented comment.

@rgiulietti Thank you for the detailed math-oriented explanation.

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

PR Comment: https://git.openjdk.org/jdk/pull/13846#issuecomment-1538977506

From psandoz at openjdk.org  Mon May  8 20:33:36 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 8 May 2023 20:33:36 GMT
Subject: RFR: JDK-8133773: clarify specification of Spliterator.tryAdvance
 [v2]
In-Reply-To: <CnoxNvzRN3G-CR6kx_w0hScOKjDlUUS772Fa_vBxfxw=.fbd55c64-b6aa-4c89-b446-ac8f208c9ad7@github.com>
References: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
 <CnoxNvzRN3G-CR6kx_w0hScOKjDlUUS772Fa_vBxfxw=.fbd55c64-b6aa-4c89-b446-ac8f208c9ad7@github.com>
Message-ID: <kwgYcnlS23L1cpbI46OfOPnJ4_XB-_3XsXfJTFGQva0=.44d02bb2-6dfc-4c5c-b7c2-60221b7fceb9@github.com>

On Mon, 8 May 2023 19:07:17 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Attempting to make the "at-most once" nature, of invoking the supplied action to tryAdvance, clearer in the JavaDoc.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/Spliterator.java
>   
>   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13860#pullrequestreview-1417469922

From tvaleev at openjdk.org  Mon May  8 20:57:21 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Mon, 8 May 2023 20:57:21 GMT
Subject: RFR: JDK-8133773: clarify specification of Spliterator.tryAdvance
 [v2]
In-Reply-To: <CnoxNvzRN3G-CR6kx_w0hScOKjDlUUS772Fa_vBxfxw=.fbd55c64-b6aa-4c89-b446-ac8f208c9ad7@github.com>
References: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
 <CnoxNvzRN3G-CR6kx_w0hScOKjDlUUS772Fa_vBxfxw=.fbd55c64-b6aa-4c89-b446-ac8f208c9ad7@github.com>
Message-ID: <7ubyZAnlM9WLy4XXrj23iIIn7oc7hXw4Gsgc_mN4NXw=.a788e637-077b-43ae-a39a-3e81a04785ab@github.com>

On Mon, 8 May 2023 19:07:17 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Attempting to make the "at-most once" nature, of invoking the supplied action to tryAdvance, clearer in the JavaDoc.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/Spliterator.java
>   
>   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

Marked as reviewed by tvaleev (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/13860#pullrequestreview-1417501296

From jiangli at openjdk.org  Mon May  8 21:00:24 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 8 May 2023 21:00:24 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v7]
In-Reply-To: <rIFR8lzb8zKI5f0h_VcaherfoEEtQqeX2C0UyApAqeE=.bb53bbe4-4bf6-4c22-9bff-a2b357397cce@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com>
 <rIFR8lzb8zKI5f0h_VcaherfoEEtQqeX2C0UyApAqeE=.bb53bbe4-4bf6-4c22-9bff-a2b357397cce@github.com>
Message-ID: <0wRYu-_MAO2LH1Xgl-icgILa9rL6PnDEsZv4sjCpY6c=.54e81c63-ccd8-43ad-88cf-e16ba0452cdd@github.com>

On Fri, 5 May 2023 20:43:41 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> Further I would like to suggest that libjvm.a gets put in the variant subdir under lib, just like libjvm.so does today (e.g. `lib/server/libjvm.a`). That way you can support building libjvm.a for all variants without worry. It will also get libjvm.a out of the way to cause less trouble for a graal build that uses the static-libs-bundles as input. This goes against what I suggested before, to just use `JVM_VARIANT_MAIN`, but I think this makes for a cleaner long term solution given the goals of the hermetic java effort.

There are some complications related to `jvm.cfg` and `libjvm.so` path runtime handling for JVM variants support, with the JDK traditional/dynamic build. With JDK static support, the usage of `libjvm` is fully determined at build time, runtime can avoid the complications and associated overhead with accessing `jvm.cfg` and determining `libjvm` path. 

At the final static image build time users need to know the sub-directory containing `libjvm.a`, if we go with the suggestion. That adds a small complication. However, from broader point of view there are probably more benefits to do so. I'll change the PR, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1539037862

From rriggs at openjdk.org  Mon May  8 21:03:14 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 8 May 2023 21:03:14 GMT
Subject: RFR: JDK-8133773: clarify specification of Spliterator.tryAdvance
 [v2]
In-Reply-To: <CnoxNvzRN3G-CR6kx_w0hScOKjDlUUS772Fa_vBxfxw=.fbd55c64-b6aa-4c89-b446-ac8f208c9ad7@github.com>
References: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
 <CnoxNvzRN3G-CR6kx_w0hScOKjDlUUS772Fa_vBxfxw=.fbd55c64-b6aa-4c89-b446-ac8f208c9ad7@github.com>
Message-ID: <bK0Y-_VeE59jdT2DXnPAQjQ2auUc2VaI0N6BOVd3fzI=.5ca2560e-0067-457a-8c4f-72ffec253ae8@github.com>

On Mon, 8 May 2023 19:07:17 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Attempting to make the "at-most once" nature, of invoking the supplied action to tryAdvance, clearer in the JavaDoc.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/Spliterator.java
>   
>   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

src/java.base/share/classes/java/util/Spliterator.java line 298:

> 296: public interface Spliterator<T> {
> 297:     /**
> 298:      * If a remaining element exists: performs the given action on it,

I'm not sure the ":" is an improvement on the ",". 
"If the remaining element exists, the action is performed on it, ..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13860#discussion_r1187894350

From smarks at openjdk.org  Mon May  8 23:21:23 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 8 May 2023 23:21:23 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
References: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
Message-ID: <J6h5fEgnQHwFX8gY1sqdCZvL1ppTrlCJaLK9PqjE-v8=.42636102-31f1-4aed-9386-94213392c880@github.com>

On Fri, 7 Apr 2023 12:22:03 GMT, Andy-Tatman <duke at openjdk.org> wrote:

> See https://bugs.java.com/bugdatabase/view_bug?bug_id=8305734

Further notes on `size()`. See this comment in [JDK-4213570](https://bugs.openjdk.org/browse/JDK-4213570?focusedCommentId=12238736&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12238736). The size() method was introduced with BitSet itself in JDK 1.0. It was probably an error, as in those days people might not have understood the importance of APIs separate from implementation. In addition, as noted previously, size() has a bunch of bugs. The comment suggests that the length() method was introduced as a replacement for size(). The length() method has its own bugs, but it's clearly an attempt to provide a better abstraction than size(). Also note that the specification for length() describes it as the "logical size."

Maybe this means that size() should be deprecated. At least, it might mean that we have more of a free hand to remove some of its obvious misbehavior, such as what's described in [JDK-8230557](https://bugs.openjdk.org/browse/JDK-8230557?focusedCommentId=14573956&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14573956).

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

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1539184723

From lmesnik at openjdk.org  Mon May  8 23:23:20 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Mon, 8 May 2023 23:23:20 GMT
Subject: RFR: 8307486: ProcessTools.java should wait until vthread is completed
 before checking exceptions
Message-ID: <F1xGFZns8GNttaWm3g6ADThWvwxZmOqvkk34Zo44hEc=.2b3fd000-3c7c-4a4c-9f04-2341fcd6d68b@github.com>

Updated processtools to check exception after join().

Tested with running CI virtual thread tests.

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

Commit messages:
 - 8307486: ProcessTools.java should wait until vthread is completed before checking exceptions

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

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

From smarks at openjdk.org  Tue May  9 00:15:16 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 9 May 2023 00:15:16 GMT
Subject: RFR: 8305734: BitSet.get(int,
 int) always returns the empty BitSet when the Integer.MAX VALUE is set
In-Reply-To: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
References: <r6FXfPbcMJR2bDlx6Al2rWdZkPBAfARx_FHXCt_tKfc=.79b978b0-9486-4839-a035-34f5ad4fd749@github.com>
Message-ID: <zqkT-bX79jlAsnCzhYTl2HqY-uFMwXqEyihxSv1VQro=.3ed11ca4-5d64-4d94-bd6d-d48d5014f6e5@github.com>

On Fri, 7 Apr 2023 12:22:03 GMT, Andy-Tatman <duke at openjdk.org> wrote:

> See https://bugs.java.com/bugdatabase/view_bug?bug_id=8305734

Re disallowing bit Integer.MAX_VALUE: I have a feeling we can do better than this.

The first paragraph of the spec states: "The bits of a BitSet are indexed by nonnegative integers." That is, valid indexes are in the range 0 to Integer.MAX_VALUE, inclusive. There are clearly some issues when bits at or near MAX_VALUE are set, but certain operations work perfectly fine. For example, setting and getting individual bits works for the full range, and printing or streaming the BitSet works fine. Other APIs such as cardinality() and length() mostly work, except when they need to represent exactly 2^31; in those cases they return Integer.MIN_VALUE because of wraparound. However, they work if the return value is interpreted as an _unsigned_ int. A sufficiently careful program can work with these values effectively by using some rudimentary unsigned support methods such as Integer.toUnsignedLong().

Some fixes in fairly recent times (JDK 9) were made to improve the behavior here. See [JDK-8076442](https://bugs.openjdk.org/browse/JDK-8076442).

The API methods that take ranges such as clear(), flip(), get(), and set() are deficient in that they can't operate on the full range of bits. That doesn't imply that the Integer.MAX_VALUE bit should be disallowed. We could accept their limitations; or we allow a special case values for the range that includes Integer.MIN_VALUE (effectively treating them as unsigned values); or we add long-based APIs for these and other methods that encounter problems with Integer.MAX_VALUE. This can quickly reach the point of diminishing returns, but it seems like there are some reasonable possibilities in this space.

> Problem:
BitSet.length() returns a negative value when Integer.MAX_VALUE is set, such as by using the set(int) method or by passing large arrays to a BitSet constructor.
This also causes the get(fromIndex, toIndex) method to always return the empty BitSet when passed with valid parameters, regardless of the value of fromIndex and toIndex.

This isn't correct. When length() returns Integer.MIN_VALUE, this doesn't _necessarily_ cause get(from, to) to always return an empty BitSet. Well, it does in the current implementation, but that's simply a bug that can be fixed. The implementation of the get() method can access the internal data of the object and do the right thing, regardless of what the length() method does. That change should probably be made, regardless of other spec changes we've been discussing.

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

PR Comment: https://git.openjdk.org/jdk/pull/13388#issuecomment-1539218598

From dholmes at openjdk.org  Tue May  9 02:29:23 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 May 2023 02:29:23 GMT
Subject: RFR: 8307483: New micros for j.u.c.LockSupport
In-Reply-To: <CGrg719xG5p69oMVCGiPV4eua0cU7_GnvVIwIYAyGu4=.a944b674-93b0-4865-9220-d2a774088a8f@github.com>
References: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
 <MPCS9xNA6fkUt-z01pnXcd4cpXYzsTFH9LAmM4tFm8w=.a54f610c-1095-4b18-bb45-36562881d5d1@github.com>
 <FVilKBI3w8Ok8vMoW5uvKxotCrN64xhPEz7a7sSsj7M=.352c508a-a5e8-45c1-bfb5-80c5c6c44dbf@github.com>
 <zW1LM8BfJzQLB3M6oR68tfDrXcwITzzeVUz2RMvuKXw=.78079063-fa08-4a79-9a75-eb09eaf5903f@github.com>
 <CGrg719xG5p69oMVCGiPV4eua0cU7_GnvVIwIYAyGu4=.a944b674-93b0-4865-9220-d2a774088a8f@github.com>
Message-ID: <F6WEtkDwIwtviOmhGvf5p3xF81dbROR7Q6SsjnaxvLk=.ca325b20-d176-4360-8d87-d8d739bfd7ca@github.com>

On Mon, 8 May 2023 10:01:49 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Same as we saw with `isAlive` before: `LockSupport.park` implicitly provides a compiler barrier. This `done` should be at least "opaque" to carry the same effect.
>
> Yes, `park()` and `unpark()` having release and acquire semantics is not documented [here](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/concurrent/locks/LockSupport.html#park()), and the documentation for `LockSupport` explicitly says "Reliable usage requires the use of volatile (or atomic) variables to control when to park or unpark. Orderings of calls to these methods are maintained with respect to volatile variable accesses, but not necessarily non-volatile variable accesses."

Irrespective of park/unpark barriers, the JIT should have hoisted `done` and rewritten as:

if (!done) {
  while(true) {
    ...
  }
}

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1188051993

From dholmes at openjdk.org  Tue May  9 02:29:23 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 9 May 2023 02:29:23 GMT
Subject: RFR: 8307483: New micros for j.u.c.LockSupport
In-Reply-To: <F6WEtkDwIwtviOmhGvf5p3xF81dbROR7Q6SsjnaxvLk=.ca325b20-d176-4360-8d87-d8d739bfd7ca@github.com>
References: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
 <MPCS9xNA6fkUt-z01pnXcd4cpXYzsTFH9LAmM4tFm8w=.a54f610c-1095-4b18-bb45-36562881d5d1@github.com>
 <FVilKBI3w8Ok8vMoW5uvKxotCrN64xhPEz7a7sSsj7M=.352c508a-a5e8-45c1-bfb5-80c5c6c44dbf@github.com>
 <zW1LM8BfJzQLB3M6oR68tfDrXcwITzzeVUz2RMvuKXw=.78079063-fa08-4a79-9a75-eb09eaf5903f@github.com>
 <CGrg719xG5p69oMVCGiPV4eua0cU7_GnvVIwIYAyGu4=.a944b674-93b0-4865-9220-d2a774088a8f@github.com>
 <F6WEtkDwIwtviOmhGvf5p3xF81dbROR7Q6SsjnaxvLk=.ca325b20-d176-4360-8d87-d8d739bfd7ca@github.com>
Message-ID: <WT2xCIN-TWYCjGJtqcjXnCIOAHRKTkAicXJTXpGimk4=.1498eafa-ffe7-4c1f-8798-a0c1c24d4c4b@github.com>

On Tue, 9 May 2023 02:23:51 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Yes, `park()` and `unpark()` having release and acquire semantics is not documented [here](https://docs.oracle.com/en/java/javase/20/docs/api/java.base/java/util/concurrent/locks/LockSupport.html#park()), and the documentation for `LockSupport` explicitly says "Reliable usage requires the use of volatile (or atomic) variables to control when to park or unpark. Orderings of calls to these methods are maintained with respect to volatile variable accesses, but not necessarily non-volatile variable accesses."
>
> Irrespective of park/unpark barriers, the JIT should have hoisted `done` and rewritten as:
> 
> if (!done) {
>   while(true) {
>     ...
>   }
> }

Well I guess the park/unpark barriers prevented that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1188053179

From liach at openjdk.org  Tue May  9 04:17:28 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 04:17:28 GMT
Subject: RFR: 8294977: Convert test/jdk/java tests from ASM library to
 Classfile API [v8]
In-Reply-To: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
References: <ZNm0kG5HiHCfixYeCz0EGjsT7ejmvPsXxN36-vAwQsU=.3eec9170-96da-444e-ad10-0095597b4fef@github.com>
Message-ID: <gotPxtkGGDqNkx5908vAQvuXufrubBUh6sxYK-CKgbI=.82b77e30-f114-418c-9ab6-4ea0d33eafc0@github.com>

> Summaries:
> 1. A few recommendations about updating the constant API is made at https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000233.html and I may update this patch shall the API changes be integrated before
> 2. One ASM library-specific test, `LambdaAsm` is removed. Others have their code generation infrastructure upgraded from ASM to Classfile API.
> 3. Most tests are included in tier1, but some are not:
> In `:jdk_io`: (tier2, part 2)
> 
> test/jdk/java/io/Serializable/records/SerialPersistentFieldsTest.java
> test/jdk/java/io/Serializable/records/ProhibitedMethods.java
> test/jdk/java/io/Serializable/records/BadCanonicalCtrTest.java
> 
> In `:jdk_instrument`: (tier 3)
> 
> test/jdk/java/lang/instrument/RetransformAgent.java
> test/jdk/java/lang/instrument/NativeMethodPrefixAgent.java
> test/jdk/java/lang/instrument/asmlib/Instrumentor.java
> 
> 
> @asotona Would you mind reviewing?

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

 - Merge branch 'master' into invoke-test-classfile
 - Switch to ConstantDescs for <init> <clinit> and void constants
 - Merge AnnotationsTest, remove ModuleTargetAttribute call
 - Merge branch 'invoke-test-classfile' of https://github.com/liachmodded/jdk into invoke-test-classfile
 - Update test/jdk/java/lang/invoke/8022701/MHIllegalAccess.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Merge branch 'master' into invoke-test-classfile
 - Fix LambdaStackTrace after running
 - formatting
 - Fix failed LambdaStackTrace test, use more convenient APIs
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into invoke-test-classfile
 - ... and 2 more: https://git.openjdk.org/jdk/compare/d9052b94...5db1e957

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

Changes: https://git.openjdk.org/jdk/pull/13009/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13009&range=07
  Stats: 1947 lines in 31 files changed: 302 ins; 890 del; 755 mod
  Patch: https://git.openjdk.org/jdk/pull/13009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13009/head:pull/13009

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

From coffeys at openjdk.org  Tue May  9 06:09:30 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 9 May 2023 06:09:30 GMT
Subject: Integrated: 8305950: Have -XshowSettings option display tzdata version
In-Reply-To: <134CrUZw5fSJ5ejfxcGwvuKDR_J160WLH4N8uurVrt8=.d43aa8ec-c8a8-4463-8dc6-b31e04c69ac6@github.com>
References: <134CrUZw5fSJ5ejfxcGwvuKDR_J160WLH4N8uurVrt8=.d43aa8ec-c8a8-4463-8dc6-b31e04c69ac6@github.com>
Message-ID: <jpVsQXDRqi3ztvu2lm874tRQrS67G4w2DEO6kYBnIbk=.599c757a-ad29-4709-890b-7a13bff246c8@github.com>

On Mon, 8 May 2023 13:14:34 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> minor enhancement to have -XshowSettings launcher option display the version of tzdata installed in the JDK
> 
> example output of the new tzdata info :
> 
> 
> ....
> Locale settings:
>     default locale = English
>     default display locale = English
>     default format locale = English
>     tzdata version = 2023c
>     available locales = , af, af_NA, af_ZA, af_ZA_#Latn, agq, agq_CM, agq_CM_#Latn,
>     ......

This pull request has now been integrated.

Changeset: 07f55c5e
Author:    Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/07f55c5ea280032b72247049223f676424aa44c0
Stats:     9 lines in 2 files changed: 6 ins; 0 del; 3 mod

8305950: Have -XshowSettings option display tzdata version

Reviewed-by: rriggs

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

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

From mchung at openjdk.org  Tue May  9 09:06:32 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 9 May 2023 09:06:32 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v4]
In-Reply-To: <cb6Od5Adh_1Y2rQ5a7FoaaMGBSB6QmpRYChzc3AKR9c=.80488616-3ad8-4e17-b7a4-a029d12741d4@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
 <cb6Od5Adh_1Y2rQ5a7FoaaMGBSB6QmpRYChzc3AKR9c=.80488616-3ad8-4e17-b7a4-a029d12741d4@github.com>
Message-ID: <JRd_wRsOOp3RDAomFj3VMfqvl9lVflQSZ0q8avdGRgc=.8c1113ac-d89b-412a-b06d-abc97fe5ce59@github.com>

On Mon, 8 May 2023 14:53:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
>> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
>> 
>> Neither os.name nor os.arch should be assumed to be changeable; 
>> one test case is removed because it assumes os.name can be changed on the command line.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct Platform.is64Bit() to report address size of the architecture enum, not the running system

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 65:

> 63:      */
> 64:     public boolean is64Bit() {
> 65:         return arch != Architecture.X86;

Have you considered having an instance `Architecture::is64bit` method in lieu of the current static method?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1188348420

From liach at openjdk.org  Tue May  9 09:17:44 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 09:17:44 GMT
Subject: Integrated: 8304031: Classfile API cannot encode Primitive Class as
 Condy
In-Reply-To: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com>
References: <6SEB6ZAh2b0ayMCo5EfvOW-adtsAysbf1Zk6qBbh2SI=.96417080-f2a8-424d-9a26-0ed68f6b33ac@github.com>
Message-ID: <kjHg9O45lDfxh27OO_XhtiEbZF0W3sHFFs1zE-19l8E=.07b3f98d-2369-4f52-a2bc-b2a0f75721da@github.com>

On Mon, 13 Mar 2023 08:13:44 GMT, Chen Liang <liach at openjdk.org> wrote:

> Without this patch, the Classfile API tries to encode PrimitiveClassDesc as CONSTANT_Class_info and error in `toInternalName`.

This pull request has now been integrated.

Changeset: cd5d0ff5
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd5d0ff5b29065222ffafbc4fb04b90f6f8909e2
Stats:     86 lines in 3 files changed: 84 ins; 0 del; 2 mod

8304031: Classfile API cannot encode Primitive Class as Condy

Reviewed-by: asotona

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

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

From duke at openjdk.org  Tue May  9 09:24:24 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 9 May 2023 09:24:24 GMT
Subject: RFR: JDK-8133773: clarify specification of Spliterator.tryAdvance
 [v2]
In-Reply-To: <bK0Y-_VeE59jdT2DXnPAQjQ2auUc2VaI0N6BOVd3fzI=.5ca2560e-0067-457a-8c4f-72ffec253ae8@github.com>
References: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
 <CnoxNvzRN3G-CR6kx_w0hScOKjDlUUS772Fa_vBxfxw=.fbd55c64-b6aa-4c89-b446-ac8f208c9ad7@github.com>
 <bK0Y-_VeE59jdT2DXnPAQjQ2auUc2VaI0N6BOVd3fzI=.5ca2560e-0067-457a-8c4f-72ffec253ae8@github.com>
Message-ID: <HSIutuu-YPkq8rAP5oT2bRzAMjlGGzNqcYT9y-CGhco=.b150fb92-a127-4887-9bfe-734a971b9602@github.com>

On Mon, 8 May 2023 21:00:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/java/util/Spliterator.java
>>   
>>   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
>
> src/java.base/share/classes/java/util/Spliterator.java line 298:
> 
>> 296: public interface Spliterator<T> {
>> 297:     /**
>> 298:      * If a remaining element exists: performs the given action on it,
> 
> I'm not sure the ":" is an improvement on the ",". 
> "If the remaining element exists, the action is performed on it, ..."

@RogerRiggs "the" instead of "a" gives me the impression that the Spliterator only has a single element left. The choice of colon instead of a comma is because "If a remaining element exists" introduces a list of 2 elements (and introducing a list is a good place for a colon) whereas the "else returns {@code false}" is a closely connected sentence to the topic of the list, which seems like a place to use the semi-colon.

But, not being a native English-speaker, I will happily change it to something which is more correct. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13860#discussion_r1188369217

From asotona at openjdk.org  Tue May  9 11:11:36 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 May 2023 11:11:36 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v13]
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <gdah40nU6KNFj_d-TWtzmnP7csD1-nne7gHh_iepn5I=.65dde8c4-bd01-43ae-ab36-fc026dc7cf20@github.com>

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

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

 - fixed StackCounter
 - Merge branch 'master' into JDK-8305990-debug-info-strip-fail
 - implemented failover stackmap generation for class version 50
   fixed StackMapGenerator error debug print + added clone constructor to SplitConstantPool
   adjusted and extended related tests
 - Apply suggestions from code review
   
   Thanks for review.
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Merge branch 'master' into JDK-8305990-debug-info-strip-fail
 - Update StackCounter.java
 - added comments to StackCounter about maxStack upper bounds calculation for JSR/RET instructions
 - fixed stack counting of JSR instructions
 - implemented StackCounter
 - Making some BufWriter fields final
 - ... and 6 more: https://git.openjdk.org/jdk/compare/e6c0bde0...5db0ed01

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13478/files
  - new: https://git.openjdk.org/jdk/pull/13478/files/795314a2..5db0ed01

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=11-12

  Stats: 24213 lines in 591 files changed: 18405 ins; 2515 del; 3293 mod
  Patch: https://git.openjdk.org/jdk/pull/13478.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13478/head:pull/13478

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

From mcimadamore at openjdk.org  Tue May  9 11:12:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 9 May 2023 11:12:33 GMT
Subject: Integrated: 8307629: FunctionDescriptor::toMethodType should allow
 sequence layouts (mainline)
In-Reply-To: <koQn_E0_0GarZg2x0ceqYyoeLCBzBzUkDU_RMiHNyMA=.effecbe6-eaae-45aa-92b6-2d2a295e21b2@github.com>
References: <koQn_E0_0GarZg2x0ceqYyoeLCBzBzUkDU_RMiHNyMA=.effecbe6-eaae-45aa-92b6-2d2a295e21b2@github.com>
Message-ID: <tpjk0RXb_fUuh1Hn1Yqpzsev_rotZoYmdovrgH85SrI=.9a7a3fe1-c779-4e9d-b9c9-af32bc37a927@github.com>

On Mon, 8 May 2023 16:10:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a port of: https://git.openjdk.org/panama-foreign/pull/830

This pull request has now been integrated.

Changeset: 7a3bea1f
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7a3bea1f6a7eaaf4c1e701f7a06226812aaa6ead
Stats:     75 lines in 5 files changed: 54 ins; 10 del; 11 mod

8307629: FunctionDescriptor::toMethodType should allow sequence layouts (mainline)

Reviewed-by: jvernee

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

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

From mcimadamore at openjdk.org  Tue May  9 11:14:32 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 9 May 2023 11:14:32 GMT
Subject: Integrated: 8307411: Test
 java/foreign/channels/TestAsyncSocketChannels.java failed:
 IllegalStateException: Already closed
In-Reply-To: <qwKabj-rS5kyj6x6I4IBje-xScTq20c6zrcM_V5as9Y=.695987b5-2a9a-4024-b2ff-7cd720b0c14e@github.com>
References: <qwKabj-rS5kyj6x6I4IBje-xScTq20c6zrcM_V5as9Y=.695987b5-2a9a-4024-b2ff-7cd720b0c14e@github.com>
Message-ID: <V0cNaiiiWncLfDCdV6bDyugzpupcRhFj5zzZHEk8CAE=.db3f5c57-ffc1-4653-b90f-de2f5ead4775@github.com>

On Mon, 8 May 2023 13:46:55 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a tricky intermittent failure on one of our async file channel test.
> 
> While the logic of the test is a bit hard to follow, I believe the test is supposed to work as follows:
> 
> * in the main thread, we submit an initial async write on a buffer
> * the completion handler of the async op will submit another async write after one completes
> * before/after each write we increment/decrement an atomic counter
> * in the main thread waits 20 secs, to make sure the write buffers are full and that there are some async writes actually awaiting for OS to serve them
> * we then try to close the test arena - this would fail as there are pending OS writes, and we keep the arena locked to prevent JVM crashes
> * then the main test will set the `continueWriting` flag to false (which will cause the handler to stop submitting new write requests).
> * the main thread will then read what's left (so that the buffers will empty and the OS can serve the outstanding writes)
> * when there's no outstanding writes left, the main thread will close the test scope.
> 
> I think, after many hours spent staring the test that, when working as intended, the test logic is correct. Each write is only submitted after the previous one finished, and the test can only end when we see the number of outstanding write to reach 0. For this to happen, we need to execute the handler once when `continueWriting` is set to false (which will cause an asymmetric decrement of the counter from the handler, which will match the asymmetric increment outside the handler, in the main test thread).
> 
> When trying to reduce the timeout which ensures that write buffers are full, I started hitting the same exception as the one described in the bug report. After some digging, I found that the exception was **not** caused (as I thought) by some bad synchronization logic which allowed the main test to close the arena before the handlers were actually finished with it. Instead, the failure is caused by the test assertion which checks that the test arena cannot be closed:
> 
> 
> assertMessage(expectThrows(ISE, () -> drop.close()), "Session is acquired by"); 
> 
> 
> This check is bogus: it assumes that the buffers are indeed full, and that some OS write operation cannot progress. In that case, the underlying arena will be kept alive (as the implementation wants to avoid a JVM crash triggered by an OS write on an already freed region of memory).
> 
> But, if the buffer is not full at this stage, there is nothing keeping the test arena alive: note that the completion handler executes **after** the arena acquire/release in `IOUtils`. So, if all write operations complete normally, `drop::close` will actually succeed!
> 
> At this point it's a coint toss as to whether we'll see a message because the copletion handler tries to allocate on an already closed arena, or if we see a message complaining about `drop::close` not failing as expected.
> 
> While there are other ways to fix this, I think a simple fix is to actually remove the assertion on `drop::close`. Note that if there's a bug in the keepalive logic of the arena, the test would still fail (but with a JVM crash). And, by avoiding a spurious call to `drop::close` we make sure that the test always runs as intended whether or not the OS buffers are full.

This pull request has now been integrated.

Changeset: f92d095e
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f92d095e164bd79b452586e49e166d1ba392632f
Stats:     2 lines in 1 file changed: 0 ins; 2 del; 0 mod

8307411: Test java/foreign/channels/TestAsyncSocketChannels.java failed: IllegalStateException: Already closed

Reviewed-by: jvernee

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

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

From duke at openjdk.org  Tue May  9 11:19:21 2023
From: duke at openjdk.org (Glavo)
Date: Tue, 9 May 2023 11:19:21 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v4]
In-Reply-To: <cb6Od5Adh_1Y2rQ5a7FoaaMGBSB6QmpRYChzc3AKR9c=.80488616-3ad8-4e17-b7a4-a029d12741d4@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
 <cb6Od5Adh_1Y2rQ5a7FoaaMGBSB6QmpRYChzc3AKR9c=.80488616-3ad8-4e17-b7a4-a029d12741d4@github.com>
Message-ID: <dIt4wAsqcZL3yqtGtqPKjtrLGtHZHTiaO2rXrON2bJQ=.5ac838c5-ca6f-453a-9e13-cc18830b5709@github.com>

On Mon, 8 May 2023 14:53:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
>> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
>> 
>> Neither os.name nor os.arch should be assumed to be changeable; 
>> one test case is removed because it assumes os.name can be changed on the command line.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct Platform.is64Bit() to report address size of the architecture enum, not the running system

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 65:

> 63:      */
> 64:     public boolean is64Bit() {
> 65:         return arch != Architecture.X86;

This change causes incorrect results to be returned on Linux ARM32.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1188504929

From mcimadamore at openjdk.org  Tue May  9 11:49:26 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 9 May 2023 11:49:26 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v13]
In-Reply-To: <gdah40nU6KNFj_d-TWtzmnP7csD1-nne7gHh_iepn5I=.65dde8c4-bd01-43ae-ab36-fc026dc7cf20@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <gdah40nU6KNFj_d-TWtzmnP7csD1-nne7gHh_iepn5I=.65dde8c4-bd01-43ae-ab36-fc026dc7cf20@github.com>
Message-ID: <Vtt4c8nCN40vtDRHm1JiJafunr8WCySIx70BrAmcUsQ=.b53af111-7f31-425f-aeeb-add96ef4ec13@github.com>

On Tue, 9 May 2023 11:11:36 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API didn't handle transformations of class files version 50 and below correctly. 
>> 
>> Proposed fix have two parts: 
>> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
>> 2. StackMapTable attribute is not generated for class file versions below 50.
>> 
>> StackMapsTest is also extended to test this patch.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - fixed StackCounter
>  - Merge branch 'master' into JDK-8305990-debug-info-strip-fail
>  - implemented failover stackmap generation for class version 50
>    fixed StackMapGenerator error debug print + added clone constructor to SplitConstantPool
>    adjusted and extended related tests
>  - Apply suggestions from code review
>    
>    Thanks for review.
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8305990-debug-info-strip-fail
>  - Update StackCounter.java
>  - added comments to StackCounter about maxStack upper bounds calculation for JSR/RET instructions
>  - fixed stack counting of JSR instructions
>  - implemented StackCounter
>  - Making some BufWriter fields final
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/b8fa6d3b...5db0ed01

Looks good, and nice extension in terms of functionality.applicability. Added some minor (optional) nits

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13478#pullrequestreview-1418489696

From mcimadamore at openjdk.org  Tue May  9 11:58:27 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 9 May 2023 11:58:27 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v13]
In-Reply-To: <gdah40nU6KNFj_d-TWtzmnP7csD1-nne7gHh_iepn5I=.65dde8c4-bd01-43ae-ab36-fc026dc7cf20@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <gdah40nU6KNFj_d-TWtzmnP7csD1-nne7gHh_iepn5I=.65dde8c4-bd01-43ae-ab36-fc026dc7cf20@github.com>
Message-ID: <-4dlwrHEeqthBaePNej17OjViy-M0hUf9TWa8UEflEA=.6c5a783f-4d50-43c5-aabd-c919318b5970@github.com>

On Tue, 9 May 2023 11:11:36 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API didn't handle transformations of class files version 50 and below correctly. 
>> 
>> Proposed fix have two parts: 
>> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
>> 2. StackMapTable attribute is not generated for class file versions below 50.
>> 
>> StackMapsTest is also extended to test this patch.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - fixed StackCounter
>  - Merge branch 'master' into JDK-8305990-debug-info-strip-fail
>  - implemented failover stackmap generation for class version 50
>    fixed StackMapGenerator error debug print + added clone constructor to SplitConstantPool
>    adjusted and extended related tests
>  - Apply suggestions from code review
>    
>    Thanks for review.
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8305990-debug-info-strip-fail
>  - Update StackCounter.java
>  - added comments to StackCounter about maxStack upper bounds calculation for JSR/RET instructions
>  - fixed stack counting of JSR instructions
>  - implemented StackCounter
>  - Making some BufWriter fields final
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/929ac16e...5db0ed01

Seems like GitHub UI does not let me add comments (as GitHub seems to be experiencing some issues). Here's what I added:

* StackCounter: `stack` and `local` are different in spirit. One adds new stack slots. The other ensure there's at least enough local slots available. As such I'd suggest a renaming `addStackSlot` and `ensureLocalSlot`.

* StackMapGeneration/DirectClassBuilder: the exception type seems a bit loose and we might end up catching more than is thrown by the stackmap generator.

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

PR Comment: https://git.openjdk.org/jdk/pull/13478#issuecomment-1540013928

From mcimadamore at openjdk.org  Tue May  9 12:02:21 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 9 May 2023 12:02:21 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v13]
In-Reply-To: <gdah40nU6KNFj_d-TWtzmnP7csD1-nne7gHh_iepn5I=.65dde8c4-bd01-43ae-ab36-fc026dc7cf20@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <gdah40nU6KNFj_d-TWtzmnP7csD1-nne7gHh_iepn5I=.65dde8c4-bd01-43ae-ab36-fc026dc7cf20@github.com>
Message-ID: <kbEWTKgPSDZXw2r9223iMDEUe9FYsJ6sg7Q6wnO9prM=.0eda6e28-2a83-46ca-863f-3ab842f859fb@github.com>

On Tue, 9 May 2023 11:11:36 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Classfile API didn't handle transformations of class files version 50 and below correctly. 
>> 
>> Proposed fix have two parts: 
>> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
>> 2. StackMapTable attribute is not generated for class file versions below 50.
>> 
>> StackMapsTest is also extended to test this patch.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - fixed StackCounter
>  - Merge branch 'master' into JDK-8305990-debug-info-strip-fail
>  - implemented failover stackmap generation for class version 50
>    fixed StackMapGenerator error debug print + added clone constructor to SplitConstantPool
>    adjusted and extended related tests
>  - Apply suggestions from code review
>    
>    Thanks for review.
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Merge branch 'master' into JDK-8305990-debug-info-strip-fail
>  - Update StackCounter.java
>  - added comments to StackCounter about maxStack upper bounds calculation for JSR/RET instructions
>  - fixed stack counting of JSR instructions
>  - implemented StackCounter
>  - Making some BufWriter fields final
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/8b214fa8...5db0ed01

Seems like GitHub UI does not let me add comments (as GitHub seems to be experiencing some issues). Here's what I added:

* StackCounter: `stack` and `local` are different in spirit. One adds new stack slots. The other ensure there's at least enough local slots available. As such I'd suggest a renaming `addStackSlot` and `ensureLocalSlot`.

* StackMapGeneration/DirectClassBuilder: the exception type seems a bit loose and we might end up catching more than is thrown by the stackmap generator.

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

PR Comment: https://git.openjdk.org/jdk/pull/13478#issuecomment-1540015728

From asotona at openjdk.org  Tue May  9 12:17:25 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 May 2023 12:17:25 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v13]
In-Reply-To: <kbEWTKgPSDZXw2r9223iMDEUe9FYsJ6sg7Q6wnO9prM=.0eda6e28-2a83-46ca-863f-3ab842f859fb@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
 <gdah40nU6KNFj_d-TWtzmnP7csD1-nne7gHh_iepn5I=.65dde8c4-bd01-43ae-ab36-fc026dc7cf20@github.com>
 <kbEWTKgPSDZXw2r9223iMDEUe9FYsJ6sg7Q6wnO9prM=.0eda6e28-2a83-46ca-863f-3ab842f859fb@github.com>
Message-ID: <1Pa5km7i8y-l1dJdyW1D_25356Q2iahnI4zQv5d_4vs=.9bd1eba1-d371-44e4-a144-17679f999c66@github.com>

On Tue, 9 May 2023 11:59:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
>> 
>>  - fixed StackCounter
>>  - Merge branch 'master' into JDK-8305990-debug-info-strip-fail
>>  - implemented failover stackmap generation for class version 50
>>    fixed StackMapGenerator error debug print + added clone constructor to SplitConstantPool
>>    adjusted and extended related tests
>>  - Apply suggestions from code review
>>    
>>    Thanks for review.
>>    
>>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>>  - Merge branch 'master' into JDK-8305990-debug-info-strip-fail
>>  - Update StackCounter.java
>>  - added comments to StackCounter about maxStack upper bounds calculation for JSR/RET instructions
>>  - fixed stack counting of JSR instructions
>>  - implemented StackCounter
>>  - Making some BufWriter fields final
>>  - ... and 6 more: https://git.openjdk.org/jdk/compare/1302ccc8...5db0ed01
>
> Seems like GitHub UI does not let me add comments (as GitHub seems to be experiencing some issues). Here's what I added:
> 
> * StackCounter: `stack` and `local` are different in spirit. One adds new stack slots. The other ensure there's at least enough local slots available. As such I'd suggest a renaming `addStackSlot` and `ensureLocalSlot`.
> 
> * StackMapGeneration/DirectClassBuilder: the exception type seems a bit loose and we might end up catching more than is thrown by the stackmap generator.

@mcimadamore thanks for review.
I've fixed `stack` and `local`.
Exception consolidation is already a part of #11411 and this catch will be changed to `IAE` only. Actually it would have to catch `ISE`, `IAE`, `IOOBE` and probably also `NPE`.

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

PR Comment: https://git.openjdk.org/jdk/pull/13478#issuecomment-1540021763

From jlaskey at openjdk.org  Tue May  9 12:54:50 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 12:54:50 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v67]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <l7J5wI3ZLIVlZLDWAOSqMm43O9LPr7wZMEAlXpAz3ek=.15f31874-1c70-45ac-b63b-97a262b0fd51@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Recommended changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/53f6280d..8e83e10d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=66
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=65-66

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

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

From jlaskey at openjdk.org  Tue May  9 12:58:27 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 12:58:27 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v68]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Dangling <p>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/8e83e10d..2ac6252b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=67
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=66-67

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

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

From asotona at openjdk.org  Tue May  9 13:08:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 May 2023 13:08:57 GMT
Subject: RFR: 8305990: Stripping debug info of ASM 9.5 fails [v14]
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <Ui1oLINbbg75f_47SzE4bSRHhkDL7tIQuVidfstzsuU=.41befaac-6ebb-47df-a86e-d9fb98281773@github.com>

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - empty commit to trigger PR update
 - renamed StackCounter::stack and local to addStackSlot and ensureLocalSlot

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13478/files
  - new: https://git.openjdk.org/jdk/pull/13478/files/5db0ed01..7d21663c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13478&range=12-13

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

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

From asotona at openjdk.org  Tue May  9 13:16:37 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 May 2023 13:16:37 GMT
Subject: Integrated: 8305990: Stripping debug info of ASM 9.5 fails
In-Reply-To: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
References: <35R-JD6N5YUwHa-ftngnBs-5kLXoWsXwpx-L5cbmXhY=.e58b2d2c-2023-4ffa-8eb5-216868185f2e@github.com>
Message-ID: <qA3AtqbmrwansyDTSSzt0PaN2CnsljtWvAr0DmB2-Q8=.ed689d57-121e-4c76-997e-ba6d87ce8fea@github.com>

On Fri, 14 Apr 2023 14:02:46 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile API didn't handle transformations of class files version 50 and below correctly. 
> 
> Proposed fix have two parts: 
> 1. Inflation of branch targets does not depend on StackMapTable attribute presence for class file version 50 and below. Alternative fallback implementation is provided. 
> 2. StackMapTable attribute is not generated for class file versions below 50.
> 
> StackMapsTest is also extended to test this patch.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: a05560d9
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a05560d99352bd5952f3feef37b56dceb74ede3b
Stats:     992 lines in 16 files changed: 816 ins; 31 del; 145 mod

8305990: Stripping debug info of ASM 9.5 fails

Reviewed-by: mcimadamore

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

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

From aefimov at openjdk.org  Tue May  9 13:20:28 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 9 May 2023 13:20:28 GMT
Subject: RFR: 8302845: Replace finalizer usage in JNDI DNS provider with
 Cleaner [v4]
In-Reply-To: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
References: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
Message-ID: <IW-EYByaigfdCT9uuTznj5NkvA7xpUoSp9F-OCWUWCw=.dd58c699-699f-4ebf-88b1-91ff048516f7@github.com>

> JNDI `DnsClient` has a finalize method to close its internal datagram channel selector.
>  The change proposed here replaces it with a cleaner to close the selector once the `DnsClient`
>   instance becomes phantom reachable. 
> 
> The change was tested with `jdk-tier1` to `jdk-tier3` test sets which showed no failures.

Aleksei Efimov has updated the pull request with a new target base 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 JDK-8302845_DNS_client_replace_finalizer
 - Use cleanable to close the selector in DnsClient::close
 - fix comment
 - 8302845: Replace finalizer usage in JNDI DNS provider with Cleaner

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13837/files
  - new: https://git.openjdk.org/jdk/pull/13837/files/3a139b27..c08c98f3

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

  Stats: 331463 lines in 3383 files changed: 281976 ins; 27082 del; 22405 mod
  Patch: https://git.openjdk.org/jdk/pull/13837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13837/head:pull/13837

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

From djelinski at openjdk.org  Tue May  9 13:41:21 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 9 May 2023 13:41:21 GMT
Subject: RFR: 8302845: Replace finalizer usage in JNDI DNS provider with
 Cleaner [v4]
In-Reply-To: <IW-EYByaigfdCT9uuTznj5NkvA7xpUoSp9F-OCWUWCw=.dd58c699-699f-4ebf-88b1-91ff048516f7@github.com>
References: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
 <IW-EYByaigfdCT9uuTznj5NkvA7xpUoSp9F-OCWUWCw=.dd58c699-699f-4ebf-88b1-91ff048516f7@github.com>
Message-ID: <5IlTvydcJ-8gK4SPIp9E44rY-GK3aTfQtn_LBmd7hDw=.73d699c5-292f-4131-9cc0-c6db3f5bf633@github.com>

On Tue, 9 May 2023 13:20:28 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> JNDI `DnsClient` has a finalize method to close its internal datagram channel selector.
>>  The change proposed here replaces it with a cleaner to close the selector once the `DnsClient`
>>   instance becomes phantom reachable. 
>> 
>> The change was tested with `jdk-tier1` to `jdk-tier3` test sets which showed no failures.
>
> Aleksei Efimov has updated the pull request with a new target base 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 JDK-8302845_DNS_client_replace_finalizer
>  - Use cleanable to close the selector in DnsClient::close
>  - fix comment
>  - 8302845: Replace finalizer usage in JNDI DNS provider with Cleaner

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13837#pullrequestreview-1418660339

From dfuchs at openjdk.org  Tue May  9 13:49:52 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 9 May 2023 13:49:52 GMT
Subject: RFR: 8302845: Replace finalizer usage in JNDI DNS provider with
 Cleaner [v4]
In-Reply-To: <IW-EYByaigfdCT9uuTznj5NkvA7xpUoSp9F-OCWUWCw=.dd58c699-699f-4ebf-88b1-91ff048516f7@github.com>
References: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
 <IW-EYByaigfdCT9uuTznj5NkvA7xpUoSp9F-OCWUWCw=.dd58c699-699f-4ebf-88b1-91ff048516f7@github.com>
Message-ID: <IAAZ4fmaCL7nRWGgz3Aeilyu_Kw8PhqtQf79MAkND1w=.8f14070d-2e4a-4faa-aaf9-f2db85165cf9@github.com>

On Tue, 9 May 2023 13:20:28 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> JNDI `DnsClient` has a finalize method to close its internal datagram channel selector.
>>  The change proposed here replaces it with a cleaner to close the selector once the `DnsClient`
>>   instance becomes phantom reachable. 
>> 
>> The change was tested with `jdk-tier1` to `jdk-tier3` test sets which showed no failures.
>
> Aleksei Efimov has updated the pull request with a new target base 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 JDK-8302845_DNS_client_replace_finalizer
>  - Use cleanable to close the selector in DnsClient::close
>  - fix comment
>  - 8302845: Replace finalizer usage in JNDI DNS provider with Cleaner

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13837#pullrequestreview-1418680784

From rriggs at openjdk.org  Tue May  9 14:06:12 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 May 2023 14:06:12 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v5]
In-Reply-To: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
Message-ID: <cPJ1TZtO0S0gyWmReXjgYOs1TQmqQS433pidCRhkdnQ=.f5e1ef05-2e11-4705-a660-4c5edaa413a3@github.com>

> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
> 
> Neither os.name nor os.arch should be assumed to be changeable; 
> one test case is removed because it assumes os.name can be changed on the command line.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  The CDS plugin supports only same platform operation.
  On 64-bit runtimes, the non-compressed oop CDS archive is generated.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13585/files
  - new: https://git.openjdk.org/jdk/pull/13585/files/db56d702..fc1959a2

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

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

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

From rriggs at openjdk.org  Tue May  9 14:09:52 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 May 2023 14:09:52 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v4]
In-Reply-To: <JRd_wRsOOp3RDAomFj3VMfqvl9lVflQSZ0q8avdGRgc=.8c1113ac-d89b-412a-b06d-abc97fe5ce59@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
 <cb6Od5Adh_1Y2rQ5a7FoaaMGBSB6QmpRYChzc3AKR9c=.80488616-3ad8-4e17-b7a4-a029d12741d4@github.com>
 <JRd_wRsOOp3RDAomFj3VMfqvl9lVflQSZ0q8avdGRgc=.8c1113ac-d89b-412a-b06d-abc97fe5ce59@github.com>
Message-ID: <LxmYoBd4_ImXp98SJkiS58wVGjdDxsFRC3LuP1xpyf0=.eaf3a44a-b53f-45f0-b7f6-7215e2e5ff69@github.com>

On Tue, 9 May 2023 09:03:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct Platform.is64Bit() to report address size of the architecture enum, not the running system
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 65:
> 
>> 63:      */
>> 64:     public boolean is64Bit() {
>> 65:         return arch != Architecture.X86;
> 
> Have you considered having an instance `Architecture::is64bit` method in lieu of the current static method?

Possibly, if a need subsequently arises. 
The only current use is in CDSPlugin and it is testing if the current/runtime platform is 64-bit so it can create the non-oop archive. The `Architecture.is64bit()` provides that.  The current `Platform.is64Bit()` method is not needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1188656539

From rriggs at openjdk.org  Tue May  9 14:09:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 May 2023 14:09:54 GMT
Subject: RFR: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink [v4]
In-Reply-To: <dIt4wAsqcZL3yqtGtqPKjtrLGtHZHTiaO2rXrON2bJQ=.5ac838c5-ca6f-453a-9e13-cc18830b5709@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
 <cb6Od5Adh_1Y2rQ5a7FoaaMGBSB6QmpRYChzc3AKR9c=.80488616-3ad8-4e17-b7a4-a029d12741d4@github.com>
 <dIt4wAsqcZL3yqtGtqPKjtrLGtHZHTiaO2rXrON2bJQ=.5ac838c5-ca6f-453a-9e13-cc18830b5709@github.com>
Message-ID: <4Q6SoIQkasluMIrUCd93fPj_jNCUrUX6PxVAnlUZe-A=.857e891b-127f-4223-8da6-a88b03cd6067@github.com>

On Tue, 9 May 2023 11:16:32 GMT, Glavo <duke at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct Platform.is64Bit() to report address size of the architecture enum, not the running system
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 65:
> 
>> 63:      */
>> 64:     public boolean is64Bit() {
>> 65:         return arch != Architecture.X86;
> 
> This change causes incorrect results to be returned on Linux ARM32.

My mistake; see above, `Platform.is64Bit()` is not needed by CDSPlugin.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13585#discussion_r1188657630

From asotona at openjdk.org  Tue May  9 14:15:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 May 2023 14:15:52 GMT
Subject: RFR: 8306842: Classfile API performance improvements
Message-ID: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>

Following improvements implemented:
- Switch over `String` replaced with switch single char
- Binary search for frames in `StackMapGenerator`
- `StackMapGenerator.rawHandlers` with pre-calculated offsets
- `ClassEntry` is caching `ClassDesc` symbol
- Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
- Caching `MethodTypeDesc` in `MethodInfo` implementations
- `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing

No API change.

Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.


Benchmark                     Mode  Cnt       Score       Error  Units
GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s



Benchmark                     Mode  Cnt       Score      Error  Units
GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s

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

Commit messages:
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8306842-perf-improvements
 - more use of MethodInfo::methodTypeSymbol and faster ClassDesc slot size calculation
 - merge from master
 - StackMapGenerator::processInvokeInstructions uses cached MethodTypeDesc
 - caching MethodTypeDesc in MethodInfo implementations and improved Util methods
 - getting symbols from NaTEntry moved to new Util::fieldTypeSymbol and Util::methodTypeSymbol methods
 - new RebuildMethodBodies benchmark
 - fixed Util::entryList
 - Apply suggestions from code review
 - caching type symbols in NameAndTypeEntry and MethodTypeEntry
 - ... and 16 more: https://git.openjdk.org/jdk/compare/a05560d9...ca4c00d4

Changes: https://git.openjdk.org/jdk/pull/13671/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13671&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306842
  Stats: 476 lines in 23 files changed: 283 ins; 83 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/13671.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13671/head:pull/13671

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

From asotona at openjdk.org  Tue May  9 14:15:54 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 May 2023 14:15:54 GMT
Subject: RFR: 8306842: Classfile API performance improvements
In-Reply-To: <fridnuwG92KYtj4jXKi1K3t1eCIQ7lPsAY9tAEGpaUE=.4132af0f-acac-4c61-9f8a-5b99f6eac56b@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <fridnuwG92KYtj4jXKi1K3t1eCIQ7lPsAY9tAEGpaUE=.4132af0f-acac-4c61-9f8a-5b99f6eac56b@github.com>
Message-ID: <xSIqEx60un8pmgSk-INHNFLe0a5HtoNDsXThcktVnNM=.08c830b2-5ca7-47c8-b41d-7a9492ce4fad@github.com>

On Wed, 26 Apr 2023 16:00:07 GMT, Chen Liang <liach at openjdk.org> wrote:

> 1. CodeBuilder.invokeInstruction and CodeBuilder.fieldInstruction can pass their symbols to the NameAndTypeEntry as well, since it's almost always going to be used by stack map generation later.

Yes, they actually do. CodeBuilder conventional methods delegate down to the NaTEntry construction from symbols. I hope I didn't miss any important path.  

> 2. Since the casts to access the field and method type symbols in `NameAndTypeEntryImpl` is quite complex, can we move it to a utility method in `Util` for cleaner call sites?
> 3. `parameterSlots` `parseParameterSlots` `maxLocals` in `Util` can probably operate on a `MethodTypeDesc` than a bitset, especially that the method type symbols are available in most scenarios already.
> 4. `StackMapGenerator.processInvokeInstructions` can probably scan through the `MethodTypeDesc` instead of using the hand-rolled `while (++pos < descLen && (ch = mDesc.charAt(pos)) != ')')` loop. In fact, the whole loop can be replaced by `Util.parameterSlots()`
> 5. `StackMapGenerator.isDoubleSlot(ClassDesc)` should be moved to `Util` and used by `parameterSlots()` etc (assuming they've migrated to `MethodTypeDesc`), and implementation be updated to:
> 
> ```java
>     public static boolean isDoubleSlot(ClassDesc desc) {
>         return desc.isPrimitive() && (desc.charAt(0) == 'D' || desc.charAt(0) == 'J');
>     }
> ```
> 
> to avoid potentially slow string comparisons.

These are great suggestions, I'll work on them.

Thanks!

> If we can hash internal names for constant pool without calling Util.toInternalName on ClassDesc instances, can that offset the performance penalty of toInternalName?

Yes, that may help. There is already manual hash calculation from the raw bytes, so it should work the same way.
Good idea, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13671#issuecomment-1525075958
PR Comment: https://git.openjdk.org/jdk/pull/13671#issuecomment-1527577715

From asotona at openjdk.org  Tue May  9 14:15:55 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 May 2023 14:15:55 GMT
Subject: RFR: 8306842: Classfile API performance improvements
In-Reply-To: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
Message-ID: <Q4IeNOOTJKWwx5tUjAFcrkxBIIorR-oYS2odLzp4I1c=.4a4e68f9-91b9-45d2-8d7d-c1e9da993365@github.com>

On Wed, 26 Apr 2023 15:04:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
> - Caching `MethodTypeDesc` in `MethodInfo` implementations
> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
> 
> No API change.
> 
> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
> 
> 
> Benchmark                     Mode  Cnt       Score       Error  Units
> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
> 
> 
> 
> Benchmark                     Mode  Cnt       Score      Error  Units
> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s

Caching of `ClassDesc` in `ClassEntry` is already a part of this PR and the internal name is key for `ClassEntry` from the very beginning, so obtaining internal name from `ClassEntry` was never an issue.
However `ClassEntry` is a short-live object, newly created for each generated or transformed class and it exists within a constant pool context only.
In order to reach the same performance as with cached internal names in `ClassDesc` instances, we would have to change the user coding schema and not the Classfile API internals.
Every code generation or transformation would have to start with static declaration of `ClassEntry` constants (instead of `ClassDesc`), constructed from to `TemporaryConstantPool` (which is for internal purpose yet).

I've added new benchmarks measuring repeated transformations rebuilding method bodies (down to the symbols expansion) from already expanded models.
I?ve added shared and unshared CP alternatives (for curiosity), however the unshared is closer to simulation of building from symbols.
 
Here are results from the actual code base:
 
Benchmark                      Mode  Cnt      Score     Error  Units
RebuildMethodBodies.shared    thrpt    4  10258.597 ? 383.699  ops/s
RebuildMethodBodies.unshared  thrpt    4   7224.543 ? 256.800  ops/s
 
And here is already visible approx. 22% improvement in both (without the rest of proposed improvements yet):
 
Benchmark                      Mode  Cnt      Score      Error  Units
RebuildMethodBodies.shared    thrpt    4  12498.597 ? 309.585  ops/s
RebuildMethodBodies.unshared  thrpt    4   8807.229 ?  167.247  ops/s

It would be also interesting to see a difference with cached internal names in `ClassDesc`.

Now we have following benchamrk numbers:

Benchmark                      Mode  Cnt      Score     Error  Units
RebuildMethodBodies.shared    thrpt    4  13380.272 ? 810.113  ops/s
RebuildMethodBodies.unshared  thrpt    4   9399.863 ? 557.060  ops/s


Which is 30% performance improvement :)

I benchmarked merged this PR with #13598 and benefits of caching of internal names in ClassDesc are insignificant (~2% performance boost).

Problem with ClassDesc "embedding" into the Utf8Entry is with its ambiguity.
Utf8Entry mainly contains some name or descriptor (MethodTypeDesc, ClassDesc, PackageDesc, ModuleDesc, etc...) or signature (Signature, MethodSignature, ClassSignature, etc...).
And even for ClassDesc there is ambiguity of the serialized form. When the Utf8Entry is related to ClassEntry it contains descriptor for arrays or internal name for classes. However when the Utf8Entry is related for example to annotation it contains always class descriptor (even for classes).
>From this perspective the Utf8Entry should not be responsible for conversions to and from symbols, because it does not know the context and so the right serialised form.
ClassEntry knows the  exact form of its Utf8Entry, Annotation, MethodInfo or (with just a minor ambiguity) also NameAndTypeEntry know which symbols to use and how to serialize/deserialize them.
I think that having Utf8Entry as a big central dispatcher for so many types of symbols and serialisation forms is not the best design and will include a lot of complexity and confusion. 
Current architecture lets interaction with symbols responsibility on the right layer.

 It is unlikely that one Utf8Entry will hold two different symbols, however still possible (for example when Signature and ClassDesc are the same).
And it is still very likely that one symbol describing the same class will be stored in two different Utf8Entries (for example the same class stored as reference from ClassEntry vs. as reference from Annotation).

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

PR Comment: https://git.openjdk.org/jdk/pull/13671#issuecomment-1527068370
PR Comment: https://git.openjdk.org/jdk/pull/13671#issuecomment-1527081241
PR Comment: https://git.openjdk.org/jdk/pull/13671#issuecomment-1527241784
PR Comment: https://git.openjdk.org/jdk/pull/13671#issuecomment-1527327378
PR Comment: https://git.openjdk.org/jdk/pull/13671#issuecomment-1531104946

From duke at openjdk.org  Tue May  9 14:15:58 2023
From: duke at openjdk.org (ExE Boss)
Date: Tue, 9 May 2023 14:15:58 GMT
Subject: RFR: 8306842: Classfile API performance improvements
In-Reply-To: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
Message-ID: <U3Up049ExKHqMZ91BXbR5FYDrbrx_1fh65kF-75v5po=.5dd4ac1d-e7d5-4c94-b2c7-4d590e40ead4@github.com>

On Wed, 26 Apr 2023 15:04:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
> - Caching `MethodTypeDesc` in `MethodInfo` implementations
> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
> 
> No API change.
> 
> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
> 
> 
> Benchmark                     Mode  Cnt       Score       Error  Units
> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
> 
> 
> 
> Benchmark                     Mode  Cnt       Score      Error  Units
> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s

In?order to?avoid eager?conversion of?a?`ClassDesc` to?internal?name, I?suggest?extending `AbstractPoolEntry.Utf8EntryImpl` with?`State.CLASS_DESC`:

class AbstractPoolEntry.Utf8EntryImpl extends AbstractPoolEntry implements Utf8Entry {
	enum State { CLASS_DESC, ... }

	// Set in any state other than RAW or CLASS_DESC
	private int hash;
	// Set in any state other than RAW
	private int charLen;
	// Only set in CLASS_DESC state, must be an L-type Class descriptor
	private ClassDesc classDesc;

	Utf8EntryImpl(ConstantPool cpm, int index, ClassDesc cd) {
		super(cpm, Classfile.TAG_UTF8, index, 0);
		this.rawBytes = null;
		this.offset = 0;
		this.rawLen = 0;
		String descriptor = cd.descriptorString();
		if (cd.isArray()) {
			this.state = State.STRING;
			this.stringValue = descriptor;
			this.charLen = descriptor.length();
			this.hash = hashString(descriptor.hashCode());
		} else {
			assert cd.isClassOrInterface() : cd;
			this.state = State.CLASS_DESC;
			this.classDesc = cd;
			this.charLen = descriptor.length() - 2;
		}
	}

	private void inflateClassDesc() {
		String internalName = Utils.toInternalName(this.classDesc);
		assert this.charLen = internalName.length();
		this.stringValue = internalName;
		this.hash = hashString(internalName.hashCode());
		this.state = State.STRING;
	}

	@Override
	public Utf8EntryImpl clone(ConstantPoolBuilder cp) {
		if (cp.canWriteDirect(constantPool))
			return this;
		if (state = State.CLASS_DESC) {
			return (Utf8EntryImpl) cp.utf8Entry(classDesc);
		}
		return (state == State.STRING && rawBytes == null)
			? (Utf8EntryImpl) cp.utf8Entry(stringValue)
			: ((SplitConstantPool) cp).maybeCloneUtf8Entry(this);
	}

	@Override
	public int hashCode() {
		if (state == State.CLASS_DESC) {
			inflateClassDesc();
		}
		...
	}

	@Override
	public String toString() {
		if (state == State.CLASS_DESC) {
			inflateClassDesc();
		}
		...
	}

	@Override
	public char charAt(int index) {
		if (state == State.CLASS_DESC) {
			return classDesc.descriptorString()
				.charAt(Objects.checkIndex(index, charLen) + 1);
		}
		...
	}

	@Override
	public boolean equalsString(String s) {
		if (state == State.CLASS_DESC) {
			inflateClassDesc();
		}
		...
	}

	@Override
	public void writeTo(BufWriter pool) {
		if (rawBytes != null) {
			...
		}
		else {
			if (state == State.CLASS_DESC) {
				inflateClassDesc();
			}
			...
		}
	}
}

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 586:

> 584:                 sym = Util.toClassDesc(asInternalName());
> 585:             }
> 586:             return sym;

Suggestion:

            var sym = this.sym;
            if (sym != null) {
                return sym;
            }
            return this.sym = Util.toClassDesc(asInternalName());

src/java.base/share/classes/jdk/internal/classfile/impl/AbstractPoolEntry.java line 988:

> 986:                 sym = MethodTypeDesc.ofDescriptor(descriptor().stringValue());
> 987:             }
> 988:             return sym;

Suggestion:

            var sym = this.sym;
            if (sym != null) {
                return sym;
            }
            return this.sym = MethodTypeDesc.ofDescriptor(descriptor().stringValue());

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

PR Comment: https://git.openjdk.org/jdk/pull/13671#issuecomment-1527967835
PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1178367689
PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1178369318

From liach at openjdk.org  Tue May  9 14:15:52 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 14:15:52 GMT
Subject: RFR: 8306842: Classfile API performance improvements
In-Reply-To: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
Message-ID: <fridnuwG92KYtj4jXKi1K3t1eCIQ7lPsAY9tAEGpaUE=.4132af0f-acac-4c61-9f8a-5b99f6eac56b@github.com>

On Wed, 26 Apr 2023 15:04:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
> - Caching `MethodTypeDesc` in `MethodInfo` implementations
> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
> 
> No API change.
> 
> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
> 
> 
> Benchmark                     Mode  Cnt       Score       Error  Units
> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
> 
> 
> 
> Benchmark                     Mode  Cnt       Score      Error  Units
> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s

1. CodeBuilder.invokeInstruction and CodeBuilder.fieldInstruction can pass their symbols to the NameAndTypeEntry as well, since it's almost always going to be used by stack map generation later.
2. Since the casts to access the field and method type symbols in `NameAndTypeEntryImpl` is quite complex, can we move it to a utility method in `Util` for cleaner call sites?
3. `parameterSlots` `parseParameterSlots` `maxLocals` in `Util` can probably operate on a `MethodTypeDesc` than a bitset, especially that the method type symbols are available in most scenarios already.
4. `StackMapGenerator.processInvokeInstructions` can probably scan through the `MethodTypeDesc` instead of using the hand-rolled `while (++pos < descLen && (ch = mDesc.charAt(pos)) != ')')` loop. In fact, the whole loop can be replaced by `Util.parameterSlots()`
5. `StackMapGenerator.isDoubleSlot(ClassDesc)` should be moved to `Util` and used by `parameterSlots()` etc (assuming they've migrated to `MethodTypeDesc`), and implementation be updated to:

    public static boolean isDoubleSlot(ClassDesc desc) {
        return desc.isPrimitive() && (desc.charAt(0) == 'D' || desc.charAt(0) == 'J');
    }

to avoid potentially slow string comparisons.

Thanks adam! Also if you can, I wish you can respond to mandy at https://github.com/openjdk/jdk/pull/13598#issuecomment-1524411693 on why we need an api to obtain the internal name (or a string for CONSTANT_Class_info) from a ClassDesc.

Though the proposal to add method to obtain internal names on ClassDesc is rejected, I think we can still obtain a performance boost if we can avoid frequent conversion between internal names and descriptors.

Looking at the usages of `Util.toClassDesc` and `Util.toInternalName`, we can already cache result of `toClassDesc` in `ClassEntry`. We can think similarly for `toInternalName`: the hash for `ClassEntry` may be derived from the class descriptor than the class internal name, so we don't need to call `toInternalName` every time we want to look up a ClassEntry with a ClassDesc in a constant pool.

If we can hash internal names for constant pool without calling Util.toInternalName on ClassDesc instances, can that offset the performance penalty of toInternalName?

I have a proof-of-concept patch here https://github.com/liachmodded/jdk/commit/3e6aa523521085e99b52fb49633676166910100f
which hashes class entries by the symbol's full descriptors instead of by the index of the linked utf8; we can access the hash of a full descriptor given the hash of an internal name easily, should be faster than iterating over or creating the internal name for a hash.

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

PR Comment: https://git.openjdk.org/jdk/pull/13671#issuecomment-1523668329
PR Comment: https://git.openjdk.org/jdk/pull/13671#issuecomment-1525083666
PR Comment: https://git.openjdk.org/jdk/pull/13671#issuecomment-1526287425
PR Comment: https://git.openjdk.org/jdk/pull/13671#issuecomment-1527477752
PR Comment: https://git.openjdk.org/jdk/pull/13671#issuecomment-1527621920

From rriggs at openjdk.org  Tue May  9 14:25:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 May 2023 14:25:18 GMT
Subject: RFR: JDK-8133773: clarify specification of Spliterator.tryAdvance
 [v2]
In-Reply-To: <CnoxNvzRN3G-CR6kx_w0hScOKjDlUUS772Fa_vBxfxw=.fbd55c64-b6aa-4c89-b446-ac8f208c9ad7@github.com>
References: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
 <CnoxNvzRN3G-CR6kx_w0hScOKjDlUUS772Fa_vBxfxw=.fbd55c64-b6aa-4c89-b446-ac8f208c9ad7@github.com>
Message-ID: <phbfQFpgu5umptCQKWkN8CN9q-qaDs3l440RWVx_q1s=.7d0e626f-ef30-4e36-98c3-14cbf1290729@github.com>

On Mon, 8 May 2023 19:07:17 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Attempting to make the "at-most once" nature, of invoking the supplied action to tryAdvance, clearer in the JavaDoc.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/util/Spliterator.java
>   
>   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13860#pullrequestreview-1418770326

From rriggs at openjdk.org  Tue May  9 14:25:20 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 May 2023 14:25:20 GMT
Subject: RFR: JDK-8133773: clarify specification of Spliterator.tryAdvance
 [v2]
In-Reply-To: <HSIutuu-YPkq8rAP5oT2bRzAMjlGGzNqcYT9y-CGhco=.b150fb92-a127-4887-9bfe-734a971b9602@github.com>
References: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
 <CnoxNvzRN3G-CR6kx_w0hScOKjDlUUS772Fa_vBxfxw=.fbd55c64-b6aa-4c89-b446-ac8f208c9ad7@github.com>
 <bK0Y-_VeE59jdT2DXnPAQjQ2auUc2VaI0N6BOVd3fzI=.5ca2560e-0067-457a-8c4f-72ffec253ae8@github.com>
 <HSIutuu-YPkq8rAP5oT2bRzAMjlGGzNqcYT9y-CGhco=.b150fb92-a127-4887-9bfe-734a971b9602@github.com>
Message-ID: <dNa2_CMEi5bTFy4riBVrzaNQXdl-_i3lFzOZEklwJB0=.f6c6fe37-afaa-4d1a-9c9f-9b08f636bb4c@github.com>

On Tue, 9 May 2023 09:21:08 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Spliterator.java line 298:
>> 
>>> 296: public interface Spliterator<T> {
>>> 297:     /**
>>> 298:      * If a remaining element exists: performs the given action on it,
>> 
>> I'm not sure the ":" is an improvement on the ",". 
>> "If the remaining element exists, the action is performed on it, ..."
>
> @RogerRiggs "the" instead of "a" gives me the impression that the Spliterator only has a single element left. The choice of colon instead of a comma is because "If a remaining element exists" introduces a list of 2 elements (and introducing a list is a good place for a colon) whereas the "else returns {@code false}" is a closely connected sentence to the topic of the list, which seems like a place to use the semi-colon.
> 
> But, not being a native English-speaker, I will happily change it to something which is more correct. :)

The switch from "a" to "the" was unintentional.  
"If a remaining element exists, the action is performed on it, returning true;..."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13860#discussion_r1188684799

From lmesnik at openjdk.org  Tue May  9 14:46:14 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 9 May 2023 14:46:14 GMT
Subject: RFR: 8307307: Improve ProcessTools.java to don't try to run
 Virtual wrapper for incompatible processes [v2]
In-Reply-To: <4XAvxExcDJxNOATuaxhHZvWcpBvt2Zhd2Bd7wuYqN1c=.86016870-ea81-423e-8f71-c44bfd2a8bad@github.com>
References: <4XAvxExcDJxNOATuaxhHZvWcpBvt2Zhd2Bd7wuYqN1c=.86016870-ea81-423e-8f71-c44bfd2a8bad@github.com>
Message-ID: <KDOqVyjj-qQVERFOy8GabsOXyBhK18z_w1_jgUxZupo=.035a26ee-a848-42ca-9a5d-9530b5632c1f@github.com>

> The ProcessTools has some support of jtreg thread factory functionality.
> It tries to run the new process using virtual thread to run `main()` method.
> This fix updates it to skip the java runs where no main class is involved and more correctly process options which has 2nd argument.
> Also is sets `main.wrapper` property to allow launched process understand id any wrappers is used.

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  fixed some params

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13808/files
  - new: https://git.openjdk.org/jdk/pull/13808/files/0047016b..106be911

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

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

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

From asotona at openjdk.org  Tue May  9 15:03:00 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 May 2023 15:03:00 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v2]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <h7axRpiKl8505vW21XplkwgrMwjby9GTXanWpxnixbQ=.f499bbd2-ddbb-4c4e-bc67-d0ae36519c45@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

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

 - more consolidation on IllegalArgumentException
 - Merge branch 'master' into JDK-8294969-javap
 - fixed TestClassNameWarning
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - consolidated safeguarding of IAE in javap
 - consolidation of constant pool originating IAEs and IOOBEs into ConstantPoolException extending IAE
 - Safeguarding CP errors + test
 - Merge branch 'master' into JDK-8294969-javap
 - fixed tools/javap/TestClassNameWarning.java
 - fixed tools/javap/T6866657.java and tools/javap/T7186925.java
 - ... and 205 more: https://git.openjdk.org/jdk/compare/672bade5...7d18b761

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

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=01
  Stats: 3766 lines in 39 files changed: 904 ins; 1723 del; 1139 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

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

From duke at openjdk.org  Tue May  9 15:08:19 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 9 May 2023 15:08:19 GMT
Subject: RFR: JDK-8133773: clarify specification of Spliterator.tryAdvance
 [v2]
In-Reply-To: <dNa2_CMEi5bTFy4riBVrzaNQXdl-_i3lFzOZEklwJB0=.f6c6fe37-afaa-4d1a-9c9f-9b08f636bb4c@github.com>
References: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
 <CnoxNvzRN3G-CR6kx_w0hScOKjDlUUS772Fa_vBxfxw=.fbd55c64-b6aa-4c89-b446-ac8f208c9ad7@github.com>
 <bK0Y-_VeE59jdT2DXnPAQjQ2auUc2VaI0N6BOVd3fzI=.5ca2560e-0067-457a-8c4f-72ffec253ae8@github.com>
 <HSIutuu-YPkq8rAP5oT2bRzAMjlGGzNqcYT9y-CGhco=.b150fb92-a127-4887-9bfe-734a971b9602@github.com>
 <dNa2_CMEi5bTFy4riBVrzaNQXdl-_i3lFzOZEklwJB0=.f6c6fe37-afaa-4d1a-9c9f-9b08f636bb4c@github.com>
Message-ID: <0t5Gsluul8pOEsjx7PvFa1Yh-OVRCHNJ2K9LPzDLDIY=.235b1c59-7c02-47f6-a964-7244bee513e4@github.com>

On Tue, 9 May 2023 14:22:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> @RogerRiggs "the" instead of "a" gives me the impression that the Spliterator only has a single element left. The choice of colon instead of a comma is because "If a remaining element exists" introduces a list of 2 elements (and introducing a list is a good place for a colon) whereas the "else returns {@code false}" is a closely connected sentence to the topic of the list, which seems like a place to use the semi-colon.
>> 
>> But, not being a native English-speaker, I will happily change it to something which is more correct. :)
>
> The switch from "a" to "the" was unintentional.  
> "If a remaining element exists, the action is performed on it, returning true;..."

@RogerRiggs Got it. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13860#discussion_r1188750200

From liach at openjdk.org  Tue May  9 15:09:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 15:09:54 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v7]
In-Reply-To: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
Message-ID: <348pBn6aG0ev6rHqGwRQ7-XC1o3mc5rr7NGql4O2fFQ=.9a3e0e65-fa9d-4479-95e4-b83a432b0914@github.com>

> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
> 
> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
> 
> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
> 
> Current questions, which I wish to discuss with @asotona:
> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?

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

 - rename to ofClassLoading/ofResourceParsing
   convert the default class provider to bypass security manager restrictions
 - Merge branch 'master' into hierarchy-resolve
 - Merge branch 'master' into hierarchy-resolve
 - Test both cached and uncached resolvers
 - Update the class hierarchy resolver api as per mailing list last week
 - Merge branch 'master' into hierarchy-resolve
 - Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Make lookup based resolver throw on illegal access eagerly
 - 8304425: ClassHierarchyResolver from Reflection
 - ClassHierarchyResolver using Reflection

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13082/files
  - new: https://git.openjdk.org/jdk/pull/13082/files/78c8f2f7..be9fa4d0

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

  Stats: 356591 lines in 3790 files changed: 293420 ins; 37875 del; 25296 mod
  Patch: https://git.openjdk.org/jdk/pull/13082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13082/head:pull/13082

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

From liach at openjdk.org  Tue May  9 15:09:54 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 15:09:54 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v7]
In-Reply-To: <SEhvgO08a8oYqgBOdzJKuYMe4z_0oWsM-VqYy_9x-80=.110e6a6f-c52b-4851-ae5f-f6ecb93828c0@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 <t4rDpFxOgOT9g3bszBFIgwhVckcnYOOM1WH28tiz4o0=.63a24e17-922c-4ec4-ba61-afd3bcdbbbf1@github.com>
 <mymIMELoWKjb1QOQVTuiqnk6UnffOSDAJQh0gZwEbiI=.9fa59085-5491-4407-b769-eb85f1d164cc@github.com>
 <SEhvgO08a8oYqgBOdzJKuYMe4z_0oWsM-VqYy_9x-80=.110e6a6f-c52b-4851-ae5f-f6ecb93828c0@github.com>
Message-ID: <_QrwFiV42JuwToew5Y2mZA01xF-QW8Bdo59wMkywygk=.8545d9d3-3933-43ca-84a6-f5f1eaf82dca@github.com>

On Wed, 26 Apr 2023 09:47:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> > @asotona Just curious, what's the current state of our new API model of caching class hierarchy info in a Classfile context object as we've discussed on the mailing list? Will you create a patch, or should I update this patch to that model?
> 
> In the discussion I tried to fine-tune exact naming of the factory methods and the default. Mainly to differentiate when the class is parsed as a resource `ofResourceParsing(ClassLoader loader)` and when it is loaded `ofClassLoading(ClassLoader loader)`
> 
> Otherwise this patch looks good.
> 
> The other part of the discussion with proposed `ClassfileReaderWriter` model is out of the scope of this topic, it has much bigger impact on all existing code and I would deferred it at least until this and other open PRs are merged.

Thanks for your evaluation, Adam. I have updated the method names to `ofClassLoading` and `ofResourceParsing`, and incorporated the idea of SecurityManager bypassing from https://github.com/openjdk/jdk/pull/13197/commits/cc6994202c93edd0c98e6fb0bb5f0cbe1da7df8e#diff-f044f7ab894bab3b36ad9f29e0b3f541df5246c90159635159343ce20e02c12cR54-R63 to ensure system libraries can use the hierarchy resolver all fine. I've ran `test/jdk/jdk/classfile` tests on my machine. Can you review again?

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

PR Comment: https://git.openjdk.org/jdk/pull/13082#issuecomment-1540326710

From liach at openjdk.org  Tue May  9 15:18:36 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 15:18:36 GMT
Subject: RFR: 8306842: Classfile API performance improvements
In-Reply-To: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
Message-ID: <AWJlhz_Tag-W4jvIjDGxfc8j8jQ_pMckiQo9qbnbWEs=.219e80f5-1c14-4ad1-ab81-7ea0203dd34d@github.com>

On Wed, 26 Apr 2023 15:04:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
> - Caching `MethodTypeDesc` in `MethodInfo` implementations
> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
> 
> No API change.
> 
> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
> 
> 
> Benchmark                     Mode  Cnt       Score       Error  Units
> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
> 
> 
> 
> Benchmark                     Mode  Cnt       Score      Error  Units
> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s

These casts can call the Util method instead, and their import of `AbstractPoolEntry` can be removed.

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java line 746:

> 744: 
> 745:     private void processFieldInstructions(RawBytecodeHelper bcs) {
> 746:         var desc = ((AbstractPoolEntry.NameAndTypeEntryImpl)((MemberRefEntry)cp.entryByIndex(bcs.getIndexU2())).nameAndType()).fieldTypeSymbol();

Suggestion:

        var desc = Util.fieldTypeSymbol((MemberRefEntry)cp.entryByIndex(bcs.getIndexU2())).nameAndType());

src/java.base/share/classes/jdk/internal/classfile/instruction/FieldInstruction.java line 80:

> 78:      */
> 79:     default ClassDesc typeSymbol() {
> 80:         return ((AbstractPoolEntry.NameAndTypeEntryImpl)field().nameAndType()).fieldTypeSymbol();

Suggestion:

        return Util.fieldTypeSymbol(field().nameAndType());

src/java.base/share/classes/jdk/internal/classfile/instruction/InvokeDynamicInstruction.java line 73:

> 71:      */
> 72:     default MethodTypeDesc typeSymbol() {
> 73:         return ((AbstractPoolEntry.NameAndTypeEntryImpl)invokedynamic().nameAndType()).methodTypeSymbol();

Suggestion:

        return Util.methodTypeSymbol(invokedynamic().nameAndType());

src/java.base/share/classes/jdk/internal/classfile/instruction/InvokeInstruction.java line 93:

> 91:      */
> 92:     default MethodTypeDesc typeSymbol() {
> 93:         return ((AbstractPoolEntry.NameAndTypeEntryImpl)method().nameAndType()).methodTypeSymbol();

Suggestion:

        return Util.methodTypeSymbol(method().nameAndType());

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

PR Review: https://git.openjdk.org/jdk/pull/13671#pullrequestreview-1418886418
PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1188762210
PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1188762982
PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1188764353
PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1188764783

From asotona at openjdk.org  Tue May  9 15:24:31 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 May 2023 15:24:31 GMT
Subject: RFR: 8304425: ClassHierarchyResolver from Reflection [v7]
In-Reply-To: <348pBn6aG0ev6rHqGwRQ7-XC1o3mc5rr7NGql4O2fFQ=.9a3e0e65-fa9d-4479-95e4-b83a432b0914@github.com>
References: <08Hy6pEhV75yr_F4mCP-dkKOKMCSoFxWI2E7OnM4iyQ=.cfa14992-8e94-4d6d-bdf9-e6689549c83e@github.com>
 <348pBn6aG0ev6rHqGwRQ7-XC1o3mc5rr7NGql4O2fFQ=.9a3e0e65-fa9d-4479-95e4-b83a432b0914@github.com>
Message-ID: <luqjRzWhSrnfydVctZge277S-21CDBijdfx9S0e-VKI=.68f5036b-6e56-40d7-815e-dafc3d39c087@github.com>

On Tue, 9 May 2023 15:09:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Add API to explore Class Hierarchy with a `ClassLoader` or a `Lookup` with proper privileges, with tests.
>> 
>> This addition is useful in case classes at runtime are not loaded from the system class loader, such as Proxy. This is also useful to APIs that generate bytecode with a `Lookup` object, such as a custom single-abstract-method class implementations from a method handle.
>> 
>> See https://mail.openjdk.org/pipermail/classfile-api-dev/2023-March/000249.html as well.
>> 
>> Current questions, which I wish to discuss with @asotona:
>> 1. Should the resolver fail fast on `IllegalAccessException` from the lookup? This usually indicates the hierarchy resolver is set up improperly, and proceeding may simply yield verification errors in class loading that are hard to track. For bytecode-generating APIs, throwing access errors for the Lookup eagerly is also more preferable than later silent generation failure.
>> 2. Whether the default resolver should be reading from jrt alone, reflection alone, or jrt then reflection. I personally believe reflection alone is more reliable, for classes may redefined with instrumentation or jfr, which may not be reflected in the system resources.
>> 3. In addition, I don't think chaining system class loader reflection after system resource retrieval is really meaningful: is there any case where reflection always works while the system resource retrieval always fails?
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - rename to ofClassLoading/ofResourceParsing
>    convert the default class provider to bypass security manager restrictions
>  - Merge branch 'master' into hierarchy-resolve
>  - Merge branch 'master' into hierarchy-resolve
>  - Test both cached and uncached resolvers
>  - Update the class hierarchy resolver api as per mailing list last week
>  - Merge branch 'master' into hierarchy-resolve
>  - Update src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Make lookup based resolver throw on illegal access eagerly
>  - 8304425: ClassHierarchyResolver from Reflection
>  - ClassHierarchyResolver using Reflection

src/java.base/share/classes/jdk/internal/classfile/impl/ClassHierarchyImpl.java line 143:

> 141:                 var sm = System.getSecurityManager();
> 142:                 if (sm != null) {
> 143:                     return AccessController.doPrivileged(new PrivilegedAction<>() {

This is out of my competency, need another reviewer for use of `PriviledgedAction` in this context.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13082#discussion_r1188773857

From liach at openjdk.org  Tue May  9 15:35:35 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 15:35:35 GMT
Subject: RFR: 8306455: Wrong majorVersion for multiple attributes in
 Classfile API
In-Reply-To: <mSyXLLN7qBVlAVaiYrvFSyAb8QAm-g9TAZ-ZSL_oiZI=.ec069d21-00c2-4343-adb6-01de938ddfc6@github.com>
References: <mSyXLLN7qBVlAVaiYrvFSyAb8QAm-g9TAZ-ZSL_oiZI=.ec069d21-00c2-4343-adb6-01de938ddfc6@github.com>
Message-ID: <jduOrGr6a8eaOlQJmyva860FFNYxhzL7UxKr2XlOdjw=.b1b5c0bb-6dad-4940-bd87-499b0bec9c04@github.com>

On Wed, 19 Apr 2023 14:31:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Spotted the typo for BootstrapMethods, and another review over the API exposed the typo on PermittedSubclasses.

Withdrawing this patch in favor of removing `validSince` completely in another patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/13536#issuecomment-1540403031

From liach at openjdk.org  Tue May  9 15:35:35 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 15:35:35 GMT
Subject: Withdrawn: 8306455: Wrong majorVersion for multiple attributes in
 Classfile API
In-Reply-To: <mSyXLLN7qBVlAVaiYrvFSyAb8QAm-g9TAZ-ZSL_oiZI=.ec069d21-00c2-4343-adb6-01de938ddfc6@github.com>
References: <mSyXLLN7qBVlAVaiYrvFSyAb8QAm-g9TAZ-ZSL_oiZI=.ec069d21-00c2-4343-adb6-01de938ddfc6@github.com>
Message-ID: <RqNtVMh4DoNtObvQg5B34ND8RtT7x72diutKcbbKLjQ=.169d403e-571e-4030-9351-0946a8dcbf78@github.com>

On Wed, 19 Apr 2023 14:31:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Spotted the typo for BootstrapMethods, and another review over the API exposed the typo on PermittedSubclasses.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Tue May  9 15:40:30 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 9 May 2023 15:40:30 GMT
Subject: Integrated: JDK-8133773: clarify specification of
 Spliterator.tryAdvance
In-Reply-To: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
References: <mv4OkXPWL2ehmDdeAl-jBuiwbcofsGkFwKYhMnc-roc=.6418108f-5ac5-4878-9c65-3bb26a0cac03@github.com>
Message-ID: <79TmbH_-LVtKTs1OotYo0EwNC2CmY5t-rzZf7XY_qIQ=.8636134a-ea24-4b90-8cca-d2681bf11f13@github.com>

On Mon, 8 May 2023 10:32:48 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Attempting to make the "at-most once" nature, of invoking the supplied action to tryAdvance, clearer in the JavaDoc.

This pull request has now been integrated.

Changeset: fdbfc8a7
Author:    Viktor Klang <viktor.klang at oracle.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fdbfc8a73b4507d31ec4f9252298ad708a0b6bf9
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8133773: clarify specification of Spliterator.tryAdvance

Reviewed-by: psandoz, tvaleev, rriggs

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

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

From asotona at openjdk.org  Tue May  9 15:57:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 May 2023 15:57:52 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v2]
In-Reply-To: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
Message-ID: <DsQz2jCb0L7uezobDQ3zHtl4zBViQJpWFH4FSsTlX-A=.9ca8a2c0-95a8-4c39-9164-d333753b6289@github.com>

> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
> - Caching `MethodTypeDesc` in `MethodInfo` implementations
> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
> 
> No API change.
> 
> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
> 
> 
> Benchmark                     Mode  Cnt       Score       Error  Units
> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
> 
> 
> 
> Benchmark                     Mode  Cnt       Score      Error  Units
> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s

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

  Apply suggestions from code review
  
  Co-authored-by: liach <7806504+liach at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13671/files
  - new: https://git.openjdk.org/jdk/pull/13671/files/ca4c00d4..0c1d4eb8

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

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

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

From darcy at openjdk.org  Tue May  9 16:04:48 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 May 2023 16:04:48 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v68]
In-Reply-To: <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
Message-ID: <FZfpnNgeSWv_zBF2Zi_t9N__2HRiPM9om-prQVYkQPo=.0f6bb954-3f1e-499d-9967-cad643fb6548@github.com>

On Tue, 9 May 2023 12:58:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dangling <p>

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1418983197

From duke at openjdk.org  Tue May  9 16:06:31 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 9 May 2023 16:06:31 GMT
Subject: RFR: JDK-8151531: Add notes to BaseStream.spliterator/iterator docs
 regarding them being escape hatches
Message-ID: <HH3ibsbjPBEBIQ6HwCiglhnDLNhwYUNFKj435anND6s=.f6611227-f1f4-4ad0-af4c-04fa8390ac72@github.com>

Still relevant to address? /cc @PaulSandoz

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

Commit messages:
 - JDK-8151531: Add notes to BaseStream.spliterator/iterator docs regarding them being escape hatches

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

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

From psandoz at openjdk.org  Tue May  9 16:08:48 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 9 May 2023 16:08:48 GMT
Subject: RFR: JDK-8151531: Add notes to BaseStream.spliterator/iterator
 docs regarding them being escape hatches
In-Reply-To: <HH3ibsbjPBEBIQ6HwCiglhnDLNhwYUNFKj435anND6s=.f6611227-f1f4-4ad0-af4c-04fa8390ac72@github.com>
References: <HH3ibsbjPBEBIQ6HwCiglhnDLNhwYUNFKj435anND6s=.f6611227-f1f4-4ad0-af4c-04fa8390ac72@github.com>
Message-ID: <N4NpXNfJp-fRiddfAg_SUO3MSiKQh2EMTmTSFaJ4pJY=.5f34b06d-c09a-4b36-b122-65bdc459e37a@github.com>

On Tue, 9 May 2023 15:50:13 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Still relevant to address? /cc @PaulSandoz

I would recommend:
- using `@apiNote` (might have to be placed at the end of the documentation); and 
- say "This operation is provided ..."

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

PR Review: https://git.openjdk.org/jdk/pull/13890#pullrequestreview-1418989740

From asotona at openjdk.org  Tue May  9 16:09:14 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 9 May 2023 16:09:14 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v3]
In-Reply-To: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
Message-ID: <exoJ1zXAbvWMBVIFmC-YCCUBYQE4dhYA-SKEMTNasbY=.b26fe531-70b6-44a3-8029-4977cf074dfd@github.com>

> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
> - Caching `MethodTypeDesc` in `MethodInfo` implementations
> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
> 
> No API change.
> 
> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
> 
> 
> Benchmark                     Mode  Cnt       Score       Error  Units
> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
> 
> 
> 
> Benchmark                     Mode  Cnt       Score      Error  Units
> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s

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

  fixed StackMapGenerator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13671/files
  - new: https://git.openjdk.org/jdk/pull/13671/files/0c1d4eb8..5af9f9c4

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

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

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

From redestad at openjdk.org  Tue May  9 16:11:25 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 9 May 2023 16:11:25 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v3]
In-Reply-To: <exoJ1zXAbvWMBVIFmC-YCCUBYQE4dhYA-SKEMTNasbY=.b26fe531-70b6-44a3-8029-4977cf074dfd@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <exoJ1zXAbvWMBVIFmC-YCCUBYQE4dhYA-SKEMTNasbY=.b26fe531-70b6-44a3-8029-4977cf074dfd@github.com>
Message-ID: <lm5o9mUABTzGie9xW_WaMEPUMOIxH9DdtyOAsVRH7_g=.84288127-cdf4-4dab-a84a-9ce85c58a74f@github.com>

On Tue, 9 May 2023 16:09:14 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Following improvements implemented:
>> - Switch over `String` replaced with switch single char
>> - Binary search for frames in `StackMapGenerator`
>> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
>> - `ClassEntry` is caching `ClassDesc` symbol
>> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
>> - Caching `MethodTypeDesc` in `MethodInfo` implementations
>> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
>> 
>> No API change.
>> 
>> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
>> 
>> 
>> Benchmark                     Mode  Cnt       Score       Error  Units
>> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
>> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
>> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
>> 
>> 
>> 
>> Benchmark                     Mode  Cnt       Score      Error  Units
>> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
>> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
>> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed StackMapGenerator

I'm having a look, but hit an early hurdle in that the microbenchmarks under org/openjdk/bench/jdk/classfile all seem to be missing necessary `--add-opens` flags. Micros should be runnable without any extra flags on the command line.

test/micro/org/openjdk/bench/jdk/classfile/RebuildMethodBodies.java line 42:

> 40: @BenchmarkMode(Mode.Throughput)
> 41: @State(Scope.Benchmark)
> 42: @Fork(value = 1, jvmArgsAppend = {"--enable-preview"})

Suggestion:

@Fork(value = 1, jvmArgsAppend = {"--enable-preview",
                                  "--add-opens", "java.base/jdk.internal.classfile=ALL-UNNAMED",
                                  "--add-opens", "java.base/jdk.internal.classfile.constantpool=ALL-UNNAMED",
                                  "--add-opens", "java.base/jdk.internal.classfile.instruction=ALL-UNNAMED"})

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

PR Review: https://git.openjdk.org/jdk/pull/13671#pullrequestreview-1418960199
PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1188810244

From liach at openjdk.org  Tue May  9 16:11:26 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 16:11:26 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v3]
In-Reply-To: <oG__BhgfsIYADPLbNEBBJep1SLvGAFPS6nbRiP48seI=.0d18c136-cfaa-4ccd-86c2-544493efc995@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <exoJ1zXAbvWMBVIFmC-YCCUBYQE4dhYA-SKEMTNasbY=.b26fe531-70b6-44a3-8029-4977cf074dfd@github.com>
 <lm5o9mUABTzGie9xW_WaMEPUMOIxH9DdtyOAsVRH7_g=.84288127-cdf4-4dab-a84a-9ce85c58a74f@github.com>
 <oG__BhgfsIYADPLbNEBBJep1SLvGAFPS6nbRiP48seI=.0d18c136-cfaa-4ccd-86c2-544493efc995@github.com>
Message-ID: <20aXsIS2b8aANbbHYb3XfI41OKiXki_ClNo0yFHOwm4=.4e09f65c-d506-434e-bc08-7d80bff8f5b4@github.com>

On Tue, 9 May 2023 15:57:44 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/jdk/classfile/RebuildMethodBodies.java line 42:
>> 
>>> 40: @BenchmarkMode(Mode.Throughput)
>>> 41: @State(Scope.Benchmark)
>>> 42: @Fork(value = 1, jvmArgsAppend = {"--enable-preview"})
>> 
>> Suggestion:
>> 
>> @Fork(value = 1, jvmArgsAppend = {"--enable-preview",
>>                                   "--add-opens", "java.base/jdk.internal.classfile=ALL-UNNAMED",
>>                                   "--add-opens", "java.base/jdk.internal.classfile.constantpool=ALL-UNNAMED",
>>                                   "--add-opens", "java.base/jdk.internal.classfile.instruction=ALL-UNNAMED"})
>
> To make this runnable without manually adding a bunch of `--add-opens` flags

They are added in the `make/RunTests.gmk`: https://github.com/openjdk/jdk/pull/13550/files#diff-041bf69ea79b333b9ce99c1f879e398d698538530a35c361500b72631f059233R599-R608

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1188832580

From redestad at openjdk.org  Tue May  9 16:11:25 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 9 May 2023 16:11:25 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v3]
In-Reply-To: <lm5o9mUABTzGie9xW_WaMEPUMOIxH9DdtyOAsVRH7_g=.84288127-cdf4-4dab-a84a-9ce85c58a74f@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <exoJ1zXAbvWMBVIFmC-YCCUBYQE4dhYA-SKEMTNasbY=.b26fe531-70b6-44a3-8029-4977cf074dfd@github.com>
 <lm5o9mUABTzGie9xW_WaMEPUMOIxH9DdtyOAsVRH7_g=.84288127-cdf4-4dab-a84a-9ce85c58a74f@github.com>
Message-ID: <oG__BhgfsIYADPLbNEBBJep1SLvGAFPS6nbRiP48seI=.0d18c136-cfaa-4ccd-86c2-544493efc995@github.com>

On Tue, 9 May 2023 15:50:30 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed StackMapGenerator
>
> test/micro/org/openjdk/bench/jdk/classfile/RebuildMethodBodies.java line 42:
> 
>> 40: @BenchmarkMode(Mode.Throughput)
>> 41: @State(Scope.Benchmark)
>> 42: @Fork(value = 1, jvmArgsAppend = {"--enable-preview"})
> 
> Suggestion:
> 
> @Fork(value = 1, jvmArgsAppend = {"--enable-preview",
>                                   "--add-opens", "java.base/jdk.internal.classfile=ALL-UNNAMED",
>                                   "--add-opens", "java.base/jdk.internal.classfile.constantpool=ALL-UNNAMED",
>                                   "--add-opens", "java.base/jdk.internal.classfile.instruction=ALL-UNNAMED"})

To make this runnable without manually adding a bunch of `--add-opens` flags

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1188819270

From rrich at openjdk.org  Tue May  9 16:17:52 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 9 May 2023 16:17:52 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v28]
In-Reply-To: <9hDHgeACLaNP0lLQ7lXtWN07t6h4DDF5a9aaOTdvyMI=.932783da-eb49-4b9b-843b-fc564c6ffc41@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <9hDHgeACLaNP0lLQ7lXtWN07t6h4DDF5a9aaOTdvyMI=.932783da-eb49-4b9b-843b-fc564c6ffc41@github.com>
Message-ID: <17yuvkpMWGUKDER9SSdcPf2AP1b41i5P1Z907AOcfko=.7dc44835-eaaf-4fb1-a494-8109c7448297@github.com>

On Sat, 6 May 2023 19:38:36 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   libTestHFA: Add explicit type conversion to avoid build warning.

Hi Martin,

finally I've completed a pass over the hotspot part of the port. This seems a good point to share the few comments and questions I've collected so far.

In general the changes do look very good. Hardly any shared code changes.
Nice work!

Cheers, Richard.

src/hotspot/cpu/ppc/vmstorage_ppc.hpp line 81:

> 79:       case T_BYTE   :
> 80:       case T_SHORT  :
> 81:       case T_INT    : segment_mask = REG32_MASK; break;

I wonder why the segment_mask depends on `bt` on ppc?

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

PR Review: https://git.openjdk.org/jdk/pull/12708#pullrequestreview-1359503718
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1188808130

From rrich at openjdk.org  Tue May  9 16:18:06 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 9 May 2023 16:18:06 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v22]
In-Reply-To: <i_lgp3XQaEdsnbxlhXV2TG9vgbGeZj5LhYrFQrDxO2E=.ab081f0c-8350-46ee-b7c0-c4fe08b9c37c@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <i_lgp3XQaEdsnbxlhXV2TG9vgbGeZj5LhYrFQrDxO2E=.ab081f0c-8350-46ee-b7c0-c4fe08b9c37c@github.com>
Message-ID: <egE8yOpC518czk87a_8pp5NOO_K38HXJ0uLY57-1Qbk=.d9ce5f44-3ec3-4073-b99a-ad3e05c820ce@github.com>

On Tue, 18 Apr 2023 10:44:03 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Adaptation for JDK-8305668
>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>  - Move ABIv2CallArranger out of linux subdirectory. ABIv1/2 does match the AIX/linux separation.
>  - Adaptation for JDK-8303022.
>  - Adaptation for JDK-8303684.
>  - Merge branch 'openjdk:master' into PPC64_Panama
>  - Merge branch 'master' into PPC64_Panama
>  - Fix Copyright format.
>  - Fix storing 32 bit integers into Java frames. Enable TestArrayStructs.
>  - Allow TestHFA to run on musl. Add Upcalls.
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/3bba8995...725732a0

src/hotspot/cpu/ppc/frame_ppc.cpp line 219:

> 217:   UpcallStub* blob = _cb->as_upcall_stub();
> 218:   JavaFrameAnchor* jfa = blob->jfa_for_frame(*this);
> 219:   return jfa->last_Java_sp() == NULL;

Suggestion:

  return jfa->last_Java_sp() == nullptr;

I'd suggest to do the same for all occurrences in the patch.

src/hotspot/cpu/ppc/methodHandles_ppc.cpp line 316:

> 314:   // Load the invoker, as NEP -> .invoker
> 315:   __ verify_oop(nep_reg);
> 316:   __ ld(temp_target, jdk_internal_foreign_abi_NativeEntryPoint::downcall_stub_address_offset_in_bytes(), nep_reg);

Other platforms use `access_load_at`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1177973466
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1177985899

From rrich at openjdk.org  Tue May  9 16:17:59 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 9 May 2023 16:17:59 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v21]
In-Reply-To: <RCI233Y726or2PZQLlhyuv7YmZSchb5JNUalXqKpavQ=.b96ef488-eff9-4077-afb9-d94b55f07bfb@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <RCI233Y726or2PZQLlhyuv7YmZSchb5JNUalXqKpavQ=.b96ef488-eff9-4077-afb9-d94b55f07bfb@github.com>
Message-ID: <Q5rEaR0A7Ux8ny-pCDtlb37T514xciEeMVVHdX5Y8G8=.5ca8ad0e-8a2f-46ef-ae2c-2bbdafd8b7a4@github.com>

On Thu, 16 Mar 2023 14:42:10 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move ABIv2CallArranger out of linux subdirectory. ABIv1/2 does match the AIX/linux separation.

src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 185:

> 183: 
> 184:   allocated_frame_size = align_up(allocated_frame_size, StackAlignmentInBytes);
> 185:   _frame_size_slots = allocated_frame_size >> LogBytesPerInt;

`VMRegImpl::stack_slot_size` could be used when converting from size in bytes to size in slots.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1149547020

From rrich at openjdk.org  Tue May  9 16:18:09 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 9 May 2023 16:18:09 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v24]
In-Reply-To: <Vr9eU-MocRqojzzn5eDc29rLeIHY8vDHHrJClAQUGNc=.f8a666a5-7722-4d51-bba2-6abefde3d711@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <Vr9eU-MocRqojzzn5eDc29rLeIHY8vDHHrJClAQUGNc=.f8a666a5-7722-4d51-bba2-6abefde3d711@github.com>
Message-ID: <A2cb0DaijDLj7Bpu5uXB_RN5ZjERQdR1KMnH58W5x6s=.80ad17fd-c893-49ad-9ce4-b20733574a38@github.com>

On Thu, 27 Apr 2023 12:54:55 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert unintended formatting changes. Fix comment.

src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 202:

> 200: 
> 201:   MacroAssembler* _masm = new MacroAssembler(&buffer);
> 202:   address start = __ function_entry(); // called by C

If `!defined(ABI_ELFv2)` a function descriptor will be emitted here. It will be initialized with `friend_toc` and `friend_env`. But that's not correct for external callers, is it? If so, wouldn't an `Unimplemented()` be better than obscure crashes?

src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 236:

> 234:   __ block_comment("{ receiver ");
> 235:   __ load_const_optimized(R3_ARG1, (intptr_t)receiver, R0);
> 236:   __ resolve_jobject(R3_ARG1, tmp, R31, MacroAssembler::PRESERVATION_FRAME_LR_GP_FP_REGS); // kills R31

As a simplification the receiver could be resolved in `UpcallLinker::on_entry` and returned in `JavaThread::_vm_result`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1179416614
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1180394508

From redestad at openjdk.org  Tue May  9 16:18:52 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 9 May 2023 16:18:52 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v3]
In-Reply-To: <20aXsIS2b8aANbbHYb3XfI41OKiXki_ClNo0yFHOwm4=.4e09f65c-d506-434e-bc08-7d80bff8f5b4@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <exoJ1zXAbvWMBVIFmC-YCCUBYQE4dhYA-SKEMTNasbY=.b26fe531-70b6-44a3-8029-4977cf074dfd@github.com>
 <lm5o9mUABTzGie9xW_WaMEPUMOIxH9DdtyOAsVRH7_g=.84288127-cdf4-4dab-a84a-9ce85c58a74f@github.com>
 <oG__BhgfsIYADPLbNEBBJep1SLvGAFPS6nbRiP48seI=.0d18c136-cfaa-4ccd-86c2-544493efc995@github.com>
 <20aXsIS2b8aANbbHYb3XfI41OKiXki_ClNo0yFHOwm4=.4e09f65c-d506-434e-bc08-7d80bff8f5b4@github.com>
Message-ID: <srajMRPA71Fg4egkihtw6g7m30BYlFI2jC5Oxay2Qbk=.afd5413f-3f89-41e7-b24c-9dfa81f2a2a0@github.com>

On Tue, 9 May 2023 16:08:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> To make this runnable without manually adding a bunch of `--add-opens` flags
>
> They are added in the `make/RunTests.gmk`: https://github.com/openjdk/jdk/pull/13550/files#diff-041bf69ea79b333b9ce99c1f879e398d698538530a35c361500b72631f059233R599-R608

That seems misplaced. Please file an RFE to have this cleaned up. 

Each microbenchmark that has to add opens needs to take responsibility for that themselves and not change the environment for everything else. And all micros the benchmarks.jar should be runnable standalone, not rely on quirks in the make runner.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1188840349

From jlaskey at openjdk.org  Tue May  9 16:24:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 16:24:24 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v69]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <gSSu4Qochcw-uAqANO3_VCC5shkeMFjeyyqUZU3wPPI=.cd287eb8-87bf-4378-90c7-ed395fe164c5@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits:

 - Merge branch 'master' into 8285932
 - Dangling <p>
 - Recommended changes
 - Requested changes
 - CSR recommendations
 - Merge branch 'master' into 8285932
 - Spacing
 - Tidy up
 - Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes
 - Typo
 - ... and 78 more: https://git.openjdk.org/jdk/compare/44fa12e7...f4f26611

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=68
  Stats: 9330 lines in 73 files changed: 9233 ins; 23 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

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

From liach at openjdk.org  Tue May  9 16:26:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 16:26:08 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v68]
In-Reply-To: <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
Message-ID: <cC6vWaC5XidjKv1fz6EfLtnEJSwFegkRZE_RKgc07VI=.2b746469-a931-4895-bb79-60871bb91afd@github.com>

On Tue, 9 May 2023 12:58:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dangling <p>

TestJavacTaskScanner is failing because of the new `setPrevToken` added that changes the total element count. Just need to update the count to take the changes to `Scanner` into account.

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

PR Comment: https://git.openjdk.org/jdk/pull/10889#issuecomment-1540490098

From duke at openjdk.org  Tue May  9 16:27:21 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 9 May 2023 16:27:21 GMT
Subject: RFR: JDK-8151531: Add notes to BaseStream.spliterator/iterator
 docs regarding them being escape hatches [v2]
In-Reply-To: <HH3ibsbjPBEBIQ6HwCiglhnDLNhwYUNFKj435anND6s=.f6611227-f1f4-4ad0-af4c-04fa8390ac72@github.com>
References: <HH3ibsbjPBEBIQ6HwCiglhnDLNhwYUNFKj435anND6s=.f6611227-f1f4-4ad0-af4c-04fa8390ac72@github.com>
Message-ID: <D8M4L3Ae4wvLjX5WszSMyu2vNQCeA8fpcAjrvrtWRpc=.cf57f634-3a3f-41a7-92af-dae150c06817@github.com>

> Still relevant to address? /cc @PaulSandoz

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Using apiNote and rewording from method to operation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13890/files
  - new: https://git.openjdk.org/jdk/pull/13890/files/5082a0f5..4739a781

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

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

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

From duke at openjdk.org  Tue May  9 16:27:27 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 9 May 2023 16:27:27 GMT
Subject: RFR: JDK-8151531: Add notes to BaseStream.spliterator/iterator
 docs regarding them being escape hatches [v2]
In-Reply-To: <N4NpXNfJp-fRiddfAg_SUO3MSiKQh2EMTmTSFaJ4pJY=.5f34b06d-c09a-4b36-b122-65bdc459e37a@github.com>
References: <HH3ibsbjPBEBIQ6HwCiglhnDLNhwYUNFKj435anND6s=.f6611227-f1f4-4ad0-af4c-04fa8390ac72@github.com>
 <N4NpXNfJp-fRiddfAg_SUO3MSiKQh2EMTmTSFaJ4pJY=.5f34b06d-c09a-4b36-b122-65bdc459e37a@github.com>
Message-ID: <Sq4TEU5H1faWtJudI13o-8lgMNvRr1P2l5FeC7sHlJ0=.cfd15fa5-6782-4ead-aca2-e2b73027d986@github.com>

On Tue, 9 May 2023 16:06:12 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Using apiNote and rewording from method to operation
>
> I would recommend:
> - using `@apiNote` (might have to be placed at the end of the documentation); and 
> - say "This operation is provided ..."

@PaulSandoz Makes a lot of sense. Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/13890#issuecomment-1540490208

From psandoz at openjdk.org  Tue May  9 16:31:41 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 9 May 2023 16:31:41 GMT
Subject: RFR: JDK-8151531: Add notes to BaseStream.spliterator/iterator
 docs regarding them being escape hatches [v2]
In-Reply-To: <D8M4L3Ae4wvLjX5WszSMyu2vNQCeA8fpcAjrvrtWRpc=.cf57f634-3a3f-41a7-92af-dae150c06817@github.com>
References: <HH3ibsbjPBEBIQ6HwCiglhnDLNhwYUNFKj435anND6s=.f6611227-f1f4-4ad0-af4c-04fa8390ac72@github.com>
 <D8M4L3Ae4wvLjX5WszSMyu2vNQCeA8fpcAjrvrtWRpc=.cf57f634-3a3f-41a7-92af-dae150c06817@github.com>
Message-ID: <7cDGRMcNPNMIfVhZnRJYSNy4fohauvOwMX7lmLHf3Tw=.44fab866-8ae8-4d07-a9ec-863b34b21917@github.com>

On Tue, 9 May 2023 16:27:21 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Still relevant to address? /cc @PaulSandoz
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Using apiNote and rewording from method to operation

Marked as reviewed by psandoz (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13890#pullrequestreview-1419029873

From jlaskey at openjdk.org  Tue May  9 16:37:07 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 16:37:07 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v69]
In-Reply-To: <gSSu4Qochcw-uAqANO3_VCC5shkeMFjeyyqUZU3wPPI=.cd287eb8-87bf-4378-90c7-ed395fe164c5@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <gSSu4Qochcw-uAqANO3_VCC5shkeMFjeyyqUZU3wPPI=.cd287eb8-87bf-4378-90c7-ed395fe164c5@github.com>
Message-ID: <VpUv5E3jOqLwYbNZ1xOWJ66XkPl27KYKeoIZBXIaoh0=.ee44084f-cdb4-4808-befb-5b0d7fabe20e@github.com>

On Tue, 9 May 2023 16:24:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Dangling <p>
>  - Recommended changes
>  - Requested changes
>  - CSR recommendations
>  - Merge branch 'master' into 8285932
>  - Spacing
>  - Tidy up
>  - Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes
>  - Typo
>  - ... and 78 more: https://git.openjdk.org/jdk/compare/44fa12e7...f4f26611

Thanks for the heads up.

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

PR Comment: https://git.openjdk.org/jdk/pull/10889#issuecomment-1540506421

From liach at openjdk.org  Tue May  9 16:41:02 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 16:41:02 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of [v2]
In-Reply-To: <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
 <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
Message-ID: <ivdEfCbFqSYwPkttjhO6m3Q0eCii_sr4ICl9bPhHglk=.d342d479-ee1d-46be-ba51-8b7bdc80ddf6@github.com>

On Sun, 23 Apr 2023 23:44:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch adding two new convenience methods that allows easier access to MethodTypeDesc instances and its associated CSR as well. This is a necessity to allow #13186 to reduce array copies in a few scenarios; the implementation of the two methods will be updated there.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306698/1/java.base/java/lang/constant/MethodTypeDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update method type and specification, update tests

Can any developer for the constant API area take a look at this patch? This API enables sharing of immutable list for method type symbols.

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

PR Comment: https://git.openjdk.org/jdk/pull/13599#issuecomment-1540510289

From jlaskey at openjdk.org  Tue May  9 16:43:15 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 16:43:15 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v70]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <9L5IuWB-IyF4NqldYaPlYKVt-29_ykeIwOu8z-x9jbk=.bb0ecc60-87aa-4a92-a6a0-d67cdf61050c@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update TestJavacTaskScanner.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/f4f26611..6b09d2e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=69
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=68-69

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

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

From jlu at openjdk.org  Tue May  9 17:18:31 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 9 May 2023 17:18:31 GMT
Subject: Integrated: 8159337: Introduce a method in Locale class to return the
 language tags as per RFC 5646 convention
In-Reply-To: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
Message-ID: <5t6PS3dY3e-ZuSF0U6AVF8pbmynoAwHR59Xpeg7QIQU=.53872529-75aa-4d8e-89f8-179624233526@github.com>

On Wed, 26 Apr 2023 22:20:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
> 
> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
> 
> 
> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
> - Will not case fold variant subtags
> - Will not case fold private use subtags prefixed by "lvariant"
> 
> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.

This pull request has now been integrated.

Changeset: 82bcee76
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/82bcee76ea6f5a0624c3ed1d7e4a262d59bfbe37
Stats:     279 lines in 3 files changed: 274 ins; 3 del; 2 mod

8159337: Introduce a method in Locale class to return the language tags as per RFC 5646 convention

Reviewed-by: naoto, rriggs

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

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

From lmesnik at openjdk.org  Tue May  9 17:25:57 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 9 May 2023 17:25:57 GMT
Subject: RFR: 8307307: Improve ProcessTools.java to don't try to run
 Virtual wrapper for incompatible processes [v3]
In-Reply-To: <4XAvxExcDJxNOATuaxhHZvWcpBvt2Zhd2Bd7wuYqN1c=.86016870-ea81-423e-8f71-c44bfd2a8bad@github.com>
References: <4XAvxExcDJxNOATuaxhHZvWcpBvt2Zhd2Bd7wuYqN1c=.86016870-ea81-423e-8f71-c44bfd2a8bad@github.com>
Message-ID: <sDm1XNPJ9cJ9AWt785i2wT_f-YwTzlFiI-hPy35Xqjk=.a454404e-6796-4aeb-bf69-17a037d427e6@github.com>

> The ProcessTools has some support of jtreg thread factory functionality.
> It tries to run the new process using virtual thread to run `main()` method.
> This fix updates it to skip the java runs where no main class is involved and more correctly process options which has 2nd argument.
> Also is sets `main.wrapper` property to allow launched process understand id any wrappers is used.

Leonid Mesnik has updated the pull request with a new target base 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:

 - excluded failed tests
 - Merge branch 'master' of https://github.com/openjdk/jdk into 8307307
 - fixed some params
 - 8307307: Improve ProcessTools.java to don't try to run Virtual wrapper for incompatible processes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13808/files
  - new: https://git.openjdk.org/jdk/pull/13808/files/106be911..bbe57f2a

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

  Stats: 21542 lines in 477 files changed: 14730 ins; 3355 del; 3457 mod
  Patch: https://git.openjdk.org/jdk/pull/13808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13808/head:pull/13808

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

From duke at openjdk.org  Tue May  9 17:30:00 2023
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Tue, 9 May 2023 17:30:00 GMT
Subject: RFR: 8304148: Remapping a class with Invokedynamic constant loses
 static bootstrap arguments [v3]
In-Reply-To: <BRqOfbw2AgskyvSwhb6zwW0m-hDgAtW77OlztQcjOfA=.8ce1a503-d4e3-40d4-b1db-22610910ea3c@github.com>
References: <BRqOfbw2AgskyvSwhb6zwW0m-hDgAtW77OlztQcjOfA=.8ce1a503-d4e3-40d4-b1db-22610910ea3c@github.com>
Message-ID: <S5-Js-dAyNsvMNZkmtJju8G-10nS-tlwWmZEkEBzjfQ=.36c0b87e-d81c-478b-89a6-9042bdfe0c61@github.com>

> 8304148: Remapping a class with Invokedynamic constant loses static bootstrap arguments

Thiago Henrique H?pner has updated the pull request incrementally with one additional commit since the last revision:

  Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13021/files
  - new: https://git.openjdk.org/jdk/pull/13021/files/d6a4fc5d..3a056462

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

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

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

From ecaspole at openjdk.org  Tue May  9 17:31:07 2023
From: ecaspole at openjdk.org (Eric Caspole)
Date: Tue, 9 May 2023 17:31:07 GMT
Subject: RFR: 8307483: New micros for j.u.c.LockSupport [v2]
In-Reply-To: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
References: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
Message-ID: <I1M7whFYdOCU--KrJ7CNTclTS3YNJ3kQ6PW7FpxEQpQ=.08ab9167-ee7d-466b-8113-abc6c73e015b@github.com>

> These micros were developed while investigating JDK-8305670 by myself and Sergey Kuksenko. The order of thread creation was important in that bug, so there are 2 JMH for creating sleepers before and after the worker threads.

Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:

  Apply Aleksey's suggestions from code review
  
  Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13815/files
  - new: https://git.openjdk.org/jdk/pull/13815/files/2e67521c..96caa77a

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

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

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

From alanb at openjdk.org  Tue May  9 17:31:35 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 May 2023 17:31:35 GMT
Subject: RFR: 8307307: Improve ProcessTools.java to don't try to run
 Virtual wrapper for incompatible processes [v3]
In-Reply-To: <sDm1XNPJ9cJ9AWt785i2wT_f-YwTzlFiI-hPy35Xqjk=.a454404e-6796-4aeb-bf69-17a037d427e6@github.com>
References: <4XAvxExcDJxNOATuaxhHZvWcpBvt2Zhd2Bd7wuYqN1c=.86016870-ea81-423e-8f71-c44bfd2a8bad@github.com>
 <sDm1XNPJ9cJ9AWt785i2wT_f-YwTzlFiI-hPy35Xqjk=.a454404e-6796-4aeb-bf69-17a037d427e6@github.com>
Message-ID: <y1qmk4oBINezbbWf-XnaFgSjX4Pr8xkfK7EdyXUfO4Q=.7e606ed8-7729-4967-89e4-3ca19d7ceb2d@github.com>

On Tue, 9 May 2023 17:25:57 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> The ProcessTools has some support of jtreg thread factory functionality.
>> It tries to run the new process using virtual thread to run `main()` method.
>> This fix updates it to skip the java runs where no main class is involved and more correctly process options which has 2nd argument.
>> Also is sets `main.wrapper` property to allow launched process understand id any wrappers is used.
>
> Leonid Mesnik has updated the pull request with a new target base 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:
> 
>  - excluded failed tests
>  - Merge branch 'master' of https://github.com/openjdk/jdk into 8307307
>  - fixed some params
>  - 8307307: Improve ProcessTools.java to don't try to run Virtual wrapper for incompatible processes

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13808#pullrequestreview-1419132721

From duke at openjdk.org  Tue May  9 17:36:33 2023
From: duke at openjdk.org (Thiago Henrique =?UTF-8?B?SMO8cG5lcg==?=)
Date: Tue, 9 May 2023 17:36:33 GMT
Subject: Integrated: 8304148: Remapping a class with Invokedynamic constant
 loses static bootstrap arguments
In-Reply-To: <BRqOfbw2AgskyvSwhb6zwW0m-hDgAtW77OlztQcjOfA=.8ce1a503-d4e3-40d4-b1db-22610910ea3c@github.com>
References: <BRqOfbw2AgskyvSwhb6zwW0m-hDgAtW77OlztQcjOfA=.8ce1a503-d4e3-40d4-b1db-22610910ea3c@github.com>
Message-ID: <dAT-AFYURLHQ7kdRp15rrLhRXJDeFSZhDZZ9xFWL25c=.ba2009b8-63d3-4768-933e-51accf93f224@github.com>

On Tue, 14 Mar 2023 14:51:34 GMT, Thiago Henrique H?pner <duke at openjdk.org> wrote:

> 8304148: Remapping a class with Invokedynamic constant loses static bootstrap arguments

This pull request has now been integrated.

Changeset: dde557e3
Author:    Thiago Henrique H?pner <thihup at gmail.com>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dde557e312d4b8eaa9e01166329daa0fac488691
Stats:     3 lines in 2 files changed: 2 ins; 0 del; 1 mod

8304148: Remapping a class with Invokedynamic constant loses static bootstrap arguments

Reviewed-by: asotona

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

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

From lmesnik at openjdk.org  Tue May  9 18:09:27 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 9 May 2023 18:09:27 GMT
Subject: Integrated: 8307307: Improve ProcessTools.java to don't try to run
 Virtual wrapper for incompatible processes
In-Reply-To: <4XAvxExcDJxNOATuaxhHZvWcpBvt2Zhd2Bd7wuYqN1c=.86016870-ea81-423e-8f71-c44bfd2a8bad@github.com>
References: <4XAvxExcDJxNOATuaxhHZvWcpBvt2Zhd2Bd7wuYqN1c=.86016870-ea81-423e-8f71-c44bfd2a8bad@github.com>
Message-ID: <TRrLIEzH7Kzr4j0Vq1fX0Zrk9dbJavlfN20pHyIb1nI=.912646a2-c647-4883-82ce-c28e65c4a49f@github.com>

On Thu, 4 May 2023 15:52:36 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> The ProcessTools has some support of jtreg thread factory functionality.
> It tries to run the new process using virtual thread to run `main()` method.
> This fix updates it to skip the java runs where no main class is involved and more correctly process options which has 2nd argument.
> Also is sets `main.wrapper` property to allow launched process understand id any wrappers is used.

This pull request has now been integrated.

Changeset: 7f05f6f7
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f05f6f7c77c10dd2aed291af20664c9130e35f9
Stats:     35 lines in 2 files changed: 16 ins; 4 del; 15 mod

8307307: Improve ProcessTools.java to don't try to run Virtual wrapper for incompatible processes

Reviewed-by: alanb

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

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

From ecaspole at openjdk.org  Tue May  9 19:13:42 2023
From: ecaspole at openjdk.org (Eric Caspole)
Date: Tue, 9 May 2023 19:13:42 GMT
Subject: RFR: 8307483: New micros for j.u.c.LockSupport [v3]
In-Reply-To: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
References: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
Message-ID: <q77A4CdvYIyasyM1E1QsuBpNbrJ_QaNeAWGhHKaWKdM=.0bfb5dea-c9bf-4325-b3aa-0f88f76fc845@github.com>

> These micros were developed while investigating JDK-8305670 by myself and Sergey Kuksenko. The order of thread creation was important in that bug, so there are 2 JMH for creating sleepers before and after the worker threads.

Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:

  Add review comments changes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13815/files
  - new: https://git.openjdk.org/jdk/pull/13815/files/96caa77a..4a486cfd

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

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

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

From jlu at openjdk.org  Tue May  9 20:47:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 9 May 2023 20:47:51 GMT
Subject: RFR: 8281103: Give example for Locale that is English and follows the
 ISO standards
Message-ID: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>

Please review this PR which adds an example snippet to `java.time.temporal.WeekFields.of(Locale locale)`

The snippet demonstrates how to create a Locale that has English Locale qualities with an ISO-8601 first day of the week. 

This snippet was added as there was a desire for an English/ISO-8601 Locale constant to be added, but the existing methods in the JDK are better suited for accomplishing this.

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

Commit messages:
 - Correct param in example
 - Copyright year
 - JDK-8281103

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

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

From rriggs at openjdk.org  Tue May  9 20:54:34 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 May 2023 20:54:34 GMT
Subject: Integrated: 8307466: java.time.Instant calculation bug in until and
 between methods
In-Reply-To: <TbOVsPh3u2tsHDgnDl6bg7DM7zDW7A0KTcM3PpMODfQ=.c27d4486-6c5d-4828-9d31-83ce21a7d26b@github.com>
References: <TbOVsPh3u2tsHDgnDl6bg7DM7zDW7A0KTcM3PpMODfQ=.c27d4486-6c5d-4828-9d31-83ce21a7d26b@github.com>
Message-ID: <ip9GZpRB7A82CE3r7MGrySqdsZD2VVMVqyLi51PXS1E=.8d46138c-7fcc-4265-8f88-376461276cb2@github.com>

On Fri, 5 May 2023 21:28:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The implementation of java.time.Instant.until(I2, ChronoUnit) in some cases did not correctly borrow or carry from the nanos to the seconds when computing using ChronoUnit.MILLIS or ChronoUnit.MICROS.
> The errant computation was introduced by [JDK-8273369](https://bugs.openjdk.org/browse/JDK-8273369).

This pull request has now been integrated.

Changeset: 356667f1
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/356667f1559396b09e0b830d92978f2ea7a9300b
Stats:     78 lines in 2 files changed: 70 ins; 0 del; 8 mod

8307466: java.time.Instant calculation bug in until and between methods

Co-authored-by: Raffaello Giulietti <rgiulietti at openjdk.org>
Reviewed-by: scolebourne, naoto

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

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

From rriggs at openjdk.org  Tue May  9 20:57:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 May 2023 20:57:18 GMT
Subject: RFR: 8281103: Give example for Locale that is English and follows
 the ISO standards
In-Reply-To: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
References: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
Message-ID: <fWZWfwGK_9CS91zVL6JLyIImwv62fi95J9dTe5Z8D5o=.1b004d4c-d7f8-4a03-8e3e-bee5c7e1da09@github.com>

On Tue, 9 May 2023 20:39:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds an example snippet to `java.time.temporal.WeekFields.of(Locale locale)`
> 
> The snippet demonstrates how to create a Locale that has English Locale qualities with an ISO-8601 first day of the week. 
> 
> This snippet was added as there was a desire for an English/ISO-8601 Locale constant to be added, but the existing methods in the JDK are better suited for accomplishing this.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13893#pullrequestreview-1419440879

From lancea at openjdk.org  Tue May  9 21:03:24 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 9 May 2023 21:03:24 GMT
Subject: RFR: 8281103: Give example for Locale that is English and follows
 the ISO standards
In-Reply-To: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
References: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
Message-ID: <f3uLD_eHAILXkN4jhUE2QGi2u88xsogyUdiqw_2Y4SI=.1707d87d-3198-4216-90a8-17f57b0de645@github.com>

On Tue, 9 May 2023 20:39:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds an example snippet to `java.time.temporal.WeekFields.of(Locale locale)`
> 
> The snippet demonstrates how to create a Locale that has English Locale qualities with an ISO-8601 first day of the week. 
> 
> This snippet was added as there was a desire for an English/ISO-8601 Locale constant to be added, but the existing methods in the JDK are better suited for accomplishing this.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13893#pullrequestreview-1419448467

From naoto at openjdk.org  Tue May  9 21:12:18 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 May 2023 21:12:18 GMT
Subject: RFR: 8281103: Give example for Locale that is English and follows
 the ISO standards
In-Reply-To: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
References: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
Message-ID: <Qj0NeP2sipC3XrYfzmXX6lzUjX6w2IAlmN2Jq6tz70U=.618ed9e4-071b-4f4f-9819-313b4a7d63c4@github.com>

On Tue, 9 May 2023 20:39:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds an example snippet to `java.time.temporal.WeekFields.of(Locale locale)`
> 
> The snippet demonstrates how to create a Locale that has English Locale qualities with an ISO-8601 first day of the week. 
> 
> This snippet was added as there was a desire for an English/ISO-8601 Locale constant to be added, but the existing methods in the JDK are better suited for accomplishing this.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13893#pullrequestreview-1419459581

From duke at openjdk.org  Tue May  9 21:16:47 2023
From: duke at openjdk.org (iaroslavski)
Date: Tue, 9 May 2023 21:16:47 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v19]
In-Reply-To: <ptbz4GUKNgTgItey6ipARJZDOM-rim2EMakqRvxVNVo=.aaa9c0f0-5f12-4804-8027-ba88ab34e9e4@github.com>
References: <8CwTPTO3LHUzkcn1tznXnWv3j7mKevPTrJCEDbBwAA8=.0347ef73-b94d-46a3-a768-b796082c832d@github.com>
 <ptbz4GUKNgTgItey6ipARJZDOM-rim2EMakqRvxVNVo=.aaa9c0f0-5f12-4804-8027-ba88ab34e9e4@github.com>
Message-ID: <4sp0olCiUFRzeQGPjoRKQfrJ1mprlOOB8jaJ9p7tGLc=.00910446-e3ad-49a0-a295-2f5a5c620318@github.com>

On Sun, 12 Mar 2023 21:28:59 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)
>   
>   * Use uninitialized array for buffers

Keeping this PR for a while

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

PR Comment: https://git.openjdk.org/jdk/pull/3938#issuecomment-1540898854

From jiangli at openjdk.org  Tue May  9 21:34:43 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 9 May 2023 21:34:43 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v8]
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <Ys6BHg2v1OVZr1G1nK4waywY8Tx0x69OdvLZct-g5Ps=.fc0333d9-cc54-4177-ae07-5078e5602d52@github.com>

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries
> 
> - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>  
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS:
  
  - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk.
  
  - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS).
  - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/<JVM_VARIANTS>. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/<variant> directory.
  
  - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13768/files
  - new: https://git.openjdk.org/jdk/pull/13768/files/2cb786ab..cf317d36

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

  Stats: 107 lines in 5 files changed: 32 ins; 60 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13768.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768

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

From jiangli at openjdk.org  Tue May  9 21:46:42 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 9 May 2023 21:46:42 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v9]
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <eEvFjN0m0w1oXJ1RBs9pkyNCuSFxOkscjV0GyYu7dag=.2847f148-a063-46e5-8a47-74f18053a0fc@github.com>

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries
> 
> - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>  
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Fix whitspace errors.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13768/files
  - new: https://git.openjdk.org/jdk/pull/13768/files/cf317d36..d30b3e34

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

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

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

From jiangli at openjdk.org  Tue May  9 21:47:32 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 9 May 2023 21:47:32 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v7]
In-Reply-To: <oZE6EqxKgAW5zxITQm0PnmwSkSO14W48jyqLHM6Wz_I=.24e187c0-d4bb-4d1c-aebe-2e2c6328397e@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <8dtK0FqK9HEYBUOi07iWmNkLMm5F_T0sPlo8T2bpKN0=.55e338af-e78e-4967-a950-30bb265cfef2@github.com>
 <rIFR8lzb8zKI5f0h_VcaherfoEEtQqeX2C0UyApAqeE=.bb53bbe4-4bf6-4c22-9bff-a2b357397cce@github.com>
 <2BVvV9m8bI-UzZXpX1GEPwoStZ6pHZBn4JuAMRQk978=.54246fe4-57b8-4372-bfc4-6b63823fa9a2@github.com>
 <oZE6EqxKgAW5zxITQm0PnmwSkSO14W48jyqLHM6Wz_I=.24e187c0-d4bb-4d1c-aebe-2e2c6328397e@github.com>
Message-ID: <DVB7w03QYm8NSvTxdNZX_TVBYnpiWZsqFibJlXS89LU=.532fb07e-7a16-4ff4-a7f5-e7051deb608d@github.com>

On Mon, 8 May 2023 19:45:18 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > > All of that said, I think we can get away with a smaller subset of targets and deliverables. AFAIK, graal needs the combined `graal-builder-image` as input to their build anyway, so they should not have any dependency on what the target `static-libs-image` produces. Given that I propose the following behavior:
> > > `make static-libs-image` produces `images/static-libs` with all .a (including libjvm.a). `make static-libs-graal-image` produces `images/static-libs-graal` with all .a except libjvm.a. `make graal-builder-image` produces `images/graal-builder-image` like today, but depends on and uses `static-libs-graal-image` instead of `static-libs-image`. `make static-libs-bundles` depends on and uses `static-libs-image` like today, so will contain libjvm.a, which is new behavior.
> > 
> > 
> > Sure, that should work too as long as there is a way to a) build the static libs only needed for graal some way b) keep `graal-builder-image` working as it does today. FWIW, we use `a)` at adoptium so as to be able to have a combination to build mandrel from. Not all users will want to have JDK + static libs so only the ones needing them should need to download them.
> 
> Thanks @erikj79 @jerboaa. We can go with what @erikj79 suggested then. I'll revise the PR.

@erikj79 and @jerboaa please please review the updated version, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1540931243

From acobbs at openjdk.org  Tue May  9 22:13:34 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 9 May 2023 22:13:34 GMT
Subject: RFR: 8305748: Clarify reentrant behavior of close() in
 FileInputStream, FileOutputStream, and RandomAccessFile [v3]
In-Reply-To: <RraYLzBv8h4DYRPcJWc32nsXMUq-icAEem6XvzIBP-A=.0708429e-61af-4e3e-ae1e-3b96a70f38d0@github.com>
References: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
 <RraYLzBv8h4DYRPcJWc32nsXMUq-icAEem6XvzIBP-A=.0708429e-61af-4e3e-ae1e-3b96a70f38d0@github.com>
Message-ID: <NxON32uBVc_s0fU-ZfwC5Gj8oK_GvclJ_02Z1fOxSeM=.a352b9af-acbf-4aa0-aa4e-5fd7e9652b7b@github.com>

On Fri, 7 Apr 2023 18:24:42 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> IO stream classes like `FileOutputStream` can have assocated NIO channels.
>> 
>> When `close()` is invoked on one of these classes, it in turn invokes `close()` on the associated channel (if any). But when the associated channel's `close()` method is invoked, it in turn invokes `close()` on the associated stream (if any).
>> 
>> As a result, these IO stream `close()` methods invoke themselves reentrantly when there is an associated channel.
>> 
>> This is not a problem for these classes because they are written to handle this (i.e., they are idempotent), but it can be surprising (or worse, just silently bug-inducing) for subclasses that override `close()`.
>> 
>> There are two possible ways to address this:
>> 1. Modify the code to detect and avoid the (unnecessary) reentrant invocations
>> 2. Add a `@implNote` to the Javadoc so subclass implementers are made aware
>> 
>> This patch takes the second, more conservative approach.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments.

pingbot

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

PR Comment: https://git.openjdk.org/jdk/pull/13379#issuecomment-1540952824

From erikj at openjdk.org  Tue May  9 22:17:18 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 9 May 2023 22:17:18 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v9]
In-Reply-To: <eEvFjN0m0w1oXJ1RBs9pkyNCuSFxOkscjV0GyYu7dag=.2847f148-a063-46e5-8a47-74f18053a0fc@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <eEvFjN0m0w1oXJ1RBs9pkyNCuSFxOkscjV0GyYu7dag=.2847f148-a063-46e5-8a47-74f18053a0fc@github.com>
Message-ID: <8-kD9iBw0LboYiC_RJnaHZdxySrxXG15ENceHPSt2qo=.8d0beed0-409d-4ba9-9b3e-bbb1cedceb6b@github.com>

On Tue, 9 May 2023 21:46:42 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries
>> 
>> - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>>  
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix whitspace errors.

I think you also need to make a change to `GraalBuilderImage.gmk` and the target in `Main.gmk` that calls it.

Otherwise this looks pretty good to me.

make/Main.gmk line 1281:

> 1279: all-bundles: product-bundles test-bundles docs-bundles static-libs-bundles
> 1280: 
> 1281: ALL_TARGETS += buildtools hotspot hotspot-libs hotspot-static-libs hotspot-gensrc gensrc gendata \

Can you add a newline to try to keep line length in check here. No need to reformat the whole block, just don't let random lines shoot way over 80.

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

PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1419519027
PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1189176422

From jiangli at openjdk.org  Tue May  9 23:06:23 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 9 May 2023 23:06:23 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v10]
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com>

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries
> 
> - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>  
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Address comments from @erikj79:
  - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk.
  - Split the long line at 1281 in Main.gmk.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13768/files
  - new: https://git.openjdk.org/jdk/pull/13768/files/d30b3e34..45dd2a00

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

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

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

From jiangli at openjdk.org  Tue May  9 23:08:27 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 9 May 2023 23:08:27 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v9]
In-Reply-To: <8-kD9iBw0LboYiC_RJnaHZdxySrxXG15ENceHPSt2qo=.8d0beed0-409d-4ba9-9b3e-bbb1cedceb6b@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <eEvFjN0m0w1oXJ1RBs9pkyNCuSFxOkscjV0GyYu7dag=.2847f148-a063-46e5-8a47-74f18053a0fc@github.com>
 <8-kD9iBw0LboYiC_RJnaHZdxySrxXG15ENceHPSt2qo=.8d0beed0-409d-4ba9-9b3e-bbb1cedceb6b@github.com>
Message-ID: <GQT0-hGVohVA3oc_oZdlzGTF1hqsTd5CdNzkRG8FB80=.47d8e77a-604c-423e-9f58-93e8b0b691ce@github.com>

On Tue, 9 May 2023 22:14:04 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I think you also need to make a change to `GraalBuilderImage.gmk` and the target in `Main.gmk` that calls it.

Good catch! Fixed `GraalBuilderImage.gmk`, thanks!

For the `graal-builder-image` target that uses `GraalBuilderImage.gmk`, it's already changed to use `static-libs-graal-image` as one of the DEPS. Please let me know if anything additional that I missed.

> make/Main.gmk line 1281:
> 
>> 1279: all-bundles: product-bundles test-bundles docs-bundles static-libs-bundles
>> 1280: 
>> 1281: ALL_TARGETS += buildtools hotspot hotspot-libs hotspot-static-libs hotspot-gensrc gensrc gendata \
> 
> Can you add a newline to try to keep line length in check here. No need to reformat the whole block, just don't let random lines shoot way over 80.

Done, thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1540998009
PR Review Comment: https://git.openjdk.org/jdk/pull/13768#discussion_r1189206701

From duke at openjdk.org  Tue May  9 23:22:28 2023
From: duke at openjdk.org (duke)
Date: Tue, 9 May 2023 23:22:28 GMT
Subject: Withdrawn: 8302872: Speed up StringLatin1.regionMatchesCI_UTF16
In-Reply-To: <4SMUYcB8RTO3-nB444DCUHNcdDCmcO7WtCBCf7Gc9KM=.c8f2ab0b-1b72-461b-88e8-135318e092cc@github.com>
References: <4SMUYcB8RTO3-nB444DCUHNcdDCmcO7WtCBCf7Gc9KM=.c8f2ab0b-1b72-461b-88e8-135318e092cc@github.com>
Message-ID: <ZH6kjU9CDlYQoOzFe20uLjXz4eb4Q25c4MelLiKPi5M=.09fe67c7-1947-4c3f-b53a-94a1e3f4eb09@github.com>

On Sat, 18 Feb 2023 18:22:49 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR continues the efforts from #12632 to speed up case-insensitive string matching.
> 
> We now tackle case-insensitive comparison of mixed-coder strings, implemented in `StringLatin1.regionMatchesCI_UTF16`
> 
> Key insights:
> 
> - If the UTF16 code point is also in latin1 range, we can leverage improvements from 12632 directly by calling `CharacterDataLatin1.equalsIgnoreCase`
> - There are exactly 7 non-latin1 Unicode code points which case fold into the latin1 range. We can special-case our comparison of these code points by adding the method `CharacterDataLatin1.latin1CaseFold`.
> - To avoid checking of `a == b` twice, this check is lifted out of `CharacterDataLatin1.equalsIgnoreCase` and the two callers are updated to check that `a != b` before calling the method. 
>  
> For completeness, the RegionMatches test is updated to also compare Turkic dotted/dotless 'i's against the uppercase ASCII 'I', not just the lowercase one.  Not stricktly related to the purpose of this PR, but it did help catch a regression introduced in an earlier iteration of the PR.   
> 
> To guard against regressions caused by future changes to the set of Unicode code points folding into latin1, a new test is added to `EqualsIgnoreCase` which identifies all such code points and verifies they are compared correcty.
> 
> Performance is tested for matching and mismatching cases of selected code point pairs picked from the ASCII letter, ASCII number, latin1 letter and non-latin Unicode letter ranges. Results in the first comment below.

This pull request has been closed without being integrated.

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

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

From bpb at openjdk.org  Wed May 10 01:18:37 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 10 May 2023 01:18:37 GMT
Subject: RFR: 8305748: Clarify reentrant behavior of close() in
 FileInputStream, FileOutputStream, and RandomAccessFile [v3]
In-Reply-To: <NxON32uBVc_s0fU-ZfwC5Gj8oK_GvclJ_02Z1fOxSeM=.a352b9af-acbf-4aa0-aa4e-5fd7e9652b7b@github.com>
References: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
 <RraYLzBv8h4DYRPcJWc32nsXMUq-icAEem6XvzIBP-A=.0708429e-61af-4e3e-ae1e-3b96a70f38d0@github.com>
 <NxON32uBVc_s0fU-ZfwC5Gj8oK_GvclJ_02Z1fOxSeM=.a352b9af-acbf-4aa0-aa4e-5fd7e9652b7b@github.com>
Message-ID: <xgUpVQgH0WNpo_9zp3kMkPcldVthdOdoYXiL99BtSY8=.0a963177-d2fd-433f-8697-77a984d624f9@github.com>

On Tue, 9 May 2023 22:10:22 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> pingbot

Thanks for the reminder. Too late to sponsor today so tomorrow.

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

PR Comment: https://git.openjdk.org/jdk/pull/13379#issuecomment-1541124772

From alanb at openjdk.org  Wed May 10 01:23:37 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 May 2023 01:23:37 GMT
Subject: RFR: 8303530: Add system property for custom JAXP configuration
 file [v11]
In-Reply-To: <qI282STKG_sL2MFdI-DYw9NP0P2-veK7mkNWmfenQhc=.9f72d3de-acc9-464f-a08d-e9b9c02eac9a@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <qI282STKG_sL2MFdI-DYw9NP0P2-veK7mkNWmfenQhc=.9f72d3de-acc9-464f-a08d-e9b9c02eac9a@github.com>
Message-ID: <9L3gcsoPMzKGzQTnl3n0PgJ4cF3O2cOaKT3OYdV_YLI=.16295c89-c1d6-4892-91d9-d1a6ffd6bd5d@github.com>

On Tue, 2 May 2023 20:16:15 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
>> 
>> CSR: https://bugs.openjdk.org/browse/JDK-8303531
>> 
>> Tests: XML SQE and JCK tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

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

> 90:  * <h3 id="CF_SP">User-defined Configuration File</h3>
> 91:  * A system property {@systemProperty java.xml.config.file} can be set on the
> 92:  * command line or through the System API (e.g. System.setProperty method) to

"or through the System API (e.g. System.setProperty)" could be improved to make it clear that the system property can be set at run-time with System.setProperty (add link).

src/java.xml/share/conf/jaxp.properties line 2:

> 1: ################################################################################
> 2: #           XML Library (java.xml) Configuration File

The file is jaxp.properties and the module is Java APIs for XML Processing. The use of "XML Library (java.xml)" is confusing here, I'm concerned that it will be inconsistent with all the existing docs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1185816062
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1185817940

From duke at openjdk.org  Wed May 10 07:48:14 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 10 May 2023 07:48:14 GMT
Subject: RFR: JDK-8151531: Add notes to BaseStream.spliterator/iterator
 docs regarding them being escape hatches [v2]
In-Reply-To: <7cDGRMcNPNMIfVhZnRJYSNy4fohauvOwMX7lmLHf3Tw=.44fab866-8ae8-4d07-a9ec-863b34b21917@github.com>
References: <HH3ibsbjPBEBIQ6HwCiglhnDLNhwYUNFKj435anND6s=.f6611227-f1f4-4ad0-af4c-04fa8390ac72@github.com>
 <D8M4L3Ae4wvLjX5WszSMyu2vNQCeA8fpcAjrvrtWRpc=.cf57f634-3a3f-41a7-92af-dae150c06817@github.com>
 <7cDGRMcNPNMIfVhZnRJYSNy4fohauvOwMX7lmLHf3Tw=.44fab866-8ae8-4d07-a9ec-863b34b21917@github.com>
Message-ID: <yL65aPi3sEdgJYGl43B6YshyPW6-fYirPOTDGJ3wl2g=.f24ff90a-d2f0-4017-9041-3d8d3faa9298@github.com>

On Tue, 9 May 2023 16:28:52 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Using apiNote and rewording from method to operation
>
> Marked as reviewed by psandoz (Reviewer).

@PaulSandoz Forgot to update copyright year so added that as well

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

PR Comment: https://git.openjdk.org/jdk/pull/13890#issuecomment-1541507232

From duke at openjdk.org  Wed May 10 07:48:11 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 10 May 2023 07:48:11 GMT
Subject: RFR: JDK-8151531: Add notes to BaseStream.spliterator/iterator
 docs regarding them being escape hatches [v3]
In-Reply-To: <HH3ibsbjPBEBIQ6HwCiglhnDLNhwYUNFKj435anND6s=.f6611227-f1f4-4ad0-af4c-04fa8390ac72@github.com>
References: <HH3ibsbjPBEBIQ6HwCiglhnDLNhwYUNFKj435anND6s=.f6611227-f1f4-4ad0-af4c-04fa8390ac72@github.com>
Message-ID: <3mjQIGtCDIJMF8oBR1VVR-G3cxOG7F1u_GsD41MT8Zs=.11286233-e2d2-4b05-a6ae-469c5422c281@github.com>

> Still relevant to address? /cc @PaulSandoz

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Updating copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13890/files
  - new: https://git.openjdk.org/jdk/pull/13890/files/4739a781..3f1cb743

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

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

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

From mcimadamore at openjdk.org  Wed May 10 09:03:32 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 10 May 2023 09:03:32 GMT
Subject: RFR: 8307610: Linker::nativeLinker should not be restricted
 (mainline) [v3]
In-Reply-To: <8owRB5GDdEv2aRLKJO3NHtMNoXnmCf3Pd2GfwUtO-Go=.f6234082-15f1-4f3e-ba69-22818a86e984@github.com>
References: <8owRB5GDdEv2aRLKJO3NHtMNoXnmCf3Pd2GfwUtO-Go=.f6234082-15f1-4f3e-ba69-22818a86e984@github.com>
Message-ID: <4Z_J4asGDViDY0FU_UtjV4qzt8w6nsjqyy_6_Z38GUs=.07d020c8-e923-4534-8ede-c84a44667430@github.com>

> Port of: https://git.openjdk.org/panama-foreign/pull/831

Maurizio Cimadamore 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 linker_restricted
 - Address review comment
 - Cleanup code so that restricted method check is shared
 - Initial push

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

Changes: https://git.openjdk.org/jdk/pull/13863/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13863&range=02
  Stats: 128 lines in 11 files changed: 65 ins; 17 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/13863.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13863/head:pull/13863

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

From sgehwolf at openjdk.org  Wed May 10 09:08:21 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 10 May 2023 09:08:21 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v10]
In-Reply-To: <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com>
Message-ID: <tzL-0CCJLRuR5MucARl8HQG9MEg43FOUys3aDIEAQQs=.5b83bb48-ad09-407b-95be-0557fb8d1bf8@github.com>

On Tue, 9 May 2023 23:06:23 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries
>> 
>> - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>>  
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments from @erikj79:
>   - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk.
>   - Split the long line at 1281 in Main.gmk.

Looks fine to me.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1420136948

From aefimov at openjdk.org  Wed May 10 09:42:32 2023
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 10 May 2023 09:42:32 GMT
Subject: Integrated: 8302845: Replace finalizer usage in JNDI DNS provider with
 Cleaner
In-Reply-To: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
References: <SpszUAKnClh7U3M6EyJVAjUkQPu_W7qF0MeGU3GLQzU=.3f2623ed-f10b-4060-914d-29af8df53870@github.com>
Message-ID: <vRE77BLdz8luvd8xH_Vwhd-ikwEOax2I5Gzy2NYOcpU=.0146503d-4970-4a19-9842-abe19b4708c9@github.com>

On Fri, 5 May 2023 17:25:38 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> JNDI `DnsClient` has a finalize method to close its internal datagram channel selector.
>  The change proposed here replaces it with a cleaner to close the selector once the `DnsClient`
>   instance becomes phantom reachable. 
> 
> The change was tested with `jdk-tier1` to `jdk-tier3` test sets which showed no failures.

This pull request has now been integrated.

Changeset: da2c9302
Author:    Aleksei Efimov <aefimov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da2c9302628886bbdb4cf588f8275c4a44ff5ac9
Stats:     31 lines in 3 files changed: 14 ins; 13 del; 4 mod

8302845: Replace finalizer usage in JNDI DNS provider with Cleaner

Reviewed-by: alanb, dfuchs, djelinski

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

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

From asotona at openjdk.org  Wed May 10 10:00:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 10 May 2023 10:00:48 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v4]
In-Reply-To: <srajMRPA71Fg4egkihtw6g7m30BYlFI2jC5Oxay2Qbk=.afd5413f-3f89-41e7-b24c-9dfa81f2a2a0@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <exoJ1zXAbvWMBVIFmC-YCCUBYQE4dhYA-SKEMTNasbY=.b26fe531-70b6-44a3-8029-4977cf074dfd@github.com>
 <lm5o9mUABTzGie9xW_WaMEPUMOIxH9DdtyOAsVRH7_g=.84288127-cdf4-4dab-a84a-9ce85c58a74f@github.com>
 <oG__BhgfsIYADPLbNEBBJep1SLvGAFPS6nbRiP48seI=.0d18c136-cfaa-4ccd-86c2-544493efc995@github.com>
 <20aXsIS2b8aANbbHYb3XfI41OKiXki_ClNo0yFHOwm4=.4e09f65c-d506-434e-bc08-7d80bff8f5b4@github.com>
 <srajMRPA71Fg4egkihtw6g7m30BYlFI2jC5Oxay2Qbk=.afd5413f-3f89-41e7-b24c-9dfa81f2a2a0@github.com>
Message-ID: <Ap01N_44Cl9vPmauuslvxJYaRhOv2kM10D4p-Nr0Ac8=.00491552-fabe-43ff-abd4-21b3ac4de561@github.com>

On Tue, 9 May 2023 16:15:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> They are added in the `make/RunTests.gmk`: https://github.com/openjdk/jdk/pull/13550/files#diff-041bf69ea79b333b9ce99c1f879e398d698538530a35c361500b72631f059233R599-R608
>
> That seems misplaced. Please file an RFE to have this cleaned up. 
> 
> Each microbenchmark that has to add opens needs to take responsibility for that themselves and not change the environment for everything else. And all micros the benchmarks.jar should be runnable standalone, not rely on quirks in the make runner.

All benchmarks fixed and --add-exports removed from make file.
Thank you for pointing this out.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1189664602

From asotona at openjdk.org  Wed May 10 10:00:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 10 May 2023 10:00:47 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v4]
In-Reply-To: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
Message-ID: <44odsoRkRp6mmgfPKFCPOy-uaHNOgOgPQUJICERzHKU=.5703da5a-0e66-45a2-af0b-23ac0665fbe7@github.com>

> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
> - Caching `MethodTypeDesc` in `MethodInfo` implementations
> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
> 
> No API change.
> 
> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
> 
> 
> Benchmark                     Mode  Cnt       Score       Error  Units
> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
> 
> 
> 
> Benchmark                     Mode  Cnt       Score      Error  Units
> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s

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

  fixed jmh benchmark parameters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13671/files
  - new: https://git.openjdk.org/jdk/pull/13671/files/5af9f9c4..3cbb11c2

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

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

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

From redestad at openjdk.org  Wed May 10 10:21:28 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 10 May 2023 10:21:28 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v4]
In-Reply-To: <Ap01N_44Cl9vPmauuslvxJYaRhOv2kM10D4p-Nr0Ac8=.00491552-fabe-43ff-abd4-21b3ac4de561@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <exoJ1zXAbvWMBVIFmC-YCCUBYQE4dhYA-SKEMTNasbY=.b26fe531-70b6-44a3-8029-4977cf074dfd@github.com>
 <lm5o9mUABTzGie9xW_WaMEPUMOIxH9DdtyOAsVRH7_g=.84288127-cdf4-4dab-a84a-9ce85c58a74f@github.com>
 <oG__BhgfsIYADPLbNEBBJep1SLvGAFPS6nbRiP48seI=.0d18c136-cfaa-4ccd-86c2-544493efc995@github.com>
 <20aXsIS2b8aANbbHYb3XfI41OKiXki_ClNo0yFHOwm4=.4e09f65c-d506-434e-bc08-7d80bff8f5b4@github.com>
 <srajMRPA71Fg4egkihtw6g7m30BYlFI2jC5Oxay2Qbk=.afd5413f-3f89-41e7-b24c-9dfa81f2a2a0@github.com>
 <Ap01N_44Cl9vPmauuslvxJYaRhOv2kM10D4p-Nr0Ac8=.00491552-fabe-43ff-abd4-21b3ac4de561@github.com>
Message-ID: <H0zbK96rIlNRY0Ttll0xh8TXWexY2S2XJEQlbdTkIQQ=.9f181c9f-3351-405a-beee-70c274fc7a4f@github.com>

On Wed, 10 May 2023 09:55:13 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> That seems misplaced. Please file an RFE to have this cleaned up. 
>> 
>> Each microbenchmark that has to add opens needs to take responsibility for that themselves and not change the environment for everything else. And all micros the benchmarks.jar should be runnable standalone, not rely on quirks in the make runner.
>
> All benchmarks fixed and --add-exports removed from make file.
> Thank you for pointing this out.

Thanks for fixing this!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1189692833

From mdoerr at openjdk.org  Wed May 10 10:57:46 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 May 2023 10:57:46 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v29]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <bYPc3viZXNMyh_4NbEwXBPoF7MTBDj3Cb_RymW9L63o=.90b7664f-d7e9-42a8-8239-f515fc3b925e@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Replace NULL by nullptr.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/74586ab8..93060258

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=27-28

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

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

From mdoerr at openjdk.org  Wed May 10 11:05:36 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 May 2023 11:05:36 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v21]
In-Reply-To: <Q5rEaR0A7Ux8ny-pCDtlb37T514xciEeMVVHdX5Y8G8=.5ca8ad0e-8a2f-46ef-ae2c-2bbdafd8b7a4@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <RCI233Y726or2PZQLlhyuv7YmZSchb5JNUalXqKpavQ=.b96ef488-eff9-4077-afb9-d94b55f07bfb@github.com>
 <Q5rEaR0A7Ux8ny-pCDtlb37T514xciEeMVVHdX5Y8G8=.5ca8ad0e-8a2f-46ef-ae2c-2bbdafd8b7a4@github.com>
Message-ID: <ghuqoMb-SMlyJQrmzXcbBRlUIlLBhXy1ee7pwCTs44g=.90eff21e-11f4-4060-8e2f-73d1d3ccf511@github.com>

On Mon, 27 Mar 2023 16:54:31 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move ABIv2CallArranger out of linux subdirectory. ABIv1/2 does match the AIX/linux separation.
>
> src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 185:
> 
>> 183: 
>> 184:   allocated_frame_size = align_up(allocated_frame_size, StackAlignmentInBytes);
>> 185:   _frame_size_slots = allocated_frame_size >> LogBytesPerInt;
> 
> `VMRegImpl::stack_slot_size` could be used when converting from size in bytes to size in slots.

Yes, I think this would be better readable. But the following code should also be adapted, then:

  int framesize() const {
    return (_frame_size_slots >> (LogBytesPerWord - LogBytesPerInt));
  }

Maybe it makes sense to do some cleanup for all platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189741783

From mdoerr at openjdk.org  Wed May 10 11:05:43 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 May 2023 11:05:43 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v22]
In-Reply-To: <egE8yOpC518czk87a_8pp5NOO_K38HXJ0uLY57-1Qbk=.d9ce5f44-3ec3-4073-b99a-ad3e05c820ce@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <i_lgp3XQaEdsnbxlhXV2TG9vgbGeZj5LhYrFQrDxO2E=.ab081f0c-8350-46ee-b7c0-c4fe08b9c37c@github.com>
 <egE8yOpC518czk87a_8pp5NOO_K38HXJ0uLY57-1Qbk=.d9ce5f44-3ec3-4073-b99a-ad3e05c820ce@github.com>
Message-ID: <Vqr0F0WNRpDnHYrEDAQMf82qYcPxgBTR54se6nfzrMw=.9fb5f576-8995-442e-b4ba-7e8058a0cc9a@github.com>

On Wed, 26 Apr 2023 14:32:59 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
>> 
>>  - Adaptation for JDK-8305668
>>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>>  - Move ABIv2CallArranger out of linux subdirectory. ABIv1/2 does match the AIX/linux separation.
>>  - Adaptation for JDK-8303022.
>>  - Adaptation for JDK-8303684.
>>  - Merge branch 'openjdk:master' into PPC64_Panama
>>  - Merge branch 'master' into PPC64_Panama
>>  - Fix Copyright format.
>>  - Fix storing 32 bit integers into Java frames. Enable TestArrayStructs.
>>  - Allow TestHFA to run on musl. Add Upcalls.
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/3bba8995...725732a0
>
> src/hotspot/cpu/ppc/frame_ppc.cpp line 219:
> 
>> 217:   UpcallStub* blob = _cb->as_upcall_stub();
>> 218:   JavaFrameAnchor* jfa = blob->jfa_for_frame(*this);
>> 219:   return jfa->last_Java_sp() == NULL;
> 
> Suggestion:
> 
>   return jfa->last_Java_sp() == nullptr;
> 
> I'd suggest to do the same for all occurrences in the patch.

Good catch! I've replaced them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189742225

From mdoerr at openjdk.org  Wed May 10 11:16:44 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 May 2023 11:16:44 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v22]
In-Reply-To: <egE8yOpC518czk87a_8pp5NOO_K38HXJ0uLY57-1Qbk=.d9ce5f44-3ec3-4073-b99a-ad3e05c820ce@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <i_lgp3XQaEdsnbxlhXV2TG9vgbGeZj5LhYrFQrDxO2E=.ab081f0c-8350-46ee-b7c0-c4fe08b9c37c@github.com>
 <egE8yOpC518czk87a_8pp5NOO_K38HXJ0uLY57-1Qbk=.d9ce5f44-3ec3-4073-b99a-ad3e05c820ce@github.com>
Message-ID: <PD6kPJMt3W8xdBYWScP0IQaBT3JSjPqhIK7D_8yMgPU=.07c347c0-2683-4fbd-b787-cdf2f3f1af58@github.com>

On Wed, 26 Apr 2023 14:41:51 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
>> 
>>  - Adaptation for JDK-8305668
>>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>>  - Move ABIv2CallArranger out of linux subdirectory. ABIv1/2 does match the AIX/linux separation.
>>  - Adaptation for JDK-8303022.
>>  - Adaptation for JDK-8303684.
>>  - Merge branch 'openjdk:master' into PPC64_Panama
>>  - Merge branch 'master' into PPC64_Panama
>>  - Fix Copyright format.
>>  - Fix storing 32 bit integers into Java frames. Enable TestArrayStructs.
>>  - Allow TestHFA to run on musl. Add Upcalls.
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/3bba8995...725732a0
>
> src/hotspot/cpu/ppc/methodHandles_ppc.cpp line 316:
> 
>> 314:   // Load the invoker, as NEP -> .invoker
>> 315:   __ verify_oop(nep_reg);
>> 316:   __ ld(temp_target, jdk_internal_foreign_abi_NativeEntryPoint::downcall_stub_address_offset_in_bytes(), nep_reg);
> 
> Other platforms use `access_load_at`.

Interesting. I have no idea why. It does the same but with a more complicated API.
I just noticed that other platforms use `NONZERO`. I think I should at least add that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189752212

From mdoerr at openjdk.org  Wed May 10 11:19:34 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 May 2023 11:19:34 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v24]
In-Reply-To: <A2cb0DaijDLj7Bpu5uXB_RN5ZjERQdR1KMnH58W5x6s=.80ad17fd-c893-49ad-9ce4-b20733574a38@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <Vr9eU-MocRqojzzn5eDc29rLeIHY8vDHHrJClAQUGNc=.f8a666a5-7722-4d51-bba2-6abefde3d711@github.com>
 <A2cb0DaijDLj7Bpu5uXB_RN5ZjERQdR1KMnH58W5x6s=.80ad17fd-c893-49ad-9ce4-b20733574a38@github.com>
Message-ID: <Qc3nOt0BHh8YQNyzio-m647o8T6nLFAinRq6XnMPYhc=.d8912cb9-7cef-4f2e-a116-2f530cedac4c@github.com>

On Thu, 27 Apr 2023 16:19:46 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert unintended formatting changes. Fix comment.
>
> src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 202:
> 
>> 200: 
>> 201:   MacroAssembler* _masm = new MacroAssembler(&buffer);
>> 202:   address start = __ function_entry(); // called by C
> 
> If `!defined(ABI_ELFv2)` a function descriptor will be emitted here. It will be initialized with `friend_toc` and `friend_env`. But that's not correct for external callers, is it? If so, wouldn't an `Unimplemented()` be better than obscure crashes?

No, this code is correct and tested (I have a partially working Big Endian patch). `toc` and `env` are loaded by the external caller (C code), but not used by the stub. So, we don't need to initialize them to any specific values.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189755698

From mdoerr at openjdk.org  Wed May 10 11:26:37 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 May 2023 11:26:37 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v24]
In-Reply-To: <A2cb0DaijDLj7Bpu5uXB_RN5ZjERQdR1KMnH58W5x6s=.80ad17fd-c893-49ad-9ce4-b20733574a38@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <Vr9eU-MocRqojzzn5eDc29rLeIHY8vDHHrJClAQUGNc=.f8a666a5-7722-4d51-bba2-6abefde3d711@github.com>
 <A2cb0DaijDLj7Bpu5uXB_RN5ZjERQdR1KMnH58W5x6s=.80ad17fd-c893-49ad-9ce4-b20733574a38@github.com>
Message-ID: <CoOM-G7ahrm3Nr3E2r4ZnYTu32nyk-oSW47QA252u-A=.86b4d704-8026-4b89-95eb-b5efb6c7a33a@github.com>

On Fri, 28 Apr 2023 13:18:27 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert unintended formatting changes. Fix comment.
>
> src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 236:
> 
>> 234:   __ block_comment("{ receiver ");
>> 235:   __ load_const_optimized(R3_ARG1, (intptr_t)receiver, R0);
>> 236:   __ resolve_jobject(R3_ARG1, tmp, R31, MacroAssembler::PRESERVATION_FRAME_LR_GP_FP_REGS); // kills R31
> 
> As a simplification the receiver could be resolved in `UpcallLinker::on_entry` and returned in `JavaThread::_vm_result`.

This sounds like a nice enhancement proposal for all platforms. The register spilling code in `resolve_jobject` can get lengthy dependent on the selected GC. Doing it in the C code (which we call anyway above) would make the upcall stubs smaller.
@JornVernee: What do you think about this idea?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189763910

From mdoerr at openjdk.org  Wed May 10 11:30:36 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 May 2023 11:30:36 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v28]
In-Reply-To: <17yuvkpMWGUKDER9SSdcPf2AP1b41i5P1Z907AOcfko=.7dc44835-eaaf-4fb1-a494-8109c7448297@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <9hDHgeACLaNP0lLQ7lXtWN07t6h4DDF5a9aaOTdvyMI=.932783da-eb49-4b9b-843b-fc564c6ffc41@github.com>
 <17yuvkpMWGUKDER9SSdcPf2AP1b41i5P1Z907AOcfko=.7dc44835-eaaf-4fb1-a494-8109c7448297@github.com>
Message-ID: <P-64WWb7KjeSj9kPCdBvRLAKfHlMRZLMkluDpk9PEO0=.0e210cf3-e62b-4dfd-9169-bd77bf61df61@github.com>

On Tue, 9 May 2023 15:48:52 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   libTestHFA: Add explicit type conversion to avoid build warning.
>
> src/hotspot/cpu/ppc/vmstorage_ppc.hpp line 81:
> 
>> 79:       case T_BYTE   :
>> 80:       case T_SHORT  :
>> 81:       case T_INT    : segment_mask = REG32_MASK; break;
> 
> I wonder why the segment_mask depends on `bt` on ppc?

The usage of the `segment_mask` can be defined for each platform. I'm using it to encode the information if a value on the Java side uses a 32 or 64 bit slot. In case of 32 bit values, the C side requires all 64 register bits to get defined values (ints get sign extended, floats get converted to double-precision format).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189768204

From jlaskey at openjdk.org  Wed May 10 11:38:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 10 May 2023 11:38:34 GMT
Subject: Integrated: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview)
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <BRO6F0Nwun-KAL86AIlKg6QjPxW-8E4_-wWH8VpPu0M=.e092c60c-021c-455d-b85e-f1265fd65082@github.com>

On Thu, 27 Oct 2022 20:16:14 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

This pull request has now been integrated.

Changeset: 4aa65cbe
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4aa65cbeefe44f29fbe6ea013809dcee579df9ff
Stats:     9331 lines in 74 files changed: 9233 ins; 23 del; 75 mod

8285932: Implementation of JEP 430 String Templates (Preview)

Reviewed-by: mcimadamore, rriggs, darcy

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

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

From erikj at openjdk.org  Wed May 10 12:49:19 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 10 May 2023 12:49:19 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v10]
In-Reply-To: <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <0viE6l2gzDCF4VBwgJcR_rAbXRApsFP4JL8RPcyRrIU=.00d04ba3-63c6-4f0f-aeef-718c0f388369@github.com>
Message-ID: <6FRecbkoJikA25hk24eO8JA_kIG2c1ie9DZ9-GYwMC4=.607ca420-7788-4574-aec4-5a47ae614238@github.com>

On Tue, 9 May 2023 23:06:23 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries
>> 
>> - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>>  
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments from @erikj79:
>   - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk.
>   - Split the long line at 1281 in Main.gmk.

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13768#pullrequestreview-1420562567

From jvernee at openjdk.org  Wed May 10 13:10:22 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 10 May 2023 13:10:22 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v22]
In-Reply-To: <PD6kPJMt3W8xdBYWScP0IQaBT3JSjPqhIK7D_8yMgPU=.07c347c0-2683-4fbd-b787-cdf2f3f1af58@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <i_lgp3XQaEdsnbxlhXV2TG9vgbGeZj5LhYrFQrDxO2E=.ab081f0c-8350-46ee-b7c0-c4fe08b9c37c@github.com>
 <egE8yOpC518czk87a_8pp5NOO_K38HXJ0uLY57-1Qbk=.d9ce5f44-3ec3-4073-b99a-ad3e05c820ce@github.com>
 <PD6kPJMt3W8xdBYWScP0IQaBT3JSjPqhIK7D_8yMgPU=.07c347c0-2683-4fbd-b787-cdf2f3f1af58@github.com>
Message-ID: <eVBag-mo-t7zyOLmlhE6ATRH4HU8gbOtudzISc4ogDs=.bedfed76-f5ef-493d-b6d1-ede330d61a4f@github.com>

On Wed, 10 May 2023 11:13:14 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> It does the same but with a more complicated API.

AFAIK It depends on the GC that's being used. `access_load_at` will make sure the right GC barriers are inserted (mostly for concurrent GCs).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189885698

From jvernee at openjdk.org  Wed May 10 13:16:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 10 May 2023 13:16:27 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v24]
In-Reply-To: <CoOM-G7ahrm3Nr3E2r4ZnYTu32nyk-oSW47QA252u-A=.86b4d704-8026-4b89-95eb-b5efb6c7a33a@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <Vr9eU-MocRqojzzn5eDc29rLeIHY8vDHHrJClAQUGNc=.f8a666a5-7722-4d51-bba2-6abefde3d711@github.com>
 <A2cb0DaijDLj7Bpu5uXB_RN5ZjERQdR1KMnH58W5x6s=.80ad17fd-c893-49ad-9ce4-b20733574a38@github.com>
 <CoOM-G7ahrm3Nr3E2r4ZnYTu32nyk-oSW47QA252u-A=.86b4d704-8026-4b89-95eb-b5efb6c7a33a@github.com>
Message-ID: <gvI1xPgLu9KjlKOy9bxjjr2FfjkplD3w79sF4KjChJg=.197eae55-7a6a-4e27-89b4-bae536e7ee4e@github.com>

On Wed, 10 May 2023 11:23:04 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 236:
>> 
>>> 234:   __ block_comment("{ receiver ");
>>> 235:   __ load_const_optimized(R3_ARG1, (intptr_t)receiver, R0);
>>> 236:   __ resolve_jobject(R3_ARG1, tmp, R31, MacroAssembler::PRESERVATION_FRAME_LR_GP_FP_REGS); // kills R31
>> 
>> As a simplification the receiver could be resolved in `UpcallLinker::on_entry` and returned in `JavaThread::_vm_result`.
>
> This sounds like a nice enhancement proposal for all platforms. The register spilling code in `resolve_jobject` can get lengthy dependent on the selected GC. Doing it in the C code (which we call anyway above) would make the upcall stubs smaller.
> @JornVernee: What do you think about this idea?

Seems like a nice idea. The resolution here pre-dates the time where we called into the VM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189892999

From rrich at openjdk.org  Wed May 10 13:27:33 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 10 May 2023 13:27:33 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v22]
In-Reply-To: <eVBag-mo-t7zyOLmlhE6ATRH4HU8gbOtudzISc4ogDs=.bedfed76-f5ef-493d-b6d1-ede330d61a4f@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <i_lgp3XQaEdsnbxlhXV2TG9vgbGeZj5LhYrFQrDxO2E=.ab081f0c-8350-46ee-b7c0-c4fe08b9c37c@github.com>
 <egE8yOpC518czk87a_8pp5NOO_K38HXJ0uLY57-1Qbk=.d9ce5f44-3ec3-4073-b99a-ad3e05c820ce@github.com>
 <PD6kPJMt3W8xdBYWScP0IQaBT3JSjPqhIK7D_8yMgPU=.07c347c0-2683-4fbd-b787-cdf2f3f1af58@github.com>
 <eVBag-mo-t7zyOLmlhE6ATRH4HU8gbOtudzISc4ogDs=.bedfed76-f5ef-493d-b6d1-ede330d61a4f@github.com>
Message-ID: <dZaLFlL64aBL4e9_EynSNKftvRI7PpmE0HpRV-CTUB8=.fa9f4470-0c29-4c0e-8301-112891b707d6@github.com>

On Wed, 10 May 2023 13:07:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Interesting. I have no idea why. It does the same but with a more complicated API.
>> I just noticed that other platforms use `NONZERO`. I think I should at least add that.
>
>> It does the same but with a more complicated API.
> 
> AFAIK It depends on the GC that's being used. `access_load_at` will make sure the right GC barriers are inserted (mostly for concurrent GCs).

As I see it, the access API is an abstraction to be used instead of raw loads. It hides details. See for instance `TemplateTable::getfield_or_static` on x86 where it is also used. PPC lags behind in making use of the access API.
With a fancy new GC the oop in nep_reg could be stale, requiring some processing which would be taken care of by using the access API.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189905194

From mdoerr at openjdk.org  Wed May 10 13:27:33 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 May 2023 13:27:33 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v22]
In-Reply-To: <dZaLFlL64aBL4e9_EynSNKftvRI7PpmE0HpRV-CTUB8=.fa9f4470-0c29-4c0e-8301-112891b707d6@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <i_lgp3XQaEdsnbxlhXV2TG9vgbGeZj5LhYrFQrDxO2E=.ab081f0c-8350-46ee-b7c0-c4fe08b9c37c@github.com>
 <egE8yOpC518czk87a_8pp5NOO_K38HXJ0uLY57-1Qbk=.d9ce5f44-3ec3-4073-b99a-ad3e05c820ce@github.com>
 <PD6kPJMt3W8xdBYWScP0IQaBT3JSjPqhIK7D_8yMgPU=.07c347c0-2683-4fbd-b787-cdf2f3f1af58@github.com>
 <eVBag-mo-t7zyOLmlhE6ATRH4HU8gbOtudzISc4ogDs=.bedfed76-f5ef-493d-b6d1-ede330d61a4f@github.com>
 <dZaLFlL64aBL4e9_EynSNKftvRI7PpmE0HpRV-CTUB8=.fa9f4470-0c29-4c0e-8301-112891b707d6@github.com>
Message-ID: <OaxP8DDQPxtNxhyQhKqj2znuuwl1AWCx3zolHIP4yRk=.2b983f23-ba26-44e6-bd2c-a9778a070880@github.com>

On Wed, 10 May 2023 13:22:48 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>>> It does the same but with a more complicated API.
>> 
>> AFAIK It depends on the GC that's being used. `access_load_at` will make sure the right GC barriers are inserted (mostly for concurrent GCs).
>
> As I see it, the access API is an abstraction to be used instead of raw loads. It hides details. See for instance `TemplateTable::getfield_or_static` on x86 where it is also used. PPC lags behind in making use of the access API.
> With a fancy new GC the oop in nep_reg could be stale, requiring some processing which would be taken care of by using the access API.

GC barriers are used when loading or storing an oop. No GC we currently have (not even the generational ones) use barriers for loading a plain address from an oop. The PPC64 implementation of the BarrierSetAssembler currently has `Unimplemented()` for non-oop types and all GCs are implemented.
Maybe it was intended for some future GC or other feature which has not yet reached the official repo.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189908142

From rrich at openjdk.org  Wed May 10 13:36:34 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 10 May 2023 13:36:34 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v22]
In-Reply-To: <OaxP8DDQPxtNxhyQhKqj2znuuwl1AWCx3zolHIP4yRk=.2b983f23-ba26-44e6-bd2c-a9778a070880@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <i_lgp3XQaEdsnbxlhXV2TG9vgbGeZj5LhYrFQrDxO2E=.ab081f0c-8350-46ee-b7c0-c4fe08b9c37c@github.com>
 <egE8yOpC518czk87a_8pp5NOO_K38HXJ0uLY57-1Qbk=.d9ce5f44-3ec3-4073-b99a-ad3e05c820ce@github.com>
 <PD6kPJMt3W8xdBYWScP0IQaBT3JSjPqhIK7D_8yMgPU=.07c347c0-2683-4fbd-b787-cdf2f3f1af58@github.com>
 <eVBag-mo-t7zyOLmlhE6ATRH4HU8gbOtudzISc4ogDs=.bedfed76-f5ef-493d-b6d1-ede330d61a4f@github.com>
 <dZaLFlL64aBL4e9_EynSNKftvRI7PpmE0HpRV-CTUB8=.fa9f4470-0c29-4c0e-8301-112891b707d6@github.com>
 <OaxP8DDQPxtNxhyQhKqj2znuuwl1AWCx3zolHIP4yRk=.2b983f23-ba26-44e6-bd2c-a9778a070880@github.com>
Message-ID: <FCnO8qx-GwmFDTbsLn6d2TB_rXG0vaJVZYCKrxgDFZY=.bfc56ad7-80e3-4e29-86b0-323ff203c442@github.com>

On Wed, 10 May 2023 13:24:55 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> As I see it, the access API is an abstraction to be used instead of raw loads. It hides details. See for instance `TemplateTable::getfield_or_static` on x86 where it is also used. PPC lags behind in making use of the access API.
>> With a fancy new GC the oop in nep_reg could be stale, requiring some processing which would be taken care of by using the access API.
>
> GC barriers are used when loading or storing an oop. No GC we currently have (not even the generational ones) use barriers for loading a plain address from an oop. The PPC64 implementation of the BarrierSetAssembler currently has `Unimplemented()` for non-oop types and all GCs are implemented.
> Maybe it was intended for some future GC or other feature which has not yet reached the official repo.

You are reasoning about implementation details. By using the provided abstraction you and other maintainers (who might be unfamiliar with them) would not have to do that. Also the assumptions you make introduce a hidden dependency.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189919874

From mdoerr at openjdk.org  Wed May 10 13:46:36 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 May 2023 13:46:36 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v22]
In-Reply-To: <FCnO8qx-GwmFDTbsLn6d2TB_rXG0vaJVZYCKrxgDFZY=.bfc56ad7-80e3-4e29-86b0-323ff203c442@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <i_lgp3XQaEdsnbxlhXV2TG9vgbGeZj5LhYrFQrDxO2E=.ab081f0c-8350-46ee-b7c0-c4fe08b9c37c@github.com>
 <egE8yOpC518czk87a_8pp5NOO_K38HXJ0uLY57-1Qbk=.d9ce5f44-3ec3-4073-b99a-ad3e05c820ce@github.com>
 <PD6kPJMt3W8xdBYWScP0IQaBT3JSjPqhIK7D_8yMgPU=.07c347c0-2683-4fbd-b787-cdf2f3f1af58@github.com>
 <eVBag-mo-t7zyOLmlhE6ATRH4HU8gbOtudzISc4ogDs=.bedfed76-f5ef-493d-b6d1-ede330d61a4f@github.com>
 <dZaLFlL64aBL4e9_EynSNKftvRI7PpmE0HpRV-CTUB8=.fa9f4470-0c29-4c0e-8301-112891b707d6@github.com>
 <OaxP8DDQPxtNxhyQhKqj2znuuwl1AWCx3zolHIP4yRk=.2b983f23-ba26-44e6-bd2c-a9778a070880@github.com>
 <FCnO8qx-GwmFDTbsLn6d2TB_rXG0vaJVZYCKrxgDFZY=.bfc56ad7-80e3-4e29-86b0-323ff203c442@github.com>
Message-ID: <3UOaZ75k_vzmyK8rntwXGjUT_Hd1IAtVRkQ5G3zpTr0=.0b46880f-1476-4688-82cc-df853e3f8bf8@github.com>

On Wed, 10 May 2023 13:33:02 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> GC barriers are used when loading or storing an oop. No GC we currently have (not even the generational ones) use barriers for loading a plain address from an oop. The PPC64 implementation of the BarrierSetAssembler currently has `Unimplemented()` for non-oop types and all GCs are implemented.
>> Maybe it was intended for some future GC or other feature which has not yet reached the official repo.
>
> You are reasoning about implementation details. By using the provided abstraction you and other maintainers (who might be unfamiliar with them) would not have to do that. Also the assumptions you make introduce a hidden dependency.

I just figured it out. It was introduced by https://bugs.openjdk.org/browse/JDK-8203172 (on aarch64) which mentions Shenandoah and future GCs. However, the Shenandoah comment says "non-reference load, no additional barrier is needed" and it doesn't use barriers in such a case. So, for the time being, I'll keep the normal load (because `access_load_at` is not ready for non-oop types). But I should add the `NONZERO` check.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189934352

From stefank at openjdk.org  Wed May 10 13:56:38 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 10 May 2023 13:56:38 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v22]
In-Reply-To: <3UOaZ75k_vzmyK8rntwXGjUT_Hd1IAtVRkQ5G3zpTr0=.0b46880f-1476-4688-82cc-df853e3f8bf8@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <i_lgp3XQaEdsnbxlhXV2TG9vgbGeZj5LhYrFQrDxO2E=.ab081f0c-8350-46ee-b7c0-c4fe08b9c37c@github.com>
 <egE8yOpC518czk87a_8pp5NOO_K38HXJ0uLY57-1Qbk=.d9ce5f44-3ec3-4073-b99a-ad3e05c820ce@github.com>
 <PD6kPJMt3W8xdBYWScP0IQaBT3JSjPqhIK7D_8yMgPU=.07c347c0-2683-4fbd-b787-cdf2f3f1af58@github.com>
 <eVBag-mo-t7zyOLmlhE6ATRH4HU8gbOtudzISc4ogDs=.bedfed76-f5ef-493d-b6d1-ede330d61a4f@github.com>
 <dZaLFlL64aBL4e9_EynSNKftvRI7PpmE0HpRV-CTUB8=.fa9f4470-0c29-4c0e-8301-112891b707d6@github.com>
 <OaxP8DDQPxtNxhyQhKqj2znuuwl1AWCx3zolHIP4yRk=.2b983f23-ba26-44e6-bd2c-a9778a070880@github.com>
 <FCnO8qx-GwmFDTbsLn6d2TB_rXG0vaJVZYCKrxgDFZY=.bfc56ad7-80e3-4e29-86b0-323ff203c442@github.com>
 <3UOaZ75k_vzmyK8rntwXGjUT_Hd1IAtVRkQ5G3zpTr0=.0b46880f-1476-4688-82cc-df853e3f8bf8@github.com>
Message-ID: <5uv2Nqt_IDeyq2NLXG3RziMSIPTeTnwUnDb9GhFaDEc=.a9728f65-3b53-44eb-94d5-87541d215334@github.com>

On Wed, 10 May 2023 13:43:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> You are reasoning about implementation details. By using the provided abstraction you and other maintainers (who might be unfamiliar with them) would not have to do that. Also the assumptions you make introduce a hidden dependency.
>
> I just figured it out. It was introduced by https://bugs.openjdk.org/browse/JDK-8203172 (on aarch64) which mentions Shenandoah and future GCs. However, the Shenandoah comment says "non-reference load, no additional barrier is needed" and it doesn't use barriers in such a case. So, for the time being, I'll keep the normal load (because `access_load_at` is not ready for non-oop types). But I should add the `NONZERO` check.

FWIW, since Shenandoah changed their load barriers we have been cleaning away the usages of the Access API for loads and stores to primitive values. There's no such support in the C++ Runtime code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189948988

From jwaters at openjdk.org  Wed May 10 14:09:26 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 10 May 2023 14:09:26 GMT
Subject: RFR: 8305341: Alignment should be enforced by alignas instead of
 compiler specific attributes [v4]
In-Reply-To: <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
References: <2d60fxZxeWZEngMaSE1N4JZz07XkvbXj8jrN_hMbo-0=.51ffb82f-2beb-43f7-9195-062555599d0b@github.com>
 <dlMKfkRoYlEOlABs5J-mW-Mbr-M3Kv455fgrnmj0A1w=.954ab66c-6dfb-44e7-9546-455e38e35f4a@github.com>
Message-ID: <MZ9Ww1-PhpCXXDqtt7KgAv070r2XgJKDDgBcOeaRuik=.b939c944-abee-4205-8c8b-2147658a4916@github.com>

On Wed, 12 Apr 2023 07:12:10 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> C11 has been stable for a long time on all platforms, so native code can use the standard alignas operator for alignment requirements
>
> Julian Waters has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Restore visCPP
>  - Restore gcc attribute
>  - Revert gcc
>  - Revert

Well, that's unfortunate

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13258#issuecomment-1542279520

From mdoerr at openjdk.org  Wed May 10 14:19:43 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 May 2023 14:19:43 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v30]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <JI-0Tk2ZN2ZwQO3jhooK5jgqnzHbCJuKMQjSE_TsaCQ=.fc73c920-6107-4c61-8021-072cb58e18b6@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: This issue is resolved by 2nd commit.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Add NONZERO check for downcall_stub_address_offset_in_bytes().

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/93060258..edcdefba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=28-29

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From rrich at openjdk.org  Wed May 10 14:19:44 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 10 May 2023 14:19:44 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v24]
In-Reply-To: <Qc3nOt0BHh8YQNyzio-m647o8T6nLFAinRq6XnMPYhc=.d8912cb9-7cef-4f2e-a116-2f530cedac4c@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <Vr9eU-MocRqojzzn5eDc29rLeIHY8vDHHrJClAQUGNc=.f8a666a5-7722-4d51-bba2-6abefde3d711@github.com>
 <A2cb0DaijDLj7Bpu5uXB_RN5ZjERQdR1KMnH58W5x6s=.80ad17fd-c893-49ad-9ce4-b20733574a38@github.com>
 <Qc3nOt0BHh8YQNyzio-m647o8T6nLFAinRq6XnMPYhc=.d8912cb9-7cef-4f2e-a116-2f530cedac4c@github.com>
Message-ID: <GCgGLlbQZKE3NTQ8kJsbkKDR1_vpbAwIuAS4oIcsRYE=.d3e076b8-57ff-4add-a29a-abb3c73ac346@github.com>

On Wed, 10 May 2023 11:16:44 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/upcallLinker_ppc.cpp line 202:
>> 
>>> 200: 
>>> 201:   MacroAssembler* _masm = new MacroAssembler(&buffer);
>>> 202:   address start = __ function_entry(); // called by C
>> 
>> If `!defined(ABI_ELFv2)` a function descriptor will be emitted here. It will be initialized with `friend_toc` and `friend_env`. But that's not correct for external callers, is it? If so, wouldn't an `Unimplemented()` be better than obscure crashes?
>
> No, this code is correct and tested (I have a partially working Big Endian patch). `toc` and `env` are loaded by the external caller (C code), but not used by the stub. So, we don't need to initialize them to any specific values.

I think I understand. The loaded `toc` and `env` of the stub are never used as Java execution does not use them and native or runtime calls will load corresponding `toc` and `env` of the callee.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189980161

From jvernee at openjdk.org  Wed May 10 14:30:27 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 10 May 2023 14:30:27 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v22]
In-Reply-To: <5uv2Nqt_IDeyq2NLXG3RziMSIPTeTnwUnDb9GhFaDEc=.a9728f65-3b53-44eb-94d5-87541d215334@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <i_lgp3XQaEdsnbxlhXV2TG9vgbGeZj5LhYrFQrDxO2E=.ab081f0c-8350-46ee-b7c0-c4fe08b9c37c@github.com>
 <egE8yOpC518czk87a_8pp5NOO_K38HXJ0uLY57-1Qbk=.d9ce5f44-3ec3-4073-b99a-ad3e05c820ce@github.com>
 <PD6kPJMt3W8xdBYWScP0IQaBT3JSjPqhIK7D_8yMgPU=.07c347c0-2683-4fbd-b787-cdf2f3f1af58@github.com>
 <eVBag-mo-t7zyOLmlhE6ATRH4HU8gbOtudzISc4ogDs=.bedfed76-f5ef-493d-b6d1-ede330d61a4f@github.com>
 <dZaLFlL64aBL4e9_EynSNKftvRI7PpmE0HpRV-CTUB8=.fa9f4470-0c29-4c0e-8301-112891b707d6@github.com>
 <OaxP8DDQPxtNxhyQhKqj2znuuwl1AWCx3zolHIP4yRk=.2b983f23-ba26-44e6-bd2c-a9778a070880@github.com>
 <FCnO8qx-GwmFDTbsLn6d2TB_rXG0vaJVZYCKrxgDFZY=.bfc56ad7-80e3-4e29-86b0-323ff203c442@github.com>
 <3UOaZ75k_vzmyK8rntwXGjUT_Hd1IAtVRkQ5G3zpTr0=.0b46880f-1476-4688-82cc-df853e3f8bf8@github.com>
 <5uv2Nqt_IDeyq2NLXG3RziMSIPTeTnwUnDb9GhFaDEc=.a9728f65-3b53-44eb-94d5-87541d215334@github.com>
Message-ID: <p_Wv3jAoX6Eri1yV1A2_ZhzKTvt1lw8b8gc1AYQUSQc=.036e254a-b796-40d8-9f0d-6a4269c8458a@github.com>

On Wed, 10 May 2023 13:53:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> I just figured it out. It was introduced by https://bugs.openjdk.org/browse/JDK-8203172 (on aarch64) which mentions Shenandoah and future GCs. However, the Shenandoah comment says "non-reference load, no additional barrier is needed" and it doesn't use barriers in such a case. So, for the time being, I'll keep the normal load (because `access_load_at` is not ready for non-oop types). But I should add the `NONZERO` check.
>
> FWIW, since Shenandoah changed their load barriers we have been cleaning away the usages of the Access API for loads and stores to primitive values. There's no such support in the C++ Runtime code.

Ok, since this is loading a `long` (which represents an address that points into the code cache) I think we're fine without using the access API then?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1189996018

From mchhipa at openjdk.org  Wed May 10 14:44:33 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 10 May 2023 14:44:33 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v6]
In-Reply-To: <7XeeodEv7RbZQqqbenSrqFrNpOrPY9Svh1xm9smxlCg=.fd871670-0d4d-42a5-add2-e4c73d931290@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <fhDJZ45cjHcgp2v9yZe4MFzBGmZxZV-wg4iyQad39fU=.e0a8da91-86cf-4bef-b608-28f9b41cdc5c@github.com>
 <7XeeodEv7RbZQqqbenSrqFrNpOrPY9Svh1xm9smxlCg=.fd871670-0d4d-42a5-add2-e4c73d931290@github.com>
Message-ID: <buEZiLiHy_KemMd3F4-WMYJThr-hOop8xhKsL7kryzI=.d0bf52a6-2c40-4be2-8fad-6621cff32328@github.com>

On Fri, 5 May 2023 21:50:06 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move the pseudo code generation part from setup() to seperate methods.
>
> test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 232:
> 
>> 230:      * JDK<version>GregorianCalendarAndDurationSerData.java files.
>> 231:      * @param baos
>> 232:      */
> 
> I think there needs to be a general comment describing how these methods are used to create the JDK<version>GregorianCalendarAndDurationSerData.java files.  There should also be a description/comment for the methods defined in GregorianCalendarAndDurationSerData.java
> 
> We need to try and put ourselves in the place of a future maintainer who needs to understand how to  create a version of one of these files.
> 
> You could probably also create a method which generates a JDK<version>GregorianCalendarAndDurationSerData.java file to save the developer from multiple cut an pastes.
> 
> At a minimum, there really should be a step by step guide

How these methods can be used, added comment regarding this under setup method. Added description for the methods defined in GregorianCalendarAndDurationSerData.java file. Now developer should be able to create the <JDK version >GregorianCalendarAndDurationSerData.java file after reading these comments.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1190014838

From mchhipa at openjdk.org  Wed May 10 14:52:58 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 10 May 2023 14:52:58 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v7]
In-Reply-To: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
Message-ID: <btivxm6byykZzzPFBTOCqD_7dM3rL0qK6bBDDYUEO-o=.fd151b43-45e9-4002-8b6f-727839674588@github.com>

> Test is updated to create the binary files during test execution.

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/13537/files
  - new: https://git.openjdk.org/jdk/pull/13537/files/b690e77b..a940f237

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13537&range=05-06

  Stats: 113 lines in 2 files changed: 36 ins; 10 del; 67 mod
  Patch: https://git.openjdk.org/jdk/pull/13537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13537/head:pull/13537

PR: https://git.openjdk.org/jdk/pull/13537

From jiangli at openjdk.org  Wed May 10 15:15:29 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 10 May 2023 15:15:29 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries
In-Reply-To: <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <-y0ADzT8MTDUDF_cB5Msg5W4OfWnP7GjcCfhcrKtT-I=.6ed57876-309a-4b7f-a23e-e04bf7047755@github.com>
Message-ID: <i-UrUwsNOEmuYA2yNAq-OLDPDXseMk4jVzH3zJLTPig=.dcd8276c-e3df-425d-9332-6f2d3f8dd2c2@github.com>

On Wed, 3 May 2023 13:34:12 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>> - Introduce new make target(s) for creating image/bundle containing hotspot libjvm.a and JDK static libraries
>> 
>> - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>>  
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>
> The current target user of the .a libraries is GraalVM, so we should check with them that the changes to the contents of the `.a` files isn't impacting them in a bad way. @dougxc what do you think?

Thanks a lot for the multiple iterations of the discussions and reviews in this PR thread. All the input, especially https://github.com/openjdk/jdk/pull/13768#pullrequestreview-1415436469 from @erikj79 helped shaped this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542387929

From psandoz at openjdk.org  Wed May 10 16:08:26 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 10 May 2023 16:08:26 GMT
Subject: RFR: JDK-8151531: Add notes to BaseStream.spliterator/iterator
 docs regarding them being escape hatches [v3]
In-Reply-To: <3mjQIGtCDIJMF8oBR1VVR-G3cxOG7F1u_GsD41MT8Zs=.11286233-e2d2-4b05-a6ae-469c5422c281@github.com>
References: <HH3ibsbjPBEBIQ6HwCiglhnDLNhwYUNFKj435anND6s=.f6611227-f1f4-4ad0-af4c-04fa8390ac72@github.com>
 <3mjQIGtCDIJMF8oBR1VVR-G3cxOG7F1u_GsD41MT8Zs=.11286233-e2d2-4b05-a6ae-469c5422c281@github.com>
Message-ID: <I2PNm0N5Dv4-GqtfzyN-sKIyCZUWe8fR3ApsUPzZEe0=.004fefff-c95d-49eb-9f97-31035633e65c@github.com>

On Wed, 10 May 2023 07:48:11 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Still relevant to address? /cc @PaulSandoz
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright year

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13890#pullrequestreview-1420974155

From jiangli at openjdk.org  Wed May 10 16:23:06 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 10 May 2023 16:23:06 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v11]
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <8XdK5PaDhcdKRH67l1erHK0jLMDfo6Gz5qJxN53pGXg=.db58f51d-b5c0-4744-827b-9c74dd6cd9ec@github.com>

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
> - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>  
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS

Jiangli Zhou has updated the pull request with a new target base 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:

 - Merge branch 'master' into JDK-8307194
 - Address comments from @erikj79:
   - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk.
   - Split the long line at 1281 in Main.gmk.
 - Fix whitspace errors.
 - Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS:
   
   - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk.
   
   - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS).
   - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/<JVM_VARIANTS>. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/<variant> directory.
   
   - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets.
 - Fix whitespace error in make/StaticJvmLibsImage.gmk.
 - - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw:
     - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a.
     - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a.
     - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib.
   - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now:
     - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk.
     - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk.
 - Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input.
 - Update make/StaticLibsImage.gmk
   
   thanks
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update make/StaticLibsImage.gmk
   
   Thanks
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update based on @erikj79 review comments and suggestions:
   - Change to copy libjvm.a for $(JVM_VARIANT_MAIN) only in make/StaticLibsImage.gmk.
   - Use $(OBJ_SUFFIX) instead of .o in make/modules/java.base/lib/CoreLibraries.gmk.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/84938550...36526d4f

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13768/files
  - new: https://git.openjdk.org/jdk/pull/13768/files/45dd2a00..36526d4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=09-10

  Stats: 44134 lines in 1102 files changed: 31678 ins; 5168 del; 7288 mod
  Patch: https://git.openjdk.org/jdk/pull/13768.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768

PR: https://git.openjdk.org/jdk/pull/13768

From acobbs at openjdk.org  Wed May 10 16:27:31 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 10 May 2023 16:27:31 GMT
Subject: Integrated: 8305748: Clarify reentrant behavior of close() in
 FileInputStream, FileOutputStream, and RandomAccessFile
In-Reply-To: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
References: <EFqX1AStSphcvhwUG8lt2qu_SRoXLra-_g6Tu9V2P2k=.0d69fb8f-dfb1-4cfa-af23-bd50bab67d76@github.com>
Message-ID: <phibQcy8ng4Cd8jux1OxQr6NmiAZe-vEHikmcWxyYD0=.1aac6132-d41e-47d1-9e09-5eaf15111f8b@github.com>

On Thu, 6 Apr 2023 22:36:33 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> IO stream classes like `FileOutputStream` can have assocated NIO channels.
> 
> When `close()` is invoked on one of these classes, it in turn invokes `close()` on the associated channel (if any). But when the associated channel's `close()` method is invoked, it in turn invokes `close()` on the associated stream (if any).
> 
> As a result, these IO stream `close()` methods invoke themselves reentrantly when there is an associated channel.
> 
> This is not a problem for these classes because they are written to handle this (i.e., they are idempotent), but it can be surprising (or worse, just silently bug-inducing) for subclasses that override `close()`.
> 
> There are two possible ways to address this:
> 1. Modify the code to detect and avoid the (unnecessary) reentrant invocations
> 2. Add a `@implNote` to the Javadoc so subclass implementers are made aware
> 
> This patch takes the second, more conservative approach.

This pull request has now been integrated.

Changeset: 0198afca
Author:    Archie Cobbs <acobbs at openjdk.org>
Committer: Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0198afca3ac1a7c421b0669ae2180eee3e4f1482
Stats:     17 lines in 4 files changed: 16 ins; 0 del; 1 mod

8305748: Clarify reentrant behavior of close() in FileInputStream, FileOutputStream, and RandomAccessFile

Reviewed-by: alanb, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/13379

From duke at openjdk.org  Wed May 10 16:32:27 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 10 May 2023 16:32:27 GMT
Subject: Integrated: JDK-8151531: Add notes to BaseStream.spliterator/iterator
 docs regarding them being escape hatches
In-Reply-To: <HH3ibsbjPBEBIQ6HwCiglhnDLNhwYUNFKj435anND6s=.f6611227-f1f4-4ad0-af4c-04fa8390ac72@github.com>
References: <HH3ibsbjPBEBIQ6HwCiglhnDLNhwYUNFKj435anND6s=.f6611227-f1f4-4ad0-af4c-04fa8390ac72@github.com>
Message-ID: <w5JuOFmu6sCygVTw_6C_wTGQShsAXPMnZijAXmyJd3g=.8161950e-2b5c-4c60-aa7f-d9939b918615@github.com>

On Tue, 9 May 2023 15:50:13 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Still relevant to address? /cc @PaulSandoz

This pull request has now been integrated.

Changeset: 8a95020a
Author:    Viktor Klang <viktor.klang at oracle.com>
Committer: Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a95020ab6c61f25954a56e1965529bb2f6f58af
Stats:     11 lines in 1 file changed: 10 ins; 0 del; 1 mod

8151531: Add notes to BaseStream.spliterator/iterator docs regarding them being escape hatches

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/13890

From jiangli at openjdk.org  Wed May 10 17:13:13 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 10 May 2023 17:13:13 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v12]
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <IYLdLeipy3ADnQkE6calR-sbud1Z5KZlbPk6-jcZ1jE=.fccfa5bf-f028-41c3-a97b-ecba7017087a@github.com>

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
> - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>  
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS

Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge branch 'master' into JDK-8307194
 - Merge branch 'master' into JDK-8307194
 - Address comments from @erikj79:
   - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk.
   - Split the long line at 1281 in Main.gmk.
 - Fix whitspace errors.
 - Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS:
   
   - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk.
   
   - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS).
   - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/<JVM_VARIANTS>. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/<variant> directory.
   
   - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets.
 - Fix whitespace error in make/StaticJvmLibsImage.gmk.
 - - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw:
     - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a.
     - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a.
     - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib.
   - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now:
     - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk.
     - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk.
 - Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input.
 - Update make/StaticLibsImage.gmk
   
   thanks
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - Update make/StaticLibsImage.gmk
   
   Thanks
   
   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>
 - ... and 3 more: https://git.openjdk.org/jdk/compare/54e2bacc...ba2e9ce6

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13768/files
  - new: https://git.openjdk.org/jdk/pull/13768/files/36526d4f..ba2e9ce6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13768&range=10-11

  Stats: 125 lines in 7 files changed: 26 ins; 96 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13768.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13768/head:pull/13768

PR: https://git.openjdk.org/jdk/pull/13768

From jiangli at openjdk.org  Wed May 10 17:29:32 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 10 May 2023 17:29:32 GMT
Subject: Integrated: 8307194: Add make target for optionally building a
 complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
Message-ID: <qseEQ8DzAfAb9I5boIYDOieVKdScp-EfDZ6fcJ_oHj8=.d97b21b0-a6a6-461a-8754-3382d5060e4b@github.com>

On Wed, 3 May 2023 02:09:22 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
> - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>  
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS

This pull request has now been integrated.

Changeset: 1964954d
Author:    Jiangli Zhou <jiangli at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1964954da9ac1d020e0b5ba35893f475d86ec909
Stats:     178 lines in 8 files changed: 127 ins; 34 del; 17 mod

8307194: Add make target for optionally building a complete set of all JDK and hotspot libjvm static libraries

Reviewed-by: erikj, sgehwolf

-------------

PR: https://git.openjdk.org/jdk/pull/13768

From naoto at openjdk.org  Wed May 10 20:19:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 May 2023 20:19:59 GMT
Subject: RFR: 8307547: Support for multiple collations for a locale
Message-ID: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>

The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.

-------------

Commit messages:
 - Test refinement
 - Clean-up
 - javadoc
 - 8307547: Support for multiple collation tables

Changes: https://git.openjdk.org/jdk/pull/13917/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13917&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307547
  Stats: 71 lines in 4 files changed: 57 ins; 4 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13917.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13917/head:pull/13917

PR: https://git.openjdk.org/jdk/pull/13917

From naoto at openjdk.org  Wed May 10 20:28:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 May 2023 20:28:11 GMT
Subject: RFR: 8307547: Support for multiple collations for a locale [v2]
In-Reply-To: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
Message-ID: <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>

> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  http -> https

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13917/files
  - new: https://git.openjdk.org/jdk/pull/13917/files/276178f8..9f0eb048

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13917&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13917&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13917.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13917/head:pull/13917

PR: https://git.openjdk.org/jdk/pull/13917

From erikj at openjdk.org  Wed May 10 20:28:06 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 10 May 2023 20:28:06 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v12]
In-Reply-To: <IYLdLeipy3ADnQkE6calR-sbud1Z5KZlbPk6-jcZ1jE=.fccfa5bf-f028-41c3-a97b-ecba7017087a@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <IYLdLeipy3ADnQkE6calR-sbud1Z5KZlbPk6-jcZ1jE=.fccfa5bf-f028-41c3-a97b-ecba7017087a@github.com>
Message-ID: <wNgaBjhwye3gcgLGyfGDwStRWpjy0_V7lntfdsmLdPc=.9d74ae1b-3916-4dc8-8721-88dfb33b19e1@github.com>

On Wed, 10 May 2023 17:13:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
>> 
>> - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>>  
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>
> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8307194
>  - Merge branch 'master' into JDK-8307194
>  - Address comments from @erikj79:
>    - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk.
>    - Split the long line at 1281 in Main.gmk.
>  - Fix whitspace errors.
>  - Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS:
>    
>    - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk.
>    
>    - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS).
>    - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/<JVM_VARIANTS>. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/<variant> directory.
>    
>    - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets.
>  - Fix whitespace error in make/StaticJvmLibsImage.gmk.
>  - - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw:
>      - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a.
>      - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a.
>      - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib.
>    - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now:
>      - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk.
>      - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk.
>  - Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input.
>  - Update make/StaticLibsIm...

This change caused all our builds but Linux to fail. Did you verify on other platforms than Linux at all? I see you have GHA turned off.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542764704

From jiangli at openjdk.org  Wed May 10 20:41:56 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 10 May 2023 20:41:56 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v12]
In-Reply-To: <wNgaBjhwye3gcgLGyfGDwStRWpjy0_V7lntfdsmLdPc=.9d74ae1b-3916-4dc8-8721-88dfb33b19e1@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <IYLdLeipy3ADnQkE6calR-sbud1Z5KZlbPk6-jcZ1jE=.fccfa5bf-f028-41c3-a97b-ecba7017087a@github.com>
 <wNgaBjhwye3gcgLGyfGDwStRWpjy0_V7lntfdsmLdPc=.9d74ae1b-3916-4dc8-8721-88dfb33b19e1@github.com>
Message-ID: <xPpKzqozMUHOygmSqjtim7SVnnCy0KEPM8iO6b5HwrA=.8750f9aa-422d-4678-8d6d-7d555ca7ac09@github.com>

On Wed, 10 May 2023 20:24:30 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> This change caused all our builds but Linux to fail. Did you verify on other platforms than Linux at all? I see you have GHA turned off.

Sorry about the issue. There were failed workflows after I merged with the latest JDK master this morning. I canceled the workflow and tried a rerun, which didn't work. I retried with a new commit with merging again. And noticed the GHA was off after merging with the latest master, but didn't know what caused it. The last night tests in the workflow (before merging with the master) were successful. So I proceeded with integration.

Please let me know if we should back out or fix forward ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542779168

From erikj at openjdk.org  Wed May 10 21:04:54 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 10 May 2023 21:04:54 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v12]
In-Reply-To: <xPpKzqozMUHOygmSqjtim7SVnnCy0KEPM8iO6b5HwrA=.8750f9aa-422d-4678-8d6d-7d555ca7ac09@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <IYLdLeipy3ADnQkE6calR-sbud1Z5KZlbPk6-jcZ1jE=.fccfa5bf-f028-41c3-a97b-ecba7017087a@github.com>
 <wNgaBjhwye3gcgLGyfGDwStRWpjy0_V7lntfdsmLdPc=.9d74ae1b-3916-4dc8-8721-88dfb33b19e1@github.com>
 <xPpKzqozMUHOygmSqjtim7SVnnCy0KEPM8iO6b5HwrA=.8750f9aa-422d-4678-8d6d-7d555ca7ac09@github.com>
Message-ID: <nr8AlQAbiLOEKvd1qaDeSolSc-rlQOSKR0il7zhTOT8=.d2bb9b81-3427-4e58-85db-5fef23589dab@github.com>

On Wed, 10 May 2023 20:38:50 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > This change caused all our builds but Linux to fail. Did you verify on other platforms than Linux at all? I see you have GHA turned off.
> 
> Sorry about the issue. There were failed workflows after I merged with the latest JDK master this morning. I canceled the workflow and tried a rerun, which didn't work. I retried with a new commit with merging again. And noticed the GHA was off after merging with the latest master, but didn't know what caused it. The last night tests in the workflow (before merging with the master) were successful. So I proceeded with integration.
> 
> Please let me know if we should back out or fix forward ...

Dan is already backing out in https://github.com/openjdk/jdk/pull/13918, so we have plenty of time to figure out the issues.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542805621

From jiangli at openjdk.org  Wed May 10 21:16:57 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 10 May 2023 21:16:57 GMT
Subject: RFR: 8307194: Add make target for optionally building a complete
 set of all JDK and hotspot libjvm static libraries [v12]
In-Reply-To: <IYLdLeipy3ADnQkE6calR-sbud1Z5KZlbPk6-jcZ1jE=.fccfa5bf-f028-41c3-a97b-ecba7017087a@github.com>
References: <iCzA_oi1VhhphYE1V3nq2Bvu93Xc1jao_gDusK2PE_k=.0119ab89-36bf-4adb-9896-607c45596672@github.com>
 <IYLdLeipy3ADnQkE6calR-sbud1Z5KZlbPk6-jcZ1jE=.fccfa5bf-f028-41c3-a97b-ecba7017087a@github.com>
Message-ID: <CIh59DuYSsVCJRQA0FqMoC2U_zOsJjE-_w778cAbV14=.506eb452-a7dc-4421-8420-eed20d696d41@github.com>

On Wed, 10 May 2023 17:13:13 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>> - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
>> 
>> - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>>  
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>
> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8307194
>  - Merge branch 'master' into JDK-8307194
>  - Address comments from @erikj79:
>    - Fix to use $(STATIC_LIBS_GRAAL_IMAGE_DIR) in GraalBuilderImage.gmk.
>    - Split the long line at 1281 in Main.gmk.
>  - Fix whitspace errors.
>  - Reflect on @erikj79 suggestions/input on static-libs-image/graal-builder-image and supporting libjvm.a for different JVM_VARIANTS:
>    
>    - Remove the new java-static-libs and java-static-libs-bundles targets. Delete the new make/StaticJvmLibsImage.gmk.
>    
>    - Restore HOTSPOT_VARIANT_STATIC_LIBS_TARGETS and related definitions from previous revision for different $(JVM_VARIANTS).
>    - Change the existing static-libs-image target to build libjvm.a in addition to JDK static libraries. The libjvm.a is placed under images/static-libs/lib/<JVM_VARIANTS>. When building multiple JVM variants, each variant contains its own libjvm.a under images/static-libs/lib/<variant> directory.
>    
>    - Add a new static-libs-graal-image target, which is used by graal-builder-image. Hotspot libjvm.a is not created when building static-libs-graal-image and graal-builder-image targets.
>  - Fix whitespace error in make/StaticJvmLibsImage.gmk.
>  - - Separate building libjvm.a from static-libs-image target, based on input from @jerboaa and @olpaw:
>      - Add a new java-static-libs-image target in Main.gmk for creating the JDK .a static libraries and libjvm.a super set. The static libraries are placed in images/static-libs/lib. The existing static-libs-image target is not affected and will not include hotspot libjvm.a.
>      - Add java-static-libs-bundles target in Bundles.gmk. The created .tar.gz bundle contains JDK .a static libraries and hotspot libjvm.a.
>      - Add StaticJvmLibsImage.gmk for placing libjvm.a into images/static-libs/lib.
>    - Further cleanup after incorporating erikj79's suggestion to only build libjvm.a for $(JVM_VARIANT_MAIN) for now:
>      - Change HOTSPOT_VARIANT_STATIC_LIBS_TARGETS to HOTSPOT_VARIANT_MAIN_STATIC_LIBS_TARGETS in Main.gmk.
>      - Change hotspot-$v-static-libs to hotspot-$(JVM_VARIANT_MAIN)-static-libs in Main.gmk.
>  - Update to create and use only hotspot-$(JVM_VARIANT_MAIN)-static-libs, based on @erikj79 input.
>  - Update make/StaticLibsIm...

> > > This change caused all our builds but Linux to fail. Did you verify on other platforms than Linux at all? I see you have GHA turned off.
> > 
> > 
> > Sorry about the issue. There were failed workflows after I merged with the latest JDK master this morning. I canceled the workflow and tried a rerun, which didn't work. I retried with a new commit with merging again. And noticed the GHA was off after merging with the latest master, but didn't know what caused it. The last night tests in the workflow (before merging with the master) were successful. So I proceeded with integration.
> > Please let me know if we should back out or fix forward ...
> 
> Dan is already backing out in #13918, so we have plenty of time to figure out the issues.

Ok, thanks! Sorry about the build failure again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13768#issuecomment-1542817870

From jlu at openjdk.org  Wed May 10 21:27:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 10 May 2023 21:27:42 GMT
Subject: RFR: 8307547: Support for multiple collations for a locale [v2]
In-Reply-To: <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>
Message-ID: <0a7KCg13e-0wh_Tu_sTWJOARq4DevBCS3c5TMSfDZ-g=.85110b0c-af3f-47c8-b9cb-85eae3cf4fef@github.com>

On Wed, 10 May 2023 20:28:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

LGTM, does it make sense to add some other locale's collation variants?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1542828520

From naoto at openjdk.org  Wed May 10 21:54:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 May 2023 21:54:45 GMT
Subject: RFR: 8307547: Support for multiple collations for a locale [v2]
In-Reply-To: <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>
Message-ID: <mHaErUp79h0hStQhWoN-c4sfoPXifLKYc999SUbIp3M=.afcc16f5-6e14-46c3-b1de-d18f05524770@github.com>

On Wed, 10 May 2023 20:28:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

Thanks, Justin

> does it make sense to add some other locale's collation variants?

Maybe, but I am not seeing any requests for adding more collation variants. This enhancement is mainly for those who need the old Swedish collation as a workaround

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1542854951

From mdoerr at openjdk.org  Wed May 10 22:32:55 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 10 May 2023 22:32:55 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v22]
In-Reply-To: <p_Wv3jAoX6Eri1yV1A2_ZhzKTvt1lw8b8gc1AYQUSQc=.036e254a-b796-40d8-9f0d-6a4269c8458a@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <i_lgp3XQaEdsnbxlhXV2TG9vgbGeZj5LhYrFQrDxO2E=.ab081f0c-8350-46ee-b7c0-c4fe08b9c37c@github.com>
 <egE8yOpC518czk87a_8pp5NOO_K38HXJ0uLY57-1Qbk=.d9ce5f44-3ec3-4073-b99a-ad3e05c820ce@github.com>
 <PD6kPJMt3W8xdBYWScP0IQaBT3JSjPqhIK7D_8yMgPU=.07c347c0-2683-4fbd-b787-cdf2f3f1af58@github.com>
 <eVBag-mo-t7zyOLmlhE6ATRH4HU8gbOtudzISc4ogDs=.bedfed76-f5ef-493d-b6d1-ede330d61a4f@github.com>
 <dZaLFlL64aBL4e9_EynSNKftvRI7PpmE0HpRV-CTUB8=.fa9f4470-0c29-4c0e-8301-112891b707d6@github.com>
 <OaxP8DDQPxtNxhyQhKqj2znuuwl1AWCx3zolHIP4yRk=.2b983f23-ba26-44e6-bd2c-a9778a070880@github.com>
 <FCnO8qx-GwmFDTbsLn6d2TB_rXG0vaJVZYCKrxgDFZY=.bfc56ad7-80e3-4e29-86b0-323ff203c442@github.com>
 <3UOaZ75k_vzmyK8rntwXGjUT_Hd1IAtVRkQ5G3zpTr0=.0b46880f-1476-4688-82cc-df853e3f8bf8@github.com>
 <5uv2Nqt_IDeyq2NLXG3RziMSIPTeTnwUnDb9GhFaDEc=.a9728f65-3b53-44eb-94d5-87541d215334@github.com>
 <p_Wv3jAoX6Eri1yV1A2_ZhzKTvt1lw8b8gc
 1AYQUSQc=.036e254a-b796-40d8-9f0d-6a4269c8458a@github.com>
Message-ID: <br-LX-hWkUMyofoG03RSyU6YWwi7nLpK3jSJ1ak-1b0=.2ada423b-7d0f-4c72-9692-c237718831d9@github.com>

On Wed, 10 May 2023 14:26:54 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> FWIW, since Shenandoah changed their load barriers we have been cleaning away the usages of the Access API for loads and stores to primitive values. There's no such support in the C++ Runtime code.
>
> Ok, since this is loading a `long` (which represents an address that points into the code cache) I think we're fine without using the access API then?

Correct. The code had been written for the previous version of Shenandoah (1.0). No current GC uses barriers for non-oop types and the C++ Runtime doesn't support it any more as Stefan pointed out.
It is still possible to use the access API on other platforms, but it does nothing more than a plain load/store for non-oop types.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1190447075

From jlu at openjdk.org  Thu May 11 00:00:49 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 00:00:49 GMT
Subject: Integrated: 8281103: Give example for Locale that is English and
 follows the ISO standards
In-Reply-To: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
References: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
Message-ID: <t42IBmNQFSz16RW8CTYyzhIHExuNRM7kxlLR3pzeoWM=.366393c1-e8e3-4ab3-a4e5-d442856cea93@github.com>

On Tue, 9 May 2023 20:39:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds an example snippet to `java.time.temporal.WeekFields.of(Locale locale)`
> 
> The snippet demonstrates how to create a Locale that has English Locale qualities with an ISO-8601 first day of the week. 
> 
> This snippet was added as there was a desire for an English/ISO-8601 Locale constant to be added, but the existing methods in the JDK are better suited for accomplishing this.

This pull request has now been integrated.

Changeset: 4795c395
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4795c395e9799719dfcdd947fe8905f25f3a11a2
Stats:     9 lines in 1 file changed: 8 ins; 0 del; 1 mod

8281103: Give example for Locale that is English and follows the ISO standards

Reviewed-by: rriggs, lancea, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13893

From jlu at openjdk.org  Thu May 11 00:02:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 00:02:43 GMT
Subject: RFR: 8300794: Use @snippet in java.util:i18n
Message-ID: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>

Please review this javadoc only change which uses `@snippet` and `@linkplain` in i18n related util packages.

-------------

Commit messages:
 - copyright years
 - property resource bundle changes
 - list resource bundle changes
 - resource bundle changes
 - currency changes
 - locale changes

Changes: https://git.openjdk.org/jdk/pull/13920/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13920&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300794
  Stats: 127 lines in 5 files changed: 7 ins; 24 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/13920.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13920/head:pull/13920

PR: https://git.openjdk.org/jdk/pull/13920

From bchristi at openjdk.org  Thu May 11 00:54:03 2023
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 11 May 2023 00:54:03 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: <zq7WnWozl-7vnHdtkyQ3yA7LXRWf64peodpZj_Ss9Jw=.bfff46c7-c906-4bc9-b563-6b0d6b237d41@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

Not yet

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8311#issuecomment-1542989403

From jpai at openjdk.org  Thu May 11 06:59:41 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 May 2023 06:59:41 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v3]
In-Reply-To: <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
Message-ID: <8CHP-dC2sryCgrM03z-9QSPzL3pUlZKJF_2ONerwN_4=.da03a9e3-70b9-405b-9df1-763b8e7aa841@github.com>

On Fri, 5 May 2023 18:38:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Several Handlers class use monitors to synchronize when formatting / publishing LogRecords.
>> When logging within a VirtualThread, holding this monitor can cause the carrier thread to be pinned.
>> Handlers could use jdk.internal.misc.InternalLock, in a similar way to some java.io classes (such as PrintStream) to avoid pinning the carrier thread.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use locks consistently

Marked as reviewed by jpai (Reviewer).

Hello Daniel, from what I see in these changes, the proposed idea is to use `java.util.concurrent.locks.ReentrantLock` by default wherever `synchronized` was used in these `Handler`s.

David already noted that these current synchronizations appear to be to serialize the calls. With the use of the proposed internal `ReentrantLock`s the serialization of the calls would still be maintained when dealing with non-subclassed `Handler`s.

Use of this internal `ReentrantLock` lock is only enabled if the `Handler` class is loaded by the platform classloader. For any other (sub-classed) `Handler`, these existing methods will still continue to use `synchronized` and thus shouldn't have any impact on  the call serialization semantics for such classes.

This change looks OK to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13832#pullrequestreview-1421875299
PR Comment: https://git.openjdk.org/jdk/pull/13832#issuecomment-1543436623

From jpai at openjdk.org  Thu May 11 07:07:41 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 May 2023 07:07:41 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly
In-Reply-To: <muuGxgh_6Q578YJd2Do4qtvQ5m_Ge8PcTr8O5uwb3Qo=.0827ef9f-d0aa-4798-8cd5-70c6d7096b78@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <muuGxgh_6Q578YJd2Do4qtvQ5m_Ge8PcTr8O5uwb3Qo=.0827ef9f-d0aa-4798-8cd5-70c6d7096b78@github.com>
Message-ID: <3_ps9PAbY26RLlStWuarvJsaMz7dqQd7p7TVLJu19bw=.12b2688a-9acf-4a3c-bc59-7d8217f16d82@github.com>

On Fri, 5 May 2023 13:53:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Something I was wondering:

> Use of InternalLock can be disabled with -Djdk.io.useMonitors=true

> But should we have a property to force the use of InternalLock (when enabled) even in the presence of custom handlers subclasses? We could use -Djdk.io.useMonitors=false to mean that - or introduce a new system property specific to java.util.logging.Handlers.

If at all we want to always use an `InternalLock` irrespective of the `-Djdk.io.useMonitors` system property, then perhaps a simpler way might be to introduce new `public static InternalLock newLock()` in `InternalLock` class, which then doesn't check the system property and instead will always return a new lock. That way we wouldn't have to introduce any new system property. That would also mean that we don't expose this control to the application/user, which I think would be a good thing since it's my opinion that this is a bit too complex detail to be configured by the applicaiton.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13832#issuecomment-1543446553

From alanb at openjdk.org  Thu May 11 07:30:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 May 2023 07:30:41 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v3]
In-Reply-To: <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
Message-ID: <ixUL9e5CQjmEcwb3QuOhZVF3kNODIEpkpupVn6Ou93w=.974591be-76fb-4853-bed2-301c59bdd668@github.com>

On Fri, 5 May 2023 18:38:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Several Handlers class use monitors to synchronize when formatting / publishing LogRecords.
>> When logging within a VirtualThread, holding this monitor can cause the carrier thread to be pinned.
>> Handlers could use jdk.internal.misc.InternalLock, in a similar way to some java.io classes (such as PrintStream) to avoid pinning the carrier thread.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use locks consistently

src/java.logging/share/classes/java/util/logging/Handler.java line 88:

> 86:             return null;
> 87:         } else {
> 88:             return InternalLock.newLockOrNull();

I'm surprised to see InternalLock used here. That class was created for the java.io area to avoid surprises when a subclass uses a RL as the lock object. I assume it's just convenience to use it here, that is, I don't think the internal lock is exposed to subclasses in the j.u.logging API.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13832#discussion_r1190745991

From dfuchs at openjdk.org  Thu May 11 07:55:46 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 May 2023 07:55:46 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v3]
In-Reply-To: <ixUL9e5CQjmEcwb3QuOhZVF3kNODIEpkpupVn6Ou93w=.974591be-76fb-4853-bed2-301c59bdd668@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
 <ixUL9e5CQjmEcwb3QuOhZVF3kNODIEpkpupVn6Ou93w=.974591be-76fb-4853-bed2-301c59bdd668@github.com>
Message-ID: <5JAusss7HWhOQQBiC9GKE-d104MO5LTdkMX7lKu9340=.933fa48d-0008-44c0-b062-0805f3389105@github.com>

On Thu, 11 May 2023 07:28:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use locks consistently
>
> src/java.logging/share/classes/java/util/logging/Handler.java line 88:
> 
>> 86:             return null;
>> 87:         } else {
>> 88:             return InternalLock.newLockOrNull();
> 
> I'm surprised to see InternalLock used here. That class was created for the java.io area to avoid surprises when a subclass uses a RL as the lock object. I assume it's just convenience to use it here, that is, I don't think the internal lock is exposed to subclasses in the j.u.logging API.

It's the same reason here: in these classes (and before that change) the lock is `this` which is always exposed to subclasses or external classes. If a handler uses `InternalLock`, and an external class `synchronize(handler)` that could cause surprising effects. My first take at this was simply using `new ReantrantLock()` but I thought it made sense to reuse `InternalLock` instead. After all, there would be no point in not using `synchronized` in StreamHandler if the underlying output stream is a PrintStream for which use of InternalLock has been disabled?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13832#discussion_r1190770759

From dfuchs at openjdk.org  Thu May 11 07:55:46 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 May 2023 07:55:46 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v3]
In-Reply-To: <5JAusss7HWhOQQBiC9GKE-d104MO5LTdkMX7lKu9340=.933fa48d-0008-44c0-b062-0805f3389105@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
 <ixUL9e5CQjmEcwb3QuOhZVF3kNODIEpkpupVn6Ou93w=.974591be-76fb-4853-bed2-301c59bdd668@github.com>
 <5JAusss7HWhOQQBiC9GKE-d104MO5LTdkMX7lKu9340=.933fa48d-0008-44c0-b062-0805f3389105@github.com>
Message-ID: <qTgrGlRT_W3ZpsGXL2-FxGm-HyeaJ5HPw3CvxC2Imyk=.a1bf804d-00d7-49bb-b48a-7470fd6c530e@github.com>

On Thu, 11 May 2023 07:51:12 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.logging/share/classes/java/util/logging/Handler.java line 88:
>> 
>>> 86:             return null;
>>> 87:         } else {
>>> 88:             return InternalLock.newLockOrNull();
>> 
>> I'm surprised to see InternalLock used here. That class was created for the java.io area to avoid surprises when a subclass uses a RL as the lock object. I assume it's just convenience to use it here, that is, I don't think the internal lock is exposed to subclasses in the j.u.logging API.
>
> It's the same reason here: in these classes (and before that change) the lock is `this` which is always exposed to subclasses or external classes. If a handler uses `InternalLock`, and an external class `synchronize(handler)` that could cause surprising effects. My first take at this was simply using `new ReantrantLock()` but I thought it made sense to reuse `InternalLock` instead. After all, there would be no point in not using `synchronized` in StreamHandler if the underlying output stream is a PrintStream for which use of InternalLock has been disabled?

I can revert to using plain `ReentrantLock` if you think it's preferable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13832#discussion_r1190772512

From dfuchs at openjdk.org  Thu May 11 07:58:44 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 May 2023 07:58:44 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v3]
In-Reply-To: <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
Message-ID: <NEzv874l38sC3JmRy0YOaJhhYTdMzOOMltULRA3ACHo=.1881a518-e958-40e2-a11b-74658bd77a68@github.com>

On Fri, 5 May 2023 18:38:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Several Handlers class use monitors to synchronize when formatting / publishing LogRecords.
>> When logging within a VirtualThread, holding this monitor can cause the carrier thread to be pinned.
>> Handlers could use jdk.internal.misc.InternalLock, in a similar way to some java.io classes (such as PrintStream) to avoid pinning the carrier thread.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use locks consistently

> > Something I was wondering:
> 
> > Use of InternalLock can be disabled with -Djdk.io.useMonitors=true
> 
> > But should we have a property to force the use of InternalLock (when enabled) even in the presence of custom handlers subclasses? We could use -Djdk.io.useMonitors=false to mean that - or introduce a new system property specific to java.util.logging.Handlers.
> 
> If at all we want to always use an `InternalLock` irrespective of the `-Djdk.io.useMonitors` system property, then perhaps a simpler way might be to introduce new
> 
> ```java
> public static InternalLock newLock()
> ```
> 
> method in `InternalLock` class, which then doesn't check the system property and instead will always return a new lock. That way we wouldn't have to introduce any new system property. That would also mean that we don't expose this control to the application/user, which I think would be a good thing since it's my opinion that this is a bit too complex detail to be configured by the applicaiton.

My concern was the opposite: do we need a property to force usage of `j.u.c.Lock` (and disable use of synchronized) even if the handler is subclassed by a custom subclass outside of the JDK?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13832#issuecomment-1543514267

From rrich at openjdk.org  Thu May 11 08:28:53 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Thu, 11 May 2023 08:28:53 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v22]
In-Reply-To: <br-LX-hWkUMyofoG03RSyU6YWwi7nLpK3jSJ1ak-1b0=.2ada423b-7d0f-4c72-9692-c237718831d9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <i_lgp3XQaEdsnbxlhXV2TG9vgbGeZj5LhYrFQrDxO2E=.ab081f0c-8350-46ee-b7c0-c4fe08b9c37c@github.com>
 <egE8yOpC518czk87a_8pp5NOO_K38HXJ0uLY57-1Qbk=.d9ce5f44-3ec3-4073-b99a-ad3e05c820ce@github.com>
 <PD6kPJMt3W8xdBYWScP0IQaBT3JSjPqhIK7D_8yMgPU=.07c347c0-2683-4fbd-b787-cdf2f3f1af58@github.com>
 <eVBag-mo-t7zyOLmlhE6ATRH4HU8gbOtudzISc4ogDs=.bedfed76-f5ef-493d-b6d1-ede330d61a4f@github.com>
 <dZaLFlL64aBL4e9_EynSNKftvRI7PpmE0HpRV-CTUB8=.fa9f4470-0c29-4c0e-8301-112891b707d6@github.com>
 <OaxP8DDQPxtNxhyQhKqj2znuuwl1AWCx3zolHIP4yRk=.2b983f23-ba26-44e6-bd2c-a9778a070880@github.com>
 <FCnO8qx-GwmFDTbsLn6d2TB_rXG0vaJVZYCKrxgDFZY=.bfc56ad7-80e3-4e29-86b0-323ff203c442@github.com>
 <3UOaZ75k_vzmyK8rntwXGjUT_Hd1IAtVRkQ5G3zpTr0=.0b46880f-1476-4688-82cc-df853e3f8bf8@github.com>
 <5uv2Nqt_IDeyq2NLXG3RziMSIPTeTnwUnDb9GhFaDEc=.a9728f65-3b53-44eb-94d5-87541d215334@github.com>
 <p_Wv3jAoX6Eri1yV1A2_ZhzKTvt1lw8b8gc
 1AYQUSQc=.036e254a-b796-40d8-9f0d-6a4269c8458a@github.com>
 <br-LX-hWkUMyofoG03RSyU6YWwi7nLpK3jSJ1ak-1b0=.2ada423b-7d0f-4c72-9692-c237718831d9@github.com>
Message-ID: <sWXFhq621NVe1WZuEI-1gLXUFTUUlpoohFiOMasYnSE=.eccd4263-a7f9-42f6-9428-91253fa2fe1d@github.com>

On Wed, 10 May 2023 22:30:13 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Ok, since this is loading a `long` (which represents an address that points into the code cache) I think we're fine without using the access API then?
>
> Correct. The code had been written for the previous version of Shenandoah (1.0). No current GC uses barriers for non-oop types and the C++ Runtime doesn't support it any more as Stefan pointed out.
> It is still possible to use the access API on other platforms, but it does nothing more than a plain load/store for non-oop types.

I'm ok with doing a plain access. I don't like the difference to other ports as it will at least waste time of people with less expertise in the area (e.g. new to the project). No need to continue the discussion in this pr though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1190812209

From alanb at openjdk.org  Thu May 11 08:54:43 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 May 2023 08:54:43 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v3]
In-Reply-To: <qTgrGlRT_W3ZpsGXL2-FxGm-HyeaJ5HPw3CvxC2Imyk=.a1bf804d-00d7-49bb-b48a-7470fd6c530e@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
 <ixUL9e5CQjmEcwb3QuOhZVF3kNODIEpkpupVn6Ou93w=.974591be-76fb-4853-bed2-301c59bdd668@github.com>
 <5JAusss7HWhOQQBiC9GKE-d104MO5LTdkMX7lKu9340=.933fa48d-0008-44c0-b062-0805f3389105@github.com>
 <qTgrGlRT_W3ZpsGXL2-FxGm-HyeaJ5HPw3CvxC2Imyk=.a1bf804d-00d7-49bb-b48a-7470fd6c530e@github.com>
Message-ID: <XSLNk6-XgRfwNUg6aXu1lJBl_XLFD9MCkqnO2fVYm1A=.0bb39f08-2d60-4910-87e5-994c348d9a3e@github.com>

On Thu, 11 May 2023 07:52:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> It's the same reason here: in these classes (and before that change) the lock is `this` which is always exposed to subclasses or external classes. If a handler uses `InternalLock`, and an external class `synchronize(handler)` that could cause surprising effects. My first take at this was simply using `new ReantrantLock()` but I thought it made sense to reuse `InternalLock` instead. After all, there would be no point in not using `synchronized` in StreamHandler if the underlying output stream is a PrintStream for which use of InternalLock has been disabled?
>
> I can revert to using plain `ReentrantLock` if you think it's preferable.

> It's the same reason here: in these classes (and before that change) the lock is `this` which is always exposed to subclasses or external classes. If a handler uses `InternalLock`, and an external class `synchronize(handler)` that could cause surprising effects. My first take at this was simply using `new ReantrantLock()` but I thought it made sense to reuse `InternalLock` instead. After all, there would be no point in not using `synchronized` in StreamHandler if the underlying output stream is a PrintStream for which use of InternalLock has been disabled?

The reason for InternalLock is because the Reader/Write "lock" field is exposed to subclasses and there is a possibility that a subclass could set the lock field to an instance of ReentrantLock and confusing all the locking.  You don't have this issue in j.u.logging. I am not objecting to using InternalLock, just surprised to see it being used here as I had assumed you'd just create your own explicit lock when not subclassed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13832#discussion_r1190850618

From rgiulietti at openjdk.org  Thu May 11 09:22:44 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 11 May 2023 09:22:44 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage [v2]
In-Reply-To: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
Message-ID: <l2Q_DjpYI9Rh5lBUzH_YclTIXR-R01VdApIBsPyOx_c=.1f5ef6f2-3e82-4b37-9144-0a4f2114f9b9@github.com>

> When appropriate and useful, copies only the relevant portion of the `CharSequence` to the match result.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Added some randomness in tests.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13231/files
  - new: https://git.openjdk.org/jdk/pull/13231/files/7d6aba38..160b970a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13231&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13231&range=00-01

  Stats: 38 lines in 1 file changed: 24 ins; 8 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13231/head:pull/13231

PR: https://git.openjdk.org/jdk/pull/13231

From alanb at openjdk.org  Thu May 11 09:47:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 May 2023 09:47:45 GMT
Subject: RFR: 8307547: Support for multiple collations for a locale [v2]
In-Reply-To: <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>
Message-ID: <B1v_fYstfh9PyopYCIaBvIgPTmuPDycG35Wb6bxF2K8=.184ecc72-a3b4-471e-bba4-6556b3cee582@github.com>

On Wed, 10 May 2023 20:28:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

src/java.base/share/classes/java/text/Collator.java line 131:

> 129:  * </blockquote>
> 130:  * may return a {@code Collator} instance with the traditional sorting, which
> 131:  * gives 'v' and 'w' the same sorting order.

The overall intent and wording looks okay but I wonder if it should be in the getInstance methods instead. Also wondering whether impNote is right because it's both informational for developers using the API and useful to implementors.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13917#discussion_r1190915577

From mcimadamore at openjdk.org  Thu May 11 09:48:51 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 11 May 2023 09:48:51 GMT
Subject: Integrated: 8307610: Linker::nativeLinker should not be restricted
 (mainline)
In-Reply-To: <8owRB5GDdEv2aRLKJO3NHtMNoXnmCf3Pd2GfwUtO-Go=.f6234082-15f1-4f3e-ba69-22818a86e984@github.com>
References: <8owRB5GDdEv2aRLKJO3NHtMNoXnmCf3Pd2GfwUtO-Go=.f6234082-15f1-4f3e-ba69-22818a86e984@github.com>
Message-ID: <VMfzrSqoEeApqUJIRBT-ZqqdUlMiTf03JFUjWtVRwQU=.6bad58a3-b839-4763-9cff-60a2f66e891e@github.com>

On Mon, 8 May 2023 11:10:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Port of: https://git.openjdk.org/panama-foreign/pull/831

This pull request has now been integrated.

Changeset: ba9714d4
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba9714d44ceabdb98078a4338fb8e8a3e22adcbe
Stats:     128 lines in 11 files changed: 65 ins; 17 del; 46 mod

8307610: Linker::nativeLinker should not be restricted (mainline)

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/13863

From rgiulietti at openjdk.org  Thu May 11 09:58:58 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 11 May 2023 09:58:58 GMT
Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded
 double streams to RandomGenerator [v9]
In-Reply-To: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
Message-ID: <dKg_t__7vqwC9rEXRFmSu-Hngq9V023st7Zanbbe-gU=.92217c43-5237-4bc5-90e7-63662f505d87@github.com>

> The `default` method `nextDouble(double origin, double bound)` in `java.util.random.RandomGenerator` aims at generating a uniformly and spatially equidistributed random `double` in the left-closed and right-open range [`origin`, `bound`). It does so by applying the affine transform `origin + (bound - origin) * r` to a uniformly and spatially equidistributed random `double` `r` in the range [0, 1).
> 
> Since floating-point arithmetic suffers from small but noticeable rounding errors, this ends up slightly deforming the distribution of `r` when applying the affine transform.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Make better use of RandomFactory.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12719/files
  - new: https://git.openjdk.org/jdk/pull/12719/files/b867d275..b3667a95

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=07-08

  Stats: 35 lines in 1 file changed: 1 ins; 4 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/12719.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12719/head:pull/12719

PR: https://git.openjdk.org/jdk/pull/12719

From mcimadamore at openjdk.org  Thu May 11 10:06:42 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 11 May 2023 10:06:42 GMT
Subject: RFR: 8307911: javadoc for MemorySegment::reinterpret has duplicate
 restricted method paragraph
Message-ID: <dtNvM-_Fp3I16qPvjT5SWFVmn0qcFkqj2ymDhVIlBxk=.699c2ecb-553c-4c10-a5d3-60952e0d62e3@github.com>

As the title says, this patch fixes an issue with `MemorySegment::reinterpet`, which reports the customary "restricted method" section twice.

I also fixed some wrong capitalization in the text of the factories in `Linker.Option`.

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/13926/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13926&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307911
  Stats: 8 lines in 2 files changed: 0 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13926.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13926/head:pull/13926

PR: https://git.openjdk.org/jdk/pull/13926

From dfuchs at openjdk.org  Thu May 11 10:15:44 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 May 2023 10:15:44 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v3]
In-Reply-To: <XSLNk6-XgRfwNUg6aXu1lJBl_XLFD9MCkqnO2fVYm1A=.0bb39f08-2d60-4910-87e5-994c348d9a3e@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
 <ixUL9e5CQjmEcwb3QuOhZVF3kNODIEpkpupVn6Ou93w=.974591be-76fb-4853-bed2-301c59bdd668@github.com>
 <5JAusss7HWhOQQBiC9GKE-d104MO5LTdkMX7lKu9340=.933fa48d-0008-44c0-b062-0805f3389105@github.com>
 <qTgrGlRT_W3ZpsGXL2-FxGm-HyeaJ5HPw3CvxC2Imyk=.a1bf804d-00d7-49bb-b48a-7470fd6c530e@github.com>
 <XSLNk6-XgRfwNUg6aXu1lJBl_XLFD9MCkqnO2fVYm1A=.0bb39f08-2d60-4910-87e5-994c348d9a3e@github.com>
Message-ID: <3AmnoQs_sOrDia2gX8v0_SDOatF5_1_WBU79mzyROY8=.f58177d6-0e4c-4d8f-8408-f43d6b8746eb@github.com>

On Thu, 11 May 2023 08:51:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I can revert to using plain `ReentrantLock` if you think it's preferable.
>
>> It's the same reason here: in these classes (and before that change) the lock is `this` which is always exposed to subclasses or external classes. If a handler uses `InternalLock`, and an external class `synchronize(handler)` that could cause surprising effects. My first take at this was simply using `new ReantrantLock()` but I thought it made sense to reuse `InternalLock` instead. After all, there would be no point in not using `synchronized` in StreamHandler if the underlying output stream is a PrintStream for which use of InternalLock has been disabled?
> 
> The reason for InternalLock is because the Reader/Write "lock" field is exposed to subclasses and there is a possibility that a subclass could set the lock field to an instance of ReentrantLock and confusing all the locking.  You don't have this issue in j.u.logging. I am not objecting to using InternalLock, just surprised to see it being used here as I had assumed you'd just create your own explicit lock when not subclassed.

It's the same usage than in `PrintStream`: the lock in `PrintStream` is an `InternalLock` even though it's never exposed to subclasses (it's a private field). My rationale was that if the underlying `PrintStream` uses `synchronized` and doesn't use `InternalLock`, because `-Djdk.io.useMonitors=true`, then there's no point in the `Handler` trying to avoid using `synchronized`. Though I admit that not all `Handlers` wrap a `PrintStream`, the `FileHandler` and `ConsoleHandler` (which are the more important ready-to-use concrete implementations) will eventually delegate to some underlying IO class that will be impacted by `-Djdk.io.useMonitors=true`. So I was thinking that we could/should use the same logic there.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13832#discussion_r1190950653

From dfuchs at openjdk.org  Thu May 11 10:18:41 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 May 2023 10:18:41 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v3]
In-Reply-To: <3AmnoQs_sOrDia2gX8v0_SDOatF5_1_WBU79mzyROY8=.f58177d6-0e4c-4d8f-8408-f43d6b8746eb@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
 <ixUL9e5CQjmEcwb3QuOhZVF3kNODIEpkpupVn6Ou93w=.974591be-76fb-4853-bed2-301c59bdd668@github.com>
 <5JAusss7HWhOQQBiC9GKE-d104MO5LTdkMX7lKu9340=.933fa48d-0008-44c0-b062-0805f3389105@github.com>
 <qTgrGlRT_W3ZpsGXL2-FxGm-HyeaJ5HPw3CvxC2Imyk=.a1bf804d-00d7-49bb-b48a-7470fd6c530e@github.com>
 <XSLNk6-XgRfwNUg6aXu1lJBl_XLFD9MCkqnO2fVYm1A=.0bb39f08-2d60-4910-87e5-994c348d9a3e@github.com>
 <3AmnoQs_sOrDia2gX8v0_SDOatF5_1_WBU79mzyROY8=.f58177d6-0e4c-4d8f-8408-f43d6b8746eb@github.com>
Message-ID: <t4AHlgn9v_CrwRwM2WxY5o4pw7q1YddyIgyFtXVDvR8=.10bd9ff7-bc07-4824-a9d7-d3962a9e97d8@github.com>

On Thu, 11 May 2023 10:13:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> It's the same reason here: in these classes (and before that change) the lock is `this` which is always exposed to subclasses or external classes. If a handler uses `InternalLock`, and an external class `synchronize(handler)` that could cause surprising effects. My first take at this was simply using `new ReantrantLock()` but I thought it made sense to reuse `InternalLock` instead. After all, there would be no point in not using `synchronized` in StreamHandler if the underlying output stream is a PrintStream for which use of InternalLock has been disabled?
>> 
>> The reason for InternalLock is because the Reader/Write "lock" field is exposed to subclasses and there is a possibility that a subclass could set the lock field to an instance of ReentrantLock and confusing all the locking.  You don't have this issue in j.u.logging. I am not objecting to using InternalLock, just surprised to see it being used here as I had assumed you'd just create your own explicit lock when not subclassed.
>
> It's the same usage than in `PrintStream`: the lock in `PrintStream` is an `InternalLock` even though it's never exposed to subclasses (it's a private field). My rationale was that if the underlying `PrintStream` uses `synchronized` and doesn't use `InternalLock`, because `-Djdk.io.useMonitors=true`, then there's no point in the `Handler` trying to avoid using `synchronized`. Though I admit that not all `Handlers` wrap a `PrintStream`, the `FileHandler` and `ConsoleHandler` (which are the more important ready-to-use concrete implementations) will eventually delegate to some underlying IO class that will be impacted by `-Djdk.io.useMonitors=true`. So I was thinking that we could/should use the same logic there.

Ah - I see that `PrintStream` lock can be accessed through SharedSecrets... Hmmm. OK - then maybe I should leave InternalLock alone and just use ReentrantLock. Let me prototype that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13832#discussion_r1190953432

From jpai at openjdk.org  Thu May 11 10:27:41 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 11 May 2023 10:27:41 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v3]
In-Reply-To: <t4AHlgn9v_CrwRwM2WxY5o4pw7q1YddyIgyFtXVDvR8=.10bd9ff7-bc07-4824-a9d7-d3962a9e97d8@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
 <ixUL9e5CQjmEcwb3QuOhZVF3kNODIEpkpupVn6Ou93w=.974591be-76fb-4853-bed2-301c59bdd668@github.com>
 <5JAusss7HWhOQQBiC9GKE-d104MO5LTdkMX7lKu9340=.933fa48d-0008-44c0-b062-0805f3389105@github.com>
 <qTgrGlRT_W3ZpsGXL2-FxGm-HyeaJ5HPw3CvxC2Imyk=.a1bf804d-00d7-49bb-b48a-7470fd6c530e@github.com>
 <XSLNk6-XgRfwNUg6aXu1lJBl_XLFD9MCkqnO2fVYm1A=.0bb39f08-2d60-4910-87e5-994c348d9a3e@github.com>
 <3AmnoQs_sOrDia2gX8v0_SDOatF5_1_WBU79mzyROY8=.f58177d6-0e4c-4d8f-8408-f43d6b8746eb@github.com>
 <t4AHlgn9v_CrwRwM2WxY5o4pw7q1YddyIgyFtXVDvR8=.10bd9ff7-bc07-4824-a9d7-d3962a9e97d8@github.com>
Message-ID: <9a80HOHfNsU4deehDfOTWXqahIuhkeI-6yY-jlz8INc=.629dc69d-e6a4-4e48-b01a-e847b9c7303f@github.com>

On Thu, 11 May 2023 10:15:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Ah - I see that PrintStream lock can be accessed through SharedSecrets

I think Alan was talking about the 

protected Object lock

on `java.io.Reader` and `java.io.Writer` classes which can be manipulated by their sub-classes and that's what prompted the creation of the new type, - `InternalLock` class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13832#discussion_r1190963255

From jlaskey at openjdk.org  Thu May 11 10:54:12 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 11 May 2023 10:54:12 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v12]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <2hfZpzvDkrICXlLe0Dl09tcVut4zF8ahGixTc8I3yHo=.0b0786e1-d364-4b44-b815-a29ecb2d304a@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Merge branch 'master' into 8306112
 - Refactor source code launcher
 - Typo
 - Recommended changes #2
 - Anonymous main classes renamed to unnamed classes
 - Add test
 - Move AnonymousMainClass to parser
 - Revert java launch
 - Leave exception alone
 - Unused variables
 - ... and 16 more: https://git.openjdk.org/jdk/compare/cc396895...c3cfa837

-------------

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=11
  Stats: 1234 lines in 28 files changed: 1068 ins; 77 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From dfuchs at openjdk.org  Thu May 11 11:02:42 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 May 2023 11:02:42 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v3]
In-Reply-To: <9a80HOHfNsU4deehDfOTWXqahIuhkeI-6yY-jlz8INc=.629dc69d-e6a4-4e48-b01a-e847b9c7303f@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
 <ixUL9e5CQjmEcwb3QuOhZVF3kNODIEpkpupVn6Ou93w=.974591be-76fb-4853-bed2-301c59bdd668@github.com>
 <5JAusss7HWhOQQBiC9GKE-d104MO5LTdkMX7lKu9340=.933fa48d-0008-44c0-b062-0805f3389105@github.com>
 <qTgrGlRT_W3ZpsGXL2-FxGm-HyeaJ5HPw3CvxC2Imyk=.a1bf804d-00d7-49bb-b48a-7470fd6c530e@github.com>
 <XSLNk6-XgRfwNUg6aXu1lJBl_XLFD9MCkqnO2fVYm1A=.0bb39f08-2d60-4910-87e5-994c348d9a3e@github.com>
 <3AmnoQs_sOrDia2gX8v0_SDOatF5_1_WBU79mzyROY8=.f58177d6-0e4c-4d8f-8408-f43d6b8746eb@github.com>
 <t4AHlgn9v_CrwRwM2WxY5o4pw7q1YddyIgyFtXVDvR8=.10bd9ff7-bc07-4824-a9d7-d3962a9e97d8@github.com>
 <9a80HOHfNsU4deehDfOTWXqahIuhkeI-6yY-jlz8INc=.629dc69d-e6a4-4e48-b01a-e847b9c7303f@github.com>
Message-ID: <iBWYmb1yJfEwzVLkhwC9YIMn_hPUherh7aR6s9iYfnI=.0e4923de-2d8a-4011-a817-63f6671995ee@github.com>

On Thu, 11 May 2023 10:24:34 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ah - I see that `PrintStream` lock can be accessed through SharedSecrets... Hmmm. OK - then maybe I should leave InternalLock alone and just use ReentrantLock. Let me prototype that.
>
>> Ah - I see that PrintStream lock can be accessed through SharedSecrets
> 
> I think Alan was talking about the 
> 
> protected Object lock
> 
> on `java.io.Reader` and `java.io.Writer` classes which can be manipulated by their sub-classes and that's what prompted the creation of the new type, - `InternalLock` class.

Yes - but InternalLock is not only used in those cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13832#discussion_r1190998001

From jlaskey at openjdk.org  Thu May 11 11:25:51 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 11 May 2023 11:25:51 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update VirtualParser.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/c3cfa837..90b1e981

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=11-12

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From jlu at openjdk.org  Thu May 11 15:48:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 15:48:40 GMT
Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java
Message-ID: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>

Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).

The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, `EquivMapsGenerator.java` builds the same.

-------------

Commit messages:
 - Replace ws with escaped newline
 - get rid of ws
 - Reduce duplication
 - Merge master and resolve conflicts
 - Reorder methods / text variables
 - Use Java text blocks and String format

Changes: https://git.openjdk.org/jdk/pull/13935/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306597
  Stats: 164 lines in 1 file changed: 73 ins; 63 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/13935.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13935/head:pull/13935

PR: https://git.openjdk.org/jdk/pull/13935

From jlahoda at openjdk.org  Thu May 11 16:49:14 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 11 May 2023 16:49:14 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v10]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <VdzI_aIXl52wVPehiTFZQPi7dXg8s57kF_fjwTCPm0E=.7beaa138-09e8-4a9f-961e-cbf37ab64293@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits:

 - Merge branch 'master' into JDK-8300543
 - Updating MatchException javadoc.
 - Merge branch 'master' into JDK-8300543
 - Reverting use of record patterns in enhanced for loop.
 - Cleanup: reflecting review feedback.
 - Merge branch 'master' into JDK-8300543
 - Reflecting review changes.
 - Adding test.
 - Removing redundant continue, as noted on the review.
 - Replacing use of mutable callsite with a mutable state.
 - ... and 33 more: https://git.openjdk.org/jdk/compare/2bf7ac58...69ba2a57

-------------

Changes: https://git.openjdk.org/jdk/pull/13074/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=09
  Stats: 4256 lines in 158 files changed: 2027 ins; 1716 del; 513 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

PR: https://git.openjdk.org/jdk/pull/13074

From naoto at openjdk.org  Thu May 11 18:06:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 18:06:34 GMT
Subject: RFR: 8307547: Support for multiple collations for a locale [v2]
In-Reply-To: <B1v_fYstfh9PyopYCIaBvIgPTmuPDycG35Wb6bxF2K8=.184ecc72-a3b4-471e-bba4-6556b3cee582@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>
 <B1v_fYstfh9PyopYCIaBvIgPTmuPDycG35Wb6bxF2K8=.184ecc72-a3b4-471e-bba4-6556b3cee582@github.com>
Message-ID: <yJSz4AgUfl5hVlfgZwdnmn5h10js29Z6KlQrzzgLlGs=.51a9e9ce-1b0e-4a9a-a3df-31f186512584@github.com>

On Thu, 11 May 2023 09:44:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   http -> https
>
> src/java.base/share/classes/java/text/Collator.java line 131:
> 
>> 129:  * </blockquote>
>> 130:  * may return a {@code Collator} instance with the traditional sorting, which
>> 131:  * gives 'v' and 'w' the same sorting order.
> 
> The overall intent and wording looks okay but I wonder if it should be in the getInstance methods instead. Also wondering whether impNote is right because it's both informational for developers using the API and useful to implementors.

Thanks. Will move it out of the class description into each `getInstance()` method, changing @implNote to @apiNote

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13917#discussion_r1191526144

From dfuchs at openjdk.org  Thu May 11 18:34:45 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 May 2023 18:34:45 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v4]
In-Reply-To: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
Message-ID: <ocy3S4R8W7aXC-nl4jxFC88WDXLkzPcFJlVPKCSKW1w=.5860823a-b2ce-47b1-9d25-eb49a5fc86af@github.com>

> Several Handlers class use monitors to synchronize when formatting / publishing LogRecords.
> When logging within a VirtualThread, holding this monitor can cause the carrier thread to be pinned.
> Handlers could use jdk.internal.misc.InternalLock, in a similar way to some java.io classes (such as PrintStream) to avoid pinning the carrier thread.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Use ReentrantLock directly

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13832/files
  - new: https://git.openjdk.org/jdk/pull/13832/files/282c6e1b..ce4238f1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13832&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13832&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13832.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13832/head:pull/13832

PR: https://git.openjdk.org/jdk/pull/13832

From jlu at openjdk.org  Thu May 11 18:34:49 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 18:34:49 GMT
Subject: RFR: 6714245: [Col] Collator - Faster Comparison for identical
 strings.
Message-ID: <GXUyAGggDuYZaMrle9tFpi1XJjboeLu0PoT6bfcnXn8=.a8ce6ff2-c204-479e-a3ee-1cbdf36a39fe@github.com>

Please review this PR which adds an initial equality check to `RuleBasedCollator.compare(String source, String target)`.

This speeds up the operation for equal input Strings, as it bypasses Collator rule comparisons of each element for both of the input Strings.

-------------

Commit messages:
 - Check for equality first in compare(string, string)

Changes: https://git.openjdk.org/jdk/pull/13938/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13938&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-6714245
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13938.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13938/head:pull/13938

PR: https://git.openjdk.org/jdk/pull/13938

From dfuchs at openjdk.org  Thu May 11 18:34:47 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 May 2023 18:34:47 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v3]
In-Reply-To: <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <19dcypzqeo01oRPpQ1Ohn6luEjVDY2diZGuA3FDEZ74=.a4c5b52c-df1d-477c-967d-791b96b53fb3@github.com>
Message-ID: <G781hDl8cNDXN-Lk129h1JOfhCFCg6e0eOIwbPusgLU=.9b26fc00-2731-4fae-8d9b-abe0f03e08b9@github.com>

On Fri, 5 May 2023 18:38:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Several Handlers class use monitors to synchronize when formatting / publishing LogRecords.
>> When logging within a VirtualThread, holding this monitor can cause the carrier thread to be pinned.
>> Handlers could use jdk.internal.misc.InternalLock, in a similar way to some java.io classes (such as PrintStream) to avoid pinning the carrier thread.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use locks consistently

@AlanBateman I dropped `InternalLock` and use `ReentrantLock` directly. No other change compared to previous version.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13832#issuecomment-1544488656

From naoto at openjdk.org  Thu May 11 18:35:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 18:35:50 GMT
Subject: RFR: 8307547: Support for multiple collations for a locale [v3]
In-Reply-To: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
Message-ID: <Yb213i_JoiQcTzX08Tj6OehSfDsOHrcMrq44FrQ_fZY=.5aac62a5-02d2-4f11-a8b7-aac9d9beacb6@github.com>

> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13917/files
  - new: https://git.openjdk.org/jdk/pull/13917/files/9f0eb048..29b1c8c4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13917&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13917&range=01-02

  Stats: 29 lines in 1 file changed: 12 ins; 16 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13917.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13917/head:pull/13917

PR: https://git.openjdk.org/jdk/pull/13917

From rriggs at openjdk.org  Thu May 11 20:26:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 11 May 2023 20:26:37 GMT
Subject: RFR: 6714245: [Col] Collator - Faster Comparison for identical
 strings.
In-Reply-To: <GXUyAGggDuYZaMrle9tFpi1XJjboeLu0PoT6bfcnXn8=.a8ce6ff2-c204-479e-a3ee-1cbdf36a39fe@github.com>
References: <GXUyAGggDuYZaMrle9tFpi1XJjboeLu0PoT6bfcnXn8=.a8ce6ff2-c204-479e-a3ee-1cbdf36a39fe@github.com>
Message-ID: <ePhObFCDJtaLlrm6SM5Uqejmn3lDmeEz-lIFlQk8VFw=.4d800415-4ee8-420a-8a69-4137154e5b7d@github.com>

On Thu, 11 May 2023 18:27:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds an initial equality check to `RuleBasedCollator.compare(String source, String target)`.
> 
> This speeds up the operation for equal input Strings, as it bypasses Collator rule comparisons of each element for both of the input Strings.

It certainly seems like a win in all cases.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13938#pullrequestreview-1423380835

From naoto at openjdk.org  Thu May 11 20:25:37 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 20:25:37 GMT
Subject: RFR: 8300794: Use @snippet in java.util:i18n
In-Reply-To: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
References: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
Message-ID: <c2-mW9V9c-k788lDgDKCx9wvZ0J0JAqmeSHViSHp1e4=.1149b02f-eb65-46ec-9158-7054eda5c25a@github.com>

On Wed, 10 May 2023 23:54:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this javadoc only change which uses `@snippet` and `@linkplain` in i18n related util packages.

Looks good overall. Some minor comments follow.

src/java.base/share/classes/java/util/Currency.java line 517:

> 515:      * If the default {@link Locale.Category#DISPLAY DISPLAY} locale
> 516:      * contains "rg" (region override)
> 517:      * {@linkplain Locale##def_locale_extension Unicode extensions},

Good catch on plurals

src/java.base/share/classes/java/util/PropertyResourceBundle.java line 85:

> 83:  * {@snippet lang=properties :
> 84:  *     # MessageFormat pattern
> 85:  *     s1=Die Platte \"{1}\" enth\u00E4lt {0}.

I was wondering if the Unicode escape would convert correctly or not, so I tried and found it fine.

src/java.base/share/classes/java/util/ResourceBundle.java line 334:

> 332:  *         if (key.equals("cancelKey")) {
> 333:  *            return "Cancel";
> 334:  *         }

Indentation is inconsistent

src/java.base/share/classes/java/util/ResourceBundle.java line 354:

> 352:  *         // don't need okKey, since parent level handles it.
> 353:  *         if (key.equals("cancelKey")) {
> 354:  *            return "Abbrechen";

Same here

src/java.base/share/classes/java/util/ResourceBundle.java line 512:

> 510:      * Calling this method is equivalent to calling
> 511:      * {@snippet lang=java :
> 512:      *     (String[]) getObject(key); // @link substring="getObject" target="#getObject(java.lang.String)"

`// @link` can be a separate line, placed on top of the target text

-------------

PR Review: https://git.openjdk.org/jdk/pull/13920#pullrequestreview-1423359717
PR Review Comment: https://git.openjdk.org/jdk/pull/13920#discussion_r1191640956
PR Review Comment: https://git.openjdk.org/jdk/pull/13920#discussion_r1191642383
PR Review Comment: https://git.openjdk.org/jdk/pull/13920#discussion_r1191642638
PR Review Comment: https://git.openjdk.org/jdk/pull/13920#discussion_r1191643088
PR Review Comment: https://git.openjdk.org/jdk/pull/13920#discussion_r1191652752

From jlu at openjdk.org  Thu May 11 20:21:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 20:21:57 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Convert the merged master changes to UTF-8
 - Merge master and fix conflicts
 - Close streams when finished loading into props
 - Adjust CF test to read in with UTF-8 to fix failing test
 - Reconvert CS.properties to UTF-8
 - Revert all changes to CurrencySymbols.properties
 - Bug6204853 should not be converted
 - Copyright year for CompileProperties
 - Redo translation for CS.properties
 - Spot convert CurrencySymbols.properties
 - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

-------------

Changes: https://git.openjdk.org/jdk/pull/12726/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=05
  Stats: 28877 lines in 493 files changed: 14 ins; 1 del; 28862 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726

From naoto at openjdk.org  Thu May 11 20:37:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 20:37:40 GMT
Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java
In-Reply-To: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
Message-ID: <J_ab01vZ5eZ85t1DKECQ6etN0z_b4y1JczKyGT5knWA=.924d127b-91ed-4c6b-9a25-e833fc419eaf@github.com>

On Thu, 11 May 2023 15:40:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
> 
> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, `EquivMapsGenerator.java` builds the same.

Looks good, with some cosmetic suggestions

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 269:

> 267:              * or visit www.oracle.com if you need additional information or have any
> 268:              * questions.
> 269:             */\n

Can be a simple new line instead of `\n`. Also holds for other text blocks.

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 272:

> 270:             """;
> 271: 
> 272:     private static final String headerText =

Not your change, but I'd capitalize those static final Strings

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 295:

> 293:     }
> 294: 
> 295:     private static final String getlsrText(){

getLSRText?

-------------

PR Review: https://git.openjdk.org/jdk/pull/13935#pullrequestreview-1423387718
PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1191658464
PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1191661027
PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1191663140

From naoto at openjdk.org  Thu May 11 20:39:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 20:39:33 GMT
Subject: RFR: 6714245: [Col] Collator - Faster Comparison for identical
 strings.
In-Reply-To: <GXUyAGggDuYZaMrle9tFpi1XJjboeLu0PoT6bfcnXn8=.a8ce6ff2-c204-479e-a3ee-1cbdf36a39fe@github.com>
References: <GXUyAGggDuYZaMrle9tFpi1XJjboeLu0PoT6bfcnXn8=.a8ce6ff2-c204-479e-a3ee-1cbdf36a39fe@github.com>
Message-ID: <hvuhnqhTZbL3pAZl8i8W6wqVrsLZHPIwYBd81UCWT28=.1f800993-931b-48ef-b0c5-6304f1bb54b2@github.com>

On Thu, 11 May 2023 18:27:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds an initial equality check to `RuleBasedCollator.compare(String source, String target)`.
> 
> This speeds up the operation for equal input Strings, as it bypasses Collator rule comparisons of each element for both of the input Strings.

LGTM. `noreg-perf` issue label might fit better for this

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13938#pullrequestreview-1423398642

From jlu at openjdk.org  Thu May 11 20:39:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 20:39:57 GMT
Subject: RFR: 8300794: Use @snippet in java.util:i18n [v2]
In-Reply-To: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
References: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
Message-ID: <aQtLPpIumIPaSdmeDnWJ3stq4wePpCq4V1YU0B6sO2I=.2b3ab5f1-1fa9-48a6-9628-6a8e0bc7b196@github.com>

> Please review this javadoc only change which uses `@snippet` and `@linkplain` in i18n related util packages.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Review: Move links on top, fix indentation in example

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13920/files
  - new: https://git.openjdk.org/jdk/pull/13920/files/179671e3..e56955e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13920&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13920&range=00-01

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13920.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13920/head:pull/13920

PR: https://git.openjdk.org/jdk/pull/13920

From jlu at openjdk.org  Thu May 11 20:39:58 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 20:39:58 GMT
Subject: RFR: 8300794: Use @snippet in java.util:i18n [v2]
In-Reply-To: <c2-mW9V9c-k788lDgDKCx9wvZ0J0JAqmeSHViSHp1e4=.1149b02f-eb65-46ec-9158-7054eda5c25a@github.com>
References: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
 <c2-mW9V9c-k788lDgDKCx9wvZ0J0JAqmeSHViSHp1e4=.1149b02f-eb65-46ec-9158-7054eda5c25a@github.com>
Message-ID: <PlfFNmidSzX_UU1fxR59DFpHkCOw7NJGT1hrunpjEDM=.0c7d87e2-4efc-41de-b15b-5563b5e9224b@github.com>

On Thu, 11 May 2023 20:21:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review: Move links on top, fix indentation in example
>
> src/java.base/share/classes/java/util/ResourceBundle.java line 512:
> 
>> 510:      * Calling this method is equivalent to calling
>> 511:      * {@snippet lang=java :
>> 512:      *     (String[]) getObject(key); // @link substring="getObject" target="#getObject(java.lang.String)"
> 
> `// @link` can be a separate line, placed on top of the target text

Thanks for the review, moved the links on top, and fixed the indentation in the example snippet.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13920#discussion_r1191663234

From naoto at openjdk.org  Thu May 11 20:51:37 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 20:51:37 GMT
Subject: RFR: 8307547: Support variant collations [v4]
In-Reply-To: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
Message-ID: <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>

> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Added "reformed" tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13917/files
  - new: https://git.openjdk.org/jdk/pull/13917/files/29b1c8c4..4ab39664

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13917&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13917&range=02-03

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13917.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13917/head:pull/13917

PR: https://git.openjdk.org/jdk/pull/13917

From jlu at openjdk.org  Thu May 11 21:16:32 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 21:16:32 GMT
Subject: RFR: 6714245: [Col] Collator - Faster Comparison for identical
 strings.
In-Reply-To: <hvuhnqhTZbL3pAZl8i8W6wqVrsLZHPIwYBd81UCWT28=.1f800993-931b-48ef-b0c5-6304f1bb54b2@github.com>
References: <GXUyAGggDuYZaMrle9tFpi1XJjboeLu0PoT6bfcnXn8=.a8ce6ff2-c204-479e-a3ee-1cbdf36a39fe@github.com>
 <hvuhnqhTZbL3pAZl8i8W6wqVrsLZHPIwYBd81UCWT28=.1f800993-931b-48ef-b0c5-6304f1bb54b2@github.com>
Message-ID: <c9YsvodPsyw79Iy_nu4uyNTJ_WVg92brGZ7gxuJFvJ8=.17f2db66-ed9b-4f82-abd2-8dcdb076a3f7@github.com>

On Thu, 11 May 2023 20:37:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which adds an initial equality check to `RuleBasedCollator.compare(String source, String target)`.
>> 
>> This speeds up the operation for equal input Strings, as it bypasses Collator rule comparisons of each element for both of the input Strings.
>
> LGTM. `noreg-perf` issue label might fit better for this

@naotoj ah good to know, I was looking for a noreg-"optimization" or something along those lines and ended up settling for cleanup since I didn't know perf was short for performance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13938#issuecomment-1544688899

From jlu at openjdk.org  Thu May 11 21:39:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 21:39:50 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <w-aBr-h4WVCyWPDEHHatqoQcdQJp6dN4eld2Y-85Ak4=.558819ae-881a-42fb-8b67-7a6b5618e323@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

Wondering if anyone has any thoughts on the consequences of this PR, in relation to Intellj's (and other IDEs) default encoding for .properties files. Intellj sets the default encoding for .properties files to ISO-8859-1, which would be the wrong encoding if the .properties files are converted to UTF-8 native. This would cause certain key,values to be skewed when represented in the file. 

Although the default file-encoding for .properties can be switched to UTF-8, it is not the default.

Wondering what some solutions/thoughts to this are.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544708830

From naoto at openjdk.org  Thu May 11 21:51:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 21:51:13 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <2apKDcin5cwY53zz5jOIPhqm7cCWhyYMdsXGU4TauEk=.781d695e-39fe-46f7-bd03-be514ca0b85c@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

I think this is fine, as those properties files are JDK's own. I believe the benefit of moving to UTF-8 outweighs the issue you wrote, which can be remedied by changing the encoding in the IDEs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544722480

From mcimadamore at openjdk.org  Thu May 11 21:52:08 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 11 May 2023 21:52:08 GMT
Subject: RFR: 8307961:
 java/foreign/enablenativeaccess/TestEnableNativeAccess.java fails with
 ShouldNotReachHere
Message-ID: <7xl3nwCbSGsrHLMoNTK4hp7UAuRQd_qYocM-24Q5diY=.00fa8513-f545-4c22-b349-f0e13a27afc9@github.com>

This patch fixes the JNI test for the enable native access flag, which was updated incorrectly as part of https://git.openjdk.org/jdk/pull/13863.

The problem is that the test doesn't make global references out of the local ones before sharing them with another thread.

I could reproduce the failure locally with `-Xcheck:jni`. With this patch, the test passes.

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/13944/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13944&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307961
  Stats: 8 lines in 1 file changed: 3 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13944.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13944/head:pull/13944

PR: https://git.openjdk.org/jdk/pull/13944

From jlu at openjdk.org  Thu May 11 21:53:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 21:53:17 GMT
Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java
 [v2]
In-Reply-To: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
Message-ID: <t_inA_q2NYETRaP3nslz2Vv4qKJJdAqJuJS5-0qQcOw=.44f9dab0-bdcb-4c44-a966-e365b13d77c3@github.com>

> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
> 
> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same.

Justin Lu has updated the pull request incrementally with three additional commits since the last revision:

 - Adjust new lines to appease jcheck?
 - Review: remove new line literals for new lines
 - Review: fix method / var names

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13935/files
  - new: https://git.openjdk.org/jdk/pull/13935/files/7a43ab93..9574a984

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=00-01

  Stats: 16 lines in 1 file changed: 6 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/13935.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13935/head:pull/13935

PR: https://git.openjdk.org/jdk/pull/13935

From jlu at openjdk.org  Thu May 11 21:53:19 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 21:53:19 GMT
Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java
 [v2]
In-Reply-To: <J_ab01vZ5eZ85t1DKECQ6etN0z_b4y1JczKyGT5knWA=.924d127b-91ed-4c6b-9a25-e833fc419eaf@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
 <J_ab01vZ5eZ85t1DKECQ6etN0z_b4y1JczKyGT5knWA=.924d127b-91ed-4c6b-9a25-e833fc419eaf@github.com>
Message-ID: <ssCHX7JLudsKjU-KVtpJfKwf7se9mUdBl7rLlEzTVFw=.d412f622-1a8a-4110-a454-13fe33083fcf@github.com>

On Thu, 11 May 2023 20:34:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Adjust new lines to appease jcheck?
>>  - Review: remove new line literals for new lines
>>  - Review: fix method / var names
>
> Looks good, with some cosmetic suggestions

Thanks for the review @naotoj , implemented the suggestions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13935#issuecomment-1544713696

From jlu at openjdk.org  Thu May 11 22:23:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 22:23:47 GMT
Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java
 [v3]
In-Reply-To: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
Message-ID: <CMZz36yOM2DwaXQC9GGqPkwT0W3ZMobKnZf8-YVjE4Q=.4b23cc07-dea5-41b3-9927-211eeca5bf8a@github.com>

> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
> 
> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Remove more ws in text block

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13935/files
  - new: https://git.openjdk.org/jdk/pull/13935/files/9574a984..33fd7993

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13935.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13935/head:pull/13935

PR: https://git.openjdk.org/jdk/pull/13935

From jvernee at openjdk.org  Thu May 11 23:58:43 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 11 May 2023 23:58:43 GMT
Subject: RFR: 8307961:
 java/foreign/enablenativeaccess/TestEnableNativeAccess.java fails with
 ShouldNotReachHere
In-Reply-To: <7xl3nwCbSGsrHLMoNTK4hp7UAuRQd_qYocM-24Q5diY=.00fa8513-f545-4c22-b349-f0e13a27afc9@github.com>
References: <7xl3nwCbSGsrHLMoNTK4hp7UAuRQd_qYocM-24Q5diY=.00fa8513-f545-4c22-b349-f0e13a27afc9@github.com>
Message-ID: <zcMgAXYfA90z2xT0XaoVyMJUZRVm_INM8ZI37r_GtPs=.9fbfe99d-6bd3-4588-8015-24f746c905f0@github.com>

On Thu, 11 May 2023 21:29:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes the JNI test for the enable native access flag, which was updated incorrectly as part of https://git.openjdk.org/jdk/pull/13863.
> 
> The problem is that the test doesn't make global references out of the local ones before sharing them with another thread.
> 
> I could reproduce the failure locally with `-Xcheck:jni`. With this patch, the test passes.

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13944#pullrequestreview-1423593045

From dcubed at openjdk.org  Fri May 12 00:19:03 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 May 2023 00:19:03 GMT
Subject: RFR: 8307966: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64
Message-ID: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>

A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64.

-------------

Commit messages:
 - 8307966: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64

Changes: https://git.openjdk.org/jdk/pull/13946/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13946&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307966
  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13946.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13946/head:pull/13946

PR: https://git.openjdk.org/jdk/pull/13946

From naoto at openjdk.org  Fri May 12 00:19:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 00:19:03 GMT
Subject: RFR: 8307966: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64
In-Reply-To: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
References: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
Message-ID: <y8DMaC7fGqkzMJ4KUz_6C7-FTqL5koHTYRAh4WVXJlA=.81fa3362-2b8c-4bbd-9b1f-411174d1d06d@github.com>

On Fri, 12 May 2023 00:05:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13946#pullrequestreview-1423602222

From lmesnik at openjdk.org  Fri May 12 00:19:03 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 12 May 2023 00:19:03 GMT
Subject: RFR: 8307966: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64
In-Reply-To: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
References: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
Message-ID: <iE6gDmrg48U13wNjzJG_q_I0Az2p9nflI19nKKlvs4I=.7b9a6f50-d5f5-485e-ab1a-1a932e885341@github.com>

On Fri, 12 May 2023 00:05:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64.

Might be this failure is platform agnostic and should be generic all. We just don't run this combination on macosx so often. (

-------------

PR Review: https://git.openjdk.org/jdk/pull/13946#pullrequestreview-1423603714

From cjplummer at openjdk.org  Fri May 12 00:19:03 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 12 May 2023 00:19:03 GMT
Subject: RFR: 8307966: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64
In-Reply-To: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
References: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
Message-ID: <S-jkQMG-7D_4J8ummcBbqueojcBTzQpcpDBqx0wl2Aw=.86ab9e86-4ea2-4f6e-bd50-0cbd97d936bb@github.com>

On Fri, 12 May 2023 00:05:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64.

Maybe linux-all would be better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13946#issuecomment-1544916181

From dcubed at openjdk.org  Fri May 12 00:19:04 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 May 2023 00:19:04 GMT
Subject: RFR: 8307966: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64
In-Reply-To: <S-jkQMG-7D_4J8ummcBbqueojcBTzQpcpDBqx0wl2Aw=.86ab9e86-4ea2-4f6e-bd50-0cbd97d936bb@github.com>
References: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
 <S-jkQMG-7D_4J8ummcBbqueojcBTzQpcpDBqx0wl2Aw=.86ab9e86-4ea2-4f6e-bd50-0cbd97d936bb@github.com>
Message-ID: <W-3Zq_pn_nOPCpW-nL8B8P6nLgVfsyNTrgZfA49yFCw=.260b6c8a-fb17-4c90-a144-61c29694543c@github.com>

On Fri, 12 May 2023 00:09:12 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64.
>
> Maybe linux-all would be better.

@plummercj - Thanks for the review. 'linux-all' would make it apply to
linux versions that we don't have. I've only seen this issue on the three
platforms that I'm targeting.

@naotoj - Thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13946#issuecomment-1544921538

From dcubed at openjdk.org  Fri May 12 00:23:45 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 May 2023 00:23:45 GMT
Subject: RFR: 8307966: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64
In-Reply-To: <iE6gDmrg48U13wNjzJG_q_I0Az2p9nflI19nKKlvs4I=.7b9a6f50-d5f5-485e-ab1a-1a932e885341@github.com>
References: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
 <iE6gDmrg48U13wNjzJG_q_I0Az2p9nflI19nKKlvs4I=.7b9a6f50-d5f5-485e-ab1a-1a932e885341@github.com>
Message-ID: <G5M-EcDwhQxHPaiDijE8oZpWBM5CJdKazKwzE7sVDoI=.687abe1a-aea4-4a27-bd4f-ca2794e000b1@github.com>

On Fri, 12 May 2023 00:15:25 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64.
>
> Might be this failure is platform agnostic and should be generic all. We just don't run this combination on macosx so often. (

@lmesnik - Thanks for the review.

Folks, I'm only going with the sightings that I've seen.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13946#issuecomment-1544925144

From lmesnik at openjdk.org  Fri May 12 00:28:43 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 12 May 2023 00:28:43 GMT
Subject: RFR: 8307966: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64
In-Reply-To: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
References: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
Message-ID: <T7lZsMdNBTP3Dr3TDi67vDXqfmDCCCXIUIiQqMP-gio=.239a822e-7db5-4e68-86a2-a0e2a5fe85ff@github.com>

On Fri, 12 May 2023 00:05:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64.

Marked as reviewed by lmesnik (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13946#pullrequestreview-1423608862

From dcubed at openjdk.org  Fri May 12 00:56:57 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 May 2023 00:56:57 GMT
Subject: RFR: 8307966: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64 [v2]
In-Reply-To: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
References: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
Message-ID: <eWHqhIv6oX1L2iBgcwAe5UDX83zFgbUm5hqNGJ1s_5E=.68a0204b-f389-4656-a56c-d1cf82330aa0@github.com>

> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64.

Daniel D. Daugherty has updated the pull request incrementally with one additional commit since the last revision:

  plummercj CR - use linux-all instead

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13946/files
  - new: https://git.openjdk.org/jdk/pull/13946/files/94bad01c..35501c98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13946&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13946&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13946.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13946/head:pull/13946

PR: https://git.openjdk.org/jdk/pull/13946

From dcubed at openjdk.org  Fri May 12 00:56:58 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 May 2023 00:56:58 GMT
Subject: RFR: 8307966: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64
In-Reply-To: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
References: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
Message-ID: <9aTRQwkRWPQHzvHr0MjRE8HLFbjJwb3h1oIZ2mjM0bI=.fe0f5336-ecf6-41ae-80bd-ed1dc60c2a68@github.com>

On Fri, 12 May 2023 00:05:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64.

I've switched to using 'linux-all' instead of enumeration of the platforms.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13946#issuecomment-1544945743

From dcubed at openjdk.org  Fri May 12 00:56:59 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Fri, 12 May 2023 00:56:59 GMT
Subject: Integrated: 8307966: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64
In-Reply-To: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
References: <OqRqtrkDVRnZIMGLjoYGXq2E9mZqM0mGyMXA-sdlmJM=.25748bbc-0655-4e8b-8a15-11183f45a201@github.com>
Message-ID: <vouZzwAc5UJBW3PUtcSBbZ-pDr1eXM7zknt0BK14Ua0=.bc9be01a-60b9-41a5-8b1e-65a5562a6337@github.com>

On Fri, 12 May 2023 00:05:21 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64.

This pull request has now been integrated.

Changeset: 9a7b4431
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a7b4431ecde03f37d9f1c1b06dab6ef8d60a94c
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8307966: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java on linux-x64

Reviewed-by: naoto, lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/13946

From joe.darcy at oracle.com  Fri May 12 00:57:50 2023
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 11 May 2023 17:57:50 -0700
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <df447921-ebc1-e683-70f0-54da9b6621d0@oracle.com>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
 <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
 <CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com>
 <46167980-41fe-e214-9b67-ce0c5ca8c032@oracle.com>
 <CABe8uE2n2ozgJzRk_N-a2Pq37FTBJtWJhuxKUT6KG+2hR0TZLg@mail.gmail.com>
 <df447921-ebc1-e683-70f0-54da9b6621d0@oracle.com>
Message-ID: <1391d41f-b4b4-1449-94c6-7e91e58cb7aa@oracle.com>

PPS Various compatibility topics were covered in a talk I gave at the 
JCP EC in April this year:

"Contributing to OpenJDK: Participating in stewardship for the long-term"
https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-04-12/Contributing_to_OpenJDK_2023_04_12.pdf

-Joe

On 5/4/2023 9:08 PM, Joseph D. Darcy wrote:
> PS And as a general policy, over the releases we've done more to 
> preserve source compatibility when possible for language changes.
>
> For example, there were many source compatibility breakages when 
> "assert" was added as a keyword back in JDK 1.4; the current keyword 
> management policies (https://openjdk.org/jeps/8223002), including 
> contextual keywords (JLS ?3.9) and hyphenated-keywords, mitigate the 
> impact of analogous changes today.
>
> -Joe
>
> On 5/4/2023 7:47 PM, - wrote:
>> In addition, in the CSR of sequenced collection, it already
>> anticipated some other form of source incompatibility:
>> If a class implements List and Deque at the same time, the return type
>> of reversed() must extend both interfaces as well.
>>
>> This alone would be a greater source incompatibility than this type
>> interference already; however, both are binarily compatible:
>> Java doesn't care about generics at runtime, and for default
>> reversed() overrides, reversed ()Ljava/util/List; and reversed
>> ()Ljava/util/Deque; are distinct methods; code calling reversed via
>> List or Deque interfaces will get the reversed version of respective
>> interfaces, which are functionally correct as well.
>>
>> I personally would consider this type inference usage moot. It is same
>> as adding another method addAll(List<String>) when there is already
>> addAll(String[]): existing addAll(null) calls will break, but this is
>> not a valid argument against adding a List<String> variant of addAll.
>>
>> On Thu, May 4, 2023 at 9:38?PM Joseph D. Darcy <joe.darcy at oracle.com> 
>> wrote:
>>> A few comments on the general compatibility policy for the JDK. 
>>> Compatibility is looked after by the Compatibility and Specification 
>>> Review (CSR) process ( Compatibility & Specification Review). 
>>> Summarizing the approach,
>>>
>>> The general compatibility policy for exported APIs implemented in 
>>> the JDK is:
>>>
>>> ???? * Don't break binary compatibility (as defined in the Java 
>>> Language Specification) without sufficient cause.
>>> ???? * Avoid introducing source incompatibilities.
>>> ???? * Manage behavioral compatibility changes.
>>>
>>> https://wiki.openjdk.org/display/csr/Main
>>>
>>> None of binary, source, and behavioral compatibly are absolutes and 
>>> judgement is used to assess the cost/benefits of changes. For 
>>> example, strict source compatibility would preclude, say, 
>>> introducing new public types in the java.lang package since the 
>>> implicit import of types in java.lang could conflict with a 
>>> same-named type *-imported from another package.
>>>
>>> When a proposed change is estimated to be sufficiently disruptive, 
>>> we conduct a corpus experiment to evaluate the impact on the change 
>>> on many public Java libraries. Back in Project Coin in JDK 7, that 
>>> basic approach was used to help quantify various language design 
>>> choices and the infrastructure to run such experiments has been 
>>> built-out in the subsequent releases.
>>>
>>> HTH,
>>>
>>> -Joe
>>> CSR Group Lead
>>>
>>> On 5/4/2023 6:32 AM, Ethan McCue wrote:
>>>
>>> I guess this a good time to ask, ignoring the benefit part of a cost 
>>> benefit analysis, what mechanisms do we have to measure the number 
>>> of codebases relying on type inference this will break?
>>>
>>> Iirc Adoptium built/ran the unit tests of a bunch of public repos, 
>>> but it's also a bit shocking if the jtreg suite had nothing for this.
>>>
>>> On Thu, May 4, 2023, 9:27 AM Raffaello Giulietti 
>>> <raffaello.giulietti at oracle.com> wrote:
>>>> Without changing the semantics at all, you could also write
>>>>
>>>> ???????? final List<Collection<String>> list =
>>>> Stream.<Collection<String>>of(nestedDequeue, nestedList).toList();
>>>>
>>>> to "help" type inference.
>>>>
>>>>
>>>>
>>>>
>>>> On 2023-05-03 15:12, forax at univ-mlv.fr wrote:
>>>>> Another example sent to me by a fellow French guy,
>>>>>
>>>>> ????? final Deque<String> nestedDequeue = new ArrayDeque<>();
>>>>> ????? nestedDequeue.addFirst("C");
>>>>> ????? nestedDequeue.addFirst("B");
>>>>> ????? nestedDequeue.addFirst("A");
>>>>>
>>>>> ????? final List<String> nestedList = new ArrayList<>();
>>>>> ????? nestedList.add("D");
>>>>> ????? nestedList.add("E");
>>>>> ????? nestedList.add("F");
>>>>>
>>>>> ????? final List<Collection<String>> list = 
>>>>> Stream.of(nestedDequeue, nestedList).toList();
>>>>>
>>>>> This one is cool because no 'var' is involved and using 
>>>>> collect(Collectors.toList()) instead of toList() solves the 
>>>>> inference problem.
>>>>>
>>>>> R?mi
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "Stuart Marks" <stuart.marks at oracle.com>
>>>>>> To: "Remi Forax" <forax at univ-mlv.fr>
>>>>>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>>>>>> Sent: Tuesday, May 2, 2023 2:44:28 AM
>>>>>> Subject: Re: The introduction of Sequenced collections is not a 
>>>>>> source compatible change
>>>>>> Hi R?mi,
>>>>>>
>>>>>> Thanks for trying out the latest build!
>>>>>>
>>>>>> I'll make sure this gets mentioned in the release note for Sequenced
>>>>>> Collections.
>>>>>> We'll also raise this issue when we talk about this feature in 
>>>>>> the Quality
>>>>>> Outreach
>>>>>> program.
>>>>>>
>>>>>> s'marks
>>>>>>
>>>>>> On 4/29/23 3:46 AM, Remi Forax wrote:
>>>>>>> I've several repositories that now fails to compile with the 
>>>>>>> latest jdk21, which
>>>>>>> introduces sequence collections.
>>>>>>>
>>>>>>> The introduction of a common supertype to existing collections 
>>>>>>> is *not* a source
>>>>>>> compatible change because of type inference.
>>>>>>>
>>>>>>> Here is a simplified example:
>>>>>>>
>>>>>>> ???? public static void m(List<Supplier<? extends Map<String, 
>>>>>>> String>>> factories) {
>>>>>>> ???? }
>>>>>>>
>>>>>>> ???? public static void main(String[] args) {
>>>>>>> Supplier<LinkedHashMap<String,String>> supplier1 = 
>>>>>>> LinkedHashMap::new;
>>>>>>> ?????? Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>>>>>>> ?????? var factories = List.of(supplier1, supplier2);
>>>>>>> ?????? m(factories);
>>>>>>> ???? }
>>>>>>>
>>>>>>>
>>>>>>> This example compiles fine with Java 20 but report an error with 
>>>>>>> Java 21:
>>>>>>> ???? SequencedCollectionBug.java:28: error: method m in class 
>>>>>>> SequencedCollectionBug
>>>>>>> ???? cannot be applied to given types;
>>>>>>> ?????? m(factories);
>>>>>>> ?????? ^
>>>>>>> ???? required: List<Supplier<? extends Map<String,String>>>
>>>>>>> ???? found:??? List<Supplier<? extends 
>>>>>>> SequencedMap<String,String>>>
>>>>>>> ???? reason: argument mismatch; List<Supplier<? extends 
>>>>>>> SequencedMap<String,String>>>
>>>>>>> ???? cannot be converted to List<Supplier<? extends 
>>>>>>> Map<String,String>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Apart from the example above, most of the failures I see are in 
>>>>>>> the unit tests
>>>>>>> provided to the students, because we are using a lot of 'var' in 
>>>>>>> them so they
>>>>>>> work whatever the name of the types chosen by the students.
>>>>>>>
>>>>>>> Discussing with a colleague, we also believe that this bug is 
>>>>>>> not limited to
>>>>>>> Java, existing Kotlin codes will also fail to compile due to 
>>>>>>> this bug.
>>>>>>>
>>>>>>> Regards,
>>>>>>> R?mi

From alanb at openjdk.org  Fri May 12 08:48:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 May 2023 08:48:46 GMT
Subject: RFR: 8307547: Support variant collations [v4]
In-Reply-To: <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
Message-ID: <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>

On Thu, 11 May 2023 20:51:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added "reformed" tests

The update, and API note in Collator.getInstance(Locale), looks okay to me. I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1545395782

From mcimadamore at openjdk.org  Fri May 12 10:41:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 12 May 2023 10:41:53 GMT
Subject: Integrated: 8307961:
 java/foreign/enablenativeaccess/TestEnableNativeAccess.java fails with
 ShouldNotReachHere
In-Reply-To: <7xl3nwCbSGsrHLMoNTK4hp7UAuRQd_qYocM-24Q5diY=.00fa8513-f545-4c22-b349-f0e13a27afc9@github.com>
References: <7xl3nwCbSGsrHLMoNTK4hp7UAuRQd_qYocM-24Q5diY=.00fa8513-f545-4c22-b349-f0e13a27afc9@github.com>
Message-ID: <Iy7QCNt2gqQvgbwzYb27gQutA09PB9TwYEZ2HEKp5f4=.45969e90-1f63-4a80-8f18-e7d720d2f1ee@github.com>

On Thu, 11 May 2023 21:29:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes the JNI test for the enable native access flag, which was updated incorrectly as part of https://git.openjdk.org/jdk/pull/13863.
> 
> The problem is that the test doesn't make global references out of the local ones before sharing them with another thread.
> 
> I could reproduce the failure locally with `-Xcheck:jni`. With this patch, the test passes.

This pull request has now been integrated.

Changeset: 13a3fce2
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13a3fce29e696354b2e79fbcfd3557dc4a1fece7
Stats:     8 lines in 1 file changed: 3 ins; 0 del; 5 mod

8307961: java/foreign/enablenativeaccess/TestEnableNativeAccess.java fails with ShouldNotReachHere

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/13944

From mcimadamore at openjdk.org  Fri May 12 12:18:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 12 May 2023 12:18:50 GMT
Subject: RFR: 8287834: Add SymbolLookup::or method
Message-ID: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>

This patch adds a simpler method for composing symbol lookups. It is common for clients to chain multiple symbol lookups together, e.g. to find a symbol in multiple libraries.

A new instance method, namely `SymbolLookup::or` is added, which first searches a symbol in the first lookup, and, if that fails, proceeds to search the symbol in the provided lookup.

We have considered alternatives to express this, such as a static factory `SymbolLookup::ofComposite` but settled on this because of the similarity with `Optional::or`.

-------------

Commit messages:
 - Add test for composite lookups
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/13954/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13954&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287834
  Stats: 169 lines in 2 files changed: 169 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13954/head:pull/13954

PR: https://git.openjdk.org/jdk/pull/13954

From jpai at openjdk.org  Fri May 12 12:55:37 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 May 2023 12:55:37 GMT
Subject: RFR: 8307403: java/util/zip/DeInflate.java timed out
Message-ID: <iZKgjHKUrExpgjmD0nD7lBjTHEy5zW_NbRExhnoxkgk=.0cf03734-bcca-422a-9b52-87ae70881527@github.com>

Can I please get a review of this test only change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8307403?

When we recently did a change in https://bugs.openjdk.org/browse/JDK-8299748, there was a oversight that the `deflate.deflate(tempBuffer)` could potentially end up taking in a zero sized array. That would then mean the loop in which this `deflate` happens, would never exit leading to the test timing out.
I've added additional details as a comment to the JBS issue https://bugs.openjdk.org/browse/JDK-8307403?focusedCommentId=14581202&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14581202.

The commit in this PR uses a fixed size temporary buffer, unrelated to the input length, to get past this problem. The use of fixed size here will not re-introduce the original issue which https://bugs.openjdk.org/browse/JDK-8299748 fixed, because unlike previously, this is just a temporary size and we continue to deflate the content into a dynamically growing `ByteArrayOutputStream` till the deflater is "finished".

Additionally I've added a log message to help debug any future issues in this call.

-------------

Commit messages:
 - 8307403: java/util/zip/DeInflate.java timed out

Changes: https://git.openjdk.org/jdk/pull/13955/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13955&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307403
  Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13955.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13955/head:pull/13955

PR: https://git.openjdk.org/jdk/pull/13955

From jpai at openjdk.org  Fri May 12 12:56:47 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 May 2023 12:56:47 GMT
Subject: RFR: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly [v4]
In-Reply-To: <ocy3S4R8W7aXC-nl4jxFC88WDXLkzPcFJlVPKCSKW1w=.5860823a-b2ce-47b1-9d25-eb49a5fc86af@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
 <ocy3S4R8W7aXC-nl4jxFC88WDXLkzPcFJlVPKCSKW1w=.5860823a-b2ce-47b1-9d25-eb49a5fc86af@github.com>
Message-ID: <M3YnMw6QuF6TyUTx3XV4svzWoUoO9Hc4H02VQ--4bQU=.7348aaab-7c82-4a15-b47e-7f00b54cc1ca@github.com>

On Thu, 11 May 2023 18:34:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Several Handlers class use monitors to synchronize when formatting / publishing LogRecords.
>> When logging within a VirtualThread, holding this monitor can cause the carrier thread to be pinned.
>> Handlers could use jdk.internal.misc.InternalLock, in a similar way to some java.io classes (such as PrintStream) to avoid pinning the carrier thread.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ReentrantLock directly

Marked as reviewed by jpai (Reviewer).

The latest changes to use `ReentrantLock` instead of `InternalLock` looks fine to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13832#pullrequestreview-1424455046
PR Comment: https://git.openjdk.org/jdk/pull/13832#issuecomment-1545699479

From jvernee at openjdk.org  Fri May 12 13:16:47 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 12 May 2023 13:16:47 GMT
Subject: RFR: 8307911: javadoc for MemorySegment::reinterpret has duplicate
 restricted method paragraph
In-Reply-To: <dtNvM-_Fp3I16qPvjT5SWFVmn0qcFkqj2ymDhVIlBxk=.699c2ecb-553c-4c10-a5d3-60952e0d62e3@github.com>
References: <dtNvM-_Fp3I16qPvjT5SWFVmn0qcFkqj2ymDhVIlBxk=.699c2ecb-553c-4c10-a5d3-60952e0d62e3@github.com>
Message-ID: <SaeOU7FoDrwXknWgayyeZ8pm-95WwLPQWEFeNzdzxGw=.a0155fed-d004-4e0f-8b68-5b27ff0aacd2@github.com>

On Thu, 11 May 2023 10:00:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> As the title says, this patch fixes an issue with `MemorySegment::reinterpet`, which reports the customary "restricted method" section twice.
> 
> I also fixed some wrong capitalization in the text of the factories in `Linker.Option`.

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13926#pullrequestreview-1424490386

From liach at openjdk.org  Fri May 12 13:23:48 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 12 May 2023 13:23:48 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v4]
In-Reply-To: <44odsoRkRp6mmgfPKFCPOy-uaHNOgOgPQUJICERzHKU=.5703da5a-0e66-45a2-af0b-23ac0665fbe7@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <44odsoRkRp6mmgfPKFCPOy-uaHNOgOgPQUJICERzHKU=.5703da5a-0e66-45a2-af0b-23ac0665fbe7@github.com>
Message-ID: <4pL9To1n8Gbf1EdM50d87Xk8nu0Ou_nAFONKBzaH1OQ=.103c7aae-dec8-409a-ace4-0f9b0d04d662@github.com>

On Wed, 10 May 2023 10:00:47 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Following improvements implemented:
>> - Switch over `String` replaced with switch single char
>> - Binary search for frames in `StackMapGenerator`
>> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
>> - `ClassEntry` is caching `ClassDesc` symbol
>> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
>> - Caching `MethodTypeDesc` in `MethodInfo` implementations
>> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
>> 
>> No API change.
>> 
>> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
>> 
>> 
>> Benchmark                     Mode  Cnt       Score       Error  Units
>> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
>> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
>> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
>> 
>> 
>> 
>> Benchmark                     Mode  Cnt       Score      Error  Units
>> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
>> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
>> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed jmh benchmark parameters

test/micro/org/openjdk/bench/jdk/classfile/RebuildMethodBodies.java line 57:

> 55:     public void setup() throws IOException {
> 56:         shared = new LinkedList<>();
> 57:         unshared = new LinkedList<>();

LinkedList should be replaced by ArrayList, as:
1. LinkedList's node wrapper around each object is too heavy, ArrayList has smaller wrapper
2. LinkedList iteration needs to follow links while ArrayList access can be machine optimized
3. ArrayList addition is amortized O(1), not really worse than LinkedList additions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1192367198

From dfuchs at openjdk.org  Fri May 12 15:27:53 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 12 May 2023 15:27:53 GMT
Subject: Integrated: 8307535: java.util.logging.Handlers should be more
 VirtualThread friendly
In-Reply-To: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
References: <OTKw_Tsk2gMAvwEj2buwulF0-S6oD9CXODnLL_ATv7A=.a80cf115-9a68-407f-8a20-4936efb53fa7@github.com>
Message-ID: <VvouC9YwRFz9b7WaJiUPhjrFcTSLw3mNVJ_iVP8-2OI=.5d67e871-03fb-4f8a-9f57-a731a6189a10@github.com>

On Fri, 5 May 2023 13:43:43 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Several Handlers class use monitors to synchronize when formatting / publishing LogRecords.
> When logging within a VirtualThread, holding this monitor can cause the carrier thread to be pinned.
> Handlers could use jdk.internal.misc.InternalLock, in a similar way to some java.io classes (such as PrintStream) to avoid pinning the carrier thread.

This pull request has now been integrated.

Changeset: 3c68c352
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c68c352fc3d3bff3d80bafcf04118759f4a2acf
Stats:     309 lines in 6 files changed: 276 ins; 2 del; 31 mod

8307535: java.util.logging.Handlers should be more VirtualThread friendly

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/13832

From simonis at openjdk.org  Fri May 12 15:31:59 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Fri, 12 May 2023 15:31:59 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
Message-ID: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>

Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.

In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.

The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.

Also did some cleanup:
 - in `jspawnhelper.c` correctly chek the result of `readFully()`
 - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
 - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

-------------

Commit messages:
 - 8307990: jspawnhelper must close its writing side of a pipe before reading from it

Changes: https://git.openjdk.org/jdk/pull/13956/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13956&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307990
  Stats: 29 lines in 4 files changed: 9 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/13956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13956/head:pull/13956

PR: https://git.openjdk.org/jdk/pull/13956

From mcimadamore at openjdk.org  Fri May 12 16:20:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 12 May 2023 16:20:56 GMT
Subject: Integrated: 8307911: javadoc for MemorySegment::reinterpret has
 duplicate restricted method paragraph
In-Reply-To: <dtNvM-_Fp3I16qPvjT5SWFVmn0qcFkqj2ymDhVIlBxk=.699c2ecb-553c-4c10-a5d3-60952e0d62e3@github.com>
References: <dtNvM-_Fp3I16qPvjT5SWFVmn0qcFkqj2ymDhVIlBxk=.699c2ecb-553c-4c10-a5d3-60952e0d62e3@github.com>
Message-ID: <egegNo5BLlsAiITYoAGgZse_wjtIjpr4-ZYPjufwa4g=.c5118490-b0f4-4312-9674-30392bd69b60@github.com>

On Thu, 11 May 2023 10:00:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> As the title says, this patch fixes an issue with `MemorySegment::reinterpet`, which reports the customary "restricted method" section twice.
> 
> I also fixed some wrong capitalization in the text of the factories in `Linker.Option`.

This pull request has now been integrated.

Changeset: 6ebea897
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6ebea8973feb08a7443d8d86ff52f453dc4aec43
Stats:     8 lines in 2 files changed: 0 ins; 5 del; 3 mod

8307911: javadoc for MemorySegment::reinterpret has duplicate restricted method paragraph

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/13926

From bpb at openjdk.org  Fri May 12 16:24:49 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 May 2023 16:24:49 GMT
Subject: RFR: 8308016: Use snippets in java.io package
Message-ID: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>

Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...>`.

-------------

Commit messages:
 - 8308016: Use snippets in java.io package

Changes: https://git.openjdk.org/jdk/pull/13957/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308016
  Stats: 178 lines in 21 files changed: 27 ins; 7 del; 144 mod
  Patch: https://git.openjdk.org/jdk/pull/13957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957

PR: https://git.openjdk.org/jdk/pull/13957

From naoto at openjdk.org  Fri May 12 16:35:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 16:35:46 GMT
Subject: RFR: 8307547: Support variant collations [v4]
In-Reply-To: <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
 <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>
Message-ID: <x1shHzMm-4SWbRgVw08cjsCFtBHmu7e6ogs3Rp2Ha1U=.ac71b8ab-835e-4fc6-b327-4911f44d52b8@github.com>

On Fri, 12 May 2023 08:45:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.

I think those should go into Oracle JDK's `Supported Locales` document. Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1546003990

From asotona at openjdk.org  Fri May 12 16:37:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 12 May 2023 16:37:56 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v2]
In-Reply-To: <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
Message-ID: <bHXXwBDdgLkt1SBfS_r3FIPGyTGlPSRHepss_dWL2oI=.79fdf0e8-52e6-4128-a59b-a70c704d13dc@github.com>

On Tue, 17 Jan 2023 15:55:40 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.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Adding comments
>  - Improving performance
>  - Merge branch 'master' into JDK-8291966
>  - 8291966: SwitchBootstrap.typeSwitch could be faster

I did several experiments with generated lookupswitch over class hashes (for final and sealed class labels only).
My experiments and benchmark results are actually showing following facts:
- traversal expanded to tableswitch (as proposed here) is significantly faster than circulating over an array
- expanded lookupswitch over class hashes is unfortunately slower than this proposal, even when benchmarked on large switches containing final or sealed class labels only

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/9779#pullrequestreview-1424836407

From naoto at openjdk.org  Fri May 12 16:41:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 16:41:48 GMT
Subject: RFR: 8300794: Use @snippet in java.util:i18n [v2]
In-Reply-To: <aQtLPpIumIPaSdmeDnWJ3stq4wePpCq4V1YU0B6sO2I=.2b3ab5f1-1fa9-48a6-9628-6a8e0bc7b196@github.com>
References: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
 <aQtLPpIumIPaSdmeDnWJ3stq4wePpCq4V1YU0B6sO2I=.2b3ab5f1-1fa9-48a6-9628-6a8e0bc7b196@github.com>
Message-ID: <H2i9kVLWIMvXhO43PTAT8N5srOYGLnqIFu_2QJhcF2o=.5b3cd0d3-dc4f-4723-a25d-c78f1c8a0147@github.com>

On Thu, 11 May 2023 20:39:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this javadoc only change which uses `@snippet` and `@linkplain` in i18n related util packages.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Move links on top, fix indentation in example

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13920#pullrequestreview-1424841206

From srl at openjdk.org  Fri May 12 16:43:52 2023
From: srl at openjdk.org (Steven Loomis)
Date: Fri, 12 May 2023 16:43:52 GMT
Subject: RFR: 8307547: Support variant collations [v4]
In-Reply-To: <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
Message-ID: <KoDGaq-MGrIEores-XK4J_BSLNYYfc-z4YIY37VGfPA=.508baaea-00bb-4269-8046-02f76046d308@github.com>

On Thu, 11 May 2023 20:51:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added "reformed" tests

Marked as reviewed by srl (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13917#pullrequestreview-1424842005

From srl at openjdk.org  Fri May 12 16:43:56 2023
From: srl at openjdk.org (Steven Loomis)
Date: Fri, 12 May 2023 16:43:56 GMT
Subject: RFR: 8307547: Support variant collations [v4]
In-Reply-To: <x1shHzMm-4SWbRgVw08cjsCFtBHmu7e6ogs3Rp2Ha1U=.ac71b8ab-835e-4fc6-b327-4911f44d52b8@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
 <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>
 <x1shHzMm-4SWbRgVw08cjsCFtBHmu7e6ogs3Rp2Ha1U=.ac71b8ab-835e-4fc6-b327-4911f44d52b8@github.com>
Message-ID: <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>

On Fri, 12 May 2023 16:32:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> > I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.
> 
> I think those should go into Oracle JDK's `Supported Locales` document. Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018)

`-u-co` is defined [here](https://www.unicode.org/reports/tr35/#UnicodeCollationIdentifier) (UTS#35) and the keys are in the datafile [here (link to `main` branch!)](https://github.com/unicode-org/cldr/blob/main/common/bcp47/collation.xml) - note the `since=` attribute, these are very stable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1546013166

From naoto at openjdk.org  Fri May 12 16:43:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 16:43:55 GMT
Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java
 [v3]
In-Reply-To: <CMZz36yOM2DwaXQC9GGqPkwT0W3ZMobKnZf8-YVjE4Q=.4b23cc07-dea5-41b3-9927-211eeca5bf8a@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
 <CMZz36yOM2DwaXQC9GGqPkwT0W3ZMobKnZf8-YVjE4Q=.4b23cc07-dea5-41b3-9927-211eeca5bf8a@github.com>
Message-ID: <HMEPBdpLW0t6cMHhZrfadFg3UH6ci9HP5j5aJOuHaUI=.57791e5d-2ab9-4305-b158-6b2df3d2e3c5@github.com>

On Thu, 11 May 2023 22:23:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
>> 
>> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove more ws in text block

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 344:

> 342:     }
> 343: 
> 344:     private static final String footerText = "    }\n\n}";

I'd prefer this one also be uppercased (and moved to a more suitable location).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1192593829

From lancea at openjdk.org  Fri May 12 17:02:44 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 12 May 2023 17:02:44 GMT
Subject: RFR: 8300794: Use @snippet in java.util:i18n [v2]
In-Reply-To: <aQtLPpIumIPaSdmeDnWJ3stq4wePpCq4V1YU0B6sO2I=.2b3ab5f1-1fa9-48a6-9628-6a8e0bc7b196@github.com>
References: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
 <aQtLPpIumIPaSdmeDnWJ3stq4wePpCq4V1YU0B6sO2I=.2b3ab5f1-1fa9-48a6-9628-6a8e0bc7b196@github.com>
Message-ID: <yMrAU7r0vU-D9V8C2-Bt6tif8m8B2JIc34Zf1JocL9s=.41411806-17c5-404f-a794-2e43a4002375@github.com>

On Thu, 11 May 2023 20:39:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this javadoc only change which uses `@snippet` and `@linkplain` in i18n related util packages.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Move links on top, fix indentation in example

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13920#pullrequestreview-1424868788

From naoto at openjdk.org  Fri May 12 17:11:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 17:11:45 GMT
Subject: RFR: 8307547: Support variant collations [v4]
In-Reply-To: <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
 <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>
 <x1shHzMm-4SWbRgVw08cjsCFtBHmu7e6ogs3Rp2Ha1U=.ac71b8ab-835e-4fc6-b327-4911f44d52b8@github.com>
 <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>
Message-ID: <NomFKC6d8uS3CoRupgiwZwQYqOAzeZWY0r7zrDiwcLA=.ceb8d7f2-97a1-4088-8c35-0187cf2db221@github.com>

On Fri, 12 May 2023 16:41:20 GMT, Steven Loomis <srl at openjdk.org> wrote:

>>> I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.
>> 
>> I think those should go into Oracle JDK's `Supported Locales` document. Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018)
>
>> > I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.
>> 
>> I think those should go into Oracle JDK's `Supported Locales` document. Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018)
> 
> `-u-co` is defined [here](https://www.unicode.org/reports/tr35/#UnicodeCollationIdentifier) (UTS#35) and the keys are in the datafile [here (link to `main` branch!)](https://github.com/unicode-org/cldr/blob/main/common/bcp47/collation.xml) - note the `since=` attribute, these are very stable.
> 
> @AlanBateman 
>> Locale.forLanguageTag supports more than BCP 47 language tag strings
> 
> It should still be all valid BCP47 including extensions and private use (such as x-lvalue). 
> 
>> so is this considered a private use language tag
> 
> Not private use at all. The `-u-` subtag is registered, and the links above are from the registrar, see
> - https://www.rfc-editor.org/info/bcp47
> - https://www.rfc-editor.org/rfc/rfc6067

Thanks @srl295 
I am just curious how CLDR handles the default switch of Swedish collation. Now the `traditional` collation used to be `standard`, and `standard` used to be `reformed`. How do apps specify their desired collation in Swedish, regardless of CLDR versions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1546042805

From srl at openjdk.org  Fri May 12 17:18:46 2023
From: srl at openjdk.org (Steven Loomis)
Date: Fri, 12 May 2023 17:18:46 GMT
Subject: RFR: 8307547: Support variant collations [v4]
In-Reply-To: <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
 <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>
 <x1shHzMm-4SWbRgVw08cjsCFtBHmu7e6ogs3Rp2Ha1U=.ac71b8ab-835e-4fc6-b327-4911f44d52b8@github.com>
 <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>
Message-ID: <JGk3tO3V-lmArLwxd9EIJeMSpIXHz3pMa_ZK7_B2jv0=.f29801b0-0c9f-4ec8-a5a1-d4d1834adcd5@github.com>

On Fri, 12 May 2023 16:41:20 GMT, Steven Loomis <srl at openjdk.org> wrote:

>>> I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.
>> 
>> I think those should go into Oracle JDK's `Supported Locales` document. Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018)
>
>> > I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.
>> 
>> I think those should go into Oracle JDK's `Supported Locales` document. Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018)
> 
> `-u-co` is defined [here](https://www.unicode.org/reports/tr35/#UnicodeCollationIdentifier) (UTS#35) and the keys are in the datafile [here (link to `main` branch!)](https://github.com/unicode-org/cldr/blob/main/common/bcp47/collation.xml) - note the `since=` attribute, these are very stable.
> 
> @AlanBateman 
>> Locale.forLanguageTag supports more than BCP 47 language tag strings
> 
> It should still be all valid BCP47 including extensions and private use (such as x-lvalue). 
> 
>> so is this considered a private use language tag
> 
> Not private use at all. The `-u-` subtag is registered, and the links above are from the registrar, see
> - https://www.rfc-editor.org/info/bcp47
> - https://www.rfc-editor.org/rfc/rfc6067

> Thanks @srl295
> I am just curious how CLDR handles the default switch of Swedish collation. Now the `traditional` collation used to be `standard`, and `standard` used to be `reformed`. How do apps specify their desired collation in Swedish, regardless of CLDR versions?

I don't know off the top of my head but digging around I found https://unicode-org.atlassian.net/browse/CLDR-7088 and cross linked some tickets. Can you ask around on those?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1546050297

From jlu at openjdk.org  Fri May 12 17:25:45 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 May 2023 17:25:45 GMT
Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java
 [v4]
In-Reply-To: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
Message-ID: <kNboTkeQjR_04uuXfv6HXD2b-WUDciv4wQjb3M12JcM=.f74b819a-78f9-4934-8e48-2efc76f6d8cd@github.com>

> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
> 
> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Review: capitalize and move footer text. Add comments to main

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13935/files
  - new: https://git.openjdk.org/jdk/pull/13935/files/33fd7993..b4e6e683

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=02-03

  Stats: 13 lines in 1 file changed: 10 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13935.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13935/head:pull/13935

PR: https://git.openjdk.org/jdk/pull/13935

From jlu at openjdk.org  Fri May 12 17:25:49 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 May 2023 17:25:49 GMT
Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java
 [v3]
In-Reply-To: <HMEPBdpLW0t6cMHhZrfadFg3UH6ci9HP5j5aJOuHaUI=.57791e5d-2ab9-4305-b158-6b2df3d2e3c5@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
 <CMZz36yOM2DwaXQC9GGqPkwT0W3ZMobKnZf8-YVjE4Q=.4b23cc07-dea5-41b3-9927-211eeca5bf8a@github.com>
 <HMEPBdpLW0t6cMHhZrfadFg3UH6ci9HP5j5aJOuHaUI=.57791e5d-2ab9-4305-b158-6b2df3d2e3c5@github.com>
Message-ID: <Qcw3TKCW56u8Ymjm6bbRXA5RUNHuKm1X0B0r0P6R4jM=.41241fd2-6b3c-48ce-90ef-3423e5fbc161@github.com>

On Fri, 12 May 2023 16:41:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove more ws in text block
>
> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 344:
> 
>> 342:     }
>> 343: 
>> 344:     private static final String footerText = "    }\n\n}";
> 
> I'd prefer this one also be uppercased (and moved to a more suitable location).

ah, missed that one, probably because of it's location too. Made uppercased and moved closer to the rest of the static text variables.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1192626527

From naoto at openjdk.org  Fri May 12 17:32:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 17:32:49 GMT
Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java
 [v4]
In-Reply-To: <kNboTkeQjR_04uuXfv6HXD2b-WUDciv4wQjb3M12JcM=.f74b819a-78f9-4934-8e48-2efc76f6d8cd@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
 <kNboTkeQjR_04uuXfv6HXD2b-WUDciv4wQjb3M12JcM=.f74b819a-78f9-4934-8e48-2efc76f6d8cd@github.com>
Message-ID: <2WPO1cEA46g85vIgS3teOTHpeiLRbG0ee7iWQSfazfM=.a7646928-a374-49e9-b488-656483af9ff1@github.com>

On Fri, 12 May 2023 17:25:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
>> 
>> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: capitalize and move footer text. Add comments to main

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13935#pullrequestreview-1424907858

From jlu at openjdk.org  Fri May 12 17:34:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 May 2023 17:34:47 GMT
Subject: RFR: 8308016: Use snippets in java.io package
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <J2FEGAKqvuHSrXZsZaKHmD5AwSQsDr5OlHYvltSv_ZY=.b556174f-d8b6-43f4-9690-f4d01eb6603a@github.com>

On Fri, 12 May 2023 16:17:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

src/java.base/share/classes/java/io/Console.java line 124:

> 122:      *         if (con != null) {
> 123:      *             Scanner sc = new Scanner(con.reader());
> 124:      *             ...

I'm not sure how you feel about this, but when I have been converting `<pre>` blocks to `@snippet`, I usually try to get rid of non code. Since snippet allows user's to copy the example code, I feel like it's redudant to leave in non code, since they will likely delete it anyways.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1192635740

From rriggs at openjdk.org  Fri May 12 17:38:50 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 12 May 2023 17:38:50 GMT
Subject: RFR: 8299340: CreateProcessW lpCommandLine must be mutable
Message-ID: <Frz6471rRcfwIp0UhYB-Jgu9gMV_jf1f5yfyUP044uY=.2f8a84c2-5650-443e-9a9e-944b693bb1e5@github.com>

Launching of processes on Windows using `ProcessCreateW` with a Unicode character set requires the buffer to be writable. An access violation might occur if `ProcessCreateW` writes to the command line string. The current implementation fetches the command line string using JNI GetStringChars returning a buffer that should not be modified. The code is unchanged since 2015.  There have not been any reported faults in that time.

This change copies the command line to a separately allocation mutable buffer to satisfy the Windows requirement.

-------------

Commit messages:
 - 8299340: CreateProcessW lpCommandLine must be mutable

Changes: https://git.openjdk.org/jdk/pull/13894/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13894&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299340
  Stats: 17 lines in 1 file changed: 9 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13894/head:pull/13894

PR: https://git.openjdk.org/jdk/pull/13894

From jlu at openjdk.org  Fri May 12 17:40:46 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 May 2023 17:40:46 GMT
Subject: RFR: 8307547: Support variant collations [v4]
In-Reply-To: <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
Message-ID: <qkG0chvl8TtS_j5_SjQQ7z4LBqRmek36WArmxkm3izc=.dbea81be-d218-452a-98eb-4e007ed9fd41@github.com>

On Thu, 11 May 2023 20:51:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added "reformed" tests

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13917#pullrequestreview-1424917959

From bpb at openjdk.org  Fri May 12 17:55:44 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 May 2023 17:55:44 GMT
Subject: RFR: 8308016: Use snippets in java.io package
In-Reply-To: <J2FEGAKqvuHSrXZsZaKHmD5AwSQsDr5OlHYvltSv_ZY=.b556174f-d8b6-43f4-9690-f4d01eb6603a@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <J2FEGAKqvuHSrXZsZaKHmD5AwSQsDr5OlHYvltSv_ZY=.b556174f-d8b6-43f4-9690-f4d01eb6603a@github.com>
Message-ID: <iOi1uN2Paot06qwac9kgaOPDuJxnxO2Lx7HHkqk4UKg=.22146c6c-9471-4806-a109-d0c17a9f9bf7@github.com>

On Fri, 12 May 2023 17:31:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.
>
> src/java.base/share/classes/java/io/Console.java line 124:
> 
>> 122:      *         if (con != null) {
>> 123:      *             Scanner sc = new Scanner(con.reader());
>> 124:      *             ...
> 
> I'm not sure how you feel about this, but when I have been converting `<pre>` blocks to `@snippet`, I usually try to get rid of non code. Since snippet allows user's to copy the example code, I feel like it's redudant to leave in non code, since they will likely delete it anyways.

I have been just trying to keep it as similar visually as possible but what you say is reasonable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1192652789

From naoto at openjdk.org  Fri May 12 18:00:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 18:00:50 GMT
Subject: RFR: 8299340: CreateProcessW lpCommandLine must be mutable
In-Reply-To: <Frz6471rRcfwIp0UhYB-Jgu9gMV_jf1f5yfyUP044uY=.2f8a84c2-5650-443e-9a9e-944b693bb1e5@github.com>
References: <Frz6471rRcfwIp0UhYB-Jgu9gMV_jf1f5yfyUP044uY=.2f8a84c2-5650-443e-9a9e-944b693bb1e5@github.com>
Message-ID: <IY3M4RTBwpkSkFUPx3RTlco_j8PdZkiDs_m6ahUayII=.eb2cf0c5-3443-4074-98c1-b4c7b6e6cc6b@github.com>

On Tue, 9 May 2023 21:46:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Launching of processes on Windows using `ProcessCreateW` with a Unicode character set requires the buffer to be writable. An access violation might occur if `ProcessCreateW` writes to the command line string. The current implementation fetches the command line string using JNI GetStringChars returning a buffer that should not be modified. The code is unchanged since 2015.  There have not been any reported faults in that time.
> 
> This change copies the command line to a separately allocation mutable buffer to satisfy the Windows requirement.

src/java.base/windows/native/libjava/ProcessImpl_md.c line 385:

> 383:                         // Copy command line to mutable char buffer; CreateProcessW may modify it
> 384:                         jsize cmdLen = (*env)->GetStringLength(env, cmd);
> 385:                         WCHAR *pcmdCopy = (WCHAR*)malloc(cmdLen * sizeof(WCHAR));

Should this include null terminator, as it is interpreted as `LPWSTR` which is null-terminated?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13894#discussion_r1192655747

From lancea at openjdk.org  Fri May 12 18:02:48 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 12 May 2023 18:02:48 GMT
Subject: RFR: 8308016: Use snippets in java.io package
In-Reply-To: <iOi1uN2Paot06qwac9kgaOPDuJxnxO2Lx7HHkqk4UKg=.22146c6c-9471-4806-a109-d0c17a9f9bf7@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <J2FEGAKqvuHSrXZsZaKHmD5AwSQsDr5OlHYvltSv_ZY=.b556174f-d8b6-43f4-9690-f4d01eb6603a@github.com>
 <iOi1uN2Paot06qwac9kgaOPDuJxnxO2Lx7HHkqk4UKg=.22146c6c-9471-4806-a109-d0c17a9f9bf7@github.com>
Message-ID: <6nU_GjadVokt6GDAMNBo1-RUglHvk5eqkdeZwHu2EsY=.5ed4c3b5-a44b-49b9-90e9-c77afb8ffa94@github.com>

On Fri, 12 May 2023 17:52:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 124:
>> 
>>> 122:      *         if (con != null) {
>>> 123:      *             Scanner sc = new Scanner(con.reader());
>>> 124:      *             ...
>> 
>> I'm not sure how you feel about this, but when I have been converting `<pre>` blocks to `@snippet`, I usually try to get rid of non code. Since snippet allows user's to copy the example code, I feel like it's redudant to leave in non code, since they will likely delete it anyways.
>
> I have been just trying to keep it as similar visually as possible but what you say is reasonable.

Agree, that I would make the code valid when using a snippet

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1192658575

From jlu at openjdk.org  Fri May 12 18:02:59 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 May 2023 18:02:59 GMT
Subject: RFR: 8308021: Update IANA Language Subtag Registry to Version
 2023-05-11
Message-ID: <iIPuwaKdPI_0zXeGnvClUFB-k1jB8BHmDv6hpi7Lwys=.de585532-b094-46b0-acb9-204ae53617f3@github.com>

Please review this trivial fix which updates the IANA data to version 5/11/2023. As the update only includes variant sub-tags, there is no impact to JDK tests. The update can be found [here](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-May/000087.html).

-------------

Commit messages:
 - Update LSRTest.java
 - Update registry.txt

Changes: https://git.openjdk.org/jdk/pull/13962/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13962&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308021
  Stats: 20 lines in 2 files changed: 17 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13962.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13962/head:pull/13962

PR: https://git.openjdk.org/jdk/pull/13962

From lancea at openjdk.org  Fri May 12 18:08:42 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 12 May 2023 18:08:42 GMT
Subject: RFR: 8308021: Update IANA Language Subtag Registry to Version
 2023-05-11
In-Reply-To: <iIPuwaKdPI_0zXeGnvClUFB-k1jB8BHmDv6hpi7Lwys=.de585532-b094-46b0-acb9-204ae53617f3@github.com>
References: <iIPuwaKdPI_0zXeGnvClUFB-k1jB8BHmDv6hpi7Lwys=.de585532-b094-46b0-acb9-204ae53617f3@github.com>
Message-ID: <3ACKBswT4rjdq9JYYK_ASVFNsUrsdqRLelkwPvMD1CA=.18ffc1d2-5215-41c7-beb8-b59221532c39@github.com>

On Fri, 12 May 2023 17:56:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this trivial fix which updates the IANA data to version 5/11/2023. As the update only includes variant sub-tags, there is no impact to JDK tests. The update can be found [here](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-May/000087.html).

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13962#pullrequestreview-1424952709

From naoto at openjdk.org  Fri May 12 18:28:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 18:28:46 GMT
Subject: RFR: 8308021: Update IANA Language Subtag Registry to Version
 2023-05-11
In-Reply-To: <iIPuwaKdPI_0zXeGnvClUFB-k1jB8BHmDv6hpi7Lwys=.de585532-b094-46b0-acb9-204ae53617f3@github.com>
References: <iIPuwaKdPI_0zXeGnvClUFB-k1jB8BHmDv6hpi7Lwys=.de585532-b094-46b0-acb9-204ae53617f3@github.com>
Message-ID: <PQCQ1-gxLgk9aezNKZcWJdCFeQUdgUjTQFvuJ0t9G7E=.3160a03a-b57d-48e8-a4e6-0e1228af7b8a@github.com>

On Fri, 12 May 2023 17:56:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this trivial fix which updates the IANA data to version 5/11/2023. As the update only includes variant sub-tags, there is no impact to JDK tests. The update can be found [here](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-May/000087.html).

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13962#pullrequestreview-1424976281

From rriggs at openjdk.org  Fri May 12 18:37:45 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 12 May 2023 18:37:45 GMT
Subject: RFR: 8299340: CreateProcessW lpCommandLine must be mutable
In-Reply-To: <IY3M4RTBwpkSkFUPx3RTlco_j8PdZkiDs_m6ahUayII=.eb2cf0c5-3443-4074-98c1-b4c7b6e6cc6b@github.com>
References: <Frz6471rRcfwIp0UhYB-Jgu9gMV_jf1f5yfyUP044uY=.2f8a84c2-5650-443e-9a9e-944b693bb1e5@github.com>
 <IY3M4RTBwpkSkFUPx3RTlco_j8PdZkiDs_m6ahUayII=.eb2cf0c5-3443-4074-98c1-b4c7b6e6cc6b@github.com>
Message-ID: <Bz2kGSDMYa0xsGsooFIlx3lLHcfB_5lIAACUL3WD4lQ=.e278e5b4-8f06-48a6-9ad5-c12bcadca5ad@github.com>

On Fri, 12 May 2023 17:56:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Launching of processes on Windows using `ProcessCreateW` with a Unicode character set requires the buffer to be writable. An access violation might occur if `ProcessCreateW` writes to the command line string. The current implementation fetches the command line string using JNI GetStringChars returning a buffer that should not be modified. The code is unchanged since 2015.  There have not been any reported faults in that time.
>> 
>> This change copies the command line to a separately allocation mutable buffer to satisfy the Windows requirement.
>
> src/java.base/windows/native/libjava/ProcessImpl_md.c line 385:
> 
>> 383:                         // Copy command line to mutable char buffer; CreateProcessW may modify it
>> 384:                         jsize cmdLen = (*env)->GetStringLength(env, cmd);
>> 385:                         WCHAR *pcmdCopy = (WCHAR*)malloc(cmdLen * sizeof(WCHAR));
> 
> Should this include null terminator, as it is interpreted as `LPWSTR` which is null-terminated?

It seems like it should now.  Java strings are not null terminated and any null termination would have accidental.
But it has worked for a long time (2013) without explicit Unicode null termination.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13894#discussion_r1192685105

From bpb at openjdk.org  Fri May 12 19:02:46 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 May 2023 19:02:46 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8308016: Remove ellipses ("...") from snippets

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13957/files
  - new: https://git.openjdk.org/jdk/pull/13957/files/8a555a76..bc5c0358

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957

PR: https://git.openjdk.org/jdk/pull/13957

From rkennke at openjdk.org  Fri May 12 19:08:11 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 12 May 2023 19:08:11 GMT
Subject: RFR: 8305895: Implementation: JEP 450: Compact Object Headers
 (Experimental)
Message-ID: <v2emO_lbVeQr6FArSo4y6krhG5b0pzaX9GPGo0A_A5M=.831590ab-3f21-454b-b100-655d44cc3b60@github.com>

This is the main body of the JEP 450: Compact Object Headers (Experimental).

Main changes:
 - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag.
 - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #10907, #13582 and #13779 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word, and dealing with (monitor-)locked objects. When the object is monitor-locked, we load the displaced mark-word from the monitor, and load the compressed Klass* from there. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded, and/or reach through to the monitor when the object is locked by a monitor.
 - The identity hash-code is narrowed to 25 bits.
 - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
 - Arrays will can now store their length at offset 8. Due to alignment restrictions, array elements will still start at offset 16. #11044 will resolve that restriction and allow array elements to start at offset 12 (except for long, double and uncompressed oops, which are still required to start at an element-aligned offset).
 - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders.

Testing:
 (+UseCompactObjectHeaders tests are run with the flag hard-patched into the build, to also catch @flagless tests, and to avoid mismatches with CDS - see above.)
 - [x] tier1 (x86_64)
 - [x] tier2 (x86_64)
 - [x] tier3 (x86_64)
 - [ ] tier4 (x86_64)
 - [x] tier1 (aarch64)
 - [x] tier2 (aarch64)
 - [x] tier3 (aarch64)
 - [ ] tier4 (aarch64)
 - [ ] tier1 (x86_64) +UseCompactObjectHeaders
 - [ ] tier2 (x86_64) +UseCompactObjectHeaders
 - [ ] tier3 (x86_64) +UseCompactObjectHeaders
 - [ ] tier4 (x86_64) +UseCompactObjectHeaders
 - [ ] tier1 (aarch64) +UseCompactObjectHeaders
 - [ ] tier2 (aarch64) +UseCompactObjectHeaders
 - [ ] tier3 (aarch64) +UseCompactObjectHeaders
 - [ ] tier4 (aarch64) +UseCompactObjectHeaders

-------------

Depends on: https://git.openjdk.org/jdk/pull/13779

Commit messages:
 - Consolidate _LP64 #ifdef
 - Remove obsolete check
 - Handle klass offset in JVMCI
 - Disable CDS tests when running with +UseCompactObjectHeaders
 - Merge branch 'JDK-8305898' into JDK-8305895-v2
 - @colenp review comments
 - Remove obsolete code
 - Some hashcode improvements (mostly SA)
 - Merge remote-tracking branch 'origin/JDK-8305895' into JDK-8305895
 - Fix some uses of klass_offset_in_bytes()
 - ... and 36 more: https://git.openjdk.org/jdk/compare/880d564a...a6e9f10a

Changes: https://git.openjdk.org/jdk/pull/13961/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13961&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305895
  Stats: 1306 lines in 98 files changed: 1025 ins; 94 del; 187 mod
  Patch: https://git.openjdk.org/jdk/pull/13961.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13961/head:pull/13961

PR: https://git.openjdk.org/jdk/pull/13961

From coleenp at openjdk.org  Fri May 12 19:08:11 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Fri, 12 May 2023 19:08:11 GMT
Subject: RFR: 8305895: Implementation: JEP 450: Compact Object Headers
 (Experimental)
In-Reply-To: <v2emO_lbVeQr6FArSo4y6krhG5b0pzaX9GPGo0A_A5M=.831590ab-3f21-454b-b100-655d44cc3b60@github.com>
References: <v2emO_lbVeQr6FArSo4y6krhG5b0pzaX9GPGo0A_A5M=.831590ab-3f21-454b-b100-655d44cc3b60@github.com>
Message-ID: <Fyoon-8C-mj7tglV1-Bx5-UCv-UQsBdTE_Me5Zu4puo=.db507822-dc51-476d-8279-5fcfb4b6ae8b@github.com>

On Fri, 12 May 2023 17:27:25 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> This is the main body of the JEP 450: Compact Object Headers (Experimental).
> 
> Main changes:
>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag.
>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #10907, #13582 and #13779 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word, and dealing with (monitor-)locked objects. When the object is monitor-locked, we load the displaced mark-word from the monitor, and load the compressed Klass* from there. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded, and/or reach through to the monitor when the object is locked by a monitor.
>  - The identity hash-code is narrowed to 25 bits.
>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>  - Arrays will can now store their length at offset 8. Due to alignment restrictions, array elements will still start at offset 16. #11044 will resolve that restriction and allow array elements to start at offset 12 (except for long, double and uncompressed oops, which are still required to start at an element-aligned offset).
>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders.
> 
> Testing:
>  (+UseCompactObjectHeaders tests are run with the flag hard-patched into the build, to also catch @flagless tests, and to avoid mismatches with CDS - see above.)
>  - [x] tier1 (x86_64)
>  - [x] tier2 (x86_64)
>  - [x] tier3 (x86_64)
>  - [ ] tier4 (x86_64)
>  - [x] tier1 (aarch64)
>  - [x] tier2 (aarch64)
>  - [x] tier3 (aarch64)
>  - [ ] tier4 (aarch64)
>  - [ ] tier1 (x86_64) +UseCompactObjectHeaders
>  - [ ] tier2 (x86_64) +UseCompactObjectHeaders
>  - [ ] tier3 (x86_64) +UseCompactObjectHeaders
>  - [ ] tier4 (x86_64) +UseCompactObjectHeaders
>  - [ ] tier1 (aarch64) +UseCompactObjectHeaders
>  - [ ] tier2 (aarch64) +UseCompactObjectHeaders
>  - [ ] tier3 (aarch64) +UseCompactObjectHeaders
>  - [ ] tier4 (aarch64) +UseCompactObjectHeaders

These changes are an improvement.

src/hotspot/cpu/x86/c1_MacroAssembler_x86.cpp line 193:

> 191:       movl(Address(obj, arrayOopDesc::length_offset_in_bytes() + sizeof(jint)), t1);
> 192:     }
> 193: #endif

This endif should go after UseCompressedClassPointers conditional, and consolidate to one set of #ifdef _LP64.

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 5126:

> 5124:   assert(UseCompactObjectHeaders, "expect compact object headers");
> 5125: 
> 5126:   if (!UseCompactObjectHeaders) {

Now this isn't needed, right?

src/hotspot/share/cds/archiveBuilder.cpp line 726:

> 724:       k->set_prototype_header(markWord::prototype().set_narrow_klass(nk));
> 725:     }
> 726: #endif //_LP64

If CDS is turned off for UseCompactObjectHeaders, I don't understand this change or the one to archiveHeapWriter.  -Xshare:dump objects would be the wrong size.  If CDS is not supported, then there should be something in arguments.cpp that gives an error for that.  And write a test for that error of mixing and matching.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13961#pullrequestreview-1424925882
PR Review Comment: https://git.openjdk.org/jdk/pull/13961#discussion_r1192648245
PR Review Comment: https://git.openjdk.org/jdk/pull/13961#discussion_r1192646637
PR Review Comment: https://git.openjdk.org/jdk/pull/13961#discussion_r1192661859

From rkennke at openjdk.org  Fri May 12 19:08:12 2023
From: rkennke at openjdk.org (Roman Kennke)
Date: Fri, 12 May 2023 19:08:12 GMT
Subject: RFR: 8305895: Implementation: JEP 450: Compact Object Headers
 (Experimental)
In-Reply-To: <Fyoon-8C-mj7tglV1-Bx5-UCv-UQsBdTE_Me5Zu4puo=.db507822-dc51-476d-8279-5fcfb4b6ae8b@github.com>
References: <v2emO_lbVeQr6FArSo4y6krhG5b0pzaX9GPGo0A_A5M=.831590ab-3f21-454b-b100-655d44cc3b60@github.com>
 <Fyoon-8C-mj7tglV1-Bx5-UCv-UQsBdTE_Me5Zu4puo=.db507822-dc51-476d-8279-5fcfb4b6ae8b@github.com>
Message-ID: <PDSGFCbBSjKLJ7TUaISUOok1ZBiOf12CymV6efqjuh8=.d2634fb8-d35e-4c93-bf7b-ab1f428fe49c@github.com>

On Fri, 12 May 2023 18:03:13 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is the main body of the JEP 450: Compact Object Headers (Experimental).
>> 
>> Main changes:
>>  - Introduction of the (experimental) flag UseCompactObjectHeaders. All changes in this PR are protected by this flag.
>>  - The compressed Klass* can now be stored in the mark-word of objects. In order to be able to do this, we are building on #10907, #13582 and #13779 to protect the relevant (upper 32) bits of the mark-word. Significant parts of this PR deal with loading the compressed Klass* from the mark-word, and dealing with (monitor-)locked objects. When the object is monitor-locked, we load the displaced mark-word from the monitor, and load the compressed Klass* from there. This PR also changes some code paths (mostly in GCs) to be more careful when accessing Klass* (or mark-word or size) to be able to fetch it from the forwardee in case the object is forwarded, and/or reach through to the monitor when the object is locked by a monitor.
>>  - The identity hash-code is narrowed to 25 bits.
>>  - Instances can now have their base-offset (the offset where the field layouter starts to place fields) at offset 8 (instead of 12 or 16).
>>  - Arrays will can now store their length at offset 8. Due to alignment restrictions, array elements will still start at offset 16. #11044 will resolve that restriction and allow array elements to start at offset 12 (except for long, double and uncompressed oops, which are still required to start at an element-aligned offset).
>>  - CDS can now write and read archives with the compressed header. However, it is not possible to read an archive that has been written with an opposite setting of UseCompactObjectHeaders.
>> 
>> Testing:
>>  (+UseCompactObjectHeaders tests are run with the flag hard-patched into the build, to also catch @flagless tests, and to avoid mismatches with CDS - see above.)
>>  - [x] tier1 (x86_64)
>>  - [x] tier2 (x86_64)
>>  - [x] tier3 (x86_64)
>>  - [ ] tier4 (x86_64)
>>  - [x] tier1 (aarch64)
>>  - [x] tier2 (aarch64)
>>  - [x] tier3 (aarch64)
>>  - [ ] tier4 (aarch64)
>>  - [ ] tier1 (x86_64) +UseCompactObjectHeaders
>>  - [ ] tier2 (x86_64) +UseCompactObjectHeaders
>>  - [ ] tier3 (x86_64) +UseCompactObjectHeaders
>>  - [ ] tier4 (x86_64) +UseCompactObjectHeaders
>>  - [ ] tier1 (aarch64) +UseCompactObjectHeaders
>>  - [ ] tier2 (aarch64) +UseCompactObjectHeaders
>>  - [ ] tier3 (aarch64) +UseCompactObjectHeaders
>>  - [ ] tier4 (aarch64) +UseCompactObjectHeaders
>
> src/hotspot/share/cds/archiveBuilder.cpp line 726:
> 
>> 724:       k->set_prototype_header(markWord::prototype().set_narrow_klass(nk));
>> 725:     }
>> 726: #endif //_LP64
> 
> If CDS is turned off for UseCompactObjectHeaders, I don't understand this change or the one to archiveHeapWriter.  -Xshare:dump objects would be the wrong size.  If CDS is not supported, then there should be something in arguments.cpp that gives an error for that.  And write a test for that error of mixing and matching.

Yeah, we do have code in arguments.cpp that turns off CDS if the wrong setting is used (i.e. the opposite of the default setting). If you hard-code UseCompactObjectHeaders to be true, then the archives will be written in the compact layout, and can be read. That's what the changes in share/cds implement. (Note: I regularily hard-patch the UseCompactObjectHeaders flag to be true for testing, because that also catches all the @flagless tests, and I know that Daniel does that, too.)
We disabled CDS jtreg tests when passing +UseCompactObjectHeaders via cmd line, because we would see a lot of test failures because of archive format mismatch. I am not sure if that's a good way to deal with that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13961#discussion_r1192698676

From rriggs at openjdk.org  Fri May 12 19:38:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 12 May 2023 19:38:53 GMT
Subject: RFR: 8299340: CreateProcessW lpCommandLine must be mutable [v2]
In-Reply-To: <Frz6471rRcfwIp0UhYB-Jgu9gMV_jf1f5yfyUP044uY=.2f8a84c2-5650-443e-9a9e-944b693bb1e5@github.com>
References: <Frz6471rRcfwIp0UhYB-Jgu9gMV_jf1f5yfyUP044uY=.2f8a84c2-5650-443e-9a9e-944b693bb1e5@github.com>
Message-ID: <GB-n3brLrkzUdwa7Pb8WzIhQb6qRfdcxoGwLPwKuOSk=.71a8acd0-2215-457d-8b09-6409e50b47cf@github.com>

> Launching of processes on Windows using `ProcessCreateW` with a Unicode character set requires the buffer to be writable. An access violation might occur if `ProcessCreateW` writes to the command line string. The current implementation fetches the command line string using JNI GetStringChars returning a buffer that should not be modified. The code is unchanged since 2015.  There have not been any reported faults in that time.
> 
> This change copies the command line to a separately allocation mutable buffer to satisfy the Windows requirement.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Add unicode null to native command line copy

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13894/files
  - new: https://git.openjdk.org/jdk/pull/13894/files/b8e49a65..41b7f7d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13894&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13894&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13894/head:pull/13894

PR: https://git.openjdk.org/jdk/pull/13894

From xuelei at openjdk.org  Fri May 12 19:51:57 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 12 May 2023 19:51:57 GMT
Subject: RFR: 8308022: update for deprecated sprintf for java.base
Message-ID: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>

Hi,

May I have this update reviewed?

The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.

Thanks,
Xuelei

-------------

Commit messages:
 - update copyright year
 - 8308022: update for deprecated sprintf for java.base

Changes: https://git.openjdk.org/jdk/pull/13963/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13963&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308022
  Stats: 44 lines in 9 files changed: 5 ins; 0 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/13963.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13963/head:pull/13963

PR: https://git.openjdk.org/jdk/pull/13963

From duke at openjdk.org  Fri May 12 19:53:55 2023
From: duke at openjdk.org (GuySteele)
Date: Fri, 12 May 2023 19:53:55 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v19]
In-Reply-To: <wmegzqOmGYmmSpapSq1N2yIsBWcKTXCYDFpUQLwDYrs=.8a7ed0df-4849-4656-a52f-8f99a4963516@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <wmegzqOmGYmmSpapSq1N2yIsBWcKTXCYDFpUQLwDYrs=.8a7ed0df-4849-4656-a52f-8f99a4963516@github.com>
Message-ID: <ICLiKPbnxo0VZNuQ1vY67aVq6e0UBx1G75xn70Xxf70=.9e37db38-cc37-4638-b1fd-513f2b81211c@github.com>

On Thu, 6 Apr 2023 18:07:29 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.
>
> Chris Hennick has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into patch-1
>  - Merge branch 'master' of https://git.openjdk.org/jdk into patch-1
>  - Merge branch 'master' into patch-1
>  - Update copyright date in RandomNext.java
>  - Update copyright date in RandomGeneratorNext.java
>  - Update copyright date in RandomGeneratorExponentialGaussian.java
>  - Update copyright date in RandomSupport.java
>  - Add parameter to enable/disable fixed PRNG seed
>  - Rewrite Javadoc
>  - Simplify Javadoc description
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/08fbb7bb...2470c00a

I have now reviewed all the changes in file .../jdk/internal/util/random/RandomSupport.java . It appears that the method formerly called computeWinsorizedNextExponential has been renamed to computeNextExponentialSoftCapped, and that is a good change. All the changes to the executable code appear to be sound (and, yes, I believe I still remember how all this code is supposed to work?even while admitting that I wrote it some years ago and that a couple of embarrassing mistakes were later discovered and repaired, thank goodness). I looked especially carefully at the change of representation for the variable "extra" from double to long and the new uses of fma. I went back and looked at email exchanges I had with Joe Darcy on May 10, 2022, and I see that many of the concerns I expressed at that time have been addressed. 

I do suggest that for extra clarity, the declaration and computation of maxExtraMinus1 at lines 1206--1212 be moved down below to after line 1222, just below the comment that begins "We didn't use the upper part of U1 after all". It may be that good optimizing Java compilers perform this code motion anyway (the code in lines 1213?1221 does not refer to maxExtraMinus1), but it would help a human reader to understand that this code is not part of and does not need to be part of the fast path through the code. Moreover, though a compiler cannot tell that it's okay to move the comparison of maxValue to 0.0 (and the possible forced return of 0.0) off the fast path, I argue that it is indeed okay to do so, because it is always permitted to return a value larger than maxValue, and the fast path does always return a nonnegative value. So I actually argue to move three more lines (in all, lines 1203?1212) to after line 1222.

In all other respects, I recommend that this set of changes be adopted exactly as is.

If making the one change I suggested above might cause adoption to slip from JDK21 to JDK22 (perhaps because of a need for retesting), then I would suggest adopting the code exactly as is and then scheduling the suggested change for JDK22, because the suggested change improves clarity and code speed but should not change the advertised functionality at all.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8131#issuecomment-1546202844

From asemenyuk at openjdk.org  Fri May 12 19:56:46 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 12 May 2023 19:56:46 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v2]
In-Reply-To: <PEKg9keUFr1YbZ2wRIq-CjOGGi-vr6fduph5XVIcEhE=.74f584e9-450f-494a-ba5c-555a73d9b4d1@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
 <PEKg9keUFr1YbZ2wRIq-CjOGGi-vr6fduph5XVIcEhE=.74f584e9-450f-494a-ba5c-555a73d9b4d1@github.com>
Message-ID: <Kd1vTFKbexnKYxPAgnCs9VBfYIaQL357a-VRYBJAiuc=.36066c4d-2ddd-44cf-9365-abefb958b9d2@github.com>

On Fri, 5 May 2023 14:12:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
>> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
>> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
>> 
>> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
>> Mac OS X 10.15 is the oldest version supported.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor source code style cleanup

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13586#pullrequestreview-1425079644

From jlu at openjdk.org  Fri May 12 20:01:53 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 May 2023 20:01:53 GMT
Subject: Integrated: 6714245: [Col] Collator - Faster Comparison for identical
 strings.
In-Reply-To: <GXUyAGggDuYZaMrle9tFpi1XJjboeLu0PoT6bfcnXn8=.a8ce6ff2-c204-479e-a3ee-1cbdf36a39fe@github.com>
References: <GXUyAGggDuYZaMrle9tFpi1XJjboeLu0PoT6bfcnXn8=.a8ce6ff2-c204-479e-a3ee-1cbdf36a39fe@github.com>
Message-ID: <BwaIy9x7xk8m5HZppbcxkxFxx0mHVnvtP7dT2JX5BIg=.44a9ef36-ad47-49f2-8402-a8db19315e45@github.com>

On Thu, 11 May 2023 18:27:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds an initial equality check to `RuleBasedCollator.compare(String source, String target)`.
> 
> This speeds up the operation for equal input Strings, as it bypasses Collator rule comparisons of each element for both of the input Strings.

This pull request has now been integrated.

Changeset: 4441a230
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4441a2306fb12f60ac879f7fda6c7446ac130dcb
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

6714245: [Col] Collator - Faster Comparison for identical strings.

Reviewed-by: rriggs, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13938

From duke at openjdk.org  Fri May 12 20:41:32 2023
From: duke at openjdk.org (Chris Hennick)
Date: Fri, 12 May 2023 20:41:32 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v20]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <BSIoCHopng4hBzyvR8dqb9-sGqdc0zCKgEzJQL6yJik=.04ed7754-75df-48dc-9929-84ce514801cf@github.com>

> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.

Chris Hennick has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'origin/patch-1' into patch-1
 - Optimize: move some code out of the fast path

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/8131/files
  - new: https://git.openjdk.org/jdk/pull/8131/files/2470c00a..e4714ec9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=18-19

  Stats: 20 lines in 1 file changed: 10 ins; 10 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From duke at openjdk.org  Fri May 12 20:41:37 2023
From: duke at openjdk.org (Chris Hennick)
Date: Fri, 12 May 2023 20:41:37 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v19]
In-Reply-To: <wmegzqOmGYmmSpapSq1N2yIsBWcKTXCYDFpUQLwDYrs=.8a7ed0df-4849-4656-a52f-8f99a4963516@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <wmegzqOmGYmmSpapSq1N2yIsBWcKTXCYDFpUQLwDYrs=.8a7ed0df-4849-4656-a52f-8f99a4963516@github.com>
Message-ID: <oTcXrh_EAjOP0SUONffmBvwoX-zIMDRc0PXFogLiHQM=.f69fade5-7bc4-4f95-abbf-eadc28da1fd3@github.com>

On Thu, 6 Apr 2023 18:07:29 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.
>
> Chris Hennick has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into patch-1
>  - Merge branch 'master' of https://git.openjdk.org/jdk into patch-1
>  - Merge branch 'master' into patch-1
>  - Update copyright date in RandomNext.java
>  - Update copyright date in RandomGeneratorNext.java
>  - Update copyright date in RandomGeneratorExponentialGaussian.java
>  - Update copyright date in RandomSupport.java
>  - Add parameter to enable/disable fixed PRNG seed
>  - Rewrite Javadoc
>  - Simplify Javadoc description
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/08fbb7bb...2470c00a

Moved the code after the fast-path return as requested.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8131#issuecomment-1546259257

From naoto at openjdk.org  Fri May 12 20:52:43 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 20:52:43 GMT
Subject: RFR: 8299340: CreateProcessW lpCommandLine must be mutable [v2]
In-Reply-To: <GB-n3brLrkzUdwa7Pb8WzIhQb6qRfdcxoGwLPwKuOSk=.71a8acd0-2215-457d-8b09-6409e50b47cf@github.com>
References: <Frz6471rRcfwIp0UhYB-Jgu9gMV_jf1f5yfyUP044uY=.2f8a84c2-5650-443e-9a9e-944b693bb1e5@github.com>
 <GB-n3brLrkzUdwa7Pb8WzIhQb6qRfdcxoGwLPwKuOSk=.71a8acd0-2215-457d-8b09-6409e50b47cf@github.com>
Message-ID: <JW8SpA4mJ1qOEYlntwOfv58GHbuHV5qlNvHmboZv224=.8d342758-a695-4156-85d0-56816b924339@github.com>

On Fri, 12 May 2023 19:38:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Launching of processes on Windows using `ProcessCreateW` with a Unicode character set requires the buffer to be writable. An access violation might occur if `ProcessCreateW` writes to the command line string. The current implementation fetches the command line string using JNI GetStringChars returning a buffer that should not be modified. The code is unchanged since 2015.  There have not been any reported faults in that time.
>> 
>> This change copies the command line to a separately allocation mutable buffer to satisfy the Windows requirement.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add unicode null to native command line copy

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13894#pullrequestreview-1425138318

From duke at openjdk.org  Fri May 12 21:00:53 2023
From: duke at openjdk.org (GuySteele)
Date: Fri, 12 May 2023 21:00:53 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v20]
In-Reply-To: <BSIoCHopng4hBzyvR8dqb9-sGqdc0zCKgEzJQL6yJik=.04ed7754-75df-48dc-9929-84ce514801cf@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
 <BSIoCHopng4hBzyvR8dqb9-sGqdc0zCKgEzJQL6yJik=.04ed7754-75df-48dc-9929-84ce514801cf@github.com>
Message-ID: <lYU-I9UMTneuOuu6Sxy2EjBVWjlNUx6QHGThl_w6ooM=.11d8397a-1119-4f92-9a21-f80f3c434e6c@github.com>

On Fri, 12 May 2023 20:41:32 GMT, Chris Hennick <duke at openjdk.org> wrote:

>> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
>> 
>> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
>> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
>> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.
>
> Chris Hennick has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/patch-1' into patch-1
>  - Optimize: move some code out of the fast path

Latest change looks good. I noted the improvement to the comment beginning "We didn't use the upper part of U1 after all".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/8131#issuecomment-1546292204

From rriggs at openjdk.org  Fri May 12 21:40:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 12 May 2023 21:40:43 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <5umr1RZubaebgzhwponiJ1NnVgXh0Ruvlw0vLDo6_1g=.79197765-4fa2-4185-85df-df62b506ded5@github.com>

On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

Looks ok.

Is it practical to write a test for this situation? 
Can I assume you've validated the improvement as a remedy for the observed hangs?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1546332294

From almatvee at openjdk.org  Fri May 12 22:08:58 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 12 May 2023 22:08:58 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v2]
In-Reply-To: <PEKg9keUFr1YbZ2wRIq-CjOGGi-vr6fduph5XVIcEhE=.74f584e9-450f-494a-ba5c-555a73d9b4d1@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
 <PEKg9keUFr1YbZ2wRIq-CjOGGi-vr6fduph5XVIcEhE=.74f584e9-450f-494a-ba5c-555a73d9b4d1@github.com>
Message-ID: <DBuIFwrtzIKUiah9Br5iZCADQw5z5ppWdR33xYWuZGM=.5665db8a-2cba-4757-bdfa-70a82a0cedd8@github.com>

On Fri, 5 May 2023 14:12:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
>> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
>> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
>> 
>> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
>> Mac OS X 10.15 is the oldest version supported.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor source code style cleanup

src/jdk.jpackage/share/classes/jdk/jpackage/internal/CLIHelp.java line 51:

> 49:             Log.info(I18N.getString("MSG_Help_no_args"));
> 50:         } else {
> 51:             OperatingSystem platform = OperatingSystem.current();

Should we add if (Log.isVerbose) back? Otherwise default case in switch statement never executed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1192826773

From liach at openjdk.org  Sat May 13 14:04:59 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 13 May 2023 14:04:59 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v2]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <sw-4mpb7ypDhzwOM-TJPVp2BFYe1p0K8gO-RmjK1yLU=.1166f37a-657a-46d4-9aa3-d1ef49471925@github.com>

> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
> 
> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
> 
> Current problems:
> - [ ] The lazy var handle is quite slow on the first invocation.
>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>    - After that, the lazy handle has a performance on par with the regular var handle.
> - [ ] The class-loading-based test is not in a unit test
>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
> 
> 
> Benchmark                                            Mode  Cnt       Score        Error  Units
> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30       0.769 ?      0.003  ns/op
> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30       0.767 ?      0.002  ns/op
> 
> 
> Benchmark                                            Mode  Cnt       Score        Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10   73140.100 ?   7735.276  ns/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10   50000.000 ?   8482.883  ns/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   91350.100 ?   9776.343  ns/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  145540.200 ?  72894.865  ns/op
> LazyStaticColdStart.varHandleCreateEager               ss   10   47069.900 ?   3513.909  ns/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10   24780.300 ?   5144.540  ns/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10   85479.700 ?  10816.983  ns/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  413630.100 ? 189370.448  ns/op

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Test the creation performance of handles, lazy one indeed better
 - Merge branch 'master' into lazy-static-varhandle
 - copyright year
 - Benchmarks. lazy initialize is SLOW
 - nuke meaningless overrides
 - make static field var handles lazy and fix NPE in isAccessModeSupported

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/4b3cfece..eea7aa84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=00-01

  Stats: 107966 lines in 1780 files changed: 86291 ins; 8891 del; 12784 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

PR: https://git.openjdk.org/jdk/pull/13821

From liach at openjdk.org  Sat May 13 14:11:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 13 May 2023 14:11:11 GMT
Subject: RFR: 8306457: Classfile API components implementations should not
 be exposed [v2]
In-Reply-To: <67PAXfiqaTaU8vYbbA31WJBG029RHK454HIDp5ZlYx8=.ec9b4ddd-fe42-4236-9e44-ef63e164e906@github.com>
References: <67PAXfiqaTaU8vYbbA31WJBG029RHK454HIDp5ZlYx8=.ec9b4ddd-fe42-4236-9e44-ef63e164e906@github.com>
Message-ID: <Cx6lfCV6bwkUp5dyRpHOfIJtwg18eoGB1nMQxXQRmv4=.495cdea9-7422-41de-95d4-9e52a8403f5d@github.com>

> The jdk.internal.classfile.components package's interfaces have implementations in their nested classes, which are implicitly public and exported with the package. They are now moved to the impl package to avoid unwanted exposures. Fixed a few minor javadoc issues in the interfaces as well.
> 
> In conflict with #13021; one needs updating if the other is merged.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - merge indy remap fix
 - Merge branch 'master' into fix/hide-component-impl
 - 8306457: Classfile API components implementations should not be exposed

-------------

Changes: https://git.openjdk.org/jdk/pull/13541/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13541&range=01
  Stats: 1772 lines in 8 files changed: 920 ins; 826 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/13541.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13541/head:pull/13541

PR: https://git.openjdk.org/jdk/pull/13541

From liach at openjdk.org  Sat May 13 14:11:11 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 13 May 2023 14:11:11 GMT
Subject: RFR: 8306457: Classfile API components implementations should not
 be exposed
In-Reply-To: <67PAXfiqaTaU8vYbbA31WJBG029RHK454HIDp5ZlYx8=.ec9b4ddd-fe42-4236-9e44-ef63e164e906@github.com>
References: <67PAXfiqaTaU8vYbbA31WJBG029RHK454HIDp5ZlYx8=.ec9b4ddd-fe42-4236-9e44-ef63e164e906@github.com>
Message-ID: <zPY7CqOaF0vwcB4I6k3eTJ0rAQcj5lV-A9Yq9-f4Q54=.87abda7c-4827-41e8-9807-b0e7dffd8fa7@github.com>

On Wed, 19 Apr 2023 16:58:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> The jdk.internal.classfile.components package's interfaces have implementations in their nested classes, which are implicitly public and exported with the package. They are now moved to the impl package to avoid unwanted exposures. Fixed a few minor javadoc issues in the interfaces as well.
> 
> In conflict with #13021; one needs updating if the other is merged.

@asotona Can you take a look at this proposal to move implementation records to the impl package since they shouldn't be public nested members of interfaces?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13541#issuecomment-1546660654

From andreas at flueckiger.ch  Sat May 13 18:43:56 2023
From: andreas at flueckiger.ch (andreas at flueckiger.ch)
Date: Sat, 13 May 2023 20:43:56 +0200
Subject: Leap second handling in Windows timestamps
Message-ID: <1790d01d985ca$e03cf6c0$a0b6e440$@flueckiger.ch>

Hello,

This is my first post to this mailing list. I've been exploring a problem concerning leap seconds that emerged with the Windows 10 October 2018 Update. The current implementation of InstantSource and other classes that interact with FILETIME structures seem to be affected. This problem extends beyond just leap second days and will occur on any future day where the UTC-TAI offset deviates from 37 seconds.

The Java code snippet below, which uses JNA to convert a Windows FILETIME to an Instant, represents my initial attempt to address this issue. This approach makes the assumption that no more than one leap second is added or removed in a day, which should hold true until at least 2035, and likely a few years beyond.

I'm not sure how this will impact performance, and I'm not certain about the exact performance requirements. Also, I'm not sure if my current level of experience and permissions allow me to contribute directly to the JDK codebase. Still, I hope this code can provide some direction towards refining the handling of Windows timestamps.

Kind regards,
Andreas

private static Instant fileTimeToInstant(long fileTime) {
  if (fileTime < 0L) {
    throw new DateTimeException("file time must not be negative");
  }

  // Calculate nano adjustment and round down fileTime to the nearest second
  int nanoAdjustment = (int) (fileTime % 10000000L);
  fileTime -= nanoAdjustment;
  nanoAdjustment *= 100;

  // Populate FILETIME structure
  FILETIME fileTimeStruct = new FILETIME();
  fileTimeStruct.dwHighDateTime = (int) (fileTime >>> 32);
  fileTimeStruct.dwLowDateTime = (int) (fileTime & 0xffffffffL);

  // Convert FILETIME structure to a SYSTEMTIME structure
  SYSTEMTIME systemTime = new SYSTEMTIME();
  if (!Kernel32.INSTANCE.FileTimeToSystemTime(fileTimeStruct, systemTime)) {
    throw new LastErrorException(Native.getLastError());
  }

  // Calculate epoch day and second of day
  long epochDay = LocalDate.of(systemTime.wYear, systemTime.wMonth, systemTime.wDay).toEpochDay();
  int secondOfDay = systemTime.wHour * 3600 + systemTime.wMinute * 60 + systemTime.wSecond;

  // Calculate UTC-SLS slew if necessary and only for dates before December 31,
  // 30827 (epochDay < 10540167). SystemTimeToFileTime does not support dates
  // after the year 30827.
  if (secondOfDay >= 85399 && epochDay < 10540167) {
    // If the actual second of the day is 86400 (leap second) and the process is in
    // "compatible mode", increment the secondOfDay variable. In compatible mode,
    // the clock slows down to half speed for two seconds at the '59' second mark,
    // and systemTime.wMilliseconds reaches 500 at the beginning of the leap second.
    // This ensures that the leap second is properly accounted for without depending
    // on the ProcessLeapSecondInfo option. Rounding down fileTime to the nearest
    // second ensures that this check works as intended.
    if (secondOfDay == 86399 && systemTime.wMilliseconds == 500) {
      secondOfDay++;
    }

    // Calculate leap adjustment
    int leapAdjustment;
    if (secondOfDay == 86400) {
      // In case of a leap second, set leap adjustment to 1
      // to avoid unnecessary further calculations
      leapAdjustment = 1;
    } else {
      // If it's not a leap second, calculate leap adjustment by
      // determining the difference to the beginning of the next day
      LocalDate nextDay = LocalDate.ofEpochDay(epochDay + 1);
      systemTime.wYear = (short) nextDay.getYear();
      systemTime.wMonth = (short) nextDay.getMonthValue();
      systemTime.wDay = (short) nextDay.getDayOfMonth();
      systemTime.wHour = 0;
      systemTime.wMinute = 0;
      systemTime.wSecond = 0;
      systemTime.wMilliseconds = 0;
      if (!Kernel32.INSTANCE.SystemTimeToFileTime(systemTime, fileTimeStruct)) {
        throw new LastErrorException(Native.getLastError());
      }
      long nextDayFileTime = (((long) fileTimeStruct.dwHighDateTime) << 32) | (fileTimeStruct.dwLowDateTime & 0xffffffffL);

      leapAdjustment = (int) ((nextDayFileTime - fileTime) / 10000000L + secondOfDay - 86400L);
    }

    // Adjust nanoseconds based on leap adjustment
    if (leapAdjustment != 0 && secondOfDay - leapAdjustment >= 85400) {
      nanoAdjustment -= ((secondOfDay - leapAdjustment - 85400) * 1000000000L + nanoAdjustment) * leapAdjustment / 1000L;
    }
  }

  return Instant.ofEpochSecond(epochDay * 86400L + secondOfDay, nanoAdjustment);
}


From tvaleev at openjdk.org  Sun May 14 05:53:56 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sun, 14 May 2023 05:53:56 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>
Message-ID: <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com>

On Fri, 12 May 2023 19:02:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308016: Remove ellipses ("...") from snippets

src/java.base/share/classes/java/io/FilePermission.java line 1033:

> 1031:      *
> 1032:      * {@snippet lang=java :
> 1033:      *     "/tmp/scratch/foo", "read,write",

This doesn't look like a valid Java code. This is not even a well-formed expression. I'm not sure whether there are any standard requirements about this (the spec is vague here), but IntelliJ IDEA assumes that the Java snippet is a member, a statement, or an expression. It's likely that parse error will be displayed here in the IDE.

src/java.base/share/classes/java/io/ObjectStreamField.java line 179:

> 177:      * Returns character encoding of field type.  The encoding is as follows:
> 178:      * {@snippet lang=java :
> 179:      *     B            byte

This is even less Java code. I don't think that snippet is appropriate here.

src/java.base/share/classes/java/io/RandomAccessFile.java line 904:

> 902:      * {@code b7}, and {@code b8,} where:
> 903:      * {@snippet lang=java :
> 904:      *         0 <= b1, b2, b3, b4, b5, b6, b7, b8 <= 255,

Same: this is not Java language syntax. Code or pre tags are fine here, they are not deprecated.

src/java.base/share/classes/java/io/StreamTokenizer.java line 394:

> 392:      * characters:
> 393:      * {@snippet lang=java :
> 394:      *         0 1 2 3 4 5 6 7 8 9 . -

But Java as well

src/java.base/share/classes/java/io/StreamTokenizer.java line 774:

> 772:      *
> 773:      * {@snippet lang=java :
> 774:      *         Token['a'], line 10

Also not Java.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193078718
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193078810
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193078975
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193079002
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193079017

From tvaleev at openjdk.org  Sun May 14 05:58:54 2023
From: tvaleev at openjdk.org (Tagir F. Valeev)
Date: Sun, 14 May 2023 05:58:54 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: <6nU_GjadVokt6GDAMNBo1-RUglHvk5eqkdeZwHu2EsY=.5ed4c3b5-a44b-49b9-90e9-c77afb8ffa94@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <J2FEGAKqvuHSrXZsZaKHmD5AwSQsDr5OlHYvltSv_ZY=.b556174f-d8b6-43f4-9690-f4d01eb6603a@github.com>
 <iOi1uN2Paot06qwac9kgaOPDuJxnxO2Lx7HHkqk4UKg=.22146c6c-9471-4806-a109-d0c17a9f9bf7@github.com>
 <6nU_GjadVokt6GDAMNBo1-RUglHvk5eqkdeZwHu2EsY=.5ed4c3b5-a44b-49b9-90e9-c77afb8ffa94@github.com>
Message-ID: <nb3UL06DiOQGeGcJhe6xMek-tmVwijvDIBXnCqKIriQ=.1c0cb146-6a2a-48eb-828d-57506008169b@github.com>

On Fri, 12 May 2023 17:59:32 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I have been just trying to keep it as similar visually as possible but what you say is reasonable.
>
> Agree, that I would make the code valid when using a snippet

There's a replacement tag for this. Some people use label, e.g.

code: // @replace substring="code:" replacement="..."


This way, the snippet remains compilable and rendered the same as before.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193079515

From alanb at openjdk.org  Sun May 14 06:25:47 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 14 May 2023 06:25:47 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>
Message-ID: <FycGtSqdssuXP44EPAvf9HQfxaN79lCatiU49JXgVAQ=.8237c7a6-c558-4fb9-8044-9840288d4d5f@github.com>

On Fri, 12 May 2023 19:02:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308016: Remove ellipses ("...") from snippets

src/java.base/share/classes/java/io/Console.java line 89:

> 87:  * if ((cons = System.console()) != null &&
> 88:  *     (passwd = cons.readPassword("[%s]", "Password:")) != null) {
> 89:  *     ...

I assume you didn't mean to remove this, this is show that there is other code in this block before the passwd is cleared.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193082310

From alanb at openjdk.org  Sun May 14 06:25:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 14 May 2023 06:25:48 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>
 <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com>
Message-ID: <s6F-7Nm9A1b2m7Di4fv68KEC8IvjJo7uHYcJYutKJwQ=.8adf808c-6b1b-4188-b119-240781304efe@github.com>

On Sun, 14 May 2023 05:47:50 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8308016: Remove ellipses ("...") from snippets
>
> src/java.base/share/classes/java/io/FilePermission.java line 1033:
> 
>> 1031:      *
>> 1032:      * {@snippet lang=java :
>> 1033:      *     "/tmp/scratch/foo", "read,write",
> 
> This doesn't look like a valid Java code. This is not even a well-formed expression. I'm not sure whether there are any standard requirements about this (the spec is vague here), but IntelliJ IDEA assumes that the Java snippet is a member, a statement, or an expression. It's likely that parse error will be displayed here in the IDE.

Indeed, maybe a script was used to replace the <pre> </pre> tags, in which case it will checking for other non-code examples.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1193082481

From alanb at openjdk.org  Sun May 14 06:39:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 14 May 2023 06:39:56 GMT
Subject: RFR: 8307547: Support variant collations [v4]
In-Reply-To: <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
 <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>
 <x1shHzMm-4SWbRgVw08cjsCFtBHmu7e6ogs3Rp2Ha1U=.ac71b8ab-835e-4fc6-b327-4911f44d52b8@github.com>
 <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>
Message-ID: <o4wDF2ZONPiqzKZLDKUegFu2zBoGv0tswAfiVpX9BLo=.222e305e-bbf5-4fdb-a9ee-3458ae3919d8@github.com>

On Fri, 12 May 2023 16:41:20 GMT, Steven Loomis <srl at openjdk.org> wrote:

> > so is this considered a private use language tag
> 
> Not private use at all. The `-u-` subtag is registered, and the links above are from the registrar, see
> 
> * https://www.rfc-editor.org/info/bcp47
> * https://www.rfc-editor.org/rfc/rfc6067

Good, I don't think I have any other questions on this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1546821026

From alanb at openjdk.org  Sun May 14 06:39:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 14 May 2023 06:39:55 GMT
Subject: RFR: 8307547: Support variant collations [v4]
In-Reply-To: <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
Message-ID: <o-gceMnFNNkSKKU-jp3B7uNhUDJHcFIXErjMWNhoSgc=.1c8f778a-201c-4652-9498-bd06cd1d5396@github.com>

On Thu, 11 May 2023 20:51:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added "reformed" tests

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13917#pullrequestreview-1425494382

From jwaters at openjdk.org  Sun May 14 12:07:45 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 14 May 2023 12:07:45 GMT
Subject: RFR: 8307163: JLONG_FORMAT_SPECIFIER should be updated on Windows
 [v2]
In-Reply-To: <mnFaRiB8So9CTnN--vpQKXEPjbWNhVVltH_BvzWCBAU=.ee0e4203-0f8b-4dfd-b916-a73994341fc7@github.com>
References: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>
 <mnFaRiB8So9CTnN--vpQKXEPjbWNhVVltH_BvzWCBAU=.ee0e4203-0f8b-4dfd-b916-a73994341fc7@github.com>
Message-ID: <iKOwYt7Xkjpqz86S_NBodSGlKFPmgO9Suqp4G46u4ZA=.6457581f-9977-4ec2-869c-255057323877@github.com>

On Tue, 2 May 2023 12:23:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Windows no longer uses I64d anywhere in their newer compilers, instead using the conforming lld specifiers. Minor cleanup here in JLI code to reflect that
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HotSpot should also use lld instead of I64d

Bumping

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13740#issuecomment-1546884247

From stuefe at openjdk.org  Sun May 14 12:35:44 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 14 May 2023 12:35:44 GMT
Subject: RFR: 8307163: JLONG_FORMAT_SPECIFIER should be updated on Windows
 [v2]
In-Reply-To: <mnFaRiB8So9CTnN--vpQKXEPjbWNhVVltH_BvzWCBAU=.ee0e4203-0f8b-4dfd-b916-a73994341fc7@github.com>
References: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>
 <mnFaRiB8So9CTnN--vpQKXEPjbWNhVVltH_BvzWCBAU=.ee0e4203-0f8b-4dfd-b916-a73994341fc7@github.com>
Message-ID: <rgtuqhSd2HD_POFlU5zwEOYubIEObsrKPuOMAHebGCE=.dae7459e-61a7-4e66-8e99-94404909fffe@github.com>

On Tue, 2 May 2023 12:23:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Windows no longer uses I64d anywhere in their newer compilers, instead using the conforming lld specifiers. Minor cleanup here in JLI code to reflect that
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HotSpot should also use lld instead of I64d

Good

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13740#pullrequestreview-1425543162

From jwaters at openjdk.org  Sun May 14 14:00:52 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Sun, 14 May 2023 14:00:52 GMT
Subject: Integrated: 8307163: JLONG_FORMAT_SPECIFIER should be updated on
 Windows
In-Reply-To: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>
References: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>
Message-ID: <W3t4W64HQwDkFRQ8Bxf9bXK-U7db_fG9Oo7yhkJjoFo=.adfbf84f-c72f-4541-9470-1ecc0d75ccab@github.com>

On Mon, 1 May 2023 16:25:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> Windows no longer uses I64d anywhere in their newer compilers, instead using the conforming lld specifiers. Minor cleanup here in JLI code to reflect that

This pull request has now been integrated.

Changeset: 0ee196be
Author:    Julian Waters <jwaters at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ee196bef199c3d32c1f88b26eb4333a7ea73c10
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8307163: JLONG_FORMAT_SPECIFIER should be updated on Windows

Reviewed-by: stuefe

-------------

PR: https://git.openjdk.org/jdk/pull/13740

From stuefe at openjdk.org  Sun May 14 17:31:52 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sun, 14 May 2023 17:31:52 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <uLba2a2HJ65xG6eU6P_27x_XbbLkFUDLOT5Qn5e4_FU=.f3df44af-6018-4f1f-909e-8c9ce41219ba@github.com>

On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

Trying to understand this, and the scope of the problem:

- Parent process opens "in" pipe. 
- Now owns read and write end of pipe. 
- Parent forks jspawnhelper. 
- jspawnhelper inherits handles. Now there are four open file descriptors to this pipe.
- Parent dies and releases its handles
- jspawnhelper gets thrown out of its first "readFully", but enters the next "readFully". It still owns both read and write end of the pipe. So it will wait endlessly. We only get an EOF from a pipe read when all write ends are closed.

Is this the problem?

I wonder whether the parent may not have the same problem at the other end. It may be prudent to close the child's ends of the three pipes right after calling startChild() (https://github.com/openjdk/jdk/blob/020a60e6449749ca979c1ace3af7db57f4c53a5f/src/java.base/unix/native/libjava/ProcessImpl_md.c#LL681C17-L681C27).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1546954075

From darcy at openjdk.org  Sun May 14 23:07:39 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sun, 14 May 2023 23:07:39 GMT
Subject: RFR: JDK-8308049: Refactor nested class declarations in FdLibm.java
Message-ID: <YmQK9g6fUm0wxEeiHXzmekhjXAp9_durXafWoQlxqhM=.6d8fe081-1409-4c4c-a403-369cfc236650@github.com>

Make the nested classes inside FdLibm.java consistently package-access, static and final.

-------------

Commit messages:
 - JDK-8308049: Refactor nested class declarations in FdLibm.java

Changes: https://git.openjdk.org/jdk/pull/13972/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13972&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308049
  Stats: 17 lines in 1 file changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13972/head:pull/13972

PR: https://git.openjdk.org/jdk/pull/13972

From duke at openjdk.org  Mon May 15 03:05:53 2023
From: duke at openjdk.org (Chang Peng)
Date: Mon, 15 May 2023 03:05:53 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
Message-ID: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>

In Vector API Java level, vector mask is represented as a boolean array with 0x00/0x01 (8 bits of each element) as values, aka in-memory format. When it is loaded into vector register, e.g. Neon, the in-memory format will be converted to in-register format with 0/-1 value for each lane (lane width aligned to its type) by VectorLoadMask [1] operation, and convert back to in-memory format by VectorStoreMask[2]. In Neon, a typical VectorStoreMask operation will first narrow given vector registers by xtn insn [3] into byte element type, and then do a vector negate to convert to 0x00/0x01 value for each element.

For most of the vector mask operations, the input mask is in-register format. And a vector mask also works in-register format all through the compilation. But for some operations like VectorMask.trueCount()[4] which counts the elements of true value, the expected input mask is in-memory format. So a VectorStoreMask is generated to convert the mask from in-register format to in-memory format before those operations.

However, for trueCount() these xtn instructions in VectorStoreMask can be saved, since the narrowing operations will not influence the number of active lane (value of 0x01) of its input.

This patch adds an optimized rule `VectorMaskTrueCount (VectorStoreMask mask)` to save the unnecessary narrowing operations.

For example,


var m = VectorMask.fromArray(IntVector.SPECIES_PREFERRED, ba, 0);
m.not().trueCount();


will produce following assembly on a Neon machine before this patch:


...
mvn     v16.16b, v16.16b           // VectorMask.not()
xtn     v16.4h, v16.4s
xtn     v16.8b, v16.8h
neg     v16.8b, v16.8b             // VectorStoreMask
addv    b17, v16.8b
umov    w0, v17.b[0]               // VectorMask.trueCount()
...


After this patch:


...
mvn     v16.16b, v16.16b           // VectorMask.not()
addv    s17, v16.4s
smov    x0, v17.b[0]
neg     x0, x0                     // Optimized VectorMask.trueCount()
...


In this case, we can save two xtn insns.

Performance:

Benchmark     Before               After                          Unit
testInt           723.822 ? 1.029  1182.375 ? 12.363    ops/ms
testLong       632.154 ? 0.197  1382.74 ? 2.188        ops/ms
testShort      788.665 ? 1.852   1152.38 ? 3.77         ops/ms

[1]: https://github.com/openjdk/jdk/blob/e1e758a7b43c29840296d337bd2f0213ab0ca3c9/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4740
[2]: https://github.com/openjdk/jdk/blob/f968da97a5a5c68c28ad29d13fdfbe3a4adf5ef7/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4841
[3]: https://developer.arm.com/documentation/dui0801/h/A64-SIMD-Vector-Instructions/XTN--XTN2--vector-
[4]: https://docs.oracle.com/en/java/javase/16/docs/api/jdk.incubator.vector/jdk/incubator/vector/VectorMask.html#trueCount()

-------------

Commit messages:
 - 8307795: AArch64: Optimize VectorMask.truecount() on Neon

Changes: https://git.openjdk.org/jdk/pull/13974/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13974&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307795
  Stats: 240 lines in 5 files changed: 240 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13974/head:pull/13974

PR: https://git.openjdk.org/jdk/pull/13974

From aturbanov at openjdk.org  Mon May 15 06:41:46 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 15 May 2023 06:41:46 GMT
Subject: RFR: 8305785: Avoid redundant HashMap.containsKey call in
 java.util.regex
In-Reply-To: <_WLYJq0pH0MAmUOuVtCJsRIYvmjtwi_cwW3_Wy341Ks=.17067b05-2a67-49f8-b167-6b2404165ae5@github.com>
References: <_WLYJq0pH0MAmUOuVtCJsRIYvmjtwi_cwW3_Wy341Ks=.17067b05-2a67-49f8-b167-6b2404165ae5@github.com>
Message-ID: <GNYR-lvtHTJs_RieaGGIOsuQWt86BA-WxyHZvueP8Fs=.d0d13592-9818-4362-88cb-1ec0ce0580b5@github.com>

On Mon, 3 Apr 2023 16:58:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Pattern.namedGroups` and `Matcher.namedGroups` contains only non-null values. It means instead of separate `containsKey`+`get` calls, we can use single `HashMap.get` call and then compare result with null.
> Result code is a bit simpler and faster.

Not yet bot. Still hope to get review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13303#issuecomment-1547272862

From stsypanov at openjdk.org  Mon May 15 07:19:45 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 15 May 2023 07:19:45 GMT
Subject: RFR: 8305785: Avoid redundant HashMap.containsKey call in
 java.util.regex
In-Reply-To: <_WLYJq0pH0MAmUOuVtCJsRIYvmjtwi_cwW3_Wy341Ks=.17067b05-2a67-49f8-b167-6b2404165ae5@github.com>
References: <_WLYJq0pH0MAmUOuVtCJsRIYvmjtwi_cwW3_Wy341Ks=.17067b05-2a67-49f8-b167-6b2404165ae5@github.com>
Message-ID: <WLVkK49hVzhvvIoG0Hg7cGig1AeSC-LzqVoqoadzxCs=.75469e4c-e276-4602-aebe-b8fbbaf6c445@github.com>

On Mon, 3 Apr 2023 16:58:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Pattern.namedGroups` and `Matcher.namedGroups` contains only non-null values. It means instead of separate `containsKey`+`get` calls, we can use single `HashMap.get` call and then compare result with null.
> Result code is a bit simpler and faster.

I think with my approve you can integrate this PR

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13303#issuecomment-1547315305

From alanb at openjdk.org  Mon May 15 07:52:05 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 May 2023 07:52:05 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
Message-ID: <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>

On Thu, 11 May 2023 11:25:51 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update VirtualParser.java

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 35:

> 33: public class MainMethodFinder {
> 34:     private static boolean isPrivate(Method method) {
> 35:         return method != null && Modifier.isPrivate(method.getModifiers());

Are you sure you want to allow null here? It seems like it's a bug in the caller if that happens.

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 38:

> 36:     }
> 37: 
> 38:     private static boolean isPublic(Method method) {

Is this left over from a previous iteration, it doesn't seem to be used.

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 53:

> 51: 
> 52:     /**
> 53:      * Gather all the "main" methods in the class heirarchy.

heirarchy -> hierarchy

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 134:

> 132: 
> 133:     /**
> 134:      * {@return priority main method or null if none found}

"or null if none found", is that out of date?

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 146:

> 144: 
> 145:             if (Modifier.isStatic(mods) && mainMethod.getDeclaringClass() != mainClass) {
> 146:                 System.err.println("WARNING: static main in super class will be deprecated.");

I thought that JEP 445 was deprecating this, in which case the text should be "is deprecated" rather than "will be".

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 156:

> 154: 
> 155:             List<Method> mains = new ArrayList<>();
> 156:             gatherMains(mainClass, mainClass, mains);

Instead of gatherMains, did you consider first looking for static main(String[], then static main()? Asking because I expected to only see the walk up the hierarchy when looking for an instance main.

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 162:

> 160:             }
> 161: 
> 162:             if (1 < mains.size()) {

Checking if mains.size() > 1 might be easier on the eyes.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 872:

> 870: 
> 871:     // Check the existence and signature of main and abort if incorrect
> 872:     public static void validateMainClass(Class<?> mainClass) {

Is there a reason that this is changed to public, maybe left over from a previous iteration?

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 896:

> 894:          * findMainMethod (above) will choose the correct method, based
> 895:          * on its name and parameter type, however, we still have to
> 896:          * ensure that the method is static (non-preview) and returns a void.

Have you looked into findMainMethod checking the return type? Right now, we have findMainMethod returning a Method that needs further checking.

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 904:

> 902: 
> 903:         if (!PreviewFeatures.isEnabled()) {
> 904:             if (!isStatic || !isPublic || noArgs) {

You can use && here and avoid the nested if.

test/jdk/tools/launcher/InstanceMainTest.java line 31:

> 29:  * @run main InstanceMainTest
> 30:  */
> 31: public class InstanceMainTest extends TestHelper {

Are you planning to add tests for the selection/precedence order?

Also wondering if we need a test to check that there is a warning when the main method in found in the super class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193379090
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193378248
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193379468
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193415367
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193385008
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193440438
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193419331
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193444639
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193455653
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193443762
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1193390566

From amitkumar at openjdk.org  Mon May 15 08:32:50 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Mon, 15 May 2023 08:32:50 GMT
Subject: RFR: 8278411: Implement UseHeavyMonitors consistently, s390 port
Message-ID: <COmFoLKTTH7QjLxUHkYBVglvbN9dWzMRsQERKpUkbXI=.a63da954-6ecf-4ea3-8358-47e95fab3356@github.com>

This PR make s390x to adapt the changes done in [JDK-8276901](https://bugs.openjdk.org/browse/JDK-8276901) OR implements UseHeavyMonitors. 

[JDK-8291555](https://bugs.openjdk.org/browse/JDK-8291555) still needs Porting effort. As for `LM_LIGHTWEIGHT` locking mode, code is Unimplemented.

-------------

Commit messages:
 - s390x Port

Changes: https://git.openjdk.org/jdk/pull/13978/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13978&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8278411
  Stats: 97 lines in 5 files changed: 25 ins; 1 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/13978.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13978/head:pull/13978

PR: https://git.openjdk.org/jdk/pull/13978

From asotona at openjdk.org  Mon May 15 08:47:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 15 May 2023 08:47:02 GMT
Subject: RFR: 8307326: Package jdk.internal.classfile.java.lang.constant become
 obsolete
Message-ID: <B7NPhT_4RixzCii1LIEVkwMrP6qNASaeOQ9Y2v9lPhk=.f9f9ca1e-9b8b-4b73-ad73-d882e35956db@github.com>

Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). 
All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and  `java.lang.constant.PackageDesc`. 
`jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. 
Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted.
Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed:
- `PackageDesc::packageName` to `PackageDesc::name`
- `PackageDesc::packageInternalName` to `PackageDesc::internalName`
- `ModuleDesc::moduleName` to `ModuleDesc::name`.

Please review this pull request.

Thanks,
Adam

-------------

Commit messages:
 - 8307326: Package jdk.internal.classfile.java.lang.constant become obsolete

Changes: https://git.openjdk.org/jdk/pull/13979/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13979&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307326
  Stats: 503 lines in 46 files changed: 0 ins; 446 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/13979.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13979/head:pull/13979

PR: https://git.openjdk.org/jdk/pull/13979

From aph at openjdk.org  Mon May 15 09:00:50 2023
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 15 May 2023 09:00:50 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
In-Reply-To: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
Message-ID: <4hN6zn1gNhhXUIKHPlKhqqVolJkX-Hcrp2SgvI6zcU0=.9ecce499-66a2-41fa-be6e-93ed7615e02d@github.com>

On Mon, 15 May 2023 02:58:46 GMT, Chang Peng <duke at openjdk.org> wrote:

> In Vector API Java level, vector mask is represented as a boolean array with 0x00/0x01 (8 bits of each element) as values, aka in-memory format. When it is loaded into vector register, e.g. Neon, the in-memory format will be converted to in-register format with 0/-1 value for each lane (lane width aligned to its type) by VectorLoadMask [1] operation, and convert back to in-memory format by VectorStoreMask[2]. In Neon, a typical VectorStoreMask operation will first narrow given vector registers by xtn insn [3] into byte element type, and then do a vector negate to convert to 0x00/0x01 value for each element.
> 
> For most of the vector mask operations, the input mask is in-register format. And a vector mask also works in-register format all through the compilation. But for some operations like VectorMask.trueCount()[4] which counts the elements of true value, the expected input mask is in-memory format. So a VectorStoreMask is generated to convert the mask from in-register format to in-memory format before those operations.
> 
> However, for trueCount() these xtn instructions in VectorStoreMask can be saved, since the narrowing operations will not influence the number of active lane (value of 0x01) of its input.
> 
> This patch adds an optimized rule `VectorMaskTrueCount (VectorStoreMask mask)` to save the unnecessary narrowing operations.
> 
> For example,
> 
> 
> var m = VectorMask.fromArray(IntVector.SPECIES_PREFERRED, ba, 0);
> m.not().trueCount();
> 
> 
> will produce following assembly on a Neon machine before this patch:
> 
> 
> ...
> mvn     v16.16b, v16.16b           // VectorMask.not()
> xtn     v16.4h, v16.4s
> xtn     v16.8b, v16.8h
> neg     v16.8b, v16.8b             // VectorStoreMask
> addv    b17, v16.8b
> umov    w0, v17.b[0]               // VectorMask.trueCount()
> ...
> 
> 
> After this patch:
> 
> 
> ...
> mvn     v16.16b, v16.16b           // VectorMask.not()
> addv    s17, v16.4s
> smov    x0, v17.b[0]
> neg     x0, x0                     // Optimized VectorMask.trueCount()
> ...
> 
> 
> In this case, we can save two xtn insns.
> 
> Performance:
> 
> Benchmark     Before               After                          Unit
> testInt           723.822 ? 1.029  1182.375 ? 12.363    ops/ms
> testLong       632.154 ? 0.197  1382.74 ? 2.188        ops/ms
> testShort      788.665 ? 1.852   1152.38 ? 3.77         ops/ms
> 
> [1]: https://github.com/openjdk/jdk/blob/e1e758a7b43c29840296d337bd2f0213ab0ca3c9/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4740
> [2]: https://github.com/openjdk/jdk/b...

That makes sense. Is it likely that there are more of these combined operations on vector masks that could be matched? if so, it might make sense to do the job earlier, in the C2 optimizer.

test/micro/org/openjdk/bench/jdk/incubator/vector/StoreMaskTrueCount.java line 80:

> 78:             m = m.not();
> 79:             res += m.trueCount();
> 80:         }

This looks like it might be removed by loop opts. I think you might need a blackhole somewhere.

-------------

Marked as reviewed by aph (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13974#pullrequestreview-1426088017
PR Review Comment: https://git.openjdk.org/jdk/pull/13974#discussion_r1193540231

From asotona at openjdk.org  Mon May 15 09:06:47 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 15 May 2023 09:06:47 GMT
Subject: RFR: 8306457: Classfile API components implementations should not
 be exposed [v2]
In-Reply-To: <Cx6lfCV6bwkUp5dyRpHOfIJtwg18eoGB1nMQxXQRmv4=.495cdea9-7422-41de-95d4-9e52a8403f5d@github.com>
References: <67PAXfiqaTaU8vYbbA31WJBG029RHK454HIDp5ZlYx8=.ec9b4ddd-fe42-4236-9e44-ef63e164e906@github.com>
 <Cx6lfCV6bwkUp5dyRpHOfIJtwg18eoGB1nMQxXQRmv4=.495cdea9-7422-41de-95d4-9e52a8403f5d@github.com>
Message-ID: <S3LLWyYF8Opon6Pm1Nqg6kdGAHY-t5Bo7ZDTWR2tg6E=.ca62fa43-3315-4160-b11c-5c415f876731@github.com>

On Sat, 13 May 2023 14:11:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The jdk.internal.classfile.components package's interfaces have implementations in their nested classes, which are implicitly public and exported with the package. They are now moved to the impl package to avoid unwanted exposures. Fixed a few minor javadoc issues in the interfaces as well.
>> 
>> In conflict with #13021; one needs updating if the other is merged.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - merge indy remap fix
>  - Merge branch 'master' into fix/hide-component-impl
>  - 8306457: Classfile API components implementations should not be exposed

I would prefer to keep formatting when moving large block of code from one source file to another. It is very hard to diff and requires deep review otherwise.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13541#pullrequestreview-1426101972

From dholmes at openjdk.org  Mon May 15 09:07:58 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 15 May 2023 09:07:58 GMT
Subject: RFR: 8307163: JLONG_FORMAT_SPECIFIER should be updated on Windows
 [v2]
In-Reply-To: <mnFaRiB8So9CTnN--vpQKXEPjbWNhVVltH_BvzWCBAU=.ee0e4203-0f8b-4dfd-b916-a73994341fc7@github.com>
References: <iWEm-n8K9iRlj3yJFmU-YG6fPLk0iRzbifCI8ES6EZ8=.bd103110-8006-4293-b564-9e7325bc38b0@github.com>
 <mnFaRiB8So9CTnN--vpQKXEPjbWNhVVltH_BvzWCBAU=.ee0e4203-0f8b-4dfd-b916-a73994341fc7@github.com>
Message-ID: <rl1PnlMQEICW5gHcwUxyMm_lowCkycyavlFEukDFFto=.17983d2a-4c4c-455d-8e89-8ce633ffa2f6@github.com>

On Tue, 2 May 2023 12:23:23 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> Windows no longer uses I64d anywhere in their newer compilers, instead using the conforming lld specifiers. Minor cleanup here in JLI code to reflect that
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   HotSpot should also use lld instead of I64d

Belated okay.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13740#pullrequestreview-1426103506

From duke at openjdk.org  Mon May 15 09:17:46 2023
From: duke at openjdk.org (Chang Peng)
Date: Mon, 15 May 2023 09:17:46 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
In-Reply-To: <4hN6zn1gNhhXUIKHPlKhqqVolJkX-Hcrp2SgvI6zcU0=.9ecce499-66a2-41fa-be6e-93ed7615e02d@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
 <4hN6zn1gNhhXUIKHPlKhqqVolJkX-Hcrp2SgvI6zcU0=.9ecce499-66a2-41fa-be6e-93ed7615e02d@github.com>
Message-ID: <-m588oeb-3gdCctnn2qYLjqrICZREj2URSICtml_PMA=.3de2fd7e-5570-44c4-853f-028ee7af1f9e@github.com>

On Mon, 15 May 2023 08:56:37 GMT, Andrew Haley <aph at openjdk.org> wrote:

> That makes sense. Is it likely that there are more of these combined operations on vector masks that could be matched? if so, it might make sense to do the job earlier, in the C2 optimizer.

Thanks for your review.

I have tried to optimize ```VectorMask.firstTrue()``` [1] and ```VectorMask.lastTrue()``` [2] in the same way as this patch, but these two operations are strong correlated with xtn, we cannot simply remove it.

I didn't find a way to optimize these two operations, they are hignly optimized in C2 backend and there are not extra instructions.

[1]: https://github.com/openjdk/jdk/blob/8d49ba9e8d3095f850b3007b56488a0c0cf8ddff/src/hotspot/cpu/aarch64/aarch64_vector.ad#L5517
[2]: https://github.com/openjdk/jdk/blob/8d49ba9e8d3095f850b3007b56488a0c0cf8ddff/src/hotspot/cpu/aarch64/aarch64_vector.ad#L5624

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13974#issuecomment-1547484838

From asotona at openjdk.org  Mon May 15 10:03:50 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 15 May 2023 10:03:50 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v4]
In-Reply-To: <4pL9To1n8Gbf1EdM50d87Xk8nu0Ou_nAFONKBzaH1OQ=.103c7aae-dec8-409a-ace4-0f9b0d04d662@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <44odsoRkRp6mmgfPKFCPOy-uaHNOgOgPQUJICERzHKU=.5703da5a-0e66-45a2-af0b-23ac0665fbe7@github.com>
 <4pL9To1n8Gbf1EdM50d87Xk8nu0Ou_nAFONKBzaH1OQ=.103c7aae-dec8-409a-ace4-0f9b0d04d662@github.com>
Message-ID: <9BNd29VILVE6pX4HEVoIiFKPEyWxtph3lb-kWfgjGCA=.5e6e8241-fa27-495f-b398-d9b5d0be9faf@github.com>

On Fri, 12 May 2023 13:19:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed jmh benchmark parameters
>
> test/micro/org/openjdk/bench/jdk/classfile/RebuildMethodBodies.java line 57:
> 
>> 55:     public void setup() throws IOException {
>> 56:         shared = new LinkedList<>();
>> 57:         unshared = new LinkedList<>();
> 
> LinkedList should be replaced by ArrayList, as:
> 1. LinkedList's node wrapper around each object is too heavy, ArrayList has smaller wrapper
> 2. LinkedList iteration needs to follow links while ArrayList access can be machine optimized
> 3. ArrayList addition is amortized O(1), not really worse than LinkedList additions.

Construction size is irrelevant here as each node holds the whole expanded `ClassModel` instances.
`LinkedList` iterator `next` speed is O(1) and possible `AraryList` optimisations of the test data iterator have no effect on this benchmark. 
Construction speed of `ArrayList` is not O(1) when the `grow` method is called, however it is also irrelevant as this is unmeasured setup part of the benchmark.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1193614917

From duke at openjdk.org  Mon May 15 10:06:47 2023
From: duke at openjdk.org (Chang Peng)
Date: Mon, 15 May 2023 10:06:47 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
In-Reply-To: <4hN6zn1gNhhXUIKHPlKhqqVolJkX-Hcrp2SgvI6zcU0=.9ecce499-66a2-41fa-be6e-93ed7615e02d@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
 <4hN6zn1gNhhXUIKHPlKhqqVolJkX-Hcrp2SgvI6zcU0=.9ecce499-66a2-41fa-be6e-93ed7615e02d@github.com>
Message-ID: <5NfBPdiTQS9KBSWSgJSjfwW_IT7UdKwi__REZAvtxo4=.35641a45-6e4d-4b8a-865f-76784e7cc173@github.com>

On Mon, 15 May 2023 08:57:30 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This looks like it might be removed by loop opts. I think you might need a blackhole somewhere.

```m``` will be updated in every iteration of this loop, so ```m``` is not a loop-invariants actually.
I can see the assembly code of this loop by using JMH perfasm.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13974#discussion_r1193618375

From rgiulietti at openjdk.org  Mon May 15 10:10:44 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 15 May 2023 10:10:44 GMT
Subject: RFR: JDK-8308049: Refactor nested class declarations in
 FdLibm.java
In-Reply-To: <YmQK9g6fUm0wxEeiHXzmekhjXAp9_durXafWoQlxqhM=.6d8fe081-1409-4c4c-a403-369cfc236650@github.com>
References: <YmQK9g6fUm0wxEeiHXzmekhjXAp9_durXafWoQlxqhM=.6d8fe081-1409-4c4c-a403-369cfc236650@github.com>
Message-ID: <jtYyoZS7eqtdQhsP3y1SWBNJ3fWa8K_wrq1yatEOHUs=.6f0abd21-7638-45b5-99d4-0ca1a5981d63@github.com>

On Sun, 14 May 2023 23:00:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Make the nested classes inside FdLibm.java consistently package-access, static and final.

LGTM

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13972#issuecomment-1547571116

From aph at openjdk.org  Mon May 15 11:01:44 2023
From: aph at openjdk.org (Andrew Haley)
Date: Mon, 15 May 2023 11:01:44 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
In-Reply-To: <5NfBPdiTQS9KBSWSgJSjfwW_IT7UdKwi__REZAvtxo4=.35641a45-6e4d-4b8a-865f-76784e7cc173@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
 <4hN6zn1gNhhXUIKHPlKhqqVolJkX-Hcrp2SgvI6zcU0=.9ecce499-66a2-41fa-be6e-93ed7615e02d@github.com>
 <5NfBPdiTQS9KBSWSgJSjfwW_IT7UdKwi__REZAvtxo4=.35641a45-6e4d-4b8a-865f-76784e7cc173@github.com>
Message-ID: <sLSOr9OkNNZAreg3bIp_R0vcO7XosgN2N3AmAvH0ogw=.bb99445f-5e83-440d-94d5-f81053628e04@github.com>

On Mon, 15 May 2023 10:04:22 GMT, Chang Peng <duke at openjdk.org> wrote:

> > This looks like it might be removed by loop opts. I think you might need a blackhole somewhere.
> 
> `m` will be updated in every iteration of this loop, so `m` is not a loop-invariants actually. I can see the assembly code of this loop by using JMH perfasm.

Isn't it? Looks to me like all it does is flip `m` each time. Whether or not this code is optimized today isn't relevant.

So it's the same as


        for (int i = 0; i < LENGTH/2; i++) {
            res += m.trueCount();
        }
        m = m.not();
        for (int i = 0; i < LENGTH/2; i++) {
            res += m.trueCount();
        } 


... which is trivially optimizable, no?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13974#discussion_r1193674595

From rgiulietti at openjdk.org  Mon May 15 12:33:50 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 15 May 2023 12:33:50 GMT
Subject: RFR: 8302204: Optimize BigDecimal.divide [v2]
In-Reply-To: <RmxcdUCqazQtulk5M7nAuwuwGPHcsILq_y2cYSUJliw=.0806795b-00ed-434c-beae-f301b293729b@github.com>
References: <rUC0Dh_-1E0PZNJwM0GRH1KPu6prPotT-oeDTUdqjI4=.a8f7d3b7-a0f2-45a0-ae01-f37ef108d18f@github.com>
 <RmxcdUCqazQtulk5M7nAuwuwGPHcsILq_y2cYSUJliw=.0806795b-00ed-434c-beae-f301b293729b@github.com>
Message-ID: <dYtOe3hUGgonNDLBJBPgnP7YyLnfv3ia5YMFjlyl4Ns=.095aee2e-5d87-49a2-a903-7e3a94077193@github.com>

On Fri, 17 Feb 2023 04:43:00 GMT, Xiaowei Lu <duke at openjdk.org> wrote:

>> [JDK-8269667](https://bugs.openjdk.org/browse/JDK-8269667) has uncovered the poor performance of BigDecimal.divide under certain circumstance.
>> 
>> We confront similar situations when benchmarking Spark3 on TPC-DS test kit. According to the flame-graph below, it is StripZeros that spends most of the time of BigDecimal.divide. Hence we propose this patch to optimize stripping zeros.
>> ![?? 1](https://user-images.githubusercontent.com/39413832/218062061-53cd0220-776e-4b72-8b9a-6b0f11707986.png)
>> 
>> Currently, createAndStripZerosToMatchScale() is performed linearly. That is, the target value is parsed from back to front, each time stripping out single ?0?. To optimize, we can adopt the method of binary search. That is, each time we try to strip out ${scale/2} ?0?s. 
>> 
>> The performance looks good. Therotically, time complexity of our method is O(log n), while the current one is O(n). In practice, benchmarks on Spark3 show that 1/3 less time (102s->68s) is spent on TPC-DS query4. We also runs Jtreg and JCK to check correctness, and it seems fine.
>> 
>> More about environment: 
>> we run Spark3.3.0 on Openjdk11, but it seems jdk version doesn?t have much impact on BigDecimal. Spark cluster consists of a main node and 2 core nodes, each has 4cores, 16g memory and 4x500GB storage.
>
> Xiaowei Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   check lowest n bits instead of single one

src/java.base/share/classes/java/math/BigDecimal.java line 4950:

> 4948:                 && scale > preferredScale) {
> 4949:             scaleStep = checkScale(intVal, Math.max(((long) scale - preferredScale) / 2, 1));
> 4950:             if (intVal.getLowestSetBit() >= scaleStep) {

I think there's no need to recompute `intVal.getLowestSetBit()` at each iteration.
If you store the original one in an `int` variable `lsb` initialized upon entry in the method, then you can simply compute `lsb -= scaleStep` at each iteration. It can become negative, but that shouldn't be a problem.

What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12509#discussion_r1193767163

From simonis at openjdk.org  Mon May 15 12:34:44 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 15 May 2023 12:34:44 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <5umr1RZubaebgzhwponiJ1NnVgXh0Ruvlw0vLDo6_1g=.79197765-4fa2-4185-85df-df62b506ded5@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <5umr1RZubaebgzhwponiJ1NnVgXh0Ruvlw0vLDo6_1g=.79197765-4fa2-4185-85df-df62b506ded5@github.com>
Message-ID: <6fdnGucXySFf8qBEuWkoIRpL8yAqltK1ZNCvKB_nsWI=.38111a07-2a2b-449e-b427-14a58cd2846a@github.com>

On Fri, 12 May 2023 21:37:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Looks ok.
> 
> Is it practical to write a test for this situation? Can I assume you've validated the improvement as a remedy for the observed hangs?

I thought about a test but couldn't come up with a practical way to write it. The JVM has to exit in the time frame after the `posix_spawn()` and before `jspawnhelper` has read its data from the parent. In production this usually happens due to memory constraints on the particular host which let the OOM-killer kill the JVM process because it is the biggest memory consumer.

The production issue could be mitigated by going back to using vfork (i.e. `-Djdk.lang.Process.launchMechanism=VFORK`). I could locally reproduce the problem manually in gdb and with the help of a small C program. I've verified that the proposed change of closing the child's write end of the pipe fixes the problem both in the small C example as well as in the JDK if the issue is reproduced manually in gdb.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1547777042

From simonis at openjdk.org  Mon May 15 13:01:47 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 15 May 2023 13:01:47 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <uLba2a2HJ65xG6eU6P_27x_XbbLkFUDLOT5Qn5e4_FU=.f3df44af-6018-4f1f-909e-8c9ce41219ba@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <uLba2a2HJ65xG6eU6P_27x_XbbLkFUDLOT5Qn5e4_FU=.f3df44af-6018-4f1f-909e-8c9ce41219ba@github.com>
Message-ID: <Q65tjNLTYLwoGeLEKjtQKgrqHFcpJC6_A106vdbvVYs=.29a3bad4-cf72-4fbd-bfea-e6762ba82532@github.com>

On Sun, 14 May 2023 17:28:33 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trying to understand this, and the scope of the problem:
> 
>     * Parent process opens "in" pipe.
> 
>     * Now owns read and write end of pipe.
> 
>     * Parent forks jspawnhelper.
> 
>     * jspawnhelper inherits handles. Now there are four open file descriptors to this pipe.
> 
>     * Parent dies and releases its handles
> 
>     * jspawnhelper gets thrown out of its first "readFully", but enters the next "readFully". It still owns both read and write end of the pipe. So it will wait endlessly. We only get an EOF from a pipe read when all write ends are closed.
> 
> Is this the problem? 

Exactly, except that `jspawnhelper` doesn't even gets "thrown out" of the first `readFully()` it is waiting in, as long as there's an open write end for that pipe.

> I wonder whether the parent may not have the same problem at the other end. It may be prudent to close the child's ends of the three pipes right after calling startChild() (https://github.com/openjdk/jdk/blob/020a60e6449749ca979c1ace3af7db57f4c53a5f/src/java.base/unix/native/libjava/ProcessImpl_md.c#LL681C17-L681C27).

But the parent first only reads from `fail[0]` (both, the keep-alive message as well as the EOF on a successfull `execvp()`). And it already closes its write end of that pipe before doing the first read, see:  https://github.com/openjdk/jdk/blob/020a60e6449749ca979c1ace3af7db57f4c53a5f/src/java.base/unix/native/libjava/ProcessImpl_md.c#L698

Once it made sure the child process was executed, it also closes the corresponding ends of the in/out/err pipes which connect it with the child process (see https://github.com/openjdk/jdk/blob/020a60e6449749ca979c1ace3af7db57f4c53a5f/src/java.base/unix/native/libjava/ProcessImpl_md.c#L738-L740).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1547811575

From erikj at openjdk.org  Mon May 15 13:20:47 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 15 May 2023 13:20:47 GMT
Subject: RFR: 8307326: Package jdk.internal.classfile.java.lang.constant
 become obsolete
In-Reply-To: <B7NPhT_4RixzCii1LIEVkwMrP6qNASaeOQ9Y2v9lPhk=.f9f9ca1e-9b8b-4b73-ad73-d882e35956db@github.com>
References: <B7NPhT_4RixzCii1LIEVkwMrP6qNASaeOQ9Y2v9lPhk=.f9f9ca1e-9b8b-4b73-ad73-d882e35956db@github.com>
Message-ID: <er5mBWPE5TDhZV4lq-AuBaWoSp7RzsHiOC3NJ2TcXag=.6c9b1325-d46e-4934-96ae-4e73e22e405e@github.com>

On Mon, 15 May 2023 08:38:54 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). 
> All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and  `java.lang.constant.PackageDesc`. 
> `jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. 
> Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted.
> Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed:
> - `PackageDesc::packageName` to `PackageDesc::name`
> - `PackageDesc::packageInternalName` to `PackageDesc::internalName`
> - `ModuleDesc::moduleName` to `ModuleDesc::name`.
> 
> Please review this pull request.
> 
> Thanks,
> Adam

Build changes look ok.

-------------

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13979#pullrequestreview-1426543240

From redestad at openjdk.org  Mon May 15 13:44:58 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 15 May 2023 13:44:58 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v4]
In-Reply-To: <4pL9To1n8Gbf1EdM50d87Xk8nu0Ou_nAFONKBzaH1OQ=.103c7aae-dec8-409a-ace4-0f9b0d04d662@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <44odsoRkRp6mmgfPKFCPOy-uaHNOgOgPQUJICERzHKU=.5703da5a-0e66-45a2-af0b-23ac0665fbe7@github.com>
 <4pL9To1n8Gbf1EdM50d87Xk8nu0Ou_nAFONKBzaH1OQ=.103c7aae-dec8-409a-ace4-0f9b0d04d662@github.com>
Message-ID: <bSD9UKkMFM-uEyD3NfuULXdog22l3_MPIzgL298A8Xk=.84ac7458-6747-457f-bb93-7aa574e8d623@github.com>

On Fri, 12 May 2023 13:19:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed jmh benchmark parameters
>
> test/micro/org/openjdk/bench/jdk/classfile/RebuildMethodBodies.java line 57:
> 
>> 55:     public void setup() throws IOException {
>> 56:         shared = new LinkedList<>();
>> 57:         unshared = new LinkedList<>();
> 
> LinkedList should be replaced by ArrayList, as:
> 1. LinkedList's node wrapper around each object is too heavy, ArrayList has smaller wrapper
> 2. LinkedList iteration needs to follow links while ArrayList access can be machine optimized
> 3. ArrayList addition is amortized O(1), not really worse than LinkedList additions.

I have to side with @liach here: `LinkedList` iteration is significantly slower than `ArrayList` even though the computational complexity is identical. Often by an integer factor. This is due to the sparseness of the linked list data structure on heap and the pointer chasing that entails.  

For minimum overhead of iteration over an immutable list then turning the list into an immutable via `List.copyOf` might be preferable due the JVM's ability to optimize over `@Stable` arrays.

Adhoc [JMH benchmark](https://gist.github.com/cl4es/1f21812241c47f32a9deaffcc996e8b3):


Benchmark                            Mode  Cnt    Score    Error   Units
ListIteration.iterateArrayList      thrpt   15  188,724 ? 10,903  ops/ms
ListIteration.iterateImmutableList  thrpt   15  230,901 ?  6,513  ops/ms
ListIteration.iterateLinkedList     thrpt   15   58,289 ?  0,497  ops/ms


Is it important to fix this? Perhaps not, but in a microbenchmark like this the fewer cycles we spend on "stuff" that isn't really part of the thing we're testing, the better. Increasingly so as the thing we're testing is getting more and more optimized.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1193858864

From asotona at openjdk.org  Mon May 15 14:36:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 15 May 2023 14:36:48 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v4]
In-Reply-To: <bSD9UKkMFM-uEyD3NfuULXdog22l3_MPIzgL298A8Xk=.84ac7458-6747-457f-bb93-7aa574e8d623@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <44odsoRkRp6mmgfPKFCPOy-uaHNOgOgPQUJICERzHKU=.5703da5a-0e66-45a2-af0b-23ac0665fbe7@github.com>
 <4pL9To1n8Gbf1EdM50d87Xk8nu0Ou_nAFONKBzaH1OQ=.103c7aae-dec8-409a-ace4-0f9b0d04d662@github.com>
 <bSD9UKkMFM-uEyD3NfuULXdog22l3_MPIzgL298A8Xk=.84ac7458-6747-457f-bb93-7aa574e8d623@github.com>
Message-ID: <nPB2iFEwbB5OfnC0b3ZcDl0zU8Fb1s7IzxiKSnmBt0E=.034f2f41-dd27-4e9b-bd32-98867b932bde@github.com>

On Mon, 15 May 2023 13:42:05 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/jdk/classfile/RebuildMethodBodies.java line 57:
>> 
>>> 55:     public void setup() throws IOException {
>>> 56:         shared = new LinkedList<>();
>>> 57:         unshared = new LinkedList<>();
>> 
>> LinkedList should be replaced by ArrayList, as:
>> 1. LinkedList's node wrapper around each object is too heavy, ArrayList has smaller wrapper
>> 2. LinkedList iteration needs to follow links while ArrayList access can be machine optimized
>> 3. ArrayList addition is amortized O(1), not really worse than LinkedList additions.
>
> I have to side with @liach here: `LinkedList` iteration is significantly slower than `ArrayList` even though the computational complexity is identical. Often by an integer factor. This is due to the sparseness of the linked list data structure on heap and the pointer chasing that entails.  
> 
> For minimum overhead of iteration over an immutable list then turning the list into an immutable via `List.copyOf` might be preferable due the JVM's ability to optimize over `@Stable` arrays.
> 
> Adhoc [JMH benchmark](https://gist.github.com/cl4es/1f21812241c47f32a9deaffcc996e8b3):
> 
> 
> Benchmark                            Mode  Cnt    Score    Error   Units
> ListIteration.iterateArrayList      thrpt   15  188,724 ? 10,903  ops/ms
> ListIteration.iterateImmutableList  thrpt   15  230,901 ?  6,513  ops/ms
> ListIteration.iterateLinkedList     thrpt   15   58,289 ?  0,497  ops/ms
> 
> 
> Is it important to fix this? Perhaps not, but in a microbenchmark like this the fewer cycles we spend on "stuff" that isn't really part of the thing we're testing, the better. Increasingly so as the thing we're testing is getting more and more optimized.

I'm not questioning performance differences between list implementations. 
The implementation of top level list for this benchmark is irrelevant because ~10ns difference cannot affect ~100?s benchmark run.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1193934410

From stuefe at openjdk.org  Mon May 15 14:39:46 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 15 May 2023 14:39:46 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <8NotrnRUoJ7b62-ZnqctKy6mgBSzGkw-6UWK7ljzF-0=.4f55a7cb-3236-4478-871b-de20cf536878@github.com>

On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

Thank you Volker for the explanations.

Some more notes:
	
1) I think the child should probably close (but without error handling) the *read* end of the fail pipe too *before* sending out the liveness ping.

https://github.com/openjdk/jdk/blob/020a60e6449749ca979c1ace3af7db57f4c53a5f/src/java.base/unix/native/libjava/childproc.c#L335

Because the same problem could arise if the parent were to terminate. Child writes to the pipe, and theoretically could block on a full pipe since it holds open an fd to the read end. I admit this is highly theoretical since the pipe would have to be full for this to happen, and nobody wrote to the pipe yet, and the aliveness ping is just an integer (4 bytes). But to be more correct, and since the fix is so trivial, the fail pipe read end should be closed in the child process before writing to fail pipe.

2) I think you don't actually have to hand in the in-pipe-read-end fd number via command line arg, just to have the child to close it. You could just, in the parent, set the fd to FD_CLOEXEC. Since posix_spawn() exec's the spawn helper, this would close the file descriptor for you. Extending this thought, you could do this with all pipe ends you want to cauterize in the child process.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1547994614

From asotona at openjdk.org  Mon May 15 14:48:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 15 May 2023 14:48:58 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v5]
In-Reply-To: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
Message-ID: <LvWUa88NeY3eHAfFZtPWSS9G-7L8Lx3Nv9clEhWbHy0=.6697f05a-908e-4ea9-b305-487fcb17da24@github.com>

> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
> - Caching `MethodTypeDesc` in `MethodInfo` implementations
> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
> 
> No API change.
> 
> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
> 
> 
> Benchmark                     Mode  Cnt       Score       Error  Units
> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
> 
> 
> 
> Benchmark                     Mode  Cnt       Score      Error  Units
> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s

Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:

 - changed LinkedList to ArrayList in RebuildMethodBodies benchmark
 - added RepeatedModelTraversal JMH benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13671/files
  - new: https://git.openjdk.org/jdk/pull/13671/files/3cbb11c2..3b299727

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13671&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13671&range=03-04

  Stats: 74 lines in 2 files changed: 71 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13671.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13671/head:pull/13671

PR: https://git.openjdk.org/jdk/pull/13671

From simonis at openjdk.org  Mon May 15 15:13:49 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 15 May 2023 15:13:49 GMT
Subject: RFR: 8307403: java/util/zip/DeInflate.java timed out
In-Reply-To: <iZKgjHKUrExpgjmD0nD7lBjTHEy5zW_NbRExhnoxkgk=.0cf03734-bcca-422a-9b52-87ae70881527@github.com>
References: <iZKgjHKUrExpgjmD0nD7lBjTHEy5zW_NbRExhnoxkgk=.0cf03734-bcca-422a-9b52-87ae70881527@github.com>
Message-ID: <xAyjKkvdpJQk4nP93zcG9MMrquaIiI7Fih8mgJPxlUc=.dab9531e-1195-414c-ae46-cafd67ee2228@github.com>

On Fri, 12 May 2023 12:47:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8307403?
> 
> When we recently did a change in https://bugs.openjdk.org/browse/JDK-8299748, there was a oversight that the `deflate.deflate(tempBuffer)` could potentially end up taking in a zero sized array. That would then mean the loop in which this `deflate` happens, would never exit leading to the test timing out.
> I've added additional details as a comment to the JBS issue https://bugs.openjdk.org/browse/JDK-8307403?focusedCommentId=14581202&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14581202.
> 
> The commit in this PR uses a fixed size temporary buffer, unrelated to the input length, to get past this problem. The use of fixed size here will not re-introduce the original issue which https://bugs.openjdk.org/browse/JDK-8299748 fixed, because unlike previously, this is just a temporary size and we continue to deflate the content into a dynamically growing `ByteArrayOutputStream` till the deflater is "finished".
> 
> Additionally I've added a log message to help debug any future issues in this call.

Looks good except the comment below.

test/jdk/java/util/zip/DeInflate.java line 146:

> 144:         def.finish();
> 145: 
> 146:         try (ByteArrayOutputStream baos = new ByteArrayOutputStream()) {

I don't think this is really required because the `ByteArrayOutputStream` will grow dynamically anyway, even if initialized to zero but for all other cases `len` is probably a better estimation than the default size of `32`. But I leave it up to you if you want to change it back.

-------------

Marked as reviewed by simonis (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13955#pullrequestreview-1426788585
PR Review Comment: https://git.openjdk.org/jdk/pull/13955#discussion_r1193983220

From duke at openjdk.org  Mon May 15 15:51:02 2023
From: duke at openjdk.org (Chris Hennick)
Date: Mon, 15 May 2023 15:51:02 GMT
Subject: RFR: 8284493: Improve computeNextExponential tail performance and
 accuracy [v21]
In-Reply-To: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
References: <3gh4M864NnJhhWbV7CAj6HcmxGnf8SWTC2Q-uqhGe98=.209577f8-d69e-4794-944f-4379beecf2f7@github.com>
Message-ID: <kvMZkYhviynRDKc99xX5jxgFWyX6fH9cXtTnoMhTu1E=.9979a2d4-ec47-4731-a971-41a3ae79e8fe@github.com>

> This PR improves both the worst-case performance of `nextExponential` and `nextGaussian` and the distribution of output at the tails. It fixes the following imperfections:
> 
> * Repeatedly adding DoubleZigguratTables.exponentialX0 to extra causes a rounding error to accumulate at the tail of the distribution (probably starting around `2*exponentialX0 == 0x1.e46eff20739afp3 ~ 15.1`); this PR fixes that by tracking the multiple of exponentialX0 as a long. (This distortion is worst when `x > 0x1.0p56` since in that case, a rounding error means `extra + x == extra`.
> * Reduces several equations using `Math.fma`. (This will almost certainly improve performance, and may or may not improve output distribution.)
> * Uses the newly-extracted `computeWinsorizedNextExponential` function to prevent `nextGaussian` from going into the `nextExponential` tail twice.

Chris Hennick has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge remote-tracking branch 'upstream/master' into patch-1
 - Merge remote-tracking branch 'origin/patch-1' into patch-1
 - Merge branch 'master' of https://git.openjdk.org/jdk into patch-1
 - Merge branch 'master' of https://git.openjdk.org/jdk into patch-1
 - Merge branch 'master' into patch-1
 - Update copyright date in RandomNext.java
 - Update copyright date in RandomGeneratorNext.java
 - Update copyright date in RandomGeneratorExponentialGaussian.java
 - Update copyright date in RandomSupport.java
 - Optimize: move some code out of the fast path
 - ... and 10 more: https://git.openjdk.org/jdk/compare/97b2ca3d...1b5656d7

-------------

Changes: https://git.openjdk.org/jdk/pull/8131/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=8131&range=20
  Stats: 144 lines in 4 files changed: 128 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/8131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/8131/head:pull/8131

PR: https://git.openjdk.org/jdk/pull/8131

From stuefe at openjdk.org  Mon May 15 15:51:48 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 15 May 2023 15:51:48 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <6fdnGucXySFf8qBEuWkoIRpL8yAqltK1ZNCvKB_nsWI=.38111a07-2a2b-449e-b427-14a58cd2846a@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <5umr1RZubaebgzhwponiJ1NnVgXh0Ruvlw0vLDo6_1g=.79197765-4fa2-4185-85df-df62b506ded5@github.com>
 <6fdnGucXySFf8qBEuWkoIRpL8yAqltK1ZNCvKB_nsWI=.38111a07-2a2b-449e-b427-14a58cd2846a@github.com>
Message-ID: <FQXfmKx0mlz3xIJcbLq82R7I8SIq_S-nRcwKn6FrxSY=.047b16fc-2783-40ac-98ec-a4e288da5b26@github.com>

On Mon, 15 May 2023 12:31:49 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> > Looks ok.
> > Is it practical to write a test for this situation? Can I assume you've validated the improvement as a remedy for the observed hangs?
> 
> I thought about a test but couldn't come up with a practical way to write it. The JVM has to exit in the time frame after the `posix_spawn()` and before `jspawnhelper` has read its data from the parent. In production this usually happens due to memory constraints on the particular host which let the OOM-killer kill the JVM process because it is the biggest memory consumer.
> 

A regression test would be good.

This can be very simply a runtime switch that kills the parent process at vulnerable times. See my example here:

https://github.com/openjdk/jdk/compare/master...tstuefe:jdk:test-for-parent-premature-death

Using that (KILLTEST=1), I was able to reproduce your problem with the hanging child. Using this to build a jtreg test is not hard.

Cheers, Thomas

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1548113927

From simonis at openjdk.org  Mon May 15 16:14:51 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 15 May 2023 16:14:51 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <CVTdCWXTjp9U0tLdtfLTvfeYTrmG6D6tEyaoAGXXgTA=.e918e4de-b7e0-4c21-be7a-93f5de716311@github.com>

On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

>     1. I think the child should probably close (but without error handling) the _read_ end of the fail pipe too _before_ sending out the liveness ping.
> 
> 
> https://github.com/openjdk/jdk/blob/020a60e6449749ca979c1ace3af7db57f4c53a5f/src/java.base/unix/native/libjava/childproc.c#L335
> 
> Because the same problem could arise if the parent were to terminate. Child writes to the pipe, and theoretically could block on a full pipe since it holds open an fd to the read end. I admit this is highly theoretical since the pipe would have to be full for this to happen, and nobody wrote to the pipe yet, and the aliveness ping is just an integer (4 bytes). But to be more correct, and since the fix is so trivial, the fail pipe read end should be closed in the child process before writing to fail pipe.

I thought about this, but as you said, I think it can not happen as we only write at most two times 4 bytes. Also, if we close the read end of the fail pipe in the child and the parent crashes (i.e. there's no read end at all), we will get a SIGPIPE which we would then have to handle in `jspawnhelper`. In the end, I don't think that's worth it for an event which should never happen (at least not in this PR).

> 
>     2. I think you don't actually have to hand in the in-pipe-read-end fd number via command line arg, just to have the child to close it. You could just, in the parent, set the fd to FD_CLOEXEC. Since posix_spawn() exec's the spawn helper, this would close the file descriptor for you. Extending this thought, you could do this with all pipe ends you want to cauterize in the child process.

I've deliberately not used `FD_CLOEXEC`  because the file descriptor closing code in `childProcess()` is shared by all launch mechanisms. So to make it work, I'd had to reset the corresponding file descriptors to `-1` in the child anyway.

I therefor felt the current fix is smaller, simpler and easier to understand.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1548154907

From simonis at openjdk.org  Mon May 15 16:20:48 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 15 May 2023 16:20:48 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <6-bpZEZIaEj1h1dtl4jenz-7AaxIa1cZukYVgjYmpuw=.8ec57118-7775-4096-80bb-f7d7c4076884@github.com>

On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

> > > Looks ok.
> > > Is it practical to write a test for this situation? Can I assume you've validated the improvement as a remedy for the observed hangs?
> > 
> > 
> > I thought about a test but couldn't come up with a practical way to write it. The JVM has to exit in the time frame after the `posix_spawn()` and before `jspawnhelper` has read its data from the parent. In production this usually happens due to memory constraints on the particular host which let the OOM-killer kill the JVM process because it is the biggest memory consumer.
> 
> A regression test would be good.
> 
> This can be very simply a runtime switch that kills the parent process at vulnerable times. See my example here:
> 
> [master...tstuefe:jdk:test-for-parent-premature-death](https://github.com/openjdk/jdk/compare/master...tstuefe:jdk:test-for-parent-premature-death)
> 
> Using that (KILLTEST=1), I was able to reproduce your problem with the hanging child. Using this to build a jtreg test is not hard.
> 
> Cheers, Thomas

Do you really think it makes sense to add such test code to the native runtime libraries?

I'm not sure. What do others think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1548163835

From naoto at openjdk.org  Mon May 15 16:31:47 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 15 May 2023 16:31:47 GMT
Subject: RFR: 8307547: Support variant collations [v4]
In-Reply-To: <o4wDF2ZONPiqzKZLDKUegFu2zBoGv0tswAfiVpX9BLo=.222e305e-bbf5-4fdb-a9ee-3458ae3919d8@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
 <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>
 <x1shHzMm-4SWbRgVw08cjsCFtBHmu7e6ogs3Rp2Ha1U=.ac71b8ab-835e-4fc6-b327-4911f44d52b8@github.com>
 <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>
 <o4wDF2ZONPiqzKZLDKUegFu2zBoGv0tswAfiVpX9BLo=.222e305e-bbf5-4fdb-a9ee-3458ae3919d8@github.com>
Message-ID: <QWBoHymJtt20dBc3eiDjiBn-WlmWKKl9iqVyp2xmoks=.b9342e6c-d7de-4283-87bf-7b0290dfd868@github.com>

On Sun, 14 May 2023 06:37:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.
>>> 
>>> I think those should go into Oracle JDK's `Supported Locales` document. Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018)
>> 
>> `-u-co` is defined [here](https://www.unicode.org/reports/tr35/#UnicodeCollationIdentifier) (UTS#35) and the keys are in the datafile [here (link to `main` branch!)](https://github.com/unicode-org/cldr/blob/main/common/bcp47/collation.xml) - note the `since=` attribute, these are very stable.
>> 
>> @AlanBateman 
>>> Locale.forLanguageTag supports more than BCP 47 language tag strings
>> 
>> It should still be all valid BCP47 including extensions and private use (such as x-lvalue). 
>> 
>>> so is this considered a private use language tag
>> 
>> Not private use at all. The `-u-` subtag is registered, and the links above are from the registrar, see
>> - https://www.rfc-editor.org/info/bcp47
>> - https://www.rfc-editor.org/rfc/rfc6067
>
>> > so is this considered a private use language tag
>> 
>> Not private use at all. The `-u-` subtag is registered, and the links above are from the registrar, see
>> 
>> * https://www.rfc-editor.org/info/bcp47
>> * https://www.rfc-editor.org/rfc/rfc6067
> 
> Good, I don't think I have any other questions on this now.

Thanks, @AlanBateman for the review.
@srl295 thanks. I found CLDR's collation documents are a bit outdated. Filed an issue here: https://unicode-org.atlassian.net/jira/software/c/projects/CLDR/issues/CLDR-16638

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1548178251

From stuefe at openjdk.org  Mon May 15 16:34:50 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 15 May 2023 16:34:50 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <m-1QliQ0sA8h_mh8BEL0pe01QK_jIRu-o0lgIU-k6_Q=.98348538-0968-48a1-b4c3-64b389608189@github.com>

On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

> > > > Looks ok.
> > > > Is it practical to write a test for this situation? Can I assume you've validated the improvement as a remedy for the observed hangs?
> > > 
> > > 
> > > I thought about a test but couldn't come up with a practical way to write it. The JVM has to exit in the time frame after the `posix_spawn()` and before `jspawnhelper` has read its data from the parent. In production this usually happens due to memory constraints on the particular host which let the OOM-killer kill the JVM process because it is the biggest memory consumer.
> > 
> > 
> > A regression test would be good.
> > This can be very simply a runtime switch that kills the parent process at vulnerable times. Sely be my example here:
> > [master...tstuefe:jdk:test-for-parent-premature-death](https://github.com/openjdk/jdk/compare/master...tstuefe:jdk:test-for-parent-premature-death)
> > Using that (KILLTEST=1), I was able to reproduce your problem with the hanging child. Using this to build a jtreg test is not hard.
> > Cheers, Thomas
> 
> Do you really think it makes sense to add such test code to the native runtime libraries?

Debug only? Sure. The fact that this error is in there since JDK 13 is scary.

> 
> I'm not sure. What do others think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1548181950

From jlaskey at openjdk.org  Mon May 15 17:01:59 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 15 May 2023 17:01:59 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
 <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
Message-ID: <pZHEJvRKpYMVIYC-EPIRX_FoDVCrswLxH0syakUGRos=.4a4fc275-8e9a-4abd-8e00-172cd38ffddc@github.com>

On Mon, 15 May 2023 06:31:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update VirtualParser.java
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 35:
> 
>> 33: public class MainMethodFinder {
>> 34:     private static boolean isPrivate(Method method) {
>> 35:         return method != null && Modifier.isPrivate(method.getModifiers());
> 
> Are you sure you want to allow null here? It seems like it's a bug in the caller if that happens.

Remnant of previous usage. Changed.

> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 38:
> 
>> 36:     }
>> 37: 
>> 38:     private static boolean isPublic(Method method) {
> 
> Is this left over from a previous iteration, it doesn't seem to be used.

Changed

> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 53:
> 
>> 51: 
>> 52:     /**
>> 53:      * Gather all the "main" methods in the class heirarchy.
> 
> heirarchy -> hierarchy

Changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194107274
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194105447
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194108052

From redestad at openjdk.org  Mon May 15 17:08:01 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Mon, 15 May 2023 17:08:01 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v4]
In-Reply-To: <nPB2iFEwbB5OfnC0b3ZcDl0zU8Fb1s7IzxiKSnmBt0E=.034f2f41-dd27-4e9b-bd32-98867b932bde@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <44odsoRkRp6mmgfPKFCPOy-uaHNOgOgPQUJICERzHKU=.5703da5a-0e66-45a2-af0b-23ac0665fbe7@github.com>
 <4pL9To1n8Gbf1EdM50d87Xk8nu0Ou_nAFONKBzaH1OQ=.103c7aae-dec8-409a-ace4-0f9b0d04d662@github.com>
 <bSD9UKkMFM-uEyD3NfuULXdog22l3_MPIzgL298A8Xk=.84ac7458-6747-457f-bb93-7aa574e8d623@github.com>
 <nPB2iFEwbB5OfnC0b3ZcDl0zU8Fb1s7IzxiKSnmBt0E=.034f2f41-dd27-4e9b-bd32-98867b932bde@github.com>
Message-ID: <L18_Ku3Ooxj1dg5LbXQqfvHz1NuarPRtVXB2dZczjg8=.6502e168-e061-4ffb-8766-3f6436b87c39@github.com>

On Mon, 15 May 2023 14:34:13 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> I have to side with @liach here: `LinkedList` iteration is significantly slower than `ArrayList` even though the computational complexity is identical. Often by an integer factor. This is due to the sparseness of the linked list data structure on heap and the pointer chasing that entails.  
>> 
>> For minimum overhead of iteration over an immutable list then turning the list into an immutable via `List.copyOf` might be preferable due the JVM's ability to optimize over `@Stable` arrays.
>> 
>> Adhoc [JMH benchmark](https://gist.github.com/cl4es/1f21812241c47f32a9deaffcc996e8b3):
>> 
>> 
>> Benchmark                            Mode  Cnt    Score    Error   Units
>> ListIteration.iterateArrayList      thrpt   15  188,724 ? 10,903  ops/ms
>> ListIteration.iterateImmutableList  thrpt   15  230,901 ?  6,513  ops/ms
>> ListIteration.iterateLinkedList     thrpt   15   58,289 ?  0,497  ops/ms
>> 
>> 
>> Is it important to fix this? Perhaps not, but in a microbenchmark like this the fewer cycles we spend on "stuff" that isn't really part of the thing we're testing, the better. Increasingly so as the thing we're testing is getting more and more optimized.
>
> I'm not questioning performance differences between list implementations. 
> The implementation of top level list for this benchmark is irrelevant because ~10ns difference cannot affect ~100?s benchmark run.

Fair point. The only counter-point I'd like to make is that these things tend to percolate and get copied around over to other places where it _could_ matter, so if it's no big deal I'd be slightly happier if we could avoid ever using `LinkedList`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1194116650

From jlaskey at openjdk.org  Mon May 15 17:09:02 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 15 May 2023 17:09:02 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
 <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
Message-ID: <9ftk4o0DvBHN-oDAlW6nW7_oM_KU8k3ZBzezvgfKWwM=.ec49936e-68a8-4b6c-a8bd-ed8c70ef3faf@github.com>

On Mon, 15 May 2023 06:45:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update VirtualParser.java
>
> test/jdk/tools/launcher/InstanceMainTest.java line 31:
> 
>> 29:  * @run main InstanceMainTest
>> 30:  */
>> 31: public class InstanceMainTest extends TestHelper {
> 
> Are you planning to add tests for the selection/precedence order?
> 
> Also wondering if we need a test to check that there is a warning when the main method in found in the super class.

InstanceMainTest does check precedence. Are you expecting a test for all combinations?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194117636

From naoto at openjdk.org  Mon May 15 17:09:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 15 May 2023 17:09:59 GMT
Subject: RFR: 8308022: update for deprecated sprintf for java.base
In-Reply-To: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
Message-ID: <Y8JiTAzeyM2YEjbGf5pMkBRc3Uom1xUBtJtUi_8dMw8=.8b8a8d67-0792-4aa9-a06a-71636102736c@github.com>

On Fri, 12 May 2023 17:57:43 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.
> 
> Thanks,
> Xuelei

Looked at TimeZone_md.c and Console_md.c, and the changes look reasonable.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13963#pullrequestreview-1427001957

From jlaskey at openjdk.org  Mon May 15 17:21:59 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 15 May 2023 17:21:59 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
 <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
Message-ID: <DQdEgriHT_67TuqxUXuECl57bvQ7eY67bARyrEhQlFE=.142a1b04-ae06-4d22-a3a5-76ec63c47be7@github.com>

On Mon, 15 May 2023 06:38:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update VirtualParser.java
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 146:
> 
>> 144: 
>> 145:             if (Modifier.isStatic(mods) && mainMethod.getDeclaringClass() != mainClass) {
>> 146:                 System.err.println("WARNING: static main in super class will be deprecated.");
> 
> I thought that JEP 445 was deprecating this, in which case the text should be "is deprecated" rather than "will be".

JEP 445 is not deprecating this. No advanced notice has been given.

> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 162:
> 
>> 160:             }
>> 161: 
>> 162:             if (1 < mains.size()) {
> 
> Checking if mains.size() > 1 might be easier on the eyes.

I never ever use > symbol. least to greatest left to right (maths).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194132127
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194133518

From dfuchs at openjdk.org  Mon May 15 17:23:46 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 15 May 2023 17:23:46 GMT
Subject: RFR: 8308022: update for deprecated sprintf for java.base
In-Reply-To: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
Message-ID: <5gmranDThlQlFLXa2i6t9E-z5tQrClncgNOErGSrfT8=.679ad5b9-ac56-418d-896f-1052fc6c4020@github.com>

On Fri, 12 May 2023 17:57:43 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.
> 
> Thanks,
> Xuelei

The libnet changes look reasonable to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13963#pullrequestreview-1427023621

From jlaskey at openjdk.org  Mon May 15 17:29:57 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 15 May 2023 17:29:57 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
 <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
Message-ID: <etSqgB9HDg8Ojy8axURx44i1hUVgr6SSgmEZ-Grpvvw=.b3644814-6af3-48ec-a0b6-d9c6ff8af880@github.com>

On Mon, 15 May 2023 07:13:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update VirtualParser.java
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 134:
> 
>> 132: 
>> 133:     /**
>> 134:      * {@return priority main method or null if none found}
> 
> "or null if none found", is that out of date?

Changed

> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 156:
> 
>> 154: 
>> 155:             List<Method> mains = new ArrayList<>();
>> 156:             gatherMains(mainClass, mainClass, mains);
> 
> Instead of gatherMains, did you consider first looking for static main(String[], then static main()? Asking because I expected to only see the walk up the hierarchy when looking for an instance main.

99.99% of the time it will be a single method in a shallow hierarchy, so cost its low. Only reason I broke out public static main was to ensure performance for existing code was the same.

> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 872:
> 
>> 870: 
>> 871:     // Check the existence and signature of main and abort if incorrect
>> 872:     public static void validateMainClass(Class<?> mainClass) {
> 
> Is there a reason that this is changed to public, maybe left over from a previous iteration?

Remnant. Changed.

> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 904:
> 
>> 902: 
>> 903:         if (!PreviewFeatures.isEnabled()) {
>> 904:             if (!isStatic || !isPublic || noArgs) {
> 
> You can use && here and avoid the nested if.

Easier to see when removing preview code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194138214
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194137852
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194141538
PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194141140

From jlaskey at openjdk.org  Mon May 15 17:37:58 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 15 May 2023 17:37:58 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
 <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
Message-ID: <lBowlr6Mc6C4PUEPwSiiEfsapnIcvZoBk5B1M8z758E=.6dce05a5-0a2e-4d23-bf88-3d9f3d2889da@github.com>

On Mon, 15 May 2023 07:48:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update VirtualParser.java
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 896:
> 
>> 894:          * findMainMethod (above) will choose the correct method, based
>> 895:          * on its name and parameter type, however, we still have to
>> 896:          * ensure that the method is static (non-preview) and returns a void.
> 
> Have you looked into findMainMethod checking the return type? Right now, we have findMainMethod returning a Method that needs further checking.

At some point I would like to fold both launchers into a single launcher. To do so would require having the source code launcher use the same error reporting and adapting downstream accordingly (tests et al). There is also a separate project to support multi-file source code launcher and I didn't want to disrupt the flow of that project at this point in time.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194149300

From rriggs at openjdk.org  Mon May 15 18:05:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 15 May 2023 18:05:55 GMT
Subject: Integrated: 8299340: CreateProcessW lpCommandLine must be mutable
In-Reply-To: <Frz6471rRcfwIp0UhYB-Jgu9gMV_jf1f5yfyUP044uY=.2f8a84c2-5650-443e-9a9e-944b693bb1e5@github.com>
References: <Frz6471rRcfwIp0UhYB-Jgu9gMV_jf1f5yfyUP044uY=.2f8a84c2-5650-443e-9a9e-944b693bb1e5@github.com>
Message-ID: <13Q4IxayQyAaP5EE9PzmPc6VtqvqEGjNF54s4w0I4bg=.aa4eab09-dab1-48b6-81fd-4f70695d24f8@github.com>

On Tue, 9 May 2023 21:46:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Launching of processes on Windows using `ProcessCreateW` with a Unicode character set requires the buffer to be writable. An access violation might occur if `ProcessCreateW` writes to the command line string. The current implementation fetches the command line string using JNI GetStringChars returning a buffer that should not be modified. The code is unchanged since 2015.  There have not been any reported faults in that time.
> 
> This change copies the command line to a separately allocation mutable buffer to satisfy the Windows requirement.

This pull request has now been integrated.

Changeset: 0f7b1c54
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0f7b1c549fbe4a90819fe3065dadf0b3e0ae94f3
Stats:     18 lines in 1 file changed: 10 ins; 0 del; 8 mod

8299340: CreateProcessW lpCommandLine must be mutable

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13894

From rriggs at openjdk.org  Mon May 15 18:06:58 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 15 May 2023 18:06:58 GMT
Subject: Integrated: 8304913: Use OperatingSystem, Architecture,
 and Version in jlink
In-Reply-To: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
References: <LW2HK7wociDAmplnX5rJfSSygB6dsJmkE_23RtR-M3Q=.3c25acac-b4de-48af-989b-229f0627988b@github.com>
Message-ID: <nGO4gCBiS1mNWFxIwykvqKjyI9RNu10fnBixkyEiE3I=.6af6396e-54d3-4f79-8550-f12de26dc8d4@github.com>

On Fri, 21 Apr 2023 17:06:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor the Platform class of jlink to use jdk.internal.util OperatingSystem and Architecture instead of os.name and os.arch. 
> They are direct replacements for the Platform enums except for UNKNOWN; its use is refactored to report errors via exceptions.
> 
> Neither os.name nor os.arch should be assumed to be changeable; 
> one test case is removed because it assumes os.name can be changed on the command line.

This pull request has now been integrated.

Changeset: 01892f9c
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/01892f9c6ed1ff6593f77b89fcc2c5da8d094abf
Stats:     166 lines in 7 files changed: 18 ins; 116 del; 32 mod

8304913: Use OperatingSystem, Architecture, and Version in jlink

Reviewed-by: jpai, alanb, mchung

-------------

PR: https://git.openjdk.org/jdk/pull/13585

From simonis at openjdk.org  Mon May 15 18:07:46 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 15 May 2023 18:07:46 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <m-1QliQ0sA8h_mh8BEL0pe01QK_jIRu-o0lgIU-k6_Q=.98348538-0968-48a1-b4c3-64b389608189@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <m-1QliQ0sA8h_mh8BEL0pe01QK_jIRu-o0lgIU-k6_Q=.98348538-0968-48a1-b4c3-64b389608189@github.com>
Message-ID: <FATGXWAxyHmLeMDd7zGznWIuNgxf136rt2X2MlaAKa0=.0b831f66-2b04-4935-a11e-a938f9493d7f@github.com>

On Mon, 15 May 2023 16:31:38 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> The fact that this error is in there since JDK 13 is scary.

The error is there since ten years since the `posix_spawn` mechanism was initially introduced with [JDK-5049299](https://bugs.openjdk.org/browse/JDK-5049299) for JDK 8 and downported to JDK 7 :)

In JDK 13 it only became the default mechanism on Linux.

And although LTS releases are not different from any other releases (reference pending :) it was only detected when migrations to JDK 17 finally started to ramp-up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1548319407

From jlaskey at openjdk.org  Mon May 15 18:08:16 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 15 May 2023 18:08:16 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v14]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <I0TIWBz6DE147ML4eJ8PcczUPuQ-dv0wLEQ4YE4OY9M=.c6d940b1-8f5e-4548-9286-28e4bf6990f0@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Requested Changes #2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/90b1e981..2b625a39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=12-13

  Stats: 9 lines in 2 files changed: 0 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From smarks at openjdk.org  Mon May 15 18:22:45 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 15 May 2023 18:22:45 GMT
Subject: RFR: JDK-8308049: Refactor nested class declarations in
 FdLibm.java
In-Reply-To: <YmQK9g6fUm0wxEeiHXzmekhjXAp9_durXafWoQlxqhM=.6d8fe081-1409-4c4c-a403-369cfc236650@github.com>
References: <YmQK9g6fUm0wxEeiHXzmekhjXAp9_durXafWoQlxqhM=.6d8fe081-1409-4c4c-a403-369cfc236650@github.com>
Message-ID: <B3E_XqCWfy4X0enC_nWvus4O3EjwcJitUJFSpDcTpSk=.02a600fc-9135-4b1d-ac9f-9ec71850ccc8@github.com>

On Sun, 14 May 2023 23:00:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Make the nested classes inside FdLibm.java consistently package-access, static and final.

Changes look good.

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13972#pullrequestreview-1427119830

From alanb at openjdk.org  Mon May 15 18:39:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 May 2023 18:39:57 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <DQdEgriHT_67TuqxUXuECl57bvQ7eY67bARyrEhQlFE=.142a1b04-ae06-4d22-a3a5-76ec63c47be7@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
 <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
 <DQdEgriHT_67TuqxUXuECl57bvQ7eY67bARyrEhQlFE=.142a1b04-ae06-4d22-a3a5-76ec63c47be7@github.com>
Message-ID: <qlS8-vnYvL8JDMCme_TZAGGDYmbx9bVDWj_C4bj_xTM=.726c7680-9ec4-44fa-ae66-a274c5fa5ab1@github.com>

On Mon, 15 May 2023 17:18:01 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 146:
>> 
>>> 144: 
>>> 145:             if (Modifier.isStatic(mods) && mainMethod.getDeclaringClass() != mainClass) {
>>> 146:                 System.err.println("WARNING: static main in super class will be deprecated.");
>> 
>> I thought that JEP 445 was deprecating this, in which case the text should be "is deprecated" rather than "will be".
>
> JEP 445 is not deprecating this. No advanced notice has been given.

Ah, I thought it was being deprecated. The JEP currently has "We deprecate the existing behavior that the launcher searches for a public static void main(String[] args) method in a superclass if one is not found in the launched class, issuing a runtime warning if such a method is found".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194220442

From bpb at openjdk.org  Mon May 15 18:44:53 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 15 May 2023 18:44:53 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v3]
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <UWP85Qx7yl8rLEis19oxDeWxCfR2kyqPI2J2jnwBByg=.f686e941-2a14-4f23-8ec6-cabdfea50c4f@github.com>

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8308016: Address reviewer comments since previous commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13957/files
  - new: https://git.openjdk.org/jdk/pull/13957/files/bc5c0358..614eeda6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=01-02

  Stats: 26 lines in 6 files changed: 2 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/13957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957

PR: https://git.openjdk.org/jdk/pull/13957

From rriggs at openjdk.org  Mon May 15 18:47:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 15 May 2023 18:47:44 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <EpRH_ZD3BR9HTcqdJMDzEwYwzzs3Gmt0aum31L2sFpI=.b9917c04-4f90-4f1b-aee9-c5e23ecd5332@github.com>

On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

I think writing a test is worth a little bit of time but getting a clean test run using the KILLTEST might be a bit tricky. The exit(-1) of the parent would be detected by jtreg as a failure. And verifying that the spawned child runs to completion might be difficult without writing a driver app to monitor the child; though it may be sufficient to know just that it does not hang and timeout. When the parent dies, the child will be re-parented.
And it would only be run in debug builds.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1548374054

From jlu at openjdk.org  Mon May 15 18:59:45 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 15 May 2023 18:59:45 GMT
Subject: RFR: 8300794: Use @snippet in java.util:i18n [v3]
In-Reply-To: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
References: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
Message-ID: <pDRk7Ri8s1v-idMcHBCKyoLyruL4ci99De3ct5nntvg=.00a6ccfb-abf3-4e08-bb0a-7d500e34b257@github.com>

> Please review this javadoc only change which uses `@snippet` and `@linkplain` in i18n related util packages.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Use elipsis replacement in snippet tag recommended in JDK PR #13957

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13920/files
  - new: https://git.openjdk.org/jdk/pull/13920/files/e56955e1..e15cacb3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13920&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13920&range=01-02

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13920.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13920/head:pull/13920

PR: https://git.openjdk.org/jdk/pull/13920

From duke at openjdk.org  Mon May 15 19:08:55 2023
From: duke at openjdk.org (Glavo)
Date: Mon, 15 May 2023 19:08:55 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v5]
In-Reply-To: <LvWUa88NeY3eHAfFZtPWSS9G-7L8Lx3Nv9clEhWbHy0=.6697f05a-908e-4ea9-b305-487fcb17da24@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <LvWUa88NeY3eHAfFZtPWSS9G-7L8Lx3Nv9clEhWbHy0=.6697f05a-908e-4ea9-b305-487fcb17da24@github.com>
Message-ID: <AWzbeR3i_EoOBCGMFJbRdnsTfgQffj_mHdRqD9fdK-Q=.96b619b3-0e45-4a47-bd4e-7d6aa8837545@github.com>

On Mon, 15 May 2023 14:48:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Following improvements implemented:
>> - Switch over `String` replaced with switch single char
>> - Binary search for frames in `StackMapGenerator`
>> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
>> - `ClassEntry` is caching `ClassDesc` symbol
>> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
>> - Caching `MethodTypeDesc` in `MethodInfo` implementations
>> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
>> 
>> No API change.
>> 
>> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
>> 
>> 
>> Benchmark                     Mode  Cnt       Score       Error  Units
>> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
>> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
>> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
>> 
>> 
>> 
>> Benchmark                     Mode  Cnt       Score      Error  Units
>> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
>> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
>> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - changed LinkedList to ArrayList in RebuildMethodBodies benchmark
>  - added RepeatedModelTraversal JMH benchmark

test/micro/org/openjdk/bench/jdk/classfile/RepeatedModelTraversal.java line 54:

> 52:     @Setup(Level.Trial)
> 53:     public void setup() throws IOException {
> 54:         models = new LinkedList<>();

I think `ArrayList` can be used instead of `LinkedList` here too. 

While this may not be an actual improvement, I don't think `LinkedList` should be used unless necessary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1194256653

From jlu at openjdk.org  Mon May 15 19:49:55 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 15 May 2023 19:49:55 GMT
Subject: RFR: 8306597: Improve string formatting in EquivMapsGenerator.java
 [v5]
In-Reply-To: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
Message-ID: <GhUOBOA6D-6LUWw6XTl1xx8mppzvvhpxwDSVJeP_JjY=.e4a17098-61a4-4945-a30f-2a80dc06ab96@github.com>

> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
> 
> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Align spacing of the maps to original

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13935/files
  - new: https://git.openjdk.org/jdk/pull/13935/files/b4e6e683..bc04b3d9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13935&range=03-04

  Stats: 4 lines in 1 file changed: 2 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13935.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13935/head:pull/13935

PR: https://git.openjdk.org/jdk/pull/13935

From lancea at openjdk.org  Mon May 15 19:58:45 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 15 May 2023 19:58:45 GMT
Subject: RFR: 8307403: java/util/zip/DeInflate.java timed out
In-Reply-To: <iZKgjHKUrExpgjmD0nD7lBjTHEy5zW_NbRExhnoxkgk=.0cf03734-bcca-422a-9b52-87ae70881527@github.com>
References: <iZKgjHKUrExpgjmD0nD7lBjTHEy5zW_NbRExhnoxkgk=.0cf03734-bcca-422a-9b52-87ae70881527@github.com>
Message-ID: <nyTdm-GVMZ7St3AWkwTouRnUiS-85ZuaYgG6WOHxdBs=.f58c7f77-0769-4bdc-8882-715f8bce8d13@github.com>

On Fri, 12 May 2023 12:47:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8307403?
> 
> When we recently did a change in https://bugs.openjdk.org/browse/JDK-8299748, there was a oversight that the `deflate.deflate(tempBuffer)` could potentially end up taking in a zero sized array. That would then mean the loop in which this `deflate` happens, would never exit leading to the test timing out.
> I've added additional details as a comment to the JBS issue https://bugs.openjdk.org/browse/JDK-8307403?focusedCommentId=14581202&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14581202.
> 
> The commit in this PR uses a fixed size temporary buffer, unrelated to the input length, to get past this problem. The use of fixed size here will not re-introduce the original issue which https://bugs.openjdk.org/browse/JDK-8299748 fixed, because unlike previously, this is just a temporary size and we continue to deflate the content into a dynamically growing `ByteArrayOutputStream` till the deflater is "finished".
> 
> Additionally I've added a log message to help debug any future issues in this call.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13955#pullrequestreview-1427277737

From duke at openjdk.org  Mon May 15 19:58:45 2023
From: duke at openjdk.org (Bernd)
Date: Mon, 15 May 2023 19:58:45 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <OYKgi_f5c6Xb4qtKGH8K3iM1wlOLgQrAWcVBRgjEYTA=.98afbb2d-f910-421c-ad50-d6dbe222da1f@github.com>

On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

Independent of the actual fix, it was mentioned that it can block listening sockets, aren?t those close on exec? Also should a write and read timeout be used in addition? At least to call the close descriptor code before retrying?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1548486244

From darcy at openjdk.org  Mon May 15 20:03:45 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 15 May 2023 20:03:45 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <PhQwmHWsZpkaMtgk1o5cU8To6ltyCEk9NbOKa9LgDtI=.4f986b17-5117-4b47-a6bb-055a5f717694@github.com>

On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

Should this issue have a CSR for any behavioral changes?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1548493002

From darcy at openjdk.org  Mon May 15 20:11:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 15 May 2023 20:11:54 GMT
Subject: Integrated: JDK-8308049: Refactor nested class declarations in
 FdLibm.java
In-Reply-To: <YmQK9g6fUm0wxEeiHXzmekhjXAp9_durXafWoQlxqhM=.6d8fe081-1409-4c4c-a403-369cfc236650@github.com>
References: <YmQK9g6fUm0wxEeiHXzmekhjXAp9_durXafWoQlxqhM=.6d8fe081-1409-4c4c-a403-369cfc236650@github.com>
Message-ID: <3X7MYXNRtu0GCqzbN2dZIyIG01tH9NNOdgDfq2SYbAA=.f454b067-89ad-4cca-91d9-557dd27b7991@github.com>

On Sun, 14 May 2023 23:00:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Make the nested classes inside FdLibm.java consistently package-access, static and final.

This pull request has now been integrated.

Changeset: 7b0b9b57
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7b0b9b570b5d6e90e0b79fbe19396c6e908a1dae
Stats:     17 lines in 1 file changed: 0 ins; 0 del; 17 mod

8308049: Refactor nested class declarations in FdLibm.java

Reviewed-by: smarks

-------------

PR: https://git.openjdk.org/jdk/pull/13972

From rriggs at openjdk.org  Mon May 15 20:13:49 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 15 May 2023 20:13:49 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v2]
In-Reply-To: <DBuIFwrtzIKUiah9Br5iZCADQw5z5ppWdR33xYWuZGM=.5665db8a-2cba-4757-bdfa-70a82a0cedd8@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
 <PEKg9keUFr1YbZ2wRIq-CjOGGi-vr6fduph5XVIcEhE=.74f584e9-450f-494a-ba5c-555a73d9b4d1@github.com>
 <DBuIFwrtzIKUiah9Br5iZCADQw5z5ppWdR33xYWuZGM=.5665db8a-2cba-4757-bdfa-70a82a0cedd8@github.com>
Message-ID: <Nevv5bwPP5ckjFCLMQW9V7lQnqch1bU4ZqRbIdzLCtM=.3d99cede-f1c5-4893-8c14-4ad6fe537d36@github.com>

On Fri, 12 May 2023 22:04:24 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Minor source code style cleanup
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/CLIHelp.java line 51:
> 
>> 49:             Log.info(I18N.getString("MSG_Help_no_args"));
>> 50:         } else {
>> 51:             OperatingSystem platform = OperatingSystem.current();
> 
> Should we add if (Log.isVerbose) back? Otherwise default case in switch statement never executed.

I was puzzled by that check early on and its still a puzzle. It seems a bit of a hack overloaded on the platform dispatch.
As it turns out, the only time that `Log.isVerbose()` is true when `showHelp()` is called is when the environment variable `JPACKAGE_DEBUG` is used for debugging.
`showHelp()` is only called before argument parsing is done and it doesn't look for --verbose. See `Main.execute()` 
So checking for isVerbose has no practical function.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1194314732

From rriggs at openjdk.org  Mon May 15 20:21:52 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 15 May 2023 20:21:52 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v2]
In-Reply-To: <PEKg9keUFr1YbZ2wRIq-CjOGGi-vr6fduph5XVIcEhE=.74f584e9-450f-494a-ba5c-555a73d9b4d1@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
 <PEKg9keUFr1YbZ2wRIq-CjOGGi-vr6fduph5XVIcEhE=.74f584e9-450f-494a-ba5c-555a73d9b4d1@github.com>
Message-ID: <4LeQruCP3drAOF77o6IXQsa5xfRkeHO56MqxwX_5AIk=.8d2aa634-c679-4c59-a3b9-aa52f085f559@github.com>

On Fri, 5 May 2023 14:12:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
>> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
>> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
>> 
>> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
>> Mac OS X 10.15 is the oldest version supported.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor source code style cleanup

One difference between the original `Platform` enum and the `OperatingSystem` enum is the handling of AIX.
In the original AIX is mapped to Linux.  The `OperatingSystem` enum considers it a separate value. 
When dispatching on the OperatingSystem, Linux and AIX should take the same actions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13586#issuecomment-1548518677

From bpb at openjdk.org  Mon May 15 20:48:47 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 15 May 2023 20:48:47 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v4]
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <skLx4Vvti_Vnqnofwh6CyD14wVtELmdjcD1vXfPvJIU=.5e9fe1e7-c6c1-4a34-8f71-fbbecb99dea9@github.com>

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8308016: Fix link in snippet of File::toPath

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13957/files
  - new: https://git.openjdk.org/jdk/pull/13957/files/614eeda6..da7c2004

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957

PR: https://git.openjdk.org/jdk/pull/13957

From darcy at openjdk.org  Mon May 15 22:20:46 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 15 May 2023 22:20:46 GMT
Subject: RFR: 8307547: Support variant collations [v4]
In-Reply-To: <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
Message-ID: <UKmZcsoyyPpP8SR6NVBdzxRGc9nyU2yICgNBA3TsHWY=.6c477050-bd4e-46b4-8ca2-984e67276b3d@github.com>

On Thu, 11 May 2023 20:51:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added "reformed" tests

src/java.base/share/classes/java/text/Collator.java line 230:

> 228:     /**
> 229:      * Gets the Collator for the desired locale.
> 230:      * @apiNote Implementations of {@code Collator} class may produce

For less l10n savvy readers, I suggest providing a bit more context in the apiNote, such as by explicitly mentioning Swedish and showing what getting the default collator would look like.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13917#discussion_r1194416496

From rriggs at openjdk.org  Mon May 15 22:51:52 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 15 May 2023 22:51:52 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v3]
In-Reply-To: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
Message-ID: <KHzI2hrflmstmSodbBnNuNbnzbvG-sNBDrWl9hk2xbo=.d77e8ca6-7de5-452d-89b5-fa9343f428b8@github.com>

> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
> 
> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
> Mac OS X 10.15 is the oldest version supported.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge branch 'master' into 8304914-os-jpackage
 - The OperatingSystem enum treats AIX separately from Linux. The original Platform used the same enum for both.
   Whereever OperatingSystem.isLinux is used in jpackage it should include isAix as well.
 - Minor source code style cleanup
 - Merge branch 'master' into 8304914-os-jpackage
 - Merge branch '8306678-os-version' into 8304914-os-jpackage
 - Merge branch '8304915-arch-enum' into 8306678-os-version
 - Correct comment on isPPC64() and refer to isLittleEndian() instead of mentioning PPC64LE
 - Simplify initialization in ClassLoaderHelper and fix VersionTest.
 - Revert changes to MacOsX sun.nio.fs.BsdFileStore; the version check is being removed in another PR.
 - Review comment updates
 - ... and 24 more: https://git.openjdk.org/jdk/compare/7b0b9b57...64ab7126

-------------

Changes: https://git.openjdk.org/jdk/pull/13586/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13586&range=02
  Stats: 239 lines in 23 files changed: 44 ins; 132 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/13586.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13586/head:pull/13586

PR: https://git.openjdk.org/jdk/pull/13586

From jlu at openjdk.org  Mon May 15 23:21:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 15 May 2023 23:21:57 GMT
Subject: Integrated: 8306597: Improve string formatting in
 EquivMapsGenerator.java
In-Reply-To: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
Message-ID: <eU792pSRCTve1pt3YQMDWX8YrdMaC2S5uCP6Xpm223g=.6e0fd122-39e4-46a9-a8e5-88decfb97324@github.com>

On Thu, 11 May 2023 15:40:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
> 
> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same.

This pull request has now been integrated.

Changeset: 31683722
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/316837226ecceb4daa14e2bc1be8ce120edbfdc9
Stats:     185 lines in 1 file changed: 94 ins; 70 del; 21 mod

8306597: Improve string formatting in EquivMapsGenerator.java

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13935

From jpai at openjdk.org  Tue May 16 01:20:52 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 May 2023 01:20:52 GMT
Subject: RFR: 8307403: java/util/zip/DeInflate.java timed out
In-Reply-To: <iZKgjHKUrExpgjmD0nD7lBjTHEy5zW_NbRExhnoxkgk=.0cf03734-bcca-422a-9b52-87ae70881527@github.com>
References: <iZKgjHKUrExpgjmD0nD7lBjTHEy5zW_NbRExhnoxkgk=.0cf03734-bcca-422a-9b52-87ae70881527@github.com>
Message-ID: <Fs5f4aP4w3h1wIL7DmeaBPjKoGrGaHHyutSeEMzzRm4=.ce6f517f-fbde-4a04-b866-33a3ac3fe2e6@github.com>

On Fri, 12 May 2023 12:47:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8307403?
> 
> When we recently did a change in https://bugs.openjdk.org/browse/JDK-8299748, there was a oversight that the `deflate.deflate(tempBuffer)` could potentially end up taking in a zero sized array. That would then mean the loop in which this `deflate` happens, would never exit leading to the test timing out.
> I've added additional details as a comment to the JBS issue https://bugs.openjdk.org/browse/JDK-8307403?focusedCommentId=14581202&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14581202.
> 
> The commit in this PR uses a fixed size temporary buffer, unrelated to the input length, to get past this problem. The use of fixed size here will not re-introduce the original issue which https://bugs.openjdk.org/browse/JDK-8299748 fixed, because unlike previously, this is just a temporary size and we continue to deflate the content into a dynamically growing `ByteArrayOutputStream` till the deflater is "finished".
> 
> Additionally I've added a log message to help debug any future issues in this call.

Thank you Lance and Volker for the reviews. I'll go ahead and merge this today.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13955#issuecomment-1548829229

From jpai at openjdk.org  Tue May 16 01:20:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 May 2023 01:20:54 GMT
Subject: RFR: 8307403: java/util/zip/DeInflate.java timed out
In-Reply-To: <xAyjKkvdpJQk4nP93zcG9MMrquaIiI7Fih8mgJPxlUc=.dab9531e-1195-414c-ae46-cafd67ee2228@github.com>
References: <iZKgjHKUrExpgjmD0nD7lBjTHEy5zW_NbRExhnoxkgk=.0cf03734-bcca-422a-9b52-87ae70881527@github.com>
 <xAyjKkvdpJQk4nP93zcG9MMrquaIiI7Fih8mgJPxlUc=.dab9531e-1195-414c-ae46-cafd67ee2228@github.com>
Message-ID: <YvUWvlltc1_kH5-r5Vqyw8QV6G0-l5BRvRw6fQDSx8c=.7dcafabc-0ac8-483d-9bf8-4c34c45ddac4@github.com>

On Mon, 15 May 2023 15:10:06 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Can I please get a review of this test only change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8307403?
>> 
>> When we recently did a change in https://bugs.openjdk.org/browse/JDK-8299748, there was a oversight that the `deflate.deflate(tempBuffer)` could potentially end up taking in a zero sized array. That would then mean the loop in which this `deflate` happens, would never exit leading to the test timing out.
>> I've added additional details as a comment to the JBS issue https://bugs.openjdk.org/browse/JDK-8307403?focusedCommentId=14581202&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14581202.
>> 
>> The commit in this PR uses a fixed size temporary buffer, unrelated to the input length, to get past this problem. The use of fixed size here will not re-introduce the original issue which https://bugs.openjdk.org/browse/JDK-8299748 fixed, because unlike previously, this is just a temporary size and we continue to deflate the content into a dynamically growing `ByteArrayOutputStream` till the deflater is "finished".
>> 
>> Additionally I've added a log message to help debug any future issues in this call.
>
> test/jdk/java/util/zip/DeInflate.java line 146:
> 
>> 144:         def.finish();
>> 145: 
>> 146:         try (ByteArrayOutputStream baos = new ByteArrayOutputStream()) {
> 
> I don't think this is really required because the `ByteArrayOutputStream` will grow dynamically anyway, even if initialized to zero but for all other cases `len` is probably a better estimation than the default size of `32`. But I leave it up to you if you want to change it back.

Hello Volker, you are right that even initializing this with `len` should be fine since the `ByteArrayOutputStream` will grow if/when needed. However, the reason I decided to remove the usage of `len` here was to avoid any kind of confusion and make it easier to read that `len` is only for the input length (as noted in the javadoc of that method) and plays no other role in deciding sizes of (temporary) outputs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13955#discussion_r1194498736

From duke at openjdk.org  Tue May 16 01:34:45 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Tue, 16 May 2023 01:34:45 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v5]
In-Reply-To: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
Message-ID: <CxiJ8tPpIHLtciNPHot9NCsDOQVBLOc_eTaF1RbawR4=.65c77760-e4ef-4ce2-b403-c14647e413fe@github.com>

> I fixed File.listRoots description.
> * remove "the insertion or ejection of removable media"
> * change "available" to "existing"
> 
> Please review this change.

Nagata-Haruhito has updated the pull request with a new target base 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 'openjdk:master' into File_javadoc
 - Merge branch 'openjdk:master' into File_javadoc
 - 8306431: The documentation of File.listRoots should be modifid after JDK-8208077
 - 8306431: File.listRoots method description should be re-examined

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13526/files
  - new: https://git.openjdk.org/jdk/pull/13526/files/acb639e5..787f71a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13526&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13526&range=03-04

  Stats: 176489 lines in 2827 files changed: 134200 ins; 21560 del; 20729 mod
  Patch: https://git.openjdk.org/jdk/pull/13526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13526/head:pull/13526

PR: https://git.openjdk.org/jdk/pull/13526

From jpai at openjdk.org  Tue May 16 05:09:53 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 May 2023 05:09:53 GMT
Subject: Integrated: 8307403: java/util/zip/DeInflate.java timed out
In-Reply-To: <iZKgjHKUrExpgjmD0nD7lBjTHEy5zW_NbRExhnoxkgk=.0cf03734-bcca-422a-9b52-87ae70881527@github.com>
References: <iZKgjHKUrExpgjmD0nD7lBjTHEy5zW_NbRExhnoxkgk=.0cf03734-bcca-422a-9b52-87ae70881527@github.com>
Message-ID: <3h3B1OA7RK_B84d2Tro_SiJdc0IV4IrEqhYV2t3bim4=.0dc9d837-0e6a-4e50-84ff-a293bf056d61@github.com>

On Fri, 12 May 2023 12:47:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test only change which addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8307403?
> 
> When we recently did a change in https://bugs.openjdk.org/browse/JDK-8299748, there was a oversight that the `deflate.deflate(tempBuffer)` could potentially end up taking in a zero sized array. That would then mean the loop in which this `deflate` happens, would never exit leading to the test timing out.
> I've added additional details as a comment to the JBS issue https://bugs.openjdk.org/browse/JDK-8307403?focusedCommentId=14581202&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14581202.
> 
> The commit in this PR uses a fixed size temporary buffer, unrelated to the input length, to get past this problem. The use of fixed size here will not re-introduce the original issue which https://bugs.openjdk.org/browse/JDK-8299748 fixed, because unlike previously, this is just a temporary size and we continue to deflate the content into a dynamically growing `ByteArrayOutputStream` till the deflater is "finished".
> 
> Additionally I've added a log message to help debug any future issues in this call.

This pull request has now been integrated.

Changeset: d22bcc81
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d22bcc813eea719b817d3d541a843594675c0ca9
Stats:     4 lines in 1 file changed: 1 ins; 1 del; 2 mod

8307403: java/util/zip/DeInflate.java timed out

Reviewed-by: simonis, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/13955

From duke at openjdk.org  Tue May 16 06:48:49 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Tue, 16 May 2023 06:48:49 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v5]
In-Reply-To: <CxiJ8tPpIHLtciNPHot9NCsDOQVBLOc_eTaF1RbawR4=.65c77760-e4ef-4ce2-b403-c14647e413fe@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <CxiJ8tPpIHLtciNPHot9NCsDOQVBLOc_eTaF1RbawR4=.65c77760-e4ef-4ce2-b403-c14647e413fe@github.com>
Message-ID: <TYlwEOT6PL18xxfsxDD-b5fG_Fa4DC1YZnRf773yhi0=.01af2a2c-4491-4858-8a72-6e2568a3bdde@github.com>

On Tue, 16 May 2023 01:34:45 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> I fixed File.listRoots description.
>> * remove "the insertion or ejection of removable media"
>> * change "available" to "existing"
>> 
>> Please review this change.
>
> Nagata-Haruhito has updated the pull request with a new target base 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 'openjdk:master' into File_javadoc
>  - Merge branch 'openjdk:master' into File_javadoc
>  - 8306431: The documentation of File.listRoots should be modifid after JDK-8208077
>  - 8306431: File.listRoots method description should be re-examined

I solved GHA failures. Would you please this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13526#issuecomment-1549080412

From alanb at openjdk.org  Tue May 16 06:56:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 May 2023 06:56:50 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v5]
In-Reply-To: <CxiJ8tPpIHLtciNPHot9NCsDOQVBLOc_eTaF1RbawR4=.65c77760-e4ef-4ce2-b403-c14647e413fe@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <CxiJ8tPpIHLtciNPHot9NCsDOQVBLOc_eTaF1RbawR4=.65c77760-e4ef-4ce2-b403-c14647e413fe@github.com>
Message-ID: <Kj8cJuc9CvjQ5q3OmHrLLuTPsJiVZXQsMRZcLgjH3T4=.810d597d-7cf7-460e-b028-0dafe9d7c2f0@github.com>

On Tue, 16 May 2023 01:34:45 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> I fixed File.listRoots description.
>> * remove "the insertion or ejection of removable media"
>> * change "available" to "existing"
>> 
>> Please review this change.
>
> Nagata-Haruhito has updated the pull request with a new target base 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 'openjdk:master' into File_javadoc
>  - Merge branch 'openjdk:master' into File_javadoc
>  - 8306431: The documentation of File.listRoots should be modifid after JDK-8208077
>  - 8306431: File.listRoots method description should be re-examined

src/java.base/share/classes/java/io/File.java line 1819:

> 1817:      *
> 1818:      * <p> This method returns an array of {@code File} objects that denote the
> 1819:      * root directories of the existing filesystem roots.  It is guaranteed

I don't think you can change "available" to "existing" here without a lot more discussion. In particular, the javadoc can't set the expectation that "existing" implies that File::exists will return true, it might not. So I think drop this from the change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13526#discussion_r1194695909

From aturbanov at openjdk.org  Tue May 16 06:56:52 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 16 May 2023 06:56:52 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v5]
In-Reply-To: <LvWUa88NeY3eHAfFZtPWSS9G-7L8Lx3Nv9clEhWbHy0=.6697f05a-908e-4ea9-b305-487fcb17da24@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <LvWUa88NeY3eHAfFZtPWSS9G-7L8Lx3Nv9clEhWbHy0=.6697f05a-908e-4ea9-b305-487fcb17da24@github.com>
Message-ID: <U_6Ij9F1l4uq9_nuYc0hAVWUMjMkcwvw0j7Vmcykqj0=.8aa002c4-3a38-430f-8ba4-2c5723eae8bf@github.com>

On Mon, 15 May 2023 14:48:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Following improvements implemented:
>> - Switch over `String` replaced with switch single char
>> - Binary search for frames in `StackMapGenerator`
>> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
>> - `ClassEntry` is caching `ClassDesc` symbol
>> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
>> - Caching `MethodTypeDesc` in `MethodInfo` implementations
>> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
>> 
>> No API change.
>> 
>> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
>> 
>> 
>> Benchmark                     Mode  Cnt       Score       Error  Units
>> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
>> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
>> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
>> 
>> 
>> 
>> Benchmark                     Mode  Cnt       Score      Error  Units
>> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
>> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
>> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s
>
> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - changed LinkedList to ArrayList in RebuildMethodBodies benchmark
>  - added RepeatedModelTraversal JMH benchmark

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java line 85:

> 83:         for(var arg : methodType.parameterList()) {
> 84:             vtis[i++] = switch (arg.descriptorString().charAt(0)) {
> 85:                 case 'I', 'S', 'C' ,'B', 'Z' ->  SimpleVerificationTypeInfo.ITEM_INTEGER;

Suggestion:

                case 'I', 'S', 'C' ,'B', 'Z' -> SimpleVerificationTypeInfo.ITEM_INTEGER;

test/micro/org/openjdk/bench/jdk/classfile/RebuildMethodBodies.java line 58:

> 56:         shared = new ArrayList<>();
> 57:         unshared = new ArrayList<>();
> 58:         Files.walk(FileSystems.getFileSystem(URI.create("jrt:/")).getPath("modules/java.base/java")).forEach(p ->  {

Suggestion:

        Files.walk(FileSystems.getFileSystem(URI.create("jrt:/")).getPath("modules/java.base/java")).forEach(p -> {

test/micro/org/openjdk/bench/jdk/classfile/RepeatedModelTraversal.java line 55:

> 53:     public void setup() throws IOException {
> 54:         models = new LinkedList<>();
> 55:         Files.walk(FileSystems.getFileSystem(URI.create("jrt:/")).getPath("modules/java.base/java/util")).forEach(p ->  {

Suggestion:

        Files.walk(FileSystems.getFileSystem(URI.create("jrt:/")).getPath("modules/java.base/java/util")).forEach(p -> {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1194695545
PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1194695808
PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1194695081

From dholmes at openjdk.org  Tue May 16 07:27:48 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 May 2023 07:27:48 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>

On Fri, 12 May 2023 15:24:19 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

I wonder if @Martin-Buchholz is able to look at this one?

My concern with changes like this is that they fix an issue but then have unexpected side-effects themselves.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1549138815

From asotona at openjdk.org  Tue May 16 07:28:17 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 16 May 2023 07:28:17 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v6]
In-Reply-To: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
Message-ID: <mHXsggIiQTfnPxZ01tKvUWv73yqI7nCfHJhdiDJAs18=.045fa650-4dae-4709-8998-929179e35d7b@github.com>

> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
> - Caching `MethodTypeDesc` in `MethodInfo` implementations
> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
> 
> No API change.
> 
> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
> 
> 
> Benchmark                     Mode  Cnt       Score       Error  Units
> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
> 
> 
> 
> Benchmark                     Mode  Cnt       Score      Error  Units
> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13671/files
  - new: https://git.openjdk.org/jdk/pull/13671/files/3b299727..71e7fa98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13671&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13671&range=04-05

  Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13671.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13671/head:pull/13671

PR: https://git.openjdk.org/jdk/pull/13671

From asotona at openjdk.org  Tue May 16 07:28:17 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 16 May 2023 07:28:17 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v4]
In-Reply-To: <L18_Ku3Ooxj1dg5LbXQqfvHz1NuarPRtVXB2dZczjg8=.6502e168-e061-4ffb-8766-3f6436b87c39@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <44odsoRkRp6mmgfPKFCPOy-uaHNOgOgPQUJICERzHKU=.5703da5a-0e66-45a2-af0b-23ac0665fbe7@github.com>
 <4pL9To1n8Gbf1EdM50d87Xk8nu0Ou_nAFONKBzaH1OQ=.103c7aae-dec8-409a-ace4-0f9b0d04d662@github.com>
 <bSD9UKkMFM-uEyD3NfuULXdog22l3_MPIzgL298A8Xk=.84ac7458-6747-457f-bb93-7aa574e8d623@github.com>
 <nPB2iFEwbB5OfnC0b3ZcDl0zU8Fb1s7IzxiKSnmBt0E=.034f2f41-dd27-4e9b-bd32-98867b932bde@github.com>
 <L18_Ku3Ooxj1dg5LbXQqfvHz1NuarPRtVXB2dZczjg8=.6502e168-e061-4ffb-8766-3f6436b87c39@github.com>
Message-ID: <U_fguCeY9gZ8uTk7TAJvmNUevrnn_6Hy_fv_uoYHbek=.45670da3-f28d-49c0-b870-2d612d720fd3@github.com>

On Mon, 15 May 2023 17:04:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I'm not questioning performance differences between list implementations. 
>> The implementation of top level list for this benchmark is irrelevant because ~10ns difference cannot affect ~100?s benchmark run.
>
> Fair point. The only counter-point I'd like to make is that these things tend to percolate and get copied around over to other places where it _could_ matter, so if it's no big deal I'd be slightly happier if we could avoid ever using `LinkedList`.

Right, fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1194724816

From stuefe at openjdk.org  Tue May 16 07:56:46 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 16 May 2023 07:56:46 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <EpRH_ZD3BR9HTcqdJMDzEwYwzzs3Gmt0aum31L2sFpI=.b9917c04-4f90-4f1b-aee9-c5e23ecd5332@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <EpRH_ZD3BR9HTcqdJMDzEwYwzzs3Gmt0aum31L2sFpI=.b9917c04-4f90-4f1b-aee9-c5e23ecd5332@github.com>
Message-ID: <tIfk96I98C1h-WLlvU8pyuAJ-jVmT4DimA9JhklgGg4=.6891c990-f685-432d-a59a-70ee2323c810@github.com>

On Mon, 15 May 2023 18:45:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> I think writing a test is worth a little bit of time but getting a clean test run using the KILLTEST might be a bit tricky. The exit(-1) of the parent would be detected by jtreg as a failure. And verifying that the spawned child runs to completion might be difficult without writing a driver app to monitor the child; though it may be sufficient to know just that it does not hang and timeout. When the parent dies, the child will be re-parented.
> And it would only be run in debug builds.

@RogerRiggs @simonis 

Okay, I wrote a jtreg test case for the issue, just to see if I could. Rebased atop of Volkers change, you can just take the commit if you want:

https://github.com/tstuefe/jdk/tree/Added-TestCase-For-Volker
https://github.com/openjdk/jdk/commit/9119b442dac8dd95228d47d70871ee59862649ce

Test case fails immediately (so, no relying on timeouts) if Volkers patch is missing. Succeeds immediately with Volkers patch. I also tried commenting out the fixing close() call, test fails immediately.

Patch relies on jspawnhelper to write a small marker file on communication error with parent if KILLTEST is set. Only in debug code. I think this is very reliable. No second-guessing aliveness of the child and worrying about PID reuse. Re-parenting is no issue either. And I think such a file make be a good idea anyway to analyze handshake errors with jspawnhelper.

Tested on Linux x64.

@simonis, feel free to add me as contributor if you take this test. I spent way to much time on this :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1549172824

From stuefe at openjdk.org  Tue May 16 07:59:44 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 16 May 2023 07:59:44 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>
Message-ID: <WNS9AUc4Uo0uJT7Q-c5WmRQGPXKHOiQ5bk3FAVhcpTw=.7b192c55-1a39-48bf-9c36-eb8219474c4f@github.com>

On Tue, 16 May 2023 07:24:31 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I wonder if @Martin-Buchholz is able to look at this one?
> 
> My concern with changes like this is that they fix an issue but then have unexpected side-effects themselves.

Are there any specific concerns you have?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1549179059

From alanb at openjdk.org  Tue May 16 08:00:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 May 2023 08:00:51 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v4]
In-Reply-To: <skLx4Vvti_Vnqnofwh6CyD14wVtELmdjcD1vXfPvJIU=.5e9fe1e7-c6c1-4a34-8f71-fbbecb99dea9@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <skLx4Vvti_Vnqnofwh6CyD14wVtELmdjcD1vXfPvJIU=.5e9fe1e7-c6c1-4a34-8f71-fbbecb99dea9@github.com>
Message-ID: <MygMOR35zTxuM0vUsEpc_lt0IpUaryt_3nEPkr3Mim4=.b25c1ffc-b3ec-498a-852c-dd559140acf9@github.com>

On Mon, 15 May 2023 20:48:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308016: Fix link in snippet of File::toPath

src/java.base/share/classes/java/io/File.java line 2375:

> 2373:      * {@snippet lang=java :
> 2374:      *         // @link substring="getDefault" target="java.nio.file.FileSystems#getDefault" @link regex="getPath(?=\(t)" target="java.nio.file.FileSystem#getPath" @link regex="getPath(?=\(\))" target="#getPath" :
> 2375:      *         FileSystems.getDefault().getPath(this.getPath());

There is already a link to FileSystems.getDefault() in the previous paragraph so I think you can remove the linking in the snippet to:

`// @link regex="getPath(?=(t)" target="java.nio.file.FileSystem#getPath" :`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1194767344

From asotona at openjdk.org  Tue May 16 08:17:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 16 May 2023 08:17:02 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v7]
In-Reply-To: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
Message-ID: <9WXdnsx_lbXdDej1YqximLLEDLIWDTz_jxtSU7iRTsw=.b1b54d6f-c220-4eb0-96bb-1b263466a0b4@github.com>

> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
> - Caching `MethodTypeDesc` in `MethodInfo` implementations
> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
> 
> No API change.
> 
> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
> 
> 
> Benchmark                     Mode  Cnt       Score       Error  Units
> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
> 
> 
> 
> Benchmark                     Mode  Cnt       Score      Error  Units
> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  LinkedList replaced with ArrayList in benchmarks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13671/files
  - new: https://git.openjdk.org/jdk/pull/13671/files/71e7fa98..d353bb33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13671&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13671&range=05-06

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13671.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13671/head:pull/13671

PR: https://git.openjdk.org/jdk/pull/13671

From asotona at openjdk.org  Tue May 16 08:17:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 16 May 2023 08:17:05 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v5]
In-Reply-To: <AWzbeR3i_EoOBCGMFJbRdnsTfgQffj_mHdRqD9fdK-Q=.96b619b3-0e45-4a47-bd4e-7d6aa8837545@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <LvWUa88NeY3eHAfFZtPWSS9G-7L8Lx3Nv9clEhWbHy0=.6697f05a-908e-4ea9-b305-487fcb17da24@github.com>
 <AWzbeR3i_EoOBCGMFJbRdnsTfgQffj_mHdRqD9fdK-Q=.96b619b3-0e45-4a47-bd4e-7d6aa8837545@github.com>
Message-ID: <CF5Q2TQ95VV0CIU3tp0kEfsq8tTVhF5M5aeFE8ek8RY=.28f23ed6-48f9-4df9-9c52-fa721ae3a662@github.com>

On Mon, 15 May 2023 19:06:16 GMT, Glavo <duke at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - changed LinkedList to ArrayList in RebuildMethodBodies benchmark
>>  - added RepeatedModelTraversal JMH benchmark
>
> test/micro/org/openjdk/bench/jdk/classfile/RepeatedModelTraversal.java line 54:
> 
>> 52:     @Setup(Level.Trial)
>> 53:     public void setup() throws IOException {
>> 54:         models = new LinkedList<>();
> 
> I think `ArrayList` can be used instead of `LinkedList` here too. 
> 
> While this may not be an actual improvement, I don't think `LinkedList` should be used unless necessary.

I've replaced all `LinkedList` with `ArrayList` in the benchmarks, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1194784609

From stuefe at openjdk.org  Tue May 16 09:03:48 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 16 May 2023 09:03:48 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <CVTdCWXTjp9U0tLdtfLTvfeYTrmG6D6tEyaoAGXXgTA=.e918e4de-b7e0-4c21-be7a-93f5de716311@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <CVTdCWXTjp9U0tLdtfLTvfeYTrmG6D6tEyaoAGXXgTA=.e918e4de-b7e0-4c21-be7a-93f5de716311@github.com>
Message-ID: <h3Mz1hEtABlHcZj-OnB8CaKMdYtwxB6KjDPgBGofJpY=.b229c5af-5aa3-46b3-9738-cfa4aaa5837f@github.com>

On Mon, 15 May 2023 16:11:46 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> > 2. I think you don't actually have to hand in the in-pipe-read-end fd number via command line arg, just to have the child to close it. You could just, in the parent, set the fd to FD_CLOEXEC. Since posix_spawn() exec's the spawn helper, this would close the file descriptor for you. Extending this thought, you could do this with all pipe ends you want to cauterize in the child process.
> 
> I've deliberately not used `FD_CLOEXEC` because the file descriptor closing code in `childProcess()` is shared by all launch mechanisms. So to make it work, I'd had to reset the corresponding file descriptors to `-1` in the child anyway.
> 
> I therefor felt the current fix is smaller, simpler and easier to understand.

I don't understand what you mean.

A) vfork, fork:

`(parent)->fork()->(child)->childProcess()`

B) posix_spawn:

`(parent)->posix_spawn()(does clone() then exec())->jspawnhelper main()->childProcess()`

With your patch, you close the offending fd in `jspawnhelper main()`. With my suggestion, it would be closed on the `exec` call `posix_spawn` does. Neither variant affects the working of vfork/fork mode. Am I missing something?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1549274987

From duke at openjdk.org  Tue May 16 10:46:44 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Tue, 16 May 2023 10:46:44 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently
Message-ID: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>

Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,

I didn't add any new tests but ran tier 1-3 with no issues

-------------

Commit messages:
 - added some case conversions missed previously
 - updated copyright year and cleaned up some formatting of imports
 - merged master into branch
 - Specify use of Locale.Root to avoid issues with case conversion

Changes: https://git.openjdk.org/jdk/pull/14006/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14006&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-7065228
  Stats: 76 lines in 21 files changed: 15 ins; 0 del; 61 mod
  Patch: https://git.openjdk.org/jdk/pull/14006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14006/head:pull/14006

PR: https://git.openjdk.org/jdk/pull/14006

From dholmes at openjdk.org  Tue May 16 12:09:46 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 16 May 2023 12:09:46 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <WNS9AUc4Uo0uJT7Q-c5WmRQGPXKHOiQ5bk3FAVhcpTw=.7b192c55-1a39-48bf-9c36-eb8219474c4f@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>
 <WNS9AUc4Uo0uJT7Q-c5WmRQGPXKHOiQ5bk3FAVhcpTw=.7b192c55-1a39-48bf-9c36-eb8219474c4f@github.com>
Message-ID: <u7bSYYuppXZ1z347-wRTJf9GoxNUW-GoWfSn4dmCLEE=.831249e0-e538-491c-8001-a7dd55673721@github.com>

On Tue, 16 May 2023 07:56:35 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > I wonder if @Martin-Buchholz is able to look at this one?
> > My concern with changes like this is that they fix an issue but then have unexpected side-effects themselves.
> 
> Are there any specific concerns you have?

There seems to be more going on here than just closing the write side of the pipe. We will now error out if any of the readFully's do a short read, rather than just when reporting an error - which on the surface seems like a good thing, but what if harmless short-reads can actually happen in some contexts?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1549538540

From stuefe at openjdk.org  Tue May 16 12:35:46 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 16 May 2023 12:35:46 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <u7bSYYuppXZ1z347-wRTJf9GoxNUW-GoWfSn4dmCLEE=.831249e0-e538-491c-8001-a7dd55673721@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>
 <WNS9AUc4Uo0uJT7Q-c5WmRQGPXKHOiQ5bk3FAVhcpTw=.7b192c55-1a39-48bf-9c36-eb8219474c4f@github.com>
 <u7bSYYuppXZ1z347-wRTJf9GoxNUW-GoWfSn4dmCLEE=.831249e0-e538-491c-8001-a7dd55673721@github.com>
Message-ID: <yZM9iro4FRdHveBRx07oeItZ9_CmQJ4wksNo3XI8Igs=.7b2097d5-0852-4f04-9c14-fc8d39a57c08@github.com>

On Tue, 16 May 2023 12:07:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > > I wonder if @Martin-Buchholz is able to look at this one?
> > > My concern with changes like this is that they fix an issue but then have unexpected side-effects themselves.
> > 
> > 
> > Are there any specific concerns you have?
> 
> There seems to be more going on here than just closing the write side of the pipe. We will now error out if any of the readFully's do a short read, rather than just when reporting an error - which on the surface seems like a good thing, but what if harmless short-reads can actually happen in some contexts?

I agree, it would be clearer to just to the close.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1549575144

From dfuchs at openjdk.org  Tue May 16 13:35:49 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 16 May 2023 13:35:49 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <DHtnnoADW3f5RUt0In8xkkrn09PAMAP-uQF-KUFS-9A=.c5b232c6-bf43-4f16-a0f9-4f9bed8eef69@github.com>

On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

Looks generally like a good improvement. In those places `toLowerCase` is called on strings (or substrings) that are expected to be ASCII, so using Locale.ROOT looks appropriate.
Would be good to get @Michael-Mc-Mahon validate these changes too.

src/java.base/share/classes/java/io/StreamTokenizer.java line 632:

> 630:             sval = String.copyValueOf(buf, 0, i);
> 631:             if (forceLower)
> 632:                 sval = sval.toLowerCase(Locale.ROOT);

This one gave me pause. AFAICS it's probably OK - but it might warant a CSR and an update of the specification to explicitly state how the lower case conversion is performed (update the `lowerCaseMode` method spec). Could we handle that in a separate PR?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1428569684
PR Review Comment: https://git.openjdk.org/jdk/pull/14006#discussion_r1195156280

From redestad at openjdk.org  Tue May 16 13:42:59 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 16 May 2023 13:42:59 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage [v2]
In-Reply-To: <l2Q_DjpYI9Rh5lBUzH_YclTIXR-R01VdApIBsPyOx_c=.1f5ef6f2-3e82-4b37-9144-0a4f2114f9b9@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
 <l2Q_DjpYI9Rh5lBUzH_YclTIXR-R01VdApIBsPyOx_c=.1f5ef6f2-3e82-4b37-9144-0a4f2114f9b9@github.com>
Message-ID: <AYpdDhGRzAcYJZyB-QXPfRIt1Qy_1NTKMIBbSLtFdA8=.ab461a31-0b4c-44de-adf2-74f452e03396@github.com>

On Thu, 11 May 2023 09:22:44 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> When appropriate and useful, copies only the relevant portion of the `CharSequence` to the match result.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added some randomness in tests.

Overall looks ok but the `captureText` usage in `Matcher::results` seem suspect.

src/java.base/share/classes/java/util/regex/Matcher.java line 359:

> 357:             if ((groups[group * 2] == -1) || (groups[group * 2 + 1] == -1))
> 358:                 return null;
> 359:             return text.subSequence(groups[group * 2] - offset, groups[group * 2 + 1] - offset).toString();

Could be simplified to `return text.substring(groups[group * 2] - offset, groups[group * 2 + 1] - offset);`

src/java.base/share/classes/java/util/regex/Matcher.java line 1381:

> 1379: 
> 1380:                 // Capture the input sequence as a string on first find
> 1381:                 textAsString = captureText();

Is this correct? The `find()` on line 1371 will set `first` and `last` and `captureText` uses that to narrow down `textAsString` to that range.. so the next `find()` will then find a new `first` and `last` pair but use the text captured after the first `find`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/13231#pullrequestreview-1428589260
PR Review Comment: https://git.openjdk.org/jdk/pull/13231#discussion_r1195169128
PR Review Comment: https://git.openjdk.org/jdk/pull/13231#discussion_r1195181270

From redestad at openjdk.org  Tue May 16 14:37:54 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 16 May 2023 14:37:54 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v7]
In-Reply-To: <9WXdnsx_lbXdDej1YqximLLEDLIWDTz_jxtSU7iRTsw=.b1b54d6f-c220-4eb0-96bb-1b263466a0b4@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <9WXdnsx_lbXdDej1YqximLLEDLIWDTz_jxtSU7iRTsw=.b1b54d6f-c220-4eb0-96bb-1b263466a0b4@github.com>
Message-ID: <ICjNfloIZQAxrQj37TN7rq4csTp7GUUNM0F5Yhe3bz0=.710b9c67-d55c-411a-aa12-a92bfaa0bd90@github.com>

On Tue, 16 May 2023 08:17:02 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Following improvements implemented:
>> - Switch over `String` replaced with switch single char
>> - Binary search for frames in `StackMapGenerator`
>> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
>> - `ClassEntry` is caching `ClassDesc` symbol
>> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
>> - Caching `MethodTypeDesc` in `MethodInfo` implementations
>> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
>> 
>> No API change.
>> 
>> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
>> 
>> 
>> Benchmark                     Mode  Cnt       Score       Error  Units
>> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
>> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
>> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
>> 
>> 
>> 
>> Benchmark                     Mode  Cnt       Score      Error  Units
>> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
>> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
>> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   LinkedList replaced with ArrayList in benchmarks

Looks like a good set of improvements for throughput cases. 

For the future I think we should probably add something that measures startup/warmup overheads of the classfile API, since it's likely that usage pattern in many applications will be heavy during bootstrap and then subside (similar to how ASM usage can be startup sensitive but will then disappear from sight once an application is up and running)

src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java line 83:

> 81:             vtis = new VerificationTypeInfo[methodType.parameterCount()];
> 82:         }
> 83:         for(var arg : methodType.parameterList()) {

`MethodTypeDesc::parameterList` copies the internal `ClassDesc[]`, so desugaring loop from `0` to `mdesc.parameterCount()` might be a small improvement for this and a few other cases.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13671#pullrequestreview-1428657206
PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1195248228

From ecaspole at openjdk.org  Tue May 16 14:38:47 2023
From: ecaspole at openjdk.org (Eric Caspole)
Date: Tue, 16 May 2023 14:38:47 GMT
Subject: RFR: 8307483: New micros for j.u.c.LockSupport [v3]
In-Reply-To: <q77A4CdvYIyasyM1E1QsuBpNbrJ_QaNeAWGhHKaWKdM=.0bfb5dea-c9bf-4325-b3aa-0f88f76fc845@github.com>
References: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
 <q77A4CdvYIyasyM1E1QsuBpNbrJ_QaNeAWGhHKaWKdM=.0bfb5dea-c9bf-4325-b3aa-0f88f76fc845@github.com>
Message-ID: <4Ia5-OM4Zp3STm7BDN7wB14kX6ackCZRTQzpyrnVi9Q=.8808963d-8c3b-4b59-b45f-e382b1de30f9@github.com>

On Tue, 9 May 2023 19:13:42 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> These micros were developed while investigating JDK-8305670 by myself and Sergey Kuksenko. The order of thread creation was important in that bug, so there are 2 JMH for creating sleepers before and after the worker threads.
>
> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add review comments changes.

I think I fixed all the commented items, could anyone look?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13815#issuecomment-1549803237

From itakiguchi at openjdk.org  Tue May 16 15:14:03 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 16 May 2023 15:14:03 GMT
Subject: RFR: 8308046: Move Solaris related Japanese charsets from
 java.base to jdk.charsets module [v2]
In-Reply-To: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
Message-ID: <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>

> According to "JDK 20 Internationalization Guide"
> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
> Following Solaris related Japanese charsets are in "contained in jdk.charsets module" list.
> 
> - PCK (x-PCK)
> - EUC_JP_Solaris (x-eucJP-Open)
> 
> These are not supported by Linux platform, so they should not be in java.base module.
> 
> Note:
> GHA Linux x86 builds were failed.
> I think it's not related by my modified code.
> I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-8308051) GHA: Linux x86 builds failure

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8308046: Move Solaris related Japanese charsets from java.base to jdk.charsets module

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13973/files
  - new: https://git.openjdk.org/jdk/pull/13973/files/192db59c..6fd12fcd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13973&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13973&range=00-01

  Stats: 29 lines in 3 files changed: 22 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13973.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13973/head:pull/13973

PR: https://git.openjdk.org/jdk/pull/13973

From liach at openjdk.org  Tue May 16 15:19:51 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 May 2023 15:19:51 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v7]
In-Reply-To: <ICjNfloIZQAxrQj37TN7rq4csTp7GUUNM0F5Yhe3bz0=.710b9c67-d55c-411a-aa12-a92bfaa0bd90@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <9WXdnsx_lbXdDej1YqximLLEDLIWDTz_jxtSU7iRTsw=.b1b54d6f-c220-4eb0-96bb-1b263466a0b4@github.com>
 <ICjNfloIZQAxrQj37TN7rq4csTp7GUUNM0F5Yhe3bz0=.710b9c67-d55c-411a-aa12-a92bfaa0bd90@github.com>
Message-ID: <d_uERMjLGg-OJo5uCT0Qo_QyLpLPDgUA14F0FwUq2aU=.e2a03cc6-4fd7-4ef0-a3c6-a8d3788592eb@github.com>

On Tue, 16 May 2023 14:23:04 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   LinkedList replaced with ArrayList in benchmarks
>
> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java line 83:
> 
>> 81:             vtis = new VerificationTypeInfo[methodType.parameterCount()];
>> 82:         }
>> 83:         for(var arg : methodType.parameterList()) {
> 
> `MethodTypeDesc::parameterList` copies the internal `ClassDesc[]`, so desugaring loop from `0` to `mdesc.parameterCount()` might be a small improvement for this and a few other cases.

I plan to share a backing list in #13186, with API additions so users can avoid copying their input immutable parameter list as well. I see no reason to use a direct array, for MTD is not passed to and used by the VM, unlike MethodType.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1195328671

From uschindler at apache.org  Tue May 16 15:38:32 2023
From: uschindler at apache.org (Uwe Schindler)
Date: Tue, 16 May 2023 17:38:32 +0200
Subject: JEP 442: Foreign Function & Memory API => why is it again preview API?
Message-ID: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>

Hi,

yesterday Apache Lucene got the information that JDK 21 got the project 
panama JEP 442 update and I implemented it already in our source tree.

Unfortunately the API is again marked "preview", but JDK 21 is "LTS 
release". Many of our users (Elasticserach, Solr) will be switching to 
this version. We were really hoping that the java.lang.foreign API is 
finished at that time. I checked the changes in our code: just a rename 
of a method and FileChannel#map now takes Arena instead of Scope.

Is it really needed to have a next round of preview API? Why not have 
Java 21 with Foreign API finalized in the same way like virtual threads? 
To me it is strange that an API like virtual threads was thrown to 
end-users (it caused problems at many places including slowdowns we have 
seen when preview was enabled in Java 19 and 20) in very short time (I 
never noticed a incubation period). In contrast the foreign memory API 
is very stable already since Java 19 and the changes were minimal in 21. 
It exists now since Java 14, where it first appeared as incubation. I 
know theres still work on the foreign linker, but why aren't the stable 
classes like MemorySegment, ValueLayout not public now?

This is really annoying to us. We were really planning to switch 
Lucene's main development to Java 21 LTS and ship it with modern memory 
mapping to our downstream projects.

Please do something and remove the @PreviewFeature from FileChannel#map 
and java.lang.foreign! Please, please, please!

Uwe

P.S.: Vector API is still in incubation, when will it go to preview?

-- 
Uwe Schindler
uschindler at apache.org
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/


From naoto at openjdk.org  Tue May 16 15:59:44 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 May 2023 15:59:44 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <E8ot4-f4CJyVS8gx-EF6NL6p9Q_QASWAYOk4aZfERcg=.0b7e9507-d3ca-4e72-9d0c-fb92f8273d6d@github.com>

On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

LGTM. Nice clean-up!

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1428917297

From Alan.Bateman at oracle.com  Tue May 16 16:07:37 2023
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 May 2023 17:07:37 +0100
Subject: JEP 442: Foreign Function & Memory API => why is it again preview
 API?
In-Reply-To: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
References: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
Message-ID: <1741f03e-383d-e40c-b236-2f1e39e7e2a7@oracle.com>

On 16/05/2023 16:38, Uwe Schindler wrote:
> :
>
> Is it really needed to have a next round of preview API? Why not have 
> Java 21 with Foreign API finalized in the same way like virtual 
> threads? To me it is strange that an API like virtual threads was 
> thrown to end-users (it caused problems at many places including 
> slowdowns we have seen when preview was enabled in Java 19 and 20) in 
> very short time (I never noticed a incubation period). 

Would it be possible to expand on "it caused problems at many places"? 
I'm wondering if there are issues that never made it to JBS.

As regards "slowdowns" with preview features enabled, I'm guessing you 
mean JDK-8300002 [1]. Can you confirm that these issues you observed do 
not exist with the JDK 21 EA builds?


> In contrast the foreign memory API is very stable already since Java 
> 19 and the changes were minimal in 21. It exists now since Java 14, 
> where it first appeared as incubation. I know theres still work on the 
> foreign linker, but why aren't the stable classes like MemorySegment, 
> ValueLayout not public now?

Are you on the panama-dev list? Maurizio sent status in December 2022 
[2]. JEP 442, proposing a 3rd preview, has been on the technical roadmap 
since March [3]. So it shouldn't be a big surprise. The memory APIs has 
been very difficult to get right, hats off to Maurizio and team for the 
persistence.

-Alan

[1] https://bugs.openjdk.org/browse/JDK-8300002
[2] https://mail.openjdk.org/pipermail/panama-dev/2022-December/018182.html
[3] https://mail.openjdk.org/pipermail/jdk-dev/2023-March/007473.html

From naoto at openjdk.org  Tue May 16 16:24:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 May 2023 16:24:13 GMT
Subject: RFR: 8307547: Support variant collations [v5]
In-Reply-To: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
Message-ID: <nIoWE4hN_63eeK9yH2FJ3JL1IYDqqo1Vq-ew9UD2K60=.baf89647-af31-4867-9e11-240ca3db159a@github.com>

> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Explicitly mention `Swedish` in the example.
 - Merge branch 'master' into JDK-8307547-multiple-collation
 - Added "reformed" tests
 - Review comments
 - http -> https
 - Test refinement
 - Clean-up
 - javadoc
 - 8307547: Support for multiple collation tables

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13917/files
  - new: https://git.openjdk.org/jdk/pull/13917/files/4ab39664..bfb19576

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13917&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13917&range=03-04

  Stats: 74851 lines in 982 files changed: 63014 ins; 5060 del; 6777 mod
  Patch: https://git.openjdk.org/jdk/pull/13917.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13917/head:pull/13917

PR: https://git.openjdk.org/jdk/pull/13917

From maurizio.cimadamore at oracle.com  Tue May 16 16:29:36 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 16 May 2023 17:29:36 +0100
Subject: JEP 442: Foreign Function & Memory API => why is it again preview
 API?
In-Reply-To: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
References: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
Message-ID: <e37bc72d-57dd-064f-5378-937c659820c4@oracle.com>


On 16/05/2023 16:38, Uwe Schindler wrote:
> It exists now since Java 14, where it first appeared as incubation. I 
> know theres still work on the foreign linker, but why aren't the 
> stable classes like MemorySegment, ValueLayout not public now?
Hi Uwe,

while I understand the frustration (and I'm grateful for the feedback 
you and others provided along the way), I think I disagree on this 
assessment. While it's true that layouts and segments have not changed 
much, the story about how to reason about the lifetime of a memory 
segment has. So, yes, MemorySegment per se has not changed, but the way 
in which you obtain segments has changed quite a bit.

Now, we could probably have finalized a subset of FFM which did *not* 
support linking of foreign function **and** deterministic deallocation. 
But would that have been useful? IIRC, Lucene has two main reasons to 
use FFM:

* deterministically unmap memory-mapped memory segments w/o using Unsafe
* mapping files that are bigger than 2GB

While a MemorySegment-only version of FFM would have allowed the latter, 
it would not have allowed for the former - meaning that there would be 
still part used by Lucene that would be under "preview".

So, while we have considered such a splitting move many times (believe 
me!), we always came up with the same conclusion: an FFM API w/o a story 
on lifetimes would not be very useful compared to what's already 
provided in the Java SE API.

Hopefully the lifetime-centric heavy-lifting is behind us. But I still 
think it would have been too risky to finalize the FFM API with a 
new-ish lifetime API that was not validated in the wild. As much as we 
try to be responsible with API changes, and do code analysis on the code 
using FFM code we know about, there's always a chance to miss something. 
For this reasons, I'm a strong believer that, when in doubt, the answer 
should always be "wait one more release" - at the end of the day that's 
why we have 6-month releases to begin with.

Cheers
Maurizio



From bpb at openjdk.org  Tue May 16 16:30:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 16 May 2023 16:30:08 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v5]
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <ymR2gUt7Hmp2K5RKYYOWNd6f5b02DbmJt3wg7DTNhC4=.c9c79507-7557-40da-90de-d4aeeb6d01fc@github.com>

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8308016: Reduce linking in File::toPath snippet

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13957/files
  - new: https://git.openjdk.org/jdk/pull/13957/files/da7c2004..724a74a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957

PR: https://git.openjdk.org/jdk/pull/13957

From psandoz at openjdk.org  Tue May 16 16:53:45 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 16 May 2023 16:53:45 GMT
Subject: RFR: 8287834: Add SymbolLookup::or method
In-Reply-To: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
References: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
Message-ID: <QkyJaqW1BgkJhUBnnoeF3VpN6mvAeo9leBY2eCday9Q=.a2b9f44e-c4fd-42d2-b6e8-0744f3646097@github.com>

On Fri, 12 May 2023 12:11:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds a simpler method for composing symbol lookups. It is common for clients to chain multiple symbol lookups together, e.g. to find a symbol in multiple libraries.
> 
> A new instance method, namely `SymbolLookup::or` is added, which first searches a symbol in the first lookup, and, if that fails, proceeds to search the symbol in the provided lookup.
> 
> We have considered alternatives to express this, such as a static factory `SymbolLookup::ofComposite` but settled on this because of the similarity with `Optional::or`.

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 136:

> 134:      * lookup} More specifically, if a symbol is not found using this lookup, the provided lookup will be
> 135:      * used as fallback. In other words, the resulting symbol lookup will only return {@linkplain Optional#empty()}
> 136:      * if both lookups fail to retrieve a given symbol.

Suggestion:

     * {@return a composed symbol lookup that returns result of finding the symbol with this lookup if found, otherwise returns the result of finding the symbol with the other lookup.}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13954#discussion_r1195440611

From mcimadamore at openjdk.org  Tue May 16 16:53:46 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 16 May 2023 16:53:46 GMT
Subject: RFR: 8287834: Add SymbolLookup::or method
In-Reply-To: <QkyJaqW1BgkJhUBnnoeF3VpN6mvAeo9leBY2eCday9Q=.a2b9f44e-c4fd-42d2-b6e8-0744f3646097@github.com>
References: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
 <QkyJaqW1BgkJhUBnnoeF3VpN6mvAeo9leBY2eCday9Q=.a2b9f44e-c4fd-42d2-b6e8-0744f3646097@github.com>
Message-ID: <j-nQKHfpHQ6Pac4ciTBWLSw_s5PXcs0MbmEpuNSZuu0=.48b5504a-a91b-46f1-9b24-b05a5f957b78@github.com>

On Tue, 16 May 2023 16:48:13 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This patch adds a simpler method for composing symbol lookups. It is common for clients to chain multiple symbol lookups together, e.g. to find a symbol in multiple libraries.
>> 
>> A new instance method, namely `SymbolLookup::or` is added, which first searches a symbol in the first lookup, and, if that fails, proceeds to search the symbol in the provided lookup.
>> 
>> We have considered alternatives to express this, such as a static factory `SymbolLookup::ofComposite` but settled on this because of the similarity with `Optional::or`.
>
> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 136:
> 
>> 134:      * lookup} More specifically, if a symbol is not found using this lookup, the provided lookup will be
>> 135:      * used as fallback. In other words, the resulting symbol lookup will only return {@linkplain Optional#empty()}
>> 136:      * if both lookups fail to retrieve a given symbol.
> 
> Suggestion:
> 
>      * {@return a composed symbol lookup that returns result of finding the symbol with this lookup if found, otherwise returns the result of finding the symbol with the other lookup.}

I was trying to split the sentence so that we could get a compact javadoc header for the factory. How much important is that?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13954#discussion_r1195443068

From psandoz at openjdk.org  Tue May 16 16:57:46 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 16 May 2023 16:57:46 GMT
Subject: RFR: 8287834: Add SymbolLookup::or method
In-Reply-To: <j-nQKHfpHQ6Pac4ciTBWLSw_s5PXcs0MbmEpuNSZuu0=.48b5504a-a91b-46f1-9b24-b05a5f957b78@github.com>
References: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
 <QkyJaqW1BgkJhUBnnoeF3VpN6mvAeo9leBY2eCday9Q=.a2b9f44e-c4fd-42d2-b6e8-0744f3646097@github.com>
 <j-nQKHfpHQ6Pac4ciTBWLSw_s5PXcs0MbmEpuNSZuu0=.48b5504a-a91b-46f1-9b24-b05a5f957b78@github.com>
Message-ID: <n-l0qfrkzPdW1sI4kxizdkkGg0gIu_qq9Be9x9y93mk=.088695a0-92aa-43fe-affd-bec0ab1875a7@github.com>

On Tue, 16 May 2023 16:50:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 136:
>> 
>>> 134:      * lookup} More specifically, if a symbol is not found using this lookup, the provided lookup will be
>>> 135:      * used as fallback. In other words, the resulting symbol lookup will only return {@linkplain Optional#empty()}
>>> 136:      * if both lookups fail to retrieve a given symbol.
>> 
>> Suggestion:
>> 
>>      * {@return a composed symbol lookup that returns result of finding the symbol with this lookup if found, otherwise returns the result of finding the symbol with the other lookup.}
>
> I was trying to split the sentence so that we could get a compact javadoc header for the factory. How much important is that?

Not very IHMO. I was just trying to say the same thing you said with less words, which makes it more amenable to being expressed as a compact javadoc header.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13954#discussion_r1195449970

From mcimadamore at openjdk.org  Tue May 16 17:06:02 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 16 May 2023 17:06:02 GMT
Subject: RFR: 8287834: Add SymbolLookup::or method [v2]
In-Reply-To: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
References: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
Message-ID: <SL9mvVvYZdA1OTHXsvvGpVZ7RVm6Dt8d0ApJgNqmCq0=.93ce3384-8aa3-48f4-9540-818312d1a42c@github.com>

> This patch adds a simpler method for composing symbol lookups. It is common for clients to chain multiple symbol lookups together, e.g. to find a symbol in multiple libraries.
> 
> A new instance method, namely `SymbolLookup::or` is added, which first searches a symbol in the first lookup, and, if that fails, proceeds to search the symbol in the provided lookup.
> 
> We have considered alternatives to express this, such as a static factory `SymbolLookup::ofComposite` but settled on this because of the similarity with `Optional::or`.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
  
  Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13954/files
  - new: https://git.openjdk.org/jdk/pull/13954/files/09637772..27e82bb6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13954&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13954&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13954/head:pull/13954

PR: https://git.openjdk.org/jdk/pull/13954

From mcimadamore at openjdk.org  Tue May 16 17:06:07 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 16 May 2023 17:06:07 GMT
Subject: RFR: 8287834: Add SymbolLookup::or method [v2]
In-Reply-To: <n-l0qfrkzPdW1sI4kxizdkkGg0gIu_qq9Be9x9y93mk=.088695a0-92aa-43fe-affd-bec0ab1875a7@github.com>
References: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
 <QkyJaqW1BgkJhUBnnoeF3VpN6mvAeo9leBY2eCday9Q=.a2b9f44e-c4fd-42d2-b6e8-0744f3646097@github.com>
 <j-nQKHfpHQ6Pac4ciTBWLSw_s5PXcs0MbmEpuNSZuu0=.48b5504a-a91b-46f1-9b24-b05a5f957b78@github.com>
 <n-l0qfrkzPdW1sI4kxizdkkGg0gIu_qq9Be9x9y93mk=.088695a0-92aa-43fe-affd-bec0ab1875a7@github.com>
Message-ID: <XgzOj7d4o1hrksH50uqB93xPQeWw3ivylDJ3y-AOH-8=.5a6293e9-7753-4ab0-84a9-bcdaa1197ad9@github.com>

On Tue, 16 May 2023 16:55:21 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> I was trying to split the sentence so that we could get a compact javadoc header for the factory. How much important is that?
>
> Not very IHMO. I was just trying to say the same thing you said with less words, which makes it more amenable to being expressed as a compact javadoc header.

ok - thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13954#discussion_r1195456129

From jlu at openjdk.org  Tue May 16 17:13:55 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 May 2023 17:13:55 GMT
Subject: Integrated: 8300794: Use @snippet in java.util:i18n
In-Reply-To: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
References: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
Message-ID: <u3DDR206bm3juimKufmuC5QY_Wm-Mecwzd9103ir60I=.2b3da974-2907-42d1-88a3-48a649be1699@github.com>

On Wed, 10 May 2023 23:54:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this javadoc only change which uses `@snippet` and `@linkplain` in i18n related util packages.

This pull request has now been integrated.

Changeset: 4e929918
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e92991809aa62cf98543a58bec352ab8a2c7b3d
Stats:     131 lines in 5 files changed: 9 ins; 24 del; 98 mod

8300794: Use @snippet in java.util:i18n

Reviewed-by: naoto, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/13920

From naoto at openjdk.org  Tue May 16 17:15:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 May 2023 17:15:46 GMT
Subject: RFR: 8308046: Move Solaris related Japanese charsets from
 java.base to jdk.charsets module [v2]
In-Reply-To: <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
Message-ID: <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>

On Tue, 16 May 2023 15:14:03 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> According to "JDK 20 Internationalization Guide"
>> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
>> Following Solaris related Japanese charsets are in "contained in jdk.charsets module" list.
>> 
>> - PCK (x-PCK)
>> - EUC_JP_Solaris (x-eucJP-Open)
>> 
>> These are not supported by Linux platform, so they should not be in java.base module.
>> 
>> Note:
>> GHA Linux x86 builds were failed.
>> I think it's not related by my modified code.
>> I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-8308051) GHA: Linux x86 builds failure
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308046: Move Solaris related Japanese charsets from java.base to jdk.charsets module

I now think it is better simply removing Solaris-related charsets, as moving them from java.base to jdk.charsets would require unnecessary code changes in non-Solaris code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1550062543

From uschindler at apache.org  Tue May 16 17:22:50 2023
From: uschindler at apache.org (Uwe Schindler)
Date: Tue, 16 May 2023 19:22:50 +0200
Subject: JEP 442: Foreign Function & Memory API => why is it again preview
 API?
In-Reply-To: <1741f03e-383d-e40c-b236-2f1e39e7e2a7@oracle.com>
References: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
 <1741f03e-383d-e40c-b236-2f1e39e7e2a7@oracle.com>
Message-ID: <e5657023-64a0-c568-4f76-12bda974b01a@apache.org>

Hi Alan,

Am 16.05.2023 um 18:07 schrieb Alan Bateman:
> On 16/05/2023 16:38, Uwe Schindler wrote:
>> :
>>
>> Is it really needed to have a next round of preview API? Why not have 
>> Java 21 with Foreign API finalized in the same way like virtual 
>> threads? To me it is strange that an API like virtual threads was 
>> thrown to end-users (it caused problems at many places including 
>> slowdowns we have seen when preview was enabled in Java 19 and 20) in 
>> very short time (I never noticed a incubation period). 
>
> Would it be possible to expand on "it caused problems at many places"? 
> I'm wondering if there are issues that never made it to JBS.

It was mainly the slowdowns when preview features were enabled. We were 
testing at the beginning with our nightly Lucene performance tests while 
preview was enabled at same time (reason was because at that time we had 
no way to enable MemorySegment for our users without them passing 
--enable-preview). So the combination caused a major slowdown especially 
when writing index files, but also some queries went down.

At first we thought it may be the MemorySegment API, but this changed 
soon later. The cool idea came after reading the preview API spec 
several times and thinking about how to get rid of the preview flag in 
our class files. Basically it works like the "--release" flag in JDK and 
the related "ct.sym" file, just simpified a bit.

Since Lucene 9.5 we now use MemorySegment preview API without requiring 
the user to enable it. At first (Lucene 9.5, Java 19 support only) we 
stipped the preview flag and later (Lucene 9.6, Java 19 and Java 20) we 
changed to another approach (see below). Users can still opt-out by a 
system property, but behind the scenes we changed our Gradle compilation 
logic to compile with our main compiler JDK (17 in main, 11 in Lucene 
9.x) against stubs of the new APIs etracted from Java 19, Java 20 and 
now also Java 21 (without those stubs, developers compiling Lucene would 
have needed to install Java 11/17 in addition to 19, 20, 21 for the 
MR-JAR parts which is not manageable, especially as Gradle doe not allow 
EA builds auto-provisioned). Those stubs extracted from JDK simply have 
the preview flag removed and are injected into compiler with 
patch-module. We carefully do all pre-checks against runtime version 
before enabling the API and loading the classes from the MR-JAR. But it 
allows our downstream users to use the API as if it would be officially 
supported.

When we compiled against our stubs and then no longer had to pass 
"--enable-preview", the nightly benchmarks got *much* faster; faster 
than with the problematic ByteBuffer API (which was the win we were all 
hoping of; in addition to safe unmapping of mmapped files. The speedup 
has to do with the fact that we can now memory map huge files in one go 
and are not limited to 2 Gigabytes adding a lot of branches in Lucene's 
code that cannot be optimized away).

So for Apache Lucene (+ Solr / Elasticserach) the MemorySegment API is a 
huge win. We have now already 2 releases with it (supporting Java 19 and 
Java 20) and it helps.

> As regards "slowdowns" with preview features enabled, I'm guessing you 
> mean JDK-8300002 [1]. Can you confirm that these issues you observed 
> do not exist with the JDK 21 EA builds?

Yes that's likely the reason. I had the feeling it was caused by the 
additional manual scheduling on waiting for IO in various 
InputStream/OutputStream/Files/... classes. This code in those classes 
is another thing why I hate the virtual threads so much: It makes some 
IO code in the JDK unreadable.

Another problem was/is memory exhaustion by people using ThreadLocals. 
We already removed all ThreadLocals from Lucene, so it is no longer an 
issue, but to me this all sounds like a release of something which is 
not ready for primetime.

We have not yet tested with Java 21 and "--enable-preview" flag enabled 
(as we no longer need it), but I will contact Mike McCandless to do it.

P.S.: Another reason why many core Lucene/SOlr/Elasticsearch people are 
unhappy about Virtual Threads is the statement by one of its maintainers 
that they are the reason for deprecation and removal of Security Manager 
without any useful replacement. So please excuse that I start this 
discussion again, it has to be said.

>> In contrast the foreign memory API is very stable already since Java 
>> 19 and the changes were minimal in 21. It exists now since Java 14, 
>> where it first appeared as incubation. I know theres still work on 
>> the foreign linker, but why aren't the stable classes like 
>> MemorySegment, ValueLayout not public now?
>
> Are you on the panama-dev list? Maurizio sent status in December 2022 
> [2]. JEP 442, proposing a 3rd preview, has been on the technical 
> roadmap since March [3]. So it shouldn't be a big surprise. The memory 
> APIs has been very difficult to get right, hats off to Maurizio and 
> team for the persistence.

Yes, I am working with Maurizio. I wrote this email to the main list in 
the hope you would change your mid and at least release the "stable" 
parts of the API. I got Maurizio's answer in the other mail.

It looks like we will create new stub JARs for the next JDK releases to 
compile against and need to add hard checks on used Java versions. 
That's fine with our compilation trick above, but it is a lot of work to 
maintain .java files for many Java versions so I had the hope that this 
ends and we can make our MR-JAR in a way that "starting with Java 21 
only a single set of classes is needed for all later versions".

If you have any questions about how the above compilation tricks work, I 
can give a close insight to anybody interested. The code is public 
available, the first PR adding Java 20 support is here: 
https://github.com/apache/lucene/pull/12188/files

The code for generating the stub files is also there.

Java 21 support for Lucene is here (it just adds new stubs): 
https://github.com/apache/lucene/pull/12294/files

Uwe

P.S.: Don't hurt me for programming around the preview limitations! It 
is all according to spec, it explicitely says you can use preview APIs 
with runtime checks and with own class files or reflection.

> -Alan
>
> [1] https://bugs.openjdk.org/browse/JDK-8300002
> [2] 
> https://mail.openjdk.org/pipermail/panama-dev/2022-December/018182.html
> [3] https://mail.openjdk.org/pipermail/jdk-dev/2023-March/007473.html

-- 
Uwe Schindler
uschindler at apache.org
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/


From forax at univ-mlv.fr  Tue May 16 17:28:23 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 16 May 2023 19:28:23 +0200 (CEST)
Subject: JEP 442: Foreign Function & Memory API => why is it again
 preview API?
In-Reply-To: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
References: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
Message-ID: <1496113050.56715554.1684258103469.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Uwe Schindler" <uschindler at apache.org>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Tuesday, May 16, 2023 5:38:32 PM
> Subject: JEP 442: Foreign Function & Memory API => why is it again preview API?

> Hi,

Hi Uwe,

> 
> yesterday Apache Lucene got the information that JDK 21 got the project
> panama JEP 442 update and I implemented it already in our source tree.
> 
> Unfortunately the API is again marked "preview", but JDK 21 is "LTS
> release". Many of our users (Elasticserach, Solr) will be switching to
> this version. We were really hoping that the java.lang.foreign API is
> finished at that time. I checked the changes in our code: just a rename
> of a method and FileChannel#map now takes Arena instead of Scope.

I see that Alan and Maurizio have already answer to your other points.

Having preview features and being a LTS are to separate concerns.
Being a LTS is about support, having preview features is about having feedback before finalizing an API.

Java 17 was released with preview features, Java 21 will be.

Before Java 10, when we were doing feature release model, if a feature was not ready yet, either the release was delayed (Java 9 was delayed 3 times if i'm remembering correctly) or postponed to the next big release (Java Module was initially scheduled for Java 8). With the new cadence model, features that are not ready yet are marked as preview.

I understand that you are eager to use MemorySegment in anger but since a looong time, Java features are only released when they are ready :)

Also, it seems that we will have a LTS release every two years now, if a LTS had no preview, it means that we will not get any feedback for 1/4 of the releases.

> 
> Uwe
> 

regards,
R?mi

> 
> --
> Uwe Schindler
> uschindler at apache.org
> ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
> Bremen, Germany
> https://lucene.apache.org/
> https://solr.apache.org/

From javalists at cbfiddle.com  Tue May 16 17:46:27 2023
From: javalists at cbfiddle.com (Alan Snyder)
Date: Tue, 16 May 2023 10:46:27 -0700
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <1391d41f-b4b4-1449-94c6-7e91e58cb7aa@oracle.com>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
 <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
 <CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com>
 <46167980-41fe-e214-9b67-ce0c5ca8c032@oracle.com>
 <CABe8uE2n2ozgJzRk_N-a2Pq37FTBJtWJhuxKUT6KG+2hR0TZLg@mail.gmail.com>
 <df447921-ebc1-e683-70f0-54da9b6621d0@oracle.com>
 <1391d41f-b4b4-1449-94c6-7e91e58cb7aa@oracle.com>
Message-ID: <132FCECD-8D9A-4ACE-8C99-E0FE61A17CA8@cbfiddle.com>

I have not seen any explanation of how this issue is going to be resolved.

Given the new information, shouldn?t the CSR review be reopened to re-evaluate the cost/benefit analysis?


From naoto at openjdk.org  Tue May 16 18:03:56 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 May 2023 18:03:56 GMT
Subject: Integrated: 8307547: Support variant collations
In-Reply-To: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
Message-ID: <czWB0_KwhsYOovbrkSzFlbur6ZSxiRqmtl6GY9K40qE=.afa73ad6-130a-4e4f-b1b9-e6a1edb8b1ae@github.com>

On Wed, 10 May 2023 20:11:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.

This pull request has now been integrated.

Changeset: f9a785e8
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f9a785e855287ff6746ac8dc8f8f2e2f90c5be07
Stats:     80 lines in 4 files changed: 61 ins; 8 del; 11 mod

8307547: Support variant collations

Reviewed-by: srl, jlu, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/13917

From liangchenblue at gmail.com  Tue May 16 18:03:51 2023
From: liangchenblue at gmail.com (-)
Date: Tue, 16 May 2023 13:03:51 -0500
Subject: JEP 442: Foreign Function & Memory API => why is it again preview
 API?
In-Reply-To: <1496113050.56715554.1684258103469.JavaMail.zimbra@univ-eiffel.fr>
References: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
 <1496113050.56715554.1684258103469.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <CABe8uE1FkrsVndoa2YvgNXf2AniU71M+P-mqvq_qFvcAB4WR+g@mail.gmail.com>

For FFI, I would prefer some parts of the FFI, especially generic ones
like Indirect Var Handles, to be promoted from the preview status.
They are useful for non-FFI purposes.
Has FFI API considered promoting APIs out of preview incrementally,
like how Virtual Threads and Scoped values are?

Chen Liang


On Tue, May 16, 2023 at 12:28?PM Remi Forax <forax at univ-mlv.fr> wrote:
>
> ----- Original Message -----
> > From: "Uwe Schindler" <uschindler at apache.org>
> > To: "core-libs-dev" <core-libs-dev at openjdk.org>
> > Sent: Tuesday, May 16, 2023 5:38:32 PM
> > Subject: JEP 442: Foreign Function & Memory API => why is it again preview API?
>
> > Hi,
>
> Hi Uwe,
>
> >
> > yesterday Apache Lucene got the information that JDK 21 got the project
> > panama JEP 442 update and I implemented it already in our source tree.
> >
> > Unfortunately the API is again marked "preview", but JDK 21 is "LTS
> > release". Many of our users (Elasticserach, Solr) will be switching to
> > this version. We were really hoping that the java.lang.foreign API is
> > finished at that time. I checked the changes in our code: just a rename
> > of a method and FileChannel#map now takes Arena instead of Scope.
>
> I see that Alan and Maurizio have already answer to your other points.
>
> Having preview features and being a LTS are to separate concerns.
> Being a LTS is about support, having preview features is about having feedback before finalizing an API.
>
> Java 17 was released with preview features, Java 21 will be.
>
> Before Java 10, when we were doing feature release model, if a feature was not ready yet, either the release was delayed (Java 9 was delayed 3 times if i'm remembering correctly) or postponed to the next big release (Java Module was initially scheduled for Java 8). With the new cadence model, features that are not ready yet are marked as preview.
>
> I understand that you are eager to use MemorySegment in anger but since a looong time, Java features are only released when they are ready :)
>
> Also, it seems that we will have a LTS release every two years now, if a LTS had no preview, it means that we will not get any feedback for 1/4 of the releases.
>
> >
> > Uwe
> >
>
> regards,
> R?mi
>
> >
> > --
> > Uwe Schindler
> > uschindler at apache.org
> > ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
> > Bremen, Germany
> > https://lucene.apache.org/
> > https://solr.apache.org/

From liach at openjdk.org  Tue May 16 18:10:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 May 2023 18:10:08 GMT
Subject: RFR: 8306457: Classfile API components implementations should not
 be exposed [v3]
In-Reply-To: <67PAXfiqaTaU8vYbbA31WJBG029RHK454HIDp5ZlYx8=.ec9b4ddd-fe42-4236-9e44-ef63e164e906@github.com>
References: <67PAXfiqaTaU8vYbbA31WJBG029RHK454HIDp5ZlYx8=.ec9b4ddd-fe42-4236-9e44-ef63e164e906@github.com>
Message-ID: <uOL-fvFa6_nzRHkr26MzBSBbo7cF3SMvvJRsXTAxHSk=.1a1c786d-a90e-4a9f-9e04-234a09447bb0@github.com>

> The jdk.internal.classfile.components package's interfaces have implementations in their nested classes, which are implicitly public and exported with the package. They are now moved to the impl package to avoid unwanted exposures. Fixed a few minor javadoc issues in the interfaces as well.
> 
> In conflict with #13021; one needs updating if the other is merged.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Don't change formatting in the migration
   
   The changes are done by copying old implementation and removing one level (4 spaces) of indent.
   The constructors of CodeLocalsShifterImpl and CodeStackTrackerImpl are promoted to public
 - Merge branch 'master' into fix/hide-component-impl
 - merge indy remap fix
 - Merge branch 'master' into fix/hide-component-impl
 - 8306457: Classfile API components implementations should not be exposed

-------------

Changes: https://git.openjdk.org/jdk/pull/13541/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13541&range=02
  Stats: 1815 lines in 8 files changed: 963 ins; 826 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/13541.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13541/head:pull/13541

PR: https://git.openjdk.org/jdk/pull/13541

From liach at openjdk.org  Tue May 16 18:10:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 May 2023 18:10:09 GMT
Subject: RFR: 8306457: Classfile API components implementations should not
 be exposed [v2]
In-Reply-To: <Cx6lfCV6bwkUp5dyRpHOfIJtwg18eoGB1nMQxXQRmv4=.495cdea9-7422-41de-95d4-9e52a8403f5d@github.com>
References: <67PAXfiqaTaU8vYbbA31WJBG029RHK454HIDp5ZlYx8=.ec9b4ddd-fe42-4236-9e44-ef63e164e906@github.com>
 <Cx6lfCV6bwkUp5dyRpHOfIJtwg18eoGB1nMQxXQRmv4=.495cdea9-7422-41de-95d4-9e52a8403f5d@github.com>
Message-ID: <TaNA3Js7wgGK4lEn2kxZiU73_PZx2AMsVp75mo8phSA=.90233d03-ff2b-445b-96ae-f1afdadb5c47@github.com>

On Sat, 13 May 2023 14:11:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The jdk.internal.classfile.components package's interfaces have implementations in their nested classes, which are implicitly public and exported with the package. They are now moved to the impl package to avoid unwanted exposures. Fixed a few minor javadoc issues in the interfaces as well.
>> 
>> In conflict with #13021; one needs updating if the other is merged.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - merge indy remap fix
>  - Merge branch 'master' into fix/hide-component-impl
>  - 8306457: Classfile API components implementations should not be exposed

I've kept the formatting by simply removing the extra indent in the beginning. However, the two implementation constructors need to be promoted to public in order to be accessible from outside of the impl package.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13541#issuecomment-1550132988

From lmesnik at openjdk.org  Tue May 16 18:15:48 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 May 2023 18:15:48 GMT
Subject: RFR: 8308223: failure handler missed jcmd.vm.info command
Message-ID: <kvBLgW9LDqqGnR8JlO00SrM-qo2lPop7pV-MDyxAlNI=.ec99024a-7fda-4371-a1ce-c555794940e0@github.com>

Trivial fix that added missed useful command.
Tested by running make of failure handler and verifying results.

-------------

Commit messages:
 - 8308223

Changes: https://git.openjdk.org/jdk/pull/14018/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14018&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308223
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14018.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14018/head:pull/14018

PR: https://git.openjdk.org/jdk/pull/14018

From liach at openjdk.org  Tue May 16 18:20:45 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 May 2023 18:20:45 GMT
Subject: RFR: 8307326: Package jdk.internal.classfile.java.lang.constant
 become obsolete
In-Reply-To: <B7NPhT_4RixzCii1LIEVkwMrP6qNASaeOQ9Y2v9lPhk=.f9f9ca1e-9b8b-4b73-ad73-d882e35956db@github.com>
References: <B7NPhT_4RixzCii1LIEVkwMrP6qNASaeOQ9Y2v9lPhk=.f9f9ca1e-9b8b-4b73-ad73-d882e35956db@github.com>
Message-ID: <5CjNjAQme8BTCA-TJzjjV8Zb7e-xYvuHvQENi7nUkrs=.5c407434-4d8f-42a7-aec6-37961ea9afe3@github.com>

On Mon, 15 May 2023 08:38:54 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). 
> All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and  `java.lang.constant.PackageDesc`. 
> `jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. 
> Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted.
> Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed:
> - `PackageDesc::packageName` to `PackageDesc::name`
> - `PackageDesc::packageInternalName` to `PackageDesc::internalName`
> - `ModuleDesc::moduleName` to `ModuleDesc::name`.
> 
> Please review this pull request.
> 
> Thanks,
> Adam

I think these are all the occurrences of jdk.internal.classfile.java.lang.constant package.

-------------

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/13979#pullrequestreview-1429153817

From psandoz at openjdk.org  Tue May 16 18:28:45 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 16 May 2023 18:28:45 GMT
Subject: RFR: 8287834: Add SymbolLookup::or method [v2]
In-Reply-To: <SL9mvVvYZdA1OTHXsvvGpVZ7RVm6Dt8d0ApJgNqmCq0=.93ce3384-8aa3-48f4-9540-818312d1a42c@github.com>
References: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
 <SL9mvVvYZdA1OTHXsvvGpVZ7RVm6Dt8d0ApJgNqmCq0=.93ce3384-8aa3-48f4-9540-818312d1a42c@github.com>
Message-ID: <Fsmjz_6HtXzhzfzZSPnac_mCnX3F8NMzXwp7XxscgoA=.d1214a43-e4ff-4dd5-8a5a-11ed1a5bfa95@github.com>

On Tue, 16 May 2023 17:06:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds a simpler method for composing symbol lookups. It is common for clients to chain multiple symbol lookups together, e.g. to find a symbol in multiple libraries.
>> 
>> A new instance method, namely `SymbolLookup::or` is added, which first searches a symbol in the first lookup, and, if that fails, proceeds to search the symbol in the provided lookup.
>> 
>> We have considered alternatives to express this, such as a static factory `SymbolLookup::ofComposite` but settled on this because of the similarity with `Optional::or`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/foreign/SymbolLookup.java
>   
>   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13954#pullrequestreview-1429165729

From alanb at openjdk.org  Tue May 16 18:34:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 May 2023 18:34:50 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v13]
In-Reply-To: <9ftk4o0DvBHN-oDAlW6nW7_oM_KU8k3ZBzezvgfKWwM=.ec49936e-68a8-4b6c-a8bd-ed8c70ef3faf@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <85gf2eJXSscffZvQgEhmfebusZ2IhfFM2W-z-4pDIms=.aa5e47b5-6e8d-4b05-9b04-66359ca1a60d@github.com>
 <YQu1NA0gSzxBm3Lqvav5icMcifbVgM7Edw198SZ6wcU=.f6d73183-03a4-453d-b2c4-17ff0986590e@github.com>
 <9ftk4o0DvBHN-oDAlW6nW7_oM_KU8k3ZBzezvgfKWwM=.ec49936e-68a8-4b6c-a8bd-ed8c70ef3faf@github.com>
Message-ID: <90pfraspjRWfTepdB2XMf4siiN6ZFqCTh2Byn8UoI_M=.5d15d232-1589-4455-8c9e-61d86ec013f6@github.com>

On Mon, 15 May 2023 17:05:48 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> InstanceMainTest does check precedence. Are you expecting a test for all combinations?

Sorry, we discussed this in previous comments, ignore my latest comment on this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1194221553

From jlaskey at openjdk.org  Tue May 16 18:34:49 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 16 May 2023 18:34:49 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v15]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <DATc1bDAoNCAu4N3OiscPyG4Pc5u-3XtLZBR1xVntlo=.166bf13f-33b5-4594-b7a8-9f1b1eb84ea5@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Merge branch 'master' into 8306112
 - Requested Changes #2
 - Update VirtualParser.java
 - Merge branch 'master' into 8306112
 - Refactor source code launcher
 - Typo
 - Recommended changes #2
 - Anonymous main classes renamed to unnamed classes
 - Add test
 - Move AnonymousMainClass to parser
 - ... and 19 more: https://git.openjdk.org/jdk/compare/316bc79e...185532a8

-------------

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=14
  Stats: 1234 lines in 28 files changed: 1069 ins; 77 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From stefank at openjdk.org  Tue May 16 18:36:45 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 May 2023 18:36:45 GMT
Subject: RFR: 8308223: failure handler missed jcmd.vm.info command
In-Reply-To: <kvBLgW9LDqqGnR8JlO00SrM-qo2lPop7pV-MDyxAlNI=.ec99024a-7fda-4371-a1ce-c555794940e0@github.com>
References: <kvBLgW9LDqqGnR8JlO00SrM-qo2lPop7pV-MDyxAlNI=.ec99024a-7fda-4371-a1ce-c555794940e0@github.com>
Message-ID: <rNr8E0nGq8nzOnGQVvUVGTIWGL7DKtx_OG0fqXCdxnk=.23ec271e-460e-4dea-a932-dd45411af3bc@github.com>

On Tue, 16 May 2023 18:07:16 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Trivial fix that added missed useful command.
> Tested by running make of failure handler and verifying results.

This looks good and "trivial". Thanks for fixing this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14018#issuecomment-1550170733

From stefank at openjdk.org  Tue May 16 19:43:45 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 16 May 2023 19:43:45 GMT
Subject: RFR: 8308223: failure handler missed jcmd.vm.info command
In-Reply-To: <kvBLgW9LDqqGnR8JlO00SrM-qo2lPop7pV-MDyxAlNI=.ec99024a-7fda-4371-a1ce-c555794940e0@github.com>
References: <kvBLgW9LDqqGnR8JlO00SrM-qo2lPop7pV-MDyxAlNI=.ec99024a-7fda-4371-a1ce-c555794940e0@github.com>
Message-ID: <BCOMGbbvBhHiaUbXebVrC416GgKPMFddAz6Dj6daxjM=.f6036ebc-4f9e-404f-9c99-ad2071c7d71d@github.com>

On Tue, 16 May 2023 18:07:16 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Trivial fix that added missed useful command.
> Tested by running make of failure handler and verifying results.

Marked as reviewed by stefank (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14018#pullrequestreview-1429289984

From lmesnik at openjdk.org  Tue May 16 19:47:52 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 16 May 2023 19:47:52 GMT
Subject: Integrated: 8308223: failure handler missed jcmd.vm.info command
In-Reply-To: <kvBLgW9LDqqGnR8JlO00SrM-qo2lPop7pV-MDyxAlNI=.ec99024a-7fda-4371-a1ce-c555794940e0@github.com>
References: <kvBLgW9LDqqGnR8JlO00SrM-qo2lPop7pV-MDyxAlNI=.ec99024a-7fda-4371-a1ce-c555794940e0@github.com>
Message-ID: <c4tpp-bjCbI4QvXltaCAxZ40to9gfQ8Zngjsodowx1w=.cf1ac7d3-ebea-445f-8882-f38b2f12580c@github.com>

On Tue, 16 May 2023 18:07:16 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> Trivial fix that added missed useful command.
> Tested by running make of failure handler and verifying results.

This pull request has now been integrated.

Changeset: 563152f3
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/563152f32dd2c8617c0e0955d55c5bbce23627fb
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8308223: failure handler missed jcmd.vm.info command

Reviewed-by: stefank

-------------

PR: https://git.openjdk.org/jdk/pull/14018

From darcy at openjdk.org  Tue May 16 21:41:47 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 16 May 2023 21:41:47 GMT
Subject: RFR: JDK-8308239: Tighten up accessibility of nested classes in
 java.lang.invoke
Message-ID: <IsG1KyYI7vkg1D422gDL-v3OQ73Ji5ykXkAjlNqZQd0=.ab31339c-3b06-4d3b-a7cd-08660b6313be@github.com>

Tightening up accessibility of a few nested classes. There is no practical impact on source compatibility -- source uses within the package still work, but by default the ability to reflectively call methods on these classes is disabled.

-------------

Commit messages:
 - JDK-8308239: Tighten up accessibility of nested classes in java.lang.invoke

Changes: https://git.openjdk.org/jdk/pull/14021/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14021&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308239
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14021.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14021/head:pull/14021

PR: https://git.openjdk.org/jdk/pull/14021

From redestad at openjdk.org  Tue May 16 22:02:51 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 16 May 2023 22:02:51 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v7]
In-Reply-To: <d_uERMjLGg-OJo5uCT0Qo_QyLpLPDgUA14F0FwUq2aU=.e2a03cc6-4fd7-4ef0-a3c6-a8d3788592eb@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <9WXdnsx_lbXdDej1YqximLLEDLIWDTz_jxtSU7iRTsw=.b1b54d6f-c220-4eb0-96bb-1b263466a0b4@github.com>
 <ICjNfloIZQAxrQj37TN7rq4csTp7GUUNM0F5Yhe3bz0=.710b9c67-d55c-411a-aa12-a92bfaa0bd90@github.com>
 <d_uERMjLGg-OJo5uCT0Qo_QyLpLPDgUA14F0FwUq2aU=.e2a03cc6-4fd7-4ef0-a3c6-a8d3788592eb@github.com>
Message-ID: <JMh5XDNYbKwuiuaQ-NcDvE6oA7nd1SrEABXEaApkLBc=.4883ba6b-1096-4005-879a-99d8dc2085d6@github.com>

On Tue, 16 May 2023 15:17:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/StackMapDecoder.java line 83:
>> 
>>> 81:             vtis = new VerificationTypeInfo[methodType.parameterCount()];
>>> 82:         }
>>> 83:         for(var arg : methodType.parameterList()) {
>> 
>> `MethodTypeDesc::parameterList` copies the internal `ClassDesc[]`, so desugaring loop from `0` to `mdesc.parameterCount()` might be a small improvement for this and a few other cases.
>
> I plan to share a backing list in #13186, with API additions so users can avoid copying their input immutable parameter list as well. I see no reason to use a direct array, for MTD is not passed to and used by the VM, unlike MethodType.

Good, I think it makes perfect sense for the MTD parameter list to be immutable and shareable without copying.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1195727321

From cjplummer at openjdk.org  Tue May 16 22:09:38 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 16 May 2023 22:09:38 GMT
Subject: RFR: 8308237: add JDWP and JDI virtual thread support for
 ThreadReference.PopFrames
Message-ID: <1UYSdhYj2QWeUbXOny3Rx_oQi9FLWAqRQ88HasIzJkY=.52abb21a-53e7-4c5c-b8c3-0a91d4c0edd6@github.com>

This is a follow-on to [JDK-8264699](https://bugs.openjdk.org/browse/JDK-8264699) which adds JVMTI PopFrames support for virtual thread. For JDWP and JDI this is mostly a spec update, although JDI needs minor changes to properly throw the correct exception. Note this PR needs JDK-8264699 in order to function properly, so there may be some GHA failures until JDK-8264699 is pushed.

There are a large number of tests that can now be removed from the problem list. Also, one test needs to be modified to no longer expect OpaqueFrameException for virtual threads. It was just revereted back to it's previous form before the OpaqueFrameException support was added for virtual threads.

As you can see from the problemlist update, there are quite a few tests for popFrames() support. However, there are still two coverage gaps:

- There is no test for throwing NativeMethodException (even for platform threads)
- There is no test case for throwing OpaqueFrameException when the virtual thread is suspended but not mounted.

I may eventually add one or both tests to the PR, or I may just file separate CRs for them for now.

-------------

Commit messages:
 - Add virtual thread popframes support the jdwp and jdi

Changes: https://git.openjdk.org/jdk/pull/14022/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14022&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308237
  Stats: 80 lines in 6 files changed: 13 ins; 50 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14022.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14022/head:pull/14022

PR: https://git.openjdk.org/jdk/pull/14022

From mcimadamore at openjdk.org  Tue May 16 22:36:51 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 16 May 2023 22:36:51 GMT
Subject: RFR: 8287834: Add SymbolLookup::or method [v3]
In-Reply-To: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
References: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
Message-ID: <eKYQGgn3rNM_La_IPkLoe6KatVEU5iZz-csW6dSecsY=.9787f082-a963-4c6a-9ad4-4916eeb6110f@github.com>

> This patch adds a simpler method for composing symbol lookups. It is common for clients to chain multiple symbol lookups together, e.g. to find a symbol in multiple libraries.
> 
> A new instance method, namely `SymbolLookup::or` is added, which first searches a symbol in the first lookup, and, if that fails, proceeds to search the symbol in the provided lookup.
> 
> We have considered alternatives to express this, such as a static factory `SymbolLookup::ofComposite` but settled on this because of the similarity with `Optional::or`.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13954/files
  - new: https://git.openjdk.org/jdk/pull/13954/files/27e82bb6..76578973

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13954&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13954&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13954.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13954/head:pull/13954

PR: https://git.openjdk.org/jdk/pull/13954

From maurizio.cimadamore at oracle.com  Tue May 16 22:41:50 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 16 May 2023 23:41:50 +0100
Subject: JEP 442: Foreign Function & Memory API => why is it again preview
 API?
In-Reply-To: <CABe8uE1FkrsVndoa2YvgNXf2AniU71M+P-mqvq_qFvcAB4WR+g@mail.gmail.com>
References: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
 <1496113050.56715554.1684258103469.JavaMail.zimbra@univ-eiffel.fr>
 <CABe8uE1FkrsVndoa2YvgNXf2AniU71M+P-mqvq_qFvcAB4WR+g@mail.gmail.com>
Message-ID: <bc2b336f-a205-e8d8-ed68-76d49c9b2d2e@oracle.com>


On 16/05/2023 19:03, - wrote:
> For FFI, I would prefer some parts of the FFI, especially generic ones
> like Indirect Var Handles, to be promoted from the preview status.
> They are useful for non-FFI purposes.
These parts (e.g. the additional var handle combinators in 
MethodHandles) are the only ones that could be finalized independently 
of the remainder of the FFM API, yes.
> Has FFI API considered promoting APIs out of preview incrementally,
> like how Virtual Threads and Scoped values are?

See my other email. FFM is composed of two biggie APIs, one for managing 
memory, and one for linking foreign functions. The lifetime abstractions 
cut across both APIs (and so do memory layouts, which are used to deal 
with memory dereference, but also to describe foreign types for the 
linker). So, I don't think there were ever concrete opportunities to 
split the two APIs (even if it would have been nice to do that).

Sometimes features can be decomposed nicely, and delivered 
incrementally. That has been the case for most Amber features, and also 
for Loom. Other times it is less practical to do so, as for FFM API, and 
patterns in switch + record patterns.

Maurizio

>
> Chen Liang
>
>
> On Tue, May 16, 2023 at 12:28?PM Remi Forax <forax at univ-mlv.fr> wrote:
>> ----- Original Message -----
>>> From: "Uwe Schindler" <uschindler at apache.org>
>>> To: "core-libs-dev" <core-libs-dev at openjdk.org>
>>> Sent: Tuesday, May 16, 2023 5:38:32 PM
>>> Subject: JEP 442: Foreign Function & Memory API => why is it again preview API?
>>> Hi,
>> Hi Uwe,
>>
>>> yesterday Apache Lucene got the information that JDK 21 got the project
>>> panama JEP 442 update and I implemented it already in our source tree.
>>>
>>> Unfortunately the API is again marked "preview", but JDK 21 is "LTS
>>> release". Many of our users (Elasticserach, Solr) will be switching to
>>> this version. We were really hoping that the java.lang.foreign API is
>>> finished at that time. I checked the changes in our code: just a rename
>>> of a method and FileChannel#map now takes Arena instead of Scope.
>> I see that Alan and Maurizio have already answer to your other points.
>>
>> Having preview features and being a LTS are to separate concerns.
>> Being a LTS is about support, having preview features is about having feedback before finalizing an API.
>>
>> Java 17 was released with preview features, Java 21 will be.
>>
>> Before Java 10, when we were doing feature release model, if a feature was not ready yet, either the release was delayed (Java 9 was delayed 3 times if i'm remembering correctly) or postponed to the next big release (Java Module was initially scheduled for Java 8). With the new cadence model, features that are not ready yet are marked as preview.
>>
>> I understand that you are eager to use MemorySegment in anger but since a looong time, Java features are only released when they are ready :)
>>
>> Also, it seems that we will have a LTS release every two years now, if a LTS had no preview, it means that we will not get any feedback for 1/4 of the releases.
>>
>>> Uwe
>>>
>> regards,
>> R?mi
>>
>>> --
>>> Uwe Schindler
>>> uschindler at apache.org
>>> ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
>>> Bremen, Germany
>>> https://lucene.apache.org/
>>> https://solr.apache.org/

From jhendrikx at openjdk.org  Wed May 17 01:33:55 2023
From: jhendrikx at openjdk.org (John Hendrikx)
Date: Wed, 17 May 2023 01:33:55 GMT
Subject: RFR: 8287834: Add SymbolLookup::or method [v3]
In-Reply-To: <eKYQGgn3rNM_La_IPkLoe6KatVEU5iZz-csW6dSecsY=.9787f082-a963-4c6a-9ad4-4916eeb6110f@github.com>
References: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
 <eKYQGgn3rNM_La_IPkLoe6KatVEU5iZz-csW6dSecsY=.9787f082-a963-4c6a-9ad4-4916eeb6110f@github.com>
Message-ID: <3KOWkW5WxXz7Kc-NXg4UHzB9Om6hXCCkMxsedHDfMJU=.f0e6ef27-71b0-4fea-b89a-682b3acfdac4@github.com>

On Tue, 16 May 2023 22:36:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds a simpler method for composing symbol lookups. It is common for clients to chain multiple symbol lookups together, e.g. to find a symbol in multiple libraries.
>> 
>> A new instance method, namely `SymbolLookup::or` is added, which first searches a symbol in the first lookup, and, if that fails, proceeds to search the symbol in the provided lookup.
>> 
>> We have considered alternatives to express this, such as a static factory `SymbolLookup::ofComposite` but settled on this because of the similarity with `Optional::or`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak javadoc

Isn't it already possible to easily create a composed `SymbolLookup`?

     SymbolLookup lookUp = name -> library1.find(name)
          .or(() -> library2.find(name))
          .or(() -> loader.find(name));

The proposed method may be a bit nicer, but it is sort of duplicating what `Optional::or` was intended for.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13954#issuecomment-1550560151

From duke at openjdk.org  Wed May 17 02:32:56 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Wed, 17 May 2023 02:32:56 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v6]
In-Reply-To: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
Message-ID: <jcpe28LzmXpGO4YE5eP6fF-RBEg-O2iUMP0EphSCox8=.6f398f44-463c-474a-8428-ee0afa09ff18@github.com>

> I fixed File.listRoots description.
> * remove "the insertion or ejection of removable media"
> * change "available" to "existing"
> 
> Please review this change.

Nagata-Haruhito has updated the pull request incrementally with three additional commits since the last revision:

 - Merge branch 'File_javadoc' of https://github.com/Nagata-Haruhito/jdk into File_javadoc
 - Drop exist to available
 - Merge branch 'master' into File_javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13526/files
  - new: https://git.openjdk.org/jdk/pull/13526/files/787f71a1..7ba2460a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13526&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13526&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13526/head:pull/13526

PR: https://git.openjdk.org/jdk/pull/13526

From duke at openjdk.org  Wed May 17 02:39:47 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Wed, 17 May 2023 02:39:47 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v5]
In-Reply-To: <Kj8cJuc9CvjQ5q3OmHrLLuTPsJiVZXQsMRZcLgjH3T4=.810d597d-7cf7-460e-b028-0dafe9d7c2f0@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <CxiJ8tPpIHLtciNPHot9NCsDOQVBLOc_eTaF1RbawR4=.65c77760-e4ef-4ce2-b403-c14647e413fe@github.com>
 <Kj8cJuc9CvjQ5q3OmHrLLuTPsJiVZXQsMRZcLgjH3T4=.810d597d-7cf7-460e-b028-0dafe9d7c2f0@github.com>
Message-ID: <yVRmFo3Wjkp8kZbo2KonPNH3HZvEEoWAGqfHUSTPiqo=.40b7700d-b083-4d7d-b32d-863a2f6209c8@github.com>

On Tue, 16 May 2023 06:53:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Nagata-Haruhito has updated the pull request with a new target base 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 'openjdk:master' into File_javadoc
>>  - Merge branch 'openjdk:master' into File_javadoc
>>  - 8306431: The documentation of File.listRoots should be modifid after JDK-8208077
>>  - 8306431: File.listRoots method description should be re-examined
>
> src/java.base/share/classes/java/io/File.java line 1819:
> 
>> 1817:      *
>> 1818:      * <p> This method returns an array of {@code File} objects that denote the
>> 1819:      * root directories of the existing filesystem roots.  It is guaranteed
> 
> I don't think you can change "available" to "existing" here without a lot more discussion. In particular, the javadoc can't set the expectation that "existing" implies that File::exists will return true, it might not. So I think drop this from the change.

Thanks for your comment. I removed above change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13526#discussion_r1195865800

From smarks at openjdk.org  Wed May 17 04:52:46 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 17 May 2023 04:52:46 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage [v2]
In-Reply-To: <AYpdDhGRzAcYJZyB-QXPfRIt1Qy_1NTKMIBbSLtFdA8=.ab461a31-0b4c-44de-adf2-74f452e03396@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
 <l2Q_DjpYI9Rh5lBUzH_YclTIXR-R01VdApIBsPyOx_c=.1f5ef6f2-3e82-4b37-9144-0a4f2114f9b9@github.com>
 <AYpdDhGRzAcYJZyB-QXPfRIt1Qy_1NTKMIBbSLtFdA8=.ab461a31-0b4c-44de-adf2-74f452e03396@github.com>
Message-ID: <6WZgsbklftvMFHpdrOczcqqvDiHPgTkFUzw29pta3FU=.3593c4a8-5dc0-49dc-9cd9-a5c0b8263c3e@github.com>

On Tue, 16 May 2023 13:38:03 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added some randomness in tests.
>
> src/java.base/share/classes/java/util/regex/Matcher.java line 1381:
> 
>> 1379: 
>> 1380:                 // Capture the input sequence as a string on first find
>> 1381:                 textAsString = captureText();
> 
> Is this correct? The `find()` on line 1371 will set `first` and `last` and `captureText` uses that to narrow down `textAsString` to that range.. so the next `find()` will then find a new `first` and `last` pair but use the text captured after the first `find`?

Yeah this doesn't seem right. To be fair the original code is quite odd. It converts the text to a String once and continues searching over the text thereafter, but stores the String (textAsString) into the returned MatchResults. Note that the text can be mutable (StringBuilder or CharBuffer). It seems like there could be mismatches between `text` and `textAsString`.

I'd think it would be better to search over text consistently, and then capture a subSequence of text from the state of the Matcher at the last moment before creating the MatchResult. As it stands, toMatchResult(String) is confusing because it gets some of its state from the Matcher and some from its argument.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13231#discussion_r1195933990

From smarks at openjdk.org  Wed May 17 05:27:44 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 17 May 2023 05:27:44 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage [v2]
In-Reply-To: <l2Q_DjpYI9Rh5lBUzH_YclTIXR-R01VdApIBsPyOx_c=.1f5ef6f2-3e82-4b37-9144-0a4f2114f9b9@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
 <l2Q_DjpYI9Rh5lBUzH_YclTIXR-R01VdApIBsPyOx_c=.1f5ef6f2-3e82-4b37-9144-0a4f2114f9b9@github.com>
Message-ID: <DlDPTgfsp7PCYBiVO3Mdb_ez-GDfaU283V-Uqndd5EA=.6de923b6-152c-403e-aace-62f9c17ab9a4@github.com>

On Thu, 11 May 2023 09:22:44 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> When appropriate and useful, copies only the relevant portion of the `CharSequence` to the match result.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added some randomness in tests.

src/java.base/share/classes/java/util/regex/Matcher.java line 271:

> 269:         return text instanceof String s ? s : text.subSequence(first, last).toString();
> 270:     }
> 271: 

I'd think we'd want to get a subSequence of any text, regardless of whether it's a String or some other CharSequence. This could result in a savings if there is a match result (or several match results) from find() operation(s) on a large String, when the matched text is relative small.

I'd also merge this into the creation of the MatchResult. The offset needs to be stored because the start/end locations are indexes into the original text, but we're storing only a subSequence of the original text. However, if we always store a subSequence, the offset is always the same as `first`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13231#discussion_r1195953652

From uschindler at apache.org  Wed May 17 07:13:35 2023
From: uschindler at apache.org (Uwe Schindler)
Date: Wed, 17 May 2023 09:13:35 +0200
Subject: JEP 442: Foreign Function & Memory API => why is it again preview
 API?
In-Reply-To: <1496113050.56715554.1684258103469.JavaMail.zimbra@univ-eiffel.fr>
References: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
 <1496113050.56715554.1684258103469.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <090d8383-736c-17b9-a028-f51cddb5550f@apache.org>

Hi Remi,

thanks for the reponse!

>> yesterday Apache Lucene got the information that JDK 21 got the project
>> panama JEP 442 update and I implemented it already in our source tree.
>>
>> Unfortunately the API is again marked "preview", but JDK 21 is "LTS
>> release". Many of our users (Elasticserach, Solr) will be switching to
>> this version. We were really hoping that the java.lang.foreign API is
>> finished at that time. I checked the changes in our code: just a rename
>> of a method and FileChannel#map now takes Arena instead of Scope.
> I see that Alan and Maurizio have already answer to your other points.
>
> Having preview features and being a LTS are to separate concerns.
> Being a LTS is about support, having preview features is about having feedback before finalizing an API.
>
> Java 17 was released with preview features, Java 21 will be.

Yes that's the case. But Java 17 did not have any "runtime visible" 
preview features, only compiler had preview features. For public 
libraries out there (open source on Maven central like Lucene), people 
don't care how they are produced by a compiler. So enhanced switch 
statements or similar stuff is a bit different than the current problem 
where the preview features are visible at runtime.

Some related note: I don't understand why classes compiled with preview 
SYNTAX features of the Java compiler need to be marked with the preview 
bit; IMHO compiler outputs should only be marked as preview if they use 
preview APIs. There should be no risk in running the compiler output of 
preview switch or instanceof statements without preview features enabled.

Uwe

-- 
Uwe Schindler
uschindler at apache.org
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/


From mdoerr at openjdk.org  Wed May 17 07:23:06 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 17 May 2023 07:23:06 GMT
Subject: RFR: 8308246: PPC64le build broken after JDK-8304913
Message-ID: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>

PPC64le needs to get recognized as PPC64. Otherwise, jlink doesn't recognize the platform and throws a PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.PPC64LE.

-------------

Commit messages:
 - 8308246: PPC64le build broken after JDK-8304913

Changes: https://git.openjdk.org/jdk/pull/14027/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14027&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308246
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14027.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14027/head:pull/14027

PR: https://git.openjdk.org/jdk/pull/14027

From uschindler at apache.org  Wed May 17 07:28:12 2023
From: uschindler at apache.org (Uwe Schindler)
Date: Wed, 17 May 2023 09:28:12 +0200
Subject: JEP 442: Foreign Function & Memory API => why is it again preview
 API?
In-Reply-To: <bc2b336f-a205-e8d8-ed68-76d49c9b2d2e@oracle.com>
References: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
 <1496113050.56715554.1684258103469.JavaMail.zimbra@univ-eiffel.fr>
 <CABe8uE1FkrsVndoa2YvgNXf2AniU71M+P-mqvq_qFvcAB4WR+g@mail.gmail.com>
 <bc2b336f-a205-e8d8-ed68-76d49c9b2d2e@oracle.com>
Message-ID: <05a9ab99-2d99-251b-fc3d-9d5dae30d8c5@apache.org>

Hi,

Am 17.05.2023 um 00:41 schrieb Maurizio Cimadamore:
>
> On 16/05/2023 19:03, - wrote:
>> For FFI, I would prefer some parts of the FFI, especially generic ones
>> like Indirect Var Handles, to be promoted from the preview status.
>> They are useful for non-FFI purposes.
> These parts (e.g. the additional var handle combinators in 
> MethodHandles) are the only ones that could be finalized independently 
> of the remainder of the FFM API, yes.
>> Has FFI API considered promoting APIs out of preview incrementally,
>> like how Virtual Threads and Scoped values are?
>
> See my other email. FFM is composed of two biggie APIs, one for 
> managing memory, and one for linking foreign functions. The lifetime 
> abstractions cut across both APIs (and so do memory layouts, which are 
> used to deal with memory dereference, but also to describe foreign 
> types for the linker). So, I don't think there were ever concrete 
> opportunities to split the two APIs (even if it would have been nice 
> to do that).

I agree with that, it is hard to split. I was not aware that the 
lifetime abstracions were such a huge issue! Why I was asking the question:

  * You changed the lifetime abstractions in Java 20 and again in 21. To
    me this is 2 rounds. After 19 people were not happy, so you added
    20. In 20 there was some additional cleanup (in my impression it was
    a step back to Java 18 state just with different class names:
    MemorySession -> Arena).
  * In 21 to me it looked that you are finishing up the API and get to a
    final state. Now with preview features in mind: Does it need to be
    in preview state whenever you change something again? If there is
    only positive feedback in 21, you would release 22 with *unchanged*
    APIs just the preview annotations removed? If there are changes
    again would that mean we get another preview round? --- unfortunate!
  * If you want feedback to the changes in 21: I am mostly fine, thanks
    for fixing FileChannel#map(). I strongly disagree with the rename
    from Arena::openShared to Arena::ofShared. This hides the fact that
    you need to use try-with-resources and close the arena. If a method
    is named "open()" it is a hint for the developer without reading the
    javadcos that this needs to be closed. the global and automatic
    Arena can use prefix "ofXy" or no prefix at all, but the confined
    and shared ones should use open() to make it clear that theres
    smething to close. The main problem is also that the java compiler
    or Eclipse gives you no warning when using ofShared() (depends on
    the constellation). On the other hand if you use global() it may
    produce a warning, as the returned Arena is an Autocloseable
    instance. How is that dealt with? Is the compiler using some method
    name matching when producing a warning?

I added panama-dev to CC.

Uwe

> Sometimes features can be decomposed nicely, and delivered 
> incrementally. That has been the case for most Amber features, and 
> also for Loom. Other times it is less practical to do so, as for FFM 
> API, and patterns in switch + record patterns.
>
> Maurizio
>
>>
>> Chen Liang
>>
>>
>> On Tue, May 16, 2023 at 12:28?PM Remi Forax <forax at univ-mlv.fr> wrote:
>>> ----- Original Message -----
>>>> From: "Uwe Schindler" <uschindler at apache.org>
>>>> To: "core-libs-dev" <core-libs-dev at openjdk.org>
>>>> Sent: Tuesday, May 16, 2023 5:38:32 PM
>>>> Subject: JEP 442: Foreign Function & Memory API => why is it again 
>>>> preview API?
>>>> Hi,
>>> Hi Uwe,
>>>
>>>> yesterday Apache Lucene got the information that JDK 21 got the 
>>>> project
>>>> panama JEP 442 update and I implemented it already in our source tree.
>>>>
>>>> Unfortunately the API is again marked "preview", but JDK 21 is "LTS
>>>> release". Many of our users (Elasticserach, Solr) will be switching to
>>>> this version. We were really hoping that the java.lang.foreign API is
>>>> finished at that time. I checked the changes in our code: just a 
>>>> rename
>>>> of a method and FileChannel#map now takes Arena instead of Scope.
>>> I see that Alan and Maurizio have already answer to your other points.
>>>
>>> Having preview features and being a LTS are to separate concerns.
>>> Being a LTS is about support, having preview features is about 
>>> having feedback before finalizing an API.
>>>
>>> Java 17 was released with preview features, Java 21 will be.
>>>
>>> Before Java 10, when we were doing feature release model, if a 
>>> feature was not ready yet, either the release was delayed (Java 9 
>>> was delayed 3 times if i'm remembering correctly) or postponed to 
>>> the next big release (Java Module was initially scheduled for Java 
>>> 8). With the new cadence model, features that are not ready yet are 
>>> marked as preview.
>>>
>>> I understand that you are eager to use MemorySegment in anger but 
>>> since a looong time, Java features are only released when they are 
>>> ready :)
>>>
>>> Also, it seems that we will have a LTS release every two years now, 
>>> if a LTS had no preview, it means that we will not get any feedback 
>>> for 1/4 of the releases.
>>>
>>>> Uwe
>>>>
>>> regards,
>>> R?mi
>>>
>>>> -- 
>>>> Uwe Schindler
>>>> uschindler at apache.org
>>>> ASF Member, Member of PMC and Committer of Apache Lucene and Apache 
>>>> Solr
>>>> Bremen, Germany
>>>> https://lucene.apache.org/
>>>> https://solr.apache.org/

-- 
Uwe Schindler
uschindler at apache.org  
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230517/0b9b8415/attachment-0001.htm>

From uschindler at apache.org  Wed May 17 07:58:40 2023
From: uschindler at apache.org (Uwe Schindler)
Date: Wed, 17 May 2023 09:58:40 +0200
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <1907607213.49439971.1683285286489.JavaMail.zimbra@univ-eiffel.fr>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
 <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
 <CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com>
 <46167980-41fe-e214-9b67-ce0c5ca8c032@oracle.com>
 <1907607213.49439971.1683285286489.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <e434c1fa-b00d-cccd-5a75-204227ab5a83@apache.org>

Hi Remi, hi all,

I'd like to add some information from open source projects and why I 
don't see the problem discussed here is a really serious one.

Background: We tested Apache Lucene and Apache Solr with Java 21. The 
compilation with Gradle went fine. So actually there are no problems 
with the new superclasses. We have extensive use of chains of stream() 
calls with Stream.of() and similar apis. Use of "var" is still seldom 
but we use it now when newly introduced code around streams is added to 
spare verbosity. But still we got no problems. But why is this so?

A good open source project should trigger the compiler with "--release". 
Apache Lucene uses Java 17 on main branch and Java 11 on 9.x branch. In 
both cases compilation worked due to the use of "--release". If we would 
change to Java 21 as compilation target, we may need to adapt our code.

There are some problems with that:

  * Not all projects use "--release", some projects still use "--source
    --target". The problem with that is Maven and Gradle still not
    making "--release" a first class citizen. Default configs only use
    "--source --target".
  * Code still on Java 8 can't use "--release", as the compiler does not
    support it. The Lucene 8.x branch still open for bugfixes has a
    trick: It detects the compiler and if it is Java 8 it passes
    "--source 8 --target 8", while starting with Java 9 compiler it
    passes "--release 8". On the other hand code still supporting java 8
    is unlikely affected by the problem, as it cannot use "var". But
    still chains of Stream.of().foo().bar() may still be affected.

What is a more serious source-incompatibility issue that I would always 
report to OpenJDK bug tracker: During testing Java 20 we were trapped by 
a compiler change that caused a source incompatibility (which was 
reverted, see https://bugs.openjdk.org/browse/JDK-8299416). So not even 
passing "--release" fixed the issue, because the compiler changed its 
semantics. This is in my opinion a breaking issue because it prevents 
code from compiling!

The changes in sequenced collections should not be a too big problem for 
the community if they have setup their projects correctly.

Uwe

P.S.: To be honest: I tried to pass "--release 21" when compiling Lucene 
and it failed, but not for sequenced collections reasons. It was more 
some tests calling Runtime#runFinalization().

Am 05.05.2023 um 13:14 schrieb forax at univ-mlv.fr:
> Hi Joe,
> in this peculiar case, there are several reasons to be worried 
> compared to other potential breaking changes that has appeared in the 
> past (see the message of Tagir for an example).
>
> Unlike other changes
> - this one touch the collection API, and those interfaces/types are 
> widely used,
> - we know that the source compatibility changes occurs mostly if 'var' 
> or the "new" inference algorithm (the one from Java 8), so this is 
> likely that most of the issues will be found in Java 11+ source code,
> - this changes may also affect all typed languages based on the JVM, 
> not only Java. Corpus of codes in Groovy, Kotlin and Scala also need 
> to be checked. In case of Kotlin and Scala, 'var' is the default 
> behavior but they have their own collections (or type system around 
> collections in case of Kotlin), so knowing the real impact of this 
> change is hard here.
>
> The problem of using a corpus experiment is that the corpus may not 
> represent the current state of the Java ecosystem, or at least the one 
> that may be impacted.
The problem with the corpus experiment is also that you need to be aware 
that most moden open source projects use "--release" flag, so you have 
to patch it away from the build system.
> In my case, on my own repositories (public and private), i had only 
> one occurrence of the issue in the main source codes because many of 
> those repositories are not using 'var' or even the stream API but on 
> the corpus of the unit tests we give to students to check their 
> implementations, little less than a third of those JUnit classes had 
> source compatibility issues because those tests are using 'var' and 
> different collections heavily.
>
> And the situation is a little worst than that because in between now 
> and the time people will use Java 21, a lot of codes will be written 
> using Java 11 and 17 and may found incompatible later.
>
> A source incompatibility issue is not a big deal, as said in this 
> thread, most of the time, explicitly fixing the type argument instead 
> of inferring it make the code compile again.
> So the house is not burning, but we should raise awareness of this 
> issue given that it may have a bigger impact than other source 
> incompatible changes that occur previously.
>
> R?mi
>
> ------------------------------------------------------------------------
>
>     *From: *"joe darcy" <joe.darcy at oracle.com>
>     *To: *"Ethan McCue" <ethan at mccue.dev>, "Raffaello Giulietti"
>     <raffaello.giulietti at oracle.com>
>     *Cc: *"Remi Forax" <forax at univ-mlv.fr>, "Stuart Marks"
>     <stuart.marks at oracle.com>, "core-libs-dev"
>     <core-libs-dev at openjdk.java.net>
>     *Sent: *Friday, May 5, 2023 4:38:16 AM
>     *Subject: *Re: The introduction of Sequenced collections is not a
>     source compatible change
>
>     A few comments on the general compatibility policy for the JDK.
>     Compatibility is looked after by the Compatibility and
>     Specification Review (CSR) process ( Compatibility & Specification
>     Review). Summarizing the approach,
>
>         The general compatibility policy for exported APIs implemented
>         in the JDK is:
>
>         ??? * Don't break binary compatibility (as defined in the Java
>         Language Specification) without sufficient cause.
>         ??? * Avoid introducing source incompatibilities.
>         ??? * Manage behavioral compatibility changes.
>
>     https://wiki.openjdk.org/display/csr/Main
>
>     None of binary, source, and behavioral compatibly are absolutes
>     and judgement is used to assess the cost/benefits of changes. For
>     example, strict source compatibility would preclude, say,
>     introducing new public types in the java.lang package since the
>     implicit import of types in java.lang could conflict with a
>     same-named type *-imported from another? package.
>
>     When a proposed change is estimated to be sufficiently disruptive,
>     we conduct a corpus experiment to evaluate the impact on the
>     change on many public Java libraries. Back in Project Coin in JDK
>     7, that basic approach was used to help quantify various language
>     design choices and the infrastructure to run such experiments has
>     been built-out in the subsequent releases.
>
>     HTH,
>
>     -Joe
>     CSR Group Lead
>
>     On 5/4/2023 6:32 AM, Ethan McCue wrote:
>
>         I guess this a good time to ask, ignoring the benefit part of
>         a cost benefit analysis, what mechanisms do we have to measure
>         the number of codebases relying on type inference this will
>         break?
>
>         Iirc Adoptium built/ran the unit tests of a bunch of public
>         repos, but it's also a bit shocking if the jtreg suite had
>         nothing for this.
>
>         On Thu, May 4, 2023, 9:27 AM Raffaello Giulietti
>         <raffaello.giulietti at oracle.com> wrote:
>
>             Without changing the semantics at all, you could also write
>
>             ? ? ? ? final List<Collection<String>> list =
>             Stream.<Collection<String>>of(nestedDequeue,
>             nestedList).toList();
>
>             to "help" type inference.
>
>
>
>
>             On 2023-05-03 15:12, forax at univ-mlv.fr wrote:
>             > Another example sent to me by a fellow French guy,
>             >
>             >? ? ? final Deque<String> nestedDequeue = new ArrayDeque<>();
>             >? ? ? nestedDequeue.addFirst("C");
>             >? ? ? nestedDequeue.addFirst("B");
>             >? ? ? nestedDequeue.addFirst("A");
>             >
>             >? ? ? final List<String> nestedList = new ArrayList<>();
>             >? ? ? nestedList.add("D");
>             >? ? ? nestedList.add("E");
>             >? ? ? nestedList.add("F");
>             >
>             >? ? ? final List<Collection<String>> list =
>             Stream.of(nestedDequeue, nestedList).toList();
>             >
>             > This one is cool because no 'var' is involved and using
>             collect(Collectors.toList()) instead of toList() solves
>             the inference problem.
>             >
>             > R?mi
>             >
>             > ----- Original Message -----
>             >> From: "Stuart Marks" <stuart.marks at oracle.com>
>             >> To: "Remi Forax" <forax at univ-mlv.fr>
>             >> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>             >> Sent: Tuesday, May 2, 2023 2:44:28 AM
>             >> Subject: Re: The introduction of Sequenced collections
>             is not a source compatible change
>             >
>             >> Hi R?mi,
>             >>
>             >> Thanks for trying out the latest build!
>             >>
>             >> I'll make sure this gets mentioned in the release note
>             for Sequenced
>             >> Collections.
>             >> We'll also raise this issue when we talk about this
>             feature in the Quality
>             >> Outreach
>             >> program.
>             >>
>             >> s'marks
>             >>
>             >> On 4/29/23 3:46 AM, Remi Forax wrote:
>             >>> I've several repositories that now fails to compile
>             with the latest jdk21, which
>             >>> introduces sequence collections.
>             >>>
>             >>> The introduction of a common supertype to existing
>             collections is *not* a source
>             >>> compatible change because of type inference.
>             >>>
>             >>> Here is a simplified example:
>             >>>
>             >>>? ? ?public static void m(List<Supplier<? extends
>             Map<String, String>>> factories) {
>             >>>? ? ?}
>             >>>
>             >>>? ? ?public static void main(String[] args) {
>             >>> ?Supplier<LinkedHashMap<String,String>> supplier1 =
>             LinkedHashMap::new;
>             >>> ?Supplier<SortedMap<String,String>> supplier2 =
>             TreeMap::new;
>             >>>? ? ? ?var factories = List.of(supplier1, supplier2);
>             >>>? ? ? ?m(factories);
>             >>>? ? ?}
>             >>>
>             >>>
>             >>> This example compiles fine with Java 20 but report an
>             error with Java 21:
>             >>>? ? ?SequencedCollectionBug.java:28: error: method m in
>             class SequencedCollectionBug
>             >>>? ? ?cannot be applied to given types;
>             >>>? ? ? ?m(factories);
>             >>>? ? ? ?^
>             >>>? ? ?required: List<Supplier<? extends Map<String,String>>>
>             >>>? ? ?found:? ? List<Supplier<? extends
>             SequencedMap<String,String>>>
>             >>>? ? ?reason: argument mismatch; List<Supplier<? extends
>             SequencedMap<String,String>>>
>             >>>? ? ?cannot be converted to List<Supplier<? extends
>             Map<String,String>>>
>             >>>
>             >>>
>             >>>
>             >>> Apart from the example above, most of the failures I
>             see are in the unit tests
>             >>> provided to the students, because we are using a lot
>             of 'var' in them so they
>             >>> work whatever the name of the types chosen by the
>             students.
>             >>>
>             >>> Discussing with a colleague, we also believe that this
>             bug is not limited to
>             >>> Java, existing Kotlin codes will also fail to compile
>             due to this bug.
>             >>>
>             >>> Regards,
>             >>> R?mi
>
>
-- 
Uwe Schindler
uschindler at apache.org  
ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
Bremen, Germany
https://lucene.apache.org/
https://solr.apache.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230517/a7fe0668/attachment-0001.htm>

From forax at univ-mlv.fr  Wed May 17 08:11:12 2023
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 17 May 2023 10:11:12 +0200 (CEST)
Subject: JEP 442: Foreign Function & Memory API => why is it again
 preview API?
In-Reply-To: <090d8383-736c-17b9-a028-f51cddb5550f@apache.org>
References: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
 <1496113050.56715554.1684258103469.JavaMail.zimbra@univ-eiffel.fr>
 <090d8383-736c-17b9-a028-f51cddb5550f@apache.org>
Message-ID: <1935131230.57017373.1684311072723.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Uwe Schindler" <uschindler at apache.org>
> To: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Wednesday, May 17, 2023 9:13:35 AM
> Subject: Re: JEP 442: Foreign Function & Memory API => why is it again preview API?

> Hi Remi,
> 
> thanks for the reponse!
> 
>>> yesterday Apache Lucene got the information that JDK 21 got the project
>>> panama JEP 442 update and I implemented it already in our source tree.
>>>
>>> Unfortunately the API is again marked "preview", but JDK 21 is "LTS
>>> release". Many of our users (Elasticserach, Solr) will be switching to
>>> this version. We were really hoping that the java.lang.foreign API is
>>> finished at that time. I checked the changes in our code: just a rename
>>> of a method and FileChannel#map now takes Arena instead of Scope.
>> I see that Alan and Maurizio have already answer to your other points.
>>
>> Having preview features and being a LTS are to separate concerns.
>> Being a LTS is about support, having preview features is about having feedback
>> before finalizing an API.
>>
>> Java 17 was released with preview features, Java 21 will be.
> 
> Yes that's the case. But Java 17 did not have any "runtime visible"
> preview features, only compiler had preview features. For public
> libraries out there (open source on Maven central like Lucene), people
> don't care how they are produced by a compiler. So enhanced switch
> statements or similar stuff is a bit different than the current problem
> where the preview features are visible at runtime.

Not true, most of the language changes in preview also have a corresponding runtime visible API marked as preview API.
In case of jdk17, the SwitchBootstraps API is marked as preview API
  https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/lang/runtime/SwitchBootstraps.html

> 
> Some related note: I don't understand why classes compiled with preview
> SYNTAX features of the Java compiler need to be marked with the preview
> bit; IMHO compiler outputs should only be marked as preview if they use
> preview APIs. There should be no risk in running the compiler output of
> preview switch or instanceof statements without preview features enabled.

Because a syntax feature usually also requires a support API, either at runtime or at compile time :)
Records has java.lang.Record, Text blocks has String.stripIndent, etc

> 
> Uwe

R?mi

> 
> --
> Uwe Schindler
> uschindler at apache.org
> ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
> Bremen, Germany
> https://lucene.apache.org/
> https://solr.apache.org/

From maurizio.cimadamore at oracle.com  Wed May 17 08:47:22 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 17 May 2023 09:47:22 +0100
Subject: JEP 442: Foreign Function & Memory API => why is it again preview
 API?
In-Reply-To: <05a9ab99-2d99-251b-fc3d-9d5dae30d8c5@apache.org>
References: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
 <1496113050.56715554.1684258103469.JavaMail.zimbra@univ-eiffel.fr>
 <CABe8uE1FkrsVndoa2YvgNXf2AniU71M+P-mqvq_qFvcAB4WR+g@mail.gmail.com>
 <bc2b336f-a205-e8d8-ed68-76d49c9b2d2e@oracle.com>
 <05a9ab99-2d99-251b-fc3d-9d5dae30d8c5@apache.org>
Message-ID: <62815a95-be2c-d89d-1d9b-9e716d8d8b99@oracle.com>

Hi Uwe,
>
>   * If there are changes again would that mean we get another preview
>     round? --- unfortunate!
>

This seems to be indeed the case for most of the stuff we finalize. E.g. 
Loom and amber feature were finalized pretty much "as is" after a round 
of very (very) light changes. In fact, finalizing FFM API after a 
signifiant round of API changes would have represented the exception, 
not the norm.
>
>   * If you want feedback to the changes in 21: I am mostly fine,
>     thanks for fixing FileChannel#map(). I strongly disagree with the
>     rename from Arena::openShared to Arena::ofShared. This hides the
>     fact that you need to use try-with-resources and close the arena.
>     If a method is named "open()" it is a hint for the developer
>     without reading the javadcos that this needs to be closed. the
>     global and automatic Arena can use prefix "ofXy" or no prefix at
>     all, but the confined and shared ones should use open() to make it
>     clear that theres smething to close. The main problem is also that
>     the java compiler or Eclipse gives you no warning when using
>     ofShared() (depends on the constellation). On the other hand if
>     you use global() it may produce a warning, as the returned Arena
>     is an Autocloseable instance. How is that dealt with? Is the
>     compiler using some method name matching when producing a warning?
>
The naming issue is a tricky one. On the one hand, I can relate to what 
you say. On the other hand, creating an automatic arena is still 
creating a _group_ of resources (e.g. you are still opening something - 
the difference is just that you don't have to call close yourself). 
Which means there's constraints pushing us in different direction: the 
semantics side of things tell us that the three methods should be named 
similarly; the try-with-resource side of things would push for having 
the confined/shared names stand out a bit more. Honestly, it feels like 
we could debate this aspect for a very long time and be none the wiser :-)

The warning is a known issue. Most IDEs seem to have a check for calling 
methods on an AutoCloseable directly (e.g. outside a 
try-with-resources). So, if you do `Arena.global().allocate(...)` you 
get a warning. This was partly why, in 20 we have tried to split the API 
more between closeable and non-closeable types, but I believe the lesson 
we learned is that the benefit we get out of that is not worth the 
complexity cost. I would assume that some of these warnings will be 
rectified, at least in cases where it's obvious they are false positives 
(or maybe, if that proves too difficult, just dropped if the static type 
happens to be Arena). I don't think this situation applies to the javac 
compiler (although javac has other cases in which false positives 
warnings are generated for AutoCloseable, such as when you use them in 
"lock" style, but these do not affect FFM API).

Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230517/b2dd56b4/attachment.htm>

From shade at openjdk.org  Wed May 17 08:52:48 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 May 2023 08:52:48 GMT
Subject: RFR: 8308246: PPC64le build broken after JDK-8304913
In-Reply-To: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
References: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
Message-ID: <coWnSOp7SZzvB7oOIM8tE2AF-gZQHyG8a7_FeJJMN2k=.7cab9f4c-9418-4add-8d18-a5908552d79f@github.com>

On Wed, 17 May 2023 07:16:17 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64le needs to get recognized as PPC64. Otherwise, jlink doesn't recognize the platform and throws a PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.PPC64LE.

Looks fine, but I have a suggestion.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 55:

> 53:         // Alias architecture "amd64" to "X64" and "ppc64le" to "ppc64"
> 54:         archName = archName.replace("amd64", "X64")
> 55:                            .replace("ppc64le", "ppc64");

I'd prefer it to be:

Suggestion:

        // Alias architecture names, if needed
        archName = archName.replace("amd64", "X64");
        archName = archName.replace("ppc64le", "PPC64");


So that other arches would add here more naturally.

(Also convert to upper-case right away, to make the subsequent `archName.toUpperCase` no-op).

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14027#pullrequestreview-1430144704
PR Review Comment: https://git.openjdk.org/jdk/pull/14027#discussion_r1196161763

From maurizio.cimadamore at oracle.com  Wed May 17 09:02:11 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 17 May 2023 10:02:11 +0100
Subject: JEP 442: Foreign Function & Memory API => why is it again preview
 API?
In-Reply-To: <05a9ab99-2d99-251b-fc3d-9d5dae30d8c5@apache.org>
References: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
 <1496113050.56715554.1684258103469.JavaMail.zimbra@univ-eiffel.fr>
 <CABe8uE1FkrsVndoa2YvgNXf2AniU71M+P-mqvq_qFvcAB4WR+g@mail.gmail.com>
 <bc2b336f-a205-e8d8-ed68-76d49c9b2d2e@oracle.com>
 <05a9ab99-2d99-251b-fc3d-9d5dae30d8c5@apache.org>
Message-ID: <3d9c330c-98d9-3708-6cf2-827e76b7de47@oracle.com>


On 17/05/2023 08:28, Uwe Schindler wrote:
> # You changed the lifetime abstractions in Java 20 and again in 21. To 
> me this is 2 rounds. After 19 people were not happy, so you added 20. 
> In 20 there was some additional cleanup (in my impression it was a 
> step back to Java 18 state just with different class names: 
> MemorySession -> Arena).

Another minor point (we discussed this before). While, it's true that 
Java 20 splits MemorySession into two abstractions and Java 21 seems to 
merge things back onto one, in reality things are more subtle. Java 21 
_still_ allows deallocation (and allocation) to be treated as a true 
capability: only code that has an Arena can close it (or allocate). This 
is **very** different from Java 18/19, where you could always ask a 
segment its scope and then close it, and created an issue where 
libraries could not, in the default configuration of the FFM API, share 
segments freely with untrusted clients.

The second very important difference is that Java 21, like Java 20 
allows clients to define custom arenas, which has always been one of the 
goals of the FFM API. As much as the JDK can try and define all the most 
common allocators, there will be always cases that will be left out. 
Allowing developers to define their own allocation scheme (as well as 
their own close policy) is IMHO a very big thing, and one we've been 
actively looking for after Java 19.

Again, I understand the frustration for having to deal with preview 
classfile versions and all. And I also understand that Lucene doesn't 
care about most of the stuff listed above (as I mentioend yesterday, the 
main thing for Lucene is the ability to close shared segments). But I 
also think we shouldn't fall into the trap of oversimplifying things: as 
explained, the memory API and the linker API have to work well together, 
and be flexible enough to handle use cases beyond what Lucene cares 
about (maybe, maybe not - perhaps one day Lucene will have its own 
wrappers around "mmap" using the Linker API :-) ). And we should, I 
think, make sure we get that balance right.

Maurizio

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230517/b406d780/attachment.htm>

From alanb at openjdk.org  Wed May 17 09:02:44 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 May 2023 09:02:44 GMT
Subject: RFR: 8308246: PPC64le build broken after JDK-8304913
In-Reply-To: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
References: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
Message-ID: <HWJgPPDg_nNp-GkQ8BixcLEM_lIAVGB-hbr38QhVmr0=.b94c467a-ef46-4914-bab1-9e21e0850bae@github.com>

On Wed, 17 May 2023 07:16:17 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64le needs to get recognized as PPC64. Otherwise, jlink doesn't recognize the platform and throws a PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.PPC64LE.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 55:

> 53:         // Alias architecture "amd64" to "X64" and "ppc64le" to "ppc64"
> 54:         archName = archName.replace("amd64", "X64")
> 55:                            .replace("ppc64le", "ppc64");

Is linux-ppc64 big endian? If so, a module with a ModuleTarget value of linux-ppc64le can't be linked with a module that has ModuleTarget value of linux-ppc64.  I'm not say the aliasing here is wrong but I am curious if attempts to link will fail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14027#discussion_r1196175791

From mdoerr at openjdk.org  Wed May 17 09:13:45 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 17 May 2023 09:13:45 GMT
Subject: RFR: 8308246: PPC64le build broken after JDK-8304913
In-Reply-To: <HWJgPPDg_nNp-GkQ8BixcLEM_lIAVGB-hbr38QhVmr0=.b94c467a-ef46-4914-bab1-9e21e0850bae@github.com>
References: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
 <HWJgPPDg_nNp-GkQ8BixcLEM_lIAVGB-hbr38QhVmr0=.b94c467a-ef46-4914-bab1-9e21e0850bae@github.com>
Message-ID: <8cFw940aUmPolVFVRnjMZYw1yKpIy-A3E89G2RzlIlk=.c1e6e29a-3083-4c75-b13c-278e6854852c@github.com>

On Wed, 17 May 2023 09:00:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> PPC64le needs to get recognized as PPC64. Otherwise, jlink doesn't recognize the platform and throws a PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.PPC64LE.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 55:
> 
>> 53:         // Alias architecture "amd64" to "X64" and "ppc64le" to "ppc64"
>> 54:         archName = archName.replace("amd64", "X64")
>> 55:                            .replace("ppc64le", "ppc64");
> 
> Is linux-ppc64 big endian? If so, a module with a ModuleTarget value of linux-ppc64le can't be linked with a module that has ModuleTarget value of linux-ppc64.  I'm not say the aliasing here is wrong but I am curious if attempts to link will fail.

Yes, linux-ppc64 is big endian. The 2 flavors are completely incompatible. linux-ppc64le is basically a new platform. Endianness should actually get checked in addition to the archName.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14027#discussion_r1196183985

From mdoerr at openjdk.org  Wed May 17 09:13:48 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 17 May 2023 09:13:48 GMT
Subject: RFR: 8308246: PPC64le build broken after JDK-8304913
In-Reply-To: <coWnSOp7SZzvB7oOIM8tE2AF-gZQHyG8a7_FeJJMN2k=.7cab9f4c-9418-4add-8d18-a5908552d79f@github.com>
References: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
 <coWnSOp7SZzvB7oOIM8tE2AF-gZQHyG8a7_FeJJMN2k=.7cab9f4c-9418-4add-8d18-a5908552d79f@github.com>
Message-ID: <A5xOuOrUE4L6qGRn-bhqNzk0elYs8mXPuyxaA67FtjM=.6982b7d1-1d82-43ac-977b-d5ae3ffeb4b9@github.com>

On Wed, 17 May 2023 08:48:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> PPC64le needs to get recognized as PPC64. Otherwise, jlink doesn't recognize the platform and throws a PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.PPC64LE.
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java line 55:
> 
>> 53:         // Alias architecture "amd64" to "X64" and "ppc64le" to "ppc64"
>> 54:         archName = archName.replace("amd64", "X64")
>> 55:                            .replace("ppc64le", "ppc64");
> 
> I'd prefer it to be:
> 
> Suggestion:
> 
>         // Alias architecture names, if needed
>         archName = archName.replace("amd64", "X64");
>         archName = archName.replace("ppc64le", "PPC64");
> 
> 
> So that other arches would add here more naturally.
> 
> (Also convert to upper-case right away, to make the subsequent `archName.toUpperCase` no-op).

Makes sense. Thanks for the review!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14027#discussion_r1196188653

From rgiulietti at openjdk.org  Wed May 17 09:19:10 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 17 May 2023 09:19:10 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage [v3]
In-Reply-To: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
Message-ID: <cJ6sxFyGezNQ6I3y-5DAnLyIj9Wge5E43lksFc-LaTw=.cb00dfcd-086f-48b4-92cf-c6aec5c6a103@github.com>

> When appropriate and useful, copies only the relevant portion of the `CharSequence` to the match result.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Adjusted incorrect logic in results().
   Added tests for results().
   Refined capturing logic when there's no match.
 - Merge branch 'master' into JDK-8132995
 - Adjusted erroneous logic in results().
   Added tests for results().
 - Added some randomness in tests.
 - 8132995: Matcher should be optimized to reduce space usage

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13231/files
  - new: https://git.openjdk.org/jdk/pull/13231/files/160b970a..4b8ead1d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13231&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13231&range=01-02

  Stats: 456167 lines in 5146 files changed: 374095 ins; 45331 del; 36741 mod
  Patch: https://git.openjdk.org/jdk/pull/13231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13231/head:pull/13231

PR: https://git.openjdk.org/jdk/pull/13231

From rgiulietti at openjdk.org  Wed May 17 09:19:24 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 17 May 2023 09:19:24 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage [v2]
In-Reply-To: <DlDPTgfsp7PCYBiVO3Mdb_ez-GDfaU283V-Uqndd5EA=.6de923b6-152c-403e-aace-62f9c17ab9a4@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
 <l2Q_DjpYI9Rh5lBUzH_YclTIXR-R01VdApIBsPyOx_c=.1f5ef6f2-3e82-4b37-9144-0a4f2114f9b9@github.com>
 <DlDPTgfsp7PCYBiVO3Mdb_ez-GDfaU283V-Uqndd5EA=.6de923b6-152c-403e-aace-62f9c17ab9a4@github.com>
Message-ID: <6AFJRP0NlsV2lCq2KneWyyYUoSQcTkLALKgwOn4ViIc=.1a9f17b3-3334-432d-b8ca-6b242af9a469@github.com>

On Wed, 17 May 2023 05:24:28 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added some randomness in tests.
>
> src/java.base/share/classes/java/util/regex/Matcher.java line 271:
> 
>> 269:         return text instanceof String s ? s : text.subSequence(first, last).toString();
>> 270:     }
>> 271: 
> 
> I'd think we'd want to get a subSequence of any text, regardless of whether it's a String or some other CharSequence. This could result in a savings if there is a match result (or several match results) from find() operation(s) on a large String, when the matched text is relative small.
> 
> I'd also merge this into the creation of the MatchResult. The offset needs to be stored because the start/end locations are indexes into the original text, but we're storing only a subSequence of the original text. However, if we always store a subSequence, the offset is always the same as `first`.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13231#discussion_r1196197916

From rgiulietti at openjdk.org  Wed May 17 09:19:24 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 17 May 2023 09:19:24 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage [v2]
In-Reply-To: <AYpdDhGRzAcYJZyB-QXPfRIt1Qy_1NTKMIBbSLtFdA8=.ab461a31-0b4c-44de-adf2-74f452e03396@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
 <l2Q_DjpYI9Rh5lBUzH_YclTIXR-R01VdApIBsPyOx_c=.1f5ef6f2-3e82-4b37-9144-0a4f2114f9b9@github.com>
 <AYpdDhGRzAcYJZyB-QXPfRIt1Qy_1NTKMIBbSLtFdA8=.ab461a31-0b4c-44de-adf2-74f452e03396@github.com>
Message-ID: <VIONKQ4fLk7l2VIAuVEw-G1-PmZSMv1XvxFDhBnbWHw=.fff991aa-05e8-4d86-919a-34906745973b@github.com>

On Tue, 16 May 2023 13:29:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added some randomness in tests.
>
> src/java.base/share/classes/java/util/regex/Matcher.java line 359:
> 
>> 357:             if ((groups[group * 2] == -1) || (groups[group * 2 + 1] == -1))
>> 358:                 return null;
>> 359:             return text.subSequence(groups[group * 2] - offset, groups[group * 2 + 1] - offset).toString();
> 
> Could be simplified to `return text.substring(groups[group * 2] - offset, groups[group * 2 + 1] - offset);`

Right. Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13231#discussion_r1196198048

From rgiulietti at openjdk.org  Wed May 17 09:19:24 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 17 May 2023 09:19:24 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage [v2]
In-Reply-To: <6WZgsbklftvMFHpdrOczcqqvDiHPgTkFUzw29pta3FU=.3593c4a8-5dc0-49dc-9cd9-a5c0b8263c3e@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
 <l2Q_DjpYI9Rh5lBUzH_YclTIXR-R01VdApIBsPyOx_c=.1f5ef6f2-3e82-4b37-9144-0a4f2114f9b9@github.com>
 <AYpdDhGRzAcYJZyB-QXPfRIt1Qy_1NTKMIBbSLtFdA8=.ab461a31-0b4c-44de-adf2-74f452e03396@github.com>
 <6WZgsbklftvMFHpdrOczcqqvDiHPgTkFUzw29pta3FU=.3593c4a8-5dc0-49dc-9cd9-a5c0b8263c3e@github.com>
Message-ID: <h7gRLUGPggThUazK_fFpAGjs5ylHxi494G8fGY_zl4w=.9f2fc982-b09c-42b6-b915-1ee018ccf5c9@github.com>

On Wed, 17 May 2023 04:50:14 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/regex/Matcher.java line 1381:
>> 
>>> 1379: 
>>> 1380:                 // Capture the input sequence as a string on first find
>>> 1381:                 textAsString = captureText();
>> 
>> Is this correct? The `find()` on line 1371 will set `first` and `last` and `captureText` uses that to narrow down `textAsString` to that range.. so the next `find()` will then find a new `first` and `last` pair but use the text captured after the first `find`?
>
> Yeah this doesn't seem right. To be fair the original code is quite odd. It converts the text to a String once and continues searching over the text thereafter, but stores the String (textAsString) into the returned MatchResults. Note that the text can be mutable (StringBuilder or CharBuffer). It seems like there could be mismatches between `text` and `textAsString`.
> 
> I'd think it would be better to search over text consistently, and then capture a subSequence of text from the state of the Matcher at the last moment before creating the MatchResult. As it stands, toMatchResult(String) is confusing because it gets some of its state from the Matcher and some from its argument.

It is incorrect, indeed.
Corrected, with additional tests exercising `results()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13231#discussion_r1196197992

From mdoerr at openjdk.org  Wed May 17 09:42:58 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 17 May 2023 09:42:58 GMT
Subject: RFR: 8308246: PPC64le build broken after JDK-8304913 [v2]
In-Reply-To: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
References: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
Message-ID: <pT5KIldLSnitmqwiukgLug6iQ4y0HdPagkGtPyKsmbE=.44b1df46-c7a0-47e4-97c1-0547bef8004e@github.com>

> PPC64le needs to get recognized as PPC64. Otherwise, jlink doesn't recognize the platform and throws a PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.PPC64LE.

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14027/files
  - new: https://git.openjdk.org/jdk/pull/14027/files/059c1ba2..37ae111e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14027&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14027&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14027.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14027/head:pull/14027

PR: https://git.openjdk.org/jdk/pull/14027

From mcimadamore at openjdk.org  Wed May 17 09:45:52 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 09:45:52 GMT
Subject: RFR: 8308248: Revisit alignment of layout constants on 32-bit
 platforms
Message-ID: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>

The FFM API exposes layout constants for Java primitives. Among those there are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of these layouts is set the same as their size (e.g. 8 bytes).

This is obviously correct on 64-bit platforms, but on 32-bit platform it is not, as such platforms cannot guarantee that doubles and longs will be always 64-bit aligned. This will also result in problems when trying to use e.g. `JAVA_DOUBLE` to model a C double for the linker API on 32-bit platforms.

For these reasons, it would be preferable to define the alignment of `JAVA_LONG` and `JAVA_DOUBLE` constants as `ADDRESS.byteSize()`. 

This patch rectifies alignment of those layout constants to reflect platform-dependent constraints. It also fixes the maximum alignment constraint supported by heap segments, so that it is 4 for long[] and double[] on 32-bit platforms.

-------------

Commit messages:
 - Add more comprehensive javadoc
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/14007/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14007&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308248
  Stats: 42 lines in 3 files changed: 16 ins; 6 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/14007.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14007/head:pull/14007

PR: https://git.openjdk.org/jdk/pull/14007

From alanb at openjdk.org  Wed May 17 09:53:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 May 2023 09:53:46 GMT
Subject: RFR: JDK-8308239: Tighten up accessibility of nested classes in
 java.lang.invoke
In-Reply-To: <IsG1KyYI7vkg1D422gDL-v3OQ73Ji5ykXkAjlNqZQd0=.ab31339c-3b06-4d3b-a7cd-08660b6313be@github.com>
References: <IsG1KyYI7vkg1D422gDL-v3OQ73Ji5ykXkAjlNqZQd0=.ab31339c-3b06-4d3b-a7cd-08660b6313be@github.com>
Message-ID: <A_-B_y5vGPiM1YgbsfXEVbsyscce53CDtCbd6lTLALM=.3fbcc46a-1027-4a4e-ab4a-5b46b38963b6@github.com>

On Tue, 16 May 2023 21:35:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Tightening up accessibility of a few nested classes. There is no practical impact on source compatibility -- source uses within the package still work, but by default the ability to reflectively call methods on these classes is disabled.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14021#pullrequestreview-1430263175

From mcimadamore at openjdk.org  Wed May 17 09:56:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 09:56:53 GMT
Subject: RFR: 8308248: Revisit alignment of layout constants on 32-bit
 platforms
In-Reply-To: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
References: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
Message-ID: <L3jWDmAbFMl1JDLPazq12lOcyaMZpwqyCwuSrBwIGSI=.442a5e53-f8c7-4bae-957c-b04c4db24936@github.com>

On Tue, 16 May 2023 11:18:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The FFM API exposes layout constants for Java primitives. Among those there are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of these layouts is set the same as their size (e.g. 8 bytes).
> 
> This is obviously correct on 64-bit platforms, but on 32-bit platform it is not, as such platforms cannot guarantee that doubles and longs will be always 64-bit aligned. This will also result in problems when trying to use e.g. `JAVA_DOUBLE` to model a C double for the linker API on 32-bit platforms.
> 
> For these reasons, it would be preferable to define the alignment of `JAVA_LONG` and `JAVA_DOUBLE` constants as `ADDRESS.byteSize()`. 
> 
> This patch rectifies alignment of those layout constants to reflect platform-dependent constraints. It also fixes the maximum alignment constraint supported by heap segments, so that it is 4 for long[] and double[] on 32-bit platforms.

Javadoc: https://cr.openjdk.org/~mcimadamore/jdk/8308248/8308248/v1/javadoc/java.base/module-summary.html
Specdiff: https://cr.openjdk.org/~mcimadamore/jdk/8308248/8308248/v1/specdiff_out/overview-summary.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14007#issuecomment-1551095329

From kasperni at gmail.com  Wed May 17 09:58:55 2023
From: kasperni at gmail.com (Kasper Nielsen)
Date: Wed, 17 May 2023 10:58:55 +0100
Subject: JEP 442: Foreign Function & Memory API => why is it again preview
 API?
In-Reply-To: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
References: <ab3632a2-f50f-4ee1-3b46-5fca2047ba01@apache.org>
Message-ID: <CAPs6152+63rcHEPZvbSn4yVTg=4J8Nh4sEMc2aZZ3p26E8UVqw@mail.gmail.com>

> In contrast the foreign memory API is very stable already since Java 19 and the changes were minimal in 21.

If you take a look at differences from Java 20 to Java 21 on Java
Almanac [1] for java.lang.foreign.
I wouldn't really call it minimal. Lots of classes and methods were
added and removed.

> P.S.: Vector API is still in incubation, when will it go to preview?

It is detailed in the lastest Vector JEP [2].

------
Accordingly, the Vector API will incubate over multiple releases until
the necessary features of Project Valhalla become available as preview
features. Once these Valhalla features are available we will adapt the
Vector API and implementation to use them and then promote the Vector
API itself to a preview feature. For further details, see the sections
on run-time compilation and future work.
-----

/Kasper

[1] https://javaalmanac.io/jdk/21/apidiff/20/
[2] https://openjdk.org/jeps/448

From mbaesken at openjdk.org  Wed May 17 10:07:47 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 17 May 2023 10:07:47 GMT
Subject: RFR: 8308246: PPC64le build broken after JDK-8304913 [v2]
In-Reply-To: <pT5KIldLSnitmqwiukgLug6iQ4y0HdPagkGtPyKsmbE=.44b1df46-c7a0-47e4-97c1-0547bef8004e@github.com>
References: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
 <pT5KIldLSnitmqwiukgLug6iQ4y0HdPagkGtPyKsmbE=.44b1df46-c7a0-47e4-97c1-0547bef8004e@github.com>
Message-ID: <LUbxoMgQMUdsIyaUFn_WlZtrmFBtn05gCeoToNZq_f4=.dc1c9c07-2c17-4746-99d5-ff32e62a6ddb@github.com>

On Wed, 17 May 2023 09:42:58 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> PPC64le needs to get recognized as PPC64. Otherwise, jlink doesn't recognize the platform and throws a PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.PPC64LE.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback.

Marked as reviewed by mbaesken (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14027#pullrequestreview-1430288129

From shade at openjdk.org  Wed May 17 10:28:52 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 17 May 2023 10:28:52 GMT
Subject: RFR: 8307483: New micros for j.u.c.LockSupport [v3]
In-Reply-To: <q77A4CdvYIyasyM1E1QsuBpNbrJ_QaNeAWGhHKaWKdM=.0bfb5dea-c9bf-4325-b3aa-0f88f76fc845@github.com>
References: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
 <q77A4CdvYIyasyM1E1QsuBpNbrJ_QaNeAWGhHKaWKdM=.0bfb5dea-c9bf-4325-b3aa-0f88f76fc845@github.com>
Message-ID: <3gbz3BbrHGi_Api40jIiQciz9PIqdqltbcjNBayijrc=.a1499c50-37aa-4791-98ba-e050945f15b9@github.com>

On Tue, 9 May 2023 19:13:42 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> These micros were developed while investigating JDK-8305670 by myself and Sergey Kuksenko. The order of thread creation was important in that bug, so there are 2 JMH for creating sleepers before and after the worker threads.
>
> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add review comments changes.

Looks okay, with a few remaining nits.

test/micro/org/openjdk/bench/java/util/concurrent/UnparkBenchSleepersAfter.java line 119:

> 117:     public void tearDown() {
> 118:         for (IdleRunnable it : idleRunnables) {
> 119:             it.stop();

Suggestion:

        for (IdleRunnable r : idleRunnables) {
            r.stop();

test/micro/org/openjdk/bench/java/util/concurrent/UnparkBenchSleepersAfter.java line 125:

> 123: 
> 124:     public static class IdleRunnable implements Runnable {
> 125:         volatile boolean done = false;

Suggestion:

        volatile boolean done;

test/micro/org/openjdk/bench/java/util/concurrent/UnparkBenchSleepersBefore.java line 98:

> 96:         idleRunnables = new IdleRunnable[idles];
> 97:         for(int i = 0; i < idleRunnables.length; i++) {
> 98:             new Thread(idleRunnables[i] = new IdleRunnable()).start();

Suggestion:

            idleRunnables[i] = new IdleRunnable();
            new Thread(idleRunnables[i]).start();

test/micro/org/openjdk/bench/java/util/concurrent/UnparkBenchSleepersBefore.java line 108:

> 106:         for(IdleRunnable it : idleRunnables) {
> 107:             it.stop();
> 108:         }

Suggestion:

        for (IdleRunnable r : idleRunnables) {
            r.stop();
        }

test/micro/org/openjdk/bench/java/util/concurrent/UnparkBenchSleepersBefore.java line 113:

> 111: 
> 112:     public static class IdleRunnable implements Runnable {
> 113:         volatile boolean done = false;

Suggestion:

        volatile boolean done;

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13815#pullrequestreview-1430315922
PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1196278779
PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1196278589
PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1196274218
PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1196275475
PR Review Comment: https://git.openjdk.org/jdk/pull/13815#discussion_r1196275669

From alanb at openjdk.org  Wed May 17 10:33:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 May 2023 10:33:46 GMT
Subject: RFR: 8308246: PPC64le build broken after JDK-8304913 [v2]
In-Reply-To: <8cFw940aUmPolVFVRnjMZYw1yKpIy-A3E89G2RzlIlk=.c1e6e29a-3083-4c75-b13c-278e6854852c@github.com>
References: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
 <HWJgPPDg_nNp-GkQ8BixcLEM_lIAVGB-hbr38QhVmr0=.b94c467a-ef46-4914-bab1-9e21e0850bae@github.com>
 <8cFw940aUmPolVFVRnjMZYw1yKpIy-A3E89G2RzlIlk=.c1e6e29a-3083-4c75-b13c-278e6854852c@github.com>
Message-ID: <AZby-FH4GtMPU5l7Vpzusdqq_sZyHhy5tz_3dd8zq9M=.72e091d6-37a1-492e-99a2-23edf81cc493@github.com>

On Wed, 17 May 2023 09:07:03 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Yes, linux-ppc64 is big endian. The 2 flavors are completely incompatible. linux-ppc64le is basically a new platform. Endianness should actually get checked in addition to the archName.

Okay, I was only asking because the ModuleTarget attribute has the OS and arch, the endianness is derived from those right now. Maybe in the future there can be more about the architecture and processor features (e.g. soft vs. hard float).  So mulling over this change and wondering what happens if there is cross linking involve these two platforms.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14027#discussion_r1196285271

From djelinski at openjdk.org  Wed May 17 10:44:47 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 17 May 2023 10:44:47 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <khArxt__ygRlbr63kl1DtT4hHdV8MV7t649XSfhCvhI=.1c153e15-b509-4b30-833d-cdb196ea0ff7@github.com>

On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 516:

> 514: 
> 515:         if (nccount != -1) {
> 516:             ncstring = Integer.toHexString (nccount).toLowerCase(Locale.ROOT);

Suggestion:

            ncstring = Integer.toHexString(nccount);

`toHexString` returns lowercase string

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14006#discussion_r1196296029

From mcimadamore at openjdk.org  Wed May 17 11:15:11 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 11:15:11 GMT
Subject: RFR: 8308248: Revisit alignment of layout constants on 32-bit
 platforms [v2]
In-Reply-To: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
References: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
Message-ID: <ru-xaWdgxVJ3revT-9ghB_KTv2oDdqhq5-NcIFZuShs=.040b67b4-025a-4aac-a077-3df94aa369d5@github.com>

> The FFM API exposes layout constants for Java primitives. Among those there are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of these layouts is set the same as their size (e.g. 8 bytes).
> 
> This is obviously correct on 64-bit platforms, but on 32-bit platform it is not, as such platforms cannot guarantee that doubles and longs will be always 64-bit aligned. This will also result in problems when trying to use e.g. `JAVA_DOUBLE` to model a C double for the linker API on 32-bit platforms.
> 
> For these reasons, it would be preferable to define the alignment of `JAVA_LONG` and `JAVA_DOUBLE` constants as `ADDRESS.byteSize()`. 
> 
> This patch rectifies alignment of those layout constants to reflect platform-dependent constraints. It also fixes the maximum alignment constraint supported by heap segments, so that it is 4 for long[] and double[] on 32-bit platforms.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix max alignment constants

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14007/files
  - new: https://git.openjdk.org/jdk/pull/14007/files/b003bd6a..731095e9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14007&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14007&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14007.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14007/head:pull/14007

PR: https://git.openjdk.org/jdk/pull/14007

From mcimadamore at openjdk.org  Wed May 17 11:18:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 11:18:58 GMT
Subject: RFR: 8308276: Change layout API to work with bytes, not bits
Message-ID: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>

As explained in [1], memory layouts and memory segments describe sizes using different units. Memory layouts use bits, whereas memory segments use bytes. This is historical: memory layouts were designed after the Minimal LDL [2], which allowed layout strings to be used to describe both memory *and* register. In practice that ship has sailed, and the FFM API uses layouts to firmly model the contents of regions of memory. While it would be possible, in principle, to tweak segments to work on bits, changing that would have implications on how easily code that is currently using ByteBuffer can migrate to use MemorySegment.

For these reasons, this patch fixes the asymmetry so that layouts also model sizes in term of bytes.

The patch is straightforward, although a bit tedious (as you can imagine), as various uses of bit sizes had to be turned in byte sizes. In practice, the migration had not been too hard, for the following reasons:

* the `withBitAlignment` and `bitSize` methods are no longer in the API, it is easy to fix any code (mainly tests) using it;
* most code already uses ready-made constants such as `JAVA_INT` - such code continues to work unchanged;
* the layout API de facto already required clients to work with bit sizes that are a multiple of 8.

The only problematic case is the presence of the `MemoryLayout::paddingLayout(long size)` factory. As this factory is changed to deal in bytes instead of bits, all constants passed to this factory will need to be updated. This is not a problem for code using jextract (as jextract will take care of generating padding) but will be an issue for code using the layout API directly.

[1] - https://mail.openjdk.org/pipermail/panama-dev/2023-May/019059.html

-------------

Commit messages:
 - Drop spurious reference to "bit"/"bits" in both javadoc and impl
 - Fix tests
 - Fix bad assertion in AbstractValueLayouts
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/14013/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14013&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308276
  Stats: 710 lines in 93 files changed: 3 ins; 191 del; 516 mod
  Patch: https://git.openjdk.org/jdk/pull/14013.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14013/head:pull/14013

PR: https://git.openjdk.org/jdk/pull/14013

From mcimadamore at openjdk.org  Wed May 17 11:18:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 11:18:58 GMT
Subject: RFR: 8308276: Change layout API to work with bytes, not bits
In-Reply-To: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
References: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
Message-ID: <SzbKHEbdFPe1t-aJnoCt0vip8p4_f19WninMX_tQENk=.623bb4a3-465d-4128-a68a-1524a14d0ec7@github.com>

On Tue, 16 May 2023 13:53:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> As explained in [1], memory layouts and memory segments describe sizes using different units. Memory layouts use bits, whereas memory segments use bytes. This is historical: memory layouts were designed after the Minimal LDL [2], which allowed layout strings to be used to describe both memory *and* register. In practice that ship has sailed, and the FFM API uses layouts to firmly model the contents of regions of memory. While it would be possible, in principle, to tweak segments to work on bits, changing that would have implications on how easily code that is currently using ByteBuffer can migrate to use MemorySegment.
> 
> For these reasons, this patch fixes the asymmetry so that layouts also model sizes in term of bytes.
> 
> The patch is straightforward, although a bit tedious (as you can imagine), as various uses of bit sizes had to be turned in byte sizes. In practice, the migration had not been too hard, for the following reasons:
> 
> * the `withBitAlignment` and `bitSize` methods are no longer in the API, it is easy to fix any code (mainly tests) using it;
> * most code already uses ready-made constants such as `JAVA_INT` - such code continues to work unchanged;
> * the layout API de facto already required clients to work with bit sizes that are a multiple of 8.
> 
> The only problematic case is the presence of the `MemoryLayout::paddingLayout(long size)` factory. As this factory is changed to deal in bytes instead of bits, all constants passed to this factory will need to be updated. This is not a problem for code using jextract (as jextract will take care of generating padding) but will be an issue for code using the layout API directly.
> 
> [1] - https://mail.openjdk.org/pipermail/panama-dev/2023-May/019059.html

javadoc: https://cr.openjdk.org/~mcimadamore/jdk/8308276/8308276/v1/javadoc/java.base/java/lang/foreign/package-summary.html
specdiff: https://cr.openjdk.org/~mcimadamore/jdk/8308276/8308276/v1/specdiff_out/overview-summary.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14013#issuecomment-1551184388

From itakiguchi at openjdk.org  Wed May 17 11:47:51 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 17 May 2023 11:47:51 GMT
Subject: RFR: 8308046: Move Solaris related Japanese charsets from
 java.base to jdk.charsets module [v2]
In-Reply-To: <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
 <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
Message-ID: <JmbJq4nk9oiDPl36qbxWQnxiKB1YHpvs6J8JOD7MmCc=.0d17f96a-2ea6-49ae-9c78-ad13b6cb3398@github.com>

On Tue, 16 May 2023 17:13:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8308046: Move Solaris related Japanese charsets from java.base to jdk.charsets module
>
> I now think it is better simply removing Solaris-related charsets, as moving them from java.base to jdk.charsets would require unnecessary code changes in non-Solaris code.

Hello @naotoj .
I'm not sure we can remove Solaris related charsets.
Somebody may use them for text communication between Solaris.
The latest change can move Big5_Solaris from java.base to jdk.charsets module.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1551244863

From pminborg at openjdk.org  Wed May 17 11:54:08 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 17 May 2023 11:54:08 GMT
Subject: RFR: 8308281: Java snippets in the FFM API need to be updated
Message-ID: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>

As the API has improved over the recent releases, not all `{@snippet ..}` sections have been kept in sync.

This PR suggests all snippets used should be verified against real code that is placed in a new `snippet-files` folder and erroneous snippets are updated.

-------------

Commit messages:
 - Reformat
 - Remove file
 - Add a snippet-files class with snippets

Changes: https://git.openjdk.org/jdk/pull/14030/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14030&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308281
  Stats: 714 lines in 7 files changed: 679 ins; 1 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/14030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14030/head:pull/14030

PR: https://git.openjdk.org/jdk/pull/14030

From mcimadamore at openjdk.org  Wed May 17 12:01:43 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 12:01:43 GMT
Subject: RFR: 8308281: Java snippets in the FFM API need to be updated
In-Reply-To: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>
References: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>
Message-ID: <ATnZGNelTKyBOAl9AxWFjqzamRRsVSPPaGcnF9mfts4=.52acf0b2-5515-4db7-a21d-881ab18cef3a@github.com>

On Wed, 17 May 2023 11:46:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> As the API has improved over the recent releases, not all `{@snippet ..}` sections have been kept in sync.
> 
> This PR suggests all snippets used should be verified against real code that is placed in a new `snippet-files` folder and erroneous snippets are updated.
> 
> In this PR, it is suggested duplicating code in the `Snippets.java` class and in the JavaDocs. The benefit of this is that code is directly visible in the code and not only in the generated javadoc.
> 
> Another thing to think about is if there should be on single `Snippets.java` class or separate ones for each FFM class.

The fixes all are great - thanks for going over it. I'm not sure about the snippet-file folder - e.g. if we're not using it, is there value in having it? I suppose (but I might be wrong) that the IDE cannot perform refactors on such a file, so it will become yet another thing that might go out of date?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14030#pullrequestreview-1430500747

From simonis at openjdk.org  Wed May 17 12:33:48 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 17 May 2023 12:33:48 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v2]
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <7wDXcglvW1xSgIGL4fWRX_LtUl2wtfoaBYiu_z36YMs=.38e799cf-a942-4e05-90c3-3f757c480e9b@github.com>

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Added test case

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13956/files
  - new: https://git.openjdk.org/jdk/pull/13956/files/020a60e6..2bef75a0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13956&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13956&range=00-01

  Stats: 47 lines in 4 files changed: 46 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13956/head:pull/13956

PR: https://git.openjdk.org/jdk/pull/13956

From asemenov at openjdk.org  Wed May 17 12:35:47 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 17 May 2023 12:35:47 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code
Message-ID: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>

When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
They can be fixed with small changes.

-------------

Commit messages:
 - 8308286 Fix clang warnings in linux code

Changes: https://git.openjdk.org/jdk/pull/14033/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308286
  Stats: 134 lines in 12 files changed: 126 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From simonis at openjdk.org  Wed May 17 12:43:46 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 17 May 2023 12:43:46 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <yZM9iro4FRdHveBRx07oeItZ9_CmQJ4wksNo3XI8Igs=.7b2097d5-0852-4f04-9c14-fc8d39a57c08@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>
 <WNS9AUc4Uo0uJT7Q-c5WmRQGPXKHOiQ5bk3FAVhcpTw=.7b192c55-1a39-48bf-9c36-eb8219474c4f@github.com>
 <u7bSYYuppXZ1z347-wRTJf9GoxNUW-GoWfSn4dmCLEE=.831249e0-e538-491c-8001-a7dd55673721@github.com>
 <yZM9iro4FRdHveBRx07oeItZ9_CmQJ4wksNo3XI8Igs=.7b2097d5-0852-4f04-9c14-fc8d39a57c08@github.com>
Message-ID: <qh4P0rQhdigeWLoD9paOaTJgT7uXOU0IsBTQlFdZ3Ew=.1eb8ea15-2d10-45e3-b883-87b088e220ba@github.com>

On Tue, 16 May 2023 12:32:44 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > > > I wonder if @Martin-Buchholz is able to look at this one?
> > > > My concern with changes like this is that they fix an issue but then have unexpected side-effects themselves.
> > > 
> > > 
> > > Are there any specific concerns you have?
> > 
> > 
> > There seems to be more going on here than just closing the write side of the pipe. We will now error out if any of the readFully's do a short read, rather than just when reporting an error - which on the surface seems like a good thing, but what if harmless short-reads can actually happen in some contexts?
> 
> I agree, it would be clearer to just to the close.

Sorry, but I don't understand this argument. If we do a short read we will work with corrupted `ChildStuff` and `SpawnInfo` structures. This can in the extreme case execute arbitrary code (e.g. if `ChildStuff.argv` is not fully read from the parent). You are basically saying it is better to work on corrupted data rather than reporting an error.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1551321557

From simonis at openjdk.org  Wed May 17 12:47:45 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 17 May 2023 12:47:45 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <EpRH_ZD3BR9HTcqdJMDzEwYwzzs3Gmt0aum31L2sFpI=.b9917c04-4f90-4f1b-aee9-c5e23ecd5332@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <EpRH_ZD3BR9HTcqdJMDzEwYwzzs3Gmt0aum31L2sFpI=.b9917c04-4f90-4f1b-aee9-c5e23ecd5332@github.com>
Message-ID: <59Gm2zbukVqcfEvk-8rFnG65qm82y9OqeZ_1wz18Q3Y=.417e338f-3f8c-4be3-a1f5-438921a692a7@github.com>

On Mon, 15 May 2023 18:45:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> I think writing a test is worth a little bit of time but getting a clean test run using the KILLTEST might be a bit tricky. The exit(-1) of the parent would be detected by jtreg as a failure. And verifying that the spawned child runs to completion might be difficult without writing a driver app to monitor the child; though it may be sufficient to know just that it does not hang and timeout. When the parent dies, the child will be re-parented.
> And it would only be run in debug builds.

> @RogerRiggs @simonis
> 
> Okay, I wrote a jtreg test case for the issue, just to see if I could. Rebased atop of Volkers change, you can just take the commit if you want:
> 
> https://github.com/tstuefe/jdk/tree/Added-TestCase-For-Volker [9119b44](https://github.com/openjdk/jdk/commit/9119b442dac8dd95228d47d70871ee59862649ce)
> 
> Test case fails immediately (so, no relying on timeouts) if Volkers patch is missing. Succeeds immediately with Volkers patch. I also tried commenting out the fixing close() call, test fails immediately.
> 
> Patch relies on jspawnhelper to write a small marker file on communication error with parent if KILLTEST is set. Only in debug code. I think this is very reliable. No second-guessing aliveness of the child and worrying about PID reuse. Re-parenting is no issue either. And I think such a file make be a good idea anyway to analyze handshake errors with jspawnhelper.
> 
> Tested on Linux x64.
> 
> @simonis, feel free to add me as contributor if you take this test. I spent way to much time on this :-)

Thank you @tstuefe . Unfortunately I saw this too late yesterday, when I already almost finished my version :)

I've now also added some "simulted crashes" to `jspawnhelper` at different points of the handshake. This didn't revealed any new issues but might be helpful for the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1551326215

From asotona at openjdk.org  Wed May 17 12:48:53 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 May 2023 12:48:53 GMT
Subject: Integrated: 8307326: Package jdk.internal.classfile.java.lang.constant
 become obsolete
In-Reply-To: <B7NPhT_4RixzCii1LIEVkwMrP6qNASaeOQ9Y2v9lPhk=.f9f9ca1e-9b8b-4b73-ad73-d882e35956db@github.com>
References: <B7NPhT_4RixzCii1LIEVkwMrP6qNASaeOQ9Y2v9lPhk=.f9f9ca1e-9b8b-4b73-ad73-d882e35956db@github.com>
Message-ID: <yez7C-OQ79w_Zj_sNrbot7UcgLI3V9m74U4HSLUZgXw=.76b1ed60-4741-4bdb-91a2-821344991400@github.com>

On Mon, 15 May 2023 08:38:54 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Package `jdk.internal.classfile.java.lang.constant` containing `ModuleDesc` and `PackageDesc` become obsolete after [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729). 
> All references to `jdk.internal.classfile.java.lang.constant.ModuleDesc` and `jdk.internal.classfile.java.lang.constant.PackageDesc` across all JDK sources, tests and JMH benchmarks are replaced with `java.lang.constant.ModuleDesc` and  `java.lang.constant.PackageDesc`. 
> `jdk.internal.classfile.java.lang.constant` package export hooks are removed from java.base module-info, make files and test headers. 
> Content of `jdk.internal.classfile.java.lang.constant` package and related tests under `jdk.classfile` are deleted.
> Method references renamed in [JDK-8306729](https://bugs.openjdk.org/browse/JDK-8306729) are fixed:
> - `PackageDesc::packageName` to `PackageDesc::name`
> - `PackageDesc::packageInternalName` to `PackageDesc::internalName`
> - `ModuleDesc::moduleName` to `ModuleDesc::name`.
> 
> Please review this pull request.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 5763be72
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5763be726700be322de3bbaf345d80e11936b472
Stats:     503 lines in 46 files changed: 0 ins; 446 del; 57 mod

8307326: Package jdk.internal.classfile.java.lang.constant become obsolete

Reviewed-by: erikj, liach

-------------

PR: https://git.openjdk.org/jdk/pull/13979

From simonis at openjdk.org  Wed May 17 12:50:44 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 17 May 2023 12:50:44 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <PhQwmHWsZpkaMtgk1o5cU8To6ltyCEk9NbOKa9LgDtI=.4f986b17-5117-4b47-a6bb-055a5f717694@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <PhQwmHWsZpkaMtgk1o5cU8To6ltyCEk9NbOKa9LgDtI=.4f986b17-5117-4b47-a6bb-055a5f717694@github.com>
Message-ID: <fYvBogZEfG6vz84VFk5ZYrdkDB98ij5klQ7F8YM6H0k=.99aeffad-fc37-4d61-a847-dbbd0b4bf91d@github.com>

On Mon, 15 May 2023 20:00:28 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Should this issue have a CSR for any behavioral changes?

Well, you can certainly argue that every bug fix is a behavioral changes, right :)

But seriously, I don't see how this PR could require a CSR. The only behavioral change is really that `jspawnhelper` can now no longer block and deadlock. But that's exactly how it should have behaved in the first place.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1551331092

From jpai at openjdk.org  Wed May 17 12:53:50 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 May 2023 12:53:50 GMT
Subject: RFR: 8305785: Avoid redundant HashMap.containsKey call in
 java.util.regex
In-Reply-To: <_WLYJq0pH0MAmUOuVtCJsRIYvmjtwi_cwW3_Wy341Ks=.17067b05-2a67-49f8-b167-6b2404165ae5@github.com>
References: <_WLYJq0pH0MAmUOuVtCJsRIYvmjtwi_cwW3_Wy341Ks=.17067b05-2a67-49f8-b167-6b2404165ae5@github.com>
Message-ID: <sn_Ze_k41CnDwpo8DH2kvCGxV5SkZVmnPio_m6gh0ik=.c8c9b88c-edb6-43e2-bcce-3131087cf25b@github.com>

On Mon, 3 Apr 2023 16:58:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Pattern.namedGroups` and `Matcher.namedGroups` contains only non-null values. It means instead of separate `containsKey`+`get` calls, we can use single `HashMap.get` call and then compare result with null.
> Result code is a bit simpler and faster.

This looks OK to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13303#pullrequestreview-1430610391

From redestad at openjdk.org  Wed May 17 12:59:49 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 17 May 2023 12:59:49 GMT
Subject: RFR: 8307483: New micros for j.u.c.LockSupport [v3]
In-Reply-To: <q77A4CdvYIyasyM1E1QsuBpNbrJ_QaNeAWGhHKaWKdM=.0bfb5dea-c9bf-4325-b3aa-0f88f76fc845@github.com>
References: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
 <q77A4CdvYIyasyM1E1QsuBpNbrJ_QaNeAWGhHKaWKdM=.0bfb5dea-c9bf-4325-b3aa-0f88f76fc845@github.com>
Message-ID: <DLVo40CwkB_H0dKDSnvI384qeg6yR5ZPa1jVF-syFZQ=.8a39d9e3-5187-4000-a6d4-1e161db57ccf@github.com>

On Tue, 9 May 2023 19:13:42 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

>> These micros were developed while investigating JDK-8305670 by myself and Sergey Kuksenko. The order of thread creation was important in that bug, so there are 2 JMH for creating sleepers before and after the worker threads.
>
> Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add review comments changes.

LGTM with @shipilev's suggestions

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13815#pullrequestreview-1430623870

From simonis at openjdk.org  Wed May 17 13:06:51 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 17 May 2023 13:06:51 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <OYKgi_f5c6Xb4qtKGH8K3iM1wlOLgQrAWcVBRgjEYTA=.98afbb2d-f910-421c-ad50-d6dbe222da1f@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <OYKgi_f5c6Xb4qtKGH8K3iM1wlOLgQrAWcVBRgjEYTA=.98afbb2d-f910-421c-ad50-d6dbe222da1f@github.com>
Message-ID: <XrNEaZfDt-J7olJRhGCYsBYvVi2XMiPGvGZ1AnJDS2s=.0c3b093d-e6be-45f9-9e9f-400b2d0c0358@github.com>

On Mon, 15 May 2023 19:55:45 GMT, Bernd <duke at openjdk.org> wrote:

> Independent of the actual fix, it was mentioned that it can block listening sockets, aren?t those close on exec? Also should a write and read timeout be used in addition? At least to call the close descriptor code before retrying?

While the JDK opens files with `FD_CLOEXEC` by default, this is not the case for sockets. There have been attempts to fix this (see "[JDK-8207335: Use SOCK_CLOEXEC when creating sockets and channels](https://bugs.openjdk.org/browse/JDK-8207335)", [mailing list thread](https://mail.openjdk.org/pipermail/net-dev/2018-July/thread.html#11622)) but they never made it into mainline.

Notice that this is usually only a problem if you fork from native code (e.g. in a JNI library). Otherwise the JDK takes care to close *all* file descriptors before `execvp()`ing a new process (see [this code in `childProcess()` in `childproc.c`](https://github.com/openjdk/jdk/blob/5763be726700be322de3bbaf345d80e11936b472/src/java.base/unix/native/libjava/childproc.c#L363-L369)).

In this specific case the sockets were not closed because `jspawnhelper` blocked very early, *before* cleaning up the file descriptors in `childProcess()`. But that's now fixed with this PR :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1551355679

From asotona at openjdk.org  Wed May 17 13:09:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 May 2023 13:09:48 GMT
Subject: RFR: 8306457: Classfile API components implementations should not
 be exposed [v3]
In-Reply-To: <uOL-fvFa6_nzRHkr26MzBSBbo7cF3SMvvJRsXTAxHSk=.1a1c786d-a90e-4a9f-9e04-234a09447bb0@github.com>
References: <67PAXfiqaTaU8vYbbA31WJBG029RHK454HIDp5ZlYx8=.ec9b4ddd-fe42-4236-9e44-ef63e164e906@github.com>
 <uOL-fvFa6_nzRHkr26MzBSBbo7cF3SMvvJRsXTAxHSk=.1a1c786d-a90e-4a9f-9e04-234a09447bb0@github.com>
Message-ID: <7iS0Kl3iq7H-6rrOl3sncckxGB-Tm2KFpHNUg8oQoJ0=.3cbc9c0d-5af4-41c5-97e7-2503bba50a9d@github.com>

On Tue, 16 May 2023 18:10:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The jdk.internal.classfile.components package's interfaces have implementations in their nested classes, which are implicitly public and exported with the package. They are now moved to the impl package to avoid unwanted exposures. Fixed a few minor javadoc issues in the interfaces as well.
>> 
>> In conflict with #13021; one needs updating if the other is merged.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Don't change formatting in the migration
>    
>    The changes are done by copying old implementation and removing one level (4 spaces) of indent.
>    The constructors of CodeLocalsShifterImpl and CodeStackTrackerImpl are promoted to public
>  - Merge branch 'master' into fix/hide-component-impl
>  - merge indy remap fix
>  - Merge branch 'master' into fix/hide-component-impl
>  - 8306457: Classfile API components implementations should not be exposed

Looks good, thank you.

-------------

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13541#pullrequestreview-1430647466

From asotona at openjdk.org  Wed May 17 13:31:48 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 May 2023 13:31:48 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v7]
In-Reply-To: <JMh5XDNYbKwuiuaQ-NcDvE6oA7nd1SrEABXEaApkLBc=.4883ba6b-1096-4005-879a-99d8dc2085d6@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <9WXdnsx_lbXdDej1YqximLLEDLIWDTz_jxtSU7iRTsw=.b1b54d6f-c220-4eb0-96bb-1b263466a0b4@github.com>
 <ICjNfloIZQAxrQj37TN7rq4csTp7GUUNM0F5Yhe3bz0=.710b9c67-d55c-411a-aa12-a92bfaa0bd90@github.com>
 <d_uERMjLGg-OJo5uCT0Qo_QyLpLPDgUA14F0FwUq2aU=.e2a03cc6-4fd7-4ef0-a3c6-a8d3788592eb@github.com>
 <JMh5XDNYbKwuiuaQ-NcDvE6oA7nd1SrEABXEaApkLBc=.4883ba6b-1096-4005-879a-99d8dc2085d6@github.com>
Message-ID: <WLkKplCxJCWRopJItohLZ1Ow8Kg14s3fquUVF6227kM=.a4f01e85-326d-4449-b5b3-da40c8025707@github.com>

On Tue, 16 May 2023 22:00:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I plan to share a backing list in #13186, with API additions so users can avoid copying their input immutable parameter list as well. I see no reason to use a direct array, for MTD is not passed to and used by the VM, unlike MethodType.
>
> Good, I think it makes perfect sense for the MTD parameter list to be immutable and shareable without copying.

Thank you for the review.
Yes, I'm looking forward to see it together with Constants API improvements in one benchamark ;)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1196525870

From asotona at openjdk.org  Wed May 17 13:41:16 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 17 May 2023 13:41:16 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v8]
In-Reply-To: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
Message-ID: <SfwaHiIZwStvsjeJ52fxlInzfKPORGAZwiliLKepN8s=.ebc76179-3c6e-4404-8e22-8fca42fbb5fc@github.com>

> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
> - Caching `MethodTypeDesc` in `MethodInfo` implementations
> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
> 
> No API change.
> 
> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
> 
> 
> Benchmark                     Mode  Cnt       Score       Error  Units
> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
> 
> 
> 
> Benchmark                     Mode  Cnt       Score      Error  Units
> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge branch 'master' into JDK-8306842-perf-improvements
   
   # Conflicts:
   #	make/RunTests.gmk
   #	src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
 - LinkedList replaced with ArrayList in benchmarks
 - Apply suggestions from code review
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - changed LinkedList to ArrayList in RebuildMethodBodies benchmark
 - added RepeatedModelTraversal JMH benchmark
 - fixed jmh benchmark parameters
 - fixed StackMapGenerator
 - Apply suggestions from code review
   
   Co-authored-by: liach <7806504+liach at users.noreply.github.com>
 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8306842-perf-improvements
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
   #	src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java
   #	src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
   #	test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
   #	test/jdk/jdk/classfile/StackMapsTest.java
 - more use of MethodInfo::methodTypeSymbol and faster ClassDesc slot size calculation
 - ... and 24 more: https://git.openjdk.org/jdk/compare/5763be72...d99e7ad0

-------------

Changes: https://git.openjdk.org/jdk/pull/13671/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13671&range=07
  Stats: 592 lines in 28 files changed: 386 ins; 90 del; 116 mod
  Patch: https://git.openjdk.org/jdk/pull/13671.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13671/head:pull/13671

PR: https://git.openjdk.org/jdk/pull/13671

From liach at openjdk.org  Wed May 17 13:41:16 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 17 May 2023 13:41:16 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v7]
In-Reply-To: <WLkKplCxJCWRopJItohLZ1Ow8Kg14s3fquUVF6227kM=.a4f01e85-326d-4449-b5b3-da40c8025707@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <9WXdnsx_lbXdDej1YqximLLEDLIWDTz_jxtSU7iRTsw=.b1b54d6f-c220-4eb0-96bb-1b263466a0b4@github.com>
 <ICjNfloIZQAxrQj37TN7rq4csTp7GUUNM0F5Yhe3bz0=.710b9c67-d55c-411a-aa12-a92bfaa0bd90@github.com>
 <d_uERMjLGg-OJo5uCT0Qo_QyLpLPDgUA14F0FwUq2aU=.e2a03cc6-4fd7-4ef0-a3c6-a8d3788592eb@github.com>
 <JMh5XDNYbKwuiuaQ-NcDvE6oA7nd1SrEABXEaApkLBc=.4883ba6b-1096-4005-879a-99d8dc2085d6@github.com>
 <WLkKplCxJCWRopJItohLZ1Ow8Kg14s3fquUVF6227kM=.a4f01e85-326d-4449-b5b3-da40c8025707@github.com>
Message-ID: <Gr-YauxcBQoaqF2iLMXqkGdkI1LEDwHEE0Zfm3wi-1s=.57898050-7195-4a4f-9255-da5c83540e1f@github.com>

On Wed, 17 May 2023 13:28:53 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Good, I think it makes perfect sense for the MTD parameter list to be immutable and shareable without copying.
>
> Thank you for the review.
> Yes, I'm looking forward to see it together with Constants API improvements in one benchamark ;)

Since you are available, can you help review my CSR request at https://bugs.openjdk.org/browse/JDK-8306699 as requested by Joe Darcy so we can get this improvement into release 21?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1196538285

From liach at openjdk.org  Wed May 17 13:49:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 17 May 2023 13:49:53 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v8]
In-Reply-To: <SfwaHiIZwStvsjeJ52fxlInzfKPORGAZwiliLKepN8s=.ebc76179-3c6e-4404-8e22-8fca42fbb5fc@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <SfwaHiIZwStvsjeJ52fxlInzfKPORGAZwiliLKepN8s=.ebc76179-3c6e-4404-8e22-8fca42fbb5fc@github.com>
Message-ID: <vJiEBLUJTfWZjIV24zicLO5hdgly8EDfehyZNYzeYkE=.aa74c748-3072-41d4-8f76-4e0b259510dd@github.com>

On Wed, 17 May 2023 13:41:16 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Following improvements implemented:
>> - Switch over `String` replaced with switch single char
>> - Binary search for frames in `StackMapGenerator`
>> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
>> - `ClassEntry` is caching `ClassDesc` symbol
>> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
>> - Caching `MethodTypeDesc` in `MethodInfo` implementations
>> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
>> 
>> No API change.
>> 
>> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
>> 
>> 
>> Benchmark                     Mode  Cnt       Score       Error  Units
>> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
>> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
>> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
>> 
>> 
>> 
>> Benchmark                     Mode  Cnt       Score      Error  Units
>> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
>> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
>> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Merge branch 'master' into JDK-8306842-perf-improvements
>    
>    # Conflicts:
>    #	make/RunTests.gmk
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
>  - LinkedList replaced with ArrayList in benchmarks
>  - Apply suggestions from code review
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - changed LinkedList to ArrayList in RebuildMethodBodies benchmark
>  - added RepeatedModelTraversal JMH benchmark
>  - fixed jmh benchmark parameters
>  - fixed StackMapGenerator
>  - Apply suggestions from code review
>    
>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8306842-perf-improvements
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java
>    #	src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
>    #	test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
>    #	test/jdk/jdk/classfile/StackMapsTest.java
>  - more use of MethodInfo::methodTypeSymbol and faster ClassDesc slot size calculation
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/5763be72...d99e7ad0

test/micro/org/openjdk/bench/jdk/classfile/AbstractCorpusBenchmark.java line 56:

> 54:         "--add-exports", "java.base/jdk.internal.classfile.constantpool=ALL-UNNAMED",
> 55:         "--add-exports", "java.base/jdk.internal.classfile.instruction=ALL-UNNAMED",
> 56:         "--add-exports", "java.base/jdk.internal.classfile.java.lang.constant=ALL-UNNAMED",

Here

test/micro/org/openjdk/bench/jdk/classfile/GenerateStackMaps.java line 64:

> 62:         "--add-exports", "java.base/jdk.internal.classfile.constantpool=ALL-UNNAMED",
> 63:         "--add-exports", "java.base/jdk.internal.classfile.instruction=ALL-UNNAMED",
> 64:         "--add-exports", "java.base/jdk.internal.classfile.java.lang.constant=ALL-UNNAMED",

Same here

test/micro/org/openjdk/bench/jdk/classfile/Write.java line 76:

> 74:         "--add-exports", "java.base/jdk.internal.classfile.constantpool=ALL-UNNAMED",
> 75:         "--add-exports", "java.base/jdk.internal.classfile.instruction=ALL-UNNAMED",
> 76:         "--add-exports", "java.base/jdk.internal.classfile.java.lang.constant=ALL-UNNAMED",

Since this package is gone, this export arg can be removed. There are a total of 3 occurrences I think.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1196545864
PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1196545744
PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1196545664

From duke at openjdk.org  Wed May 17 13:53:55 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 17 May 2023 13:53:55 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
   
   Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
 - removed StreamTokenizer changes, will make seperate ticket for those

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14006/files
  - new: https://git.openjdk.org/jdk/pull/14006/files/a79969c2..6d40e1c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14006&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14006&range=00-01

  Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14006.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14006/head:pull/14006

PR: https://git.openjdk.org/jdk/pull/14006

From duke at openjdk.org  Wed May 17 13:53:57 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Wed, 17 May 2023 13:53:57 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <khArxt__ygRlbr63kl1DtT4hHdV8MV7t649XSfhCvhI=.1c153e15-b509-4b30-833d-cdb196ea0ff7@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <khArxt__ygRlbr63kl1DtT4hHdV8MV7t649XSfhCvhI=.1c153e15-b509-4b30-833d-cdb196ea0ff7@github.com>
Message-ID: <Og1RmemzWJrIVkwiivXnQs7MCuO7eFHzNkH2PPDLNLc=.56c9a06d-1ef9-4d53-a38f-408bdcd9ce4d@github.com>

On Wed, 17 May 2023 10:41:57 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>>    
>>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>>  - removed StreamTokenizer changes, will make seperate ticket for those
>
> src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java line 516:
> 
>> 514: 
>> 515:         if (nccount != -1) {
>> 516:             ncstring = Integer.toHexString (nccount).toLowerCase(Locale.ROOT);
> 
> Suggestion:
> 
>             ncstring = Integer.toHexString(nccount);
> 
> `toHexString` returns lowercase string

Thanks for pointing that out!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14006#discussion_r1196555183

From ethan at mccue.dev  Wed May 17 14:07:47 2023
From: ethan at mccue.dev (Ethan McCue)
Date: Wed, 17 May 2023 10:07:47 -0400
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <e434c1fa-b00d-cccd-5a75-204227ab5a83@apache.org>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
 <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
 <CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com>
 <46167980-41fe-e214-9b67-ce0c5ca8c032@oracle.com>
 <1907607213.49439971.1683285286489.JavaMail.zimbra@univ-eiffel.fr>
 <e434c1fa-b00d-cccd-5a75-204227ab5a83@apache.org>
Message-ID: <CA+NR86ig2N9cWv-CbuSc0FY+=FEnyQ3KF70XytgG70BoOeo3BA@mail.gmail.com>

> if they have setup their projects correctly.

Can you be more clear about what "setup their projects correctly" means? If
you are referring to usage of --release, you seem to be making a pretty
strong argument that this will not be the case.

> We tested Apache Lucene and Apache Solr with Java 21.
> We have extensive use of chains of stream() calls with Stream.of() and
similar apis
> Use of "var" is still seldom

I'm sorry, but this doesn't seem to contradict the concern raised by Remi.
He, apparently, has codebases that do not compile as a result of the
SequencedCollections change. This means either

* He is doing something in those codebases which is uncommon and the risk
of wider breakage was adequately assessed by the Corpus experiment.
* He is doing something that is more common than the Corpus experiment
showed and that Corpus is not representative in a meaningful way.

That Lucene and Solr are in the clear doesn't seem relevant.

There is an implicit filter on the Java community of all the folks who even
touch preview builds, who would feel comfortable using a mailing list, and
who would feel comfortable offering a dissenting opinion. I don't know what
that means in terms of statistical significance of his issues, but it would
be insane if there was no effect.

On Wed, May 17, 2023 at 3:58?AM Uwe Schindler <uschindler at apache.org> wrote:

> Hi Remi, hi all,
> I'd like to add some information from open source projects and why I don't
> see the problem discussed here is a really serious one.
>
> Background: We tested Apache Lucene and Apache Solr with Java 21. The
> compilation with Gradle went fine. So actually there are no problems with
> the new superclasses. We have extensive use of chains of stream() calls
> with Stream.of() and similar apis. Use of "var" is still seldom but we use
> it now when newly introduced code around streams is added to spare
> verbosity. But still we got no problems. But why is this so?
>
> A good open source project should trigger the compiler with "--release".
> Apache Lucene uses Java 17 on main branch and Java 11 on 9.x branch. In
> both cases compilation worked due to the use of "--release". If we would
> change to Java 21 as compilation target, we may need to adapt our code.
>
> There are some problems with that:
>
>    - Not all projects use "--release", some projects still use "--source
>    --target". The problem with that is Maven and Gradle still not making
>    "--release" a first class citizen. Default configs only use "--source
>    --target".
>    - Code still on Java 8 can't use "--release", as the compiler does not
>    support it. The Lucene 8.x branch still open for bugfixes has a trick: It
>    detects the compiler and if it is Java 8 it passes "--source 8 --target 8",
>    while starting with Java 9 compiler it passes "--release 8". On the other
>    hand code still supporting java 8 is unlikely affected by the problem, as
>    it cannot use "var". But still chains of Stream.of().foo().bar() may still
>    be affected.
>
> What is a more serious source-incompatibility issue that I would always
> report to OpenJDK bug tracker: During testing Java 20 we were trapped by a
> compiler change that caused a source incompatibility (which was reverted,
> see https://bugs.openjdk.org/browse/JDK-8299416). So not even passing
> "--release" fixed the issue, because the compiler changed its semantics.
> This is in my opinion a breaking issue because it prevents code from
> compiling!
>
> The changes in sequenced collections should not be a too big problem for
> the community if they have setup their projects correctly.
>
> Uwe
>
> P.S.: To be honest: I tried to pass "--release 21" when compiling Lucene
> and it failed, but not for sequenced collections reasons. It was more some
> tests calling Runtime#runFinalization().
>
> Am 05.05.2023 um 13:14 schrieb forax at univ-mlv.fr:
>
> Hi Joe,
> in this peculiar case, there are several reasons to be worried compared to
> other potential breaking changes that has appeared in the past (see the
> message of Tagir for an example).
>
> Unlike other changes
> - this one touch the collection API, and those interfaces/types are widely
> used,
> - we know that the source compatibility changes occurs mostly if 'var' or
> the "new" inference algorithm (the one from Java 8), so this is likely that
> most of the issues will be found in Java 11+ source code,
> - this changes may also affect all typed languages based on the JVM, not
> only Java. Corpus of codes in Groovy, Kotlin and Scala also need to be
> checked. In case of Kotlin and Scala, 'var' is the default behavior but
> they have their own collections (or type system around collections in case
> of Kotlin), so knowing the real impact of this change is hard here.
>
> The problem of using a corpus experiment is that the corpus may not
> represent the current state of the Java ecosystem, or at least the one that
> may be impacted.
>
> The problem with the corpus experiment is also that you need to be aware
> that most moden open source projects use "--release" flag, so you have to
> patch it away from the build system.
>
> In my case, on my own repositories (public and private), i had only one
> occurrence of the issue in the main source codes because many of those
> repositories are not using 'var' or even the stream API but on the corpus
> of the unit tests we give to students to check their implementations,
> little less than a third of those JUnit classes had source compatibility
> issues because those tests are using 'var' and different collections
> heavily.
>
> And the situation is a little worst than that because in between now and
> the time people will use Java 21, a lot of codes will be written using Java
> 11 and 17 and may found incompatible later.
>
> A source incompatibility issue is not a big deal, as said in this thread,
> most of the time, explicitly fixing the type argument instead of inferring
> it make the code compile again.
> So the house is not burning, but we should raise awareness of this issue
> given that it may have a bigger impact than other source incompatible
> changes that occur previously.
>
> R?mi
>
> ------------------------------
>
> *From: *"joe darcy" <joe.darcy at oracle.com> <joe.darcy at oracle.com>
> *To: *"Ethan McCue" <ethan at mccue.dev> <ethan at mccue.dev>, "Raffaello
> Giulietti" <raffaello.giulietti at oracle.com>
> <raffaello.giulietti at oracle.com>
> *Cc: *"Remi Forax" <forax at univ-mlv.fr> <forax at univ-mlv.fr>, "Stuart
> Marks" <stuart.marks at oracle.com> <stuart.marks at oracle.com>,
> "core-libs-dev" <core-libs-dev at openjdk.java.net>
> <core-libs-dev at openjdk.java.net>
> *Sent: *Friday, May 5, 2023 4:38:16 AM
> *Subject: *Re: The introduction of Sequenced collections is not a source
> compatible change
>
> A few comments on the general compatibility policy for the JDK.
> Compatibility is looked after by the Compatibility and Specification Review
> (CSR) process ( Compatibility & Specification Review). Summarizing the
> approach,
>
> The general compatibility policy for exported APIs implemented in the JDK
> is:
>
>     * Don't break binary compatibility (as defined in the Java Language
> Specification) without sufficient cause.
>     * Avoid introducing source incompatibilities.
>     * Manage behavioral compatibility changes.
>
> https://wiki.openjdk.org/display/csr/Main
>
> None of binary, source, and behavioral compatibly are absolutes and
> judgement is used to assess the cost/benefits of changes. For example,
> strict source compatibility would preclude, say, introducing new public
> types in the java.lang package since the implicit import of types in
> java.lang could conflict with a same-named type *-imported from another
> package.
>
> When a proposed change is estimated to be sufficiently disruptive, we
> conduct a corpus experiment to evaluate the impact on the change on many
> public Java libraries. Back in Project Coin in JDK 7, that basic approach
> was used to help quantify various language design choices and the
> infrastructure to run such experiments has been built-out in the subsequent
> releases.
>
> HTH,
>
> -Joe
> CSR Group Lead
> On 5/4/2023 6:32 AM, Ethan McCue wrote:
>
> I guess this a good time to ask, ignoring the benefit part of a cost
> benefit analysis, what mechanisms do we have to measure the number of
> codebases relying on type inference this will break?
>
> Iirc Adoptium built/ran the unit tests of a bunch of public repos, but
> it's also a bit shocking if the jtreg suite had nothing for this.
>
> On Thu, May 4, 2023, 9:27 AM Raffaello Giulietti <
> raffaello.giulietti at oracle.com> wrote:
>
>> Without changing the semantics at all, you could also write
>>
>>         final List<Collection<String>> list =
>> Stream.<Collection<String>>of(nestedDequeue, nestedList).toList();
>>
>> to "help" type inference.
>>
>>
>>
>>
>> On 2023-05-03 15:12, forax at univ-mlv.fr wrote:
>> > Another example sent to me by a fellow French guy,
>> >
>> >      final Deque<String> nestedDequeue = new ArrayDeque<>();
>> >      nestedDequeue.addFirst("C");
>> >      nestedDequeue.addFirst("B");
>> >      nestedDequeue.addFirst("A");
>> >
>> >      final List<String> nestedList = new ArrayList<>();
>> >      nestedList.add("D");
>> >      nestedList.add("E");
>> >      nestedList.add("F");
>> >
>> >      final List<Collection<String>> list = Stream.of(nestedDequeue,
>> nestedList).toList();
>> >
>> > This one is cool because no 'var' is involved and using
>> collect(Collectors.toList()) instead of toList() solves the inference
>> problem.
>> >
>> > R?mi
>> >
>> > ----- Original Message -----
>> >> From: "Stuart Marks" <stuart.marks at oracle.com>
>> >> To: "Remi Forax" <forax at univ-mlv.fr>
>> >> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> >> Sent: Tuesday, May 2, 2023 2:44:28 AM
>> >> Subject: Re: The introduction of Sequenced collections is not a source
>> compatible change
>> >
>> >> Hi R?mi,
>> >>
>> >> Thanks for trying out the latest build!
>> >>
>> >> I'll make sure this gets mentioned in the release note for Sequenced
>> >> Collections.
>> >> We'll also raise this issue when we talk about this feature in the
>> Quality
>> >> Outreach
>> >> program.
>> >>
>> >> s'marks
>> >>
>> >> On 4/29/23 3:46 AM, Remi Forax wrote:
>> >>> I've several repositories that now fails to compile with the latest
>> jdk21, which
>> >>> introduces sequence collections.
>> >>>
>> >>> The introduction of a common supertype to existing collections is
>> *not* a source
>> >>> compatible change because of type inference.
>> >>>
>> >>> Here is a simplified example:
>> >>>
>> >>>     public static void m(List<Supplier<? extends Map<String,
>> String>>> factories) {
>> >>>     }
>> >>>
>> >>>     public static void main(String[] args) {
>> >>>       Supplier<LinkedHashMap<String,String>> supplier1 =
>> LinkedHashMap::new;
>> >>>       Supplier<SortedMap<String,String>> supplier2 = TreeMap::new;
>> >>>       var factories = List.of(supplier1, supplier2);
>> >>>       m(factories);
>> >>>     }
>> >>>
>> >>>
>> >>> This example compiles fine with Java 20 but report an error with Java
>> 21:
>> >>>     SequencedCollectionBug.java:28: error: method m in class
>> SequencedCollectionBug
>> >>>     cannot be applied to given types;
>> >>>       m(factories);
>> >>>       ^
>> >>>     required: List<Supplier<? extends Map<String,String>>>
>> >>>     found:    List<Supplier<? extends SequencedMap<String,String>>>
>> >>>     reason: argument mismatch; List<Supplier<? extends
>> SequencedMap<String,String>>>
>> >>>     cannot be converted to List<Supplier<? extends
>> Map<String,String>>>
>> >>>
>> >>>
>> >>>
>> >>> Apart from the example above, most of the failures I see are in the
>> unit tests
>> >>> provided to the students, because we are using a lot of 'var' in them
>> so they
>> >>> work whatever the name of the types chosen by the students.
>> >>>
>> >>> Discussing with a colleague, we also believe that this bug is not
>> limited to
>> >>> Java, existing Kotlin codes will also fail to compile due to this bug.
>> >>>
>> >>> Regards,
>> >>> R?mi
>>
>
> --
> Uwe Schindleruschindler at apache.org
> ASF Member, Member of PMC and Committer of Apache Lucene and Apache Solr
> Bremen, Germanyhttps://lucene.apache.org/https://solr.apache.org/
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230517/fa4dc591/attachment-0001.htm>

From stuefe at openjdk.org  Wed May 17 14:21:52 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 17 May 2023 14:21:52 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v2]
In-Reply-To: <7wDXcglvW1xSgIGL4fWRX_LtUl2wtfoaBYiu_z36YMs=.38e799cf-a942-4e05-90c3-3f757c480e9b@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <7wDXcglvW1xSgIGL4fWRX_LtUl2wtfoaBYiu_z36YMs=.38e799cf-a942-4e05-90c3-3f757c480e9b@github.com>
Message-ID: <VkG2Y0wZIyZjDfbEult4z6sMFHtzXrqrKDed7UgTJPo=.9c93a305-cd45-4207-8421-327bd26ddfbf@github.com>

On Wed, 17 May 2023 12:33:48 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added test case

The fixes look reasonable, though I would prefer them to be split over individual RFEs. Would make backporting easier too.

I would still like an automated test as part of the jtreg suite. Please see my test proposal, that thing should be adaptable to work with your fix.

src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 140:

> 138:     struct stat buf;
> 139:     /* argv[0] contains the fd number to read all the child info */
> 140:     int r, fdinr, fdinw, fdout;

Since you are here, can you init these?

src/java.base/unix/native/libjava/ProcessImpl_md.c line 490:

> 488:     pid_t resultPid;
> 489:     int i, offset, rval, bufsize, magic;
> 490:     char *buf, buf1[24];

Since you are here could you please increase buffer size to something safe? Max len of INT_MIN is 11 bytes, so lets have at least 3*11 + 3 bytes.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13956#pullrequestreview-1430748541
PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1196551493
PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1196586907

From liach at openjdk.org  Wed May 17 14:25:49 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 17 May 2023 14:25:49 GMT
Subject: RFR: 8308281: Java snippets in the FFM API need to be updated
In-Reply-To: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>
References: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>
Message-ID: <yJEMw5mKOAtawlDtVWJ5-PToNZHY62GAKaf44cn_NKU=.2e0e3366-5a2c-4f81-b106-2bdd3797b904@github.com>

On Wed, 17 May 2023 11:46:39 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> As the API has improved over the recent releases, not all `{@snippet ..}` sections have been kept in sync.
> 
> This PR suggests all snippets used should be verified against real code that is placed in a new `snippet-files` folder and erroneous snippets are updated.
> 
> In this PR, it is suggested duplicating code in the `Snippets.java` class and in the JavaDocs. The benefit of this is that code is directly visible in the code and not only in the generated javadoc.
> 
> Another thing to think about is if there should be on single `Snippets.java` class or separate ones for each FFM class.

src/java.base/share/classes/java/lang/foreign/Arena.java line 168:

> 166:  *
> 167:  *      public MemorySegment allocate(long byteSize, long byteAlignment) {
> 168:  *            return slicingAllocator.allocate(byteSize, byteAlignment);

Shouldn't the indentation be 4 spaces?
Suggestion:

 *          return slicingAllocator.allocate(byteSize, byteAlignment);

src/java.base/share/classes/java/lang/foreign/Arena.java line 172:

> 170:  *
> 171:  *      public MemorySegment.Scope scope() {
> 172:  *            return arena.scope();

Suggestion:

 *          return arena.scope();

src/java.base/share/classes/java/lang/foreign/Arena.java line 176:

> 174:  *
> 175:  *      public void close() {
> 176:  *            arena.close();

Suggestion:

 *          arena.close();

src/java.base/share/classes/java/lang/foreign/Linker.java line 96:

> 94:  * try (Arena arena = Arena.ofConfined()) {
> 95:  *     MemorySegment str = arena.allocateUtf8String("Hello");
> 96:  *     long len          = (long) strlen.invoke(str);  // 5

Suggestion:

 *     long len          = (long) strlen.invokeExact(str);  // 5

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14030#discussion_r1196588335
PR Review Comment: https://git.openjdk.org/jdk/pull/14030#discussion_r1196588479
PR Review Comment: https://git.openjdk.org/jdk/pull/14030#discussion_r1196588748
PR Review Comment: https://git.openjdk.org/jdk/pull/14030#discussion_r1196593902

From tholenstein at openjdk.org  Wed May 17 14:43:48 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Wed, 17 May 2023 14:43:48 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly
Message-ID: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>

At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 

### Old CompileOnly format
- matching a **method name** with **class name** and **package name**:
`-XX:CompileOnly=package/path/Class.method`
`-XX:CompileOnly=package/path/Class::method`
`-XX:CompileOnly=package.path.Class::method`
BUT NOT `-XX:CompileOnly=package.path.Class.method`

- just matching a **single method name**:
`-XX:CompileOnly=.hashCode`
`-XX:CompileOnly=::hashCode`
BUT NOT `-XX:CompileOnly=hashCode`

- Matching **all method names** in a **class name** with **package name**
`-XX:CompileOnly=java/lang/String`
BUT NOT `-XX:CompileOnly=java/lang/String.`
BUT NOT `-XX:CompileOnly=java.lang.String`
BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
BUT NOT `-XX:CompileOnly=String`
BUT NOT `-XX:CompileOnly=String.`
BUT NOT `-XX:CompileOnly=String::`

- Matching **all method names** in a **class name** with **NO package name**
`-XX:CompileOnly=String`
BUT NOT `-XX:CompileOnly=String.`
BUT NOT `-XX:CompileOnly=String::`

- There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command

### CompileCommand=compileonly format
`CompileCommand` allows two different forms for paths: 
- `package/path/Class.method`
- `package.path.Class::method`

In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 

 Valid forms: 
`-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
`-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
`-XX:CompileCommand=compileonly,java.lang.String::*`
`-XX:CompileCommand=compileonly,*::hashCode`
`-XX:CompileCommand=compileonly,*ng.String::hashC*`
`-XX:CompileCommand=compileonly,*String::hash*`

 Invalid forms (Error: Embedded * not allowed):
 `-XX:CompileCommand=compileonly,java.*.String::has*Code`

### Use CompileCommand syntax for CompileOnly
At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 

`CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 

With this PR `CompileOnly` becomes an alias for `CompileCommand=compileonly` with possibility to take lists as input. 

New syntax for `CompileOnly`:
- `-XX:CompileOnly=pattern1,pattern2`
is an **alias** for: 
- `-XX:CompileCommand=compileonly,pattern1 -XX:CompileCommand=compileonly,pattern2`

### Handling invalid syntax
Before `CompileOnly` just ignored invalid syntax. `CompileCommand` at least prints an error massage for invalid patterns:

CompileOnly: An error occurred during parsing
Error: Could not parse method pattern
Line: 'pattern'

Since `CompileOnly` now maps to `CompileCommand` is also prints the error message for invalid inputs. 
In the future `CompileCommand` (and `CompileOnly`) parsing errors could exit the VM https://bugs.openjdk.org/browse/JDK-8282797

### Changed test cases
In the following we mean with `-XX:CompileOnly=oldPattern` -> `-XX:CompileOnly=newPattern` that we changed the tests from the `oldPattern` to the `newPattern`:
- `Class.method` -> `Class::method` AND `package/path/Class.method` -> `package.path.Class::method`
Prefer the `package.path.Class::method` format because it is used by `-XX:+PrintCompilation`

- `Class` -> `Class::*`
The `CompileCommand` format requires the `::` to define if `Class` is a class name or a method name. 

- `::method` -> `*::method`
The `CompileCommand` format requires the `*`(wildcard) if no class name is given. 

- `package/path/Class` -> `package.path.Class::*`
The `CompileCommand` format requires the `*`(wildcard) if no method name is given. 
Prefer the `package.path.Class::method` format because it is used by `-XX:+PrintCompilation`

- `::get,::get1` -> `*Class::get*`
The `CompileCommand` format requires the `*`(wildcard) if no method name is given. Therefore `*::get` would work as well, but this matches many other methods as well like `java.util.HashMap::get`.
`*Class::get,*Class::get1` matches the wanted class name - `*Class::get*` is just the short form. 

- `package/path/Class::method` -> `package.path.Class::method`
The old format of `CompileOnly` combining `/` with `::`. 
The `CompileCommand` is either `package/path/Class.method` or `package.path.Class::method`. 

- _BUG_: `package.path.Class::` -> `package.path.Class::*`
There was a bug in the old format of `CompileOnly` : when the pattern ended with `::` the `CompileOnly` was just ignored and all methods compiled. The `CompileCommand` format requires the `*`(wildcard) if no method name is given.

-------------

Commit messages:
 - Updated copyright
 - fix CompileOnly tests
 - JDK-8027711: Unify wildcarding syntax for CompileCommand and CompileOnly

Changes: https://git.openjdk.org/jdk/pull/13802/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13802&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8027711
  Stats: 376 lines in 71 files changed: 29 ins; 73 del; 274 mod
  Patch: https://git.openjdk.org/jdk/pull/13802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13802/head:pull/13802

PR: https://git.openjdk.org/jdk/pull/13802

From tholenstein at openjdk.org  Wed May 17 14:43:55 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Wed, 17 May 2023 14:43:55 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly
In-Reply-To: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
Message-ID: <uY1nGfJsaorIL316N0ABwltqLvjlN-nsyNxEgrjAAqg=.9c1aa742-645a-4025-9728-3b0e57985bc2@github.com>

On Thu, 4 May 2023 13:36:22 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
> 
> ### Old CompileOnly format
> - matching a **method name** with **class name** and **package name**:
> `-XX:CompileOnly=package/path/Class.method`
> `-XX:CompileOnly=package/path/Class::method`
> `-XX:CompileOnly=package.path.Class::method`
> BUT NOT `-XX:CompileOnly=package.path.Class.method`
> 
> - just matching a **single method name**:
> `-XX:CompileOnly=.hashCode`
> `-XX:CompileOnly=::hashCode`
> BUT NOT `-XX:CompileOnly=hashCode`
> 
> - Matching **all method names** in a **class name** with **package name**
> `-XX:CompileOnly=java/lang/String`
> BUT NOT `-XX:CompileOnly=java/lang/String.`
> BUT NOT `-XX:CompileOnly=java.lang.String`
> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
> BUT NOT `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - Matching **all method names** in a **class name** with **NO package name**
> `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
> 
> ### CompileCommand=compileonly format
> `CompileCommand` allows two different forms for paths: 
> - `package/path/Class.method`
> - `package.path.Class::method`
> 
> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
> 
>  Valid forms: 
> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
> `-XX:CompileCommand=compileonly,java.lang.String::*`
> `-XX:CompileCommand=compileonly,*::hashCode`
> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
> `-XX:CompileCommand=compileonly,*String::hash*`
> 
>  Invalid forms (Error: Embedded * not allowed):
>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
> 
> ### Use CompileCommand syntax for CompileOnly
> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
> 
> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
> 
> With this PR `CompileOnly` becomes an alias for `CompileC...

The CSR can be found here: https://bugs.openjdk.org/browse/JDK-8308287

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13802#issuecomment-1551524277

From mdoerr at openjdk.org  Wed May 17 15:02:49 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 17 May 2023 15:02:49 GMT
Subject: RFR: 8308246: PPC64le build broken after JDK-8304913 [v2]
In-Reply-To: <pT5KIldLSnitmqwiukgLug6iQ4y0HdPagkGtPyKsmbE=.44b1df46-c7a0-47e4-97c1-0547bef8004e@github.com>
References: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
 <pT5KIldLSnitmqwiukgLug6iQ4y0HdPagkGtPyKsmbE=.44b1df46-c7a0-47e4-97c1-0547bef8004e@github.com>
Message-ID: <qcGo--s0BzR19hWEAzT7puruN7kmWQTXqg2phOp1kNg=.3e442fb1-0cc5-429a-a491-32e9e83abda8@github.com>

On Wed, 17 May 2023 09:42:58 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> PPC64le needs to get recognized as PPC64. Otherwise, jlink doesn't recognize the platform and throws a PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.PPC64LE.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback.

Thanks for reviewing and feedback! I'm repairing the build:

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14027#issuecomment-1551547628

From rriggs at openjdk.org  Wed May 17 15:03:16 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 May 2023 15:03:16 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v2]
In-Reply-To: <7wDXcglvW1xSgIGL4fWRX_LtUl2wtfoaBYiu_z36YMs=.38e799cf-a942-4e05-90c3-3f757c480e9b@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <7wDXcglvW1xSgIGL4fWRX_LtUl2wtfoaBYiu_z36YMs=.38e799cf-a942-4e05-90c3-3f757c480e9b@github.com>
Message-ID: <BSrm0CrbY1CRrO6w50iQBjtrlHPAOmB4KVYN1DqMLO8=.b5234562-2c75-4303-8875-ab97eefb2baa@github.com>

On Wed, 17 May 2023 12:33:48 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added test case

src/java.base/unix/native/libjava/childproc.c line 408:

> 406:  * or the newly created jspawnhelper child process during the execution of
> 407:  * Java_java_lang_ProcessImpl_forkAndExec().
> 408:  * See: test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java

Is there a file missing from the commit? Where is JspawnhelperProtocol.java?
It might be useful to include the bug number; though generally they can get stale and uninteresting quickly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1196651832

From rriggs at openjdk.org  Wed May 17 15:02:52 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 May 2023 15:02:52 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <fYvBogZEfG6vz84VFk5ZYrdkDB98ij5klQ7F8YM6H0k=.99aeffad-fc37-4d61-a847-dbbd0b4bf91d@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <PhQwmHWsZpkaMtgk1o5cU8To6ltyCEk9NbOKa9LgDtI=.4f986b17-5117-4b47-a6bb-055a5f717694@github.com>
 <fYvBogZEfG6vz84VFk5ZYrdkDB98ij5klQ7F8YM6H0k=.99aeffad-fc37-4d61-a847-dbbd0b4bf91d@github.com>
Message-ID: <NKcMniUs_0zJlCLT2gnPfqBIjOxQuA0lHdo1UqKS33Q=.41e36a92-1660-42a3-8fce-52edf9ab3b2f@github.com>

On Wed, 17 May 2023 12:48:17 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> > Should this issue have a CSR for any behavioral changes?
> 
> Well, you can certainly argue that every bug fix is a behavioral changes, right :)
> 
> But seriously, I don't see how this PR could require a CSR. The only behavioral change is really that `jspawnhelper` can now no longer block and deadlock. But that's exactly how it should have behaved in the first place.

Not quite the bar needed for a CSR, but it might be useful to write a release note with a more problem oriented descriptive title. The current title describes the solution, not the problem.
Something that includes the ideas in "process launch can hang if parent process dies prematurely".

Anyone observing this behavior in their own operations would not find this this issue.
A release note would provide an explanation and closure for issues they might have been seeing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1551531952

From redestad at openjdk.org  Wed May 17 15:03:00 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 17 May 2023 15:03:00 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage [v3]
In-Reply-To: <cJ6sxFyGezNQ6I3y-5DAnLyIj9Wge5E43lksFc-LaTw=.cb00dfcd-086f-48b4-92cf-c6aec5c6a103@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
 <cJ6sxFyGezNQ6I3y-5DAnLyIj9Wge5E43lksFc-LaTw=.cb00dfcd-086f-48b4-92cf-c6aec5c6a103@github.com>
Message-ID: <vKEJxCBmtiQiwnnLSwgTVpwylrwF199ir7u-24aLH44=.6ef5c5c8-eec7-4cca-935d-964d0999f787@github.com>

On Wed, 17 May 2023 09:19:10 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> When appropriate and useful, copies only the relevant portion of the `CharSequence` to the match result.
>
> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Adjusted incorrect logic in results().
>    Added tests for results().
>    Refined capturing logic when there's no match.
>  - Merge branch 'master' into JDK-8132995
>  - Adjusted erroneous logic in results().
>    Added tests for results().
>  - Added some randomness in tests.
>  - 8132995: Matcher should be optimized to reduce space usage

LGTM. 

Consider simplifying `text instanceof String s ? s.substring(first, last) : text.subSequence(first, last).toString()` to just `text.subSequence(first, last).toString()`

src/java.base/share/classes/java/util/regex/Matcher.java line 278:

> 276:     public MatchResult toMatchResult() {
> 277:         String capturedText = hasMatch()
> 278:                 ? text instanceof String s

This `instanceof` became a little gratuitous now since `text.subSequence(..)` on `String` delegates to `substring` and the `toString()` will be a no-op.

-------------

Marked as reviewed by redestad (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13231#pullrequestreview-1430876173
PR Review Comment: https://git.openjdk.org/jdk/pull/13231#discussion_r1196633626

From rgiulietti at openjdk.org  Wed May 17 15:03:08 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 17 May 2023 15:03:08 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage [v3]
In-Reply-To: <vKEJxCBmtiQiwnnLSwgTVpwylrwF199ir7u-24aLH44=.6ef5c5c8-eec7-4cca-935d-964d0999f787@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
 <cJ6sxFyGezNQ6I3y-5DAnLyIj9Wge5E43lksFc-LaTw=.cb00dfcd-086f-48b4-92cf-c6aec5c6a103@github.com>
 <vKEJxCBmtiQiwnnLSwgTVpwylrwF199ir7u-24aLH44=.6ef5c5c8-eec7-4cca-935d-964d0999f787@github.com>
Message-ID: <QnR5nGXfFK7I3dyTtb-Y4kkv1ccDR2EOmfJP6H-HV9I=.7810255a-bbdf-4422-8336-7f7d981c9215@github.com>

On Wed, 17 May 2023 14:42:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Adjusted incorrect logic in results().
>>    Added tests for results().
>>    Refined capturing logic when there's no match.
>>  - Merge branch 'master' into JDK-8132995
>>  - Adjusted erroneous logic in results().
>>    Added tests for results().
>>  - Added some randomness in tests.
>>  - 8132995: Matcher should be optimized to reduce space usage
>
> src/java.base/share/classes/java/util/regex/Matcher.java line 278:
> 
>> 276:     public MatchResult toMatchResult() {
>> 277:         String capturedText = hasMatch()
>> 278:                 ? text instanceof String s
> 
> This `instanceof` became a little gratuitous now since `text.subSequence(..)` on `String` delegates to `substring` and the `toString()` will be a no-op.

Addressed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13231#discussion_r1196653497

From duke at openjdk.org  Wed May 17 15:03:04 2023
From: duke at openjdk.org (Bernd)
Date: Wed, 17 May 2023 15:03:04 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <qh4P0rQhdigeWLoD9paOaTJgT7uXOU0IsBTQlFdZ3Ew=.1eb8ea15-2d10-45e3-b883-87b088e220ba@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>
 <WNS9AUc4Uo0uJT7Q-c5WmRQGPXKHOiQ5bk3FAVhcpTw=.7b192c55-1a39-48bf-9c36-eb8219474c4f@github.com>
 <u7bSYYuppXZ1z347-wRTJf9GoxNUW-GoWfSn4dmCLEE=.831249e0-e538-491c-8001-a7dd55673721@github.com>
 <yZM9iro4FRdHveBRx07oeItZ9_CmQJ4wksNo3XI8Igs=.7b2097d5-0852-4f04-9c14-fc8d39a57c08@github.com>
 <qh4P0rQhdigeWLoD9paOaTJgT7uXOU0IsBTQlFdZ3Ew=.1eb8ea15-2d10-45e3-b883-87b088e220ba@github.com>
Message-ID: <UEWUBLJugdp1ab0fAHWoJ89R6CBkSPVT90StoyYCUjE=.9dad941c-28e0-4e85-9637-c3ef3ec9e44a@github.com>

On Wed, 17 May 2023 12:40:58 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> If we do a short read we will work with corrupted `ChildStuff` and `SpawnInfo` structures.

i would agree failing after readFully returns short reads is fine. It won?t stop the method from retrying/completing endlessly in a pathological condition (like the missing close), though).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1551554490

From rgiulietti at openjdk.org  Wed May 17 15:05:53 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 17 May 2023 15:05:53 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage [v4]
In-Reply-To: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
Message-ID: <7SYKnNqUsGXJKoht_Azqh8wAoBcWgCYNko2eg4nqtBA=.0ae7d114-a5ee-4fdc-94e3-0d7ffecdae7b@github.com>

> When appropriate and useful, copies only the relevant portion of the `CharSequence` to the match result.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Simplified text capturing.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13231/files
  - new: https://git.openjdk.org/jdk/pull/13231/files/4b8ead1d..b5621d52

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13231&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13231&range=02-03

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13231.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13231/head:pull/13231

PR: https://git.openjdk.org/jdk/pull/13231

From mdoerr at openjdk.org  Wed May 17 15:14:46 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 17 May 2023 15:14:46 GMT
Subject: Integrated: 8308246: PPC64le build broken after JDK-8304913
In-Reply-To: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
References: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
Message-ID: <ufQbHyD5_9Q9WbWhMUPfx-R61gSkVJK5w8Wq7SmBwJw=.89b8420f-37d7-4eb4-b1fb-e81c1176da6b@github.com>

On Wed, 17 May 2023 07:16:17 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> PPC64le needs to get recognized as PPC64. Otherwise, jlink doesn't recognize the platform and throws a PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.PPC64LE.

This pull request has now been integrated.

Changeset: 64f6681c
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64f6681cc7bb184112adcf2b4f2c313e1b0a5c4f
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8308246: PPC64le build broken after JDK-8304913

Reviewed-by: shade, mbaesken

-------------

PR: https://git.openjdk.org/jdk/pull/14027

From rgiulietti at openjdk.org  Wed May 17 15:21:20 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 17 May 2023 15:21:20 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage [v4]
In-Reply-To: <7SYKnNqUsGXJKoht_Azqh8wAoBcWgCYNko2eg4nqtBA=.0ae7d114-a5ee-4fdc-94e3-0d7ffecdae7b@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
 <7SYKnNqUsGXJKoht_Azqh8wAoBcWgCYNko2eg4nqtBA=.0ae7d114-a5ee-4fdc-94e3-0d7ffecdae7b@github.com>
Message-ID: <6KGr-0UDKHW8MYXrFMOIaPj8FhbeJdVx_y3irH1TBcA=.5a789a68-d968-42dd-9866-3fb8c14dd7c8@github.com>

On Wed, 17 May 2023 15:05:53 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> When appropriate and useful, copies only the relevant portion of the `CharSequence` to the match result.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified text capturing.

@stuart-marks Is there anything you'd like to add before integration?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13231#issuecomment-1551595036

From darcy at openjdk.org  Wed May 17 15:34:17 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 May 2023 15:34:17 GMT
Subject: Integrated: JDK-8308239: Tighten up accessibility of nested classes in
 java.lang.invoke
In-Reply-To: <IsG1KyYI7vkg1D422gDL-v3OQ73Ji5ykXkAjlNqZQd0=.ab31339c-3b06-4d3b-a7cd-08660b6313be@github.com>
References: <IsG1KyYI7vkg1D422gDL-v3OQ73Ji5ykXkAjlNqZQd0=.ab31339c-3b06-4d3b-a7cd-08660b6313be@github.com>
Message-ID: <DTQwjOw2n6OTPokc6T3IGBRhLGKoo0RuwHzqBVs4VZQ=.8845c247-489c-4d19-acca-cfafb1eea010@github.com>

On Tue, 16 May 2023 21:35:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Tightening up accessibility of a few nested classes. There is no practical impact on source compatibility -- source uses within the package still work, but by default the ability to reflectively call methods on these classes is disabled.

This pull request has now been integrated.

Changeset: f57c7833
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f57c78337e4f968c2e6a924acbebf725d4e46d59
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8308239: Tighten up accessibility of nested classes in java.lang.invoke

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14021

From rriggs at openjdk.org  Wed May 17 15:39:45 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 May 2023 15:39:45 GMT
Subject: RFR: 8308246: PPC64le build broken after JDK-8304913 [v2]
In-Reply-To: <AZby-FH4GtMPU5l7Vpzusdqq_sZyHhy5tz_3dd8zq9M=.72e091d6-37a1-492e-99a2-23edf81cc493@github.com>
References: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
 <HWJgPPDg_nNp-GkQ8BixcLEM_lIAVGB-hbr38QhVmr0=.b94c467a-ef46-4914-bab1-9e21e0850bae@github.com>
 <8cFw940aUmPolVFVRnjMZYw1yKpIy-A3E89G2RzlIlk=.c1e6e29a-3083-4c75-b13c-278e6854852c@github.com>
 <AZby-FH4GtMPU5l7Vpzusdqq_sZyHhy5tz_3dd8zq9M=.72e091d6-37a1-492e-99a2-23edf81cc493@github.com>
Message-ID: <X0Dhk2-vsZxMWY3VIicRi3OP0hVe5PLu2SiX2bfhzCc=.9005c344-e4c3-40f9-8761-4d74081397f4@github.com>

On Wed, 17 May 2023 10:31:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Yes, linux-ppc64 is big endian. The 2 flavors are completely incompatible. linux-ppc64le is basically a new platform. Endianness should actually get checked in addition to the archName.
>
>> Yes, linux-ppc64 is big endian. The 2 flavors are completely incompatible. linux-ppc64le is basically a new platform. Endianness should actually get checked in addition to the archName.
> 
> Okay, I was only asking because the ModuleTarget attribute has the OS and arch, the endianness is derived from those right now. Maybe in the future there can be more about the architecture and processor features (e.g. soft vs. hard float).  So mulling over this change and wondering what happens if there is cross linking involve these two platforms.

Hmm,  most java bytecode (classfiles) aren't going to care about the endian-ness; in int is an int, etc.
Runtime calls to extract int from byte[] is going to check a runtime flag; possibly static and optimization by HotSpot, etc.
The Architecture enum was intending to capture essential build time attributes.
If there is a need for more static attributes of a build, the current API doesn't cover that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14027#discussion_r1196716416

From rriggs at openjdk.org  Wed May 17 15:52:58 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 May 2023 15:52:58 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>
 <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com>
Message-ID: <A4cl0OLlMYnjcv-85F4iGTfC3IS7lvT6_f563gGxz9U=.fa8f3b04-5c24-4401-8c4a-995fb6c06f3a@github.com>

On Sun, 14 May 2023 05:50:20 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8308016: Remove ellipses ("...") from snippets
>
> src/java.base/share/classes/java/io/RandomAccessFile.java line 904:
> 
>> 902:      * {@code b7}, and {@code b8,} where:
>> 903:      * {@snippet lang=java :
>> 904:      *         0 <= b1, b2, b3, b4, b5, b6, b7, b8 <= 255,
> 
> Same: this is not Java language syntax. Code or pre tags are fine here, they are not deprecated.

I would keep the snippet markup but change the language to "text"; removing the expectation of language support.
The benefits of a consistent look are still desirable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1196733214

From simonis at openjdk.org  Wed May 17 16:00:23 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 17 May 2023 16:00:23 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v3]
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <V6X7mD9t_bH6l8iYAxk2B8wszDqj8_Oa9zcgarrxotc=.6beeb6ad-6ddc-4ab4-a3c7-1c35050e3978@github.com>

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  REALLY adding the test :)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13956/files
  - new: https://git.openjdk.org/jdk/pull/13956/files/2bef75a0..edfec9fe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13956&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13956&range=01-02

  Stats: 176 lines in 1 file changed: 176 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13956/head:pull/13956

PR: https://git.openjdk.org/jdk/pull/13956

From simonis at openjdk.org  Wed May 17 16:00:25 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 17 May 2023 16:00:25 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v2]
In-Reply-To: <BSrm0CrbY1CRrO6w50iQBjtrlHPAOmB4KVYN1DqMLO8=.b5234562-2c75-4303-8875-ab97eefb2baa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <7wDXcglvW1xSgIGL4fWRX_LtUl2wtfoaBYiu_z36YMs=.38e799cf-a942-4e05-90c3-3f757c480e9b@github.com>
 <BSrm0CrbY1CRrO6w50iQBjtrlHPAOmB4KVYN1DqMLO8=.b5234562-2c75-4303-8875-ab97eefb2baa@github.com>
Message-ID: <pQcv5NM5-UXVbb3bP281LSoozvwULLwzpAu1RpNGWaM=.0c3fa545-b3ca-4fd1-a7b1-2eaf7e641258@github.com>

On Wed, 17 May 2023 14:55:00 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added test case
>
> src/java.base/unix/native/libjava/childproc.c line 408:
> 
>> 406:  * or the newly created jspawnhelper child process during the execution of
>> 407:  * Java_java_lang_ProcessImpl_forkAndExec().
>> 408:  * See: test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java
> 
> Is there a file missing from the commit? Where is JspawnhelperProtocol.java?
> It might be useful to include the bug number; though generally they can get stale and uninteresting quickly.

Sorry, I could say I wanted to see if somebody is really looking at this, but in reality I just missed to add the new test file to the commit :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1196738178

From simonis at openjdk.org  Wed May 17 16:08:39 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 17 May 2023 16:08:39 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v2]
In-Reply-To: <VkG2Y0wZIyZjDfbEult4z6sMFHtzXrqrKDed7UgTJPo=.9c93a305-cd45-4207-8421-327bd26ddfbf@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <7wDXcglvW1xSgIGL4fWRX_LtUl2wtfoaBYiu_z36YMs=.38e799cf-a942-4e05-90c3-3f757c480e9b@github.com>
 <VkG2Y0wZIyZjDfbEult4z6sMFHtzXrqrKDed7UgTJPo=.9c93a305-cd45-4207-8421-327bd26ddfbf@github.com>
Message-ID: <YY8ZiTzjcdkYsJUh7N4x7Tcm4gLUemKmLA_KzE4d3lI=.ef3e2c0e-ec39-4bef-b72e-741aae4d905c@github.com>

On Wed, 17 May 2023 13:46:29 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added test case
>
> src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 140:
> 
>> 138:     struct stat buf;
>> 139:     /* argv[0] contains the fd number to read all the child info */
>> 140:     int r, fdinr, fdinw, fdout;
> 
> Since you are here, can you init these?

What would be the right value to initialize them to and what would it help? We use `sscanf()` right in the following line and exit if `sscanf()` is not assigning all three values. I think that should be good enough.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1196757471

From joe.darcy at oracle.com  Wed May 17 16:08:54 2023
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 17 May 2023 09:08:54 -0700
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <CA+NR86ig2N9cWv-CbuSc0FY+=FEnyQ3KF70XytgG70BoOeo3BA@mail.gmail.com>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
 <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
 <CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com>
 <46167980-41fe-e214-9b67-ce0c5ca8c032@oracle.com>
 <1907607213.49439971.1683285286489.JavaMail.zimbra@univ-eiffel.fr>
 <e434c1fa-b00d-cccd-5a75-204227ab5a83@apache.org>
 <CA+NR86ig2N9cWv-CbuSc0FY+=FEnyQ3KF70XytgG70BoOeo3BA@mail.gmail.com>
Message-ID: <8c107e75-fecc-f961-f9c0-ab75ea7cd8dd@oracle.com>

On 5/17/2023 7:07 AM, Ethan McCue wrote:
> > if they have setup their projects correctly.
>
> Can you be more clear about what "setup their projects correctly" 
> means? If you are referring to usage of --release, you seem to be 
> making a pretty strong argument that this will not be the case.
>

Use of "javac --release $OLD ..." rather than "javac -source $OLD 
-target $OLD ..." avoids certain categories of false compatibility problems.

In brief, " -source $OLD -target $OLD " alone doesn't set the 
bootclasspath equivalent to the libraries on the old release, meaning 
the compiled code can use newer methods in the core libraries, such as a 
new overload or a new? covariant override of an existing method. Those 
new methods do not exist when actually running against the old release.

That above situation doesn't happen all the time, but happened often 
enough to generate a steady trickle of bug reports before --release was 
introduced. To avoid this, --release also sets the bootclasspath 
equivalent to the older value.

HTH,

-Joe


From simonis at openjdk.org  Wed May 17 16:15:16 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 17 May 2023 16:15:16 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v2]
In-Reply-To: <VkG2Y0wZIyZjDfbEult4z6sMFHtzXrqrKDed7UgTJPo=.9c93a305-cd45-4207-8421-327bd26ddfbf@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <7wDXcglvW1xSgIGL4fWRX_LtUl2wtfoaBYiu_z36YMs=.38e799cf-a942-4e05-90c3-3f757c480e9b@github.com>
 <VkG2Y0wZIyZjDfbEult4z6sMFHtzXrqrKDed7UgTJPo=.9c93a305-cd45-4207-8421-327bd26ddfbf@github.com>
Message-ID: <Q387-0ldMO8QxjJqtDBNh0xY91F0w6h2om1yJZxEwrE=.59e5f2a8-2d6d-4081-9b8c-1df67847f3ef@github.com>

On Wed, 17 May 2023 14:10:59 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added test case
>
> src/java.base/unix/native/libjava/ProcessImpl_md.c line 490:
> 
>> 488:     pid_t resultPid;
>> 489:     int i, offset, rval, bufsize, magic;
>> 490:     char *buf, buf1[24];
> 
> Since you are here could you please increase buffer size to something safe? Max len of INT_MIN is 11 bytes, so lets have at least 3*11 + 3 bytes.

OK, so let it be (until we get 64-bit integers and file descriptors :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1196768397

From ecaspole at openjdk.org  Wed May 17 16:28:20 2023
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 17 May 2023 16:28:20 GMT
Subject: RFR: 8307483: New micros for j.u.c.LockSupport [v4]
In-Reply-To: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
References: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
Message-ID: <fjwYnt12q5l1cQ-R1dU3ZDd3WHbSEp6G_PzfrKx5uCk=.e3c7aa4c-8f7e-41b4-a4c0-14d89a897892@github.com>

> These micros were developed while investigating JDK-8305670 by myself and Sergey Kuksenko. The order of thread creation was important in that bug, so there are 2 JMH for creating sleepers before and after the worker threads.

Eric Caspole has updated the pull request incrementally with one additional commit since the last revision:

  Apply suggestions from code review
  
  Apply Aleksey's suggestions of May 17
  
  Co-authored-by: Aleksey Shipil?v <shipilev at amazon.de>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13815/files
  - new: https://git.openjdk.org/jdk/pull/13815/files/4a486cfd..9023b6c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13815&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13815&range=02-03

  Stats: 8 lines in 2 files changed: 1 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13815.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13815/head:pull/13815

PR: https://git.openjdk.org/jdk/pull/13815

From simonis at openjdk.org  Wed May 17 16:33:52 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 17 May 2023 16:33:52 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <NKcMniUs_0zJlCLT2gnPfqBIjOxQuA0lHdo1UqKS33Q=.41e36a92-1660-42a3-8fce-52edf9ab3b2f@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <PhQwmHWsZpkaMtgk1o5cU8To6ltyCEk9NbOKa9LgDtI=.4f986b17-5117-4b47-a6bb-055a5f717694@github.com>
 <fYvBogZEfG6vz84VFk5ZYrdkDB98ij5klQ7F8YM6H0k=.99aeffad-fc37-4d61-a847-dbbd0b4bf91d@github.com>
 <NKcMniUs_0zJlCLT2gnPfqBIjOxQuA0lHdo1UqKS33Q=.41e36a92-1660-42a3-8fce-52edf9ab3b2f@github.com>
Message-ID: <qNOL_UiVmY_QTP6PFtcnRchIny6qFCF5lGChhkIbis8=.45d8c67b-fb0e-4dca-b8fb-14347ae30c2a@github.com>

On Wed, 17 May 2023 14:42:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> if parent process dies prematurely

@RogerRiggs , I've created a release note for the issue based on your suggestions. Please feel free to proof-read and enhance it :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1551719840

From stuefe at openjdk.org  Wed May 17 16:50:53 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 17 May 2023 16:50:53 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v2]
In-Reply-To: <YY8ZiTzjcdkYsJUh7N4x7Tcm4gLUemKmLA_KzE4d3lI=.ef3e2c0e-ec39-4bef-b72e-741aae4d905c@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <7wDXcglvW1xSgIGL4fWRX_LtUl2wtfoaBYiu_z36YMs=.38e799cf-a942-4e05-90c3-3f757c480e9b@github.com>
 <VkG2Y0wZIyZjDfbEult4z6sMFHtzXrqrKDed7UgTJPo=.9c93a305-cd45-4207-8421-327bd26ddfbf@github.com>
 <YY8ZiTzjcdkYsJUh7N4x7Tcm4gLUemKmLA_KzE4d3lI=.ef3e2c0e-ec39-4bef-b72e-741aae4d905c@github.com>
Message-ID: <QRUHDY_XM37jwRxn7hUVl43nglWhvvFdlvh03aOQfNg=.66091337-e2bb-4c9f-96de-f710d51487d8@github.com>

On Wed, 17 May 2023 16:05:58 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 140:
>> 
>>> 138:     struct stat buf;
>>> 139:     /* argv[0] contains the fd number to read all the child info */
>>> 140:     int r, fdinr, fdinw, fdout;
>> 
>> Since you are here, can you init these?
>
> What would be the right value to initialize them to and what would it help? We use `sscanf()` right in the following line and exit if `sscanf()` is not assigning all three values. I think that should be good enough.

I usually init fds with -1. It's mostly a protection against bitrot and general cleanliness.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1196806451

From kvn at openjdk.org  Wed May 17 16:54:49 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 17 May 2023 16:54:49 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly
In-Reply-To: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
Message-ID: <1iF_2pFExGpBX1dxqyM6TiQecD8o1qSJWeIv4HVG0vE=.930245c2-8033-402e-a0e8-0a7e3ffaff6c@github.com>

On Thu, 4 May 2023 13:36:22 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
> 
> ### Old CompileOnly format
> - matching a **method name** with **class name** and **package name**:
> `-XX:CompileOnly=package/path/Class.method`
> `-XX:CompileOnly=package/path/Class::method`
> `-XX:CompileOnly=package.path.Class::method`
> BUT NOT `-XX:CompileOnly=package.path.Class.method`
> 
> - just matching a **single method name**:
> `-XX:CompileOnly=.hashCode`
> `-XX:CompileOnly=::hashCode`
> BUT NOT `-XX:CompileOnly=hashCode`
> 
> - Matching **all method names** in a **class name** with **package name**
> `-XX:CompileOnly=java/lang/String`
> BUT NOT `-XX:CompileOnly=java/lang/String.`
> BUT NOT `-XX:CompileOnly=java.lang.String`
> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
> BUT NOT `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - Matching **all method names** in a **class name** with **NO package name**
> `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
> 
> ### CompileCommand=compileonly format
> `CompileCommand` allows two different forms for paths: 
> - `package/path/Class.method`
> - `package.path.Class::method`
> 
> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
> 
>  Valid forms: 
> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
> `-XX:CompileCommand=compileonly,java.lang.String::*`
> `-XX:CompileCommand=compileonly,*::hashCode`
> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
> `-XX:CompileCommand=compileonly,*String::hash*`
> 
>  Invalid forms (Error: Embedded * not allowed):
>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
> 
> ### Use CompileCommand syntax for CompileOnly
> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
> 
> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
> 
> With this PR `CompileOnly` becomes an alias for `CompileC...

Thank you for fixing this finally!

FTR. We planned to do this for long time. Main motivations: unify syntax and catch invalid commands.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13802#pullrequestreview-1431162594

From bpb at openjdk.org  Wed May 17 17:07:15 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 17 May 2023 17:07:15 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v6]
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <u0EfE6vknEnro8Kb928c0VEvUOATFGlY0aLqfG59tyk=.6e423c95-b737-4a8f-8f45-c39dcf0f3052@github.com>

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8308016: Reinstate @snippet for RandomAccessFile::readLong

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13957/files
  - new: https://git.openjdk.org/jdk/pull/13957/files/724a74a9..8ae42cf2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957

PR: https://git.openjdk.org/jdk/pull/13957

From rriggs at openjdk.org  Wed May 17 17:13:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 May 2023 17:13:02 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v3]
In-Reply-To: <V6X7mD9t_bH6l8iYAxk2B8wszDqj8_Oa9zcgarrxotc=.6beeb6ad-6ddc-4ab4-a3c7-1c35050e3978@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <V6X7mD9t_bH6l8iYAxk2B8wszDqj8_Oa9zcgarrxotc=.6beeb6ad-6ddc-4ab4-a3c7-1c35050e3978@github.com>
Message-ID: <pPfpk0spHtI57ovb4jUjGFCroYNVLBcW7VEglb6B1xw=.267a7093-0fd5-485a-8e76-1b5ee179d770@github.com>

On Wed, 17 May 2023 16:00:23 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   REALLY adding the test :)

test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 63:

> 61:         if (p.exitValue() == 0) {
> 62:             String pwd = p.inputReader().readLine();
> 63:             if (!Path.of("").toAbsolutePath().toString().equals(pwd)) {

It would be useful to print the unexpected string; it might help isolate what went wrong.
And make it easier to understand what ERROR+2 means.

test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 78:

> 76:         pb = ProcessTools.createJavaProcessBuilder("-Djdk.lang.Process.launchMechanism=posix_spawn",
> 77:                                                    "JspawnhelperProtocol",
> 78:                                                    "normalExec");

I would just redirect the output to the parent.
`pb.inheritIO()`  and avoid the extra code at line 88.

test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 106:

> 104:             }
> 105:             line = br.readLine();
> 106:         }

Try-with-resources works well in cases like this.  (Moving foundCrashInfo out of the t-w-r).

test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 116:

> 114:         int ret = p.exitValue();
> 115:         if (ret == 0) {
> 116:             throw new Exception("Expected error in child execution");

Mixing the two styles of error reporting seems a bit odd, some throw exceptions and others just exit.
Being consistent throwing an exception with a message would be better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1196820848
PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1196824653
PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1196825895
PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1196827447

From roger.riggs at oracle.com  Wed May 17 17:19:46 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 17 May 2023 13:19:46 -0400
Subject: Leap second handling in Windows timestamps
In-Reply-To: <1790d01d985ca$e03cf6c0$a0b6e440$@flueckiger.ch>
References: <1790d01d985ca$e03cf6c0$a0b6e440$@flueckiger.ch>
Message-ID: <71d99c8c-f188-a09c-fc38-f428cc8ff6c0@oracle.com>

Hi,

Thanks for the report, I created a Jira issue to track the investigation.
https://bugs.openjdk.org/browse/JDK-8308302

Regards, Roger

On 5/13/23 2:43 PM, andreas at flueckiger.ch wrote:
> Subject:
> Leap second handling in Windows timestamps
> From:
> <andreas at flueckiger.ch>
> Date:
> 5/13/23, 2:43 PM
>
> To:
> <core-libs-dev at openjdk.org>
>
>
> Hello,
>
> This is my first post to this mailing list. I've been exploring a problem concerning leap seconds that emerged with the Windows 10 October 2018 Update. The current implementation of InstantSource and other classes that interact with FILETIME structures seem to be affected. This problem extends beyond just leap second days and will occur on any future day where the UTC-TAI offset deviates from 37 seconds.
>
> The Java code snippet below, which uses JNA to convert a Windows FILETIME to an Instant, represents my initial attempt to address this issue. This approach makes the assumption that no more than one leap second is added or removed in a day, which should hold true until at least 2035, and likely a few years beyond.
>
> I'm not sure how this will impact performance, and I'm not certain about the exact performance requirements. Also, I'm not sure if my current level of experience and permissions allow me to contribute directly to the JDK codebase. Still, I hope this code can provide some direction towards refining the handling of Windows timestamps.
>
> Kind regards,
> Andreas
>
> private static Instant fileTimeToInstant(long fileTime) {
>    if (fileTime < 0L) {
>      throw new DateTimeException("file time must not be negative");
>    }
>
>    // Calculate nano adjustment and round down fileTime to the nearest second
>    int nanoAdjustment = (int) (fileTime % 10000000L);
>    fileTime -= nanoAdjustment;
>    nanoAdjustment *= 100;
>
>    // Populate FILETIME structure
>    FILETIME fileTimeStruct = new FILETIME();
>    fileTimeStruct.dwHighDateTime = (int) (fileTime >>> 32);
>    fileTimeStruct.dwLowDateTime = (int) (fileTime & 0xffffffffL);
>
>    // Convert FILETIME structure to a SYSTEMTIME structure
>    SYSTEMTIME systemTime = new SYSTEMTIME();
>    if (!Kernel32.INSTANCE.FileTimeToSystemTime(fileTimeStruct, systemTime)) {
>      throw new LastErrorException(Native.getLastError());
>    }
>
>    // Calculate epoch day and second of day
>    long epochDay = LocalDate.of(systemTime.wYear, systemTime.wMonth, systemTime.wDay).toEpochDay();
>    int secondOfDay = systemTime.wHour * 3600 + systemTime.wMinute * 60 + systemTime.wSecond;
>
>    // Calculate UTC-SLS slew if necessary and only for dates before December 31,
>    // 30827 (epochDay < 10540167). SystemTimeToFileTime does not support dates
>    // after the year 30827.
>    if (secondOfDay >= 85399 && epochDay < 10540167) {
>      // If the actual second of the day is 86400 (leap second) and the process is in
>      // "compatible mode", increment the secondOfDay variable. In compatible mode,
>      // the clock slows down to half speed for two seconds at the '59' second mark,
>      // and systemTime.wMilliseconds reaches 500 at the beginning of the leap second.
>      // This ensures that the leap second is properly accounted for without depending
>      // on the ProcessLeapSecondInfo option. Rounding down fileTime to the nearest
>      // second ensures that this check works as intended.
>      if (secondOfDay == 86399 && systemTime.wMilliseconds == 500) {
>        secondOfDay++;
>      }
>
>      // Calculate leap adjustment
>      int leapAdjustment;
>      if (secondOfDay == 86400) {
>        // In case of a leap second, set leap adjustment to 1
>        // to avoid unnecessary further calculations
>        leapAdjustment = 1;
>      } else {
>        // If it's not a leap second, calculate leap adjustment by
>        // determining the difference to the beginning of the next day
>        LocalDate nextDay = LocalDate.ofEpochDay(epochDay + 1);
>        systemTime.wYear = (short) nextDay.getYear();
>        systemTime.wMonth = (short) nextDay.getMonthValue();
>        systemTime.wDay = (short) nextDay.getDayOfMonth();
>        systemTime.wHour = 0;
>        systemTime.wMinute = 0;
>        systemTime.wSecond = 0;
>        systemTime.wMilliseconds = 0;
>        if (!Kernel32.INSTANCE.SystemTimeToFileTime(systemTime, fileTimeStruct)) {
>          throw new LastErrorException(Native.getLastError());
>        }
>        long nextDayFileTime = (((long) fileTimeStruct.dwHighDateTime) << 32) | (fileTimeStruct.dwLowDateTime & 0xffffffffL);
>
>        leapAdjustment = (int) ((nextDayFileTime - fileTime) / 10000000L + secondOfDay - 86400L);
>      }
>
>      // Adjust nanoseconds based on leap adjustment
>      if (leapAdjustment != 0 && secondOfDay - leapAdjustment >= 85400) {
>        nanoAdjustment -= ((secondOfDay - leapAdjustment - 85400) * 1000000000L + nanoAdjustment) * leapAdjustment / 1000L;
>      }
>    }
>
>    return Instant.ofEpochSecond(epochDay * 86400L + secondOfDay, nanoAdjustment);
> }
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230517/8713b8d0/attachment.htm>

From liach at openjdk.org  Wed May 17 17:20:37 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 17 May 2023 17:20:37 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v3]
In-Reply-To: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
Message-ID: <LvTHTEI6f2wcPaMklu_WZedfqnUqWX_ij9iG_y10sfE=.ed10c1d5-c391-4fc0-8ed2-631ce508d5f4@github.com>

> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
> 
> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
> 
> Current problems:
> - [ ] The lazy var handle is quite slow on the first invocation.
>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>    - After that, the lazy handle has a performance on par with the regular var handle.
> - [ ] The class-loading-based test is not in a unit test
>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
> 
> 
> Benchmark                                            Mode  Cnt       Score        Error  Units
> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30       0.769 ?      0.003  ns/op
> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30       0.767 ?      0.002  ns/op
> 
> 
> Benchmark                                            Mode  Cnt       Score        Error  Units
> LazyStaticColdStart.methodHandleCreateEager            ss   10   73140.100 ?   7735.276  ns/op
> LazyStaticColdStart.methodHandleCreateLazy             ss   10   50000.000 ?   8482.883  ns/op
> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   91350.100 ?   9776.343  ns/op
> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  145540.200 ?  72894.865  ns/op
> LazyStaticColdStart.varHandleCreateEager               ss   10   47069.900 ?   3513.909  ns/op
> LazyStaticColdStart.varHandleCreateLazy                ss   10   24780.300 ?   5144.540  ns/op
> LazyStaticColdStart.varHandleInitializeCallEager       ss   10   85479.700 ?  10816.983  ns/op
> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  413630.100 ? 189370.448  ns/op

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Remove export for removed package
 - Merge branch 'master' into lazy-static-varhandle
 - Test the creation performance of handles, lazy one indeed better
 - Merge branch 'master' into lazy-static-varhandle
 - copyright year
 - Benchmarks. lazy initialize is SLOW
 - nuke meaningless overrides
 - make static field var handles lazy and fix NPE in isAccessModeSupported

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13821/files
  - new: https://git.openjdk.org/jdk/pull/13821/files/eea7aa84..6ed6b805

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13821&range=01-02

  Stats: 10143 lines in 473 files changed: 5357 ins; 1503 del; 3283 mod
  Patch: https://git.openjdk.org/jdk/pull/13821.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13821/head:pull/13821

PR: https://git.openjdk.org/jdk/pull/13821

From bulasevich at openjdk.org  Wed May 17 17:44:02 2023
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Wed, 17 May 2023 17:44:02 GMT
Subject: RFR: 8308270: ARM32 build broken after JDK-8304913
Message-ID: <nSPefr45paSqGTl51Z_yVzKdhxRSSpY0ymNMJ4Wgh8Y=.9d8e3d1b-21df-4f68-9993-8b54c2ed2a9e@github.com>

Build issue happens after https://git.openjdk.org/jdk/pull/13585:

$ make bundles
...
jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.ARM
	at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
	at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
	at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
	at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
	at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)


With this PR I follow the https://github.com/openjdk/jdk/pull/13357 change to add a missing ARM32 architecture to the list of supported architectures: `X64, X86, AARCH64, RISCV64, S390, PPC64`.

-------------

Commit messages:
 - 8308270: ARM32 build broken after JDK-8304913

Changes: https://git.openjdk.org/jdk/pull/14028/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14028&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308270
  Stats: 13 lines in 3 files changed: 13 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14028.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14028/head:pull/14028

PR: https://git.openjdk.org/jdk/pull/14028

From maurizio.cimadamore at oracle.com  Wed May 17 17:52:05 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 17 May 2023 18:52:05 +0100
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <e434c1fa-b00d-cccd-5a75-204227ab5a83@apache.org>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
 <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
 <CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com>
 <46167980-41fe-e214-9b67-ce0c5ca8c032@oracle.com>
 <1907607213.49439971.1683285286489.JavaMail.zimbra@univ-eiffel.fr>
 <e434c1fa-b00d-cccd-5a75-204227ab5a83@apache.org>
Message-ID: <e508c54c-1cc8-d32c-9a31-36fb1e2ee60b@oracle.com>


On 17/05/2023 08:58, Uwe Schindler wrote:
> If we would change to Java 21 as compilation target, we may need to 
> adapt our code.

I believe that would be an experiment worth doing (if you can!), and 
report back if you find any compilation problems.

E.g. using --release 17 effectively shields Lucene from the changes 
discussed here. I think what we'd like to understand better is how often 
the examples shown by Remi would occur in the wild.

Cheers
Maurizio


From mcimadamore at openjdk.org  Wed May 17 17:52:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 17:52:55 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports
Message-ID: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>

This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:


jshell> import java.lang.foreign.*;

jshell> Linker.nativeLinker().canonicalLayouts()
$2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}


This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.

-------------

Commit messages:
 - Tweak javadoc
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/14037/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14037&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308293
  Stats: 105 lines in 3 files changed: 74 ins; 5 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/14037.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14037/head:pull/14037

PR: https://git.openjdk.org/jdk/pull/14037

From mcimadamore at openjdk.org  Wed May 17 17:52:57 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 17:52:57 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports
In-Reply-To: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
Message-ID: <TRVhMWQIXtXOua7qX2l0gFKEZ80AdG3K1bnNY2GBmxA=.ce1e560f-e3cd-47cf-ade0-02e186afd393@github.com>

On Wed, 17 May 2023 17:15:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
> 
> 
> jshell> import java.lang.foreign.*;
> 
> jshell> Linker.nativeLinker().canonicalLayouts()
> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
> 
> 
> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.

javadoc: https://cr.openjdk.org/~mcimadamore/jdk/8308293/v1/javadoc/java.base/module-summary.html
specdiff: https://cr.openjdk.org/~mcimadamore/jdk/8308293/v1/specdiff_out/overview-summary.html

src/java.base/share/classes/java/lang/foreign/Linker.java line 205:

> 203:  * </table></blockquote>
> 204:  * <p>
> 205:  * All the native linker implementations can only operate on a subset of memory layouts, called <em>supported layouts</em>.

I revamped this section as I realized that what we had did not cover things in the recursive case - e.g. a struct layout is only supported if it contains other supported layouts. This new text should hopefully capture everything in a more mathematical form.

src/java.base/share/classes/java/lang/foreign/Linker.java line 595:

> 593: 
> 594:     /**
> 595:      * {@return a mapping between the names of data types used by the ABI implemented by this linker and their

Much of the verbiage here is carried over from `defaultLookup` as we need to do the usual dance of saying that the set of returned types is not specified, but should be (a) sensible and (b) stable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1551817970
PR Review Comment: https://git.openjdk.org/jdk/pull/14037#discussion_r1196842518
PR Review Comment: https://git.openjdk.org/jdk/pull/14037#discussion_r1196841486

From maurizio.cimadamore at oracle.com  Wed May 17 17:53:45 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 17 May 2023 18:53:45 +0100
Subject: The introduction of Sequenced collections is not a source
 compatible change
In-Reply-To: <e508c54c-1cc8-d32c-9a31-36fb1e2ee60b@oracle.com>
References: <1920983262.44661427.1682765181190.JavaMail.zimbra@univ-eiffel.fr>
 <5bcdedb9-e875-37e5-abda-7811085c16ad@oracle.com>
 <2051038420.47724734.1683119563893.JavaMail.zimbra@univ-eiffel.fr>
 <d84aec0d-3a5e-4544-84e0-b40811825a09@oracle.com>
 <CA+NR86hdGHFN7j_eWsBVznsCojZ2GthV-1zzhvgEra0=FtQLRQ@mail.gmail.com>
 <46167980-41fe-e214-9b67-ce0c5ca8c032@oracle.com>
 <1907607213.49439971.1683285286489.JavaMail.zimbra@univ-eiffel.fr>
 <e434c1fa-b00d-cccd-5a75-204227ab5a83@apache.org>
 <e508c54c-1cc8-d32c-9a31-36fb1e2ee60b@oracle.com>
Message-ID: <2c068adb-af6d-3fb2-8b33-9740bf5973bc@oracle.com>


On 17/05/2023 18:52, Maurizio Cimadamore wrote:
> I believe that would be an experiment worth doing (if you can!), and 
> report back if you find any compilation problems. 
Ah - I missed this critical last line:

> P.S.: To be honest: I tried to pass "--release 21" when compiling 
> Lucene and it failed, but not for sequenced collections reasons. It 
> was more some tests calling Runtime#runFinalization().


Thanks

Maurizio



From mcimadamore at openjdk.org  Wed May 17 18:18:03 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 18:18:03 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v2]
In-Reply-To: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
Message-ID: <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>

> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
> 
> 
> jshell> import java.lang.foreign.*;
> 
> jshell> Linker.nativeLinker().canonicalLayouts()
> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
> 
> 
> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14037/files
  - new: https://git.openjdk.org/jdk/pull/14037/files/ee89cdfc..955241f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14037&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14037&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14037.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14037/head:pull/14037

PR: https://git.openjdk.org/jdk/pull/14037

From thartmann at openjdk.org  Wed May 17 19:11:53 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 17 May 2023 19:11:53 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly
In-Reply-To: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
Message-ID: <bjIGN2uGPBoXHKkqvxAMblPF8g-lmbNyqIOopfhz2QU=.3d854a2a-aebd-4d36-ae2b-0da9e2de8b5f@github.com>

On Thu, 4 May 2023 13:36:22 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
> 
> ### Old CompileOnly format
> - matching a **method name** with **class name** and **package name**:
> `-XX:CompileOnly=package/path/Class.method`
> `-XX:CompileOnly=package/path/Class::method`
> `-XX:CompileOnly=package.path.Class::method`
> BUT NOT `-XX:CompileOnly=package.path.Class.method`
> 
> - just matching a **single method name**:
> `-XX:CompileOnly=.hashCode`
> `-XX:CompileOnly=::hashCode`
> BUT NOT `-XX:CompileOnly=hashCode`
> 
> - Matching **all method names** in a **class name** with **package name**
> `-XX:CompileOnly=java/lang/String`
> BUT NOT `-XX:CompileOnly=java/lang/String.`
> BUT NOT `-XX:CompileOnly=java.lang.String`
> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
> BUT NOT `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - Matching **all method names** in a **class name** with **NO package name**
> `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
> 
> ### CompileCommand=compileonly format
> `CompileCommand` allows two different forms for paths: 
> - `package/path/Class.method`
> - `package.path.Class::method`
> 
> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
> 
>  Valid forms: 
> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
> `-XX:CompileCommand=compileonly,java.lang.String::*`
> `-XX:CompileCommand=compileonly,*::hashCode`
> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
> `-XX:CompileCommand=compileonly,*String::hash*`
> 
>  Invalid forms (Error: Embedded * not allowed):
>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
> 
> ### Use CompileCommand syntax for CompileOnly
> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
> 
> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
> 
> With this PR `CompileOnly` becomes an alias for `CompileC...

Thanks for taking care of this tedious changes, Toby. Looks good to me too!

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13802#pullrequestreview-1431379325

From stuefe at openjdk.org  Wed May 17 19:39:49 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 17 May 2023 19:39:49 GMT
Subject: RFR: 8308270: ARM32 build broken after JDK-8304913
In-Reply-To: <nSPefr45paSqGTl51Z_yVzKdhxRSSpY0ymNMJ4Wgh8Y=.9d8e3d1b-21df-4f68-9993-8b54c2ed2a9e@github.com>
References: <nSPefr45paSqGTl51Z_yVzKdhxRSSpY0ymNMJ4Wgh8Y=.9d8e3d1b-21df-4f68-9993-8b54c2ed2a9e@github.com>
Message-ID: <X90iXmju_kFk5QQgMdUMnsT_fjjvcZ-KV9327SwvIDo=.4c6a0838-be99-499f-80d8-ba96fabd17e1@github.com>

On Wed, 17 May 2023 08:45:23 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Build issue happens after https://git.openjdk.org/jdk/pull/13585:
> 
> $ make bundles
> ...
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.ARM
> 	at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> 
> 
> With this PR I follow the https://github.com/openjdk/jdk/pull/13357 change to add a missing ARM32 architecture to the list of supported architectures: `X64, X86, AARCH64, RISCV64, S390, PPC64`.

Looks good. Thanks for fixing this.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14028#pullrequestreview-1431433623

From naoto at openjdk.org  Wed May 17 19:48:00 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 17 May 2023 19:48:00 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
Message-ID: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>

This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.

-------------

Commit messages:
 - 8308108: Support Unicode extension for collation settings

Changes: https://git.openjdk.org/jdk/pull/14040/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14040&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308108
  Stats: 113 lines in 2 files changed: 112 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14040/head:pull/14040

PR: https://git.openjdk.org/jdk/pull/14040

From darcy at openjdk.org  Wed May 17 20:06:58 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 May 2023 20:06:58 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <NKcMniUs_0zJlCLT2gnPfqBIjOxQuA0lHdo1UqKS33Q=.41e36a92-1660-42a3-8fce-52edf9ab3b2f@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <PhQwmHWsZpkaMtgk1o5cU8To6ltyCEk9NbOKa9LgDtI=.4f986b17-5117-4b47-a6bb-055a5f717694@github.com>
 <fYvBogZEfG6vz84VFk5ZYrdkDB98ij5klQ7F8YM6H0k=.99aeffad-fc37-4d61-a847-dbbd0b4bf91d@github.com>
 <NKcMniUs_0zJlCLT2gnPfqBIjOxQuA0lHdo1UqKS33Q=.41e36a92-1660-42a3-8fce-52edf9ab3b2f@github.com>
Message-ID: <csdVRwugp359LIivw-fOUfIPvgLQhUYKy1terkI5zhY=.5b46222f-a203-45ed-9392-5deb035ce8b1@github.com>

On Wed, 17 May 2023 14:42:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> > Should this issue have a CSR for any behavioral changes?
> 
> Well, you can certainly argue that every bug fix is a behavioral changes, right :)
> 
> But seriously, I don't see how this PR could require a CSR. The only behavioral change is really that `jspawnhelper` can now no longer block and deadlock. But that's exactly how it should have behaved in the first place.

Yes, some judgement is needed on behavioral changes; this was broached in portions of my recent talk to the JCP EC:

"Contributing to OpenJDK: Participating in stewardship for the long-term"
https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-04-12/Contributing_to_OpenJDK_2023_04_12.pdf

The process spawning code is apparently tricky and subtle, so much so that this will be apparently the third attempt at it since JDK 12. (I still have memories of various platform-specific issues in process handling from my time maintaining the launcher.)

So I don't think the applicability of a CSR for this change should be dismissed and personally I would prefer a change like this be made early in JDK 22 rather than a few weeks before JDK 21 rampdown; it is easier to address any bug tail early in 22 rather than late in 21.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1551975825

From ecaspole at openjdk.org  Wed May 17 20:43:02 2023
From: ecaspole at openjdk.org (Eric Caspole)
Date: Wed, 17 May 2023 20:43:02 GMT
Subject: Integrated: 8307483: New micros for j.u.c.LockSupport
In-Reply-To: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
References: <LxEnqrG1kgeTh8UajFEovdWAkT1rFygMbt1028YWoHo=.580dccca-e2c9-49ff-83e4-16c15fa7f946@github.com>
Message-ID: <iaTpIYwpl38KeSVc0VavBAh3QinZGU6Cpfc4gz2pALA=.d4ed386a-cd18-4259-844c-76c93910b62a@github.com>

On Thu, 4 May 2023 20:17:11 GMT, Eric Caspole <ecaspole at openjdk.org> wrote:

> These micros were developed while investigating JDK-8305670 by myself and Sergey Kuksenko. The order of thread creation was important in that bug, so there are 2 JMH for creating sleepers before and after the worker threads.

This pull request has now been integrated.

Changeset: 6073edf3
Author:    Eric Caspole <ecaspole at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6073edf3cdbc1ff7d0cccfb9b4547ef1357d292c
Stats:     273 lines in 2 files changed: 273 ins; 0 del; 0 mod

8307483: New micros for j.u.c.LockSupport

Co-authored-by: Sergey Kuksenko <skuksenko at openjdk.org>
Reviewed-by: shade, redestad

-------------

PR: https://git.openjdk.org/jdk/pull/13815

From bpb at openjdk.org  Wed May 17 20:51:29 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 17 May 2023 20:51:29 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v7]
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <jPkoZCShs1oyBRYLRaXDWQwNeVZC-SoDRDa36kTjMeg=.3b17b331-7817-4528-8e45-4957c2315829@github.com>

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

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 seven additional commits since the last revision:

 - Merge
 - 8308016: Reinstate @snippet for RandomAccessFile::readLong
 - 8308016: Reduce linking in File::toPath snippet
 - 8308016: Fix link in snippet of File::toPath
 - 8308016: Address reviewer comments since previous commit
 - 8308016: Remove ellipses ("...") from snippets
 - 8308016: Use snippets in java.io package

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13957/files
  - new: https://git.openjdk.org/jdk/pull/13957/files/8ae42cf2..d0dce640

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=05-06

  Stats: 13770 lines in 553 files changed: 8566 ins; 1596 del; 3608 mod
  Patch: https://git.openjdk.org/jdk/pull/13957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957

PR: https://git.openjdk.org/jdk/pull/13957

From psandoz at openjdk.org  Wed May 17 20:51:56 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 17 May 2023 20:51:56 GMT
Subject: RFR: 8308248: Revisit alignment of layout constants on 32-bit
 platforms [v2]
In-Reply-To: <ru-xaWdgxVJ3revT-9ghB_KTv2oDdqhq5-NcIFZuShs=.040b67b4-025a-4aac-a077-3df94aa369d5@github.com>
References: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
 <ru-xaWdgxVJ3revT-9ghB_KTv2oDdqhq5-NcIFZuShs=.040b67b4-025a-4aac-a077-3df94aa369d5@github.com>
Message-ID: <wnOaYPGsoOhKiHs6nnnEaB8HH2PEwLQTZBqAHyMonq4=.9e2b0378-d69a-4683-9aab-274fef3426f9@github.com>

On Wed, 17 May 2023 11:15:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The FFM API exposes layout constants for Java primitives. Among those there are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of these layouts is set the same as their size (e.g. 8 bytes).
>> 
>> This is obviously correct on 64-bit platforms, but on 32-bit platform it is not, as such platforms cannot guarantee that doubles and longs will be always 64-bit aligned. This will also result in problems when trying to use e.g. `JAVA_DOUBLE` to model a C double for the linker API on 32-bit platforms.
>> 
>> For these reasons, it would be preferable to define the alignment of `JAVA_LONG` and `JAVA_DOUBLE` constants as `ADDRESS.byteSize()`. 
>> 
>> This patch rectifies alignment of those layout constants to reflect platform-dependent constraints. It also fixes the maximum alignment constraint supported by heap segments, so that it is 4 for long[] and double[] on 32-bit platforms.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix max alignment constants

Marked as reviewed by psandoz (Reviewer).

src/java.base/share/classes/java/lang/foreign/ValueLayout.java line 488:

> 486:     /**
> 487:      * A value layout constant whose size is the same as that of a Java {@code long},
> 488:      * bit alignment set to {@code ADDRESS.bitSize()}, and byte order set to {@link ByteOrder#nativeOrder()}.

Suggestion:

     * (platform dependent) bit alignment set to {@code ADDRESS.bitSize()}, and byte order set to {@link ByteOrder#nativeOrder()}.

?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14007#pullrequestreview-1431604601
PR Review Comment: https://git.openjdk.org/jdk/pull/14007#discussion_r1197038551

From rriggs at openjdk.org  Wed May 17 20:55:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 17 May 2023 20:55:51 GMT
Subject: RFR: 8308270: ARM32 build broken after JDK-8304913
In-Reply-To: <nSPefr45paSqGTl51Z_yVzKdhxRSSpY0ymNMJ4Wgh8Y=.9d8e3d1b-21df-4f68-9993-8b54c2ed2a9e@github.com>
References: <nSPefr45paSqGTl51Z_yVzKdhxRSSpY0ymNMJ4Wgh8Y=.9d8e3d1b-21df-4f68-9993-8b54c2ed2a9e@github.com>
Message-ID: <jOK6S5vu-li9V9CJJyr1889-OKchf-V-o24Eyb7x8AA=.59c3464f-feeb-4f48-9432-7587840876f3@github.com>

On Wed, 17 May 2023 08:45:23 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Build issue happens after https://git.openjdk.org/jdk/pull/13585:
> 
> $ make bundles
> ...
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.ARM
> 	at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> 
> 
> With this PR I follow the https://github.com/openjdk/jdk/pull/13357 change to add a missing ARM32 architecture to the list of supported architectures: `X64, X86, AARCH64, RISCV64, S390, PPC64`.

Look good, thanks for addition.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14028#pullrequestreview-1431613648

From psandoz at openjdk.org  Wed May 17 21:14:57 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 17 May 2023 21:14:57 GMT
Subject: RFR: 8308276: Change layout API to work with bytes, not bits
In-Reply-To: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
References: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
Message-ID: <eDcyoiy4DuE6lB8qdeawH9cR87oYHx5ACrBoH7-tLR4=.f1df3f94-5ccf-4162-ac85-015f6f8ad506@github.com>

On Tue, 16 May 2023 13:53:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> As explained in [1], memory layouts and memory segments describe sizes using different units. Memory layouts use bits, whereas memory segments use bytes. This is historical: memory layouts were designed after the Minimal LDL [2], which allowed layout strings to be used to describe both memory *and* register. In practice that ship has sailed, and the FFM API uses layouts to firmly model the contents of regions of memory. While it would be possible, in principle, to tweak segments to work on bits, changing that would have implications on how easily code that is currently using ByteBuffer can migrate to use MemorySegment.
> 
> For these reasons, this patch fixes the asymmetry so that layouts also model sizes in term of bytes.
> 
> The patch is straightforward, although a bit tedious (as you can imagine), as various uses of bit sizes had to be turned in byte sizes. In practice, the migration had not been too hard, for the following reasons:
> 
> * the `withBitAlignment` and `bitSize` methods are no longer in the API, it is easy to fix any code (mainly tests) using it;
> * most code already uses ready-made constants such as `JAVA_INT` - such code continues to work unchanged;
> * the layout API de facto already required clients to work with bit sizes that are a multiple of 8.
> 
> The only problematic case is the presence of the `MemoryLayout::paddingLayout(long size)` factory. As this factory is changed to deal in bytes instead of bits, all constants passed to this factory will need to be updated. This is not a problem for code using jextract (as jextract will take care of generating padding) but will be an issue for code using the layout API directly.
> 
> [1] - https://mail.openjdk.org/pipermail/panama-dev/2023-May/019059.html

src/java.base/share/classes/jdk/internal/foreign/layout/ValueLayouts.java line 155:

> 153:             assert isValidCarrier(carrier);
> 154:             assert carrier != MemorySegment.class
> 155:                     // MemorySegment byteSize must always equal ADDRESS_SIZE_BITS

Suggestion:

                    // MemorySegment byteSize must always equal ADDRESS_SIZE_BYTES

test/jdk/java/foreign/TestIllegalLink.java line 122:

> 120:             {
> 121:                     FunctionDescriptor.ofVoid(C_INT.withByteAlignment(2)),
> 122:                     "Layout bit alignment must be natural alignment"

Suggestion:

                    "Layout byte alignment must be natural alignment"

And for all the other occurrences.

test/jdk/java/foreign/TestLayoutPaths.java line 49:

> 47: public class TestLayoutPaths {
> 48: 
> 49:     @Test(expectedExceptions = IllegalArgumentException.class)

Remove this test, since its is the same as the next one.

test/jdk/java/foreign/TestLayoutPaths.java line 185:

> 183:         for (int i = 0 ; i < 4 ; i++) {
> 184:             long bitOffset = g.byteOffset(groupSelector.apply(i));
> 185:             assertEquals(offsets[i], bitOffset);

Suggestion:

            long byteOffset = g.byteOffset(groupSelector.apply(i));
            assertEquals(offsets[i], byteOffset);

test/jdk/java/foreign/TestLayoutPaths.java line 236:

> 234:         for (int i = 0 ; i < 4 ; i++) {
> 235:             long bitOffset = g.byteOffset(sequenceElement(i));
> 236:             assertEquals(offsets[i], bitOffset);

Suggestion:

            long byteOffset = g.byteOffset(sequenceElement(i));
            assertEquals(offsets[i], byteOffset);

test/jdk/java/foreign/TestLayoutPaths.java line 246:

> 244:         byteOffsetHandle = byteOffsetHandle.asSpreader(long[].class, indexes.length);
> 245:         long actualBitOffset = (long) byteOffsetHandle.invokeExact(indexes);
> 246:         assertEquals(actualBitOffset, expectedByteOffset);

Suggestion:

        long actualByteOffset = (long) byteOffsetHandle.invokeExact(indexes);
        assertEquals(actualByteOffset, expectedByteOffset);

test/jdk/java/foreign/TestLayouts.java line 286:

> 284: 
> 285:     @Test(dataProvider="layoutsAndAlignments")
> 286:     public void testBadBitAlignment(MemoryLayout layout, long byteAlign) {

Suggestion:

    public void testBadByteAlignment(MemoryLayout layout, long byteAlign) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14013#discussion_r1197051902
PR Review Comment: https://git.openjdk.org/jdk/pull/14013#discussion_r1197057928
PR Review Comment: https://git.openjdk.org/jdk/pull/14013#discussion_r1197053576
PR Review Comment: https://git.openjdk.org/jdk/pull/14013#discussion_r1197054978
PR Review Comment: https://git.openjdk.org/jdk/pull/14013#discussion_r1197055501
PR Review Comment: https://git.openjdk.org/jdk/pull/14013#discussion_r1197056040
PR Review Comment: https://git.openjdk.org/jdk/pull/14013#discussion_r1197056551

From psandoz at openjdk.org  Wed May 17 21:32:50 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 17 May 2023 21:32:50 GMT
Subject: RFR: 8308276: Change layout API to work with bytes, not bits
In-Reply-To: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
References: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
Message-ID: <cenNAQeIdzRZrG6aJKkg9rJnuTx436BtXoShq-YjtWA=.b2536010-ca40-4fb4-b4b4-006493875fcf@github.com>

On Tue, 16 May 2023 13:53:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> As explained in [1], memory layouts and memory segments describe sizes using different units. Memory layouts use bits, whereas memory segments use bytes. This is historical: memory layouts were designed after the Minimal LDL [2], which allowed layout strings to be used to describe both memory *and* register. In practice that ship has sailed, and the FFM API uses layouts to firmly model the contents of regions of memory. While it would be possible, in principle, to tweak segments to work on bits, changing that would have implications on how easily code that is currently using ByteBuffer can migrate to use MemorySegment.
> 
> For these reasons, this patch fixes the asymmetry so that layouts also model sizes in term of bytes.
> 
> The patch is straightforward, although a bit tedious (as you can imagine), as various uses of bit sizes had to be turned in byte sizes. In practice, the migration had not been too hard, for the following reasons:
> 
> * the `withBitAlignment` and `bitSize` methods are no longer in the API, it is easy to fix any code (mainly tests) using it;
> * most code already uses ready-made constants such as `JAVA_INT` - such code continues to work unchanged;
> * the layout API de facto already required clients to work with bit sizes that are a multiple of 8.
> 
> The only problematic case is the presence of the `MemoryLayout::paddingLayout(long size)` factory. As this factory is changed to deal in bytes instead of bits, all constants passed to this factory will need to be updated. This is not a problem for code using jextract (as jextract will take care of generating padding) but will be an issue for code using the layout API directly.
> 
> [1] - https://mail.openjdk.org/pipermail/panama-dev/2023-May/019059.html

Looks good.

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14013#pullrequestreview-1431693685

From psandoz at openjdk.org  Wed May 17 22:11:53 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 17 May 2023 22:11:53 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v2]
In-Reply-To: <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
Message-ID: <j_xcmzBCMjn4UGrrAZNKJKBWCfivqGvzYECADzRGKpw=.25a72705-d671-4bd0-bfbe-ebfa21289372@github.com>

On Wed, 17 May 2023 18:18:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak javadoc

src/java.base/share/classes/java/lang/foreign/Linker.java line 219:

> 217:  * <ol>
> 218:  * <li>the alignment constraint of {@code G} is set to its <a href="MemoryLayout.html#layout-align">natural alignment</a>;</li>
> 219:  * <li>the size of {@code G} is a multiple of its alignment constraint;</li>

Do you think this is a constraint that will hold across all linker implementations?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14037#discussion_r1197102015

From mcimadamore at openjdk.org  Wed May 17 22:37:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 22:37:50 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v2]
In-Reply-To: <j_xcmzBCMjn4UGrrAZNKJKBWCfivqGvzYECADzRGKpw=.25a72705-d671-4bd0-bfbe-ebfa21289372@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
 <j_xcmzBCMjn4UGrrAZNKJKBWCfivqGvzYECADzRGKpw=.25a72705-d671-4bd0-bfbe-ebfa21289372@github.com>
Message-ID: <ga9xdTS3OpQ5xj2jTx6xaMUW7ZuLZffPKKs_njfTqmA=.a45ea9ff-119c-4295-98ce-677723ca73e9@github.com>

On Wed, 17 May 2023 22:08:57 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tweak javadoc
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 219:
> 
>> 217:  * <ol>
>> 218:  * <li>the alignment constraint of {@code G} is set to its <a href="MemoryLayout.html#layout-align">natural alignment</a>;</li>
>> 219:  * <li>the size of {@code G} is a multiple of its alignment constraint;</li>
> 
> Do you think this is a constraint that will hold across all linker implementations?

All "native linkers" as the text says. Other linkers (e.g. not for C) might obey other rules. These rules are basically constraining  struct layouts to what can come out of a native compiler in the absence of pragma pack directives.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14037#discussion_r1197121074

From psandoz at openjdk.org  Wed May 17 22:43:49 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 17 May 2023 22:43:49 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v2]
In-Reply-To: <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
Message-ID: <kK8VMKm-u9h2VJrf210ggkxkdeEU__NFRxrttTut9OY=.27708517-9db4-44bf-88dd-9e76419ffbcf@github.com>

On Wed, 17 May 2023 18:18:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak javadoc

I wonder if we need to be stronger on the compatibility requirements for the supported canonical layouts. It seems we can make stronger claims than symbols made available by the default linker because the ABI supported by the linker will make strong (specification) claims.

So maybe this comes down to the linker supporting a subset ABI's data types, and that subset might increase over time, but never decrease? In this respect could we present a table for each supported linker ABI listing the ABI type and its canonical layout type? (in practice it might just be one table with noted adjustments.)

Then there is the possibility that a linker might change the layout corresponding to a data type. Ideally the linker support the prior layout *and* the new layout. I don't think this will arise with the current support set of supported ABI data types, but it might if we choose to add support for say the optional `__int128` data type prior to the platform adding support for a primitive value class of Int128?

[1] https://gitlab.com/x86-psABIs/x86-64-ABI

-------------

PR Review: https://git.openjdk.org/jdk/pull/14037#pullrequestreview-1431762962

From psandoz at openjdk.org  Wed May 17 22:48:52 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 17 May 2023 22:48:52 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v2]
In-Reply-To: <ga9xdTS3OpQ5xj2jTx6xaMUW7ZuLZffPKKs_njfTqmA=.a45ea9ff-119c-4295-98ce-677723ca73e9@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
 <j_xcmzBCMjn4UGrrAZNKJKBWCfivqGvzYECADzRGKpw=.25a72705-d671-4bd0-bfbe-ebfa21289372@github.com>
 <ga9xdTS3OpQ5xj2jTx6xaMUW7ZuLZffPKKs_njfTqmA=.a45ea9ff-119c-4295-98ce-677723ca73e9@github.com>
Message-ID: <HNTiz5oGiZHoQzCXseSrCEDZzY9YEiLGyeuoaDlKhpY=.c280bc26-8cfd-4bb2-8b2f-4a3a441728f9@github.com>

On Wed, 17 May 2023 22:34:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/foreign/Linker.java line 219:
>> 
>>> 217:  * <ol>
>>> 218:  * <li>the alignment constraint of {@code G} is set to its <a href="MemoryLayout.html#layout-align">natural alignment</a>;</li>
>>> 219:  * <li>the size of {@code G} is a multiple of its alignment constraint;</li>
>> 
>> Do you think this is a constraint that will hold across all linker implementations?
>
> All "native linkers" as the text says. Other linkers (e.g. not for C) might obey other rules. These rules are basically constraining  struct layouts to what can come out of a native compiler in the absence of pragma pack directives.

Ah, i see now, i missed the relevance of that term, introduced earlier in non-modified text.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14037#discussion_r1197130720

From mcimadamore at openjdk.org  Wed May 17 23:06:49 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 17 May 2023 23:06:49 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v2]
In-Reply-To: <kK8VMKm-u9h2VJrf210ggkxkdeEU__NFRxrttTut9OY=.27708517-9db4-44bf-88dd-9e76419ffbcf@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
 <kK8VMKm-u9h2VJrf210ggkxkdeEU__NFRxrttTut9OY=.27708517-9db4-44bf-88dd-9e76419ffbcf@github.com>
Message-ID: <jck5f382AzvQ84UkwtQW4w3z8yEdXAV4-0YfrvJgwE4=.b0019ae7-e268-4947-97c5-43ca68592bee@github.com>

On Wed, 17 May 2023 22:41:16 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> So maybe this comes down to the linker supporting a subset ABI's data types, and that subset might increase over time, but never decrease? In this respect could we present a table for each supported linker ABI listing the ABI type and its canonical layout type? (in practice it might just be one table with noted adjustments.)

I see what you mean and I'm not sure about this. On the one hand, having a set of "trusted" type names would be handy - but I don't know how much commitment we want to put in there? I'm also a bit skeptical at listing all possible ABIs, since I suspect the set of supported platforms will change quickly.

Is what you are after some kind of guarantee of "at least these type names will be available" ?

As for a linker possibly having multiple different layouts for the same ABI type, that is true, and, in a way, already the case with ValueLayout.OfChar/ValueLayout.OfShort. I worked around that by using different type names - e.g. `int16_t` and `char16_t`. 

For more exotic types which might be modeled initially opaquely with MemorySegment, and later on with some other ValueLayout.OfFooBar, I believe we'd need to provide a way to go from the opaque layout to the less opaque one.

The other option would be to admit that a single ABI type can map to multiple layouts, and have `Map<String, List<MemoryLayout>>`. It seemed a bit on the convoluted side of things (esp. given that we can get away without it, at least in this patch), but if you think that would be more robust, I can change that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1552194582

From naoto at openjdk.org  Wed May 17 23:33:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 17 May 2023 23:33:53 GMT
Subject: RFR: 8308046: Move Solaris related Japanese charsets from
 java.base to jdk.charsets module [v2]
In-Reply-To: <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
 <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
Message-ID: <4yFGg-CgLRvNAEB7tpVH9Bi13fdlyAAdVniQnYoZcX4=.32f55011-db19-4c15-adc1-7cfc4cd564a6@github.com>

On Tue, 16 May 2023 17:13:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8308046: Move Solaris related Japanese charsets from java.base to jdk.charsets module
>
> I now think it is better simply removing Solaris-related charsets, as moving them from java.base to jdk.charsets would require unnecessary code changes in non-Solaris code.

> Hello @naotoj . I'm not sure we can remove Solaris related charsets. Somebody may use them for text communication between Solaris.

OK, maybe not now.

I think the fix may be simplified by changing access for those `DoubleByte-X.java.template` internals, such as `DecodeHolder` to `public`, instead of introducing those access methods. You can import classes in `java.base/sun.nio.cs` with the wild card so that it would work on all platforms (`Big5` either in `java.base` or `jdk.charsets`)

Also, please drop `Japanese` from the issue/PR title

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1552210567

From naoto at openjdk.org  Wed May 17 23:34:00 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 17 May 2023 23:34:00 GMT
Subject: RFR: 8308046: Move Solaris related Japanese charsets from
 java.base to jdk.charsets module [v2]
In-Reply-To: <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
Message-ID: <NawIfrkfWF6jn8-_zTybWLOQda6czGdr7r7NQ6X4ijo=.8dd1c828-b5b2-48b4-9b22-79f439707447@github.com>

On Tue, 16 May 2023 15:14:03 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> According to "JDK 20 Internationalization Guide"
>> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
>> Following Solaris related Japanese charsets are in "contained in jdk.charsets module" list.
>> 
>> - PCK (x-PCK)
>> - EUC_JP_Solaris (x-eucJP-Open)
>> 
>> These are not supported by Linux platform, so they should not be in java.base module.
>> 
>> Note:
>> GHA Linux x86 builds were failed.
>> I think it's not related by my modified code.
>> I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-8308051) GHA: Linux x86 builds failure
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308046: Move Solaris related Japanese charsets from java.base to jdk.charsets module

src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP_Open.java.template line 71:

> 69:         private static final DoubleByte.Decoder DEC0208 =
> 70:             (DoubleByte.Decoder)new JIS_X_0208().newDecoder();
> 71: 

Can these also be removed, by making those original ones in `EUC_JP` public?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13973#discussion_r1197162002

From naoto at openjdk.org  Thu May 18 00:52:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 May 2023 00:52:55 GMT
Subject: RFR: 8308046: Move Solaris related charsets from java.base to
 jdk.charsets module [v2]
In-Reply-To: <4yFGg-CgLRvNAEB7tpVH9Bi13fdlyAAdVniQnYoZcX4=.32f55011-db19-4c15-adc1-7cfc4cd564a6@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
 <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
 <4yFGg-CgLRvNAEB7tpVH9Bi13fdlyAAdVniQnYoZcX4=.32f55011-db19-4c15-adc1-7cfc4cd564a6@github.com>
Message-ID: <URWJaXXaEzUAWnM0t0t_VFs-eSpBxYhrWKpHL1Dd1b4=.456a44fc-ce38-46ee-ba17-48fd37df65f5@github.com>

On Wed, 17 May 2023 23:29:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>You can import classes in `java.base/sun.nio.cs` with the wild card so that it would work on all platforms (`Big5` either in `java.base` or `jdk.charsets`)

Scratch that, you've already did it. Then you can remove these: 

import sun.nio.cs.DoubleByte;
import sun.nio.cs.HistoricallyNamedCharset;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1552259703

From bulasevich at openjdk.org  Thu May 18 03:18:07 2023
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Thu, 18 May 2023 03:18:07 GMT
Subject: Integrated: 8308270: ARM32 build broken after JDK-8304913
In-Reply-To: <nSPefr45paSqGTl51Z_yVzKdhxRSSpY0ymNMJ4Wgh8Y=.9d8e3d1b-21df-4f68-9993-8b54c2ed2a9e@github.com>
References: <nSPefr45paSqGTl51Z_yVzKdhxRSSpY0ymNMJ4Wgh8Y=.9d8e3d1b-21df-4f68-9993-8b54c2ed2a9e@github.com>
Message-ID: <YNWZKWF3pZJH7K9qN1OaVjjhXS5eHXa7XvGYYrk6tAI=.ee2dc536-a480-4cdb-b44a-c39a7b00513f@github.com>

On Wed, 17 May 2023 08:45:23 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Build issue happens after https://git.openjdk.org/jdk/pull/13585:
> 
> $ make bundles
> ...
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.ARM
> 	at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> 
> 
> With this PR I follow the https://github.com/openjdk/jdk/pull/13357 change to add a missing ARM32 architecture to the list of supported architectures: `X64, X86, AARCH64, RISCV64, S390, PPC64`.

This pull request has now been integrated.

Changeset: 83c096d6
Author:    Boris Ulasevich <bulasevich at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83c096d6e20cd6e1164bc666df1be197a10431eb
Stats:     13 lines in 3 files changed: 13 ins; 0 del; 0 mod

8308270: ARM32 build broken after JDK-8304913

Reviewed-by: stuefe, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14028

From bulasevich at openjdk.org  Thu May 18 03:18:05 2023
From: bulasevich at openjdk.org (Boris Ulasevich)
Date: Thu, 18 May 2023 03:18:05 GMT
Subject: RFR: 8308270: ARM32 build broken after JDK-8304913
In-Reply-To: <nSPefr45paSqGTl51Z_yVzKdhxRSSpY0ymNMJ4Wgh8Y=.9d8e3d1b-21df-4f68-9993-8b54c2ed2a9e@github.com>
References: <nSPefr45paSqGTl51Z_yVzKdhxRSSpY0ymNMJ4Wgh8Y=.9d8e3d1b-21df-4f68-9993-8b54c2ed2a9e@github.com>
Message-ID: <GlMyhY1bs_8I8Na8dem95zUZzQ12BUHfjT-QGG7KQrQ=.deb74e4f-8fb1-4710-b9e3-cca3e4061872@github.com>

On Wed, 17 May 2023 08:45:23 GMT, Boris Ulasevich <bulasevich at openjdk.org> wrote:

> Build issue happens after https://git.openjdk.org/jdk/pull/13585:
> 
> $ make bundles
> ...
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.ARM
> 	at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
> 	at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> 
> 
> With this PR I follow the https://github.com/openjdk/jdk/pull/13357 change to add a missing ARM32 architecture to the list of supported architectures: `X64, X86, AARCH64, RISCV64, S390, PPC64`.

Thank you for reviewing!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14028#issuecomment-1552345436

From asotona at openjdk.org  Thu May 18 06:08:12 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 18 May 2023 06:08:12 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v9]
In-Reply-To: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
Message-ID: <90HWs6b9mO8sonGvSr-ljGC61qz_DjLyH2D0HVJb69g=.7023816e-7d44-473f-b1e0-a224cd816898@github.com>

> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
> - Caching `MethodTypeDesc` in `MethodInfo` implementations
> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
> 
> No API change.
> 
> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
> 
> 
> Benchmark                     Mode  Cnt       Score       Error  Units
> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
> 
> 
> 
> Benchmark                     Mode  Cnt       Score      Error  Units
> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  removed obsolete exports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13671/files
  - new: https://git.openjdk.org/jdk/pull/13671/files/d99e7ad0..07079387

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13671&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13671&range=07-08

  Stats: 3 lines in 3 files changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13671.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13671/head:pull/13671

PR: https://git.openjdk.org/jdk/pull/13671

From asotona at openjdk.org  Thu May 18 06:08:14 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 18 May 2023 06:08:14 GMT
Subject: RFR: 8306842: Classfile API performance improvements [v8]
In-Reply-To: <vJiEBLUJTfWZjIV24zicLO5hdgly8EDfehyZNYzeYkE=.aa74c748-3072-41d4-8f76-4e0b259510dd@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
 <SfwaHiIZwStvsjeJ52fxlInzfKPORGAZwiliLKepN8s=.ebc76179-3c6e-4404-8e22-8fca42fbb5fc@github.com>
 <vJiEBLUJTfWZjIV24zicLO5hdgly8EDfehyZNYzeYkE=.aa74c748-3072-41d4-8f76-4e0b259510dd@github.com>
Message-ID: <d5qO6LhLFiS7UkPdJeGy-5yQmFGS8QLrwo0t_74Pod8=.464df143-af77-49a2-8c89-1f35ceeceeda@github.com>

On Wed, 17 May 2023 13:42:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
>> 
>>  - Merge branch 'master' into JDK-8306842-perf-improvements
>>    
>>    # Conflicts:
>>    #	make/RunTests.gmk
>>    #	src/java.base/share/classes/jdk/internal/classfile/impl/Util.java
>>  - LinkedList replaced with ArrayList in benchmarks
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - changed LinkedList to ArrayList in RebuildMethodBodies benchmark
>>  - added RepeatedModelTraversal JMH benchmark
>>  - fixed jmh benchmark parameters
>>  - fixed StackMapGenerator
>>  - Apply suggestions from code review
>>    
>>    Co-authored-by: liach <7806504+liach at users.noreply.github.com>
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8306842-perf-improvements
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java
>>    #	src/java.base/share/classes/jdk/internal/classfile/impl/StackCounter.java
>>    #	src/java.base/share/classes/jdk/internal/classfile/impl/StackMapGenerator.java
>>    #	test/jdk/jdk/classfile/DiscontinuedInstructionsTest.java
>>    #	test/jdk/jdk/classfile/StackMapsTest.java
>>  - more use of MethodInfo::methodTypeSymbol and faster ClassDesc slot size calculation
>>  - ... and 24 more: https://git.openjdk.org/jdk/compare/5763be72...d99e7ad0
>
> test/micro/org/openjdk/bench/jdk/classfile/Write.java line 76:
> 
>> 74:         "--add-exports", "java.base/jdk.internal.classfile.constantpool=ALL-UNNAMED",
>> 75:         "--add-exports", "java.base/jdk.internal.classfile.instruction=ALL-UNNAMED",
>> 76:         "--add-exports", "java.base/jdk.internal.classfile.java.lang.constant=ALL-UNNAMED",
> 
> Since this package is gone, this export arg can be removed. There are a total of 3 occurrences I think.

Good catch, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13671#discussion_r1197409528

From asotona at openjdk.org  Thu May 18 06:08:15 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 18 May 2023 06:08:15 GMT
Subject: Integrated: 8306842: Classfile API performance improvements
In-Reply-To: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
References: <y4HSD1FtT6CBLQKDcr-M7LaduaNKh-le1ozwGcOKlx0=.ce6e8d63-2ba8-42ce-b262-fe5040e3ef06@github.com>
Message-ID: <AhDaHjNYSi9cAkKGh020Dv1gUBtO5T0CHikeRarouZI=.97ac00a7-6cc0-465d-8060-1ce24a59fef5@github.com>

On Wed, 26 Apr 2023 15:04:50 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Following improvements implemented:
> - Switch over `String` replaced with switch single char
> - Binary search for frames in `StackMapGenerator`
> - `StackMapGenerator.rawHandlers` with pre-calculated offsets
> - `ClassEntry` is caching `ClassDesc` symbol
> - Caching of type symbols in `NameAndTypeEntry` and `MethodTypeEntry`
> - Caching `MethodTypeDesc` in `MethodInfo` implementations
> - `StackMapGenerator` and `Utils` delegating to cached `MethodTypeDesc` instead of custom parsing
> 
> No API change.
> 
> Benchmarks show stack map generation improved by 21% and code generation from symbols improved by 30%.
> 
> 
> Benchmark                     Mode  Cnt       Score       Error  Units
> GenerateStackMaps.benchmark  thrpt   10  407931.202 ? 13101.023  ops/s
> RebuildMethodBodies.shared   thrpt    4   10258.597 ?   383.699  ops/s
> RebuildMethodBodies.unshared thrpt    4    7224.543 ?   256.800  ops/s
> 
> 
> 
> Benchmark                     Mode  Cnt       Score      Error  Units
> GenerateStackMaps.benchmark  thrpt   10  495101.110 ? 2389.628  ops/s
> RebuildMethodBodies.shared    thrpt   4   13380.272 ?  810.113  ops/s
> RebuildMethodBodies.unshared  thrpt   4    9399.863 ?  557.060  ops/s

This pull request has now been integrated.

Changeset: f4f5542f
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f4f5542f8d49dbb756f52a281b745c3c2bbc9829
Stats:     589 lines in 28 files changed: 383 ins; 90 del; 116 mod

8306842: Classfile API performance improvements

Reviewed-by: redestad

-------------

PR: https://git.openjdk.org/jdk/pull/13671

From alanb at openjdk.org  Thu May 18 06:09:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 May 2023 06:09:03 GMT
Subject: RFR: 8308246: PPC64le build broken after JDK-8304913 [v2]
In-Reply-To: <X0Dhk2-vsZxMWY3VIicRi3OP0hVe5PLu2SiX2bfhzCc=.9005c344-e4c3-40f9-8761-4d74081397f4@github.com>
References: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
 <HWJgPPDg_nNp-GkQ8BixcLEM_lIAVGB-hbr38QhVmr0=.b94c467a-ef46-4914-bab1-9e21e0850bae@github.com>
 <8cFw940aUmPolVFVRnjMZYw1yKpIy-A3E89G2RzlIlk=.c1e6e29a-3083-4c75-b13c-278e6854852c@github.com>
 <AZby-FH4GtMPU5l7Vpzusdqq_sZyHhy5tz_3dd8zq9M=.72e091d6-37a1-492e-99a2-23edf81cc493@github.com>
 <X0Dhk2-vsZxMWY3VIicRi3OP0hVe5PLu2SiX2bfhzCc=.9005c344-e4c3-40f9-8761-4d74081397f4@github.com>
Message-ID: <L2QZAP9VO3YZ9L0RbhgD-1pvNJ30XEKIAYy7bj5tnJ8=.6730eb7c-d640-4edc-b438-38eb0180f2e9@github.com>

On Wed, 17 May 2023 15:36:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Hmm, most java bytecode (classfiles) aren't going to care about the endian-ness; in int is an int, etc.
> Runtime calls to extract int from byte[] is going to check a runtime flag; possibly static and optimization by HotSpot, etc.
> The Architecture enum was intending to capture essential build time attributes.
> If there is a need for more static attributes of a build, the current API doesn't cover that.

The image writer needs to be told the endianness of the target platform, usually the native order but can be overridden. As part of pull/11943, a new resource file is added to map the value of the ModuleTarget class file attribute (essentially $os-$arch) to the endianness to help cross linking.  I don't yet see how this will work with the changes in the this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14027#discussion_r1197414070

From amitkumar at openjdk.org  Thu May 18 06:18:45 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 18 May 2023 06:18:45 GMT
Subject: RFR: 8308347: [s390x]  build broken after JDK-8304913
Message-ID: <RueF9me4xKw1608zHbpN9JTn7Ef0WsnnYyBhCd9wIm0=.0e628197-dfb4-46ce-88cf-d539c17832c7@github.com>

s390x needs to be recognised as `S390`. After [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913) during build I was getting this PluginException: 

jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.S390X
        at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
        at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
        at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
        at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
        at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
        at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
        at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
        at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
        at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
        at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)


Builds tested :`fastdebug, release`.

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/14043/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14043&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308347
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14043/head:pull/14043

PR: https://git.openjdk.org/jdk/pull/14043

From amitkumar at openjdk.org  Thu May 18 06:24:49 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 18 May 2023 06:24:49 GMT
Subject: RFR: 8308347: [s390x]  build broken after JDK-8304913
In-Reply-To: <RueF9me4xKw1608zHbpN9JTn7Ef0WsnnYyBhCd9wIm0=.0e628197-dfb4-46ce-88cf-d539c17832c7@github.com>
References: <RueF9me4xKw1608zHbpN9JTn7Ef0WsnnYyBhCd9wIm0=.0e628197-dfb4-46ce-88cf-d539c17832c7@github.com>
Message-ID: <Tsoy2K_Cd0PBy5AfiNJZw-wy17nmdNJejUOzH7CeU9s=.e7955e28-acbe-4cd5-a3b6-ba630e12a8fb@github.com>

On Thu, 18 May 2023 06:12:19 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> s390x needs to be recognised as `S390`. After [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913) during build I was getting this PluginException: 
> 
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.S390X
>         at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
>         at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
>         at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
>         at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
>         at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> 
> 
> Builds tested :`fastdebug, release`.

@RealLucy , @TheRealMDoerr , would you like to review this one :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14043#issuecomment-1552507228

From stuefe at openjdk.org  Thu May 18 06:42:49 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 May 2023 06:42:49 GMT
Subject: RFR: 8308347: [s390x]  build broken after JDK-8304913
In-Reply-To: <RueF9me4xKw1608zHbpN9JTn7Ef0WsnnYyBhCd9wIm0=.0e628197-dfb4-46ce-88cf-d539c17832c7@github.com>
References: <RueF9me4xKw1608zHbpN9JTn7Ef0WsnnYyBhCd9wIm0=.0e628197-dfb4-46ce-88cf-d539c17832c7@github.com>
Message-ID: <2lSloWKEIu3Wb1Tav9fyfXeh3Eu3gIUN3WLK_c2TJPw=.e0c509ba-7ec2-45f3-99bb-f3944c4d27bf@github.com>

On Thu, 18 May 2023 06:12:19 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> s390x needs to be recognised as `S390`. After [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913) during build I was getting this PluginException: 
> 
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.S390X
>         at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
>         at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
>         at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
>         at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
>         at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> 
> 
> Builds tested :`fastdebug, release`.

Looks good and trivial. Thanks for fixing.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14043#pullrequestreview-1432126181

From amitkumar at openjdk.org  Thu May 18 06:45:48 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 18 May 2023 06:45:48 GMT
Subject: RFR: 8308347: [s390x]  build broken after JDK-8304913
In-Reply-To: <2lSloWKEIu3Wb1Tav9fyfXeh3Eu3gIUN3WLK_c2TJPw=.e0c509ba-7ec2-45f3-99bb-f3944c4d27bf@github.com>
References: <RueF9me4xKw1608zHbpN9JTn7Ef0WsnnYyBhCd9wIm0=.0e628197-dfb4-46ce-88cf-d539c17832c7@github.com>
 <2lSloWKEIu3Wb1Tav9fyfXeh3Eu3gIUN3WLK_c2TJPw=.e0c509ba-7ec2-45f3-99bb-f3944c4d27bf@github.com>
Message-ID: <vxnFIbrhHcLIWDtIoq7ZnvJNgmtuhjaqllBO0IVCxPU=.1b32cbed-9029-4b67-ac81-6d678a237698@github.com>

On Thu, 18 May 2023 06:40:30 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> s390x needs to be recognised as `S390`. After [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913) during build I was getting this PluginException: 
>> 
>> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.S390X
>>         at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
>>         at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
>>         at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
>>         at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
>>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
>>         at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
>>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
>>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
>>         at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
>>         at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
>> 
>> 
>> Builds tested :`fastdebug, release`.
>
> Looks good and trivial. Thanks for fixing.

Thanks @tstuefe for review. As this is trivial change, Moving ahead with integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14043#issuecomment-1552549189

From liach at openjdk.org  Thu May 18 06:57:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 May 2023 06:57:05 GMT
Subject: Integrated: 8306457: Classfile API components implementations should
 not be exposed
In-Reply-To: <67PAXfiqaTaU8vYbbA31WJBG029RHK454HIDp5ZlYx8=.ec9b4ddd-fe42-4236-9e44-ef63e164e906@github.com>
References: <67PAXfiqaTaU8vYbbA31WJBG029RHK454HIDp5ZlYx8=.ec9b4ddd-fe42-4236-9e44-ef63e164e906@github.com>
Message-ID: <od-CUBKR8wKu8gggprtEzwhNz_k1i3tNWAFAIqr-lvo=.1fc038c7-51de-4755-8449-b36529aaea87@github.com>

On Wed, 19 Apr 2023 16:58:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> The jdk.internal.classfile.components package's interfaces have implementations in their nested classes, which are implicitly public and exported with the package. They are now moved to the impl package to avoid unwanted exposures. Fixed a few minor javadoc issues in the interfaces as well.
> 
> In conflict with #13021; one needs updating if the other is merged.

This pull request has now been integrated.

Changeset: 3c9ec263
Author:    Chen Liang <liach at openjdk.org>
Committer: Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c9ec26370dfae5d1230b6b69ae26122fe42e51d
Stats:     1815 lines in 8 files changed: 963 ins; 826 del; 26 mod

8306457: Classfile API components implementations should not be exposed

Reviewed-by: asotona

-------------

PR: https://git.openjdk.org/jdk/pull/13541

From stuefe at openjdk.org  Thu May 18 07:22:23 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 May 2023 07:22:23 GMT
Subject: RFR: JDK-8308350: Increase buffer size for jspawnhelper arguments
Message-ID: <gTlgkqij_PkBAW5mi8FMlKuirGo26usST1mGa_Y1JrE=.805fef89-efc8-4f70-a448-a43054e139d6@github.com>

Trivial fix for a small problem.

jspawnhelper gets handed several file descriptors as arguments. The buffer size for this string is too small (7 chars per fd) to print out every conceivable int. This will overun the buffer if we happen to have fds larger than (printed size) 7 characters. This could lead to crashes or malfunctions if the parent VM has opened a large amount of file descriptors.

Note that on Linux, this can normally not happen since the kernel limits the number of open file descriptors per process to 1M, and these fds are still printable within the limits of this buffer. It is possible to get more fds per process, but only via kernel patch. But we still should not rely on that. And there is also still MacOS using the same mechanism.

-------------

Commit messages:
 - JDK-8308350-Increase-buffer-size-for-jspawnhelper-arguments

Changes: https://git.openjdk.org/jdk/pull/14045/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14045&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308350
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14045/head:pull/14045

PR: https://git.openjdk.org/jdk/pull/14045

From stuefe at openjdk.org  Thu May 18 07:22:55 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 May 2023 07:22:55 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v2]
In-Reply-To: <Q387-0ldMO8QxjJqtDBNh0xY91F0w6h2om1yJZxEwrE=.59e5f2a8-2d6d-4081-9b8c-1df67847f3ef@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <7wDXcglvW1xSgIGL4fWRX_LtUl2wtfoaBYiu_z36YMs=.38e799cf-a942-4e05-90c3-3f757c480e9b@github.com>
 <VkG2Y0wZIyZjDfbEult4z6sMFHtzXrqrKDed7UgTJPo=.9c93a305-cd45-4207-8421-327bd26ddfbf@github.com>
 <Q387-0ldMO8QxjJqtDBNh0xY91F0w6h2om1yJZxEwrE=.59e5f2a8-2d6d-4081-9b8c-1df67847f3ef@github.com>
Message-ID: <VtCTpWDuZm62cYyIOo61UrDZaLBEUgtg6rUXdbgne8g=.c3d914f5-cd77-42b8-887d-a7f3c0671560@github.com>

On Wed, 17 May 2023 16:12:15 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> src/java.base/unix/native/libjava/ProcessImpl_md.c line 490:
>> 
>>> 488:     pid_t resultPid;
>>> 489:     int i, offset, rval, bufsize, magic;
>>> 490:     char *buf, buf1[24];
>> 
>> Since you are here could you please increase buffer size to something safe? Max len of INT_MIN is 11 bytes, so lets have at least 3*11 + 3 bytes.
>
> OK, so let it be (until we get 64-bit integers and file descriptors :)

Ok, if you let it be, I fix it in a separate RFE. Cleaner that way anyway. 

I filed https://bugs.openjdk.org/browse/JDK-8308350 and https://github.com/openjdk/jdk/pull/14045. 

Should I happen to push before you, this should be easily adaptable for you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1197488813

From stuefe at openjdk.org  Thu May 18 07:22:58 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 May 2023 07:22:58 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v3]
In-Reply-To: <V6X7mD9t_bH6l8iYAxk2B8wszDqj8_Oa9zcgarrxotc=.6beeb6ad-6ddc-4ab4-a3c7-1c35050e3978@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <V6X7mD9t_bH6l8iYAxk2B8wszDqj8_Oa9zcgarrxotc=.6beeb6ad-6ddc-4ab4-a3c7-1c35050e3978@github.com>
Message-ID: <gYLF_feBOnLwYB8S4hbzPmCyqHT4u62UMzcJzcEFldA=.c6a55056-2779-42fa-a09d-d7152b8e5f4f@github.com>

On Wed, 17 May 2023 16:00:23 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   REALLY adding the test :)

src/java.base/unix/native/libjava/childproc.c line 413:

> 411:     const char* env = getenv("JTREG_JSPAWNHELPER_PROTOCOL_TEST");
> 412:     if (env != NULL && atoi(env) == stage) {
> 413:         printf("posix_spawn:%d\n", child);

I would do an `_exit()` here, not `exit()`, to prevent exit handlers from running. You want to simulate a sudden death. Or a `kill(getpid(), 9);`

Combine this with an explicit `fflush(stdout)` before to get your test output out.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1197409076

From stuefe at openjdk.org  Thu May 18 07:24:48 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 May 2023 07:24:48 GMT
Subject: RFR: JDK-8308350: Increase buffer size for jspawnhelper arguments
In-Reply-To: <gTlgkqij_PkBAW5mi8FMlKuirGo26usST1mGa_Y1JrE=.805fef89-efc8-4f70-a448-a43054e139d6@github.com>
References: <gTlgkqij_PkBAW5mi8FMlKuirGo26usST1mGa_Y1JrE=.805fef89-efc8-4f70-a448-a43054e139d6@github.com>
Message-ID: <2jmBRpp2uEOB-1SMxvMp3VfXqqgVPeEFR_xjoXgTIfk=.4774537e-2c5e-4738-841c-34334e48887d@github.com>

On Thu, 18 May 2023 07:08:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial fix for a small problem.
> 
> jspawnhelper gets handed several file descriptors as arguments. The buffer size for this string is too small (7 chars per fd) to print out every conceivable int. This will overun the buffer if we happen to have fds larger than (printed size) 7 characters. This could lead to crashes or malfunctions if the parent VM has opened a large amount of file descriptors.
> 
> Note that on Linux, this can normally not happen since the kernel limits the number of open file descriptors per process to 1M, and these fds are still printable within the limits of this buffer. It is possible to get more fds per process, but only via kernel patch. But we still should not rely on that. And there is also still MacOS using the same mechanism.

GHAs are all suffering from infrastructure problems.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14045#issuecomment-1552625592

From mcimadamore at openjdk.org  Thu May 18 09:13:20 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 18 May 2023 09:13:20 GMT
Subject: RFR: 8308276: Change layout API to work with bytes, not bits [v2]
In-Reply-To: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
References: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
Message-ID: <hNnIGJDveyJiC4Fx5wAst4X_ZNsdKgNstBVziBu8g4I=.4fcf6dde-6900-4a77-a29e-f684709cf5f9@github.com>

> As explained in [1], memory layouts and memory segments describe sizes using different units. Memory layouts use bits, whereas memory segments use bytes. This is historical: memory layouts were designed after the Minimal LDL [2], which allowed layout strings to be used to describe both memory *and* register. In practice that ship has sailed, and the FFM API uses layouts to firmly model the contents of regions of memory. While it would be possible, in principle, to tweak segments to work on bits, changing that would have implications on how easily code that is currently using ByteBuffer can migrate to use MemorySegment.
> 
> For these reasons, this patch fixes the asymmetry so that layouts also model sizes in term of bytes.
> 
> The patch is straightforward, although a bit tedious (as you can imagine), as various uses of bit sizes had to be turned in byte sizes. In practice, the migration had not been too hard, for the following reasons:
> 
> * the `withBitAlignment` and `bitSize` methods are no longer in the API, it is easy to fix any code (mainly tests) using it;
> * most code already uses ready-made constants such as `JAVA_INT` - such code continues to work unchanged;
> * the layout API de facto already required clients to work with bit sizes that are a multiple of 8.
> 
> The only problematic case is the presence of the `MemoryLayout::paddingLayout(long size)` factory. As this factory is changed to deal in bytes instead of bits, all constants passed to this factory will need to be updated. This is not a problem for code using jextract (as jextract will take care of generating padding) but will be an issue for code using the layout API directly.
> 
> [1] - https://mail.openjdk.org/pipermail/panama-dev/2023-May/019059.html

Maurizio Cimadamore has updated the pull request incrementally with five additional commits since the last revision:

 - Update test/jdk/java/foreign/TestLayouts.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update test/jdk/java/foreign/TestLayoutPaths.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update test/jdk/java/foreign/TestLayoutPaths.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update test/jdk/java/foreign/TestLayoutPaths.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update src/java.base/share/classes/jdk/internal/foreign/layout/ValueLayouts.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14013/files
  - new: https://git.openjdk.org/jdk/pull/14013/files/0f6f4e29..4fe42c17

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14013&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14013&range=00-01

  Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14013.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14013/head:pull/14013

PR: https://git.openjdk.org/jdk/pull/14013

From mcimadamore at openjdk.org  Thu May 18 09:18:03 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 18 May 2023 09:18:03 GMT
Subject: RFR: 8308276: Change layout API to work with bytes, not bits [v3]
In-Reply-To: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
References: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
Message-ID: <R0tbY8z1Ukf3-aPqFxSfrxnPA6h6m-LOYfXnBaWd6IE=.0b39d7c6-a688-4b27-9fdd-21e9f900e978@github.com>

> As explained in [1], memory layouts and memory segments describe sizes using different units. Memory layouts use bits, whereas memory segments use bytes. This is historical: memory layouts were designed after the Minimal LDL [2], which allowed layout strings to be used to describe both memory *and* register. In practice that ship has sailed, and the FFM API uses layouts to firmly model the contents of regions of memory. While it would be possible, in principle, to tweak segments to work on bits, changing that would have implications on how easily code that is currently using ByteBuffer can migrate to use MemorySegment.
> 
> For these reasons, this patch fixes the asymmetry so that layouts also model sizes in term of bytes.
> 
> The patch is straightforward, although a bit tedious (as you can imagine), as various uses of bit sizes had to be turned in byte sizes. In practice, the migration had not been too hard, for the following reasons:
> 
> * the `withBitAlignment` and `bitSize` methods are no longer in the API, it is easy to fix any code (mainly tests) using it;
> * most code already uses ready-made constants such as `JAVA_INT` - such code continues to work unchanged;
> * the layout API de facto already required clients to work with bit sizes that are a multiple of 8.
> 
> The only problematic case is the presence of the `MemoryLayout::paddingLayout(long size)` factory. As this factory is changed to deal in bytes instead of bits, all constants passed to this factory will need to be updated. This is not a problem for code using jextract (as jextract will take care of generating padding) but will be an issue for code using the layout API directly.
> 
> [1] - https://mail.openjdk.org/pipermail/panama-dev/2023-May/019059.html

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14013/files
  - new: https://git.openjdk.org/jdk/pull/14013/files/4fe42c17..0214e409

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14013&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14013&range=01-02

  Stats: 12 lines in 2 files changed: 0 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14013.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14013/head:pull/14013

PR: https://git.openjdk.org/jdk/pull/14013

From stuefe at openjdk.org  Thu May 18 09:22:19 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 May 2023 09:22:19 GMT
Subject: RFR: JDK-8308350: Increase buffer size for jspawnhelper arguments
 [v2]
In-Reply-To: <gTlgkqij_PkBAW5mi8FMlKuirGo26usST1mGa_Y1JrE=.805fef89-efc8-4f70-a448-a43054e139d6@github.com>
References: <gTlgkqij_PkBAW5mi8FMlKuirGo26usST1mGa_Y1JrE=.805fef89-efc8-4f70-a448-a43054e139d6@github.com>
Message-ID: <dgUkptUppUo4hpbWAiGfm-7bXskKoBPmp2ok9Yx_vic=.cf91d415-b7f4-4ec1-b13c-cca7559fa4c9@github.com>

> Trivial fix for a small problem.
> 
> jspawnhelper gets handed several file descriptors as arguments. The buffer size for this string is too small (7 chars per fd) to print out every conceivable int. This will overun the buffer if we happen to have fds larger than (printed size) 7 characters. This could lead to crashes or malfunctions if the parent VM has opened a large amount of file descriptors.
> 
> Note that on Linux, this can normally not happen since the kernel limits the number of open file descriptors per process to 1M, and these fds are still printable within the limits of this buffer. It is possible to get more fds per process, but only via kernel patch. But we still should not rely on that. And there is also still MacOS using the same mechanism.

Thomas Stuefe has updated the pull request with a new target base 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 JDK-8308350-Increase-buffer-size-for-jspawnhelper-arguments
 - JDK-8308350-Increase-buffer-size-for-jspawnhelper-arguments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14045/files
  - new: https://git.openjdk.org/jdk/pull/14045/files/6fda35fb..dbce7ce1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14045&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14045&range=00-01

  Stats: 23 lines in 2 files changed: 23 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14045.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14045/head:pull/14045

PR: https://git.openjdk.org/jdk/pull/14045

From duke at openjdk.org  Thu May 18 09:23:59 2023
From: duke at openjdk.org (Chang Peng)
Date: Thu, 18 May 2023 09:23:59 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
 [v2]
In-Reply-To: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
Message-ID: <iDLnT0SXEc7KvefafFukgq0pWoKM4hJiVqI0hFCJTvE=.7ba6f43e-a1b5-4335-af28-ff50263a37da@github.com>

> In Vector API Java level, vector mask is represented as a boolean array with 0x00/0x01 (8 bits of each element) as values, aka in-memory format. When it is loaded into vector register, e.g. Neon, the in-memory format will be converted to in-register format with 0/-1 value for each lane (lane width aligned to its type) by VectorLoadMask [1] operation, and convert back to in-memory format by VectorStoreMask[2]. In Neon, a typical VectorStoreMask operation will first narrow given vector registers by xtn insn [3] into byte element type, and then do a vector negate to convert to 0x00/0x01 value for each element.
> 
> For most of the vector mask operations, the input mask is in-register format. And a vector mask also works in-register format all through the compilation. But for some operations like VectorMask.trueCount()[4] which counts the elements of true value, the expected input mask is in-memory format. So a VectorStoreMask is generated to convert the mask from in-register format to in-memory format before those operations.
> 
> However, for trueCount() these xtn instructions in VectorStoreMask can be saved, since the narrowing operations will not influence the number of active lane (value of 0x01) of its input.
> 
> This patch adds an optimized rule `VectorMaskTrueCount (VectorStoreMask mask)` to save the unnecessary narrowing operations.
> 
> For example,
> 
> 
> var m = VectorMask.fromArray(IntVector.SPECIES_PREFERRED, ba, 0);
> m.not().trueCount();
> 
> 
> will produce following assembly on a Neon machine before this patch:
> 
> 
> ...
> mvn     v16.16b, v16.16b           // VectorMask.not()
> xtn     v16.4h, v16.4s
> xtn     v16.8b, v16.8h
> neg     v16.8b, v16.8b             // VectorStoreMask
> addv    b17, v16.8b
> umov    w0, v17.b[0]               // VectorMask.trueCount()
> ...
> 
> 
> After this patch:
> 
> 
> ...
> mvn     v16.16b, v16.16b           // VectorMask.not()
> addv    s17, v16.4s
> smov    x0, v17.b[0]
> neg     x0, x0                     // Optimized VectorMask.trueCount()
> ...
> 
> 
> In this case, we can save two xtn insns.
> 
> Performance:
> 
> Benchmark     Before               After                          Unit
> testInt           723.822 ? 1.029  1182.375 ? 12.363    ops/ms
> testLong       632.154 ? 0.197  1382.74 ? 2.188        ops/ms
> testShort      788.665 ? 1.852   1152.38 ? 3.77         ops/ms
> 
> [1]: https://github.com/openjdk/jdk/blob/e1e758a7b43c29840296d337bd2f0213ab0ca3c9/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4740
> [2]: https://github.com/openjdk/jdk/b...

Chang Peng has updated the pull request with a new target base 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 optimize_truecount_neon
 - 8307795: AArch64: Optimize VectorMask.truecount() on Neon
   
   In Vector API Java level, vector mask is represented as a boolean array
   with 0x00/0x01 (8 bits of each element) as values, aka in-memory format.
   When it is loaded into vector register, e.g. Neon, the in-memory format
   will be converted to in-register format with 0/-1 value for each lane
   (lane width aligned to its type) by VectorLoadMask [4] operation, and
   convert back to in-memory format by VectorStoreMask[2]. In Neon, a
   typical VectorStoreMask operation will first narrow given vector
   registers by xtn insn into byte element type, and then do a vector
   negate to convert to 0x00/0x01 value for each element.
   
   For most of the vector mask operations, the input mask is in-register
   format. And a vector mask also works in-register format all through
   the compilation. But for some operations like VectorMask.trueCount()[3]
   which counts the elements of true value, the expected input mask is
   in-memory format. So a VectorStoreMask [2] is generated to convert the
   mask from in-register format to in-memory format before those operations.
   
   However, for trueCount() these xtn instructions in VectorStoreMask can
   be saved, since the narrowing operations will not influence the number
   of active lane (value of 0x01) of its input.
   
   This patch adds an optimized rule
   `VectorMaskTrueCount (VectorStoreMask mask)` to save the unnecessary
   narrowing operations.
   
   For example,
   
   ```
   var m = VectorMask.fromArray(IntVector.SPECIES_PREFERRED, ba, 0);
   m.not().trueCount();
   ```
   
   will produce following assembly on a Neon machine before this patch:
   
   ```
   ...
   mvn     v16.16b, v16.16b           // VectorMask.not()
   xtn     v16.4h, v16.4s
   xtn     v16.8b, v16.8h
   neg     v16.8b, v16.8b             // VectorStoreMask
   addv    b17, v16.8b
   umov    w0, v17.b[0]               // VectorMask.trueCount()
   ...
   ```
   
   After this patch:
   
   ```
   ...
   mvn     v16.16b, v16.16b           // VectorMask.not()
   addv    s17, v16.4s
   smov    x0, v17.b[0]
   neg     x0, x0                     // Optimized VectorMask.trueCount()
   ...
   ```
   
   In this case, we can save two xtn insns.
   
   Performance:
   
   Benchmark     Before            After             Unit
   testInt       723.822 ? 1.029 1182.375 ? 12.363 ops/ms
   testLong      632.154 ? 0.197 1382.74 ? 2.188   ops/ms
   testShort     788.665 ? 1.852 1152.38 ? 3.77  ops/ms
   
   [1]: https://developer.arm.com/documentation/dui0801/h/A64-SIMD-Vector-Instructions/XTN--XTN2--vector-
   [2]: https://github.com/openjdk/jdk/blob/f968da97a5a5c68c28ad29d13fdfbe3a4adf5ef7/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4841
   [3]: https://docs.oracle.com/en/java/javase/16/docs/api/jdk.incubator.vector/jdk/incubator/vector/VectorMask.html#trueCount()
   [4]: https://github.com/openjdk/jdk/blob/e1e758a7b43c29840296d337bd2f0213ab0ca3c9/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4740

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13974/files
  - new: https://git.openjdk.org/jdk/pull/13974/files/b0eb5324..49e35b63

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13974&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13974&range=00-01

  Stats: 445618 lines in 4990 files changed: 371359 ins; 38351 del; 35908 mod
  Patch: https://git.openjdk.org/jdk/pull/13974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13974/head:pull/13974

PR: https://git.openjdk.org/jdk/pull/13974

From mcimadamore at openjdk.org  Thu May 18 09:33:00 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 18 May 2023 09:33:00 GMT
Subject: RFR: 8308248: Revisit alignment of layout constants on 32-bit
 platforms [v3]
In-Reply-To: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
References: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
Message-ID: <Fu0Fur5UCOmcjM6wp2qdvliOyUO2KTS0d_OedGSCMuQ=.76d47595-68a1-4cdd-a471-95b165e5fe0d@github.com>

> The FFM API exposes layout constants for Java primitives. Among those there are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of these layouts is set the same as their size (e.g. 8 bytes).
> 
> This is obviously correct on 64-bit platforms, but on 32-bit platform it is not, as such platforms cannot guarantee that doubles and longs will be always 64-bit aligned. This will also result in problems when trying to use e.g. `JAVA_DOUBLE` to model a C double for the linker API on 32-bit platforms.
> 
> For these reasons, it would be preferable to define the alignment of `JAVA_LONG` and `JAVA_DOUBLE` constants as `ADDRESS.byteSize()`. 
> 
> This patch rectifies alignment of those layout constants to reflect platform-dependent constraints. It also fixes the maximum alignment constraint supported by heap segments, so that it is 4 for long[] and double[] on 32-bit platforms.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments
  Actually tweak alignment of ValueLayout.OfLong/ValueLayout.OfDouble

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14007/files
  - new: https://git.openjdk.org/jdk/pull/14007/files/731095e9..0cb7d5a9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14007&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14007&range=01-02

  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14007.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14007/head:pull/14007

PR: https://git.openjdk.org/jdk/pull/14007

From mcimadamore at openjdk.org  Thu May 18 09:33:01 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 18 May 2023 09:33:01 GMT
Subject: RFR: 8308248: Revisit alignment of layout constants on 32-bit
 platforms [v3]
In-Reply-To: <Fu0Fur5UCOmcjM6wp2qdvliOyUO2KTS0d_OedGSCMuQ=.76d47595-68a1-4cdd-a471-95b165e5fe0d@github.com>
References: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
 <Fu0Fur5UCOmcjM6wp2qdvliOyUO2KTS0d_OedGSCMuQ=.76d47595-68a1-4cdd-a471-95b165e5fe0d@github.com>
Message-ID: <qXSpp4txpqmPwP8meOZ2931t2z8xXQNTwxV_WMZ-qXo=.b96aad3c-e022-4e8d-8e59-8a943c68ac04@github.com>

On Thu, 18 May 2023 09:28:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The FFM API exposes layout constants for Java primitives. Among those there are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of these layouts is set the same as their size (e.g. 8 bytes).
>> 
>> This is obviously correct on 64-bit platforms, but on 32-bit platform it is not, as such platforms cannot guarantee that doubles and longs will be always 64-bit aligned. This will also result in problems when trying to use e.g. `JAVA_DOUBLE` to model a C double for the linker API on 32-bit platforms.
>> 
>> For these reasons, it would be preferable to define the alignment of `JAVA_LONG` and `JAVA_DOUBLE` constants as `ADDRESS.byteSize()`. 
>> 
>> This patch rectifies alignment of those layout constants to reflect platform-dependent constraints. It also fixes the maximum alignment constraint supported by heap segments, so that it is 4 for long[] and double[] on 32-bit platforms.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments
>   Actually tweak alignment of ValueLayout.OfLong/ValueLayout.OfDouble

src/java.base/share/classes/jdk/internal/foreign/layout/ValueLayouts.java line 298:

> 296: 
> 297:         public static OfLong of(ByteOrder order) {
> 298:             return new OfLongImpl(order, ADDRESS_SIZE_BITS, Optional.empty());

Whoops - I forgot these all-important changes :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14007#discussion_r1197604492

From aturbanov at openjdk.org  Thu May 18 09:42:49 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 18 May 2023 09:42:49 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
In-Reply-To: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
Message-ID: <pCIEkF6tO7zBED3NtovGxm8ZVIBv1rry_9mZtajlAYQ=.74cd348c-e3e9-42b2-bedd-e717b43e9b81@github.com>

On Wed, 17 May 2023 19:40:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.

test/jdk/sun/text/resources/Collator/CollationSettingsTests.java line 43:

> 41: 
> 42: public class CollationSettingsTests {
> 43:     private static final Collator ENG_DEF =  Collator.getInstance(Locale.ENGLISH);

nit
Suggestion:

    private static final Collator ENG_DEF = Collator.getInstance(Locale.ENGLISH);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14040#discussion_r1197616430

From djelinski at openjdk.org  Thu May 18 09:47:52 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 18 May 2023 09:47:52 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <Agw1U8jJIdnuZuC_WY3nK8Ht5oZi6J3rN17BQVLK2HI=.8056e5a9-caa7-43f1-9f6c-b55e899820fd@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

Marked as reviewed by djelinski (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1432388069

From duke at openjdk.org  Thu May 18 09:50:13 2023
From: duke at openjdk.org (Chang Peng)
Date: Thu, 18 May 2023 09:50:13 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
 [v3]
In-Reply-To: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
Message-ID: <cXXQlLg77sWd5xEttH2vIPlxbFItZxSdz7qW4oZLAds=.dc774213-d8ec-4fc9-be0a-d70579cc20df@github.com>

> In Vector API Java level, vector mask is represented as a boolean array with 0x00/0x01 (8 bits of each element) as values, aka in-memory format. When it is loaded into vector register, e.g. Neon, the in-memory format will be converted to in-register format with 0/-1 value for each lane (lane width aligned to its type) by VectorLoadMask [1] operation, and convert back to in-memory format by VectorStoreMask[2]. In Neon, a typical VectorStoreMask operation will first narrow given vector registers by xtn insn [3] into byte element type, and then do a vector negate to convert to 0x00/0x01 value for each element.
> 
> For most of the vector mask operations, the input mask is in-register format. And a vector mask also works in-register format all through the compilation. But for some operations like VectorMask.trueCount()[4] which counts the elements of true value, the expected input mask is in-memory format. So a VectorStoreMask is generated to convert the mask from in-register format to in-memory format before those operations.
> 
> However, for trueCount() these xtn instructions in VectorStoreMask can be saved, since the narrowing operations will not influence the number of active lane (value of 0x01) of its input.
> 
> This patch adds an optimized rule `VectorMaskTrueCount (VectorStoreMask mask)` to save the unnecessary narrowing operations.
> 
> For example,
> 
> 
> var m = VectorMask.fromArray(IntVector.SPECIES_PREFERRED, ba, 0);
> m.not().trueCount();
> 
> 
> will produce following assembly on a Neon machine before this patch:
> 
> 
> ...
> mvn     v16.16b, v16.16b           // VectorMask.not()
> xtn     v16.4h, v16.4s
> xtn     v16.8b, v16.8h
> neg     v16.8b, v16.8b             // VectorStoreMask
> addv    b17, v16.8b
> umov    w0, v17.b[0]               // VectorMask.trueCount()
> ...
> 
> 
> After this patch:
> 
> 
> ...
> mvn     v16.16b, v16.16b           // VectorMask.not()
> addv    s17, v16.4s
> smov    x0, v17.b[0]
> neg     x0, x0                     // Optimized VectorMask.trueCount()
> ...
> 
> 
> In this case, we can save two xtn insns.
> 
> Performance:
> 
> Benchmark     Before               After                          Unit
> testInt           723.822 ? 1.029  1182.375 ? 12.363    ops/ms
> testLong       632.154 ? 0.197  1382.74 ? 2.188        ops/ms
> testShort      788.665 ? 1.852   1152.38 ? 3.77         ops/ms
> 
> [1]: https://github.com/openjdk/jdk/blob/e1e758a7b43c29840296d337bd2f0213ab0ca3c9/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4740
> [2]: https://github.com/openjdk/jdk/b...

Chang Peng has updated the pull request incrementally with one additional commit since the last revision:

  Update benchmark to avoid potential optimization

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13974/files
  - new: https://git.openjdk.org/jdk/pull/13974/files/49e35b63..567f69a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13974&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13974&range=01-02

  Stats: 20 lines in 4 files changed: 0 ins; 5 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13974/head:pull/13974

PR: https://git.openjdk.org/jdk/pull/13974

From duke at openjdk.org  Thu May 18 09:54:54 2023
From: duke at openjdk.org (Chang Peng)
Date: Thu, 18 May 2023 09:54:54 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
 [v3]
In-Reply-To: <sLSOr9OkNNZAreg3bIp_R0vcO7XosgN2N3AmAvH0ogw=.bb99445f-5e83-440d-94d5-f81053628e04@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
 <4hN6zn1gNhhXUIKHPlKhqqVolJkX-Hcrp2SgvI6zcU0=.9ecce499-66a2-41fa-be6e-93ed7615e02d@github.com>
 <5NfBPdiTQS9KBSWSgJSjfwW_IT7UdKwi__REZAvtxo4=.35641a45-6e4d-4b8a-865f-76784e7cc173@github.com>
 <sLSOr9OkNNZAreg3bIp_R0vcO7XosgN2N3AmAvH0ogw=.bb99445f-5e83-440d-94d5-f81053628e04@github.com>
Message-ID: <eRix8dJ4ZCZYuomBSPut-FWt-dhYc3bmdxI9G1mOxg8=.6a9c0f57-6765-4892-82bf-afb4892ca027@github.com>

On Mon, 15 May 2023 10:59:11 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > > This looks like it might be removed by loop opts. I think you might need a blackhole somewhere.
> > 
> > 
> > `m` will be updated in every iteration of this loop, so `m` is not a loop-invariants actually. I can see the assembly code of this loop by using JMH perfasm.
> 
> Isn't it? Looks to me like all it does is flip `m` each time. Whether or not this code is optimized today isn't relevant.
> 
> So it's the same as
> 
> ```
>         for (int i = 0; i < LENGTH/2; i++) {
>             res += m.trueCount();
>         }
>         m = m.not();
>         for (int i = 0; i < LENGTH/2; i++) {
>             res += m.trueCount();
>         } 
> ```
> 
> ... which is trivially optimizable, no?

Sorry for the delay.

Yes, actually they do the same thing, though current C2 compiler cannot do such optimization so far. Anyway, I have updated this benchmark to avoid potential optimization and ensure that we can measure performance effectively.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13974#discussion_r1197626911

From dfuchs at openjdk.org  Thu May 18 10:04:51 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 May 2023 10:04:51 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <0GxhPfV9kjdGq_66qtf-4bnWOhVwd5wZKr4HVDbBvkE=.fd5017df-882c-48a8-b373-34d6204664a1@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1432410653

From pminborg at openjdk.org  Thu May 18 10:07:52 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 18 May 2023 10:07:52 GMT
Subject: RFR: 8308248: Revisit alignment of layout constants on 32-bit
 platforms [v3]
In-Reply-To: <Fu0Fur5UCOmcjM6wp2qdvliOyUO2KTS0d_OedGSCMuQ=.76d47595-68a1-4cdd-a471-95b165e5fe0d@github.com>
References: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
 <Fu0Fur5UCOmcjM6wp2qdvliOyUO2KTS0d_OedGSCMuQ=.76d47595-68a1-4cdd-a471-95b165e5fe0d@github.com>
Message-ID: <a2-AgcX-VaV6SqOjPffm2nsWSrQZGdPxctEk5wI8_pE=.35595792-103a-4c14-ba8a-c620fe1ce650@github.com>

On Thu, 18 May 2023 09:33:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The FFM API exposes layout constants for Java primitives. Among those there are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of these layouts is set the same as their size (e.g. 8 bytes).
>> 
>> This is obviously correct on 64-bit platforms, but on 32-bit platform it is not, as such platforms cannot guarantee that doubles and longs will be always 64-bit aligned. This will also result in problems when trying to use e.g. `JAVA_DOUBLE` to model a C double for the linker API on 32-bit platforms.
>> 
>> For these reasons, it would be preferable to define the alignment of `JAVA_LONG` and `JAVA_DOUBLE` constants as `ADDRESS.byteSize()`. 
>> 
>> This patch rectifies alignment of those layout constants to reflect platform-dependent constraints. It also fixes the maximum alignment constraint supported by heap segments, so that it is 4 for long[] and double[] on 32-bit platforms.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments
>   Actually tweak alignment of ValueLayout.OfLong/ValueLayout.OfDouble

Does it make sense to add two test classes, each running on a 64/32-bit platform that verifies the two alignment variants?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14007#issuecomment-1552828503

From rriggs at openjdk.org  Thu May 18 13:49:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 May 2023 13:49:53 GMT
Subject: RFR: JDK-8308350: Increase buffer size for jspawnhelper arguments
 [v2]
In-Reply-To: <dgUkptUppUo4hpbWAiGfm-7bXskKoBPmp2ok9Yx_vic=.cf91d415-b7f4-4ec1-b13c-cca7559fa4c9@github.com>
References: <gTlgkqij_PkBAW5mi8FMlKuirGo26usST1mGa_Y1JrE=.805fef89-efc8-4f70-a448-a43054e139d6@github.com>
 <dgUkptUppUo4hpbWAiGfm-7bXskKoBPmp2ok9Yx_vic=.cf91d415-b7f4-4ec1-b13c-cca7559fa4c9@github.com>
Message-ID: <EucQcKuOiFoH-QYQgzdZ2_MNVCapmTtkMnGu_bCMqNw=.3603858a-3cef-42fd-96cd-156e3457f9fa@github.com>

On Thu, 18 May 2023 09:22:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Trivial fix for a small problem.
>> 
>> jspawnhelper gets handed several file descriptors as arguments. The buffer size for this string is too small (7 chars per fd) to print out every conceivable int. This will overun the buffer if we happen to have fds larger than (printed size) 7 characters. This could lead to crashes or malfunctions if the parent VM has opened a large amount of file descriptors.
>> 
>> Note that on Linux, this can normally not happen since the kernel limits the number of open file descriptors per process to 1M, and these fds are still printable within the limits of this buffer. It is possible to get more fds per process, but only via kernel patch. But we still should not rely on that. And there is also still MacOS using the same mechanism.
>
> Thomas Stuefe has updated the pull request with a new target base 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 JDK-8308350-Increase-buffer-size-for-jspawnhelper-arguments
>  - JDK-8308350-Increase-buffer-size-for-jspawnhelper-arguments

Trivial

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14045#pullrequestreview-1432744394

From rriggs at openjdk.org  Thu May 18 13:51:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 May 2023 13:51:51 GMT
Subject: RFR: 8308347: [s390x]  build broken after JDK-8304913
In-Reply-To: <RueF9me4xKw1608zHbpN9JTn7Ef0WsnnYyBhCd9wIm0=.0e628197-dfb4-46ce-88cf-d539c17832c7@github.com>
References: <RueF9me4xKw1608zHbpN9JTn7Ef0WsnnYyBhCd9wIm0=.0e628197-dfb4-46ce-88cf-d539c17832c7@github.com>
Message-ID: <-U-yIvLDqHvmuEnO-WWPuSoEseFUozVIOJJIAvpvnRA=.48dc24b2-ef8a-4bdf-b842-9a3e2b806e8e@github.com>

On Thu, 18 May 2023 06:12:19 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> s390x needs to be recognised as `S390`. After [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913) during build I was getting this PluginException: 
> 
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.S390X
>         at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
>         at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
>         at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
>         at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
>         at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> 
> 
> Builds tested :`fastdebug, release`.

LGTM; trivial

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14043#pullrequestreview-1432749151

From amitkumar at openjdk.org  Thu May 18 13:55:02 2023
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 18 May 2023 13:55:02 GMT
Subject: Integrated: 8308347: [s390x]  build broken after JDK-8304913
In-Reply-To: <RueF9me4xKw1608zHbpN9JTn7Ef0WsnnYyBhCd9wIm0=.0e628197-dfb4-46ce-88cf-d539c17832c7@github.com>
References: <RueF9me4xKw1608zHbpN9JTn7Ef0WsnnYyBhCd9wIm0=.0e628197-dfb4-46ce-88cf-d539c17832c7@github.com>
Message-ID: <aGqihnoT_C9_OT_pbyakEawXxovGLI_IRdhhBP80a5g=.444964a8-7f3e-47cc-b955-0a5f0931e1e8@github.com>

On Thu, 18 May 2023 06:12:19 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> s390x needs to be recognised as `S390`. After [JDK-8304913](https://bugs.openjdk.org/browse/JDK-8304913) during build I was getting this PluginException: 
> 
> jdk.tools.jlink.plugin.PluginException: ModuleTarget is malformed: No enum constant jdk.internal.util.Architecture.S390X
>         at jdk.jlink/jdk.tools.jlink.builder.DefaultImageBuilder.storeFiles(DefaultImageBuilder.java:181)
>         at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.storeFiles(ImagePluginStack.java:486)
>         at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:168)
>         at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:100)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:860)
>         at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:423)
>         at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:286)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
>         at jdk.jlink/jdk.tools.jlink.internal.Main.main(Main.java:34)
> 
> 
> Builds tested :`fastdebug, release`.

This pull request has now been integrated.

Changeset: a58e0ca9
Author:    Amit Kumar <amitkumar at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a58e0ca9d263807d7bfc0090b01bc71bff7c92db
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8308347: [s390x]  build broken after JDK-8304913

Reviewed-by: stuefe, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14043

From duke at openjdk.org  Thu May 18 13:57:05 2023
From: duke at openjdk.org (Glavo)
Date: Thu, 18 May 2023 13:57:05 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v3]
In-Reply-To: <KHzI2hrflmstmSodbBnNuNbnzbvG-sNBDrWl9hk2xbo=.d77e8ca6-7de5-452d-89b5-fa9343f428b8@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
 <KHzI2hrflmstmSodbBnNuNbnzbvG-sNBDrWl9hk2xbo=.d77e8ca6-7de5-452d-89b5-fa9343f428b8@github.com>
Message-ID: <AFm-p7RoBNIx5UiKRyipKTG9Ek3ZKL6AGk-PaX64ICY=.06aa2bc8-012a-488a-891c-b7916681d27c@github.com>

On Mon, 15 May 2023 22:51:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
>> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
>> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
>> 
>> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
>> Mac OS X 10.15 is the oldest version supported.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Merge branch 'master' into 8304914-os-jpackage
>  - The OperatingSystem enum treats AIX separately from Linux. The original Platform used the same enum for both.
>    Whereever OperatingSystem.isLinux is used in jpackage it should include isAix as well.
>  - Minor source code style cleanup
>  - Merge branch 'master' into 8304914-os-jpackage
>  - Merge branch '8306678-os-version' into 8304914-os-jpackage
>  - Merge branch '8304915-arch-enum' into 8306678-os-version
>  - Correct comment on isPPC64() and refer to isLittleEndian() instead of mentioning PPC64LE
>  - Simplify initialization in ClassLoaderHelper and fix VersionTest.
>  - Revert changes to MacOsX sun.nio.fs.BsdFileStore; the version check is being removed in another PR.
>  - Review comment updates
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/7b0b9b57...64ab7126

src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxDebBundler.java line 512:

> 510:     @Override
> 511:     public boolean supported(boolean runtimeInstaller) {
> 512:         return (OperatingSystem.isLinux() | OperatingSystem.isAix())

Ditto.

src/jdk.jpackage/linux/classes/jdk/jpackage/internal/LinuxRpmBundler.java line 335:

> 333:     @Override
> 334:     public boolean supported(boolean runtimeInstaller) {
> 335:         return (OperatingSystem.isLinux() | OperatingSystem.isAix())

Why use `|`? I think from the code logic, `||` is better.

Suggestion:

        return (OperatingSystem.isLinux() || OperatingSystem.isAix())

src/jdk.jpackage/share/classes/jdk/jpackage/internal/AddLauncherArguments.java line 144:

> 142:         }
> 143: 
> 144:         if (OperatingSystem.isLinux() | OperatingSystem.isAix()) {

Ditto.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/ApplicationLayout.java line 188:

> 186:         }
> 187: 
> 188:         if (OperatingSystem.isLinux() | OperatingSystem.isAix()) {

Ditto.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/I18N.java line 46:

> 44: 
> 45:     static {
> 46:         if (OperatingSystem.isLinux() | OperatingSystem.isAix()) {

Ditto.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/ToolValidator.java line 50:

> 48:         args = new ArrayList<>();
> 49: 
> 50:         if (OperatingSystem.isLinux() | OperatingSystem.isAix()) {

Ditto.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/ValidOptions.java line 142:

> 140:         }
> 141: 
> 142:         if (OperatingSystem.isLinux() | OperatingSystem.isAix()) {

Ditto.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1197846502
PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1197843828
PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1197858672
PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1197858780
PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1197858999
PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1197859099
PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1197859447

From stuefe at openjdk.org  Thu May 18 14:04:01 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 May 2023 14:04:01 GMT
Subject: Integrated: JDK-8308350: Increase buffer size for jspawnhelper
 arguments
In-Reply-To: <gTlgkqij_PkBAW5mi8FMlKuirGo26usST1mGa_Y1JrE=.805fef89-efc8-4f70-a448-a43054e139d6@github.com>
References: <gTlgkqij_PkBAW5mi8FMlKuirGo26usST1mGa_Y1JrE=.805fef89-efc8-4f70-a448-a43054e139d6@github.com>
Message-ID: <AOlQxoVMydW9DGlALMwjMkbT7sE5YIA56ZqGucnwD2Q=.c00662db-e9e1-4441-a76e-29a81c30895f@github.com>

On Thu, 18 May 2023 07:08:57 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial fix for a small problem.
> 
> jspawnhelper gets handed several file descriptors as arguments. The buffer size for this string is too small (7 chars per fd) to print out every conceivable int. This will overun the buffer if we happen to have fds larger than (printed size) 7 characters. This could lead to crashes or malfunctions if the parent VM has opened a large amount of file descriptors.
> 
> Note that on Linux, this can normally not happen since the kernel limits the number of open file descriptors per process to 1M, and these fds are still printable within the limits of this buffer. It is possible to get more fds per process, but only via kernel patch. But we still should not rely on that. And there is also still MacOS using the same mechanism.

This pull request has now been integrated.

Changeset: 808dc1b0
Author:    Thomas Stuefe <stuefe at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/808dc1b047c5a67b7397d47e38495efde022317d
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8308350: Increase buffer size for jspawnhelper arguments

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14045

From stuefe at openjdk.org  Thu May 18 14:04:00 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 18 May 2023 14:04:00 GMT
Subject: RFR: JDK-8308350: Increase buffer size for jspawnhelper arguments
 [v2]
In-Reply-To: <EucQcKuOiFoH-QYQgzdZ2_MNVCapmTtkMnGu_bCMqNw=.3603858a-3cef-42fd-96cd-156e3457f9fa@github.com>
References: <gTlgkqij_PkBAW5mi8FMlKuirGo26usST1mGa_Y1JrE=.805fef89-efc8-4f70-a448-a43054e139d6@github.com>
 <dgUkptUppUo4hpbWAiGfm-7bXskKoBPmp2ok9Yx_vic=.cf91d415-b7f4-4ec1-b13c-cca7559fa4c9@github.com>
 <EucQcKuOiFoH-QYQgzdZ2_MNVCapmTtkMnGu_bCMqNw=.3603858a-3cef-42fd-96cd-156e3457f9fa@github.com>
Message-ID: <tHGLqwIzukAHNV7hDY_edwcqOT-DY4aP_0njp4sCP-U=.bb6c727a-db38-4d8a-9688-5acd6a72e25e@github.com>

On Thu, 18 May 2023 13:46:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thomas Stuefe has updated the pull request with a new target base 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 JDK-8308350-Increase-buffer-size-for-jspawnhelper-arguments
>>  - JDK-8308350-Increase-buffer-size-for-jspawnhelper-arguments
>
> Trivial

Thanks @RogerRiggs !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14045#issuecomment-1553102627

From mdoerr at openjdk.org  Thu May 18 15:43:58 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 18 May 2023 15:43:58 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v17]
In-Reply-To: <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
Message-ID: <XVFRTEtEB6po-dQPGzG8TrGOujTMqj3v5qrxZSrlJGY=.880fbf6e-2ae4-4b4a-ac26-9fd2d34cfca2@github.com>

On Wed, 29 Mar 2023 01:40:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup test - rename method and update code comment as suggested by Alan
>  - Rename KNOWN_ENDIANNESS to PLATFORM_PROPERTIES

We will probably have to remove the mapping here if we treat ppc64le as a new architecture:
https://github.com/openjdk/jdk/blob/cc5c9b5da2de4229c0244169bcbd6496f68db5ab/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java#L55

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1553249225

From mdoerr at openjdk.org  Thu May 18 15:49:01 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 18 May 2023 15:49:01 GMT
Subject: RFR: 8308246: PPC64le build broken after JDK-8304913 [v2]
In-Reply-To: <L2QZAP9VO3YZ9L0RbhgD-1pvNJ30XEKIAYy7bj5tnJ8=.6730eb7c-d640-4edc-b438-38eb0180f2e9@github.com>
References: <OUvPvQDbXIsQ-O-qR63tufry6qINGdj_5d5JHgfMXdM=.5763443b-5156-4c68-83a7-2238051db85b@github.com>
 <HWJgPPDg_nNp-GkQ8BixcLEM_lIAVGB-hbr38QhVmr0=.b94c467a-ef46-4914-bab1-9e21e0850bae@github.com>
 <8cFw940aUmPolVFVRnjMZYw1yKpIy-A3E89G2RzlIlk=.c1e6e29a-3083-4c75-b13c-278e6854852c@github.com>
 <AZby-FH4GtMPU5l7Vpzusdqq_sZyHhy5tz_3dd8zq9M=.72e091d6-37a1-492e-99a2-23edf81cc493@github.com>
 <X0Dhk2-vsZxMWY3VIicRi3OP0hVe5PLu2SiX2bfhzCc=.9005c344-e4c3-40f9-8761-4d74081397f4@github.com>
 <L2QZAP9VO3YZ9L0RbhgD-1pvNJ30XEKIAYy7bj5tnJ8=.6730eb7c-d640-4edc-b438-38eb0180f2e9@github.com>
Message-ID: <yYFbyd0gE1-UX4W9WoTsntlIBWRzc2S7VFWRxdyMzZA=.b2ca3c9b-b7b3-4e98-a0ed-d33d9183daee@github.com>

On Thu, 18 May 2023 06:06:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hmm,  most java bytecode (classfiles) aren't going to care about the endian-ness; in int is an int, etc.
>> Runtime calls to extract int from byte[] is going to check a runtime flag; possibly static and optimization by HotSpot, etc.
>> The Architecture enum was intending to capture essential build time attributes.
>> If there is a need for more static attributes of a build, the current API doesn't cover that.
>
>> Hmm, most java bytecode (classfiles) aren't going to care about the endian-ness; in int is an int, etc.
>> Runtime calls to extract int from byte[] is going to check a runtime flag; possibly static and optimization by HotSpot, etc.
>> The Architecture enum was intending to capture essential build time attributes.
>> If there is a need for more static attributes of a build, the current API doesn't cover that.
> 
> The image writer needs to be told the endianness of the target platform, usually the native order but can be overridden. As part of pull/11943, a new resource file is added to map the value of the ModuleTarget class file attribute (essentially $os-$arch) to the endianness to help cross linking.  I don't yet see how this will work with the changes in the this PR.

Thanks for the hint! I've added a comment to https://github.com/openjdk/jdk/pull/11943 .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14027#discussion_r1197984714

From smarks at openjdk.org  Thu May 18 16:17:55 2023
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 18 May 2023 16:17:55 GMT
Subject: RFR: 8132995: Matcher$ImmutableMatchResult should be optimized to
 reduce space usage [v4]
In-Reply-To: <7SYKnNqUsGXJKoht_Azqh8wAoBcWgCYNko2eg4nqtBA=.0ae7d114-a5ee-4fdc-94e3-0d7ffecdae7b@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
 <7SYKnNqUsGXJKoht_Azqh8wAoBcWgCYNko2eg4nqtBA=.0ae7d114-a5ee-4fdc-94e3-0d7ffecdae7b@github.com>
Message-ID: <VbowNd_RzLW_oJza7vL7E8_s0v4ERlqwcywfaWHzoIE=.8998dd95-b55c-4372-b3b8-89f29ee4532d@github.com>

On Wed, 17 May 2023 15:05:53 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> When appropriate and useful, copies only the relevant portion of the `CharSequence` to the match result.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplified text capturing.

Thanks for the updates. Things look good.

-------------

Marked as reviewed by smarks (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13231#pullrequestreview-1433015398

From rriggs at openjdk.org  Thu May 18 16:30:58 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 May 2023 16:30:58 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v17]
In-Reply-To: <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
Message-ID: <AyPEnAiu7YCaAtFj48iOTK3-1BWhJAc0ar9A_LoOvwg=.5fbff5b5-9bd5-4724-b64f-7cffe8e04e38@github.com>

On Wed, 29 Mar 2023 01:40:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup test - rename method and update code comment as suggested by Alan
>  - Rename KNOWN_ENDIANNESS to PLATFORM_PROPERTIES

It seems that the endian-ness is intrinsic to the architecture, as it support for 64-bit addresses. Its not just an ancillary attribute.
This PR makes the case that identifiers for os and architecture need to cover the cross-platform uses, not just the current runtime.
Including the endianness in the architecture names/enums seems like a simple and consistent way to cover the case.
The class file attribute ModuleTarget and the jdk.internal.util.Architecture namespace should be consistent or the same. 
I'd be happy to propose an update to the jdk.internal.util.Architecture to expand the namespace and provide methods for endianness and address size.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1553311460

From vromero at openjdk.org  Thu May 18 16:39:53 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 May 2023 16:39:53 GMT
Subject: RFR: 8303669: SelectVersion indexes past the end of the argv array
 [v2]
In-Reply-To: <ywo2zms31sKW-lu900w0M0xElHHIIN6cIcNE4vLeYDE=.d26b0a95-eb8c-445d-ad33-26c3c71851a9@github.com>
References: <D2zcOZqRQkhsvO7q8bs0m1Ut9JDS-fx4EK64ENVOkXQ=.cc815a28-826d-442a-acd8-8cfbef9deaf0@github.com>
 <ywo2zms31sKW-lu900w0M0xElHHIIN6cIcNE4vLeYDE=.d26b0a95-eb8c-445d-ad33-26c3c71851a9@github.com>
Message-ID: <WJytKVR0JFHrm99HOyu1R4z22a3RMpaKoJhSSvsETPc=.2cdcd376-eec7-435c-bbcb-051317e2e6c0@github.com>

On Thu, 4 May 2023 09:17:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> libjli/java.c's SelectVersion method receives argc and argv but ignores argc in some circumstances an instead checks if *argv == 0 in its while loop, which results in a segmentation fault if the provided array is not NULL terminated. 
>> 
>> This patch counts down argc in the while loops instead of looking for zero termination.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added test

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13775#pullrequestreview-1433049710

From naoto at openjdk.org  Thu May 18 16:42:23 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 May 2023 16:42:23 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v2]
In-Reply-To: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
Message-ID: <38pDLy8zk4Ln68q9I07Lyjwdo6uVaVX27Ox4sHnjAZY=.19a7edf4-6e19-48ef-a186-32c6d03a27df@github.com>

> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/sun/text/resources/Collator/CollationSettingsTests.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14040/files
  - new: https://git.openjdk.org/jdk/pull/14040/files/c0c34bab..88a93839

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14040&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14040&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14040/head:pull/14040

PR: https://git.openjdk.org/jdk/pull/14040

From psandoz at openjdk.org  Thu May 18 16:54:55 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 18 May 2023 16:54:55 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v2]
In-Reply-To: <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
Message-ID: <mlze1coMTtKZsZWLD_WsGeHwKTGLsXGzmDBh3uNM7Ek=.a5e07f05-0cc8-4afe-a65f-8a8357cada29@github.com>

On Wed, 17 May 2023 18:18:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak javadoc

Here's the crux of what i am wondering about. Can we specify native linker support for a subset of the System V Application Binary Interface (e.g., LP64 and ILP32 programming models for all non-optional scalar types, sequences of, and groups of) such that a developer can write code using the FFM API and it will work across all JDK implementations supporting that native linker?

AFAICT the closest we have to that is the table in the Linker doc, and that table references C type names. Perhaps we can use C type name as the ABI type name for the System V Application Binary Interface? (literally copy the name used in Figure 3.1 C column of the ABI specification).

Then can do we the same and specify the equivalent native linker support for ABIs of Windows 64/32 and ARM?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1553337761

From bpb at openjdk.org  Thu May 18 17:01:54 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 May 2023 17:01:54 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v2]
In-Reply-To: <A4cl0OLlMYnjcv-85F4iGTfC3IS7lvT6_f563gGxz9U=.fa8f3b04-5c24-4401-8c4a-995fb6c06f3a@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <r_LcqolK93KzEk0mGDDPGAd8S7T071NUonelCwdcRnc=.c1de1c11-2f65-41c8-8365-625120bbd965@github.com>
 <-A9yScsR3ORyuNEdtKmsWhaUSw0OXxS025FWUINAlkc=.eb505075-c6a6-432b-bf9b-0f2bcdc8b8fe@github.com>
 <A4cl0OLlMYnjcv-85F4iGTfC3IS7lvT6_f563gGxz9U=.fa8f3b04-5c24-4401-8c4a-995fb6c06f3a@github.com>
Message-ID: <ql09L2uOj696eUdJhr9W8LLBhZvJQXUqulqBE_OlfKc=.a42c2a2b-d09a-4feb-adae-a91916345b41@github.com>

On Wed, 17 May 2023 15:50:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/RandomAccessFile.java line 904:
>> 
>>> 902:      * {@code b7}, and {@code b8,} where:
>>> 903:      * {@snippet lang=java :
>>> 904:      *         0 <= b1, b2, b3, b4, b5, b6, b7, b8 <= 255,
>> 
>> Same: this is not Java language syntax. Code or pre tags are fine here, they are not deprecated.
>
> I would keep the snippet markup but change the language to "text"; removing the expectation of language support.
> The benefits of a consistent look are still desirable.

Changed to unspecified language in 8ae42cf24b931d21dc643d233f33d4ccc5b32d6f.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198061816

From iris at openjdk.org  Thu May 18 17:03:51 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 18 May 2023 17:03:51 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v2]
In-Reply-To: <38pDLy8zk4Ln68q9I07Lyjwdo6uVaVX27Ox4sHnjAZY=.19a7edf4-6e19-48ef-a186-32c6d03a27df@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <38pDLy8zk4Ln68q9I07Lyjwdo6uVaVX27Ox4sHnjAZY=.19a7edf4-6e19-48ef-a186-32c6d03a27df@github.com>
Message-ID: <SCQe4m4WmpTkYWgWthtVaAXxb1oiWnA-eSTwygKRZoI=.ccdaf1d0-eecc-4283-b5e1-357ff496aa79@github.com>

On Thu, 18 May 2023 16:42:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/text/resources/Collator/CollationSettingsTests.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Looks good.

Associated CSR also Reviewed.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14040#pullrequestreview-1433091642

From mcimadamore at openjdk.org  Thu May 18 17:45:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 18 May 2023 17:45:53 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v2]
In-Reply-To: <mlze1coMTtKZsZWLD_WsGeHwKTGLsXGzmDBh3uNM7Ek=.a5e07f05-0cc8-4afe-a65f-8a8357cada29@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
 <mlze1coMTtKZsZWLD_WsGeHwKTGLsXGzmDBh3uNM7Ek=.a5e07f05-0cc8-4afe-a65f-8a8357cada29@github.com>
Message-ID: <-mkxytKGg0mOre0rrI1Jc5bwlFPgz0eghI8hPtM9Ldg=.6e2c8307-2d76-4fd0-a571-5b84a491c245@github.com>

On Thu, 18 May 2023 16:52:15 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Here's the crux of what i am wondering about. Can we specify native linker support for a subset of the System V Application Binary Interface (e.g., LP64 and ILP32 programming models for all non-optional scalar types, sequences of, and groups of) such that a developer can write code using the FFM API and it will work across all JDK implementations supporting that native linker?
> 
> AFAICT the closest we have to that is the table in the Linker doc, and that table references C type names. Perhaps we can use C type name as the ABI type name for the System V Application Binary Interface? (literally copy the name used in Figure 3.1 C column of the ABI specification).
> 
> Then can do we the same and specify the equivalent native linker support for ABIs of Windows 64/32 and ARM?

Consider that, at the time of writing we support (or might support soon):

* Sysv (Linux and MacOS)
* Aarch64(Linux, MacOs, Windows) - these have actually some ABI differences (e.g. variadic calls)
* PowerPC (which might come in big/little endian flavors)
* RiscV

That's quite a lot of ABIs and tables to have.

Also, if we wanted to tighten up the spec a little bit, what the user cares about is some minimum guarantees about the supported ABI types across platforms. E.g. you don't want a table-per-ABI, precisely because you want to know (I think): "if I call `linker.canonicalLayout().get("int")`" is this call guaranteed to succeed?

So, pulling on the string, IMHO we should:

* define which common subset of C types we support (e.g. list the C type names) - probably the one we use now is a good set;
* Give an example, on x64, of how these types might be realized using layouts (e.g. current table)

More pulling, the `char16_t` type is probably *not* defined on all ABIs (e.g. I can't find it here [1]). Which seems to suggest that perhaps canonical layout should just return mapping from string to lists of layouts, even if inconvenient?

[1] - https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#arm-c-and-c-language-mappings

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1553401016

From naoto at openjdk.org  Thu May 18 18:11:01 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 May 2023 18:11:01 GMT
Subject: RFR: 8308369: Default decomposition mode in Collator
Message-ID: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>

Amending the description about the default decomposition mode in `Collator.NO_DECOMPOSITION` javadoc.

-------------

Commit messages:
 - 8308369: Default decomposition mode in Collator

Changes: https://git.openjdk.org/jdk/pull/14049/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14049&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308369
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14049/head:pull/14049

PR: https://git.openjdk.org/jdk/pull/14049

From rriggs at openjdk.org  Thu May 18 18:23:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 May 2023 18:23:55 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v2]
In-Reply-To: <38pDLy8zk4Ln68q9I07Lyjwdo6uVaVX27Ox4sHnjAZY=.19a7edf4-6e19-48ef-a186-32c6d03a27df@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <38pDLy8zk4Ln68q9I07Lyjwdo6uVaVX27Ox4sHnjAZY=.19a7edf4-6e19-48ef-a186-32c6d03a27df@github.com>
Message-ID: <0UrJan8HJvt8arbtR0sKYixpvoY7m-rBsImek3Pmg_o=.c622654f-2c30-41d7-93c0-62ef24650b2b@github.com>

On Thu, 18 May 2023 16:42:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/text/resources/Collator/CollationSettingsTests.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

src/java.base/share/classes/java/text/Collator.java line 236:

> 234:      * setting value is not recognized, strength and/or decomposition will not be
> 235:      * overridden.
> 236:      * @apiNote Implementations of {@code Collator} class may produce

The API should identify the valid values for ks and kk and the corresponding values as passed to setStrength and setDecomposition.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14040#discussion_r1198141303

From rriggs at openjdk.org  Thu May 18 18:36:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 May 2023 18:36:55 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v7]
In-Reply-To: <jPkoZCShs1oyBRYLRaXDWQwNeVZC-SoDRDa36kTjMeg=.3b17b331-7817-4528-8e45-4957c2315829@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <jPkoZCShs1oyBRYLRaXDWQwNeVZC-SoDRDa36kTjMeg=.3b17b331-7817-4528-8e45-4957c2315829@github.com>
Message-ID: <MKOPt7rHfUgCNG6jb9ZrdSXpDGIx9nCdgn_fdlXK0HQ=.1d0f5117-2ca8-4761-a10b-d2c22e2afdf6@github.com>

On Wed, 17 May 2023 20:51:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.
>
> 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 seven additional commits since the last revision:
> 
>  - Merge
>  - 8308016: Reinstate @snippet for RandomAccessFile::readLong
>  - 8308016: Reduce linking in File::toPath snippet
>  - 8308016: Fix link in snippet of File::toPath
>  - 8308016: Address reviewer comments since previous commit
>  - 8308016: Remove ellipses ("...") from snippets
>  - 8308016: Use snippets in java.io package

src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 284:

> 282:      * array such that:
> 283:      * {@snippet lang=java :
> 284:      *         c == (char)(((hibyte & 0xff) << 8) | (b & 0xff))

I'd skip the extra indentation for just the single line example.

src/java.base/share/classes/java/io/CharArrayWriter.java line 189:

> 187:      *
> 188:      * {@snippet lang=java :
> 189:      *     out.write(csq.subSequence(start, end).toString())

a trailing ";' would be useful for copy/paste; butr that's not the existing style.  Your call.

src/java.base/share/classes/java/io/Console.java line 125:

> 123:      *             Scanner sc = new Scanner(con.reader());
> 124:      *             code: // @replace substring="code:" replacement="..."
> 125:      *         }

4 space indentation would be enough.

src/java.base/share/classes/java/io/RandomAccessFile.java line 762:

> 760:      * then the result is:
> 761:      * {@snippet lang=java :
> 762:      *         (byte)(b)

4 space indent is sufficient in this file

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198146819
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198147802
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198151689
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198160636

From jlaskey at openjdk.org  Thu May 18 19:06:28 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 18 May 2023 19:06:28 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v16]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <saUbdY7RX8Tkj8Osbr77Tfd9plfNXEdia8eIzvoR3lU=.183779ae-56ff-4a93-9c8b-89cfe55cdebb@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Give subclass priority

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/185532a8..83f31522

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=14-15

  Stats: 96 lines in 2 files changed: 43 ins; 30 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From bpb at openjdk.org  Thu May 18 19:14:02 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 May 2023 19:14:02 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v8]
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <M9zVErlCn0A2sEt_iOGlAh3pypQmmY43hB1QVOncwlA=.22a1d957-3165-465d-80db-f678d31f4048@github.com>

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8308016: Address reviewer comments since previous commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13957/files
  - new: https://git.openjdk.org/jdk/pull/13957/files/d0dce640..b6abb2e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13957&range=06-07

  Stats: 13 lines in 3 files changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/13957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13957/head:pull/13957

PR: https://git.openjdk.org/jdk/pull/13957

From bpb at openjdk.org  Thu May 18 19:14:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 May 2023 19:14:06 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v7]
In-Reply-To: <MKOPt7rHfUgCNG6jb9ZrdSXpDGIx9nCdgn_fdlXK0HQ=.1d0f5117-2ca8-4761-a10b-d2c22e2afdf6@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <jPkoZCShs1oyBRYLRaXDWQwNeVZC-SoDRDa36kTjMeg=.3b17b331-7817-4528-8e45-4957c2315829@github.com>
 <MKOPt7rHfUgCNG6jb9ZrdSXpDGIx9nCdgn_fdlXK0HQ=.1d0f5117-2ca8-4761-a10b-d2c22e2afdf6@github.com>
Message-ID: <fYT0w_SlJjMaStDmuOTmAgb_fjUF59I7a8qDxdyl838=.bcaeb567-18bf-43a4-9ff8-b80c7f44f93e@github.com>

On Thu, 18 May 2023 18:23:53 GMT, Roger Riggs <rriggs 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 seven additional commits since the last revision:
>> 
>>  - Merge
>>  - 8308016: Reinstate @snippet for RandomAccessFile::readLong
>>  - 8308016: Reduce linking in File::toPath snippet
>>  - 8308016: Fix link in snippet of File::toPath
>>  - 8308016: Address reviewer comments since previous commit
>>  - 8308016: Remove ellipses ("...") from snippets
>>  - 8308016: Use snippets in java.io package
>
> src/java.base/share/classes/java/io/ByteArrayOutputStream.java line 284:
> 
>> 282:      * array such that:
>> 283:      * {@snippet lang=java :
>> 284:      *         c == (char)(((hibyte & 0xff) << 8) | (b & 0xff))
> 
> I'd skip the extra indentation for just the single line example.

So changed in b6abb2e40fe574f40ebdfc0c5b1e28ed4b09126e.

> src/java.base/share/classes/java/io/CharArrayWriter.java line 189:
> 
>> 187:      *
>> 188:      * {@snippet lang=java :
>> 189:      *     out.write(csq.subSequence(start, end).toString())
> 
> a trailing ";' would be useful for copy/paste; butr that's not the existing style.  Your call.

These statements in general do not have a trailing `;`; left unchanged.

> src/java.base/share/classes/java/io/Console.java line 125:
> 
>> 123:      *             Scanner sc = new Scanner(con.reader());
>> 124:      *             code: // @replace substring="code:" replacement="..."
>> 125:      *         }
> 
> 4 space indentation would be enough.

So changed in b6abb2e40fe574f40ebdfc0c5b1e28ed4b09126e.

> src/java.base/share/classes/java/io/RandomAccessFile.java line 762:
> 
>> 760:      * then the result is:
>> 761:      * {@snippet lang=java :
>> 762:      *         (byte)(b)
> 
> 4 space indent is sufficient in this file

So changed in b6abb2e40fe574f40ebdfc0c5b1e28ed4b09126e.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198203067
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198203673
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198204033
PR Review Comment: https://git.openjdk.org/jdk/pull/13957#discussion_r1198203822

From psandoz at openjdk.org  Thu May 18 19:33:49 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 18 May 2023 19:33:49 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v2]
In-Reply-To: <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
Message-ID: <hDblMNy5lSS8IjFwT-_ECIEjUbi5NPBQ0p8M9kRxtPA=.54cd8d73-4efd-418a-b085-2fe8c85078d5@github.com>

On Wed, 17 May 2023 18:18:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak javadoc

I agree focusing on a subset of C types is the way to go. That avoids the unnecessary verbosity of many tables, and we can enumerate the types differing by data model (e.g., LP64 and ILP32). 

As a developer i would like to know for all C-based native linkers (which is all native linkers? what else would they be based on?) if:

1. the C `int` type etc is supported; and
2. whether i can use the `JAVA_INT` layout in my function descriptors, and know it corresponds to a C `int`. 

It seems obvious that i should be able to but AFAICT the specification is more example based, so it's not clear to me if different Java implementations can deviate in such behaviour.

Requiring the use of the C type names in the canonical mapping does help, because then i can more directly ask the C-based linker "Hey what's your canonical layout for the C `char` type?" .

I don't see `char16_t` defined either and i believe that type is an alias for `uint_least16_t`, which is a type of *at least* 16 bits. We need to use a C type of `unsigned short` or `uint16_t`:

- Java `ValueLayout.JAVA_SHORT` <-> C `short`
- Java `ValueLayout.JAVA_CHAR` <-> C `unsigned short`

?

For canonical type names we may want to prefer types specified by the C language over those defined by the C library in standard headers?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1553541814

From naoto at openjdk.org  Thu May 18 19:44:01 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 May 2023 19:44:01 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v3]
In-Reply-To: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
Message-ID: <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>

> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Added a table for possible BCP47 values and their mappings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14040/files
  - new: https://git.openjdk.org/jdk/pull/14040/files/88a93839..627b78b3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14040&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14040&range=01-02

  Stats: 33 lines in 1 file changed: 30 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14040/head:pull/14040

PR: https://git.openjdk.org/jdk/pull/14040

From rriggs at openjdk.org  Thu May 18 19:58:49 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 May 2023 19:58:49 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v3]
In-Reply-To: <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
Message-ID: <PcF-iRMWB2Wk4SfZBlL77iR9k5C4inGjqYaxdMAyHR0=.47a85bce-e2f3-486d-a569-34288ac19f08@github.com>

On Thu, 18 May 2023 19:44:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a table for possible BCP47 values and their mappings

Looks good

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14040#pullrequestreview-1433363782

From mcimadamore at openjdk.org  Thu May 18 20:33:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 18 May 2023 20:33:50 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v2]
In-Reply-To: <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
Message-ID: <PDYfy0oxTK70VmcZncZsM0NWNI5yLV0JSbDYFdwMyh0=.666fb105-7f86-4cb5-9dda-337e7a0994af@github.com>

On Wed, 17 May 2023 18:18:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak javadoc

> I don't see `char16_t` defined either and i believe that type is an alias for `uint_least16_t`, which is a type of _at least_ 16 bits. We need to use a C type of `unsigned short` or `uint16_t`:
> 
>     * Java `ValueLayout.JAVA_SHORT` <-> C `short`
> 
>     * Java `ValueLayout.JAVA_CHAR` <-> C `unsigned short`
> 
> 
> ?
Good point on "unsigned short". 
> 
> For canonical type names we may want to prefer types specified by the C language over those defined by the C library in standard headers?

Yes, I think better to stick with standard C types - IMHO with the exception of size_t which is very ubiquitous.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1553609560

From almatvee at openjdk.org  Thu May 18 21:14:52 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 18 May 2023 21:14:52 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v2]
In-Reply-To: <Nevv5bwPP5ckjFCLMQW9V7lQnqch1bU4ZqRbIdzLCtM=.3d99cede-f1c5-4893-8c14-4ad6fe537d36@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
 <PEKg9keUFr1YbZ2wRIq-CjOGGi-vr6fduph5XVIcEhE=.74f584e9-450f-494a-ba5c-555a73d9b4d1@github.com>
 <DBuIFwrtzIKUiah9Br5iZCADQw5z5ppWdR33xYWuZGM=.5665db8a-2cba-4757-bdfa-70a82a0cedd8@github.com>
 <Nevv5bwPP5ckjFCLMQW9V7lQnqch1bU4ZqRbIdzLCtM=.3d99cede-f1c5-4893-8c14-4ad6fe537d36@github.com>
Message-ID: <KFgJ9LhtTBro2R5x19wAKW4s2EeNPJbmToZIwssBh9E=.68ccef8b-90ec-4914-a60a-932038a691d7@github.com>

On Mon, 15 May 2023 20:10:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/jdk.jpackage/share/classes/jdk/jpackage/internal/CLIHelp.java line 51:
>> 
>>> 49:             Log.info(I18N.getString("MSG_Help_no_args"));
>>> 50:         } else {
>>> 51:             OperatingSystem platform = OperatingSystem.current();
>> 
>> Should we add if (Log.isVerbose) back? Otherwise default case in switch statement never executed.
>
> I was puzzled by that check early on and its still a puzzle. It seems a bit of a hack overloaded on the platform dispatch.
> As it turns out, the only time that `Log.isVerbose()` is true when `showHelp()` is called is when the environment variable `JPACKAGE_DEBUG` is used for debugging.
> `showHelp()` is only called before argument parsing is done and it doesn't look for --verbose. See `Main.execute()` 
> So checking for isVerbose has no practical function.

Makes sense. Looks good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13586#discussion_r1198309008

From almatvee at openjdk.org  Thu May 18 21:27:54 2023
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 18 May 2023 21:27:54 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v3]
In-Reply-To: <KHzI2hrflmstmSodbBnNuNbnzbvG-sNBDrWl9hk2xbo=.d77e8ca6-7de5-452d-89b5-fa9343f428b8@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
 <KHzI2hrflmstmSodbBnNuNbnzbvG-sNBDrWl9hk2xbo=.d77e8ca6-7de5-452d-89b5-fa9343f428b8@github.com>
Message-ID: <qLLFp-vK0czoK2jeaC3B1m15VGAieStLa-FDEtdamVY=.0027bcd7-8d59-4a23-9328-5e834ceeb4f9@github.com>

On Mon, 15 May 2023 22:51:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
>> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
>> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
>> 
>> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
>> Mac OS X 10.15 is the oldest version supported.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:
> 
>  - Merge branch 'master' into 8304914-os-jpackage
>  - The OperatingSystem enum treats AIX separately from Linux. The original Platform used the same enum for both.
>    Whereever OperatingSystem.isLinux is used in jpackage it should include isAix as well.
>  - Minor source code style cleanup
>  - Merge branch 'master' into 8304914-os-jpackage
>  - Merge branch '8306678-os-version' into 8304914-os-jpackage
>  - Merge branch '8304915-arch-enum' into 8306678-os-version
>  - Correct comment on isPPC64() and refer to isLittleEndian() instead of mentioning PPC64LE
>  - Simplify initialization in ClassLoaderHelper and fix VersionTest.
>  - Revert changes to MacOsX sun.nio.fs.BsdFileStore; the version check is being removed in another PR.
>  - Review comment updates
>  - ... and 24 more: https://git.openjdk.org/jdk/compare/7b0b9b57...64ab7126

Based on jpackage Platform.java we defined Linux as `os.indexOf("nix") >= 0 || os.indexOf("nux") >= 0`, I might be wrong but I think it will not detect AIX in original implementation. Do you know why it is added to jpackage? Also, did we test jpackage on AIX system?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13586#issuecomment-1553665336

From asemenyuk at openjdk.org  Thu May 18 21:36:51 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 18 May 2023 21:36:51 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v3]
In-Reply-To: <qLLFp-vK0czoK2jeaC3B1m15VGAieStLa-FDEtdamVY=.0027bcd7-8d59-4a23-9328-5e834ceeb4f9@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
 <KHzI2hrflmstmSodbBnNuNbnzbvG-sNBDrWl9hk2xbo=.d77e8ca6-7de5-452d-89b5-fa9343f428b8@github.com>
 <qLLFp-vK0czoK2jeaC3B1m15VGAieStLa-FDEtdamVY=.0027bcd7-8d59-4a23-9328-5e834ceeb4f9@github.com>
Message-ID: <i78YmYkmZ6r0Y7cuZLGQyMx_TiiMgZDyaFAjmVkyLOw=.b9a1a3b7-ff6c-4739-baa3-fe9013de7009@github.com>

On Thu, 18 May 2023 21:25:26 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> did we test jpackage on AIX system?

I don't think so. What is the native packaging on this platform?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13586#issuecomment-1553675715

From jlahoda at openjdk.org  Thu May 18 22:22:25 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 18 May 2023 22:22:25 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v11]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <0X0aAkDx30U-5AwZyjtCMFlljZKIu2AvvSN-erf-wFQ=.a44007e2-95c0-42cb-a8a3-81939b4aa953@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Disallowing annotations on record patterns.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13074/files
  - new: https://git.openjdk.org/jdk/pull/13074/files/69ba2a57..924ca58d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=09-10

  Stats: 102 lines in 7 files changed: 101 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

PR: https://git.openjdk.org/jdk/pull/13074

From vromero at openjdk.org  Thu May 18 22:36:07 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 18 May 2023 22:36:07 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v11]
In-Reply-To: <0X0aAkDx30U-5AwZyjtCMFlljZKIu2AvvSN-erf-wFQ=.a44007e2-95c0-42cb-a8a3-81939b4aa953@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
 <0X0aAkDx30U-5AwZyjtCMFlljZKIu2AvvSN-erf-wFQ=.a44007e2-95c0-42cb-a8a3-81939b4aa953@github.com>
Message-ID: <L0P1h0U3ProED8YX9qpAyXV22caL26_XzOjD9pmBIuU=.02fccb99-7910-4ac0-987d-5a525b652a24@github.com>

On Thu, 18 May 2023 22:22:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
>> 
>>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>>  - parenthesized patterns are removed.
>>  - qualified enum constants are supported for case labels.
>> 
>> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Disallowing annotations on record patterns.

minor comment, looks good

test/langtools/tools/javac/T8297602.java line 28:

> 26:  * @bug 8297602
> 27:  * @summary Compiler crash with type annotation and generic record during pattern matching
> 28:  * @compile/fail/ref=T8297602.out -XDrawDiagnostics T8297602.java

I think that this test can be eliminated as new test AnnotationErrors supersedes it.

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13074#pullrequestreview-1433538513
PR Review Comment: https://git.openjdk.org/jdk/pull/13074#discussion_r1198364712

From jpai at openjdk.org  Fri May 19 05:18:50 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 19 May 2023 05:18:50 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <Exw7vHSSx1vZBRx6gEBLZoeMu_ttiiGWbOFZAKtHK38=.485a27a9-2d3d-4b8a-850c-fa1f928880d8@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

These changes look fine to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1433788568

From dholmes at openjdk.org  Fri May 19 06:31:57 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 May 2023 06:31:57 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <qh4P0rQhdigeWLoD9paOaTJgT7uXOU0IsBTQlFdZ3Ew=.1eb8ea15-2d10-45e3-b883-87b088e220ba@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>
 <WNS9AUc4Uo0uJT7Q-c5WmRQGPXKHOiQ5bk3FAVhcpTw=.7b192c55-1a39-48bf-9c36-eb8219474c4f@github.com>
 <u7bSYYuppXZ1z347-wRTJf9GoxNUW-GoWfSn4dmCLEE=.831249e0-e538-491c-8001-a7dd55673721@github.com>
 <yZM9iro4FRdHveBRx07oeItZ9_CmQJ4wksNo3XI8Igs=.7b2097d5-0852-4f04-9c14-fc8d39a57c08@github.com>
 <qh4P0rQhdigeWLoD9paOaTJgT7uXOU0IsBTQlFdZ3Ew=.1eb8ea15-2d10-45e3-b883-87b088e220ba@github.com>
Message-ID: <Q1qJR_GJWPvAItv1fmJu-QYM0g5ozWkWd2ljkAy7VQ8=.3a657b07-464d-4184-a667-a3f9a7c9c72a@github.com>

On Wed, 17 May 2023 12:40:58 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Sorry, but I don't understand this argument. If we do a short read we will work with corrupted ChildStuff and SpawnInfo 
> structures. This can in the extreme case execute arbitrary code (e.g. if ChildStuff.argv is not fully read from the parent). You are 
> basically saying it is better to work on corrupted data rather than reporting an error.

No I am simply pointing out that this has changed more than just the issue with close. Any maybe a short-read does indicate data "corruption" and maybe it should be a fatal error. But I don't know exactly how this might manifest so perhaps there are benign short-reads that actually do happen. Regardless it might be better to split this part out and focus on the close issue here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1554073177

From pminborg at openjdk.org  Fri May 19 06:44:19 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 19 May 2023 06:44:19 GMT
Subject: RFR: 8308281: Java snippets in the FFM API need to be updated [v2]
In-Reply-To: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>
References: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>
Message-ID: <KvALOr5BDkB71pOepsV8hdCmSP81-JAcDnxU_TfTxNA=.d8e37953-b060-4c96-8b92-c4580902e643@github.com>

> As the API has improved over the recent releases, not all `{@snippet ..}` sections have been kept in sync.
> 
> This PR suggests all snippets used should be verified against real code that is placed in a new `snippet-files` folder and erroneous snippets are updated.
> 
> In this PR, it is suggested duplicating code in the `Snippets.java` class and in the JavaDocs. The benefit of this is that code is directly visible in the code and not only in the generated javadoc.
> 
> Another thing to think about is if there should be on single `Snippets.java` class or separate ones for each FFM class.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix according to comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14030/files
  - new: https://git.openjdk.org/jdk/pull/14030/files/cf6267ad..2cbff9c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14030&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14030&range=00-01

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14030/head:pull/14030

PR: https://git.openjdk.org/jdk/pull/14030

From mbaesken at openjdk.org  Fri May 19 07:06:02 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 19 May 2023 07:06:02 GMT
Subject: RFR: JDK-8308300: enhance exceptions in MappedMemoryUtils.c
Message-ID: <HAdmPxpkTj9Xzd-xBZxvAaSDLInLorEi-UvcxygEiUs=.84a938a8-a0c8-4271-a88b-7ffd4356c366@github.com>

MappedMemoryUtils.c can generate exceptions like those :
java.io.UncheckedIOException: java.io.IOException: Invalid argument
       at java.base/java.nio.MappedMemoryUtils.force(MappedMemoryUtils.java:105)
       at java.base/java.nio.Buffer$2.force(Buffer.java:890)
       at java.base/jdk.internal.misc.ScopedMemoryAccess.forceInternal(ScopedMemoryAccess.java:317)
       at java.base/jdk.internal.misc.ScopedMemoryAccess.force(ScopedMemoryAccess.java:305)
       at java.base/jdk.internal.foreign.MappedMemorySegmentImpl.force(MappedMemorySegmentImpl.java:92)
       at TestByteBuffer.testMappedSegmentAsByteBuffer(TestByteBuffer.java:327)

(we see this for example on AIX); there is some room for improvement, at least the info should be added that msync failed and caused this exception.

-------------

Commit messages:
 - JDK-8308300

Changes: https://git.openjdk.org/jdk/pull/14054/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14054&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308300
  Stats: 16 lines in 3 files changed: 13 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14054.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14054/head:pull/14054

PR: https://git.openjdk.org/jdk/pull/14054

From alanb at openjdk.org  Fri May 19 08:02:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 08:02:49 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v3]
In-Reply-To: <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
Message-ID: <hif0_x1Xsly3QcpMBMxoD69Yc5IX2G6aZvATHgQBYOw=.43b003ac-4d64-4764-862a-22a8cc675b46@github.com>

On Thu, 18 May 2023 19:44:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a table for possible BCP47 values and their mappings

src/java.base/share/classes/java/text/Collator.java line 264:

> 262:      * </table>
> 263:      * If the specified setting value is not recognized, strength and/or
> 264:      * decomposition will not be overridden.

The proposed update looks okay except for the last part "If the specified setting value is not recognized, strength and/or decomposition will not be overridden". I thin this could be clearer.
If I understand correctly, if the Unicode locale type for the given Locale might have a strength level and decomposition mode and this method makes a best effort to return a Collator with the expected level and mode. If so, then I think the javadoc needs to make this a bit clearer. Also, if the factory method returns a Collator that doesn't do what I asked, can I call setStrength/setDecomposition to change it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14040#discussion_r1198665295

From rgiulietti at openjdk.org  Fri May 19 08:08:02 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 19 May 2023 08:08:02 GMT
Subject: Integrated: 8132995: Matcher$ImmutableMatchResult should be optimized
 to reduce space usage
In-Reply-To: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
References: <IeErf_ZY-gLUjWWBVVhQuzCTkutzHq_miPxttrK9NsE=.d1a79a35-edc0-4ba4-8ae2-787d1ec0cd7e@github.com>
Message-ID: <4oepp1Y11Gc42xB2OP8rGBGaaY0RiquS7_dqYiBWWyY=.efe480d3-859e-4608-848a-aaca39b1d0fe@github.com>

On Wed, 29 Mar 2023 18:09:22 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> When appropriate and useful, copies only the relevant portion of the `CharSequence` to the match result.

This pull request has now been integrated.

Changeset: 25868b95
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25868b95ee91eee9e7611ad18540a7e30032e49b
Stats:     209 lines in 2 files changed: 183 ins; 15 del; 11 mod

8132995: Matcher$ImmutableMatchResult should be optimized to reduce space usage

Reviewed-by: redestad, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/13231

From asotona at openjdk.org  Fri May 19 08:12:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 19 May 2023 08:12:58 GMT
Subject: RFR: 8303669: SelectVersion indexes past the end of the argv array
 [v2]
In-Reply-To: <ywo2zms31sKW-lu900w0M0xElHHIIN6cIcNE4vLeYDE=.d26b0a95-eb8c-445d-ad33-26c3c71851a9@github.com>
References: <D2zcOZqRQkhsvO7q8bs0m1Ut9JDS-fx4EK64ENVOkXQ=.cc815a28-826d-442a-acd8-8cfbef9deaf0@github.com>
 <ywo2zms31sKW-lu900w0M0xElHHIIN6cIcNE4vLeYDE=.d26b0a95-eb8c-445d-ad33-26c3c71851a9@github.com>
Message-ID: <OwPjso5odqVXPD62hvMMEqwOkDqYnSZOplCR9u5Hnj4=.caf76248-7407-425f-a972-9213a57541cd@github.com>

On Thu, 4 May 2023 09:17:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> libjli/java.c's SelectVersion method receives argc and argv but ignores argc in some circumstances an instead checks if *argv == 0 in its while loop, which results in a segmentation fault if the provided array is not NULL terminated. 
>> 
>> This patch counts down argc in the while loops instead of looking for zero termination.
>> 
>> Please review.
>> 
>> Thank you,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added test

Thank you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13775#issuecomment-1554205049

From asotona at openjdk.org  Fri May 19 08:13:00 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 19 May 2023 08:13:00 GMT
Subject: Integrated: 8303669: SelectVersion indexes past the end of the argv
 array
In-Reply-To: <D2zcOZqRQkhsvO7q8bs0m1Ut9JDS-fx4EK64ENVOkXQ=.cc815a28-826d-442a-acd8-8cfbef9deaf0@github.com>
References: <D2zcOZqRQkhsvO7q8bs0m1Ut9JDS-fx4EK64ENVOkXQ=.cc815a28-826d-442a-acd8-8cfbef9deaf0@github.com>
Message-ID: <tN6CqzgImHytHSM8VFNUt7SZ5UKZ0QSJcaGykbdkvmg=.c795e2dc-0c8c-4ec6-96e9-a2e4b7c608c6@github.com>

On Wed, 3 May 2023 12:03:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> libjli/java.c's SelectVersion method receives argc and argv but ignores argc in some circumstances an instead checks if *argv == 0 in its while loop, which results in a segmentation fault if the provided array is not NULL terminated. 
> 
> This patch counts down argc in the while loops instead of looking for zero termination.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: fa143148
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa14314853e161c6ca5561be3e1e280691d8fe99
Stats:     10 lines in 3 files changed: 6 ins; 0 del; 4 mod

8303669: SelectVersion indexes past the end of the argv array

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/13775

From alanb at openjdk.org  Fri May 19 08:17:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 08:17:16 GMT
Subject: RFR: 8308235: ThreadContainer registry accumulates weak refs
Message-ID: <FS-cdoNCm7sqOB8-RRUSEZxfrIgTBlYuH4_UQ9tK7FA=.7f90bd7f-65fc-4945-be38-525c7b233951@github.com>

ThreadContainers is an internal class used to make thread pools and other groupings of threads discoverable for observability. Some refactoring in 2021 (in the loom repo, and before integration) accidentally changed the creation of a weak reference so that it no longer associated with the reference queue. The result is that stale refs aren't expunged from a CHM, leading to a memory leak. The change to fix the issue is trivial.

Tests for memory leaks can be problematic, often more trouble than they are worth. I started with a test that polls the size of the internal CHM but decided to ditch it. Instead, the test is simple. It just runs for a few seconds creating ExecuorService implementations (including TPE, TPPE, and FJP), unreferencing them without shutdown (so they don't terminate and unregister). This is enough to causes OOME with product builds a small heap.

-------------

Commit messages:
 - Fix @run tag
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14047/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14047&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308235
  Stats: 47 lines in 2 files changed: 45 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14047.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14047/head:pull/14047

PR: https://git.openjdk.org/jdk/pull/14047

From duke at openjdk.org  Fri May 19 08:29:49 2023
From: duke at openjdk.org (Viktor Klang)
Date: Fri, 19 May 2023 08:29:49 GMT
Subject: RFR: 8308235: ThreadContainer registry accumulates weak refs
In-Reply-To: <FS-cdoNCm7sqOB8-RRUSEZxfrIgTBlYuH4_UQ9tK7FA=.7f90bd7f-65fc-4945-be38-525c7b233951@github.com>
References: <FS-cdoNCm7sqOB8-RRUSEZxfrIgTBlYuH4_UQ9tK7FA=.7f90bd7f-65fc-4945-be38-525c7b233951@github.com>
Message-ID: <rEBv1f-Hu-rAS83IglAwgel5E07AVwtTyo_ei1vo44k=.5de5dcc1-d17d-432f-bf74-a48ca4b081b3@github.com>

On Thu, 18 May 2023 15:44:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> ThreadContainers is an internal class used to make thread pools and other groupings of threads discoverable for observability. Some refactoring in 2021 (in the loom repo, and before integration) accidentally changed the creation of a weak reference so that it no longer associated with the reference queue. The result is that stale refs aren't expunged from a CHM, leading to a memory leak. The change to fix the issue is trivial.
> 
> Tests for memory leaks can be problematic, often more trouble than they are worth. I started with a test that polls the size of the internal CHM but decided to ditch it. Instead, the test is simple. It just runs for a few seconds creating ExecuorService implementations (including TPE, TPPE, and FJP), unreferencing them without shutdown (so they don't terminate and unregister). This is enough to causes OOME with product builds a small heap.

test/jdk/java/util/concurrent/Executors/UnreferencedExecutor.java line 38:

> 36:         int ncores = Runtime.getRuntime().availableProcessors();
> 37:         long start = System.currentTimeMillis();
> 38:         while (System.currentTimeMillis() - start < 5000) {

@AlanBateman Might want to have this based on `nanoTime()` such that changes to wall-clock doesn't impact the length of the run of the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14047#discussion_r1198690117

From jpai at openjdk.org  Fri May 19 08:49:01 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 19 May 2023 08:49:01 GMT
Subject: RFR: 8308235: ThreadContainer registry accumulates weak refs
In-Reply-To: <FS-cdoNCm7sqOB8-RRUSEZxfrIgTBlYuH4_UQ9tK7FA=.7f90bd7f-65fc-4945-be38-525c7b233951@github.com>
References: <FS-cdoNCm7sqOB8-RRUSEZxfrIgTBlYuH4_UQ9tK7FA=.7f90bd7f-65fc-4945-be38-525c7b233951@github.com>
Message-ID: <3AWCdFoRWdn8NGAbdrY-b8_u-BeiSlbKNv_A8M8QMJY=.c970372a-c96f-415f-b48a-2033d0e0cae6@github.com>

On Thu, 18 May 2023 15:44:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> ThreadContainers is an internal class used to make thread pools and other groupings of threads discoverable for observability. Some refactoring in 2021 (in the loom repo, and before integration) accidentally changed the creation of a weak reference so that it no longer associated with the reference queue. The result is that stale refs aren't expunged from a CHM, leading to a memory leak. The change to fix the issue is trivial.
> 
> Tests for memory leaks can be problematic, often more trouble than they are worth. I started with a test that polls the size of the internal CHM but decided to ditch it. Instead, the test is simple. It just runs for a few seconds creating ExecuorService implementations (including TPE, TPPE, and FJP), unreferencing them without shutdown (so they don't terminate and unregister). This is enough to causes OOME with product builds a small heap.

The change looks OK to me. The `QUEUE` (of `WeakReference`) and thus the registry, gets cleaned up whenever new `ThreadContainer`s are registered with the registry.

Would it be worth calling `expungeStaleEntries()` to do this cleanup even when a specific `ThreadContainer` is deregistered, in the implementation of method `deregisterContainer(...)`?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14047#issuecomment-1554246479

From alanb at openjdk.org  Fri May 19 09:08:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 09:08:52 GMT
Subject: RFR: JDK-8308300: enhance exceptions in MappedMemoryUtils.c
In-Reply-To: <HAdmPxpkTj9Xzd-xBZxvAaSDLInLorEi-UvcxygEiUs=.84a938a8-a0c8-4271-a88b-7ffd4356c366@github.com>
References: <HAdmPxpkTj9Xzd-xBZxvAaSDLInLorEi-UvcxygEiUs=.84a938a8-a0c8-4271-a88b-7ffd4356c366@github.com>
Message-ID: <t_7RkY9VYPjYf0f4OG9n8kNAqyWdECJw8tnuaifQqlA=.86cdc544-0bf6-4cc9-b976-05fa993ed4e4@github.com>

On Fri, 19 May 2023 06:58:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> MappedMemoryUtils.c can generate exceptions like those :
> java.io.UncheckedIOException: java.io.IOException: Invalid argument
>        at java.base/java.nio.MappedMemoryUtils.force(MappedMemoryUtils.java:105)
>        at java.base/java.nio.Buffer$2.force(Buffer.java:890)
>        at java.base/jdk.internal.misc.ScopedMemoryAccess.forceInternal(ScopedMemoryAccess.java:317)
>        at java.base/jdk.internal.misc.ScopedMemoryAccess.force(ScopedMemoryAccess.java:305)
>        at java.base/jdk.internal.foreign.MappedMemorySegmentImpl.force(MappedMemorySegmentImpl.java:92)
>        at TestByteBuffer.testMappedSegmentAsByteBuffer(TestByteBuffer.java:327)
> 
> (we see this for example on AIX); there is some room for improvement, at least the info should be added that msync failed and caused this exception.

src/java.base/share/native/libjava/jni_util.c line 196:

> 194: {
> 195:     JNU_ThrowByNameWithMessageAndLastError(env, "java/io/IOException", message);
> 196: }

The additional function looks okay but I think the function description would be clearer if it were like this


/*
 * Throw java.io.IOException using a given message and the string
 * returned by getLastErrorString to construct the detail string.
 */


I see JNU_ThrowIOExceptionWithLastError also "Convenience method" but it's a function :-)

src/java.base/unix/native/libnio/MappedMemoryUtils.c line 114:

> 112:     if (result == -1) {
> 113:         JNU_ThrowIOExceptionWithMessageAndLastError(env, "madvise with parameter MADV_WILLNEED failed");
> 114:     }

Maybe change "with parameter" to "with advise" so it's clearer what the value is about?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14054#discussion_r1198727146
PR Review Comment: https://git.openjdk.org/jdk/pull/14054#discussion_r1198728333

From alanb at openjdk.org  Fri May 19 09:12:02 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 09:12:02 GMT
Subject: RFR: 8308235: ThreadContainer registry accumulates weak refs
In-Reply-To: <3AWCdFoRWdn8NGAbdrY-b8_u-BeiSlbKNv_A8M8QMJY=.c970372a-c96f-415f-b48a-2033d0e0cae6@github.com>
References: <FS-cdoNCm7sqOB8-RRUSEZxfrIgTBlYuH4_UQ9tK7FA=.7f90bd7f-65fc-4945-be38-525c7b233951@github.com>
 <3AWCdFoRWdn8NGAbdrY-b8_u-BeiSlbKNv_A8M8QMJY=.c970372a-c96f-415f-b48a-2033d0e0cae6@github.com>
Message-ID: <eyrCsyqBnkSCmpFblIn-7I0hV-YLXY51JaAcslXvtpo=.a9e884d3-a889-41fa-b2d0-023c2187c242@github.com>

On Fri, 19 May 2023 08:46:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Would it be worth calling `expungeStaleEntries()` to do this cleanup even when a specific `ThreadContainer` is deregistered, in the implementation of method `deregisterContainer(...)`?

If there is a mix of usages where some are explicitly shutdown/terminated, and others are abandoned, then it might help some usage patterns. There is more significant work to do this area and I think we can look at it then.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14047#issuecomment-1554273632

From jpai at openjdk.org  Fri May 19 09:14:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 19 May 2023 09:14:49 GMT
Subject: RFR: 8308235: ThreadContainer registry accumulates weak refs
In-Reply-To: <FS-cdoNCm7sqOB8-RRUSEZxfrIgTBlYuH4_UQ9tK7FA=.7f90bd7f-65fc-4945-be38-525c7b233951@github.com>
References: <FS-cdoNCm7sqOB8-RRUSEZxfrIgTBlYuH4_UQ9tK7FA=.7f90bd7f-65fc-4945-be38-525c7b233951@github.com>
Message-ID: <x_OQ3SEEVvJR9-ql2FvfYIV-tKd8ERpC9AphS4WIcuY=.18bfac6d-472f-4f09-916e-f6c4187f4361@github.com>

On Thu, 18 May 2023 15:44:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> ThreadContainers is an internal class used to make thread pools and other groupings of threads discoverable for observability. Some refactoring in 2021 (in the loom repo, and before integration) accidentally changed the creation of a weak reference so that it no longer associated with the reference queue. The result is that stale refs aren't expunged from a CHM, leading to a memory leak. The change to fix the issue is trivial.
> 
> Tests for memory leaks can be problematic, often more trouble than they are worth. I started with a test that polls the size of the internal CHM but decided to ditch it. Instead, the test is simple. It just runs for a few seconds creating ExecuorService implementations (including TPE, TPPE, and FJP), unreferencing them without shutdown (so they don't terminate and unregister). This is enough to causes OOME with product builds a small heap.

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14047#pullrequestreview-1434069274

From jpai at openjdk.org  Fri May 19 09:14:49 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 19 May 2023 09:14:49 GMT
Subject: RFR: 8308235: ThreadContainer registry accumulates weak refs
In-Reply-To: <eyrCsyqBnkSCmpFblIn-7I0hV-YLXY51JaAcslXvtpo=.a9e884d3-a889-41fa-b2d0-023c2187c242@github.com>
References: <FS-cdoNCm7sqOB8-RRUSEZxfrIgTBlYuH4_UQ9tK7FA=.7f90bd7f-65fc-4945-be38-525c7b233951@github.com>
 <3AWCdFoRWdn8NGAbdrY-b8_u-BeiSlbKNv_A8M8QMJY=.c970372a-c96f-415f-b48a-2033d0e0cae6@github.com>
 <eyrCsyqBnkSCmpFblIn-7I0hV-YLXY51JaAcslXvtpo=.a9e884d3-a889-41fa-b2d0-023c2187c242@github.com>
Message-ID: <WydWKlyoxUHzjfgdz_X-7Z6KFiBqEUc5jwxnqPtBrI4=.a96c53a5-74f8-41b7-a2dd-e1a865d8d415@github.com>

On Fri, 19 May 2023 09:09:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> There is more significant work to do this area and I think we can look at it then.

That sounds reasonable to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14047#issuecomment-1554277576

From mcimadamore at openjdk.org  Fri May 19 09:22:05 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 19 May 2023 09:22:05 GMT
Subject: RFR: 8308248: Revisit alignment of layout constants on 32-bit
 platforms [v4]
In-Reply-To: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
References: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
Message-ID: <aztE_ucMA3CyhDHROFaHSO6633HN_17XbdzOXrH-eCk=.8aaff0c7-cd5b-4fdd-81c3-a7324a686294@github.com>

> The FFM API exposes layout constants for Java primitives. Among those there are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of these layouts is set the same as their size (e.g. 8 bytes).
> 
> This is obviously correct on 64-bit platforms, but on 32-bit platform it is not, as such platforms cannot guarantee that doubles and longs will be always 64-bit aligned. This will also result in problems when trying to use e.g. `JAVA_DOUBLE` to model a C double for the linker API on 32-bit platforms.
> 
> For these reasons, it would be preferable to define the alignment of `JAVA_LONG` and `JAVA_DOUBLE` constants as `ADDRESS.byteSize()`. 
> 
> This patch rectifies alignment of those layout constants to reflect platform-dependent constraints. It also fixes the maximum alignment constraint supported by heap segments, so that it is 4 for long[] and double[] on 32-bit platforms.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add simple sanity check

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14007/files
  - new: https://git.openjdk.org/jdk/pull/14007/files/0cb7d5a9..19ae22a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14007&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14007&range=02-03

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14007.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14007/head:pull/14007

PR: https://git.openjdk.org/jdk/pull/14007

From alanb at openjdk.org  Fri May 19 09:34:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 09:34:51 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v6]
In-Reply-To: <jcpe28LzmXpGO4YE5eP6fF-RBEg-O2iUMP0EphSCox8=.6f398f44-463c-474a-8428-ee0afa09ff18@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <jcpe28LzmXpGO4YE5eP6fF-RBEg-O2iUMP0EphSCox8=.6f398f44-463c-474a-8428-ee0afa09ff18@github.com>
Message-ID: <LFgxOLcJ5_iQPvsWlslmCOmvedtb2_i9WEywTBnOca4=.4d3b0563-c795-4eaa-bf86-a77a76768cf2@github.com>

On Wed, 17 May 2023 02:32:56 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> I fixed File.listRoots description.
>> * remove "the insertion or ejection of removable media"
>> * change "available" to "existing"
>> 
>> Please review this change.
>
> Nagata-Haruhito has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Merge branch 'File_javadoc' of https://github.com/Nagata-Haruhito/jdk into File_javadoc
>  - Drop exist to available
>  - Merge branch 'master' into File_javadoc

src/java.base/share/classes/java/io/File.java line 1828:

> 1826:      * namely {@code "/"}.  The set of filesystem roots is affected
> 1827:      * by various system-level operations such as the disconnecting or
> 1828:      * unmounting of physical or virtual disk drives.

I think you'll have to move this to the end of the method description, otherwise the paragraphs that follow will show up as "Implementation Note" too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13526#discussion_r1198752925

From mbaesken at openjdk.org  Fri May 19 09:46:59 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 19 May 2023 09:46:59 GMT
Subject: RFR: JDK-8308300: enhance exceptions in MappedMemoryUtils.c [v2]
In-Reply-To: <HAdmPxpkTj9Xzd-xBZxvAaSDLInLorEi-UvcxygEiUs=.84a938a8-a0c8-4271-a88b-7ffd4356c366@github.com>
References: <HAdmPxpkTj9Xzd-xBZxvAaSDLInLorEi-UvcxygEiUs=.84a938a8-a0c8-4271-a88b-7ffd4356c366@github.com>
Message-ID: <zNA2bmDcgM9kUctXeiyjOlOEylP2wMc_tfygDeuKOqo=.4f2a4299-8a7b-4793-989b-e5c2c65f5ab3@github.com>

> MappedMemoryUtils.c can generate exceptions like those :
> java.io.UncheckedIOException: java.io.IOException: Invalid argument
>        at java.base/java.nio.MappedMemoryUtils.force(MappedMemoryUtils.java:105)
>        at java.base/java.nio.Buffer$2.force(Buffer.java:890)
>        at java.base/jdk.internal.misc.ScopedMemoryAccess.forceInternal(ScopedMemoryAccess.java:317)
>        at java.base/jdk.internal.misc.ScopedMemoryAccess.force(ScopedMemoryAccess.java:305)
>        at java.base/jdk.internal.foreign.MappedMemorySegmentImpl.force(MappedMemorySegmentImpl.java:92)
>        at TestByteBuffer.testMappedSegmentAsByteBuffer(TestByteBuffer.java:327)
> 
> (we see this for example on AIX); there is some room for improvement, at least the info should be added that msync failed and caused this exception.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  Change comments and madvise exception text

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14054/files
  - new: https://git.openjdk.org/jdk/pull/14054/files/5e800075..7b9ecc22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14054&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14054&range=00-01

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14054.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14054/head:pull/14054

PR: https://git.openjdk.org/jdk/pull/14054

From mbaesken at openjdk.org  Fri May 19 09:47:47 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 19 May 2023 09:47:47 GMT
Subject: RFR: JDK-8308300: enhance exceptions in MappedMemoryUtils.c
In-Reply-To: <HAdmPxpkTj9Xzd-xBZxvAaSDLInLorEi-UvcxygEiUs=.84a938a8-a0c8-4271-a88b-7ffd4356c366@github.com>
References: <HAdmPxpkTj9Xzd-xBZxvAaSDLInLorEi-UvcxygEiUs=.84a938a8-a0c8-4271-a88b-7ffd4356c366@github.com>
Message-ID: <WBKXtLtEYWuM8uBtLShv8Yva1pZU--7S7tdW2aF_n54=.0e405ebe-f06b-4ced-a339-383408791a73@github.com>

On Fri, 19 May 2023 06:58:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> MappedMemoryUtils.c can generate exceptions like those :
> java.io.UncheckedIOException: java.io.IOException: Invalid argument
>        at java.base/java.nio.MappedMemoryUtils.force(MappedMemoryUtils.java:105)
>        at java.base/java.nio.Buffer$2.force(Buffer.java:890)
>        at java.base/jdk.internal.misc.ScopedMemoryAccess.forceInternal(ScopedMemoryAccess.java:317)
>        at java.base/jdk.internal.misc.ScopedMemoryAccess.force(ScopedMemoryAccess.java:305)
>        at java.base/jdk.internal.foreign.MappedMemorySegmentImpl.force(MappedMemorySegmentImpl.java:92)
>        at TestByteBuffer.testMappedSegmentAsByteBuffer(TestByteBuffer.java:327)
> 
> (we see this for example on AIX); there is some room for improvement, at least the info should be added that msync failed and caused this exception.

Hi Alan, thanks for the comments.
I changed the exception texts regarding madvise and adjusted the Java-comments

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14054#issuecomment-1554314469

From alanb at openjdk.org  Fri May 19 09:54:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 09:54:49 GMT
Subject: RFR: JDK-8308300: enhance exceptions in MappedMemoryUtils.c [v2]
In-Reply-To: <zNA2bmDcgM9kUctXeiyjOlOEylP2wMc_tfygDeuKOqo=.4f2a4299-8a7b-4793-989b-e5c2c65f5ab3@github.com>
References: <HAdmPxpkTj9Xzd-xBZxvAaSDLInLorEi-UvcxygEiUs=.84a938a8-a0c8-4271-a88b-7ffd4356c366@github.com>
 <zNA2bmDcgM9kUctXeiyjOlOEylP2wMc_tfygDeuKOqo=.4f2a4299-8a7b-4793-989b-e5c2c65f5ab3@github.com>
Message-ID: <uzD0FRYQwJBmv_DZovKevngbRpB7vE0JiOfwl4M_Vt4=.3a46dc98-10ab-4926-98b3-52ddaf5b4608@github.com>

On Fri, 19 May 2023 09:46:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> MappedMemoryUtils.c can generate exceptions like those :
>> java.io.UncheckedIOException: java.io.IOException: Invalid argument
>>        at java.base/java.nio.MappedMemoryUtils.force(MappedMemoryUtils.java:105)
>>        at java.base/java.nio.Buffer$2.force(Buffer.java:890)
>>        at java.base/jdk.internal.misc.ScopedMemoryAccess.forceInternal(ScopedMemoryAccess.java:317)
>>        at java.base/jdk.internal.misc.ScopedMemoryAccess.force(ScopedMemoryAccess.java:305)
>>        at java.base/jdk.internal.foreign.MappedMemorySegmentImpl.force(MappedMemorySegmentImpl.java:92)
>>        at TestByteBuffer.testMappedSegmentAsByteBuffer(TestByteBuffer.java:327)
>> 
>> (we see this for example on AIX); there is some room for improvement, at least the info should be added that msync failed and caused this exception.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change comments and madvise exception text

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14054#pullrequestreview-1434127237

From mcimadamore at openjdk.org  Fri May 19 10:06:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 19 May 2023 10:06:53 GMT
Subject: RFR: 8308248: Revisit alignment of layout constants on 32-bit
 platforms [v5]
In-Reply-To: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
References: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
Message-ID: <GYcm5JWPI-ADV9Lz0Cg2-eDPn_mRGZ8S6nEJNws5ajo=.fae4c8ce-1f28-4b92-896c-9e0f62605ea8@github.com>

> The FFM API exposes layout constants for Java primitives. Among those there are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of these layouts is set the same as their size (e.g. 8 bytes).
> 
> This is obviously correct on 64-bit platforms, but on 32-bit platform it is not, as such platforms cannot guarantee that doubles and longs will be always 64-bit aligned. This will also result in problems when trying to use e.g. `JAVA_DOUBLE` to model a C double for the linker API on 32-bit platforms.
> 
> For these reasons, it would be preferable to define the alignment of `JAVA_LONG` and `JAVA_DOUBLE` constants as `ADDRESS.byteSize()`. 
> 
> This patch rectifies alignment of those layout constants to reflect platform-dependent constraints. It also fixes the maximum alignment constraint supported by heap segments, so that it is 4 for long[] and double[] on 32-bit platforms.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix tests for x86

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14007/files
  - new: https://git.openjdk.org/jdk/pull/14007/files/19ae22a1..53db756e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14007&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14007&range=03-04

  Stats: 29 lines in 2 files changed: 11 ins; 7 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/14007.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14007/head:pull/14007

PR: https://git.openjdk.org/jdk/pull/14007

From jiefu at openjdk.org  Fri May 19 10:08:53 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 19 May 2023 10:08:53 GMT
Subject: RFR: 8308408: Build failure with -Werror=maybe-uninitialized in
 libjli/java.c with GCC8
Message-ID: <F-wZCZtdCQ9YFlaIohbA-aINa7iakWa7V42hAKCLv3g=.3d21e2de-7d01-4bd0-b6a7-995f5045ab81@github.com>

May I get review for this change which fixes the build broken with GCC8?
Thanks.

-------------

Commit messages:
 - 8308408: Build failure with -Werror=maybe-uninitialized in libjli/java.c with GCC8

Changes: https://git.openjdk.org/jdk/pull/14057/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14057&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308408
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14057.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14057/head:pull/14057

PR: https://git.openjdk.org/jdk/pull/14057

From alanb at openjdk.org  Fri May 19 10:15:48 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 10:15:48 GMT
Subject: RFR: 8308408: Build failure with -Werror=maybe-uninitialized in
 libjli/java.c with GCC8
In-Reply-To: <F-wZCZtdCQ9YFlaIohbA-aINa7iakWa7V42hAKCLv3g=.3d21e2de-7d01-4bd0-b6a7-995f5045ab81@github.com>
References: <F-wZCZtdCQ9YFlaIohbA-aINa7iakWa7V42hAKCLv3g=.3d21e2de-7d01-4bd0-b6a7-995f5045ab81@github.com>
Message-ID: <49L8iGt-5ZIjZCn7s6bBzmZcbzyYwXDE_hPDytykMBQ=.cc39c7e8-fe2a-4105-a407-035f43ccdb16@github.com>

On Fri, 19 May 2023 10:02:04 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> May I get review for this change which fixes the build broken with GCC8?
> Thanks.

This looks okay

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14057#pullrequestreview-1434156403

From clanger at openjdk.org  Fri May 19 10:37:51 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 19 May 2023 10:37:51 GMT
Subject: RFR: JDK-8308300: enhance exceptions in MappedMemoryUtils.c [v2]
In-Reply-To: <zNA2bmDcgM9kUctXeiyjOlOEylP2wMc_tfygDeuKOqo=.4f2a4299-8a7b-4793-989b-e5c2c65f5ab3@github.com>
References: <HAdmPxpkTj9Xzd-xBZxvAaSDLInLorEi-UvcxygEiUs=.84a938a8-a0c8-4271-a88b-7ffd4356c366@github.com>
 <zNA2bmDcgM9kUctXeiyjOlOEylP2wMc_tfygDeuKOqo=.4f2a4299-8a7b-4793-989b-e5c2c65f5ab3@github.com>
Message-ID: <n8e78xyFC044GObuKcAI0hYyR9JQWjygN1ut2Ch-g18=.d674d1f4-e5d9-4aea-a00e-45dcd0d3b47d@github.com>

On Fri, 19 May 2023 09:46:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> MappedMemoryUtils.c can generate exceptions like those :
>> java.io.UncheckedIOException: java.io.IOException: Invalid argument
>>        at java.base/java.nio.MappedMemoryUtils.force(MappedMemoryUtils.java:105)
>>        at java.base/java.nio.Buffer$2.force(Buffer.java:890)
>>        at java.base/jdk.internal.misc.ScopedMemoryAccess.forceInternal(ScopedMemoryAccess.java:317)
>>        at java.base/jdk.internal.misc.ScopedMemoryAccess.force(ScopedMemoryAccess.java:305)
>>        at java.base/jdk.internal.foreign.MappedMemorySegmentImpl.force(MappedMemorySegmentImpl.java:92)
>>        at TestByteBuffer.testMappedSegmentAsByteBuffer(TestByteBuffer.java:327)
>> 
>> (we see this for example on AIX); there is some room for improvement, at least the info should be added that msync failed and caused this exception.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change comments and madvise exception text

Marked as reviewed by clanger (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14054#pullrequestreview-1434195594

From jiefu at openjdk.org  Fri May 19 10:46:50 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 19 May 2023 10:46:50 GMT
Subject: RFR: 8308408: Build failure with -Werror=maybe-uninitialized in
 libjli/java.c with GCC8
In-Reply-To: <49L8iGt-5ZIjZCn7s6bBzmZcbzyYwXDE_hPDytykMBQ=.cc39c7e8-fe2a-4105-a407-035f43ccdb16@github.com>
References: <F-wZCZtdCQ9YFlaIohbA-aINa7iakWa7V42hAKCLv3g=.3d21e2de-7d01-4bd0-b6a7-995f5045ab81@github.com>
 <49L8iGt-5ZIjZCn7s6bBzmZcbzyYwXDE_hPDytykMBQ=.cc39c7e8-fe2a-4105-a407-035f43ccdb16@github.com>
Message-ID: <B0j6rG6uJ4yTLp6Q1yMAIkuYjHkoYq6hrfjBCdzwCdE=.b4376be2-2e22-42cd-9ca1-2d28a4da14b4@github.com>

On Fri, 19 May 2023 10:12:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This looks okay

Thanks @AlanBateman for your quick review.

May I push it now since it's a build breakage?
Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14057#issuecomment-1554383346

From mbaesken at openjdk.org  Fri May 19 10:46:51 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 19 May 2023 10:46:51 GMT
Subject: RFR: JDK-8308300: enhance exceptions in MappedMemoryUtils.c [v2]
In-Reply-To: <zNA2bmDcgM9kUctXeiyjOlOEylP2wMc_tfygDeuKOqo=.4f2a4299-8a7b-4793-989b-e5c2c65f5ab3@github.com>
References: <HAdmPxpkTj9Xzd-xBZxvAaSDLInLorEi-UvcxygEiUs=.84a938a8-a0c8-4271-a88b-7ffd4356c366@github.com>
 <zNA2bmDcgM9kUctXeiyjOlOEylP2wMc_tfygDeuKOqo=.4f2a4299-8a7b-4793-989b-e5c2c65f5ab3@github.com>
Message-ID: <kjLIzcRjtdsh9toUJ6pn8qIPvuB2y8MCuIUDqEGO9FE=.2e95c132-a706-49dd-a70c-6a7130f3cade@github.com>

On Fri, 19 May 2023 09:46:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> MappedMemoryUtils.c can generate exceptions like those :
>> java.io.UncheckedIOException: java.io.IOException: Invalid argument
>>        at java.base/java.nio.MappedMemoryUtils.force(MappedMemoryUtils.java:105)
>>        at java.base/java.nio.Buffer$2.force(Buffer.java:890)
>>        at java.base/jdk.internal.misc.ScopedMemoryAccess.forceInternal(ScopedMemoryAccess.java:317)
>>        at java.base/jdk.internal.misc.ScopedMemoryAccess.force(ScopedMemoryAccess.java:305)
>>        at java.base/jdk.internal.foreign.MappedMemorySegmentImpl.force(MappedMemorySegmentImpl.java:92)
>>        at TestByteBuffer.testMappedSegmentAsByteBuffer(TestByteBuffer.java:327)
>> 
>> (we see this for example on AIX); there is some room for improvement, at least the info should be added that msync failed and caused this exception.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change comments and madvise exception text

Hi Alan and Christoph, thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14054#issuecomment-1554384092

From alanb at openjdk.org  Fri May 19 10:53:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 10:53:49 GMT
Subject: RFR: 8308408: Build failure with -Werror=maybe-uninitialized in
 libjli/java.c with GCC8
In-Reply-To: <B0j6rG6uJ4yTLp6Q1yMAIkuYjHkoYq6hrfjBCdzwCdE=.b4376be2-2e22-42cd-9ca1-2d28a4da14b4@github.com>
References: <F-wZCZtdCQ9YFlaIohbA-aINa7iakWa7V42hAKCLv3g=.3d21e2de-7d01-4bd0-b6a7-995f5045ab81@github.com>
 <49L8iGt-5ZIjZCn7s6bBzmZcbzyYwXDE_hPDytykMBQ=.cc39c7e8-fe2a-4105-a407-035f43ccdb16@github.com>
 <B0j6rG6uJ4yTLp6Q1yMAIkuYjHkoYq6hrfjBCdzwCdE=.b4376be2-2e22-42cd-9ca1-2d28a4da14b4@github.com>
Message-ID: <zAuvpMh9VxPkCgp75W7dXgedHakbXGN-633aSoLDoeM=.e3fabd41-3946-4364-8257-596a79141690@github.com>

On Fri, 19 May 2023 10:44:02 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> May I push it now since it's a build breakage? Thanks.

Yes, the change is trivial so please go ahead.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14057#issuecomment-1554390879

From mcimadamore at openjdk.org  Fri May 19 11:08:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 19 May 2023 11:08:10 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v3]
In-Reply-To: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
Message-ID: <Js67F4k4vce7aJj1IaxhDV3Ny6NEVF4fD8OA85KloB8=.26bae93a-c26e-44d8-a158-8789f77ef58d@github.com>

> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
> 
> 
> jshell> import java.lang.foreign.*;
> 
> jshell> Linker.nativeLinker().canonicalLayouts()
> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
> 
> 
> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Address review comments
 - More javadoc tweaks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14037/files
  - new: https://git.openjdk.org/jdk/pull/14037/files/955241f9..df92467c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14037&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14037&range=01-02

  Stats: 62 lines in 3 files changed: 49 ins; 10 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14037.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14037/head:pull/14037

PR: https://git.openjdk.org/jdk/pull/14037

From mcimadamore at openjdk.org  Fri May 19 11:08:11 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 19 May 2023 11:08:11 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v2]
In-Reply-To: <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
Message-ID: <34znF1BROlqZyrCga1eOekb2EwhNBv9Al76V6jZpfco=.dabb5cea-9fd6-4ca7-9503-35ad7967fff2@github.com>

On Wed, 17 May 2023 18:18:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak javadoc

I've addressed the comments and tweaked the javadoc. Now we list all the C types that a linker is guaranteed to support (and state that the canonical layout associated with those types can vary depending on data model). Then we roll in the usual/more concrete table for Linux/x64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1554405281

From mcimadamore at openjdk.org  Fri May 19 11:08:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 19 May 2023 11:08:33 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v2]
In-Reply-To: <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <AA7BMeDz2cVc5iOhfjpTqnaNTsRTepRWPrNurjZR-_U=.4514e303-2c3f-48bf-96cc-ea16dfb43b4c@github.com>
Message-ID: <JH3PshScovWLcVa_ob5LwAd0EVA4ucR9pou_bEWgxPo=.01ad46b1-af4d-45a9-be37-36b0e6ee4a21@github.com>

On Wed, 17 May 2023 18:18:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak javadoc

Updated javadoc and specdiffs:
javadoc: https://cr.openjdk.org/~mcimadamore/jdk/8308293/v2/javadoc/java.base/java/lang/foreign/Linker.html
specdiff: https://cr.openjdk.org/~mcimadamore/jdk/8308293/v2/specdiff_out/overview-summary.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1554410079

From jiefu at openjdk.org  Fri May 19 11:17:59 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 19 May 2023 11:17:59 GMT
Subject: Integrated: 8308408: Build failure with -Werror=maybe-uninitialized in
 libjli/java.c with GCC8
In-Reply-To: <F-wZCZtdCQ9YFlaIohbA-aINa7iakWa7V42hAKCLv3g=.3d21e2de-7d01-4bd0-b6a7-995f5045ab81@github.com>
References: <F-wZCZtdCQ9YFlaIohbA-aINa7iakWa7V42hAKCLv3g=.3d21e2de-7d01-4bd0-b6a7-995f5045ab81@github.com>
Message-ID: <KuUCO0PqEyV4NQmAXMrL6y6GDy3K01YTCY0JU8xPa5s=.7d901067-a7d7-43f9-9ba5-2db4d2689213@github.com>

On Fri, 19 May 2023 10:02:04 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> May I get review for this change which fixes the build broken with GCC8?
> Thanks.

This pull request has now been integrated.

Changeset: 690d3969
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/690d3969b80776bf896fbfbfac5eabe7d074c9bb
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8308408: Build failure with -Werror=maybe-uninitialized in libjli/java.c with GCC8

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14057

From jiefu at openjdk.org  Fri May 19 11:17:57 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Fri, 19 May 2023 11:17:57 GMT
Subject: RFR: 8308408: Build failure with -Werror=maybe-uninitialized in
 libjli/java.c with GCC8
In-Reply-To: <zAuvpMh9VxPkCgp75W7dXgedHakbXGN-633aSoLDoeM=.e3fabd41-3946-4364-8257-596a79141690@github.com>
References: <F-wZCZtdCQ9YFlaIohbA-aINa7iakWa7V42hAKCLv3g=.3d21e2de-7d01-4bd0-b6a7-995f5045ab81@github.com>
 <49L8iGt-5ZIjZCn7s6bBzmZcbzyYwXDE_hPDytykMBQ=.cc39c7e8-fe2a-4105-a407-035f43ccdb16@github.com>
 <B0j6rG6uJ4yTLp6Q1yMAIkuYjHkoYq6hrfjBCdzwCdE=.b4376be2-2e22-42cd-9ca1-2d28a4da14b4@github.com>
 <zAuvpMh9VxPkCgp75W7dXgedHakbXGN-633aSoLDoeM=.e3fabd41-3946-4364-8257-596a79141690@github.com>
Message-ID: <8rA1oQKhc_V-H3OaHZti-xtz1dtbvtxev8NesF2PcSo=.44d2c57b-d1a6-4efc-b461-e983ce75de5e@github.com>

On Fri, 19 May 2023 10:50:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > May I push it now since it's a build breakage? Thanks.
> 
> Yes, the change is trivial so please go ahead.

Thanks @AlanBateman .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14057#issuecomment-1554418471

From michaelm at openjdk.org  Fri May 19 11:26:52 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 19 May 2023 11:26:52 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <MIanutU-5zaHU08XWWykYRu2HSZhUfGSr70gu9SZ2ug=.77440635-04f7-4cbe-b573-a2322fed985b@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

Seems like a useful change and I can see how issues could arise if strings were stored somewhere after being upper/lower cased and then reused in a different locale. 

Is it correct to say that the assumption is these strings are all supposed to be US ASCII (eg protocol defined identifiers, or hostnames etc) rather than user generated text strings? That seems to be the case as far as I can see.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14006#issuecomment-1554431858

From pminborg at openjdk.org  Fri May 19 11:33:49 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 19 May 2023 11:33:49 GMT
Subject: RFR: 8308248: Revisit alignment of layout constants on 32-bit
 platforms [v5]
In-Reply-To: <GYcm5JWPI-ADV9Lz0Cg2-eDPn_mRGZ8S6nEJNws5ajo=.fae4c8ce-1f28-4b92-896c-9e0f62605ea8@github.com>
References: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
 <GYcm5JWPI-ADV9Lz0Cg2-eDPn_mRGZ8S6nEJNws5ajo=.fae4c8ce-1f28-4b92-896c-9e0f62605ea8@github.com>
Message-ID: <yg1QXl5DBrvRwtl0rkvN1nEreDEJeKJroKhFkUvamXs=.e4a73a0c-8909-42ae-9e40-33c8ab657ad7@github.com>

On Fri, 19 May 2023 10:06:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The FFM API exposes layout constants for Java primitives. Among those there are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of these layouts is set the same as their size (e.g. 8 bytes).
>> 
>> This is obviously correct on 64-bit platforms, but on 32-bit platform it is not, as such platforms cannot guarantee that doubles and longs will be always 64-bit aligned. This will also result in problems when trying to use e.g. `JAVA_DOUBLE` to model a C double for the linker API on 32-bit platforms.
>> 
>> For these reasons, it would be preferable to define the alignment of `JAVA_LONG` and `JAVA_DOUBLE` constants as `ADDRESS.byteSize()`. 
>> 
>> This patch rectifies alignment of those layout constants to reflect platform-dependent constraints. It also fixes the maximum alignment constraint supported by heap segments, so that it is 4 for long[] and double[] on 32-bit platforms.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix tests for x86

Marked as reviewed by pminborg (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14007#pullrequestreview-1434264181

From michaelm at openjdk.org  Fri May 19 11:45:50 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 19 May 2023 11:45:50 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
Message-ID: <lVPhG5xf1OqkUt02UdnjCSXVoF-H4KW_PGfrKQJ-Tto=.3980eaab-78e7-4ee4-8a62-6925757d9f9f@github.com>

On Wed, 17 May 2023 13:53:55 GMT, Darragh Clarke <duke at openjdk.org> wrote:

>> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
>> 
>> I didn't add any new tests but ran tier 1-3 with no issues
>
> Darragh Clarke has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update src/java.base/share/classes/sun/net/www/protocol/http/DigestAuthentication.java
>    
>    Co-authored-by: Daniel Jelinski <djelinski1 at gmail.com>
>  - removed StreamTokenizer changes, will make seperate ticket for those

Marked as reviewed by michaelm (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14006#pullrequestreview-1434277855

From asotona at openjdk.org  Fri May 19 12:23:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 19 May 2023 12:23:57 GMT
Subject: RFR: 8308410: broken compilation of
 test\jdk\tools\launcher\exeJliLaunchTest.c
Message-ID: <MRVH7vOkLOTd9DgkVv5LVHxNQvWj9qPjThIzlopnNZ0=.f13718f5-c0b6-4634-9979-0fd64993fed0@github.com>

JDK-8303669 patch to test\jdk\tools\launcher\exeJliLaunchTest.c broke compilation on windows.
Unfortunately MSVC does not support variable length arrays.
This patch fixes test\jdk\tools\launcher\exeJliLaunchTest.c to use dynamic array allocation.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8308410: broken compilation of test\jdk\tools\launcher\exeJliLaunchTest.c

Changes: https://git.openjdk.org/jdk/pull/14060/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14060&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308410
  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14060.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14060/head:pull/14060

PR: https://git.openjdk.org/jdk/pull/14060

From alanb at openjdk.org  Fri May 19 12:38:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 12:38:49 GMT
Subject: RFR: 8308410: broken compilation of
 test\jdk\tools\launcher\exeJliLaunchTest.c
In-Reply-To: <MRVH7vOkLOTd9DgkVv5LVHxNQvWj9qPjThIzlopnNZ0=.f13718f5-c0b6-4634-9979-0fd64993fed0@github.com>
References: <MRVH7vOkLOTd9DgkVv5LVHxNQvWj9qPjThIzlopnNZ0=.f13718f5-c0b6-4634-9979-0fd64993fed0@github.com>
Message-ID: <m8MhoUhdqChV0-NCFpGAdoSv-gNmhP_NTU-aLw3HxN0=.afffdde1-aad4-4927-be37-3abb2be45a9e@github.com>

On Fri, 19 May 2023 12:08:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> JDK-8303669 patch to test\jdk\tools\launcher\exeJliLaunchTest.c broke compilation on windows.
> Unfortunately MSVC does not support variable length arrays.
> This patch fixes test\jdk\tools\launcher\exeJliLaunchTest.c to use dynamic array allocation.
> 
> Please review.
> 
> Thanks,
> Adam

test/jdk/tools/launcher/exeJliLaunchTest.c line 39:

> 37: {
> 38:     //avoid null-terminated array of arguments to test JDK-8303669
> 39:     char **argv = malloc(sizeof(char *) * argc);

If this is building on all platforms then okay but I would have expected you'd need a cast here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14060#discussion_r1198910081

From jlahoda at openjdk.org  Fri May 19 12:42:22 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 19 May 2023 12:42:22 GMT
Subject: RFR: 8300543 Compiler Implementation for Pattern Matching for
 switch [v12]
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <dJ_GmL3sg48JA0dRYd8vmmO9BADligcbTu08iWkSJ3Y=.0ebc6510-9272-4177-8f8a-8c4030037f0a@github.com>

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Removing obsolette test, as suggested.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13074/files
  - new: https://git.openjdk.org/jdk/pull/13074/files/924ca58d..b641efca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13074&range=10-11

  Stats: 54 lines in 2 files changed: 0 ins; 54 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13074.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13074/head:pull/13074

PR: https://git.openjdk.org/jdk/pull/13074

From asotona at openjdk.org  Fri May 19 13:06:49 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 19 May 2023 13:06:49 GMT
Subject: RFR: 8308410: broken compilation of
 test\jdk\tools\launcher\exeJliLaunchTest.c
In-Reply-To: <m8MhoUhdqChV0-NCFpGAdoSv-gNmhP_NTU-aLw3HxN0=.afffdde1-aad4-4927-be37-3abb2be45a9e@github.com>
References: <MRVH7vOkLOTd9DgkVv5LVHxNQvWj9qPjThIzlopnNZ0=.f13718f5-c0b6-4634-9979-0fd64993fed0@github.com>
 <m8MhoUhdqChV0-NCFpGAdoSv-gNmhP_NTU-aLw3HxN0=.afffdde1-aad4-4927-be37-3abb2be45a9e@github.com>
Message-ID: <4JaWgWcjgeZ9DAsfC_gjWwGt2A9Cc-Gikgg6Vlb_eRE=.5200f457-ccbd-4029-bf86-c9ecf2c1d465@github.com>

On Fri, 19 May 2023 12:35:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> JDK-8303669 patch to test\jdk\tools\launcher\exeJliLaunchTest.c broke compilation on windows.
>> Unfortunately MSVC does not support variable length arrays.
>> This patch fixes test\jdk\tools\launcher\exeJliLaunchTest.c to use dynamic array allocation.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> test/jdk/tools/launcher/exeJliLaunchTest.c line 39:
> 
>> 37: {
>> 38:     //avoid null-terminated array of arguments to test JDK-8303669
>> 39:     char **argv = malloc(sizeof(char *) * argc);
> 
> If this is building on all platforms then okay but I would have expected you'd need a cast here.

I've learned that there are completely opposite rules for C and C++.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14060#discussion_r1198933225

From asotona at openjdk.org  Fri May 19 13:06:50 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 19 May 2023 13:06:50 GMT
Subject: RFR: 8308410: broken compilation of
 test\jdk\tools\launcher\exeJliLaunchTest.c
In-Reply-To: <4JaWgWcjgeZ9DAsfC_gjWwGt2A9Cc-Gikgg6Vlb_eRE=.5200f457-ccbd-4029-bf86-c9ecf2c1d465@github.com>
References: <MRVH7vOkLOTd9DgkVv5LVHxNQvWj9qPjThIzlopnNZ0=.f13718f5-c0b6-4634-9979-0fd64993fed0@github.com>
 <m8MhoUhdqChV0-NCFpGAdoSv-gNmhP_NTU-aLw3HxN0=.afffdde1-aad4-4927-be37-3abb2be45a9e@github.com>
 <4JaWgWcjgeZ9DAsfC_gjWwGt2A9Cc-Gikgg6Vlb_eRE=.5200f457-ccbd-4029-bf86-c9ecf2c1d465@github.com>
Message-ID: <cJRdyna_9P6M8y0er-SNtujKfKwX-IdNLrin-JSsAEc=.cd403548-22a9-4bf0-acba-99574287658a@github.com>

On Fri, 19 May 2023 13:01:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> test/jdk/tools/launcher/exeJliLaunchTest.c line 39:
>> 
>>> 37: {
>>> 38:     //avoid null-terminated array of arguments to test JDK-8303669
>>> 39:     char **argv = malloc(sizeof(char *) * argc);
>> 
>> If this is building on all platforms then okay but I would have expected you'd need a cast here.
>
> I've learned that there are completely opposite rules for C and C++.

Tier1 tests just passed on all platforms.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14060#discussion_r1198935073

From asotona at openjdk.org  Fri May 19 13:15:04 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 19 May 2023 13:15:04 GMT
Subject: Integrated: 8308410: broken compilation of
 test\jdk\tools\launcher\exeJliLaunchTest.c
In-Reply-To: <MRVH7vOkLOTd9DgkVv5LVHxNQvWj9qPjThIzlopnNZ0=.f13718f5-c0b6-4634-9979-0fd64993fed0@github.com>
References: <MRVH7vOkLOTd9DgkVv5LVHxNQvWj9qPjThIzlopnNZ0=.f13718f5-c0b6-4634-9979-0fd64993fed0@github.com>
Message-ID: <Oxv1Vh6eJC-20qwU7e7gQ7HRtAu66sJHHwRbTtecJKE=.3b090dd9-8eea-4454-9fb6-7733dc3ce381@github.com>

On Fri, 19 May 2023 12:08:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> JDK-8303669 patch to test\jdk\tools\launcher\exeJliLaunchTest.c broke compilation on windows.
> Unfortunately MSVC does not support variable length arrays.
> This patch fixes test\jdk\tools\launcher\exeJliLaunchTest.c to use dynamic array allocation.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 80ef5c22
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/80ef5c228b0f8a7a881a333c418a5d3068fe5a6e
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8308410: broken compilation of test\jdk\tools\launcher\exeJliLaunchTest.c

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14060

From alanb at openjdk.org  Fri May 19 13:15:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 13:15:00 GMT
Subject: RFR: 8308410: broken compilation of
 test\jdk\tools\launcher\exeJliLaunchTest.c
In-Reply-To: <MRVH7vOkLOTd9DgkVv5LVHxNQvWj9qPjThIzlopnNZ0=.f13718f5-c0b6-4634-9979-0fd64993fed0@github.com>
References: <MRVH7vOkLOTd9DgkVv5LVHxNQvWj9qPjThIzlopnNZ0=.f13718f5-c0b6-4634-9979-0fd64993fed0@github.com>
Message-ID: <CWkbqowmQQ5wn85dhBTwSt0xdNaRZlwLXgvz5gMvFGE=.b0d7d6b3-6d29-4dbd-9b5d-b8c24610538e@github.com>

On Fri, 19 May 2023 12:08:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> JDK-8303669 patch to test\jdk\tools\launcher\exeJliLaunchTest.c broke compilation on windows.
> Unfortunately MSVC does not support variable length arrays.
> This patch fixes test\jdk\tools\launcher\exeJliLaunchTest.c to use dynamic array allocation.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14060#pullrequestreview-1434394156

From asotona at openjdk.org  Fri May 19 13:15:01 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 19 May 2023 13:15:01 GMT
Subject: RFR: 8308410: broken compilation of
 test\jdk\tools\launcher\exeJliLaunchTest.c
In-Reply-To: <MRVH7vOkLOTd9DgkVv5LVHxNQvWj9qPjThIzlopnNZ0=.f13718f5-c0b6-4634-9979-0fd64993fed0@github.com>
References: <MRVH7vOkLOTd9DgkVv5LVHxNQvWj9qPjThIzlopnNZ0=.f13718f5-c0b6-4634-9979-0fd64993fed0@github.com>
Message-ID: <vCfw5XamIMCOcUQ0MVkdHM_YO713DiRjyahmIo5wGyk=.f661f985-a180-471e-8a15-abee86d04bb8@github.com>

On Fri, 19 May 2023 12:08:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> JDK-8303669 patch to test\jdk\tools\launcher\exeJliLaunchTest.c broke compilation on windows.
> Unfortunately MSVC does not support variable length arrays.
> This patch fixes test\jdk\tools\launcher\exeJliLaunchTest.c to use dynamic array allocation.
> 
> Please review.
> 
> Thanks,
> Adam

Thank you for quick review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14060#issuecomment-1554551187

From alanb at openjdk.org  Fri May 19 13:15:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 13:15:03 GMT
Subject: RFR: 8308410: broken compilation of
 test\jdk\tools\launcher\exeJliLaunchTest.c
In-Reply-To: <cJRdyna_9P6M8y0er-SNtujKfKwX-IdNLrin-JSsAEc=.cd403548-22a9-4bf0-acba-99574287658a@github.com>
References: <MRVH7vOkLOTd9DgkVv5LVHxNQvWj9qPjThIzlopnNZ0=.f13718f5-c0b6-4634-9979-0fd64993fed0@github.com>
 <m8MhoUhdqChV0-NCFpGAdoSv-gNmhP_NTU-aLw3HxN0=.afffdde1-aad4-4927-be37-3abb2be45a9e@github.com>
 <4JaWgWcjgeZ9DAsfC_gjWwGt2A9Cc-Gikgg6Vlb_eRE=.5200f457-ccbd-4029-bf86-c9ecf2c1d465@github.com>
 <cJRdyna_9P6M8y0er-SNtujKfKwX-IdNLrin-JSsAEc=.cd403548-22a9-4bf0-acba-99574287658a@github.com>
Message-ID: <ogORaP63wQbOxyc-GKzdTMlWHaryukr_gBhzlUR_Yq8=.9bb9f2ce-cae5-41e4-9e7f-ab200d1ed294@github.com>

On Fri, 19 May 2023 13:03:34 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Tier1 tests just passed on all platforms.

Okay, in that case we should get the change in because there is build breakage right now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14060#discussion_r1198940202

From rrich at openjdk.org  Fri May 19 14:25:06 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Fri, 19 May 2023 14:25:06 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v30]
In-Reply-To: <JI-0Tk2ZN2ZwQO3jhooK5jgqnzHbCJuKMQjSE_TsaCQ=.fc73c920-6107-4c61-8021-072cb58e18b6@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <JI-0Tk2ZN2ZwQO3jhooK5jgqnzHbCJuKMQjSE_TsaCQ=.fc73c920-6107-4c61-8021-072cb58e18b6@github.com>
Message-ID: <bf4m7b8y3H4H8IrJ_SyexNLSZza8RY0sKCS99ikbe4M=.1de7b9d8-56df-4778-9819-174ba24dba17@github.com>

On Wed, 10 May 2023 14:19:43 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separat...
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add NONZERO check for downcall_stub_address_offset_in_bytes().

Hi Martin,
I've made a pass over the Java part (except HFA). I found the specs hard to understand but most specs are like this.
I'll finish the rest beginning of next week.
Cheers, Richard.

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 28:

> 26: package jdk.internal.foreign.abi.ppc64;
> 27: 
> 28: import java.lang.foreign.AddressLayout;

Imports are not grouped and ordered alphabetically.
(Very much as the aarch64 version)

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 73:

> 71:     public static final int MAX_FLOAT_REGISTER_ARGUMENTS = 13;
> 72: 
> 73:     // This is derived from the 64-Bit ELF V2 ABI spec, restricted to what's

The comment says ABI V2 but the code seems to handle V1 too.

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 158:

> 156:     class StorageCalculator {
> 157:         private final boolean forArguments;
> 158:         private boolean forVarArgs = false;

Seems to be not used.

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 221:

> 219:             // !useABIv2() && layout.byteSize() > 8 && layout.byteSize() % 8 != 0
> 220: 
> 221:             // Allocate individual fields as gp slots (regs and stack).

You explained to me, it's not individual (struct) fields that are handled here. Looks like registers and 8 byte stack slots are allocated to completely cover the struct. Would be good if you could change the comment and names in the code to better reflect this.

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64leLinker.java line 41:

> 39: 
> 40:     public static LinuxPPC64leLinker getInstance() {
> 41:         if (instance == null) {

Other platforms optimized this to return a constant (probably after you forked off the port).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12708#pullrequestreview-1428763014
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1195280060
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1195344452
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1195363380
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1198915617
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1199011136

From mcimadamore at openjdk.org  Fri May 19 14:31:01 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 19 May 2023 14:31:01 GMT
Subject: Integrated: 8308248: Revisit alignment of layout constants on 32-bit
 platforms
In-Reply-To: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
References: <8lufHecEJ93w4drm20HJRo0NIMlJJsoG22sLr1X8ApU=.7f655400-35cb-4bbb-bdd5-16f0a0a13c1e@github.com>
Message-ID: <HNA0QPlknU0fJmVeii9xshMjLEM0smLcrlcgDpUIh-s=.13127117-66e7-4e3e-94df-8ffc11ab39d3@github.com>

On Tue, 16 May 2023 11:18:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The FFM API exposes layout constants for Java primitives. Among those there are constants for `JAVA_LONG` and `JAVA_DOUBLE`. Currently, the alignment of these layouts is set the same as their size (e.g. 8 bytes).
> 
> This is obviously correct on 64-bit platforms, but on 32-bit platform it is not, as such platforms cannot guarantee that doubles and longs will be always 64-bit aligned. This will also result in problems when trying to use e.g. `JAVA_DOUBLE` to model a C double for the linker API on 32-bit platforms.
> 
> For these reasons, it would be preferable to define the alignment of `JAVA_LONG` and `JAVA_DOUBLE` constants as `ADDRESS.byteSize()`. 
> 
> This patch rectifies alignment of those layout constants to reflect platform-dependent constraints. It also fixes the maximum alignment constraint supported by heap segments, so that it is 4 for long[] and double[] on 32-bit platforms.

This pull request has now been integrated.

Changeset: 44218b1c
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/44218b1c9e5daa33557aac9336251cf8398d81eb
Stats:     68 lines in 6 files changed: 29 ins; 6 del; 33 mod

8308248: Revisit alignment of layout constants on 32-bit platforms

Reviewed-by: psandoz, pminborg

-------------

PR: https://git.openjdk.org/jdk/pull/14007

From rriggs at openjdk.org  Fri May 19 15:08:04 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 May 2023 15:08:04 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v4]
In-Reply-To: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
Message-ID: <GhyIjJfg8TfNsPKM0439apYQJr1979z4YtpZpAL3ZcU=.a318da8d-bd9d-4c16-af4d-98a3c65be9aa@github.com>

> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
> 
> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
> Mac OS X 10.15 is the oldest version supported.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Revert "The OperatingSystem enum treats AIX separately from Linux."  AIX is NOT an alias for Linux.
  This reverts commit 802456d52a3c85a2abd8830ea80147b212d2a5b0.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13586/files
  - new: https://git.openjdk.org/jdk/pull/13586/files/64ab7126..d40a07d6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13586&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13586&range=02-03

  Stats: 10 lines in 8 files changed: 0 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13586.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13586/head:pull/13586

PR: https://git.openjdk.org/jdk/pull/13586

From rriggs at openjdk.org  Fri May 19 15:37:01 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 May 2023 15:37:01 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v3]
In-Reply-To: <i78YmYkmZ6r0Y7cuZLGQyMx_TiiMgZDyaFAjmVkyLOw=.b9a1a3b7-ff6c-4739-baa3-fe9013de7009@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
 <KHzI2hrflmstmSodbBnNuNbnzbvG-sNBDrWl9hk2xbo=.d77e8ca6-7de5-452d-89b5-fa9343f428b8@github.com>
 <qLLFp-vK0czoK2jeaC3B1m15VGAieStLa-FDEtdamVY=.0027bcd7-8d59-4a23-9328-5e834ceeb4f9@github.com>
 <i78YmYkmZ6r0Y7cuZLGQyMx_TiiMgZDyaFAjmVkyLOw=.b9a1a3b7-ff6c-4739-baa3-fe9013de7009@github.com>
Message-ID: <HIEKBS1-m1uEO-4CIjEHvt3vHSZivbNDFNKYpQncJzg=.9d04ddf0-85f6-46c6-ac47-1f860e2572b3@github.com>

On Thu, 18 May 2023 21:33:53 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> > did we test jpackage on AIX system?
> 
> I don't think so. What is the native packaging on this platform?

To the best of my knowledge, AIX uses `installp` and `rpm`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13586#issuecomment-1554761233

From bpb at openjdk.org  Fri May 19 15:42:50 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 May 2023 15:42:50 GMT
Subject: RFR: JDK-8308300: enhance exceptions in MappedMemoryUtils.c [v2]
In-Reply-To: <zNA2bmDcgM9kUctXeiyjOlOEylP2wMc_tfygDeuKOqo=.4f2a4299-8a7b-4793-989b-e5c2c65f5ab3@github.com>
References: <HAdmPxpkTj9Xzd-xBZxvAaSDLInLorEi-UvcxygEiUs=.84a938a8-a0c8-4271-a88b-7ffd4356c366@github.com>
 <zNA2bmDcgM9kUctXeiyjOlOEylP2wMc_tfygDeuKOqo=.4f2a4299-8a7b-4793-989b-e5c2c65f5ab3@github.com>
Message-ID: <vTmN04oK4fSXpexOEJNcAEnQN0Ce6PNtDbkhGnmlF5I=.85767f81-56aa-4899-af73-13f638bf25f8@github.com>

On Fri, 19 May 2023 09:46:59 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> MappedMemoryUtils.c can generate exceptions like those :
>> java.io.UncheckedIOException: java.io.IOException: Invalid argument
>>        at java.base/java.nio.MappedMemoryUtils.force(MappedMemoryUtils.java:105)
>>        at java.base/java.nio.Buffer$2.force(Buffer.java:890)
>>        at java.base/jdk.internal.misc.ScopedMemoryAccess.forceInternal(ScopedMemoryAccess.java:317)
>>        at java.base/jdk.internal.misc.ScopedMemoryAccess.force(ScopedMemoryAccess.java:305)
>>        at java.base/jdk.internal.foreign.MappedMemorySegmentImpl.force(MappedMemorySegmentImpl.java:92)
>>        at TestByteBuffer.testMappedSegmentAsByteBuffer(TestByteBuffer.java:327)
>> 
>> (we see this for example on AIX); there is some room for improvement, at least the info should be added that msync failed and caused this exception.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change comments and madvise exception text

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14054#pullrequestreview-1434661119

From rriggs at openjdk.org  Fri May 19 15:45:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 May 2023 15:45:55 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <Q1qJR_GJWPvAItv1fmJu-QYM0g5ozWkWd2ljkAy7VQ8=.3a657b07-464d-4184-a667-a3f9a7c9c72a@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>
 <WNS9AUc4Uo0uJT7Q-c5WmRQGPXKHOiQ5bk3FAVhcpTw=.7b192c55-1a39-48bf-9c36-eb8219474c4f@github.com>
 <u7bSYYuppXZ1z347-wRTJf9GoxNUW-GoWfSn4dmCLEE=.831249e0-e538-491c-8001-a7dd55673721@github.com>
 <yZM9iro4FRdHveBRx07oeItZ9_CmQJ4wksNo3XI8Igs=.7b2097d5-0852-4f04-9c14-fc8d39a57c08@github.com>
 <qh4P0rQhdigeWLoD9paOaTJgT7uXOU0IsBTQlFdZ3Ew=.1eb8ea15-2d10-45e3-b883-87b088e220ba@github.com>
 <Q1qJR_GJWPvAItv1fmJu-QYM0g5ozWkWd2ljkAy7VQ8=.3a657b07-464d-4184-a667-a3f9a7c9c72a@github.com>
Message-ID: <61e5pVShTICWmDodgIDEACwz-NJB6OMUOw2crLQ2zTE=.2fc8ed80-5979-45c1-8797-ac2a8b47157e@github.com>

On Fri, 19 May 2023 06:28:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > Sorry, but I don't understand this argument. If we do a short read we will work with corrupted ChildStuff and SpawnInfo
> > structures. This can in the extreme case execute arbitrary code (e.g. if ChildStuff.argv is not fully read from the parent). You are
> > basically saying it is better to work on corrupted data rather than reporting an error.
> 
> No I am simply pointing out that this has changed more than just the issue with close. And maybe a short-read does indicate data "corruption" and maybe it should be a fatal error. But I don't know exactly how this might manifest so perhaps there are benign short-reads that actually do happen. Regardless it might be better to split this part out and focus on the close issue here.

Given the purpose and implementation of the `readFully` function, I don't see how it can return anything other than an error or the full requested read length.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1554772268

From naoto at openjdk.org  Fri May 19 16:46:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 May 2023 16:46:55 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v3]
In-Reply-To: <hif0_x1Xsly3QcpMBMxoD69Yc5IX2G6aZvATHgQBYOw=.43b003ac-4d64-4764-862a-22a8cc675b46@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
 <hif0_x1Xsly3QcpMBMxoD69Yc5IX2G6aZvATHgQBYOw=.43b003ac-4d64-4764-862a-22a8cc675b46@github.com>
Message-ID: <X0aaL2rnAUGysmk2250BMQLHeG3lyJOZQlPFWZ0Hwcg=.e177be42-6827-4018-8d4e-f27aeb1c7ef3@github.com>

On Fri, 19 May 2023 07:59:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a table for possible BCP47 values and their mappings
>
> src/java.base/share/classes/java/text/Collator.java line 264:
> 
>> 262:      * </table>
>> 263:      * If the specified setting value is not recognized, strength and/or
>> 264:      * decomposition will not be overridden.
> 
> The proposed update looks okay except for the last part "If the specified setting value is not recognized, strength and/or decomposition will not be overridden". I thin this could be clearer.
> If I understand correctly, if the Unicode locale type for the given Locale might have a strength level and decomposition mode and this method makes a best effort to return a Collator with the expected level and mode. If so, then I think the javadoc needs to make this a bit clearer. Also, if the factory method returns a Collator that doesn't do what I asked, can I call setStrength/setDecomposition to change it?

I don't think there is any chance that the factory method returns a Collator that fails to meet the settings in the locale, because setStrength()/setDecompositon() with valid values never fail. So the returned instance will always have the requested strength/decomposition. Does this answer your question?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14040#discussion_r1199167454

From jlahoda at openjdk.org  Fri May 19 16:48:59 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 19 May 2023 16:48:59 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v2]
In-Reply-To: <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
Message-ID: <lqXa5JPcH8eyVSHE5vwq5ElGvG2SdWG4ixp23v1xojY=.8851f9d6-86b2-4562-9b3f-018027313ed9@github.com>

On Tue, 17 Jan 2023 15:55:40 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.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Adding comments
>  - Improving performance
>  - Merge branch 'master' into JDK-8291966
>  - 8291966: SwitchBootstrap.typeSwitch could be faster

FWIW, @liach, thanks for the comments. I've decided to wait for PR #13074 to be done. After that, I'll update this patch to it, and reflect your comments. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9779#issuecomment-1554878491

From alanb at openjdk.org  Fri May 19 17:14:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 17:14:51 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v3]
In-Reply-To: <X0aaL2rnAUGysmk2250BMQLHeG3lyJOZQlPFWZ0Hwcg=.e177be42-6827-4018-8d4e-f27aeb1c7ef3@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
 <hif0_x1Xsly3QcpMBMxoD69Yc5IX2G6aZvATHgQBYOw=.43b003ac-4d64-4764-862a-22a8cc675b46@github.com>
 <X0aaL2rnAUGysmk2250BMQLHeG3lyJOZQlPFWZ0Hwcg=.e177be42-6827-4018-8d4e-f27aeb1c7ef3@github.com>
Message-ID: <jPdpWcGFCqT_sU_dBhfkMIK9t5J-B-a8TJJH9BMcPss=.c282c784-c798-43f7-af8d-1e400380ac68@github.com>

On Fri, 19 May 2023 16:44:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I don't think there is any chance that the factory method returns a Collator that fails to meet the settings in the locale, because setStrength()/setDecompositon() with valid values never fail. So the returned instance will always have the requested strength/decomposition. Does this answer your question?

It's the last sentence that bothers me. I understand the setters can't fail but the last sentence of the proposed text makes it sound like invalid settings will be just ignored. So I think this sentence needs to be re-examined as I don't think I understand what it is trying to say now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14040#discussion_r1199193045

From jlu at openjdk.org  Fri May 19 18:25:56 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 19 May 2023 18:25:56 GMT
Subject: Integrated: 8308021: Update IANA Language Subtag Registry to Version
 2023-05-11
In-Reply-To: <iIPuwaKdPI_0zXeGnvClUFB-k1jB8BHmDv6hpi7Lwys=.de585532-b094-46b0-acb9-204ae53617f3@github.com>
References: <iIPuwaKdPI_0zXeGnvClUFB-k1jB8BHmDv6hpi7Lwys=.de585532-b094-46b0-acb9-204ae53617f3@github.com>
Message-ID: <rFhbBCBkTF36HlX-9dzcyBro9e_0Akw7GfJU1IfFBHY=.485e3b82-c6ca-4803-b906-59f8f7d8d36d@github.com>

On Fri, 12 May 2023 17:56:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this trivial fix which updates the IANA data to version 5/11/2023. As the update only includes variant sub-tags, there is no impact to JDK tests. The update can be found [here](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-May/000087.html).

This pull request has now been integrated.

Changeset: 34468e1c
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/34468e1c916890d09e83d06094e225435c4642ba
Stats:     20 lines in 2 files changed: 17 ins; 0 del; 3 mod

8308021: Update IANA Language Subtag Registry to Version 2023-05-11

Reviewed-by: lancea, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13962

From jlu at openjdk.org  Fri May 19 18:41:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 19 May 2023 18:41:50 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v3]
In-Reply-To: <jPdpWcGFCqT_sU_dBhfkMIK9t5J-B-a8TJJH9BMcPss=.c282c784-c798-43f7-af8d-1e400380ac68@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
 <hif0_x1Xsly3QcpMBMxoD69Yc5IX2G6aZvATHgQBYOw=.43b003ac-4d64-4764-862a-22a8cc675b46@github.com>
 <X0aaL2rnAUGysmk2250BMQLHeG3lyJOZQlPFWZ0Hwcg=.e177be42-6827-4018-8d4e-f27aeb1c7ef3@github.com>
 <jPdpWcGFCqT_sU_dBhfkMIK9t5J-B-a8TJJH9BMcPss=.c282c784-c798-43f7-af8d-1e400380ac68@github.com>
Message-ID: <1dcFgCXvaxngBZS7E6TkCmFEKAi26eDgmlJA82qJxZE=.31ebb4c3-c183-446a-b3c6-0817afb9c951@github.com>

On Fri, 19 May 2023 17:11:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I don't think there is any chance that the factory method returns a Collator that fails to meet the settings in the locale, because setStrength()/setDecompositon() with valid values never fail. So the returned instance will always have the requested strength/decomposition. Does this answer your question?
>
>> I don't think there is any chance that the factory method returns a Collator that fails to meet the settings in the locale, because setStrength()/setDecompositon() with valid values never fail. So the returned instance will always have the requested strength/decomposition. Does this answer your question?
> 
> It's the last sentence that bothers me. I understand the setters can't fail but the last sentence of the proposed text makes it sound like invalid settings will be just ignored. So I think this sentence needs to be re-examined as I don't think I understand what it is trying to say now.

IIUC that's already the existing behavior for any Unicode extension.

Example,


Locale enIsoLoc = Locale.forLanguageTag("en-u-fw-mon");
WeekFields.of(enIsoLoc).getFirstDayOfWeek(); // MONDAY
Locale badExtension = Locale.forLanguageTag("en-u-fw-zzz");
WeekFields.of(badExtension).getFirstDayOfWeek(); // SUNDAY


If the value for a Unicode extension is invalid, they are simply ignored. In this case 'zzz' is not recognized and thus can not overhaul the first day of the week.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14040#discussion_r1199266617

From jlu at openjdk.org  Fri May 19 18:50:52 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 19 May 2023 18:50:52 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v3]
In-Reply-To: <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
Message-ID: <53fIv3Ebti14_cWhqDoCJb5fvo2KVwKOa4wQM18VBt4=.c8479c8f-3016-4a48-9812-8868683ab5d4@github.com>

On Thu, 18 May 2023 19:44:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a table for possible BCP47 values and their mappings

LGTM

-------------

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14040#pullrequestreview-1434931594

From mdoerr at openjdk.org  Fri May 19 18:54:19 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 19 May 2023 18:54:19 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v31]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <mPbG06Sl25MLR9FNrcDkNFzkcsb_h9TbwBKD71XzVcU=.e4221c6b-24ff-4049-be5e-4fce4381e9d0@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: T...

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup imports, improve comments, updates from other platforms.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/edcdefba..b1f04382

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=29-30

  Stats: 35 lines in 2 files changed: 12 ins; 11 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From mdoerr at openjdk.org  Fri May 19 18:54:20 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 19 May 2023 18:54:20 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v30]
In-Reply-To: <bf4m7b8y3H4H8IrJ_SyexNLSZza8RY0sKCS99ikbe4M=.1de7b9d8-56df-4778-9819-174ba24dba17@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <JI-0Tk2ZN2ZwQO3jhooK5jgqnzHbCJuKMQjSE_TsaCQ=.fc73c920-6107-4c61-8021-072cb58e18b6@github.com>
 <bf4m7b8y3H4H8IrJ_SyexNLSZza8RY0sKCS99ikbe4M=.1de7b9d8-56df-4778-9819-174ba24dba17@github.com>
Message-ID: <6xmxUDp_QPq_6Nigjth1OqTi3iHBchfPzhtvQs6DkVM=.939c69ae-6bdc-4323-bf9f-3308f7c714fb@github.com>

On Tue, 16 May 2023 14:44:25 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add NONZERO check for downcall_stub_address_offset_in_bytes().
>
> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 28:
> 
>> 26: package jdk.internal.foreign.abi.ppc64;
>> 27: 
>> 28: import java.lang.foreign.AddressLayout;
> 
> Imports are not grouped and ordered alphabetically.
> (Very much as the aarch64 version)

Done.

> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 73:
> 
>> 71:     public static final int MAX_FLOAT_REGISTER_ARGUMENTS = 13;
>> 72: 
>> 73:     // This is derived from the 64-Bit ELF V2 ABI spec, restricted to what's
> 
> The comment says ABI V2 but the code seems to handle V1 too.

It's derived from ABI v2, but v1 is compatible. Added that to the comment.

> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 158:
> 
>> 156:     class StorageCalculator {
>> 157:         private final boolean forArguments;
>> 158:         private boolean forVarArgs = false;
> 
> Seems to be not used.

I had kept it in case another PPC64 OS would need it, but I guess it's unlikely. So, I just removed it. Could get added back easily if needed.

> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 221:
> 
>> 219:             // !useABIv2() && layout.byteSize() > 8 && layout.byteSize() % 8 != 0
>> 220: 
>> 221:             // Allocate individual fields as gp slots (regs and stack).
> 
> You explained to me, it's not individual (struct) fields that are handled here. Looks like registers and 8 byte stack slots are allocated to completely cover the struct. Would be good if you could change the comment and names in the code to better reflect this.

Adapted to aarch64 implementation (using `MAX_COPY_SIZE`).

> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/linux/LinuxPPC64leLinker.java line 41:
> 
>> 39: 
>> 40:     public static LinuxPPC64leLinker getInstance() {
>> 41:         if (instance == null) {
> 
> Other platforms optimized this to return a constant (probably after you forked off the port).

Good catch. Adapted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1199271594
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1199271941
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1199272912
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1199273422
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1199273918

From rriggs at openjdk.org  Fri May 19 19:24:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 May 2023 19:24:57 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v17]
In-Reply-To: <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
Message-ID: <iWX5eKsfCUxRQvfCpA3U6VA2o9Hr0QyRKQiV_zzNP5k=.bf307045-4dde-485c-ab8f-b3bf2cc98d2c@github.com>

On Wed, 29 Mar 2023 01:40:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup test - rename method and update code comment as suggested by Alan
>  - Rename KNOWN_ENDIANNESS to PLATFORM_PROPERTIES

See draft PR https://github.com/openjdk/jdk/pull/14063 for a proposal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1555128657

From jiangli at openjdk.org  Fri May 19 20:25:52 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 19 May 2023 20:25:52 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
Message-ID: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>

Original description for JDK-8307194 change:
-----
This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:

 - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target

 - For libjvm.a specifically, exclude operator_new.o

- Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
  - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
  - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a

- Handle long arguments case for static build in make/common/NativeCompilation.gmk

- Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
-----

Updates to address build failures reported on macosx-<cpu> platforms:

- For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 

The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.

The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

-------------

Commit messages:
 - Merge branch 'master' into JDK-8307858
 - Clean up.
 - In clude $MACHINE_FLAG in partial linking flag.
 - Use '-m32' instead of '-m elf_i386'.
 - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform.
 - Only do partial linking step with gcc/clang on 64-bit platform.
 - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG.
 - Merge branch 'master' into JDK-8307858
 - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change.
 - When building a static library, partially link the input object files first. Then create the static library using the output object file produced by partial linking.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/265f40b4...8af1ec2f

Changes: https://git.openjdk.org/jdk/pull/14064/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307858
  Stats: 201 lines in 10 files changed: 150 ins; 34 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064

PR: https://git.openjdk.org/jdk/pull/14064

From naoto at openjdk.org  Fri May 19 21:13:37 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 May 2023 21:13:37 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v4]
In-Reply-To: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
Message-ID: <LTwn7xI9M_cxurZCiO0K-wWavrfoHJM-Vw7lvH9iXWk=.d8363cd4-e4b8-416e-97b8-906758fe5369@github.com>

> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  A bit of clarification

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14040/files
  - new: https://git.openjdk.org/jdk/pull/14040/files/627b78b3..1cfc09b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14040&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14040&range=02-03

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14040/head:pull/14040

PR: https://git.openjdk.org/jdk/pull/14040

From erikj at openjdk.org  Fri May 19 21:23:02 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 19 May 2023 21:23:02 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>

On Fri, 19 May 2023 20:18:53 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

I ran this patch in our internal build and test system and got failures on macos and windows. I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in.


[2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error
[2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
[2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed
[2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1

make/common/NativeCompilation.gmk line 1208:

> 1206: 	  $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \
> 1207: 	     $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \
> 1208:                  $$($1_LD_OBJ_ARG))

This command line is missing `$$($1_SYSROOT_LDFLAGS)` which is causing it to fail in our builds with:

ld: library not found for -lSystem

-------------

PR Review: https://git.openjdk.org/jdk/pull/14064#pullrequestreview-1435143793
PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1199405809

From jiangli at openjdk.org  Fri May 19 21:50:49 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 19 May 2023 21:50:49 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
Message-ID: <O8auyJ9WC5f_CVwL16zmVLG1Ac_7Nl_J886jKHRXSL0=.e823b39a-da86-4a57-8d02-8f46b1298fb9@github.com>

On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> I ran this patch in our internal build and test system and got failures on macos and windows. 

Thanks a lot, @erikj79! I was going to ask your help for testing the patch.

> I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in.
> 
> ```
> [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error
> [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
> [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed
> [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1
> ```

The warning error looks the same as https://bugs.openjdk.org/browse/JDK-8307858?focusedCommentId=14581027&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14581027. Sorry I didn't look closely earlier. I just took a look of https://github.com/openjdk/jdk/blob/939344b8433b32166f42ad73ae3d96e84b033478/src/hotspot/share/compiler/disassembler.cpp#L792:

#ifdef STATIC_BUILD
  char* p = strrchr(buf, '/');
  *p = '\0';
  strcat(p, "/lib/");
  lib_offset = jvm_offset = strlen(buf);
#else

The code is only enabled for the static build, which is why the issue doesn't show up in regular JDK build. `strlen` return value is `size_t`. I'll work on a fix.

Could you please help fix the mac failure as you have already looked into it. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1555290450

From psandoz at openjdk.org  Fri May 19 22:23:53 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 19 May 2023 22:23:53 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v3]
In-Reply-To: <Js67F4k4vce7aJj1IaxhDV3Ny6NEVF4fD8OA85KloB8=.26bae93a-c26e-44d8-a158-8789f77ef58d@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <Js67F4k4vce7aJj1IaxhDV3Ny6NEVF4fD8OA85KloB8=.26bae93a-c26e-44d8-a158-8789f77ef58d@github.com>
Message-ID: <fGX-KZ4sKymEyi0Cn0DbIrm_4UnMXTf-mNIt5I_yKe4=.39451142-0f8b-40c2-9718-fcde9356419d@github.com>

On Fri, 19 May 2023 11:08:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>  - More javadoc tweaks

src/java.base/share/classes/java/lang/foreign/Linker.java line 62:

> 60:  * </ul>
> 61:  * A linker provides a way to lookup up the <em>canonical layouts</em> associated with the data types used by the ABI.
> 62:  * For example, the canonical layout for the C {@code size_t} type is equal to {@link ValueLayout#JAVA_LONG}. The canonical

Suggestion:

 * For example, the canonical layout for the C {@code size_t} type is equal to {@link ValueLayout#JAVA_LONG} on 64-bit platforms. The canonical

?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14037#discussion_r1199471895

From psandoz at openjdk.org  Fri May 19 22:46:51 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 19 May 2023 22:46:51 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v3]
In-Reply-To: <Js67F4k4vce7aJj1IaxhDV3Ny6NEVF4fD8OA85KloB8=.26bae93a-c26e-44d8-a158-8789f77ef58d@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <Js67F4k4vce7aJj1IaxhDV3Ny6NEVF4fD8OA85KloB8=.26bae93a-c26e-44d8-a158-8789f77ef58d@github.com>
Message-ID: <UdfB19Vae80C9ik7RiTNGDukWMMHfblif9zF3JaeM1s=.6a7521a7-7d37-4720-a6fc-9de0580a3aa9@github.com>

On Fri, 19 May 2023 11:08:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>  - More javadoc tweaks

This look much better. Can we strengthen the specification of `canonicalLayouts` in accordance with the class specification

-------------

PR Review: https://git.openjdk.org/jdk/pull/14037#pullrequestreview-1435247934

From erikj at openjdk.org  Fri May 19 22:47:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Fri, 19 May 2023 22:47:52 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
Message-ID: <axH2L8Xbo_ay03Sh4my9Zm69fjIZLG4siwfLtP_iI4c=.a11629bc-45c7-43ff-9e2b-fd150dcf6ace@github.com>

On Fri, 19 May 2023 21:13:24 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Original description for JDK-8307194 change:
>> -----
>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
>> 
>>  - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>> 
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>> -----
>> 
>> Updates to address build failures reported on macosx-<cpu> platforms:
>> 
>> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
>> 
>> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
>> 
>> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.
>
> make/common/NativeCompilation.gmk line 1208:
> 
>> 1206: 	  $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \
>> 1207: 	     $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \
>> 1208:                  $$($1_LD_OBJ_ARG))
> 
> This command line is missing `$$($1_SYSROOT_LDFLAGS)` which is causing it to fail in our builds with:
> 
> ld: library not found for -lSystem

This is the mac failure, sorry if that wasn't clear.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1199482710

From mcimadamore at openjdk.org  Fri May 19 22:57:50 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 19 May 2023 22:57:50 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v3]
In-Reply-To: <fGX-KZ4sKymEyi0Cn0DbIrm_4UnMXTf-mNIt5I_yKe4=.39451142-0f8b-40c2-9718-fcde9356419d@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <Js67F4k4vce7aJj1IaxhDV3Ny6NEVF4fD8OA85KloB8=.26bae93a-c26e-44d8-a158-8789f77ef58d@github.com>
 <fGX-KZ4sKymEyi0Cn0DbIrm_4UnMXTf-mNIt5I_yKe4=.39451142-0f8b-40c2-9718-fcde9356419d@github.com>
Message-ID: <99Rt1rv4HwRuHGVG5NZ9nDlBQvSBGWiYFrfKkv97NvI=.2121a46a-6890-4dc9-9749-4f83cfb327b3@github.com>

On Fri, 19 May 2023 22:20:32 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Address review comments
>>  - More javadoc tweaks
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 62:
> 
>> 60:  * </ul>
>> 61:  * A linker provides a way to lookup up the <em>canonical layouts</em> associated with the data types used by the ABI.
>> 62:  * For example, the canonical layout for the C {@code size_t} type is equal to {@link ValueLayout#JAVA_LONG}. The canonical
> 
> Suggestion:
> 
>  * For example, the canonical layout for the C {@code size_t} type is equal to {@link ValueLayout#JAVA_LONG} on 64-bit platforms. The canonical
> 
> ?

You are correct in calling this out. I think this should be spelled out more (similarly to what we do for default lookup) since we're still in the "general" linker section. E.g.


A linker provides a way to lookup up the <em>canonical layouts</em> associated with the data types used by the ABI.
For example, a linker implementing the C ABI might chose to provide a canonical layout for the C {@code size_t} type. On 64-bit platforms, this canonical layout might be equal to {@link ValueLayout#JAVA_LONG}. The canonical
layouts supported by a linker are exposed via the {@link #canonicalLayouts()} method, which returns a map from
ABI type names to canonical layouts.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14037#discussion_r1199485729

From mcimadamore at openjdk.org  Fri May 19 23:00:51 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 19 May 2023 23:00:51 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v3]
In-Reply-To: <UdfB19Vae80C9ik7RiTNGDukWMMHfblif9zF3JaeM1s=.6a7521a7-7d37-4720-a6fc-9de0580a3aa9@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <Js67F4k4vce7aJj1IaxhDV3Ny6NEVF4fD8OA85KloB8=.26bae93a-c26e-44d8-a158-8789f77ef58d@github.com>
 <UdfB19Vae80C9ik7RiTNGDukWMMHfblif9zF3JaeM1s=.6a7521a7-7d37-4720-a6fc-9de0580a3aa9@github.com>
Message-ID: <uouq_KJZGLAf75DkDu6y9YnN2DRq5jrkycZrNuvX104=.d821d16c-052e-4a69-86ee-c045d46171b5@github.com>

On Fri, 19 May 2023 22:43:56 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> This look much better. Can we strengthen the specification of `canonicalLayouts` in accordance with the class specification

We can't do more in that method javadoc,  think, as that has to be general enough for all linkers. I think the rules set up in that method javadoc are good - e.g. the set of layouts should be stable (both in terms of names and layout types).

What we can do is to sprinkle some wording in the `nativeLinker` factory - e.g. `the native linker is guaranteed to provide canonical layouts for basic C types <link to the class section>`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1555354443

From psandoz at openjdk.org  Fri May 19 23:10:51 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 19 May 2023 23:10:51 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v3]
In-Reply-To: <uouq_KJZGLAf75DkDu6y9YnN2DRq5jrkycZrNuvX104=.d821d16c-052e-4a69-86ee-c045d46171b5@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <Js67F4k4vce7aJj1IaxhDV3Ny6NEVF4fD8OA85KloB8=.26bae93a-c26e-44d8-a158-8789f77ef58d@github.com>
 <UdfB19Vae80C9ik7RiTNGDukWMMHfblif9zF3JaeM1s=.6a7521a7-7d37-4720-a6fc-9de0580a3aa9@github.com>
 <uouq_KJZGLAf75DkDu6y9YnN2DRq5jrkycZrNuvX104=.d821d16c-052e-4a69-86ee-c045d46171b5@github.com>
Message-ID: <H6vAs4zEAdTMHV_4HqSWYrJV3rof0uFCWPc---q9p7c=.42da24c9-233f-454e-9072-3bb8151e45cb@github.com>

On Fri, 19 May 2023 22:57:39 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > This look much better. Can we strengthen the specification of `canonicalLayouts` in accordance with the class specification
> 
> We can't do more in that method javadoc, think, as that has to be general enough for all linkers. I think the rules set up in that method javadoc are good - e.g. the set of layouts should be stable (both in terms of names and layout types).
> 
> What we can do is to sprinkle some wording in the `nativeLinker` factory - e.g. `the native linker is guaranteed to provide canonical layouts for basic C types <link to the class section>`.

Yes, that's better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1555361325

From jlu at openjdk.org  Sat May 20 00:06:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 20 May 2023 00:06:57 GMT
Subject: RFR: 8159023: Engineering notation of DecimalFormat does not work as
 documented
Message-ID: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>

Please review this PR which updates the Scientific Notation section of Decimal Format. It aims to resolve [JDK-8159023](https://bugs.openjdk.org/browse/JDK-8159023) as well as [JDK-6282188](https://bugs.openjdk.org/browse/JDK-6282188).

**Scientific Notation** in Decimal Format contains the definition for a scientific notation formatted number's mantissa as such: _The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits. For example, 12345 formatted with "##0.##E0" is "12.3E3"._

Both the definition and example are incorrect, as the actual result is "12.E345". 

The following example data show that scientific notation formatted numbers do not adhere to that definition. As, according to the definition, the following numbers should have 3 significant digits, but in reality, they have up to 5.

123 formatted by ##0.#E0 is 123E0
1234 formatted by ##0.#E0 is 1.234E3
12345 formatted by ##0.#E0 is 12.34E3
123456 formatted by ##0.#E0 is 123.5E3
1234567 formatted by ##0.#E0 is 1.235E6
12345678 formatted by ##0.#E0 is 12.35E6
123456789 formatted by ##0.#E0 is 123.5E6 


The actual definition of the mantissa, as well as examples and further context are included in this change. In addition, a test has been added that tests various patterns to numbers and ensures the format follows the new definition's mathematical expression.

-------------

Commit messages:
 - Remove comments if they serve no purpose in the code
 - Add test for new definition
 - Add Specification

Changes: https://git.openjdk.org/jdk/pull/14066/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14066&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8159023
  Stats: 158 lines in 2 files changed: 151 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14066/head:pull/14066

PR: https://git.openjdk.org/jdk/pull/14066

From itakiguchi at openjdk.org  Sat May 20 01:06:59 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Sat, 20 May 2023 01:06:59 GMT
Subject: RFR: 8308046: Move Solaris related charsets from java.base to
 jdk.charsets module [v2]
In-Reply-To: <URWJaXXaEzUAWnM0t0t_VFs-eSpBxYhrWKpHL1Dd1b4=.456a44fc-ce38-46ee-ba17-48fd37df65f5@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
 <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
 <4yFGg-CgLRvNAEB7tpVH9Bi13fdlyAAdVniQnYoZcX4=.32f55011-db19-4c15-adc1-7cfc4cd564a6@github.com>
 <URWJaXXaEzUAWnM0t0t_VFs-eSpBxYhrWKpHL1Dd1b4=.456a44fc-ce38-46ee-ba17-48fd37df65f5@github.com>
Message-ID: <Of7--k3lQYJdoaAusVAhJB6XzmAoxuYD5FMm7P448P8=.2e742cdb-d7f5-4f38-87de-ff5725fec96b@github.com>

On Thu, 18 May 2023 00:50:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> Hello @naotoj . I'm not sure we can remove Solaris related charsets. Somebody may use them for text communication between Solaris.
>> 
>> OK, maybe not now.
>> 
>> I think the fix may be simplified by changing access for those `DoubleByte-X.java.template` internals, such as `DecodeHolder` to `public`, instead of introducing those access methods. You can import classes in `java.base/sun.nio.cs` with the wild card so that it would work on all platforms (`Big5` either in `java.base` or `jdk.charsets`)
>> 
>> Also, please drop `Japanese` from the issue/PR title
>
>>You can import classes in `java.base/sun.nio.cs` with the wild card so that it would work on all platforms (`Big5` either in `java.base` or `jdk.charsets`)
> 
> Scratch that, you've already did it. Then you can remove these: 
> 
> import sun.nio.cs.DoubleByte;
> import sun.nio.cs.HistoricallyNamedCharset;

Hello @naotoj .
I'd like to confirm about DoubleByte-X.java.template and EUC_JP.java.template.
I think the values are package-private.
Even if class is changed to `public`, the classes in`sun.nio.cs.ext` package could not access to these values in `sun.nio.cs` package...
I may be misunderstanding your suggestion, could you tell me more ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1555405480

From naoto at openjdk.org  Sat May 20 17:29:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 20 May 2023 17:29:50 GMT
Subject: RFR: 8308046: Move Solaris related charsets from java.base to
 jdk.charsets module [v2]
In-Reply-To: <Of7--k3lQYJdoaAusVAhJB6XzmAoxuYD5FMm7P448P8=.2e742cdb-d7f5-4f38-87de-ff5725fec96b@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
 <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
 <4yFGg-CgLRvNAEB7tpVH9Bi13fdlyAAdVniQnYoZcX4=.32f55011-db19-4c15-adc1-7cfc4cd564a6@github.com>
 <URWJaXXaEzUAWnM0t0t_VFs-eSpBxYhrWKpHL1Dd1b4=.456a44fc-ce38-46ee-ba17-48fd37df65f5@github.com>
 <Of7--k3lQYJdoaAusVAhJB6XzmAoxuYD5FMm7P448P8=.2e742cdb-d7f5-4f38-87de-ff5725fec96b@github.com>
Message-ID: <txZ17bmXVyokeDGUg0Nv7coyls0P9nd4s95qyxFY3rA=.4fe47161-b45c-436f-9074-1aa6df738958@github.com>

On Sat, 20 May 2023 01:03:52 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> I think the values are package-private. Even if class is changed to `public`, the classes in`sun.nio.cs.ext` package could not access to these values in `sun.nio.cs` package... 

I meant making those package-private fields public. I believe it's OK because java.base/sun.nio.cs package is only exported to jdk.charsets module.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1555957029

From liangchenblue at gmail.com  Sun May 21 04:52:44 2023
From: liangchenblue at gmail.com (-)
Date: Sat, 20 May 2023 23:52:44 -0500
Subject: Exposing checked exceptions that a MethodHandle can throw
Message-ID: <CABe8uE06fhHacUU0=nBuiFS5pbVcfyUnxih3TtBQ_KgTc69bbA@mail.gmail.com>

Hello,
I am eliciting a discussion on the feasibility of tracking checked
exceptions thrown by a MethodHandle. It is already requested in
https://bugs.openjdk.org/browse/JDK-8268116 as it appears useful in
the development of Foreign Function Interface API.

Currently, explicit MethodHandle usages are hampered by the catch
block as the invoke methods are declared to throw any Throwable. Could
it be possible that we specify the types of possible exceptions at
MethodHandle invocation, so that:
1. Javac accepts code that just call the handle without ugly try-catch block
2. If the exceptions anticipated at invocation site are incompatible
with (i.e. more specific than) those declared by the invoked handle,
it can throw an exception like the existing `WrongMethodTypeException`
eagerly.

Is such a plan feasible? Tracking of exceptions should be easy from
Direct MH and the MethodHandles combinators already, while the
invocation semantics update might be more complex, maybe in the form
of compiler-inserted stubs before the actual invoke calls. I wish such
improvements can make MethodHandle more friendly to direct usages in
code, so users don't need to wrap MH invocations in try-catch blocks
everywhere.

Chen Liang

From jpai at openjdk.org  Sun May 21 09:28:17 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 21 May 2023 09:28:17 GMT
Subject: RFR: 8308475: Make the thread dump files generated by jcmd
 Thread.dump_to_file jtreg failure handler action easily accessible
Message-ID: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>

Can I please get a review of this change which proposes to improve the accessibility of the thread dump files that are generated by the `jcmd Thread.dump_to_file` command configured in the failure handler configurations? This addresses https://bugs.openjdk.org/browse/JDK-8308475. 

The changes in this PR include:
 - Enhancement to `GatherProcessInfoTimeoutHandler` to allow configuring a `successArtifacts` action parameter which can be used to generate links to files that are generated by the failure handler commands.
 - Introduction of a `%iterCount` token to allow ability to refer to the current iteration when the command is repeated
 - The `jcmd Thread.dump_to_file` is now configured to create the thread dumps in `json` format. Additionally, it has now been configured to create the thread dumps 6 times, just like the `jstack` command.

Detailed explanation of the `successArtifacts` parameter and the `%iterCount` token is provided in the JBS comment here https://bugs.openjdk.org/browse/JDK-8308475?focusedCommentId=14583072&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14583072

Tests have been run locally with this change and tier1, tier2 and tier3 tests on CI system to verify this change works and doesn't cause regression.

-------------

Commit messages:
 - 8308475: Make the thread dump files generated by jcmd Thread.dump_to_file jtreg failure handler action easily accessible

Changes: https://git.openjdk.org/jdk/pull/14071/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14071&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308475
  Stats: 78 lines in 5 files changed: 66 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/14071.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14071/head:pull/14071

PR: https://git.openjdk.org/jdk/pull/14071

From jpai at openjdk.org  Sun May 21 09:28:17 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 21 May 2023 09:28:17 GMT
Subject: RFR: 8308475: Make the thread dump files generated by jcmd
 Thread.dump_to_file jtreg failure handler action easily accessible
In-Reply-To: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>
References: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>
Message-ID: <izGOkU1DbNc4BtmdfVjySe_FmrIPn1OtcwxtONKfDLk=.4dda9132-1ddb-4ca3-bc42-33dc7ff7393f@github.com>

On Sun, 21 May 2023 09:19:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to improve the accessibility of the thread dump files that are generated by the `jcmd Thread.dump_to_file` command configured in the failure handler configurations? This addresses https://bugs.openjdk.org/browse/JDK-8308475. 
> 
> The changes in this PR include:
>  - Enhancement to `GatherProcessInfoTimeoutHandler` to allow configuring a `successArtifacts` action parameter which can be used to generate links to files that are generated by the failure handler commands.
>  - Introduction of a `%iterCount` token to allow ability to refer to the current iteration when the command is repeated
>  - The `jcmd Thread.dump_to_file` is now configured to create the thread dumps in `json` format. Additionally, it has now been configured to create the thread dumps 6 times, just like the `jstack` command.
> 
> Detailed explanation of the `successArtifacts` parameter and the `%iterCount` token is provided in the JBS comment here https://bugs.openjdk.org/browse/JDK-8308475?focusedCommentId=14583072&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14583072
> 
> Tests have been run locally with this change and tier1, tier2 and tier3 tests on CI system to verify this change works and doesn't cause regression.

Here's how the link to the thread dump file will look like with these current changes, in the processes.html:

<img width="1581" alt="processes html" src="https://github.com/openjdk/jdk/assets/143523/131ffec4-6411-4c63-8f05-d47ebb9151d5">

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14071#issuecomment-1556129202

From alanb at openjdk.org  Sun May 21 09:40:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 21 May 2023 09:40:00 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v4]
In-Reply-To: <LTwn7xI9M_cxurZCiO0K-wWavrfoHJM-Vw7lvH9iXWk=.d8363cd4-e4b8-416e-97b8-906758fe5369@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <LTwn7xI9M_cxurZCiO0K-wWavrfoHJM-Vw7lvH9iXWk=.d8363cd4-e4b8-416e-97b8-906758fe5369@github.com>
Message-ID: <Hn-BV4fggEKc8pgb2NTUF0DDk2Lz99zpFsnH1HBvMLg=.570e3ee2-5bb8-4ece-b5b1-1396d33cb45c@github.com>

On Fri, 19 May 2023 21:13:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A bit of clarification

I went through the latest javadoc but the last sentence is still confusing. I think the part that is missing is the method doesn't make it clear up front that it gets requested locale and then attempts to set its strength and decomposition if recognized. If this were clear in the first part of the method description then it is okay to say that the returned Collator might not have the expected strength and decomposition.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14040#issuecomment-1556131544

From forax at univ-mlv.fr  Sun May 21 13:47:46 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 21 May 2023 15:47:46 +0200 (CEST)
Subject: Exposing checked exceptions that a MethodHandle can throw
In-Reply-To: <CABe8uE06fhHacUU0=nBuiFS5pbVcfyUnxih3TtBQ_KgTc69bbA@mail.gmail.com>
References: <CABe8uE06fhHacUU0=nBuiFS5pbVcfyUnxih3TtBQ_KgTc69bbA@mail.gmail.com>
Message-ID: <1476800905.60149992.1684676866306.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "-" <liangchenblue at gmail.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Sunday, May 21, 2023 6:52:44 AM
> Subject: Exposing checked exceptions that a MethodHandle can throw

> Hello,
> I am eliciting a discussion on the feasibility of tracking checked
> exceptions thrown by a MethodHandle. It is already requested in
> https://bugs.openjdk.org/browse/JDK-8268116 as it appears useful in
> the development of Foreign Function Interface API.

At the bytecode level, checked exceptions are stored in an attribute associated to a method.
  https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.7.5

If you have a direct MethodHandle, you can already get the checked exceptions using Lookup.revealDirect() + MethodHandleInfo.reflectAs().

> 
> Currently, explicit MethodHandle usages are hampered by the catch
> block as the invoke methods are declared to throw any Throwable. Could
> it be possible that we specify the types of possible exceptions at
> MethodHandle invocation, so that:
> 1. Javac accepts code that just call the handle without ugly try-catch block
> 2. If the exceptions anticipated at invocation site are incompatible
> with (i.e. more specific than) those declared by the invoked handle,
> it can throw an exception like the existing `WrongMethodTypeException`
> eagerly.

The bug you reference seems to be about runtime information, but the paragraph above is about type-checking information.
The question here is "is the Java type system good enough to track checked exception in a backward compatible way ?"
Practically, I believe the answer is no, you can not compose function with different type parameters representing exception, there is no varargs of type parameters, there is no default type argument for a type parameter, etc.

It's also significant departure of the way the method handle API is created, the idea behind is that each combiner has the semantics of an existing bytecode. But all invoke* bytecodes are oblivious to exception. Said differently, the method handle API represent how the JVM works, not how Java the language works. 

> 
> Is such a plan feasible? Tracking of exceptions should be easy from
> Direct MH and the MethodHandles combinators already, while the
> invocation semantics update might be more complex, maybe in the form
> of compiler-inserted stubs before the actual invoke calls. I wish such
> improvements can make MethodHandle more friendly to direct usages in
> code, so users don't need to wrap MH invocations in try-catch blocks
> everywhere.

see above.

> 
> Chen Liang

R?mi

From jlahoda at openjdk.org  Mon May 22 04:27:21 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 22 May 2023 04:27:21 GMT
Subject: Integrated: 8300543 Compiler Implementation for Pattern Matching for
 switch
In-Reply-To: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
References: <LGzOJWBBUpSZrmrQWKR5UhpP16kp2VJdtf_ba9cNj7w=.87e7e87b-6f25-4576-8506-1064dc342efa@github.com>
Message-ID: <kOU5f1WY3hB8FbzwhbLuh_r_s4gcPN68OXY_aCho-uA=.162483c0-1555-40ba-a077-fd0b68a65a79@github.com>

On Fri, 17 Mar 2023 12:15:58 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is the first draft of a patch for JEP 440 and JEP 441. Changes included:
> 
>  - the pattern matching for switch and record patterns features are made final, together with updates to tests.
>  - parenthesized patterns are removed.
>  - qualified enum constants are supported for case labels.
> 
> This change herein also includes removal record patterns in for each loop, which may be split into a separate PR in the future.

This pull request has now been integrated.

Changeset: eaa80ad0
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eaa80ad08c949a05abcfa48897654ed52139145b
Stats:     4391 lines in 161 files changed: 2113 ins; 1755 del; 523 mod

8300543: Compiler Implementation for Pattern Matching for switch
8300545: Compiler Implementation for Record Patterns

Co-authored-by: Aggelos Biboudis <abimpoudis at openjdk.org>
Reviewed-by: vromero, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/13074

From liangchenblue at gmail.com  Mon May 22 04:28:27 2023
From: liangchenblue at gmail.com (-)
Date: Sun, 21 May 2023 23:28:27 -0500
Subject: javac to emit static flag for local and anonymous classes in static
 contexts
Message-ID: <CABe8uE0M8EE_Z4hLNYuk865fD22xeF4o=dQkm2iaAqAqO2_bFw@mail.gmail.com>

Hello,
While looking at https://bugs.openjdk.org/browse/JDK-8162500 and
https://bugs.openjdk.org/browse/JDK-8162501 I realized that the static
flag in InnerClasses attribute alone is not sufficient to check if an
inner class is static; this flag is simply not emitted on local and
anonymous classes.

A simple workaround would be to check the EnclosingMethod attribute
and check if the enclosing method is static. However, this does not
always work:
Local/anonymous classes can be declared in an initializer block
(instance or static) and anonymous classes can be declared in variable
initialization statements.
In this case, the EnclosingMethod attribute can only report the
enclosing class, since the class appears in multiple methods (for
<init>) or non-reflectable method (<clinit>), and simple attempts to
guess will fail.
Moreover, with the upcoming JEP 447 that adds a pre-initialization
context, local/anonymous classes in the constructor may potentially be
static before the super constructor call, and be instance after the
super constructor call, which complicates the guessing problem.

Thus, I suggest emitting static flags for the InnerClasses attribute
of anonymous/local classes in static/pre-initialization contexts, in
order to allow core reflection to reliably detect the receiver class
of a local or anonymous class. It may also have a cascading effect on
the nested classes within these local/anonymous classes, as shown in
JDK-8162500.

Chen Liang

From alanb at openjdk.org  Mon May 22 06:20:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 May 2023 06:20:59 GMT
Subject: RFR: 8308235: ThreadContainer registry accumulates weak refs [v2]
In-Reply-To: <FS-cdoNCm7sqOB8-RRUSEZxfrIgTBlYuH4_UQ9tK7FA=.7f90bd7f-65fc-4945-be38-525c7b233951@github.com>
References: <FS-cdoNCm7sqOB8-RRUSEZxfrIgTBlYuH4_UQ9tK7FA=.7f90bd7f-65fc-4945-be38-525c7b233951@github.com>
Message-ID: <Cc0C0mIv-yX-gmN9UlFhrQn-9_5NOY36caBYqr91N8U=.7574bae3-a65f-40e7-ac99-8d2bf5f5b4ad@github.com>

> ThreadContainers is an internal class used to make thread pools and other groupings of threads discoverable for observability. Some refactoring in 2021 (in the loom repo, and before integration) accidentally changed the creation of a weak reference so that it no longer associated with the reference queue. The result is that stale refs aren't expunged from a CHM, leading to a memory leak. The change to fix the issue is trivial.
> 
> Tests for memory leaks can be problematic, often more trouble than they are worth. I started with a test that polls the size of the internal CHM but decided to ditch it. Instead, the test is simple. It just runs for a few seconds creating ExecuorService implementations (including TPE, TPPE, and FJP), unreferencing them without shutdown (so they don't terminate and unregister). This is enough to causes OOME with product builds a small heap.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Change test to use nanoTime
 - Merge
 - Fix @run tag
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14047/files
  - new: https://git.openjdk.org/jdk/pull/14047/files/89475604..562c6a1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14047&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14047&range=00-01

  Stats: 5024 lines in 169 files changed: 3826 ins; 371 del; 827 mod
  Patch: https://git.openjdk.org/jdk/pull/14047.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14047/head:pull/14047

PR: https://git.openjdk.org/jdk/pull/14047

From alanb at openjdk.org  Mon May 22 06:21:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 May 2023 06:21:00 GMT
Subject: RFR: 8308235: ThreadContainer registry accumulates weak refs [v2]
In-Reply-To: <rEBv1f-Hu-rAS83IglAwgel5E07AVwtTyo_ei1vo44k=.5de5dcc1-d17d-432f-bf74-a48ca4b081b3@github.com>
References: <FS-cdoNCm7sqOB8-RRUSEZxfrIgTBlYuH4_UQ9tK7FA=.7f90bd7f-65fc-4945-be38-525c7b233951@github.com>
 <rEBv1f-Hu-rAS83IglAwgel5E07AVwtTyo_ei1vo44k=.5de5dcc1-d17d-432f-bf74-a48ca4b081b3@github.com>
Message-ID: <Qx-oKTNAgv42U3TooZ4fANyvrpOwbJoedkCmDxTHTDE=.7d444d16-1071-44a2-953c-a62d798b87db@github.com>

On Fri, 19 May 2023 08:26:31 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Change test to use nanoTime
>>  - Merge
>>  - Fix @run tag
>>  - Initial commit
>
> test/jdk/java/util/concurrent/Executors/UnreferencedExecutor.java line 38:
> 
>> 36:         int ncores = Runtime.getRuntime().availableProcessors();
>> 37:         long start = System.currentTimeMillis();
>> 38:         while (System.currentTimeMillis() - start < 5000) {
> 
> @AlanBateman Might want to have this based on `nanoTime()` such that changes to wall-clock doesn't impact the length of the run of the test.

Okay, that would be better.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14047#discussion_r1199999336

From pminborg at openjdk.org  Mon May 22 06:47:52 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 22 May 2023 06:47:52 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v3]
In-Reply-To: <Js67F4k4vce7aJj1IaxhDV3Ny6NEVF4fD8OA85KloB8=.26bae93a-c26e-44d8-a158-8789f77ef58d@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <Js67F4k4vce7aJj1IaxhDV3Ny6NEVF4fD8OA85KloB8=.26bae93a-c26e-44d8-a158-8789f77ef58d@github.com>
Message-ID: <iisiScVPbKh5LckLyHxq5INfysZd22Z8VwmvssTi1J8=.c1be4037-4e8d-4239-886e-cb9c4f9b2c2b@github.com>

On Fri, 19 May 2023 11:08:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Address review comments
>  - More javadoc tweaks

src/java.base/share/classes/java/lang/foreign/Linker.java line 614:

> 612: 
> 613:     /**
> 614:      * {@return a mapping between the names of data types used by the ABI implemented by this linker and their

I think we should state we return "an unmodifiable mapping".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14037#discussion_r1200030077

From duke at openjdk.org  Mon May 22 07:02:55 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Mon, 22 May 2023 07:02:55 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v6]
In-Reply-To: <LFgxOLcJ5_iQPvsWlslmCOmvedtb2_i9WEywTBnOca4=.4d3b0563-c795-4eaa-bf86-a77a76768cf2@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <jcpe28LzmXpGO4YE5eP6fF-RBEg-O2iUMP0EphSCox8=.6f398f44-463c-474a-8428-ee0afa09ff18@github.com>
 <LFgxOLcJ5_iQPvsWlslmCOmvedtb2_i9WEywTBnOca4=.4d3b0563-c795-4eaa-bf86-a77a76768cf2@github.com>
Message-ID: <sfcR4rV6FFmdw1O_YEOaC_pFQNMBlr2y4fAdvyMCyY8=.4171e46e-aefc-479e-a547-5b829edac406@github.com>

On Fri, 19 May 2023 09:32:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Nagata-Haruhito has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Merge branch 'File_javadoc' of https://github.com/Nagata-Haruhito/jdk into File_javadoc
>>  - Drop exist to available
>>  - Merge branch 'master' into File_javadoc
>
> src/java.base/share/classes/java/io/File.java line 1828:
> 
>> 1826:      * namely {@code "/"}.  The set of filesystem roots is affected
>> 1827:      * by various system-level operations such as the disconnecting or
>> 1828:      * unmounting of physical or virtual disk drives.
> 
> I think you'll have to move this to the end of the method description, otherwise the paragraphs that follow will show up as "Implementation Note" too.

I think following two paragraphs belongs to `Implementation Note` too, because of UNC pathname and SecurityException. 
Is it wrong?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13526#discussion_r1200048699

From alanb at openjdk.org  Mon May 22 07:07:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 May 2023 07:07:53 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v6]
In-Reply-To: <sfcR4rV6FFmdw1O_YEOaC_pFQNMBlr2y4fAdvyMCyY8=.4171e46e-aefc-479e-a547-5b829edac406@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <jcpe28LzmXpGO4YE5eP6fF-RBEg-O2iUMP0EphSCox8=.6f398f44-463c-474a-8428-ee0afa09ff18@github.com>
 <LFgxOLcJ5_iQPvsWlslmCOmvedtb2_i9WEywTBnOca4=.4d3b0563-c795-4eaa-bf86-a77a76768cf2@github.com>
 <sfcR4rV6FFmdw1O_YEOaC_pFQNMBlr2y4fAdvyMCyY8=.4171e46e-aefc-479e-a547-5b829edac406@github.com>
Message-ID: <ucSc_a5SqIQQTyoavnkWjbp-zeQVjCbNMlvKLdQBukI=.0d17c676-6ee2-4984-abca-81918e16d70d@github.com>

On Mon, 22 May 2023 07:00:27 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/File.java line 1828:
>> 
>>> 1826:      * namely {@code "/"}.  The set of filesystem roots is affected
>>> 1827:      * by various system-level operations such as the disconnecting or
>>> 1828:      * unmounting of physical or virtual disk drives.
>> 
>> I think you'll have to move this to the end of the method description, otherwise the paragraphs that follow will show up as "Implementation Note" too.
>
> I think following two paragraphs belongs to `Implementation Note` too, because of UNC pathname and SecurityException. 
> Is it wrong?

The paragraph about that the result is filtered when checkRead is denied by the SecurityException is normative.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13526#discussion_r1200052457

From simonis at openjdk.org  Mon May 22 07:24:56 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 22 May 2023 07:24:56 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v3]
In-Reply-To: <pPfpk0spHtI57ovb4jUjGFCroYNVLBcW7VEglb6B1xw=.267a7093-0fd5-485a-8e76-1b5ee179d770@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <V6X7mD9t_bH6l8iYAxk2B8wszDqj8_Oa9zcgarrxotc=.6beeb6ad-6ddc-4ab4-a3c7-1c35050e3978@github.com>
 <pPfpk0spHtI57ovb4jUjGFCroYNVLBcW7VEglb6B1xw=.267a7093-0fd5-485a-8e76-1b5ee179d770@github.com>
Message-ID: <hcqmeZhpj8fQPLP-rSJ5pJrhPr-vGHGRClqeVUAuAxU=.91d62e02-c068-4323-89ef-8a64ae8371ac@github.com>

On Wed, 17 May 2023 17:08:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   REALLY adding the test :)
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 116:
> 
>> 114:         int ret = p.exitValue();
>> 115:         if (ret == 0) {
>> 116:             throw new Exception("Expected error in child execution");
> 
> Mixing the two styles of error reporting seems a bit odd, some throw exceptions and others just exit.
> Being consistent throwing an exception with a message would be better.

Good point. Changed the exits to exceptions except in `childCode()` where we need `System.exit()` in order to communicate different error states back to the parent process.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1200069183

From duke at openjdk.org  Mon May 22 07:27:00 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Mon, 22 May 2023 07:27:00 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v7]
In-Reply-To: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
Message-ID: <hw_GfSecKgwyXkMjKCqk8Cbpa-0_4wZe8M6aHrQVzIQ=.acf75a82-db86-4422-9d73-48efe2ad16b4@github.com>

> I fixed File.listRoots description.
> * remove "the insertion or ejection of removable media"
> * change "available" to "existing"
> 
> Please review this change.

Nagata-Haruhito has updated the pull request incrementally with one additional commit since the last revision:

  Move SecurityException paragraph

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13526/files
  - new: https://git.openjdk.org/jdk/pull/13526/files/7ba2460a..3d4aed98

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13526&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13526&range=05-06

  Stats: 12 lines in 1 file changed: 6 ins; 6 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13526.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13526/head:pull/13526

PR: https://git.openjdk.org/jdk/pull/13526

From duke at openjdk.org  Mon May 22 07:27:00 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Mon, 22 May 2023 07:27:00 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v6]
In-Reply-To: <ucSc_a5SqIQQTyoavnkWjbp-zeQVjCbNMlvKLdQBukI=.0d17c676-6ee2-4984-abca-81918e16d70d@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <jcpe28LzmXpGO4YE5eP6fF-RBEg-O2iUMP0EphSCox8=.6f398f44-463c-474a-8428-ee0afa09ff18@github.com>
 <LFgxOLcJ5_iQPvsWlslmCOmvedtb2_i9WEywTBnOca4=.4d3b0563-c795-4eaa-bf86-a77a76768cf2@github.com>
 <sfcR4rV6FFmdw1O_YEOaC_pFQNMBlr2y4fAdvyMCyY8=.4171e46e-aefc-479e-a547-5b829edac406@github.com>
 <ucSc_a5SqIQQTyoavnkWjbp-zeQVjCbNMlvKLdQBukI=.0d17c676-6ee2-4984-abca-81918e16d70d@github.com>
Message-ID: <30rt3l_VHjkPrgiFWVrlzWxTJ1flVbnCOOE9BZ5g7_I=.e1fee020-6515-47ee-b58e-7778fe9ce0bd@github.com>

On Mon, 22 May 2023 07:04:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I think following two paragraphs belongs to `Implementation Note` too, because of UNC pathname and SecurityException. 
>> Is it wrong?
>
> The paragraph about that the result is filtered when checkRead is denied by the SecurityException is normative.

Thank you for your advice.
I moved this paragraph upper.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13526#discussion_r1200068557

From pminborg at openjdk.org  Mon May 22 07:29:53 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 22 May 2023 07:29:53 GMT
Subject: RFR: 8301552: Use AtomicReferenceArray for caching instead of CHM
 in ZoneOffset [v8]
In-Reply-To: <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
Message-ID: <1AX3LgL7iwg56xqgzV3I6wE5QxI4wgkp2VVncRNqRFM=.a9f3a52c-f928-42d1-948f-e4b64a6f2c4b@github.com>

On Thu, 9 Feb 2023 13:46:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
>> 
>> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unused setup method
>  - Rename method in test
>  - Add copyright header

Keep alive. We might use another construct.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12346#issuecomment-1556683570

From simonis at openjdk.org  Mon May 22 07:37:01 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 22 May 2023 07:37:01 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v3]
In-Reply-To: <pPfpk0spHtI57ovb4jUjGFCroYNVLBcW7VEglb6B1xw=.267a7093-0fd5-485a-8e76-1b5ee179d770@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <V6X7mD9t_bH6l8iYAxk2B8wszDqj8_Oa9zcgarrxotc=.6beeb6ad-6ddc-4ab4-a3c7-1c35050e3978@github.com>
 <pPfpk0spHtI57ovb4jUjGFCroYNVLBcW7VEglb6B1xw=.267a7093-0fd5-485a-8e76-1b5ee179d770@github.com>
Message-ID: <4OmIAytgEGiNzqRw61FskJeg66UnxZwBN-w3ZvaJukQ=.75007594-069e-4e5c-9b37-c1cd7435cb5b@github.com>

On Wed, 17 May 2023 17:01:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   REALLY adding the test :)
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 63:
> 
>> 61:         if (p.exitValue() == 0) {
>> 62:             String pwd = p.inputReader().readLine();
>> 63:             if (!Path.of("").toAbsolutePath().toString().equals(pwd)) {
> 
> It would be useful to print the unexpected string; it might help isolate what went wrong.
> And make it easier to understand what ERROR+2 means.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1200082310

From simonis at openjdk.org  Mon May 22 07:41:56 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 22 May 2023 07:41:56 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v3]
In-Reply-To: <pPfpk0spHtI57ovb4jUjGFCroYNVLBcW7VEglb6B1xw=.267a7093-0fd5-485a-8e76-1b5ee179d770@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <V6X7mD9t_bH6l8iYAxk2B8wszDqj8_Oa9zcgarrxotc=.6beeb6ad-6ddc-4ab4-a3c7-1c35050e3978@github.com>
 <pPfpk0spHtI57ovb4jUjGFCroYNVLBcW7VEglb6B1xw=.267a7093-0fd5-485a-8e76-1b5ee179d770@github.com>
Message-ID: <eBcV0GIpyFnD79S1G5AsjJvUyMJgM-l7quzNIdgiqLw=.66f9741d-985b-4375-943b-7276cd2fbf6b@github.com>

On Wed, 17 May 2023 17:05:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   REALLY adding the test :)
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 78:
> 
>> 76:         pb = ProcessTools.createJavaProcessBuilder("-Djdk.lang.Process.launchMechanism=posix_spawn",
>> 77:                                                    "JspawnhelperProtocol",
>> 78:                                                    "normalExec");
> 
> I would just redirect the output to the parent.
> `pb.inheritIO()`  and avoid the extra code at line 88.

Good suggestion. Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1200086821

From dholmes at openjdk.org  Mon May 22 08:03:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 22 May 2023 08:03:55 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <61e5pVShTICWmDodgIDEACwz-NJB6OMUOw2crLQ2zTE=.2fc8ed80-5979-45c1-8797-ac2a8b47157e@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>
 <WNS9AUc4Uo0uJT7Q-c5WmRQGPXKHOiQ5bk3FAVhcpTw=.7b192c55-1a39-48bf-9c36-eb8219474c4f@github.com>
 <u7bSYYuppXZ1z347-wRTJf9GoxNUW-GoWfSn4dmCLEE=.831249e0-e538-491c-8001-a7dd55673721@github.com>
 <yZM9iro4FRdHveBRx07oeItZ9_CmQJ4wksNo3XI8Igs=.7b2097d5-0852-4f04-9c14-fc8d39a57c08@github.com>
 <qh4P0rQhdigeWLoD9paOaTJgT7uXOU0IsBTQlFdZ3Ew=.1eb8ea15-2d10-45e3-b883-87b088e220ba@github.com>
 <Q1qJR_GJWPvAItv1fmJu-QYM0g5ozWkWd2ljkAy7VQ8=.3a657b07-464d-4184-a667-a3f9a7c9c72a@github.com>
 <61e5pVShTICWmDodgIDEACwz-NJB6OMUOw2crLQ2zTE=.2fc8ed80-5979-45c1-8797-ac2a8b47157e@github.com>
Message-ID: <mmKw9s9KXG4GzwkhEwnKk4tyMLeDukua45o2louCl2E=.ab09f151-c16b-4e08-a288-927c284e45a5@github.com>

On Fri, 19 May 2023 15:43:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Given the purpose and implementation of the readFully function, I don't see how it can return anything other than an error or the full requested read length.

@RogerRiggs it will return < requested read length if it encounters EOF - i.e. a short read.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1556727447

From simonis at openjdk.org  Mon May 22 08:03:57 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 22 May 2023 08:03:57 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v3]
In-Reply-To: <pPfpk0spHtI57ovb4jUjGFCroYNVLBcW7VEglb6B1xw=.267a7093-0fd5-485a-8e76-1b5ee179d770@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <V6X7mD9t_bH6l8iYAxk2B8wszDqj8_Oa9zcgarrxotc=.6beeb6ad-6ddc-4ab4-a3c7-1c35050e3978@github.com>
 <pPfpk0spHtI57ovb4jUjGFCroYNVLBcW7VEglb6B1xw=.267a7093-0fd5-485a-8e76-1b5ee179d770@github.com>
Message-ID: <koMx6J06YDDz1FkRUY5Ptj89eDGlJozLr5RWaaAGSJk=.e1445d06-684c-4c3d-a4af-ab7869654b0b@github.com>

On Wed, 17 May 2023 17:07:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   REALLY adding the test :)
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 106:
> 
>> 104:             }
>> 105:             line = br.readLine();
>> 106:         }
> 
> Try-with-resources works well in cases like this.  (Moving foundCrashInfo out of the t-w-r).

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1200111600

From rrich at openjdk.org  Mon May 22 08:26:01 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 22 May 2023 08:26:01 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v30]
In-Reply-To: <6xmxUDp_QPq_6Nigjth1OqTi3iHBchfPzhtvQs6DkVM=.939c69ae-6bdc-4323-bf9f-3308f7c714fb@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <JI-0Tk2ZN2ZwQO3jhooK5jgqnzHbCJuKMQjSE_TsaCQ=.fc73c920-6107-4c61-8021-072cb58e18b6@github.com>
 <bf4m7b8y3H4H8IrJ_SyexNLSZza8RY0sKCS99ikbe4M=.1de7b9d8-56df-4778-9819-174ba24dba17@github.com>
 <6xmxUDp_QPq_6Nigjth1OqTi3iHBchfPzhtvQs6DkVM=.939c69ae-6bdc-4323-bf9f-3308f7c714fb@github.com>
Message-ID: <JWtmm0ruYBLwf37MzTGbQPvuYSJ48oEgdCB8MwGvJqc=.0694841d-3d1f-44a8-bd20-3dbddc6c3df1@github.com>

On Fri, 19 May 2023 18:47:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 158:
>> 
>>> 156:     class StorageCalculator {
>>> 157:         private final boolean forArguments;
>>> 158:         private boolean forVarArgs = false;
>> 
>> Seems to be not used.
>
> I had kept it in case another PPC64 OS would need it, but I guess it's unlikely. So, I just removed it. Could get added back easily if needed.

I see. There are other examples of redundant code that might serve a purpose in the future. I honestly don't like that.
In the case of `forVarArgs` porters can still find it in the aarch64 version :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1200139200

From alanb at openjdk.org  Mon May 22 08:37:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 May 2023 08:37:00 GMT
Subject: RFR: 8308038:
 java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java
 timed out
Message-ID: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>

This is a test only change to the unit test for the ExecutorService returned by Executors.newThreadPerTaskExecutor. The tests for interrupting invokeAll assume the threads started to execute the tasks do actually execute the task code. The refresh in JEP 444 changed the implementation to use FutureTask, and FutureTask checks the interrupt status before it executes the task code. So some intermittent timeouts of the tests for interrupting invokeAll as those tests were waiting for the task to complete.

The main change is that the tests for interrupting invokeAll are changed to interrupt when the main thread blocks in invokeAll. They are also changed to check if the task started or not. The tests for interrupting invokeAny already did this, but these are changed to use the same infrastructure to avoid having two styles of tests in the same source file.

-------------

Commit messages:
 - Update
 - Merge
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/14072/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14072&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308038
  Stats: 206 lines in 1 file changed: 87 ins; 57 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/14072.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14072/head:pull/14072

PR: https://git.openjdk.org/jdk/pull/14072

From rrich at openjdk.org  Mon May 22 08:56:07 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 22 May 2023 08:56:07 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v31]
In-Reply-To: <mPbG06Sl25MLR9FNrcDkNFzkcsb_h9TbwBKD71XzVcU=.e4221c6b-24ff-4049-be5e-4fce4381e9d0@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <mPbG06Sl25MLR9FNrcDkNFzkcsb_h9TbwBKD71XzVcU=.e4221c6b-24ff-4049-be5e-4fce4381e9d0@github.com>
Message-ID: <r1q_PmuWWnewZrJYJtRY7GROVRgy0Uy1Hqd0NbCt__M=.bcb5cf75-966a-403f-8362-8f37948a1f86@github.com>

On Fri, 19 May 2023 18:54:19 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separat...
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cleanup imports, improve comments, updates from other platforms.

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 65:

> 63:  */
> 64: public abstract class CallArranger {
> 65:     protected abstract boolean useABIv2();

This could also be refactored into a static method with the same trick that is used in `LinuxPPC64leLinker::getInstance`. Callers could be static then and you could delete `CallArranger::ABIv2` and `ABIv2CallArranger`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1200197510

From mcimadamore at openjdk.org  Mon May 22 09:34:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 22 May 2023 09:34:53 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v4]
In-Reply-To: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
Message-ID: <mNvyH9yRqp0OZJdx10SwbRBgyqTq_QdXGB-qHeTQ8B8=.c3bc2710-e51a-4855-a18e-0e3cbee33281@github.com>

> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
> 
> 
> jshell> import java.lang.foreign.*;
> 
> jshell> Linker.nativeLinker().canonicalLayouts()
> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
> 
> 
> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address further review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14037/files
  - new: https://git.openjdk.org/jdk/pull/14037/files/df92467c..dbc8049a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14037&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14037&range=02-03

  Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14037.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14037/head:pull/14037

PR: https://git.openjdk.org/jdk/pull/14037

From maurizio.cimadamore at oracle.com  Mon May 22 09:53:36 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 22 May 2023 10:53:36 +0100
Subject: RFR: 8287834: Add SymbolLookup::or method [v3]
In-Reply-To: <3KOWkW5WxXz7Kc-NXg4UHzB9Om6hXCCkMxsedHDfMJU=.f0e6ef27-71b0-4fea-b89a-682b3acfdac4@github.com>
References: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
 <eKYQGgn3rNM_La_IPkLoe6KatVEU5iZz-csW6dSecsY=.9787f082-a963-4c6a-9ad4-4916eeb6110f@github.com>
 <3KOWkW5WxXz7Kc-NXg4UHzB9Om6hXCCkMxsedHDfMJU=.f0e6ef27-71b0-4fea-b89a-682b3acfdac4@github.com>
Message-ID: <8af2801d-883a-9d61-772a-eeb9da13398e@oracle.com>


On 17/05/2023 02:33, John Hendrikx wrote:
> SymbolLookup lookUp = name -> library1.find(name)
>            .or(() -> library2.find(name))
>            .or(() -> loader.find(name));

What you say is true - e.g. the fact that a lookup returns an optional 
can be used to chain multiple lookups as you describe.

There are, however some difference - note that your example only uses 
"captures" symbol lookup variable names - so the full code would be more 
something like:

```java
SymbolLookup library1 = SymbolLookup.libraryLookup("lib1", arena);
SymbolLookup library2 = SymbolLookup.libraryLookup("lib2", arena);
SymbolLookup loader = SymbolLookup.loaderLookup();
SymbolLookup lookUp = name -> library1.find(name)
 ????????? .or(() -> library2.find(name))
 ????????? .or(() -> loader.find(name));
```

Without the initial setup, we could try to write something like this:

```java
SymbolLookup lookUp = name -> SymbolLookup.libraryLookup("lib1", 
arena).find(name)
 ????????? .or(() -> SymbolLookup.libraryLookup("lib2", arena).find(name))
 ????????? .or(() -> SymbolLookup.loaderLookup().find(name));
```

But this more compact version has several issues. First, it creates a 
new library lookup on each call to "find" (possibly more). Second, the 
loader in which the lookup is retrieved depends on who calls the "find" 
method.

So, the more compact version is not "like for like" for the more verbose 
option above. And this is due to the fact that, in most cases, 
retrieving a symbol lookup has some side-effects, such as loading a 
library - it is *not* a purely functional process.

With the new method, it becomes like this:

```java
SymbolLookup lookUp =SymbolLookup.libraryLookup("lib1", arena)
 ????????? .or(SymbolLookup.libraryLookup("lib2", arena))
 ????????? .or(SymbolLookup.loaderLookup());
```

So, not only the new method results in more succinct code (compared to 
the alternatives), but it also combines symbol lookups in the "right 
way", so that the chain of lookups is defined, once and for all, when 
the composite lookup is first created.

Cheers
Maurizio


From dfuchs at openjdk.org  Mon May 22 09:54:48 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 22 May 2023 09:54:48 GMT
Subject: RFR: 8308038:
 java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java
 timed out
In-Reply-To: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
References: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
Message-ID: <MZBCWV7TwyBS7o4G7AcJFJE8FENU8nCfgrH9orGJExk=.3ba1a4bb-fee6-403b-bf11-cfc19d197b09@github.com>

On Sun, 21 May 2023 13:52:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to the unit test for the ExecutorService returned by Executors.newThreadPerTaskExecutor. The tests for interrupting invokeAll assume the threads started to execute the tasks do actually execute the task code. The refresh in JEP 444 changed the implementation to use FutureTask, and FutureTask checks the interrupt status before it executes the task code. So some intermittent timeouts of the tests for interrupting invokeAll as those tests were waiting for the task to complete.
> 
> The main change is that the tests for interrupting invokeAll are changed to interrupt when the main thread blocks in invokeAll. They are also changed to check if the task started or not. The tests for interrupting invokeAny already did this, but these are changed to use the same infrastructure to avoid having two styles of tests in the same source file.

Looks reasonable. Just some question about testing invokeAll/invokeAny when there is only one task.

test/jdk/java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java line 578:

> 576:             try {
> 577:                 scheduleInterruptAt("java.util.concurrent.ThreadPerTaskExecutor.invokeAny");
> 578:                 executor.invokeAny(Set.of(task));

Seems strange to test invokeAny when there is only one task?

test/jdk/java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java line 835:

> 833:             try {
> 834:                 scheduleInterruptAt("java.util.concurrent.ThreadPerTaskExecutor.invokeAll");
> 835:                 executor.invokeAll(Set.of(task));

same remark for invokeAll?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14072#pullrequestreview-1436244152
PR Review Comment: https://git.openjdk.org/jdk/pull/14072#discussion_r1200271736
PR Review Comment: https://git.openjdk.org/jdk/pull/14072#discussion_r1200272685

From jpai at openjdk.org  Mon May 22 10:08:56 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 22 May 2023 10:08:56 GMT
Subject: RFR: 8308038:
 java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java
 timed out
In-Reply-To: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
References: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
Message-ID: <QkAv0mlfCjEMAsLhJZpS99oqnZgzylsaUW21HyudGQ0=.473409c8-50d6-4b8c-81f4-c480b38080d9@github.com>

On Sun, 21 May 2023 13:52:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to the unit test for the ExecutorService returned by Executors.newThreadPerTaskExecutor. The tests for interrupting invokeAll assume the threads started to execute the tasks do actually execute the task code. The refresh in JEP 444 changed the implementation to use FutureTask, and FutureTask checks the interrupt status before it executes the task code. So some intermittent timeouts of the tests for interrupting invokeAll as those tests were waiting for the task to complete.
> 
> The main change is that the tests for interrupting invokeAll are changed to interrupt when the main thread blocks in invokeAll. They are also changed to check if the task started or not. The tests for interrupting invokeAny already did this, but these are changed to use the same infrastructure to avoid having two styles of tests in the same source file.

test/jdk/java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java line 269:

> 267:         assertTrue(executor.awaitTermination(10, TimeUnit.MILLISECONDS));
> 268:         Throwable e = assertThrows(ExecutionException.class, future::get);
> 269:         assertTrue(e.getCause() instanceof InterruptedException);

Would using `assertEquals(InterruptedException.class, e.getCause().getClass())` be better? That way if/when the test fails, it even prints the unexpected exception type?

But I then see that this test already uses `assertTrue` for similar cases in some other place, so maybe it's fine in the current form?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14072#discussion_r1200291899

From asotona at openjdk.org  Mon May 22 10:09:52 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 22 May 2023 10:09:52 GMT
Subject: RFR: 8308093: Disable language preview features use in JDK
Message-ID: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>

This patch disables temporary use of language preview features in JDK.
Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary.
All redundant use of --enable-preview in the Classfile API tests are also removed.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8308093: Disable language preview features use in JDK

Changes: https://git.openjdk.org/jdk/pull/14076/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14076&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308093
  Stats: 24 lines in 12 files changed: 0 ins; 22 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14076.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14076/head:pull/14076

PR: https://git.openjdk.org/jdk/pull/14076

From alanb at openjdk.org  Mon May 22 10:13:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 May 2023 10:13:49 GMT
Subject: RFR: 8308038:
 java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java
 timed out
In-Reply-To: <QkAv0mlfCjEMAsLhJZpS99oqnZgzylsaUW21HyudGQ0=.473409c8-50d6-4b8c-81f4-c480b38080d9@github.com>
References: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
 <QkAv0mlfCjEMAsLhJZpS99oqnZgzylsaUW21HyudGQ0=.473409c8-50d6-4b8c-81f4-c480b38080d9@github.com>
Message-ID: <ZoaYFRYLZTyj4cOeE9C_1NWhMxfpTa76To8gfHRmQiI=.1192ede8-3287-4511-a77c-dad2052b64e5@github.com>

On Mon, 22 May 2023 10:05:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This is a test only change to the unit test for the ExecutorService returned by Executors.newThreadPerTaskExecutor. The tests for interrupting invokeAll assume the threads started to execute the tasks do actually execute the task code. The refresh in JEP 444 changed the implementation to use FutureTask, and FutureTask checks the interrupt status before it executes the task code. So some intermittent timeouts of the tests for interrupting invokeAll as those tests were waiting for the task to complete.
>> 
>> The main change is that the tests for interrupting invokeAll are changed to interrupt when the main thread blocks in invokeAll. They are also changed to check if the task started or not. The tests for interrupting invokeAny already did this, but these are changed to use the same infrastructure to avoid having two styles of tests in the same source file.
>
> test/jdk/java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java line 269:
> 
>> 267:         assertTrue(executor.awaitTermination(10, TimeUnit.MILLISECONDS));
>> 268:         Throwable e = assertThrows(ExecutionException.class, future::get);
>> 269:         assertTrue(e.getCause() instanceof InterruptedException);
> 
> Would using `assertEquals(InterruptedException.class, e.getCause().getClass())` be better? That way if/when the test fails, it even prints the unexpected exception type?
> 
> But I then see that this test already uses `assertTrue` for similar cases in some other place, so maybe it's fine in the current form?

I don't mind moving this but it would require changing them everywhere (as you point out).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14072#discussion_r1200299321

From alanb at openjdk.org  Mon May 22 10:13:53 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 May 2023 10:13:53 GMT
Subject: RFR: 8308038:
 java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java
 timed out
In-Reply-To: <MZBCWV7TwyBS7o4G7AcJFJE8FENU8nCfgrH9orGJExk=.3ba1a4bb-fee6-403b-bf11-cfc19d197b09@github.com>
References: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
 <MZBCWV7TwyBS7o4G7AcJFJE8FENU8nCfgrH9orGJExk=.3ba1a4bb-fee6-403b-bf11-cfc19d197b09@github.com>
Message-ID: <svIhXrORnlsih_fsiwo5_OEW7chVpb4uNvDdsIx0IwU=.acac5a03-97f3-498b-b04a-efc77be459e3@github.com>

On Mon, 22 May 2023 09:48:15 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Seems strange to test invokeAny when there is only one task?

There are several tests further up that exercise invokeAny with more than one task. This one is testing interrupt of invokeAny, we could expect it to test interrupting with many tasks if needed.

> test/jdk/java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java line 835:
> 
>> 833:             try {
>> 834:                 scheduleInterruptAt("java.util.concurrent.ThreadPerTaskExecutor.invokeAll");
>> 835:                 executor.invokeAll(Set.of(task));
> 
> same remark for invokeAll?

There are several tests further up that exercise invokeAll with more than one task.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14072#discussion_r1200295889
PR Review Comment: https://git.openjdk.org/jdk/pull/14072#discussion_r1200296492

From itakiguchi at openjdk.org  Mon May 22 10:22:20 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Mon, 22 May 2023 10:22:20 GMT
Subject: RFR: 8308046: Move Solaris related charsets from java.base to
 jdk.charsets module [v3]
In-Reply-To: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
Message-ID: <J8vcvL_IR3Q_Gcf-mN_TN8iVC8vvYkK85Rb3e-XwmzU=.d7039bdd-8d20-4681-bd55-54344eb6ac1a@github.com>

> According to "JDK 20 Internationalization Guide"
> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
> Following Solaris related charsets are in "contained in jdk.charsets module" list.
> 
> - PCK (x-PCK)
> - EUC_JP_Solaris (x-eucJP-Open)
> - Big5_Solaris (x-Big5-Solaris)
> 
> These are not supported by Linux platform, so they should not be in java.base module.
> 
> Note:
> GHA Linux x86 builds were failed.
> I think it's not related by my modified code.
> I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-8308051) GHA: Linux x86 builds failure

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8308046: Move Solaris related charsets from java.base to jdk.charsets module

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13973/files
  - new: https://git.openjdk.org/jdk/pull/13973/files/6fd12fcd..1c10b107

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13973&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13973&range=01-02

  Stats: 43 lines in 4 files changed: 0 ins; 29 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/13973.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13973/head:pull/13973

PR: https://git.openjdk.org/jdk/pull/13973

From simonis at openjdk.org  Mon May 22 10:22:16 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 22 May 2023 10:22:16 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v4]
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <5uakOuAdd9XDJ-E5ARGF6EFTixE7W9A5NzucACL3glE=.3dc3ff58-f186-4aa7-b311-792a10dabd86@github.com>

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into JDK-8307990
 - Address comments from tstuefe and RogerRiggs
 - REALLY adding the test :)
 - Added test case
 - 8307990: jspawnhelper must close its writing side of a pipe before reading from it

-------------

Changes: https://git.openjdk.org/jdk/pull/13956/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13956&range=03
  Stats: 260 lines in 5 files changed: 239 ins; 1 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/13956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13956/head:pull/13956

PR: https://git.openjdk.org/jdk/pull/13956

From simonis at openjdk.org  Mon May 22 10:22:17 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 22 May 2023 10:22:17 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v3]
In-Reply-To: <gYLF_feBOnLwYB8S4hbzPmCyqHT4u62UMzcJzcEFldA=.c6a55056-2779-42fa-a09d-d7152b8e5f4f@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <V6X7mD9t_bH6l8iYAxk2B8wszDqj8_Oa9zcgarrxotc=.6beeb6ad-6ddc-4ab4-a3c7-1c35050e3978@github.com>
 <gYLF_feBOnLwYB8S4hbzPmCyqHT4u62UMzcJzcEFldA=.c6a55056-2779-42fa-a09d-d7152b8e5f4f@github.com>
Message-ID: <tCCsSrhFAURFDXvgg969DBs4RVjKadEJ7PxiH3SzTf0=.ad36dc8f-fb92-4d9d-a67f-b86de71a34e3@github.com>

On Thu, 18 May 2023 05:58:26 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   REALLY adding the test :)
>
> src/java.base/unix/native/libjava/childproc.c line 413:
> 
>> 411:     const char* env = getenv("JTREG_JSPAWNHELPER_PROTOCOL_TEST");
>> 412:     if (env != NULL && atoi(env) == stage) {
>> 413:         printf("posix_spawn:%d\n", child);
> 
> I would do an `_exit()` here, not `exit()`, to prevent exit handlers from running. You want to simulate a sudden death. Or a `kill(getpid(), 9);`
> 
> Combine this with an explicit `fflush(stdout)` before to get your test output out.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1200309154

From duke at openjdk.org  Mon May 22 10:22:56 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Mon, 22 May 2023 10:22:56 GMT
Subject: RFR: 7065228: To interpret case-insensitive string locale
 independently [v2]
In-Reply-To: <MIanutU-5zaHU08XWWykYRu2HSZhUfGSr70gu9SZ2ug=.77440635-04f7-4cbe-b573-a2322fed985b@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
 <RJtvyPf1e7DskuTAmzyj9e1RGaU2y5_gIOqwW1KVTe4=.d5079753-cc5c-41bb-82d1-08c127d54097@github.com>
 <MIanutU-5zaHU08XWWykYRu2HSZhUfGSr70gu9SZ2ug=.77440635-04f7-4cbe-b573-a2322fed985b@github.com>
Message-ID: <_gCEzkKMiIQiTGFQMSmpM0E4xnXPig7RaUPT3tbZNts=.e904c7f1-cf98-4987-ad0f-861689b83078@github.com>

On Fri, 19 May 2023 11:24:30 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> Seems like a useful change and I can see how issues could arise if strings were stored somewhere after being upper/lower cased and then reused in a different locale.
> 
> Is it correct to say that the assumption is these strings are all supposed to be US ASCII (eg protocol defined identifiers, or hostnames etc) rather than user generated text strings? That seems to be the case as far as I can see.

Yes

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14006#issuecomment-1556955595

From mcimadamore at openjdk.org  Mon May 22 10:27:04 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 22 May 2023 10:27:04 GMT
Subject: RFR: 8308276: Change layout API to work with bytes, not bits [v4]
In-Reply-To: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
References: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
Message-ID: <hdvuP8mzt_svbvAgnrN-SWZlNIYqzFu6O6Leovmwcg8=.9c1696ba-51ce-487a-a617-d471b1ab4968@github.com>

> As explained in [1], memory layouts and memory segments describe sizes using different units. Memory layouts use bits, whereas memory segments use bytes. This is historical: memory layouts were designed after the Minimal LDL [2], which allowed layout strings to be used to describe both memory *and* register. In practice that ship has sailed, and the FFM API uses layouts to firmly model the contents of regions of memory. While it would be possible, in principle, to tweak segments to work on bits, changing that would have implications on how easily code that is currently using ByteBuffer can migrate to use MemorySegment.
> 
> For these reasons, this patch fixes the asymmetry so that layouts also model sizes in term of bytes.
> 
> The patch is straightforward, although a bit tedious (as you can imagine), as various uses of bit sizes had to be turned in byte sizes. In practice, the migration had not been too hard, for the following reasons:
> 
> * the `withBitAlignment` and `bitSize` methods are no longer in the API, it is easy to fix any code (mainly tests) using it;
> * most code already uses ready-made constants such as `JAVA_INT` - such code continues to work unchanged;
> * the layout API de facto already required clients to work with bit sizes that are a multiple of 8.
> 
> The only problematic case is the presence of the `MemoryLayout::paddingLayout(long size)` factory. As this factory is changed to deal in bytes instead of bits, all constants passed to this factory will need to be updated. This is not a problem for code using jextract (as jextract will take care of generating padding) but will be an issue for code using the layout API directly.
> 
> [1] - https://mail.openjdk.org/pipermail/panama-dev/2023-May/019059.html

Maurizio Cimadamore 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 'master' into bits_to_bytes_layouts
 - Address review comments
 - Update test/jdk/java/foreign/TestLayouts.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update test/jdk/java/foreign/TestLayoutPaths.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update test/jdk/java/foreign/TestLayoutPaths.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update test/jdk/java/foreign/TestLayoutPaths.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Update src/java.base/share/classes/jdk/internal/foreign/layout/ValueLayouts.java
   
   Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
 - Drop spurious reference to "bit"/"bits" in both javadoc and impl
 - Fix tests
 - Fix bad assertion in AbstractValueLayouts
   Fix vector tests to use withByteAlignment
 - ... and 1 more: https://git.openjdk.org/jdk/compare/8aa50288...145fb32d

-------------

Changes: https://git.openjdk.org/jdk/pull/14013/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14013&range=03
  Stats: 724 lines in 93 files changed: 3 ins; 197 del; 524 mod
  Patch: https://git.openjdk.org/jdk/pull/14013.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14013/head:pull/14013

PR: https://git.openjdk.org/jdk/pull/14013

From aturbanov at openjdk.org  Mon May 22 10:30:57 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 22 May 2023 10:30:57 GMT
Subject: RFR: 8305785: Avoid redundant HashMap.containsKey call in
 java.util.regex
In-Reply-To: <_WLYJq0pH0MAmUOuVtCJsRIYvmjtwi_cwW3_Wy341Ks=.17067b05-2a67-49f8-b167-6b2404165ae5@github.com>
References: <_WLYJq0pH0MAmUOuVtCJsRIYvmjtwi_cwW3_Wy341Ks=.17067b05-2a67-49f8-b167-6b2404165ae5@github.com>
Message-ID: <bIdFmekeRQLYOAJn0KSSfQjQTnu36pZeBj97hVIsj-E=.84c61041-8e41-475e-bbd3-431408d6f44b@github.com>

On Mon, 3 Apr 2023 16:58:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Pattern.namedGroups` and `Matcher.namedGroups` contains only non-null values. It means instead of separate `containsKey`+`get` calls, we can use single `HashMap.get` call and then compare result with null.
> Result code is a bit simpler and faster.

Thank you for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13303#issuecomment-1556966620

From aturbanov at openjdk.org  Mon May 22 10:30:59 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 22 May 2023 10:30:59 GMT
Subject: Integrated: 8305785: Avoid redundant HashMap.containsKey call in
 java.util.regex
In-Reply-To: <_WLYJq0pH0MAmUOuVtCJsRIYvmjtwi_cwW3_Wy341Ks=.17067b05-2a67-49f8-b167-6b2404165ae5@github.com>
References: <_WLYJq0pH0MAmUOuVtCJsRIYvmjtwi_cwW3_Wy341Ks=.17067b05-2a67-49f8-b167-6b2404165ae5@github.com>
Message-ID: <tbyJ6AK2VZbxtC47MLemumWKTyHwKJI69Jk8fI4Qj9k=.efa2cbb8-67bd-43a5-a4c0-b18e7bec4d93@github.com>

On Mon, 3 Apr 2023 16:58:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> `Pattern.namedGroups` and `Matcher.namedGroups` contains only non-null values. It means instead of separate `containsKey`+`get` calls, we can use single `HashMap.get` call and then compare result with null.
> Result code is a bit simpler and faster.

This pull request has now been integrated.

Changeset: 6b65e575
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b65e5754cc96c812892077881fc069e02fedc62
Stats:     10 lines in 2 files changed: 3 ins; 0 del; 7 mod

8305785: Avoid redundant HashMap.containsKey call in java.util.regex

Reviewed-by: stsypanov, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/13303

From jpai at openjdk.org  Mon May 22 10:34:48 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 22 May 2023 10:34:48 GMT
Subject: RFR: 8308038:
 java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java
 timed out
In-Reply-To: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
References: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
Message-ID: <Iy1B_54GsOMK3P59u-vqnNYTyM_v3RJZbAL95C4jHxM=.d30c32ee-5c3d-4ce1-a0bf-92ffbb063a46@github.com>

On Sun, 21 May 2023 13:52:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to the unit test for the ExecutorService returned by Executors.newThreadPerTaskExecutor. The tests for interrupting invokeAll assume the threads started to execute the tasks do actually execute the task code. The refresh in JEP 444 changed the implementation to use FutureTask, and FutureTask checks the interrupt status before it executes the task code. So some intermittent timeouts of the tests for interrupting invokeAll as those tests were waiting for the task to complete.
> 
> The main change is that the tests for interrupting invokeAll are changed to interrupt when the main thread blocks in invokeAll. They are also changed to check if the task started or not. The tests for interrupting invokeAny already did this, but these are changed to use the same infrastructure to avoid having two styles of tests in the same source file.

The change now waits for the current thread to reach a particular code location before interrupting the thread and then also verifies that the submitted task was indeed started, before checking that it is done. This I believe should solve the intermittent failures observed in this test.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14072#pullrequestreview-1436322155

From jpai at openjdk.org  Mon May 22 10:34:51 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 22 May 2023 10:34:51 GMT
Subject: RFR: 8308038:
 java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java
 timed out
In-Reply-To: <ZoaYFRYLZTyj4cOeE9C_1NWhMxfpTa76To8gfHRmQiI=.1192ede8-3287-4511-a77c-dad2052b64e5@github.com>
References: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
 <QkAv0mlfCjEMAsLhJZpS99oqnZgzylsaUW21HyudGQ0=.473409c8-50d6-4b8c-81f4-c480b38080d9@github.com>
 <ZoaYFRYLZTyj4cOeE9C_1NWhMxfpTa76To8gfHRmQiI=.1192ede8-3287-4511-a77c-dad2052b64e5@github.com>
Message-ID: <lrvIsgA2YFqkLU0OiJRzoUFC_jWxdzCPmFR4XefUWSE=.4bd344f2-dea4-44e3-bce6-6ebab3674752@github.com>

On Mon, 22 May 2023 10:11:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java line 269:
>> 
>>> 267:         assertTrue(executor.awaitTermination(10, TimeUnit.MILLISECONDS));
>>> 268:         Throwable e = assertThrows(ExecutionException.class, future::get);
>>> 269:         assertTrue(e.getCause() instanceof InterruptedException);
>> 
>> Would using `assertEquals(InterruptedException.class, e.getCause().getClass())` be better? That way if/when the test fails, it even prints the unexpected exception type?
>> 
>> But I then see that this test already uses `assertTrue` for similar cases in some other place, so maybe it's fine in the current form?
>
> I don't mind moving this but it would require changing them everywhere (as you point out).

I think it's fine to leave it in the current form then. If/when any of these tests fail due to unexpected exception type in these asserts, we can then move them all to the other proposed (or some other) construct.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14072#discussion_r1200321915

From simonis at openjdk.org  Mon May 22 10:47:52 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Mon, 22 May 2023 10:47:52 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <csdVRwugp359LIivw-fOUfIPvgLQhUYKy1terkI5zhY=.5b46222f-a203-45ed-9392-5deb035ce8b1@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <PhQwmHWsZpkaMtgk1o5cU8To6ltyCEk9NbOKa9LgDtI=.4f986b17-5117-4b47-a6bb-055a5f717694@github.com>
 <fYvBogZEfG6vz84VFk5ZYrdkDB98ij5klQ7F8YM6H0k=.99aeffad-fc37-4d61-a847-dbbd0b4bf91d@github.com>
 <NKcMniUs_0zJlCLT2gnPfqBIjOxQuA0lHdo1UqKS33Q=.41e36a92-1660-42a3-8fce-52edf9ab3b2f@github.com>
 <csdVRwugp359LIivw-fOUfIPvgLQhUYKy1terkI5zhY=.5b46222f-a203-45ed-9392-5deb035ce8b1@github.com>
Message-ID: <_YzMOLVvjhB0Aq9KdCSXzzhWegERaOkVVmHp66Nzmao=.fde2238f-d6d0-4e41-8d57-286b7141ec19@github.com>

On Wed, 17 May 2023 20:03:37 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > > Should this issue have a CSR for any behavioral changes?
> > 
> > 
> > Well, you can certainly argue that every bug fix is a behavioral changes, right :)
> > But seriously, I don't see how this PR could require a CSR. The only behavioral change is really that `jspawnhelper` can now no longer block and deadlock. But that's exactly how it should have behaved in the first place.
> 
> Yes, some judgement is needed on behavioral changes; this was broached in portions of my recent talk to the JCP EC:
> 
> "Contributing to OpenJDK: Participating in stewardship for the long-term" https://jcp.org/aboutJava/communityprocess/ec-public/materials/2023-04-12/Contributing_to_OpenJDK_2023_04_12.pdf
> 
> The process spawning code is apparently tricky and subtle, so much so that this will be apparently the third attempt at it since JDK 12. (I still have memories of various platform-specific issues in process handling from my time maintaining the launcher.)
> 
> So I don't think the applicability of a CSR for this change should be dismissed

I've created a [Release Note](https://bugs.openjdk.org/browse/JDK-8308297) (please feel to review it :) which outlines the "*behavioral change*". But this change is really just a simple bug fix for the case where the JVM leaves a hanging process (`jspawnhelper`) behind when it crashes. I don't really see see how a CSR will fit in here unless we start to treat crashes as "defined behavior" and start  tracking them across releases.

If you still think a CSR will be needed, please advice how it should look like?
 
>  and personally I would prefer a change like this be made early in JDK 22 rather than a few weeks before JDK 21 rampdown; it is easier to address any bug tail early in 22 rather than late in 21.

First, this is a bug fix for an issue which impacts production usage of the JDK. Second, tt's a "first-day" bug introduced by [JDK-5049299](https://bugs.openjdk.org/browse/JDK-5049299) for JDK 8 (initially only active on Solaris). It started to manifest on Linux in JDK 13 when the `POSIX_SPAWN` launching mechanism was ported to Linux as well, **but** it was only detected some time after JDK 17 was released when a higher rate of production services started to migrate to JDK 17.

I really don't want to go into a bike-shedding discussion about "*LTS releases are not special*", but I think this is a serious enough bug with a simple enough fix to resolve it as quick as possible (and downport it to JDK 17 as fast as possible). We are still more than two weeks before RDP 1 and we still have more than three month before GA so I don't see a reason not to fix this now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1556989917

From duke at openjdk.org  Mon May 22 10:57:02 2023
From: duke at openjdk.org (Darragh Clarke)
Date: Mon, 22 May 2023 10:57:02 GMT
Subject: Integrated: 7065228: To interpret case-insensitive string locale
 independently
In-Reply-To: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
References: <nlBqhQP-XwrL99Ffz-TMRIF2kYp2w47B8yzxeimiGHg=.1a26763f-1f01-4238-b278-e763c1aea050@github.com>
Message-ID: <UAfznS1njzmi0P8cL1j0-1NSA3gF-qhhWRAmqgiK0qM=.d8f27bbc-31d2-4936-9e23-1b7570696181@github.com>

On Tue, 16 May 2023 10:38:52 GMT, Darragh Clarke <duke at openjdk.org> wrote:

> Updated instances of `toLowerCase` and `toUpperCase` in several net and io files to specify `Locale.ROOT` to ensure that case conversion issues don't occur,
> 
> I didn't add any new tests but ran tier 1-3 with no issues

This pull request has now been integrated.

Changeset: 05e99db4
Author:    Darragh Clarke <darraghclarke98 at gmail.com>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/05e99db466e7ef5c26f089db772a21cb2ca62e93
Stats:     74 lines in 20 files changed: 14 ins; 0 del; 60 mod

7065228: To interpret case-insensitive string locale independently

Reviewed-by: dfuchs, naoto, djelinski, jpai, michaelm

-------------

PR: https://git.openjdk.org/jdk/pull/14006

From dfuchs at openjdk.org  Mon May 22 11:01:50 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 22 May 2023 11:01:50 GMT
Subject: RFR: 8308038:
 java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java
 timed out
In-Reply-To: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
References: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
Message-ID: <hn0nbWyAFQIp9f1xLPLXarsFcPUz_jq_bfnildjpw1Y=.34e08ee3-3182-41aa-bb35-abc77f3cddd8@github.com>

On Sun, 21 May 2023 13:52:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to the unit test for the ExecutorService returned by Executors.newThreadPerTaskExecutor. The tests for interrupting invokeAll assume the threads started to execute the tasks do actually execute the task code. The refresh in JEP 444 changed the implementation to use FutureTask, and FutureTask checks the interrupt status before it executes the task code. So some intermittent timeouts of the tests for interrupting invokeAll as those tests were waiting for the task to complete.
> 
> The main change is that the tests for interrupting invokeAll are changed to interrupt when the main thread blocks in invokeAll. They are also changed to check if the task started or not. The tests for interrupting invokeAny already did this, but these are changed to use the same infrastructure to avoid having two styles of tests in the same source file.

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14072#pullrequestreview-1436367855

From dfuchs at openjdk.org  Mon May 22 11:01:53 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 22 May 2023 11:01:53 GMT
Subject: RFR: 8308038:
 java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java
 timed out
In-Reply-To: <svIhXrORnlsih_fsiwo5_OEW7chVpb4uNvDdsIx0IwU=.acac5a03-97f3-498b-b04a-efc77be459e3@github.com>
References: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
 <MZBCWV7TwyBS7o4G7AcJFJE8FENU8nCfgrH9orGJExk=.3ba1a4bb-fee6-403b-bf11-cfc19d197b09@github.com>
 <svIhXrORnlsih_fsiwo5_OEW7chVpb4uNvDdsIx0IwU=.acac5a03-97f3-498b-b04a-efc77be459e3@github.com>
Message-ID: <y_evGwQeP__R2E7kFM4INhbAyy28j6gdhtD1DcysIXs=.a7c68039-2187-4146-aee0-85f34010d605@github.com>

On Mon, 22 May 2023 10:09:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java line 578:
>> 
>>> 576:             try {
>>> 577:                 scheduleInterruptAt("java.util.concurrent.ThreadPerTaskExecutor.invokeAny");
>>> 578:                 executor.invokeAny(Set.of(task));
>> 
>> Seems strange to test invokeAny when there is only one task?
>
>> Seems strange to test invokeAny when there is only one task?
> 
> There are several tests further up that exercise invokeAny with more than one task. This one is testing interrupt of invokeAny, we could expect it to test interrupting with many tasks if needed.

OK - looks fine to me then.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14072#discussion_r1200349759

From alanb at openjdk.org  Mon May 22 11:21:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 May 2023 11:21:49 GMT
Subject: RFR: 8308038:
 java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java
 timed out
In-Reply-To: <lrvIsgA2YFqkLU0OiJRzoUFC_jWxdzCPmFR4XefUWSE=.4bd344f2-dea4-44e3-bce6-6ebab3674752@github.com>
References: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
 <QkAv0mlfCjEMAsLhJZpS99oqnZgzylsaUW21HyudGQ0=.473409c8-50d6-4b8c-81f4-c480b38080d9@github.com>
 <ZoaYFRYLZTyj4cOeE9C_1NWhMxfpTa76To8gfHRmQiI=.1192ede8-3287-4511-a77c-dad2052b64e5@github.com>
 <lrvIsgA2YFqkLU0OiJRzoUFC_jWxdzCPmFR4XefUWSE=.4bd344f2-dea4-44e3-bce6-6ebab3674752@github.com>
Message-ID: <RkwTko8Ew0nhm8HAkvBz2gJfnMK8AplkpOEvfGW9fus=.710ae305-c96e-48dc-bdd9-bd19236e7412@github.com>

On Mon, 22 May 2023 10:30:27 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I don't mind moving this but it would require changing them everywhere (as you point out).
>
> I think it's fine to leave it in the current form then. If/when any of these tests fail due to unexpected exception type in these asserts, we can then move them all to the other proposed (or some other) construct.

Yes, as we really want an instanceof check here, the exception could be a subclass.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14072#discussion_r1200372861

From eliu at openjdk.org  Mon May 22 11:46:54 2023
From: eliu at openjdk.org (Eric Liu)
Date: Mon, 22 May 2023 11:46:54 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
 [v3]
In-Reply-To: <cXXQlLg77sWd5xEttH2vIPlxbFItZxSdz7qW4oZLAds=.dc774213-d8ec-4fc9-be0a-d70579cc20df@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
 <cXXQlLg77sWd5xEttH2vIPlxbFItZxSdz7qW4oZLAds=.dc774213-d8ec-4fc9-be0a-d70579cc20df@github.com>
Message-ID: <-bS3aIFdUhBDKMi5yZO9rHTnaPvEi3OSewrDNZfgau8=.e309e65b-a566-456b-bb45-2db59ad460fd@github.com>

On Thu, 18 May 2023 09:50:13 GMT, Chang Peng <duke at openjdk.org> wrote:

>> In Vector API Java level, vector mask is represented as a boolean array with 0x00/0x01 (8 bits of each element) as values, aka in-memory format. When it is loaded into vector register, e.g. Neon, the in-memory format will be converted to in-register format with 0/-1 value for each lane (lane width aligned to its type) by VectorLoadMask [1] operation, and convert back to in-memory format by VectorStoreMask[2]. In Neon, a typical VectorStoreMask operation will first narrow given vector registers by xtn insn [3] into byte element type, and then do a vector negate to convert to 0x00/0x01 value for each element.
>> 
>> For most of the vector mask operations, the input mask is in-register format. And a vector mask also works in-register format all through the compilation. But for some operations like VectorMask.trueCount()[4] which counts the elements of true value, the expected input mask is in-memory format. So a VectorStoreMask is generated to convert the mask from in-register format to in-memory format before those operations.
>> 
>> However, for trueCount() these xtn instructions in VectorStoreMask can be saved, since the narrowing operations will not influence the number of active lane (value of 0x01) of its input.
>> 
>> This patch adds an optimized rule `VectorMaskTrueCount (VectorStoreMask mask)` to save the unnecessary narrowing operations.
>> 
>> For example,
>> 
>> 
>> var m = VectorMask.fromArray(IntVector.SPECIES_PREFERRED, ba, 0);
>> m.not().trueCount();
>> 
>> 
>> will produce following assembly on a Neon machine before this patch:
>> 
>> 
>> ...
>> mvn     v16.16b, v16.16b           // VectorMask.not()
>> xtn     v16.4h, v16.4s
>> xtn     v16.8b, v16.8h
>> neg     v16.8b, v16.8b             // VectorStoreMask
>> addv    b17, v16.8b
>> umov    w0, v17.b[0]               // VectorMask.trueCount()
>> ...
>> 
>> 
>> After this patch:
>> 
>> 
>> ...
>> mvn     v16.16b, v16.16b           // VectorMask.not()
>> addv    s17, v16.4s
>> smov    x0, v17.b[0]
>> neg     x0, x0                     // Optimized VectorMask.trueCount()
>> ...
>> 
>> 
>> In this case, we can save two xtn insns.
>> 
>> Performance:
>> 
>> Benchmark     Before               After                          Unit
>> testInt           723.822 ? 1.029  1182.375 ? 12.363    ops/ms
>> testLong       632.154 ? 0.197  1382.74 ? 2.188        ops/ms
>> testShort      788.665 ? 1.852   1152.38 ? 3.77         ops/ms
>> 
>> [1]: https://github.com/openjdk/jdk/blob/e1e758a7b43c29840296d337bd2f0213ab0ca3c9/src/hotspot/cpu/aarch64/aarch64_vect...
>
> Chang Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update benchmark to avoid potential optimization

LGTM.

-------------

Marked as reviewed by eliu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13974#pullrequestreview-1436444533

From liach at openjdk.org  Mon May 22 11:52:50 2023
From: liach at openjdk.org (Chen Liang)
Date: Mon, 22 May 2023 11:52:50 GMT
Subject: RFR: 8308093: Disable language preview features use in JDK
In-Reply-To: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
References: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
Message-ID: <qX58dhWRNH6VktuPwVW2vPwXmVmBNvUtGj2PU8agNT4=.a282ff03-b62c-4290-80f5-834122c6965e@github.com>

On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch disables temporary use of language preview features in JDK.
> Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary.
> All redundant use of --enable-preview in the Classfile API tests are also removed.
> 
> Please review.
> 
> Thanks,
> Adam

The enable-preview for jmh benchmark compilation exists before Classfile API integration, so this should be it.

-------------

Marked as reviewed by liach (Author).

PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1436460682

From rrich at openjdk.org  Mon May 22 12:18:08 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 22 May 2023 12:18:08 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v31]
In-Reply-To: <r1q_PmuWWnewZrJYJtRY7GROVRgy0Uy1Hqd0NbCt__M=.bcb5cf75-966a-403f-8362-8f37948a1f86@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <mPbG06Sl25MLR9FNrcDkNFzkcsb_h9TbwBKD71XzVcU=.e4221c6b-24ff-4049-be5e-4fce4381e9d0@github.com>
 <r1q_PmuWWnewZrJYJtRY7GROVRgy0Uy1Hqd0NbCt__M=.bcb5cf75-966a-403f-8362-8f37948a1f86@github.com>
Message-ID: <gkL8LsfdCt9YXWYFO39c6tbfLuZeQS_Qx8qW2VDYYmE=.5e3b9495-2192-47d0-8610-2e9162276bd3@github.com>

On Mon, 22 May 2023 08:53:21 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Cleanup imports, improve comments, updates from other platforms.
>
> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 65:
> 
>> 63:  */
>> 64: public abstract class CallArranger {
>> 65:     protected abstract boolean useABIv2();
> 
> This could also be refactored into a static method with the same trick that is used in `LinuxPPC64leLinker::getInstance`. Callers could be static then and you could delete `CallArranger::ABIv2` and `ABIv2CallArranger`.

Maybe something like?

    protected static final boolean useABIv2 = CABI.current() == CABI.LINUX_PPC_64_LE;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1200432599

From mdoerr at openjdk.org  Mon May 22 12:42:08 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 May 2023 12:42:08 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v31]
In-Reply-To: <gkL8LsfdCt9YXWYFO39c6tbfLuZeQS_Qx8qW2VDYYmE=.5e3b9495-2192-47d0-8610-2e9162276bd3@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <mPbG06Sl25MLR9FNrcDkNFzkcsb_h9TbwBKD71XzVcU=.e4221c6b-24ff-4049-be5e-4fce4381e9d0@github.com>
 <r1q_PmuWWnewZrJYJtRY7GROVRgy0Uy1Hqd0NbCt__M=.bcb5cf75-966a-403f-8362-8f37948a1f86@github.com>
 <gkL8LsfdCt9YXWYFO39c6tbfLuZeQS_Qx8qW2VDYYmE=.5e3b9495-2192-47d0-8610-2e9162276bd3@github.com>
Message-ID: <WQKxIlZbPz6P8dldBxm8G_Qj7MKDla-GV-oi0ZW-lus=.8805e90c-f5f1-4ce7-810e-bd3814dcbcea@github.com>

On Mon, 22 May 2023 12:14:48 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 65:
>> 
>>> 63:  */
>>> 64: public abstract class CallArranger {
>>> 65:     protected abstract boolean useABIv2();
>> 
>> This could also be refactored into a static method with the same trick that is used in `LinuxPPC64leLinker::getInstance`. Callers could be static then and you could delete `CallArranger::ABIv2` and `ABIv2CallArranger`.
>
> Maybe something like?
> 
>     protected static final boolean useABIv2 = CABI.current() == CABI.LINUX_PPC_64_LE;

That would be better to read, but would make the PPC64 CallArranger dependent on the current CABI.
Note that there are tests which use

import jdk.internal.foreign.abi.aarch64.CallArranger;
...
CallArranger.LINUX.getBindings(mt, fd, false);

for example. The tests are designed to run on all platforms.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1200459227

From pminborg at openjdk.org  Mon May 22 12:44:42 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 22 May 2023 12:44:42 GMT
Subject: RFR: 8308281: Java snippets in the FFM API need to be updated [v3]
In-Reply-To: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>
References: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>
Message-ID: <FJA-z7zSZTt5UBgV4GDzr2vBepn18Sz0qC2A9L3nTkI=.5be0ba96-e094-44a1-bbde-32f13326d056@github.com>

> As the API has improved over the recent releases, not all `{@snippet ..}` sections have been kept in sync.
> 
> This PR suggests all snippets used should be verified against real code that is placed in a new `snippet-files` folder and erroneous snippets are updated.
> 
> In this PR, it is suggested duplicating code in the `Snippets.java` class and in the JavaDocs. The benefit of this is that code is directly visible in the code and not only in the generated javadoc.
> 
> Another thing to think about is if there should be on single `Snippets.java` class or separate ones for each FFM class.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Use hybrid snippets for Arena

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14030/files
  - new: https://git.openjdk.org/jdk/pull/14030/files/2cbff9c3..df59d9fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14030&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14030&range=01-02

  Stats: 75 lines in 2 files changed: 20 ins; 13 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/14030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14030/head:pull/14030

PR: https://git.openjdk.org/jdk/pull/14030

From erikj at openjdk.org  Mon May 22 12:52:52 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 22 May 2023 12:52:52 GMT
Subject: RFR: 8308093: Disable language preview features use in JDK
In-Reply-To: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
References: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
Message-ID: <HIsKi4fLu1ikw-T19ccsiPYu3Kgp172dhS8LJhNFhBA=.7002159b-69e4-46e7-9648-2179e6d96343@github.com>

On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch disables temporary use of language preview features in JDK.
> Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary.
> All redundant use of --enable-preview in the Classfile API tests are also removed.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1436562362

From alanb at openjdk.org  Mon May 22 13:01:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 May 2023 13:01:49 GMT
Subject: RFR: 8308093: Disable language preview features use in JDK
In-Reply-To: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
References: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
Message-ID: <mrsrNAxweMnt-pB_0o5XkHsb-6MSNNzqpSIzYt11_z0=.28d8a7ab-2795-4e0c-ab4b-8ac51d2aa514@github.com>

On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch disables temporary use of language preview features in JDK.
> Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary.
> All redundant use of --enable-preview in the Classfile API tests are also removed.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1436580302

From duke at openjdk.org  Mon May 22 13:18:55 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 22 May 2023 13:18:55 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java timed
 out
Message-ID: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>

Doubling the max heap size since not all GCs might have compressed OOPs, so this change should make this test more robust.

Cleared with @DougLea

-------------

Commit messages:
 - JDK-8298066: Increasing max heap size for OOMEinAQS since not all GCs might have compressed oops

Changes: https://git.openjdk.org/jdk/pull/14082/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14082&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8298066
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14082/head:pull/14082

PR: https://git.openjdk.org/jdk/pull/14082

From alanb at openjdk.org  Mon May 22 13:30:50 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 May 2023 13:30:50 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out
In-Reply-To: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
Message-ID: <-R-w4-Pz5g28MPD64fFKsM_QE81Z-WT3nYgveFinhHE=.78191104-9a31-4cfb-b0ed-7b19882737b5@github.com>

On Mon, 22 May 2023 13:12:02 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Doubling the max heap size since not all GCs might have compressed OOPs, so this change should make this test more robust.
> 
> Cleared with @DougLea

Should the test be removed from ProblemList-generational-zgc.txt as part of this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14082#issuecomment-1557224363

From rrich at openjdk.org  Mon May 22 13:32:02 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 22 May 2023 13:32:02 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v31]
In-Reply-To: <WQKxIlZbPz6P8dldBxm8G_Qj7MKDla-GV-oi0ZW-lus=.8805e90c-f5f1-4ce7-810e-bd3814dcbcea@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <mPbG06Sl25MLR9FNrcDkNFzkcsb_h9TbwBKD71XzVcU=.e4221c6b-24ff-4049-be5e-4fce4381e9d0@github.com>
 <r1q_PmuWWnewZrJYJtRY7GROVRgy0Uy1Hqd0NbCt__M=.bcb5cf75-966a-403f-8362-8f37948a1f86@github.com>
 <gkL8LsfdCt9YXWYFO39c6tbfLuZeQS_Qx8qW2VDYYmE=.5e3b9495-2192-47d0-8610-2e9162276bd3@github.com>
 <WQKxIlZbPz6P8dldBxm8G_Qj7MKDla-GV-oi0ZW-lus=.8805e90c-f5f1-4ce7-810e-bd3814dcbcea@github.com>
Message-ID: <VIQ6QbAZXOic1VS6vFBgMEY2AsXSJHJsST_n3xPzIDA=.33cf0525-15b1-4c63-bd02-b81bfab2740d@github.com>

On Mon, 22 May 2023 12:38:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> That would be better to read, but would make the PPC64 CallArranger dependent on the current CABI. Note that there are tests which use
> 
> ```
> import jdk.internal.foreign.abi.aarch64.CallArranger;
> ...
> CallArranger.LINUX.getBindings(mt, fd, false);
> ```
> 
> for example. The tests are designed to run on all platforms.

I see, thanks. Would be nice to have some for PPC64 too :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1200520623

From duke at openjdk.org  Mon May 22 13:36:49 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 22 May 2023 13:36:49 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out
In-Reply-To: <-R-w4-Pz5g28MPD64fFKsM_QE81Z-WT3nYgveFinhHE=.78191104-9a31-4cfb-b0ed-7b19882737b5@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
 <-R-w4-Pz5g28MPD64fFKsM_QE81Z-WT3nYgveFinhHE=.78191104-9a31-4cfb-b0ed-7b19882737b5@github.com>
Message-ID: <6wzr6FDgGolZyNfudAor73J3bg4oj1aTWNzsM3D0xSw=.c5fec5f3-e88b-4aad-af42-50d62edb9c76@github.com>

On Mon, 22 May 2023 13:28:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Doubling the max heap size since not all GCs might have compressed OOPs, so this change should make this test more robust.
>> 
>> Cleared with @DougLea
>
> Should the test be removed from ProblemList-generational-zgc.txt as part of this?

@AlanBateman My thinking was to integrate this and make sure that the problem doesn't resurface before removing it from the problem list. Does that make sense? ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14082#issuecomment-1557232300

From mdoerr at openjdk.org  Mon May 22 13:38:04 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 May 2023 13:38:04 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v31]
In-Reply-To: <VIQ6QbAZXOic1VS6vFBgMEY2AsXSJHJsST_n3xPzIDA=.33cf0525-15b1-4c63-bd02-b81bfab2740d@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <mPbG06Sl25MLR9FNrcDkNFzkcsb_h9TbwBKD71XzVcU=.e4221c6b-24ff-4049-be5e-4fce4381e9d0@github.com>
 <r1q_PmuWWnewZrJYJtRY7GROVRgy0Uy1Hqd0NbCt__M=.bcb5cf75-966a-403f-8362-8f37948a1f86@github.com>
 <gkL8LsfdCt9YXWYFO39c6tbfLuZeQS_Qx8qW2VDYYmE=.5e3b9495-2192-47d0-8610-2e9162276bd3@github.com>
 <WQKxIlZbPz6P8dldBxm8G_Qj7MKDla-GV-oi0ZW-lus=.8805e90c-f5f1-4ce7-810e-bd3814dcbcea@github.com>
 <VIQ6QbAZXOic1VS6vFBgMEY2AsXSJHJsST_n3xPzIDA=.33cf0525-15b1-4c63-bd02-b81bfab2740d@github.com>
Message-ID: <yQc4xkGpD1ZQVJp3qAP3KCDhvRHk92N4AeqPPnnZc0M=.27a655f8-749a-4d5d-947f-fca02c2ddaee@github.com>

On Mon, 22 May 2023 13:29:14 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> That would be better to read, but would make the PPC64 CallArranger dependent on the current CABI.
>> Note that there are tests which use
>> 
>> import jdk.internal.foreign.abi.aarch64.CallArranger;
>> ...
>> CallArranger.LINUX.getBindings(mt, fd, false);
>> 
>> for example. The tests are designed to run on all platforms.
>
>> That would be better to read, but would make the PPC64 CallArranger dependent on the current CABI. Note that there are tests which use
>> 
>> ```
>> import jdk.internal.foreign.abi.aarch64.CallArranger;
>> ...
>> CallArranger.LINUX.getBindings(mt, fd, false);
>> ```
>> 
>> for example. The tests are designed to run on all platforms.
> 
> I see, thanks. Would be nice to have some for PPC64 too :)

Probably, yes. I didn't find time for figuring out what would be useful tests. We could still add some in the future or with the big endian port.
Another idea: Would the following be better?
`final boolean useABIv2 = (this.getClass() == ABIv2CallArranger.class);`
That would also allow getting rid of the method `useABIv2()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1200527513

From mdoerr at openjdk.org  Mon May 22 13:45:12 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 May 2023 13:45:12 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v31]
In-Reply-To: <yQc4xkGpD1ZQVJp3qAP3KCDhvRHk92N4AeqPPnnZc0M=.27a655f8-749a-4d5d-947f-fca02c2ddaee@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <mPbG06Sl25MLR9FNrcDkNFzkcsb_h9TbwBKD71XzVcU=.e4221c6b-24ff-4049-be5e-4fce4381e9d0@github.com>
 <r1q_PmuWWnewZrJYJtRY7GROVRgy0Uy1Hqd0NbCt__M=.bcb5cf75-966a-403f-8362-8f37948a1f86@github.com>
 <gkL8LsfdCt9YXWYFO39c6tbfLuZeQS_Qx8qW2VDYYmE=.5e3b9495-2192-47d0-8610-2e9162276bd3@github.com>
 <WQKxIlZbPz6P8dldBxm8G_Qj7MKDla-GV-oi0ZW-lus=.8805e90c-f5f1-4ce7-810e-bd3814dcbcea@github.com>
 <VIQ6QbAZXOic1VS6vFBgMEY2AsXSJHJsST_n3xPzIDA=.33cf0525-15b1-4c63-bd02-b81bfab2740d@github.com>
 <yQc4xkGpD1ZQVJp3qAP3KCDhvRHk92N4AeqPPnnZc0M=.27a655f8-749a-4d5d-947f-fca02c2ddaee@github.com>
Message-ID: <BnUnowpbcxEF6NP5OiUyp9E_9xFVV65obWsC7nuti5E=.e03967f6-9d58-4760-9c58-aff3d0934cd5@github.com>

On Mon, 22 May 2023 13:34:49 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>>> That would be better to read, but would make the PPC64 CallArranger dependent on the current CABI. Note that there are tests which use
>>> 
>>> ```
>>> import jdk.internal.foreign.abi.aarch64.CallArranger;
>>> ...
>>> CallArranger.LINUX.getBindings(mt, fd, false);
>>> ```
>>> 
>>> for example. The tests are designed to run on all platforms.
>> 
>> I see, thanks. Would be nice to have some for PPC64 too :)
>
> Probably, yes. I didn't find time for figuring out what would be useful tests. We could still add some in the future or with the big endian port.
> Another idea: Would the following be better?
> `final boolean useABIv2 = (this.getClass() == ABIv2CallArranger.class);`
> That would also allow getting rid of the method `useABIv2()`.

Or better `final boolean useABIv2 = (this instanceof ABIv2CallArranger);`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1200537482

From rrich at openjdk.org  Mon May 22 14:02:04 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 22 May 2023 14:02:04 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v31]
In-Reply-To: <BnUnowpbcxEF6NP5OiUyp9E_9xFVV65obWsC7nuti5E=.e03967f6-9d58-4760-9c58-aff3d0934cd5@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <mPbG06Sl25MLR9FNrcDkNFzkcsb_h9TbwBKD71XzVcU=.e4221c6b-24ff-4049-be5e-4fce4381e9d0@github.com>
 <r1q_PmuWWnewZrJYJtRY7GROVRgy0Uy1Hqd0NbCt__M=.bcb5cf75-966a-403f-8362-8f37948a1f86@github.com>
 <gkL8LsfdCt9YXWYFO39c6tbfLuZeQS_Qx8qW2VDYYmE=.5e3b9495-2192-47d0-8610-2e9162276bd3@github.com>
 <WQKxIlZbPz6P8dldBxm8G_Qj7MKDla-GV-oi0ZW-lus=.8805e90c-f5f1-4ce7-810e-bd3814dcbcea@github.com>
 <VIQ6QbAZXOic1VS6vFBgMEY2AsXSJHJsST_n3xPzIDA=.33cf0525-15b1-4c63-bd02-b81bfab2740d@github.com>
 <yQc4xkGpD1ZQVJp3qAP3KCDhvRHk92N4AeqPPnnZc0M=.27a655f8-749a-4d5d-947f-fca02c2ddaee@github.com>
 <BnUnowpbcxEF6NP5OiUyp9E_9xFVV65obWsC7nuti5E=.e03967f6-9d58-4760-9c58-aff3d0934cd5@github.com>
Message-ID: <BmwKleK8i3eKTUAj9FFeUhLSiw3OMCGwnFpL5_C3NwA=.264ca5f4-c900-4f91-b0e8-c3ba16099005@github.com>

On Mon, 22 May 2023 13:42:27 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Probably, yes. I didn't find time for figuring out what would be useful tests. We could still add some in the future or with the big endian port.
>> Another idea: Would the following be better?
>> `final boolean useABIv2 = (this.getClass() == ABIv2CallArranger.class);`
>> That would also allow getting rid of the method `useABIv2()`.
>
> Or better `final boolean useABIv2 = (this instanceof ABIv2CallArranger);`

Yes, good idea.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1200558827

From mdoerr at openjdk.org  Mon May 22 14:18:56 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 May 2023 14:18:56 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v32]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <YyEo3LZUIwyHE7SzBcovcco-rfTHMZ_yJkEjuYmEjss=.d6355690-a299-44d1-8982-18fcb95de909@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: T...

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Replace abstract method useABIv2().

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/b1f04382..70736be6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=30-31

  Stats: 13 lines in 2 files changed: 0 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From mdoerr at openjdk.org  Mon May 22 14:19:02 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 May 2023 14:19:02 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v31]
In-Reply-To: <BmwKleK8i3eKTUAj9FFeUhLSiw3OMCGwnFpL5_C3NwA=.264ca5f4-c900-4f91-b0e8-c3ba16099005@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <mPbG06Sl25MLR9FNrcDkNFzkcsb_h9TbwBKD71XzVcU=.e4221c6b-24ff-4049-be5e-4fce4381e9d0@github.com>
 <r1q_PmuWWnewZrJYJtRY7GROVRgy0Uy1Hqd0NbCt__M=.bcb5cf75-966a-403f-8362-8f37948a1f86@github.com>
 <gkL8LsfdCt9YXWYFO39c6tbfLuZeQS_Qx8qW2VDYYmE=.5e3b9495-2192-47d0-8610-2e9162276bd3@github.com>
 <WQKxIlZbPz6P8dldBxm8G_Qj7MKDla-GV-oi0ZW-lus=.8805e90c-f5f1-4ce7-810e-bd3814dcbcea@github.com>
 <VIQ6QbAZXOic1VS6vFBgMEY2AsXSJHJsST_n3xPzIDA=.33cf0525-15b1-4c63-bd02-b81bfab2740d@github.com>
 <yQc4xkGpD1ZQVJp3qAP3KCDhvRHk92N4AeqPPnnZc0M=.27a655f8-749a-4d5d-947f-fca02c2ddaee@github.com>
 <BnUnowpbcxEF6NP5OiUyp9E_9xFVV65obWsC7nuti5E=.e03967f6-9d58-4760-9c58-aff3d0934cd5@github.com>
 <BmwKleK8i3eKTUAj9FFeUhLSiw3OMCGwnFpL5_C3NwA=.264ca5f4-c900-4f91-b0e8-c3ba16099005@github.com>
Message-ID: <RF92AKAzaDtfeobWN24XSP1aHGzWVTNb9pjlb3FLrc0=.7739fd4b-8482-414d-a7fd-fd2eb3396ba6@github.com>

On Mon, 22 May 2023 13:59:05 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Or better `final boolean useABIv2 = (this instanceof ABIv2CallArranger);`
>
> Yes, good idea.

Please take a look at https://github.com/openjdk/jdk/pull/12708/commits/70736be631e4f1bf3fd3c0d45ddfc076b74ef9dd

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1200571704

From rrich at openjdk.org  Mon May 22 14:19:06 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 22 May 2023 14:19:06 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v31]
In-Reply-To: <RF92AKAzaDtfeobWN24XSP1aHGzWVTNb9pjlb3FLrc0=.7739fd4b-8482-414d-a7fd-fd2eb3396ba6@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <mPbG06Sl25MLR9FNrcDkNFzkcsb_h9TbwBKD71XzVcU=.e4221c6b-24ff-4049-be5e-4fce4381e9d0@github.com>
 <r1q_PmuWWnewZrJYJtRY7GROVRgy0Uy1Hqd0NbCt__M=.bcb5cf75-966a-403f-8362-8f37948a1f86@github.com>
 <gkL8LsfdCt9YXWYFO39c6tbfLuZeQS_Qx8qW2VDYYmE=.5e3b9495-2192-47d0-8610-2e9162276bd3@github.com>
 <WQKxIlZbPz6P8dldBxm8G_Qj7MKDla-GV-oi0ZW-lus=.8805e90c-f5f1-4ce7-810e-bd3814dcbcea@github.com>
 <VIQ6QbAZXOic1VS6vFBgMEY2AsXSJHJsST_n3xPzIDA=.33cf0525-15b1-4c63-bd02-b81bfab2740d@github.com>
 <yQc4xkGpD1ZQVJp3qAP3KCDhvRHk92N4AeqPPnnZc0M=.27a655f8-749a-4d5d-947f-fca02c2ddaee@github.com>
 <BnUnowpbcxEF6NP5OiUyp9E_9xFVV65obWsC7nuti5E=.e03967f6-9d58-4760-9c58-aff3d0934cd5@github.com>
 <BmwKleK8i3eKTUAj9FFeUhLSiw3OMCGwnFpL5_C3NwA=.264ca5f4-c900-4f91-b0e8-c3ba16099005@github.com>
 <RF92AKAzaDtfeobWN24XSP1aHGzWVTNb9pjlb3FLrc0=.7739fd4b-8482-414d-a7fd-fd2eb3396ba6@github.com>
Message-ID: <TpgMG5tWe1VqXQTDsTcOcTatyFM7_sR9q_SyVlGGJAg=.2cdfeabf-1272-41f4-9734-4ec1fce097a4@github.com>

On Mon, 22 May 2023 14:09:22 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Yes, good idea.
>
> Please take a look at https://github.com/openjdk/jdk/pull/12708/commits/70736be631e4f1bf3fd3c0d45ddfc076b74ef9dd

It looks good.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1200576857

From avu at openjdk.org  Mon May 22 14:21:56 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Mon, 22 May 2023 14:21:56 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <zpNLQSOrVJgeXGKdOj7HN7OzGZLg376AEB9rRUqOMok=.79d48b95-421c-40fc-b007-b6815f710413@github.com>

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

I would suggest either disable warnings on per file basis or rewrite problematic code.  Disabling warnings per fragment of code makes it less readable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1557306893

From itakiguchi at openjdk.org  Mon May 22 14:21:56 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Mon, 22 May 2023 14:21:56 GMT
Subject: RFR: 8308046: Move Solaris related charsets from java.base to
 jdk.charsets module [v2]
In-Reply-To: <txZ17bmXVyokeDGUg0Nv7coyls0P9nd4s95qyxFY3rA=.4fe47161-b45c-436f-9074-1aa6df738958@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
 <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
 <4yFGg-CgLRvNAEB7tpVH9Bi13fdlyAAdVniQnYoZcX4=.32f55011-db19-4c15-adc1-7cfc4cd564a6@github.com>
 <URWJaXXaEzUAWnM0t0t_VFs-eSpBxYhrWKpHL1Dd1b4=.456a44fc-ce38-46ee-ba17-48fd37df65f5@github.com>
 <Of7--k3lQYJdoaAusVAhJB6XzmAoxuYD5FMm7P448P8=.2e742cdb-d7f5-4f38-87de-ff5725fec96b@github.com>
 <txZ17bmXVyokeDGUg0Nv7coyls0P9nd4s95qyxFY3rA=.4fe47161-b45c-436f-9074-1aa6df738958@github.com>
Message-ID: <5wQGcZRhWrV_goUQTe5OSychMbzEE8oO5vphXyPSmH8=.4005b3d4-9034-4759-8d1d-e353b913c8a9@github.com>

On Sat, 20 May 2023 17:26:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello @naotoj .
>> I'd like to confirm about DoubleByte-X.java.template and EUC_JP.java.template.
>> I think the values are package-private.
>> Even if class is changed to `public`, the classes in`sun.nio.cs.ext` package could not access to these values in `sun.nio.cs` package...
>> I may be misunderstanding your suggestion, could you tell me more ?
>
>> I think the values are package-private. Even if class is changed to `public`, the classes in`sun.nio.cs.ext` package could not access to these values in `sun.nio.cs` package... 
> 
> I meant making those package-private fields public. I believe it's OK because java.base/sun.nio.cs package is only exported to jdk.charsets module.

Thanks @naotoj .
I changed related fields to `public`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1557308396

From pminborg at openjdk.org  Mon May 22 14:32:01 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 22 May 2023 14:32:01 GMT
Subject: RFR: 8308276: Change layout API to work with bytes, not bits [v4]
In-Reply-To: <hdvuP8mzt_svbvAgnrN-SWZlNIYqzFu6O6Leovmwcg8=.9c1696ba-51ce-487a-a617-d471b1ab4968@github.com>
References: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
 <hdvuP8mzt_svbvAgnrN-SWZlNIYqzFu6O6Leovmwcg8=.9c1696ba-51ce-487a-a617-d471b1ab4968@github.com>
Message-ID: <8VZNRL2U3mditLdOtSrXckJUE5RIez0yv4WL7D--E6c=.2657b8a9-25df-4fb1-83a6-d712b7e4cdce@github.com>

On Mon, 22 May 2023 10:27:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> As explained in [1], memory layouts and memory segments describe sizes using different units. Memory layouts use bits, whereas memory segments use bytes. This is historical: memory layouts were designed after the Minimal LDL [2], which allowed layout strings to be used to describe both memory *and* register. In practice that ship has sailed, and the FFM API uses layouts to firmly model the contents of regions of memory. While it would be possible, in principle, to tweak segments to work on bits, changing that would have implications on how easily code that is currently using ByteBuffer can migrate to use MemorySegment.
>> 
>> For these reasons, this patch fixes the asymmetry so that layouts also model sizes in term of bytes.
>> 
>> The patch is straightforward, although a bit tedious (as you can imagine), as various uses of bit sizes had to be turned in byte sizes. In practice, the migration had not been too hard, for the following reasons:
>> 
>> * the `withBitAlignment` and `bitSize` methods are no longer in the API, it is easy to fix any code (mainly tests) using it;
>> * most code already uses ready-made constants such as `JAVA_INT` - such code continues to work unchanged;
>> * the layout API de facto already required clients to work with bit sizes that are a multiple of 8.
>> 
>> The only problematic case is the presence of the `MemoryLayout::paddingLayout(long size)` factory. As this factory is changed to deal in bytes instead of bits, all constants passed to this factory will need to be updated. This is not a problem for code using jextract (as jextract will take care of generating padding) but will be an issue for code using the layout API directly.
>> 
>> [1] - https://mail.openjdk.org/pipermail/panama-dev/2023-May/019059.html
>
> Maurizio Cimadamore 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 'master' into bits_to_bytes_layouts
>  - Address review comments
>  - Update test/jdk/java/foreign/TestLayouts.java
>    
>    Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
>  - Update test/jdk/java/foreign/TestLayoutPaths.java
>    
>    Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
>  - Update test/jdk/java/foreign/TestLayoutPaths.java
>    
>    Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
>  - Update test/jdk/java/foreign/TestLayoutPaths.java
>    
>    Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
>  - Update src/java.base/share/classes/jdk/internal/foreign/layout/ValueLayouts.java
>    
>    Co-authored-by: Paul Sandoz <paul.d.sandoz at googlemail.com>
>  - Drop spurious reference to "bit"/"bits" in both javadoc and impl
>  - Fix tests
>  - Fix bad assertion in AbstractValueLayouts
>    Fix vector tests to use withByteAlignment
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/8aa50288...145fb32d

LGTM.

-------------

Marked as reviewed by pminborg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14013#pullrequestreview-1436768257

From pminborg at openjdk.org  Mon May 22 14:37:58 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 22 May 2023 14:37:58 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v4]
In-Reply-To: <mNvyH9yRqp0OZJdx10SwbRBgyqTq_QdXGB-qHeTQ8B8=.c3bc2710-e51a-4855-a18e-0e3cbee33281@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <mNvyH9yRqp0OZJdx10SwbRBgyqTq_QdXGB-qHeTQ8B8=.c3bc2710-e51a-4855-a18e-0e3cbee33281@github.com>
Message-ID: <UC3hGHb8s_29SUC3Qz8HhKKtV9Gk4rB2GQRdfie1Sq8=.d7259916-b9eb-4c04-b016-1a64a5afcaf5@github.com>

On Mon, 22 May 2023 09:34:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address further review comments

LGTM. Are there any additional types we might consider apart from the basic ones and `size_t`? Maybe one for an address pointing at `errno`?

-------------

Marked as reviewed by pminborg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14037#pullrequestreview-1436779774

From alanb at openjdk.org  Mon May 22 14:48:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 May 2023 14:48:49 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out
In-Reply-To: <-R-w4-Pz5g28MPD64fFKsM_QE81Z-WT3nYgveFinhHE=.78191104-9a31-4cfb-b0ed-7b19882737b5@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
 <-R-w4-Pz5g28MPD64fFKsM_QE81Z-WT3nYgveFinhHE=.78191104-9a31-4cfb-b0ed-7b19882737b5@github.com>
Message-ID: <OxNrLd5U4zRCrdWWu64DL6kOLlAtJNUXx-WP7_xf8HU=.45473fff-c298-4c52-a0b6-b91d72769bc6@github.com>

On Mon, 22 May 2023 13:28:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Doubling the max heap size since not all GCs might have compressed OOPs, so this change should make this test more robust.
>> 
>> Cleared with @DougLea
>
> Should the test be removed from ProblemList-generational-zgc.txt as part of this?

> @AlanBateman My thinking was to integrate this and make sure that the problem doesn't resurface before removing it from the problem list. Does that make sense? ?

No objection, it's just it would leave ProblemList-generational-zgc.txt listing a test against as issue marked as fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14082#issuecomment-1557352028

From mcimadamore at openjdk.org  Mon May 22 14:55:04 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 22 May 2023 14:55:04 GMT
Subject: Integrated: 8287834: Add SymbolLookup::or method
In-Reply-To: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
References: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
Message-ID: <ugDluXH5L7vPN6sjrB57AWrPVW8eFfd982T5O1W_-0Y=.6349ff8c-928e-4f60-aaec-13f4ff47f52c@github.com>

On Fri, 12 May 2023 12:11:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds a simpler method for composing symbol lookups. It is common for clients to chain multiple symbol lookups together, e.g. to find a symbol in multiple libraries.
> 
> A new instance method, namely `SymbolLookup::or` is added, which first searches a symbol in the first lookup, and, if that fails, proceeds to search the symbol in the provided lookup.
> 
> We have considered alternatives to express this, such as a static factory `SymbolLookup::ofComposite` but settled on this because of the similarity with `Optional::or`.

This pull request has now been integrated.

Changeset: 91aeb5de
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91aeb5de580633dfc361957051cd00545aa883c7
Stats:     167 lines in 2 files changed: 167 ins; 0 del; 0 mod

8287834: Add SymbolLookup::or method

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/13954

From mcimadamore at openjdk.org  Mon May 22 15:00:00 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 22 May 2023 15:00:00 GMT
Subject: Integrated: 8308276: Change layout API to work with bytes, not bits
In-Reply-To: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
References: <YAQneCZK9CcEocWPMNbuuVnBsmvN2xDZ7bSawyvPosk=.ebb9f276-832c-4ec2-8855-f525567087f8@github.com>
Message-ID: <6COUdMDvZCId6U8GdjLEWBuDC9mk-F21lWR0Z-QkuAo=.47c5f1ec-1a5e-42b1-8d75-db38b7efd25f@github.com>

On Tue, 16 May 2023 13:53:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> As explained in [1], memory layouts and memory segments describe sizes using different units. Memory layouts use bits, whereas memory segments use bytes. This is historical: memory layouts were designed after the Minimal LDL [2], which allowed layout strings to be used to describe both memory *and* register. In practice that ship has sailed, and the FFM API uses layouts to firmly model the contents of regions of memory. While it would be possible, in principle, to tweak segments to work on bits, changing that would have implications on how easily code that is currently using ByteBuffer can migrate to use MemorySegment.
> 
> For these reasons, this patch fixes the asymmetry so that layouts also model sizes in term of bytes.
> 
> The patch is straightforward, although a bit tedious (as you can imagine), as various uses of bit sizes had to be turned in byte sizes. In practice, the migration had not been too hard, for the following reasons:
> 
> * the `withBitAlignment` and `bitSize` methods are no longer in the API, it is easy to fix any code (mainly tests) using it;
> * most code already uses ready-made constants such as `JAVA_INT` - such code continues to work unchanged;
> * the layout API de facto already required clients to work with bit sizes that are a multiple of 8.
> 
> The only problematic case is the presence of the `MemoryLayout::paddingLayout(long size)` factory. As this factory is changed to deal in bytes instead of bits, all constants passed to this factory will need to be updated. This is not a problem for code using jextract (as jextract will take care of generating padding) but will be an issue for code using the layout API directly.
> 
> [1] - https://mail.openjdk.org/pipermail/panama-dev/2023-May/019059.html

This pull request has now been integrated.

Changeset: 5fc9b578
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5fc9b5787dc4d7f00d2c59288bc8d840fdf5b495
Stats:     724 lines in 93 files changed: 3 ins; 197 del; 524 mod

8308276: Change layout API to work with bytes, not bits

Reviewed-by: psandoz, pminborg

-------------

PR: https://git.openjdk.org/jdk/pull/14013

From rriggs at openjdk.org  Mon May 22 15:01:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 22 May 2023 15:01:56 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v4]
In-Reply-To: <5uakOuAdd9XDJ-E5ARGF6EFTixE7W9A5NzucACL3glE=.3dc3ff58-f186-4aa7-b311-792a10dabd86@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <5uakOuAdd9XDJ-E5ARGF6EFTixE7W9A5NzucACL3glE=.3dc3ff58-f186-4aa7-b311-792a10dabd86@github.com>
Message-ID: <-N5GoZTMkqwWTnLVs4zXVJeC6FHA6cBq01ClpgrGMpE=.ed5246f3-d77e-4b39-9c2e-26464812220a@github.com>

On Mon, 22 May 2023 10:22:16 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8307990
>  - Address comments from tstuefe and RogerRiggs
>  - REALLY adding the test :)
>  - Added test case
>  - 8307990: jspawnhelper must close its writing side of a pipe before reading from it

Look good, thanks for the cleanup.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13956#pullrequestreview-1436831675

From pminborg at openjdk.org  Mon May 22 15:28:04 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 22 May 2023 15:28:04 GMT
Subject: RFR: 8307205: Downcall to clibrary printf fails on OS X AArch64
Message-ID: <RGUsFPlKWiBPknSzRmsKio30igmDt5EEm9skeIkYBrU=.8b32e588-3cc8-458e-af45-623f7f553a24@github.com>

This PR adds a test that shows the documented way of calling `printf` works.

-------------

Commit messages:
 - Add test for issue

Changes: https://git.openjdk.org/jdk/pull/14088/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14088&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307205
  Stats: 22 lines in 1 file changed: 22 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14088.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14088/head:pull/14088

PR: https://git.openjdk.org/jdk/pull/14088

From psandoz at openjdk.org  Mon May 22 15:59:10 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Mon, 22 May 2023 15:59:10 GMT
Subject: RFR: 8287834: Add SymbolLookup::or method
In-Reply-To: <8af2801d-883a-9d61-772a-eeb9da13398e@oracle.com>
References: <CUulW9KGCqOFnsZl3Qfw_87KLmUK-FDfHjmGZJ-EgCo=.9b208a6a-da1e-4817-bf4a-09f108c63c02@github.com>
 <8af2801d-883a-9d61-772a-eeb9da13398e@oracle.com>
Message-ID: <b__H8ZGFxaAdygI3wOJ_s32AmvCC-aa-8NW3WVjiyCE=.b26ff972-f954-4749-96cf-a20701aeb55f@github.com>

On Mon, 22 May 2023 11:51:33 GMT, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:

> So, not only the new method results in more succinct code (compared to the alternatives), but it also combines symbol lookups in the "right way", so that the chain of lookups is defined, once and for all, when the composite lookup is first created.
>

Yes, it's composition of *lookups* not composition of their results.
 
Paul.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13954#issuecomment-1557478950

From mdoerr at openjdk.org  Mon May 22 16:06:02 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 May 2023 16:06:02 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v33]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <-4sIEOVwyrDPTp4DKnIJnoWau845QEXn3aTOkS9FLp8=.6c87bc30-c614-4b1c-8a72-51214bff444d@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: T...

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Add comment about Register Save Area.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/70736be6..ac5c5dcc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=31-32

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From darcy at openjdk.org  Mon May 22 16:28:52 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 22 May 2023 16:28:52 GMT
Subject: RFR: 8308093: Disable language preview features use in JDK
In-Reply-To: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
References: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
Message-ID: <6W0aexRp4fpOKLKKklkPohKXNP6yGQEVHOAKaHotvPQ=.64d8fc08-4c59-4186-b031-b66b215710d6@github.com>

On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch disables temporary use of language preview features in JDK.
> Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary.
> All redundant use of --enable-preview in the Classfile API tests are also removed.
> 
> Please review.
> 
> Thanks,
> Adam

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14076#pullrequestreview-1437004246

From sgehwolf at openjdk.org  Mon May 22 17:03:23 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 22 May 2023 17:03:23 GMT
Subject: RFR: 8308090: Add container tests for on-the-fly resource quota
 updates
Message-ID: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>

Please review these test changes which implement automatic testing of container resource updates without JVM restart. Note that this merely tests container detection code handling this case. It doesn't do anything special for the JVM itself, though it might make sense to add some sanity checks should we detect certain limits changing. In another PR, though.

As to the test design, it works similar to the shared temp tests: Interact between the two containers by virtue of a shared filesystem `/tmp` and creating marker files there in order to make them cooperate. Note that the new test needs `podman` version `4.3.0` and better (`4.5` is current).

Testing:
 - [ ] GHA (still running)
 - [x] Linux x86_64 container tests on cg v1 and cg v2 system
 - [x] Newly added tests on Linux x86_64 cg v1 and cg v2 (`podman` and `docker`)

-------------

Commit messages:
 - Fix whitespace
 - 8308090: Add container tests for on-the-fly resource quota updates

Changes: https://git.openjdk.org/jdk/pull/14090/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14090&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308090
  Stats: 434 lines in 5 files changed: 431 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14090.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14090/head:pull/14090

PR: https://git.openjdk.org/jdk/pull/14090

From mcimadamore at openjdk.org  Mon May 22 17:05:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 22 May 2023 17:05:55 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v4]
In-Reply-To: <UC3hGHb8s_29SUC3Qz8HhKKtV9Gk4rB2GQRdfie1Sq8=.d7259916-b9eb-4c04-b016-1a64a5afcaf5@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <mNvyH9yRqp0OZJdx10SwbRBgyqTq_QdXGB-qHeTQ8B8=.c3bc2710-e51a-4855-a18e-0e3cbee33281@github.com>
 <UC3hGHb8s_29SUC3Qz8HhKKtV9Gk4rB2GQRdfie1Sq8=.d7259916-b9eb-4c04-b016-1a64a5afcaf5@github.com>
Message-ID: <oPJtSWkGlwxv3im7AVab0eUfA_uHN5Z7B1xfSC_5wDc=.fce2a505-67c8-417a-bdc5-ff30fe84c06c@github.com>

On Mon, 22 May 2023 14:34:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> LGTM. Are there any additional types we might consider apart from the basic ones and `size_t`? Maybe one for an address pointing at `errno`?

I think there is a certain gravitational pull towards keeping the set of guaranteed canonical layouts as minimal as possible. In that sense pointer to errno seems not to meet the bar IMHO. (also note that one could always ask the captureStateLayout, and figure out how to express the errno type from there).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1557585319

From naoto at openjdk.org  Mon May 22 17:12:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 May 2023 17:12:51 GMT
Subject: RFR: 8308046: Move Solaris related charsets from java.base to
 jdk.charsets module [v3]
In-Reply-To: <J8vcvL_IR3Q_Gcf-mN_TN8iVC8vvYkK85Rb3e-XwmzU=.d7039bdd-8d20-4681-bd55-54344eb6ac1a@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <J8vcvL_IR3Q_Gcf-mN_TN8iVC8vvYkK85Rb3e-XwmzU=.d7039bdd-8d20-4681-bd55-54344eb6ac1a@github.com>
Message-ID: <bruRq4_rndaaAGQ20uFof_oRIKzcwENRgORd4JYHbek=.74cf4bd6-b37f-4418-8739-2ca06d63c05d@github.com>

On Mon, 22 May 2023 10:22:20 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> According to "JDK 20 Internationalization Guide"
>> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
>> Following Solaris related charsets are in "contained in jdk.charsets module" list.
>> 
>> - PCK (x-PCK)
>> - EUC_JP_Solaris (x-eucJP-Open)
>> - Big5_Solaris (x-Big5-Solaris)
>> 
>> These are not supported by Linux platform, so they should not be in java.base module.
>> 
>> Note:
>> GHA Linux x86 builds were failed.
>> I think it's not related by my modified code.
>> I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-8308051) GHA: Linux x86 builds failure
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308046: Move Solaris related charsets from java.base to jdk.charsets module

Looks good. I think you may want to change `stdcs-aix` as well.
As to the JBS issue, please change the title to match the PR title, and add `noreg-cleanup` label

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13973#pullrequestreview-1437077458

From naoto at openjdk.org  Mon May 22 17:59:18 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 May 2023 17:59:18 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v5]
In-Reply-To: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
Message-ID: <EodPecDgFYPgwrX60SZVYwbAk5uflaH4yZmEXVpBCQ4=.109c0fa1-06a1-405b-88fb-d889b3258309@github.com>

> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Further clarifying the method description

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14040/files
  - new: https://git.openjdk.org/jdk/pull/14040/files/1cfc09b6..83cfe984

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14040&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14040&range=03-04

  Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14040.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14040/head:pull/14040

PR: https://git.openjdk.org/jdk/pull/14040

From naoto at openjdk.org  Mon May 22 18:04:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 May 2023 18:04:52 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v5]
In-Reply-To: <EodPecDgFYPgwrX60SZVYwbAk5uflaH4yZmEXVpBCQ4=.109c0fa1-06a1-405b-88fb-d889b3258309@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <EodPecDgFYPgwrX60SZVYwbAk5uflaH4yZmEXVpBCQ4=.109c0fa1-06a1-405b-88fb-d889b3258309@github.com>
Message-ID: <uLO774ItDztVTaRqnBWqk4v4PEBKrRFK61rKT6Z9KU8=.f4c35968-f5e2-4b03-8eb5-d10890a5797e@github.com>

On Mon, 22 May 2023 17:59:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further clarifying the method description

Thanks, Alan. Clarified the method doc based on your suggestion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14040#issuecomment-1557663088

From prr at openjdk.org  Mon May 22 18:04:51 2023
From: prr at openjdk.org (Phil Race)
Date: Mon, 22 May 2023 18:04:51 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <x_mmgeePvt94ApbI3L5Ubj7b0rwLdJI5CE5tSf7kTuk=.131f868d-52b7-4439-9957-a9b39a996046@github.com>

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

I don't like this approach at all. if github had a "reject" button I'd be pushing it now.
updating the makefiles is the normal way to do this but I don't know if we even want that.
Until clang is the supported compiler for Linux then I see no reason for this to be in JDK at all.

Code changes which make it so there's no warning would be the preferred way but I'd expect that to be tested properly. Also if the warning is spurious - sometimes they are - then that would NOT be appropriate.

-------------

Changes requested by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1437172390

From john.r.rose at oracle.com  Mon May 22 18:29:40 2023
From: john.r.rose at oracle.com (John Rose)
Date: Mon, 22 May 2023 11:29:40 -0700
Subject: Exposing checked exceptions that a MethodHandle can throw
In-Reply-To: <1476800905.60149992.1684676866306.JavaMail.zimbra@univ-eiffel.fr>
References: <CABe8uE06fhHacUU0=nBuiFS5pbVcfyUnxih3TtBQ_KgTc69bbA@mail.gmail.com>
 <1476800905.60149992.1684676866306.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <883A750E-EB8D-4D7E-A434-6C18D4D5EF32@oracle.com>

Thanks for the good response Remi.
This is part of a larger FAQ, ?why are MHs hard to use??
Part of the answer is ?they model bytecode behavior?.
(Perhaps they should have been called BytecodeBehaviorHandles.)

Lifting such raw VM-level behaviors up into Java source code is 
necessary, but it will never be pleasant, at least not until Java has 
enough capabilities in its syntax and type system to model such beasties 
without extra layers of object wrapping.

That would include fully incorporating exception checking into the 
generic type system, a hard problem.  It would also involve making some 
way to name a Java method (perhaps as `Foo::bar` or `myFoo::bar` or some 
lambda) but get a MH out of the expression.  Also some kinds of varargs 
processing might be needed to ?add suger? to varargs-related MH 
transforms.

The amount of Java language engineering necessary for such things is so 
large it will never be done, if MHs are the only use case.  There are 
far too many important improvements to make.  (Thought experiment:  
Should we drop some part of the pattern matching work in order to make 
room for method handle exception checks?  I thought not.)

Perhaps in the future there will come a time when exception checking is 
tracked and/or `Foo::bar` syntax is made more generic, and that will 
benefit MHs, but if it happens it will be for a list of weighty reasons, 
apart from MHs.

For now, MH code has to be written in a low-level style in Java source 
code.  (But it works beautifully at the assembly code level, if you are 
spinning bytecodes.)  For example, Java source methods which exist to 
process MHs should just declare `throws Throwable`.  Then you catch the 
non-existent throwables at the boundary.

You can make this a little easier on yourself, sometimes, if you write a 
higher-order helper function that takes a Throwable-throwing lambda and 
sanitizes it down to the exceptions you expect.  Then there?s just one 
clunky `catch`, and your low-level Throwable-throwing code goes inside 
lambda bodies.

On 21 May 2023, at 6:47, Remi Forax wrote:

> ----- Original Message -----
>> From: "-" <liangchenblue at gmail.com>
>> To: "core-libs-dev" <core-libs-dev at openjdk.org>
>> Sent: Sunday, May 21, 2023 6:52:44 AM
>> Subject: Exposing checked exceptions that a MethodHandle can throw
>
>> Hello,
>> I am eliciting a discussion on the feasibility of tracking checked
>> exceptions thrown by a MethodHandle. It is already requested in
>> https://bugs.openjdk.org/browse/JDK-8268116 as it appears useful in
>> the development of Foreign Function Interface API.
>
> At the bytecode level, checked exceptions are stored in an attribute 
> associated to a method.
> https://docs.oracle.com/javase/specs/jvms/se20/html/jvms-4.html#jvms-4.7.5
>
> If you have a direct MethodHandle, you can already get the checked 
> exceptions using Lookup.revealDirect() + MethodHandleInfo.reflectAs().
>
>>
>> Currently, explicit MethodHandle usages are hampered by the catch
>> block as the invoke methods are declared to throw any Throwable. 
>> Could
>> it be possible that we specify the types of possible exceptions at
>> MethodHandle invocation, so that:
>> 1. Javac accepts code that just call the handle without ugly 
>> try-catch block
>> 2. If the exceptions anticipated at invocation site are incompatible
>> with (i.e. more specific than) those declared by the invoked handle,
>> it can throw an exception like the existing 
>> `WrongMethodTypeException`
>> eagerly.
>
> The bug you reference seems to be about runtime information, but the 
> paragraph above is about type-checking information.
> The question here is "is the Java type system good enough to track 
> checked exception in a backward compatible way ?"
> Practically, I believe the answer is no, you can not compose function 
> with different type parameters representing exception, there is no 
> varargs of type parameters, there is no default type argument for a 
> type parameter, etc.
>
> It's also significant departure of the way the method handle API is 
> created, the idea behind is that each combiner has the semantics of an 
> existing bytecode. But all invoke* bytecodes are oblivious to 
> exception. Said differently, the method handle API represent how the 
> JVM works, not how Java the language works.
>
>>
>> Is such a plan feasible? Tracking of exceptions should be easy from
>> Direct MH and the MethodHandles combinators already, while the
>> invocation semantics update might be more complex, maybe in the form
>> of compiler-inserted stubs before the actual invoke calls. I wish 
>> such
>> improvements can make MethodHandle more friendly to direct usages in
>> code, so users don't need to wrap MH invocations in try-catch blocks
>> everywhere.
>
> see above.
>
>>
>> Chen Liang
>
> R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230522/8c38a393/attachment.htm>

From aturbanov at openjdk.org  Mon May 22 18:33:50 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 22 May 2023 18:33:50 GMT
Subject: RFR: 8305538: Avoid redundant HashMap.containsKey call in
 ModuleDescriptor.Builder [v2]
In-Reply-To: <YUsGhFl8t78O8CaDlAl_Ha8lNPEzaMxs9IcDPS76Txo=.43dd77f4-322e-4bda-b6fa-2377159a6e72@github.com>
References: <cwKHk3sU2rRXKv4jNF2Biij7dPqlFQva3hBb8ZlVm-4=.18a6501d-db9d-44f4-9297-4e6dfa39c2e8@github.com>
 <YUsGhFl8t78O8CaDlAl_Ha8lNPEzaMxs9IcDPS76Txo=.43dd77f4-322e-4bda-b6fa-2377159a6e72@github.com>
Message-ID: <NI2-63UgeJg1jOQZHjPA63PdnjDGqxXMlfuKD6AcbtE=.1aedb508-754b-46ab-8936-664caa84e87f@github.com>

On Tue, 4 Apr 2023 20:50:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> `Map.containsKey` call is sometimes unnecessary, when it's known that `Map` doesn't contain `null` values.
>> Instead of pair containsKey+put we can use putIfAbsent and compare result with null.
>> Result code is shorter and a bit faster.
>> Same approach is used with `HashSet<String> uses` in `java.lang.module.ModuleDescriptor.Builder#uses`. Instead of separate `contains`+`add` - we can just call `add` then check what it returns.
>> 
>> Testing: Linux x64 `java/lang`
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8305538: Avoid redundant HashMap.containsKey call in ModuleDescriptor.Builder
>   
>   update java.lang.module.ModuleDescriptor.Builder.uses too

let's wait for review a bit more

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13288#issuecomment-1557703281

From archie.cobbs at gmail.com  Mon May 22 17:16:15 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 22 May 2023 12:16:15 -0500
Subject: javac to emit static flag for local and anonymous classes in
 static contexts
In-Reply-To: <CABe8uE0M8EE_Z4hLNYuk865fD22xeF4o=dQkm2iaAqAqO2_bFw@mail.gmail.com>
References: <CABe8uE0M8EE_Z4hLNYuk865fD22xeF4o=dQkm2iaAqAqO2_bFw@mail.gmail.com>
Message-ID: <CANSoFxvmeVQf_A0fP8vimZRT5DAwdqRZoMZ1LwkOvU-AcBe-gg@mail.gmail.com>

Hi Liang,

On Sun, May 21, 2023 at 11:29?PM - <liangchenblue at gmail.com> wrote:

> Thus, I suggest emitting static flags for the InnerClasses attribute
> of anonymous/local classes in static/pre-initialization contexts,
>

Related to your question on PR#13656 ... local/anonymous classes in a
pre-initialization context (which we're now calling a "pre-construction"
context) are not static, they're just not instantiable until after
superclass construction.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230522/d3b9b2fb/attachment.htm>

From jiangli at openjdk.org  Mon May 22 19:14:00 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 22 May 2023 19:14:00 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <axH2L8Xbo_ay03Sh4my9Zm69fjIZLG4siwfLtP_iI4c=.a11629bc-45c7-43ff-9e2b-fd150dcf6ace@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
 <axH2L8Xbo_ay03Sh4my9Zm69fjIZLG4siwfLtP_iI4c=.a11629bc-45c7-43ff-9e2b-fd150dcf6ace@github.com>
Message-ID: <mTfRnDj0EpOBp46MFua8u-fMCxWQhtvzkfLTyM1sajw=.2cafff2a-7198-4722-a1dc-a2f0f72d2c5c@github.com>

On Fri, 19 May 2023 22:45:16 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> make/common/NativeCompilation.gmk line 1208:
>> 
>>> 1206: 	  $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \
>>> 1207: 	     $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \
>>> 1208:                  $$($1_LD_OBJ_ARG))
>> 
>> This command line is missing `$$($1_SYSROOT_LDFLAGS)` which is causing it to fail in our builds with:
>> 
>> ld: library not found for -lSystem
>
> This is the mac failure, sorry if that wasn't clear.

Thanks @erikj79. Could you please help provide some more info on the build failure:

Which macOs version ran into the build issue? My mac is on Ventura 13.3.1 (a). It builds successfully for the `static-libs-image` target.

Does it fail when partially linking `libjvm_relocatable.o` only, or it fails when partially linking other native libraries as well on macosx? Could you please share the partial linking command, e.g. hotspot/variant-server/libjvm/gtest/objs/static/BUILD_GTEST_LIBJVM_partial_link.cmdline?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200929473

From jiangli at openjdk.org  Mon May 22 19:24:52 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 22 May 2023 19:24:52 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries
In-Reply-To: <mTfRnDj0EpOBp46MFua8u-fMCxWQhtvzkfLTyM1sajw=.2cafff2a-7198-4722-a1dc-a2f0f72d2c5c@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
 <axH2L8Xbo_ay03Sh4my9Zm69fjIZLG4siwfLtP_iI4c=.a11629bc-45c7-43ff-9e2b-fd150dcf6ace@github.com>
 <mTfRnDj0EpOBp46MFua8u-fMCxWQhtvzkfLTyM1sajw=.2cafff2a-7198-4722-a1dc-a2f0f72d2c5c@github.com>
Message-ID: <IjC2q-lB9OZy36wkztu4ok7G00occGcHBAYWFMmtzGI=.10771dd2-bae1-4077-8e6e-06d1d3af4ca4@github.com>

On Mon, 22 May 2023 19:10:57 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Thanks @erikj79. Could you please help provide some more info on the build failure:
> 
> Which macOs version ran into the build issue? My mac is on Ventura 13.3.1 (a). It builds successfully for the `static-libs-image` target.
> 
> Does it fail when partially linking `libjvm_relocatable.o` only, or it fails when partially linking other native libraries as well on macosx? Could you please share the partial linking command, e.g. hotspot/variant-server/libjvm/gtest/objs/static/BUILD_GTEST_LIBJVM_partial_link.cmdline?

Additional info, following is the partial linking command from my `macosx-x86_64` build:


/usr/bin/g++ -m64 -r -o /.../github/JDK-8307858/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/gtest/objs/static/libjvm_relocatable.o @/.../github/JDK-8307858/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/gtest/objs/static/_BUILD_GTEST_LIBJVM_objectfilenames.txt

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200946838

From rriggs at openjdk.org  Mon May 22 19:31:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 22 May 2023 19:31:03 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v8]
In-Reply-To: <M9zVErlCn0A2sEt_iOGlAh3pypQmmY43hB1QVOncwlA=.22a1d957-3165-465d-80db-f678d31f4048@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <M9zVErlCn0A2sEt_iOGlAh3pypQmmY43hB1QVOncwlA=.22a1d957-3165-465d-80db-f678d31f4048@github.com>
Message-ID: <70nu7qZqJSWf13HVFRnxYCbE1QJovmEuJXZ2M7dVVIg=.0da39bf9-c641-41d5-b090-a071e8bd97d7@github.com>

On Thu, 18 May 2023 19:14:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308016: Address reviewer comments since previous commit

Thanks for the updates.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13957#pullrequestreview-1437322626

From jiangli at openjdk.org  Mon May 22 19:40:00 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 22 May 2023 19:40:00 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v2]
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com>

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into JDK-8307858
 - Merge branch 'master' into JDK-8307858
 - Clean up.
 - In clude $MACHINE_FLAG in partial linking flag.
 - Use '-m32' instead of '-m elf_i386'.
 - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform.
   
   It's based on the post on https://www.linuxquestions.org/questions/linux-software-2/relocatable-linking-on-x86-64-for-i386-872812/.
 - Only do partial linking step with gcc/clang on 64-bit platform.
   
   There is a linking failure with linux-x86 build:
   
   /usr/bin/ld: relocatable linking with relocations from format elf32-i386 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/gmock-all.o) to format elf64-x86-64 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/libgtest_relocatable.o) is not supported
 - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG.
 - Merge branch 'master' into JDK-8307858
 - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change.
 - ... and 2 more: https://git.openjdk.org/jdk/compare/8474e693...fb945210

-------------

Changes: https://git.openjdk.org/jdk/pull/14064/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=01
  Stats: 201 lines in 10 files changed: 150 ins; 34 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064

PR: https://git.openjdk.org/jdk/pull/14064

From erikj at openjdk.org  Mon May 22 19:47:51 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 22 May 2023 19:47:51 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v2]
In-Reply-To: <IjC2q-lB9OZy36wkztu4ok7G00occGcHBAYWFMmtzGI=.10771dd2-bae1-4077-8e6e-06d1d3af4ca4@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
 <axH2L8Xbo_ay03Sh4my9Zm69fjIZLG4siwfLtP_iI4c=.a11629bc-45c7-43ff-9e2b-fd150dcf6ace@github.com>
 <mTfRnDj0EpOBp46MFua8u-fMCxWQhtvzkfLTyM1sajw=.2cafff2a-7198-4722-a1dc-a2f0f72d2c5c@github.com>
 <IjC2q-lB9OZy36wkztu4ok7G00occGcHBAYWFMmtzGI=.10771dd2-bae1-4077-8e6e-06d1d3af4ca4@github.com>
Message-ID: <Gcp_ItWmdpmvibA0kAnVCpnThV3EbMH1jUYqcJ7YnBY=.e0338032-17f4-4f72-bd71-f3e351ce66fe@github.com>

On Mon, 22 May 2023 19:21:52 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Thanks @erikj79. Could you please help provide some more info on the build failure:
>> 
>> Which macOs version ran into the build issue? My mac is on Ventura 13.3.1 (a). It builds successfully for the `static-libs-image` target.
>> 
>> Does it fail when partially linking `libjvm_relocatable.o` only, or it fails when partially linking other native libraries as well on macosx? Could you please share the partial linking command, e.g. hotspot/variant-server/libjvm/gtest/objs/static/BUILD_GTEST_LIBJVM_partial_link.cmdline?
>
>> Thanks @erikj79. Could you please help provide some more info on the build failure:
>> 
>> Which macOs version ran into the build issue? My mac is on Ventura 13.3.1 (a). It builds successfully for the `static-libs-image` target.
>> 
>> Does it fail when partially linking `libjvm_relocatable.o` only, or it fails when partially linking other native libraries as well on macosx? Could you please share the partial linking command, e.g. hotspot/variant-server/libjvm/gtest/objs/static/BUILD_GTEST_LIBJVM_partial_link.cmdline?
> 
> Additional info, following is the partial linking command from my `macosx-x86_64` build:
> 
> 
> /usr/bin/g++ -m64 -r -o /.../github/JDK-8307858/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/gtest/objs/static/libjvm_relocatable.o @/.../github/JDK-8307858/build/linux-x86_64-server-release/hotspot/variant-server/libjvm/gtest/objs/static/_BUILD_GTEST_LIBJVM_objectfilenames.txt

It fails because we are using a "devkit" and not an installed Xcode. The SYSROOT flags must always be added to any compiler or link command lines.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200973154

From bpb at openjdk.org  Mon May 22 19:52:50 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 May 2023 19:52:50 GMT
Subject: RFR: 8308016: Use snippets in java.io package [v8]
In-Reply-To: <70nu7qZqJSWf13HVFRnxYCbE1QJovmEuJXZ2M7dVVIg=.0da39bf9-c641-41d5-b090-a071e8bd97d7@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
 <M9zVErlCn0A2sEt_iOGlAh3pypQmmY43hB1QVOncwlA=.22a1d957-3165-465d-80db-f678d31f4048@github.com>
 <70nu7qZqJSWf13HVFRnxYCbE1QJovmEuJXZ2M7dVVIg=.0da39bf9-c641-41d5-b090-a071e8bd97d7@github.com>
Message-ID: <BuWN-2JkVJnyrnBGcjIn57p7UC7v2rCEuVSE4ubkAWw=.b60c66b4-e0d3-4907-ada1-324b17116435@github.com>

On Mon, 22 May 2023 19:28:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Thanks for the updates.

Thanks for all the comments (and the approval).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13957#issuecomment-1557863535

From erikj at openjdk.org  Mon May 22 19:57:59 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 22 May 2023 19:57:59 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v2]
In-Reply-To: <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com>
Message-ID: <vvcK21NymLG_JT_DjIIiMy249IbVu00oaVQuX8-MSwc=.0b179720-a2d7-49e1-87dd-949dc3c8b2f6@github.com>

On Mon, 22 May 2023 19:40:00 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Original description for JDK-8307194 change:
>> -----
>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
>> 
>>  - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>> 
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>> -----
>> 
>> Updates to address build failures reported on macosx-<cpu> platforms:
>> 
>> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
>> 
>> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
>> 
>> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.
>
> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into JDK-8307858
>  - Merge branch 'master' into JDK-8307858
>  - Clean up.
>  - In clude $MACHINE_FLAG in partial linking flag.
>  - Use '-m32' instead of '-m elf_i386'.
>  - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform.
>    
>    It's based on the post on https://www.linuxquestions.org/questions/linux-software-2/relocatable-linking-on-x86-64-for-i386-872812/.
>  - Only do partial linking step with gcc/clang on 64-bit platform.
>    
>    There is a linking failure with linux-x86 build:
>    
>    /usr/bin/ld: relocatable linking with relocations from format elf32-i386 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/gmock-all.o) to format elf64-x86-64 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/libgtest_relocatable.o) is not supported
>  - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG.
>  - Merge branch 'master' into JDK-8307858
>  - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change.
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/8474e693...fb945210

make/common/NativeCompilation.gmk line 1175:

> 1173: 
> 1174:   ifeq ($$($1_TYPE), STATIC_LIBRARY)
> 1175:     $1_VARDEPS := $$($1_AR) $$(ARFLAGS) $$($1_ARFLAGS) $$($1_LIBS) \

We also need to add some things to VARDEPS. Looks like at least `$$($1_LD)` and `$$($1_SYSROOT_LDFLAGS)` are needed. Maybe conditionally.

make/common/NativeCompilation.gmk line 1208:

> 1206: 	  $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \
> 1207: 	     $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \
> 1208:                  $$($1_LD_OBJ_ARG))

This makes my build pass.
Suggestion:

	     $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \
	         $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \
                 $$($1_LD_OBJ_ARG))

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200980626
PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1200982365

From duke at openjdk.org  Mon May 22 20:25:50 2023
From: duke at openjdk.org (Viktor Klang)
Date: Mon, 22 May 2023 20:25:50 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out
In-Reply-To: <OxNrLd5U4zRCrdWWu64DL6kOLlAtJNUXx-WP7_xf8HU=.45473fff-c298-4c52-a0b6-b91d72769bc6@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
 <-R-w4-Pz5g28MPD64fFKsM_QE81Z-WT3nYgveFinhHE=.78191104-9a31-4cfb-b0ed-7b19882737b5@github.com>
 <OxNrLd5U4zRCrdWWu64DL6kOLlAtJNUXx-WP7_xf8HU=.45473fff-c298-4c52-a0b6-b91d72769bc6@github.com>
Message-ID: <RXGvMnx6U2Sh0ewq8tpbsDIC5B7_hOx-_LescPuAmmE=.2476bace-a3ab-4066-8d2c-ee53d5f3578c@github.com>

On Mon, 22 May 2023 14:46:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Should the test be removed from ProblemList-generational-zgc.txt as part of this?
>
>> @AlanBateman My thinking was to integrate this and make sure that the problem doesn't resurface before removing it from the problem list. Does that make sense? ?
> 
> No objection, it's just it would leave ProblemList-generational-zgc.txt listing a test against as issue marked as fixed.

@AlanBateman I wonder, perhaps it makes more sense, as you say, to clear the problem list together with this, and resurrect it in case it spuriously resurfaces. It's always a challenge to prove a negative. :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14082#issuecomment-1557920226

From mcimadamore at openjdk.org  Mon May 22 20:37:48 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 22 May 2023 20:37:48 GMT
Subject: RFR: 8307205: Downcall to clibrary printf fails on OS X AArch64
In-Reply-To: <RGUsFPlKWiBPknSzRmsKio30igmDt5EEm9skeIkYBrU=.8b32e588-3cc8-458e-af45-623f7f553a24@github.com>
References: <RGUsFPlKWiBPknSzRmsKio30igmDt5EEm9skeIkYBrU=.8b32e588-3cc8-458e-af45-623f7f553a24@github.com>
Message-ID: <t82wf2Ety1cD3o3xR3rKAKPN-ddFDzOFxFDXtbh1gz4=.0931bafc-4ea0-4e07-9c9f-f2f80e30d50f@github.com>

On Mon, 22 May 2023 15:21:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR adds a test that shows the documented way of calling `printf` works.

I'm not sure I get this: StdLibTest already tests variadic calls, and there's a brand new javadoc section about this topic:
https://download.java.net/java/early_access/jdk21/docs/api/java.base/java/lang/foreign/Linker.html#variadic-funcs

Note: I'm not opposed to the test per se, but I note that (a) test-wise it is redundant, and (b) using tests as placeholder for documentation is a bit odd.

(Also, note that the bug this PR refers to is closed)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14088#issuecomment-1557943328

From naoto at openjdk.org  Mon May 22 20:49:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 May 2023 20:49:52 GMT
Subject: RFR: 8159023: Engineering notation of DecimalFormat does not work
 as documented
In-Reply-To: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
Message-ID: <cvtKeIeeZO6zK9hC043WnymHg7x1OdYDqoxCD_hedIo=.73707abd-2ada-4705-b9a6-c765652d50a7@github.com>

On Sat, 20 May 2023 00:00:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the Scientific Notation section of Decimal Format. It aims to resolve [JDK-8159023](https://bugs.openjdk.org/browse/JDK-8159023) as well as [JDK-6282188](https://bugs.openjdk.org/browse/JDK-6282188).
> 
> **Scientific Notation** in Decimal Format contains the definition for a scientific notation formatted number's mantissa as such: _The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits. For example, 12345 formatted with "##0.##E0" is "12.3E3"._
> 
> Both the definition and example are incorrect, as the actual result is "12.E345". 
> 
> The following example data show that scientific notation formatted numbers do not adhere to that definition. As, according to the definition, the following numbers should have 3 significant digits, but in reality, they have up to 5.
> 
> 123 formatted by ##0.#E0 is 123E0
> 1234 formatted by ##0.#E0 is 1.234E3
> 12345 formatted by ##0.#E0 is 12.34E3
> 123456 formatted by ##0.#E0 is 123.5E3
> 1234567 formatted by ##0.#E0 is 1.235E6
> 12345678 formatted by ##0.#E0 is 12.35E6
> 123456789 formatted by ##0.#E0 is 123.5E6 
> 
> 
> The actual definition of the mantissa, as well as examples and further context are included in this change. In addition, a test has been added that tests various patterns to numbers and ensures the format follows the new definition's mathematical expression.

(a bit of background to others) We did some archaeological work to dig into the history of this spec, and found that the spec was retrofitted to the implementation. (https://bugs.openjdk.org/browse/JDK-4241670). We suspect that this wording was incorrectly interpreted from the impl at that time.

test/jdk/java/text/Format/DecimalFormat/MantissaDigits.java line 56:

> 54:     public void testMantissaDefinition(String pattern) {
> 55:         Locale.setDefault(Locale.ENGLISH);
> 56:         DecimalFormat df = new DecimalFormat(pattern);

Instead of setting the default locale, you could get the explicit format by

new DecimalFormat(pattern, new DecimalFormatSymbols(Locale.US)); // DFS can be a static instance

test/jdk/java/text/Format/DecimalFormat/MantissaDigits.java line 89:

> 87:             // Test the new definition of the Mantissa
> 88:             Integer calculatedDigits = Math
> 89:                     .min(Math.max(zeroes, originalNumDigits), (hashes+zeroes));

Could we make those expected numbers into the `Arguments` so that there is no need to calculate in the test case at runtime? I think that would be more readable.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14066#pullrequestreview-1437505357
PR Review Comment: https://git.openjdk.org/jdk/pull/14066#discussion_r1201067500
PR Review Comment: https://git.openjdk.org/jdk/pull/14066#discussion_r1201062733

From jiangli at openjdk.org  Mon May 22 20:57:43 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 22 May 2023 20:57:43 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v3]
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <l1gytsgwVwKTDC3A8vDoggVNYaoqX6OV7120xyI8yq4=.24dc94ac-ad2d-4166-99ec-854168cae834@github.com>

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Update make/common/NativeCompilation.gmk
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14064/files
  - new: https://git.openjdk.org/jdk/pull/14064/files/fb945210..6a321bd1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064

PR: https://git.openjdk.org/jdk/pull/14064

From jiangli at openjdk.org  Mon May 22 20:57:47 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 22 May 2023 20:57:47 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v2]
In-Reply-To: <vvcK21NymLG_JT_DjIIiMy249IbVu00oaVQuX8-MSwc=.0b179720-a2d7-49e1-87dd-949dc3c8b2f6@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com>
 <vvcK21NymLG_JT_DjIIiMy249IbVu00oaVQuX8-MSwc=.0b179720-a2d7-49e1-87dd-949dc3c8b2f6@github.com>
Message-ID: <n0bp-ssn4-7qpLHH5T9xHQzdogCizatmht0hB4XhlF4=.b69dcbf5-a06b-448d-ab4a-354b97ebec13@github.com>

On Mon, 22 May 2023 19:54:59 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge branch 'master' into JDK-8307858
>>  - Merge branch 'master' into JDK-8307858
>>  - Clean up.
>>  - In clude $MACHINE_FLAG in partial linking flag.
>>  - Use '-m32' instead of '-m elf_i386'.
>>  - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform.
>>    
>>    It's based on the post on https://www.linuxquestions.org/questions/linux-software-2/relocatable-linking-on-x86-64-for-i386-872812/.
>>  - Only do partial linking step with gcc/clang on 64-bit platform.
>>    
>>    There is a linking failure with linux-x86 build:
>>    
>>    /usr/bin/ld: relocatable linking with relocations from format elf32-i386 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/gmock-all.o) to format elf64-x86-64 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/libgtest_relocatable.o) is not supported
>>  - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG.
>>  - Merge branch 'master' into JDK-8307858
>>  - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change.
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/8474e693...fb945210
>
> make/common/NativeCompilation.gmk line 1208:
> 
>> 1206: 	  $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \
>> 1207: 	     $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \
>> 1208:                  $$($1_LD_OBJ_ARG))
> 
> This makes my build pass.
> Suggestion:
> 
> 	     $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \
> 	         $(LD_OUT_OPTION)$$($1_TARGET_RELOCATABLE) \
>                  $$($1_LD_OBJ_ARG))

Thanks! Tested with a macosx-x86_64 build and also with our prototype on JDK 11 for linux-x64. They still build okay with the change. Looks like it affects/needed for cross build. Committing your fix.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1201077691

From jiangli at openjdk.org  Mon May 22 21:27:58 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 22 May 2023 21:27:58 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14064/files
  - new: https://git.openjdk.org/jdk/pull/14064/files/6a321bd1..695bda5e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=02-03

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064

PR: https://git.openjdk.org/jdk/pull/14064

From jiangli at openjdk.org  Mon May 22 21:28:04 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 22 May 2023 21:28:04 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v2]
In-Reply-To: <vvcK21NymLG_JT_DjIIiMy249IbVu00oaVQuX8-MSwc=.0b179720-a2d7-49e1-87dd-949dc3c8b2f6@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <0i3aaM1W1-QFR0Ezx6aNWgMlJpO6ODoK2sdt-nbjcW4=.c47621ea-521c-44ee-a469-8b7a87bcb097@github.com>
 <vvcK21NymLG_JT_DjIIiMy249IbVu00oaVQuX8-MSwc=.0b179720-a2d7-49e1-87dd-949dc3c8b2f6@github.com>
Message-ID: <rgQbsAPRzYIYnEJE6vSrw3RP8-6HmYqQrq6LBQFLeZ8=.bc4699d4-156b-44d8-abf4-b888a6dc19af@github.com>

On Mon, 22 May 2023 19:52:42 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge branch 'master' into JDK-8307858
>>  - Merge branch 'master' into JDK-8307858
>>  - Clean up.
>>  - In clude $MACHINE_FLAG in partial linking flag.
>>  - Use '-m32' instead of '-m elf_i386'.
>>  - Use '-m elf_i386' for partial linking with gcc for linux 32-bit platform.
>>    
>>    It's based on the post on https://www.linuxquestions.org/questions/linux-software-2/relocatable-linking-on-x86-64-for-i386-872812/.
>>  - Only do partial linking step with gcc/clang on 64-bit platform.
>>    
>>    There is a linking failure with linux-x86 build:
>>    
>>    /usr/bin/ld: relocatable linking with relocations from format elf32-i386 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/gmock-all.o) to format elf64-x86-64 (/home/runner/work/jdk/jdk/build/linux-x86/hotspot/variant-server/libjvm/libgtest/objs/libgtest_relocatable.o) is not supported
>>  - Need to set $1_AR_OBJ_ARG to $$($1_LD_OBJ_ARG) instead of $1_LD_OBJ_ARG.
>>  - Merge branch 'master' into JDK-8307858
>>  - Revert src/java.desktop/linux/native/libjsound/PLATFORM_API_LinuxOS_ALSA_CommonUtils.c change.
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/8474e693...fb945210
>
> make/common/NativeCompilation.gmk line 1175:
> 
>> 1173: 
>> 1174:   ifeq ($$($1_TYPE), STATIC_LIBRARY)
>> 1175:     $1_VARDEPS := $$($1_AR) $$(ARFLAGS) $$($1_ARFLAGS) $$($1_LIBS) \
> 
> We also need to add some things to VARDEPS. Looks like at least `$$($1_LD)` and `$$($1_SYSROOT_LDFLAGS)` are needed. Maybe conditionally.

Fix, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1201128665

From mdoerr at openjdk.org  Mon May 22 21:36:12 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 May 2023 21:36:12 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v34]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <_rcz557uylyTKjbgSwU4vMDdy7ifSR8g0EUCjy9TmiI=.9bf264af-1f4b-4492-8db7-61b6308f5694@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: T...

Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:

 - Adaptation for JDK-8308276.
 - Merge remote-tracking branch 'origin' into PPC64_Panama
 - Add comment about Register Save Area.
 - Replace abstract method useABIv2().
 - Cleanup imports, improve comments, updates from other platforms.
 - Add NONZERO check for downcall_stub_address_offset_in_bytes().
 - Replace NULL by nullptr.
 - libTestHFA: Add explicit type conversion to avoid build warning.
 - Add test case for passing a double value in a GP register. Use better instructions for moving between FP and GP reg. Improve comments.
 - Merge remote-tracking branch 'origin' into PPC64_Panama
 - ... and 31 more: https://git.openjdk.org/jdk/compare/939344b8...08a5c143

-------------

Changes: https://git.openjdk.org/jdk/pull/12708/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=33
  Stats: 2479 lines in 27 files changed: 2432 ins; 0 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From rrich at openjdk.org  Mon May 22 22:03:04 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 22 May 2023 22:03:04 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v34]
In-Reply-To: <_rcz557uylyTKjbgSwU4vMDdy7ifSR8g0EUCjy9TmiI=.9bf264af-1f4b-4492-8db7-61b6308f5694@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <_rcz557uylyTKjbgSwU4vMDdy7ifSR8g0EUCjy9TmiI=.9bf264af-1f4b-4492-8db7-61b6308f5694@github.com>
Message-ID: <MDQvdzvPktDAVzKgslZWMGpZF0RTxL207FRcpr_awf0=.d9313849-25c0-47ab-ba8a-e2554158af14@github.com>

On Mon, 22 May 2023 21:36:12 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separat...
>
> Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
> 
>  - Adaptation for JDK-8308276.
>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>  - Add comment about Register Save Area.
>  - Replace abstract method useABIv2().
>  - Cleanup imports, improve comments, updates from other platforms.
>  - Add NONZERO check for downcall_stub_address_offset_in_bytes().
>  - Replace NULL by nullptr.
>  - libTestHFA: Add explicit type conversion to avoid build warning.
>  - Add test case for passing a double value in a GP register. Use better instructions for moving between FP and GP reg. Improve comments.
>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>  - ... and 31 more: https://git.openjdk.org/jdk/compare/939344b8...08a5c143

Hi Martin,

there seems to be a mismatch between this pr and the [64-bit ELF ABI V2 for PPC](https://openpowerfoundation.org/specifications/64bitelfabi/). In fact all dynamically generated calls that have to conform to ABI V2 are affected. I'm giving a short summary of our discussion this afternoon.

Very briefly: ABI V2 states that a Parameter Save Area (PSA) shall be allocated _unless_ all parameters can be passed in registers as indicated by the caller's prototype, whereas the port always allocates a PSA of 8 double words.
(Details under "Parameter Save Area" in "2.2.3.3. Optional Save Areas" of ELF ABI V2)

It is not wrong what we're doing. It is like we didn't know the prototype of the call targets. But for most calls [1] we are wasting stack space (and confusing everybody that tries to match the implementation with the spec).
Interestingly ABI V1 states that a PSA of at least 8 double words is always needed. Looks like we've missed that change.

I have conducted a little experiment and compiled the following test program using Compiler Explorer [2]


#include <stdint.h>

int64_t test_callee(int64_t p1, int64_t p2, int64_t p3, int64_t p4);

int64_t test_call(int64_t p1, int64_t p2, int64_t p3, int64_t p4) {
    return test_callee(p1, p2, p3, p4);
}


This is the -O2 output for ELF ABI V2 (little endian)
Note: the stdu allocates just the minimal frame of 4 double words without PSA.


test_call:                              # @test_call
.Lfunc_gep0:
        addis 2, 12, .TOC.-.Lfunc_gep0 at ha
        addi 2, 2, .TOC.-.Lfunc_gep0 at l
        mflr 0
        stdu 1, -32(1)
        std 0, 48(1)
        bl test_callee
        nop
        addi 1, 1, 32
        ld 0, 16(1)
        mtlr 0
        blr


This is the -O2 output for ELF ABI V1 (big endian)


test_call:                              # @test_call
        .quad   .Lfunc_begin0
        .quad   .TOC. at tocbase
        .quad   0
.Lfunc_begin0:
        mflr 0
        stdu 1, -112(1)
        std 0, 128(1)
        bl test_callee
        nop
        addi 1, 1, 112
        ld 0, 16(1)
        mtlr 0
        blr

Note: the stdu allocates a much larger frame because it accomodates a PSA of 8 double words.

I'd suggest to keep the current well tested version but add comments to the code that a PSA is always allocated even though ABI V2 does not require it. This should also be explained in the JBS item.

Furthermore RFEs should be filed to adopt ABI V2 in the FFM API port and in the hotspot port to PPC64le. There's quite a bit of room for improvement there. Ironically I've very recently fixed [JDK-8306111](https://bugs.openjdk.org/browse/JDK-8306111) citing the ABI V2 spec without realizing that the fix is not needed for V2, just for V1.


[1] Exceptions that _do_ require a PSA are calls with a really long or variable parameter list or if a prototype is not available

[2] [Experiment with "Compiler Explorer"](https://godbolt.org/#z:OYLghAFBqd5QCxAYwPYBMCmBRdBLAF1QCcAaPECAMzwBtMA7AQwFtMQByARg9KtQYEAysib0QXACx8BBAKoBnTAAUAHpwAMvAFYgATKVpMGoAPrnkpJfWQE8Ayo3QBhVLQCuLBhNJOAMngMmAByngBGmMQgABykAA6oCoT2DK4eXj4JSXYCAUGhLBFRsdaYtilCBEzEBGme3lxWmDY5DJXVBHkh4ZExVlU1dRmNCgOdgd2FvdEAlFao7sTI7BwApHoAzIHIHlgA1KsbzqP4ggB0CIfYqxoAgje3gQQAbJKmBHsEmKOmorT0mAgT1e7z2cUae2Bbw%2BcQMkMEIJhG1I8Je0LBkhmhwAQg8HlDQV8fn9aECEejwSiCTC4dSwcjUYiMTMDgB2XF3PZcvbETAERYMT7fAi/MQAiCUsFwuIMuKYnF41kAEQeHDmtE4AFZeN4OFpSKhOM49goFktMAdNnpeARNGq5gBrECSACcZw0Gi4Ls1zxdklZXGeekkyI1HEkOrtBs4vAUIA0pFterVpDgsBgiBQqBYcTokXIlDQObzUWQcTiyFeNiMJlIWAAbnhlgA1PCYADuAHk4oxODw%2BHQvsQ4xAwlGwoFqgBPPu8CfMYhTzthbRlJP9otsQSdhi0GfJuuYFjGYDiA/4XnlevfKOYVRldxfWfkQTNKO0PBhYjT1xYKMEYg8BYWc5ioIxgAUVsO27XtuF4fhBBEMR2CkGRBEUFR1APXRGhrMwLEMT840gOZUDiVo4w4ABaTtrQNa9iEArBiIgOZSnKBwICcIYGl8Bh0C6AoikyRJkgEHiROyFJBJ6KIRmaNcKjGCT5JaJSOhkqY5P6DoVJ0mpNOErg2LNZZ9HVLVIwPQ0ODBVB20iKsLR2E89ggAD3AYB0WQgXBCBIS0Nj0GYbTtGY5gQTAmCwKJW
 NIJ0NlZM5NUMTgI1IYDNQTXV9Rs2N40TMLUwzCAkCLXN6DICgIHKksUHLStJBc2sGybTAoK7HtdX7GhaCHEcxwPedp2fYbF2XVdbGfTdGAIHc9yjLBjxMM99QvRTr0o/U7wfJ84JfL4w31D8vx/DAVn1ACgJAvhwMgttOtgnrZCQ8RUIQ%2BQlDUKNdAMPCQHMX5CLCFjSPIlJKJoujUAYpibxIpo1M47i3HqCRYn8CYhN6QN4lE1oVNiLIxIYQyceeRHFIEdpBlR4ZKY4toxjJ7TRl0uneLZgysdkiQTMWMzgtSjhtVIHLeBsuyHOICtXj2ZrgDcjyvJ8vyiGIQLgtC5NwtISLot6OKw3SzLsqjPKrAKpMtF1p0srOF0XWiDQQw0TU9GiRLNVZYWNis3KY0KnWLI4OjxejDhtZtuYGKSBxJCAA%3D%3D)

src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 205:

> 203:                 stack = stackAlloc(4, 4);
> 204:             } else {
> 205:                 stack = stackAlloc(is32Bit ? 4 : 8, STACK_SLOT_SIZE);

This looks like a stack slot is always allocated. Please explain that for ABI V2 this is actually only required if it is know from a prototype that not all parameters can be passed in registers and that we plan to change this.

-------------

Changes requested by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12708#pullrequestreview-1437623272
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1201198779

From rrich at openjdk.org  Mon May 22 22:03:07 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Mon, 22 May 2023 22:03:07 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v33]
In-Reply-To: <-4sIEOVwyrDPTp4DKnIJnoWau845QEXn3aTOkS9FLp8=.6c87bc30-c614-4b1c-8a72-51214bff444d@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <-4sIEOVwyrDPTp4DKnIJnoWau845QEXn3aTOkS9FLp8=.6c87bc30-c614-4b1c-8a72-51214bff444d@github.com>
Message-ID: <XRHDMdHaSMMehVQ__p-Pn9hIcNxI_YW05a-FoJiegus=.481b24f7-3f34-4113-a8f1-58536aa97a78@github.com>

On Mon, 22 May 2023 16:06:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separat...
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about Register Save Area.

src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 161:

> 159:   // (native_abi_reg_args is native_abi_minframe plus space for 8 argument register spill slots)
> 160:   assert(_abi._shadow_space_bytes == frame::native_abi_minframe_size, "expected space according to ABI");
> 161:   // Note: For ABIv2, we only need (_input_registers.length() > 8) ? _input_registers.length() : 0

This is hard to understand. It should be explained that we allocate a PSA even though ABI V2 only requires it if not all parameters can be passed in registers.

src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 162:

> 160:   assert(_abi._shadow_space_bytes == frame::native_abi_minframe_size, "expected space according to ABI");
> 161:   // Note: For ABIv2, we only need (_input_registers.length() > 8) ? _input_registers.length() : 0
> 162:   int register_save_area_slots = MAX2(_input_registers.length(), 8);

Both specs, ABI V1 and V2, call this "Parameter Save Area" we should use the same name.
Suggestion:

  int parameter_save_area_slots = MAX2(_input_registers.length(), 8);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1201132931
PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1201128718

From mcimadamore at openjdk.org  Mon May 22 22:26:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 22 May 2023 22:26:53 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v3]
In-Reply-To: <H6vAs4zEAdTMHV_4HqSWYrJV3rof0uFCWPc---q9p7c=.42da24c9-233f-454e-9072-3bb8151e45cb@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <Js67F4k4vce7aJj1IaxhDV3Ny6NEVF4fD8OA85KloB8=.26bae93a-c26e-44d8-a158-8789f77ef58d@github.com>
 <UdfB19Vae80C9ik7RiTNGDukWMMHfblif9zF3JaeM1s=.6a7521a7-7d37-4720-a6fc-9de0580a3aa9@github.com>
 <uouq_KJZGLAf75DkDu6y9YnN2DRq5jrkycZrNuvX104=.d821d16c-052e-4a69-86ee-c045d46171b5@github.com>
 <H6vAs4zEAdTMHV_4HqSWYrJV3rof0uFCWPc---q9p7c=.42da24c9-233f-454e-9072-3bb8151e45cb@github.com>
Message-ID: <bIQPpVDzmQqHLrlEdoXJXIq0Qdce657_MriGQ-LaszE=.7e37648a-97d3-4aae-b367-b0cdbbc1b971@github.com>

On Fri, 19 May 2023 23:08:00 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>>> This look much better. Can we strengthen the specification of `canonicalLayouts` in accordance with the class specification
>> 
>> We can't do more in that method javadoc,  think, as that has to be general enough for all linkers. I think the rules set up in that method javadoc are good - e.g. the set of layouts should be stable (both in terms of names and layout types).
>> 
>> What we can do is to sprinkle some wording in the `nativeLinker` factory - e.g. `the native linker is guaranteed to provide canonical layouts for basic C types <link to the class section>`.
>
>> > This look much better. Can we strengthen the specification of `canonicalLayouts` in accordance with the class specification
>> 
>> We can't do more in that method javadoc, think, as that has to be general enough for all linkers. I think the rules set up in that method javadoc are good - e.g. the set of layouts should be stable (both in terms of names and layout types).
>> 
>> What we can do is to sprinkle some wording in the `nativeLinker` factory - e.g. `the native linker is guaranteed to provide canonical layouts for basic C types <link to the class section>`.
> 
> Yes, that's better.

@PaulSandoz after thinking some more, it seems a bit ad-hoc to guarantee a canonical for "unsigned short", but not for other unsigned types? Possible alternatives (beside keeping what we have in this PR):

* guarantee also all the other unsigned types (e.g. char, int, long and long long)
* do not guarantee unsigned short - but provide a mapping for it anyways
* do not guarantee unsigned short, and do not provide a mapping for it - this means that JAVA_CHAR will not be usable when linking

What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1558110434

From mdoerr at openjdk.org  Mon May 22 22:29:18 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 May 2023 22:29:18 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v35]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <cABEdgxmtvRq8ZYtkWQP27aGKP1GnkoLdTTERYPBSrE=.bcfbbd3c-2b68-4857-8962-5ab2976e8d27@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: T...

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Parameter Save Area is the correct name.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/08a5c143..b912155b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=34
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=33-34

  Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From mdoerr at openjdk.org  Mon May 22 22:29:18 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 May 2023 22:29:18 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v33]
In-Reply-To: <XRHDMdHaSMMehVQ__p-Pn9hIcNxI_YW05a-FoJiegus=.481b24f7-3f34-4113-a8f1-58536aa97a78@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <-4sIEOVwyrDPTp4DKnIJnoWau845QEXn3aTOkS9FLp8=.6c87bc30-c614-4b1c-8a72-51214bff444d@github.com>
 <XRHDMdHaSMMehVQ__p-Pn9hIcNxI_YW05a-FoJiegus=.481b24f7-3f34-4113-a8f1-58536aa97a78@github.com>
Message-ID: <SRV-u_Cq0WYiXWfOYYNKVKJTKbux01Z3YdC4lNvkgAU=.d1c847dd-68f1-4f47-b721-d5bb29a91160@github.com>

On Mon, 22 May 2023 21:22:50 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add comment about Register Save Area.
>
> src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 162:
> 
>> 160:   assert(_abi._shadow_space_bytes == frame::native_abi_minframe_size, "expected space according to ABI");
>> 161:   // Note: For ABIv2, we only need (_input_registers.length() > 8) ? _input_registers.length() : 0
>> 162:   int register_save_area_slots = MAX2(_input_registers.length(), 8);
> 
> Both specs, ABI V1 and V2, call this "Parameter Save Area" we should use the same name.
> Suggestion:
> 
>   int parameter_save_area_slots = MAX2(_input_registers.length(), 8);

Thanks! Changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1201234986

From mdoerr at openjdk.org  Mon May 22 22:39:06 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 May 2023 22:39:06 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v34]
In-Reply-To: <MDQvdzvPktDAVzKgslZWMGpZF0RTxL207FRcpr_awf0=.d9313849-25c0-47ab-ba8a-e2554158af14@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <_rcz557uylyTKjbgSwU4vMDdy7ifSR8g0EUCjy9TmiI=.9bf264af-1f4b-4492-8db7-61b6308f5694@github.com>
 <MDQvdzvPktDAVzKgslZWMGpZF0RTxL207FRcpr_awf0=.d9313849-25c0-47ab-ba8a-e2554158af14@github.com>
Message-ID: <JDOhOlggfSFkt_Nt39CvtaGhnLjHW7k8qfPwZfBbycQ=.6b8fc681-03b3-4037-91a0-ea82de07c0e5@github.com>

On Mon, 22 May 2023 21:49:27 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Martin Doerr has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits:
>> 
>>  - Adaptation for JDK-8308276.
>>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>>  - Add comment about Register Save Area.
>>  - Replace abstract method useABIv2().
>>  - Cleanup imports, improve comments, updates from other platforms.
>>  - Add NONZERO check for downcall_stub_address_offset_in_bytes().
>>  - Replace NULL by nullptr.
>>  - libTestHFA: Add explicit type conversion to avoid build warning.
>>  - Add test case for passing a double value in a GP register. Use better instructions for moving between FP and GP reg. Improve comments.
>>  - Merge remote-tracking branch 'origin' into PPC64_Panama
>>  - ... and 31 more: https://git.openjdk.org/jdk/compare/939344b8...08a5c143
>
> src/java.base/share/classes/jdk/internal/foreign/abi/ppc64/CallArranger.java line 205:
> 
>> 203:                 stack = stackAlloc(4, 4);
>> 204:             } else {
>> 205:                 stack = stackAlloc(is32Bit ? 4 : 8, STACK_SLOT_SIZE);
> 
> This looks like a stack slot is always allocated. Please explain that for ABI V2 this is actually only required if it is know from a prototype that not all parameters can be passed in registers and that we plan to change this.

This basically computes the stack layout. We need to count all slots to get the right offset for the registers which actually get written on stack. The first such register will hit native_abi_minframe_size + 8 slots. If fewer registers are used, the counted stack slots will not be used.
The decision whether we allocate the Parameter Save Area or not is done in the downcall stub and doesn't depend on the stackAllocs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1201251283

From mdoerr at openjdk.org  Mon May 22 22:49:04 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 22 May 2023 22:49:04 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v35]
In-Reply-To: <cABEdgxmtvRq8ZYtkWQP27aGKP1GnkoLdTTERYPBSrE=.bcfbbd3c-2b68-4857-8962-5ab2976e8d27@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <cABEdgxmtvRq8ZYtkWQP27aGKP1GnkoLdTTERYPBSrE=.bcfbbd3c-2b68-4857-8962-5ab2976e8d27@github.com>
Message-ID: <xnXIQ1TL8yWVM2jvoifCKXQjWrFkiWNo9F41mmqD0f8=.d2029def-8155-4d52-909c-a0b38b5c73ae@github.com>

On Mon, 22 May 2023 22:29:18 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separat...
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Parameter Save Area is the correct name.

Thanks for publishing our discussion, here. The unnecessary PSA affects other areas of hotspot much more than Panama. Yes, we should file an RFE. I think one for hotspot is sufficient as the downcall stub is part of it. I don't think it needs extra treatment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12708#issuecomment-1558139323

From jlu at openjdk.org  Mon May 22 23:03:10 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 22 May 2023 23:03:10 GMT
Subject: RFR: 8159023: Engineering notation of DecimalFormat does not work
 as documented [v2]
In-Reply-To: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
Message-ID: <G6ys5jd53ugGSFPMdFoC-Qho1r8pxEwoeMVwUhASpRI=.8c9ac6db-878a-45a2-b4f8-a3372e69e9d0@github.com>

> Please review this PR which updates the Scientific Notation section of Decimal Format. It aims to resolve [JDK-8159023](https://bugs.openjdk.org/browse/JDK-8159023) as well as [JDK-6282188](https://bugs.openjdk.org/browse/JDK-6282188).
> 
> **Scientific Notation** in Decimal Format contains the definition for a scientific notation formatted number's mantissa as such: _The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits. For example, 12345 formatted with "##0.##E0" is "12.3E3"._
> 
> Both the definition and example are incorrect, as the actual result is "12.E345". 
> 
> The following example data show that scientific notation formatted numbers do not adhere to that definition. As, according to the definition, the following numbers should have 3 significant digits, but in reality, they have up to 5.
> 
> 123 formatted by ##0.#E0 is 123E0
> 1234 formatted by ##0.#E0 is 1.234E3
> 12345 formatted by ##0.#E0 is 12.34E3
> 123456 formatted by ##0.#E0 is 123.5E3
> 1234567 formatted by ##0.#E0 is 1.235E6
> 12345678 formatted by ##0.#E0 is 12.35E6
> 123456789 formatted by ##0.#E0 is 123.5E6 
> 
> 
> The actual definition of the mantissa, as well as examples and further context are included in this change. In addition, a test has been added that tests various patterns to numbers and ensures the format follows the new definition's mathematical expression.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Review: Use Static dfs, error message, and exponent digit. Hard code min and max digits instead of calculating at runtime

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14066/files
  - new: https://git.openjdk.org/jdk/pull/14066/files/e6cbbeea..faa32ec6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14066&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14066&range=00-01

  Stats: 35 lines in 1 file changed: 6 ins; 12 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14066/head:pull/14066

PR: https://git.openjdk.org/jdk/pull/14066

From jlu at openjdk.org  Mon May 22 23:07:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 22 May 2023 23:07:51 GMT
Subject: RFR: 8159023: Engineering notation of DecimalFormat does not work
 as documented [v2]
In-Reply-To: <cvtKeIeeZO6zK9hC043WnymHg7x1OdYDqoxCD_hedIo=.73707abd-2ada-4705-b9a6-c765652d50a7@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
 <cvtKeIeeZO6zK9hC043WnymHg7x1OdYDqoxCD_hedIo=.73707abd-2ada-4705-b9a6-c765652d50a7@github.com>
Message-ID: <QSBPanDVt2KM8MyRdLo9EwjLp69p1MtWGvEKAjg9E0g=.f019b00e-cb44-4991-bb1e-2875267269a9@github.com>

On Mon, 22 May 2023 20:41:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review: Use Static dfs, error message, and exponent digit. Hard code min and max digits instead of calculating at runtime
>
> test/jdk/java/text/Format/DecimalFormat/MantissaDigits.java line 89:
> 
>> 87:             // Test the new definition of the Mantissa
>> 88:             Integer calculatedDigits = Math
>> 89:                     .min(Math.max(zeroes, originalNumDigits), (hashes+zeroes));
> 
> Could we make those expected numbers into the `Arguments` so that there is no need to calculate in the test case at runtime? I think that would be more readable.

Thanks for the review, addressed both suggestions in the most recent commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14066#discussion_r1201272651

From naoto at openjdk.org  Mon May 22 23:34:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 May 2023 23:34:51 GMT
Subject: RFR: 8159023: Engineering notation of DecimalFormat does not work
 as documented [v2]
In-Reply-To: <G6ys5jd53ugGSFPMdFoC-Qho1r8pxEwoeMVwUhASpRI=.8c9ac6db-878a-45a2-b4f8-a3372e69e9d0@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
 <G6ys5jd53ugGSFPMdFoC-Qho1r8pxEwoeMVwUhASpRI=.8c9ac6db-878a-45a2-b4f8-a3372e69e9d0@github.com>
Message-ID: <w8IYWaF82fbUMBOM6Ucr7JrZGTiCrR3nEF-h96SZPy0=.56f7313b-bdbc-4e7e-ae50-e118a6ba4f99@github.com>

On Mon, 22 May 2023 23:03:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the Scientific Notation section of Decimal Format. It aims to resolve [JDK-8159023](https://bugs.openjdk.org/browse/JDK-8159023) as well as [JDK-6282188](https://bugs.openjdk.org/browse/JDK-6282188).
>> 
>> **Scientific Notation** in Decimal Format contains the definition for a scientific notation formatted number's mantissa as such: _The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits. For example, 12345 formatted with "##0.##E0" is "12.3E3"._
>> 
>> Both the definition and example are incorrect, as the actual result is "12.E345". 
>> 
>> The following example data show that scientific notation formatted numbers do not adhere to that definition. As, according to the definition, the following numbers should have 3 significant digits, but in reality, they have up to 5.
>> 
>> 123 formatted by ##0.#E0 is 123E0
>> 1234 formatted by ##0.#E0 is 1.234E3
>> 12345 formatted by ##0.#E0 is 12.34E3
>> 123456 formatted by ##0.#E0 is 123.5E3
>> 1234567 formatted by ##0.#E0 is 1.235E6
>> 12345678 formatted by ##0.#E0 is 12.35E6
>> 123456789 formatted by ##0.#E0 is 123.5E6 
>> 
>> 
>> The actual definition of the mantissa, as well as examples and further context are included in this change. In addition, a test has been added that tests various patterns to numbers and ensures the format follows the new definition's mathematical expression.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Use Static dfs, error message, and exponent digit. Hard code min and max digits instead of calculating at runtime

Thanks, Justin. Left some super-nits.

test/jdk/java/text/Format/DecimalFormat/MantissaDigits.java line 52:

> 50:             1.1234, 1.1111, 1.412, 222.333, -771.2222
> 51:             };
> 52:     private static final DecimalFormatSymbols dfs = new DecimalFormatSymbols(Locale.US);

The `static final` field is better uppercased.

test/jdk/java/text/Format/DecimalFormat/MantissaDigits.java line 64:

> 62:         for (double number : numbers) {
> 63:             // Count the significant digits in the pre-formatted number
> 64:             int originalNumDigits = String.valueOf(number)

It's OK as it stands, but you could write:

str.chars().filter(Character::isDigit).count()

which might be more readable

-------------

PR Review: https://git.openjdk.org/jdk/pull/14066#pullrequestreview-1437867369
PR Review Comment: https://git.openjdk.org/jdk/pull/14066#discussion_r1201295121
PR Review Comment: https://git.openjdk.org/jdk/pull/14066#discussion_r1201295601

From itakiguchi at openjdk.org  Tue May 23 00:12:50 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 23 May 2023 00:12:50 GMT
Subject: RFR: 8308046: Move Solaris related charsets from java.base to
 jdk.charsets module [v2]
In-Reply-To: <txZ17bmXVyokeDGUg0Nv7coyls0P9nd4s95qyxFY3rA=.4fe47161-b45c-436f-9074-1aa6df738958@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
 <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
 <4yFGg-CgLRvNAEB7tpVH9Bi13fdlyAAdVniQnYoZcX4=.32f55011-db19-4c15-adc1-7cfc4cd564a6@github.com>
 <URWJaXXaEzUAWnM0t0t_VFs-eSpBxYhrWKpHL1Dd1b4=.456a44fc-ce38-46ee-ba17-48fd37df65f5@github.com>
 <Of7--k3lQYJdoaAusVAhJB6XzmAoxuYD5FMm7P448P8=.2e742cdb-d7f5-4f38-87de-ff5725fec96b@github.com>
 <txZ17bmXVyokeDGUg0Nv7coyls0P9nd4s95qyxFY3rA=.4fe47161-b45c-436f-9074-1aa6df738958@github.com>
Message-ID: <JenWk-CIZLt9lCH1cxKtXbNisFd1BQDtN2L6BNVtErY=.889d5a9a-5dc9-453f-a329-a54c95d88019@github.com>

On Sat, 20 May 2023 17:26:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello @naotoj .
>> I'd like to confirm about DoubleByte-X.java.template and EUC_JP.java.template.
>> I think the values are package-private.
>> Even if class is changed to `public`, the classes in`sun.nio.cs.ext` package could not access to these values in `sun.nio.cs` package...
>> I may be misunderstanding your suggestion, could you tell me more ?
>
>> I think the values are package-private. Even if class is changed to `public`, the classes in`sun.nio.cs.ext` package could not access to these values in `sun.nio.cs` package... 
> 
> I meant making those package-private fields public. I believe it's OK because java.base/sun.nio.cs package is only exported to jdk.charsets module.

Hello @naotoj .
I appreciate your attention about JBS side.
I changed title and description, add noreg-cleanup label.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1558228901

From itakiguchi at openjdk.org  Tue May 23 00:45:10 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 23 May 2023 00:45:10 GMT
Subject: Integrated: 8308046: Move Solaris related charsets from java.base to
 jdk.charsets module
In-Reply-To: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
Message-ID: <x6CNq7R3ck3jDBMCDX1v6f5f3YZSHaHARE77ebQvmgw=.a11a0f65-bf34-4d15-8f54-f4219d26c0a4@github.com>

On Mon, 15 May 2023 00:28:41 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> According to "JDK 20 Internationalization Guide"
> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
> Following Solaris related charsets are in "contained in jdk.charsets module" list.
> 
> - PCK (x-PCK)
> - EUC_JP_Solaris (x-eucJP-Open)
> - Big5_Solaris (x-Big5-Solaris)
> 
> These are not supported by Linux platform, so they should not be in java.base module.
> 
> Note:
> GHA Linux x86 builds were failed.
> I think it's not related by my modified code.
> I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-8308051) GHA: Linux x86 builds failure

This pull request has now been integrated.

Changeset: 5d8ba938
Author:    Ichiroh Takiguchi <itakiguchi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d8ba938bef162b74816147eb1002a0620a419ba
Stats:     21 lines in 4 files changed: 0 ins; 6 del; 15 mod

8308046: Move Solaris related charsets from java.base to jdk.charsets module

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13973

From darcy at openjdk.org  Tue May 23 05:10:56 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 May 2023 05:10:56 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v4]
In-Reply-To: <5uakOuAdd9XDJ-E5ARGF6EFTixE7W9A5NzucACL3glE=.3dc3ff58-f186-4aa7-b311-792a10dabd86@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <5uakOuAdd9XDJ-E5ARGF6EFTixE7W9A5NzucACL3glE=.3dc3ff58-f186-4aa7-b311-792a10dabd86@github.com>
Message-ID: <3fHvFwyrO-aZ3KKwhR2cZFeZl8Yf8vXi6FKACwc-Ay4=.1c192847-4fae-44db-a9a8-fed1dcddcf65@github.com>

On Mon, 22 May 2023 10:22:16 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8307990
>  - Address comments from tstuefe and RogerRiggs
>  - REALLY adding the test :)
>  - Added test case
>  - 8307990: jspawnhelper must close its writing side of a pipe before reading from it

> 

Without further investigation on my part, I don't know if this fix falls more squarely in the "obviously no bugs" or "no obvious bugs" category.

I left a comment on the release note issue suggesting a description of the solution or implications of the solution be added to the note. It could be also be helpful to state under what conditions the problem being solved is more likely to manifest, if that is known.

For whenever this goes back, highlighting the change on a quality-discuss message could help validate the change doesn't have unexpected side-effects.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1558529211

From jlu at openjdk.org  Tue May 23 05:31:37 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 May 2023 05:31:37 GMT
Subject: RFR: 8159023: Engineering notation of DecimalFormat does not work
 as documented [v3]
In-Reply-To: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
Message-ID: <CAoRwOaYvLyvcwX__-iBVtN2BX6hw_smDC53OmKc5Ks=.668e2637-7a68-4aa7-a4c4-ca1a457999d1@github.com>

> Please review this PR which updates the Scientific Notation section of Decimal Format. It aims to resolve [JDK-8159023](https://bugs.openjdk.org/browse/JDK-8159023) as well as [JDK-6282188](https://bugs.openjdk.org/browse/JDK-6282188).
> 
> **Scientific Notation** in Decimal Format contains the definition for a scientific notation formatted number's mantissa as such: _The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits. For example, 12345 formatted with "##0.##E0" is "12.3E3"._
> 
> Both the definition and example are incorrect, as the actual result is "12.E345". 
> 
> The following example data show that scientific notation formatted numbers do not adhere to that definition. As, according to the definition, the following numbers should have 3 significant digits, but in reality, they have up to 5.
> 
> 123 formatted by ##0.#E0 is 123E0
> 1234 formatted by ##0.#E0 is 1.234E3
> 12345 formatted by ##0.#E0 is 12.34E3
> 123456 formatted by ##0.#E0 is 123.5E3
> 1234567 formatted by ##0.#E0 is 1.235E6
> 12345678 formatted by ##0.#E0 is 12.35E6
> 123456789 formatted by ##0.#E0 is 123.5E6 
> 
> 
> The actual definition of the mantissa, as well as examples and further context are included in this change. In addition, a test has been added that tests various patterns to numbers and ensures the format follows the new definition's mathematical expression.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Review: replace counting with isDigit, use all caps static final vars

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14066/files
  - new: https://git.openjdk.org/jdk/pull/14066/files/faa32ec6..dd516b63

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14066&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14066&range=01-02

  Stats: 13 lines in 1 file changed: 0 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14066/head:pull/14066

PR: https://git.openjdk.org/jdk/pull/14066

From jlu at openjdk.org  Tue May 23 05:31:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 May 2023 05:31:40 GMT
Subject: RFR: 8159023: Engineering notation of DecimalFormat does not work
 as documented [v2]
In-Reply-To: <w8IYWaF82fbUMBOM6Ucr7JrZGTiCrR3nEF-h96SZPy0=.56f7313b-bdbc-4e7e-ae50-e118a6ba4f99@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
 <G6ys5jd53ugGSFPMdFoC-Qho1r8pxEwoeMVwUhASpRI=.8c9ac6db-878a-45a2-b4f8-a3372e69e9d0@github.com>
 <w8IYWaF82fbUMBOM6Ucr7JrZGTiCrR3nEF-h96SZPy0=.56f7313b-bdbc-4e7e-ae50-e118a6ba4f99@github.com>
Message-ID: <ERWp6zdBqMjamrbKH70udCEUGKI2bg8DfyFSuifc3-o=.dffb9d6f-b15d-4939-b326-699e0ef4bdb7@github.com>

On Mon, 22 May 2023 23:31:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review: Use Static dfs, error message, and exponent digit. Hard code min and max digits instead of calculating at runtime
>
> test/jdk/java/text/Format/DecimalFormat/MantissaDigits.java line 64:
> 
>> 62:         for (double number : numbers) {
>> 63:             // Count the significant digits in the pre-formatted number
>> 64:             int originalNumDigits = String.valueOf(number)
> 
> It's OK as it stands, but you could write:
> 
> str.chars().filter(Character::isDigit).count()
> 
> which might be more readable

Like this much better, incorporated!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14066#discussion_r1201538926

From pminborg at openjdk.org  Tue May 23 06:37:59 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 23 May 2023 06:37:59 GMT
Subject: Withdrawn: 8307205: Downcall to clibrary printf fails on OS X AArch64
In-Reply-To: <RGUsFPlKWiBPknSzRmsKio30igmDt5EEm9skeIkYBrU=.8b32e588-3cc8-458e-af45-623f7f553a24@github.com>
References: <RGUsFPlKWiBPknSzRmsKio30igmDt5EEm9skeIkYBrU=.8b32e588-3cc8-458e-af45-623f7f553a24@github.com>
Message-ID: <XaS_3gYKAjpF8vKiObrPyiMLnbvaEhF7ZvthhwOVUhY=.299ae1df-b60c-4257-8daa-ab7ba45d10df@github.com>

On Mon, 22 May 2023 15:21:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR adds a test that shows the documented way of calling `printf` works.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14088

From pminborg at openjdk.org  Tue May 23 06:37:58 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 23 May 2023 06:37:58 GMT
Subject: RFR: 8307205: Downcall to clibrary printf fails on OS X AArch64
In-Reply-To: <RGUsFPlKWiBPknSzRmsKio30igmDt5EEm9skeIkYBrU=.8b32e588-3cc8-458e-af45-623f7f553a24@github.com>
References: <RGUsFPlKWiBPknSzRmsKio30igmDt5EEm9skeIkYBrU=.8b32e588-3cc8-458e-af45-623f7f553a24@github.com>
Message-ID: <uA7hACrFkNX2_UUt-Rm-QTV031lpKqaBpGLPC4kt1yc=.bb983eba-ea23-48c5-8dc4-4720bc48f39b@github.com>

On Mon, 22 May 2023 15:21:37 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR adds a test that shows the documented way of calling `printf` works.

I've closed the bug explicitly because it was not a bug. I am going to close this PR as the test is a bit redundant.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14088#issuecomment-1558619579

From pminborg at openjdk.org  Tue May 23 06:50:33 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 23 May 2023 06:50:33 GMT
Subject: RFR: 8308281: Java snippets in the FFM API need to be updated [v4]
In-Reply-To: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>
References: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>
Message-ID: <9zA8oj5bnGts9rlnpHyxAnQTVL01Zbd2mfJtXBgvVXU=.0dd4065a-ead3-4cdc-86bc-67fc50d56bc0@github.com>

> As the API has improved over the recent releases, not all `{@snippet ..}` sections have been kept in sync.
> 
> This PR suggests all snippets used should be verified against real code that is placed in a new `snippet-files` folder and erroneous snippets are updated.
> 
> In this PR, it is suggested duplicating code in the `Snippets.java` class and in the JavaDocs. The benefit of this is that code is directly visible in the code and not only in the generated javadoc.
> 
> Another thing to think about is if there should be on single `Snippets.java` class or separate ones for each FFM class.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove hybrid snippets

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14030/files
  - new: https://git.openjdk.org/jdk/pull/14030/files/df59d9fa..e99d9b33

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14030&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14030&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14030/head:pull/14030

PR: https://git.openjdk.org/jdk/pull/14030

From alanb at openjdk.org  Tue May 23 07:08:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 May 2023 07:08:03 GMT
Subject: Integrated: 8308235: ThreadContainer registry accumulates weak refs
In-Reply-To: <FS-cdoNCm7sqOB8-RRUSEZxfrIgTBlYuH4_UQ9tK7FA=.7f90bd7f-65fc-4945-be38-525c7b233951@github.com>
References: <FS-cdoNCm7sqOB8-RRUSEZxfrIgTBlYuH4_UQ9tK7FA=.7f90bd7f-65fc-4945-be38-525c7b233951@github.com>
Message-ID: <P0YlMo_7Fh6xuIpEEiqTEN5U5YbnGGFUDrnW_azFs4M=.5af9e056-1f45-40aa-8385-b1366fb47aef@github.com>

On Thu, 18 May 2023 15:44:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> ThreadContainers is an internal class used to make thread pools and other groupings of threads discoverable for observability. Some refactoring in 2021 (in the loom repo, and before integration) accidentally changed the creation of a weak reference so that it no longer associated with the reference queue. The result is that stale refs aren't expunged from a CHM, leading to a memory leak. The change to fix the issue is trivial.
> 
> Tests for memory leaks can be problematic, often more trouble than they are worth. I started with a test that polls the size of the internal CHM but decided to ditch it. Instead, the test is simple. It just runs for a few seconds creating ExecuorService implementations (including TPE, TPPE, and FJP), unreferencing them without shutdown (so they don't terminate and unregister). This is enough to causes OOME with product builds a small heap.

This pull request has now been integrated.

Changeset: ada416e6
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ada416e66cbff6c8e631bf352acc0744c248740b
Stats:     52 lines in 2 files changed: 50 ins; 0 del; 2 mod

8308235: ThreadContainer registry accumulates weak refs

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/14047

From alanb at openjdk.org  Tue May 23 07:08:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 May 2023 07:08:57 GMT
Subject: Integrated: 8308038:
 java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java
 timed out
In-Reply-To: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
References: <Nb-dWjt-xZD-572ValQe5BBKxAtbuq9t0FQIFDHk7O8=.a5c3fda2-dbfd-4bf3-8ab3-8dae28bc8c61@github.com>
Message-ID: <x_hU-NMnpKAmi3yoW-dWNCkVuK7HzGY18cEAV6J8NE4=.a5e28ccc-9b1b-48c3-a01e-7709b3fc3c1a@github.com>

On Sun, 21 May 2023 13:52:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a test only change to the unit test for the ExecutorService returned by Executors.newThreadPerTaskExecutor. The tests for interrupting invokeAll assume the threads started to execute the tasks do actually execute the task code. The refresh in JEP 444 changed the implementation to use FutureTask, and FutureTask checks the interrupt status before it executes the task code. So some intermittent timeouts of the tests for interrupting invokeAll as those tests were waiting for the task to complete.
> 
> The main change is that the tests for interrupting invokeAll are changed to interrupt when the main thread blocks in invokeAll. They are also changed to check if the task started or not. The tests for interrupting invokeAny already did this, but these are changed to use the same infrastructure to avoid having two styles of tests in the same source file.

This pull request has now been integrated.

Changeset: fe8c689e
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fe8c689eeea4fa19d4a8742f4ef1d8216f1394e6
Stats:     206 lines in 1 file changed: 87 ins; 57 del; 62 mod

8308038: java/util/concurrent/ThreadPerTaskExecutor/ThreadPerTaskExecutorTest.java timed out

Reviewed-by: dfuchs, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/14072

From dholmes at openjdk.org  Tue May 23 07:22:50 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 23 May 2023 07:22:50 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out
In-Reply-To: <RXGvMnx6U2Sh0ewq8tpbsDIC5B7_hOx-_LescPuAmmE=.2476bace-a3ab-4066-8d2c-ee53d5f3578c@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
 <-R-w4-Pz5g28MPD64fFKsM_QE81Z-WT3nYgveFinhHE=.78191104-9a31-4cfb-b0ed-7b19882737b5@github.com>
 <OxNrLd5U4zRCrdWWu64DL6kOLlAtJNUXx-WP7_xf8HU=.45473fff-c298-4c52-a0b6-b91d72769bc6@github.com>
 <RXGvMnx6U2Sh0ewq8tpbsDIC5B7_hOx-_LescPuAmmE=.2476bace-a3ab-4066-8d2c-ee53d5f3578c@github.com>
Message-ID: <bZfFzUJZQ_KeaPm5ZWpj4pEBkXaW7jZuOfpVhxFyxzw=.8c342b53-4161-4eec-a915-2db5d154ee46@github.com>

On Mon, 22 May 2023 20:23:20 GMT, Viktor Klang <duke at openjdk.org> wrote:

>>> @AlanBateman My thinking was to integrate this and make sure that the problem doesn't resurface before removing it from the problem list. Does that make sense? ?
>> 
>> No objection, it's just it would leave ProblemList-generational-zgc.txt listing a test against as issue marked as fixed.
>
> @AlanBateman I wonder, perhaps it makes more sense, as you say, to clear the problem list together with this, and resurrect it in case it spuriously resurfaces. It's always a challenge to prove a negative. :)

@viktorklang-ora  if you think the test is fixed then you have to remove it from the ProblemList files so that it actually gets tested again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14082#issuecomment-1558679759

From pminborg at openjdk.org  Tue May 23 07:23:18 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 23 May 2023 07:23:18 GMT
Subject: RFR: 8308281: Java snippets in the FFM API need to be updated [v5]
In-Reply-To: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>
References: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>
Message-ID: <bfGixCUJc1dJzGly3OSR6TYxb5C4GCCuBULhkWHZRWo=.ecc9a890-c09f-46c4-bcba-083c57bc0432@github.com>

> As the API has improved over the recent releases, not all `{@snippet ..}` sections have been kept in sync.
> 
> This PR suggests all snippets used should be verified against real code that is placed in a new `snippet-files` folder and erroneous snippets are updated.
> 
> In this PR, it is suggested duplicating code in the `Snippets.java` class and in the JavaDocs. The benefit of this is that code is directly visible in the code and not only in the generated javadoc.
> 
> Another thing to think about is if there should be on single `Snippets.java` class or separate ones for each FFM class.

Per Minborg 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 master
 - Remove hybrid snippets
 - Use hybrid snippets for Arena
 - Fix according to comments
 - Reformat
 - Remove file
 - Add a snippet-files class with snippets

-------------

Changes: https://git.openjdk.org/jdk/pull/14030/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14030&range=04
  Stats: 750 lines in 7 files changed: 689 ins; 4 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/14030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14030/head:pull/14030

PR: https://git.openjdk.org/jdk/pull/14030

From asotona at openjdk.org  Tue May 23 07:27:05 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 23 May 2023 07:27:05 GMT
Subject: Integrated: 8308093: Disable language preview features use in JDK
In-Reply-To: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
References: <YjicnE1WS54xeHFeuIvDB8zwb7hZffMoJIRaQ1-lccY=.ac5996cf-7b22-41be-9ca1-7575403d1f59@github.com>
Message-ID: <_GLlDTboTGCGkynUb5U62e-q8NksFwl0fSGfsBAQzl0=.5f1ef796-ec46-440a-9228-073fc3c2c471@github.com>

On Mon, 22 May 2023 10:01:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch disables temporary use of language preview features in JDK.
> Temporary enabled language preview features (to allow Pattern Matching for switch use in the Classfile API library) are no more necessary.
> All redundant use of --enable-preview in the Classfile API tests are also removed.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: c4408278
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4408278d1012746c91ba4c31068538850c68d30
Stats:     24 lines in 12 files changed: 0 ins; 22 del; 2 mod

8308093: Disable language preview features use in JDK

Reviewed-by: liach, erikj, alanb, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/14076

From pminborg at openjdk.org  Tue May 23 07:29:17 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 23 May 2023 07:29:17 GMT
Subject: RFR: 8308281: Java snippets in the FFM API need to be updated [v6]
In-Reply-To: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>
References: <QOXiQDLxr-bkH3nX5rkCh4xjtDkbTorUVb5VrIly13s=.74055de4-6137-47de-bf18-fe5969926668@github.com>
Message-ID: <DpP5akozdvHDrJ-47YSYySNo2iQXm_Fik-w2FgWHS0Q=.e4987ccd-8b85-4df4-a6a5-31da68685f17@github.com>

> As the API has improved over the recent releases, not all `{@snippet ..}` sections have been kept in sync.
> 
> This PR suggests all snippets used should be verified against real code that is placed in a new `snippet-files` folder and erroneous snippets are updated.
> 
> In this PR, it is suggested duplicating code in the `Snippets.java` class and in the JavaDocs. The benefit of this is that code is directly visible in the code and not only in the generated javadoc.
> 
> Another thing to think about is if there should be on single `Snippets.java` class or separate ones for each FFM class.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove last hybrid snippet

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14030/files
  - new: https://git.openjdk.org/jdk/pull/14030/files/cb114ce5..06d04b24

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14030&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14030&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14030/head:pull/14030

PR: https://git.openjdk.org/jdk/pull/14030

From rrich at openjdk.org  Tue May 23 07:41:05 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 23 May 2023 07:41:05 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v35]
In-Reply-To: <cABEdgxmtvRq8ZYtkWQP27aGKP1GnkoLdTTERYPBSrE=.bcfbbd3c-2b68-4857-8962-5ab2976e8d27@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <cABEdgxmtvRq8ZYtkWQP27aGKP1GnkoLdTTERYPBSrE=.bcfbbd3c-2b68-4857-8962-5ab2976e8d27@github.com>
Message-ID: <_UnPU5zMoXYMnjctnqw9hvTHbJXltv5w0wEJjRVod54=.0d591e6b-5ae4-4c45-88f4-41227d98c745@github.com>

On Mon, 22 May 2023 22:29:18 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separat...
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Parameter Save Area is the correct name.

src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 163:

> 161:   // The Parameter Save Area needs to be at least 8 slots for ABIv1.
> 162:   // ABIv2 allows omitting it when all parameters can get passed in registers. We currently don't optimize this.
> 163:   // For ABIv2, we only need (_input_registers.length() > 8) ? _input_registers.length() : 0

The PSA is also needed if the parameter list is variable in length. Is the expression `(_input_registers.length() > 8) ? _input_registers.length() : 0` correct in that case too?
Otherwise: `ABIv2 allows omitting it if the caller's prototype indicates that stack parameters are not expected. We currently don't optimize this.`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1201693249

From mbaesken at openjdk.org  Tue May 23 07:47:04 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 23 May 2023 07:47:04 GMT
Subject: Integrated: JDK-8308300: enhance exceptions in MappedMemoryUtils.c
In-Reply-To: <HAdmPxpkTj9Xzd-xBZxvAaSDLInLorEi-UvcxygEiUs=.84a938a8-a0c8-4271-a88b-7ffd4356c366@github.com>
References: <HAdmPxpkTj9Xzd-xBZxvAaSDLInLorEi-UvcxygEiUs=.84a938a8-a0c8-4271-a88b-7ffd4356c366@github.com>
Message-ID: <ZRKIuAMQERe-ulM7zpmgf4gnz5Lyxo1M2_KjcuW5XzU=.b7f2e1d3-753d-4fb6-84f5-b8f2f4d62bbd@github.com>

On Fri, 19 May 2023 06:58:49 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> MappedMemoryUtils.c can generate exceptions like those :
> java.io.UncheckedIOException: java.io.IOException: Invalid argument
>        at java.base/java.nio.MappedMemoryUtils.force(MappedMemoryUtils.java:105)
>        at java.base/java.nio.Buffer$2.force(Buffer.java:890)
>        at java.base/jdk.internal.misc.ScopedMemoryAccess.forceInternal(ScopedMemoryAccess.java:317)
>        at java.base/jdk.internal.misc.ScopedMemoryAccess.force(ScopedMemoryAccess.java:305)
>        at java.base/jdk.internal.foreign.MappedMemorySegmentImpl.force(MappedMemorySegmentImpl.java:92)
>        at TestByteBuffer.testMappedSegmentAsByteBuffer(TestByteBuffer.java:327)
> 
> (we see this for example on AIX); there is some room for improvement, at least the info should be added that msync failed and caused this exception.

This pull request has now been integrated.

Changeset: 69f508a2
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/69f508a2ac344eb61cef7be985348873b8265171
Stats:     18 lines in 3 files changed: 13 ins; 0 del; 5 mod

8308300: enhance exceptions in MappedMemoryUtils.c

Reviewed-by: alanb, clanger, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/14054

From rrich at openjdk.org  Tue May 23 07:49:05 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 23 May 2023 07:49:05 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v35]
In-Reply-To: <_UnPU5zMoXYMnjctnqw9hvTHbJXltv5w0wEJjRVod54=.0d591e6b-5ae4-4c45-88f4-41227d98c745@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <cABEdgxmtvRq8ZYtkWQP27aGKP1GnkoLdTTERYPBSrE=.bcfbbd3c-2b68-4857-8962-5ab2976e8d27@github.com>
 <_UnPU5zMoXYMnjctnqw9hvTHbJXltv5w0wEJjRVod54=.0d591e6b-5ae4-4c45-88f4-41227d98c745@github.com>
Message-ID: <S9Qn2AZTRiQDuB0CW-tP7MY-2xiUYl4njfg-PgO07vE=.3a30e96c-8149-4c5b-b0e5-882fc69c5fce@github.com>

On Tue, 23 May 2023 07:37:37 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Parameter Save Area is the correct name.
>
> src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 163:
> 
>> 161:   // The Parameter Save Area needs to be at least 8 slots for ABIv1.
>> 162:   // ABIv2 allows omitting it when all parameters can get passed in registers. We currently don't optimize this.
>> 163:   // For ABIv2, we only need (_input_registers.length() > 8) ? _input_registers.length() : 0
> 
> The PSA is also needed if the parameter list is variable in length. Is the expression `(_input_registers.length() > 8) ? _input_registers.length() : 0` correct in that case too?
> Otherwise: `ABIv2 allows omitting it if the callee's prototype indicates that stack parameters are not expected. We currently don't optimize this.`

Ok, I see now. This is not obvious though. There are a few layers of abstraction at play which hide this. A comment is needed. Maybe like this:
```c++
            // With ABIv1 a Parameter Save Area of at least 8 double words is always needed.
            // ABIv2 allows omitting it if the callee's prototype indicates that stack parameters are not expected.
            // We currently don't optimize this (see DowncallStubGenerator in the backend).
            if (reg == null) return stack;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1201706335

From rrich at openjdk.org  Tue May 23 07:54:04 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 23 May 2023 07:54:04 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v35]
In-Reply-To: <xnXIQ1TL8yWVM2jvoifCKXQjWrFkiWNo9F41mmqD0f8=.d2029def-8155-4d52-909c-a0b38b5c73ae@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <cABEdgxmtvRq8ZYtkWQP27aGKP1GnkoLdTTERYPBSrE=.bcfbbd3c-2b68-4857-8962-5ab2976e8d27@github.com>
 <xnXIQ1TL8yWVM2jvoifCKXQjWrFkiWNo9F41mmqD0f8=.d2029def-8155-4d52-909c-a0b38b5c73ae@github.com>
Message-ID: <fdH_msEgyldxxIaSKoUub5ohu7s4cbR7CObfqaAG_mg=.c01c1acb-6c33-4afa-a3fe-b54615cf41e8@github.com>

On Mon, 22 May 2023 22:44:41 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Thanks for publishing our discussion, here. The unnecessary PSA affects other areas of hotspot much more than Panama. Yes, we should file an RFE. I think one for hotspot is sufficient as the downcall stub is part of it. I don't think it needs extra treatment.

That's fine. It should have a little list of areas to be revisited.

Adoc:

- Runtime calls by the interpreter, c1, and c2
- Interpreted and compiled JNI calls
- FFM API ("Panama") calls
- Runtime calls by continuation intrisics
- Runtime calls by GC barriers

Subtasks can be generated from that list.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12708#issuecomment-1558725262

From chagedorn at openjdk.org  Tue May 23 08:10:09 2023
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Tue, 23 May 2023 08:10:09 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly
In-Reply-To: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
Message-ID: <2DEZv0Dqrai9gFHdJ4RN5SUno7CZzhMVXMEDxr7WB1c=.e260673d-db9d-42f2-8560-496e7c1a37b5@github.com>

On Thu, 4 May 2023 13:36:22 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
> 
> ### Old CompileOnly format
> - matching a **method name** with **class name** and **package name**:
> `-XX:CompileOnly=package/path/Class.method`
> `-XX:CompileOnly=package/path/Class::method`
> `-XX:CompileOnly=package.path.Class::method`
> BUT NOT `-XX:CompileOnly=package.path.Class.method`
> 
> - just matching a **single method name**:
> `-XX:CompileOnly=.hashCode`
> `-XX:CompileOnly=::hashCode`
> BUT NOT `-XX:CompileOnly=hashCode`
> 
> - Matching **all method names** in a **class name** with **package name**
> `-XX:CompileOnly=java/lang/String`
> BUT NOT `-XX:CompileOnly=java/lang/String.`
> BUT NOT `-XX:CompileOnly=java.lang.String`
> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
> BUT NOT `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - Matching **all method names** in a **class name** with **NO package name**
> `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
> 
> ### CompileCommand=compileonly format
> `CompileCommand` allows two different forms for paths: 
> - `package/path/Class.method`
> - `package.path.Class::method`
> 
> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
> 
>  Valid forms: 
> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
> `-XX:CompileCommand=compileonly,java.lang.String::*`
> `-XX:CompileCommand=compileonly,*::hashCode`
> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
> `-XX:CompileCommand=compileonly,*String::hash*`
> 
>  Invalid forms (Error: Embedded * not allowed):
>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
> 
> ### Use CompileCommand syntax for CompileOnly
> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
> 
> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
> 
> With this PR `CompileOnly` becomes an alias for `CompileC...

Nice unification! I just have some small comments. Otherwise, looks good!

src/hotspot/share/compiler/compilerOracle.cpp line 1015:

> 1013: 
> 1014: void CompilerOracle::parse_compile_only(char* line) {
> 1015:   if (line[0] == '\0') return;

I suggest to use braces for single line ifs:

Suggestion:

  if (line[0] == '\0') {
    return;
  }

src/hotspot/share/compiler/compilerOracle.cpp line 1017:

> 1015:   if (line[0] == '\0') return;
> 1016:   ResourceMark rm;
> 1017:   char error_buf[1024] = {0};

Wouldn't it be sufficient to only initialize the first character with `\0`?

src/hotspot/share/compiler/compilerOracle.cpp line 1021:

> 1019:   char* method_pattern;
> 1020:   do {
> 1021:     if (line[0] == '\0') break;

Suggestion:

    if (line[0] == '\0') {
      break;
    }

test/hotspot/jtreg/compiler/loopopts/Test8211698.java line 57:

> 55:     }
> 56: }
> 57: 

You can leave this empty line in at the end of the file.

-------------

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13802#pullrequestreview-1438882451
PR Review Comment: https://git.openjdk.org/jdk/pull/13802#discussion_r1201705460
PR Review Comment: https://git.openjdk.org/jdk/pull/13802#discussion_r1201720761
PR Review Comment: https://git.openjdk.org/jdk/pull/13802#discussion_r1201705793
PR Review Comment: https://git.openjdk.org/jdk/pull/13802#discussion_r1201731777

From duke at openjdk.org  Tue May 23 08:12:00 2023
From: duke at openjdk.org (Marius Lichtblau)
Date: Tue, 23 May 2023 08:12:00 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v4]
In-Reply-To: <5uakOuAdd9XDJ-E5ARGF6EFTixE7W9A5NzucACL3glE=.3dc3ff58-f186-4aa7-b311-792a10dabd86@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <5uakOuAdd9XDJ-E5ARGF6EFTixE7W9A5NzucACL3glE=.3dc3ff58-f186-4aa7-b311-792a10dabd86@github.com>
Message-ID: <WcVhvgsIzKeBRHc9vJTuRIx4LCgzTsU5G4Nhb2PnvbA=.12e98658-7344-4bfe-933e-dd3137e9a673@github.com>

On Mon, 22 May 2023 10:22:16 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8307990
>  - Address comments from tstuefe and RogerRiggs
>  - REALLY adding the test :)
>  - Added test case
>  - 8307990: jspawnhelper must close its writing side of a pipe before reading from it

Hey, chiming on this conversation, because I believe it will fix an issue we encountered since, upgrading from JDK 11 to 17.
In our application we spawn a lot of processes over time and noticed that more and more JVM threads get stuck in the native `ProcessImpl.forkAndExec`.
<details>
<summary>Thread Dump Excerpt</summary>

Thread dump contains multiple threads in this state.

"redacted" #954 prio=5 os_prio=0 cpu=59718.38ms elapsed=286286.30s tid=0x00007f62f80201e0 nid=0x3c16 runnable  [0x00007f609ec56000]
   java.lang.Thread.State: RUNNABLE
	at java.lang.ProcessImpl.forkAndExec(java.base at 17.0.7/Native Method)
	at java.lang.ProcessImpl.<init>(java.base at 17.0.7/ProcessImpl.java:314)
	at java.lang.ProcessImpl.start(java.base at 17.0.7/ProcessImpl.java:244)
	at java.lang.ProcessBuilder.start(java.base at 17.0.7/ProcessBuilder.java:1110)
	at java.lang.ProcessBuilder.start(java.base at 17.0.7/ProcessBuilder.java:1073)

</details>

After some investigation we saw that we have `jspawnhelper` processes corresponding to the number of the stuck threads.
`/proc/*/task/{id}/syscall` shows that all of these processes are currently reading from the pipe.

Our theory is that the write calls from the parent thread were interrupted resulting in an incomplete write. 
https://github.com/openjdk/jdk/blob/69f508a2ac344eb61cef7be985348873b8265171/src/java.base/unix/native/libjava/ProcessImpl_md.c#L556-L559
This would cause the `readFully` on the `jspawnhelper` side to wait for the remaining data.
As the number of bytes written is not checked on the writer side it would continue and wait for the alive ping from the `jspawnhelper` which results in a deadlock.
I would be interested in a reproducer e.g. using `gdb`, but to be honest I wouldn't know where to start.
But regardless of whether this fixes our issue I think incomplete writes should be handled according to specification.
I think the `restartableWrites` in this PR do that?

We also mitigated by falling back to `VFORK` as was also mentioned in [this comment](https://github.com/openjdk/jdk/pull/13956#issuecomment-1547777042). 

Maybe it would be worth it to mention our bug situation in the release notes as well?
Thank you and please let me know if I got something wrong or there is anything I could provide to help!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1558743318

From duke at openjdk.org  Tue May 23 08:27:39 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 23 May 2023 08:27:39 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out [v2]
In-Reply-To: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
Message-ID: <-fVaJz96WfMFD965RD6f00ZPhRnePyIYOZoQUK53Yuk=.9f2b1a67-312c-4d88-96c7-9896e0b8422f@github.com>

> Doubling the max heap size since not all GCs might have compressed OOPs, so this change should make this test more robust.
> 
> Cleared with @DougLea

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Removing OOMEInAQS from zgc problem list

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14082/files
  - new: https://git.openjdk.org/jdk/pull/14082/files/2145e6fb..9d2335d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14082&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14082&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14082/head:pull/14082

PR: https://git.openjdk.org/jdk/pull/14082

From alanb at openjdk.org  Tue May 23 08:27:40 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 May 2023 08:27:40 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out [v2]
In-Reply-To: <-fVaJz96WfMFD965RD6f00ZPhRnePyIYOZoQUK53Yuk=.9f2b1a67-312c-4d88-96c7-9896e0b8422f@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
 <-fVaJz96WfMFD965RD6f00ZPhRnePyIYOZoQUK53Yuk=.9f2b1a67-312c-4d88-96c7-9896e0b8422f@github.com>
Message-ID: <kZHoAf8xw5c2QoCaWHzleEKt45GYjZQxrtovmdpiXxI=.0f499b15-f320-4433-a325-ad394e565697@github.com>

On Tue, 23 May 2023 08:22:22 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Doubling the max heap size since not all GCs might have compressed OOPs, so this change should make this test more robust.
>> 
>> Cleared with @DougLea
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removing OOMEInAQS from zgc problem list

Thanks for removing it from the exclude list.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14082#pullrequestreview-1438956387

From duke at openjdk.org  Tue May 23 08:27:42 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 23 May 2023 08:27:42 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out
In-Reply-To: <bZfFzUJZQ_KeaPm5ZWpj4pEBkXaW7jZuOfpVhxFyxzw=.8c342b53-4161-4eec-a915-2db5d154ee46@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
 <-R-w4-Pz5g28MPD64fFKsM_QE81Z-WT3nYgveFinhHE=.78191104-9a31-4cfb-b0ed-7b19882737b5@github.com>
 <OxNrLd5U4zRCrdWWu64DL6kOLlAtJNUXx-WP7_xf8HU=.45473fff-c298-4c52-a0b6-b91d72769bc6@github.com>
 <RXGvMnx6U2Sh0ewq8tpbsDIC5B7_hOx-_LescPuAmmE=.2476bace-a3ab-4066-8d2c-ee53d5f3578c@github.com>
 <bZfFzUJZQ_KeaPm5ZWpj4pEBkXaW7jZuOfpVhxFyxzw=.8c342b53-4161-4eec-a915-2db5d154ee46@github.com>
Message-ID: <4pw54eCkvE2SG-0bLdJoRvnRgs3hxJJ-Ftoa_3_6k9Y=.689b85cf-0125-49c9-942d-7c719e1104f5@github.com>

On Tue, 23 May 2023 07:19:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @AlanBateman I wonder, perhaps it makes more sense, as you say, to clear the problem list together with this, and resurrect it in case it spuriously resurfaces. It's always a challenge to prove a negative. :)
>
> @viktorklang-ora  if you think the test is fixed then you have to remove it from the ProblemList files so that it actually gets tested again.

@dholmes-ora ? done

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14082#issuecomment-1558766951

From simonis at openjdk.org  Tue May 23 08:33:06 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 23 May 2023 08:33:06 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v4]
In-Reply-To: <5uakOuAdd9XDJ-E5ARGF6EFTixE7W9A5NzucACL3glE=.3dc3ff58-f186-4aa7-b311-792a10dabd86@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <5uakOuAdd9XDJ-E5ARGF6EFTixE7W9A5NzucACL3glE=.3dc3ff58-f186-4aa7-b311-792a10dabd86@github.com>
Message-ID: <ConUar7hFGvvSQviGt7ro6F8hlDv3VaJ5ATDKRAc3_I=.2709bcdd-1775-44ae-a0de-06c1520c9862@github.com>

On Mon, 22 May 2023 10:22:16 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8307990
>  - Address comments from tstuefe and RogerRiggs
>  - REALLY adding the test :)
>  - Added test case
>  - 8307990: jspawnhelper must close its writing side of a pipe before reading from it

> Hey, chiming on this conversation, because I believe it will fix an issue we encountered since, upgrading from JDK 11 to 17. In our application we spawn a lot of processes over time and noticed that more and more JVM threads get stuck in the native `ProcessImpl.forkAndExec`.
> 
> Thread Dump Excerpt
> After some investigation we saw that we have `jspawnhelper` processes corresponding to the number of the stuck threads. `/proc/*/task/{id}/syscall` shows that all of these processes are currently reading from the pipe.
> 
> Our theory is that the write calls from the parent thread were interrupted resulting in an incomplete write.
> 
> https://github.com/openjdk/jdk/blob/69f508a2ac344eb61cef7be985348873b8265171/src/java.base/unix/native/libjava/ProcessImpl_md.c#L556-L559
> 
> 
> This would cause the `readFully` on the `jspawnhelper` side to wait for the remaining data.
> As the number of bytes written is not checked on the writer side it would continue and wait for the alive ping from the `jspawnhelper` which results in a deadlock.
> I would be interested in a reproducer e.g. using `gdb`, but to be honest I wouldn't know where to start.
> But regardless of whether this fixes our issue I think incomplete writes should be handled according to specification.
> I think the `restartableWrites` in this PR do that?
> We also mitigated by falling back to `VFORK` as was also mentioned in [this comment](https://github.com/openjdk/jdk/pull/13956#issuecomment-1547777042).
> 
> Maybe it would be worth it to mention our bug situation in the release notes as well? Thank you and please let me know if I got something wrong or there is anything I could provide to help!

@mlichtblau thanks a lot for your report. I saw some similar reports from our internal Maven builds (have to check though if they are exactly the same). Your analysis of the problem seems sound and I hope the restartable writes will indeed fix the problem.

I'll definitely add your example to the release notes and I'll try if I can come up with a test that reproduces your issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1558794718

From turbanoff at gmail.com  Tue May 23 08:45:37 2023
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Tue, 23 May 2023 11:45:37 +0300
Subject: EnumSet doesn't implement SequencedSet
Message-ID: <CAF+DQ5f=BK3L+LQdHb1Wk7w9dws62YRJzhQFbn+_P0=ns14==A@mail.gmail.com>

Hello.
I've noticed that EnumSet unfortunately doesn't implement the newly
introduced interface SequencedSet.
>From the first look it fits into it.
Is there a reason for that? Sorry if it was already discussed.

Andrey Turbanov

From duke at openjdk.org  Tue May 23 09:02:27 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 23 May 2023 09:02:27 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out [v3]
In-Reply-To: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
Message-ID: <HMsaRRf7tKO1p37PKuXAIdtgG9g3MiuYCWp6I_emU_Q=.cc5cb35a-f0ec-468c-9220-de31757c0855@github.com>

> Doubling the max heap size since not all GCs might have compressed OOPs, so this change should make this test more robust.
> 
> Cleared with @DougLea

Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Removing OOMEInAQS from zgc problem list
 - JDK-8298066: Increasing max heap size for OOMEinAQS since not all GCs might have compressed oops

-------------

Changes: https://git.openjdk.org/jdk/pull/14082/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14082&range=02
  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14082/head:pull/14082

PR: https://git.openjdk.org/jdk/pull/14082

From duke at openjdk.org  Tue May 23 09:02:28 2023
From: duke at openjdk.org (Viktor Klang)
Date: Tue, 23 May 2023 09:02:28 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out [v2]
In-Reply-To: <-fVaJz96WfMFD965RD6f00ZPhRnePyIYOZoQUK53Yuk=.9f2b1a67-312c-4d88-96c7-9896e0b8422f@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
 <-fVaJz96WfMFD965RD6f00ZPhRnePyIYOZoQUK53Yuk=.9f2b1a67-312c-4d88-96c7-9896e0b8422f@github.com>
Message-ID: <fLXyyoCHpbkLjq48ODTffe1k6pCM3PZfmy7DsZ2EF4Q=.f347b357-7cb8-4e6c-91f9-ef5215d53d40@github.com>

On Tue, 23 May 2023 08:27:39 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Doubling the max heap size since not all GCs might have compressed OOPs, so this change should make this test more robust.
>> 
>> Cleared with @DougLea
>
> Viktor Klang has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available.

(Addressed conflict, hence the force-push)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14082#issuecomment-1558845566

From sgehwolf at openjdk.org  Tue May 23 09:04:11 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 23 May 2023 09:04:11 GMT
Subject: RFR: 8308090: Add container tests for on-the-fly resource quota
 updates [v2]
In-Reply-To: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
References: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
Message-ID: <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>

> Please review these test changes which implement automatic testing of container resource updates without JVM restart. Note that this merely tests container detection code handling this case. It doesn't do anything special for the JVM itself, though it might make sense to add some sanity checks should we detect certain limits changing. In another PR, though.
> 
> As to the test design, it works similar to the shared temp tests: Interact between the two containers by virtue of a shared filesystem `/tmp` and creating marker files there in order to make them cooperate. Note that the new test needs `podman` version `4.3.0` and better (`4.5` is current).
> 
> Testing:
>  - [ ] GHA (still running)
>  - [x] Linux x86_64 container tests on cg v1 and cg v2 system
>  - [x] Newly added tests on Linux x86_64 cg v1 and cg v2 (`podman` and `docker`)

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into jdk-8308090-tests-container-on-fly-updates
 - Fix whitespace
 - 8308090: Add container tests for on-the-fly resource quota updates

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14090/files
  - new: https://git.openjdk.org/jdk/pull/14090/files/761f410e..8cca3671

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14090&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14090&range=00-01

  Stats: 18326 lines in 687 files changed: 9112 ins; 4973 del; 4241 mod
  Patch: https://git.openjdk.org/jdk/pull/14090.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14090/head:pull/14090

PR: https://git.openjdk.org/jdk/pull/14090

From tholenstein at openjdk.org  Tue May 23 09:08:20 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Tue, 23 May 2023 09:08:20 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly [v2]
In-Reply-To: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
Message-ID: <3tF5Nlnp_YCBvjfj38WxdiRrYeOyfA9Wz4wJ8tm5z2o=.4719cce4-0d72-485b-9494-cd97594c42fa@github.com>

> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
> 
> ### Old CompileOnly format
> - matching a **method name** with **class name** and **package name**:
> `-XX:CompileOnly=package/path/Class.method`
> `-XX:CompileOnly=package/path/Class::method`
> `-XX:CompileOnly=package.path.Class::method`
> BUT NOT `-XX:CompileOnly=package.path.Class.method`
> 
> - just matching a **single method name**:
> `-XX:CompileOnly=.hashCode`
> `-XX:CompileOnly=::hashCode`
> BUT NOT `-XX:CompileOnly=hashCode`
> 
> - Matching **all method names** in a **class name** with **package name**
> `-XX:CompileOnly=java/lang/String`
> BUT NOT `-XX:CompileOnly=java/lang/String.`
> BUT NOT `-XX:CompileOnly=java.lang.String`
> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
> BUT NOT `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - Matching **all method names** in a **class name** with **NO package name**
> `-XX:CompileOnly=String`
> BUT NOT `-XX:CompileOnly=String.`
> BUT NOT `-XX:CompileOnly=String::`
> 
> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
> 
> ### CompileCommand=compileonly format
> `CompileCommand` allows two different forms for paths: 
> - `package/path/Class.method`
> - `package.path.Class::method`
> 
> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
> 
>  Valid forms: 
> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
> `-XX:CompileCommand=compileonly,java.lang.String::*`
> `-XX:CompileCommand=compileonly,*::hashCode`
> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
> `-XX:CompileCommand=compileonly,*String::hash*`
> 
>  Invalid forms (Error: Embedded * not allowed):
>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
> 
> ### Use CompileCommand syntax for CompileOnly
> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
> 
> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
> 
> With this PR `CompileOnly` becomes an alias for `CompileC...

Tobias Holenstein has updated the pull request incrementally with three additional commits since the last revision:

 - Update Test8211698.java
 - Update src/hotspot/share/compiler/compilerOracle.cpp
   
   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
 - Update src/hotspot/share/compiler/compilerOracle.cpp
   
   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13802/files
  - new: https://git.openjdk.org/jdk/pull/13802/files/d6fca2b8..40b17296

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13802&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13802&range=00-01

  Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13802.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13802/head:pull/13802

PR: https://git.openjdk.org/jdk/pull/13802

From tholenstein at openjdk.org  Tue May 23 09:08:20 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Tue, 23 May 2023 09:08:20 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly [v2]
In-Reply-To: <2DEZv0Dqrai9gFHdJ4RN5SUno7CZzhMVXMEDxr7WB1c=.e260673d-db9d-42f2-8560-496e7c1a37b5@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
 <2DEZv0Dqrai9gFHdJ4RN5SUno7CZzhMVXMEDxr7WB1c=.e260673d-db9d-42f2-8560-496e7c1a37b5@github.com>
Message-ID: <iTXr0jmfIDCgv6LHzNHY8f9j4ph-MPq7Q5xsg4cV0NU=.85aec2ca-afb5-4a1c-a515-6a08c3cbd57c@github.com>

On Tue, 23 May 2023 08:01:07 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Tobias Holenstein has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update Test8211698.java
>>  - Update src/hotspot/share/compiler/compilerOracle.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update src/hotspot/share/compiler/compilerOracle.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>
> test/hotspot/jtreg/compiler/loopopts/Test8211698.java line 57:
> 
>> 55:     }
>> 56: }
>> 57: 
> 
> You can leave this empty line in at the end of the file.

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13802#discussion_r1201860361

From stuefe at openjdk.org  Tue May 23 09:44:59 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Tue, 23 May 2023 09:44:59 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v4]
In-Reply-To: <5uakOuAdd9XDJ-E5ARGF6EFTixE7W9A5NzucACL3glE=.3dc3ff58-f186-4aa7-b311-792a10dabd86@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <5uakOuAdd9XDJ-E5ARGF6EFTixE7W9A5NzucACL3glE=.3dc3ff58-f186-4aa7-b311-792a10dabd86@github.com>
Message-ID: <1y98UzjGPmDKhM5Yq9OyJONJpsmWYSr1mTH9y7QxVY0=.54a67e2f-a10c-4845-bd03-3c61627614aa@github.com>

On Mon, 22 May 2023 10:22:16 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into JDK-8307990
>  - Address comments from tstuefe and RogerRiggs
>  - REALLY adding the test :)
>  - Added test case
>  - 8307990: jspawnhelper must close its writing side of a pipe before reading from it

Looks good. 

Please enable for muslc (see remark). Otherwise, all other remarks are nits and I leave it up to you whether you accept them. I don't need another review.

src/java.base/unix/native/jspawnhelper/jspawnhelper.c line 148:

> 146:     r = sscanf (argv[argc-1], "%d:%d:%d", &fdinr, &fdinw, &fdout);
> 147:     if (r == 3 && fcntl(fdinr, F_GETFD) != -1 && fcntl(fdinw, F_GETFD) != -1) {
> 148:         fstat(fdinr, &buf);

Preexisting, and possibly for another RFE:
- why don't we test fdout as well?
- we probably could make sure the output fds are valid for us (S_ISREG | S_ISFIFO | (possibly?) S_ISSOCK)

test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 28:

> 26:  * @test
> 27:  * @bug 8307990
> 28:  * @requires (os.family == "linux" & !vm.musl)

Muslc supports posix_spawn.

I tested your patch on Alpine, it works and the test works too. Please enable for musl.

test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 92:

> 90:         }
> 91:     }
> 92: 

Small nits, mainly to make this test easier to understand to the casual reader:
- consistent naming: we have "simulateCrashInChild" and "simulateCrashInParent", good, but then we have "childCode", which is actually the code executed in the parent, right?
- simulateCrashInChild and simulateCrashInParent could be merged into one function that does:
  - spawn parent with env var
  - read output, scan for `"posix_spawn:XXX"`
  - parent must have exit code != 0 and should not have timed out
  - if XXX is not 0, check grandchild pid (must not be a live process)

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13956#pullrequestreview-1438535260
PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1201539615
PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1201548057
PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1201770607

From amaembo at gmail.com  Tue May 23 09:57:16 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Tue, 23 May 2023 11:57:16 +0200
Subject: EnumSet doesn't implement SequencedSet
In-Reply-To: <CAF+DQ5f=BK3L+LQdHb1Wk7w9dws62YRJzhQFbn+_P0=ns14==A@mail.gmail.com>
References: <CAF+DQ5f=BK3L+LQdHb1Wk7w9dws62YRJzhQFbn+_P0=ns14==A@mail.gmail.com>
Message-ID: <CAE+3fjZagX91ME_cspP0a7i0b-Wr7PGnohZrxF1DUwNz3jq0zA@mail.gmail.com>

Hello!

Looks like this was overlooked. On the other hand, it could even implement
SortedSet or Navigable set, as it's essentially not just ordered but
sorted, according to the enum natural order. Same for EnumMap.

With best regards,
Tagir Valeev

On Tue, May 23, 2023, 11:46 Andrey Turbanov <turbanoff at gmail.com> wrote:

> Hello.
> I've noticed that EnumSet unfortunately doesn't implement the newly
> introduced interface SequencedSet.
> From the first look it fits into it.
> Is there a reason for that? Sorry if it was already discussed.
>
> Andrey Turbanov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230523/44e4a6e3/attachment.htm>

From sergei.tsypanov at yandex.ru  Tue May 23 11:20:44 2023
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Tue, 23 May 2023 13:20:44 +0200
Subject: Classes used in method body are loaded lazily or eagerly depending on
 method return type
Message-ID: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>

Hello,

originally this question was asked here: https://stackoverflow.com/q/76260269/12473843,
the code sample for reproduction will be put below or can be found via the link

The issue is about eager/lazy loading of a class depending on method return type.
If one runs the code below with Java 11-19 it will fail with NoClassDefFoundError (this is expected as delete class file for ChildClass):

java.lang.NoClassDefFoundError: org/example/TestLoading$ChildClass
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:390)
	at java.base/java.lang.Class.forName(Class.java:381)
	at org.example.TestLoading.loadMyClass(TestLoading.java:29)
	at org.example.TestLoading.main(TestLoading.java:23)
Caused by: java.lang.ClassNotFoundException: org.example.TestLoading$ChildClass
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
	... 5 more

As of Java 20 chapter 12.4.1 of JLS states:
---------------------------------------------------------
A class or interface T will be initialized immediately before the first occurrence of any one of the following:

- T is a class and an instance of T is created.
- a static method declared by T is invoked.
- a static field declared by T is assigned.
- a static field declared by T is used and the field is not a constant variable (?4.12.4).

When a class is initialized, its superclasses are initialized (if they have not been previously initialized), as well as any superinterfaces (?8.1.5) that declare any default methods (?9.4.3) (if they have not been previously initialized).
Initialization of an interface does not, of itself, cause initialization of any of its superinterfaces.
A reference to a static field (?8.3.1.1) causes initialization of only the class or interface that actually declares it, even though it might be referred to through the name of a subclass, a subinterface, or a class that implements an interface.
Invocation of certain reflective methods in class Class and in package java.lang.reflect also causes class or interface initialization.
A class or interface will not be initialized under any other circumstance.
---------------------------------------------------------
With the code snippet we see that calling Class.forName(ObjectReturner.class.getName()) succeeds and Class.forName(BaseClassReturner.class.getName()) fails even though both declare returning an instance of ChildClass.
This failure is unexpected as in the code below we don't fulfill any requirement for class loading as of JLS 12.4.1, but the JVM still tries to load the class.

I suspect it might be related to class file validation and/or security, because when we run the code with -Xlog:class+init there's a reference to LinkageError in loading log:

loading: org.example.TestLoading$BaseClassReturner...
[0.277s][info][class,init] Start class verification for: org.example.TestLoading$BaseClassReturner
[0.277s][info][class,init] 771 Initializing 'java/lang/ReflectiveOperationException'(no method) (0x0000000800004028)
[0.277s][info][class,init] 772 Initializing 'java/lang/ClassNotFoundException'(no method) (0x0000000800004288)
[0.277s][info][class,init] 773 Initializing 'java/lang/LinkageError'(no method) (0x00000008000044f8)                                  <----
[0.277s][info][class,init] 774 Initializing 'java/lang/NoClassDefFoundError'(no method) (0x0000000800004758)
[0.277s][info][class,init] Verification for org.example.TestLoading$BaseClassReturner has exception pending 'java.lang.NoClassDefFoundError org/example/TestLoading$ChildClass'
[0.277s][info][class,init] End class verification for: org.example.TestLoading$BaseClassReturner


So I've got three questions about this:
- Does class loading depend on method's return type?
- Which part of JLS/JVM spec describes eager class loading in this case?
- Could one point out the particular piece of the VM code responsible for class loading in this case?

Regards,
Sergey Tsypanov

Code snippet for reproduction:

public class TestLoading {

  public static void main(String[] args) throws Exception {
    Class.forName(BaseClass.class.getName());
    URL classFileB = TestLoading.class.getResource(TestLoading.class.getSimpleName() + "$ChildClass.class");
    if (classFileB != null) {
      if (!"file".equals(classFileB.getProtocol())) {
        throw new UnsupportedOperationException();
      }
      Path path = new File(classFileB.getPath()).toPath();
      System.out.println("deleting: " + path);
      Files.delete(path);
    }

    loadMyClass(ObjectReturner.class.getName());
    loadMyClass(BaseClassReturner.class.getName());
  }

  private static void loadMyClass(String name) {
    System.out.println("loading: " + name + "...");
    try {
      Class.forName(name);
    } catch (Throwable e) {
      e.printStackTrace(System.out);
    }
  }

  public static class BaseClass {
  }

  public static class ChildClass extends BaseClass {
  }

  public static class ObjectReturner {
    public Object getObject() {
      return new ChildClass();
    }
  }

  public static class BaseClassReturner {
    public BaseClass getObject() {
      return new ChildClass();
    }
  }
}

From david.holmes at oracle.com  Tue May 23 12:14:58 2023
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 23 May 2023 22:14:58 +1000
Subject: Classes used in method body are loaded lazily or eagerly
 depending on method return type
In-Reply-To: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
References: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
Message-ID: <f60f5ae9-348c-6fd4-bea8-8e8f4babf8e1@oracle.com>

Hi,

On 23/05/2023 9:20 pm, ?????? ??????? wrote:
> Hello,
> 
> originally this question was asked here: https://stackoverflow.com/q/76260269/12473843,
> the code sample for reproduction will be put below or can be found via the link
> 
> The issue is about eager/lazy loading of a class depending on method return type.
> If one runs the code below with Java 11-19 it will fail with NoClassDefFoundError (this is expected as delete class file for ChildClass):
> 
> java.lang.NoClassDefFoundError: org/example/TestLoading$ChildClass
> 	at java.base/java.lang.Class.forName0(Native Method)
> 	at java.base/java.lang.Class.forName(Class.java:390)
> 	at java.base/java.lang.Class.forName(Class.java:381)
> 	at org.example.TestLoading.loadMyClass(TestLoading.java:29)
> 	at org.example.TestLoading.main(TestLoading.java:23)
> Caused by: java.lang.ClassNotFoundException: org.example.TestLoading$ChildClass
> 	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> 	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> 	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> 	... 5 more
> 
> As of Java 20 chapter 12.4.1 of JLS states:
> ---------------------------------------------------------
> A class or interface T will be initialized immediately before the first occurrence of any one of the following:
> 
> - T is a class and an instance of T is created.
> - a static method declared by T is invoked.
> - a static field declared by T is assigned.
> - a static field declared by T is used and the field is not a constant variable (?4.12.4).
> 
> When a class is initialized, its superclasses are initialized (if they have not been previously initialized), as well as any superinterfaces (?8.1.5) that declare any default methods (?9.4.3) (if they have not been previously initialized).
> Initialization of an interface does not, of itself, cause initialization of any of its superinterfaces.
> A reference to a static field (?8.3.1.1) causes initialization of only the class or interface that actually declares it, even though it might be referred to through the name of a subclass, a subinterface, or a class that implements an interface.
> Invocation of certain reflective methods in class Class and in package java.lang.reflect also causes class or interface initialization.
> A class or interface will not be initialized under any other circumstance.
> ---------------------------------------------------------
> With the code snippet we see that calling Class.forName(ObjectReturner.class.getName()) succeeds and Class.forName(BaseClassReturner.class.getName()) fails even though both declare returning an instance of ChildClass.
> This failure is unexpected as in the code below we don't fulfill any requirement for class loading as of JLS 12.4.1, but the JVM still tries to load the class.
> 
> I suspect it might be related to class file validation and/or security, because when we run the code with -Xlog:class+init there's a reference to LinkageError in loading log:
> 
> loading: org.example.TestLoading$BaseClassReturner...
> [0.277s][info][class,init] Start class verification for: org.example.TestLoading$BaseClassReturner
> [0.277s][info][class,init] 771 Initializing 'java/lang/ReflectiveOperationException'(no method) (0x0000000800004028)
> [0.277s][info][class,init] 772 Initializing 'java/lang/ClassNotFoundException'(no method) (0x0000000800004288)
> [0.277s][info][class,init] 773 Initializing 'java/lang/LinkageError'(no method) (0x00000008000044f8)                                  <----
> [0.277s][info][class,init] 774 Initializing 'java/lang/NoClassDefFoundError'(no method) (0x0000000800004758)
> [0.277s][info][class,init] Verification for org.example.TestLoading$BaseClassReturner has exception pending 'java.lang.NoClassDefFoundError org/example/TestLoading$ChildClass'
> [0.277s][info][class,init] End class verification for: org.example.TestLoading$BaseClassReturner
> 
> 
> So I've got three questions about this:
> - Does class loading depend on method's return type?
> - Which part of JLS/JVM spec describes eager class loading in this case?
> - Could one point out the particular piece of the VM code responsible for class loading in this case?

Verification can require classes to be loaded to perform the 
verification - see JVMS 4.10 for all the details.

Note you seem to be confusing class loading with class initialization 
above. The rules for initialization are very precise; the rules for 
loading are far more lax.

Cheers,
David
-----

> Regards,
> Sergey Tsypanov
> 
> Code snippet for reproduction:
> 
> public class TestLoading {
> 
>    public static void main(String[] args) throws Exception {
>      Class.forName(BaseClass.class.getName());
>      URL classFileB = TestLoading.class.getResource(TestLoading.class.getSimpleName() + "$ChildClass.class");
>      if (classFileB != null) {
>        if (!"file".equals(classFileB.getProtocol())) {
>          throw new UnsupportedOperationException();
>        }
>        Path path = new File(classFileB.getPath()).toPath();
>        System.out.println("deleting: " + path);
>        Files.delete(path);
>      }
> 
>      loadMyClass(ObjectReturner.class.getName());
>      loadMyClass(BaseClassReturner.class.getName());
>    }
> 
>    private static void loadMyClass(String name) {
>      System.out.println("loading: " + name + "...");
>      try {
>        Class.forName(name);
>      } catch (Throwable e) {
>        e.printStackTrace(System.out);
>      }
>    }
> 
>    public static class BaseClass {
>    }
> 
>    public static class ChildClass extends BaseClass {
>    }
> 
>    public static class ObjectReturner {
>      public Object getObject() {
>        return new ChildClass();
>      }
>    }
> 
>    public static class BaseClassReturner {
>      public BaseClass getObject() {
>        return new ChildClass();
>      }
>    }
> }

From raffaello.giulietti at oracle.com  Tue May 23 14:50:17 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Tue, 23 May 2023 16:50:17 +0200
Subject: Classes used in method body are loaded lazily or eagerly
 depending on method return type
In-Reply-To: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
References: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
Message-ID: <c4954b0c-ca2a-7cb1-4710-36af333e7d06@oracle.com>

I think the problem here is that you are deleting a class in a nest.

During the verification of BaseClassReturner.getObject(), access control 
(JVMS, 5.4.4, second half) determines that the nest is broken, as 
ChildClass is not present anymore.

If you move ChildClass out of TestLoading so that it becomes a top-level 
class extending TestLoading.BaseClass, and if you adapt the line that 
initializes the local var classFileB to refer to the new location, the 
code will not throw, despite ChildClass being deleted.


Greetings
Raffaello



On 2023-05-23 13:20, ?????? ??????? wrote:
> Hello,
> 
> originally this question was asked here: https://stackoverflow.com/q/76260269/12473843,
> the code sample for reproduction will be put below or can be found via the link
> 
> The issue is about eager/lazy loading of a class depending on method return type.
> If one runs the code below with Java 11-19 it will fail with NoClassDefFoundError (this is expected as delete class file for ChildClass):
> 
> java.lang.NoClassDefFoundError: org/example/TestLoading$ChildClass
> 	at java.base/java.lang.Class.forName0(Native Method)
> 	at java.base/java.lang.Class.forName(Class.java:390)
> 	at java.base/java.lang.Class.forName(Class.java:381)
> 	at org.example.TestLoading.loadMyClass(TestLoading.java:29)
> 	at org.example.TestLoading.main(TestLoading.java:23)
> Caused by: java.lang.ClassNotFoundException: org.example.TestLoading$ChildClass
> 	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
> 	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
> 	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
> 	... 5 more
> 
> As of Java 20 chapter 12.4.1 of JLS states:
> ---------------------------------------------------------
> A class or interface T will be initialized immediately before the first occurrence of any one of the following:
> 
> - T is a class and an instance of T is created.
> - a static method declared by T is invoked.
> - a static field declared by T is assigned.
> - a static field declared by T is used and the field is not a constant variable (?4.12.4).
> 
> When a class is initialized, its superclasses are initialized (if they have not been previously initialized), as well as any superinterfaces (?8.1.5) that declare any default methods (?9.4.3) (if they have not been previously initialized).
> Initialization of an interface does not, of itself, cause initialization of any of its superinterfaces.
> A reference to a static field (?8.3.1.1) causes initialization of only the class or interface that actually declares it, even though it might be referred to through the name of a subclass, a subinterface, or a class that implements an interface.
> Invocation of certain reflective methods in class Class and in package java.lang.reflect also causes class or interface initialization.
> A class or interface will not be initialized under any other circumstance.
> ---------------------------------------------------------
> With the code snippet we see that calling Class.forName(ObjectReturner.class.getName()) succeeds and Class.forName(BaseClassReturner.class.getName()) fails even though both declare returning an instance of ChildClass.
> This failure is unexpected as in the code below we don't fulfill any requirement for class loading as of JLS 12.4.1, but the JVM still tries to load the class.
> 
> I suspect it might be related to class file validation and/or security, because when we run the code with -Xlog:class+init there's a reference to LinkageError in loading log:
> 
> loading: org.example.TestLoading$BaseClassReturner...
> [0.277s][info][class,init] Start class verification for: org.example.TestLoading$BaseClassReturner
> [0.277s][info][class,init] 771 Initializing 'java/lang/ReflectiveOperationException'(no method) (0x0000000800004028)
> [0.277s][info][class,init] 772 Initializing 'java/lang/ClassNotFoundException'(no method) (0x0000000800004288)
> [0.277s][info][class,init] 773 Initializing 'java/lang/LinkageError'(no method) (0x00000008000044f8)                                  <----
> [0.277s][info][class,init] 774 Initializing 'java/lang/NoClassDefFoundError'(no method) (0x0000000800004758)
> [0.277s][info][class,init] Verification for org.example.TestLoading$BaseClassReturner has exception pending 'java.lang.NoClassDefFoundError org/example/TestLoading$ChildClass'
> [0.277s][info][class,init] End class verification for: org.example.TestLoading$BaseClassReturner
> 
> 
> So I've got three questions about this:
> - Does class loading depend on method's return type?
> - Which part of JLS/JVM spec describes eager class loading in this case?
> - Could one point out the particular piece of the VM code responsible for class loading in this case?
> 
> Regards,
> Sergey Tsypanov
> 
> Code snippet for reproduction:
> 
> public class TestLoading {
> 
>    public static void main(String[] args) throws Exception {
>      Class.forName(BaseClass.class.getName());
>      URL classFileB = TestLoading.class.getResource(TestLoading.class.getSimpleName() + "$ChildClass.class");
>      if (classFileB != null) {
>        if (!"file".equals(classFileB.getProtocol())) {
>          throw new UnsupportedOperationException();
>        }
>        Path path = new File(classFileB.getPath()).toPath();
>        System.out.println("deleting: " + path);
>        Files.delete(path);
>      }
> 
>      loadMyClass(ObjectReturner.class.getName());
>      loadMyClass(BaseClassReturner.class.getName());
>    }
> 
>    private static void loadMyClass(String name) {
>      System.out.println("loading: " + name + "...");
>      try {
>        Class.forName(name);
>      } catch (Throwable e) {
>        e.printStackTrace(System.out);
>      }
>    }
> 
>    public static class BaseClass {
>    }
> 
>    public static class ChildClass extends BaseClass {
>    }
> 
>    public static class ObjectReturner {
>      public Object getObject() {
>        return new ChildClass();
>      }
>    }
> 
>    public static class BaseClassReturner {
>      public BaseClass getObject() {
>        return new ChildClass();
>      }
>    }
> }

From alanb at openjdk.org  Tue May 23 15:09:52 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 May 2023 15:09:52 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out [v3]
In-Reply-To: <HMsaRRf7tKO1p37PKuXAIdtgG9g3MiuYCWp6I_emU_Q=.cc5cb35a-f0ec-468c-9220-de31757c0855@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
 <HMsaRRf7tKO1p37PKuXAIdtgG9g3MiuYCWp6I_emU_Q=.cc5cb35a-f0ec-468c-9220-de31757c0855@github.com>
Message-ID: <p5wvPFlOpdFDzIFAwD7Yy_n6gAyrNSr_Bx1Q14I_uzo=.42259340-4124-4d7a-9b28-c14e8dd69b1d@github.com>

On Tue, 23 May 2023 09:02:27 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Doubling the max heap size since not all GCs might have compressed OOPs, so this change should make this test more robust.
>> 
>> Cleared with @DougLea
>
> Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Removing OOMEInAQS from zgc problem list
>  - JDK-8298066: Increasing max heap size for OOMEinAQS since not all GCs might have compressed oops

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14082#pullrequestreview-1439681598

From asotona at openjdk.org  Tue May 23 15:10:41 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 23 May 2023 15:10:41 GMT
Subject: RFR: 8308549: Classfile API should fail to generate over-sized Code
 attribute
Message-ID: <FMfhhGe4XrEG4Brj1GZS69ovfeNMSAEeLwlMq05SzwA=.7014deec-41a2-44cc-b4bd-51f3f71f291b@github.com>

Classfile API allowed to generate Code attribute exceeding the 65k limit. No exception has been thrown during class generation and the class failed verification later during class loading.
This patch adds Code size limit check throwing IllegalArgumentException.
The patch also adds similar check for constant pool size limit to avoid generation class file with corrupted  constant pool.
Two new tests are added to check response on oversized Code attribute and constant pool.
`VerifierImpl` is extended to check Code attribute size as a part of class verification process.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8308549: Classfile API should fail to generate over-sized Code attribute

Changes: https://git.openjdk.org/jdk/pull/14100/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14100&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308549
  Stats: 40 lines in 4 files changed: 35 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14100.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14100/head:pull/14100

PR: https://git.openjdk.org/jdk/pull/14100

From michaelm at openjdk.org  Tue May 23 15:11:22 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 23 May 2023 15:11:22 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters
Message-ID: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>

This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.

This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).

-------------

Commit messages:
 - test update
 - Merge branch 'master' into nullStrings
 - exception message update
 - test update
 - remve whitespace
 - update
 - Merge branch 'master' into nullStrings
 - first impl

Changes: https://git.openjdk.org/jdk/pull/14083/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14083&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300038
  Stats: 183 lines in 9 files changed: 163 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/14083.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14083/head:pull/14083

PR: https://git.openjdk.org/jdk/pull/14083

From simonis at openjdk.org  Tue May 23 15:14:30 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 23 May 2023 15:14:30 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v5]
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <pYn_FUefSOtB0ZlX1-FPUYwj_fU1h-fd4kpTQqyWOkU=.079b53b8-5462-4556-9172-658ee2b4a8fa@github.com>

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Test: added better description, enabled for musl and improved wording in logs/exceptions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13956/files
  - new: https://git.openjdk.org/jdk/pull/13956/files/6649b725..facbdcf3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13956&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13956&range=03-04

  Stats: 28 lines in 1 file changed: 12 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/13956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13956/head:pull/13956

PR: https://git.openjdk.org/jdk/pull/13956

From rriggs at openjdk.org  Tue May 23 15:14:42 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 23 May 2023 15:14:42 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v5]
In-Reply-To: <pYn_FUefSOtB0ZlX1-FPUYwj_fU1h-fd4kpTQqyWOkU=.079b53b8-5462-4556-9172-658ee2b4a8fa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <pYn_FUefSOtB0ZlX1-FPUYwj_fU1h-fd4kpTQqyWOkU=.079b53b8-5462-4556-9172-658ee2b4a8fa@github.com>
Message-ID: <v0SQi4on5O3GQebhugVNYRZO29IcLdz7Q2Hhfij0WdY=.82fb3c7a-6649-4e30-8f1e-a54307a0cb2d@github.com>

On Tue, 23 May 2023 14:21:06 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test: added better description, enabled for musl and improved wording in logs/exceptions

ok with latest doc and naming updates.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13956#pullrequestreview-1439795305

From simonis at openjdk.org  Tue May 23 15:15:05 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 23 May 2023 15:15:05 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v4]
In-Reply-To: <1y98UzjGPmDKhM5Yq9OyJONJpsmWYSr1mTH9y7QxVY0=.54a67e2f-a10c-4845-bd03-3c61627614aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <5uakOuAdd9XDJ-E5ARGF6EFTixE7W9A5NzucACL3glE=.3dc3ff58-f186-4aa7-b311-792a10dabd86@github.com>
 <1y98UzjGPmDKhM5Yq9OyJONJpsmWYSr1mTH9y7QxVY0=.54a67e2f-a10c-4845-bd03-3c61627614aa@github.com>
Message-ID: <CVEcu8kac6NLyTBkt7tuY7FAA3vQqT8YzbLwoPvpwtk=.5dc09777-f54a-43d7-90d4-fab20a871cfd@github.com>

On Tue, 23 May 2023 05:34:15 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Volker Simonis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - Merge branch 'master' into JDK-8307990
>>  - Address comments from tstuefe and RogerRiggs
>>  - REALLY adding the test :)
>>  - Added test case
>>  - 8307990: jspawnhelper must close its writing side of a pipe before reading from it
>
> test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 28:
> 
>> 26:  * @test
>> 27:  * @bug 8307990
>> 28:  * @requires (os.family == "linux" & !vm.musl)
> 
> Muslc supports posix_spawn.
> 
> I tested your patch on Alpine, it works and the test works too. Please enable for musl.

Thanks, will do.

> test/jdk/java/lang/ProcessBuilder/JspawnhelperProtocol.java line 92:
> 
>> 90:         }
>> 91:     }
>> 92: 
> 
> Small nits, mainly to make this test easier to understand to the casual reader:
> - consistent naming: we have "simulateCrashInChild" and "simulateCrashInParent", good, but then we have "childCode", which is actually the code executed in the parent, right?
> - simulateCrashInChild and simulateCrashInParent could be merged into one function that does:
>   - spawn parent with env var
>   - read output, scan for `"posix_spawn:XXX"`
>   - parent must have exit code != 0 and should not have timed out
>   - if XXX is not 0, check grandchild pid (must not be a live process)

This sounds reasonable. I've renamed `childCode()` to `parentCode()`, streamlined the wording for "parent" and "child" in the various log messages and exceptions and added a comment to the `main()` method which explains the working of the test and the meaning of "parent" and "child" in the output.

I've not merged `simulateCrashInChild()` and `simulateCrashInParent()` because there are some subtle differences between the two (and now with the improved "parent"/"child" naming even more :) and I don't think that a merged version will improve the readability.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1202266007
PR Review Comment: https://git.openjdk.org/jdk/pull/13956#discussion_r1202365663

From simonis at openjdk.org  Tue May 23 15:14:42 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 23 May 2023 15:14:42 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <61e5pVShTICWmDodgIDEACwz-NJB6OMUOw2crLQ2zTE=.2fc8ed80-5979-45c1-8797-ac2a8b47157e@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>
 <WNS9AUc4Uo0uJT7Q-c5WmRQGPXKHOiQ5bk3FAVhcpTw=.7b192c55-1a39-48bf-9c36-eb8219474c4f@github.com>
 <u7bSYYuppXZ1z347-wRTJf9GoxNUW-GoWfSn4dmCLEE=.831249e0-e538-491c-8001-a7dd55673721@github.com>
 <yZM9iro4FRdHveBRx07oeItZ9_CmQJ4wksNo3XI8Igs=.7b2097d5-0852-4f04-9c14-fc8d39a57c08@github.com>
 <qh4P0rQhdigeWLoD9paOaTJgT7uXOU0IsBTQlFdZ3Ew=.1eb8ea15-2d10-45e3-b883-87b088e220ba@github.com>
 <Q1qJR_GJWPvAItv1fmJu-QYM0g5ozWkWd2ljkAy7VQ8=.3a657b07-464d-4184-a667-a3f9a7c9c72a@github.com>
 <61e5pVShTICWmDodgIDEACwz-NJB6OMUOw2crLQ2zTE=.2fc8ed80-5979-45c1-8797-ac2a8b47157e@github.com>
Message-ID: <856EyprqUzpqqfBJsW7ntneq2hoMLQ-DLZyW_1J90bk=.a1696d8a-37e6-42fb-b3cd-cdc0ea460e06@github.com>

On Fri, 19 May 2023 15:43:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> Sorry, but I don't understand this argument. If we do a short read we will work with corrupted ChildStuff and SpawnInfo 
>>> structures. This can in the extreme case execute arbitrary code (e.g. if ChildStuff.argv is not fully read from the parent). You are 
>>> basically saying it is better to work on corrupted data rather than reporting an error.
>> 
>> No I am simply pointing out that this has changed more than just the issue with close. And maybe a short-read does indicate data "corruption" and maybe it should be a fatal error. But I don't know exactly how this might manifest so perhaps there are benign short-reads that actually do happen. Regardless it might be better to split this part out and focus on the close issue here.
>
>> > Sorry, but I don't understand this argument. If we do a short read we will work with corrupted ChildStuff and SpawnInfo
>> > structures. This can in the extreme case execute arbitrary code (e.g. if ChildStuff.argv is not fully read from the parent). You are
>> > basically saying it is better to work on corrupted data rather than reporting an error.
>> 
>> No I am simply pointing out that this has changed more than just the issue with close. And maybe a short-read does indicate data "corruption" and maybe it should be a fatal error. But I don't know exactly how this might manifest so perhaps there are benign short-reads that actually do happen. Regardless it might be better to split this part out and focus on the close issue here.
> 
> Given the purpose and implementation of the `readFully` function, I don't see how it can return anything other than an error or the full requested read length.

@RogerRiggs , @tstuefe thanks for your reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1559423017

From mdoerr at openjdk.org  Tue May 23 15:21:02 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 23 May 2023 15:21:02 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v36]
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <KKNNiTG9blypCJS4z6JVaq1xltjRJI4a82E7jtwS998=.35ba5b42-3f77-4187-aac0-6b854b1f0681@github.com>

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: T...

Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:

  Improve comments about the Parameter Save Area.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12708/files
  - new: https://git.openjdk.org/jdk/pull/12708/files/b912155b..5a00d804

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=35
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12708&range=34-35

  Stats: 8 lines in 2 files changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12708.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12708/head:pull/12708

PR: https://git.openjdk.org/jdk/pull/12708

From mdoerr at openjdk.org  Tue May 23 15:21:11 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 23 May 2023 15:21:11 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v35]
In-Reply-To: <S9Qn2AZTRiQDuB0CW-tP7MY-2xiUYl4njfg-PgO07vE=.3a30e96c-8149-4c5b-b0e5-882fc69c5fce@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <cABEdgxmtvRq8ZYtkWQP27aGKP1GnkoLdTTERYPBSrE=.bcfbbd3c-2b68-4857-8962-5ab2976e8d27@github.com>
 <_UnPU5zMoXYMnjctnqw9hvTHbJXltv5w0wEJjRVod54=.0d591e6b-5ae4-4c45-88f4-41227d98c745@github.com>
 <S9Qn2AZTRiQDuB0CW-tP7MY-2xiUYl4njfg-PgO07vE=.3a30e96c-8149-4c5b-b0e5-882fc69c5fce@github.com>
Message-ID: <bV_bQlasw-ST3EHQ_D-zinoVIe0bYAnBD8VQ-iba7_8=.58542ea8-2d07-4ecb-80ae-d0839ebc6446@github.com>

On Tue, 23 May 2023 07:46:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/cpu/ppc/downcallLinker_ppc.cpp line 163:
>> 
>>> 161:   // The Parameter Save Area needs to be at least 8 slots for ABIv1.
>>> 162:   // ABIv2 allows omitting it when all parameters can get passed in registers. We currently don't optimize this.
>>> 163:   // For ABIv2, we only need (_input_registers.length() > 8) ? _input_registers.length() : 0
>> 
>> The PSA is also needed if the parameter list is variable in length. Is the expression `(_input_registers.length() > 8) ? _input_registers.length() : 0` correct in that case too?
>> Otherwise: `ABIv2 allows omitting it if the callee's prototype indicates that stack parameters are not expected. We currently don't optimize this.`
>
> Ok, I see now. This is not obvious though. There are a few layers of abstraction at play which hide this. A comment is needed. Maybe like this:
> ```c++
>             // With ABIv1 a Parameter Save Area of at least 8 double words is always needed.
>             // ABIv2 allows omitting it if the callee's prototype indicates that stack parameters are not expected.
>             // We currently don't optimize this (see DowncallStubGenerator in the backend).
>             if (reg == null) return stack;

I believe omitting the PSA is wrong for varargs, but we don't have this information in the backend. So, I think we should simply not optimize it. Reserving 64 Byte stack space should be affordable for a downcall even if it's not always needed. The Java side could compute it, but there's no way to pass this information to the backend. I've improved the comments. Please take a look.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1202235085

From liach at openjdk.org  Tue May 23 15:29:29 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 May 2023 15:29:29 GMT
Subject: RFR: 8308549: Classfile API should fail to generate over-sized
 Code attribute
In-Reply-To: <FMfhhGe4XrEG4Brj1GZS69ovfeNMSAEeLwlMq05SzwA=.7014deec-41a2-44cc-b4bd-51f3f71f291b@github.com>
References: <FMfhhGe4XrEG4Brj1GZS69ovfeNMSAEeLwlMq05SzwA=.7014deec-41a2-44cc-b4bd-51f3f71f291b@github.com>
Message-ID: <u-iJuFVDgm7hlBCP1zWAdAtmI7icAIdBH-XZV8L2dno=.0acdf4d8-adae-46f8-9b48-8c91a3c19b16@github.com>

On Tue, 23 May 2023 12:54:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile API allowed to generate Code attribute exceeding the 65k limit. No exception has been thrown during class generation and the class failed verification later during class loading.
> This patch adds Code size limit check throwing IllegalArgumentException.
> The patch also adds similar check for constant pool size limit to avoid generation class file with corrupted  constant pool.
> Two new tests are added to check response on oversized Code attribute and constant pool.
> `VerifierImpl` is extended to check Code attribute size as a part of class verification process.
> 
> Please review.
> 
> Thanks,
> Adam

On a side note, does Classfile API reject methods with too many slots (locals) (MethodTypeDesc can represent parameter lists with over 255 slots) or stack (operand)?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14100#issuecomment-1559642335

From mcimadamore at openjdk.org  Tue May 23 15:31:02 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 23 May 2023 15:31:02 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed
In-Reply-To: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
Message-ID: <uXweDKpEWFgfF_inYu9ZEkPt5J0AHPp4LBQ4RlmlJCE=.43cffb2f-871b-4578-9806-153c5b5d5ee2@github.com>

On Tue, 23 May 2023 11:48:59 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
> 
> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
> 
> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
> 
> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
> 
> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
> 
> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
> 
> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
> 
> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
> 
> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can throw because of an ...

Javadoc: https://cr.openjdk.org/~mcimadamore/jdk/8308645/javadoc/java.base/java/lang/foreign/package-summary.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14098#issuecomment-1559552992

From mcimadamore at openjdk.org  Tue May 23 15:30:59 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 23 May 2023 15:30:59 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed
Message-ID: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>

As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.

While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:

* `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.

* `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.

* `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.

* In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.

In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).

The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).

Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can throw because of an overflow during offset computation.

Finally, I've left most of the snippets alone, as they are being dealt with in https://github.com/openjdk/jdk/pull/14030

-------------

Commit messages:
 - Merge branch 'master' into javadoc_fixes
 - Add overflow tests
 - Fix overflow @throw in MemorySegment::copy
 - Add overflow @throws clause on SegmentAllocator::allocateArray
 - More fixes to MemoryLayout
 - Finish ValueLayout
 - Merge branch 'master' into javadoc_fixes
 - Finish SymbolLookup
 - Finish SequenceLayout/StructLayout/UnionLayout
 - Finish SegmentAllocator
 - ... and 11 more: https://git.openjdk.org/jdk/compare/c0c4d771...afb7360e

Changes: https://git.openjdk.org/jdk/pull/14098/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14098&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308645
  Stats: 818 lines in 23 files changed: 269 ins; 116 del; 433 mod
  Patch: https://git.openjdk.org/jdk/pull/14098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14098/head:pull/14098

PR: https://git.openjdk.org/jdk/pull/14098

From alanb at openjdk.org  Tue May 23 15:31:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 May 2023 15:31:24 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
Message-ID: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>

This is the implementation of:

- JEP 453: Structured Concurrency (Preview)
- JEP 446: Scoped Values (Preview)

For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:

- StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
- ScopedValue.where methods are replaced with runWhere, callWhere and getWhere

-------------

Commit messages:
 - Test should not be in update for main line
 - Sync with loom repo
 - Sync up tests frmo loom repo
 - Sync up with loom repo
 - Sync update API/impl/tests
 - Merge
 - Sync up with loom repo
 - Merge
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/13932/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13932&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306647
  Stats: 9389 lines in 42 files changed: 4995 ins; 4330 del; 64 mod
  Patch: https://git.openjdk.org/jdk/pull/13932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13932/head:pull/13932

PR: https://git.openjdk.org/jdk/pull/13932

From michaelm at openjdk.org  Tue May 23 15:31:49 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 23 May 2023 15:31:49 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v2]
In-Reply-To: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
Message-ID: <r_qqI8I4_pGoPgxWMRB4iusdSYt4LL3oEr5SK8KohcI=.5f16a2fd-47d3-4587-8c4d-88bf480c1ad7@github.com>

> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
> 
> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).

Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:

  test comment update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14083/files
  - new: https://git.openjdk.org/jdk/pull/14083/files/8cf24635..0acc456a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14083&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14083&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14083.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14083/head:pull/14083

PR: https://git.openjdk.org/jdk/pull/14083

From alanb at openjdk.org  Tue May 23 15:31:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 May 2023 15:31:38 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
In-Reply-To: <aseaLvZ5OlPRUbqiUIvhVIak85RfTstljxSDVlnNYGg=.5fbed2d7-f6a2-49fc-a8e6-ca2c37d08097@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
 <aseaLvZ5OlPRUbqiUIvhVIak85RfTstljxSDVlnNYGg=.5fbed2d7-f6a2-49fc-a8e6-ca2c37d08097@github.com>
Message-ID: <GKc6SPQM8wJ85aPX-cTCSAIYeDbxDpmRzK7AQaVYfQM=.5fa5e537-dd7f-4291-aa35-7ae39a56db8d@github.com>

On Sat, 20 May 2023 00:27:23 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This is the implementation of:
>> 
>> - JEP 453: Structured Concurrency (Preview)
>> - JEP 446: Scoped Values (Preview)
>> 
>> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
>> 
>> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
>> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere
>
> src/java.base/share/classes/java/lang/ScopedValue.java line 252:
> 
>> 250:      * bound (or rebound) to {@code v1}, and {@code k2} bound (or rebound) to {@code v2}.
>> 251:      * {@snippet lang=java :
>> 252:      *     // @link substring="runWhere" target="#runWhere(ScopedValue, Object)" :
> 
> Is this correct?

Good catch, might have been the victim of search and replace, it should continue to link to ScopedValue.where.

> src/java.base/share/classes/java/lang/ScopedValue.java line 399:
> 
>> 397:             var prevSnapshot = scopedValueBindings();
>> 398:             var newSnapshot = new Snapshot(this, prevSnapshot);
>> 399:             return runWith(newSnapshot, new CallableAdapter<R>(op));
> 
> Can we just do this instead?
> Suggestion:
> 
>             return runWith(newSnapshot, op::get);
> 
> IIUC the current approach is to avoid the dynamic creation of a class via the invoke dynamic? I don't fully understand the comment about release fencing.

@theRealAph will want to comment on this as it is very performance sensitive. I think CallableAdapter.s is non-final to avoid the release fence.

> src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1077:
> 
>> 1075:             }
>> 1076: 
>> 1077:             throw new IllegalStateException("No completed subtasks");
> 
> I believe it may be possible to implement as the following if you so wish:
> Suggestion:
> 
>             return result(ExecutionException::new);

Good, avoids duplication.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1199577982
PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1200899135
PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1202097524

From dfuchs at openjdk.org  Tue May 23 15:31:51 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 23 May 2023 15:31:51 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v2]
In-Reply-To: <r_qqI8I4_pGoPgxWMRB4iusdSYt4LL3oEr5SK8KohcI=.5f16a2fd-47d3-4587-8c4d-88bf480c1ad7@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
 <r_qqI8I4_pGoPgxWMRB4iusdSYt4LL3oEr5SK8KohcI=.5f16a2fd-47d3-4587-8c4d-88bf480c1ad7@github.com>
Message-ID: <srVILxcHJG1Yqnijz7VPoFC0UqUcvmts6eW_H1MqTGE=.f7fdee42-c681-42e1-b0f1-b3652229f554@github.com>

On Tue, 23 May 2023 15:18:36 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
>> 
>> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test comment update

test/jdk/java/net/InetAddress/NullCharDriver.java line 29:

> 27:  * @modules java.base/java.net
> 28:  * @compile/module=java.base java/net/NullChar.java
> 29:  * @summary foo

It would be good to have a better summary ;-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14083#discussion_r1202541587

From psandoz at openjdk.org  Tue May 23 15:31:36 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 23 May 2023 15:31:36 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
In-Reply-To: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
Message-ID: <aseaLvZ5OlPRUbqiUIvhVIak85RfTstljxSDVlnNYGg=.5fbed2d7-f6a2-49fc-a8e6-ca2c37d08097@github.com>

On Thu, 11 May 2023 13:08:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of:
> 
> - JEP 453: Structured Concurrency (Preview)
> - JEP 446: Scoped Values (Preview)
> 
> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
> 
> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere

src/java.base/share/classes/java/lang/ScopedValue.java line 252:

> 250:      * bound (or rebound) to {@code v1}, and {@code k2} bound (or rebound) to {@code v2}.
> 251:      * {@snippet lang=java :
> 252:      *     // @link substring="runWhere" target="#runWhere(ScopedValue, Object)" :

Is this correct?

src/java.base/share/classes/java/lang/ScopedValue.java line 399:

> 397:             var prevSnapshot = scopedValueBindings();
> 398:             var newSnapshot = new Snapshot(this, prevSnapshot);
> 399:             return runWith(newSnapshot, new CallableAdapter<R>(op));

Can we just do this instead?
Suggestion:

            return runWith(newSnapshot, op::get);

IIUC the current approach is to avoid the dynamic creation of a class via the invoke dynamic? I don't fully understand the comment about release fencing.

src/java.base/share/classes/java/lang/ScopedValue.java line 408:

> 406:         // runtime bytecode generation nor any release fencing.
> 407:         private static final class CallableAdapter<V> implements Callable<V> {
> 408:             private Supplier<? extends V> s;

Suggestion:

            private final Supplier<? extends V> s;

src/java.base/share/classes/java/lang/ScopedValue.java line 558:

> 556:      * This method is implemented to be equivalent to:
> 557:      * {@snippet lang=java :
> 558:      *     // @link substring="call" target="Carrier#call(Callable)" :

Suggestion:

     *     // @link substring="get" target="Carrier#get(Supplier)" :

?

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 159:

> 157:  * The example uses {@link Supplier#get()} to get the result of each subtask. Using
> 158:  * {@code Supplier} instead of {@code Subtask} is preferred for common cases where the
> 159:  * the object returned by fork is only used to get the result of a subtask that completed

Suggestion:

 * {@code Supplier} instead of {@code Subtask} is preferred for common cases where
 * the object returned by fork is only used to get the result of a subtask that completed

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1077:

> 1075:             }
> 1076: 
> 1077:             throw new IllegalStateException("No completed subtasks");

I believe it may be possible to implement as the following if you so wish:
Suggestion:

            return result(ExecutionException::new);

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1251:

> 1249:             Throwable exception = firstException;
> 1250:             if (exception != null)
> 1251:                 throw new ExecutionException(exception);

Suggestion:

            throwIfFailed(ExecutionException::new);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1199509233
PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1200863513
PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1199502950
PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1199508974
PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1200910221
PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1201014854
PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1201028382

From aph at openjdk.org  Tue May 23 15:31:42 2023
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 23 May 2023 15:31:42 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
In-Reply-To: <GKc6SPQM8wJ85aPX-cTCSAIYeDbxDpmRzK7AQaVYfQM=.5fa5e537-dd7f-4291-aa35-7ae39a56db8d@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
 <aseaLvZ5OlPRUbqiUIvhVIak85RfTstljxSDVlnNYGg=.5fbed2d7-f6a2-49fc-a8e6-ca2c37d08097@github.com>
 <GKc6SPQM8wJ85aPX-cTCSAIYeDbxDpmRzK7AQaVYfQM=.5fa5e537-dd7f-4291-aa35-7ae39a56db8d@github.com>
Message-ID: <K_3lHIPmRRc3VMIUS7O2dsIXMDsvUwPxOdVV91cgaL8=.00326c77-1bee-4193-99e5-ccf38a25fafb@github.com>

On Mon, 22 May 2023 18:42:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/ScopedValue.java line 399:
>> 
>>> 397:             var prevSnapshot = scopedValueBindings();
>>> 398:             var newSnapshot = new Snapshot(this, prevSnapshot);
>>> 399:             return runWith(newSnapshot, new CallableAdapter<R>(op));
>> 
>> Can we just do this instead?
>> Suggestion:
>> 
>>             return runWith(newSnapshot, op::get);
>> 
>> IIUC the current approach is to avoid the dynamic creation of a class via the invoke dynamic? I don't fully understand the comment about release fencing.
>
> @theRealAph will want to comment on this as it is very performance sensitive. I think CallableAdapter.s is non-final to avoid the release fence.

That's right. The problem is that we can never get rid of the release fence, apparently even when the instance of the adapter is scalar replaced. I imagine that'll get fixed one day, but this is internal JDK code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1202492523

From dfuchs at openjdk.org  Tue May 23 15:34:35 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 23 May 2023 15:34:35 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v2]
In-Reply-To: <r_qqI8I4_pGoPgxWMRB4iusdSYt4LL3oEr5SK8KohcI=.5f16a2fd-47d3-4587-8c4d-88bf480c1ad7@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
 <r_qqI8I4_pGoPgxWMRB4iusdSYt4LL3oEr5SK8KohcI=.5f16a2fd-47d3-4587-8c4d-88bf480c1ad7@github.com>
Message-ID: <jmMenM59kPNjhv1hv630a4EuZOPU8D-wl15W08xD0kg=.81c28b6e-3a62-4f44-b3e5-6152d6f0454f@github.com>

On Tue, 23 May 2023 15:31:49 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
>> 
>> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test comment update

Looks good to me, but it would be good to get this reviewed by someone with more knowledge of native character encoding.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14083#pullrequestreview-1439991999

From tholenstein at openjdk.org  Tue May 23 15:50:56 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Tue, 23 May 2023 15:50:56 GMT
Subject: RFR: JDK-8282797: CompileCommand parsing errors should exit VM
Message-ID: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>

Currently, errors during compile command parsing just print an error but don't exit the VM. As a result, issues go unnoticed. 

With this PR the behavior is changed to exit the VM when an error occurs.

E.g. `java -XX:CompileCommand=compileonly,HashMap:: -version` will exit the VM after a parsing occurred.  

CompileCommand: An error occurred during parsing
Error: Could not parse method pattern
Line: 'compileonly,HashMap::'

Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
Use:   '-XX:CompileCommand=help' for more information and to list all option.

Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.


### Updated Tests
Updated all tests to now expect an error code `1` for wrong `CompileCommand`

-------------

Commit messages:
 - update copyright
 - fix trailing whitespace
 - Update CheckCompileCommandOption.java
 - Update PrintIdealPhaseTest.java
 - update OptionTest.java: _id is not a valid intrinsics
 - update CompilerConfigFileWarning.java
 - adjust Scenario.java for failing CompileCommands
 - JDK-8282797: CompileCommand parsing errors should exit VM

Changes: https://git.openjdk.org/jdk/pull/13753/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13753&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8282797
  Stats: 164 lines in 24 files changed: 46 ins; 7 del; 111 mod
  Patch: https://git.openjdk.org/jdk/pull/13753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13753/head:pull/13753

PR: https://git.openjdk.org/jdk/pull/13753

From bpb at openjdk.org  Tue May 23 16:03:43 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 May 2023 16:03:43 GMT
Subject: Integrated: 8308016: Use snippets in java.io package
In-Reply-To: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
References: <K7SveKb0eInTPU0z0rO07_JpTkThBEfBNOWBWji465w=.01b17999-665a-49eb-9c97-c738b2ebaff0@github.com>
Message-ID: <ybcD57nW2pl9rrY_JMES3uILD07v3JVCYuhBKQT4Ip0=.65ec3938-0742-462f-a12e-c79a0430a0d4@github.com>

On Fri, 12 May 2023 16:17:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replace `<pre>{@code ...}</pre>` patterns and the like with `{@snippet lang=java : ...}`.

This pull request has now been integrated.

Changeset: 710453c6
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/710453c676712d021bf856dc601d965e4e270805
Stats:     159 lines in 20 files changed: 27 ins; 7 del; 125 mod

8308016: Use snippets in java.io package

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/13957

From naoto at openjdk.org  Tue May 23 16:21:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 23 May 2023 16:21:13 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v2]
In-Reply-To: <r_qqI8I4_pGoPgxWMRB4iusdSYt4LL3oEr5SK8KohcI=.5f16a2fd-47d3-4587-8c4d-88bf480c1ad7@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
 <r_qqI8I4_pGoPgxWMRB4iusdSYt4LL3oEr5SK8KohcI=.5f16a2fd-47d3-4587-8c4d-88bf480c1ad7@github.com>
Message-ID: <5RK9fi9ix0bascOnml6sfEGvW2TrGRloVJ-ToEVly2I=.9630d5ad-0344-4127-b5bc-a82c05ba3b71@github.com>

On Tue, 23 May 2023 15:31:49 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
>> 
>> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).
>
> Michael McMahon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test comment update

Looks good

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14083#pullrequestreview-1440123393

From kvn at openjdk.org  Tue May 23 16:22:06 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Tue, 23 May 2023 16:22:06 GMT
Subject: RFR: JDK-8282797: CompileCommand parsing errors should exit VM
In-Reply-To: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
References: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
Message-ID: <fsU5V4ZjcXA0xGstyosSDzZ2Y7IRhGUQsyA3V3uW5sQ=.42d3857f-0c06-4fff-809e-e3357a3ad012@github.com>

On Tue, 2 May 2023 11:35:54 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

> Currently, errors during compile command parsing just print an error but don't exit the VM. As a result, issues go unnoticed. 
> 
> With this PR the behavior is changed to exit the VM when an error occurs.
> 
> E.g. `java -XX:CompileCommand=compileonly,HashMap:: -version` will exit the VM after a parsing occurred.  
> 
> CompileCommand: An error occurred during parsing
> Error: Could not parse method pattern
> Line: 'compileonly,HashMap::'
> 
> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
> Use:   '-XX:CompileCommand=help' for more information and to list all option.
> 
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> 
> ### Updated Tests
> Updated all tests to now expect an error code `1` for wrong `CompileCommand`

Looks good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13753#pullrequestreview-1440125001

From naoto at openjdk.org  Tue May 23 16:22:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 23 May 2023 16:22:52 GMT
Subject: RFR: 8159023: Engineering notation of DecimalFormat does not work
 as documented [v3]
In-Reply-To: <CAoRwOaYvLyvcwX__-iBVtN2BX6hw_smDC53OmKc5Ks=.668e2637-7a68-4aa7-a4c4-ca1a457999d1@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
 <CAoRwOaYvLyvcwX__-iBVtN2BX6hw_smDC53OmKc5Ks=.668e2637-7a68-4aa7-a4c4-ca1a457999d1@github.com>
Message-ID: <nk16hshcam19YEE4T_DpEXCDlWXXdA6ieTxvngeSkYY=.3c488e65-19a3-40a6-906c-9239b0f9587f@github.com>

On Tue, 23 May 2023 05:31:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the Scientific Notation section of Decimal Format. It aims to resolve [JDK-8159023](https://bugs.openjdk.org/browse/JDK-8159023) as well as [JDK-6282188](https://bugs.openjdk.org/browse/JDK-6282188).
>> 
>> **Scientific Notation** in Decimal Format contains the definition for a scientific notation formatted number's mantissa as such: _The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits. For example, 12345 formatted with "##0.##E0" is "12.3E3"._
>> 
>> Both the definition and example are incorrect, as the actual result is "12.E345". 
>> 
>> The following example data show that scientific notation formatted numbers do not adhere to that definition. As, according to the definition, the following numbers should have 3 significant digits, but in reality, they have up to 5.
>> 
>> 123 formatted by ##0.#E0 is 123E0
>> 1234 formatted by ##0.#E0 is 1.234E3
>> 12345 formatted by ##0.#E0 is 12.34E3
>> 123456 formatted by ##0.#E0 is 123.5E3
>> 1234567 formatted by ##0.#E0 is 1.235E6
>> 12345678 formatted by ##0.#E0 is 12.35E6
>> 123456789 formatted by ##0.#E0 is 123.5E6 
>> 
>> 
>> The actual definition of the mantissa, as well as examples and further context are included in this change. In addition, a test has been added that tests various patterns to numbers and ensures the format follows the new definition's mathematical expression.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: replace counting with isDigit, use all caps static final vars

Looks good

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14066#pullrequestreview-1440125960

From rrich at openjdk.org  Tue May 23 16:23:03 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 23 May 2023 16:23:03 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v35]
In-Reply-To: <bV_bQlasw-ST3EHQ_D-zinoVIe0bYAnBD8VQ-iba7_8=.58542ea8-2d07-4ecb-80ae-d0839ebc6446@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <cABEdgxmtvRq8ZYtkWQP27aGKP1GnkoLdTTERYPBSrE=.bcfbbd3c-2b68-4857-8962-5ab2976e8d27@github.com>
 <_UnPU5zMoXYMnjctnqw9hvTHbJXltv5w0wEJjRVod54=.0d591e6b-5ae4-4c45-88f4-41227d98c745@github.com>
 <S9Qn2AZTRiQDuB0CW-tP7MY-2xiUYl4njfg-PgO07vE=.3a30e96c-8149-4c5b-b0e5-882fc69c5fce@github.com>
 <bV_bQlasw-ST3EHQ_D-zinoVIe0bYAnBD8VQ-iba7_8=.58542ea8-2d07-4ecb-80ae-d0839ebc6446@github.com>
Message-ID: <PYWgDDazbKGXi5hm3r3mYs7aWAEeAicTtpplgGNW88Y=.68f4f7ff-69b0-4b0e-a302-99733b1ed7d9@github.com>

On Tue, 23 May 2023 12:26:52 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> I believe omitting the PSA is wrong for varargs, but we don't have this information in the backend.

It is clearly wrong.

> So, I think we should simply not optimize it.

Already agreed for this version.

> Reserving 64 Byte stack space should be affordable for a downcall even if it's not always needed.

It is hardly ever needed to begin with. It's just not pretty to allocate the PSA for little test functions. It'll confuse people that compare the downcall stub to what the C compiler produces. They might even think we havn't understood the ABI ;)

> The Java side could compute it, but there's no way to pass this information to the backend.

I'm not sure about that. First idea would be to keep the allocated `stack` in `nextStorage` if needed and pass it to the backend.

> I've improved the comments. Please take a look.

Great! Thanks :)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12708#discussion_r1202652115

From rrich at openjdk.org  Tue May 23 16:58:17 2023
From: rrich at openjdk.org (Richard Reingruber)
Date: Tue, 23 May 2023 16:58:17 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v36]
In-Reply-To: <KKNNiTG9blypCJS4z6JVaq1xltjRJI4a82E7jtwS998=.35ba5b42-3f77-4187-aac0-6b854b1f0681@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <KKNNiTG9blypCJS4z6JVaq1xltjRJI4a82E7jtwS998=.35ba5b42-3f77-4187-aac0-6b854b1f0681@github.com>
Message-ID: <ylq6g8C926blihtHYOL9AFmdw_z5Olh6NIqBXizrwBs=.0c0cd26e-93c7-450d-a774-2f9fe59d9be6@github.com>

On Tue, 23 May 2023 15:21:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separat...
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments about the Parameter Save Area.

This is really good to go now.
(maybe after a final round of tests)

Thanks a lot!
Richard.

-------------

Marked as reviewed by rrich (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12708#pullrequestreview-1440198377

From stuart.marks at oracle.com  Tue May 23 17:51:28 2023
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 23 May 2023 10:51:28 -0700
Subject: EnumSet doesn't implement SequencedSet
In-Reply-To: <CAE+3fjZagX91ME_cspP0a7i0b-Wr7PGnohZrxF1DUwNz3jq0zA@mail.gmail.com>
References: <CAF+DQ5f=BK3L+LQdHb1Wk7w9dws62YRJzhQFbn+_P0=ns14==A@mail.gmail.com>
 <CAE+3fjZagX91ME_cspP0a7i0b-Wr7PGnohZrxF1DUwNz3jq0zA@mail.gmail.com>
Message-ID: <5acfae4b-1dfa-a933-5b7c-f7f0ae8e0846@oracle.com>

The idea of EnumSet implementing SortedSet or NavigableSet has been around for a 
long time; see

https://bugs.openjdk.org/browse/JDK-6278287

But yes, EnumSet could also implement SequencedSet. Similarly, EnumMap could 
implement SequencedMap, SortedMap, or NavigableMap.

Implementing NavigableSet/Map is somewhat onerous, given that there's no 
AbstractNavigableSet/Map, and there are a lot of methods and variations of views to 
be implemented.

I'm a bit skeptical about the usefulness of retrofitting EnumSet/Map this way, 
though. My hunch is that EnumSet is usually treated as a bag of named booleans used 
as a set of boolean options. The EnumSet is passed around as an aggregate, with 
individual enum instances tested at specific points in the code to adjust the logic. 
It doesn't seem like the members of an EnumSet would be iterated frequently, or that 
it would be useful to have specific subsets of an EnumSet (which is what 
NavigableSet would provide). Maybe similar analysis applies to EnumMap.

I could be convinced otherwise with use cases, though.

s'marks


On 5/23/23 2:57 AM, Tagir Valeev wrote:
> Hello!
>
> Looks like this was overlooked. On the other hand, it could even implement 
> SortedSet or Navigable set, as it's essentially not just ordered but sorted, 
> according to the enum natural order. Same for EnumMap.
>
> With best regards,
> Tagir Valeev
>
> On Tue, May 23, 2023, 11:46 Andrey Turbanov <turbanoff at gmail.com> wrote:
>
>     Hello.
>     I've noticed that EnumSet unfortunately doesn't implement the newly
>     introduced interface SequencedSet.
>     From the first look it fits into it.
>     Is there a reason for that? Sorry if it was already discussed.
>
>     Andrey Turbanov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230523/c618a242/attachment-0001.htm>

From alanb at openjdk.org  Tue May 23 18:05:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 May 2023 18:05:21 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v16]
In-Reply-To: <saUbdY7RX8Tkj8Osbr77Tfd9plfNXEdia8eIzvoR3lU=.183779ae-56ff-4a93-9c8b-89cfe55cdebb@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <saUbdY7RX8Tkj8Osbr77Tfd9plfNXEdia8eIzvoR3lU=.183779ae-56ff-4a93-9c8b-89cfe55cdebb@github.com>
Message-ID: <pQmLR_25LVbNENqHu82_CZruKxvsw1hR1axtS1dLB24=.70af85a7-cb99-4704-9ad2-0ef7944ed777@github.com>

On Thu, 18 May 2023 19:06:28 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Give subclass priority

src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 129:

> 127:      * @throws NoSuchMethodException when not preview and no method found
> 128:      */
> 129:     public static Method findMainMethod(Class<?> mainClass) throws NoSuchMethodException {

The latest iteration of changes removes the warning but the latest iteration of the JEP proposes a warning when an instance main or static no-args main is preferred over an inherited static main. Is it that the JEP is just running ahead a bit and the changes in the PR will catch up soon?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1202796707

From jlaskey at openjdk.org  Tue May 23 18:12:09 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 23 May 2023 18:12:09 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v16]
In-Reply-To: <pQmLR_25LVbNENqHu82_CZruKxvsw1hR1axtS1dLB24=.70af85a7-cb99-4704-9ad2-0ef7944ed777@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <saUbdY7RX8Tkj8Osbr77Tfd9plfNXEdia8eIzvoR3lU=.183779ae-56ff-4a93-9c8b-89cfe55cdebb@github.com>
 <pQmLR_25LVbNENqHu82_CZruKxvsw1hR1axtS1dLB24=.70af85a7-cb99-4704-9ad2-0ef7944ed777@github.com>
Message-ID: <Hv1ITXYgGt-Wchfd4GXWuzmnbuIo4LMXL1Cb5mQCgQk=.72247468-b69e-4f47-b80e-9e1f937f0f93@github.com>

On Tue, 23 May 2023 18:02:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Give subclass priority
>
> src/java.base/share/classes/jdk/internal/misc/MainMethodFinder.java line 129:
> 
>> 127:      * @throws NoSuchMethodException when not preview and no method found
>> 128:      */
>> 129:     public static Method findMainMethod(Class<?> mainClass) throws NoSuchMethodException {
> 
> The latest iteration of changes removes the warning but the latest iteration of the JEP proposes a warning when an instance main or static no-args main is preferred over an inherited static main. Is it that the JEP is just running ahead a bit and the changes in the PR will catch up soon?

Yes. There is some juggling going on to get the code to align with the requirement and the interpretation thereof.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1202804732

From psandoz at openjdk.org  Tue May 23 18:26:57 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 23 May 2023 18:26:57 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
In-Reply-To: <K_3lHIPmRRc3VMIUS7O2dsIXMDsvUwPxOdVV91cgaL8=.00326c77-1bee-4193-99e5-ccf38a25fafb@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
 <aseaLvZ5OlPRUbqiUIvhVIak85RfTstljxSDVlnNYGg=.5fbed2d7-f6a2-49fc-a8e6-ca2c37d08097@github.com>
 <GKc6SPQM8wJ85aPX-cTCSAIYeDbxDpmRzK7AQaVYfQM=.5fa5e537-dd7f-4291-aa35-7ae39a56db8d@github.com>
 <K_3lHIPmRRc3VMIUS7O2dsIXMDsvUwPxOdVV91cgaL8=.00326c77-1bee-4193-99e5-ccf38a25fafb@github.com>
Message-ID: <idUNsqi1jZQuVInCzqNQrOZ1jZaQZg8sbZ7bii1BJY8=.a47c2eff-7756-4ed8-90b0-2ebdb217ba64@github.com>

On Tue, 23 May 2023 14:57:26 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> @theRealAph will want to comment on this as it is very performance sensitive. I think CallableAdapter.s is non-final to avoid the release fence.
>
> That's right. The problem is that we can never get rid of the release fence, apparently even when the instance of the adapter is scalar replaced. I imagine that'll get fixed one day, but this is internal JDK code.

Oh, and i guess that has some performance implications in some cases? more so on the set of instructions produced on ARM say rather than limiting C2 optimizations?

Given that the Supplier is likely to be the target of a lambda expression which may also capture I was surprised there would be much of an increased impact. (HotSpot may not strength reduce multiple fences in this case.)

Can we update to add say "/* non-final */ to the field and update the class doc to say the release fence inserted by HotSpot as a result of constructing a class with final fields has performance implications <<"insert loose quantification of those implications">> ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1202821873

From sergei.tsypanov at yandex.ru  Tue May 23 19:04:03 2023
From: sergei.tsypanov at yandex.ru (=?utf-8?B?0KHQtdGA0LPQtdC5INCm0YvQv9Cw0L3QvtCy?=)
Date: Tue, 23 May 2023 21:04:03 +0200
Subject: Classes used in method body are loaded lazily or eagerly
 depending on method return type
In-Reply-To: <f60f5ae9-348c-6fd4-bea8-8e8f4babf8e1@oracle.com>
References: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
 <f60f5ae9-348c-6fd4-bea8-8e8f4babf8e1@oracle.com>
Message-ID: <91431684868643@3vegvw7aj2jyj665.iva.yp-c.yandex.net>

Hi,

> Verification can require classes to be loaded to perform the
> verification - see JVMS 4.10 for all the details.

sorry, I still don't get it completely. Here's the byte code for ObjectReturner.getObject():

// access flags 0x1
public getObject()Ljava/lang/Object;
 L0
  LINENUMBER 43 L0
  NEW org/example/TestLoading$ChildClass
  DUP
  INVOKESPECIAL org/example/TestLoading$ChildClass.<init> ()V
  ARETURN
 L1
  LOCALVARIABLE this Lorg/example/TestLoading$ObjectReturner; L0 L1 0
  MAXSTACK = 2
  MAXLOCALS = 1

and this one is for BaseClassReturner.getObject():

// access flags 0x1
public getObject()Lorg/example/TestLoading$BaseClass;
 L0
  LINENUMBER 49 L0
  NEW org/example/TestLoading$ChildClass
  DUP
  INVOKESPECIAL org/example/TestLoading$ChildClass.<init> ()V
  ARETURN
 L1
  LOCALVARIABLE this Lorg/example/TestLoading$BaseClassReturner; L0 L1 0
  MAXSTACK = 2
  MAXLOCALS = 1

Apart from type of 'this' the only difference is return type, so I've referenced JVMS 4.10 in the part where return type is described.

There we have clause for areturn:

"An areturn instruction is type safe iff the enclosing method has a declared return type, ReturnType, that is a reference type, and one can validly pop a type matching ReturnType off the incoming operand stack."

and for return type:

"If the method returns a reference type, only an areturn instruction may be used, and the type of the returned value must be assignment compatible with the return descriptor of the method (?4.3.3)"

I guess the second one is a clue for to check whether returned value can be assigned to return type the VM should look into inheritance tree. Please correct me if idea is wrong.

Regards,
Sergey


> Hi,
> 
> On 23/05/2023 9:20 pm, ?????? ??????? wrote:
> 
>> Hello,
>>
>> originally this question was asked here: https://stackoverflow.com/q/76260269/12473843,
>> the code sample for reproduction will be put below or can be found via the link
>>
>> The issue is about eager/lazy loading of a class depending on method return type.
>> If one runs the code below with Java 11-19 it will fail with NoClassDefFoundError (this is expected as delete class file for ChildClass):
>>
>> java.lang.NoClassDefFoundError: org/example/TestLoading$ChildClass
>> at java.base/java.lang.Class.forName0(Native Method)
>> at java.base/java.lang.Class.forName(Class.java:390)
>> at java.base/java.lang.Class.forName(Class.java:381)
>> at org.example.TestLoading.loadMyClass(TestLoading.java:29)
>> at org.example.TestLoading.main(TestLoading.java:23)
>> Caused by: java.lang.ClassNotFoundException: org.example.TestLoading$ChildClass
>> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>> ... 5 more
>>
>> As of Java 20 chapter 12.4.1 of JLS states:
>> ---------------------------------------------------------
>> A class or interface T will be initialized immediately before the first occurrence of any one of the following:
>>
>> - T is a class and an instance of T is created.
>> - a static method declared by T is invoked.
>> - a static field declared by T is assigned.
>> - a static field declared by T is used and the field is not a constant variable (?4.12.4).
>>
>> When a class is initialized, its superclasses are initialized (if they have not been previously initialized), as well as any superinterfaces (?8.1.5) that declare any default methods (?9.4.3) (if they have not been previously initialized).
>> Initialization of an interface does not, of itself, cause initialization of any of its superinterfaces.
>> A reference to a static field (?8.3.1.1) causes initialization of only the class or interface that actually declares it, even though it might be referred to through the name of a subclass, a subinterface, or a class that implements an interface.
>> Invocation of certain reflective methods in class Class and in package java.lang.reflect also causes class or interface initialization.
>> A class or interface will not be initialized under any other circumstance.
>> ---------------------------------------------------------
>> With the code snippet we see that calling Class.forName(ObjectReturner.class.getName()) succeeds and Class.forName(BaseClassReturner.class.getName()) fails even though both declare returning an instance of ChildClass.
>> This failure is unexpected as in the code below we don't fulfill any requirement for class loading as of JLS 12.4.1, but the JVM still tries to load the class.
>>
>> I suspect it might be related to class file validation and/or security, because when we run the code with -Xlog:class+init there's a reference to LinkageError in loading log:
>>
>> loading: org.example.TestLoading$BaseClassReturner...
>> [0.277s][info][class,init] Start class verification for: org.example.TestLoading$BaseClassReturner
>> [0.277s][info][class,init] 771 Initializing 'java/lang/ReflectiveOperationException'(no method) (0x0000000800004028)
>> [0.277s][info][class,init] 772 Initializing 'java/lang/ClassNotFoundException'(no method) (0x0000000800004288)
>> [0.277s][info][class,init] 773 Initializing 'java/lang/LinkageError'(no method) (0x00000008000044f8) <----
>> [0.277s][info][class,init] 774 Initializing 'java/lang/NoClassDefFoundError'(no method) (0x0000000800004758)
>> [0.277s][info][class,init] Verification for org.example.TestLoading$BaseClassReturner has exception pending 'java.lang.NoClassDefFoundError org/example/TestLoading$ChildClass'
>> [0.277s][info][class,init] End class verification for: org.example.TestLoading$BaseClassReturner
>>
>> So I've got three questions about this:
>> - Does class loading depend on method's return type?
>> - Which part of JLS/JVM spec describes eager class loading in this case?
>> - Could one point out the particular piece of the VM code responsible for class loading in this case?
> 
> Verification can require classes to be loaded to perform the
> verification - see JVMS 4.10 for all the details.
> 
> Note you seem to be confusing class loading with class initialization
> above. The rules for initialization are very precise; the rules for
> loading are far more lax.
> 
> Cheers,
> David
> -----
> 
>> Regards,
>> Sergey Tsypanov
>>
>> Code snippet for reproduction:
>>
>> public class TestLoading {
>>
>> public static void main(String[] args) throws Exception {
>> Class.forName(BaseClass.class.getName());
>> URL classFileB = TestLoading.class.getResource(TestLoading.class.getSimpleName() + "$ChildClass.class");
>> if (classFileB != null) {
>> if (!"file".equals(classFileB.getProtocol())) {
>> throw new UnsupportedOperationException();
>> }
>> Path path = new File(classFileB.getPath()).toPath();
>> System.out.println("deleting: " + path);
>> Files.delete(path);
>> }
>>
>> loadMyClass(ObjectReturner.class.getName());
>> loadMyClass(BaseClassReturner.class.getName());
>> }
>>
>> private static void loadMyClass(String name) {
>> System.out.println("loading: " + name + "...");
>> try {
>> Class.forName(name);
>> } catch (Throwable e) {
>> e.printStackTrace(System.out);
>> }
>> }
>>
>> public static class BaseClass {
>> }
>>
>> public static class ChildClass extends BaseClass {
>> }
>>
>> public static class ObjectReturner {
>> public Object getObject() {
>> return new ChildClass();
>> }
>> }
>>
>> public static class BaseClassReturner {
>> public BaseClass getObject() {
>> return new ChildClass();
>> }
>> }
>> }

From aph at openjdk.org  Tue May 23 19:10:00 2023
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 23 May 2023 19:10:00 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
In-Reply-To: <idUNsqi1jZQuVInCzqNQrOZ1jZaQZg8sbZ7bii1BJY8=.a47c2eff-7756-4ed8-90b0-2ebdb217ba64@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
 <aseaLvZ5OlPRUbqiUIvhVIak85RfTstljxSDVlnNYGg=.5fbed2d7-f6a2-49fc-a8e6-ca2c37d08097@github.com>
 <GKc6SPQM8wJ85aPX-cTCSAIYeDbxDpmRzK7AQaVYfQM=.5fa5e537-dd7f-4291-aa35-7ae39a56db8d@github.com>
 <K_3lHIPmRRc3VMIUS7O2dsIXMDsvUwPxOdVV91cgaL8=.00326c77-1bee-4193-99e5-ccf38a25fafb@github.com>
 <idUNsqi1jZQuVInCzqNQrOZ1jZaQZg8sbZ7bii1BJY8=.a47c2eff-7756-4ed8-90b0-2ebdb217ba64@github.com>
Message-ID: <pNQ_6MhlUcuGbyI5_XroD2Rirkb00kqIZbKoZZadiU8=.8498e4c9-a498-4ad6-a8fd-f2bf44873259@github.com>

On Tue, 23 May 2023 18:23:21 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Oh, and i guess that has some performance implications in some cases? more so on the set of instructions produced on ARM say rather than limiting C2 optimizations?

I think so. As far as I can remember, a release fence on x86 generates no code at all.

> Given that the Supplier is likely to be the target of a lambda expression which may also capture I was surprised there would be much of an increased impact. (HotSpot may not strength reduce multiple fences in this case.)

It may, or it may not. I don't really want the call without a checked exception to be more costly than a call with one. That seems a little weird, at least.

> Can we update to add say "/* non-final */ to the field and update the class doc to say the release fence inserted by HotSpot as a result of constructing a class with final fields has performance implications <<"insert loose quantification of those implications">> ?

Sure, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1202870649

From mchung at openjdk.org  Tue May 23 19:20:53 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 23 May 2023 19:20:53 GMT
Subject: RFR: 8308549: Classfile API should fail to generate over-sized
 Code attribute
In-Reply-To: <FMfhhGe4XrEG4Brj1GZS69ovfeNMSAEeLwlMq05SzwA=.7014deec-41a2-44cc-b4bd-51f3f71f291b@github.com>
References: <FMfhhGe4XrEG4Brj1GZS69ovfeNMSAEeLwlMq05SzwA=.7014deec-41a2-44cc-b4bd-51f3f71f291b@github.com>
Message-ID: <u0M3gV5oZpSBYvhAiQCcpAoUZfZqZ47TqXcVcLokJV8=.c137b109-772c-43f3-980c-77a94d552f39@github.com>

On Tue, 23 May 2023 12:54:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile API allowed to generate Code attribute exceeding the 65k limit. No exception has been thrown during class generation and the class failed verification later during class loading.
> This patch adds Code size limit check throwing IllegalArgumentException.
> The patch also adds similar check for constant pool size limit to avoid generation class file with corrupted  constant pool.
> Two new tests are added to check response on oversized Code attribute and constant pool.
> `VerifierImpl` is extended to check Code attribute size as a part of class verification process.
> 
> Please review.
> 
> Thanks,
> Adam

This looks ok to me.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14100#pullrequestreview-1440411354

From liach at openjdk.org  Tue May 23 19:45:56 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 May 2023 19:45:56 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of [v2]
In-Reply-To: <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
 <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
Message-ID: <wZlsoVpbEOjllfB6ujDH3Gr0NWnZE0u7LU7Ylwj6FcI=.2184f330-eb44-44b9-8a37-1b04179e6bb5@github.com>

On Sun, 23 Apr 2023 23:44:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch adding two new convenience methods that allows easier access to MethodTypeDesc instances and its associated CSR as well. This is a necessity to allow #13186 to reduce array copies in a few scenarios; the implementation of the two methods will be updated there.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306698/1/java.base/java/lang/constant/MethodTypeDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update method type and specification, update tests

@mlchung Since you appear to be back, can you review this patch that allows future immutable-list  parameter type sharing and benefit the Classfile API for JDK 21? I would be grateful if you can review a few other java.lang.invoke improvements I submitted as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13599#issuecomment-1560027705

From psandoz at openjdk.org  Tue May 23 19:47:01 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 23 May 2023 19:47:01 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v4]
In-Reply-To: <mNvyH9yRqp0OZJdx10SwbRBgyqTq_QdXGB-qHeTQ8B8=.c3bc2710-e51a-4855-a18e-0e3cbee33281@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <mNvyH9yRqp0OZJdx10SwbRBgyqTq_QdXGB-qHeTQ8B8=.c3bc2710-e51a-4855-a18e-0e3cbee33281@github.com>
Message-ID: <uBXHsBcQq_tqWe0oma53QzpwI19z5Ohtl_IGDOr1ORI=.47363c8c-50ad-42d9-bf2e-a0c81e036ffa@github.com>

On Mon, 22 May 2023 09:34:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address further review comments

On further reflection i think mapping C `unsigned short` only to Java `char` is a misleading. Although Java `char` is an integral type is not really intended to be used generally as an unsigned 16-bit integer, so arguably Java `char` is not as useful a carrier type for native interoperation as Java `short` might be even though it is signed.
Thus i am inclined to remove that mapping.

What if we say something to the effect of:

> unless explicitly declared in the canonical layouts C's unsigned integral types are mapped to the layouts associated with the required C's signed integral types of the same bit sizes.

?

Arguably C `unsigned short` could map to carriers Java `short` or Java `char`, but i am inclined to say the user should cast between Java `short` to `char` in such cases.

FWIW i checked what the FFM API and jextract does today and it maps unsigned C types to signed Java types.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1560028359

From talden at gmail.com  Tue May 23 19:51:31 2023
From: talden at gmail.com (Aaron Scott-Boddendijk)
Date: Wed, 24 May 2023 07:51:31 +1200
Subject: EnumSet doesn't implement SequencedSet
In-Reply-To: <5acfae4b-1dfa-a933-5b7c-f7f0ae8e0846@oracle.com>
References: <CAF+DQ5f=BK3L+LQdHb1Wk7w9dws62YRJzhQFbn+_P0=ns14==A@mail.gmail.com>
 <CAE+3fjZagX91ME_cspP0a7i0b-Wr7PGnohZrxF1DUwNz3jq0zA@mail.gmail.com>
 <5acfae4b-1dfa-a933-5b7c-f7f0ae8e0846@oracle.com>
Message-ID: <CAE=ECuSQcE_83QCP04p790KmP=mYVX0ohiY1v9XMDZ3u2iTwtQ@mail.gmail.com>

> It doesn't seem like the members of an EnumSet would be iterated
frequently...

We use EnumSet and EnumMap extensively, frequently iterating over them (the
enum's natural order being critical).

> ...usually treated as a bag of named booleans used as a set of boolean
options.

So for us it's... "ordered bag of named booleans with cheap lookup".

But I agree our usage probably wouldn't benefit from sequenced/navigable
functionality much (if at all).

--
Aaron Scott-Boddendijk

On Wed, May 24, 2023 at 5:51?AM Stuart Marks <stuart.marks at oracle.com>
wrote:

> The idea of EnumSet implementing SortedSet or NavigableSet has been around
> for a long time; see
>
>     https://bugs.openjdk.org/browse/JDK-6278287
>
> But yes, EnumSet could also implement SequencedSet. Similarly, EnumMap
> could implement SequencedMap, SortedMap, or NavigableMap.
>
> Implementing NavigableSet/Map is somewhat onerous, given that there's no
> AbstractNavigableSet/Map, and there are a lot of methods and variations of
> views to be implemented.
>
> I'm a bit skeptical about the usefulness of retrofitting EnumSet/Map this
> way, though. My hunch is that EnumSet is usually treated as a bag of named
> booleans used as a set of boolean options. The EnumSet is passed around as
> an aggregate, with individual enum instances tested at specific points in
> the code to adjust the logic. It doesn't seem like the members of an
> EnumSet would be iterated frequently, or that it would be useful to have
> specific subsets of an EnumSet (which is what NavigableSet would provide).
> Maybe similar analysis applies to EnumMap.
>
> I could be convinced otherwise with use cases, though.
>
> s'marks
>
>
> On 5/23/23 2:57 AM, Tagir Valeev wrote:
>
> Hello!
>
> Looks like this was overlooked. On the other hand, it could even implement
> SortedSet or Navigable set, as it's essentially not just ordered but
> sorted, according to the enum natural order. Same for EnumMap.
>
> With best regards,
> Tagir Valeev
>
> On Tue, May 23, 2023, 11:46 Andrey Turbanov <turbanoff at gmail.com> wrote:
>
>> Hello.
>> I've noticed that EnumSet unfortunately doesn't implement the newly
>> introduced interface SequencedSet.
>> From the first look it fits into it.
>> Is there a reason for that? Sorry if it was already discussed.
>>
>> Andrey Turbanov
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230524/dae83686/attachment.htm>

From jlaskey at openjdk.org  Tue May 23 20:04:45 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 23 May 2023 20:04:45 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v17]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <tnsWpX02tby0A4lKZyk4PDOitc8UoiLqoYqGTfwRRrQ=.cfc01697-83ef-4ba3-9441-4766403d4c03@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - Fix missing constructor error messages and handle inner class launching
 - Merge branch 'master' into 8306112
 - Issue warning if traditional main not used.
 - Give subclass priority
 - Merge branch 'master' into 8306112
 - Requested Changes #2
 - Update VirtualParser.java
 - Merge branch 'master' into 8306112
 - Refactor source code launcher
 - Typo
 - ... and 23 more: https://git.openjdk.org/jdk/compare/bddf4838...b55f82f8

-------------

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=16
  Stats: 1235 lines in 28 files changed: 1071 ins; 32 del; 132 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From mchung at openjdk.org  Tue May 23 20:05:58 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 23 May 2023 20:05:58 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of [v2]
In-Reply-To: <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
 <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
Message-ID: <UsE2cqLt4sNxAYxfB8ViADLt7jR4goXCu5p7QWX6G_I=.540bb884-35e4-46da-8cc6-701284f8051b@github.com>

On Sun, 23 Apr 2023 23:44:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch adding two new convenience methods that allows easier access to MethodTypeDesc instances and its associated CSR as well. This is a necessity to allow #13186 to reduce array copies in a few scenarios; the implementation of the two methods will be updated there.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306698/1/java.base/java/lang/constant/MethodTypeDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update method type and specification, update tests

yes, I'm back from vacation.

This change looks fine.  Can you update the copyright header to 2023?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13599#issuecomment-1560051087

From mchung at openjdk.org  Tue May 23 20:08:55 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 23 May 2023 20:08:55 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of [v2]
In-Reply-To: <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
 <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
Message-ID: <NJ3DLiyBDRvErM-WgB5U361yE_HZC90wynPf2LQgMFk=.6ea1090b-1dae-47d7-b0ec-6b63aec26bac@github.com>

On Sun, 23 Apr 2023 23:44:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch adding two new convenience methods that allows easier access to MethodTypeDesc instances and its associated CSR as well. This is a necessity to allow #13186 to reduce array copies in a few scenarios; the implementation of the two methods will be updated there.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306698/1/java.base/java/lang/constant/MethodTypeDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update method type and specification, update tests

What is the plan for https://git.openjdk.org/jdk/pull/13186?   It seems that keeping `argTypes` in an array is okay.   In any case, we can do the discussion in PR 13186 after this one is integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13599#issuecomment-1560053685

From mdoerr at openjdk.org  Tue May 23 20:22:10 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 23 May 2023 20:22:10 GMT
Subject: RFR: 8303040: linux PPC64le: Implementation of Foreign Function &
 Memory API (Preview) [v36]
In-Reply-To: <KKNNiTG9blypCJS4z6JVaq1xltjRJI4a82E7jtwS998=.35ba5b42-3f77-4187-aac0-6b854b1f0681@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
 <KKNNiTG9blypCJS4z6JVaq1xltjRJI4a82E7jtwS998=.35ba5b42-3f77-4187-aac0-6b854b1f0681@github.com>
Message-ID: <xfYL7QlBMF0jNdkiEAjWvtRKhuaXiN6Zrp8sJFWLIkU=.489d041b-55c5-48fa-ae78-1ca28eec70d3@github.com>

On Tue, 23 May 2023 15:21:02 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
>> 
>> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
>> 
>> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
>> 
>> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
>> 
>> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
>> 
>> I had to make changes to shared code and code for other platforms:
>> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
>> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
>> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
>> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
>> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separat...
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve comments about the Parameter Save Area.

Thanks a lot for all discussions, feedback and the reviews! This was really helpful! I'm planning to integrate tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12708#issuecomment-1560069523

From liach at openjdk.org  Tue May 23 20:32:58 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 May 2023 20:32:58 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of [v2]
In-Reply-To: <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
 <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
Message-ID: <LjQ3jyPnarDVhN1sgSyeE8lFQniNqLe7mmL7oXyIzKU=.b8d95179-3343-44a3-9be6-d5e08e0ea234@github.com>

On Sun, 23 Apr 2023 23:44:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch adding two new convenience methods that allows easier access to MethodTypeDesc instances and its associated CSR as well. This is a necessity to allow #13186 to reduce array copies in a few scenarios; the implementation of the two methods will be updated there.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306698/1/java.base/java/lang/constant/MethodTypeDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update method type and specification, update tests

I plan to keep it. Migration to an immutable list to optimize `parameterList` while it doesn't affect the performance of other accessors. Meanwhile, the list passed by the user code to the factory can be shared safely if it's immutable, while we shouldn't trust the vararg array to the factory.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13599#issuecomment-1560082635

From liach at openjdk.org  Tue May 23 20:32:59 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 May 2023 20:32:59 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of [v2]
In-Reply-To: <UsE2cqLt4sNxAYxfB8ViADLt7jR4goXCu5p7QWX6G_I=.540bb884-35e4-46da-8cc6-701284f8051b@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
 <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
 <UsE2cqLt4sNxAYxfB8ViADLt7jR4goXCu5p7QWX6G_I=.540bb884-35e4-46da-8cc6-701284f8051b@github.com>
Message-ID: <KYm7uEvXSYqk4k6UyCdyfx0ZFltnsNrkn8mwANcWuO8=.1bb5c64e-a94e-47d5-b646-1f2b52f692ad@github.com>

On Tue, 23 May 2023 20:03:35 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> yes, I'm back from vacation.
> 
> This change looks fine. Can you update the copyright header to 2023?

The copyright year was already updated to 2023 when covariant override for `resolveConstantDesc` was added.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13599#issuecomment-1560084308

From mcimadamore at openjdk.org  Tue May 23 20:35:00 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 23 May 2023 20:35:00 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v4]
In-Reply-To: <mNvyH9yRqp0OZJdx10SwbRBgyqTq_QdXGB-qHeTQ8B8=.c3bc2710-e51a-4855-a18e-0e3cbee33281@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <mNvyH9yRqp0OZJdx10SwbRBgyqTq_QdXGB-qHeTQ8B8=.c3bc2710-e51a-4855-a18e-0e3cbee33281@github.com>
Message-ID: <JKdzvoFRLTLg3GIZSCWmfvXXE6TKuB4L-9PWTV3MuKw=.1f76e514-a9d7-4b6c-9843-d9ff4d6cdcd7@github.com>

On Mon, 22 May 2023 09:34:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address further review comments

> On further reflection i think mapping C `unsigned short` only to Java `char` is a misleading. Although Java `char` is an integral type is not really intended to be used generally as an unsigned 16-bit integer, so arguably Java `char` is not as useful a carrier type for native interoperation as Java `short` might be even though it is signed. Thus i am inclined to remove that mapping.
> 
> What if we say something to the effect of:
> 
> > unless explicitly declared in the canonical layouts C's unsigned integral types are mapped to the layouts associated with the required C's signed integral types of the same bit sizes.
> 
> ?
> 
> Arguably C `unsigned short` could map to carriers Java `short` or Java `char`, but i am inclined to say the user should cast between Java `short` to `char` in such cases.
> 
> FWIW i checked what the FFM API and jextract does today and it maps unsigned C types to signed Java types.



> On further reflection i think mapping C `unsigned short` only to Java `char` is a misleading. Although Java `char` is an integral type is not really intended to be used generally as an unsigned 16-bit integer, so arguably Java `char` is not as useful a carrier type for native interoperation as Java `short` might be even though it is signed. Thus i am inclined to remove that mapping.
> 
> What if we say something to the effect of:
> 
> > unless explicitly declared in the canonical layouts C's unsigned integral types are mapped to the layouts associated with the required C's signed integral types of the same bit sizes.
> 
> ?
> 
> Arguably C `unsigned short` could map to carriers Java `short` or Java `char`, but i am inclined to say the user should cast between Java `short` to `char` in such cases.
> 
> FWIW i checked what the FFM API and jextract does today and it maps unsigned C types to signed Java types.

I tend to agree with your conclusion. And I confirm that we do not use "char" anywhere in jextract. The only "problem" with that approach is that if we go down that path, JAVA_CHAR is no longer a canonical type, so users cannot mention it in function descriptors. Apart from requiring few test updates, I don't see many other problems with it - if one really really wanted the result of a native call to be converted to `char`, a MH adapter can be used. Effectively, what you suggest amount at saying: we do have a JAVA_CHAR layout, which is mostly there for Java interop. But a native linker (which only cares about native interop) doesn't really care much about that. Does that sound good?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1560086050

From darcy at openjdk.org  Tue May 23 20:36:11 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 May 2023 20:36:11 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22
Message-ID: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>

Time to get JDK 22 underway...

-------------

Commit messages:
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Minor test fixes.
 - Merge branch 'master' into JDK-8306584
 - Update symbol files to JDK 21 b23.
 - Merge branch 'JDK-8306584' of https://github.com/jddarcy/jdk into JDK-8306584
 - Add symbol files.
 - Merge branch 'master' into JDK-8306584
 - Problem list failing langtools test.
 - Merge branch 'master' into JDK-8306584
 - ... and 9 more: https://git.openjdk.org/jdk/compare/8474e693...6047c2cb

Changes: https://git.openjdk.org/jdk/pull/13567/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306584
  Stats: 5650 lines in 69 files changed: 5596 ins; 0 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/13567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567

PR: https://git.openjdk.org/jdk/pull/13567

From darcy at openjdk.org  Tue May 23 20:36:12 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 May 2023 20:36:12 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <KdtVAlWGgFXRl1nlFdZ2DCSH47sji2MXXA1Y8EwsWe4=.ebf0678c-3174-4524-9522-308b8bee0957@github.com>

On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to get JDK 22 underway...

Typical start-of-JDK-next changes. As usual, the bulk of the PR is the symbol file information to support "javac --release 21".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13567#issuecomment-1560085911

From jjg at openjdk.org  Tue May 23 20:42:00 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 23 May 2023 20:42:00 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <aOP4D56C1ZNMV0EF3tQVI1R_zCJmlbmMkoS_ZeTHgiI=.dd4fe3e6-849f-49c0-91da-6990e84a5c1f@github.com>

On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to get JDK 22 underway...

test/langtools/tools/javac/versions/Versions.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 4981566 5028634 5094412 6304984 7025786 7025789 8001112 8028545 8000961 8030610 8028546 8188870 8173382 8173382 8193290 8205619 8028563 8245147 8245586 8257453 8286035 8306586

At some point, this line should be wrapped

test/langtools/tools/javac/versions/Versions.java line 93:

> 91:         TWENTY(false,    "64.0", "20", Versions::checksrc20),
> 92:         TWENTY_ONE(false,"65.0", "21", Versions::checksrc20),
> 93:         TWENTY_TWO(false,"66.0", "22", Versions::checksrc20);

when do these get updated?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1202974585
PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1202976605

From erikj at openjdk.org  Tue May 23 20:41:58 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 23 May 2023 20:41:58 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <Mp05bI_h03-YkavqrCuntjcrKjElMipkJFB4_FM08G4=.a8f4bff8-4ebb-4af1-b693-5e1777d77de1@github.com>

On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to get JDK 22 underway...

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1440532444

From mchung at openjdk.org  Tue May 23 20:48:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 23 May 2023 20:48:57 GMT
Subject: RFR: 8306698: Add overloads to MethodTypeDesc::of [v2]
In-Reply-To: <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
 <IVH7Q2FelKBXq6z6oStvuj5xuusfjFJbuJMBMDoCABg=.97ee90bc-5c0f-45bb-804b-a62adfa19573@github.com>
Message-ID: <XWvWP6_SzU489tGcCi8vIrsCsTAYPanSbTl7MhTDmqQ=.7f429ca1-ad6b-4c35-b166-113e55725520@github.com>

On Sun, 23 Apr 2023 23:44:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch adding two new convenience methods that allows easier access to MethodTypeDesc instances and its associated CSR as well. This is a necessity to allow #13186 to reduce array copies in a few scenarios; the implementation of the two methods will be updated there.
>> 
>> Javadoc: https://cr.openjdk.org/~liach/8306698/1/java.base/java/lang/constant/MethodTypeDesc.html
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update method type and specification, update tests

Marked as reviewed by mchung (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13599#pullrequestreview-1440542755

From darcy at openjdk.org  Tue May 23 20:52:57 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 May 2023 20:52:57 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22
In-Reply-To: <aOP4D56C1ZNMV0EF3tQVI1R_zCJmlbmMkoS_ZeTHgiI=.dd4fe3e6-849f-49c0-91da-6990e84a5c1f@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <aOP4D56C1ZNMV0EF3tQVI1R_zCJmlbmMkoS_ZeTHgiI=.dd4fe3e6-849f-49c0-91da-6990e84a5c1f@github.com>
Message-ID: <RBMae1be7T6K2yEPsyGb3EesrzePOGDXQ_DndVutjtw=.3fc47616-9350-4d62-bf9d-6c7113937505@github.com>

On Tue, 23 May 2023 20:38:34 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Time to get JDK 22 underway...
>
> test/langtools/tools/javac/versions/Versions.java line 93:
> 
>> 91:         TWENTY(false,    "64.0", "20", Versions::checksrc20),
>> 92:         TWENTY_ONE(false,"65.0", "21", Versions::checksrc20),
>> 93:         TWENTY_TWO(false,"66.0", "22", Versions::checksrc20);
> 
> when do these get updated?

Ah, when new non-preview language structures are added. With two new language features in JDK 21, looks like it is time for me to add another one; thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1202991806

From mcimadamore at openjdk.org  Tue May 23 21:03:56 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 23 May 2023 21:03:56 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v4]
In-Reply-To: <JKdzvoFRLTLg3GIZSCWmfvXXE6TKuB4L-9PWTV3MuKw=.1f76e514-a9d7-4b6c-9843-d9ff4d6cdcd7@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <mNvyH9yRqp0OZJdx10SwbRBgyqTq_QdXGB-qHeTQ8B8=.c3bc2710-e51a-4855-a18e-0e3cbee33281@github.com>
 <JKdzvoFRLTLg3GIZSCWmfvXXE6TKuB4L-9PWTV3MuKw=.1f76e514-a9d7-4b6c-9843-d9ff4d6cdcd7@github.com>
Message-ID: <DR4XBsWlqQU2HCz3SNZkSwPqTF-gU5bp4uyGUMnbB4g=.6b3df23c-84ff-44ce-9550-68d843b92e62@github.com>

On Tue, 23 May 2023 20:32:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Arguably C `unsigned short` could map to carriers Java `short` or Java `char`, but i am inclined to say the user should cast between Java `short` to `char` in such cases.

(Another advantage of this is that, should we get proper unsigned carriers from Valhalla one day, native linkers could be updated to support those en masse - not just for `short`)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1560118602

From iris at openjdk.org  Tue May 23 21:20:57 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 23 May 2023 21:20:57 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <Exzu8vMVI6iI5zUy2UC5QChQ-xBwLqp1OZSA4qeQcNA=.dd4263a5-5841-416b-8aac-2adf65f77956@github.com>

On Thu, 20 Apr 2023 20:28:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Time to get JDK 22 underway...

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1440582657

From liach at openjdk.org  Tue May 23 21:30:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 23 May 2023 21:30:04 GMT
Subject: Integrated: 8306698: Add overloads to MethodTypeDesc::of
In-Reply-To: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
References: <omg4bzcQrDPiwoFTjWPWlNO3_l7rU9nqwWcXKpIWNeo=.80958132-6c2d-4482-aac8-a2f70166efbb@github.com>
Message-ID: <wLHnUa3pfuuDid36aBO19RK-K2_qyQkmfmwAA0KZ3eA=.d4fb845e-6138-4dc2-bb73-e76fe01a3bf2@github.com>

On Sat, 22 Apr 2023 16:31:31 GMT, Chen Liang <liach at openjdk.org> wrote:

> Please review this patch adding two new convenience methods that allows easier access to MethodTypeDesc instances and its associated CSR as well. This is a necessity to allow #13186 to reduce array copies in a few scenarios; the implementation of the two methods will be updated there.
> 
> Javadoc: https://cr.openjdk.org/~liach/8306698/1/java.base/java/lang/constant/MethodTypeDesc.html

This pull request has now been integrated.

Changeset: 8ffa264c
Author:    Chen Liang <liach at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8ffa264cf009ddb1af486831f12bc70f93d74cf5
Stats:     83 lines in 3 files changed: 45 ins; 30 del; 8 mod

8306698: Add overloads to MethodTypeDesc::of

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/13599

From david.holmes at oracle.com  Tue May 23 22:06:35 2023
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 24 May 2023 08:06:35 +1000
Subject: Classes used in method body are loaded lazily or eagerly
 depending on method return type
In-Reply-To: <91431684868643@3vegvw7aj2jyj665.iva.yp-c.yandex.net>
References: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
 <f60f5ae9-348c-6fd4-bea8-8e8f4babf8e1@oracle.com>
 <91431684868643@3vegvw7aj2jyj665.iva.yp-c.yandex.net>
Message-ID: <ef2119d9-1de6-9cd1-3ee5-36c140bf7ed5@oracle.com>

On 24/05/2023 5:04 am, ?????? ??????? wrote:
> Hi,
> 
>> Verification can require classes to be loaded to perform the
>> verification - see JVMS 4.10 for all the details.
> 
> sorry, I still don't get it completely. Here's the byte code for ObjectReturner.getObject():
> 
> // access flags 0x1
> public getObject()Ljava/lang/Object;
>   L0
>    LINENUMBER 43 L0
>    NEW org/example/TestLoading$ChildClass
>    DUP
>    INVOKESPECIAL org/example/TestLoading$ChildClass.<init> ()V
>    ARETURN
>   L1
>    LOCALVARIABLE this Lorg/example/TestLoading$ObjectReturner; L0 L1 0
>    MAXSTACK = 2
>    MAXLOCALS = 1
> 
> and this one is for BaseClassReturner.getObject():
> 
> // access flags 0x1
> public getObject()Lorg/example/TestLoading$BaseClass;
>   L0
>    LINENUMBER 49 L0
>    NEW org/example/TestLoading$ChildClass
>    DUP
>    INVOKESPECIAL org/example/TestLoading$ChildClass.<init> ()V
>    ARETURN
>   L1
>    LOCALVARIABLE this Lorg/example/TestLoading$BaseClassReturner; L0 L1 0
>    MAXSTACK = 2
>    MAXLOCALS = 1
> 
> Apart from type of 'this' the only difference is return type, so I've referenced JVMS 4.10 in the part where return type is described.
> 
> There we have clause for areturn:
> 
> "An areturn instruction is type safe iff the enclosing method has a declared return type, ReturnType, that is a reference type, and one can validly pop a type matching ReturnType off the incoming operand stack."
> 
> and for return type:
> 
> "If the method returns a reference type, only an areturn instruction may be used, and the type of the returned value must be assignment compatible with the return descriptor of the method (?4.3.3)"
> 
> I guess the second one is a clue for to check whether returned value can be assigned to return type the VM should look into inheritance tree. Please correct me if idea is wrong.

For the Object case the type-checking is always obviously trivially 
correct so it doesn't need to load the actual return type. So the seems 
a reasonable conclusion.

If you take your test code and only have the BaseClassReturner and only 
load it then you see in the logging:

loading: TestLoading$BaseClassReturner...
[0.067s][info][class,init              ] Start class verification for: 
TestLoading$BaseClassReturner
[0.067s][info][verification            ] Verifying class 
TestLoading$BaseClassReturner with new format
[0.067s][info][verification            ] Verifying method 
TestLoading$BaseClassReturner.<init>()V
[0.067s][info][verification            ] Verifying method 
TestLoading$BaseClassReturner.getObject()LTestLoading$BaseClass;
[0.068s][info][class,load              ] TestLoading$BaseClass source: 
file:/scratch/users/daholme/tests/
[0.068s][info][class,load              ] TestLoading$ChildClass source: 
file:/scratch/users/daholme/tests/
[0.068s][info][class,init              ] End class verification for: 
TestLoading$BaseClassReturner
[0.068s][info][verification            ] End class verification for: 
TestLoading$BaseClassReturner

So you can see the ChildClass being loaded.

David
-----



> Regards,
> Sergey
> 
> 
>> Hi,
>>
>> On 23/05/2023 9:20 pm, ?????? ??????? wrote:
>>
>>> Hello,
>>>
>>> originally this question was asked here: https://stackoverflow.com/q/76260269/12473843,
>>> the code sample for reproduction will be put below or can be found via the link
>>>
>>> The issue is about eager/lazy loading of a class depending on method return type.
>>> If one runs the code below with Java 11-19 it will fail with NoClassDefFoundError (this is expected as delete class file for ChildClass):
>>>
>>> java.lang.NoClassDefFoundError: org/example/TestLoading$ChildClass
>>> at java.base/java.lang.Class.forName0(Native Method)
>>> at java.base/java.lang.Class.forName(Class.java:390)
>>> at java.base/java.lang.Class.forName(Class.java:381)
>>> at org.example.TestLoading.loadMyClass(TestLoading.java:29)
>>> at org.example.TestLoading.main(TestLoading.java:23)
>>> Caused by: java.lang.ClassNotFoundException: org.example.TestLoading$ChildClass
>>> at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>>> at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>>> ... 5 more
>>>
>>> As of Java 20 chapter 12.4.1 of JLS states:
>>> ---------------------------------------------------------
>>> A class or interface T will be initialized immediately before the first occurrence of any one of the following:
>>>
>>> - T is a class and an instance of T is created.
>>> - a static method declared by T is invoked.
>>> - a static field declared by T is assigned.
>>> - a static field declared by T is used and the field is not a constant variable (?4.12.4).
>>>
>>> When a class is initialized, its superclasses are initialized (if they have not been previously initialized), as well as any superinterfaces (?8.1.5) that declare any default methods (?9.4.3) (if they have not been previously initialized).
>>> Initialization of an interface does not, of itself, cause initialization of any of its superinterfaces.
>>> A reference to a static field (?8.3.1.1) causes initialization of only the class or interface that actually declares it, even though it might be referred to through the name of a subclass, a subinterface, or a class that implements an interface.
>>> Invocation of certain reflective methods in class Class and in package java.lang.reflect also causes class or interface initialization.
>>> A class or interface will not be initialized under any other circumstance.
>>> ---------------------------------------------------------
>>> With the code snippet we see that calling Class.forName(ObjectReturner.class.getName()) succeeds and Class.forName(BaseClassReturner.class.getName()) fails even though both declare returning an instance of ChildClass.
>>> This failure is unexpected as in the code below we don't fulfill any requirement for class loading as of JLS 12.4.1, but the JVM still tries to load the class.
>>>
>>> I suspect it might be related to class file validation and/or security, because when we run the code with -Xlog:class+init there's a reference to LinkageError in loading log:
>>>
>>> loading: org.example.TestLoading$BaseClassReturner...
>>> [0.277s][info][class,init] Start class verification for: org.example.TestLoading$BaseClassReturner
>>> [0.277s][info][class,init] 771 Initializing 'java/lang/ReflectiveOperationException'(no method) (0x0000000800004028)
>>> [0.277s][info][class,init] 772 Initializing 'java/lang/ClassNotFoundException'(no method) (0x0000000800004288)
>>> [0.277s][info][class,init] 773 Initializing 'java/lang/LinkageError'(no method) (0x00000008000044f8) <----
>>> [0.277s][info][class,init] 774 Initializing 'java/lang/NoClassDefFoundError'(no method) (0x0000000800004758)
>>> [0.277s][info][class,init] Verification for org.example.TestLoading$BaseClassReturner has exception pending 'java.lang.NoClassDefFoundError org/example/TestLoading$ChildClass'
>>> [0.277s][info][class,init] End class verification for: org.example.TestLoading$BaseClassReturner
>>>
>>> So I've got three questions about this:
>>> - Does class loading depend on method's return type?
>>> - Which part of JLS/JVM spec describes eager class loading in this case?
>>> - Could one point out the particular piece of the VM code responsible for class loading in this case?
>>
>> Verification can require classes to be loaded to perform the
>> verification - see JVMS 4.10 for all the details.
>>
>> Note you seem to be confusing class loading with class initialization
>> above. The rules for initialization are very precise; the rules for
>> loading are far more lax.
>>
>> Cheers,
>> David
>> -----
>>
>>> Regards,
>>> Sergey Tsypanov
>>>
>>> Code snippet for reproduction:
>>>
>>> public class TestLoading {
>>>
>>> public static void main(String[] args) throws Exception {
>>> Class.forName(BaseClass.class.getName());
>>> URL classFileB = TestLoading.class.getResource(TestLoading.class.getSimpleName() + "$ChildClass.class");
>>> if (classFileB != null) {
>>> if (!"file".equals(classFileB.getProtocol())) {
>>> throw new UnsupportedOperationException();
>>> }
>>> Path path = new File(classFileB.getPath()).toPath();
>>> System.out.println("deleting: " + path);
>>> Files.delete(path);
>>> }
>>>
>>> loadMyClass(ObjectReturner.class.getName());
>>> loadMyClass(BaseClassReturner.class.getName());
>>> }
>>>
>>> private static void loadMyClass(String name) {
>>> System.out.println("loading: " + name + "...");
>>> try {
>>> Class.forName(name);
>>> } catch (Throwable e) {
>>> e.printStackTrace(System.out);
>>> }
>>> }
>>>
>>> public static class BaseClass {
>>> }
>>>
>>> public static class ChildClass extends BaseClass {
>>> }
>>>
>>> public static class ObjectReturner {
>>> public Object getObject() {
>>> return new ChildClass();
>>> }
>>> }
>>>
>>> public static class BaseClassReturner {
>>> public BaseClass getObject() {
>>> return new ChildClass();
>>> }
>>> }
>>> }

From david.holmes at oracle.com  Tue May 23 22:23:24 2023
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 24 May 2023 08:23:24 +1000
Subject: Classes used in method body are loaded lazily or eagerly
 depending on method return type
In-Reply-To: <c4954b0c-ca2a-7cb1-4710-36af333e7d06@oracle.com>
References: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
 <c4954b0c-ca2a-7cb1-4710-36af333e7d06@oracle.com>
Message-ID: <59b1c6ff-ab08-8a8f-12b7-21f78285571b@oracle.com>

On 24/05/2023 12:50 am, Raffaello Giulietti wrote:
> I think the problem here is that you are deleting a class in a nest.
> 
> During the verification of BaseClassReturner.getObject(), access control 
> (JVMS, 5.4.4, second half) determines that the nest is broken, as 
> ChildClass is not present anymore.

Not sure access control gets involved at this stage of the verification 
process. But in any case turning on logging does not show anything 
related to nestmates happening between BaseClass and ChildClass. It 
seems to just be the resolution of the return type during verification 
of the method, that causes the loading of ChildClass and the subsequent 
CNFE if it has been removed.

> If you move ChildClass out of TestLoading so that it becomes a top-level 
> class extending TestLoading.BaseClass, and if you adapt the line that 
> initializes the local var classFileB to refer to the new location, the 
> code will not throw, despite ChildClass being deleted.

My simplified test shows it still throws when verifying BaseClassReturner.


Cheers,
David

> 
> Greetings
> Raffaello
> 
> 
> 
> On 2023-05-23 13:20, ?????? ??????? wrote:
>> Hello,
>>
>> originally this question was asked here: 
>> https://stackoverflow.com/q/76260269/12473843,
>> the code sample for reproduction will be put below or can be found via 
>> the link
>>
>> The issue is about eager/lazy loading of a class depending on method 
>> return type.
>> If one runs the code below with Java 11-19 it will fail with 
>> NoClassDefFoundError (this is expected as delete class file for 
>> ChildClass):
>>
>> java.lang.NoClassDefFoundError: org/example/TestLoading$ChildClass
>> ????at java.base/java.lang.Class.forName0(Native Method)
>> ????at java.base/java.lang.Class.forName(Class.java:390)
>> ????at java.base/java.lang.Class.forName(Class.java:381)
>> ????at org.example.TestLoading.loadMyClass(TestLoading.java:29)
>> ????at org.example.TestLoading.main(TestLoading.java:23)
>> Caused by: java.lang.ClassNotFoundException: 
>> org.example.TestLoading$ChildClass
>> ????at 
>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>> ????at 
>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>> ????at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>> ????... 5 more
>>
>> As of Java 20 chapter 12.4.1 of JLS states:
>> ---------------------------------------------------------
>> A class or interface T will be initialized immediately before the 
>> first occurrence of any one of the following:
>>
>> - T is a class and an instance of T is created.
>> - a static method declared by T is invoked.
>> - a static field declared by T is assigned.
>> - a static field declared by T is used and the field is not a constant 
>> variable (?4.12.4).
>>
>> When a class is initialized, its superclasses are initialized (if they 
>> have not been previously initialized), as well as any superinterfaces 
>> (?8.1.5) that declare any default methods (?9.4.3) (if they have not 
>> been previously initialized).
>> Initialization of an interface does not, of itself, cause 
>> initialization of any of its superinterfaces.
>> A reference to a static field (?8.3.1.1) causes initialization of only 
>> the class or interface that actually declares it, even though it might 
>> be referred to through the name of a subclass, a subinterface, or a 
>> class that implements an interface.
>> Invocation of certain reflective methods in class Class and in package 
>> java.lang.reflect also causes class or interface initialization.
>> A class or interface will not be initialized under any other 
>> circumstance.
>> ---------------------------------------------------------
>> With the code snippet we see that calling 
>> Class.forName(ObjectReturner.class.getName()) succeeds and 
>> Class.forName(BaseClassReturner.class.getName()) fails even though 
>> both declare returning an instance of ChildClass.
>> This failure is unexpected as in the code below we don't fulfill any 
>> requirement for class loading as of JLS 12.4.1, but the JVM still 
>> tries to load the class.
>>
>> I suspect it might be related to class file validation and/or 
>> security, because when we run the code with -Xlog:class+init there's a 
>> reference to LinkageError in loading log:
>>
>> loading: org.example.TestLoading$BaseClassReturner...
>> [0.277s][info][class,init] Start class verification for: 
>> org.example.TestLoading$BaseClassReturner
>> [0.277s][info][class,init] 771 Initializing 
>> 'java/lang/ReflectiveOperationException'(no method) (0x0000000800004028)
>> [0.277s][info][class,init] 772 Initializing 
>> 'java/lang/ClassNotFoundException'(no method) (0x0000000800004288)
>> [0.277s][info][class,init] 773 Initializing 
>> 'java/lang/LinkageError'(no method) 
>> (0x00000008000044f8)????????????????????????????????? <----
>> [0.277s][info][class,init] 774 Initializing 
>> 'java/lang/NoClassDefFoundError'(no method) (0x0000000800004758)
>> [0.277s][info][class,init] Verification for 
>> org.example.TestLoading$BaseClassReturner has exception pending 
>> 'java.lang.NoClassDefFoundError org/example/TestLoading$ChildClass'
>> [0.277s][info][class,init] End class verification for: 
>> org.example.TestLoading$BaseClassReturner
>>
>>
>> So I've got three questions about this:
>> - Does class loading depend on method's return type?
>> - Which part of JLS/JVM spec describes eager class loading in this case?
>> - Could one point out the particular piece of the VM code responsible 
>> for class loading in this case?
>>
>> Regards,
>> Sergey Tsypanov
>>
>> Code snippet for reproduction:
>>
>> public class TestLoading {
>>
>> ?? public static void main(String[] args) throws Exception {
>> ???? Class.forName(BaseClass.class.getName());
>> ???? URL classFileB = 
>> TestLoading.class.getResource(TestLoading.class.getSimpleName() + 
>> "$ChildClass.class");
>> ???? if (classFileB != null) {
>> ?????? if (!"file".equals(classFileB.getProtocol())) {
>> ???????? throw new UnsupportedOperationException();
>> ?????? }
>> ?????? Path path = new File(classFileB.getPath()).toPath();
>> ?????? System.out.println("deleting: " + path);
>> ?????? Files.delete(path);
>> ???? }
>>
>> ???? loadMyClass(ObjectReturner.class.getName());
>> ???? loadMyClass(BaseClassReturner.class.getName());
>> ?? }
>>
>> ?? private static void loadMyClass(String name) {
>> ???? System.out.println("loading: " + name + "...");
>> ???? try {
>> ?????? Class.forName(name);
>> ???? } catch (Throwable e) {
>> ?????? e.printStackTrace(System.out);
>> ???? }
>> ?? }
>>
>> ?? public static class BaseClass {
>> ?? }
>>
>> ?? public static class ChildClass extends BaseClass {
>> ?? }
>>
>> ?? public static class ObjectReturner {
>> ???? public Object getObject() {
>> ?????? return new ChildClass();
>> ???? }
>> ?? }
>>
>> ?? public static class BaseClassReturner {
>> ???? public BaseClass getObject() {
>> ?????? return new ChildClass();
>> ???? }
>> ?? }
>> }

From forax at univ-mlv.fr  Tue May 23 22:31:36 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 24 May 2023 00:31:36 +0200 (CEST)
Subject: Classes used in method body are loaded lazily or eagerly
 depending on method return type
In-Reply-To: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
References: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
Message-ID: <573460028.62977001.1684881096522.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "?????? ???????" <sergei.tsypanov at yandex.ru>
> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Tuesday, May 23, 2023 1:20:44 PM
> Subject: Classes used in method body are loaded lazily or eagerly depending on method return type

> Hello,

Hello,

> 
> originally this question was asked here:
> https://stackoverflow.com/q/76260269/12473843,
> the code sample for reproduction will be put below or can be found via the link
> 
> The issue is about eager/lazy loading of a class depending on method return
> type.

It also depends on the content of the methods.
If you modify the code to return null, the NoClassDefFoundError disappears

 public static class ObjectReturner {
   public Object getObject() {
     return null;
   }
 }
 
 public static class BaseClassReturner {
    public BaseClass getObject() {
      return null;
    }
 }

which means that the NoClassDefFoundError comes from the bytecode verifier.

In your original ObjectReturner, the bytecode verifier needs to check if ChildClass is an Object and there is a shortcircuit for that, so ChildClass does not need to be loaded.
But in BaseClassReturner, the bytecode verifier needs to check if ChildClass is a BaseClass, so it has to load ChildClass to know if the superclass is BaseClass.

Another way to see that it's the verifier that triggers the class loading is to use the option "-noverify"
  java -noverify TestLoading

should works !

regards,
R?mi


> If one runs the code below with Java 11-19 it will fail with
> NoClassDefFoundError (this is expected as delete class file for ChildClass):
> 
> java.lang.NoClassDefFoundError: org/example/TestLoading$ChildClass
>	at java.base/java.lang.Class.forName0(Native Method)
>	at java.base/java.lang.Class.forName(Class.java:390)
>	at java.base/java.lang.Class.forName(Class.java:381)
>	at org.example.TestLoading.loadMyClass(TestLoading.java:29)
>	at org.example.TestLoading.main(TestLoading.java:23)
> Caused by: java.lang.ClassNotFoundException: org.example.TestLoading$ChildClass
>	at
>	java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>	at
>	java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>	... 5 more
> 
> As of Java 20 chapter 12.4.1 of JLS states:
> ---------------------------------------------------------
> A class or interface T will be initialized immediately before the first
> occurrence of any one of the following:
> 
> - T is a class and an instance of T is created.
> - a static method declared by T is invoked.
> - a static field declared by T is assigned.
> - a static field declared by T is used and the field is not a constant variable
> (?4.12.4).
> 
> When a class is initialized, its superclasses are initialized (if they have not
> been previously initialized), as well as any superinterfaces (?8.1.5) that
> declare any default methods (?9.4.3) (if they have not been previously
> initialized).
> Initialization of an interface does not, of itself, cause initialization of any
> of its superinterfaces.
> A reference to a static field (?8.3.1.1) causes initialization of only the class
> or interface that actually declares it, even though it might be referred to
> through the name of a subclass, a subinterface, or a class that implements an
> interface.
> Invocation of certain reflective methods in class Class and in package
> java.lang.reflect also causes class or interface initialization.
> A class or interface will not be initialized under any other circumstance.
> ---------------------------------------------------------
> With the code snippet we see that calling
> Class.forName(ObjectReturner.class.getName()) succeeds and
> Class.forName(BaseClassReturner.class.getName()) fails even though both declare
> returning an instance of ChildClass.
> This failure is unexpected as in the code below we don't fulfill any requirement
> for class loading as of JLS 12.4.1, but the JVM still tries to load the class.
> 
> I suspect it might be related to class file validation and/or security, because
> when we run the code with -Xlog:class+init there's a reference to LinkageError
> in loading log:
> 
> loading: org.example.TestLoading$BaseClassReturner...
> [0.277s][info][class,init] Start class verification for:
> org.example.TestLoading$BaseClassReturner
> [0.277s][info][class,init] 771 Initializing
> 'java/lang/ReflectiveOperationException'(no method) (0x0000000800004028)
> [0.277s][info][class,init] 772 Initializing
> 'java/lang/ClassNotFoundException'(no method) (0x0000000800004288)
> [0.277s][info][class,init] 773 Initializing 'java/lang/LinkageError'(no method)
> (0x00000008000044f8)                                  <----
> [0.277s][info][class,init] 774 Initializing 'java/lang/NoClassDefFoundError'(no
> method) (0x0000000800004758)
> [0.277s][info][class,init] Verification for
> org.example.TestLoading$BaseClassReturner has exception pending
> 'java.lang.NoClassDefFoundError org/example/TestLoading$ChildClass'
> [0.277s][info][class,init] End class verification for:
> org.example.TestLoading$BaseClassReturner
> 
> 
> So I've got three questions about this:
> - Does class loading depend on method's return type?
> - Which part of JLS/JVM spec describes eager class loading in this case?
> - Could one point out the particular piece of the VM code responsible for class
> loading in this case?
> 
> Regards,
> Sergey Tsypanov
> 
> Code snippet for reproduction:
> 
> public class TestLoading {
> 
>  public static void main(String[] args) throws Exception {
>    Class.forName(BaseClass.class.getName());
>    URL classFileB = TestLoading.class.getResource(TestLoading.class.getSimpleName()
>    + "$ChildClass.class");
>    if (classFileB != null) {
>      if (!"file".equals(classFileB.getProtocol())) {
>        throw new UnsupportedOperationException();
>      }
>      Path path = new File(classFileB.getPath()).toPath();
>      System.out.println("deleting: " + path);
>      Files.delete(path);
>    }
> 
>    loadMyClass(ObjectReturner.class.getName());
>    loadMyClass(BaseClassReturner.class.getName());
>  }
> 
>  private static void loadMyClass(String name) {
>    System.out.println("loading: " + name + "...");
>    try {
>      Class.forName(name);
>    } catch (Throwable e) {
>      e.printStackTrace(System.out);
>    }
>  }
> 
>  public static class BaseClass {
>  }
> 
>  public static class ChildClass extends BaseClass {
>  }
> 
>  public static class ObjectReturner {
>    public Object getObject() {
>      return new ChildClass();
>    }
>  }
> 
>  public static class BaseClassReturner {
>    public BaseClass getObject() {
>      return new ChildClass();
>    }
>  }
> }

From forax at univ-mlv.fr  Tue May 23 22:35:06 2023
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 24 May 2023 00:35:06 +0200 (CEST)
Subject: Classes used in method body are loaded lazily or eagerly
 depending on method return type
In-Reply-To: <59b1c6ff-ab08-8a8f-12b7-21f78285571b@oracle.com>
References: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
 <c4954b0c-ca2a-7cb1-4710-36af333e7d06@oracle.com>
 <59b1c6ff-ab08-8a8f-12b7-21f78285571b@oracle.com>
Message-ID: <1813541396.62977656.1684881306040.JavaMail.zimbra@univ-eiffel.fr>



----- Original Message -----
> From: "David Holmes" <david.holmes at oracle.com>
> To: "Raffaello Giulietti" <raffaello.giulietti at oracle.com>, "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Wednesday, May 24, 2023 12:23:24 AM
> Subject: Re: Classes used in method body are loaded lazily or eagerly depending on method return type

> On 24/05/2023 12:50 am, Raffaello Giulietti wrote:
>> I think the problem here is that you are deleting a class in a nest.
>> 
>> During the verification of BaseClassReturner.getObject(), access control
>> (JVMS, 5.4.4, second half) determines that the nest is broken, as
>> ChildClass is not present anymore.
> 
> Not sure access control gets involved at this stage of the verification
> process. But in any case turning on logging does not show anything
> related to nestmates happening between BaseClass and ChildClass. It
> seems to just be the resolution of the return type during verification
> of the method, that causes the loading of ChildClass and the subsequent
> CNFE if it has been removed.
> 
>> If you move ChildClass out of TestLoading so that it becomes a top-level
>> class extending TestLoading.BaseClass, and if you adapt the line that
>> initializes the local var classFileB to refer to the new location, the
>> code will not throw, despite ChildClass being deleted.
> 
> My simplified test shows it still throws when verifying BaseClassReturner.

Nestmate checking is done lazily, so if you do not call a method/access a field of a nested class, the VM should not trigger a class loading.

Moreover, if you test with Java 8 (nestmates were introduced in Java 11), it failed too.
That's another clue that the error is not related to nestmates checking.

> 
> 
> Cheers,
> David

regards,
R?mi

> 
>> 
>> Greetings
>> Raffaello
>> 
>> 
>> 
>> On 2023-05-23 13:20, ?????? ??????? wrote:
>>> Hello,
>>>
>>> originally this question was asked here:
>>> https://stackoverflow.com/q/76260269/12473843,
>>> the code sample for reproduction will be put below or can be found via
>>> the link
>>>
>>> The issue is about eager/lazy loading of a class depending on method
>>> return type.
>>> If one runs the code below with Java 11-19 it will fail with
>>> NoClassDefFoundError (this is expected as delete class file for
>>> ChildClass):
>>>
>>> java.lang.NoClassDefFoundError: org/example/TestLoading$ChildClass
>>> ????at java.base/java.lang.Class.forName0(Native Method)
>>> ????at java.base/java.lang.Class.forName(Class.java:390)
>>> ????at java.base/java.lang.Class.forName(Class.java:381)
>>> ????at org.example.TestLoading.loadMyClass(TestLoading.java:29)
>>> ????at org.example.TestLoading.main(TestLoading.java:23)
>>> Caused by: java.lang.ClassNotFoundException:
>>> org.example.TestLoading$ChildClass
>>> ????at
>>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>>> ????at
>>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>>> ????at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>>> ????... 5 more
>>>
>>> As of Java 20 chapter 12.4.1 of JLS states:
>>> ---------------------------------------------------------
>>> A class or interface T will be initialized immediately before the
>>> first occurrence of any one of the following:
>>>
>>> - T is a class and an instance of T is created.
>>> - a static method declared by T is invoked.
>>> - a static field declared by T is assigned.
>>> - a static field declared by T is used and the field is not a constant
>>> variable (?4.12.4).
>>>
>>> When a class is initialized, its superclasses are initialized (if they
>>> have not been previously initialized), as well as any superinterfaces
>>> (?8.1.5) that declare any default methods (?9.4.3) (if they have not
>>> been previously initialized).
>>> Initialization of an interface does not, of itself, cause
>>> initialization of any of its superinterfaces.
>>> A reference to a static field (?8.3.1.1) causes initialization of only
>>> the class or interface that actually declares it, even though it might
>>> be referred to through the name of a subclass, a subinterface, or a
>>> class that implements an interface.
>>> Invocation of certain reflective methods in class Class and in package
>>> java.lang.reflect also causes class or interface initialization.
>>> A class or interface will not be initialized under any other
>>> circumstance.
>>> ---------------------------------------------------------
>>> With the code snippet we see that calling
>>> Class.forName(ObjectReturner.class.getName()) succeeds and
>>> Class.forName(BaseClassReturner.class.getName()) fails even though
>>> both declare returning an instance of ChildClass.
>>> This failure is unexpected as in the code below we don't fulfill any
>>> requirement for class loading as of JLS 12.4.1, but the JVM still
>>> tries to load the class.
>>>
>>> I suspect it might be related to class file validation and/or
>>> security, because when we run the code with -Xlog:class+init there's a
>>> reference to LinkageError in loading log:
>>>
>>> loading: org.example.TestLoading$BaseClassReturner...
>>> [0.277s][info][class,init] Start class verification for:
>>> org.example.TestLoading$BaseClassReturner
>>> [0.277s][info][class,init] 771 Initializing
>>> 'java/lang/ReflectiveOperationException'(no method) (0x0000000800004028)
>>> [0.277s][info][class,init] 772 Initializing
>>> 'java/lang/ClassNotFoundException'(no method) (0x0000000800004288)
>>> [0.277s][info][class,init] 773 Initializing
>>> 'java/lang/LinkageError'(no method)
>>> (0x00000008000044f8)????????????????????????????????? <----
>>> [0.277s][info][class,init] 774 Initializing
>>> 'java/lang/NoClassDefFoundError'(no method) (0x0000000800004758)
>>> [0.277s][info][class,init] Verification for
>>> org.example.TestLoading$BaseClassReturner has exception pending
>>> 'java.lang.NoClassDefFoundError org/example/TestLoading$ChildClass'
>>> [0.277s][info][class,init] End class verification for:
>>> org.example.TestLoading$BaseClassReturner
>>>
>>>
>>> So I've got three questions about this:
>>> - Does class loading depend on method's return type?
>>> - Which part of JLS/JVM spec describes eager class loading in this case?
>>> - Could one point out the particular piece of the VM code responsible
>>> for class loading in this case?
>>>
>>> Regards,
>>> Sergey Tsypanov
>>>
>>> Code snippet for reproduction:
>>>
>>> public class TestLoading {
>>>
>>> ?? public static void main(String[] args) throws Exception {
>>> ???? Class.forName(BaseClass.class.getName());
>>> ???? URL classFileB =
>>> TestLoading.class.getResource(TestLoading.class.getSimpleName() +
>>> "$ChildClass.class");
>>> ???? if (classFileB != null) {
>>> ?????? if (!"file".equals(classFileB.getProtocol())) {
>>> ???????? throw new UnsupportedOperationException();
>>> ?????? }
>>> ?????? Path path = new File(classFileB.getPath()).toPath();
>>> ?????? System.out.println("deleting: " + path);
>>> ?????? Files.delete(path);
>>> ???? }
>>>
>>> ???? loadMyClass(ObjectReturner.class.getName());
>>> ???? loadMyClass(BaseClassReturner.class.getName());
>>> ?? }
>>>
>>> ?? private static void loadMyClass(String name) {
>>> ???? System.out.println("loading: " + name + "...");
>>> ???? try {
>>> ?????? Class.forName(name);
>>> ???? } catch (Throwable e) {
>>> ?????? e.printStackTrace(System.out);
>>> ???? }
>>> ?? }
>>>
>>> ?? public static class BaseClass {
>>> ?? }
>>>
>>> ?? public static class ChildClass extends BaseClass {
>>> ?? }
>>>
>>> ?? public static class ObjectReturner {
>>> ???? public Object getObject() {
>>> ?????? return new ChildClass();
>>> ???? }
>>> ?? }
>>>
>>> ?? public static class BaseClassReturner {
>>> ???? public BaseClass getObject() {
>>> ?????? return new ChildClass();
>>> ???? }
>>> ?? }
> >> }

From bpb at openjdk.org  Tue May 23 22:57:03 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 May 2023 22:57:03 GMT
Subject: RFR: 8290499: new File(parent,
 \"/\") breaks normalization =?UTF-8?B?4oCT?= creates File with slash at the
 end
Message-ID: <8xzVUmIbNYbHrO6ymEBcptZ4uK5saoxx0xXzmdVSc9E=.30439fa6-e4bb-46fb-b1be-0e103a31d6e5@github.com>

In `java.io.File`, change the constructors `File(File,String)` and `File(String,String)` so that they do not for typical cases return a `File` whose path has a trailing name separator.

-------------

Commit messages:
 - 8290499: new File(parent, \"/\") breaks normalization ? creates File with slash at the end

Changes: https://git.openjdk.org/jdk/pull/14109/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14109&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8290499
  Stats: 34 lines in 3 files changed: 28 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14109.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14109/head:pull/14109

PR: https://git.openjdk.org/jdk/pull/14109

From psandoz at openjdk.org  Tue May 23 23:11:56 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 23 May 2023 23:11:56 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v4]
In-Reply-To: <JKdzvoFRLTLg3GIZSCWmfvXXE6TKuB4L-9PWTV3MuKw=.1f76e514-a9d7-4b6c-9843-d9ff4d6cdcd7@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <mNvyH9yRqp0OZJdx10SwbRBgyqTq_QdXGB-qHeTQ8B8=.c3bc2710-e51a-4855-a18e-0e3cbee33281@github.com>
 <JKdzvoFRLTLg3GIZSCWmfvXXE6TKuB4L-9PWTV3MuKw=.1f76e514-a9d7-4b6c-9843-d9ff4d6cdcd7@github.com>
Message-ID: <0yBgEHwVOF3O1JYXdtD_QNqBpS-rR_MM6F29QICWqZA=.a1daa08a-1953-40d7-98b0-733887ebd804@github.com>

On Tue, 23 May 2023 20:32:10 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Effectively, what you suggest amount at saying: we do have a JAVA_CHAR layout, which is mostly there for Java interop. But a native linker (which only cares about native interop) doesn't really care much about that. Does that sound good?

Yes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1560241481

From jlu at openjdk.org  Tue May 23 23:24:01 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 May 2023 23:24:01 GMT
Subject: RFR: 8174722: Wrong behavior of DecimalFormat with RoundingMode.UP in
 special case
Message-ID: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>

Please review this PR, which addresses a case where Decimal Format would violate certain RoundingMode contracts given the right pattern and double.

For example,


DecimalFormat df = new DecimalFormat();
df.setRoundingMode(RoundingMode.UP);
double small = 0.0001;
double big = 1.0001;
df.applyPattern("0.00");
df.format(small); // returns 0.00, which violates UP
df.format(big); // returns 1.01, which does not violate UP


In this example `0.0001` becomes `0.00`, a decrease in magnitude. This violates the RoundingMode.UP contract as RoundingMode.UP states "Note that this rounding mode never decreases the magnitude of the calculated value."

This edge case is a result of when values smaller than the absolute value of `.1` have more leading zeros between the decimal and the first non-zero digit (_0.0001 -> **3**_) than maximum fractional digits in the pattern (_0.00 -> **2**_).

The change to Decimal Format ensures that during this case, the rounding mode is considered before truncation, which dictates if the formatted number should insert a 1 in the least significant digit location.

The test validates the change by using data from larger counterparts. For example, If we are testing `0.0009`, we can format `1.0009` with the same pattern and mode that we use on `0.0009`, then compare the fractional portions to each other and ensure they are equal.

-------------

Commit messages:
 - Clarify test comment
 - Missing period
 - Add Impl
 - Use RoundingMode.values() instead of hard coding a static array
 - Add test

Changes: https://git.openjdk.org/jdk/pull/14110/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14110&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8174722
  Stats: 164 lines in 2 files changed: 163 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14110.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14110/head:pull/14110

PR: https://git.openjdk.org/jdk/pull/14110

From darcy at openjdk.org  Tue May 23 23:32:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 May 2023 23:32:54 GMT
Subject: RFR: 8174722: Wrong behavior of DecimalFormat with RoundingMode.UP
 in special case
In-Reply-To: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
Message-ID: <m3Jb8l0DUHcjimtBoafHR2fng3_JHz6RpviDtKcl47k=.a8a2c222-aee8-4a95-a040-8ce90fb98f03@github.com>

On Tue, 23 May 2023 23:16:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which addresses a case where Decimal Format would violate certain RoundingMode contracts given the right pattern and double.
> 
> For example,
> 
> 
> DecimalFormat df = new DecimalFormat();
> df.setRoundingMode(RoundingMode.UP);
> double small = 0.0001;
> double big = 1.0001;
> df.applyPattern("0.00");
> df.format(small); // returns 0.00, which violates UP
> df.format(big); // returns 1.01, which does not violate UP
> 
> 
> In this example `0.0001` becomes `0.00`, a decrease in magnitude. This violates the RoundingMode.UP contract as RoundingMode.UP states "Note that this rounding mode never decreases the magnitude of the calculated value."
> 
> This edge case is a result of when values smaller than the absolute value of `.1` have more leading zeros between the decimal and the first non-zero digit (_0.0001 -> **3**_) than maximum fractional digits in the pattern (_0.00 -> **2**_).
> 
> The change to Decimal Format ensures that during this case, the rounding mode is considered before truncation, which dictates if the formatted number should insert a 1 in the least significant digit location.
> 
> The test validates the change by using data from larger counterparts. For example, If we are testing `0.0009`, we can format `1.0009` with the same pattern and mode that we use on `0.0009`, then compare the fractional portions to each other and ensure they are equal.

Note there are some hazards here with respect to the numerical values of double and the decimal string used to represent the double; in exact terms:


jshell> new BigDecimal(1.0001)
$2 ==> 1.0000999999999999889865875957184471189975738525390625

jshell> new BigDecimal(0.0001)
$3 ==> 0.000100000000000000004792173602385929598312941379845142364501953125

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14110#issuecomment-1560254680

From jlu at openjdk.org  Wed May 24 00:38:10 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 24 May 2023 00:38:10 GMT
Subject: RFR: 8174722: Wrong behavior of DecimalFormat with RoundingMode.UP
 in special case
In-Reply-To: <m3Jb8l0DUHcjimtBoafHR2fng3_JHz6RpviDtKcl47k=.a8a2c222-aee8-4a95-a040-8ce90fb98f03@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
 <m3Jb8l0DUHcjimtBoafHR2fng3_JHz6RpviDtKcl47k=.a8a2c222-aee8-4a95-a040-8ce90fb98f03@github.com>
Message-ID: <j2Wi1WfGlqgNbZwviFtIkHFoNLM5cn1ufZD75R3c3aw=.eda3df62-d347-4078-b1f6-d16a2a19507b@github.com>

On Tue, 23 May 2023 23:30:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Note there are some hazards here with respect to the numerical values of double and the decimal string used to represent the double; in exact terms:
> 
> ```
> jshell> new BigDecimal(1.0001)
> $2 ==> 1.0000999999999999889865875957184471189975738525390625
> 
> jshell> new BigDecimal(0.0001)
> $3 ==> 0.000100000000000000004792173602385929598312941379845142364501953125
> ```

Thanks for bringing that to my attention Joe. I will re-evaluate how I test the changes then.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14110#issuecomment-1560295694

From liach at openjdk.org  Wed May 24 02:18:01 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 May 2023 02:18:01 GMT
Subject: RFR: 8306889: Convert MethodTypeDescImpl parameter storage from
 array to immutable list [v3]
In-Reply-To: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
Message-ID: <F5fSirVfToAsjvy7e4N3fG43gh52SPoPNS4lZsmRm4Q=.adb115d9-0ef8-47b5-b46b-f1383efa41a2@github.com>

> This patch moves the parameters to an immutable list, to avoid allocations on `parameterList` as well. In addition, it fixes 8304932, the bug where if a caller keeps a reference to the array passed into `MethodTypeDesc.of`, the caller may mutate the Desc via the array and can create invalid MethodTypeDesc.
> 
> This patch has minor performance gains on `ofDescriptor` factory, even compared to Adam's patch that optimized `ofDescriptor` in #12945.
> 
> Benchmark of Oracle JDK 20: https://gist.github.com/683c6219e183cbc2b336224fc2c0d50a
> Benchmark of this patch: https://gist.github.com/22be9371a2370fb4a7b44f1684750ec4
> Benchmark of [asotona's patch](https://github.com/openjdk/jdk/pull/12945/files#diff-ac8e413d3e13532a2b0d34a90253c6ddd7a4f04082f792b9d076e9b5a33f2078): https://gist.github.com/eb98579c3b51cafae481049a95a78f80
> 
> [sotona vs this](https://jmh.morethan.io/?gists=eb98579c3b51cafae481049a95a78f80,22be9371a2370fb4a7b44f1684750ec4); [20 vs this](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,22be9371a2370fb4a7b44f1684750ec4); [20 vs sotona](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,eb98579c3b51cafae481049a95a78f80), for reference

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Finish merge, also examine the improved performance of descriptor string computation
 - Merge branch 'master' into fix/mtd-immutable
 - Merge branch 'mtd-desc-cache' into fix/mtd-immutable
 - commit
 - Fix some inconsistencies in the method descriptor derivation methods
 - Add benchmark
 - 8304932: MethodTypeDescImpl can be mutated by argument passed to MethodTypeDesc.of

-------------

Changes: https://git.openjdk.org/jdk/pull/13186/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13186&range=02
  Stats: 415 lines in 6 files changed: 275 ins; 75 del; 65 mod
  Patch: https://git.openjdk.org/jdk/pull/13186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13186/head:pull/13186

PR: https://git.openjdk.org/jdk/pull/13186

From liach at openjdk.org  Wed May 24 02:29:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 May 2023 02:29:09 GMT
Subject: RFR: 8306889: Convert MethodTypeDescImpl parameter storage from
 array to immutable list [v4]
In-Reply-To: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
Message-ID: <vzn8QEVPvzZa3WqRyZWFQniQ3UjhiWFeJUjXb4Pguhc=.835afe67-b172-4647-8926-4081d02f050a@github.com>

> This patch moves the parameters to an immutable list, to avoid allocations on `parameterList` as well. In addition, it fixes 8304932, the bug where if a caller keeps a reference to the array passed into `MethodTypeDesc.of`, the caller may mutate the Desc via the array and can create invalid MethodTypeDesc.
> 
> This patch has minor performance gains on `ofDescriptor` factory, even compared to Adam's patch that optimized `ofDescriptor` in #12945.
> 
> Benchmark of Oracle JDK 20: https://gist.github.com/683c6219e183cbc2b336224fc2c0d50a
> Benchmark of this patch: https://gist.github.com/22be9371a2370fb4a7b44f1684750ec4
> Benchmark of [asotona's patch](https://github.com/openjdk/jdk/pull/12945/files#diff-ac8e413d3e13532a2b0d34a90253c6ddd7a4f04082f792b9d076e9b5a33f2078): https://gist.github.com/eb98579c3b51cafae481049a95a78f80
> 
> [sotona vs this](https://jmh.morethan.io/?gists=eb98579c3b51cafae481049a95a78f80,22be9371a2370fb4a7b44f1684750ec4); [20 vs this](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,22be9371a2370fb4a7b44f1684750ec4); [20 vs sotona](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,eb98579c3b51cafae481049a95a78f80), for reference

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  reuse immutable list to avoid array allocation

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13186/files
  - new: https://git.openjdk.org/jdk/pull/13186/files/6044b7ee..efc8018c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13186&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13186&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13186.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13186/head:pull/13186

PR: https://git.openjdk.org/jdk/pull/13186

From liach at openjdk.org  Wed May 24 02:44:06 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 24 May 2023 02:44:06 GMT
Subject: RFR: 8306889: Convert MethodTypeDescImpl parameter storage from
 array to immutable list [v4]
In-Reply-To: <vzn8QEVPvzZa3WqRyZWFQniQ3UjhiWFeJUjXb4Pguhc=.835afe67-b172-4647-8926-4081d02f050a@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
 <vzn8QEVPvzZa3WqRyZWFQniQ3UjhiWFeJUjXb4Pguhc=.835afe67-b172-4647-8926-4081d02f050a@github.com>
Message-ID: <UMxrcX6lk4-Zm5Ikdsdc6ymovRzgrE4Jc8XjkV3cO24=.57ce3706-2fdf-4490-92a4-8affc52358d1@github.com>

On Wed, 24 May 2023 02:29:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch moves the parameters to an immutable list, to avoid allocations on `parameterList` as well. In addition, it fixes 8304932, the bug where if a caller keeps a reference to the array passed into `MethodTypeDesc.of`, the caller may mutate the Desc via the array and can create invalid MethodTypeDesc.
>> 
>> The latest benchmark results are available here: https://github.com/openjdk/jdk/pull/13186#issuecomment-1560378822
>> 
>> This patch has minor performance gains on `ofDescriptor` factory, even compared to Adam's patch that optimized `ofDescriptor` in #12945.
>> 
>> Benchmark of Oracle JDK 20: https://gist.github.com/683c6219e183cbc2b336224fc2c0d50a
>> Benchmark of this patch: https://gist.github.com/22be9371a2370fb4a7b44f1684750ec4
>> Benchmark of [asotona's patch](https://github.com/openjdk/jdk/pull/12945/files#diff-ac8e413d3e13532a2b0d34a90253c6ddd7a4f04082f792b9d076e9b5a33f2078): https://gist.github.com/eb98579c3b51cafae481049a95a78f80
>> 
>> [sotona vs this](https://jmh.morethan.io/?gists=eb98579c3b51cafae481049a95a78f80,22be9371a2370fb4a7b44f1684750ec4); [20 vs this](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,22be9371a2370fb4a7b44f1684750ec4); [20 vs sotona](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,eb98579c3b51cafae481049a95a78f80), for reference
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reuse immutable list to avoid array allocation

Now updated to the latest MethodTypeDesc.of factories, this patch is ready for review and integration. Below is a few performance information about this patch.

This patch:

Benchmark                                                                     (descString)   Mode  Cnt      Score      Error   Units
MethodTypeDescDescriptor.computeDescriptorString   (Ljava/lang/Object;Ljava/lang/String;)I  thrpt    6  39518.106 ?  525.077  ops/ms
MethodTypeDescDescriptor.computeDescriptorString                                       ()V  thrpt    6  62312.500 ?  579.585  ops/ms
MethodTypeDescDescriptor.computeDescriptorString  ([IJLjava/lang/String;Z)Ljava/util/List;  thrpt    6  21856.065 ?  678.237  ops/ms
MethodTypeDescDescriptor.computeDescriptorString                     ()[Ljava/lang/String;  thrpt    6  57457.483 ? 1416.646  ops/ms

Benchmark                      Mode  Cnt      Score     Error  Units
RebuildMethodBodies.shared    thrpt    4  21684.365 ? 941.586  ops/s
RebuildMethodBodies.unshared  thrpt    4  15724.422 ? 153.420  ops/s

master:

Benchmark                                                                        (descString)   Mode  Cnt     Score     Error   Units
MethodTypeDescDescriptorOld.computeDescriptorString   (Ljava/lang/Object;Ljava/lang/String;)I  thrpt    6  6062.735 ?  61.852  ops/ms
MethodTypeDescDescriptorOld.computeDescriptorString                                       ()V  thrpt    6  8703.338 ? 205.429  ops/ms
MethodTypeDescDescriptorOld.computeDescriptorString  ([IJLjava/lang/String;Z)Ljava/util/List;  thrpt    6  5673.104 ?  62.810  ops/ms
MethodTypeDescDescriptorOld.computeDescriptorString                     ()[Ljava/lang/String;  thrpt    6  8232.874 ? 161.060  ops/ms

Benchmark                      Mode  Cnt      Score     Error  Units
RebuildMethodBodies.shared    thrpt    4  18317.288 ? 465.309  ops/s
RebuildMethodBodies.unshared  thrpt    4  13744.541 ? 399.263  ops/s


The Classfile API code generation and descriptor string computation speed up with this patch.

Additional benchmarks for this patch:

Benchmark                                     (kind)   Mode  Cnt       Score       Error   Units
MethodTypeDescConstruct.ofArrayBench         GENERIC  thrpt    6  203322.703 ?  5795.340  ops/ms
MethodTypeDescConstruct.ofArrayBench            VOID  thrpt    6  397200.234 ?  7467.524  ops/ms
MethodTypeDescConstruct.ofArrayBench        NO_PARAM  thrpt    6  398156.642 ?  7230.653  ops/ms
MethodTypeDescConstruct.ofArrayBench       ARBITRARY  thrpt    6   91751.039 ?  2451.052  ops/ms
MethodTypeDescConstruct.ofDescriptorBench    GENERIC  thrpt    6    8184.264 ?   185.177  ops/ms
MethodTypeDescConstruct.ofDescriptorBench       VOID  thrpt    6   68775.908 ?  2471.949  ops/ms
MethodTypeDescConstruct.ofDescriptorBench   NO_PARAM  thrpt    6   28129.233 ?   454.477  ops/ms
MethodTypeDescConstruct.ofDescriptorBench  ARBITRARY  thrpt    6    7634.086 ?   333.202  ops/ms
MethodTypeDescConstruct.ofListBench          GENERIC  thrpt    6  311382.640 ? 15817.487  ops/ms
MethodTypeDescConstruct.ofListBench             VOID  thrpt    6  371300.447 ?  2310.545  ops/ms
MethodTypeDescConstruct.ofListBench         NO_PARAM  thrpt    6  367942.613 ? 10068.395  ops/ms
MethodTypeDescConstruct.ofListBench        ARBITRARY  thrpt    6  199825.985 ?  5963.658  ops/ms

Shows that immutable parameter lists from users can be reused, and that using object representation to construct method type descs is always preferable to parsing descriptors; this is the same conclusion from #13671, that avoiding repeated parsing and reusing tokenization from classfile builder site actually improves performance.

Descriptor parsing is somewhat slower than in the initial benchmark, though the recent updates did not touch code in that area.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13186#issuecomment-1560378822

From alanb at openjdk.org  Wed May 24 06:04:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 May 2023 06:04:56 GMT
Subject: RFR: 8308475: Make the thread dump files generated by jcmd
 Thread.dump_to_file jtreg failure handler action easily accessible
In-Reply-To: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>
References: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>
Message-ID: <JnPKnWyVYwYrJIbQTX5BG8jsCtVjAz108rJvNyQA8cI=.eb536a6d-1b50-4191-95d9-2fb8b1d2022a@github.com>

On Sun, 21 May 2023 09:19:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to improve the accessibility of the thread dump files that are generated by the `jcmd Thread.dump_to_file` command configured in the failure handler configurations? This addresses https://bugs.openjdk.org/browse/JDK-8308475. 
> 
> The changes in this PR include:
>  - Enhancement to `GatherProcessInfoTimeoutHandler` to allow configuring a `successArtifacts` action parameter which can be used to generate links to files that are generated by the failure handler commands.
>  - Introduction of a `%iterCount` token to allow ability to refer to the current iteration when the command is repeated
>  - The `jcmd Thread.dump_to_file` is now configured to create the thread dumps in `json` format. Additionally, it has now been configured to create the thread dumps 6 times, just like the `jstack` command.
> 
> Detailed explanation of the `successArtifacts` parameter and the `%iterCount` token is provided in the JBS comment here https://bugs.openjdk.org/browse/JDK-8308475?focusedCommentId=14583072&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14583072
> 
> Tests have been run locally with this change and tier1, tier2 and tier3 tests on CI system to verify this change works and doesn't cause regression.

@lmesnik Do you have cycles to look at this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14071#issuecomment-1560501691

From alanb at openjdk.org  Wed May 24 06:10:59 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 May 2023 06:10:59 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out [v3]
In-Reply-To: <HMsaRRf7tKO1p37PKuXAIdtgG9g3MiuYCWp6I_emU_Q=.cc5cb35a-f0ec-468c-9220-de31757c0855@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
 <HMsaRRf7tKO1p37PKuXAIdtgG9g3MiuYCWp6I_emU_Q=.cc5cb35a-f0ec-468c-9220-de31757c0855@github.com>
Message-ID: <jMO4C9umQIMb7vsr4bbEOFNwI3KHMrrBmV5F_3vlLlA=.a920b489-df8b-4705-8373-7263e2829c1a@github.com>

On Tue, 23 May 2023 09:02:27 GMT, Viktor Klang <duke at openjdk.org> wrote:

>> Doubling the max heap size since not all GCs might have compressed OOPs, so this change should make this test more robust.
>> 
>> Cleared with @DougLea
>
> Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Removing OOMEInAQS from zgc problem list
>  - JDK-8298066: Increasing max heap size for OOMEinAQS since not all GCs might have compressed oops

The bot isn't happy because JDK-8298066 is listed in both ProblemList-zgc.txt and ProblemList-generational-zgc.txt, it will need to be removed from both or else a separate issue if the increased heap size doesn't work for both GCs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14082#issuecomment-1560507399

From alanb at openjdk.org  Wed May 24 06:45:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 May 2023 06:45:56 GMT
Subject: RFR: 8308108: Support Unicode extension for collation settings
 [v5]
In-Reply-To: <EodPecDgFYPgwrX60SZVYwbAk5uflaH4yZmEXVpBCQ4=.109c0fa1-06a1-405b-88fb-d889b3258309@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <EodPecDgFYPgwrX60SZVYwbAk5uflaH4yZmEXVpBCQ4=.109c0fa1-06a1-405b-88fb-d889b3258309@github.com>
Message-ID: <hVkdpipH9tNKxbPjz7kmJNAUI5c9EeXll9mTHHGlSUg=.70f33703-342b-4a0f-8ecb-aa06cd3c1fd0@github.com>

On Mon, 22 May 2023 17:59:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further clarifying the method description

Thanks for persisting with this to get the wording clear, the latest version looks good.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14040#pullrequestreview-1441043457

From duke at openjdk.org  Wed May 24 08:04:12 2023
From: duke at openjdk.org (Naoki Kishida)
Date: Wed, 24 May 2023 08:04:12 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v17]
In-Reply-To: <tnsWpX02tby0A4lKZyk4PDOitc8UoiLqoYqGTfwRRrQ=.cfc01697-83ef-4ba3-9441-4766403d4c03@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <tnsWpX02tby0A4lKZyk4PDOitc8UoiLqoYqGTfwRRrQ=.cfc01697-83ef-4ba3-9441-4766403d4c03@github.com>
Message-ID: <XEicoJ7OAd0ACesTx7abd4s9AJd8Dw8_mBYVnVuTjOM=.cd4fdd9f-5802-4317-bf45-c2cc685cb4b8@github.com>

On Tue, 23 May 2023 20:04:45 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - Fix missing constructor error messages and handle inner class launching
>  - Merge branch 'master' into 8306112
>  - Issue warning if traditional main not used.
>  - Give subclass priority
>  - Merge branch 'master' into 8306112
>  - Requested Changes #2
>  - Update VirtualParser.java
>  - Merge branch 'master' into 8306112
>  - Refactor source code launcher
>  - Typo
>  - ... and 23 more: https://git.openjdk.org/jdk/compare/bddf4838...b55f82f8

Can we use enum?


public class Main{
  enum Foo {A, B}
  void main() {
    System.out.println(Foo.A);
  }
}

? OK


enum Foo {A, B}
void main() {
  System.out.println(Foo.A);
}

?error(enumtest.java is the filename)

enumtest.java:1: Error : package enumtest does not exist
  enum Foo {A, B}
  ^

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13689#issuecomment-1560631740

From duke at openjdk.org  Wed May 24 08:37:03 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 24 May 2023 08:37:03 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out [v4]
In-Reply-To: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
Message-ID: <bqG9hcu4kPH-RaAcWDNuNW5DXo40z-ivF4f1PWlQTDw=.368bbbd4-0fd5-41ef-bfbe-9c0f05c46261@github.com>

> Doubling the max heap size since not all GCs might have compressed OOPs, so this change should make this test more robust.
> 
> Cleared with @DougLea

Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Removing 8298066 from ProblemList-generational-zgc.txt
 - Removing OOMEInAQS from zgc problem list
 - JDK-8298066: Increasing max heap size for OOMEinAQS since not all GCs might have compressed oops

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14082/files
  - new: https://git.openjdk.org/jdk/pull/14082/files/3bfa87fc..02a063c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14082&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14082&range=02-03

  Stats: 5534 lines in 114 files changed: 3714 ins; 1264 del; 556 mod
  Patch: https://git.openjdk.org/jdk/pull/14082.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14082/head:pull/14082

PR: https://git.openjdk.org/jdk/pull/14082

From duke at openjdk.org  Wed May 24 08:37:08 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 24 May 2023 08:37:08 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out [v3]
In-Reply-To: <jMO4C9umQIMb7vsr4bbEOFNwI3KHMrrBmV5F_3vlLlA=.a920b489-df8b-4705-8373-7263e2829c1a@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
 <HMsaRRf7tKO1p37PKuXAIdtgG9g3MiuYCWp6I_emU_Q=.cc5cb35a-f0ec-468c-9220-de31757c0855@github.com>
 <jMO4C9umQIMb7vsr4bbEOFNwI3KHMrrBmV5F_3vlLlA=.a920b489-df8b-4705-8373-7263e2829c1a@github.com>
Message-ID: <RN4BPdFuaa7w5BUi-b-yQq4Zmy0LbFwt7gXtVa3rvFM=.7dd8cd34-bec4-4084-9093-3096f4d8214d@github.com>

On Wed, 24 May 2023 06:07:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Removing OOMEInAQS from zgc problem list
>>  - JDK-8298066: Increasing max heap size for OOMEinAQS since not all GCs might have compressed oops
>
> The bot isn't happy because JDK-8298066 is listed in both ProblemList-zgc.txt and ProblemList-generational-zgc.txt, it will need to be removed from both or else a separate issue if the increased heap size doesn't work for both GCs.

@AlanBateman Sounds good, thanks for confirming. I've updated both the ProblemLists, but it needed yet another rebase, so yet another forced push.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14082#issuecomment-1560678749

From mdoerr at openjdk.org  Wed May 24 08:42:23 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 24 May 2023 08:42:23 GMT
Subject: Integrated: 8303040: linux PPC64le: Implementation of Foreign Function
 & Memory API (Preview)
In-Reply-To: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
References: <Yuxy6FrsDAN79ya8w8UIkvytGr25zGllDPtPJ1QbGwc=.182664b2-6d8c-497e-a4ae-95e0ad007cf9@github.com>
Message-ID: <lBmzhm58AD_nxXugHJNbJjzxO0cFyobVzRZTF_0T3LI=.4486b85a-8a81-4e4a-912e-7f1728fd3d4e@github.com>

On Wed, 22 Feb 2023 05:31:46 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Implementation of "Foreign Function & Memory API" for linux on Power (Little Endian) according to "Power Architecture 64-Bit ELF V2 ABI Specification".
> 
> This PR does not include code for VaList support because it's supposed to get removed by [JDK-8299736](https://bugs.openjdk.org/browse/JDK-8299736). I've kept the related tests disabled for this platform and throw an exception instead. Note that the ABI doesn't precisely specify variable argument lists. Instead, it refers to `<stdarg.h>` (2.2.4 Variable Argument Lists).
> 
> Big Endian support is implemented to some extend, but not complete. E.g. structs with size not divisible by 8 are not passed correctly (see `useABIv2` in CallArranger.java). Big Endian is excluded by selecting `ARCH.equals("ppc64le")` (CABI.java) only.
> 
> There's another limitation: This PR only accepts structures with size divisible by 4. (An `IllegalArgumentException` gets thrown otherwise.) I think arbitrary sizes are not usable on other platforms, either, because `SharedUtils.primitiveCarrierForSize` only accepts powers of 2. Update: Resolved after merging of [JDK-8303017](https://bugs.openjdk.org/browse/JDK-8303017)
> 
> The ABI has some tricky corner cases related to HFA (Homogeneous Float Aggregate). The same argument may need to get passed in both, a FP reg and a GP reg or stack slot (see "no partial DW rule"). This cases are not covered by the existing tests.
> 
> I had to make changes to shared code and code for other platforms:
> 1. Pass type information when creating `VMStorage` objects from `VMReg`. This is needed for the following reasons:
> - PPC64 ABI requires integer types to get extended to 64 bit (also see CCallingConventionRequiresIntsAsLongs in existing hotspot code). We need to know the type or at least the bit width for that.
> - Floating point load / store instructions need the correct width to select between the correct IEEE 754 formats. The register representation in single FP registers is always IEEE 754 double precision on PPC64.
> - Big Endian also needs usage of the precise size. Storing 8 Bytes and loading 4 Bytes yields different values than on Little Endian!
> 2. It happens that a `NativeMemorySegmentImpl` is used as a raw pointer (with byteSize() == 0) while running TestUpcallScope. Hence, existing size checks don't work (see MemorySegment.java). As a workaround, I'm just skipping the check in this particular case. Please check if this makes sense or if there's a better fix (possibly as separate RFE). Update: T...

This pull request has now been integrated.

Changeset: 20f15352
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20f15352a3014042aa69f7cbfb67de0f7fdddb40
Stats:     2485 lines in 27 files changed: 2438 ins; 0 del; 47 mod

8303040: linux PPC64le: Implementation of Foreign Function & Memory API (Preview)

Reviewed-by: jvernee, rrich

-------------

PR: https://git.openjdk.org/jdk/pull/12708

From mcimadamore at openjdk.org  Wed May 24 09:22:08 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 May 2023 09:22:08 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v5]
In-Reply-To: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
Message-ID: <ykcFwiqBUh0Zhz9R52XDkiWEFRZYTqBwZ4WiB4EIFdQ=.7fb9c7a9-7b59-477d-b802-4a2f9805b3b6@github.com>

> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
> 
> 
> jshell> import java.lang.foreign.*;
> 
> jshell> Linker.nativeLinker().canonicalLayouts()
> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
> 
> 
> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Drop "unsigned short"
  Beef up javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14037/files
  - new: https://git.openjdk.org/jdk/pull/14037/files/dbc8049a..708f987d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14037&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14037&range=03-04

  Stats: 35 lines in 5 files changed: 6 ins; 13 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/14037.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14037/head:pull/14037

PR: https://git.openjdk.org/jdk/pull/14037

From mcimadamore at openjdk.org  Wed May 24 09:22:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 May 2023 09:22:10 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v4]
In-Reply-To: <mNvyH9yRqp0OZJdx10SwbRBgyqTq_QdXGB-qHeTQ8B8=.c3bc2710-e51a-4855-a18e-0e3cbee33281@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <mNvyH9yRqp0OZJdx10SwbRBgyqTq_QdXGB-qHeTQ8B8=.c3bc2710-e51a-4855-a18e-0e3cbee33281@github.com>
Message-ID: <_-n4m4ORhNW9TvHEIxPyTkJwtI-Zh-uaROUYb4Vpyak=.8ba90075-88c8-48e1-b405-7981061df5bf@github.com>

On Mon, 22 May 2023 09:34:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address further review comments

Updated javadoc and specdiffs (v3):
javadoc: https://cr.openjdk.org/~mcimadamore/jdk/8308293/v3/javadoc/java.base/java/lang/foreign/Linker.html
specdiff: https://cr.openjdk.org/~mcimadamore/jdk/8308293/v3/specdiff_out/overview-summary.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1560749402

From mdoerr at openjdk.org  Wed May 24 09:22:58 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 24 May 2023 09:22:58 GMT
Subject: RFR: 8308761: New test TestHFA needs adaptation for JDK-8308276
Message-ID: <WMQnNo99kheqaDnv4TBIKO3K4owidlI7rXC3Zp-Imbg=.d78e0709-b378-452d-99e1-a3c5b2c990a2@github.com>

Please review this trivial adaptation for JDK-8308276.

-------------

Commit messages:
 - 8308761: New test TestHFA needs adaptation for JDK-8308276

Changes: https://git.openjdk.org/jdk/pull/14116/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14116&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308761
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14116.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14116/head:pull/14116

PR: https://git.openjdk.org/jdk/pull/14116

From chagedorn at openjdk.org  Wed May 24 09:35:04 2023
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 24 May 2023 09:35:04 GMT
Subject: RFR: JDK-8282797: CompileCommand parsing errors should exit VM
In-Reply-To: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
References: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
Message-ID: <hOT5XejT7Jv8-DQDUg26-z6MzQMyAZ--htr2gExjk5o=.bbc5ca6d-d382-4b93-99ee-7050f97782e9@github.com>

On Tue, 2 May 2023 11:35:54 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

> Currently, errors during compile command parsing just print an error but don't exit the VM. As a result, issues go unnoticed. 
> 
> With this PR the behavior is changed to exit the VM when an error occurs.
> 
> E.g. `java -XX:CompileCommand=compileonly,HashMap:: -version` will exit the VM after a parsing occurred.  
> 
> CompileCommand: An error occurred during parsing
> Error: Could not parse method pattern
> Line: 'compileonly,HashMap::'
> 
> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
> Use:   '-XX:CompileCommand=help' for more information and to list all option.
> 
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> 
> ### Updated Tests
> Updated all tests to now expect an error code `1` for wrong `CompileCommand`

That's a nice feature to avoid accidental compile command typos in tests!

I have some comments.

That's a nice feature to avoid accidental compile command typos in tests!

I have some comments.

src/hotspot/share/compiler/compilerOracle.cpp line 815:

> 813: bool CompilerOracle::parse_from_line(char* line) {
> 814:   if (line[0] == '\0') return true;
> 815:   if (line[0] == '#')  return true;

While at it, you could unify these.

src/hotspot/share/compiler/compilerOracle.cpp line 955:

> 953:   assert(has_command_file(), "command file must be specified");
> 954:   FILE* stream = os::fopen(cc_file(), "rt");
> 955:   if (stream == nullptr) return true;

Whilte at it, you could add braces:

Suggestion:

  if (stream == nullptr) {
    return true;
  }

src/hotspot/share/compiler/compilerOracle.cpp line 1062:

> 1060:       char* newName = NEW_RESOURCE_ARRAY( char, i + 1);
> 1061:       if (newName == nullptr)
> 1062:         return true;

Should be `false`.

You could also add braces here.

test/hotspot/jtreg/compiler/compilercontrol/share/IntrinsicCommand.java line 79:

> 77:                 md, type, intrinsic_ids);
> 78: 
> 79:         System.out.println("XXXXXXXXXXXXXXXX compileCommand.isValid " + compileCommand.isValid());

Leftover from debugging?

test/hotspot/jtreg/compiler/compilercontrol/share/scenario/Scenario.java line 127:

> 125:             Asserts.assertNE(mainOutput.getExitValue(), 0, "VM should exit with "
> 126:                     + "error for incorrect directives");
> 127:             //if (isJcmdValid) {

Intentionally commented out? Then it can be removed.

test/hotspot/jtreg/compiler/compilercontrol/share/scenario/Scenario.java line 129:

> 127:             //if (isJcmdValid) {
> 128:             boolean parse_error_found = false;
> 129:             for(OutputAnalyzer out : outputList) {

Suggestion:

            for (OutputAnalyzer out : outputList) {

-------------

Changes requested by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13753#pullrequestreview-1441216621
PR Review: https://git.openjdk.org/jdk/pull/13753#pullrequestreview-1441377274
PR Review Comment: https://git.openjdk.org/jdk/pull/13753#discussion_r1203672003
PR Review Comment: https://git.openjdk.org/jdk/pull/13753#discussion_r1203673827
PR Review Comment: https://git.openjdk.org/jdk/pull/13753#discussion_r1203676771
PR Review Comment: https://git.openjdk.org/jdk/pull/13753#discussion_r1203786219
PR Review Comment: https://git.openjdk.org/jdk/pull/13753#discussion_r1203788061
PR Review Comment: https://git.openjdk.org/jdk/pull/13753#discussion_r1203788762

From thartmann at openjdk.org  Wed May 24 09:35:07 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Wed, 24 May 2023 09:35:07 GMT
Subject: RFR: JDK-8282797: CompileCommand parsing errors should exit VM
In-Reply-To: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
References: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
Message-ID: <hqNR-TgqrKibOjbs8SL0ewYO5XQ-N5DnK0_PckkIEI0=.b492d3b8-0f3e-400c-9c4c-1af358827cd7@github.com>

On Tue, 2 May 2023 11:35:54 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

> Currently, errors during compile command parsing just print an error but don't exit the VM. As a result, issues go unnoticed. 
> 
> With this PR the behavior is changed to exit the VM when an error occurs.
> 
> E.g. `java -XX:CompileCommand=compileonly,HashMap:: -version` will exit the VM after a parsing occurred.  
> 
> CompileCommand: An error occurred during parsing
> Error: Could not parse method pattern
> Line: 'compileonly,HashMap::'
> 
> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
> Use:   '-XX:CompileCommand=help' for more information and to list all option.
> 
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> 
> ### Updated Tests
> Updated all tests to now expect an error code `1` for wrong `CompileCommand`

Looks good to me otherwise.

test/hotspot/jtreg/compiler/compilercontrol/share/IntrinsicCommand.java line 79:

> 77:                 md, type, intrinsic_ids);
> 78: 
> 79:         System.out.println("XXXXXXXXXXXXXXXX compileCommand.isValid " + compileCommand.isValid());

Accidental leftover?

test/hotspot/jtreg/compiler/compilercontrol/share/scenario/Scenario.java line 127:

> 125:             Asserts.assertNE(mainOutput.getExitValue(), 0, "VM should exit with "
> 126:                     + "error for incorrect directives");
> 127:             //if (isJcmdValid) {

Should be removed.

test/hotspot/jtreg/compiler/compilercontrol/share/scenario/Scenario.java line 129:

> 127:             //if (isJcmdValid) {
> 128:             boolean parse_error_found = false;
> 129:             for(OutputAnalyzer out : outputList) {

Suggestion:

            for (OutputAnalyzer out : outputList) {

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13753#pullrequestreview-1441371827
PR Review Comment: https://git.openjdk.org/jdk/pull/13753#discussion_r1203787476
PR Review Comment: https://git.openjdk.org/jdk/pull/13753#discussion_r1203789223
PR Review Comment: https://git.openjdk.org/jdk/pull/13753#discussion_r1203790531

From mcimadamore at openjdk.org  Wed May 24 09:36:34 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 May 2023 09:36:34 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v6]
In-Reply-To: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
Message-ID: <c1et2B8bNarPWOrpKzWq-uRaxpybGbEJkwBwDd7jcro=.34594240-c8ea-4507-bb22-3bee3ee3bb99@github.com>

> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
> 
> 
> jshell> import java.lang.foreign.*;
> 
> jshell> Linker.nativeLinker().canonicalLayouts()
> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
> 
> 
> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Merge branch 'master' into linker_types
 - Drop "unsigned short"
   Beef up javadoc
 - Address further review comments
 - Address review comments
 - More javadoc tweaks
 - Tweak javadoc
 - Tweak javadoc
   Add char type
 - Initial push

-------------

Changes: https://git.openjdk.org/jdk/pull/14037/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14037&range=05
  Stats: 177 lines in 6 files changed: 121 ins; 16 del; 40 mod
  Patch: https://git.openjdk.org/jdk/pull/14037.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14037/head:pull/14037

PR: https://git.openjdk.org/jdk/pull/14037

From michaelm at openjdk.org  Wed May 24 10:14:23 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 24 May 2023 10:14:23 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v3]
In-Reply-To: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
Message-ID: <uGGlsyDavyKXLuI-Ok4tj1iDR7oJ8ZqFRzM1V8wWH7o=.74d82f35-33e4-4ada-a3b5-f90307125344@github.com>

> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
> 
> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).

Michael McMahon 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 nullStrings
 - test comment update
 - test update
 - Merge branch 'master' into nullStrings
 - exception message update
 - test update
 - remve whitespace
 - update
 - Merge branch 'master' into nullStrings
 - first impl

-------------

Changes: https://git.openjdk.org/jdk/pull/14083/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14083&range=02
  Stats: 183 lines in 9 files changed: 163 ins; 1 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/14083.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14083/head:pull/14083

PR: https://git.openjdk.org/jdk/pull/14083

From tholenstein at openjdk.org  Wed May 24 10:56:00 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Wed, 24 May 2023 10:56:00 GMT
Subject: RFR: JDK-8282797: CompileCommand parsing errors should exit VM
 [v2]
In-Reply-To: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
References: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
Message-ID: <2ycbSNwrp8qqybU5N5sWwwiAVQ_PvTNtwwQrGi83QlI=.9a6f968f-a039-456d-998c-aa5e8d0c71d0@github.com>

> Currently, errors during compile command parsing just print an error but don't exit the VM. As a result, issues go unnoticed. 
> 
> With this PR the behavior is changed to exit the VM when an error occurs.
> 
> E.g. `java -XX:CompileCommand=compileonly,HashMap:: -version` will exit the VM after a parsing occurred.  
> 
> CompileCommand: An error occurred during parsing
> Error: Could not parse method pattern
> Line: 'compileonly,HashMap::'
> 
> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
> Use:   '-XX:CompileCommand=help' for more information and to list all option.
> 
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> 
> ### Updated Tests
> Updated all tests to now expect an error code `1` for wrong `CompileCommand`

Tobias Holenstein has updated the pull request incrementally with four additional commits since the last revision:

 - Update test/hotspot/jtreg/compiler/compilercontrol/share/scenario/Scenario.java
   
   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
 - Update IntrinsicCommand.java
 - Update compilerOracle.cpp
 - Update src/hotspot/share/compiler/compilerOracle.cpp
   
   Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13753/files
  - new: https://git.openjdk.org/jdk/pull/13753/files/6de71f77..8aeef24d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13753&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13753&range=00-01

  Stats: 9 lines in 3 files changed: 3 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13753/head:pull/13753

PR: https://git.openjdk.org/jdk/pull/13753

From tholenstein at openjdk.org  Wed May 24 10:56:03 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Wed, 24 May 2023 10:56:03 GMT
Subject: RFR: JDK-8282797: CompileCommand parsing errors should exit VM
 [v2]
In-Reply-To: <hOT5XejT7Jv8-DQDUg26-z6MzQMyAZ--htr2gExjk5o=.bbc5ca6d-d382-4b93-99ee-7050f97782e9@github.com>
References: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
 <hOT5XejT7Jv8-DQDUg26-z6MzQMyAZ--htr2gExjk5o=.bbc5ca6d-d382-4b93-99ee-7050f97782e9@github.com>
Message-ID: <tNe9M7_LOylrA9VQfx80wxjM_C8XjwBG_dUD3rqRGkA=.dd238a8e-452e-4f31-af54-5f9fb5ae9ee7@github.com>

On Wed, 24 May 2023 09:29:10 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Tobias Holenstein has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Update test/hotspot/jtreg/compiler/compilercontrol/share/scenario/Scenario.java
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update IntrinsicCommand.java
>>  - Update compilerOracle.cpp
>>  - Update src/hotspot/share/compiler/compilerOracle.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>
> test/hotspot/jtreg/compiler/compilercontrol/share/IntrinsicCommand.java line 79:
> 
>> 77:                 md, type, intrinsic_ids);
>> 78: 
>> 79:         System.out.println("XXXXXXXXXXXXXXXX compileCommand.isValid " + compileCommand.isValid());
> 
> Leftover from debugging?

right. I removed it now

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13753#discussion_r1203886333

From tholenstein at openjdk.org  Wed May 24 10:56:06 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Wed, 24 May 2023 10:56:06 GMT
Subject: RFR: JDK-8282797: CompileCommand parsing errors should exit VM
 [v2]
In-Reply-To: <hqNR-TgqrKibOjbs8SL0ewYO5XQ-N5DnK0_PckkIEI0=.b492d3b8-0f3e-400c-9c4c-1af358827cd7@github.com>
References: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
 <hqNR-TgqrKibOjbs8SL0ewYO5XQ-N5DnK0_PckkIEI0=.b492d3b8-0f3e-400c-9c4c-1af358827cd7@github.com>
Message-ID: <z0-MJG9TYamkrPCNROGrfUJTviH9OSAhizNLHvMnfZQ=.bacf6bcd-205c-4758-9823-92fd4f1f1bb6@github.com>

On Wed, 24 May 2023 09:29:53 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Tobias Holenstein has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Update test/hotspot/jtreg/compiler/compilercontrol/share/scenario/Scenario.java
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update IntrinsicCommand.java
>>  - Update compilerOracle.cpp
>>  - Update src/hotspot/share/compiler/compilerOracle.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>
> test/hotspot/jtreg/compiler/compilercontrol/share/IntrinsicCommand.java line 79:
> 
>> 77:                 md, type, intrinsic_ids);
>> 78: 
>> 79:         System.out.println("XXXXXXXXXXXXXXXX compileCommand.isValid " + compileCommand.isValid());
> 
> Accidental leftover?

yes. I removed it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13753#discussion_r1203888283

From tholenstein at openjdk.org  Wed May 24 11:05:01 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Wed, 24 May 2023 11:05:01 GMT
Subject: RFR: JDK-8282797: CompileCommand parsing errors should exit VM
 [v3]
In-Reply-To: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
References: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
Message-ID: <4ZMRDekcK4Yc3dS9rHvpqj9NcU6dH30aR7u2wtrc_Ac=.4f6c76cd-636a-445f-99e3-973e6fc51360@github.com>

> Currently, errors during compile command parsing just print an error but don't exit the VM. As a result, issues go unnoticed. 
> 
> With this PR the behavior is changed to exit the VM when an error occurs.
> 
> E.g. `java -XX:CompileCommand=compileonly,HashMap:: -version` will exit the VM after a parsing occurred.  
> 
> CompileCommand: An error occurred during parsing
> Error: Could not parse method pattern
> Line: 'compileonly,HashMap::'
> 
> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
> Use:   '-XX:CompileCommand=help' for more information and to list all option.
> 
> Error: Could not create the Java Virtual Machine.
> Error: A fatal exception has occurred. Program will exit.
> 
> 
> ### Updated Tests
> Updated all tests to now expect an error code `1` for wrong `CompileCommand`

Tobias Holenstein has updated the pull request incrementally with two additional commits since the last revision:

 - Update Scenario.java
 - Update compilerOracle.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13753/files
  - new: https://git.openjdk.org/jdk/pull/13753/files/8aeef24d..bc36e400

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13753&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13753&range=01-02

  Stats: 4 lines in 2 files changed: 1 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13753.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13753/head:pull/13753

PR: https://git.openjdk.org/jdk/pull/13753

From tholenstein at openjdk.org  Wed May 24 11:05:04 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Wed, 24 May 2023 11:05:04 GMT
Subject: RFR: JDK-8282797: CompileCommand parsing errors should exit VM
 [v3]
In-Reply-To: <hOT5XejT7Jv8-DQDUg26-z6MzQMyAZ--htr2gExjk5o=.bbc5ca6d-d382-4b93-99ee-7050f97782e9@github.com>
References: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
 <hOT5XejT7Jv8-DQDUg26-z6MzQMyAZ--htr2gExjk5o=.bbc5ca6d-d382-4b93-99ee-7050f97782e9@github.com>
Message-ID: <WQAOCJZylt1YF1F7oAcnqBS3cNXZMPr3TbkN4p2B4ps=.a420a1d0-7132-4b33-9a3c-e94f8cb59d70@github.com>

On Wed, 24 May 2023 08:20:32 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Tobias Holenstein has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update Scenario.java
>>  - Update compilerOracle.cpp
>
> src/hotspot/share/compiler/compilerOracle.cpp line 1062:
> 
>> 1060:       char* newName = NEW_RESOURCE_ARRAY( char, i + 1);
>> 1061:       if (newName == nullptr)
>> 1062:         return true;
> 
> Should be `false`.
> 
> You could also add braces here.

right. I changed it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13753#discussion_r1203898368

From tholenstein at openjdk.org  Wed May 24 11:05:07 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Wed, 24 May 2023 11:05:07 GMT
Subject: RFR: JDK-8282797: CompileCommand parsing errors should exit VM
 [v3]
In-Reply-To: <hqNR-TgqrKibOjbs8SL0ewYO5XQ-N5DnK0_PckkIEI0=.b492d3b8-0f3e-400c-9c4c-1af358827cd7@github.com>
References: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
 <hqNR-TgqrKibOjbs8SL0ewYO5XQ-N5DnK0_PckkIEI0=.b492d3b8-0f3e-400c-9c4c-1af358827cd7@github.com>
Message-ID: <gaURntFUr_ARetpYO28pM1uIF7m3k8cdho36P8gmLHA=.035548c0-f05f-49d7-b4a7-963ce2785efd@github.com>

On Wed, 24 May 2023 09:30:58 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

>> Tobias Holenstein has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update Scenario.java
>>  - Update compilerOracle.cpp
>
> test/hotspot/jtreg/compiler/compilercontrol/share/scenario/Scenario.java line 127:
> 
>> 125:             Asserts.assertNE(mainOutput.getExitValue(), 0, "VM should exit with "
>> 126:                     + "error for incorrect directives");
>> 127:             //if (isJcmdValid) {
> 
> Should be removed.

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13753#discussion_r1203901120

From asotona at openjdk.org  Wed May 24 11:20:58 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 24 May 2023 11:20:58 GMT
Subject: RFR: 8308549: Classfile API should fail to generate over-sized
 Code attribute
In-Reply-To: <u-iJuFVDgm7hlBCP1zWAdAtmI7icAIdBH-XZV8L2dno=.0acdf4d8-adae-46f8-9b48-8c91a3c19b16@github.com>
References: <FMfhhGe4XrEG4Brj1GZS69ovfeNMSAEeLwlMq05SzwA=.7014deec-41a2-44cc-b4bd-51f3f71f291b@github.com>
 <u-iJuFVDgm7hlBCP1zWAdAtmI7icAIdBH-XZV8L2dno=.0acdf4d8-adae-46f8-9b48-8c91a3c19b16@github.com>
Message-ID: <MIHud6eoYT14kFyOu5BC-pKIaETVi4N3e1hUkscOEhM=.6c01b9ee-0af5-4946-9904-25b75fe3c0ed@github.com>

On Tue, 23 May 2023 15:13:04 GMT, Chen Liang <liach at openjdk.org> wrote:

> On a side note, does Classfile API reject methods with too many slots (locals) (MethodTypeDesc can represent parameter lists with over 255 slots) or stack (operand)?

Classfile API does not perform any extra verifications of MethodTypeDesc and 255 slots is limit for method parameters. Code attribute maxLocals and maxStack have limit of 65535, however it is not checked yet.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14100#issuecomment-1560933070

From tholenstein at openjdk.org  Wed May 24 11:23:01 2023
From: tholenstein at openjdk.org (Tobias Holenstein)
Date: Wed, 24 May 2023 11:23:01 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly [v2]
In-Reply-To: <2DEZv0Dqrai9gFHdJ4RN5SUno7CZzhMVXMEDxr7WB1c=.e260673d-db9d-42f2-8560-496e7c1a37b5@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
 <2DEZv0Dqrai9gFHdJ4RN5SUno7CZzhMVXMEDxr7WB1c=.e260673d-db9d-42f2-8560-496e7c1a37b5@github.com>
Message-ID: <zvFpo2iFSkE_2KkqKVRLQfOPKxnFZDlIgQz3jFOrrTM=.eff5a211-1c91-4f92-95be-e6f98b621e61@github.com>

On Tue, 23 May 2023 07:55:35 GMT, Christian Hagedorn <chagedorn at openjdk.org> wrote:

>> Tobias Holenstein has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update Test8211698.java
>>  - Update src/hotspot/share/compiler/compilerOracle.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>>  - Update src/hotspot/share/compiler/compilerOracle.cpp
>>    
>>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>
> src/hotspot/share/compiler/compilerOracle.cpp line 1017:
> 
>> 1015:   if (line[0] == '\0') return;
>> 1016:   ResourceMark rm;
>> 1017:   char error_buf[1024] = {0};
> 
> Wouldn't it be sufficient to only initialize the first character with `\0`?

Probably, but all other error buffer also init with zero. I will leave it for now. Can update them all together in the future

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13802#discussion_r1203930148

From jlaskey at openjdk.org  Wed May 24 12:00:11 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 24 May 2023 12:00:11 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v17]
In-Reply-To: <tnsWpX02tby0A4lKZyk4PDOitc8UoiLqoYqGTfwRRrQ=.cfc01697-83ef-4ba3-9441-4766403d4c03@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <tnsWpX02tby0A4lKZyk4PDOitc8UoiLqoYqGTfwRRrQ=.cfc01697-83ef-4ba3-9441-4766403d4c03@github.com>
Message-ID: <S4B3WpuOGBcDRydBsbfDqMymBr7RLc5DsZWhAKGhST4=.f5fe57c9-5884-4887-803e-0052662ffb7e@github.com>

On Tue, 23 May 2023 20:04:45 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
> 
>  - Fix missing constructor error messages and handle inner class launching
>  - Merge branch 'master' into 8306112
>  - Issue warning if traditional main not used.
>  - Give subclass priority
>  - Merge branch 'master' into 8306112
>  - Requested Changes #2
>  - Update VirtualParser.java
>  - Merge branch 'master' into 8306112
>  - Refactor source code launcher
>  - Typo
>  - ... and 23 more: https://git.openjdk.org/jdk/compare/bddf4838...b55f82f8

Good catch - will look into it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13689#issuecomment-1560984490

From jpai at openjdk.org  Wed May 24 12:06:58 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 12:06:58 GMT
Subject: RFR: 8308549: Classfile API should fail to generate over-sized
 Code attribute
In-Reply-To: <FMfhhGe4XrEG4Brj1GZS69ovfeNMSAEeLwlMq05SzwA=.7014deec-41a2-44cc-b4bd-51f3f71f291b@github.com>
References: <FMfhhGe4XrEG4Brj1GZS69ovfeNMSAEeLwlMq05SzwA=.7014deec-41a2-44cc-b4bd-51f3f71f291b@github.com>
Message-ID: <syz3XMWhoaWib849NAnApB1e-DIxE8ZotgoFFKcCiZ4=.6d622d25-0e9a-40e4-8ab9-4f881149cd77@github.com>

On Tue, 23 May 2023 12:54:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile API allowed to generate Code attribute exceeding the 65k limit. No exception has been thrown during class generation and the class failed verification later during class loading.
> This patch adds Code size limit check throwing IllegalArgumentException.
> The patch also adds similar check for constant pool size limit to avoid generation class file with corrupted  constant pool.
> Two new tests are added to check response on oversized Code attribute and constant pool.
> `VerifierImpl` is extended to check Code attribute size as a part of class verification process.
> 
> Please review.
> 
> Thanks,
> Adam

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 314:

> 312: 
> 313:                 int codeLength = curPc();
> 314:                 if (codeLength >= 65536) {

Hello Adam, looking at the JVM spec, section 4.7.3 https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.7.3, it states:

> The value of code_length must be greater than zero (as the code array must not be empty) and less than 65536. 

Do you think this check then should also verify (and throw) if the codeLength <= 0?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14100#discussion_r1203993221

From mcimadamore at openjdk.org  Wed May 24 12:14:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 May 2023 12:14:55 GMT
Subject: RFR: 8308761: New test TestHFA needs adaptation for JDK-8308276
In-Reply-To: <WMQnNo99kheqaDnv4TBIKO3K4owidlI7rXC3Zp-Imbg=.d78e0709-b378-452d-99e1-a3c5b2c990a2@github.com>
References: <WMQnNo99kheqaDnv4TBIKO3K4owidlI7rXC3Zp-Imbg=.d78e0709-b378-452d-99e1-a3c5b2c990a2@github.com>
Message-ID: <uDaU5OZ1Kyu3qoxcA4RomN-FqohkNoxfl4HpLvlD9sU=.7b9f2e12-cc38-42ce-abb1-488f4bbed489@github.com>

On Wed, 24 May 2023 09:16:46 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Please review this trivial adaptation for JDK-8308276.

Looks good - I apologize for having missed it.

test/jdk/java/foreign/TestHFA.java line 53:

> 51:     final static SymbolLookup lookup = SymbolLookup.loaderLookup();
> 52: 
> 53:     static final OfFloat FLOAT = JAVA_FLOAT.withByteAlignment(4);

Is this even required - e.g. the alignment of Java float is 4 bytes...

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14116#pullrequestreview-1441682588
PR Review Comment: https://git.openjdk.org/jdk/pull/14116#discussion_r1204006404

From jpai at openjdk.org  Wed May 24 12:25:07 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 12:25:07 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v17]
In-Reply-To: <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
Message-ID: <UW05hA0Uo1BHgoEPo983IiOAKuR0cqJOQUUstWcydPg=.5ac15da7-3fec-4b98-8dd0-66088f2b89ff@github.com>

On Wed, 29 Mar 2023 01:40:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup test - rename method and update code comment as suggested by Alan
>  - Rename KNOWN_ENDIANNESS to PLATFORM_PROPERTIES

> See draft PR #14063 for a proposal

Hello Roger, I had a look at that draft PR.

The introduction of `Architecture.byteOrder()` and `Architecture.lookupByName(archName)` in that PR, I believe is going to help us here. I could then read the `ModuleTarget` attribute and use the `Architecture.lookupByName()` to get hold of the target architecture and thus its endianness through `Architecture.byteOrder()`. That would then mean we no longer need the `target.properties` file that was previously proposed in this PR.

I haven't had a chance to refresh this PR to resolve the merge conflicts. I hope to get to it soon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1561023227

From duke at openjdk.org  Wed May 24 12:45:14 2023
From: duke at openjdk.org (Viktor Klang)
Date: Wed, 24 May 2023 12:45:14 GMT
Subject: Integrated: JDK-8298066:
 java/util/concurrent/locks/Lock/OOMEInAQS.java timed out
In-Reply-To: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
Message-ID: <WKRSUpPkHz3QfqJwaduOuUPj1L_zRNtUAp-vgaTXcxc=.ff27b221-b4f9-4678-b522-a20dfc1114cf@github.com>

On Mon, 22 May 2023 13:12:02 GMT, Viktor Klang <duke at openjdk.org> wrote:

> Doubling the max heap size since not all GCs might have compressed OOPs, so this change should make this test more robust.
> 
> Cleared with @DougLea

This pull request has now been integrated.

Changeset: 544978cb
Author:    Viktor Klang <viktor.klang at oracle.com>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/544978cb76d4a4f7cd3f4e5dc0dac3f6e4a52be1
Stats:     3 lines in 3 files changed: 0 ins; 2 del; 1 mod

8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java timed out

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14082

From mdoerr at openjdk.org  Wed May 24 12:51:00 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 24 May 2023 12:51:00 GMT
Subject: RFR: 8308761: New test TestHFA needs adaptation for JDK-8308276
In-Reply-To: <uDaU5OZ1Kyu3qoxcA4RomN-FqohkNoxfl4HpLvlD9sU=.7b9f2e12-cc38-42ce-abb1-488f4bbed489@github.com>
References: <WMQnNo99kheqaDnv4TBIKO3K4owidlI7rXC3Zp-Imbg=.d78e0709-b378-452d-99e1-a3c5b2c990a2@github.com>
 <uDaU5OZ1Kyu3qoxcA4RomN-FqohkNoxfl4HpLvlD9sU=.7b9f2e12-cc38-42ce-abb1-488f4bbed489@github.com>
Message-ID: <z6l0NSkQxDffuCFDrHaGzidKtuQNvqUQvbMdVqjST2E=.e331d707-9c1c-4fd3-a3b0-dbe2474859ee@github.com>

On Wed, 24 May 2023 12:12:25 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Please review this trivial adaptation for JDK-8308276.
>
> test/jdk/java/foreign/TestHFA.java line 53:
> 
>> 51:     final static SymbolLookup lookup = SymbolLookup.loaderLookup();
>> 52: 
>> 53:     static final OfFloat FLOAT = JAVA_FLOAT.withByteAlignment(4);
> 
> Is this even required - e.g. the alignment of Java float is 4 bytes...

It's probably not required. It was derived from a jextract generated file.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14116#discussion_r1204069281

From mdoerr at openjdk.org  Wed May 24 12:59:56 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 24 May 2023 12:59:56 GMT
Subject: RFR: 8308761: New test TestHFA needs adaptation for JDK-8308276
In-Reply-To: <z6l0NSkQxDffuCFDrHaGzidKtuQNvqUQvbMdVqjST2E=.e331d707-9c1c-4fd3-a3b0-dbe2474859ee@github.com>
References: <WMQnNo99kheqaDnv4TBIKO3K4owidlI7rXC3Zp-Imbg=.d78e0709-b378-452d-99e1-a3c5b2c990a2@github.com>
 <uDaU5OZ1Kyu3qoxcA4RomN-FqohkNoxfl4HpLvlD9sU=.7b9f2e12-cc38-42ce-abb1-488f4bbed489@github.com>
 <z6l0NSkQxDffuCFDrHaGzidKtuQNvqUQvbMdVqjST2E=.e331d707-9c1c-4fd3-a3b0-dbe2474859ee@github.com>
Message-ID: <O_o670dMGEEac1EsWoP6gxEImRf-j8EqDS6WMleRYN0=.d65bd8b3-92b9-4448-bc94-de9ad18bc191@github.com>

On Wed, 24 May 2023 12:48:00 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> test/jdk/java/foreign/TestHFA.java line 53:
>> 
>>> 51:     final static SymbolLookup lookup = SymbolLookup.loaderLookup();
>>> 52: 
>>> 53:     static final OfFloat FLOAT = JAVA_FLOAT.withByteAlignment(4);
>> 
>> Is this even required - e.g. the alignment of Java float is 4 bytes...
>
> It's probably not required. It was derived from a jextract generated file.

Do you prefer removing it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14116#discussion_r1204083863

From mbaesken at openjdk.org  Wed May 24 13:07:56 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 24 May 2023 13:07:56 GMT
Subject: RFR: 8308761: New test TestHFA needs adaptation for JDK-8308276
In-Reply-To: <WMQnNo99kheqaDnv4TBIKO3K4owidlI7rXC3Zp-Imbg=.d78e0709-b378-452d-99e1-a3c5b2c990a2@github.com>
References: <WMQnNo99kheqaDnv4TBIKO3K4owidlI7rXC3Zp-Imbg=.d78e0709-b378-452d-99e1-a3c5b2c990a2@github.com>
Message-ID: <W2o_UkM1z9M9CRwnUYBcGfHFyjVxn7oI6HJ6mcXPhGo=.476c9832-1cd2-4866-90ca-eb35c1b01023@github.com>

On Wed, 24 May 2023 09:16:46 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Please review this trivial adaptation for JDK-8308276.

Marked as reviewed by mbaesken (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14116#pullrequestreview-1441800497

From asotona at openjdk.org  Wed May 24 13:00:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 24 May 2023 13:00:59 GMT
Subject: RFR: 8308549: Classfile API should fail to generate over-sized
 Code attribute
In-Reply-To: <syz3XMWhoaWib849NAnApB1e-DIxE8ZotgoFFKcCiZ4=.6d622d25-0e9a-40e4-8ab9-4f881149cd77@github.com>
References: <FMfhhGe4XrEG4Brj1GZS69ovfeNMSAEeLwlMq05SzwA=.7014deec-41a2-44cc-b4bd-51f3f71f291b@github.com>
 <syz3XMWhoaWib849NAnApB1e-DIxE8ZotgoFFKcCiZ4=.6d622d25-0e9a-40e4-8ab9-4f881149cd77@github.com>
Message-ID: <FxnT8SNnmG1tPlJvgOpGr8sN1msl60RfhF0nwXKTfsk=.3e9dab70-4941-446a-afeb-f5f060953b6f@github.com>

On Wed, 24 May 2023 12:04:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Classfile API allowed to generate Code attribute exceeding the 65k limit. No exception has been thrown during class generation and the class failed verification later during class loading.
>> This patch adds Code size limit check throwing IllegalArgumentException.
>> The patch also adds similar check for constant pool size limit to avoid generation class file with corrupted  constant pool.
>> Two new tests are added to check response on oversized Code attribute and constant pool.
>> `VerifierImpl` is extended to check Code attribute size as a part of class verification process.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 314:
> 
>> 312: 
>> 313:                 int codeLength = curPc();
>> 314:                 if (codeLength >= 65536) {
> 
> Hello Adam, looking at the JVM spec, section 4.7.3 https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.7.3, it states:
> 
>> The value of code_length must be greater than zero (as the code array must not be empty) and less than 65536. 
> 
> Do you think this check then should also verify (and throw) if the codeLength <= 0?

Right, DirectCodeBuilder can be triggered empty, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14100#discussion_r1204085835

From mdoerr at openjdk.org  Wed May 24 13:11:58 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 24 May 2023 13:11:58 GMT
Subject: RFR: 8308761: New test TestHFA needs adaptation for JDK-8308276
In-Reply-To: <uDaU5OZ1Kyu3qoxcA4RomN-FqohkNoxfl4HpLvlD9sU=.7b9f2e12-cc38-42ce-abb1-488f4bbed489@github.com>
References: <WMQnNo99kheqaDnv4TBIKO3K4owidlI7rXC3Zp-Imbg=.d78e0709-b378-452d-99e1-a3c5b2c990a2@github.com>
 <uDaU5OZ1Kyu3qoxcA4RomN-FqohkNoxfl4HpLvlD9sU=.7b9f2e12-cc38-42ce-abb1-488f4bbed489@github.com>
Message-ID: <NpJwCO6uoaQBibrCpvkDoFYoP9_aeOPaPhrWpYk9iDo=.2df5c96c-2396-46ba-baec-0820083992dc@github.com>

On Wed, 24 May 2023 12:11:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Looks good - I apologize for having missed it.

It was my mistake when merging with your change. Thanks for the reviews!
I think I should integrate it soon in order to get the tests working again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14116#issuecomment-1561118118

From asotona at openjdk.org  Wed May 24 13:18:15 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Wed, 24 May 2023 13:18:15 GMT
Subject: RFR: 8308549: Classfile API should fail to generate over-sized
 Code attribute [v2]
In-Reply-To: <FMfhhGe4XrEG4Brj1GZS69ovfeNMSAEeLwlMq05SzwA=.7014deec-41a2-44cc-b4bd-51f3f71f291b@github.com>
References: <FMfhhGe4XrEG4Brj1GZS69ovfeNMSAEeLwlMq05SzwA=.7014deec-41a2-44cc-b4bd-51f3f71f291b@github.com>
Message-ID: <W1ARN7VUPPE2_QFLfWnCCJ53tsTdOMhSW7ewSqTlh98=.eb968428-5ead-410c-8f8c-bebe17805f00@github.com>

> Classfile API allowed to generate Code attribute exceeding the 65k limit. No exception has been thrown during class generation and the class failed verification later during class loading.
> This patch adds Code size limit check throwing IllegalArgumentException.
> The patch also adds similar check for constant pool size limit to avoid generation class file with corrupted  constant pool.
> Two new tests are added to check response on oversized Code attribute and constant pool.
> `VerifierImpl` is extended to check Code attribute size as a part of class verification process.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  added check for empty Code + test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14100/files
  - new: https://git.openjdk.org/jdk/pull/14100/files/32c00386..d4b21a22

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14100&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14100&range=00-01

  Stats: 12 lines in 4 files changed: 10 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14100.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14100/head:pull/14100

PR: https://git.openjdk.org/jdk/pull/14100

From mdoerr at openjdk.org  Wed May 24 13:49:07 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 24 May 2023 13:49:07 GMT
Subject: RFR: 8308761: New test TestHFA needs adaptation for JDK-8308276
In-Reply-To: <O_o670dMGEEac1EsWoP6gxEImRf-j8EqDS6WMleRYN0=.d65bd8b3-92b9-4448-bc94-de9ad18bc191@github.com>
References: <WMQnNo99kheqaDnv4TBIKO3K4owidlI7rXC3Zp-Imbg=.d78e0709-b378-452d-99e1-a3c5b2c990a2@github.com>
 <uDaU5OZ1Kyu3qoxcA4RomN-FqohkNoxfl4HpLvlD9sU=.7b9f2e12-cc38-42ce-abb1-488f4bbed489@github.com>
 <z6l0NSkQxDffuCFDrHaGzidKtuQNvqUQvbMdVqjST2E=.e331d707-9c1c-4fd3-a3b0-dbe2474859ee@github.com>
 <O_o670dMGEEac1EsWoP6gxEImRf-j8EqDS6WMleRYN0=.d65bd8b3-92b9-4448-bc94-de9ad18bc191@github.com>
Message-ID: <LlDEa4GnqPrFr-GbEadERChW6EChSMDTFnTQ6REWG8M=.6e77d3db-92fd-49f8-84d3-20bc19d7d66a@github.com>

On Wed, 24 May 2023 12:56:55 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> It's probably not required. It was derived from a jextract generated file.
>
> Do you prefer removing it?

I think it's not important. I'll just integrate it to get the tests working again.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14116#discussion_r1204170274

From mcimadamore at openjdk.org  Wed May 24 13:49:07 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 May 2023 13:49:07 GMT
Subject: RFR: 8308761: New test TestHFA needs adaptation for JDK-8308276
In-Reply-To: <LlDEa4GnqPrFr-GbEadERChW6EChSMDTFnTQ6REWG8M=.6e77d3db-92fd-49f8-84d3-20bc19d7d66a@github.com>
References: <WMQnNo99kheqaDnv4TBIKO3K4owidlI7rXC3Zp-Imbg=.d78e0709-b378-452d-99e1-a3c5b2c990a2@github.com>
 <uDaU5OZ1Kyu3qoxcA4RomN-FqohkNoxfl4HpLvlD9sU=.7b9f2e12-cc38-42ce-abb1-488f4bbed489@github.com>
 <z6l0NSkQxDffuCFDrHaGzidKtuQNvqUQvbMdVqjST2E=.e331d707-9c1c-4fd3-a3b0-dbe2474859ee@github.com>
 <O_o670dMGEEac1EsWoP6gxEImRf-j8EqDS6WMleRYN0=.d65bd8b3-92b9-4448-bc94-de9ad18bc191@github.com>
 <LlDEa4GnqPrFr-GbEadERChW6EChSMDTFnTQ6REWG8M=.6e77d3db-92fd-49f8-84d3-20bc19d7d66a@github.com>
Message-ID: <h6ZGHDwVJB7u3B0HDNcn1HRxhVsZLIc1otZpOhdZLnI=.dcda4ff4-b01e-4006-a395-0da2c0398788@github.com>

On Wed, 24 May 2023 13:44:40 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Do you prefer removing it?
>
> I think it's not important. I'll just integrate it to get the tests working again.

Yeah, let's integrate

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14116#discussion_r1204172106

From mdoerr at openjdk.org  Wed May 24 13:49:08 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 24 May 2023 13:49:08 GMT
Subject: Integrated: 8308761: New test TestHFA needs adaptation for JDK-8308276
In-Reply-To: <WMQnNo99kheqaDnv4TBIKO3K4owidlI7rXC3Zp-Imbg=.d78e0709-b378-452d-99e1-a3c5b2c990a2@github.com>
References: <WMQnNo99kheqaDnv4TBIKO3K4owidlI7rXC3Zp-Imbg=.d78e0709-b378-452d-99e1-a3c5b2c990a2@github.com>
Message-ID: <zqDEifE5eJdy3p4_R-zDH-48OEc58rqAtfeP9uIDHic=.ed24cc79-a711-48d8-92f0-16bbcdfcaefc@github.com>

On Wed, 24 May 2023 09:16:46 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Please review this trivial adaptation for JDK-8308276.

This pull request has now been integrated.

Changeset: 7764f46e
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7764f46e9e3a46e39419ce35aaca8efdb3669872
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8308761: New test TestHFA needs adaptation for JDK-8308276

Reviewed-by: mcimadamore, mbaesken

-------------

PR: https://git.openjdk.org/jdk/pull/14116

From jpai at openjdk.org  Wed May 24 13:52:57 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 24 May 2023 13:52:57 GMT
Subject: RFR: 8308549: Classfile API should fail to generate over-sized
 Code attribute [v2]
In-Reply-To: <FxnT8SNnmG1tPlJvgOpGr8sN1msl60RfhF0nwXKTfsk=.3e9dab70-4941-446a-afeb-f5f060953b6f@github.com>
References: <FMfhhGe4XrEG4Brj1GZS69ovfeNMSAEeLwlMq05SzwA=.7014deec-41a2-44cc-b4bd-51f3f71f291b@github.com>
 <syz3XMWhoaWib849NAnApB1e-DIxE8ZotgoFFKcCiZ4=.6d622d25-0e9a-40e4-8ab9-4f881149cd77@github.com>
 <FxnT8SNnmG1tPlJvgOpGr8sN1msl60RfhF0nwXKTfsk=.3e9dab70-4941-446a-afeb-f5f060953b6f@github.com>
Message-ID: <BiifuM8MxQZbQBrrwN2KW4JZ_kR1hHZFkiwV-bVhMME=.416c61d5-05d2-4d2f-890e-402da5543a21@github.com>

On Wed, 24 May 2023 12:57:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 314:
>> 
>>> 312: 
>>> 313:                 int codeLength = curPc();
>>> 314:                 if (codeLength >= 65536) {
>> 
>> Hello Adam, looking at the JVM spec, section 4.7.3 https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.7.3, it states:
>> 
>>> The value of code_length must be greater than zero (as the code array must not be empty) and less than 65536. 
>> 
>> Do you think this check then should also verify (and throw) if the codeLength <= 0?
>
> Right, DirectCodeBuilder can be triggered empty, thanks.

Thank you Adam for the update, looks good to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14100#discussion_r1204181523

From jwaters at openjdk.org  Wed May 24 14:04:03 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 24 May 2023 14:04:03 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows
Message-ID: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>

On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

-------------

Commit messages:
 - Fix the Java Integer types on Windows

Changes: https://git.openjdk.org/jdk/pull/14125/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14125&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308780
  Stats: 24 lines in 11 files changed: 0 ins; 5 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/14125.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14125/head:pull/14125

PR: https://git.openjdk.org/jdk/pull/14125

From jlaskey at openjdk.org  Wed May 24 14:12:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 24 May 2023 14:12:24 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v18]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <7v5CJ2-10s6fliOBRJw5y_QyZL-TNkBsi56E5vokdG8=.c0ffcd0c-6b8d-41f5-8b20-44e3270cdb9a@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Allow unqualified access to unnamed class (internally visible)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/b55f82f8..e590c736

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=16-17

  Stats: 35 lines in 2 files changed: 34 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From alanb at openjdk.org  Wed May 24 14:33:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 May 2023 14:33:00 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v3]
In-Reply-To: <uGGlsyDavyKXLuI-Ok4tj1iDR7oJ8ZqFRzM1V8wWH7o=.74d82f35-33e4-4ada-a3b5-f90307125344@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
 <uGGlsyDavyKXLuI-Ok4tj1iDR7oJ8ZqFRzM1V8wWH7o=.74d82f35-33e4-4ada-a3b5-f90307125344@github.com>
Message-ID: <4k8EWVU6magkRGFo4MkojmXsZpdIW94CpdLPhKoYlcM=.d2a74b5b-cc20-4b06-a5a4-123edbeecca9@github.com>

On Wed, 24 May 2023 10:14:23 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
>> 
>> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).
>
> Michael McMahon 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 nullStrings
>  - test comment update
>  - test update
>  - Merge branch 'master' into nullStrings
>  - exception message update
>  - test update
>  - remve whitespace
>  - update
>  - Merge branch 'master' into nullStrings
>  - first impl

I skimmed through the changes and mostly look okay. There's a few usage of "NULL" in exception messages that I assume should be "NUL character".  Probably need to bump the copyright date on several files.  You might want to find a better name for the test as NullChar isn't too descriptive, the test is really doing a lookup of a hostname that contains a NUL character. I assume there will be follow up issues to change other parts of the system to use the strict functions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14083#issuecomment-1561271438

From raffaello.giulietti at oracle.com  Wed May 24 14:34:24 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Wed, 24 May 2023 16:34:24 +0200
Subject: [External] : Re: Classes used in method body are loaded lazily or
 eagerly depending on method return type
In-Reply-To: <1813541396.62977656.1684881306040.JavaMail.zimbra@univ-eiffel.fr>
References: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
 <c4954b0c-ca2a-7cb1-4710-36af333e7d06@oracle.com>
 <59b1c6ff-ab08-8a8f-12b7-21f78285571b@oracle.com>
 <1813541396.62977656.1684881306040.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <2cf71b1c-7ac1-e158-1c80-762caa3e6e82@oracle.com>

As mentioned in my previous email, if you move the member class 
ChildClass out of TestLoading (out of the nest), and make it a top-level 
class like

     public class ChildClass extends TestLoading.BaseClass {
     }

and change

     URL classFileB = 
TestLoading.class.getResource(TestLoading.class.getSimpleName() + 
"$ChildClass.class");

to

     URL classFileB = 
TestLoading.class.getResource(ChildClass.class.getSimpleName() + ".class");

rebuild everything and run, nothing is thrown.

     deleting: <path-to>/ChildClass.class
     loading: TestLoading$ObjectReturner...
     loading: TestLoading$BaseClassReturner...

I can't see any substantial difference, except that the nest rooted at 
TestLoading lacks a member in the original setup and lacks nothing in 
this setup.

What's an explanation for this difference?


Greetings
Raffaello


On 2023-05-24 00:35, Remi Forax wrote:
> 
> 
> ----- Original Message -----
>> From: "David Holmes" <david.holmes at oracle.com>
>> To: "Raffaello Giulietti" <raffaello.giulietti at oracle.com>, "core-libs-dev" <core-libs-dev at openjdk.org>
>> Sent: Wednesday, May 24, 2023 12:23:24 AM
>> Subject: Re: Classes used in method body are loaded lazily or eagerly depending on method return type
> 
>> On 24/05/2023 12:50 am, Raffaello Giulietti wrote:
>>> I think the problem here is that you are deleting a class in a nest.
>>>
>>> During the verification of BaseClassReturner.getObject(), access control
>>> (JVMS, 5.4.4, second half) determines that the nest is broken, as
>>> ChildClass is not present anymore.
>>
>> Not sure access control gets involved at this stage of the verification
>> process. But in any case turning on logging does not show anything
>> related to nestmates happening between BaseClass and ChildClass. It
>> seems to just be the resolution of the return type during verification
>> of the method, that causes the loading of ChildClass and the subsequent
>> CNFE if it has been removed.
>>
>>> If you move ChildClass out of TestLoading so that it becomes a top-level
>>> class extending TestLoading.BaseClass, and if you adapt the line that
>>> initializes the local var classFileB to refer to the new location, the
>>> code will not throw, despite ChildClass being deleted.
>>
>> My simplified test shows it still throws when verifying BaseClassReturner.
> 
> Nestmate checking is done lazily, so if you do not call a method/access a field of a nested class, the VM should not trigger a class loading.
> 
> Moreover, if you test with Java 8 (nestmates were introduced in Java 11), it failed too.
> That's another clue that the error is not related to nestmates checking.
> 
>>
>>
>> Cheers,
>> David
> 
> regards,
> R?mi
> 
>>
>>>
>>> Greetings
>>> Raffaello
>>>
>>>
>>>
>>> On 2023-05-23 13:20, ?????? ??????? wrote:
>>>> Hello,
>>>>
>>>> originally this question was asked here:
>>>> https://urldefense.com/v3/__https://stackoverflow.com/q/76260269/12473843__;!!ACWV5N9M2RV99hQ!Mb5nhj7EbuftWzF7s4GX9auUZZlyPyCUnLs64c4mkmSGJm4pw0CNgRzQR5wOYuApyE_kHSAnVxGyTM9PHz5StCppGw$ ,
>>>> the code sample for reproduction will be put below or can be found via
>>>> the link
>>>>
>>>> The issue is about eager/lazy loading of a class depending on method
>>>> return type.
>>>> If one runs the code below with Java 11-19 it will fail with
>>>> NoClassDefFoundError (this is expected as delete class file for
>>>> ChildClass):
>>>>
>>>> java.lang.NoClassDefFoundError: org/example/TestLoading$ChildClass
>>>>  ????at java.base/java.lang.Class.forName0(Native Method)
>>>>  ????at java.base/java.lang.Class.forName(Class.java:390)
>>>>  ????at java.base/java.lang.Class.forName(Class.java:381)
>>>>  ????at org.example.TestLoading.loadMyClass(TestLoading.java:29)
>>>>  ????at org.example.TestLoading.main(TestLoading.java:23)
>>>> Caused by: java.lang.ClassNotFoundException:
>>>> org.example.TestLoading$ChildClass
>>>>  ????at
>>>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>>>>  ????at
>>>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>>>>  ????at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>>>>  ????... 5 more
>>>>
>>>> As of Java 20 chapter 12.4.1 of JLS states:
>>>> ---------------------------------------------------------
>>>> A class or interface T will be initialized immediately before the
>>>> first occurrence of any one of the following:
>>>>
>>>> - T is a class and an instance of T is created.
>>>> - a static method declared by T is invoked.
>>>> - a static field declared by T is assigned.
>>>> - a static field declared by T is used and the field is not a constant
>>>> variable (?4.12.4).
>>>>
>>>> When a class is initialized, its superclasses are initialized (if they
>>>> have not been previously initialized), as well as any superinterfaces
>>>> (?8.1.5) that declare any default methods (?9.4.3) (if they have not
>>>> been previously initialized).
>>>> Initialization of an interface does not, of itself, cause
>>>> initialization of any of its superinterfaces.
>>>> A reference to a static field (?8.3.1.1) causes initialization of only
>>>> the class or interface that actually declares it, even though it might
>>>> be referred to through the name of a subclass, a subinterface, or a
>>>> class that implements an interface.
>>>> Invocation of certain reflective methods in class Class and in package
>>>> java.lang.reflect also causes class or interface initialization.
>>>> A class or interface will not be initialized under any other
>>>> circumstance.
>>>> ---------------------------------------------------------
>>>> With the code snippet we see that calling
>>>> Class.forName(ObjectReturner.class.getName()) succeeds and
>>>> Class.forName(BaseClassReturner.class.getName()) fails even though
>>>> both declare returning an instance of ChildClass.
>>>> This failure is unexpected as in the code below we don't fulfill any
>>>> requirement for class loading as of JLS 12.4.1, but the JVM still
>>>> tries to load the class.
>>>>
>>>> I suspect it might be related to class file validation and/or
>>>> security, because when we run the code with -Xlog:class+init there's a
>>>> reference to LinkageError in loading log:
>>>>
>>>> loading: org.example.TestLoading$BaseClassReturner...
>>>> [0.277s][info][class,init] Start class verification for:
>>>> org.example.TestLoading$BaseClassReturner
>>>> [0.277s][info][class,init] 771 Initializing
>>>> 'java/lang/ReflectiveOperationException'(no method) (0x0000000800004028)
>>>> [0.277s][info][class,init] 772 Initializing
>>>> 'java/lang/ClassNotFoundException'(no method) (0x0000000800004288)
>>>> [0.277s][info][class,init] 773 Initializing
>>>> 'java/lang/LinkageError'(no method)
>>>> (0x00000008000044f8)????????????????????????????????? <----
>>>> [0.277s][info][class,init] 774 Initializing
>>>> 'java/lang/NoClassDefFoundError'(no method) (0x0000000800004758)
>>>> [0.277s][info][class,init] Verification for
>>>> org.example.TestLoading$BaseClassReturner has exception pending
>>>> 'java.lang.NoClassDefFoundError org/example/TestLoading$ChildClass'
>>>> [0.277s][info][class,init] End class verification for:
>>>> org.example.TestLoading$BaseClassReturner
>>>>
>>>>
>>>> So I've got three questions about this:
>>>> - Does class loading depend on method's return type?
>>>> - Which part of JLS/JVM spec describes eager class loading in this case?
>>>> - Could one point out the particular piece of the VM code responsible
>>>> for class loading in this case?
>>>>
>>>> Regards,
>>>> Sergey Tsypanov
>>>>
>>>> Code snippet for reproduction:
>>>>
>>>> public class TestLoading {
>>>>
>>>>  ?? public static void main(String[] args) throws Exception {
>>>>  ???? Class.forName(BaseClass.class.getName());
>>>>  ???? URL classFileB =
>>>> TestLoading.class.getResource(TestLoading.class.getSimpleName() +
>>>> "$ChildClass.class");
>>>>  ???? if (classFileB != null) {
>>>>  ?????? if (!"file".equals(classFileB.getProtocol())) {
>>>>  ???????? throw new UnsupportedOperationException();
>>>>  ?????? }
>>>>  ?????? Path path = new File(classFileB.getPath()).toPath();
>>>>  ?????? System.out.println("deleting: " + path);
>>>>  ?????? Files.delete(path);
>>>>  ???? }
>>>>
>>>>  ???? loadMyClass(ObjectReturner.class.getName());
>>>>  ???? loadMyClass(BaseClassReturner.class.getName());
>>>>  ?? }
>>>>
>>>>  ?? private static void loadMyClass(String name) {
>>>>  ???? System.out.println("loading: " + name + "...");
>>>>  ???? try {
>>>>  ?????? Class.forName(name);
>>>>  ???? } catch (Throwable e) {
>>>>  ?????? e.printStackTrace(System.out);
>>>>  ???? }
>>>>  ?? }
>>>>
>>>>  ?? public static class BaseClass {
>>>>  ?? }
>>>>
>>>>  ?? public static class ChildClass extends BaseClass {
>>>>  ?? }
>>>>
>>>>  ?? public static class ObjectReturner {
>>>>  ???? public Object getObject() {
>>>>  ?????? return new ChildClass();
>>>>  ???? }
>>>>  ?? }
>>>>
>>>>  ?? public static class BaseClassReturner {
>>>>  ???? public BaseClass getObject() {
>>>>  ?????? return new ChildClass();
>>>>  ???? }
>>>>  ?? }
>>>> }

From simonis at openjdk.org  Wed May 24 14:37:29 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 24 May 2023 14:37:29 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v6]
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <qR6B7lvFPUN3q2uxLzDl5MnskqHcY9511jMni0LVLdo=.9d7c54ca-69e9-46d5-b3bf-b8efd314a296@github.com>

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Fix the case of truncated writes in the parent process and add a test for it

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13956/files
  - new: https://git.openjdk.org/jdk/pull/13956/files/facbdcf3..b41604ae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13956&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13956&range=04-05

  Stats: 123 lines in 5 files changed: 96 ins; 10 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13956/head:pull/13956

PR: https://git.openjdk.org/jdk/pull/13956

From simonis at openjdk.org  Wed May 24 14:37:29 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Wed, 24 May 2023 14:37:29 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <61e5pVShTICWmDodgIDEACwz-NJB6OMUOw2crLQ2zTE=.2fc8ed80-5979-45c1-8797-ac2a8b47157e@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>
 <WNS9AUc4Uo0uJT7Q-c5WmRQGPXKHOiQ5bk3FAVhcpTw=.7b192c55-1a39-48bf-9c36-eb8219474c4f@github.com>
 <u7bSYYuppXZ1z347-wRTJf9GoxNUW-GoWfSn4dmCLEE=.831249e0-e538-491c-8001-a7dd55673721@github.com>
 <yZM9iro4FRdHveBRx07oeItZ9_CmQJ4wksNo3XI8Igs=.7b2097d5-0852-4f04-9c14-fc8d39a57c08@github.com>
 <qh4P0rQhdigeWLoD9paOaTJgT7uXOU0IsBTQlFdZ3Ew=.1eb8ea15-2d10-45e3-b883-87b088e220ba@github.com>
 <Q1qJR_GJWPvAItv1fmJu-QYM0g5ozWkWd2ljkAy7VQ8=.3a657b07-464d-4184-a667-a3f9a7c9c72a@github.com>
 <61e5pVShTICWmDodgIDEACwz-NJB6OMUOw2crLQ2zTE=.2fc8ed80-5979-45c1-8797-ac2a8b47157e@github.com>
Message-ID: <z1jaZAYnrkHpNidlY8rdzrWNYLS61FMaClzcLbu6iAM=.da4ce393-9150-41ee-89dd-c5bc38a0cb9d@github.com>

On Fri, 19 May 2023 15:43:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>>> Sorry, but I don't understand this argument. If we do a short read we will work with corrupted ChildStuff and SpawnInfo 
>>> structures. This can in the extreme case execute arbitrary code (e.g. if ChildStuff.argv is not fully read from the parent). You are 
>>> basically saying it is better to work on corrupted data rather than reporting an error.
>> 
>> No I am simply pointing out that this has changed more than just the issue with close. And maybe a short-read does indicate data "corruption" and maybe it should be a fatal error. But I don't know exactly how this might manifest so perhaps there are benign short-reads that actually do happen. Regardless it might be better to split this part out and focus on the close issue here.
>
>> > Sorry, but I don't understand this argument. If we do a short read we will work with corrupted ChildStuff and SpawnInfo
>> > structures. This can in the extreme case execute arbitrary code (e.g. if ChildStuff.argv is not fully read from the parent). You are
>> > basically saying it is better to work on corrupted data rather than reporting an error.
>> 
>> No I am simply pointing out that this has changed more than just the issue with close. And maybe a short-read does indicate data "corruption" and maybe it should be a fatal error. But I don't know exactly how this might manifest so perhaps there are benign short-reads that actually do happen. Regardless it might be better to split this part out and focus on the close issue here.
> 
> Given the purpose and implementation of the `readFully` function, I don't see how it can return anything other than an error or the full requested read length.

@RogerRiggs , @tstuefe sorry for bothering you one more time, but I think @mlichtblau brought up an interesting case yesterday which isn't fully resolved by the current fix. In @mlichtblau example, `Java_java_lang_ProcessImpl_forkAndExec()` got stuck waiting on the ping from `jspawnhelper` which itself blocks in `readFully()` because of a truncated `write()` from the parent.

The current fix already replaces `write()` with `restartableWrite()` which handles the case where a `write()` call was interrupted **before** writing a single byte. But there's a second case, namely when `write()` was interrupted after it already wrote some (but not all) of the requested bytes. The `write()` man page states:

> Note  that a successful `write()` may transfer fewer than `count` bytes. Such partial writes can occur for various reasons; for example, because .., or because a blocked `write()` to  a  socket, pipe, or similar was interrupted by a signal handler after it had transferred some, but before it had transferred all of the requested bytes.  In the event of a partial write, the caller can make another `write()` call to transfer the remaining bytes.

So in order to safely handle the second case as well, we have to replace `restartableWrite()` with something like `writeFully()` and that's exactly what this new commit does. I've also added a new test case which reproduces the issue by simulating a truncated `write()`.

For your convenience I've tried to explain all the additional changes (except for trivial cleanups and renamings in the test) below:

Thanks in advance,
Volker

##### `jspawnhelper.c`:


+    // The file descriptor for reporting errors back to our parent we got on the command
+    // line should be the same like the one in the ChildStuff struct we've just read.
+    assert(c.fail[1] == fdout);


Just trying to be overly cautious.

##### childproc.{c,h}


-ssize_t restartableWrite(int fd, const void *buf, size_t count);
+ssize_t writeFully(int fd, const void *buf, size_t count);



-ssize_t
-restartableWrite(int fd, const void *buf, size_t count)
...
-}

+ssize_t
+writeFully(int fd, const void *buf, size_t nbyte)
+#ifdef DEBUG
...
+#endif
...
+}


Replace `restartableWrite()` with `writeFully()` which is basically a copy of `readFully()` (with additional testing code for jtreg). This handles both cases, when `write()` is interrupted before having written a single byte and returns EINTR, as well as the case where `write()` already wrote some (but not all) bytes before it was interrupted. 


-        restartableWrite(fail_pipe_fd, &code, sizeof(code));
+        if (writeFully(fail_pipe_fd, &code, sizeof(code)) != sizeof(code)) {
+            goto WhyCantJohnnyExec;
+        }


Treat an incomplete write as error and bail out.


-        restartableWrite(fail_pipe_fd, &errnum, sizeof(errnum));
+        writeFully(fail_pipe_fd, &errnum, sizeof(errnum));


We're already in the error handling code here (i.e. `WhyCantJohnnyExec`) so not much we can do. We'll close the pipe and exit with an error anyway.

##### `ProcessImpl_md.c`


-    restartableWrite(c->childenv[1], (char *)&magic, sizeof(magic)); // magic number first
+    if (writeFully(c->childenv[1], (char *)&magic, sizeof(magic)) != sizeof(magic)) { // magic number first
+        return -1;
+    }
...
-    restartableWrite(c->childenv[1], (char *)c, sizeof(*c));
-    restartableWrite(c->childenv[1], (char *)&sp, sizeof(sp));
-    restartableWrite(c->childenv[1], buf, bufsize);
+    if (writeFully(c->childenv[1], (char *)c, sizeof(*c)) != sizeof(*c) ||
+        writeFully(c->childenv[1], (char *)&sp, sizeof(sp)) != sizeof(sp) ||
+        writeFully(c->childenv[1], buf, bufsize) != bufsize) {
+        return -1;
+    }


Make sure we've written all the required data to jspawnhelper or return an error otherwise. The `-1` return value will be handled in `Java_java_lang_ProcessImpl_forkAndExec()` by throwing an `IOException("posix_spawn failed")`.


+    /* We're done. Let jspwanhelper know he can't expect any more data from us. */
+    close(c->childenv[1]);
+    c->childenv[1] = -1;


Close the write end of the pipe to jspawnhelper after we've written all data. This will prevent `jspawnhelper` to block on the reading side if somthing goes wrong (e.g. we've not written enough data).


+    // Reset errno to protect against bogus error messages
+    errno = 0;


In `Java_java_lang_ProcessImpl_forkAndExec()` we might call `throwIOException(env, errno, ..)` in error situations not caused by a failing system call (e.g. if `startChild()` returned `-1` because of a bad response from `jspawnhelper`). It is therefor better to reset `errno` at the beginning of the method to avoid bogus error messages in the generated `IOExceptions`s.


-            assert(errnum == CHILD_IS_ALIVE);
             if (errnum != CHILD_IS_ALIVE) {
-                /* Should never happen since the first thing the spawn
-                 * helper should do is to send an alive ping to the parent,
-                 * before doing any subsequent work. */
+                /* This can happen if the spawn helper encounters an error
+                 * before or during the handshake with the parent. */
                 throwIOException(env, 0, "Bad code from spawn helper "


This assertion isn't useful. We'd rather want to see the generated exception if `errnum != CHILD_IS_ALIVE` instead of crashing the process. Also, the comment is wrong, because `jspawnhelper` does quite some stuff (e.g. allocating, reading from parent) before sending the alive ping and if these actions fail, `jspawnhelper` will send an error code (e.g. `ERR_MALLOC`, `ERR_PIPE`) which is not equal to `CHILD_IS_ALIVE`.

##### JspawnhelperProtocol.java


+    private static void simulateTruncatedWriteInParent(int stage) throws Exception {
...
+    }


Added a new test to simualte a truncated write in the parent process to jspawnhelper communication.


-            Optional<String> cmd = ph.info().command();
-            if (cmd.isPresent() && cmd.get().endsWith("jspawnhelper")) {
-                throw new Exception("jspawnhelper still alive after parent Java process terminated");
+            try {
+                // Give jspawnhelper a chance to exit gracefully
+                ph.onExit().get(TIMEOUT, TimeUnit.SECONDS);
+            } catch (TimeoutException te) {
+                Optional<String> cmd = ph.info().command();
+                if (cmd.isPresent() && cmd.get().endsWith("jspawnhelper")) {
+                    throw new Exception("jspawnhelper still alive after parent Java process terminated");
+                }


Make the `simulateCrashInParent()` sub-test more robust by allowing `jspawnhelper` up to `TIMEOUT` seconds to terminate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1561271712

From jiangli at openjdk.org  Wed May 24 15:01:01 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 24 May 2023 15:01:01 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
Message-ID: <pGJ-4FXM217g0KW5wW2GrrY3wNHYQUH7xudL-VxWjhw=.10bd8fd9-a144-417a-82ce-592f95a3d565@github.com>

On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
>
> I ran this patch in our internal build and test system and got failures on macos and windows. I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in.
> 
> 
> [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error
> [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
> [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed
> [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1

Hi @erikj79 Please let me know if you have any additional comments for the PR. Could you please also help run through testing for the latest version? Thanks

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561320098

From rriggs at openjdk.org  Wed May 24 15:02:10 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 24 May 2023 15:02:10 GMT
Subject: RFR: 8304006: jlink should create the jimage file in the native
 endian for the target platform [v17]
In-Reply-To: <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
References: <mQKRPfXuNRn7qos0m9ddFoO7m9a4j0V_yoK4ffDLSSU=.47bb2b27-25d9-4323-952c-374b0afe08c9@github.com>
 <sMwYEg5s0F3O3g4ZHYrzemSltFgqvotVYNcfG1LNfJ8=.d4be632f-7d35-4111-98ca-d3c2a4d762ad@github.com>
Message-ID: <n9w1WHMCWsLCUKeQ1E4ypAX3cgoPo4dS3wYlVGLA108=.3fd6605e-66bc-487d-a49e-3c03e60061d3@github.com>

On Wed, 29 Mar 2023 01:40:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this change which proposes to fix the issue reported in https://bugs.openjdk.org/browse/JDK-8206890?
>> 
>> The `jlink` command allows a `--endian` option to specify the byte order in the generated image. Before this change, when such a image was being launched, the code would assume the byte order in the image to be the native order of the host where the image is being launched. That would result in failure to launch java, as noted in the linked issue.
>> 
>> The commit in this PR, changes relevant places to not assume native order and instead determine the byte order by reading the magic bytes in the image file's header content.
>> 
>> A new jtreg test has been added which reproduces the issue and verifies the fix.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup test - rename method and update code comment as suggested by Alan
>  - Rename KNOWN_ENDIANNESS to PLATFORM_PROPERTIES

For the ModuleTarget attribute can we come to a conclusion that the attribute for big/little endian is implicit in the architecture 'name'?  
It seems to be the simplest but doesn't naturally extend to other possible attributes of a target architecture that might not be intrinsic to the architecture.
I will convert the draft to a full PR to get reviews started.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11943#issuecomment-1561321280

From rriggs at openjdk.org  Wed May 24 15:08:09 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 24 May 2023 15:08:09 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order and
 address size
Message-ID: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>

The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.

The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
The enum values directly reflect the build-time artifacts and resulting executables.

This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.

-------------

Commit messages:
 - Correct address size for ARM (32-bit)
 - 8308452: Extend internal Architecture enum with byte order and address size

Changes: https://git.openjdk.org/jdk/pull/14063/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14063&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308452
  Stats: 134 lines in 4 files changed: 111 ins; 3 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/14063.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14063/head:pull/14063

PR: https://git.openjdk.org/jdk/pull/14063

From mdoerr at openjdk.org  Wed May 24 15:08:11 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 24 May 2023 15:08:11 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size
In-Reply-To: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
Message-ID: <ecTHGOp8nTYUObj0Z4tAIsXr9CP1E9qiBW20noW4emc=.3ff95f3e-b26c-4e84-8477-3f1fad7307a6@github.com>

On Fri, 19 May 2023 19:19:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
> 
> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
> The enum values directly reflect the build-time artifacts and resulting executables.
> 
> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.

I think this makes sense. Thanks for working on it! Most architectures have a fixed endianness.
For PPC64, I think using PPC64LE is fine to distinguish as it is a common name.
Another architecture which supports both endianness flavors is IA64. HPUX is big endian and linux little endian. I don't know how this should be handled. Fortunately, I don't think we need to support IA64. :-)

src/java.base/share/classes/jdk/internal/util/Architecture.java line 42:

> 40:     X86(32, ByteOrder.LITTLE_ENDIAN),
> 41:     AARCH64(64, ByteOrder.LITTLE_ENDIAN),
> 42:     ARM(64, ByteOrder.LITTLE_ENDIAN),

ARM should be 32 bit.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14063#pullrequestreview-1435010016
PR Review Comment: https://git.openjdk.org/jdk/pull/14063#discussion_r1199316006

From rriggs at openjdk.org  Wed May 24 15:27:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 24 May 2023 15:27:57 GMT
Subject: RFR: 8290499: new File(parent,
 \"/\") breaks normalization =?UTF-8?B?4oCT?= creates File with slash at the
 end
In-Reply-To: <8xzVUmIbNYbHrO6ymEBcptZ4uK5saoxx0xXzmdVSc9E=.30439fa6-e4bb-46fb-b1be-0e103a31d6e5@github.com>
References: <8xzVUmIbNYbHrO6ymEBcptZ4uK5saoxx0xXzmdVSc9E=.30439fa6-e4bb-46fb-b1be-0e103a31d6e5@github.com>
Message-ID: <zBEIXZZG7MxriC2rtzL_l5Eak9r4fIPLmIyGLhnipi4=.d9cb2959-241c-4e63-bba9-e56c3de75188@github.com>

On Tue, 23 May 2023 22:49:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `java.io.File`, change the constructors `File(File,String)` and `File(String,String)` so that they do not for typical cases return a `File` whose path has a trailing name separator.

src/java.base/unix/classes/java/io/UnixFileSystem.java line 109:

> 107:         if (len > 1 && s.charAt(len - 1) == '/')
> 108:             return s.substring(0, len - 1);
> 109:         return s;

If there are multiple trailing `/`, is it sufficient to remove only a single `/`?
Does this have the same result as `normalize(pathname)`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14109#discussion_r1204387220

From mcimadamore at openjdk.org  Wed May 24 15:34:02 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 May 2023 15:34:02 GMT
Subject: RFR: 8300491: SymbolLookup::libraryLookup accepts strings with
 terminators
Message-ID: <CEGuI__aV-PjLH3s4i6AuQhnJ_Y3ukytNuBtuKCxAOE=.375bc90e-d127-4508-85ac-765125fe6873@github.com>

There is a difference in behavior between `System::loadLibrary` and `SymbolLookup::libraryLookup(String)`. While the former catches library names containing NULL chars (because, internally it uses Path/File logic, which reject those), `SymbolLookup` does not. As a result, it is possible to load libraries such as `libGL.so\0foobar`, because the string is passed directly to `dlopen`.

A similar issue arises when we consider `SymbolLookup::find`, as the name is again sent unmodified to `dlopen`. In reality, some filtering *does* happen in that case, as the native code calls `GetStringUTFChars`:

https://docs.oracle.com/en/java/javase/20/docs/specs/jni/functions.html#getstringutfchars

Which encodes the NULL chars in a different form:

https://docs.oracle.com/en/java/javase/20/docs/specs/jni/types.html#modified-utf-8-strings

So, in practice, even if the input is not validated, a call to `find` with one or more NULL chars is unlikely to succeed.

In this patch I have added several checks to make sure that:
* the name of library passed to `libraryLookup(String)` does not contain `\0` and, if so, throw `IllegalArgumentException` (which is already covered by current spec;
* the name of a symbol passed to `SymbolLookup::find` does not contain `\0` and, if so, return empty optional. This required changes on all the lookups we implement.

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/14126/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14126&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8300491
  Stats: 33 lines in 5 files changed: 33 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14126.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14126/head:pull/14126

PR: https://git.openjdk.org/jdk/pull/14126

From jlaskey at openjdk.org  Wed May 24 15:42:28 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 24 May 2023 15:42:28 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v19]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <tyAD2PL7pU50zkaaQgFOB8y-jYzlJMbJ6kak2Tt6cPM=.89dd834d-d5db-4a47-b181-e87d6a9715d3@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Ignore SKIPs (semicolon class declarations)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/e590c736..8ccb9502

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=17-18

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From bpb at openjdk.org  Wed May 24 15:49:01 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 24 May 2023 15:49:01 GMT
Subject: RFR: 8290499: new File(parent,
 \"/\") breaks normalization =?UTF-8?B?4oCT?= creates File with slash at the
 end
In-Reply-To: <zBEIXZZG7MxriC2rtzL_l5Eak9r4fIPLmIyGLhnipi4=.d9cb2959-241c-4e63-bba9-e56c3de75188@github.com>
References: <8xzVUmIbNYbHrO6ymEBcptZ4uK5saoxx0xXzmdVSc9E=.30439fa6-e4bb-46fb-b1be-0e103a31d6e5@github.com>
 <zBEIXZZG7MxriC2rtzL_l5Eak9r4fIPLmIyGLhnipi4=.d9cb2959-241c-4e63-bba9-e56c3de75188@github.com>
Message-ID: <t66tMlZuWltxbz2JQHMBWahtxTO7IWhYL2FNJWEUGx4=.39279173-948f-41be-a074-978b679dd496@github.com>

On Wed, 24 May 2023 15:25:37 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> In `java.io.File`, change the constructors `File(File,String)` and `File(String,String)` so that they do not for typical cases return a `File` whose path has a trailing name separator.
>
> src/java.base/unix/classes/java/io/UnixFileSystem.java line 109:
> 
>> 107:         if (len > 1 && s.charAt(len - 1) == '/')
>> 108:             return s.substring(0, len - 1);
>> 109:         return s;
> 
> If there are multiple trailing `/`, is it sufficient to remove only a single `/`?
> Does this have the same result as `normalize(pathname)`?

The main calling context is

            if (parent.path.isEmpty()) {
                this.path = FS.resolve(FS.getDefaultParent(),
                                       FS.normalize(child));
            } else {
                this.path = FS.resolve(parent.path,
                                       FS.normalize(child));
            }

where `parent` is non-`null` and already normalized. Thus both components should already be normalized and multiple trailing `/` impossible. I _think_ that it should give the same result as `normalize(pathname)`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14109#discussion_r1204421403

From alanb at openjdk.org  Wed May 24 16:31:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 May 2023 16:31:03 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size
In-Reply-To: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
Message-ID: <gkzuZHq5qLPSPiSVqPwyclOWkoyd32ZjKuQ8dAgsnoI=.69065735-0c46-4cd1-b7d0-37dc5e1acbe8@github.com>

On Fri, 19 May 2023 19:19:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
> 
> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
> The enum values directly reflect the build-time artifacts and resulting executables.
> 
> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.

Mapping the arch to endianness seems okay for the current ports but I could imagine needing to re-visit that at some point.

src/java.base/share/classes/jdk/internal/util/Architecture.java line 38:

> 36:  */
> 37: public enum Architecture {
> 38:     OTHER(0, null),          // An unknown architecture not specifically named

ByteOrder.nativeOrder() might be a better default for unknown archs.

src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 140:

> 138:      */
> 139:     /* package-private */
> 140:     static String toUpperCase(String str) {

A bit icky to have OperatingSystem to expose a static method to convert Strings as it's nothing to do with OperatingSystem, is there anywhere else?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14063#pullrequestreview-1442315684
PR Review Comment: https://git.openjdk.org/jdk/pull/14063#discussion_r1204472688
PR Review Comment: https://git.openjdk.org/jdk/pull/14063#discussion_r1204477269

From psandoz at openjdk.org  Wed May 24 16:32:55 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 24 May 2023 16:32:55 GMT
Subject: RFR: 8300491: SymbolLookup::libraryLookup accepts strings with
 terminators
In-Reply-To: <CEGuI__aV-PjLH3s4i6AuQhnJ_Y3ukytNuBtuKCxAOE=.375bc90e-d127-4508-85ac-765125fe6873@github.com>
References: <CEGuI__aV-PjLH3s4i6AuQhnJ_Y3ukytNuBtuKCxAOE=.375bc90e-d127-4508-85ac-765125fe6873@github.com>
Message-ID: <Zsr96-EC3nMs6MiOjTdL-n_JphT3bzlJ2Z251BHBpQI=.ddb6e8da-7dd5-4267-bd48-bfb042886c84@github.com>

On Wed, 24 May 2023 15:22:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> There is a difference in behavior between `System::loadLibrary` and `SymbolLookup::libraryLookup(String)`. While the former catches library names containing NULL chars (because, internally it uses Path/File logic, which reject those), `SymbolLookup` does not. As a result, it is possible to load libraries such as `libGL.so\0foobar`, because the string is passed directly to `dlopen`.
> 
> A similar issue arises when we consider `SymbolLookup::find`, as the name is again sent unmodified to `dlopen`. In reality, some filtering *does* happen in that case, as the native code calls `GetStringUTFChars`:
> 
> https://docs.oracle.com/en/java/javase/20/docs/specs/jni/functions.html#getstringutfchars
> 
> Which encodes the NULL chars in a different form:
> 
> https://docs.oracle.com/en/java/javase/20/docs/specs/jni/types.html#modified-utf-8-strings
> 
> So, in practice, even if the input is not validated, a call to `find` with one or more NULL chars is unlikely to succeed.
> 
> In this patch I have added several checks to make sure that:
> * the name of library passed to `libraryLookup(String)` does not contain `\0` and, if so, throw `IllegalArgumentException` (which is already covered by current spec;
> * the name of a symbol passed to `SymbolLookup::find` does not contain `\0` and, if so, return empty optional. This required changes on all the lookups we implement.

Do you also need to test on `SymbolLookup` returned from `Linker::defaultLookup`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14126#pullrequestreview-1442329856

From mcimadamore at openjdk.org  Wed May 24 16:45:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 May 2023 16:45:55 GMT
Subject: RFR: 8300491: SymbolLookup::libraryLookup accepts strings with
 terminators
In-Reply-To: <Zsr96-EC3nMs6MiOjTdL-n_JphT3bzlJ2Z251BHBpQI=.ddb6e8da-7dd5-4267-bd48-bfb042886c84@github.com>
References: <CEGuI__aV-PjLH3s4i6AuQhnJ_Y3ukytNuBtuKCxAOE=.375bc90e-d127-4508-85ac-765125fe6873@github.com>
 <Zsr96-EC3nMs6MiOjTdL-n_JphT3bzlJ2Z251BHBpQI=.ddb6e8da-7dd5-4267-bd48-bfb042886c84@github.com>
Message-ID: <JJuetIOQd4rw_149gRNiBMwbu4ipQSZ1-es7Rt27N98=.fcf432ec-1155-4333-b77d-05e83e311bba@github.com>

On Wed, 24 May 2023 16:30:25 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Do you also need to test on `SymbolLookup` returned from `Linker::defaultLookup`?

Yeah - some test would be better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14126#issuecomment-1561568364

From mcimadamore at openjdk.org  Wed May 24 17:09:23 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 24 May 2023 17:09:23 GMT
Subject: RFR: 8300491: SymbolLookup::libraryLookup accepts strings with
 terminators [v2]
In-Reply-To: <CEGuI__aV-PjLH3s4i6AuQhnJ_Y3ukytNuBtuKCxAOE=.375bc90e-d127-4508-85ac-765125fe6873@github.com>
References: <CEGuI__aV-PjLH3s4i6AuQhnJ_Y3ukytNuBtuKCxAOE=.375bc90e-d127-4508-85ac-765125fe6873@github.com>
Message-ID: <IcMxY0UOdnxnp9FoD-a9sLN4pmzCbMZLaKLH-icA5Uw=.31a30e6b-b96a-4d80-84b7-8f405d3148fc@github.com>

> There is a difference in behavior between `System::loadLibrary` and `SymbolLookup::libraryLookup(String)`. While the former catches library names containing NULL chars (because, internally it uses Path/File logic, which reject those), `SymbolLookup` does not. As a result, it is possible to load libraries such as `libGL.so\0foobar`, because the string is passed directly to `dlopen`.
> 
> A similar issue arises when we consider `SymbolLookup::find`, as the name is again sent unmodified to `dlopen`. In reality, some filtering *does* happen in that case, as the native code calls `GetStringUTFChars`:
> 
> https://docs.oracle.com/en/java/javase/20/docs/specs/jni/functions.html#getstringutfchars
> 
> Which encodes the NULL chars in a different form:
> 
> https://docs.oracle.com/en/java/javase/20/docs/specs/jni/types.html#modified-utf-8-strings
> 
> So, in practice, even if the input is not validated, a call to `find` with one or more NULL chars is unlikely to succeed.
> 
> In this patch I have added several checks to make sure that:
> * the name of library passed to `libraryLookup(String)` does not contain `\0` and, if so, throw `IllegalArgumentException` (which is already covered by current spec;
> * the name of a symbol passed to `SymbolLookup::find` does not contain `\0` and, if so, return empty optional. This required changes on all the lookups we implement.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add test for system lookup

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14126/files
  - new: https://git.openjdk.org/jdk/pull/14126/files/706e9585..52077b57

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14126&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14126&range=00-01

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14126.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14126/head:pull/14126

PR: https://git.openjdk.org/jdk/pull/14126

From naoto at openjdk.org  Wed May 24 17:41:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 24 May 2023 17:41:57 GMT
Subject: RFR: 8174722: Wrong behavior of DecimalFormat with RoundingMode.UP
 in special case
In-Reply-To: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
Message-ID: <Yx9RVsgO0XR7-qtJoJ6jJ-uI6n6Np2zU4T1_-PG9bGI=.0a2a9cbe-95c1-43ca-8f5e-1b70f370bea0@github.com>

On Tue, 23 May 2023 23:16:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which addresses a case where Decimal Format would violate certain RoundingMode contracts given the right pattern and double.
> 
> For example,
> 
> 
> DecimalFormat df = new DecimalFormat();
> df.setRoundingMode(RoundingMode.UP);
> double small = 0.0001;
> double big = 1.0001;
> df.applyPattern("0.00");
> df.format(small); // returns 0.00, which violates UP
> df.format(big); // returns 1.01, which does not violate UP
> 
> 
> In this example `0.0001` becomes `0.00`, a decrease in magnitude. This violates the RoundingMode.UP contract as RoundingMode.UP states "Note that this rounding mode never decreases the magnitude of the calculated value."
> 
> This edge case is a result of when values smaller than the absolute value of `.1` have more leading zeros between the decimal and the first non-zero digit (_0.0001 -> **3**_) than maximum fractional digits in the pattern (_0.00 -> **2**_).
> 
> The change to Decimal Format ensures that during this case, the rounding mode is considered before truncation, which dictates if the formatted number should insert a 1 in the least significant digit location.
> 
> The test validates the change by using data from larger counterparts. For example, If we are testing `0.0009`, we can format `1.0009` with the same pattern and mode that we use on `0.0009`, then compare the fractional portions to each other and ensure they are equal.

I just wonder if it is ok to reverse the rounding/truncation only in this special case. If the truncation always comes first, then 0.00 would be correct (then 1.01 may be something wrong). Looks to me that the original comment suggests it tries to truncate those cases. I suggest filing a CSR for further behavioral consideration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14110#issuecomment-1561676671

From aturbanov at openjdk.org  Wed May 24 17:41:57 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 24 May 2023 17:41:57 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
In-Reply-To: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
Message-ID: <R7QCZix2oVrPtFE61w6gxbmzytuZdDlUX2hAFPIM2So=.59403153-6e88-4d62-b0de-aa3b374ea634@github.com>

On Thu, 11 May 2023 13:08:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is the implementation of:
> 
> - JEP 453: Structured Concurrency (Preview)
> - JEP 446: Scoped Values (Preview)
> 
> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
> 
> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere

test/jdk/java/util/concurrent/StructuredTaskScope/StructuredTaskScopeTest.java line 1016:

> 1014:             scope.join();
> 1015: 
> 1016:             var subtask1  = scope.find(task1);

Suggestion:

            var subtask1 = scope.find(task1);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1204557338

From alexey.ivanov at oracle.com  Wed May 24 18:03:19 2023
From: alexey.ivanov at oracle.com (Aleksei Ivanov)
Date: Wed, 24 May 2023 19:03:19 +0100
Subject: Remove unnecessary method call in PriorityBlockingQueue
In-Reply-To: <CAENJvPVUXR4NdCz6U6uH+s_tO2JP_vBzv7cjBzdstvxf0pfjTQ@mail.gmail.com>
References: <CAENJvPVUXR4NdCz6U6uH+s_tO2JP_vBzv7cjBzdstvxf0pfjTQ@mail.gmail.com>
Message-ID: <6c79ca64-7e81-be4d-99ad-be3a6dd9d164@oracle.com>

Hi Robin,

This belongs in core-libs.

On 24/05/2023 16:50, Robin Gong wrote:
> Hi,
>
> Recently, I found this constructor in?PriorityBlockingQueue:
>
>     ? public PriorityBlockingQueue(int initialCapacity,
>     ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Comparator<? super E> comparator) {
>     ? ? ? ? if (initialCapacity < 1)
>     ? ? ? ? ? ? throw new IllegalArgumentException();
>     ? ? ? ? this.comparator = comparator;
>     ? ? ? ? this.queue = new Object[Math.max(1, initialCapacity)];
>     ? ? }
>
>
> I believe we could change 'Math.max(1, initialCapacity)' to 
> 'initialCapacity'. Since?initialCapacity must be greater or equal to 1.

It looks reasonable to me.

-- 
Regards,
Alexey

>
> And also that's how?PriorityQueue running.
>
>     ? public PriorityQueue(int initialCapacity,
>     ? ? ? ? ? ? ? ? ? ? ? ? ?Comparator<? super E> comparator) {
>     ? ? ? ? // Note: This restriction of at least one is not actually
>     needed,
>     ? ? ? ? // but continues for 1.5 compatibility
>     ? ? ? ? if (initialCapacity < 1)
>     ? ? ? ? ? ? throw new IllegalArgumentException();
>     ? ? ? ? this.queue = new Object[initialCapacity];
>     ? ? ? ? this.comparator = comparator;
>     ? ? }
>
>
> Best regarts,
> Robin Gong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230524/c2cced67/attachment.htm>

From stuefe at openjdk.org  Wed May 24 18:37:06 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 24 May 2023 18:37:06 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it
In-Reply-To: <z1jaZAYnrkHpNidlY8rdzrWNYLS61FMaClzcLbu6iAM=.da4ce393-9150-41ee-89dd-c5bc38a0cb9d@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <RR5Pfxptvf3uqKnWvd_gmgio4PSSE9Xknp2NPHzyM_U=.a16aeb5d-36d2-4847-9b2b-42f522333c1b@github.com>
 <WNS9AUc4Uo0uJT7Q-c5WmRQGPXKHOiQ5bk3FAVhcpTw=.7b192c55-1a39-48bf-9c36-eb8219474c4f@github.com>
 <u7bSYYuppXZ1z347-wRTJf9GoxNUW-GoWfSn4dmCLEE=.831249e0-e538-491c-8001-a7dd55673721@github.com>
 <yZM9iro4FRdHveBRx07oeItZ9_CmQJ4wksNo3XI8Igs=.7b2097d5-0852-4f04-9c14-fc8d39a57c08@github.com>
 <qh4P0rQhdigeWLoD9paOaTJgT7uXOU0IsBTQlFdZ3Ew=.1eb8ea15-2d10-45e3-b883-87b088e220ba@github.com>
 <Q1qJR_GJWPvAItv1fmJu-QYM0g5ozWkWd2ljkAy7VQ8=.3a657b07-464d-4184-a667-a3f9a7c9c72a@github.com>
 <61e5pVShTICWmDodgIDEACwz-NJB6OMUOw2crLQ2zTE=.2fc8ed80-5979-45c1-8797-ac2a8b47157e@github.com>
 <z1jaZAYnrkHpNidlY8rdzrWNYLS61FMaClzcLbu6iAM=.da4ce393-9150-41ee-89dd-c5bc38a0cb9d@github.com>
Message-ID: <TmirZ7rlm8L8n1AeEqb28y4i6_9oxS_p1JsA0Lu4LA4=.82e2d43f-a4c6-4308-9197-27d3f0d8fc70@github.com>

On Wed, 24 May 2023 14:30:10 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>>> > Sorry, but I don't understand this argument. If we do a short read we will work with corrupted ChildStuff and SpawnInfo
>>> > structures. This can in the extreme case execute arbitrary code (e.g. if ChildStuff.argv is not fully read from the parent). You are
>>> > basically saying it is better to work on corrupted data rather than reporting an error.
>>> 
>>> No I am simply pointing out that this has changed more than just the issue with close. And maybe a short-read does indicate data "corruption" and maybe it should be a fatal error. But I don't know exactly how this might manifest so perhaps there are benign short-reads that actually do happen. Regardless it might be better to split this part out and focus on the close issue here.
>> 
>> Given the purpose and implementation of the `readFully` function, I don't see how it can return anything other than an error or the full requested read length.
>
> @RogerRiggs , @tstuefe sorry for bothering you one more time, but I think @mlichtblau brought up an interesting case yesterday which isn't fully resolved by the current fix. In @mlichtblau example, `Java_java_lang_ProcessImpl_forkAndExec()` got stuck waiting on the ping from `jspawnhelper` which itself blocks in `readFully()` because of a truncated `write()` from the parent.
> 
> The current fix already replaces `write()` with `restartableWrite()` which handles the case where a `write()` call was interrupted **before** writing a single byte. But there's a second case, namely when `write()` was interrupted after it already wrote some (but not all) of the requested bytes. The `write()` man page states:
> 
>> Note  that a successful `write()` may transfer fewer than `count` bytes. Such partial writes can occur for various reasons; for example, because .., or because a blocked `write()` to  a  socket, pipe, or similar was interrupted by a signal handler after it had transferred some, but before it had transferred all of the requested bytes.  In the event of a partial write, the caller can make another `write()` call to transfer the remaining bytes.
> 
> So in order to safely handle the second case as well, we have to replace `restartableWrite()` with something like `writeFully()` and that's exactly what this new commit does. I've also added a new test case which reproduces the issue by simulating a truncated `write()`.
> 
> For your convenience I've tried to explain all the additional changes (except for trivial cleanups and renamings in the test) below:
> 
> Thanks in advance,
> Volker
> 
> ##### `jspawnhelper.c`:
> 
> 
> +    // The file descriptor for reporting errors back to our parent we got on the command
> +    // line should be the same like the one in the ChildStuff struct we've just read.
> +    assert(c.fail[1] == fdout);
> 
> 
> Just trying to be overly cautious.
> 
> ##### childproc.{c,h}
> 
> 
> -ssize_t restartableWrite(int fd, const void *buf, size_t count);
> +ssize_t writeFully(int fd, const void *buf, size_t count);
> 
> 
> 
> -ssize_t
> -restartableWrite(int fd, const void *buf, size_t count)
> ...
> -}
> 
> +ssize_t
> +writeFully(int fd, const void *buf, size_t nbyte)
> +#ifdef DEBUG
> ...
> +#endif
> ...
> +}
> 
> 
> Replace `restartableWrite()` with `writeFully()` which is basically a copy of `readFully()` (with additional testing code for jtreg). This handles both cases, when `write()` is interrupted before having written a single byte and returns EINTR, as well as the case where...

@simonis I try to look at this before the weekend, but no guarantees. Your analysis looks sound, but the code is sensitive and I want to give it my full attention.

One remark though, you should change JBS title and issue text to reflect the growing number of issues this patch is fixing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1561750301

From jlu at openjdk.org  Wed May 24 18:39:55 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 24 May 2023 18:39:55 GMT
Subject: RFR: 8174722: Wrong behavior of DecimalFormat with RoundingMode.UP
 in special case
In-Reply-To: <Yx9RVsgO0XR7-qtJoJ6jJ-uI6n6Np2zU4T1_-PG9bGI=.0a2a9cbe-95c1-43ca-8f5e-1b70f370bea0@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
 <Yx9RVsgO0XR7-qtJoJ6jJ-uI6n6Np2zU4T1_-PG9bGI=.0a2a9cbe-95c1-43ca-8f5e-1b70f370bea0@github.com>
Message-ID: <tc2WNaKDU6pGMiSlWQlh_Hfv3kY7xlIEzC_1m4qsJXI=.93a9520a-5161-4b9b-b60e-f05e2fc96dbc@github.com>

On Wed, 24 May 2023 17:36:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I just wonder if it is ok to reverse the rounding/truncation only in this special case. If the truncation always comes first, then 0.00 would be correct (then 1.01 may be something wrong). Looks to me that the original comment suggests it tries to truncate those cases. I suggest filing a CSR for further behavioral consideration.

The normal behavior of DecimalFormat (DigitList) "rounds" before truncation. For example, consider

`1.0000009` formatted to `0.0` with `RoundingMode.UP`

DigitList will search past the maximum digits allowed to decide if the formatted value should be rounded. '9' will be found, and as such the value will be "rounded", by incrementing the value by 1 at the max digit location -> `1.1000009`, then DigitList will truncate -> `1.1`

Thus I believe that this change is aligning this special case to be consistent with the existing behavior of rounding before truncation. I will follow-up in the CSR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14110#issuecomment-1561752907

From jlaskey at openjdk.org  Wed May 24 18:50:33 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 24 May 2023 18:50:33 GMT
Subject: RFR: JDK-8308040 Evaluate new public types in non-public classes
Message-ID: <afI8vPnbCDVuF5xZLKamPqNyJjfPKykW6RnBmP4Q1tQ=.1e3ec34d-04e8-4de7-b3ee-bc1b5d5abdce@github.com>

As reported by Marc Hoffman of javaalmanac.io, in a recent JDK 21 build there are new public types nested in non-public interfaces: 

java.lang.runtime.ReferenceKey.SoftKey 
java.lang.runtime.ReferenceKey.StrongKey 
java.lang.runtime.ReferenceKey.WeakKey 
java.util.Digits.DecimalDigits 
java.util.Digits.HexDigits 
java.util.Digits.OctalDigits

This PR moves the nested classes to neighbouring package private classes

-------------

Commit messages:
 - Changes for ReferencedKeyMap
 - Changes for Digits

Changes: https://git.openjdk.org/jdk/pull/14039/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14039&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308040
  Stats: 989 lines in 10 files changed: 586 ins; 396 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14039.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14039/head:pull/14039

PR: https://git.openjdk.org/jdk/pull/14039

From rriggs at openjdk.org  Wed May 24 18:50:34 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 24 May 2023 18:50:34 GMT
Subject: RFR: JDK-8308040 Evaluate new public types in non-public classes
In-Reply-To: <afI8vPnbCDVuF5xZLKamPqNyJjfPKykW6RnBmP4Q1tQ=.1e3ec34d-04e8-4de7-b3ee-bc1b5d5abdce@github.com>
References: <afI8vPnbCDVuF5xZLKamPqNyJjfPKykW6RnBmP4Q1tQ=.1e3ec34d-04e8-4de7-b3ee-bc1b5d5abdce@github.com>
Message-ID: <5hh1MDntGVOqbFMdW6g-K1K5CcrwOfVj84BFM8WhhTA=.9e1977ef-2092-4417-adb1-d411e58ae350@github.com>

On Wed, 17 May 2023 19:14:20 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> As reported by Marc Hoffman of javaalmanac.io, in a recent JDK 21 build there are new public types nested in non-public interfaces: 
> 
> java.lang.runtime.ReferenceKey.SoftKey 
> java.lang.runtime.ReferenceKey.StrongKey 
> java.lang.runtime.ReferenceKey.WeakKey 
> java.util.Digits.DecimalDigits 
> java.util.Digits.HexDigits 
> java.util.Digits.OctalDigits
> 
> This PR moves the nested classes to neighbouring package private classes

Looks good, a straight-forward rename/move of nested classes to package-private classes implementing a package-private interface.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14039#pullrequestreview-1442543998

From darcy at openjdk.org  Wed May 24 18:51:03 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 May 2023 18:51:03 GMT
Subject: RFR: 8174722: Wrong behavior of DecimalFormat with RoundingMode.UP
 in special case
In-Reply-To: <tc2WNaKDU6pGMiSlWQlh_Hfv3kY7xlIEzC_1m4qsJXI=.93a9520a-5161-4b9b-b60e-f05e2fc96dbc@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
 <Yx9RVsgO0XR7-qtJoJ6jJ-uI6n6Np2zU4T1_-PG9bGI=.0a2a9cbe-95c1-43ca-8f5e-1b70f370bea0@github.com>
 <tc2WNaKDU6pGMiSlWQlh_Hfv3kY7xlIEzC_1m4qsJXI=.93a9520a-5161-4b9b-b60e-f05e2fc96dbc@github.com>
Message-ID: <Ih7pe5C2S0z0sfzlx6g2L6XHb-JkTRa643CkUG1zRuM=.83acdc49-7b98-44dc-b50c-78dc820600f8@github.com>

On Wed, 24 May 2023 18:36:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> > I just wonder if it is ok to reverse the rounding/truncation only in this special case. If the truncation always comes first, then 0.00 would be correct (then 1.01 may be something wrong). Looks to me that the original comment suggests it tries to truncate those cases. I suggest filing a CSR for further behavioral consideration.
> 
> The normal behavior of DecimalFormat (DigitList) "rounds" before truncation. For example, consider
> 
> `1.0000009` formatted to `0.0` with `RoundingMode.UP`
> 
> DigitList will search past the maximum digits allowed to decide if the formatted value should be rounded. '9' will be found, and as such the value will be "rounded", by incrementing the value by 1 at the max digit location -> `1.1000009`, then DigitList will truncate -> `1.1`
> 
> Thus I believe that this change is aligning this special case to be consistent with the existing behavior of rounding before truncation. I will follow-up in the CSR.

A quick comment without diving into the particular issues here, for each finite floating-point value, there is a range of the real number line that will round to that floating-point value. Under the default rounding policy, some of those real numbers will be less than the floating-point value and other of those real numbers will be greater than the floating-point value.

So there are decimal strings corresponding to those numbers greater than and less than the floating-point value, all of which will get rounded to the same double value on string conversion.

If the operation is phrased in terms of *the floating-point value* and not *the real number value of what happened to be the input string*, then the actual real value of the floating-point number should be the reference point for rounding up/down on double -> String conversion.

This may give "surprising" results, but is numerically better. Without finding the bug ids, some previous changes were made to decimal format when rounding to nearest along those lines. HTH

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14110#issuecomment-1561765426

From viktor.klang at oracle.com  Wed May 24 18:51:24 2023
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 24 May 2023 18:51:24 +0000
Subject: Remove unnecessary method call in PriorityBlockingQueue
In-Reply-To: <6c79ca64-7e81-be4d-99ad-be3a6dd9d164@oracle.com>
References: <CAENJvPVUXR4NdCz6U6uH+s_tO2JP_vBzv7cjBzdstvxf0pfjTQ@mail.gmail.com>
 <6c79ca64-7e81-be4d-99ad-be3a6dd9d164@oracle.com>
Message-ID: <MW4PR10MB5774B0853A5BF7A5D9C6EFF9FF419@MW4PR10MB5774.namprd10.prod.outlook.com>

Sounds very reasonable.
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Aleksei Ivanov <alexey.ivanov at oracle.com>
Sent: Wednesday, 24 May 2023 20:03
To: Robin Gong <irobingong at gmail.com>; core-libs <core-libs-dev at openjdk.org>
Subject: Re: Remove unnecessary method call in PriorityBlockingQueue

Hi Robin,

This belongs in core-libs.

On 24/05/2023 16:50, Robin Gong wrote:
Hi,

Recently, I found this constructor in PriorityBlockingQueue:

    public PriorityBlockingQueue(int initialCapacity,
                                 Comparator<? super E> comparator) {
        if (initialCapacity < 1)
            throw new IllegalArgumentException();
        this.comparator = comparator;
        this.queue = new Object[Math.max(1, initialCapacity)];
    }

I believe we could change 'Math.max(1, initialCapacity)' to 'initialCapacity'. Since initialCapacity must be greater or equal to 1.

It looks reasonable to me.

--
Regards,
Alexey


And also that's how PriorityQueue running.

    public PriorityQueue(int initialCapacity,
                         Comparator<? super E> comparator) {
        // Note: This restriction of at least one is not actually needed,
        // but continues for 1.5 compatibility
        if (initialCapacity < 1)
            throw new IllegalArgumentException();
        this.queue = new Object[initialCapacity];
        this.comparator = comparator;
    }

Best regarts,
Robin Gong

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230524/9bc16f55/attachment.htm>

From darcy at openjdk.org  Wed May 24 18:52:58 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 May 2023 18:52:58 GMT
Subject: RFR: JDK-8308040 Evaluate new public types in non-public classes
In-Reply-To: <afI8vPnbCDVuF5xZLKamPqNyJjfPKykW6RnBmP4Q1tQ=.1e3ec34d-04e8-4de7-b3ee-bc1b5d5abdce@github.com>
References: <afI8vPnbCDVuF5xZLKamPqNyJjfPKykW6RnBmP4Q1tQ=.1e3ec34d-04e8-4de7-b3ee-bc1b5d5abdce@github.com>
Message-ID: <oUlufz8d6NBCe5WQEySocqYRPpRJ41f7c4bO3kNqmaw=.06da72e9-fbc0-4c00-ab77-6ae1abdaef7b@github.com>

On Wed, 17 May 2023 19:14:20 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> As reported by Marc Hoffman of javaalmanac.io, in a recent JDK 21 build there are new public types nested in non-public interfaces: 
> 
> java.lang.runtime.ReferenceKey.SoftKey 
> java.lang.runtime.ReferenceKey.StrongKey 
> java.lang.runtime.ReferenceKey.WeakKey 
> java.util.Digits.DecimalDigits 
> java.util.Digits.HexDigits 
> java.util.Digits.OctalDigits
> 
> This PR moves the nested classes to neighbouring package private classes

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14039#pullrequestreview-1442553002

From roger.riggs at oracle.com  Wed May 24 18:57:29 2023
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 24 May 2023 14:57:29 -0400
Subject: Remove unnecessary method call in PriorityBlockingQueue
In-Reply-To: <MW4PR10MB5774B0853A5BF7A5D9C6EFF9FF419@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAENJvPVUXR4NdCz6U6uH+s_tO2JP_vBzv7cjBzdstvxf0pfjTQ@mail.gmail.com>
 <6c79ca64-7e81-be4d-99ad-be3a6dd9d164@oracle.com>
 <MW4PR10MB5774B0853A5BF7A5D9C6EFF9FF419@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <c5340c0a-7b3d-7a85-77d8-8175583f3258@oracle.com>

Hi,

The upstream source of PriorityBlockingQueue is the concurrency library 
maintained by Doug Lea.
Noting this suggestion to the Concurrency Interest mailing list is 
recommended. [1]

Regards, Roger

[1] http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest

On 5/24/23 2:51 PM, Viktor Klang wrote:
> Sounds very reasonable.
> ------------------------------------------------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of 
> Aleksei Ivanov <alexey.ivanov at oracle.com>
> *Sent:* Wednesday, 24 May 2023 20:03
> *To:* Robin Gong <irobingong at gmail.com>; core-libs 
> <core-libs-dev at openjdk.org>
> *Subject:* Re: Remove unnecessary method call in PriorityBlockingQueue
> Hi Robin,
>
> This belongs in core-libs.
>
> On 24/05/2023 16:50, Robin Gong wrote:
>> Hi,
>>
>> Recently, I found this constructor in?PriorityBlockingQueue:
>>
>>     ? ? public PriorityBlockingQueue(int initialCapacity,
>>     ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Comparator<? super E> comparator) {
>>     ? ? ? ? if (initialCapacity < 1)
>>     ? ? ? ? ? ? throw new IllegalArgumentException();
>>     ? ? ? ? this.comparator = comparator;
>>     ? ? ? ? this.queue = new Object[Math.max(1, initialCapacity)];
>>     ? ? }
>>
>>
>> I believe we could change 'Math.max(1, initialCapacity)' to 
>> 'initialCapacity'. Since?initialCapacity must be greater or equal to 1.
>
> It looks reasonable to me.
>
> -- 
> Regards,
> Alexey
>
>>
>> And also that's how?PriorityQueue running.
>>
>>     ? ? public PriorityQueue(int initialCapacity,
>>     ? ? ? ? ? ? ? ? ? ? ? ? ?Comparator<? super E> comparator) {
>>     ? ? ? ? // Note: This restriction of at least one is not actually
>>     needed,
>>     ? ? ? ? // but continues for 1.5 compatibility
>>     ? ? ? ? if (initialCapacity < 1)
>>     ? ? ? ? ? ? throw new IllegalArgumentException();
>>     ? ? ? ? this.queue = new Object[initialCapacity];
>>     ? ? ? ? this.comparator = comparator;
>>     ? ? }
>>
>>
>> Best regarts,
>> Robin Gong
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230524/90b87d5d/attachment-0001.htm>

From jlaskey at openjdk.org  Wed May 24 19:12:09 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 24 May 2023 19:12:09 GMT
Subject: Integrated: JDK-8308040 Evaluate new public types in non-public
 classes
In-Reply-To: <afI8vPnbCDVuF5xZLKamPqNyJjfPKykW6RnBmP4Q1tQ=.1e3ec34d-04e8-4de7-b3ee-bc1b5d5abdce@github.com>
References: <afI8vPnbCDVuF5xZLKamPqNyJjfPKykW6RnBmP4Q1tQ=.1e3ec34d-04e8-4de7-b3ee-bc1b5d5abdce@github.com>
Message-ID: <toVijnlzUvZHVEMvSWTLdQfe89X6LTHbBqyS3OXJobw=.29017066-9893-41b6-b947-e834e4c79b83@github.com>

On Wed, 17 May 2023 19:14:20 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> As reported by Marc Hoffman of javaalmanac.io, in a recent JDK 21 build there are new public types nested in non-public interfaces: 
> 
> java.lang.runtime.ReferenceKey.SoftKey 
> java.lang.runtime.ReferenceKey.StrongKey 
> java.lang.runtime.ReferenceKey.WeakKey 
> java.util.Digits.DecimalDigits 
> java.util.Digits.HexDigits 
> java.util.Digits.OctalDigits
> 
> This PR moves the nested classes to neighbouring package private classes

This pull request has now been integrated.

Changeset: b44fa365
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b44fa365cacce0ae3f9e576a52c08d9ed6258185
Stats:     989 lines in 10 files changed: 586 ins; 396 del; 7 mod

8308040: Evaluate new public types in non-public classes

Reviewed-by: rriggs, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/14039

From erikj at openjdk.org  Wed May 24 19:16:58 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 24 May 2023 19:16:58 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <Z57cdvxsZ7RCp7kcVjkYGbhxfO_QseMrNCMRFueGREQ=.91b98af1-5d80-4a01-945d-08ebba55433c@github.com>
Message-ID: <4DLj_HAFFpv2ZhVaat71afM_xf3BPQ9sRW0FQOcRfr4=.8aac858e-55a9-4ed1-b397-ef84e73af2cc@github.com>

On Fri, 19 May 2023 21:20:19 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.
>
> I ran this patch in our internal build and test system and got failures on macos and windows. I think I know the cause for the mac failure, but the Windows failure I don't know. It looks like the same error I saw before after the original patch went in.
> 
> 
> [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): error C2220: the following warning is treated as an error
> [2023-05-19T20:51:31,466Z] c:\sb\prod\1684529071\workspace\open\src\hotspot\share\compiler\disassembler.cpp(792): warning C4267: '=': conversion from 'size_t' to 'int', possible loss of data
> [2023-05-19T20:51:31,466Z] lib/CompileJvm.gmk:152: recipe for target '/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj' failed
> [2023-05-19T20:51:31,466Z] make[3]: *** [/cygdrive/c/sb/prod/1684529071/workspace/build/windows-x64-open/hotspot/variant-server/libjvm/objs/static/disassembler.obj] Error 1

> Hi @erikj79 Please let me know if you have any additional comments for the PR. Could you please also help run through testing for the latest version? Thanks

I'm running a full set of builds now, but in my initial local build on mac, I see a lot of warnings like this:


.../Xcode/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/lib/libc++.tbd, ignoring unexpected dylib text stub file


Any idea what that could be caused by or if it's possible to eliminate?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561798109

From xuelei at openjdk.org  Wed May 24 19:20:10 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 24 May 2023 19:20:10 GMT
Subject: RFR: 8308022: update for deprecated sprintf for java.base [v2]
In-Reply-To: <5gmranDThlQlFLXa2i6t9E-z5tQrClncgNOErGSrfT8=.679ad5b9-ac56-418d-896f-1052fc6c4020@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
 <5gmranDThlQlFLXa2i6t9E-z5tQrClncgNOErGSrfT8=.679ad5b9-ac56-418d-896f-1052fc6c4020@github.com>
Message-ID: <z3H0q2y-ajS2GdTssGp5LkgHZl3GKVjHnEvnDZj6PmY=.348a0219-cdf7-498c-b6de-e7321a1f642a@github.com>

On Mon, 15 May 2023 17:21:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The libnet changes look reasonable to me.

@dfuch Thank you for the review.  This patch may be still too big as a few components were involved.  To easy to review process, I opened a new PR for libnet update, and will reverse the libnet changes in this PR.  Please review the [new PR](https://github.com/openjdk/jdk/pull/14132).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13963#issuecomment-1561796288

From xuelei at openjdk.org  Wed May 24 19:20:09 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 24 May 2023 19:20:09 GMT
Subject: RFR: 8308022: update for deprecated sprintf for java.base [v2]
In-Reply-To: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
Message-ID: <KoGd_keDUhRHvaB5YVqBVtzbuXxlaTdWdbrc1dylFK8=.6c7411d0-6c71-431f-8968-03e823774ca6@github.com>

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  exclude update for libnet

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13963/files
  - new: https://git.openjdk.org/jdk/pull/13963/files/363555b6..2247a56d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13963&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13963&range=00-01

  Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13963.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13963/head:pull/13963

PR: https://git.openjdk.org/jdk/pull/13963

From shade at openjdk.org  Wed May 24 19:26:50 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 24 May 2023 19:26:50 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java
Message-ID: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>

UUID is very important class that is used to track identities of objects in large scale systems. Yet, the coverage in JDK test is disappointing: it tests only 100 of UUID instances per test, which is way too small to detect collisions due to the bad randomness for example.

I have some pending work to improve UUID performance, and tests should be improved. 

The improved test still runs in less than 5 seconds on my laptop.

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/14134/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14134&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308803
  Stats: 163 lines in 1 file changed: 83 ins; 7 del; 73 mod
  Patch: https://git.openjdk.org/jdk/pull/14134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14134/head:pull/14134

PR: https://git.openjdk.org/jdk/pull/14134

From psandoz at openjdk.org  Wed May 24 20:29:58 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 24 May 2023 20:29:58 GMT
Subject: RFR: 8300491: SymbolLookup::libraryLookup accepts strings with
 terminators [v2]
In-Reply-To: <IcMxY0UOdnxnp9FoD-a9sLN4pmzCbMZLaKLH-icA5Uw=.31a30e6b-b96a-4d80-84b7-8f405d3148fc@github.com>
References: <CEGuI__aV-PjLH3s4i6AuQhnJ_Y3ukytNuBtuKCxAOE=.375bc90e-d127-4508-85ac-765125fe6873@github.com>
 <IcMxY0UOdnxnp9FoD-a9sLN4pmzCbMZLaKLH-icA5Uw=.31a30e6b-b96a-4d80-84b7-8f405d3148fc@github.com>
Message-ID: <n4nRIchaR_A35D5dfWZIGdTDTc3SFL6EnPG-Xw2H65I=.d49bb5d8-1829-482a-9009-cb7a06653e67@github.com>

On Wed, 24 May 2023 17:09:23 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> There is a difference in behavior between `System::loadLibrary` and `SymbolLookup::libraryLookup(String)`. While the former catches library names containing NULL chars (because, internally it uses Path/File logic, which reject those), `SymbolLookup` does not. As a result, it is possible to load libraries such as `libGL.so\0foobar`, because the string is passed directly to `dlopen`.
>> 
>> A similar issue arises when we consider `SymbolLookup::find`, as the name is again sent unmodified to `dlopen`. In reality, some filtering *does* happen in that case, as the native code calls `GetStringUTFChars`:
>> 
>> https://docs.oracle.com/en/java/javase/20/docs/specs/jni/functions.html#getstringutfchars
>> 
>> Which encodes the NULL chars in a different form:
>> 
>> https://docs.oracle.com/en/java/javase/20/docs/specs/jni/types.html#modified-utf-8-strings
>> 
>> So, in practice, even if the input is not validated, a call to `find` with one or more NULL chars is unlikely to succeed.
>> 
>> In this patch I have added several checks to make sure that:
>> * the name of library passed to `libraryLookup(String)` does not contain `\0` and, if so, throw `IllegalArgumentException` (which is already covered by current spec;
>> * the name of a symbol passed to `SymbolLookup::find` does not contain `\0` and, if so, return empty optional. This required changes on all the lookups we implement.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add test for system lookup

Marked as reviewed by psandoz (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14126#pullrequestreview-1442698703

From erikj at openjdk.org  Wed May 24 20:31:57 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 24 May 2023 20:31:57 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
Message-ID: <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>

On Mon, 22 May 2023 21:27:58 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Original description for JDK-8307194 change:
>> -----
>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
>> 
>>  - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>> 
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>> -----
>> 
>> Updates to address build failures reported on macosx-<cpu> platforms:
>> 
>> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
>> 
>> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
>> 
>> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   - Add $$($1_LD) $$($1_SYSROOT_LDFLAGS) to $1_VARDEPS if $(TOOLCHAIN_TYPE) is gcc or clang, as suggested by @erikj79.

My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message:


[2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so

make/common/NativeCompilation.gmk line 1210:

> 1208:         ifneq ($(findstring $(TOOLCHAIN_TYPE), gcc clang), )
> 1209: 	  $$(call ExecuteWithLog, $$($1_OBJECT_DIR)/$$($1_SAFE_NAME)_partial_link, \
> 1210: 	     $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \

Mac builds failed in our distributed system. I believe this will fix it:

Suggestion:

	      $(if $$($1_LINK_OBJS_RELATIVE), $$(CD) $$(OUTPUTDIR) ; ) \
	      $$($1_LD) $(LDFLAGS_CXX_PARTIAL_LINKING) $$($1_SYSROOT_LDFLAGS) \

It also looks like the indentation in this block is off, 3 spaces instead of 4.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14064#pullrequestreview-1442698087
PR Review Comment: https://git.openjdk.org/jdk/pull/14064#discussion_r1204726154

From jlu at openjdk.org  Wed May 24 20:37:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 24 May 2023 20:37:33 GMT
Subject: RFR: 8174722: Wrong behavior of DecimalFormat with RoundingMode.UP
 in special case [v2]
In-Reply-To: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
Message-ID: <gEcsserbD9lHyTCJefQyCy2P9Z1Xhn2A7Nm68pu2BvE=.c09ef670-58ef-48ab-ba38-2f4982a9bad8@github.com>

> Please review this PR, which addresses a case where Decimal Format would violate certain RoundingMode contracts given the right pattern and double.
> 
> For example,
> 
> 
> DecimalFormat df = new DecimalFormat();
> df.setRoundingMode(RoundingMode.UP);
> double small = 0.0001;
> double big = 1.0001;
> df.applyPattern("0.00");
> df.format(small); // returns 0.00, which violates UP
> df.format(big); // returns 1.01, which does not violate UP
> 
> 
> In this example `0.0001` becomes `0.00`, a decrease in magnitude. This violates the RoundingMode.UP contract as RoundingMode.UP states "Note that this rounding mode never decreases the magnitude of the calculated value."
> 
> This edge case is a result of when values smaller than the absolute value of `.1` have more leading zeros between the decimal and the first non-zero digit (_0.0001 -> **3**_) than maximum fractional digits in the pattern (_0.00 -> **2**_).
> 
> The change to Decimal Format ensures that during this case, the rounding mode is considered before truncation, which dictates if the formatted number should insert a 1 in the least significant digit location.
> 
> The test validates the change by using data from larger counterparts. For example, If we are testing `0.0009`, we can format `1.0009` with the same pattern and mode that we use on `0.0009`, then compare the fractional portions to each other and ensure they are equal.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Review: RAdjust test to not depend on a larger number counterpart

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14110/files
  - new: https://git.openjdk.org/jdk/pull/14110/files/5fbc601d..a8e1a81b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14110&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14110&range=00-01

  Stats: 74 lines in 1 file changed: 40 ins; 1 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/14110.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14110/head:pull/14110

PR: https://git.openjdk.org/jdk/pull/14110

From michaelm at openjdk.org  Wed May 24 20:46:23 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 24 May 2023 20:46:23 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v4]
In-Reply-To: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
Message-ID: <2rjN4GzOonpuRQUt_3QkkgAYJ1ZYs81tl8bpZ6wWpYY=.dfb0aeb3-32bc-4ede-bd45-041413455347@github.com>

> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
> 
> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).

Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into nullStrings
 - error message and test update
 - Merge branch 'master' into nullStrings
 - test comment update
 - test update
 - Merge branch 'master' into nullStrings
 - exception message update
 - test update
 - remve whitespace
 - update
 - ... and 2 more: https://git.openjdk.org/jdk/compare/207fbcb0...35df1a67

-------------

Changes: https://git.openjdk.org/jdk/pull/14083/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14083&range=03
  Stats: 188 lines in 9 files changed: 163 ins; 1 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/14083.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14083/head:pull/14083

PR: https://git.openjdk.org/jdk/pull/14083

From michaelm at openjdk.org  Wed May 24 20:46:23 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 24 May 2023 20:46:23 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v3]
In-Reply-To: <4k8EWVU6magkRGFo4MkojmXsZpdIW94CpdLPhKoYlcM=.d2a74b5b-cc20-4b06-a5a4-123edbeecca9@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
 <uGGlsyDavyKXLuI-Ok4tj1iDR7oJ8ZqFRzM1V8wWH7o=.74d82f35-33e4-4ada-a3b5-f90307125344@github.com>
 <4k8EWVU6magkRGFo4MkojmXsZpdIW94CpdLPhKoYlcM=.d2a74b5b-cc20-4b06-a5a4-123edbeecca9@github.com>
Message-ID: <8ZifTD2mMXOKHuqAbPvML6rpg8GCtq_lIyAMIzC0y0M=.cd5b1bfd-3770-4ab6-b2eb-d3ceba603c09@github.com>

On Wed, 24 May 2023 14:30:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I skimmed through the changes and mostly look okay. There's a few usage of "NULL" in exception messages that I assume should be "NUL character". Probably need to bump the copyright date on several files. You might want to find a better name for the test as NullChar isn't too descriptive, the test is really doing a lookup of a hostname that contains a NUL character. I assume there will be follow up issues to change other parts of the system to use the strict functions.

Thanks, I've updated per these comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14083#issuecomment-1561899890

From jiangli at openjdk.org  Wed May 24 21:02:00 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 24 May 2023 21:02:00 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v5]
In-Reply-To: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
Message-ID: <lGFitaAIrq_qUEjHdeqQHOgs14HPzDVuVa08CVOYovU=.c2108377-c67a-4411-8bbc-233e1ab236ca@github.com>

> Original description for JDK-8307194 change:
> -----
> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
> 
>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
> 
>  - For libjvm.a specifically, exclude operator_new.o
> 
> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
> 
> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
> 
> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
> -----
> 
> Updates to address build failures reported on macosx-<cpu> platforms:
> 
> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
> 
> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
> 
> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.

Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:

  Update make/common/NativeCompilation.gmk
  
  Thanks you!
  
  Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14064/files
  - new: https://git.openjdk.org/jdk/pull/14064/files/695bda5e..93366e38

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14064&range=03-04

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14064/head:pull/14064

PR: https://git.openjdk.org/jdk/pull/14064

From erikj at openjdk.org  Wed May 24 21:02:01 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 24 May 2023 21:02:01 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
 <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>
Message-ID: <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>

On Wed, 24 May 2023 20:29:09 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message:
> 
> ```
> [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so
> ```

If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561910764

From jiangli at openjdk.org  Wed May 24 21:02:01 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 24 May 2023 21:02:01 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
 <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>
 <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>
Message-ID: <dEk-GocelSVhW9mK_T9Id4WmRMcB55WC-6N_zphwHTU=.d0a91b63-b70f-4846-ab9d-a23915c04428@github.com>

On Wed, 24 May 2023 20:52:38 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message:
>> 
>> 
>> [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so
>
>> My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message:
>> 
>> ```
>> [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so
>> ```
> 
> If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems.

> > Hi @erikj79 Please let me know if you have any additional comments for the PR. Could you please also help run through testing for the latest version? Thanks
> 
> I'm running a full set of builds now, but in my initial local build on mac, I see a lot of warnings like this:
> 
> ```
> .../Xcode/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX11.1.sdk/usr/lib/libc++.tbd, ignoring unexpected dylib text stub file
> ```
> 
> Any idea what that could be caused by or if it's possible to eliminate?

I observed the same warnings on my macosx-x86_64 local build. It's from the partial linking step. Not much information yielded when I searched for `ignoring unexpected dylib text stub file`. Search found https://opensource.apple.com/source/ld64/ld64-609/src/ld/InputFiles.cpp with the linker code throwing the warning (`dylibsNotAllowed` is true if `_options.outputKind` is `Options::kObjectFile`, which is related to what we are observing). 

I tried linking a `javastatic` executable using the static libraries created with partial linking on macosx-x86_64 last week. I was able to execute `javastatic` in my quick test but didn't go further for more verification, as the runtime didn't work with the static build yet. 

Haven't found any information on how to suppress the warning either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561913004

From duke at openjdk.org  Wed May 24 21:29:59 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 24 May 2023 21:29:59 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v5]
In-Reply-To: <ykcFwiqBUh0Zhz9R52XDkiWEFRZYTqBwZ4WiB4EIFdQ=.7fb9c7a9-7b59-477d-b802-4a2f9805b3b6@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <ykcFwiqBUh0Zhz9R52XDkiWEFRZYTqBwZ4WiB4EIFdQ=.7fb9c7a9-7b59-477d-b802-4a2f9805b3b6@github.com>
Message-ID: <4jBqLkF5t_u3cPJhSC1AIzD3ZNotrFZgqkM_7SseXHc=.60b38d03-ce57-43ab-b57f-a6364638cebe@github.com>

On Wed, 24 May 2023 09:22:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop "unsigned short"
>   Beef up javadoc

test/jdk/java/foreign/normalize/TestNormalize.java line 169:

> 167:             { JAVA_BOOLEAN, booleanToInt(true),     BOOLEAN_HOB_MASK, BOOLEAN_TO_INT, SAVE_BOOLEAN_AS_INT },
> 168:             { JAVA_BYTE,    byteToInt((byte) 42),   BYTE_HOB_MASK,    BYTE_TO_INT,    SAVE_BYTE_AS_INT    },
> 169:             { JAVA_SHORT,   shortToInt((short) 42), SHORT_HOB_MASK,   SHORT_TO_INT,   SAVE_SHORT_AS_INT   }

Since?arrays?support trailing?commas, this?can?use?that:
Suggestion:

            { JAVA_SHORT,   shortToInt((short) 42), SHORT_HOB_MASK,   SHORT_TO_INT,   SAVE_SHORT_AS_INT   },

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14037#discussion_r1204774626

From jiangli at openjdk.org  Wed May 24 21:50:55 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 24 May 2023 21:50:55 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
 <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>
 <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>
Message-ID: <De483G2Bvse6UB0b1PcuEDjX7Er_D0HYfQa8U3Ln9dQ=.8800cca1-748d-43f2-bafc-419a64643d77@github.com>

On Wed, 24 May 2023 20:52:38 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

> > My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message:
> > ```
> > [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so
> > ```
> 
> If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems.

The partial linking was originally suggested by C++/Clang toolchain folks to mitigate linker overhead that was observed during final executable link time. For a static library containing any object file (`.o`) that was compiled with ThinLTO (https://clang.llvm.org/docs/ThinLTO.html) enabled, linking an executable using the static library without distributed ThinLTO could experience more overhead and slow down linking. Solving the macosx `ar` limitation is a side-effect/benefit of using partial linking. We probably would want to include the partial linking even without the `ar` limitation.

Is it possible `$$($1_SYSROOT_LDFLAGS)` pulled in `libstdc++.so` as part of the input for partial linking with the linux-aarch64 cross build?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1561969001

From mdoerr at openjdk.org  Wed May 24 22:33:54 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 24 May 2023 22:33:54 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size
In-Reply-To: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
Message-ID: <g_yMICvnMScOzWzCQrUc3VfxUs8NlNFeK0_2dBXP6H0=.e6366982-55b0-488a-bebf-bb255da7786b@github.com>

On Fri, 19 May 2023 19:19:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
> 
> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
> The enum values directly reflect the build-time artifacts and resulting executables.
> 
> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.

I think the mapping from ppc64le to ppc64 should get removed with the introduction of ppc64le as separate architecture:
https://github.com/openjdk/jdk/blob/64f6681cc7bb184112adcf2b4f2c313e1b0a5c4f/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/Platform.java#LL55C5-L55C5
Would you mind removing it with your change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14063#issuecomment-1562010424

From naoto at openjdk.org  Wed May 24 22:48:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 24 May 2023 22:48:53 GMT
Subject: RFR: 8174722: Wrong behavior of DecimalFormat with RoundingMode.UP
 in special case
In-Reply-To: <Ih7pe5C2S0z0sfzlx6g2L6XHb-JkTRa643CkUG1zRuM=.83acdc49-7b98-44dc-b50c-78dc820600f8@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
 <Yx9RVsgO0XR7-qtJoJ6jJ-uI6n6Np2zU4T1_-PG9bGI=.0a2a9cbe-95c1-43ca-8f5e-1b70f370bea0@github.com>
 <tc2WNaKDU6pGMiSlWQlh_Hfv3kY7xlIEzC_1m4qsJXI=.93a9520a-5161-4b9b-b60e-f05e2fc96dbc@github.com>
 <Ih7pe5C2S0z0sfzlx6g2L6XHb-JkTRa643CkUG1zRuM=.83acdc49-7b98-44dc-b50c-78dc820600f8@github.com>
Message-ID: <Sdnhed6W7Dnu8SRsTFGl76Dr6-F5Mis40kZp5l9johA=.04c3e743-8d85-4e12-9d18-087b54321d2c@github.com>

On Wed, 24 May 2023 18:47:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>>> I just wonder if it is ok to reverse the rounding/truncation only in this special case. If the truncation always comes first, then 0.00 would be correct (then 1.01 may be something wrong). Looks to me that the original comment suggests it tries to truncate those cases. I suggest filing a CSR for further behavioral consideration.
>> 
>> The normal behavior of DecimalFormat (DigitList) "rounds" before truncation. For example, consider
>> 
>> `1.0000009` formatted to `0.0` with `RoundingMode.UP`
>> 
>> DigitList will search past the maximum digits allowed to decide if the formatted value should be rounded. '9' will be found, and as such the value will be "rounded", by incrementing the value by 1 at the max digit location -> `1.1000009`, then DigitList will truncate -> `1.1`
>> 
>> Thus I believe that this change is aligning this special case to be consistent with the existing behavior of rounding before truncation. I will follow-up in the CSR.
>
>> > I just wonder if it is ok to reverse the rounding/truncation only in this special case. If the truncation always comes first, then 0.00 would be correct (then 1.01 may be something wrong). Looks to me that the original comment suggests it tries to truncate those cases. I suggest filing a CSR for further behavioral consideration.
>> 
>> The normal behavior of DecimalFormat (DigitList) "rounds" before truncation. For example, consider
>> 
>> `1.0000009` formatted to `0.0` with `RoundingMode.UP`
>> 
>> DigitList will search past the maximum digits allowed to decide if the formatted value should be rounded. '9' will be found, and as such the value will be "rounded", by incrementing the value by 1 at the max digit location -> `1.1000009`, then DigitList will truncate -> `1.1`
>> 
>> Thus I believe that this change is aligning this special case to be consistent with the existing behavior of rounding before truncation. I will follow-up in the CSR.
> 
> A quick comment without diving into the particular issues here, for each finite floating-point value, there is a range of the real number line that will round to that floating-point value. Under the default rounding policy, some of those real numbers will be less than the floating-point value and other of those real numbers will be greater than the floating-point value.
> 
> So there are decimal strings corresponding to those numbers greater than and less than the floating-point value, all of which will get rounded to the same double value on string conversion.
> 
> If the operation is phrased in terms of *the floating-point value* and not *the real number value of what happened to be the input string*, then the actual real value of the floating-point number should be the reference point for rounding up/down on double -> String conversion.
> 
> This may give "surprising" results, but is numerically better. Without finding the bug ids, some previous changes were made to decimal format when rounding to nearest along those lines. HTH

Hi @jddarcy , are you referring to the cases like this:https://bugs.openjdk.org/browse/JDK-8062756 ? I understand the binary representation of real number could be below the real number, then the rounding may look strange, but in this particular case, I believe it won't affect the result, as the fix is to the following specific condition (excerpt of the comment there):

                // Handle an underflow to zero when we round something like
                // 0.0009 to 2 fractional digits.

So even if the number `0.0001` is represented by `0.00009999999something` it should round up to `0.01`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14110#issuecomment-1562021619

From prappo at openjdk.org  Wed May 24 23:40:08 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 24 May 2023 23:40:08 GMT
Subject: RFR: 8308735: Typos in parameter names
Message-ID: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>

Please review this simple fix.

-------------

Commit messages:
 - Fix typos

Changes: https://git.openjdk.org/jdk/pull/14136/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14136&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308735
  Stats: 9 lines in 3 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/14136.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14136/head:pull/14136

PR: https://git.openjdk.org/jdk/pull/14136

From naoto at openjdk.org  Wed May 24 23:48:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 24 May 2023 23:48:54 GMT
Subject: RFR: 8308735: Typos in parameter names
In-Reply-To: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
References: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
Message-ID: <GCXNO-3PD2aiPHTt0ED85Ar-t5AzjuY6K-iH55zFjkY=.a90ad455-9f10-422b-9388-7512de40e1fe@github.com>

On Wed, 24 May 2023 23:32:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple fix.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14136#pullrequestreview-1442893076

From iris at openjdk.org  Wed May 24 23:51:58 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 24 May 2023 23:51:58 GMT
Subject: RFR: 8308735: Typos in parameter names
In-Reply-To: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
References: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
Message-ID: <uuBk1h6H98pDt4Yg5krFLuaoh_Rw_SmKMkYju0kWD4Y=.4b6f346a-e457-47b5-b6e9-00cbe226244a@github.com>

On Wed, 24 May 2023 23:32:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple fix.

Looks good.  (I'm not sure I'd characterize this as a "typo", more like a failure to adjust "cut and paste" replication.  Regardless you're fixing an error.)

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14136#pullrequestreview-1442894523

From bpb at openjdk.org  Thu May 25 00:44:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 25 May 2023 00:44:04 GMT
Subject: RFR: 8308735: Typos in parameter names
In-Reply-To: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
References: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
Message-ID: <ocwU73Dwx6Mp5t1yDJTzlB5kZu1fXFMihCZfxNOX9VY=.bca2c00f-df12-4548-93ba-3c6e03f078db@github.com>

On Wed, 24 May 2023 23:32:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple fix.

+1

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14136#pullrequestreview-1442923610

From jiangli at openjdk.org  Thu May 25 01:22:02 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Thu, 25 May 2023 01:22:02 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <De483G2Bvse6UB0b1PcuEDjX7Er_D0HYfQa8U3Ln9dQ=.8800cca1-748d-43f2-bafc-419a64643d77@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
 <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>
 <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>
 <De483G2Bvse6UB0b1PcuEDjX7Er_D0HYfQa8U3Ln9dQ=.8800cca1-748d-43f2-bafc-419a64643d77@github.com>
Message-ID: <nyP_xGJqxSRrMGArbCqN03qRaifxETOgcdzElL_0MGw=.e3d3e454-393a-49e6-a0fc-2473189f4424@github.com>

On Wed, 24 May 2023 21:47:49 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > > My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message:
> > > ```
> > > [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so
> > > ```
> > 
> > 
> > If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems.
> 
> The partial linking was originally suggested by C++/Clang toolchain folks to mitigate linker overhead that was observed during final executable link time. For a static library containing any object file (`.o`) that was compiled with ThinLTO (https://clang.llvm.org/docs/ThinLTO.html) enabled, linking an executable using the static library without distributed ThinLTO could experience more overhead and slow down linking. Solving the macosx `ar` limitation is a side-effect/benefit of using partial linking. We probably would want to include the partial linking even without the `ar` limitation.
> 
> Is it possible `$$($1_SYSROOT_LDFLAGS)` pulled in `libstdc++.so` as part of the input for partial linking with the linux-aarch64 cross build?

Another possibility might be the user provided `BUILD_LDCXX` includes extra options in the testing build (?). If that's the case, we probably could define a separate `BUILD_LD_PARTIAL` with no added options. In our prototype on JDK 11, we define a separate one for partial linking.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1562128417

From lmesnik at openjdk.org  Thu May 25 01:25:55 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 25 May 2023 01:25:55 GMT
Subject: RFR: 8308475: Make the thread dump files generated by jcmd
 Thread.dump_to_file jtreg failure handler action easily accessible
In-Reply-To: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>
References: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>
Message-ID: <u4P2YycIkMYoMzk73bxuLAnEPGnOVxZStoRGFOHBsUQ=.bf420abd-e9f2-48c6-b5ce-f14084cd6a47@github.com>

On Sun, 21 May 2023 09:19:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to improve the accessibility of the thread dump files that are generated by the `jcmd Thread.dump_to_file` command configured in the failure handler configurations? This addresses https://bugs.openjdk.org/browse/JDK-8308475. 
> 
> The changes in this PR include:
>  - Enhancement to `GatherProcessInfoTimeoutHandler` to allow configuring a `successArtifacts` action parameter which can be used to generate links to files that are generated by the failure handler commands.
>  - Introduction of a `%iterCount` token to allow ability to refer to the current iteration when the command is repeated
>  - The `jcmd Thread.dump_to_file` is now configured to create the thread dumps in `json` format. Additionally, it has now been configured to create the thread dumps 6 times, just like the `jstack` command.
> 
> Detailed explanation of the `successArtifacts` parameter and the `%iterCount` token is provided in the JBS comment here https://bugs.openjdk.org/browse/JDK-8308475?focusedCommentId=14583072&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14583072
> 
> Tests have been run locally with this change and tier1, tier2 and tier3 tests on CI system to verify this change works and doesn't cause regression.

Cool!

-------------

Marked as reviewed by lmesnik (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14071#pullrequestreview-1442947346

From dholmes at openjdk.org  Thu May 25 01:36:55 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 May 2023 01:36:55 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <HcUA6rbzCg3rlA_EGlZkm4n1aGAV4HnkkE11GKRBT7U=.137f14ae-54f7-4fc6-a363-4d11f4eb2eb2@github.com>

On Wed, 24 May 2023 13:56:05 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

I think the JNI type definition change is okay.

However many of the other changes appear to me to not involve Java variables and so don't need to be Java types i.e they should be `int` rather than `jint` - though as these are native Windows types there may not actually be any reason to change them from `long`. This is for the client-libs folk to decide.

src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp line 325:

> 323:     }
> 324: 
> 325:     jint sx, sy, ex, ey;

These are not Java variables. They get passed to the win32 GDI Arc function below which expects `int`.

src/java.desktop/windows/native/libawt/java2d/windows/GDIRenderer.cpp line 605:

> 603:         return;
> 604:     }
> 605:     jint sx, sy, ex, ey;

Again these don't seem to need to be Java types.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14125#pullrequestreview-1442950619
PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1204903525
PR Review Comment: https://git.openjdk.org/jdk/pull/14125#discussion_r1204904147

From david.holmes at oracle.com  Thu May 25 02:57:28 2023
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 25 May 2023 12:57:28 +1000
Subject: [External] : Re: Classes used in method body are loaded lazily or
 eagerly depending on method return type
In-Reply-To: <2cf71b1c-7ac1-e158-1c80-762caa3e6e82@oracle.com>
References: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
 <c4954b0c-ca2a-7cb1-4710-36af333e7d06@oracle.com>
 <59b1c6ff-ab08-8a8f-12b7-21f78285571b@oracle.com>
 <1813541396.62977656.1684881306040.JavaMail.zimbra@univ-eiffel.fr>
 <2cf71b1c-7ac1-e158-1c80-762caa3e6e82@oracle.com>
Message-ID: <36c13724-9c08-c082-67ab-fa24773314ec@oracle.com>

On 25/05/2023 12:34 am, Raffaello Giulietti wrote:
> As mentioned in my previous email, if you move the member class 
> ChildClass out of TestLoading (out of the nest), and make it a top-level 
> class like
> 
>  ??? public class ChildClass extends TestLoading.BaseClass {
>  ??? }
> 
> and change
> 
>  ??? URL classFileB = 
> TestLoading.class.getResource(TestLoading.class.getSimpleName() + 
> "$ChildClass.class");
> 
> to
> 
>  ??? URL classFileB = 
> TestLoading.class.getResource(ChildClass.class.getSimpleName() + ".class");
> 
> rebuild everything and run, nothing is thrown.
> 
>  ??? deleting: <path-to>/ChildClass.class
>  ??? loading: TestLoading$ObjectReturner...
>  ??? loading: TestLoading$BaseClassReturner...
> 
> I can't see any substantial difference, except that the nest rooted at 
> TestLoading lacks a member in the original setup and lacks nothing in 
> this setup.
> 
> What's an explanation for this difference?

Are you sure it actually deletes the file? What do you see when you 
enable class+load/init and verification logging?

David
-----



> 
> Greetings
> Raffaello
> 
> 
> On 2023-05-24 00:35, Remi Forax wrote:
>>
>>
>> ----- Original Message -----
>>> From: "David Holmes" <david.holmes at oracle.com>
>>> To: "Raffaello Giulietti" <raffaello.giulietti at oracle.com>, 
>>> "core-libs-dev" <core-libs-dev at openjdk.org>
>>> Sent: Wednesday, May 24, 2023 12:23:24 AM
>>> Subject: Re: Classes used in method body are loaded lazily or eagerly 
>>> depending on method return type
>>
>>> On 24/05/2023 12:50 am, Raffaello Giulietti wrote:
>>>> I think the problem here is that you are deleting a class in a nest.
>>>>
>>>> During the verification of BaseClassReturner.getObject(), access 
>>>> control
>>>> (JVMS, 5.4.4, second half) determines that the nest is broken, as
>>>> ChildClass is not present anymore.
>>>
>>> Not sure access control gets involved at this stage of the verification
>>> process. But in any case turning on logging does not show anything
>>> related to nestmates happening between BaseClass and ChildClass. It
>>> seems to just be the resolution of the return type during verification
>>> of the method, that causes the loading of ChildClass and the subsequent
>>> CNFE if it has been removed.
>>>
>>>> If you move ChildClass out of TestLoading so that it becomes a 
>>>> top-level
>>>> class extending TestLoading.BaseClass, and if you adapt the line that
>>>> initializes the local var classFileB to refer to the new location, the
>>>> code will not throw, despite ChildClass being deleted.
>>>
>>> My simplified test shows it still throws when verifying 
>>> BaseClassReturner.
>>
>> Nestmate checking is done lazily, so if you do not call a 
>> method/access a field of a nested class, the VM should not trigger a 
>> class loading.
>>
>> Moreover, if you test with Java 8 (nestmates were introduced in Java 
>> 11), it failed too.
>> That's another clue that the error is not related to nestmates checking.
>>
>>>
>>>
>>> Cheers,
>>> David
>>
>> regards,
>> R?mi
>>
>>>
>>>>
>>>> Greetings
>>>> Raffaello
>>>>
>>>>
>>>>
>>>> On 2023-05-23 13:20, ?????? ??????? wrote:
>>>>> Hello,
>>>>>
>>>>> originally this question was asked here:
>>>>> https://urldefense.com/v3/__https://stackoverflow.com/q/76260269/12473843__;!!ACWV5N9M2RV99hQ!Mb5nhj7EbuftWzF7s4GX9auUZZlyPyCUnLs64c4mkmSGJm4pw0CNgRzQR5wOYuApyE_kHSAnVxGyTM9PHz5StCppGw$ ,
>>>>> the code sample for reproduction will be put below or can be found via
>>>>> the link
>>>>>
>>>>> The issue is about eager/lazy loading of a class depending on method
>>>>> return type.
>>>>> If one runs the code below with Java 11-19 it will fail with
>>>>> NoClassDefFoundError (this is expected as delete class file for
>>>>> ChildClass):
>>>>>
>>>>> java.lang.NoClassDefFoundError: org/example/TestLoading$ChildClass
>>>>> ?????at java.base/java.lang.Class.forName0(Native Method)
>>>>> ?????at java.base/java.lang.Class.forName(Class.java:390)
>>>>> ?????at java.base/java.lang.Class.forName(Class.java:381)
>>>>> ?????at org.example.TestLoading.loadMyClass(TestLoading.java:29)
>>>>> ?????at org.example.TestLoading.main(TestLoading.java:23)
>>>>> Caused by: java.lang.ClassNotFoundException:
>>>>> org.example.TestLoading$ChildClass
>>>>> ?????at
>>>>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>>>>> ?????at
>>>>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>>>>> ?????at 
>>>>> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>>>>> ?????... 5 more
>>>>>
>>>>> As of Java 20 chapter 12.4.1 of JLS states:
>>>>> ---------------------------------------------------------
>>>>> A class or interface T will be initialized immediately before the
>>>>> first occurrence of any one of the following:
>>>>>
>>>>> - T is a class and an instance of T is created.
>>>>> - a static method declared by T is invoked.
>>>>> - a static field declared by T is assigned.
>>>>> - a static field declared by T is used and the field is not a constant
>>>>> variable (?4.12.4).
>>>>>
>>>>> When a class is initialized, its superclasses are initialized (if they
>>>>> have not been previously initialized), as well as any superinterfaces
>>>>> (?8.1.5) that declare any default methods (?9.4.3) (if they have not
>>>>> been previously initialized).
>>>>> Initialization of an interface does not, of itself, cause
>>>>> initialization of any of its superinterfaces.
>>>>> A reference to a static field (?8.3.1.1) causes initialization of only
>>>>> the class or interface that actually declares it, even though it might
>>>>> be referred to through the name of a subclass, a subinterface, or a
>>>>> class that implements an interface.
>>>>> Invocation of certain reflective methods in class Class and in package
>>>>> java.lang.reflect also causes class or interface initialization.
>>>>> A class or interface will not be initialized under any other
>>>>> circumstance.
>>>>> ---------------------------------------------------------
>>>>> With the code snippet we see that calling
>>>>> Class.forName(ObjectReturner.class.getName()) succeeds and
>>>>> Class.forName(BaseClassReturner.class.getName()) fails even though
>>>>> both declare returning an instance of ChildClass.
>>>>> This failure is unexpected as in the code below we don't fulfill any
>>>>> requirement for class loading as of JLS 12.4.1, but the JVM still
>>>>> tries to load the class.
>>>>>
>>>>> I suspect it might be related to class file validation and/or
>>>>> security, because when we run the code with -Xlog:class+init there's a
>>>>> reference to LinkageError in loading log:
>>>>>
>>>>> loading: org.example.TestLoading$BaseClassReturner...
>>>>> [0.277s][info][class,init] Start class verification for:
>>>>> org.example.TestLoading$BaseClassReturner
>>>>> [0.277s][info][class,init] 771 Initializing
>>>>> 'java/lang/ReflectiveOperationException'(no method) 
>>>>> (0x0000000800004028)
>>>>> [0.277s][info][class,init] 772 Initializing
>>>>> 'java/lang/ClassNotFoundException'(no method) (0x0000000800004288)
>>>>> [0.277s][info][class,init] 773 Initializing
>>>>> 'java/lang/LinkageError'(no method)
>>>>> (0x00000008000044f8)????????????????????????????????? <----
>>>>> [0.277s][info][class,init] 774 Initializing
>>>>> 'java/lang/NoClassDefFoundError'(no method) (0x0000000800004758)
>>>>> [0.277s][info][class,init] Verification for
>>>>> org.example.TestLoading$BaseClassReturner has exception pending
>>>>> 'java.lang.NoClassDefFoundError org/example/TestLoading$ChildClass'
>>>>> [0.277s][info][class,init] End class verification for:
>>>>> org.example.TestLoading$BaseClassReturner
>>>>>
>>>>>
>>>>> So I've got three questions about this:
>>>>> - Does class loading depend on method's return type?
>>>>> - Which part of JLS/JVM spec describes eager class loading in this 
>>>>> case?
>>>>> - Could one point out the particular piece of the VM code responsible
>>>>> for class loading in this case?
>>>>>
>>>>> Regards,
>>>>> Sergey Tsypanov
>>>>>
>>>>> Code snippet for reproduction:
>>>>>
>>>>> public class TestLoading {
>>>>>
>>>>> ??? public static void main(String[] args) throws Exception {
>>>>> ????? Class.forName(BaseClass.class.getName());
>>>>> ????? URL classFileB =
>>>>> TestLoading.class.getResource(TestLoading.class.getSimpleName() +
>>>>> "$ChildClass.class");
>>>>> ????? if (classFileB != null) {
>>>>> ??????? if (!"file".equals(classFileB.getProtocol())) {
>>>>> ????????? throw new UnsupportedOperationException();
>>>>> ??????? }
>>>>> ??????? Path path = new File(classFileB.getPath()).toPath();
>>>>> ??????? System.out.println("deleting: " + path);
>>>>> ??????? Files.delete(path);
>>>>> ????? }
>>>>>
>>>>> ????? loadMyClass(ObjectReturner.class.getName());
>>>>> ????? loadMyClass(BaseClassReturner.class.getName());
>>>>> ??? }
>>>>>
>>>>> ??? private static void loadMyClass(String name) {
>>>>> ????? System.out.println("loading: " + name + "...");
>>>>> ????? try {
>>>>> ??????? Class.forName(name);
>>>>> ????? } catch (Throwable e) {
>>>>> ??????? e.printStackTrace(System.out);
>>>>> ????? }
>>>>> ??? }
>>>>>
>>>>> ??? public static class BaseClass {
>>>>> ??? }
>>>>>
>>>>> ??? public static class ChildClass extends BaseClass {
>>>>> ??? }
>>>>>
>>>>> ??? public static class ObjectReturner {
>>>>> ????? public Object getObject() {
>>>>> ??????? return new ChildClass();
>>>>> ????? }
>>>>> ??? }
>>>>>
>>>>> ??? public static class BaseClassReturner {
>>>>> ????? public BaseClass getObject() {
>>>>> ??????? return new ChildClass();
>>>>> ????? }
>>>>> ??? }
>>>>> }

From jpai at openjdk.org  Thu May 25 04:48:54 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 25 May 2023 04:48:54 GMT
Subject: RFR: 8308475: Make the thread dump files generated by jcmd
 Thread.dump_to_file jtreg failure handler action easily accessible
In-Reply-To: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>
References: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>
Message-ID: <FuluYhtbVFpq6ewUAaq-3UY6ajTOHUQoz7IAfNKXaNw=.fae35f53-137b-405e-9b99-7f3680e29cca@github.com>

On Sun, 21 May 2023 09:19:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to improve the accessibility of the thread dump files that are generated by the `jcmd Thread.dump_to_file` command configured in the failure handler configurations? This addresses https://bugs.openjdk.org/browse/JDK-8308475. 
> 
> The changes in this PR include:
>  - Enhancement to `GatherProcessInfoTimeoutHandler` to allow configuring a `successArtifacts` action parameter which can be used to generate links to files that are generated by the failure handler commands.
>  - Introduction of a `%iterCount` token to allow ability to refer to the current iteration when the command is repeated
>  - The `jcmd Thread.dump_to_file` is now configured to create the thread dumps in `json` format. Additionally, it has now been configured to create the thread dumps 6 times, just like the `jstack` command.
> 
> Detailed explanation of the `successArtifacts` parameter and the `%iterCount` token is provided in the JBS comment here https://bugs.openjdk.org/browse/JDK-8308475?focusedCommentId=14583072&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14583072
> 
> Tests have been run locally with this change and tier1, tier2 and tier3 tests on CI system to verify this change works and doesn't cause regression.

Thank you Leonid for the review.

Since this is tagged hotspot, can I please get a second Reviewer to review this please?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14071#issuecomment-1562259531

From david.holmes at oracle.com  Thu May 25 05:50:29 2023
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 25 May 2023 15:50:29 +1000
Subject: Remove unnecessary method call in PriorityBlockingQueue
In-Reply-To: <c5340c0a-7b3d-7a85-77d8-8175583f3258@oracle.com>
References: <CAENJvPVUXR4NdCz6U6uH+s_tO2JP_vBzv7cjBzdstvxf0pfjTQ@mail.gmail.com>
 <6c79ca64-7e81-be4d-99ad-be3a6dd9d164@oracle.com>
 <MW4PR10MB5774B0853A5BF7A5D9C6EFF9FF419@MW4PR10MB5774.namprd10.prod.outlook.com>
 <c5340c0a-7b3d-7a85-77d8-8175583f3258@oracle.com>
Message-ID: <ea948a5e-d0d8-ee8a-bcd4-33feb0fdca1f@oracle.com>

Hi Roger,

On 25/05/2023 4:57 am, Roger Riggs wrote:
> Hi,
> 
> The upstream source of PriorityBlockingQueue is the concurrency library 
> maintained by Doug Lea.
> Noting this suggestion to the Concurrency Interest mailing list is 
> recommended. [1]

Unfortunately Doug's mailing list has never returned after his mail 
server outage.

David

> Regards, Roger
> 
> [1] http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
> 
> On 5/24/23 2:51 PM, Viktor Klang wrote:
>> Sounds very reasonable.
>> ------------------------------------------------------------------------
>> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of 
>> Aleksei Ivanov <alexey.ivanov at oracle.com>
>> *Sent:* Wednesday, 24 May 2023 20:03
>> *To:* Robin Gong <irobingong at gmail.com>; core-libs 
>> <core-libs-dev at openjdk.org>
>> *Subject:* Re: Remove unnecessary method call in PriorityBlockingQueue
>> Hi Robin,
>>
>> This belongs in core-libs.
>>
>> On 24/05/2023 16:50, Robin Gong wrote:
>>> Hi,
>>>
>>> Recently, I found this constructor in?PriorityBlockingQueue:
>>>
>>>     ? ? public PriorityBlockingQueue(int initialCapacity,
>>>     ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?Comparator<? super E> comparator) {
>>>     ? ? ? ? if (initialCapacity < 1)
>>>     ? ? ? ? ? ? throw new IllegalArgumentException();
>>>     ? ? ? ? this.comparator = comparator;
>>>     ? ? ? ? this.queue = new Object[Math.max(1, initialCapacity)];
>>>     ? ? }
>>>
>>>
>>> I believe we could change 'Math.max(1, initialCapacity)' to 
>>> 'initialCapacity'. Since?initialCapacity must be greater or equal to 1.
>>
>> It looks reasonable to me.
>>
>> -- 
>> Regards,
>> Alexey
>>
>>>
>>> And also that's how?PriorityQueue running.
>>>
>>>     ? ? public PriorityQueue(int initialCapacity,
>>>     ? ? ? ? ? ? ? ? ? ? ? ? ?Comparator<? super E> comparator) {
>>>     ? ? ? ? // Note: This restriction of at least one is not actually
>>>     needed,
>>>     ? ? ? ? // but continues for 1.5 compatibility
>>>     ? ? ? ? if (initialCapacity < 1)
>>>     ? ? ? ? ? ? throw new IllegalArgumentException();
>>>     ? ? ? ? this.queue = new Object[initialCapacity];
>>>     ? ? ? ? this.comparator = comparator;
>>>     ? ? }
>>>
>>>
>>> Best regarts,
>>> Robin Gong
>>
> 

From asotona at openjdk.org  Thu May 25 07:17:07 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 25 May 2023 07:17:07 GMT
Subject: Integrated: 8308549: Classfile API should fail to generate over-sized
 Code attribute
In-Reply-To: <FMfhhGe4XrEG4Brj1GZS69ovfeNMSAEeLwlMq05SzwA=.7014deec-41a2-44cc-b4bd-51f3f71f291b@github.com>
References: <FMfhhGe4XrEG4Brj1GZS69ovfeNMSAEeLwlMq05SzwA=.7014deec-41a2-44cc-b4bd-51f3f71f291b@github.com>
Message-ID: <-HFj9b0lA7k6IC75I0xuQRYbRu7vbze9abjwdYNNFkE=.8bc1c603-935b-43e2-801b-8dc49caf9413@github.com>

On Tue, 23 May 2023 12:54:20 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Classfile API allowed to generate Code attribute exceeding the 65k limit. No exception has been thrown during class generation and the class failed verification later during class loading.
> This patch adds Code size limit check throwing IllegalArgumentException.
> The patch also adds similar check for constant pool size limit to avoid generation class file with corrupted  constant pool.
> Two new tests are added to check response on oversized Code attribute and constant pool.
> `VerifierImpl` is extended to check Code attribute size as a part of class verification process.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: bfcae68e
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfcae68ed10e4330c35f5de0bdb2d31e44e2872e
Stats:     50 lines in 6 files changed: 45 ins; 0 del; 5 mod

8308549: Classfile API should fail to generate over-sized Code attribute

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/14100

From dholmes at openjdk.org  Thu May 25 07:21:56 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 May 2023 07:21:56 GMT
Subject: RFR: 8308475: Make the thread dump files generated by jcmd
 Thread.dump_to_file jtreg failure handler action easily accessible
In-Reply-To: <FuluYhtbVFpq6ewUAaq-3UY6ajTOHUQoz7IAfNKXaNw=.fae35f53-137b-405e-9b99-7f3680e29cca@github.com>
References: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>
 <FuluYhtbVFpq6ewUAaq-3UY6ajTOHUQoz7IAfNKXaNw=.fae35f53-137b-405e-9b99-7f3680e29cca@github.com>
Message-ID: <Jj39tdKY-5xnHFE5HT4JkH9D0fKQwF6iBtnQ_6eHNeM=.5dac86d3-03d4-4e0a-b74b-3cf2c4dd1f65@github.com>

On Thu, 25 May 2023 04:46:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to improve the accessibility of the thread dump files that are generated by the `jcmd Thread.dump_to_file` command configured in the failure handler configurations? This addresses https://bugs.openjdk.org/browse/JDK-8308475. 
>> 
>> The changes in this PR include:
>>  - Enhancement to `GatherProcessInfoTimeoutHandler` to allow configuring a `successArtifacts` action parameter which can be used to generate links to files that are generated by the failure handler commands.
>>  - Introduction of a `%iterCount` token to allow ability to refer to the current iteration when the command is repeated
>>  - The `jcmd Thread.dump_to_file` is now configured to create the thread dumps in `json` format. Additionally, it has now been configured to create the thread dumps 6 times, just like the `jstack` command.
>> 
>> Detailed explanation of the `successArtifacts` parameter and the `%iterCount` token is provided in the JBS comment here https://bugs.openjdk.org/browse/JDK-8308475?focusedCommentId=14583072&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14583072
>> 
>> Tests have been run locally with this change and tier1, tier2 and tier3 tests on CI system to verify this change works and doesn't cause regression.
>
> Thank you Leonid for the review.
> 
> Since this is tagged hotspot, can I please get a second Reviewer to review this please?

@jaikiran I don't know why @AlanBateman tagged this as Hotspot as there are no hotspot related changes. Perhaps it was just for visibility of shared failure handler changes? But I don't think you need a Hotspot review here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14071#issuecomment-1562403634

From jwaters at openjdk.org  Thu May 25 07:25:54 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 25 May 2023 07:25:54 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows
In-Reply-To: <HcUA6rbzCg3rlA_EGlZkm4n1aGAV4HnkkE11GKRBT7U=.137f14ae-54f7-4fc6-a363-4d11f4eb2eb2@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <HcUA6rbzCg3rlA_EGlZkm4n1aGAV4HnkkE11GKRBT7U=.137f14ae-54f7-4fc6-a363-4d11f4eb2eb2@github.com>
Message-ID: <ojnSpOgSEr6ngfPtLVSnDJUl2D2iFA6R5DnNMY5J61o=.5e989855-5afb-4900-8f4a-2312d429b415@github.com>

On Thu, 25 May 2023 01:34:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I think the JNI type definition change is okay.
> 
> However many of the other changes appear to me to not involve Java variables and so don't need to be Java types i.e they should be `int` rather than `jint` - though as these are native Windows types there may not actually be any reason to change them from `long`. This is for the client-libs folk to decide.

All the changes from long were done since there was conversion from or to a jint somewhere down the line, and the compilation would fail if not done otherwise. I also changed them to jint rather than int so there wouldn't be a need to keep the variables in sync with the jni.h declarations, but I guess I'll wait for more reviews to see what to do here

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1562408466

From jwaters at openjdk.org  Thu May 25 07:28:57 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 25 May 2023 07:28:57 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <y-QZ-xcvAKq4PlULwpsgKplyaD63VtXDSz7HUER5hMs=.a6d73599-1761-4158-aea8-0738dedf04fc@github.com>

On Wed, 24 May 2023 13:56:05 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Going to page for @aivanov-jdk for `client-libs` review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1562412122

From dholmes at openjdk.org  Thu May 25 07:33:54 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 May 2023 07:33:54 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows
In-Reply-To: <ojnSpOgSEr6ngfPtLVSnDJUl2D2iFA6R5DnNMY5J61o=.5e989855-5afb-4900-8f4a-2312d429b415@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
 <HcUA6rbzCg3rlA_EGlZkm4n1aGAV4HnkkE11GKRBT7U=.137f14ae-54f7-4fc6-a363-4d11f4eb2eb2@github.com>
 <ojnSpOgSEr6ngfPtLVSnDJUl2D2iFA6R5DnNMY5J61o=.5e989855-5afb-4900-8f4a-2312d429b415@github.com>
Message-ID: <3gHtTfGRCwS2s9JxA8cpAdZmaw9ShU1v1VPIT--Rn5I=.2414e309-e34f-437d-b4dd-6a734e5bb88f@github.com>

On Thu, 25 May 2023 07:22:50 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> All the changes from long were done since there was conversion from or to a jint somewhere down the line,

Okay I see that now. It is a messy situation - at some point the incoming jint's need to be "converted" to a native type.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1562418414

From dholmes at openjdk.org  Thu May 25 07:39:10 2023
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 25 May 2023 07:39:10 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out [v3]
In-Reply-To: <RN4BPdFuaa7w5BUi-b-yQq4Zmy0LbFwt7gXtVa3rvFM=.7dd8cd34-bec4-4084-9093-3096f4d8214d@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
 <HMsaRRf7tKO1p37PKuXAIdtgG9g3MiuYCWp6I_emU_Q=.cc5cb35a-f0ec-468c-9220-de31757c0855@github.com>
 <jMO4C9umQIMb7vsr4bbEOFNwI3KHMrrBmV5F_3vlLlA=.a920b489-df8b-4705-8373-7263e2829c1a@github.com>
 <RN4BPdFuaa7w5BUi-b-yQq4Zmy0LbFwt7gXtVa3rvFM=.7dd8cd34-bec4-4084-9093-3096f4d8214d@github.com>
Message-ID: <OvlAbyvgKlUGXdRI9dC1KCfO6Wjbi-Pe_3hKUJwFf5w=.b641cc6b-c272-4d44-bd9b-d0b88f6bd935@github.com>

On Wed, 24 May 2023 08:30:21 GMT, Viktor Klang <duke at openjdk.org> wrote:

> it needed yet another rebase, so yet another forced push.

You don't need to rebase (and force-push) you just merge with the master branch and skara will take care of flattening the commits.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14082#issuecomment-1562422988

From asotona at openjdk.org  Thu May 25 07:52:39 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 25 May 2023 07:52:39 GMT
Subject: RFR: 8294969: Convert jdk.jdeps javap to use the Classfile API
 [v3]
In-Reply-To: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
References: <TXt5pqfn0LNdAK74x-1kN5O4L4MFhHGi2i_h2waWG0U=.87d85017-4b0b-4735-8854-bcbd57a86fbd@github.com>
Message-ID: <SLTVrQBnbiRhp6qW3VJtrFlzJ7BzA877v-aRDY3_doc=.f7d3a15d-83a0-496e-98df-01531ff7f7a5@github.com>

> javap uses proprietary com.sun.tools.classfile library to parse class files.
> 
> This patch converts javap to use Classfile API.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 217 commits:

 - fixed build
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - more consolidation on IllegalArgumentException
 - Merge branch 'master' into JDK-8294969-javap
 - fixed TestClassNameWarning
 - Merge branch 'master' into JDK-8294969-javap
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - consolidated safeguarding of IAE in javap
 - consolidation of constant pool originating IAEs and IOOBEs into ConstantPoolException extending IAE
 - Safeguarding CP errors + test
 - Merge branch 'master' into JDK-8294969-javap
 - ... and 207 more: https://git.openjdk.org/jdk/compare/bfcae68e...f704791a

-------------

Changes: https://git.openjdk.org/jdk/pull/11411/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11411&range=02
  Stats: 3758 lines in 37 files changed: 896 ins; 1723 del; 1139 mod
  Patch: https://git.openjdk.org/jdk/pull/11411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/11411/head:pull/11411

PR: https://git.openjdk.org/jdk/pull/11411

From alanb at openjdk.org  Thu May 25 08:21:39 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 May 2023 08:21:39 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
 [v2]
In-Reply-To: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
Message-ID: <UW0KwW5uYPaaKzTgCRM2I6_R78E26N2SFDJPi-tjSvE=.4463ad73-3d3f-49c9-bc4f-c27c1decf11b@github.com>

> This is the implementation of:
> 
> - JEP 453: Structured Concurrency (Preview)
> - JEP 446: Scoped Values (Preview)
> 
> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
> 
> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Sync up from loom repo
 - Remove csm.Threads
 - Merge
 - Test should not be in update for main line
 - Sync with loom repo
 - Sync up tests frmo loom repo
 - Sync up with loom repo
 - Sync update API/impl/tests
 - Merge
 - Sync up with loom repo
 - ... and 2 more: https://git.openjdk.org/jdk/compare/89f2d458...e92ba524

-------------

Changes: https://git.openjdk.org/jdk/pull/13932/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13932&range=01
  Stats: 9227 lines in 40 files changed: 4835 ins; 4330 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/13932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13932/head:pull/13932

PR: https://git.openjdk.org/jdk/pull/13932

From alanb at openjdk.org  Thu May 25 08:25:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 May 2023 08:25:55 GMT
Subject: RFR: 8308475: Make the thread dump files generated by jcmd
 Thread.dump_to_file jtreg failure handler action easily accessible
In-Reply-To: <FuluYhtbVFpq6ewUAaq-3UY6ajTOHUQoz7IAfNKXaNw=.fae35f53-137b-405e-9b99-7f3680e29cca@github.com>
References: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>
 <FuluYhtbVFpq6ewUAaq-3UY6ajTOHUQoz7IAfNKXaNw=.fae35f53-137b-405e-9b99-7f3680e29cca@github.com>
Message-ID: <4jJB3n6GweheI6zkFEflWqZmIIitV-PGTh1eQKq6tAg=.418d6ee7-b548-4cd1-afc1-3496afb4c362@github.com>

On Thu, 25 May 2023 04:46:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to improve the accessibility of the thread dump files that are generated by the `jcmd Thread.dump_to_file` command configured in the failure handler configurations? This addresses https://bugs.openjdk.org/browse/JDK-8308475. 
>> 
>> The changes in this PR include:
>>  - Enhancement to `GatherProcessInfoTimeoutHandler` to allow configuring a `successArtifacts` action parameter which can be used to generate links to files that are generated by the failure handler commands.
>>  - Introduction of a `%iterCount` token to allow ability to refer to the current iteration when the command is repeated
>>  - The `jcmd Thread.dump_to_file` is now configured to create the thread dumps in `json` format. Additionally, it has now been configured to create the thread dumps 6 times, just like the `jstack` command.
>> 
>> Detailed explanation of the `successArtifacts` parameter and the `%iterCount` token is provided in the JBS comment here https://bugs.openjdk.org/browse/JDK-8308475?focusedCommentId=14583072&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14583072
>> 
>> Tests have been run locally with this change and tier1, tier2 and tier3 tests on CI system to verify this change works and doesn't cause regression.
>
> Thank you Leonid for the review.
> 
> Since this is tagged hotspot, can I please get a second Reviewer to review this please?

> @jaikiran I don't know why @AlanBateman tagged this as Hotspot as there are no hotspot related changes. Perhaps it was just for visibility of shared failure handler changes?

config/mailinglist/rules/jdk.json (in the skara repo) maps changes test/failure_handler/ to core-libs but changes to the jtreg failure handler are of wider interest. It looks like changes to the handler have previously been cc'ed to the hotspot list too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14071#issuecomment-1562490146

From asotona at openjdk.org  Thu May 25 08:36:08 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 25 May 2023 08:36:08 GMT
Subject: RFR: 8308842: Consolidate exceptions thrown from Class-File API
Message-ID: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>

Class-File API actually throws wide variety of exceptions based on the actual situation. Complete error handling code must cover `IndexOutOfBoundsException`, `IllegalStateException` and `IllegalArgumentException`. 

Based on previous discussions we decided to consolidate on `IllegalArgumentException` with possible sub-classes. 

It allows easy common error handling in majority of use case, however it allows also to distinguish source of the error when needed (for example `javap` needs to know if the exception comes from constant poll or not). 

Newly introduced `ConstantPoolException` extends `IllegalArgumentException` to indicate the source of the problem is in constant pool. 

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8308842: Consolidate exceptions thrown from Class-File API

Changes: https://git.openjdk.org/jdk/pull/14143/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14143&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308842
  Stats: 120 lines in 15 files changed: 61 ins; 7 del; 52 mod
  Patch: https://git.openjdk.org/jdk/pull/14143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14143/head:pull/14143

PR: https://git.openjdk.org/jdk/pull/14143

From jwaters at openjdk.org  Thu May 25 08:51:55 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 25 May 2023 08:51:55 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <Os9B4Y8FArNayjZAyqiZb-MYitfSRXjErnsAAO2vbgY=.945ac4ce-1da7-4669-915b-79c913f070cf@github.com>

On Wed, 24 May 2023 13:56:05 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

I'll see what I can do, I'll check the parameter type for the methods that are called in relevant code, though if they take an int as an argument I'm not really sure what to change

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1562526271

From aph at openjdk.org  Thu May 25 09:02:13 2023
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 25 May 2023 09:02:13 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
 [v3]
In-Reply-To: <cXXQlLg77sWd5xEttH2vIPlxbFItZxSdz7qW4oZLAds=.dc774213-d8ec-4fc9-be0a-d70579cc20df@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
 <cXXQlLg77sWd5xEttH2vIPlxbFItZxSdz7qW4oZLAds=.dc774213-d8ec-4fc9-be0a-d70579cc20df@github.com>
Message-ID: <BLTHH3D7y7wF2V8IIx7lg469SJ0DGpK4PDRjukp3OPQ=.3e62eed3-06d3-4fee-a8b7-3a96c4d6b3b1@github.com>

On Thu, 18 May 2023 09:50:13 GMT, Chang Peng <duke at openjdk.org> wrote:

>> In Vector API Java level, vector mask is represented as a boolean array with 0x00/0x01 (8 bits of each element) as values, aka in-memory format. When it is loaded into vector register, e.g. Neon, the in-memory format will be converted to in-register format with 0/-1 value for each lane (lane width aligned to its type) by VectorLoadMask [1] operation, and convert back to in-memory format by VectorStoreMask[2]. In Neon, a typical VectorStoreMask operation will first narrow given vector registers by xtn insn [3] into byte element type, and then do a vector negate to convert to 0x00/0x01 value for each element.
>> 
>> For most of the vector mask operations, the input mask is in-register format. And a vector mask also works in-register format all through the compilation. But for some operations like VectorMask.trueCount()[4] which counts the elements of true value, the expected input mask is in-memory format. So a VectorStoreMask is generated to convert the mask from in-register format to in-memory format before those operations.
>> 
>> However, for trueCount() these xtn instructions in VectorStoreMask can be saved, since the narrowing operations will not influence the number of active lane (value of 0x01) of its input.
>> 
>> This patch adds an optimized rule `VectorMaskTrueCount (VectorStoreMask mask)` to save the unnecessary narrowing operations.
>> 
>> For example,
>> 
>> 
>> var m = VectorMask.fromArray(IntVector.SPECIES_PREFERRED, ba, 0);
>> m.not().trueCount();
>> 
>> 
>> will produce following assembly on a Neon machine before this patch:
>> 
>> 
>> ...
>> mvn     v16.16b, v16.16b           // VectorMask.not()
>> xtn     v16.4h, v16.4s
>> xtn     v16.8b, v16.8h
>> neg     v16.8b, v16.8b             // VectorStoreMask
>> addv    b17, v16.8b
>> umov    w0, v17.b[0]               // VectorMask.trueCount()
>> ...
>> 
>> 
>> After this patch:
>> 
>> 
>> ...
>> mvn     v16.16b, v16.16b           // VectorMask.not()
>> addv    s17, v16.4s
>> smov    x0, v17.b[0]
>> neg     x0, x0                     // Optimized VectorMask.trueCount()
>> ...
>> 
>> 
>> In this case, we can save two xtn insns.
>> 
>> Performance:
>> 
>> Benchmark     Before               After                          Unit
>> testInt           723.822 ? 1.029  1182.375 ? 12.363    ops/ms
>> testLong       632.154 ? 0.197  1382.74 ? 2.188        ops/ms
>> testShort      788.665 ? 1.852   1152.38 ? 3.77         ops/ms
>> 
>> [1]: https://github.com/openjdk/jdk/blob/e1e758a7b43c29840296d337bd2f0213ab0ca3c9/src/hotspot/cpu/aarch64/aarch64_vect...
>
> Chang Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update benchmark to avoid potential optimization

Marked as reviewed by aph (Reviewer).

src/hotspot/cpu/aarch64/aarch64_vector_ad.m4 line 3825:

> 3823: %}
> 3824: 
> 3825: // Combined rule for VectorStoreMask + VectorMaskTrueCount when the vector element type is not T_BYTE.

Suggestion:

// Combined rule for VectorMaskTrueCount (VectorStoreMask) when the vector element type is not T_BYTE.

Using `+` is unnecessarily confusing, as is swapping the operands.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13974#pullrequestreview-1443414797
PR Review Comment: https://git.openjdk.org/jdk/pull/13974#discussion_r1205210387

From liach at openjdk.org  Thu May 25 09:16:03 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 25 May 2023 09:16:03 GMT
Subject: RFR: 8308842: Consolidate exceptions thrown from Class-File API
In-Reply-To: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
References: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
Message-ID: <3JOMuJ08hUBziMq0qHCcwEu6CfNxpgul8F_0ZVqHYow=.58344e38-b410-49c6-b176-2fd8f4d30593@github.com>

On Thu, 25 May 2023 08:29:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API actually throws wide variety of exceptions based on the actual situation. Complete error handling code must cover `IndexOutOfBoundsException`, `IllegalStateException` and `IllegalArgumentException`. 
> 
> Based on previous discussions we decided to consolidate on `IllegalArgumentException` with possible sub-classes. 
> 
> It allows easy common error handling in majority of use case, however it allows also to distinguish source of the error when needed (for example `javap` needs to know if the exception comes from constant poll or not). 
> 
> Newly introduced `ConstantPoolException` extends `IllegalArgumentException` to indicate the source of the problem is in constant pool. 
> 
> Please review.
> 
> Thanks,
> Adam

What other types of exceptions does javap distinguish, and should Classfile API distinguish them as well?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14143#issuecomment-1562560698

From raffaello.giulietti at oracle.com  Thu May 25 09:21:09 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Thu, 25 May 2023 11:21:09 +0200
Subject: [External] : Re: Classes used in method body are loaded lazily or
 eagerly depending on method return type
In-Reply-To: <36c13724-9c08-c082-67ab-fa24773314ec@oracle.com>
References: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
 <c4954b0c-ca2a-7cb1-4710-36af333e7d06@oracle.com>
 <59b1c6ff-ab08-8a8f-12b7-21f78285571b@oracle.com>
 <1813541396.62977656.1684881306040.JavaMail.zimbra@univ-eiffel.fr>
 <2cf71b1c-7ac1-e158-1c80-762caa3e6e82@oracle.com>
 <36c13724-9c08-c082-67ab-fa24773314ec@oracle.com>
Message-ID: <22412a94-1d04-fb01-d309-870a55328a41@oracle.com>


Yes, ChildClass.class is removed from the filesystem.


And here's, the relevant info when running with -Xlog:class+init, 
showing that verification succeeds for both TestLoading$ObjectReturner 
and TestLoading$BaseClassReturner:

loading: TestLoading$ObjectReturner...
[0.039s][info][class,init] Start class verification for: 
TestLoading$ObjectReturner
[0.039s][info][class,init] End class verification for: 
TestLoading$ObjectReturner
[0.039s][info][class,init] 500 Initializing 
'TestLoading$ObjectReturner'(no method) (0x0000000801001800)
loading: TestLoading$BaseClassReturner...
[0.039s][info][class,init] Start class verification for: 
TestLoading$BaseClassReturner
[0.039s][info][class,init] End class verification for: 
TestLoading$BaseClassReturner
[0.039s][info][class,init] 501 Initializing 
'TestLoading$BaseClassReturner'(no method) (0x0000000801001a08)




On 2023-05-25 04:57, David Holmes wrote:
> On 25/05/2023 12:34 am, Raffaello Giulietti wrote:
>> As mentioned in my previous email, if you move the member class 
>> ChildClass out of TestLoading (out of the nest), and make it a 
>> top-level class like
>>
>> ???? public class ChildClass extends TestLoading.BaseClass {
>> ???? }
>>
>> and change
>>
>> ???? URL classFileB = 
>> TestLoading.class.getResource(TestLoading.class.getSimpleName() + 
>> "$ChildClass.class");
>>
>> to
>>
>> ???? URL classFileB = 
>> TestLoading.class.getResource(ChildClass.class.getSimpleName() + 
>> ".class");
>>
>> rebuild everything and run, nothing is thrown.
>>
>> ???? deleting: <path-to>/ChildClass.class
>> ???? loading: TestLoading$ObjectReturner...
>> ???? loading: TestLoading$BaseClassReturner...
>>
>> I can't see any substantial difference, except that the nest rooted at 
>> TestLoading lacks a member in the original setup and lacks nothing in 
>> this setup.
>>
>> What's an explanation for this difference?
> 
> Are you sure it actually deletes the file? What do you see when you 
> enable class+load/init and verification logging?
> 
> David
> -----
> 
> 
> 
>>
>> Greetings
>> Raffaello
>>
>>
>> On 2023-05-24 00:35, Remi Forax wrote:
>>>
>>>
>>> ----- Original Message -----
>>>> From: "David Holmes" <david.holmes at oracle.com>
>>>> To: "Raffaello Giulietti" <raffaello.giulietti at oracle.com>, 
>>>> "core-libs-dev" <core-libs-dev at openjdk.org>
>>>> Sent: Wednesday, May 24, 2023 12:23:24 AM
>>>> Subject: Re: Classes used in method body are loaded lazily or 
>>>> eagerly depending on method return type
>>>
>>>> On 24/05/2023 12:50 am, Raffaello Giulietti wrote:
>>>>> I think the problem here is that you are deleting a class in a nest.
>>>>>
>>>>> During the verification of BaseClassReturner.getObject(), access 
>>>>> control
>>>>> (JVMS, 5.4.4, second half) determines that the nest is broken, as
>>>>> ChildClass is not present anymore.
>>>>
>>>> Not sure access control gets involved at this stage of the verification
>>>> process. But in any case turning on logging does not show anything
>>>> related to nestmates happening between BaseClass and ChildClass. It
>>>> seems to just be the resolution of the return type during verification
>>>> of the method, that causes the loading of ChildClass and the subsequent
>>>> CNFE if it has been removed.
>>>>
>>>>> If you move ChildClass out of TestLoading so that it becomes a 
>>>>> top-level
>>>>> class extending TestLoading.BaseClass, and if you adapt the line that
>>>>> initializes the local var classFileB to refer to the new location, the
>>>>> code will not throw, despite ChildClass being deleted.
>>>>
>>>> My simplified test shows it still throws when verifying 
>>>> BaseClassReturner.
>>>
>>> Nestmate checking is done lazily, so if you do not call a 
>>> method/access a field of a nested class, the VM should not trigger a 
>>> class loading.
>>>
>>> Moreover, if you test with Java 8 (nestmates were introduced in Java 
>>> 11), it failed too.
>>> That's another clue that the error is not related to nestmates checking.
>>>
>>>>
>>>>
>>>> Cheers,
>>>> David
>>>
>>> regards,
>>> R?mi
>>>
>>>>
>>>>>
>>>>> Greetings
>>>>> Raffaello
>>>>>
>>>>>
>>>>>
>>>>> On 2023-05-23 13:20, ?????? ??????? wrote:
>>>>>> Hello,
>>>>>>
>>>>>> originally this question was asked here:
>>>>>> https://urldefense.com/v3/__https://stackoverflow.com/q/76260269/12473843__;!!ACWV5N9M2RV99hQ!Mb5nhj7EbuftWzF7s4GX9auUZZlyPyCUnLs64c4mkmSGJm4pw0CNgRzQR5wOYuApyE_kHSAnVxGyTM9PHz5StCppGw$ ,
>>>>>> the code sample for reproduction will be put below or can be found 
>>>>>> via
>>>>>> the link
>>>>>>
>>>>>> The issue is about eager/lazy loading of a class depending on method
>>>>>> return type.
>>>>>> If one runs the code below with Java 11-19 it will fail with
>>>>>> NoClassDefFoundError (this is expected as delete class file for
>>>>>> ChildClass):
>>>>>>
>>>>>> java.lang.NoClassDefFoundError: org/example/TestLoading$ChildClass
>>>>>> ?????at java.base/java.lang.Class.forName0(Native Method)
>>>>>> ?????at java.base/java.lang.Class.forName(Class.java:390)
>>>>>> ?????at java.base/java.lang.Class.forName(Class.java:381)
>>>>>> ?????at org.example.TestLoading.loadMyClass(TestLoading.java:29)
>>>>>> ?????at org.example.TestLoading.main(TestLoading.java:23)
>>>>>> Caused by: java.lang.ClassNotFoundException:
>>>>>> org.example.TestLoading$ChildClass
>>>>>> ?????at
>>>>>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>>>>>> ?????at
>>>>>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>>>>>> ?????at 
>>>>>> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>>>>>> ?????... 5 more
>>>>>>
>>>>>> As of Java 20 chapter 12.4.1 of JLS states:
>>>>>> ---------------------------------------------------------
>>>>>> A class or interface T will be initialized immediately before the
>>>>>> first occurrence of any one of the following:
>>>>>>
>>>>>> - T is a class and an instance of T is created.
>>>>>> - a static method declared by T is invoked.
>>>>>> - a static field declared by T is assigned.
>>>>>> - a static field declared by T is used and the field is not a 
>>>>>> constant
>>>>>> variable (?4.12.4).
>>>>>>
>>>>>> When a class is initialized, its superclasses are initialized (if 
>>>>>> they
>>>>>> have not been previously initialized), as well as any superinterfaces
>>>>>> (?8.1.5) that declare any default methods (?9.4.3) (if they have not
>>>>>> been previously initialized).
>>>>>> Initialization of an interface does not, of itself, cause
>>>>>> initialization of any of its superinterfaces.
>>>>>> A reference to a static field (?8.3.1.1) causes initialization of 
>>>>>> only
>>>>>> the class or interface that actually declares it, even though it 
>>>>>> might
>>>>>> be referred to through the name of a subclass, a subinterface, or a
>>>>>> class that implements an interface.
>>>>>> Invocation of certain reflective methods in class Class and in 
>>>>>> package
>>>>>> java.lang.reflect also causes class or interface initialization.
>>>>>> A class or interface will not be initialized under any other
>>>>>> circumstance.
>>>>>> ---------------------------------------------------------
>>>>>> With the code snippet we see that calling
>>>>>> Class.forName(ObjectReturner.class.getName()) succeeds and
>>>>>> Class.forName(BaseClassReturner.class.getName()) fails even though
>>>>>> both declare returning an instance of ChildClass.
>>>>>> This failure is unexpected as in the code below we don't fulfill any
>>>>>> requirement for class loading as of JLS 12.4.1, but the JVM still
>>>>>> tries to load the class.
>>>>>>
>>>>>> I suspect it might be related to class file validation and/or
>>>>>> security, because when we run the code with -Xlog:class+init 
>>>>>> there's a
>>>>>> reference to LinkageError in loading log:
>>>>>>
>>>>>> loading: org.example.TestLoading$BaseClassReturner...
>>>>>> [0.277s][info][class,init] Start class verification for:
>>>>>> org.example.TestLoading$BaseClassReturner
>>>>>> [0.277s][info][class,init] 771 Initializing
>>>>>> 'java/lang/ReflectiveOperationException'(no method) 
>>>>>> (0x0000000800004028)
>>>>>> [0.277s][info][class,init] 772 Initializing
>>>>>> 'java/lang/ClassNotFoundException'(no method) (0x0000000800004288)
>>>>>> [0.277s][info][class,init] 773 Initializing
>>>>>> 'java/lang/LinkageError'(no method)
>>>>>> (0x00000008000044f8)????????????????????????????????? <----
>>>>>> [0.277s][info][class,init] 774 Initializing
>>>>>> 'java/lang/NoClassDefFoundError'(no method) (0x0000000800004758)
>>>>>> [0.277s][info][class,init] Verification for
>>>>>> org.example.TestLoading$BaseClassReturner has exception pending
>>>>>> 'java.lang.NoClassDefFoundError org/example/TestLoading$ChildClass'
>>>>>> [0.277s][info][class,init] End class verification for:
>>>>>> org.example.TestLoading$BaseClassReturner
>>>>>>
>>>>>>
>>>>>> So I've got three questions about this:
>>>>>> - Does class loading depend on method's return type?
>>>>>> - Which part of JLS/JVM spec describes eager class loading in this 
>>>>>> case?
>>>>>> - Could one point out the particular piece of the VM code responsible
>>>>>> for class loading in this case?
>>>>>>
>>>>>> Regards,
>>>>>> Sergey Tsypanov
>>>>>>
>>>>>> Code snippet for reproduction:
>>>>>>
>>>>>> public class TestLoading {
>>>>>>
>>>>>> ??? public static void main(String[] args) throws Exception {
>>>>>> ????? Class.forName(BaseClass.class.getName());
>>>>>> ????? URL classFileB =
>>>>>> TestLoading.class.getResource(TestLoading.class.getSimpleName() +
>>>>>> "$ChildClass.class");
>>>>>> ????? if (classFileB != null) {
>>>>>> ??????? if (!"file".equals(classFileB.getProtocol())) {
>>>>>> ????????? throw new UnsupportedOperationException();
>>>>>> ??????? }
>>>>>> ??????? Path path = new File(classFileB.getPath()).toPath();
>>>>>> ??????? System.out.println("deleting: " + path);
>>>>>> ??????? Files.delete(path);
>>>>>> ????? }
>>>>>>
>>>>>> ????? loadMyClass(ObjectReturner.class.getName());
>>>>>> ????? loadMyClass(BaseClassReturner.class.getName());
>>>>>> ??? }
>>>>>>
>>>>>> ??? private static void loadMyClass(String name) {
>>>>>> ????? System.out.println("loading: " + name + "...");
>>>>>> ????? try {
>>>>>> ??????? Class.forName(name);
>>>>>> ????? } catch (Throwable e) {
>>>>>> ??????? e.printStackTrace(System.out);
>>>>>> ????? }
>>>>>> ??? }
>>>>>>
>>>>>> ??? public static class BaseClass {
>>>>>> ??? }
>>>>>>
>>>>>> ??? public static class ChildClass extends BaseClass {
>>>>>> ??? }
>>>>>>
>>>>>> ??? public static class ObjectReturner {
>>>>>> ????? public Object getObject() {
>>>>>> ??????? return new ChildClass();
>>>>>> ????? }
>>>>>> ??? }
>>>>>>
>>>>>> ??? public static class BaseClassReturner {
>>>>>> ????? public BaseClass getObject() {
>>>>>> ??????? return new ChildClass();
>>>>>> ????? }
>>>>>> ??? }
>>>>>> }

From jwaters at openjdk.org  Thu May 25 09:25:59 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 25 May 2023 09:25:59 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <18Hb8qz70ED7U2vLbTCN11B28K117KPmEh8CIVASDMk=.136e983b-1cad-43e5-b8c9-b9495a60ff84@github.com>

On Wed, 24 May 2023 13:56:05 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

For reference as to what types the calls in affected code accepts as parameters, so any future reviews don't need to dig through the code

GDIRenderer.cpp:

- Java_sun_java2d_windows_GDIRenderer_doFillArc
  * AngleToCoord takes jints as arguments
  * ::Pie takes ints as arguments

- Java_sun_java2d_windows_GDIRenderer_doDrawArc
  * AngleToCoord takes jints as arguments
  * ::Arc takes ints as arguments

GDIWindowSurfaceData.cpp:

- GDIWinSD_GetRasInfo
  * SurfaceDataRasInfo's lutBase field is a jint*

awt_MenuBar.cpp (Encompasses the changes in awt_Menu.h and awt_MenuBar.h as well):

- AwtMenuBar::GetItem passes the only relevant jint (formerly long) into env->CallObjectMethod()

AccessInfo.cpp

- getAccessibleInfo
  * start and end (both formerly long) are both passed to GetAccessibleTextLineBounds and GetAccessibleTextRange which take jints


Only outlier is jaccesswalker, which I think I may have edited wrongly

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1562575536

From jpai at openjdk.org  Thu May 25 09:27:09 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 25 May 2023 09:27:09 GMT
Subject: RFR: 8308475: Make the thread dump files generated by jcmd
 Thread.dump_to_file jtreg failure handler action easily accessible
In-Reply-To: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>
References: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>
Message-ID: <PsMbA4thI_AWT4s_UoBF9HqrZB-uomtzQc0eeAVVjbU=.33872921-56c5-4f95-a359-a3c266efed1a@github.com>

On Sun, 21 May 2023 09:19:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to improve the accessibility of the thread dump files that are generated by the `jcmd Thread.dump_to_file` command configured in the failure handler configurations? This addresses https://bugs.openjdk.org/browse/JDK-8308475. 
> 
> The changes in this PR include:
>  - Enhancement to `GatherProcessInfoTimeoutHandler` to allow configuring a `successArtifacts` action parameter which can be used to generate links to files that are generated by the failure handler commands.
>  - Introduction of a `%iterCount` token to allow ability to refer to the current iteration when the command is repeated
>  - The `jcmd Thread.dump_to_file` is now configured to create the thread dumps in `json` format. Additionally, it has now been configured to create the thread dumps 6 times, just like the `jstack` command.
> 
> Detailed explanation of the `successArtifacts` parameter and the `%iterCount` token is provided in the JBS comment here https://bugs.openjdk.org/browse/JDK-8308475?focusedCommentId=14583072&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14583072
> 
> Tests have been run locally with this change and tier1, tier2 and tier3 tests on CI system to verify this change works and doesn't cause regression.

Thank you all for the help. I'll go ahead and integrate this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14071#issuecomment-1562574463

From jpai at openjdk.org  Thu May 25 09:27:10 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 25 May 2023 09:27:10 GMT
Subject: Integrated: 8308475: Make the thread dump files generated by jcmd
 Thread.dump_to_file jtreg failure handler action easily accessible
In-Reply-To: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>
References: <VVRMUUDTEpyY6OpW9EH2Tm0s7EwkhL23lAQ_BUETqYk=.b5ff523d-7a87-4cdd-88ff-232719f44c1f@github.com>
Message-ID: <qsxg_HEyQvSlluyx6B_9eQxk8GzRR_158XHPmC4hxzY=.567f322e-c6ad-45b5-bff7-446d52149ed1@github.com>

On Sun, 21 May 2023 09:19:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to improve the accessibility of the thread dump files that are generated by the `jcmd Thread.dump_to_file` command configured in the failure handler configurations? This addresses https://bugs.openjdk.org/browse/JDK-8308475. 
> 
> The changes in this PR include:
>  - Enhancement to `GatherProcessInfoTimeoutHandler` to allow configuring a `successArtifacts` action parameter which can be used to generate links to files that are generated by the failure handler commands.
>  - Introduction of a `%iterCount` token to allow ability to refer to the current iteration when the command is repeated
>  - The `jcmd Thread.dump_to_file` is now configured to create the thread dumps in `json` format. Additionally, it has now been configured to create the thread dumps 6 times, just like the `jstack` command.
> 
> Detailed explanation of the `successArtifacts` parameter and the `%iterCount` token is provided in the JBS comment here https://bugs.openjdk.org/browse/JDK-8308475?focusedCommentId=14583072&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14583072
> 
> Tests have been run locally with this change and tier1, tier2 and tier3 tests on CI system to verify this change works and doesn't cause regression.

This pull request has now been integrated.

Changeset: 426ebf4f
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/426ebf4fe930aa966dd5a0ebefbbeae107a8d223
Stats:     78 lines in 5 files changed: 66 ins; 0 del; 12 mod

8308475: Make the thread dump files generated by jcmd Thread.dump_to_file jtreg failure handler action easily accessible

Reviewed-by: lmesnik

-------------

PR: https://git.openjdk.org/jdk/pull/14071

From duke at openjdk.org  Thu May 25 09:28:22 2023
From: duke at openjdk.org (JoKern65)
Date: Thu, 25 May 2023 09:28:22 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code
Message-ID: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>

When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
Some of those are in shared codebase and could be addressed by small adjustments.
A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.

-------------

Commit messages:
 - white space
 - JDK-8308288

Changes: https://git.openjdk.org/jdk/pull/14146/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14146&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308288
  Stats: 52 lines in 11 files changed: 46 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/14146.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14146/head:pull/14146

PR: https://git.openjdk.org/jdk/pull/14146

From asotona at openjdk.org  Thu May 25 09:28:57 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 25 May 2023 09:28:57 GMT
Subject: RFR: 8308842: Consolidate exceptions thrown from Class-File API
In-Reply-To: <3JOMuJ08hUBziMq0qHCcwEu6CfNxpgul8F_0ZVqHYow=.58344e38-b410-49c6-b176-2fd8f4d30593@github.com>
References: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
 <3JOMuJ08hUBziMq0qHCcwEu6CfNxpgul8F_0ZVqHYow=.58344e38-b410-49c6-b176-2fd8f4d30593@github.com>
Message-ID: <P-oGHMnxLXpfVgZ_dJihc1RanKAci_KnglzOJZ_q1W0=.dadf4f08-50c2-42d5-a842-edd13f6b9f38@github.com>

On Thu, 25 May 2023 09:12:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> What other types of exceptions does javap distinguish, and should Classfile API distinguish them as well?

Invalid CP index or content are cases where javap tries to recover, replace the value with '???' and print the rest.
This PR is extracted Classfile API - related part of #11411

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14143#issuecomment-1562579655

From liach at openjdk.org  Thu May 25 09:33:57 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 25 May 2023 09:33:57 GMT
Subject: RFR: 8308842: Consolidate exceptions thrown from Class-File API
In-Reply-To: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
References: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
Message-ID: <jczXBa9fjl5W9VSusKN7Xh_pMhdA7G07H_AA8ZlUuf4=.59cc2d00-d548-45f5-b76b-4f76aa017b97@github.com>

On Thu, 25 May 2023 08:29:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API actually throws wide variety of exceptions based on the actual situation. Complete error handling code must cover `IndexOutOfBoundsException`, `IllegalStateException` and `IllegalArgumentException`. 
> 
> Based on previous discussions we decided to consolidate on `IllegalArgumentException` with possible sub-classes. 
> 
> It allows easy common error handling in majority of use case, however it allows also to distinguish source of the error when needed (for example `javap` needs to know if the exception comes from constant poll or not). 
> 
> Newly introduced `ConstantPoolException` extends `IllegalArgumentException` to indicate the source of the problem is in constant pool. 
> 
> Please review.
> 
> Thanks,
> Adam

Then this should suffice for now. We can create specific subtypes if we wish to expose specific exceptions in the future.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14143#issuecomment-1562588110

From prappo at openjdk.org  Thu May 25 10:26:04 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 25 May 2023 10:26:04 GMT
Subject: Integrated: 8308735: Typos in parameter names
In-Reply-To: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
References: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
Message-ID: <odvywRgvz9xbSlXVY8F3cqOYsi0hqRsfDqnK7fhGNJk=.f72ecc9b-3cd8-43b3-bef2-9d77fcefac95@github.com>

On Wed, 24 May 2023 23:32:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple fix.

This pull request has now been integrated.

Changeset: 38367d3c
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/38367d3c3ad9292b7c581917c89e9f07fac3dd31
Stats:     9 lines in 3 files changed: 0 ins; 0 del; 9 mod

8308735: Typos in parameter names

Reviewed-by: naoto, iris, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/14136

From stsypanov at openjdk.org  Thu May 25 11:30:58 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 25 May 2023 11:30:58 GMT
Subject: RFR: 8301492: Modernize equals() method of ResourceBundle.CacheKey
 and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <WiGTYwVTe9M7657nrA2pcDLgcV5TTLZ2eGlfZdDIw7k=.188e48c6-bd57-4963-9b21-b6be72ffa175@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Not now

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1562739064

From shade at openjdk.org  Thu May 25 11:40:28 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 May 2023 11:40:28 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with bulk/scalable
 PRNG access
Message-ID: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>

UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.

The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.

We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 


Benchmark               Mode  Cnt  Score   Error   Units

### AArch64 (m6g.4xlarge, Graviton, 16 cores)

# Before
UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling

# After
UUIDRandomBench.single  thrpt   15  4.421 ? 0.047  ops/us 
UUIDRandomBench.max     thrpt   15  6.658 ? 0.092  ops/us ; positive scaling, ~1.5x

### x86_64 (c6.8xlarge, Xeon, 18 cores)

# Before
UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 

# After
Benchmark                Mode  Cnt  Score   Error   Units
UUIDRandomBench.single  thrpt   15  3.099 ? 0.022  ops/us
UUIDRandomBench.max     thrpt   15  3.555 ? 0.062  ops/us  ; positive scaling, ~1.2x


Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance. This PR adds a system property to select the implementation, and there we can clearly see the benefit:


Benchmark               Mode  Cnt   Score   Error   Units

### x86_64 (c6.8xlarge, Xeon, 18 cores)

# Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
UUIDRandomBench.single  thrpt   15  3.661 ? 0.008  ops/us
UUIDRandomBench.max     thrpt   15  2.400 ? 0.031  ops/us  ; faster than NativePRNG, but still negative scalability

# After, -Djava.util.UUID.prngName=SHA1PRNG
UUIDRandomBench.single  thrpt   15   3.522 ? 0.009  ops/us
UUIDRandomBench.max     thrpt   15  50.506 ? 1.734  ops/us ;  positive scaling, ~14x


Other scalable random number providers would improve the similar way. Note that just changing to`SHA1PRNG` right now would not help much, because it would still be very contended. This PR does not change the default PRNG provider, that would need a larger discussion. It only provides the means to select another one.

Since the buffers are allocated on-demand and stay permanently, there are allocation rate improvements: generating an UUID now takes 80 bytes per op instead of 120 bytes per op. The buffer cache also takes memory. Back-envelope: for large 192-core machine that takes UUIDs in all threads, the default settings add up to 768K of additional memory.

Additional testing:
 - [x] Updated tests from #14134 
 - [ ] Linux AArch64 fastdebug `tier1 tier2 tier3`

The new options are not strictly speaking required for this work to be useful, but it would be convenient to have them around for field tuning and diagnostics.

-------------

Commit messages:
 - More touchups
 - Comment updates
 - Runtime options and touchups
 - Add benchmark
 - Initial work

Changes: https://git.openjdk.org/jdk/pull/14135/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14135&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308804
  Stats: 237 lines in 2 files changed: 221 ins; 9 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/14135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14135/head:pull/14135

PR: https://git.openjdk.org/jdk/pull/14135

From alanb at openjdk.org  Thu May 25 12:23:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 May 2023 12:23:00 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access
In-Reply-To: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
Message-ID: <WrtGGw8ClImuXdBKJsDkmPL2tFDus66iJLc-Vn2I8iM=.e1d0dd74-7e28-4379-b5a7-38892d780d6b@github.com>

On Wed, 24 May 2023 19:36:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
> 
> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
> 
> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
> 
> 
> Benchmark               Mode  Cnt  Score   Error   Units
> 
> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
> 
> # After
> UUIDRandomBench.single  thrpt   15  4.421 ? 0.047  ops/us 
> UUIDRandomBench.max     thrpt   15  6.658 ? 0.092  ops/us ; positive scaling, ~1.5x
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
> 
> # After
> Benchmark                Mode  Cnt  Score   Error   Units
> UUIDRandomBench.single  thrpt   15  3.099 ? 0.022  ops/us
> UUIDRandomBench.max     thrpt   15  3.555 ? 0.062  ops/us  ; positive scaling, ~1.2x
> 
> 
> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. Still, using the bulk reads even when the underlying PRNG is heavily synchronized is a win.
> 
> This PR adds a system property to select the implementation, and there we can clearly see the benefit with more scalable PRNG sources:
> 
> 
> Benchmark               Mode  Cnt   Score   Error   Units
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
> UUIDRandomBench.single  thrpt   15  3.661 ? 0.008  ops/us
> UUIDRandomBench.max     thrpt   15  2.400 ? 0.031  ops/us  ; faster than NativePRNG, but still negative scalability
> 
> # After, -Djava.util.UUID.prngName=SHA1PRNG
> UUIDRandomBench.single  thrpt   15   3.522 ? 0.009  ops/us
> UUIDRandom...

src/java.base/share/classes/java/util/UUID.java line 127:

> 125:         static {
> 126:             try {
> 127:                 PRNG_NAME = System.getProperty(PROP_NAME_PRNG_NAME, null);

You'll have to use GetPropertyAction.privilegedGetProperty as this will otherwise fail if someone runs with a SM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1205433513

From asotona at openjdk.org  Thu May 25 12:32:02 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 25 May 2023 12:32:02 GMT
Subject: RFR: 8308856: jdk.internal.classfile.impl.EntryMap::nextPowerOfTwo
 math problem
Message-ID: <A0SmHH6KU16n2rdxGrqQoPeCqwZxjJ6amYDMcZBC3Xo=.be307a1e-1007-4898-87e5-03a82bbac830@github.com>

Fix of jdk.internal.classfile.impl.EntryMap::nextPowerOfTwo returning correct zero power of two.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - 8308856: jdk.internal.classfile.impl.EntryMap::nextPowerOfTwo math problem

Changes: https://git.openjdk.org/jdk/pull/14148/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14148&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308856
  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14148.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14148/head:pull/14148

PR: https://git.openjdk.org/jdk/pull/14148

From mbaesken at openjdk.org  Thu May 25 12:57:55 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 25 May 2023 12:57:55 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code
In-Reply-To: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
Message-ID: <Qc0jokVc2URgTCa_RXbbP2GKO8nRZ9dXqAlGYd7MrdE=.29275aa3-50b0-4c5f-b5ab-35fcc40df8eb@github.com>

On Thu, 25 May 2023 09:14:14 GMT, JoKern65 <duke at openjdk.org> wrote:

> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
> Some of those are in shared codebase and could be addressed by small adjustments.
> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.

In the macro define checks, you both check macros _AIX and AIX, sometimes this, sometimes that. Might be possible to just use one of the two for consistency, but I am fine with using both as well, leave this up to you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1562859320

From duke at openjdk.org  Thu May 25 13:14:11 2023
From: duke at openjdk.org (Viktor Klang)
Date: Thu, 25 May 2023 13:14:11 GMT
Subject: RFR: JDK-8298066: java/util/concurrent/locks/Lock/OOMEInAQS.java
 timed out [v3]
In-Reply-To: <OvlAbyvgKlUGXdRI9dC1KCfO6Wjbi-Pe_3hKUJwFf5w=.b641cc6b-c272-4d44-bd9b-d0b88f6bd935@github.com>
References: <wE1uJznMYEbStLuivDgUCIAullM7XjMkAAZ61cy2aFg=.f9e68dbf-2e58-4021-b5b6-589851ef8eaf@github.com>
 <HMsaRRf7tKO1p37PKuXAIdtgG9g3MiuYCWp6I_emU_Q=.cc5cb35a-f0ec-468c-9220-de31757c0855@github.com>
 <jMO4C9umQIMb7vsr4bbEOFNwI3KHMrrBmV5F_3vlLlA=.a920b489-df8b-4705-8373-7263e2829c1a@github.com>
 <RN4BPdFuaa7w5BUi-b-yQq4Zmy0LbFwt7gXtVa3rvFM=.7dd8cd34-bec4-4084-9093-3096f4d8214d@github.com>
 <OvlAbyvgKlUGXdRI9dC1KCfO6Wjbi-Pe_3hKUJwFf5w=.b641cc6b-c272-4d44-bd9b-d0b88f6bd935@github.com>
Message-ID: <kzfxT1QmvW27WhWo3q7kgGYmw8YzDTZhnOtlqn1yYx8=.921ba0db-f63b-4133-a2cb-f82ba4892815@github.com>

On Thu, 25 May 2023 07:35:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> @AlanBateman Sounds good, thanks for confirming. I've updated both the ProblemLists, but it needed yet another rebase, so yet another forced push.
>
>> it needed yet another rebase, so yet another forced push.
> 
> You don't need to rebase (and force-push) you just merge with the master branch and skara will take care of flattening the commits.

@dholmes-ora It takes time to unlearn decades of "avoid merge commits" :) Thanks for the tip!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14082#issuecomment-1562884014

From alanb at openjdk.org  Thu May 25 14:07:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 May 2023 14:07:04 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access
In-Reply-To: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
Message-ID: <cBkMN9Na-lcYkaPcjDxrpaAZiy7H81-wMPm4zhG06tE=.d34bcfb3-1b70-43de-895f-7d6fce8f2d50@github.com>

On Wed, 24 May 2023 19:36:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
> 
> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
> 
> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
> 
> 
> Benchmark               Mode  Cnt  Score   Error   Units
> 
> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
> 
> # After
> UUIDRandomBench.single  thrpt   15  4.421 ? 0.047  ops/us 
> UUIDRandomBench.max     thrpt   15  6.658 ? 0.092  ops/us ; positive scaling, ~1.5x
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
> 
> # After
> Benchmark                Mode  Cnt  Score   Error   Units
> UUIDRandomBench.single  thrpt   15  3.099 ? 0.022  ops/us
> UUIDRandomBench.max     thrpt   15  3.555 ? 0.062  ops/us  ; positive scaling, ~1.2x
> 
> 
> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
> 
> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
> 
> 
> Benchmark               Mode  Cnt   Score   Error   Units
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
> UUIDRandomBench.single  thrpt   15  3.661 ? 0.008  ops/us
> UUIDRandomBench...

src/java.base/share/classes/java/util/UUID.java line 149:

> 147:             } else {
> 148:                 try {
> 149:                     return SecureRandom.getInstance(PRNG_NAME);

Part of the change here is that the RNG algorithm is configurable via a system property. The naming of the naming (java.util.UUID.prngName) hints that you might want it to be a standard system property but maybe it's for testing?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1205568056

From shade at openjdk.org  Thu May 25 14:07:05 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 25 May 2023 14:07:05 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access
In-Reply-To: <cBkMN9Na-lcYkaPcjDxrpaAZiy7H81-wMPm4zhG06tE=.d34bcfb3-1b70-43de-895f-7d6fce8f2d50@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <cBkMN9Na-lcYkaPcjDxrpaAZiy7H81-wMPm4zhG06tE=.d34bcfb3-1b70-43de-895f-7d6fce8f2d50@github.com>
Message-ID: <PMygQbcPXK6GNPn2UFG_OLs-gTDNx4Dey8CVmo7Sncc=.467705c2-8be5-48e1-9729-eb0782aaf443@github.com>

On Thu, 25 May 2023 14:01:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
>> 
>> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
>> 
>> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
>> 
>> 
>> Benchmark               Mode  Cnt  Score   Error   Units
>> 
>> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
>> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
>> 
>> # After
>> UUIDRandomBench.single  thrpt   15  4.421 ? 0.047  ops/us 
>> UUIDRandomBench.max     thrpt   15  6.658 ? 0.092  ops/us ; positive scaling, ~1.5x
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
>> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
>> 
>> # After
>> Benchmark                Mode  Cnt  Score   Error   Units
>> UUIDRandomBench.single  thrpt   15  3.099 ? 0.022  ops/us
>> UUIDRandomBench.max     thrpt   15  3.555 ? 0.062  ops/us  ; positive scaling, ~1.2x
>> 
>> 
>> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
>> 
>> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
>> 
>> 
>> Benchmark               Mode  Cnt   Score   Error   Units
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
>> UUIDRandomBench.single  thrpt  ...
>
> src/java.base/share/classes/java/util/UUID.java line 149:
> 
>> 147:             } else {
>> 148:                 try {
>> 149:                     return SecureRandom.getInstance(PRNG_NAME);
> 
> Part of the change here is that the RNG algorithm is configurable via a system property. The naming of the naming (java.util.UUID.prngName) hints that you might want it to be a standard system property but maybe it's for testing?

Yes, I used them for testing, but left them in, because it would be convenient to have them around for field tuning and diagnostics. This would require a CSR, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1205572151

From michaelm at openjdk.org  Thu May 25 14:23:58 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 25 May 2023 14:23:58 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v4]
In-Reply-To: <2rjN4GzOonpuRQUt_3QkkgAYJ1ZYs81tl8bpZ6wWpYY=.dfb0aeb3-32bc-4ede-bd45-041413455347@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
 <2rjN4GzOonpuRQUt_3QkkgAYJ1ZYs81tl8bpZ6wWpYY=.dfb0aeb3-32bc-4ede-bd45-041413455347@github.com>
Message-ID: <JK1PFQPJMurx3Sa5NOcN4OBMLIJogHKgj7gDU0NpCjo=.0a961217-d9d3-4f08-89cc-01a768366a64@github.com>

On Wed, 24 May 2023 20:46:23 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
>> 
>> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).
>
> Michael McMahon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge branch 'master' into nullStrings
>  - error message and test update
>  - Merge branch 'master' into nullStrings
>  - test comment update
>  - test update
>  - Merge branch 'master' into nullStrings
>  - exception message update
>  - test update
>  - remve whitespace
>  - update
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/207fbcb0...35df1a67

I'll integrate this today unless there are further comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14083#issuecomment-1562998991

From alanb at openjdk.org  Thu May 25 14:26:58 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 May 2023 14:26:58 GMT
Subject: RFR: 8300038: Make new version of JNU_GetStringPlatformChars which
 checks for null characters [v4]
In-Reply-To: <JK1PFQPJMurx3Sa5NOcN4OBMLIJogHKgj7gDU0NpCjo=.0a961217-d9d3-4f08-89cc-01a768366a64@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
 <2rjN4GzOonpuRQUt_3QkkgAYJ1ZYs81tl8bpZ6wWpYY=.dfb0aeb3-32bc-4ede-bd45-041413455347@github.com>
 <JK1PFQPJMurx3Sa5NOcN4OBMLIJogHKgj7gDU0NpCjo=.0a961217-d9d3-4f08-89cc-01a768366a64@github.com>
Message-ID: <ENMam1qOqATPY7ZCuLPATIBYzauLNs_cZ2NR5bbw_s8=.59d83d88-a9a0-49b9-91c4-5a38bbc01f17@github.com>

On Thu, 25 May 2023 14:21:34 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> I'll integrate this today unless there are further comments.

Thanks for addressing my comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14083#issuecomment-1563002770

From jlaskey at openjdk.org  Thu May 25 14:32:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 25 May 2023 14:32:44 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v20]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <DBQsWeRpbETtO0mMAZyfS46Z70Z5fuAEntDOR-k6oXs=.38100514-3edf-48df-abf3-a97b293fa89e@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Improving error recovery in presence of less important syntactic errors in top-level methods and fields.
  
  Author: Jan Lahoda <jlahoda at openjdk.org>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/8ccb9502..cfac821a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=18-19

  Stats: 32 lines in 4 files changed: 24 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From michaelm at openjdk.org  Thu May 25 15:01:21 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 25 May 2023 15:01:21 GMT
Subject: Integrated: 8300038: Make new version of JNU_GetStringPlatformChars
 which checks for null characters
In-Reply-To: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
References: <sTL10tfetAC4svhK6FemxH9KGUGxInMvVBZts3iV6F8=.34e617a2-2892-4b62-adf4-896b46fc5b08@github.com>
Message-ID: <nTSeCoG82gv_0ih-Wyez0gLuIW_s7VN8B2eK4jA4vRA=.ed7090ff-1e87-4fc3-baa7-0c0bdec7bbf8@github.com>

On Mon, 22 May 2023 13:19:04 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> This PR creates a new version of the JNI utility function JNU_GetStringPlatformChars called JNU_GetStringPlatformCharsStrict, which performs additional validation of the returned string, namely that it does not contain any embedded NULL characters. If any such characters are found the function returns NULL with an IAE pending. The change also switches usage in the networking native code to use the new function.
> 
> This cautious approach was taken rather than changing the behavior of the existing function as each native code area needs to review the effect of making the switch. Otherwise, surprising behavior changes might occur (eg undocumented IAE being thrown to user code instead of some other exception).

This pull request has now been integrated.

Changeset: e7edf8d1
Author:    Michael McMahon <michaelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e7edf8d1458ff0d66aedbb0086050c36864702f6
Stats:     188 lines in 9 files changed: 163 ins; 1 del; 24 mod

8300038: Make new version of JNU_GetStringPlatformChars which checks for null characters

Reviewed-by: dfuchs, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/14083

From kbarrett at openjdk.org  Thu May 25 15:23:58 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 25 May 2023 15:23:58 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code
In-Reply-To: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
Message-ID: <Z6J__T8X9bDvrfFjUxNImPMEUwKQmbESvmzYUeDolkQ=.9309297e-ab60-4cd5-9a20-687d545101a8@github.com>

On Thu, 25 May 2023 09:14:14 GMT, JoKern65 <duke at openjdk.org> wrote:

> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
> Some of those are in shared codebase and could be addressed by small adjustments.
> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.

Sorry, but I can't review the warning suppressions. Without more information
about exactly what warnings are being suppressed and where, I have no way to
evaluate whether suppression is an appropriate response. It could be that some
of the warnings are correctly pointing out (possibly serious) flaws that
really need to be fixed.  Continuing to hide them doesn't seem like a winning
strategy to me.

I also suggest avoiding omnibus changes like this when possible (which it is
here). Just because it's all about removing warnings from a new toolchain
doesn't make it a cohesive change. That makes it harder to review and to
manage the review, because it is larger and affects a wide range of areas, so
may need many reviewers. And the whole thing might get stalled by discussion
of one piece.

make/modules/java.desktop/lib/Awt2dLibraries.gmk line 706:

> 704:   # temporarily disable PNG_POWERPC_VSX_OPT which would be set, because
> 705:   # if defined(__PPC64__) && defined(__ALTIVEC__) && defined(__VSX__)
> 706:   # is true, the then needed libpng function .png_init_filter_functions_vsx

s/then//

src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47:

> 45:   #undef malloc
> 46:   extern void *malloc(size_t) asm("vec_malloc");
> 47: #endif

Wow!  And I don't mean that in a good way.  I'm not questioning whether this is correct, just commenting
on how crazy it seems that such a thing might be needed.

test/jdk/java/io/File/libGetXSpace.c line 128:

> 126: #else
> 127:     struct statfs buf;
> 128:     int result = statfs((char*)chars, &buf);

Is this working around a bug in IBM's declaration?

Also, pre-existing, the cast seems really suspicious.  The type of `chars` is `jchar*`, which is a
sequence of 16bit characters.  Does this actually work?  If so, how?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14146#pullrequestreview-1444057072
PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205622153
PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205655676
PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205673657

From simonis at openjdk.org  Thu May 25 15:25:40 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 25 May 2023 15:25:40 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v7]
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <R6DVMij5x0AMpm-QIduWF1NnfmpP86FDRkXaZ2474Ms=.85ac8e8a-3d29-4c57-baa9-4e8e830dad5d@github.com>

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Fix for failing CloseRace test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13956/files
  - new: https://git.openjdk.org/jdk/pull/13956/files/b41604ae..13fb0bf7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13956&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13956&range=05-06

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13956/head:pull/13956

PR: https://git.openjdk.org/jdk/pull/13956

From mcimadamore at openjdk.org  Thu May 25 15:26:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 May 2023 15:26:15 GMT
Subject: Integrated: 8300491: SymbolLookup::libraryLookup accepts strings with
 terminators
In-Reply-To: <CEGuI__aV-PjLH3s4i6AuQhnJ_Y3ukytNuBtuKCxAOE=.375bc90e-d127-4508-85ac-765125fe6873@github.com>
References: <CEGuI__aV-PjLH3s4i6AuQhnJ_Y3ukytNuBtuKCxAOE=.375bc90e-d127-4508-85ac-765125fe6873@github.com>
Message-ID: <XPppkdhJN-nMOJZVJeqW2ISfcN4C4DJAOncDguZTmkE=.4547fefe-d494-4d69-abdd-566ae340f75b@github.com>

On Wed, 24 May 2023 15:22:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> There is a difference in behavior between `System::loadLibrary` and `SymbolLookup::libraryLookup(String)`. While the former catches library names containing NULL chars (because, internally it uses Path/File logic, which reject those), `SymbolLookup` does not. As a result, it is possible to load libraries such as `libGL.so\0foobar`, because the string is passed directly to `dlopen`.
> 
> A similar issue arises when we consider `SymbolLookup::find`, as the name is again sent unmodified to `dlopen`. In reality, some filtering *does* happen in that case, as the native code calls `GetStringUTFChars`:
> 
> https://docs.oracle.com/en/java/javase/20/docs/specs/jni/functions.html#getstringutfchars
> 
> Which encodes the NULL chars in a different form:
> 
> https://docs.oracle.com/en/java/javase/20/docs/specs/jni/types.html#modified-utf-8-strings
> 
> So, in practice, even if the input is not validated, a call to `find` with one or more NULL chars is unlikely to succeed.
> 
> In this patch I have added several checks to make sure that:
> * the name of library passed to `libraryLookup(String)` does not contain `\0` and, if so, throw `IllegalArgumentException` (which is already covered by current spec;
> * the name of a symbol passed to `SymbolLookup::find` does not contain `\0` and, if so, return empty optional. This required changes on all the lookups we implement.

This pull request has now been integrated.

Changeset: 534de6d8
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/534de6d8ae8a241562ffae002a96e40c1ae0b015
Stats:     38 lines in 6 files changed: 38 ins; 0 del; 0 mod

8300491: SymbolLookup::libraryLookup accepts strings with terminators

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.org/jdk/pull/14126

From simonis at openjdk.org  Thu May 25 15:31:04 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Thu, 25 May 2023 15:31:04 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v7]
In-Reply-To: <R6DVMij5x0AMpm-QIduWF1NnfmpP86FDRkXaZ2474Ms=.85ac8e8a-3d29-4c57-baa9-4e8e830dad5d@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <R6DVMij5x0AMpm-QIduWF1NnfmpP86FDRkXaZ2474Ms=.85ac8e8a-3d29-4c57-baa9-4e8e830dad5d@github.com>
Message-ID: <QMJMk0OiRDaIpD8ohct1LFaSn52Kl3fq8R502yRdDdw=.59323392-2b93-41ed-94f0-3bee00d75045@github.com>

On Thu, 25 May 2023 15:25:40 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for failing CloseRace test

Fixing the last bug :)

If we close the writing end of the pipe to jspawnhelper early in `spawnChild()` right after the last write (which I still think is a good idea), we have to use `c->childenv` rather than `childenv` when closing the pipe descriptors at the end of `Java_java_lang_ProcessImpl_forkAndExec()` in order to avoid double closing:


-    closeSafely(childenv[0]);
-    closeSafely(childenv[1]);
+    /* We use 'c->childenv' here rather than 'childenv' because 'spawnChild()' might have
+     * already closed 'c->childenv[1]' and signaled this by setting 'c->childenv[1]' to '-1'.
+     * Otherwise 'c->childenv' and 'childenv' are the same because we just copied 'childenv'
+     * to 'c->childenv' (with 'copyPipe()') before calling 'startChild()'. */
+    closeSafely(c->childenv[0]);
+    closeSafely(c->childenv[1]);


This also fixes `test/jdk/java/lang/ProcessBuilder/CloseRace.java` which could failed sporadically the previous version of the change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1563105428

From mcimadamore at openjdk.org  Thu May 25 15:31:43 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 25 May 2023 15:31:43 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v2]
In-Reply-To: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
Message-ID: <kz9NItuQM63bAaPRJIoX2Fgr-PLQNMkmpfTRGuVmiL4=.fec4c54d-e997-46b7-bab7-77a2f1e132df@github.com>

> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
> 
> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
> 
> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
> 
> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
> 
> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
> 
> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
> 
> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
> 
> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
> 
> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can throw because of an ...

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Tweak javadoc of MemorySegment::get/setUtf8String to deal with overflow

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14098/files
  - new: https://git.openjdk.org/jdk/pull/14098/files/afb7360e..df6c1239

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14098&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14098&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14098/head:pull/14098

PR: https://git.openjdk.org/jdk/pull/14098

From duke at openjdk.org  Thu May 25 16:16:57 2023
From: duke at openjdk.org (JoKern65)
Date: Thu, 25 May 2023 16:16:57 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code
In-Reply-To: <Z6J__T8X9bDvrfFjUxNImPMEUwKQmbESvmzYUeDolkQ=.9309297e-ab60-4cd5-9a20-687d545101a8@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <Z6J__T8X9bDvrfFjUxNImPMEUwKQmbESvmzYUeDolkQ=.9309297e-ab60-4cd5-9a20-687d545101a8@github.com>
Message-ID: <JO--b-rYU9GkmwjXkZx90gkLnIiXagV2ojnUP6AiKws=.37b5f972-205f-4409-8f8a-1b4da3c9c24f@github.com>

On Thu, 25 May 2023 15:18:41 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small adjustments.
>> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.
>
> test/jdk/java/io/File/libGetXSpace.c line 128:
> 
>> 126: #else
>> 127:     struct statfs buf;
>> 128:     int result = statfs((char*)chars, &buf);
> 
> Is this working around a bug in IBM's declaration?
> 
> Also, pre-existing, the cast seems really suspicious.  The type of `chars` is `jchar*`, which is a
> sequence of 16bit characters.  Does this actually work?  If so, how?

This is IBMs declaration of statfs
`extern int statfs(char *, struct statfs *);`
So the compiler will not accept a `const char*`
Indeed I do not know if this ever worked, but my change makes it not worse.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205745144

From lbourges at openjdk.org  Thu May 25 16:39:00 2023
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Thu, 25 May 2023 16:39:00 GMT
Subject: RFR: JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
 [v6]
In-Reply-To: <aeZ8z-znPXfQBL0ptEcSDMpuADDtpPBxCbKRaaaMWnE=.da492fc8-39ac-43f7-8ee3-f9f002334837@github.com>
References: <918oCEfFu2JweXfV-afD1l_AGDDuc7dJwAxip-Ze6ZI=.8d5e9692-23db-47e4-9586-99e53b9cfbb6@github.com>
 <aeZ8z-znPXfQBL0ptEcSDMpuADDtpPBxCbKRaaaMWnE=.da492fc8-39ac-43f7-8ee3-f9f002334837@github.com>
Message-ID: <lqzzQPnWkET7INgKkye8wfC81v-E_tL3L5aNJd21Th8=.1b983905-081b-45e8-839f-c6d00f2a74a6@github.com>

On Sun, 23 Apr 2023 17:33:38 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

>> * improved  mixed insertion sort (makes whole sorting faster)
>> * introduced Radix which sort shows several times boost of performance and has linear complexity instead of n*ln(n)
>> * improved merging sort for almost sorted data
>> * optimized parallel sorting
>> * improved step for pivot candidates and pivot partitioning
>> * extended existing tests
>> * added benchmarking JMH tests
>> * suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError, threshold is 1/16th heap
>> 
>> I am going on previous PR by Vladimir Yaroslavskyi: https://github.com/openjdk/jdk/pull/3938
>
> Laurent Bourg?s has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into dpqs23
>  - fixed javadoc and size renamed to length for clarity
>  - improved and more obvious max length test to always respect max heap memory footprint
>  - Merge branch 'openjdk:master' into dpqs23
>  - rewritten radix sort condition + fixed max buffer size
>  - optimized radix sort heuristic
>  - JDK-8266431: Dual-Pivot Quicksort improvements (Radix sort)
>        * Optimized mixed insertion sort
>        * Optimized insertion sort
>        * Optimized Radix sort
>        * Updated microbenchmark

@AlanBateman @rose00 @mbreinhold Could any core-libs reviewer have a look ?
No hurry as jdk21 rdp0 is coming but later in june ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13568#issuecomment-1563199749

From naoto at openjdk.org  Thu May 25 17:23:06 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 25 May 2023 17:23:06 GMT
Subject: Integrated: 8308108: Support Unicode extension for collation settings
In-Reply-To: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
Message-ID: <Zzi5zCfH9XXtAHLjlmoejrUW5N15QffKHKomRWzAZkI=.7ebbacaf-f62b-4d82-8245-233925342b6e@github.com>

On Wed, 17 May 2023 19:40:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 27ba8bd4
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27ba8bd4edf0c6f6d747579534262c223047a645
Stats:     143 lines in 2 files changed: 142 ins; 0 del; 1 mod

8308108: Support Unicode extension for collation settings

Reviewed-by: iris, rriggs, jlu, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14040

From mdoerr at openjdk.org  Thu May 25 18:21:58 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 25 May 2023 18:21:58 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code
In-Reply-To: <Z6J__T8X9bDvrfFjUxNImPMEUwKQmbESvmzYUeDolkQ=.9309297e-ab60-4cd5-9a20-687d545101a8@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <Z6J__T8X9bDvrfFjUxNImPMEUwKQmbESvmzYUeDolkQ=.9309297e-ab60-4cd5-9a20-687d545101a8@github.com>
Message-ID: <G0ZEvXBOXoDAbZOSj0zcDFxcADCi_Mk-hNOvsJiCw58=.443eb739-394c-44da-8e48-6b157ad59045@github.com>

On Thu, 25 May 2023 15:04:32 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small adjustments.
>> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.
>
> src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47:
> 
>> 45:   #undef malloc
>> 46:   extern void *malloc(size_t) asm("vec_malloc");
>> 47: #endif
> 
> Wow!  And I don't mean that in a good way.  I'm not questioning whether this is correct, just commenting
> on how crazy it seems that such a thing might be needed.

The crazy thing is that `malloc` is defined! That means all places where we use the term malloc are getting replaced without such a workaround. (E.g. for log tags.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1205867287

From davidalayachew at gmail.com  Thu May 25 18:24:29 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 25 May 2023 14:24:29 -0400
Subject: EnumSet doesn't implement SequencedSet
Message-ID: <CAA9v-_MdNZYs1y-V282_XFT7grOOTZyTO9siv7F0ydQnrLn2Vg@mail.gmail.com>

Hello folks,

Since you are asking, let me chime in and say that I use enum's very
frequently. However, my most common use case for them isn't for boolean
flags -- it's actually the strategy pattern. Meaning, attaching a piece of
logic to each value. And more importantly, I order the strategies via the
ordinal of the enum (giving me a priority queue of strategies until I find
one that solves the problem). So for me, the order matters greatly, and I
think that it should be reflected in the API.

Thank you for your time!
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20230525/1ef82dc7/attachment-0001.htm>

From psandoz at openjdk.org  Thu May 25 20:14:00 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 25 May 2023 20:14:00 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
 [v2]
In-Reply-To: <UW0KwW5uYPaaKzTgCRM2I6_R78E26N2SFDJPi-tjSvE=.4463ad73-3d3f-49c9-bc4f-c27c1decf11b@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
 <UW0KwW5uYPaaKzTgCRM2I6_R78E26N2SFDJPi-tjSvE=.4463ad73-3d3f-49c9-bc4f-c27c1decf11b@github.com>
Message-ID: <d1cDEMRB8oN5NvJDcBEWmWdKP3cl4IL4bJbDRVB6mBE=.5d98b5dd-713f-4586-adff-6500b106c4d9@github.com>

On Thu, 25 May 2023 08:21:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of:
>> 
>> - JEP 453: Structured Concurrency (Preview)
>> - JEP 446: Scoped Values (Preview)
>> 
>> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
>> 
>> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
>> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Sync up from loom repo
>  - Remove csm.Threads
>  - Merge
>  - Test should not be in update for main line
>  - Sync with loom repo
>  - Sync up tests frmo loom repo
>  - Sync up with loom repo
>  - Sync update API/impl/tests
>  - Merge
>  - Sync up with loom repo
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/89f2d458...e92ba524

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 521:

> 519:      * captured when the task scope was created.
> 520:      *
> 521:      * <p> This method returns a {@link Subtask Subtask}to represent the <em>forked

Suggestion:

     * <p> This method returns a {@link Subtask Subtask} to represent the <em>forked

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1205960578

From psandoz at openjdk.org  Thu May 25 20:24:59 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 25 May 2023 20:24:59 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
 [v2]
In-Reply-To: <UW0KwW5uYPaaKzTgCRM2I6_R78E26N2SFDJPi-tjSvE=.4463ad73-3d3f-49c9-bc4f-c27c1decf11b@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
 <UW0KwW5uYPaaKzTgCRM2I6_R78E26N2SFDJPi-tjSvE=.4463ad73-3d3f-49c9-bc4f-c27c1decf11b@github.com>
Message-ID: <12gGPOiyskDCTWaM5sfOFpPt4AlUnAS2MqvyQOOEcGA=.a650e165-944b-4053-b3c0-5c450f6d7f56@github.com>

On Thu, 25 May 2023 08:21:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of:
>> 
>> - JEP 453: Structured Concurrency (Preview)
>> - JEP 446: Scoped Values (Preview)
>> 
>> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
>> 
>> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
>> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Sync up from loom repo
>  - Remove csm.Threads
>  - Merge
>  - Test should not be in update for main line
>  - Sync with loom repo
>  - Sync up tests frmo loom repo
>  - Sync up with loom repo
>  - Sync update API/impl/tests
>  - Merge
>  - Sync up with loom repo
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/89f2d458...e92ba524

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 473:

> 471:     /**
> 472:      * Ensures that the current thread is the owner of this task scope and that it joined
> 473:      * (with {@link #join()} or {@link #joinUntil(Instant)} after {@linkplain #fork(Callable)

Suggestion:

     * (with {@link #join()} or {@link #joinUntil(Instant)}) after {@linkplain #fork(Callable)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13932#discussion_r1205969173

From mchung at openjdk.org  Thu May 25 20:45:34 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 25 May 2023 20:45:34 GMT
Subject: RFR: 8307944: ClassFileDumper should only load java.nio.file.Path if
 enabled
Message-ID: <jdahgZeAZtruycStvqWmSB3YbdTCN063GjMRXP9xJy0=.e3b786d2-d2be-47e1-a258-f7f5e0d61c7a@github.com>

Change `ClassFileDumper` constructor to take a `String` rather than `Path` to avoid the file system implementation classes loaded during startup.  In addition, `FilePermission` also causes the default file system to be initialized. 

This patch changes `ClassFileDumper` to validate the given path only if it's enabled and not to use limited `doPrivileged` to avoid the initialization of `FilePermission` class and the file system implementation classes by default.

This patch also changes `ClassFileDumper::write` to use `File` instead of `Path` because of JDK-8306678.  `OperatingSystem::<clinit>` causes `Enum::valueOf` to be called which calls core reflection which in turns invokes method handles.   If `-Djdk.invoke.MethodHandle.dumpMethodHandleInternals` is set, VM initialization would fail because `BootLoader::<clinit>` causes `ClassLoaderHelper` to initialize which in turn causes `OperatingSystem` be initialized.   If additional LFs are spinned and dumped, if `ClassFileDumper` uses `Path` for writing, `FileSystems::getDefault` would fail with `NullPointerException` because it calls `BootLoader.loadLibrary` which is not fully initialized. 

A separate issue will be filed to follow up the startup overhead of `OperatingSystem`.

-------------

Commit messages:
 - 8307944: ClassFileDumper should only load java.nio.file.Path if enabled

Changes: https://git.openjdk.org/jdk/pull/14160/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14160&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8307944
  Stats: 184 lines in 6 files changed: 85 ins; 56 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/14160.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14160/head:pull/14160

PR: https://git.openjdk.org/jdk/pull/14160

From psandoz at openjdk.org  Thu May 25 20:46:02 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 25 May 2023 20:46:02 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
 [v2]
In-Reply-To: <UW0KwW5uYPaaKzTgCRM2I6_R78E26N2SFDJPi-tjSvE=.4463ad73-3d3f-49c9-bc4f-c27c1decf11b@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
 <UW0KwW5uYPaaKzTgCRM2I6_R78E26N2SFDJPi-tjSvE=.4463ad73-3d3f-49c9-bc4f-c27c1decf11b@github.com>
Message-ID: <6b0o5vkvODNuB6vLHAbz9IUBULP8YlFdArdDENoqcps=.7ba2e078-8107-4095-bbfc-c5f4b2a95d13@github.com>

On Thu, 25 May 2023 08:21:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of:
>> 
>> - JEP 453: Structured Concurrency (Preview)
>> - JEP 446: Scoped Values (Preview)
>> 
>> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
>> 
>> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
>> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Sync up from loom repo
>  - Remove csm.Threads
>  - Merge
>  - Test should not be in update for main line
>  - Sync with loom repo
>  - Sync up tests frmo loom repo
>  - Sync up with loom repo
>  - Sync update API/impl/tests
>  - Merge
>  - Sync up with loom repo
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/89f2d458...e92ba524

This looks good (both `ScopedValue` and `StructuredTaskScope`).

I recall some discussion on the loom email list noting that `ScopedValue` instances are like capabilities and should be shared carefully (like `MethodHandle`s in some sense). I think it would be useful to follow up on that in the specification.

I am uncertain on the name `Subtask` but cannot think of anything better, perhaps during this round of preview we might find something else.

For a small API `StructureTaskScope` is rather powerful and deftly combines language, library, and platform features (virtual threads). 

I suggest revisiting the constraints on operating on `SubTask` instances. I get the motivation but i wonder if the additional specification and implementation work required to properly describe the behaviour and enforce it is really worth it. Such a restriction tends to feel artificial given there are no side-effects to such operations, and further we cannot enforce such restrictions in the compiler. 
The constraints of `fork`, `join`, `shutdown`, and `close` are key with the idiomatic use with try-with-resources. Just let subtasks be accessible by any thread for all its methods and provide clear documentation on the recommended use.

-------------

PR Review: https://git.openjdk.org/jdk/pull/13932#pullrequestreview-1444622838

From joehw at openjdk.org  Thu May 25 21:16:07 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 25 May 2023 21:16:07 GMT
Subject: RFR: 8303530: Redefine JAXP Configuration File [v12]
In-Reply-To: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
Message-ID: <GcW_Z092oSSSf6lAPIRIcaJvXhhn89I5pfRE3JZGTpA=.47e1d057-bf18-454d-aaad-a15610f18480@github.com>

> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8303531
> 
> Tests: XML SQE and JCK tests passed.

Joe Wang has updated the pull request with a new target base 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:

 - Merge branch 'master' into JDK-8303530
 - address review comments
 - update to address review comments
 - Merge branch 'master' into JDK-8303530
 - Update based on the review meeting on 4/5. Added (duplicated) definitions in jaxp.properties; Rewrote Property Precedence with samples; Other updates.
 - update javadoc as discussed in the review meeting; add a sample configuration file jaxp.properties; update impl and tests accordingly.
 - continue support stax.properties at the impl level, though dropped from the spec
 - change prefix from jdk to java
 - change prefix from jdk to java; rm zip file that accidentally checked in
 - update config file description; add a general scope and order section; move value definition for external properties to class description
 - ... and 2 more: https://git.openjdk.org/jdk/compare/5ebcd202...6506451c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12985/files
  - new: https://git.openjdk.org/jdk/pull/12985/files/474d3470..6506451c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=10-11

  Stats: 190530 lines in 3310 files changed: 143376 ins; 22624 del; 24530 mod
  Patch: https://git.openjdk.org/jdk/pull/12985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12985/head:pull/12985

PR: https://git.openjdk.org/jdk/pull/12985

From joehw at openjdk.org  Thu May 25 21:32:21 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 25 May 2023 21:32:21 GMT
Subject: RFR: 8303530: Redefine JAXP Configuration File [v13]
In-Reply-To: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
Message-ID: <bsxHc-U6tx17QS93MHl5h0Z9CyW0cBKpj3or2RxPrcU=.2613e3c3-7e6f-4aca-b553-dfa3bb293ad0@github.com>

> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8303531
> 
> Tests: XML SQE and JCK tests passed.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  Changes after many iterations in 3 weeks: added intro, streamlined sections leading to the Configuration File section with most of the text edited; removed duplicate sections in implNote; Other adjustments reflecting these changes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12985/files
  - new: https://git.openjdk.org/jdk/pull/12985/files/6506451c..98d9417b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=11-12

  Stats: 624 lines in 6 files changed: 272 ins; 256 del; 96 mod
  Patch: https://git.openjdk.org/jdk/pull/12985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12985/head:pull/12985

PR: https://git.openjdk.org/jdk/pull/12985

From joehw at openjdk.org  Thu May 25 21:37:00 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 25 May 2023 21:37:00 GMT
Subject: RFR: 8303530: Redefine JAXP Configuration File [v9]
In-Reply-To: <gA2qUanp3A8uN-hFTEOv7thSJ3slpMHX7rH6vR1AaDQ=.1d7f1c0e-9ac3-4447-82cc-6d9b3ee04181@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <w_VQMDXdJScfmyacC0Mxsq4ZshVvw8vLNEcw62YbH1I=.4296584d-da35-4b67-8914-ac26aeef1873@github.com>
 <tii6-GGgEZTZiTOmh83uN4qrUaK1WXvmJJTfxD5oHvA=.e3048ff2-e0e6-4f3f-b1fd-8533ce5264ab@github.com>
 <fnyLl2iOgGVDKb12U9zrej7-SEjK2_RxYAdW2jeucA8=.4b8ea8d9-a305-40a5-8c1b-4fbf2429aa7b@github.com>
 <1I219vxR0joKlSO2Yo3sPEzrD29mWoh_xSYcC2UTiLU=.81ad6084-e199-459d-8399-ce38e7e10ef1@github.com>
 <gA2qUanp3A8uN-hFTEOv7thSJ3slpMHX7rH6vR1AaDQ=.1d7f1c0e-9ac3-4447-82cc-6d9b3ee04181@github.com>
Message-ID: <its13zFY0ng8nDi1Fu782gYlewA6heef5EIfZm2-NlE=.44bdfd18-5a11-4239-971c-a92e6e9a274b@github.com>

On Fri, 5 May 2023 08:12:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Changed the opening statement and also the naming of config file as above.
>
> I've looked through the updated proposal but I think the intro is going to take a few iterations to get to something that is easy to read. I had hoped the intro would provide an overview of the APIs in the module and establish the terminology that is needed to read further. The existing text isn't great but it does name the APIs in the module so the reader knows there are several APIs for processing XML. With the update, the names of the APIs in the module is lost, and in its place, the text switches to "XML library" and talks about factories and processors. I understand the focus of this PR is to introduce a system property to allow for configuration file but it's changing important API docs that introduce the APIs. 
> 
> My view is that we have to create a new introduction that provides a summary of the APIs in the module and a short summary of some concepts. We can't have API docs talk about "factories" and "processors" without defining them. This intro/setup is needed before diving into the configuration, which we might title "Configuring factories and processors" with a summary of the various ways that they can be configured. I think the text from the "Property Precedence" section will need to move into the section on Configuration as it is hard to list the various ways to configure without also talking about precedence.
> 
> Once you have a good introduction and seciton on Configuration then I think the other sections will follow without too much work.

New introduction added, along with sections leading up to the Configuration File.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1206026416

From joehw at openjdk.org  Thu May 25 21:37:04 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 25 May 2023 21:37:04 GMT
Subject: RFR: 8303530: Redefine JAXP Configuration File [v11]
In-Reply-To: <9L3gcsoPMzKGzQTnl3n0PgJ4cF3O2cOaKT3OYdV_YLI=.16295c89-c1d6-4892-91d9-d1a6ffd6bd5d@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <qI282STKG_sL2MFdI-DYw9NP0P2-veK7mkNWmfenQhc=.9f72d3de-acc9-464f-a08d-e9b9c02eac9a@github.com>
 <9L3gcsoPMzKGzQTnl3n0PgJ4cF3O2cOaKT3OYdV_YLI=.16295c89-c1d6-4892-91d9-d1a6ffd6bd5d@github.com>
Message-ID: <E4RYNuKL3aUi5ylB4FTrP-qFDT1mTD996sSV8WwF2JM=.16f3b647-e611-419a-9be2-89c641ca9c56@github.com>

On Fri, 5 May 2023 08:16:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address review comments
>
> src/java.xml/share/conf/jaxp.properties line 2:
> 
>> 1: ################################################################################
>> 2: #           XML Library (java.xml) Configuration File
> 
> The file is jaxp.properties and the module is Java APIs for XML Processing. The use of "XML Library (java.xml)" is confusing here, I'm concerned that it will be inconsistent with all the existing docs.

"JAXP Configuration File" is now used throughout the spec.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1206023820

From naoto at openjdk.org  Thu May 25 21:39:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 25 May 2023 21:39:40 GMT
Subject: RFR: 8308316: Default decomposition mode in Collator [v2]
In-Reply-To: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>
References: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>
Message-ID: <8XsjlRBeuKqluDnEEMHmVYCK7-tEFb2wHGrPlkFZ5do=.531520c9-730f-4370-9219-838a1e759a1a@github.com>

> Amending the description about the default decomposition mode in `Collator.NO_DECOMPOSITION` javadoc.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Default values
 - Merge branch 'master' into JDK-8308316-default-decomposition
 - Merge branch 'master' into JDK-8308316-default-decomposition
 - 8308369: Default decomposition mode in Collator

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14049/files
  - new: https://git.openjdk.org/jdk/pull/14049/files/90eb68f7..304c5a6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14049&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14049&range=00-01

  Stats: 50356 lines in 1201 files changed: 34222 ins; 9623 del; 6511 mod
  Patch: https://git.openjdk.org/jdk/pull/14049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14049/head:pull/14049

PR: https://git.openjdk.org/jdk/pull/14049

From jlu at openjdk.org  Thu May 25 21:58:08 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 25 May 2023 21:58:08 GMT
Subject: Integrated: 8159023: Engineering notation of DecimalFormat does not
 work as documented
In-Reply-To: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
Message-ID: <V1E6zUYU2ZTWuPe1zcozoIVGYSrfwtICN44YgfVFlUg=.08c33ab1-318f-495b-ad9c-9314a75cd91d@github.com>

On Sat, 20 May 2023 00:00:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the Scientific Notation section of Decimal Format. It aims to resolve [JDK-8159023](https://bugs.openjdk.org/browse/JDK-8159023) as well as [JDK-6282188](https://bugs.openjdk.org/browse/JDK-6282188).
> 
> **Scientific Notation** in Decimal Format contains the definition for a scientific notation formatted number's mantissa as such: _The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits. For example, 12345 formatted with "##0.##E0" is "12.3E3"._
> 
> Both the definition and example are incorrect, as the actual result is "12.E345". 
> 
> The following example data show that scientific notation formatted numbers do not adhere to that definition. As, according to the definition, the following numbers should have 3 significant digits, but in reality, they have up to 5.
> 
> 123 formatted by ##0.#E0 is 123E0
> 1234 formatted by ##0.#E0 is 1.234E3
> 12345 formatted by ##0.#E0 is 12.34E3
> 123456 formatted by ##0.#E0 is 123.5E3
> 1234567 formatted by ##0.#E0 is 1.235E6
> 12345678 formatted by ##0.#E0 is 12.35E6
> 123456789 formatted by ##0.#E0 is 123.5E6 
> 
> 
> The actual definition of the mantissa, as well as examples and further context are included in this change. In addition, a test has been added that tests various patterns to numbers and ensures the format follows the new definition's mathematical expression.

This pull request has now been integrated.

Changeset: 46c4da7f
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46c4da7fddb8103934f2a90b4456a5ce6ed3467c
Stats:     147 lines in 2 files changed: 140 ins; 0 del; 7 mod

8159023: Engineering notation of DecimalFormat does not work as documented

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/14066

From rriggs at openjdk.org  Thu May 25 22:14:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 25 May 2023 22:14:56 GMT
Subject: RFR: 8307944: ClassFileDumper should only load java.nio.file.Path
 if enabled
In-Reply-To: <jdahgZeAZtruycStvqWmSB3YbdTCN063GjMRXP9xJy0=.e3b786d2-d2be-47e1-a258-f7f5e0d61c7a@github.com>
References: <jdahgZeAZtruycStvqWmSB3YbdTCN063GjMRXP9xJy0=.e3b786d2-d2be-47e1-a258-f7f5e0d61c7a@github.com>
Message-ID: <6hXYzbj7SBy6DAp08OcHAw8EIVETDGYZFXfZcOWTJKc=.25d36e8f-b4ce-48ab-8a7a-f5598701b2b4@github.com>

On Thu, 25 May 2023 20:23:27 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Change `ClassFileDumper` constructor to take a `String` rather than `Path` to avoid the file system implementation classes loaded during startup.  In addition, `FilePermission` also causes the default file system to be initialized. 
> 
> This patch changes `ClassFileDumper` to validate the given path only if it's enabled and not to use limited `doPrivileged` to avoid the initialization of `FilePermission` class and the file system implementation classes by default.
> 
> This patch also changes `ClassFileDumper::write` to use `File` instead of `Path` because of JDK-8306678.  `OperatingSystem::<clinit>` causes `Enum::valueOf` to be called which calls core reflection which in turns invokes method handles.   If `-Djdk.invoke.MethodHandle.dumpMethodHandleInternals` is set, VM initialization would fail because `BootLoader::<clinit>` causes `ClassLoaderHelper` to initialize which in turn causes `OperatingSystem` be initialized.   If additional LFs are spinned and dumped, if `ClassFileDumper` uses `Path` for writing, `FileSystems::getDefault` would fail with `NullPointerException` because it calls `BootLoader.loadLibrary` which is not fully initialized. 
> 
> A separate issue will be filed to follow up the startup overhead of `OperatingSystem`.

Looks good, delaying the checking of the file system until its is needed will save on startup.

src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 136:

> 134:         // recursive initialization during early startup. e.g.
> 135:         // Enum::valueOf causes method handle to be invoked which
> 136:         // may cause classes to be spinned and dumped

This comment could be omitted; it won't age well and is out of context for the fix.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14160#pullrequestreview-1444720329
PR Review Comment: https://git.openjdk.org/jdk/pull/14160#discussion_r1206049390

From naoto at openjdk.org  Thu May 25 22:19:18 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 25 May 2023 22:19:18 GMT
Subject: RFR: 8308316: Default decomposition mode in Collator [v3]
In-Reply-To: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>
References: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>
Message-ID: <uLvdxZ39JHYsB9F1t_qaLnWA7ckhC3wDeZ3y2KYPjUo=.824c2878-9566-49c1-876c-ace94217e03d@github.com>

> Amending the description about the default decomposition mode in `Collator.NO_DECOMPOSITION` javadoc.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  use present tense

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14049/files
  - new: https://git.openjdk.org/jdk/pull/14049/files/304c5a6b..717f4c92

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14049&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14049&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14049/head:pull/14049

PR: https://git.openjdk.org/jdk/pull/14049

From duke at openjdk.org  Thu May 25 22:48:55 2023
From: duke at openjdk.org (ExE Boss)
Date: Thu, 25 May 2023 22:48:55 GMT
Subject: RFR: 8308842: Consolidate exceptions thrown from Class-File API
In-Reply-To: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
References: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
Message-ID: <AGo3TiQkl5iXTFNSKMo4gYY7spZiQxSIl5PxI1wwv8g=.dd93829c-a41b-4690-8dad-3184aa7d1a98@github.com>

On Thu, 25 May 2023 08:29:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API actually throws wide variety of exceptions based on the actual situation. Complete error handling code must cover `IndexOutOfBoundsException`, `IllegalStateException` and `IllegalArgumentException`. 
> 
> Based on previous discussions we decided to consolidate on `IllegalArgumentException` with possible sub-classes. 
> 
> It allows easy common error handling in majority of use case, however it allows also to distinguish source of the error when needed (for example `javap` needs to know if the exception comes from constant poll or not). 
> 
> Newly introduced `ConstantPoolException` extends `IllegalArgumentException` to indicate the source of the problem is in constant pool. 
> 
> Please review.
> 
> Thanks,
> Adam

src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 389:

> 387:         // Check for empty try block
> 388:         if (tryBlock.isEmpty()) {
> 389:             throw new IllegalArgumentException("The body of the try block is empty");

This?exception should?be?documented in?the?method?s?**Javadoc**.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14143#discussion_r1206065903

From psandoz at openjdk.org  Thu May 25 23:25:59 2023
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 25 May 2023 23:25:59 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v6]
In-Reply-To: <c1et2B8bNarPWOrpKzWq-uRaxpybGbEJkwBwDd7jcro=.34594240-c8ea-4507-bb22-3bee3ee3bb99@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <c1et2B8bNarPWOrpKzWq-uRaxpybGbEJkwBwDd7jcro=.34594240-c8ea-4507-bb22-3bee3ee3bb99@github.com>
Message-ID: <Vu2dAGqbOVDU4z2Lit022rr1Q7ICp7IrdzaWatZuqvQ=.6eb6c909-6f25-45e1-bb30-dc3c5fd81beb@github.com>

On Wed, 24 May 2023 09:36:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into linker_types
>  - Drop "unsigned short"
>    Beef up javadoc
>  - Address further review comments
>  - Address review comments
>  - More javadoc tweaks
>  - Tweak javadoc
>  - Tweak javadoc
>    Add char type
>  - Initial push

This all looks reasonable. I say let's soak it and then see if we need refine based on feedback and further research (e.g., if we find we need to declare multiple layouts per ABI type for extensibility reasons).

-------------

Marked as reviewed by psandoz (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14037#pullrequestreview-1444770061

From apangin at openjdk.org  Fri May 26 00:20:03 2023
From: apangin at openjdk.org (Andrei Pangin)
Date: Fri, 26 May 2023 00:20:03 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access
In-Reply-To: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
Message-ID: <nLbp1mGK9qZaUwM8WMCmPDQe-QakWokmFvwMk1S7qUU=.780a0535-a8be-4309-8f93-8f2ed8eb6456@github.com>

On Wed, 24 May 2023 19:36:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
> 
> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
> 
> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
> 
> 
> Benchmark               Mode  Cnt  Score   Error   Units
> 
> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
> 
> # After
> UUIDRandomBench.single  thrpt   15  4.421 ? 0.047  ops/us 
> UUIDRandomBench.max     thrpt   15  6.658 ? 0.092  ops/us ; positive scaling, ~1.5x
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
> 
> # After
> Benchmark                Mode  Cnt  Score   Error   Units
> UUIDRandomBench.single  thrpt   15  3.099 ? 0.022  ops/us
> UUIDRandomBench.max     thrpt   15  3.555 ? 0.062  ops/us  ; positive scaling, ~1.2x
> 
> 
> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
> 
> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
> 
> 
> Benchmark               Mode  Cnt   Score   Error   Units
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
> UUIDRandomBench.single  thrpt   15  3.661 ? 0.008  ops/us
> UUIDRandomBench...

src/java.base/share/classes/java/util/UUID.java line 224:

> 222:                     // Try to pull the UUID from the current buffer at current position.
> 223:                     if (stamp != 0) {
> 224:                         int p = (int)VH_POS.getAndAdd(this, UUID_CHUNK);

An atomic update together with an optimistic lock looks non-idiomatic use of StampedLock to me. Won't a simple CAS loop be simpler? E.g. in pseudocode:

while ((p = this.pos) + 16) < buf.length) {
    long msb = getLong(buf, p);
    long lsb = getLong(buf, p + 8);
    if (cas(this.pos, p, p + 16)) {
        return new UUID(msb, lsb);
    }
}

// refill buffer under lock

src/java.base/share/classes/java/util/UUID.java line 226:

> 224:                         int p = (int)VH_POS.getAndAdd(this, UUID_CHUNK);
> 225:                         if (p < BUF_SIZE) {
> 226:                             uuid = new UUID(buf, p);

We can read msb/lsb from the buffer here and move object allocation outside the lock to reduce the length of the critical section.

src/java.base/share/classes/java/util/UUID.java line 260:

> 258:                         buf[c + 8] &= 0x3f;  /* clear variant        */
> 259:                         buf[c + 8] |= (byte) 0x80;  /* set to IETF variant  */
> 260:                     }

I'm not sure I understand the point about initialization. Why not just setting the required version bits right in UUID constructor without updating the array? This will be faster and simpler IMO.

src/java.base/share/classes/java/util/UUID.java line 286:

> 284:         long lsb = 0;
> 285:         for (int i = start; i < start + 8; i++) {
> 286:             msb = (msb << 8) | (data[i] & 0xff);

Can we use VarHandle/ByteBuffer to read 64 bits at a time?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206104940
PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206105877
PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206096052
PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206097261

From duke at openjdk.org  Fri May 26 00:52:55 2023
From: duke at openjdk.org (Brett Okken)
Date: Fri, 26 May 2023 00:52:55 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access
In-Reply-To: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
Message-ID: <BvoKDJ_TxeJP4EPvpHaP_V3hI6HzmnpuYrlIMM5qEO0=.c7421cc9-8579-4549-82ab-8d82919161f4@github.com>

On Wed, 24 May 2023 19:36:44 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
> 
> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
> 
> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
> 
> 
> Benchmark               Mode  Cnt  Score   Error   Units
> 
> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
> 
> # After
> UUIDRandomBench.single  thrpt   15  4.421 ? 0.047  ops/us 
> UUIDRandomBench.max     thrpt   15  6.658 ? 0.092  ops/us ; positive scaling, ~1.5x
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
> 
> # After
> Benchmark                Mode  Cnt  Score   Error   Units
> UUIDRandomBench.single  thrpt   15  3.099 ? 0.022  ops/us
> UUIDRandomBench.max     thrpt   15  3.555 ? 0.062  ops/us  ; positive scaling, ~1.2x
> 
> 
> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
> 
> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
> 
> 
> Benchmark               Mode  Cnt   Score   Error   Units
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
> UUIDRandomBench.single  thrpt   15  3.661 ? 0.008  ops/us
> UUIDRandomBench...

src/java.base/share/classes/java/util/UUID.java line 255:

> 253:                     // initializations, and thus false sharing between reader threads.
> 254:                     random.nextBytes(buf);
> 255:                     for (int c = 0; c < BUF_SIZE; c += UUID_CHUNK) {

I think this could be faster by using a ByteBuffer (or VarHandle) to process as longs.

https://mail.openjdk.org/pipermail/core-libs-dev/2023-March/101249.html

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206118465

From darcy at openjdk.org  Fri May 26 06:10:07 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 May 2023 06:10:07 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v20]
In-Reply-To: <DBQsWeRpbETtO0mMAZyfS46Z70Z5fuAEntDOR-k6oXs=.38100514-3edf-48df-abf3-a97b293fa89e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <DBQsWeRpbETtO0mMAZyfS46Z70Z5fuAEntDOR-k6oXs=.38100514-3edf-48df-abf3-a97b293fa89e@github.com>
Message-ID: <lVuFaWAEYdySBVKt4XQF0DXjKInm34bGG1we2V-SGN0=.e9d4546f-8d62-4a61-a179-7245684c2f9e@github.com>

On Thu, 25 May 2023 14:32:44 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improving error recovery in presence of less important syntactic errors in top-level methods and fields.
>   
>   Author: Jan Lahoda <jlahoda at openjdk.org>

test/jdk/tools/launcher/InstanceMainTest.java line 31:

> 29:  * @run main InstanceMainTest
> 30:  */
> 31: public class InstanceMainTest extends TestHelper {

By my reading of the spec, "main" methods can be defined in record classes and enum classes as well as normal classes.
Are there tests for record and enum main method operation?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1206277064

From david.holmes at oracle.com  Fri May 26 06:10:09 2023
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 26 May 2023 16:10:09 +1000
Subject: [External] : Re: Classes used in method body are loaded lazily or
 eagerly depending on method return type
In-Reply-To: <22412a94-1d04-fb01-d309-870a55328a41@oracle.com>
References: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
 <c4954b0c-ca2a-7cb1-4710-36af333e7d06@oracle.com>
 <59b1c6ff-ab08-8a8f-12b7-21f78285571b@oracle.com>
 <1813541396.62977656.1684881306040.JavaMail.zimbra@univ-eiffel.fr>
 <2cf71b1c-7ac1-e158-1c80-762caa3e6e82@oracle.com>
 <36c13724-9c08-c082-67ab-fa24773314ec@oracle.com>
 <22412a94-1d04-fb01-d309-870a55328a41@oracle.com>
Message-ID: <3280f8e4-0f07-598c-f6e7-32c081da2c5e@oracle.com>

On 25/05/2023 7:21 pm, Raffaello Giulietti wrote:
> 
> Yes, ChildClass.class is removed from the filesystem.
> 
> 
> And here's, the relevant info when running with -Xlog:class+init, 
> showing that verification succeeds for both TestLoading$ObjectReturner 
> and TestLoading$BaseClassReturner:
> 
> loading: TestLoading$ObjectReturner...
> [0.039s][info][class,init] Start class verification for: 
> TestLoading$ObjectReturner
> [0.039s][info][class,init] End class verification for: 
> TestLoading$ObjectReturner
> [0.039s][info][class,init] 500 Initializing 
> 'TestLoading$ObjectReturner'(no method) (0x0000000801001800)
> loading: TestLoading$BaseClassReturner...
> [0.039s][info][class,init] Start class verification for: 
> TestLoading$BaseClassReturner
> [0.039s][info][class,init] End class verification for: 
> TestLoading$BaseClassReturner
> [0.039s][info][class,init] 501 Initializing 
> 'TestLoading$BaseClassReturner'(no method) (0x0000000801001a08)

Can you enable -xlog:verification and class+load too please.

Thanks,
David
-----

> 
> 
> 
> On 2023-05-25 04:57, David Holmes wrote:
>> On 25/05/2023 12:34 am, Raffaello Giulietti wrote:
>>> As mentioned in my previous email, if you move the member class 
>>> ChildClass out of TestLoading (out of the nest), and make it a 
>>> top-level class like
>>>
>>> ???? public class ChildClass extends TestLoading.BaseClass {
>>> ???? }
>>>
>>> and change
>>>
>>> ???? URL classFileB = 
>>> TestLoading.class.getResource(TestLoading.class.getSimpleName() + 
>>> "$ChildClass.class");
>>>
>>> to
>>>
>>> ???? URL classFileB = 
>>> TestLoading.class.getResource(ChildClass.class.getSimpleName() + 
>>> ".class");
>>>
>>> rebuild everything and run, nothing is thrown.
>>>
>>> ???? deleting: <path-to>/ChildClass.class
>>> ???? loading: TestLoading$ObjectReturner...
>>> ???? loading: TestLoading$BaseClassReturner...
>>>
>>> I can't see any substantial difference, except that the nest rooted 
>>> at TestLoading lacks a member in the original setup and lacks nothing 
>>> in this setup.
>>>
>>> What's an explanation for this difference?
>>
>> Are you sure it actually deletes the file? What do you see when you 
>> enable class+load/init and verification logging?
>>
>> David
>> -----
>>
>>
>>
>>>
>>> Greetings
>>> Raffaello
>>>
>>>
>>> On 2023-05-24 00:35, Remi Forax wrote:
>>>>
>>>>
>>>> ----- Original Message -----
>>>>> From: "David Holmes" <david.holmes at oracle.com>
>>>>> To: "Raffaello Giulietti" <raffaello.giulietti at oracle.com>, 
>>>>> "core-libs-dev" <core-libs-dev at openjdk.org>
>>>>> Sent: Wednesday, May 24, 2023 12:23:24 AM
>>>>> Subject: Re: Classes used in method body are loaded lazily or 
>>>>> eagerly depending on method return type
>>>>
>>>>> On 24/05/2023 12:50 am, Raffaello Giulietti wrote:
>>>>>> I think the problem here is that you are deleting a class in a nest.
>>>>>>
>>>>>> During the verification of BaseClassReturner.getObject(), access 
>>>>>> control
>>>>>> (JVMS, 5.4.4, second half) determines that the nest is broken, as
>>>>>> ChildClass is not present anymore.
>>>>>
>>>>> Not sure access control gets involved at this stage of the 
>>>>> verification
>>>>> process. But in any case turning on logging does not show anything
>>>>> related to nestmates happening between BaseClass and ChildClass. It
>>>>> seems to just be the resolution of the return type during verification
>>>>> of the method, that causes the loading of ChildClass and the 
>>>>> subsequent
>>>>> CNFE if it has been removed.
>>>>>
>>>>>> If you move ChildClass out of TestLoading so that it becomes a 
>>>>>> top-level
>>>>>> class extending TestLoading.BaseClass, and if you adapt the line that
>>>>>> initializes the local var classFileB to refer to the new location, 
>>>>>> the
>>>>>> code will not throw, despite ChildClass being deleted.
>>>>>
>>>>> My simplified test shows it still throws when verifying 
>>>>> BaseClassReturner.
>>>>
>>>> Nestmate checking is done lazily, so if you do not call a 
>>>> method/access a field of a nested class, the VM should not trigger a 
>>>> class loading.
>>>>
>>>> Moreover, if you test with Java 8 (nestmates were introduced in Java 
>>>> 11), it failed too.
>>>> That's another clue that the error is not related to nestmates 
>>>> checking.
>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>> David
>>>>
>>>> regards,
>>>> R?mi
>>>>
>>>>>
>>>>>>
>>>>>> Greetings
>>>>>> Raffaello
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 2023-05-23 13:20, ?????? ??????? wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> originally this question was asked here:
>>>>>>> https://urldefense.com/v3/__https://stackoverflow.com/q/76260269/12473843__;!!ACWV5N9M2RV99hQ!Mb5nhj7EbuftWzF7s4GX9auUZZlyPyCUnLs64c4mkmSGJm4pw0CNgRzQR5wOYuApyE_kHSAnVxGyTM9PHz5StCppGw$ ,
>>>>>>> the code sample for reproduction will be put below or can be 
>>>>>>> found via
>>>>>>> the link
>>>>>>>
>>>>>>> The issue is about eager/lazy loading of a class depending on method
>>>>>>> return type.
>>>>>>> If one runs the code below with Java 11-19 it will fail with
>>>>>>> NoClassDefFoundError (this is expected as delete class file for
>>>>>>> ChildClass):
>>>>>>>
>>>>>>> java.lang.NoClassDefFoundError: org/example/TestLoading$ChildClass
>>>>>>> ?????at java.base/java.lang.Class.forName0(Native Method)
>>>>>>> ?????at java.base/java.lang.Class.forName(Class.java:390)
>>>>>>> ?????at java.base/java.lang.Class.forName(Class.java:381)
>>>>>>> ?????at org.example.TestLoading.loadMyClass(TestLoading.java:29)
>>>>>>> ?????at org.example.TestLoading.main(TestLoading.java:23)
>>>>>>> Caused by: java.lang.ClassNotFoundException:
>>>>>>> org.example.TestLoading$ChildClass
>>>>>>> ?????at
>>>>>>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>>>>>>> ?????at
>>>>>>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>>>>>>> ?????at 
>>>>>>> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>>>>>>> ?????... 5 more
>>>>>>>
>>>>>>> As of Java 20 chapter 12.4.1 of JLS states:
>>>>>>> ---------------------------------------------------------
>>>>>>> A class or interface T will be initialized immediately before the
>>>>>>> first occurrence of any one of the following:
>>>>>>>
>>>>>>> - T is a class and an instance of T is created.
>>>>>>> - a static method declared by T is invoked.
>>>>>>> - a static field declared by T is assigned.
>>>>>>> - a static field declared by T is used and the field is not a 
>>>>>>> constant
>>>>>>> variable (?4.12.4).
>>>>>>>
>>>>>>> When a class is initialized, its superclasses are initialized (if 
>>>>>>> they
>>>>>>> have not been previously initialized), as well as any 
>>>>>>> superinterfaces
>>>>>>> (?8.1.5) that declare any default methods (?9.4.3) (if they have not
>>>>>>> been previously initialized).
>>>>>>> Initialization of an interface does not, of itself, cause
>>>>>>> initialization of any of its superinterfaces.
>>>>>>> A reference to a static field (?8.3.1.1) causes initialization of 
>>>>>>> only
>>>>>>> the class or interface that actually declares it, even though it 
>>>>>>> might
>>>>>>> be referred to through the name of a subclass, a subinterface, or a
>>>>>>> class that implements an interface.
>>>>>>> Invocation of certain reflective methods in class Class and in 
>>>>>>> package
>>>>>>> java.lang.reflect also causes class or interface initialization.
>>>>>>> A class or interface will not be initialized under any other
>>>>>>> circumstance.
>>>>>>> ---------------------------------------------------------
>>>>>>> With the code snippet we see that calling
>>>>>>> Class.forName(ObjectReturner.class.getName()) succeeds and
>>>>>>> Class.forName(BaseClassReturner.class.getName()) fails even though
>>>>>>> both declare returning an instance of ChildClass.
>>>>>>> This failure is unexpected as in the code below we don't fulfill any
>>>>>>> requirement for class loading as of JLS 12.4.1, but the JVM still
>>>>>>> tries to load the class.
>>>>>>>
>>>>>>> I suspect it might be related to class file validation and/or
>>>>>>> security, because when we run the code with -Xlog:class+init 
>>>>>>> there's a
>>>>>>> reference to LinkageError in loading log:
>>>>>>>
>>>>>>> loading: org.example.TestLoading$BaseClassReturner...
>>>>>>> [0.277s][info][class,init] Start class verification for:
>>>>>>> org.example.TestLoading$BaseClassReturner
>>>>>>> [0.277s][info][class,init] 771 Initializing
>>>>>>> 'java/lang/ReflectiveOperationException'(no method) 
>>>>>>> (0x0000000800004028)
>>>>>>> [0.277s][info][class,init] 772 Initializing
>>>>>>> 'java/lang/ClassNotFoundException'(no method) (0x0000000800004288)
>>>>>>> [0.277s][info][class,init] 773 Initializing
>>>>>>> 'java/lang/LinkageError'(no method)
>>>>>>> (0x00000008000044f8)????????????????????????????????? <----
>>>>>>> [0.277s][info][class,init] 774 Initializing
>>>>>>> 'java/lang/NoClassDefFoundError'(no method) (0x0000000800004758)
>>>>>>> [0.277s][info][class,init] Verification for
>>>>>>> org.example.TestLoading$BaseClassReturner has exception pending
>>>>>>> 'java.lang.NoClassDefFoundError org/example/TestLoading$ChildClass'
>>>>>>> [0.277s][info][class,init] End class verification for:
>>>>>>> org.example.TestLoading$BaseClassReturner
>>>>>>>
>>>>>>>
>>>>>>> So I've got three questions about this:
>>>>>>> - Does class loading depend on method's return type?
>>>>>>> - Which part of JLS/JVM spec describes eager class loading in 
>>>>>>> this case?
>>>>>>> - Could one point out the particular piece of the VM code 
>>>>>>> responsible
>>>>>>> for class loading in this case?
>>>>>>>
>>>>>>> Regards,
>>>>>>> Sergey Tsypanov
>>>>>>>
>>>>>>> Code snippet for reproduction:
>>>>>>>
>>>>>>> public class TestLoading {
>>>>>>>
>>>>>>> ??? public static void main(String[] args) throws Exception {
>>>>>>> ????? Class.forName(BaseClass.class.getName());
>>>>>>> ????? URL classFileB =
>>>>>>> TestLoading.class.getResource(TestLoading.class.getSimpleName() +
>>>>>>> "$ChildClass.class");
>>>>>>> ????? if (classFileB != null) {
>>>>>>> ??????? if (!"file".equals(classFileB.getProtocol())) {
>>>>>>> ????????? throw new UnsupportedOperationException();
>>>>>>> ??????? }
>>>>>>> ??????? Path path = new File(classFileB.getPath()).toPath();
>>>>>>> ??????? System.out.println("deleting: " + path);
>>>>>>> ??????? Files.delete(path);
>>>>>>> ????? }
>>>>>>>
>>>>>>> ????? loadMyClass(ObjectReturner.class.getName());
>>>>>>> ????? loadMyClass(BaseClassReturner.class.getName());
>>>>>>> ??? }
>>>>>>>
>>>>>>> ??? private static void loadMyClass(String name) {
>>>>>>> ????? System.out.println("loading: " + name + "...");
>>>>>>> ????? try {
>>>>>>> ??????? Class.forName(name);
>>>>>>> ????? } catch (Throwable e) {
>>>>>>> ??????? e.printStackTrace(System.out);
>>>>>>> ????? }
>>>>>>> ??? }
>>>>>>>
>>>>>>> ??? public static class BaseClass {
>>>>>>> ??? }
>>>>>>>
>>>>>>> ??? public static class ChildClass extends BaseClass {
>>>>>>> ??? }
>>>>>>>
>>>>>>> ??? public static class ObjectReturner {
>>>>>>> ????? public Object getObject() {
>>>>>>> ??????? return new ChildClass();
>>>>>>> ????? }
>>>>>>> ??? }
>>>>>>>
>>>>>>> ??? public static class BaseClassReturner {
>>>>>>> ????? public BaseClass getObject() {
>>>>>>> ??????? return new ChildClass();
>>>>>>> ????? }
>>>>>>> ??? }
>>>>>>> }

From forax at openjdk.org  Fri May 26 06:23:05 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 26 May 2023 06:23:05 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v20]
In-Reply-To: <lVuFaWAEYdySBVKt4XQF0DXjKInm34bGG1we2V-SGN0=.e9d4546f-8d62-4a61-a179-7245684c2f9e@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <DBQsWeRpbETtO0mMAZyfS46Z70Z5fuAEntDOR-k6oXs=.38100514-3edf-48df-abf3-a97b293fa89e@github.com>
 <lVuFaWAEYdySBVKt4XQF0DXjKInm34bGG1we2V-SGN0=.e9d4546f-8d62-4a61-a179-7245684c2f9e@github.com>
Message-ID: <7txzmoyjMl_VmeZW96En2DsyU50tTb4Vf9ls9cPTcUQ=.76a7f314-5ca8-4d27-b1a3-2541ca60bd73@github.com>

On Fri, 26 May 2023 06:07:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improving error recovery in presence of less important syntactic errors in top-level methods and fields.
>>   
>>   Author: Jan Lahoda <jlahoda at openjdk.org>
>
> test/jdk/tools/launcher/InstanceMainTest.java line 31:
> 
>> 29:  * @run main InstanceMainTest
>> 30:  */
>> 31: public class InstanceMainTest extends TestHelper {
> 
> By my reading of the spec, "main" methods can be defined in record classes and enum classes as well as normal classes.
> Are there tests for record and enum main method operation?

You can also have a `main` method inside an interface. For enum classes and interfaces, the main has to be static.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1206285923

From duke at openjdk.org  Fri May 26 06:49:56 2023
From: duke at openjdk.org (Hannes Greule)
Date: Fri, 26 May 2023 06:49:56 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access
In-Reply-To: <nLbp1mGK9qZaUwM8WMCmPDQe-QakWokmFvwMk1S7qUU=.780a0535-a8be-4309-8f93-8f2ed8eb6456@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <nLbp1mGK9qZaUwM8WMCmPDQe-QakWokmFvwMk1S7qUU=.780a0535-a8be-4309-8f93-8f2ed8eb6456@github.com>
Message-ID: <VLSyzPEdPTk6AtGJkAV_761pY-QL4EsgYRWEP137CkY=.7d960983-1071-4cac-abd5-bb252351686c@github.com>

On Thu, 25 May 2023 23:54:14 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
>> 
>> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
>> 
>> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
>> 
>> 
>> Benchmark               Mode  Cnt  Score   Error   Units
>> 
>> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
>> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
>> 
>> # After
>> UUIDRandomBench.single  thrpt   15  4.421 ? 0.047  ops/us 
>> UUIDRandomBench.max     thrpt   15  6.658 ? 0.092  ops/us ; positive scaling, ~1.5x
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
>> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
>> 
>> # After
>> Benchmark                Mode  Cnt  Score   Error   Units
>> UUIDRandomBench.single  thrpt   15  3.099 ? 0.022  ops/us
>> UUIDRandomBench.max     thrpt   15  3.555 ? 0.062  ops/us  ; positive scaling, ~1.2x
>> 
>> 
>> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
>> 
>> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
>> 
>> 
>> Benchmark               Mode  Cnt   Score   Error   Units
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
>> UUIDRandomBench.single  thrpt  ...
>
> src/java.base/share/classes/java/util/UUID.java line 286:
> 
>> 284:         long lsb = 0;
>> 285:         for (int i = start; i < start + 8; i++) {
>> 286:             msb = (msb << 8) | (data[i] & 0xff);
> 
> Can we use VarHandle/ByteBuffer to read 64 bits at a time?

`jdk.internal.util.ByteArray` has VarHandle-based methods ready for that

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206305263

From mbaesken at openjdk.org  Fri May 26 07:14:55 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 May 2023 07:14:55 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code
In-Reply-To: <JO--b-rYU9GkmwjXkZx90gkLnIiXagV2ojnUP6AiKws=.37b5f972-205f-4409-8f8a-1b4da3c9c24f@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <Z6J__T8X9bDvrfFjUxNImPMEUwKQmbESvmzYUeDolkQ=.9309297e-ab60-4cd5-9a20-687d545101a8@github.com>
 <JO--b-rYU9GkmwjXkZx90gkLnIiXagV2ojnUP6AiKws=.37b5f972-205f-4409-8f8a-1b4da3c9c24f@github.com>
Message-ID: <e7gJRQpy8wi-L6tyNjxZIHsZVdLgsfv0Q9CFX0mS3Lg=.ca827f09-eaa6-495f-aeef-685c66705e99@github.com>

On Thu, 25 May 2023 16:13:49 GMT, JoKern65 <duke at openjdk.org> wrote:

>> test/jdk/java/io/File/libGetXSpace.c line 128:
>> 
>>> 126: #else
>>> 127:     struct statfs buf;
>>> 128:     int result = statfs((char*)chars, &buf);
>> 
>> Is this working around a bug in IBM's declaration?
>> 
>> Also, pre-existing, the cast seems really suspicious.  The type of `chars` is `jchar*`, which is a
>> sequence of 16bit characters.  Does this actually work?  If so, how?
>
> This is IBMs declaration of statfs
> `extern int statfs(char *, struct statfs *);`
> So the compiler will not accept a `const char*`
> Indeed I do not know if this ever worked, but my change makes it not worse.

Here is the documentation of statfs on AIX  https://www.ibm.com/docs/en/aix/7.2?topic=s-statfs-fstatfs-statfs64-fstatfs64-ustat-subroutine  (showing the IBM declaration Joachim told us) .

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1206326207

From djelinski at openjdk.org  Fri May 26 07:50:56 2023
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 26 May 2023 07:50:56 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <VpEl4v3oeJJGf7hCma44tp9IG-d6T1jyRjemqZN8Kfg=.8338f76a-37e5-4524-9cfe-83b2a774b3bc@github.com>

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

According to our docs, [clang is a supported compiler for Linux](https://github.com/openjdk/jdk/blob/master/doc/building.md#native-compiler-toolchain-requirements).

Here's an example how warning exclusion is implemented today:
https://github.com/openjdk/jdk/blob/master/make/modules/java.desktop/lib/Awt2dLibraries.gmk#L827

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1563956337

From asotona at openjdk.org  Fri May 26 07:51:28 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 26 May 2023 07:51:28 GMT
Subject: RFR: 8308842: Consolidate exceptions thrown from Class-File API
 [v2]
In-Reply-To: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
References: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
Message-ID: <FcYf5BoLaG8Ezc5aU2ax31TwTi-3HaFdBqTuNgWRT8o=.fb702cbc-009e-4497-8673-b99a37570278@github.com>

> Class-File API actually throws wide variety of exceptions based on the actual situation. Complete error handling code must cover `IndexOutOfBoundsException`, `IllegalStateException` and `IllegalArgumentException`. 
> 
> Based on previous discussions we decided to consolidate on `IllegalArgumentException` with possible sub-classes. 
> 
> It allows easy common error handling in majority of use case, however it allows also to distinguish source of the error when needed (for example `javap` needs to know if the exception comes from constant poll or not). 
> 
> Newly introduced `ConstantPoolException` extends `IllegalArgumentException` to indicate the source of the problem is in constant pool. 
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14143/files
  - new: https://git.openjdk.org/jdk/pull/14143/files/d2ec1c99..8bc444df

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14143&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14143&range=00-01

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14143.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14143/head:pull/14143

PR: https://git.openjdk.org/jdk/pull/14143

From mbaesken at openjdk.org  Fri May 26 07:55:56 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 May 2023 07:55:56 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code
In-Reply-To: <e7gJRQpy8wi-L6tyNjxZIHsZVdLgsfv0Q9CFX0mS3Lg=.ca827f09-eaa6-495f-aeef-685c66705e99@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <Z6J__T8X9bDvrfFjUxNImPMEUwKQmbESvmzYUeDolkQ=.9309297e-ab60-4cd5-9a20-687d545101a8@github.com>
 <JO--b-rYU9GkmwjXkZx90gkLnIiXagV2ojnUP6AiKws=.37b5f972-205f-4409-8f8a-1b4da3c9c24f@github.com>
 <e7gJRQpy8wi-L6tyNjxZIHsZVdLgsfv0Q9CFX0mS3Lg=.ca827f09-eaa6-495f-aeef-685c66705e99@github.com>
Message-ID: <cg_QwIlU_HyL8d2aDcCEhMBJU-jsw0h1e62j9zpRq1Q=.586bae61-2808-4c15-b1ea-4661b163878c@github.com>

On Fri, 26 May 2023 07:12:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> This is IBMs declaration of statfs
>> `extern int statfs(char *, struct statfs *);`
>> So the compiler will not accept a `const char*`
>> Indeed I do not know if this ever worked, but my change makes it not worse.
>
> Here is the documentation of statfs on AIX  https://www.ibm.com/docs/en/aix/7.2?topic=s-statfs-fstatfs-statfs64-fstatfs64-ustat-subroutine  (showing the IBM declaration Joachim told us) .

> Also, pre-existing, the cast seems really suspicious. The type of `chars` is `jchar*`, which is a sequence of 16bit characters. Does this actually work? If so, how?

Probably a jchar to char conversion would be needed for the array elements,  maybe like this here (or is there a better utility function in the codebase) ? See  jCharArrayToCKCharArray
https://github.com/openjdk/jdk/blob/199b1bf5009120efd1fd37a1ddabc0c6fb84f62c/src/jdk.crypto.cryptoki/share/native/libj2pkcs11/p11_util.c#L644

I am not aware of an AIX statfs for wchars but maybe I miss something.  But it is a separate issue of Java_GetXSpace_getSpace0  anyway and should be handled in another bug.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1206370114

From duke at openjdk.org  Fri May 26 08:31:46 2023
From: duke at openjdk.org (JoKern65)
Date: Fri, 26 May 2023 08:31:46 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
Message-ID: <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>

> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
> Some of those are in shared codebase and could be addressed by small adjustments.
> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.

JoKern65 has updated the pull request incrementally with one additional commit since the last revision:

  forgotton _

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14146/files
  - new: https://git.openjdk.org/jdk/pull/14146/files/2699fdce..da38fb2d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14146&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14146&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14146.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14146/head:pull/14146

PR: https://git.openjdk.org/jdk/pull/14146

From shade at openjdk.org  Fri May 26 08:42:57 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 08:42:57 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access
In-Reply-To: <nLbp1mGK9qZaUwM8WMCmPDQe-QakWokmFvwMk1S7qUU=.780a0535-a8be-4309-8f93-8f2ed8eb6456@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <nLbp1mGK9qZaUwM8WMCmPDQe-QakWokmFvwMk1S7qUU=.780a0535-a8be-4309-8f93-8f2ed8eb6456@github.com>
Message-ID: <JmT8CGbbHfwlEgnLnrkv7qs-F5OtE5AmQmzfC9YjHcY=.c16c0654-06ff-46ca-9369-687f40935bd3@github.com>

On Fri, 26 May 2023 00:13:57 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
>> 
>> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
>> 
>> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
>> 
>> 
>> Benchmark               Mode  Cnt  Score   Error   Units
>> 
>> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
>> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
>> 
>> # After
>> UUIDRandomBench.single  thrpt   15  4.421 ? 0.047  ops/us 
>> UUIDRandomBench.max     thrpt   15  6.658 ? 0.092  ops/us ; positive scaling, ~1.5x
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
>> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
>> 
>> # After
>> Benchmark                Mode  Cnt  Score   Error   Units
>> UUIDRandomBench.single  thrpt   15  3.099 ? 0.022  ops/us
>> UUIDRandomBench.max     thrpt   15  3.555 ? 0.062  ops/us  ; positive scaling, ~1.2x
>> 
>> 
>> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
>> 
>> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
>> 
>> 
>> Benchmark               Mode  Cnt   Score   Error   Units
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
>> UUIDRandomBench.single  thrpt  ...
>
> src/java.base/share/classes/java/util/UUID.java line 224:
> 
>> 222:                     // Try to pull the UUID from the current buffer at current position.
>> 223:                     if (stamp != 0) {
>> 224:                         int p = (int)VH_POS.getAndAdd(this, UUID_CHUNK);
> 
> An atomic update together with an optimistic lock looks non-idiomatic use of StampedLock to me. Won't a simple CAS loop be simpler? E.g. in pseudocode:
> 
> while ((p = this.pos) + 16) < buf.length) {
>     long msb = getLong(buf, p);
>     long lsb = getLong(buf, p + 8);
>     if (cas(this.pos, p, p + 16)) {
>         return new UUID(msb, lsb);
>     }
> }
> 
> // refill buffer under lock

Nope, I don't think you cannot do this, because there is a race on concurrently-updating `buf`. The StampedLock (RW lock), protects the buffer-reading threads from seeing the `buf` undergoing the initialization by buffer-writing threads. Atomic pos only arbitrates the concurrent buffer-threads. That atomic does not help to resolve the buf races.

> src/java.base/share/classes/java/util/UUID.java line 260:
> 
>> 258:                         buf[c + 8] &= 0x3f;  /* clear variant        */
>> 259:                         buf[c + 8] |= (byte) 0x80;  /* set to IETF variant  */
>> 260:                     }
> 
> I'm not sure I understand the point about initialization. Why not just setting the required version bits right in UUID constructor without updating the array? This will be faster and simpler IMO.

Right, we can do things straight on locals, without ever touching the heap, let's see...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206430447
PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206433588

From shade at openjdk.org  Fri May 26 08:43:00 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 08:43:00 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access
In-Reply-To: <BvoKDJ_TxeJP4EPvpHaP_V3hI6HzmnpuYrlIMM5qEO0=.c7421cc9-8579-4549-82ab-8d82919161f4@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <BvoKDJ_TxeJP4EPvpHaP_V3hI6HzmnpuYrlIMM5qEO0=.c7421cc9-8579-4549-82ab-8d82919161f4@github.com>
Message-ID: <cTnCk50G8-IeSbOuZonVbin5QbVywa2Ml4zw3ZDd-nQ=.c5b1715f-05eb-48ef-a9ac-3d628f2af02e@github.com>

On Fri, 26 May 2023 00:50:04 GMT, Brett Okken <duke at openjdk.org> wrote:

>> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
>> 
>> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
>> 
>> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
>> 
>> 
>> Benchmark               Mode  Cnt  Score   Error   Units
>> 
>> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
>> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
>> 
>> # After
>> UUIDRandomBench.single  thrpt   15  4.421 ? 0.047  ops/us 
>> UUIDRandomBench.max     thrpt   15  6.658 ? 0.092  ops/us ; positive scaling, ~1.5x
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
>> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
>> 
>> # After
>> Benchmark                Mode  Cnt  Score   Error   Units
>> UUIDRandomBench.single  thrpt   15  3.099 ? 0.022  ops/us
>> UUIDRandomBench.max     thrpt   15  3.555 ? 0.062  ops/us  ; positive scaling, ~1.2x
>> 
>> 
>> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
>> 
>> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
>> 
>> 
>> Benchmark               Mode  Cnt   Score   Error   Units
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
>> UUIDRandomBench.single  thrpt  ...
>
> src/java.base/share/classes/java/util/UUID.java line 255:
> 
>> 253:                     // initializations, and thus false sharing between reader threads.
>> 254:                     random.nextBytes(buf);
>> 255:                     for (int c = 0; c < BUF_SIZE; c += UUID_CHUNK) {
> 
> I think this could be faster by using a ByteBuffer (or VarHandle) to process as longs.
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2023-March/101249.html

Yup, but that would probably fold into discussion here: https://github.com/openjdk/jdk/pull/14135#discussion_r1206097261

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206434408

From shade at openjdk.org  Fri May 26 08:43:02 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 08:43:02 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access
In-Reply-To: <VLSyzPEdPTk6AtGJkAV_761pY-QL4EsgYRWEP137CkY=.7d960983-1071-4cac-abd5-bb252351686c@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <nLbp1mGK9qZaUwM8WMCmPDQe-QakWokmFvwMk1S7qUU=.780a0535-a8be-4309-8f93-8f2ed8eb6456@github.com>
 <VLSyzPEdPTk6AtGJkAV_761pY-QL4EsgYRWEP137CkY=.7d960983-1071-4cac-abd5-bb252351686c@github.com>
Message-ID: <gYLLVVuTpRp73awOdXSXVlY8xbYASxzlEs4sWsbj084=.1eb25989-64de-487a-855f-72ebcea08c1b@github.com>

On Fri, 26 May 2023 06:47:29 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/UUID.java line 286:
>> 
>>> 284:         long lsb = 0;
>>> 285:         for (int i = start; i < start + 8; i++) {
>>> 286:             msb = (msb << 8) | (data[i] & 0xff);
>> 
>> Can we use VarHandle/ByteBuffer to read 64 bits at a time?
>
> `jdk.internal.util.ByteArray` has VarHandle-based methods ready for that

Yes, I have that optimization in the pipeline, and wanted to do so separately. I can still fold it here, let me see.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206431718

From duke at openjdk.org  Fri May 26 08:48:55 2023
From: duke at openjdk.org (Nagata-Haruhito)
Date: Fri, 26 May 2023 08:48:55 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v7]
In-Reply-To: <hw_GfSecKgwyXkMjKCqk8Cbpa-0_4wZe8M6aHrQVzIQ=.acf75a82-db86-4422-9d73-48efe2ad16b4@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <hw_GfSecKgwyXkMjKCqk8Cbpa-0_4wZe8M6aHrQVzIQ=.acf75a82-db86-4422-9d73-48efe2ad16b4@github.com>
Message-ID: <8hwJYhcT5DQJpsC0Zzlj_kcWqpw9b8yBcVXMLVJurqA=.593e7ec9-f221-4c09-803a-a2de35bfcdb3@github.com>

On Mon, 22 May 2023 07:27:00 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

>> I fixed File.listRoots description.
>> * remove "the insertion or ejection of removable media"
>> * change "available" to "existing"
>> 
>> Please review this change.
>
> Nagata-Haruhito has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move SecurityException paragraph

Would you please review this PR ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13526#issuecomment-1564029175

From asotona at openjdk.org  Fri May 26 09:23:56 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 26 May 2023 09:23:56 GMT
Subject: RFR: 8308842: Consolidate exceptions thrown from Class-File API
 [v2]
In-Reply-To: <AGo3TiQkl5iXTFNSKMo4gYY7spZiQxSIl5PxI1wwv8g=.dd93829c-a41b-4690-8dad-3184aa7d1a98@github.com>
References: <IK7tkcyqY1vSs1ta1lQannGyVUG084w36mVh9jhfO6I=.84bd6be7-eedf-46f2-a262-5535fe41699e@github.com>
 <AGo3TiQkl5iXTFNSKMo4gYY7spZiQxSIl5PxI1wwv8g=.dd93829c-a41b-4690-8dad-3184aa7d1a98@github.com>
Message-ID: <64osUnNM-J2bS52c-x_3T7iVV1xdVNuwF-iDUAj8wvc=.d87e2dbe-b257-4f6b-b65b-ecb262e3b18f@github.com>

On Thu, 25 May 2023 22:45:01 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fixed javadoc
>
> src/java.base/share/classes/jdk/internal/classfile/CodeBuilder.java line 389:
> 
>> 387:         // Check for empty try block
>> 388:         if (tryBlock.isEmpty()) {
>> 389:             throw new IllegalArgumentException("The body of the try block is empty");
> 
> This?exception should?be?documented in?the?method?s?**Javadoc**.

Fixed, thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14143#discussion_r1206483576

From shade at openjdk.org  Fri May 26 09:37:57 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 09:37:57 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access
In-Reply-To: <nLbp1mGK9qZaUwM8WMCmPDQe-QakWokmFvwMk1S7qUU=.780a0535-a8be-4309-8f93-8f2ed8eb6456@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <nLbp1mGK9qZaUwM8WMCmPDQe-QakWokmFvwMk1S7qUU=.780a0535-a8be-4309-8f93-8f2ed8eb6456@github.com>
Message-ID: <9QZfG0qAOr39JKYgZTbbQEzCv140BfY633vQiw8Arl8=.41f65a21-e138-44d4-b716-556b062895ce@github.com>

On Fri, 26 May 2023 00:16:19 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
>> 
>> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
>> 
>> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
>> 
>> 
>> Benchmark               Mode  Cnt  Score   Error   Units
>> 
>> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
>> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
>> 
>> # After
>> UUIDRandomBench.single  thrpt   15  4.421 ? 0.047  ops/us 
>> UUIDRandomBench.max     thrpt   15  6.658 ? 0.092  ops/us ; positive scaling, ~1.5x
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
>> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
>> 
>> # After
>> Benchmark                Mode  Cnt  Score   Error   Units
>> UUIDRandomBench.single  thrpt   15  3.099 ? 0.022  ops/us
>> UUIDRandomBench.max     thrpt   15  3.555 ? 0.062  ops/us  ; positive scaling, ~1.2x
>> 
>> 
>> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
>> 
>> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
>> 
>> 
>> Benchmark               Mode  Cnt   Score   Error   Units
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
>> UUIDRandomBench.single  thrpt  ...
>
> src/java.base/share/classes/java/util/UUID.java line 226:
> 
>> 224:                         int p = (int)VH_POS.getAndAdd(this, UUID_CHUNK);
>> 225:                         if (p < BUF_SIZE) {
>> 226:                             uuid = new UUID(buf, p);
> 
> We can read msb/lsb from the buffer here and move object allocation outside the lock to reduce the length of the critical section.

Yes, I am doing this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206496030

From shade at openjdk.org  Fri May 26 09:38:01 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 09:38:01 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access
In-Reply-To: <JmT8CGbbHfwlEgnLnrkv7qs-F5OtE5AmQmzfC9YjHcY=.c16c0654-06ff-46ca-9369-687f40935bd3@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <nLbp1mGK9qZaUwM8WMCmPDQe-QakWokmFvwMk1S7qUU=.780a0535-a8be-4309-8f93-8f2ed8eb6456@github.com>
 <JmT8CGbbHfwlEgnLnrkv7qs-F5OtE5AmQmzfC9YjHcY=.c16c0654-06ff-46ca-9369-687f40935bd3@github.com>
Message-ID: <XPEx95RJ1-o4EezSdj2Prrq15LNZ8wYRGXoPCkzCKGI=.4dea78ce-f226-43b5-9d74-eab2363b145c@github.com>

On Fri, 26 May 2023 08:39:10 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/UUID.java line 260:
>> 
>>> 258:                         buf[c + 8] &= 0x3f;  /* clear variant        */
>>> 259:                         buf[c + 8] |= (byte) 0x80;  /* set to IETF variant  */
>>> 260:                     }
>> 
>> I'm not sure I understand the point about initialization. Why not just setting the required version bits right in UUID constructor without updating the array? This will be faster and simpler IMO.
>
> Right, we can do things straight on locals, without ever touching the heap, let's see...

Yup, that works beautifully.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206499212

From shade at openjdk.org  Fri May 26 09:51:47 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 09:51:47 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v2]
In-Reply-To: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
Message-ID: <pPQo9gZKBxsK3BKEtYKTZGOXkHV0UDTaB--uAR8uVEQ=.c97a176e-a963-4cfa-8ab7-8bd59949017b@github.com>

> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
> 
> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
> 
> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
> 
> 
> Benchmark               Mode  Cnt  Score   Error   Units
> 
> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
> 
> # After
> UUIDRandomBench.single  thrpt   15  4.421 ? 0.047  ops/us 
> UUIDRandomBench.max     thrpt   15  6.658 ? 0.092  ops/us ; positive scaling, ~1.5x
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
> 
> # After
> Benchmark                Mode  Cnt  Score   Error   Units
> UUIDRandomBench.single  thrpt   15  3.099 ? 0.022  ops/us
> UUIDRandomBench.max     thrpt   15  3.555 ? 0.062  ops/us  ; positive scaling, ~1.2x
> 
> 
> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
> 
> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
> 
> 
> Benchmark               Mode  Cnt   Score   Error   Units
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
> UUIDRandomBench.single  thrpt   15  3.661 ? 0.008  ops/us
> UUIDRandomBench...

Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:

 - Handle privileged properties
 - Use ByteArray to convert. Do version/variant preparations straight on locals. Move init out of optimistic lock section.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14135/files
  - new: https://git.openjdk.org/jdk/pull/14135/files/51dc2903..be38dffe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14135&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14135&range=00-01

  Stats: 211 lines in 2 files changed: 103 ins; 21 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/14135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14135/head:pull/14135

PR: https://git.openjdk.org/jdk/pull/14135

From shade at openjdk.org  Fri May 26 09:51:51 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 09:51:51 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v2]
In-Reply-To: <gYLLVVuTpRp73awOdXSXVlY8xbYASxzlEs4sWsbj084=.1eb25989-64de-487a-855f-72ebcea08c1b@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <nLbp1mGK9qZaUwM8WMCmPDQe-QakWokmFvwMk1S7qUU=.780a0535-a8be-4309-8f93-8f2ed8eb6456@github.com>
 <VLSyzPEdPTk6AtGJkAV_761pY-QL4EsgYRWEP137CkY=.7d960983-1071-4cac-abd5-bb252351686c@github.com>
 <gYLLVVuTpRp73awOdXSXVlY8xbYASxzlEs4sWsbj084=.1eb25989-64de-487a-855f-72ebcea08c1b@github.com>
Message-ID: <2jyuw1hm5Dk7P1wxitjANaxQRCtGYbpFiHctXZlX6zY=.9e23194a-17d6-4415-bacc-076fd405166f@github.com>

On Fri, 26 May 2023 08:37:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> `jdk.internal.util.ByteArray` has VarHandle-based methods ready for that
>
> Yes, I have that optimization in the pipeline, and wanted to do so separately. I can still fold it here, let me see.

Did so in new commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206511880

From shade at openjdk.org  Fri May 26 09:51:49 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 09:51:49 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v2]
In-Reply-To: <WrtGGw8ClImuXdBKJsDkmPL2tFDus66iJLc-Vn2I8iM=.e1d0dd74-7e28-4379-b5a7-38892d780d6b@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <WrtGGw8ClImuXdBKJsDkmPL2tFDus66iJLc-Vn2I8iM=.e1d0dd74-7e28-4379-b5a7-38892d780d6b@github.com>
Message-ID: <oEKxjDauGaWeuTlk5DiUDxm2Dpx5EDkuxzqKv4lnZOo=.fd5da7fa-8e47-4ef7-bf18-3316e0cd8fe6@github.com>

On Thu, 25 May 2023 12:17:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Handle privileged properties
>>  - Use ByteArray to convert. Do version/variant preparations straight on locals. Move init out of optimistic lock section.
>
> src/java.base/share/classes/java/util/UUID.java line 127:
> 
>> 125:         static {
>> 126:             try {
>> 127:                 PRNG_NAME = System.getProperty(PROP_NAME_PRNG_NAME, null);
> 
> You'll have to use GetPropertyAction.privilegedGetProperty as this will otherwise fail if someone runs with a SM.

Good spot. Should be fixed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206512318

From shade at openjdk.org  Fri May 26 10:08:56 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 10:08:56 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java
In-Reply-To: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
Message-ID: <LzGfH4k4mnbbrKhUQts4kEK_VC0jUxRAXA5BQbZUKEs=.3b9be127-bda5-42dd-94cf-afce2ac8da94@github.com>

On Wed, 24 May 2023 19:18:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> UUID is very important class that is used to track identities of objects in large scale systems. Yet, the coverage in JDK test is disappointing: it tests only 100 of UUID instances per test, which is way too small to detect collisions due to the bad randomness for example.
> 
> I have some pending work to improve UUID performance, and tests should be improved. 
> 
> The improved test still runs in less than 5 seconds on my laptop.

Any takers? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14134#issuecomment-1564143336

From duke at openjdk.org  Fri May 26 10:12:55 2023
From: duke at openjdk.org (JoKern65)
Date: Fri, 26 May 2023 10:12:55 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
Message-ID: <zZ1cSQWfV4hTDarhkjAJHwtpT4R7CvE1v5apuNH00hw=.723a62a6-37ef-41a3-981a-99ba50e0143c@github.com>

On Fri, 26 May 2023 08:31:46 GMT, JoKern65 <duke at openjdk.org> wrote:

>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small adjustments.
>> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.
>
> JoKern65 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forgotton _

Here are the reasons for the disabled warnings in make/modules/java.base/Lib.gmk
   DISABLED_WARNINGS_clang_aix_DefaultProxySelector.c := deprecated-non-prototype, \
    DISABLED_WARNINGS_clang_aix_NetworkInterface.c := gnu-pointer-arith, \
    DISABLED_WARNINGS_clang_aix_UnixNativeDispatcher.c := undef, \

src/java.base/unix/native/libnet/DefaultProxySelector.c:378:41:22: error: passing arguments to a function without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
    proxies = (*g_proxy_resolver_lookup)(resolver, uri, NULL, &error);
                                                             ^

src/java.base/unix/native/libnet/NetworkInterface.c:1612:24: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
    end = (void *)nddp + size;
     ~~~~~~~~~~~~ ^

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef]
#elif _ALLBSD_SOURCE
      ^

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564143664

From duke at openjdk.org  Fri May 26 10:20:58 2023
From: duke at openjdk.org (JoKern65)
Date: Fri, 26 May 2023 10:20:58 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
Message-ID: <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com>

On Fri, 26 May 2023 08:31:46 GMT, JoKern65 <duke at openjdk.org> wrote:

>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small adjustments.
>> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.
>
> JoKern65 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forgotton _

Here are the reasons for the disabled warnings in make/modules/java.base/lib/CoreLibraries.gmk
  DISABLED_WARNINGS_clang_aix_ProcessHandleImpl_unix.c := sign-compare, \
  DISABLED_WARNINGS_clang_aix := gnu-pointer-arith, \
  DISABLED_WARNINGS_clang := gnu-pointer-arith format-nonliteral deprecated-non-prototype, \

src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long'
if (ret < sizeof(psinfo_t)) {
         ^

src/java.base/aix/native/libjli/java_md_aix.c:42:38: error: arithmetic on a pointer to void is a GNU extension [-Werror,-Wgnu-pointer-arith]
            addr < p->ldinfo_textorg + p->ldinfo_textsize) {
                   ~~~~~~~~~~~~~~~~~ ^

src/java.base/share/native/libzip/zlib/inffast.c:74:20: error: a function definition without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
void ZLIB_INTERNAL inflate_fast(strm, start)
                   ^
src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
    vfprintf(stderr, fmt, vl);
                            ^~~

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564165195

From mbaesken at openjdk.org  Fri May 26 10:24:55 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 May 2023 10:24:55 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <zZ1cSQWfV4hTDarhkjAJHwtpT4R7CvE1v5apuNH00hw=.723a62a6-37ef-41a3-981a-99ba50e0143c@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
 <zZ1cSQWfV4hTDarhkjAJHwtpT4R7CvE1v5apuNH00hw=.723a62a6-37ef-41a3-981a-99ba50e0143c@github.com>
Message-ID: <JZJgZHyqi7_AyBEsVFFXIis93RQPKP_0HS3XMXmuKz0=.f2a6d447-aced-46d5-9d9e-8e833382f38b@github.com>

On Fri, 26 May 2023 10:05:56 GMT, JoKern65 <duke at openjdk.org> wrote:

> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c:1251:7: error: '_ALLBSD_SOURCE' is not defined, evaluates to 0 [-Werror,-Wundef]
> #elif _ALLBSD_SOURCE
> 

Should probably better be
`#elif defined(_ALLBSD_SOURCE)`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564168769

From mbaesken at openjdk.org  Fri May 26 10:47:55 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 May 2023 10:47:55 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
 <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com>
Message-ID: <mUbChDpVlA7SrAM6AdHlt9gwkiziksv2JyR-TkqDdrM=.a3c7b2bf-d12c-4c0d-8752-da11e706ed84@github.com>

On Fri, 26 May 2023 10:18:37 GMT, JoKern65 <duke at openjdk.org> wrote:

> src/java.base/share/native/libjli/java.c:2311:22: error: format string is not a string literal [-Werror,-Wformat-nonliteral] vfprintf(stderr, fmt, vl); ^~~

We disable this warning too for clang on all platforms in BUILD_LIBJLI ( DISABLED_WARNINGS_clang := **format-nonlitera**l deprecated-non-prototype, \ ), so I think we should do it the same way for BUILD_LIBJLI_STATIC on AIX.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564193886

From mbaesken at openjdk.org  Fri May 26 10:55:02 2023
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 26 May 2023 10:55:02 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
 <1HhxMPs2-ZAR3zcdR6EhFDCJAYnMfVKxh3pmDh2vQlQ=.a836c68b-6098-436c-b34e-3fb35f9c2d36@github.com>
Message-ID: <S64gFjkWKOFyiRs58ymX4WXSgfns172WH838KqNkJWs=.9ebc1c97-7b15-4f1a-83af-cb4fcd29db2e@github.com>

On Fri, 26 May 2023 10:18:37 GMT, JoKern65 <duke at openjdk.org> wrote:

> Here are the reasons for the disabled warnings in make/modules/java.base/lib/CoreLibraries.gmk DISABLED_WARNINGS_clang_aix_ProcessHandleImpl_unix.c := sign-compare, DISABLED_WARNINGS_clang_aix := gnu-pointer-arith, DISABLED_WARNINGS_clang := gnu-pointer-arith format-nonliteral deprecated-non-prototype, \
> 
> src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c:638 comparison of integers of different signs: 'int' and 'unsigned long' if (ret < sizeof(psinfo_t)) { ^
> 

`fread` returns a `size_t ` on Linux and AIX, could you please check Mac/BSD too ?
https://github.com/openjdk/jdk/blob/d3b9b364da8c11c9b4dd14a6451a7b24f41202e7/src/java.base/unix/native/libjava/ProcessHandleImpl_unix.c#L636

We should probably change to size_t  ret  (from type int), then the warning would not occur, correct ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564207011

From dfuchs at openjdk.org  Fri May 26 11:28:59 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 26 May 2023 11:28:59 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v2]
In-Reply-To: <pPQo9gZKBxsK3BKEtYKTZGOXkHV0UDTaB--uAR8uVEQ=.c97a176e-a963-4cfa-8ab7-8bd59949017b@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <pPQo9gZKBxsK3BKEtYKTZGOXkHV0UDTaB--uAR8uVEQ=.c97a176e-a963-4cfa-8ab7-8bd59949017b@github.com>
Message-ID: <77sA9HIrYDW4c8GBhN_VziZmB4cblVOTNe-b9mm1nrQ=.dddc611d-fe4c-4fb2-9531-337793ab3802@github.com>

On Fri, 26 May 2023 09:51:47 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
>> 
>> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
>> 
>> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
>> 
>> 
>> Benchmark               Mode  Cnt  Score   Error   Units
>> 
>> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
>> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
>> 
>> # After
>> UUIDRandomBench.single  thrpt   15  4.823 ? 0.023  ops/us 
>> UUIDRandomBench.max     thrpt   15  6.561 ? 0.054  ops/us ; positive scaling, ~1.5x
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
>> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
>> 
>> # After
>> Benchmark                Mode  Cnt  Score   Error   Units
>> UUIDRandomBench.single  thrpt   15  3.109 ? 0.026  ops/us
>> UUIDRandomBench.max     thrpt   15  3.561 ? 0.071  ops/us  ; positive scaling, ~1.2x
>> 
>> 
>> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
>> 
>> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
>> 
>> 
>> Benchmark               Mode  Cnt   Score   Error   Units
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
>> UUIDRandomBench.single  thrpt  ...
>
> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Handle privileged properties
>  - Use ByteArray to convert. Do version/variant preparations straight on locals. Move init out of optimistic lock section.

src/java.base/share/classes/java/util/UUID.java line 144:

> 142:                 BUFS = new Buffer[BUFS_COUNT];
> 143:             } catch (Exception e) {
> 144:                 throw new InternalError(e);

Would it be better to throw `ExceptionInInitializerError` here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206636006

From shade at openjdk.org  Fri May 26 11:43:11 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 11:43:11 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v3]
In-Reply-To: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
Message-ID: <K6mGrn-ipEgXeaEW1UVGKp4KxE-6TRRm3Gts73BWnpc=.daa29af8-029d-4a94-bd30-3130a9d81f72@github.com>

> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
> 
> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
> 
> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
> 
> 
> Benchmark               Mode  Cnt  Score   Error   Units
> 
> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
> 
> # After
> UUIDRandomBench.single  thrpt   15  4.823 ? 0.023  ops/us 
> UUIDRandomBench.max     thrpt   15  6.561 ? 0.054  ops/us ; positive scaling, ~1.5x
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
> 
> # After
> Benchmark                Mode  Cnt  Score   Error   Units
> UUIDRandomBench.single  thrpt   15  3.109 ? 0.026  ops/us
> UUIDRandomBench.max     thrpt   15  3.561 ? 0.071  ops/us  ; positive scaling, ~1.2x
> 
> 
> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
> 
> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
> 
> 
> Benchmark               Mode  Cnt   Score   Error   Units
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
> UUIDRandomBench.single  thrpt   15  3.661 ? 0.008  ops/us
> UUIDRandomBench...

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Fine-tune exceptions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14135/files
  - new: https://git.openjdk.org/jdk/pull/14135/files/be38dffe..deddaa6e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14135&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14135&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14135/head:pull/14135

PR: https://git.openjdk.org/jdk/pull/14135

From shade at openjdk.org  Fri May 26 11:43:15 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 11:43:15 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v2]
In-Reply-To: <77sA9HIrYDW4c8GBhN_VziZmB4cblVOTNe-b9mm1nrQ=.dddc611d-fe4c-4fb2-9531-337793ab3802@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <pPQo9gZKBxsK3BKEtYKTZGOXkHV0UDTaB--uAR8uVEQ=.c97a176e-a963-4cfa-8ab7-8bd59949017b@github.com>
 <77sA9HIrYDW4c8GBhN_VziZmB4cblVOTNe-b9mm1nrQ=.dddc611d-fe4c-4fb2-9531-337793ab3802@github.com>
Message-ID: <p9e2nNjYZXaYrBR5PJoMSCMOsuUFWoSIc85exbalKuA=.bf0f8b47-0134-4e1f-b801-dd2573163824@github.com>

On Fri, 26 May 2023 11:24:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Handle privileged properties
>>  - Use ByteArray to convert. Do version/variant preparations straight on locals. Move init out of optimistic lock section.
>
> src/java.base/share/classes/java/util/UUID.java line 144:
> 
>> 142:                 BUFS = new Buffer[BUFS_COUNT];
>> 143:             } catch (Exception e) {
>> 144:                 throw new InternalError(e);
> 
> Would it be better to throw `ExceptionInInitializerError` here?

Sure, see new commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206653656

From apangin at openjdk.org  Fri May 26 12:11:56 2023
From: apangin at openjdk.org (Andrei Pangin)
Date: Fri, 26 May 2023 12:11:56 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v3]
In-Reply-To: <JmT8CGbbHfwlEgnLnrkv7qs-F5OtE5AmQmzfC9YjHcY=.c16c0654-06ff-46ca-9369-687f40935bd3@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <nLbp1mGK9qZaUwM8WMCmPDQe-QakWokmFvwMk1S7qUU=.780a0535-a8be-4309-8f93-8f2ed8eb6456@github.com>
 <JmT8CGbbHfwlEgnLnrkv7qs-F5OtE5AmQmzfC9YjHcY=.c16c0654-06ff-46ca-9369-687f40935bd3@github.com>
Message-ID: <jl9dRqLxzAz8eXzli0moCcxl9BYp2_L__DCaGAkvIMU=.800429c6-b946-4df3-b80a-97e8a338c234@github.com>

On Fri, 26 May 2023 08:36:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/UUID.java line 224:
>> 
>>> 222:                     // Try to pull the UUID from the current buffer at current position.
>>> 223:                     if (stamp != 0) {
>>> 224:                         int p = (int)VH_POS.getAndAdd(this, UUID_CHUNK);
>> 
>> An atomic update together with an optimistic lock looks non-idiomatic use of StampedLock to me. Won't a simple CAS loop be simpler? E.g. in pseudocode:
>> 
>> while ((p = this.pos) + 16) < buf.length) {
>>     long msb = getLong(buf, p);
>>     long lsb = getLong(buf, p + 8);
>>     if (cas(this.pos, p, p + 16)) {
>>         return new UUID(msb, lsb);
>>     }
>> }
>> 
>> // refill buffer under lock
>
> Nope, I don't think you cannot do this, because there is a race on concurrently-updating `buf`. The StampedLock (RW lock), protects the buffer-reading threads from seeing the `buf` undergoing the initialization by buffer-writing threads. Atomic pos only arbitrates the concurrent buffer-threads. That atomic does not help to resolve the buf races.

Right, my example suffers from the ABA problem. It could be likely solved by adding "generation" bits to the pos, but this will be a bit ugly. OK, let's stick with the StampedLock.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206686499

From apangin at openjdk.org  Fri May 26 12:11:59 2023
From: apangin at openjdk.org (Andrei Pangin)
Date: Fri, 26 May 2023 12:11:59 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v3]
In-Reply-To: <K6mGrn-ipEgXeaEW1UVGKp4KxE-6TRRm3Gts73BWnpc=.daa29af8-029d-4a94-bd30-3130a9d81f72@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <K6mGrn-ipEgXeaEW1UVGKp4KxE-6TRRm3Gts73BWnpc=.daa29af8-029d-4a94-bd30-3130a9d81f72@github.com>
Message-ID: <FIiQ3EHrKct94ItDTIDs7WmLkyaPQo4mG0FFDoLZh4Y=.fa9e34d4-41de-456a-910b-e94b7fcf6e05@github.com>

On Fri, 26 May 2023 11:43:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
>> 
>> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
>> 
>> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
>> 
>> 
>> Benchmark               Mode  Cnt  Score   Error   Units
>> 
>> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
>> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
>> 
>> # After
>> UUIDRandomBench.single  thrpt   15  4.823 ? 0.023  ops/us 
>> UUIDRandomBench.max     thrpt   15  6.561 ? 0.054  ops/us ; positive scaling, ~1.5x
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before
>> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
>> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
>> 
>> # After
>> Benchmark                Mode  Cnt  Score   Error   Units
>> UUIDRandomBench.single  thrpt   15  3.109 ? 0.026  ops/us
>> UUIDRandomBench.max     thrpt   15  3.561 ? 0.071  ops/us  ; positive scaling, ~1.2x
>> 
>> 
>> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
>> 
>> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
>> 
>> 
>> Benchmark               Mode  Cnt   Score   Error   Units
>> 
>> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
>> 
>> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
>> UUIDRandomBench.single  thrpt  ...
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fine-tune exceptions

src/java.base/share/classes/java/util/UUID.java line 226:

> 224:                 // set variant to IETF
> 225:                 msb = (msb & (0x3FFF_FFFF_FFFF_FFFFL)) | 0x8000_0000_0000_0000L;
> 226:                 return new UUID(lsb, msb);

Doesn't `msb` [come first](https://github.com/openjdk/jdk/blob/deddaa6ea61f85e9822982a37dad51ff4310457b/src/java.base/share/classes/java/util/UUID.java#L314)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206680628

From duke at openjdk.org  Fri May 26 12:19:55 2023
From: duke at openjdk.org (JoKern65)
Date: Fri, 26 May 2023 12:19:55 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
Message-ID: <v2Bhu4d0_gjWuZI4CGoqNHP4ozLGPKk0cozYa-2FQc8=.5626c5a7-d10a-4886-b42a-da50a14ea736@github.com>

On Fri, 26 May 2023 08:31:46 GMT, JoKern65 <duke at openjdk.org> wrote:

>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small adjustments.
>> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.
>
> JoKern65 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forgotton _

Here are the reasons for the disabled warnings in make/modules/java.desktop/lib/Awt2dLibraries.gmk

/data/d042520/pr/jdk/src/java.desktop/unix/native/common/awt/awt_GraphicsEnv.h:53:12: error: a function declaration without a prototype is deprecated in all versions of C and is treated as a zero-parameter prototype in C2x, conflicting with a previous declaration [-Werror,-Wdeprecated-non-prototype]
extern int XShmQueryExtension();
           ^
/usr/include/X11/extensions/XShm.h:91:6: note: conflicting prototype is here
Bool XShmQueryExtension(
     ^
solved by adding line (generic, because several source files are involved)
DISABLED_WARNINGS_clang_aix := deprecated-non-prototype, \


src/java.desktop/unix/native/libawt_xawt/xawt/awt_Taskbar.c:158:11: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
    if (m = fp_unity_launcher_entry_get_quicklist(entry)) {
        ~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_awt_Taskbar.c := parentheses, \

src/java.desktop/share/native/common/java2d/opengl/OGLPaints.c:581:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
        snprintf(cycleCode, sizeof(cycleCode), noCycleCode, texCoordCalcCode);
                                               ^~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_OGLPaints.c := format-nonliteral, \

src/java.desktop/share/native/common/java2d/opengl/OGLBufImgOps.c:153:48: error: format string is not a string literal [-Werror,-Wformat-nonliteral]
    snprintf(finalSource, sizeof(finalSource), convolveShaderSource,
                                               ^~~~~~~~~~~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_OGLBufImgOps.c := format-nonliteral, \


src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1095:41: error: '&&' within '||' [-Werror,-Wlogical-op-parentheses]
    if ((synth_state & MOUSE_OVER) != 0 && (synth_state & PRESSED) == 0 ||
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~
src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:1180:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
            if (init_result = (NULL == gtk2_widgets[_GTK_CHECK_MENU_ITEM_TYPE]))
                ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_gtk2_interface.c := parentheses logical-op-parentheses, \

src/java.desktop/unix/native/libawt_xawt/awt/gtk3_interface.c:903:29: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
            if (init_result = (NULL == gtk3_widgets[_GTK_BUTTON_TYPE]))
                ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_gtk3_interface.c := parentheses, \

src/java.desktop/unix/native/libawt_xawt/awt/sun_awt_X11_GtkFileDialogPeer.c:87:26: error: using the result of an assignment as a condition without parentheses [-Werror,-Wparentheses]
    if (pendingException = (*env)->ExceptionOccurred(env)) {
        ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
solved by adding line
DISABLED_WARNINGS_clang_aix_sun_awt_X11_GtkFileDialogPeer.c := parentheses, \


src/java.desktop/aix/native/libawt_xawt/awt/awt_InputMethod.c:1969:32: error: comparison of integers of different signs: 'Window' (aka 'unsigned long') and 'jlong' (aka 'long') [-Werror,-Wsign-compare]
        if (currentFocusWindow != w) {
            ~~~~~~~~~~~~~~~~~~ ^  ~
solved by adding line
DISABLED_WARNINGS_clang_aix_awt_InputMethod.c := sign-compare, \

Here is the reason for the disabled warning in make/modules/java.security.jgss/Lib.gmk

src/java.security.jgss/share/native/libj2gss/NativeUtil.h:30:
/data/d042520/pr/jdk/src/java.security.jgss/share/native/libj2gss/gssapi.h:48:5: error: 'TARGET_OS_MAC' is not defined, evaluates to 0 [-Werror,-Wundef]
#if TARGET_OS_MAC && (defined(__ppc__) || defined(__ppc64__) || defined(__i386__) || defined(__x86_64__))
    ^
make/modules/java.security.jgss/Lib.gmk add line 
DISABLED_WARNINGS_clang_aix := undef, \

Here is the reason for the disabled warning in make/modules/jdk.jdwp.agent/Lib.gmk

src/jdk.jdwp.agent/share/native/libdt_socket/socketTransport.c:718:33: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces]
    struct in6_addr mappedAny = IN6ADDR_ANY_INIT;
                                ^~~~~~~~~~~~~~~~
/usr/include/netinet/in.h:454:32: note: expanded from macro 'IN6ADDR_ANY_INIT'
#define IN6ADDR_ANY_INIT      {0, 0, 0, 0}
solved by adding line
    DISABLED_WARNINGS_clang_aix := missing-braces, \

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564303459
PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564304989
PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564306115

From jlaskey at openjdk.org  Fri May 26 13:08:08 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 May 2023 13:08:08 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v20]
In-Reply-To: <7txzmoyjMl_VmeZW96En2DsyU50tTb4Vf9ls9cPTcUQ=.76a7f314-5ca8-4d27-b1a3-2541ca60bd73@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <DBQsWeRpbETtO0mMAZyfS46Z70Z5fuAEntDOR-k6oXs=.38100514-3edf-48df-abf3-a97b293fa89e@github.com>
 <lVuFaWAEYdySBVKt4XQF0DXjKInm34bGG1we2V-SGN0=.e9d4546f-8d62-4a61-a179-7245684c2f9e@github.com>
 <7txzmoyjMl_VmeZW96En2DsyU50tTb4Vf9ls9cPTcUQ=.76a7f314-5ca8-4d27-b1a3-2541ca60bd73@github.com>
Message-ID: <sr8jTPL0cPzFBESgc16g0Ae9ZlgeWbhLjCWFHIyo57Y=.1be4f55a-f11a-4e94-86ad-c4fa631d434b@github.com>

On Fri, 26 May 2023 06:20:14 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> test/jdk/tools/launcher/InstanceMainTest.java line 31:
>> 
>>> 29:  * @run main InstanceMainTest
>>> 30:  */
>>> 31: public class InstanceMainTest extends TestHelper {
>> 
>> By my reading of the spec, "main" methods can be defined in record classes and enum classes as well as normal classes.
>> Are there tests for record and enum main method operation?
>
> You can also have a `main` method inside an interface. For enum classes and interfaces, the main has to be static.

updating tests

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13689#discussion_r1206753443

From jlaskey at openjdk.org  Fri May 26 13:19:49 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 May 2023 13:19:49 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v21]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <Lo-_0KThx6XDZgRAmRQu-cGegc39FG8ql8OARg525SY=.67fe43d3-40ae-49b0-8d25-8e49de6b2a0f@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Add main  tests for inferface/enum/record

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/cfac821a..4e54c17a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=19-20

  Stats: 128 lines in 2 files changed: 27 ins; 22 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From liach at openjdk.org  Fri May 26 13:23:04 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 May 2023 13:23:04 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v3]
In-Reply-To: <LvTHTEI6f2wcPaMklu_WZedfqnUqWX_ij9iG_y10sfE=.ed10c1d5-c391-4fc0-8ed2-631ce508d5f4@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <LvTHTEI6f2wcPaMklu_WZedfqnUqWX_ij9iG_y10sfE=.ed10c1d5-c391-4fc0-8ed2-631ce508d5f4@github.com>
Message-ID: <dmhp2kQGhQUQO1axPdeAl4tygzXUiLWZnHXG44dzkI8=.4f0da61c-8b40-489f-bc4a-e11d1c349eef@github.com>

On Wed, 17 May 2023 17:20:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30       0.769 ?      0.003  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30       0.767 ?      0.002  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10   73140.100 ?   7735.276  ns/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10   50000.000 ?   8482.883  ns/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   91350.100 ?   9776.343  ns/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  145540.200 ?  72894.865  ns/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10   47069.900 ?   3513.909  ns/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10   24780.300 ?   5144.540  ns/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10   85479.700 ?  10816.983  ns/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  413630.100 ? 189370.448  ns/op
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Remove export for removed package
>  - Merge branch 'master' into lazy-static-varhandle
>  - Test the creation performance of handles, lazy one indeed better
>  - Merge branch 'master' into lazy-static-varhandle
>  - copyright year
>  - Benchmarks. lazy initialize is SLOW
>  - nuke meaningless overrides
>  - make static field var handles lazy and fix NPE in isAccessModeSupported

@mlchung Would you mind taking a look at this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1564386002

From jlaskey at openjdk.org  Fri May 26 13:22:59 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 26 May 2023 13:22:59 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v22]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <fQnM3RKA8c6l_RX1shTn2H5gHDJEhRyqCNiINWxe97Q=.dd133e2a-904c-44b8-a9e8-baf9eadb9e75@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Remove trailing whitespace

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/4e54c17a..06aa43ec

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=20-21

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From mdoerr at openjdk.org  Fri May 26 13:37:55 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 26 May 2023 13:37:55 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
Message-ID: <WQLgaO9aCVx1253y74vhudFQdxyvQQ8Lc5CCVdDHj08=.dcf77230-b8d0-4f8f-ba1c-924d049ebd31@github.com>

On Fri, 26 May 2023 08:31:46 GMT, JoKern65 <duke at openjdk.org> wrote:

>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small adjustments.
>> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.
>
> JoKern65 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forgotton _

Just a side note: The warning elimination is new for AIX compilers. We had given it up at earlier times: https://bugs.openjdk.org/browse/JDK-8202325
I still appreciate if we can get warning free and it makes sense to review all of them. But, I wouldn't require it for JDK21.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14146#issuecomment-1564406986

From shade at openjdk.org  Fri May 26 14:57:03 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 14:57:03 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v4]
In-Reply-To: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
Message-ID: <XCkPURqRm7CuA8f_IwcGO_j6JjyXjihIf2GlQ0-QzF8=.f18ad29f-9444-4da2-9cbd-e62493dde55f@github.com>

> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
> 
> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
> 
> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
> 
> 
> Benchmark               Mode  Cnt  Score   Error   Units
> 
> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
> 
> # After
> UUIDRandomBench.single  thrpt   15  4.823 ? 0.023  ops/us 
> UUIDRandomBench.max     thrpt   15  6.561 ? 0.054  ops/us ; positive scaling, ~1.5x
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
> 
> # After
> Benchmark                Mode  Cnt  Score   Error   Units
> UUIDRandomBench.single  thrpt   15  3.109 ? 0.026  ops/us
> UUIDRandomBench.max     thrpt   15  3.561 ? 0.071  ops/us  ; positive scaling, ~1.2x
> 
> 
> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
> 
> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
> 
> 
> Benchmark               Mode  Cnt   Score   Error   Units
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
> UUIDRandomBench.single  thrpt   15  3.661 ? 0.008  ops/us
> UUIDRandomBench...

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Swap lsb/msb

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14135/files
  - new: https://git.openjdk.org/jdk/pull/14135/files/deddaa6e..4e9503d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14135&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14135&range=02-03

  Stats: 13 lines in 1 file changed: 0 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/14135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14135/head:pull/14135

PR: https://git.openjdk.org/jdk/pull/14135

From rriggs at openjdk.org  Fri May 26 15:04:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 May 2023 15:04:37 GMT
Subject: RFR: 8308960: Decouple internal Version and OperatingSystem classes
Message-ID: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>

Decouple the jdk.internal.util OperatingSystem and Version classes to simplify class loading and avoid an indirect cyclic initialization.

Move the method to get the current OS version from OperatingSystem to the Version class and its initialization.
Revert to using String.toUpperCase() instead of custom code to uppercase.

Update the uses of OperatingSystem.version to be Version.current.

-------------

Commit messages:
 - 8308960: Decouple internal Version and OperatingSystem classes

Changes: https://git.openjdk.org/jdk/pull/14181/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14181&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308960
  Stats: 58 lines in 4 files changed: 24 ins; 29 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14181.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14181/head:pull/14181

PR: https://git.openjdk.org/jdk/pull/14181

From shade at openjdk.org  Fri May 26 15:05:59 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 15:05:59 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v3]
In-Reply-To: <FIiQ3EHrKct94ItDTIDs7WmLkyaPQo4mG0FFDoLZh4Y=.fa9e34d4-41de-456a-910b-e94b7fcf6e05@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <K6mGrn-ipEgXeaEW1UVGKp4KxE-6TRRm3Gts73BWnpc=.daa29af8-029d-4a94-bd30-3130a9d81f72@github.com>
 <FIiQ3EHrKct94ItDTIDs7WmLkyaPQo4mG0FFDoLZh4Y=.fa9e34d4-41de-456a-910b-e94b7fcf6e05@github.com>
Message-ID: <txcV6KBH6rWat0T-2n5nL0MjLTw0co-pixboxn1kyis=.9b52b3a0-eb8f-4f2e-bc6f-7d76d7a44e31@github.com>

On Fri, 26 May 2023 12:01:50 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fine-tune exceptions
>
> src/java.base/share/classes/java/util/UUID.java line 226:
> 
>> 224:                 // set variant to IETF
>> 225:                 msb = (msb & (0x3FFF_FFFF_FFFF_FFFFL)) | 0x8000_0000_0000_0000L;
>> 226:                 return new UUID(lsb, msb);
> 
> Doesn't `msb` [come first](https://github.com/openjdk/jdk/blob/deddaa6ea61f85e9822982a37dad51ff4310457b/src/java.base/share/classes/java/util/UUID.java#L314)?

Yes. Swapped.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206925415

From dfuchs at openjdk.org  Fri May 26 15:24:55 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 26 May 2023 15:24:55 GMT
Subject: RFR: 8308960: Decouple internal Version and OperatingSystem
 classes
In-Reply-To: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
References: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
Message-ID: <uel-9FMlOpmEfX8cA6lK5nb4VUv23b65rNOs9VJtoAw=.da752ee3-3b4f-4cbf-b8b7-08f8e073427b@github.com>

On Fri, 26 May 2023 14:57:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Decouple the jdk.internal.util OperatingSystem and Version classes to simplify class loading and avoid an indirect cyclic initialization.
> 
> Move the method to get the current OS version from OperatingSystem to the Version class and its initialization.
> Revert to using String.toUpperCase() instead of custom code to uppercase.
> 
> Update the uses of OperatingSystem.version to be Version.current.

Should we take this opportunity to rename `jdk.internal.util.Version` into something like `OsVersion` to make it more clear what its `current()` method actually returns?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14181#issuecomment-1564553174

From rriggs at openjdk.org  Fri May 26 15:33:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 May 2023 15:33:08 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v4]
In-Reply-To: <PMygQbcPXK6GNPn2UFG_OLs-gTDNx4Dey8CVmo7Sncc=.467705c2-8be5-48e1-9729-eb0782aaf443@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <cBkMN9Na-lcYkaPcjDxrpaAZiy7H81-wMPm4zhG06tE=.d34bcfb3-1b70-43de-895f-7d6fce8f2d50@github.com>
 <PMygQbcPXK6GNPn2UFG_OLs-gTDNx4Dey8CVmo7Sncc=.467705c2-8be5-48e1-9729-eb0782aaf443@github.com>
Message-ID: <7rA4uDeQUlq38eXO2M_P2eAVUMubJLtTIUI5GE6zR6E=.8bd0d7c7-260b-498c-809d-e9e2266f4af9@github.com>

On Thu, 25 May 2023 14:04:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/UUID.java line 149:
>> 
>>> 147:             } else {
>>> 148:                 try {
>>> 149:                     return SecureRandom.getInstance(PRNG_NAME);
>> 
>> Part of the change here is that the RNG algorithm is configurable via a system property. The naming of the naming (java.util.UUID.prngName) hints that you might want it to be a standard system property but maybe it's for testing?
>
> Yes, I used them for testing, but left them in, because it would be convenient to have them around for field tuning and diagnostics. This would require a CSR, right?

I don't think there is a strong case for adding the system properties. They just add to the surface area that has to be maintained and add very little value except in very rare cases.  If someone needs very special treatment they can build it outside of UUID and use the new UUID(long, long) constructor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1206962862

From rriggs at openjdk.org  Fri May 26 15:34:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 May 2023 15:34:56 GMT
Subject: RFR: 8308960: Decouple internal Version and OperatingSystem
 classes
In-Reply-To: <uel-9FMlOpmEfX8cA6lK5nb4VUv23b65rNOs9VJtoAw=.da752ee3-3b4f-4cbf-b8b7-08f8e073427b@github.com>
References: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
 <uel-9FMlOpmEfX8cA6lK5nb4VUv23b65rNOs9VJtoAw=.da752ee3-3b4f-4cbf-b8b7-08f8e073427b@github.com>
Message-ID: <7sBzZV7suahhEjbw0LQ5fYFV668wSGPEv_YCdBzaKb0=.db24d2fa-114a-414b-aeb3-c64ee6d8b129@github.com>

On Fri, 26 May 2023 15:21:42 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Should we take this opportunity to rename `jdk.internal.util.Version` into something like `OsVersion` to make it more clear what its `current()` method actually returns?

ok, it will give a bit more flavor; there are already multiple version classes with little to distinguish them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14181#issuecomment-1564567712

From duke at openjdk.org  Fri May 26 15:40:19 2023
From: duke at openjdk.org (Rudi Horn)
Date: Fri, 26 May 2023 15:40:19 GMT
Subject: RFR: 8308748: JNU_GetStringPlatformChars may write to String's
 internal memory array
Message-ID: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>

This change prevents the contents of the internal string array from being copied back when releasing it.

-------------

Commit messages:
 - Use JNI_ABORT to release string bytes

Changes: https://git.openjdk.org/jdk/pull/14117/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14117&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308748
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14117.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14117/head:pull/14117

PR: https://git.openjdk.org/jdk/pull/14117

From rriggs at openjdk.org  Fri May 26 15:45:24 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 May 2023 15:45:24 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v2]
In-Reply-To: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
Message-ID: <j3y1HjxREp6cAdoBMDbEikdF0aAuSWQfXyRqZYS20hM=.7d51faae-601d-4259-a73c-9755ec97740b@github.com>

> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
> 
> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
> The enum values directly reflect the build-time artifacts and resulting executables.
> 
> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Review suggestions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14063/files
  - new: https://git.openjdk.org/jdk/pull/14063/files/e9c8d89b..b384396b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14063&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14063&range=00-01

  Stats: 29 lines in 3 files changed: 6 ins; 19 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14063.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14063/head:pull/14063

PR: https://git.openjdk.org/jdk/pull/14063

From rriggs at openjdk.org  Fri May 26 15:52:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 May 2023 15:52:54 GMT
Subject: RFR: 8290499: new File(parent,
 "/") breaks normalization =?UTF-8?B?4oCT?= creates File with slash at the end
In-Reply-To: <8xzVUmIbNYbHrO6ymEBcptZ4uK5saoxx0xXzmdVSc9E=.30439fa6-e4bb-46fb-b1be-0e103a31d6e5@github.com>
References: <8xzVUmIbNYbHrO6ymEBcptZ4uK5saoxx0xXzmdVSc9E=.30439fa6-e4bb-46fb-b1be-0e103a31d6e5@github.com>
Message-ID: <6homD6QR3R1w80IJUrggBnL_dRyT6fk0l7T_DfU21JE=.4171194f-5968-4d20-b191-279cffe4b0d7@github.com>

On Tue, 23 May 2023 22:49:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `java.io.File`, change the constructors `File(File,String)` and `File(String,String)` so that they do not for typical cases return a `File` whose path has a trailing name separator.

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14109#pullrequestreview-1446514781

From bpb at openjdk.org  Fri May 26 15:59:57 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 26 May 2023 15:59:57 GMT
Subject: RFR: 8306431: File.listRoots method description should be
 re-examined [v7]
In-Reply-To: <8hwJYhcT5DQJpsC0Zzlj_kcWqpw9b8yBcVXMLVJurqA=.593e7ec9-f221-4c09-803a-a2de35bfcdb3@github.com>
References: <r2g378dduK1RcEGpwEBP5bHpvQ3P6OQyL6aEXe1YAx4=.32d1b517-b6f8-4e89-ae8a-bd4c5e6f2b1d@github.com>
 <hw_GfSecKgwyXkMjKCqk8Cbpa-0_4wZe8M6aHrQVzIQ=.acf75a82-db86-4422-9d73-48efe2ad16b4@github.com>
 <8hwJYhcT5DQJpsC0Zzlj_kcWqpw9b8yBcVXMLVJurqA=.593e7ec9-f221-4c09-803a-a2de35bfcdb3@github.com>
Message-ID: <wPttW_J88W-KkZeynbBh2dDK9IxwYbkHQhFPK8Ym9TU=.39169dff-b116-416d-8f69-3055054b254e@github.com>

On Fri, 26 May 2023 08:46:09 GMT, Nagata-Haruhito <duke at openjdk.org> wrote:

> Would you please review this PR ?

We are in the last two weeks before JDK 21 rampdown phase 1 and so are rather busy. This PR has not been forgotten. Thanks for you patience.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13526#issuecomment-1564601445

From mchung at openjdk.org  Fri May 26 16:08:54 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 May 2023 16:08:54 GMT
Subject: RFR: 8308960: Decouple internal Version and OperatingSystem
 classes
In-Reply-To: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
References: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
Message-ID: <EwSZ3Xt56Tp5mgdH_xEqHSvxT_1ANlBadC6LGQlKLtY=.7e80f738-b277-4762-8288-a5fbe9d458cd@github.com>

On Fri, 26 May 2023 14:57:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Decouple the jdk.internal.util OperatingSystem and Version classes to simplify class loading and avoid an indirect cyclic initialization.
> 
> Move the method to get the current OS version from OperatingSystem to the Version class and its initialization.
> Revert to using String.toUpperCase() instead of custom code to uppercase.
> 
> Update the uses of OperatingSystem.version to be Version.current.

Looks good.  Thanks for fixing this.  It will allow ClassFileDumper to use `Path`.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14181#pullrequestreview-1446540821

From mchung at openjdk.org  Fri May 26 16:19:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 May 2023 16:19:56 GMT
Subject: RFR: 8308960: Decouple internal Version and OperatingSystem
 classes
In-Reply-To: <7sBzZV7suahhEjbw0LQ5fYFV668wSGPEv_YCdBzaKb0=.db24d2fa-114a-414b-aeb3-c64ee6d8b129@github.com>
References: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
 <uel-9FMlOpmEfX8cA6lK5nb4VUv23b65rNOs9VJtoAw=.da752ee3-3b4f-4cbf-b8b7-08f8e073427b@github.com>
 <7sBzZV7suahhEjbw0LQ5fYFV668wSGPEv_YCdBzaKb0=.db24d2fa-114a-414b-aeb3-c64ee6d8b129@github.com>
Message-ID: <waOML2MDhT2La-QUr7TJlV8M7-84mxXW7jvqIoVhYi8=.fafefbda-a7d8-40b0-9ba8-1358c3a0049a@github.com>

On Fri, 26 May 2023 15:32:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Should we take this opportunity to rename `jdk.internal.util.Version` into something like `OsVersion` to make it more clear what its `current()` method actually returns?

Alternatively, move `Version` record as a nested class in `OperatingSystem`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14181#issuecomment-1564625922

From dfuchs at openjdk.org  Fri May 26 16:25:54 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 26 May 2023 16:25:54 GMT
Subject: RFR: 8308960: Decouple internal Version and OperatingSystem
 classes
In-Reply-To: <waOML2MDhT2La-QUr7TJlV8M7-84mxXW7jvqIoVhYi8=.fafefbda-a7d8-40b0-9ba8-1358c3a0049a@github.com>
References: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
 <uel-9FMlOpmEfX8cA6lK5nb4VUv23b65rNOs9VJtoAw=.da752ee3-3b4f-4cbf-b8b7-08f8e073427b@github.com>
 <7sBzZV7suahhEjbw0LQ5fYFV668wSGPEv_YCdBzaKb0=.db24d2fa-114a-414b-aeb3-c64ee6d8b129@github.com>
 <waOML2MDhT2La-QUr7TJlV8M7-84mxXW7jvqIoVhYi8=.fafefbda-a7d8-40b0-9ba8-1358c3a0049a@github.com>
Message-ID: <57mdaCEZ7onMTjRLjyf7QXxh6ShiskPgJZlwZq_Yxto=.2126d670-5421-4b84-8e69-cfbdeba8cd23@github.com>

On Fri, 26 May 2023 16:16:58 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Alternatively, move `Version` record as a nested class in `OperatingSystem`.

That would work WRT naming, but I thought the point was to not have to load OperatingSystem in order to load Version?
Unless loading a static inner class doesn't force the loading of the outer class?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14181#issuecomment-1564631561

From mchung at openjdk.org  Fri May 26 16:30:59 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 May 2023 16:30:59 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v3]
In-Reply-To: <LvTHTEI6f2wcPaMklu_WZedfqnUqWX_ij9iG_y10sfE=.ed10c1d5-c391-4fc0-8ed2-631ce508d5f4@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <LvTHTEI6f2wcPaMklu_WZedfqnUqWX_ij9iG_y10sfE=.ed10c1d5-c391-4fc0-8ed2-631ce508d5f4@github.com>
Message-ID: <iJAf7i_OmQiDG2N3QphU-YL1P-G7ylfrPxeJ7RLpmpk=.72fbcdbe-0216-420c-8549-daeea5eb5fea@github.com>

On Wed, 17 May 2023 17:20:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30       0.769 ?      0.003  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30       0.767 ?      0.002  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10   73140.100 ?   7735.276  ns/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10   50000.000 ?   8482.883  ns/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   91350.100 ?   9776.343  ns/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  145540.200 ?  72894.865  ns/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10   47069.900 ?   3513.909  ns/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10   24780.300 ?   5144.540  ns/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10   85479.700 ?  10816.983  ns/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  413630.100 ? 189370.448  ns/op
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Remove export for removed package
>  - Merge branch 'master' into lazy-static-varhandle
>  - Test the creation performance of handles, lazy one indeed better
>  - Merge branch 'master' into lazy-static-varhandle
>  - copyright year
>  - Benchmarks. lazy initialize is SLOW
>  - nuke meaningless overrides
>  - make static field var handles lazy and fix NPE in isAccessModeSupported

I'm aware of these PRs.  I'll get to it when I get to it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13821#issuecomment-1564639138

From mchung at openjdk.org  Fri May 26 16:31:54 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 May 2023 16:31:54 GMT
Subject: RFR: 8308960: Decouple internal Version and OperatingSystem
 classes
In-Reply-To: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
References: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
Message-ID: <WWHB3g0jmD1-NFs29Z-na1F4tALXRqGikdaOBqn4ewA=.c2d9a33e-eeb1-4a3d-9ef2-07737f9bae81@github.com>

On Fri, 26 May 2023 14:57:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Decouple the jdk.internal.util OperatingSystem and Version classes to simplify class loading and avoid an indirect cyclic initialization.
> 
> Move the method to get the current OS version from OperatingSystem to the Version class and its initialization.
> Revert to using String.toUpperCase() instead of custom code to uppercase.
> 
> Update the uses of OperatingSystem.version to be Version.current.

I mean static member class of `OperatingSystem`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14181#issuecomment-1564637892

From rriggs at openjdk.org  Fri May 26 16:31:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 May 2023 16:31:55 GMT
Subject: RFR: 8308960: Decouple internal Version and OperatingSystem
 classes
In-Reply-To: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
References: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
Message-ID: <JXzg9ELjhvMS4zv1-GbAV_EBIeIiJ7cuNA1BjlQi_CE=.af690f3d-5f2b-4176-ae45-476e2b5bcd27@github.com>

On Fri, 26 May 2023 14:57:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Decouple the jdk.internal.util OperatingSystem and Version classes to simplify class loading and avoid an indirect cyclic initialization.
> 
> Move the method to get the current OS version from OperatingSystem to the Version class and its initialization.
> Revert to using String.toUpperCase() instead of custom code to uppercase.
> 
> Update the uses of OperatingSystem.version to be Version.current.

For the time being, I think they should be independent and clearly named.
The nesting creates a very unwieldy and long name.  (Not withstanding imports)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14181#issuecomment-1564640242

From mcimadamore at openjdk.org  Fri May 26 16:34:08 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 26 May 2023 16:34:08 GMT
Subject: RFR: 8308293: A linker should expose the layouts it supports [v6]
In-Reply-To: <c1et2B8bNarPWOrpKzWq-uRaxpybGbEJkwBwDd7jcro=.34594240-c8ea-4507-bb22-3bee3ee3bb99@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
 <c1et2B8bNarPWOrpKzWq-uRaxpybGbEJkwBwDd7jcro=.34594240-c8ea-4507-bb22-3bee3ee3bb99@github.com>
Message-ID: <iUFXmjvA6I3XWzWXGS-PYBtg7u-WhbJq06x5zKXUuGk=.1f4034dc-95a5-4423-b8c8-e9d407ab6417@github.com>

On Wed, 24 May 2023 09:36:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
>> 
>> 
>> jshell> import java.lang.foreign.*;
>> 
>> jshell> Linker.nativeLinker().canonicalLayouts()
>> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
>> 
>> 
>> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into linker_types
>  - Drop "unsigned short"
>    Beef up javadoc
>  - Address further review comments
>  - Address review comments
>  - More javadoc tweaks
>  - Tweak javadoc
>  - Tweak javadoc
>    Add char type
>  - Initial push

Thanks for taking the time to review. After some more consideration, I will withdraw this PR. While this API is largely not problematic, we need to make sure that this API fits with how the FFM API will be evolved to support other types besides the C basic types we know and love (e.g. `long double`, vectors, `complex` types). So adding this API point now seems premature.

I will bring over relevant javadoc improvements in the other javadoc PR I have open: https://github.com/openjdk/panama-foreign/pull/833

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14037#issuecomment-1564641545

From mcimadamore at openjdk.org  Fri May 26 16:34:10 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 26 May 2023 16:34:10 GMT
Subject: Withdrawn: 8308293: A linker should expose the layouts it supports
In-Reply-To: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
References: <C_xJCpHauS1PT0jZgygMlkdv8JV7UWUpydg9PDon1fc=.272a6625-5f0f-4d4e-a13b-ed1f73cff719@github.com>
Message-ID: <DlIHsRrhrEOSyDFdMP3AFSFKfIo9t91ltEpZ55WC-jA=.f9dab510-51b1-442f-8ae3-72fbe7af159f@github.com>

On Wed, 17 May 2023 17:15:06 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch adds an instance method on `Linker`, namely `Linker::canonicalLayouts` which returns all the layouts known by the linker as implementing some ABI type. For instance, if I call this on my machine (Linux/x64) I get this:
> 
> 
> jshell> import java.lang.foreign.*;
> 
> jshell> Linker.nativeLinker().canonicalLayouts()
> $2 ==> {char16_t=c16, int8_t=b8, long=j64, size_t=j64, bool=z8, int=i32, long long=j64, int64_t=j64, void*=a64, float=f32, char=b8, int16_t=s16, int32_t=i32, short=s16, double=d64}
> 
> 
> This can be useful to discover the ABI types supported by a linker implementation, as well as for, in the future, add support for more exotic (and platform-dependent) linker types, such as `long double` or `complex long`.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/14037

From rriggs at openjdk.org  Fri May 26 16:54:42 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 May 2023 16:54:42 GMT
Subject: RFR: 8308960: Decouple internal Version and OperatingSystem
 classes [v2]
In-Reply-To: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
References: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
Message-ID: <P954_kQ2SMc7QILMjC5yiVnQM9BJuX4KaYfnembec7c=.f5ac4360-f703-4d88-abd1-559ed3b98a58@github.com>

> Decouple the jdk.internal.util OperatingSystem and Version classes to simplify class loading and avoid an indirect cyclic initialization.
> 
> Move the method to get the current OS version from OperatingSystem to the Version class and its initialization.
> Revert to using String.toUpperCase() instead of custom code to uppercase.
> 
> Update the uses of OperatingSystem.version to be Version.current.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Rename jdk.internal.util.Version to OSVersion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14181/files
  - new: https://git.openjdk.org/jdk/pull/14181/files/f6332cd9..22e022c0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14181&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14181&range=00-01

  Stats: 298 lines in 5 files changed: 135 ins; 136 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/14181.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14181/head:pull/14181

PR: https://git.openjdk.org/jdk/pull/14181

From stuefe at openjdk.org  Fri May 26 17:01:57 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 26 May 2023 17:01:57 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <G0ZEvXBOXoDAbZOSj0zcDFxcADCi_Mk-hNOvsJiCw58=.443eb739-394c-44da-8e48-6b157ad59045@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <Z6J__T8X9bDvrfFjUxNImPMEUwKQmbESvmzYUeDolkQ=.9309297e-ab60-4cd5-9a20-687d545101a8@github.com>
 <G0ZEvXBOXoDAbZOSj0zcDFxcADCi_Mk-hNOvsJiCw58=.443eb739-394c-44da-8e48-6b157ad59045@github.com>
Message-ID: <nA6t5xQ1QqQJ9UEwtTbAcG9P705u1cjmnmBrWCtbXq4=.1bed9538-5073-4649-bfd6-0f5734b0a967@github.com>

On Thu, 25 May 2023 18:18:43 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> src/hotspot/share/utilities/globalDefinitions_xlc.hpp line 47:
>> 
>>> 45:   #undef malloc
>>> 46:   extern void *malloc(size_t) asm("vec_malloc");
>>> 47: #endif
>> 
>> Wow!  And I don't mean that in a good way.  I'm not questioning whether this is correct, just commenting
>> on how crazy it seems that such a thing might be needed.
>
> The crazy thing is that `malloc` is defined! That means all places where we use the term malloc are getting replaced without such a workaround. (E.g. for log tags.)

So, we do this only for malloc? Not for calloc, posix_memalign, realloc etc? What about free? 

As ugly as defining malloc is (and I remember QADRT), I hesitate about removing that define.

Removing that define and hard-coding it here assumes 1) our replacement is equivalent (ok, easy to check) 2) it will always be equivalent in future AIX versions 3) pointers it returns work with the unchanged free() and realloc() the system provides, and will always do so.

I don't know... I would not do this just to get rid of a warning.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1207078176

From shade at openjdk.org  Fri May 26 17:21:33 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 17:21:33 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v5]
In-Reply-To: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
Message-ID: <udsMAtMdqRwE24w3NWynoOm9q0l916OqjHmaQSRZYAk=.83b26c6a-c1d1-47c3-81de-2d13d90276b1@github.com>

> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
> 
> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
> 
> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
> 
> 
> Benchmark               Mode  Cnt  Score   Error   Units
> 
> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
> 
> # After
> UUIDRandomBench.single  thrpt   15  4.823 ? 0.023  ops/us 
> UUIDRandomBench.max     thrpt   15  6.561 ? 0.054  ops/us ; positive scaling, ~1.5x
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
> 
> # After
> Benchmark                Mode  Cnt  Score   Error   Units
> UUIDRandomBench.single  thrpt   15  3.109 ? 0.026  ops/us
> UUIDRandomBench.max     thrpt   15  3.561 ? 0.071  ops/us  ; positive scaling, ~1.2x
> 
> 
> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
> 
> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
> 
> 
> Benchmark               Mode  Cnt   Score   Error   Units
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
> UUIDRandomBench.single  thrpt   15  3.661 ? 0.008  ops/us
> UUIDRandomBench...

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Remove the properties

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14135/files
  - new: https://git.openjdk.org/jdk/pull/14135/files/4e9503d1..47375313

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14135&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14135&range=03-04

  Stats: 42 lines in 1 file changed: 0 ins; 37 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14135/head:pull/14135

PR: https://git.openjdk.org/jdk/pull/14135

From shade at openjdk.org  Fri May 26 17:21:53 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 17:21:53 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v5]
In-Reply-To: <7rA4uDeQUlq38eXO2M_P2eAVUMubJLtTIUI5GE6zR6E=.8bd0d7c7-260b-498c-809d-e9e2266f4af9@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <cBkMN9Na-lcYkaPcjDxrpaAZiy7H81-wMPm4zhG06tE=.d34bcfb3-1b70-43de-895f-7d6fce8f2d50@github.com>
 <PMygQbcPXK6GNPn2UFG_OLs-gTDNx4Dey8CVmo7Sncc=.467705c2-8be5-48e1-9729-eb0782aaf443@github.com>
 <7rA4uDeQUlq38eXO2M_P2eAVUMubJLtTIUI5GE6zR6E=.8bd0d7c7-260b-498c-809d-e9e2266f4af9@github.com>
Message-ID: <V4v0__v4Zf8oGle1YUCzNM9iM-wKiqYcejxTAx_0eXw=.473bcf35-172c-4a7d-aae1-4fb4990ad92b@github.com>

On Fri, 26 May 2023 15:30:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Yes, I used them for testing, but left them in, because it would be convenient to have them around for field tuning and diagnostics. This would require a CSR, right?
>
> I don't think there is a strong case for adding the system properties. They just add to the surface area that has to be maintained and add very little value except in very rare cases.  If someone needs very special treatment they can build it outside of UUID and use the new UUID(long, long) constructor.

That sounds okay to me. It simplifies the whole thing and does not require me to implement more test and have a CSR discussion about the options too :) Removed in the new commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1207103570

From shade at openjdk.org  Fri May 26 17:22:12 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 17:22:12 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v5]
In-Reply-To: <7rA4uDeQUlq38eXO2M_P2eAVUMubJLtTIUI5GE6zR6E=.8bd0d7c7-260b-498c-809d-e9e2266f4af9@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
 <cBkMN9Na-lcYkaPcjDxrpaAZiy7H81-wMPm4zhG06tE=.d34bcfb3-1b70-43de-895f-7d6fce8f2d50@github.com>
 <PMygQbcPXK6GNPn2UFG_OLs-gTDNx4Dey8CVmo7Sncc=.467705c2-8be5-48e1-9729-eb0782aaf443@github.com>
 <7rA4uDeQUlq38eXO2M_P2eAVUMubJLtTIUI5GE6zR6E=.8bd0d7c7-260b-498c-809d-e9e2266f4af9@github.com>
Message-ID: <V4v0__v4Zf8oGle1YUCzNM9iM-wKiqYcejxTAx_0eXw=.9a1f339b-66ba-490e-b238-e0e5883d4b4f@github.com>

On Fri, 26 May 2023 15:30:29 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Yes, I used them for testing, but left them in, because it would be convenient to have them around for field tuning and diagnostics. This would require a CSR, right?
>
> I don't think there is a strong case for adding the system properties. They just add to the surface area that has to be maintained and add very little value except in very rare cases.  If someone needs very special treatment they can build it outside of UUID and use the new UUID(long, long) constructor.

That sounds okay to me. It simplifies the whole thing and does not require me to implement more test and have a CSR discussion about the options too :) Removed in the new commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14135#discussion_r1207103570

From stuefe at openjdk.org  Fri May 26 17:26:02 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 26 May 2023 17:26:02 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v7]
In-Reply-To: <R6DVMij5x0AMpm-QIduWF1NnfmpP86FDRkXaZ2474Ms=.85ac8e8a-3d29-4c57-baa9-4e8e830dad5d@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <R6DVMij5x0AMpm-QIduWF1NnfmpP86FDRkXaZ2474Ms=.85ac8e8a-3d29-4c57-baa9-4e8e830dad5d@github.com>
Message-ID: <Oi1ArfWySswooqIBtoqsG6TlsuOJCgvYHzkS-o-mWuk=.cb5beafd-adcc-46af-9440-785ca73749ec@github.com>

On Thu, 25 May 2023 15:25:40 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for failing CloseRace test

> Fixing the last bug :)
> 
> If we close the writing end of the pipe to jspawnhelper early in `spawnChild()` right after the last write (which I still think is a good idea), we have to use `c->childenv` rather than `childenv` when closing the pipe descriptors at the end of `Java_java_lang_ProcessImpl_forkAndExec()` in order to avoid double closing:
> 
> ```c++
> -    closeSafely(childenv[0]);
> -    closeSafely(childenv[1]);
> +    /* We use 'c->childenv' here rather than 'childenv' because 'spawnChild()' might have
> +     * already closed 'c->childenv[1]' and signaled this by setting 'c->childenv[1]' to '-1'.
> +     * Otherwise 'c->childenv' and 'childenv' are the same because we just copied 'childenv'
> +     * to 'c->childenv' (with 'copyPipe()') before calling 'startChild()'. */
> +    closeSafely(c->childenv[0]);
> +    closeSafely(c->childenv[1]);
> ```
> 
> This also fixes `test/jdk/java/lang/ProcessBuilder/CloseRace.java` which could failed sporadically the previous version of the change.

I missed that. Christ this stuff is complex :( 

Still think it would be cleaner and simpler to set the FD in the parent to CLOEXEC, before doing posix_spawn, and at the same time set the childStuff variable to -1 to prevent the child from attempting to re-close it. Reconsider?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1564700036

From shade at openjdk.org  Fri May 26 17:26:56 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 26 May 2023 17:26:56 GMT
Subject: RFR: 8308804: Improve UUID.randomUUID performance with
 bulk/scalable PRNG access [v6]
In-Reply-To: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
References: <qoltlnuHH-7ZUHHwrvP1N_kr9qphvYH07aibwDRwVRc=.cb19e409-cd51-4bc9-bd27-d6d48fe52e44@github.com>
Message-ID: <0r0fU0qQ5-zibjd3hNdH_LbB_hyWRLkRSytc-OsFzfc=.71ea314f-9df6-4e64-9a34-2853d1b0a6ba@github.com>

> UUID is the very important class that is used to track identities of objects in large scale systems. On some of our systems, `UUID.randomUUID` takes >1% of total CPU time, and is frequently a scalability bottleneck due to `SecureRandom` synchronization.
> 
> The major issue with UUID code itself is that it reads from the single `SecureRandom` instance by 16 bytes. So the heavily contended `SecureRandom` is bashed with very small requests. This also has a chilling effect on other users of `SecureRandom`, when there is a heavy UUID generation traffic.
> 
> We can improve this by doing the bulk reads from the backing SecureRandom and possibly striping the reads across many instances of it. 
> 
> 
> Benchmark               Mode  Cnt  Score   Error   Units
> 
> ### AArch64 (m6g.4xlarge, Graviton, 16 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  3.545 ? 0.058  ops/us
> UUIDRandomBench.max     thrpt   15  1.832 ? 0.059  ops/us ; negative scaling
> 
> # After
> UUIDRandomBench.single  thrpt   15  4.823 ? 0.023  ops/us 
> UUIDRandomBench.max     thrpt   15  6.561 ? 0.054  ops/us ; positive scaling, ~1.5x
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before
> UUIDRandomBench.single  thrpt   15  2.710 ? 0.038  ops/us
> UUIDRandomBench.max     thrpt   15  1.880 ? 0.029  ops/us  ; negative scaling 
> 
> # After
> Benchmark                Mode  Cnt  Score   Error   Units
> UUIDRandomBench.single  thrpt   15  3.109 ? 0.026  ops/us
> UUIDRandomBench.max     thrpt   15  3.561 ? 0.071  ops/us  ; positive scaling, ~1.2x
> 
> 
> Note that there is still a scalability bottleneck in current default random (`NativePRNG`), because it synchronizes over a singleton instance for SHA1 mixer, then the engine itself, etc. -- it is quite a whack-a-mole to figure out the synchronization story there. The scalability fix in current default `SecureRandom` would be much more intrusive and risky, since it would change a core crypto class with unknown bug fanout.
> 
> Using the bulk reads even when the underlying PRNG is heavily synchronized is still a win. A more scalable PRNG would benefit from this as well. This PR adds a system property to select the PRNG implementation, and there we can clearly see the benefit with more scalable PRNG sources:
> 
> 
> Benchmark               Mode  Cnt   Score   Error   Units
> 
> ### x86_64 (c6.8xlarge, Xeon, 18 cores)
> 
> # Before, hacked `new SecureRandom()` to `SecureRandom.getInstance("SHA1PRNG")`
> UUIDRandomBench.single  thrpt   15  3.661 ? 0.008  ops/us
> UUIDRandomBench...

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Simplify clinit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14135/files
  - new: https://git.openjdk.org/jdk/pull/14135/files/47375313..75455ca2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14135&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14135&range=04-05

  Stats: 6 lines in 1 file changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14135/head:pull/14135

PR: https://git.openjdk.org/jdk/pull/14135

From michaelm at openjdk.org  Fri May 26 17:38:57 2023
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 26 May 2023 17:38:57 GMT
Subject: RFR: 8308748: JNU_GetStringPlatformChars may write to String's
 internal memory array
In-Reply-To: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>
References: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>
Message-ID: <TaV2tvpuANCahtox0mgOs7h0xP4st-gjMnmwICu1aKg=.cbaee55f-4cde-4ff4-a708-ad394ee30038@github.com>

On Wed, 24 May 2023 09:24:46 GMT, Rudi Horn <duke at openjdk.org> wrote:

> This change prevents the contents of the internal string array from being copied back when releasing it.

There was an unrelated change to these functions recently. You might want to rebase this PR with the latest version.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14117#issuecomment-1564712601

From raffaello.giulietti at oracle.com  Fri May 26 18:06:31 2023
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Fri, 26 May 2023 20:06:31 +0200
Subject: [External] : Re: Classes used in method body are loaded lazily or
 eagerly depending on method return type
In-Reply-To: <3280f8e4-0f07-598c-f6e7-32c081da2c5e@oracle.com>
References: <893691684840844@xzgj7besbn6v2djj.myt.yp-c.yandex.net>
 <c4954b0c-ca2a-7cb1-4710-36af333e7d06@oracle.com>
 <59b1c6ff-ab08-8a8f-12b7-21f78285571b@oracle.com>
 <1813541396.62977656.1684881306040.JavaMail.zimbra@univ-eiffel.fr>
 <2cf71b1c-7ac1-e158-1c80-762caa3e6e82@oracle.com>
 <36c13724-9c08-c082-67ab-fa24773314ec@oracle.com>
 <22412a94-1d04-fb01-d309-870a55328a41@oracle.com>
 <3280f8e4-0f07-598c-f6e7-32c081da2c5e@oracle.com>
Message-ID: <b76a1089-8032-dabe-9caa-64bce357a7ed@oracle.com>

My bad.

In the modifications of the original code, I proposed to replace

     URL classFileB = 
TestLoading.class.getResource(TestLoading.class.getSimpleName() + 
"$ChildClass.class");

with

     URL classFileB = 
TestLoading.class.getResource(ChildClass.class.getSimpleName() + ".class");

However, this loads ChildClass just a few lines *before* it is removed 
from the filesystem, so later uses of the class in the same run, in 
particular during verification of method BaseClassReturner.getObject(), 
are immune to the removal.

Replacing with

     URL classFileB = 
TestLoading.class.getResource(TestLoading.class.getPackageName() + 
"ChildClass.class");

will remove the class without loading it, and will later throw, as in 
the original setup.


Sorry for the noise
Raffaello



On 2023-05-26 08:10, David Holmes wrote:
> On 25/05/2023 7:21 pm, Raffaello Giulietti wrote:
>>
>> Yes, ChildClass.class is removed from the filesystem.
>>
>>
>> And here's, the relevant info when running with -Xlog:class+init, 
>> showing that verification succeeds for both TestLoading$ObjectReturner 
>> and TestLoading$BaseClassReturner:
>>
>> loading: TestLoading$ObjectReturner...
>> [0.039s][info][class,init] Start class verification for: 
>> TestLoading$ObjectReturner
>> [0.039s][info][class,init] End class verification for: 
>> TestLoading$ObjectReturner
>> [0.039s][info][class,init] 500 Initializing 
>> 'TestLoading$ObjectReturner'(no method) (0x0000000801001800)
>> loading: TestLoading$BaseClassReturner...
>> [0.039s][info][class,init] Start class verification for: 
>> TestLoading$BaseClassReturner
>> [0.039s][info][class,init] End class verification for: 
>> TestLoading$BaseClassReturner
>> [0.039s][info][class,init] 501 Initializing 
>> 'TestLoading$BaseClassReturner'(no method) (0x0000000801001a08)
> 
> Can you enable -xlog:verification and class+load too please.
> 
> Thanks,
> David
> -----
> 
>>
>>
>>
>> On 2023-05-25 04:57, David Holmes wrote:
>>> On 25/05/2023 12:34 am, Raffaello Giulietti wrote:
>>>> As mentioned in my previous email, if you move the member class 
>>>> ChildClass out of TestLoading (out of the nest), and make it a 
>>>> top-level class like
>>>>
>>>> ???? public class ChildClass extends TestLoading.BaseClass {
>>>> ???? }
>>>>
>>>> and change
>>>>
>>>> ???? URL classFileB = 
>>>> TestLoading.class.getResource(TestLoading.class.getSimpleName() + 
>>>> "$ChildClass.class");
>>>>
>>>> to
>>>>
>>>> ???? URL classFileB = 
>>>> TestLoading.class.getResource(ChildClass.class.getSimpleName() + 
>>>> ".class");
>>>>
>>>> rebuild everything and run, nothing is thrown.
>>>>
>>>> ???? deleting: <path-to>/ChildClass.class
>>>> ???? loading: TestLoading$ObjectReturner...
>>>> ???? loading: TestLoading$BaseClassReturner...
>>>>
>>>> I can't see any substantial difference, except that the nest rooted 
>>>> at TestLoading lacks a member in the original setup and lacks 
>>>> nothing in this setup.
>>>>
>>>> What's an explanation for this difference?
>>>
>>> Are you sure it actually deletes the file? What do you see when you 
>>> enable class+load/init and verification logging?
>>>
>>> David
>>> -----
>>>
>>>
>>>
>>>>
>>>> Greetings
>>>> Raffaello
>>>>
>>>>
>>>> On 2023-05-24 00:35, Remi Forax wrote:
>>>>>
>>>>>
>>>>> ----- Original Message -----
>>>>>> From: "David Holmes" <david.holmes at oracle.com>
>>>>>> To: "Raffaello Giulietti" <raffaello.giulietti at oracle.com>, 
>>>>>> "core-libs-dev" <core-libs-dev at openjdk.org>
>>>>>> Sent: Wednesday, May 24, 2023 12:23:24 AM
>>>>>> Subject: Re: Classes used in method body are loaded lazily or 
>>>>>> eagerly depending on method return type
>>>>>
>>>>>> On 24/05/2023 12:50 am, Raffaello Giulietti wrote:
>>>>>>> I think the problem here is that you are deleting a class in a nest.
>>>>>>>
>>>>>>> During the verification of BaseClassReturner.getObject(), access 
>>>>>>> control
>>>>>>> (JVMS, 5.4.4, second half) determines that the nest is broken, as
>>>>>>> ChildClass is not present anymore.
>>>>>>
>>>>>> Not sure access control gets involved at this stage of the 
>>>>>> verification
>>>>>> process. But in any case turning on logging does not show anything
>>>>>> related to nestmates happening between BaseClass and ChildClass. It
>>>>>> seems to just be the resolution of the return type during 
>>>>>> verification
>>>>>> of the method, that causes the loading of ChildClass and the 
>>>>>> subsequent
>>>>>> CNFE if it has been removed.
>>>>>>
>>>>>>> If you move ChildClass out of TestLoading so that it becomes a 
>>>>>>> top-level
>>>>>>> class extending TestLoading.BaseClass, and if you adapt the line 
>>>>>>> that
>>>>>>> initializes the local var classFileB to refer to the new 
>>>>>>> location, the
>>>>>>> code will not throw, despite ChildClass being deleted.
>>>>>>
>>>>>> My simplified test shows it still throws when verifying 
>>>>>> BaseClassReturner.
>>>>>
>>>>> Nestmate checking is done lazily, so if you do not call a 
>>>>> method/access a field of a nested class, the VM should not trigger 
>>>>> a class loading.
>>>>>
>>>>> Moreover, if you test with Java 8 (nestmates were introduced in 
>>>>> Java 11), it failed too.
>>>>> That's another clue that the error is not related to nestmates 
>>>>> checking.
>>>>>
>>>>>>
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>
>>>>> regards,
>>>>> R?mi
>>>>>
>>>>>>
>>>>>>>
>>>>>>> Greetings
>>>>>>> Raffaello
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 2023-05-23 13:20, ?????? ??????? wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> originally this question was asked here:
>>>>>>>> https://urldefense.com/v3/__https://stackoverflow.com/q/76260269/12473843__;!!ACWV5N9M2RV99hQ!Mb5nhj7EbuftWzF7s4GX9auUZZlyPyCUnLs64c4mkmSGJm4pw0CNgRzQR5wOYuApyE_kHSAnVxGyTM9PHz5StCppGw$ ,
>>>>>>>> the code sample for reproduction will be put below or can be 
>>>>>>>> found via
>>>>>>>> the link
>>>>>>>>
>>>>>>>> The issue is about eager/lazy loading of a class depending on 
>>>>>>>> method
>>>>>>>> return type.
>>>>>>>> If one runs the code below with Java 11-19 it will fail with
>>>>>>>> NoClassDefFoundError (this is expected as delete class file for
>>>>>>>> ChildClass):
>>>>>>>>
>>>>>>>> java.lang.NoClassDefFoundError: org/example/TestLoading$ChildClass
>>>>>>>> ?????at java.base/java.lang.Class.forName0(Native Method)
>>>>>>>> ?????at java.base/java.lang.Class.forName(Class.java:390)
>>>>>>>> ?????at java.base/java.lang.Class.forName(Class.java:381)
>>>>>>>> ?????at org.example.TestLoading.loadMyClass(TestLoading.java:29)
>>>>>>>> ?????at org.example.TestLoading.main(TestLoading.java:23)
>>>>>>>> Caused by: java.lang.ClassNotFoundException:
>>>>>>>> org.example.TestLoading$ChildClass
>>>>>>>> ?????at
>>>>>>>> java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
>>>>>>>> ?????at
>>>>>>>> java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
>>>>>>>> ?????at 
>>>>>>>> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:521)
>>>>>>>> ?????... 5 more
>>>>>>>>
>>>>>>>> As of Java 20 chapter 12.4.1 of JLS states:
>>>>>>>> ---------------------------------------------------------
>>>>>>>> A class or interface T will be initialized immediately before the
>>>>>>>> first occurrence of any one of the following:
>>>>>>>>
>>>>>>>> - T is a class and an instance of T is created.
>>>>>>>> - a static method declared by T is invoked.
>>>>>>>> - a static field declared by T is assigned.
>>>>>>>> - a static field declared by T is used and the field is not a 
>>>>>>>> constant
>>>>>>>> variable (?4.12.4).
>>>>>>>>
>>>>>>>> When a class is initialized, its superclasses are initialized 
>>>>>>>> (if they
>>>>>>>> have not been previously initialized), as well as any 
>>>>>>>> superinterfaces
>>>>>>>> (?8.1.5) that declare any default methods (?9.4.3) (if they have 
>>>>>>>> not
>>>>>>>> been previously initialized).
>>>>>>>> Initialization of an interface does not, of itself, cause
>>>>>>>> initialization of any of its superinterfaces.
>>>>>>>> A reference to a static field (?8.3.1.1) causes initialization 
>>>>>>>> of only
>>>>>>>> the class or interface that actually declares it, even though it 
>>>>>>>> might
>>>>>>>> be referred to through the name of a subclass, a subinterface, or a
>>>>>>>> class that implements an interface.
>>>>>>>> Invocation of certain reflective methods in class Class and in 
>>>>>>>> package
>>>>>>>> java.lang.reflect also causes class or interface initialization.
>>>>>>>> A class or interface will not be initialized under any other
>>>>>>>> circumstance.
>>>>>>>> ---------------------------------------------------------
>>>>>>>> With the code snippet we see that calling
>>>>>>>> Class.forName(ObjectReturner.class.getName()) succeeds and
>>>>>>>> Class.forName(BaseClassReturner.class.getName()) fails even though
>>>>>>>> both declare returning an instance of ChildClass.
>>>>>>>> This failure is unexpected as in the code below we don't fulfill 
>>>>>>>> any
>>>>>>>> requirement for class loading as of JLS 12.4.1, but the JVM still
>>>>>>>> tries to load the class.
>>>>>>>>
>>>>>>>> I suspect it might be related to class file validation and/or
>>>>>>>> security, because when we run the code with -Xlog:class+init 
>>>>>>>> there's a
>>>>>>>> reference to LinkageError in loading log:
>>>>>>>>
>>>>>>>> loading: org.example.TestLoading$BaseClassReturner...
>>>>>>>> [0.277s][info][class,init] Start class verification for:
>>>>>>>> org.example.TestLoading$BaseClassReturner
>>>>>>>> [0.277s][info][class,init] 771 Initializing
>>>>>>>> 'java/lang/ReflectiveOperationException'(no method) 
>>>>>>>> (0x0000000800004028)
>>>>>>>> [0.277s][info][class,init] 772 Initializing
>>>>>>>> 'java/lang/ClassNotFoundException'(no method) (0x0000000800004288)
>>>>>>>> [0.277s][info][class,init] 773 Initializing
>>>>>>>> 'java/lang/LinkageError'(no method)
>>>>>>>> (0x00000008000044f8)????????????????????????????????? <----
>>>>>>>> [0.277s][info][class,init] 774 Initializing
>>>>>>>> 'java/lang/NoClassDefFoundError'(no method) (0x0000000800004758)
>>>>>>>> [0.277s][info][class,init] Verification for
>>>>>>>> org.example.TestLoading$BaseClassReturner has exception pending
>>>>>>>> 'java.lang.NoClassDefFoundError org/example/TestLoading$ChildClass'
>>>>>>>> [0.277s][info][class,init] End class verification for:
>>>>>>>> org.example.TestLoading$BaseClassReturner
>>>>>>>>
>>>>>>>>
>>>>>>>> So I've got three questions about this:
>>>>>>>> - Does class loading depend on method's return type?
>>>>>>>> - Which part of JLS/JVM spec describes eager class loading in 
>>>>>>>> this case?
>>>>>>>> - Could one point out the particular piece of the VM code 
>>>>>>>> responsible
>>>>>>>> for class loading in this case?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Sergey Tsypanov
>>>>>>>>
>>>>>>>> Code snippet for reproduction:
>>>>>>>>
>>>>>>>> public class TestLoading {
>>>>>>>>
>>>>>>>> ??? public static void main(String[] args) throws Exception {
>>>>>>>> ????? Class.forName(BaseClass.class.getName());
>>>>>>>> ????? URL classFileB =
>>>>>>>> TestLoading.class.getResource(TestLoading.class.getSimpleName() +
>>>>>>>> "$ChildClass.class");
>>>>>>>> ????? if (classFileB != null) {
>>>>>>>> ??????? if (!"file".equals(classFileB.getProtocol())) {
>>>>>>>> ????????? throw new UnsupportedOperationException();
>>>>>>>> ??????? }
>>>>>>>> ??????? Path path = new File(classFileB.getPath()).toPath();
>>>>>>>> ??????? System.out.println("deleting: " + path);
>>>>>>>> ??????? Files.delete(path);
>>>>>>>> ????? }
>>>>>>>>
>>>>>>>> ????? loadMyClass(ObjectReturner.class.getName());
>>>>>>>> ????? loadMyClass(BaseClassReturner.class.getName());
>>>>>>>> ??? }
>>>>>>>>
>>>>>>>> ??? private static void loadMyClass(String name) {
>>>>>>>> ????? System.out.println("loading: " + name + "...");
>>>>>>>> ????? try {
>>>>>>>> ??????? Class.forName(name);
>>>>>>>> ????? } catch (Throwable e) {
>>>>>>>> ??????? e.printStackTrace(System.out);
>>>>>>>> ????? }
>>>>>>>> ??? }
>>>>>>>>
>>>>>>>> ??? public static class BaseClass {
>>>>>>>> ??? }
>>>>>>>>
>>>>>>>> ??? public static class ChildClass extends BaseClass {
>>>>>>>> ??? }
>>>>>>>>
>>>>>>>> ??? public static class ObjectReturner {
>>>>>>>> ????? public Object getObject() {
>>>>>>>> ??????? return new ChildClass();
>>>>>>>> ????? }
>>>>>>>> ??? }
>>>>>>>>
>>>>>>>> ??? public static class BaseClassReturner {
>>>>>>>> ????? public BaseClass getObject() {
>>>>>>>> ??????? return new ChildClass();
>>>>>>>> ????? }
>>>>>>>> ??? }
>>>>>>>> }

From mcimadamore at openjdk.org  Fri May 26 18:11:14 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 26 May 2023 18:11:14 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v3]
In-Reply-To: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
Message-ID: <g1HwuTYOcOUiOG0XNXLxk-pEglO0lPEWXZoGVfzwTto=.2f176104-bf6a-4003-8a02-715cc978647c@github.com>

> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
> 
> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
> 
> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
> 
> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
> 
> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
> 
> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
> 
> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
> 
> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
> 
> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can throw because of an ...

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Improve javadoc on supported linker layouts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14098/files
  - new: https://git.openjdk.org/jdk/pull/14098/files/df6c1239..6703eee9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14098&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14098&range=01-02

  Stats: 69 lines in 3 files changed: 45 ins; 3 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/14098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14098/head:pull/14098

PR: https://git.openjdk.org/jdk/pull/14098

From mcimadamore at openjdk.org  Fri May 26 18:11:30 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 26 May 2023 18:11:30 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v2]
In-Reply-To: <kz9NItuQM63bAaPRJIoX2Fgr-PLQNMkmpfTRGuVmiL4=.fec4c54d-e997-46b7-bab7-77a2f1e132df@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <kz9NItuQM63bAaPRJIoX2Fgr-PLQNMkmpfTRGuVmiL4=.fec4c54d-e997-46b7-bab7-77a2f1e132df@github.com>
Message-ID: <KPoMPR5DUeDrO4Wxez-ZQalYDGPwhPnezOGS4h7PjTU=.2f8cb144-7cef-4551-9dba-47b6e979f0ef@github.com>

On Thu, 25 May 2023 15:31:43 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
>> 
>> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
>> 
>> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
>> 
>> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
>> 
>> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
>> 
>> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
>> 
>> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
>> 
>> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
>> 
>> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can th...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tweak javadoc of MemorySegment::get/setUtf8String to deal with overflow

I brought over some javadoc improvements from https://github.com/openjdk/jdk/pull/14037 (which has been withdrawn). These improvements should allow us to enable support for Linker in x86 platforms, as they define the notion of "what is a linker supported layout" much more precisely, and in a way that is not dependent on natural alignment (for value layouts).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14098#issuecomment-1564747719

From mchung at openjdk.org  Fri May 26 19:02:11 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 May 2023 19:02:11 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
Message-ID: <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>

On Sun, 7 May 2023 13:34:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As John Rose has pointed out in this issue, the current j.l.r.Proxy based implementation of MethodHandleProxies.asInterface has a few issues:
>> 1. Exposes too much information via Proxy supertype (and WrapperInstance interface)
>> 2. Does not allow future expansion to support SAM[^1] abstract classes
>> 3. Slow (in fact, very slow)
>> 
>> This patch addresses all 3 problems:
>> 1. It updates the WrapperInstance methods to take an `Empty` to avoid method clashes
>> 2. This patch obtains already generated classes from a ClassValue by the requested interface type; the ClassValue can later be updated to compute implementation generation for abstract classes as well.
>> 3. This patch's faster than old implementation in general.
>> 
>> 
>> Benchmark                                                          Mode  Cnt      Score      Error  Units
>> MethodHandleProxiesAsIFInstance.baselineAllocCompute               avgt   15      1.483 ?    0.025  ns/op
>> MethodHandleProxiesAsIFInstance.baselineCompute                    avgt   15      0.264 ?    0.006  ns/op
>> MethodHandleProxiesAsIFInstance.testCall                           avgt   15      1.773 ?    0.040  ns/op
>> MethodHandleProxiesAsIFInstance.testCreate                         avgt   15     16.754 ?    0.411  ns/op
>> MethodHandleProxiesAsIFInstance.testCreateCall                     avgt   15     19.609 ?    1.598  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callDoable                     avgt   15      0.424 ?    0.024  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callHandle                     avgt   15      1.936 ?    0.008  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callInterfaceInstance          avgt   15      1.766 ?    0.014  ns/op
>> MethodHandleProxiesAsIFInstanceCall.callLambda                     avgt   15      0.414 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantDoable                 avgt   15      0.271 ?    0.006  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantHandle                 avgt   15      0.263 ?    0.004  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantInterfaceInstance      avgt   15      0.266 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCall.constantLambda                 avgt   15      0.262 ?    0.003  ns/op
>> MethodHandleProxiesAsIFInstanceCall.direct                         avgt   15      0.264 ?    0.005  ns/op
>> MethodHandleProxiesAsIFInstanceCreate.createCallInterfaceInstance  avgt   15     18.000 ?    0.181  ns/op
>> MethodHandleProxiesAsIFInstanceCreat...
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove assertion, no longer true with teleport definition in MHP

src/hotspot/share/prims/jvm.cpp line 1019:

> 1017:     }
> 1018:   }
> 1019:   assert(Reflection::is_same_class_package(lookup_k, ik),

I use the Lookup of the proxy interface to define a hidden class in a dynamic module as the dynamic module has no class yet and it's defined to the class loader of the proxy interface. 

We should keep the same package check if the defined class is a normal class or a hidden nestmate class.   It only allows the lookup class be in a different package for defining a hidden non-nestmate class.   This is only internal capability.    `Lookup::defineHiddenClass` API will throw IAE if the given bytes denotes a class in a different package than the lookup class.


+  if ((!is_hidden || is_nestmate) && !Reflection::is_same_class_package(lookup_k, ik)) { 
+    // non-hidden class or nestmate class must be in the same package as the Lookup class
+    THROW_MSG_0(vmSymbols::java_lang_IllegalArgumentException(), "Lookup class and defined class are in different packages");
+  }
+

src/java.base/share/classes/java/lang/ClassLoader.java line 685:

> 683:         final SecurityManager sm = System.getSecurityManager();
> 684:         if (sm != null) {
> 685:             if (ReflectUtil.isNonPublicProxyClass(cls) || ReflectUtil.isMethodHandleProxiesClass(cls)) {

Why do you need this?   `Proxy` allows non-public interface whereas `MethodHandleProxies` only allows public interface.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 209:

> 207:         if (intfc.isHidden())
> 208:             throw newIllegalArgumentException("a hidden interface", intfc.getName());
> 209:         if (!VM.isModuleSystemInited())

I don't expect this is needed.  I assume you are thinking for LMF to use this API?

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 245:

> 243:     private record LocalMethodInfo(MethodTypeDesc desc, List<ClassDesc> thrown, String fieldName) {}
> 244: 
> 245:     private record ProxyClassInfo(MethodHandle constructor, Lookup originalLookup) {}

`ProxyClassInfo` for interface `I` will be stored in the class value of `I`.  Hence it keeps a strong reference to the generated proxy class for `I` until `I` is unloaded.  The hidden class implicitly becomes a strong link to the defining class loader.    Need to look into keeping it in a weak reference to allow the hidden class to be unloaded independent of the lifetime of the class loader.

src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 433:

> 431: 
> 432:     private static WrapperInstance asWrapperInstance(Object x) {
> 433:         if (x instanceof WrapperInstance wrapperInstance)

In the previous version, `WrapperInstance` was not needed.  Instead it checks if the class is a  MHProxy class.   Did you run into any issue that you resurrect `WrapperInstance`?    Is it just because of accessing `ensureOriginalLookup`?

test/jdk/java/lang/reflect/Proxy/ProxyForMethodHandle.java line 42:

> 40:  * @run testng ProxyForMethodHandle
> 41:  */
> 42: public class ProxyForMethodHandle {

This test seems to be useful.   Can this be modified and moved to `test/jdk/java/lang/invoke/MethodHandleProxies`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207189226
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207185214
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207191315
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207194444
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207208803
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207190411

From rriggs at openjdk.org  Fri May 26 19:07:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 May 2023 19:07:03 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v7]
In-Reply-To: <R6DVMij5x0AMpm-QIduWF1NnfmpP86FDRkXaZ2474Ms=.85ac8e8a-3d29-4c57-baa9-4e8e830dad5d@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <R6DVMij5x0AMpm-QIduWF1NnfmpP86FDRkXaZ2474Ms=.85ac8e8a-3d29-4c57-baa9-4e8e830dad5d@github.com>
Message-ID: <CQFhyfQnZWBprzk4RYqHjB7Yb7EdHd49qirD8ySMakY=.c99444fb-ccf6-4f47-b012-940be3202b3d@github.com>

On Thu, 25 May 2023 15:25:40 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for failing CloseRace test

Shaping up nicely, thanks for the careful attention to detail.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13956#pullrequestreview-1446800955

From rriggs at openjdk.org  Fri May 26 19:19:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 May 2023 19:19:56 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v2]
In-Reply-To: <gkzuZHq5qLPSPiSVqPwyclOWkoyd32ZjKuQ8dAgsnoI=.69065735-0c46-4cd1-b7d0-37dc5e1acbe8@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
 <gkzuZHq5qLPSPiSVqPwyclOWkoyd32ZjKuQ8dAgsnoI=.69065735-0c46-4cd1-b7d0-37dc5e1acbe8@github.com>
Message-ID: <vEHWFv7pkeTCVacARsDQPYRMgQ7jHplO2kHJEXugUSs=.2b32e6fa-2195-4fac-8c0e-ff1345044f7a@github.com>

On Wed, 24 May 2023 16:26:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review suggestions
>
> src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 140:
> 
>> 138:      */
>> 139:     /* package-private */
>> 140:     static String toUpperCase(String str) {
> 
> A bit icky to have OperatingSystem to expose a static method to convert Strings as it's nothing to do with OperatingSystem, is there anywhere else?

Delaying the initialization of OperatingSystem made it possible to revert to String.toUpperCase(). 
Enabled by the fix in PR [14181](https://github.com/openjdk/jdk/pull/14181).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14063#discussion_r1207228241

From duke at openjdk.org  Fri May 26 19:28:58 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 26 May 2023 19:28:58 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v3]
In-Reply-To: <g1HwuTYOcOUiOG0XNXLxk-pEglO0lPEWXZoGVfzwTto=.2f176104-bf6a-4003-8a02-715cc978647c@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
 <g1HwuTYOcOUiOG0XNXLxk-pEglO0lPEWXZoGVfzwTto=.2f176104-bf6a-4003-8a02-715cc978647c@github.com>
Message-ID: <w7piztMCaFXFMiW1W05MZ9KE2ay5IYEs6sZSBI8JWLY=.eb930641-330d-4b39-83ef-037c5b7d2d2b@github.com>

On Fri, 26 May 2023 18:11:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
>> 
>> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
>> 
>> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
>> 
>> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
>> 
>> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
>> 
>> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
>> 
>> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
>> 
>> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
>> 
>> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can th...
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve javadoc on supported linker layouts

src/java.base/share/classes/java/lang/foreign/MemoryLayout.java line 187:

> 185:  *                         ).withName("point")
> 186: *                   )
> 187: *          ).withName("points")

Wrong?indentation:
Suggestion:

 *                 )
 *         ).withName("points")

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14098#discussion_r1207238878

From duke at openjdk.org  Fri May 26 19:50:00 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 26 May 2023 19:50:00 GMT
Subject: RFR: 8291065: Creating a VarHandle for a static field triggers
 class initialization [v3]
In-Reply-To: <LvTHTEI6f2wcPaMklu_WZedfqnUqWX_ij9iG_y10sfE=.ed10c1d5-c391-4fc0-8ed2-631ce508d5f4@github.com>
References: <xaWHpNXbFsTbtwjAoa8t3dxW89EPDhZNMLpQwqxb-mo=.7c5dd90f-046a-47bd-bfc1-244b88e60d9c@github.com>
 <LvTHTEI6f2wcPaMklu_WZedfqnUqWX_ij9iG_y10sfE=.ed10c1d5-c391-4fc0-8ed2-631ce508d5f4@github.com>
Message-ID: <IyyDAJBTHnU1qOVB3s78woq-ffHCk-4N1hMeUMWZRvI=.e39cd1ac-4714-4458-bb86-ff019731b1d1@github.com>

On Wed, 17 May 2023 17:20:37 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Also fixed the bug with NPE in `IndirectVarHandle::isAccessModeSupported`.
>> 
>> A few implementation-detail methods in VarHandle are now documented with the implied constraints to avoid subtle problems in the future. Changed `IndirectVarHandle` to call `asDirect` lazily to accomodate the lazy VarHandle changes. Also changed VarHandleBaseTest to report the whole incorrect type of exception caught than swallow it and leaving only a message.
>> 
>> Current problems:
>> - [ ] The lazy var handle is quite slow on the first invocation.
>>    - As seen in the benchmark, users can first call `Lookup::ensureInitialized` to create an eager handle.
>>    - After that, the lazy handle has a performance on par with the regular var handle.
>> - [ ] The class-loading-based test is not in a unit test
>>    - The test frameworks don't seem to offer fine-grained control for class-loading detection or reliable unloading
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> VarHandleLazyStaticInvocation.initializedInvocation  avgt   30       0.769 ?      0.003  ns/op
>> VarHandleLazyStaticInvocation.lazyInvocation         avgt   30       0.767 ?      0.002  ns/op
>> 
>> 
>> Benchmark                                            Mode  Cnt       Score        Error  Units
>> LazyStaticColdStart.methodHandleCreateEager            ss   10   73140.100 ?   7735.276  ns/op
>> LazyStaticColdStart.methodHandleCreateLazy             ss   10   50000.000 ?   8482.883  ns/op
>> LazyStaticColdStart.methodHandleInitializeCallEager    ss   10   91350.100 ?   9776.343  ns/op
>> LazyStaticColdStart.methodHandleInitializeCallLazy     ss   10  145540.200 ?  72894.865  ns/op
>> LazyStaticColdStart.varHandleCreateEager               ss   10   47069.900 ?   3513.909  ns/op
>> LazyStaticColdStart.varHandleCreateLazy                ss   10   24780.300 ?   5144.540  ns/op
>> LazyStaticColdStart.varHandleInitializeCallEager       ss   10   85479.700 ?  10816.983  ns/op
>> LazyStaticColdStart.varHandleInitializeCallLazy        ss   10  413630.100 ? 189370.448  ns/op
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Remove export for removed package
>  - Merge branch 'master' into lazy-static-varhandle
>  - Test the creation performance of handles, lazy one indeed better
>  - Merge branch 'master' into lazy-static-varhandle
>  - copyright year
>  - Benchmarks. lazy initialize is SLOW
>  - nuke meaningless overrides
>  - make static field var handles lazy and fix NPE in isAccessModeSupported

src/java.base/share/classes/java/lang/invoke/VarHandles.java line 111:

> 109:         else {
> 110:             if (UNSAFE.shouldBeInitialized(refc)) {
> 111:                 return new LazyStaticVarHandle(refc, f, isWriteAllowedOnFinalFields, false);

This?should probably?call `maybeAdapt` on?the?result:
Suggestion:

                return maybeAdapt(new LazyStaticVarHandle(refc, f, isWriteAllowedOnFinalFields, false));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13821#discussion_r1207261501

From duke at openjdk.org  Fri May 26 19:54:08 2023
From: duke at openjdk.org (Rudi Horn)
Date: Fri, 26 May 2023 19:54:08 GMT
Subject: RFR: 8308748: JNU_GetStringPlatformChars may write to String's
 internal memory array
In-Reply-To: <TaV2tvpuANCahtox0mgOs7h0xP4st-gjMnmwICu1aKg=.cbaee55f-4cde-4ff4-a708-ad394ee30038@github.com>
References: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>
 <TaV2tvpuANCahtox0mgOs7h0xP4st-gjMnmwICu1aKg=.cbaee55f-4cde-4ff4-a708-ad394ee30038@github.com>
Message-ID: <VknjfMa2PR8NIa8BhFJ5hmgk7N04haqPILeD_tsqOno=.c38fb726-0b67-414e-982f-b6b902c50079@github.com>

On Fri, 26 May 2023 17:36:12 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> There was an unrelated change to these functions recently. You might want to rebase this PR with the latest version.

Done

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14117#issuecomment-1564855730

From duke at openjdk.org  Fri May 26 19:54:07 2023
From: duke at openjdk.org (Rudi Horn)
Date: Fri, 26 May 2023 19:54:07 GMT
Subject: RFR: 8308748: JNU_GetStringPlatformChars may write to String's
 internal memory array [v2]
In-Reply-To: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>
References: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>
Message-ID: <z-Sp5itXRBV0S__vZF5OAzZR5W-l3lo2B8u2j-oaYKs=.77813e70-66d9-4080-9448-63b1f19ebbe7@github.com>

> This change prevents the contents of the internal string array from being copied back when releasing it.

Rudi Horn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Use JNI_ABORT to release string bytes

-------------

Changes: https://git.openjdk.org/jdk/pull/14117/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14117&range=01
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14117.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14117/head:pull/14117

PR: https://git.openjdk.org/jdk/pull/14117

From jiangli at openjdk.org  Fri May 26 20:28:55 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 26 May 2023 20:28:55 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v4]
In-Reply-To: <nyP_xGJqxSRrMGArbCqN03qRaifxETOgcdzElL_0MGw=.e3d3e454-393a-49e6-a0fc-2473189f4424@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <jxHZW_q3pnBv97sb2lqcruvtD_kuG6igXAZ464K7O5o=.a2fccf9f-bd66-40b3-92b6-60d5d0031cf6@github.com>
 <p_r1k3hlvlctwZhBEWlFkfpEnmAuApkrnFNI0Sji31g=.8f3387c1-2e17-4549-a29e-098a33d65b0f@github.com>
 <qfkQzYgNBOnStqE05kKv9PPKsJrPQg20EVHf9upNhB0=.a2baf9de-620a-4b8d-9141-18197edb98c3@github.com>
 <De483G2Bvse6UB0b1PcuEDjX7Er_D0HYfQa8U3Ln9dQ=.8800cca1-748d-43f2-bafc-419a64643d77@github.com>
 <nyP_xGJqxSRrMGArbCqN03qRaifxETOgcdzElL_0MGw=.e3d3e454-393a-49e6-a0fc-2473189f4424@github.com>
Message-ID: <U3pG9DQ5y_HDljrZG8SaA6s1Ho7W94wiTJu3Yzdgu2s=.0d3c3578-631c-422a-a26c-be46f7592bc6@github.com>

On Thu, 25 May 2023 01:19:11 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > > > My build job is still running, but it has failed in two distinct ways already. See below for mac fix. Our cross build of arm32 fails with this message:
> > > > ```
> > > > [2023-05-24T19:25:15,310Z] /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/bin/ld: fatal error: cannot mix -r with dynamic object /opt/mach5/mesos/work_dir/jib-master/install/jpg/infra/builddeps/devkit-linux_x64-to-linux_arm/gcc8.2.0-Fedora27+1.0/devkit-linux_x64-to-linux_arm-gcc8.2.0-Fedora27+1.0.tar.gz/x86_64-linux-gnu-to-arm-linux-gnueabihf/bin/../lib/gcc/arm-linux-gnueabihf/8.2.0/../../../../arm-linux-gnueabihf/lib/libstdc++.so
> > > > ```
> > > 
> > > 
> > > If this is a problem with your partial link solution, then perhaps just employing the relative path trick for the `ar` command line on mac could be enough to handle long paths and lots of object files? That appears to be how we handle it with clang for linking already due to @-file problems.
> > 
> > 
> > The partial linking was originally suggested by C++/Clang toolchain folks to mitigate linker overhead that was observed during final executable link time. For a static library containing any object file (`.o`) that was compiled with ThinLTO (https://clang.llvm.org/docs/ThinLTO.html) enabled, linking an executable using the static library without distributed ThinLTO could experience more overhead and slow down linking. Solving the macosx `ar` limitation is a side-effect/benefit of using partial linking. We probably would want to include the partial linking even without the `ar` limitation.
> > Is it possible `$$($1_SYSROOT_LDFLAGS)` pulled in `libstdc++.so` as part of the input for partial linking with the linux-aarch64 cross build?
> 
> Another possibility might be the user provided `BUILD_LDCXX` includes extra options in the testing build (?). If that's the case, we probably could define a separate `BUILD_LD_PARTIAL` with no added options. In our prototype on JDK 11, we define a separate one for partial linking.

I tried building `static-libs-image` for linux-aarch64 on Ubuntu machine using `devkit` to reproduce the failure. Also tried building for `linux-ppc64le-server-release` target using `devkit` on Ubuntu. Both built successfully with using `devkit`. I could not build a `devkit` for arm32 (with `make TARGETS="arm-linux-gnueabihf" BASE_OS=Fedora BASE_OS_VERSION=17`, also tried with BASE_OS_VERSION=17). 

@erikj79 Could you please help provide additional insight for the build failure you found for arm32? `BUILD_LIBJVM_partial_link.cmdline` might help shed some light.

For the `aarch64-linux-gnu` build using `devkit`, I see following, which is ok. No unexpected options are included.


/.../bin/aarch64-linux-gnu-g++ -r --sysroot=/.../aarch64-linux-gnu/sysroot -o /...linux-aarch64-server-release/hotspot/variant-server/libjvm/objs/static/libjvm_relocatable.o @/.../hotspot/variant-server/libjvm/objs/static/_BUILD_LIBJVM_objectfilenames.txt

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1564908324

From mdoerr at openjdk.org  Fri May 26 20:29:54 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 26 May 2023 20:29:54 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <nA6t5xQ1QqQJ9UEwtTbAcG9P705u1cjmnmBrWCtbXq4=.1bed9538-5073-4649-bfd6-0f5734b0a967@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <Z6J__T8X9bDvrfFjUxNImPMEUwKQmbESvmzYUeDolkQ=.9309297e-ab60-4cd5-9a20-687d545101a8@github.com>
 <G0ZEvXBOXoDAbZOSj0zcDFxcADCi_Mk-hNOvsJiCw58=.443eb739-394c-44da-8e48-6b157ad59045@github.com>
 <nA6t5xQ1QqQJ9UEwtTbAcG9P705u1cjmnmBrWCtbXq4=.1bed9538-5073-4649-bfd6-0f5734b0a967@github.com>
Message-ID: <IZ4YR_xufzTDcXxB951WwGkcF4icFdEg-fwalgd59qA=.787de67a-2d85-4319-bf74-d73c2bafdf3d@github.com>

On Fri, 26 May 2023 16:58:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The crazy thing is that `malloc` is defined! That means all places where we use the term malloc are getting replaced without such a workaround. (E.g. for log tags.)
>
> So, we do this only for malloc? Not for calloc, posix_memalign, realloc etc? What about free? 
> 
> As ugly as defining malloc is (and I remember QADRT), I hesitate about removing that define.
> 
> Removing that define and hard-coding it here assumes 1) our replacement is equivalent (ok, easy to check) 2) it will always be equivalent in future AIX versions 3) pointers it returns work with the unchanged free() and realloc() the system provides, and will always do so.
> 
> I don't know... I would not do this just to get rid of a warning.

This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1207308708

From jiangli at openjdk.org  Fri May 26 20:39:57 2023
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 26 May 2023 20:39:57 GMT
Subject: RFR: 8307858: [REDO] JDK-8307194 Add make target for optionally
 building a complete set of all JDK and hotspot libjvm static libraries [v5]
In-Reply-To: <lGFitaAIrq_qUEjHdeqQHOgs14HPzDVuVa08CVOYovU=.c2108377-c67a-4411-8bbc-233e1ab236ca@github.com>
References: <lxCup28T6kHGN5JSmH-k_8NXGZqKVxNnZwtlVecIfL8=.eaf5071b-c86c-42c7-84da-b31e82ea6f79@github.com>
 <lGFitaAIrq_qUEjHdeqQHOgs14HPzDVuVa08CVOYovU=.c2108377-c67a-4411-8bbc-233e1ab236ca@github.com>
Message-ID: <jtBYV_fBSlM7i2aj0NkKgGgHaaLZoFRAcMBzmQaANXI=.36852394-9b02-4646-8dae-dd512c3c8188@github.com>

On Wed, 24 May 2023 21:02:00 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Original description for JDK-8307194 change:
>> -----
>> This PR is branched from the makefile changes for https://bugs.openjdk.org/browse/JDK-8303796 and contains the following for handling the JDK/hotspot static libraries:
>> 
>>  - Build hotspot libjvm.a and JDK static libraries for static-libs-image/static-libs-bundles targets; This change does not affect the graal-builder-image target
>> 
>>  - For libjvm.a specifically, exclude operator_new.o
>> 
>> - Filter out "external" .o files (those are the .o files included from a different JDK library and needed when creating the .so shared library only) from JDK .a libraries; That's to avoid linker failures caused by duplicate symbols
>>   - For libjli.a: Not include inflate.o inftrees.o inffast.o zadler32.o zcrc32.o zutil.o (compiled from zlib sources) if zlib is built as JDK bundled
>>   - For libawt_xawt.a and libawt_head.a: Not include systemScale.o, since it's provided in libawt.a
>> 
>> - Handle long arguments case for static build in make/common/NativeCompilation.gmk
>> 
>> - Address @erikj79's comment in https://github.com/openjdk/jdk/pull/13709#discussion_r1180750185 for LIBJLI_STATIC_EXCLUDE_OBJS
>> -----
>> 
>> Updates to address build failures reported on macosx-<cpu> platforms:
>> 
>> - For gcc/clang, when building a static library first partially link (using the `-r` linking option) all object files into one object. The output object file from the partial linking is then passed to `ar` to create the static library. 
>> 
>> The original change for JDK-8307194 used @argument_file for all platforms when dealing with long arguments to `ar`, which caused failures on macosx-<cpu> builds. On darwin (https://www.unix.com/man-page/osx/1/ar/), `ar` does not support @argument_file. The updated change avoids using @argument_file for `ar`.
>> 
>> The partial linking change is done in make/common/NativeCompilation.gmk. The flag related change is done in make/autoconf/flags-ldflags.m4 mainly.
>
> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update make/common/NativeCompilation.gmk
>   
>   Thanks you!
>   
>   Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com>

`with `make TARGETS="arm-linux-gnueabihf" BASE_OS=Fedora BASE_OS_VERSION=17`, also tried with BASE_OS_VERSION=17`

Fix typo: `also tried with BASE_OS_VERSION=18`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14064#issuecomment-1564919758

From mchung at openjdk.org  Fri May 26 20:43:58 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 May 2023 20:43:58 GMT
Subject: RFR: 8306889: Convert MethodTypeDescImpl parameter storage from
 array to immutable list [v4]
In-Reply-To: <vzn8QEVPvzZa3WqRyZWFQniQ3UjhiWFeJUjXb4Pguhc=.835afe67-b172-4647-8926-4081d02f050a@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
 <vzn8QEVPvzZa3WqRyZWFQniQ3UjhiWFeJUjXb4Pguhc=.835afe67-b172-4647-8926-4081d02f050a@github.com>
Message-ID: <AdHwQZAeklxWofiQtkzO43Vd4KxlrdWqZ2N-ZuqR79g=.b11da573-ba20-4fc4-9b41-1c0b7b6a4214@github.com>

On Wed, 24 May 2023 02:29:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch moves the parameters to an immutable list, to avoid allocations on `parameterList` as well. In addition, it fixes 8304932, the bug where if a caller keeps a reference to the array passed into `MethodTypeDesc.of`, the caller may mutate the Desc via the array and can create invalid MethodTypeDesc.
>> 
>> The latest benchmark results are available here: https://github.com/openjdk/jdk/pull/13186#issuecomment-1560378822
>> 
>> This patch has minor performance gains on `ofDescriptor` factory, even compared to Adam's patch that optimized `ofDescriptor` in #12945.
>> 
>> Benchmark of Oracle JDK 20: https://gist.github.com/683c6219e183cbc2b336224fc2c0d50a
>> Benchmark of this patch: https://gist.github.com/22be9371a2370fb4a7b44f1684750ec4
>> Benchmark of [asotona's patch](https://github.com/openjdk/jdk/pull/12945/files#diff-ac8e413d3e13532a2b0d34a90253c6ddd7a4f04082f792b9d076e9b5a33f2078): https://gist.github.com/eb98579c3b51cafae481049a95a78f80
>> 
>> [sotona vs this](https://jmh.morethan.io/?gists=eb98579c3b51cafae481049a95a78f80,22be9371a2370fb4a7b44f1684750ec4); [20 vs this](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,22be9371a2370fb4a7b44f1684750ec4); [20 vs sotona](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,eb98579c3b51cafae481049a95a78f80), for reference
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reuse immutable list to avoid array allocation

The microbenchmark shows the performance of using the `MethodTypeDesc` factory methods.  With [#13671](https://github.com/openjdk/jdk/pull/13671), `MethodTypeDesc` is cached and I wonder if this is no longer the bottleneck of ClassFile API performance.   

[JDK-8304932](https://bugs.openjdk.org/browse/JDK-8304932) is a bug that can simply be fixed by 

diff --git a/src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java b/src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java
index 738c4d68a43..ed23887c9ef 100644
--- a/src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java
+++ b/src/java.base/share/classes/java/lang/constant/MethodTypeDesc.java
@@ -95,7 +95,7 @@ public sealed interface MethodTypeDesc
      * {@link ClassDesc} for {@code void}
      */
     static MethodTypeDesc of(ClassDesc returnDesc, ClassDesc... paramDescs) {
-        return new MethodTypeDescImpl(returnDesc, paramDescs);
+        return new MethodTypeDescImpl(returnDesc, paramDescs.clone());
     }
 
     /**
diff --git a/src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java b/src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java
index 4341c3fb56f..8586bfb5926 100644
--- a/src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java
+++ b/src/java.base/share/classes/java/lang/constant/MethodTypeDescImpl.java
@@ -41,7 +41,7 @@ import static java.util.Objects.requireNonNull;
  */
 final class MethodTypeDescImpl implements MethodTypeDesc {
     private final ClassDesc returnType;
-    private final ClassDesc[] argTypes;
+    private final ClassDesc[] argTypes;     // trusted array
 
     /**
      * Constructs a {@linkplain MethodTypeDesc} with the specified return type
@@ -102,14 +102,14 @@ final class MethodTypeDescImpl implements MethodTypeDesc {
 
     @Override
     public MethodTypeDesc changeReturnType(ClassDesc returnType) {
-        return MethodTypeDesc.of(returnType, argTypes);
+        return new MethodTypeDescImpl(returnType, argTypes);
     }
 
     @Override
     public MethodTypeDesc changeParameterType(int index, ClassDesc paramType) {
         ClassDesc[] newArgs = argTypes.clone();
         newArgs[index] = paramType;
-        return MethodTypeDesc.of(returnType, newArgs);
+        return new MethodTypeDescImpl(returnType, newArgs);
     }
 
     @Override
@@ -120,7 +120,7 @@ final class MethodTypeDescImpl implements MethodTypeDesc {
         ClassDesc[] newArgs = new ClassDesc[argTypes.length - (end - start)];
         System.arraycopy(argTypes, 0, newArgs, 0, start);
         System.arraycopy(argTypes, end, newArgs, start, argTypes.length - end);
-        return MethodTypeDesc.of(returnType, newArgs);
+        return new MethodTypeDescImpl(returnType, newArgs);
     }
 
     @Override
@@ -131,7 +131,7 @@ final class MethodTypeDescImpl implements MethodTypeDesc {
         System.arraycopy(argTypes, 0, newArgs, 0, pos);
         System.arraycopy(paramTypes, 0, newArgs, pos, paramTypes.length);
         System.arraycopy(argTypes, pos, newArgs, pos+paramTypes.length, argTypes.length - pos);
-        return MethodTypeDesc.of(returnType, newArgs);
+        return new MethodTypeDescImpl(returnType, newArgs);
     }
 
```      

I won't object to keep `argTypes` in an immutable list instead of an array.  However, `MethodTypeDescImpl::ofDescriptor` has to build from the list of string parameters to an array or mutable list of parameter descriptors first anyway.  Other APIs to add/drop the parameter types also construct a new array/list of parameter types.   Keeping argTypes in a trusted array seems to be the simplest.    Converting `argTypes` to an immutable list seems to be an extra step to make it immutable - we need frozen arrays!!   

So I think we should only fix JDK-8304932.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13186#issuecomment-1564925561

From darcy at openjdk.org  Fri May 26 21:05:03 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 May 2023 21:05:03 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
Message-ID: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>

Explain in java.lang.Class how unnamed classes are modeled in core reflection.

-------------

Commit messages:
 - Cleanup and edit text.
 - Respond to review comments.
 - Appease jcheck.
 - JDK-8308913: Update core reflection for JEP 445 (preview)

Changes: https://git.openjdk.org/jdk/pull/14165/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14165&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308913
  Stats: 26 lines in 1 file changed: 25 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14165.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14165/head:pull/14165

PR: https://git.openjdk.org/jdk/pull/14165

From mchung at openjdk.org  Fri May 26 21:05:03 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 May 2023 21:05:03 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
In-Reply-To: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
Message-ID: <xYnXMWfvWBp2Roi-AAjQtZbJk2e2hl0eePc2Rj4fZZs=.a1703847-97cb-445b-9643-e1102c734d40@github.com>

On Fri, 26 May 2023 02:06:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Explain in java.lang.Class how unnamed classes are modeled in core reflection.

Looks fine.   This version matches the current implementation where `getCanonicalName` returns non-null.   When the implementation of `getCanonicalName` is updated to return null, the spec should be updated.

Nit: `<p>` is needed assuming the section of "Unnamed Classes" has 3 paragraphs.

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14165#pullrequestreview-1446650885

From darcy at openjdk.org  Fri May 26 21:05:04 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 May 2023 21:05:04 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
In-Reply-To: <xYnXMWfvWBp2Roi-AAjQtZbJk2e2hl0eePc2Rj4fZZs=.a1703847-97cb-445b-9643-e1102c734d40@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
 <xYnXMWfvWBp2Roi-AAjQtZbJk2e2hl0eePc2Rj4fZZs=.a1703847-97cb-445b-9643-e1102c734d40@github.com>
Message-ID: <0Iu5yZ8HNHtGFg-EzGL1ZHVrM36Z_V16SSX9Tf3lAJo=.6f800439-56d7-41ea-8a4b-14be4b6beffa@github.com>

On Fri, 26 May 2023 17:18:42 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Looks fine. This version matches the current implementation where `getCanonicalName` returns non-null. When the implementation of `getCanonicalName` is updated to return null, the spec should be updated.
> 
> Nit: `<p>` is needed assuming the section of "Unnamed Classes" has 3 paragraphs.

Thanks @mlchung.

Yes, the current spec matches what the implementation in @JimLaskey 's PR https://github.com/openjdk/jdk/pull/13689 does at the time of writing.

Discussions are on-going with the JEP 445 team regarding whether and how to implement a "isUnnamedClass" predicate for core reflection which would allow the `getCanonicalName` method to screen for unnamed classes and return null, as would reasonably be implied by a reading of the most current draft JLS updates.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14165#issuecomment-1564901806

From darcy at openjdk.org  Fri May 26 21:05:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 May 2023 21:05:05 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
In-Reply-To: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
Message-ID: <8Yl9LB0CtuI0st9nNAd6BiKgnP0Ef77mWU2smcLRmRA=.b030f3d2-f511-41b0-be47-2abd5e3fd369@github.com>

On Fri, 26 May 2023 02:06:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Explain in java.lang.Class how unnamed classes are modeled in core reflection.

> > Looks fine. This version matches the current implementation where `getCanonicalName` returns non-null. When the implementation of `getCanonicalName` is updated to return null, the spec should be updated.
> > Nit: `<p>` is needed assuming the section of "Unnamed Classes" has 3 paragraphs.
> 
> Thanks @mlchung.
> 
> Yes, the current spec matches what the implementation in @JimLaskey 's PR #13689 does at the time of writing.
> 
> Discussions are on-going with the JEP 445 team regarding whether and how to implement a "isUnnamedClass" predicate for core reflection which would allow the `getCanonicalName` method to screen for unnamed classes and return null, as would reasonably be implied by a reading of the most current draft JLS updates.

PS Depending on the result of those discussion, the specification for `getCanonicalName` may be changed to return `null`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14165#issuecomment-1564920419

From dholmes at openjdk.org  Fri May 26 21:05:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 26 May 2023 21:05:08 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
In-Reply-To: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
Message-ID: <8C9PWWOIC-1ZfZobolwStxwoPqjMGhejZLlSA9dzF6s=.0856baf8-317c-40c5-92e3-30da0d043961@github.com>

On Fri, 26 May 2023 02:06:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Explain in java.lang.Class how unnamed classes are modeled in core reflection.

src/java.base/share/classes/java/lang/Class.java line 192:

> 190:  * <h2><a id=unnamedClasses>Unnamed Classes</a></h2>
> 191:  *
> 192:  * The {@code class} file representing an unnnamed class is generated

Typo unnnamed (3 n's)

src/java.base/share/classes/java/lang/Class.java line 193:

> 191:  *
> 192:  * The {@code class} file representing an unnnamed class is generated
> 193:  * by a Java compiler from a source file from an unnamed class. The

"for an unnamed class." ?

src/java.base/share/classes/java/lang/Class.java line 196:

> 194:  * {@code Class} object representing an unnamed class is top-level,
> 195:  * {@linkplain #isSynthetic synthetic}, and {@code final}. While an
> 196:  * unnamed class does <em>not</em> have have a name in its Java source

typo: have have

src/java.base/share/classes/java/lang/Class.java line 201:

> 199:  * representing an unnamed class. Conventionally, a Java compiler
> 200:  * creates a class file where the class name matches the base name of
> 201:  * the class file; for example, a source file for an unnamed class

s/the class file;/the source file;/ ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1206160539
PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1206160610
PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1206160814
PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1206161235

From liach at openjdk.org  Fri May 26 21:09:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 May 2023 21:09:09 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
Message-ID: <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>

On Fri, 26 May 2023 18:39:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove assertion, no longer true with teleport definition in MHP
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 209:
> 
>> 207:         if (intfc.isHidden())
>> 208:             throw newIllegalArgumentException("a hidden interface", intfc.getName());
>> 209:         if (!VM.isModuleSystemInited())
> 
> I don't expect this is needed.  I assume you are thinking for LMF to use this API?

Proxy-based impl had this check, so I'd assume MHP might want to defend against the same kind of improper usage.

> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 433:
> 
>> 431: 
>> 432:     private static WrapperInstance asWrapperInstance(Object x) {
>> 433:         if (x instanceof WrapperInstance wrapperInstance)
> 
> In the previous version, `WrapperInstance` was not needed.  Instead it checks if the class is a  MHProxy class.   Did you run into any issue that you resurrect `WrapperInstance`?    Is it just because of accessing `ensureOriginalLookup`?

John Rose argues against using class data for Leyden. Since class data is the only known way to defend against user-manufactured annotations, I switched back to an extra wrapper interface. This approach also requires the Class loading checks since the interface is not unconditionally exported and fails security manager.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207350363
PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207349212

From mchung at openjdk.org  Fri May 26 21:26:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 May 2023 21:26:05 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
 <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
Message-ID: <NsNbY_G6Nb0x313vuzyiYg0ZLMz7wZc37zVBlw5XhVQ=.127f8d5b-5402-461b-b08e-0c1b4518fe0f@github.com>

On Fri, 26 May 2023 21:05:39 GMT, Chen Liang <liach at openjdk.org> wrote:

> This approach also requires the Class loading checks since the interface is not unconditionally exported and fails security manager.

Are you referring to `ClassLoader::checkPackageAccess` change?   As MHProxy implements `sun.invoke.WrapperInstance`, it needs to export `java.base/sun.invoke` to the dynamic module.    The change to `ClassLoader::checkPackageAccess` doesn't make sense for this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207376506

From liach at openjdk.org  Fri May 26 21:32:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 May 2023 21:32:09 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <NsNbY_G6Nb0x313vuzyiYg0ZLMz7wZc37zVBlw5XhVQ=.127f8d5b-5402-461b-b08e-0c1b4518fe0f@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
 <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
 <NsNbY_G6Nb0x313vuzyiYg0ZLMz7wZc37zVBlw5XhVQ=.127f8d5b-5402-461b-b08e-0c1b4518fe0f@github.com>
Message-ID: <98YBa_WBEwtCvYRDW5MGvaldIafXiTtF8NNtVntaDJ0=.0eb04101-f922-4ae8-b12b-1e8a926ec926@github.com>

On Fri, 26 May 2023 21:23:32 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> John Rose argues against using class data for Leyden. Since class data is the only known way to defend against user-manufactured annotations, I switched back to an extra wrapper interface. This approach also requires the Class loading checks since the interface is not unconditionally exported and fails security manager.
>
>> This approach also requires the Class loading checks since the interface is not unconditionally exported and fails security manager.
> 
> Are you referring to `ClassLoader::checkPackageAccess` change?   As MHProxy implements `sun.invoke.WrapperInstance`, it needs to export `java.base/sun.invoke` to the dynamic module.    The change to `ClassLoader::checkPackageAccess` doesn't make sense for this.

Yes. Unfortunately, it fails at https://github.com/openjdk/jdk/blob/bd21e68e679c41c98f39dd2fbd38270ae7d55ed9/src/java.base/share/classes/java/lang/SecurityManager.java#L1317 because a conditionally-exported package is considered a non-(unconditionally-)exported package.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207384208

From darcy at openjdk.org  Fri May 26 21:37:18 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 26 May 2023 21:37:18 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v22]
In-Reply-To: <fQnM3RKA8c6l_RX1shTn2H5gHDJEhRyqCNiINWxe97Q=.dd133e2a-904c-44b8-a9e8-baf9eadb9e75@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
 <fQnM3RKA8c6l_RX1shTn2H5gHDJEhRyqCNiINWxe97Q=.dd133e2a-904c-44b8-a9e8-baf9eadb9e75@github.com>
Message-ID: <Lo3jFDnzX76d9nUPEoxPjXeUGpu0GJlV6qzPeZ0TuFE=.70f9877c-8823-4cb7-91dc-0369c70d44bb@github.com>

On Fri, 26 May 2023 13:22:59 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Add flexible main methods and anonymous main classes to the Java language.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove trailing whitespace

In case I overlooked them, it would be good to have some core reflection tests of what a unnamed class looks like reflectively, basically a core reflection analogue to the draft javac/javax.lang.model test:

https://github.com/openjdk/jdk/pull/14140/files#diff-106fc5b2c4d391546c7fa8a75e68fbd963733964f8f7ddf577606b5afda9b889

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13689#issuecomment-1564983686

From liach at openjdk.org  Fri May 26 21:39:59 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 May 2023 21:39:59 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
In-Reply-To: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
Message-ID: <5xAcuciIpNQufUPxCkvVRctp0K75jd_4xfDqz4utno8=.683bc220-c29f-4df6-b4ad-3a8ddc151f79@github.com>

On Fri, 26 May 2023 02:06:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Explain in java.lang.Class how unnamed classes are modeled in core reflection.

src/java.base/share/classes/java/lang/Class.java line 212:

> 210:  * {@linkplain #getTypeName type name}, {@linkplain #getSimpleName
> 211:  * simple name}, and {@linkplain #getCanonicalName canonical name} all
> 212:  * return results equal to "{@code HelloWorld}".

I recommend moving the quotes into `{@code}` because this is how the file name is represented above. Same is used for existing strings in code, like the rendering of `{@value #STRING_FIELD}` values.
Suggestion:

 * return results equal to {@code "HelloWorld"}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14165#discussion_r1207393725

From mchung at openjdk.org  Fri May 26 22:08:15 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 May 2023 22:08:15 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
 <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
Message-ID: <AJxdedZPxkFH0Uw22CX7tXPo3_Auv297ZXnfOKxKNB8=.83f84f60-8c8a-4eea-bd87-c309096627da@github.com>

On Fri, 26 May 2023 21:06:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandleProxies.java line 209:
>> 
>>> 207:         if (intfc.isHidden())
>>> 208:             throw newIllegalArgumentException("a hidden interface", intfc.getName());
>>> 209:         if (!VM.isModuleSystemInited())
>> 
>> I don't expect this is needed.  I assume you are thinking for LMF to use this API?
>
> Proxy-based impl had this check, so I'd assume MHP might want to defend against the same kind of improper usage.

Proxy is used by annotation implementation.   I suspect that's why that check was there.

For `MHP::asInterfaceInstance`, I would drop the `isModuleSystemInitied` check until the API is being used during early startup.   I don't expect it be called before module system is initialized.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207391651

From mchung at openjdk.org  Fri May 26 22:08:16 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 May 2023 22:08:16 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <98YBa_WBEwtCvYRDW5MGvaldIafXiTtF8NNtVntaDJ0=.0eb04101-f922-4ae8-b12b-1e8a926ec926@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
 <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
 <NsNbY_G6Nb0x313vuzyiYg0ZLMz7wZc37zVBlw5XhVQ=.127f8d5b-5402-461b-b08e-0c1b4518fe0f@github.com>
 <98YBa_WBEwtCvYRDW5MGvaldIafXiTtF8NNtVntaDJ0=.0eb04101-f922-4ae8-b12b-1e8a926ec926@github.com>
Message-ID: <f-DRv-zieo1-oPOMlGdcJkzXPQWQGohmGYd_Z7loJRQ=.bc7de20c-9627-44c9-9e37-c32da1905453@github.com>

On Fri, 26 May 2023 21:29:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>>> This approach also requires the Class loading checks since the interface is not unconditionally exported and fails security manager.
>> 
>> Are you referring to `ClassLoader::checkPackageAccess` change?   As MHProxy implements `sun.invoke.WrapperInstance`, it needs to export `java.base/sun.invoke` to the dynamic module.    The change to `ClassLoader::checkPackageAccess` doesn't make sense for this.
>
> Yes. Unfortunately, it fails at https://github.com/openjdk/jdk/blob/bd21e68e679c41c98f39dd2fbd38270ae7d55ed9/src/java.base/share/classes/java/lang/SecurityManager.java#L1317 because a conditionally-exported package is considered a non-(unconditionally-)exported package.

If we keep a cache of all MHProxy classes, I think this would not need `sun.invoke.WrapperInstance`.   OTOH, `sun.invoke` does not have any other class except `WrapperInstance` and the `ensureOriginalLookup` method would need to be in an internal class.   So no problem of implementing `sun.invoke.WrapperInstance`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207387430

From mchung at openjdk.org  Fri May 26 22:08:17 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 May 2023 22:08:17 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <f-DRv-zieo1-oPOMlGdcJkzXPQWQGohmGYd_Z7loJRQ=.bc7de20c-9627-44c9-9e37-c32da1905453@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
 <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
 <NsNbY_G6Nb0x313vuzyiYg0ZLMz7wZc37zVBlw5XhVQ=.127f8d5b-5402-461b-b08e-0c1b4518fe0f@github.com>
 <98YBa_WBEwtCvYRDW5MGvaldIafXiTtF8NNtVntaDJ0=.0eb04101-f922-4ae8-b12b-1e8a926ec926@github.com>
 <f-DRv-zieo1-oPOMlGdcJkzXPQWQGohmGYd_Z7loJRQ=.bc7de20c-9627-44c9-9e37-c32da1905453@github.com>
Message-ID: <hsjtEhKMBGFEYZQBM7exD58qbS5TBHtHj7w3utQu2Vw=.f83790b1-4cee-439d-a35c-d1365e799e84@github.com>

On Fri, 26 May 2023 21:31:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Yes. Unfortunately, it fails at https://github.com/openjdk/jdk/blob/bd21e68e679c41c98f39dd2fbd38270ae7d55ed9/src/java.base/share/classes/java/lang/SecurityManager.java#L1317 because a conditionally-exported package is considered a non-(unconditionally-)exported package.
>
> If we keep a cache of all MHProxy classes, I think this would not need `sun.invoke.WrapperInstance`.   OTOH, `sun.invoke` does not have any other class except `WrapperInstance` and the `ensureOriginalLookup` method would need to be in an internal class.   So no problem of implementing `sun.invoke.WrapperInstance`.

> because a conditionally-exported package is considered a non-(unconditionally-)exported package.

OK.  I need to look into the right solution for this.   The Proxy implementation uses null protection domain to define the proxy class whereas this patch uses the protection domain as the interface to define the MHProxy class.  That's why this issue only occurs in this new implementation.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207415941

From mchung at openjdk.org  Fri May 26 22:08:18 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 26 May 2023 22:08:18 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <hsjtEhKMBGFEYZQBM7exD58qbS5TBHtHj7w3utQu2Vw=.f83790b1-4cee-439d-a35c-d1365e799e84@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
 <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
 <NsNbY_G6Nb0x313vuzyiYg0ZLMz7wZc37zVBlw5XhVQ=.127f8d5b-5402-461b-b08e-0c1b4518fe0f@github.com>
 <98YBa_WBEwtCvYRDW5MGvaldIafXiTtF8NNtVntaDJ0=.0eb04101-f922-4ae8-b12b-1e8a926ec926@github.com>
 <f-DRv-zieo1-oPOMlGdcJkzXPQWQGohmGYd_Z7loJRQ=.bc7de20c-9627-44c9-9e37-c32da1905453@github.com>
 <hsjtEhKMBGFEYZQBM7exD58qbS5TBHtHj7w3utQu2Vw=.f83790b1-4cee-439d-a35c-d1365e799e84@github.com>
Message-ID: <8P2hD5jJPd7oWhpg3AuFbjpXjJETdN_BR1ydkTySXlo=.2d0a8c28-9d9b-4a70-b54e-311e2bd86b7a@github.com>

On Fri, 26 May 2023 22:03:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> If we keep a cache of all MHProxy classes, I think this would not need `sun.invoke.WrapperInstance`.   OTOH, `sun.invoke` does not have any other class except `WrapperInstance` and the `ensureOriginalLookup` method would need to be in an internal class.   So no problem of implementing `sun.invoke.WrapperInstance`.
>
>> because a conditionally-exported package is considered a non-(unconditionally-)exported package.
> 
> OK.  I need to look into the right solution for this.   The Proxy implementation uses null protection domain to define the proxy class whereas this patch uses the protection domain as the interface to define the MHProxy class.  That's why this issue only occurs in this new implementation.

If we can avoid implementing `sun.invoke.WrapperInstance`, this package access check issue would go away.  Do you think you can look into it?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207416972

From liach at openjdk.org  Fri May 26 22:13:55 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 May 2023 22:13:55 GMT
Subject: RFR: 8306889: Convert MethodTypeDescImpl parameter storage from
 array to immutable list [v4]
In-Reply-To: <vzn8QEVPvzZa3WqRyZWFQniQ3UjhiWFeJUjXb4Pguhc=.835afe67-b172-4647-8926-4081d02f050a@github.com>
References: <S5tCSy1i5i6CMTFu1Q1ZAO_5RCHSbZ_w4av4dCN-6lE=.8302e8fc-9c37-4e82-b375-eb7e18fa86fd@github.com>
 <vzn8QEVPvzZa3WqRyZWFQniQ3UjhiWFeJUjXb4Pguhc=.835afe67-b172-4647-8926-4081d02f050a@github.com>
Message-ID: <zpRxO2rAAZ3tH9U5ixclitCkU0aXLTQ7sNbItaGpVCA=.57ddafcf-58eb-4a10-985a-403909ea69c2@github.com>

On Wed, 24 May 2023 02:29:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This patch moves the parameters to an immutable list, to avoid allocations on `parameterList` as well. In addition, it fixes 8304932, the bug where if a caller keeps a reference to the array passed into `MethodTypeDesc.of`, the caller may mutate the Desc via the array and can create invalid MethodTypeDesc.
>> 
>> The latest benchmark results are available here: https://github.com/openjdk/jdk/pull/13186#issuecomment-1560378822
>> 
>> This patch has minor performance gains on `ofDescriptor` factory, even compared to Adam's patch that optimized `ofDescriptor` in #12945.
>> 
>> Benchmark of Oracle JDK 20: https://gist.github.com/683c6219e183cbc2b336224fc2c0d50a
>> Benchmark of this patch: https://gist.github.com/22be9371a2370fb4a7b44f1684750ec4
>> Benchmark of [asotona's patch](https://github.com/openjdk/jdk/pull/12945/files#diff-ac8e413d3e13532a2b0d34a90253c6ddd7a4f04082f792b9d076e9b5a33f2078): https://gist.github.com/eb98579c3b51cafae481049a95a78f80
>> 
>> [sotona vs this](https://jmh.morethan.io/?gists=eb98579c3b51cafae481049a95a78f80,22be9371a2370fb4a7b44f1684750ec4); [20 vs this](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,22be9371a2370fb4a7b44f1684750ec4); [20 vs sotona](https://jmh.morethan.io/?gists=683c6219e183cbc2b336224fc2c0d50a,eb98579c3b51cafae481049a95a78f80), for reference
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reuse immutable list to avoid array allocation

The benefits of a list implementation over an array implementation are:
1. `parameterList()` is much faster, allowing more beautiful user code compared to manually unpacked iteration (immutable list factory doesn't allow using non-Object backing arrays)
2. `of(ClassDesc, List)` allows users to share immutable parameter lists than having to copy

> With https://github.com/openjdk/jdk/pull/13671, MethodTypeDesc is cached and I wonder if this is no longer the bottleneck of ClassFile API performance.

The parsing is no more, but `descriptorString` is still a bottleneck. The master in the last benchmark already had 8306842 integrated.

In fact, I don't think argType array sharing goes far enough: in these modification methods and ofDescriptor, we can skip the array/list iteration validation if we can ensure the change parts alone have not produced an invalid method type (insertion of void, slot changes). I would postpone such in-depth sharing into a later issue, where we track the slot count information as well (to preemptively reject invalid resolveConstantDesc calls)

> Converting `argTypes` to an immutable list seems to be an extra step to make it immutable - we need frozen arrays!!

Unfortunately, this is currently the only way general users have access to frozen arrays, where index-based access may be constant-folded, as `@Stable` is not generally available.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13186#issuecomment-1565013833

From liach at openjdk.org  Fri May 26 22:21:03 2023
From: liach at openjdk.org (Chen Liang)
Date: Fri, 26 May 2023 22:21:03 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <8P2hD5jJPd7oWhpg3AuFbjpXjJETdN_BR1ydkTySXlo=.2d0a8c28-9d9b-4a70-b54e-311e2bd86b7a@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
 <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
 <NsNbY_G6Nb0x313vuzyiYg0ZLMz7wZc37zVBlw5XhVQ=.127f8d5b-5402-461b-b08e-0c1b4518fe0f@github.com>
 <98YBa_WBEwtCvYRDW5MGvaldIafXiTtF8NNtVntaDJ0=.0eb04101-f922-4ae8-b12b-1e8a926ec926@github.com>
 <f-DRv-zieo1-oPOMlGdcJkzXPQWQGohmGYd_Z7loJRQ=.bc7de20c-9627-44c9-9e37-c32da1905453@github.com>
 <hsjtEhKMBGFEYZQBM7exD58qbS5TBHtHj7w3utQu2Vw=.f83790b1-4cee-439d-a35c-d1365e799e84@github.com>
 <8P2hD5jJPd7oWhpg3AuFbjpXjJETdN_BR1ydkTySXlo=.2d0a8c28-9d9b-4a70-b54e-311e2bd86b7a@github.com>
Message-ID: <V4XJOEZR3VHnoecHXtdKTuNr8SDbNW2azd_q5rczddQ=.9548a2b3-7b9f-4c1d-a7bb-2c6491ca4207@github.com>

On Fri, 26 May 2023 22:05:06 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> because a conditionally-exported package is considered a non-(unconditionally-)exported package.
>> 
>> OK.  I need to look into the right solution for this.   The Proxy implementation uses null protection domain to define the proxy class whereas this patch uses the protection domain as the interface to define the MHProxy class.  That's why this issue only occurs in this new implementation.
>
> If we can avoid implementing `sun.invoke.WrapperInstance`, this package access check issue would go away.  Do you think you can look into it?

I think we can probably insert a static final field in a wrapper instance class to point to the implemented class and verify with the `PROXY_CLASS_INFOS` ClassValue, much like VarForm field in VarHandle implementations. This should have less reflective impact than the annotation-based approach, and can be cached in a ClassValue as well. Should we cache it though?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1207426728

From stuefe at openjdk.org  Sat May 27 11:28:54 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 27 May 2023 11:28:54 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <IZ4YR_xufzTDcXxB951WwGkcF4icFdEg-fwalgd59qA=.787de67a-2d85-4319-bf74-d73c2bafdf3d@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <Z6J__T8X9bDvrfFjUxNImPMEUwKQmbESvmzYUeDolkQ=.9309297e-ab60-4cd5-9a20-687d545101a8@github.com>
 <G0ZEvXBOXoDAbZOSj0zcDFxcADCi_Mk-hNOvsJiCw58=.443eb739-394c-44da-8e48-6b157ad59045@github.com>
 <nA6t5xQ1QqQJ9UEwtTbAcG9P705u1cjmnmBrWCtbXq4=.1bed9538-5073-4649-bfd6-0f5734b0a967@github.com>
 <IZ4YR_xufzTDcXxB951WwGkcF4icFdEg-fwalgd59qA=.787de67a-2d85-4319-bf74-d73c2bafdf3d@github.com>
Message-ID: <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com>

On Fri, 26 May 2023 20:27:12 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags.

That does not invalidate my argument, nor does it answer my question. Those test errors could be also fixed by renaming the log tag. Maybe that would be the better way. 

Also, I'm curious, why does it not complain about "free", which is a logtag as well?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1207892378

From stuefe at openjdk.org  Sat May 27 11:52:55 2023
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 27 May 2023 11:52:55 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <Z6J__T8X9bDvrfFjUxNImPMEUwKQmbESvmzYUeDolkQ=.9309297e-ab60-4cd5-9a20-687d545101a8@github.com>
 <G0ZEvXBOXoDAbZOSj0zcDFxcADCi_Mk-hNOvsJiCw58=.443eb739-394c-44da-8e48-6b157ad59045@github.com>
 <nA6t5xQ1QqQJ9UEwtTbAcG9P705u1cjmnmBrWCtbXq4=.1bed9538-5073-4649-bfd6-0f5734b0a967@github.com>
 <IZ4YR_xufzTDcXxB951WwGkcF4icFdEg-fwalgd59qA=.787de67a-2d85-4319-bf74-d73c2bafdf3d@github.com>
 <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com>
Message-ID: <lc7fUJc3lm6GhV0G56hZd8ufG4RR1k1Q1cYonp4MAeI=.cef8ed54-11ef-4281-acc3-eb378547fd87@github.com>

On Sat, 27 May 2023 11:25:41 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags.
>
>> This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags.
> 
> That does not invalidate my argument, nor does it answer my question. Those test errors could be also fixed by renaming the log tag. Maybe that would be the better way. 
> 
> Also, I'm curious, why does it not complain about "free", which is a logtag as well?

I am basically worried that undefining malloc, even if it seems harmless now, exposes us to difficult-to-investigate problems down the road, since it depends on how the libc devs will reform those macros in the future. I would prefer a simple solution that does not depend on how the libc includes evolve.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1207907447

From alanb at openjdk.org  Sat May 27 14:24:03 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 27 May 2023 14:24:03 GMT
Subject: RFR: 8308748: JNU_GetStringPlatformChars may write to String's
 internal memory array [v2]
In-Reply-To: <z-Sp5itXRBV0S__vZF5OAzZR5W-l3lo2B8u2j-oaYKs=.77813e70-66d9-4080-9448-63b1f19ebbe7@github.com>
References: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>
 <z-Sp5itXRBV0S__vZF5OAzZR5W-l3lo2B8u2j-oaYKs=.77813e70-66d9-4080-9448-63b1f19ebbe7@github.com>
Message-ID: <VYpbti8qYFHcDDU46JZ6zHadk921azwXabC3xCnQjPw=.484b7657-e1ab-4c15-92d8-8eb32981b636@github.com>

On Fri, 26 May 2023 19:54:07 GMT, Rudi Horn <duke at openjdk.org> wrote:

>> This change prevents the contents of the internal string array from being copied back when releasing it.
>
> Rudi Horn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Use JNI_ABORT to release string bytes

This looks okay. Have you checked the other usages of ReleasePrimitiveArrayCritical (e.g. libzip) see if they need the copy back when releasing?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14117#issuecomment-1565450604

From kbarrett at openjdk.org  Sat May 27 15:36:55 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sat, 27 May 2023 15:36:55 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <lc7fUJc3lm6GhV0G56hZd8ufG4RR1k1Q1cYonp4MAeI=.cef8ed54-11ef-4281-acc3-eb378547fd87@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <Z6J__T8X9bDvrfFjUxNImPMEUwKQmbESvmzYUeDolkQ=.9309297e-ab60-4cd5-9a20-687d545101a8@github.com>
 <G0ZEvXBOXoDAbZOSj0zcDFxcADCi_Mk-hNOvsJiCw58=.443eb739-394c-44da-8e48-6b157ad59045@github.com>
 <nA6t5xQ1QqQJ9UEwtTbAcG9P705u1cjmnmBrWCtbXq4=.1bed9538-5073-4649-bfd6-0f5734b0a967@github.com>
 <IZ4YR_xufzTDcXxB951WwGkcF4icFdEg-fwalgd59qA=.787de67a-2d85-4319-bf74-d73c2bafdf3d@github.com>
 <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com>
 <lc7fUJc3lm6GhV0G56hZd8ufG4RR1k1Q1cYonp4MAeI=.cef8ed54-11ef-4281-acc3-eb378547fd87@github.com>
Message-ID: <Sd028nVao99R40f2WC1j159LGpWtcaUasdFWScfq4Fs=.87d3ca9e-2c13-4bbe-b8ab-c11ab0165d3f@github.com>

On Sat, 27 May 2023 11:50:11 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> This one is not just to get rid of a warning. We get real test errors because malloc gets replaced by vec_malloc in log tags.
>> 
>> That does not invalidate my argument, nor does it answer my question. Those test errors could be also fixed by renaming the log tag. Maybe that would be the better way. 
>> 
>> Also, I'm curious, why does it not complain about "free", which is a logtag as well?
>
> I am basically worried that undefining malloc, even if it seems harmless now, exposes us to difficult-to-investigate problems down the road, since it depends on how the libc devs will reform those macros in the future. I would prefer a simple solution that does not depend on how the libc includes evolve.

Is it possible to see the stdlib.h source code that is being a problem?  Maybe more eyes can come up
with a better solution, or at least come to a better understanding of why we have to go this way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1208039639

From darcy at openjdk.org  Sat May 27 21:11:50 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 27 May 2023 21:11:50 GMT
Subject: RFR: JDK-8308987: Update java.lang.Class to use javadoc snippets
Message-ID: <0yqeEu2-dyUcIiBDInyHLmsbtXmjtqcXiMIZNMDlOC4=.bc254a1d-51c5-4215-80bc-02132e810cab@github.com>

Straightforward doc refactoring to use snippets.

-------------

Commit messages:
 - JDK-8308987: Update java.lang.Class to use javadoc snippets

Changes: https://git.openjdk.org/jdk/pull/14194/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14194&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308987
  Stats: 24 lines in 1 file changed: 0 ins; 0 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/14194.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14194/head:pull/14194

PR: https://git.openjdk.org/jdk/pull/14194

From liach at openjdk.org  Sat May 27 22:35:55 2023
From: liach at openjdk.org (Chen Liang)
Date: Sat, 27 May 2023 22:35:55 GMT
Subject: RFR: JDK-8308987: Update java.lang.Class to use javadoc snippets
In-Reply-To: <0yqeEu2-dyUcIiBDInyHLmsbtXmjtqcXiMIZNMDlOC4=.bc254a1d-51c5-4215-80bc-02132e810cab@github.com>
References: <0yqeEu2-dyUcIiBDInyHLmsbtXmjtqcXiMIZNMDlOC4=.bc254a1d-51c5-4215-80bc-02132e810cab@github.com>
Message-ID: <LSlUS9g-UE67vhxSVAnWjS9gBNYS1bpAUrX8qCShn5Q=.9d938300-dfe9-4c09-8109-a93c97c72aa4@github.com>

On Sat, 27 May 2023 21:04:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Straightforward doc refactoring to use snippets.

src/java.base/share/classes/java/lang/Class.java line 356:

> 354:      *
> 355:      * {@snippet lang="java" :
> 356:      *   Class<?> t = Class.forName("java.lang.Thread")

This should have a final semicolon, as it's already a variable declaration and initialization.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14194#discussion_r1208169192

From kbarrett at openjdk.org  Sun May 28 03:39:10 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 28 May 2023 03:39:10 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: <VpEl4v3oeJJGf7hCma44tp9IG-d6T1jyRjemqZN8Kfg=.8338f76a-37e5-4524-9cfe-83b2a774b3bc@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <VpEl4v3oeJJGf7hCma44tp9IG-d6T1jyRjemqZN8Kfg=.8338f76a-37e5-4524-9cfe-83b2a774b3bc@github.com>
Message-ID: <63Q15YTSJDgsIJb4fYQYdrtBYkSNebRm7Q8jVgzTiW8=.86a710d5-1930-4b3c-80a2-743a83653831@github.com>

On Fri, 26 May 2023 07:48:06 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> According to our docs, [clang is a supported compiler for Linux](https://github.com/openjdk/jdk/blob/master/doc/building.md#native-compiler-toolchain-requirements).

I think that's aspirational rather than actual.  Clang has been included in
that list for a long time (since at least JDK 9), but I think there's never
been anyone claiming to provide such support, be a maintainer, or even
build/test on some regular basis:
https://wiki.openjdk.org/display/Build/Supported+Build+Platforms

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14033#issuecomment-1565842012

From kbarrett at openjdk.org  Sun May 28 04:14:04 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Sun, 28 May 2023 04:14:04 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <_RQshJQSfZfWSXTPvIjEekBkNIJCGy6UPHo_94bE5IM=.afc7036a-4553-45f2-b5d2-76758e69dbb4@github.com>

On Wed, 17 May 2023 12:28:47 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

All of the -Wformat-nonliteral changes make me wonder why we're seeing these
with clang but not with gcc.  Figuring that out will likely give a better
chance of acceptance.

src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c line 1163:

> 1161: #if defined(__clang__)
> 1162: #pragma clang diagnostic push
> 1163: #pragma clang diagnostic ignored "-Wparentheses"

I think this warning is because of the several `if (init_result = ...)`?  Better would be to just add the extra parens.

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 575:

> 573: if (ps_pdread(ph, (char *)link_map_addr + LINK_MAP_LD_OFFSET,
> 574:                &lib_ld, sizeof(uintptr_t)) != PS_OK) {
> 575: #else

What problem is being "fixed" by these?  I'm dubious that this is the best solution to whatever the problem
is, but can't evaluate or suggest alternatives without knowing what it is.

-------------

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1447852014
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1208298799
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1208302906

From alanb at openjdk.org  Sun May 28 18:53:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 28 May 2023 18:53:56 GMT
Subject: RFR: JDK-8308987: Update java.lang.Class to use javadoc snippets
In-Reply-To: <0yqeEu2-dyUcIiBDInyHLmsbtXmjtqcXiMIZNMDlOC4=.bc254a1d-51c5-4215-80bc-02132e810cab@github.com>
References: <0yqeEu2-dyUcIiBDInyHLmsbtXmjtqcXiMIZNMDlOC4=.bc254a1d-51c5-4215-80bc-02132e810cab@github.com>
Message-ID: <mvaU7uAgrjUBsJd7G0OI6Yv1GWeVBEreCOW_uQqO0bU=.a4f61555-1e26-42a0-a344-6811bcf66c3e@github.com>

On Sat, 27 May 2023 21:04:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Straightforward doc refactoring to use snippets.

src/java.base/share/classes/java/lang/Class.java line 426:

> 424:      * {@snippet lang="java" :
> 425:      *  Class.forName("Foo", true, this.getClass().getClassLoader())
> 426:      * }

Not important but there are at least 3 different indentation widths in the update. Does it look okay in the generated javadoc?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14194#discussion_r1208625597

From aturbanov at openjdk.org  Sun May 28 22:06:54 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 28 May 2023 22:06:54 GMT
Subject: RFR: 8308856: jdk.internal.classfile.impl.EntryMap::nextPowerOfTwo
 math problem
In-Reply-To: <A0SmHH6KU16n2rdxGrqQoPeCqwZxjJ6amYDMcZBC3Xo=.be307a1e-1007-4898-87e5-03a82bbac830@github.com>
References: <A0SmHH6KU16n2rdxGrqQoPeCqwZxjJ6amYDMcZBC3Xo=.be307a1e-1007-4898-87e5-03a82bbac830@github.com>
Message-ID: <erpxa6ZGbWdhgQNLsB64f11g2JyoJJMVDjsGDxOJfwc=.d6c1f1ee-1cba-4beb-aeb6-11157fbdbb96@github.com>

On Thu, 25 May 2023 12:24:59 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Fix of jdk.internal.classfile.impl.EntryMap::nextPowerOfTwo returning correct zero power of two.
> 
> Please review.
> 
> Thanks,
> Adam

src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java line 177:

> 175: 
> 176:     public static long nextPowerOfTwo( long x ) {
> 177:         return 1l << -Long.numberOfLeadingZeros(x - 1);

Suggestion:

        return 1L << -Long.numberOfLeadingZeros(x - 1);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14148#discussion_r1208669192

From duke at openjdk.org  Mon May 29 02:20:07 2023
From: duke at openjdk.org (Chang Peng)
Date: Mon, 29 May 2023 02:20:07 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
 [v4]
In-Reply-To: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
Message-ID: <ah2Znw6zKxUU7O0Qlsq86xaXFiv2wbw-dvkSKxnayfw=.8f07af5e-e6e2-4895-a71b-54fa801927bd@github.com>

> In Vector API Java level, vector mask is represented as a boolean array with 0x00/0x01 (8 bits of each element) as values, aka in-memory format. When it is loaded into vector register, e.g. Neon, the in-memory format will be converted to in-register format with 0/-1 value for each lane (lane width aligned to its type) by VectorLoadMask [1] operation, and convert back to in-memory format by VectorStoreMask[2]. In Neon, a typical VectorStoreMask operation will first narrow given vector registers by xtn insn [3] into byte element type, and then do a vector negate to convert to 0x00/0x01 value for each element.
> 
> For most of the vector mask operations, the input mask is in-register format. And a vector mask also works in-register format all through the compilation. But for some operations like VectorMask.trueCount()[4] which counts the elements of true value, the expected input mask is in-memory format. So a VectorStoreMask is generated to convert the mask from in-register format to in-memory format before those operations.
> 
> However, for trueCount() these xtn instructions in VectorStoreMask can be saved, since the narrowing operations will not influence the number of active lane (value of 0x01) of its input.
> 
> This patch adds an optimized rule `VectorMaskTrueCount (VectorStoreMask mask)` to save the unnecessary narrowing operations.
> 
> For example,
> 
> 
> var m = VectorMask.fromArray(IntVector.SPECIES_PREFERRED, ba, 0);
> m.not().trueCount();
> 
> 
> will produce following assembly on a Neon machine before this patch:
> 
> 
> ...
> mvn     v16.16b, v16.16b           // VectorMask.not()
> xtn     v16.4h, v16.4s
> xtn     v16.8b, v16.8h
> neg     v16.8b, v16.8b             // VectorStoreMask
> addv    b17, v16.8b
> umov    w0, v17.b[0]               // VectorMask.trueCount()
> ...
> 
> 
> After this patch:
> 
> 
> ...
> mvn     v16.16b, v16.16b           // VectorMask.not()
> addv    s17, v16.4s
> smov    x0, v17.b[0]
> neg     x0, x0                     // Optimized VectorMask.trueCount()
> ...
> 
> 
> In this case, we can save two xtn insns.
> 
> Performance:
> 
> Benchmark     Before               After                          Unit
> testInt           723.822 ? 1.029  1182.375 ? 12.363    ops/ms
> testLong       632.154 ? 0.197  1382.74 ? 2.188        ops/ms
> testShort      788.665 ? 1.852   1152.38 ? 3.77         ops/ms
> 
> [1]: https://github.com/openjdk/jdk/blob/e1e758a7b43c29840296d337bd2f0213ab0ca3c9/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4740
> [2]: https://github.com/openjdk/jdk/b...

Chang Peng has updated the pull request incrementally with one additional commit since the last revision:

  Update aarch64_vector.ad

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13974/files
  - new: https://git.openjdk.org/jdk/pull/13974/files/567f69a2..e8762c03

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13974&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13974&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13974.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13974/head:pull/13974

PR: https://git.openjdk.org/jdk/pull/13974

From duke at openjdk.org  Mon May 29 02:32:16 2023
From: duke at openjdk.org (duke)
Date: Mon, 29 May 2023 02:32:16 GMT
Subject: Withdrawn: 8301220: Return value of toArray() of
 =?UTF-8?B?0KFvbGxlY3Rpb24=?= types from java.base should be trusted
In-Reply-To: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
References: <TT0uMtRrRVdLtw3Rr2RUjL9aNrjTlcyIRDk2zxIG8OQ=.f46f2e33-313f-4e40-ab2a-2fb82f6da58f@github.com>
Message-ID: <jT_54i_7EMINlUAINcynqORYo4Uk-CRrxSHS3dfe2ZM=.ba52ef3c-fefb-4369-83ec-b6c2f0d15e5a@github.com>

On Thu, 26 Jan 2023 06:46:16 GMT, Glavo <duke at openjdk.org> wrote:

> I checked the `java.base` module, and all the `Collection#toArray()` method of collections be implemented correctly.
> 
> Their return values can be trusted, so many unnecessary array duplication can be eliminated.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12212

From dholmes at openjdk.org  Mon May 29 02:52:54 2023
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 29 May 2023 02:52:54 GMT
Subject: RFR: 8308748: JNU_GetStringPlatformChars may write to String's
 internal memory array [v2]
In-Reply-To: <VYpbti8qYFHcDDU46JZ6zHadk921azwXabC3xCnQjPw=.484b7657-e1ab-4c15-92d8-8eb32981b636@github.com>
References: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>
 <z-Sp5itXRBV0S__vZF5OAzZR5W-l3lo2B8u2j-oaYKs=.77813e70-66d9-4080-9448-63b1f19ebbe7@github.com>
 <VYpbti8qYFHcDDU46JZ6zHadk921azwXabC3xCnQjPw=.484b7657-e1ab-4c15-92d8-8eb32981b636@github.com>
Message-ID: <SvengrUOC91DX9tp2ec6ZuiPH65aMXJWDVPyhDHEuFY=.77bd4ba3-f07e-4929-9872-13cb1e6a0c16@github.com>

On Sat, 27 May 2023 14:21:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This looks okay. Have you checked the other usages of ReleasePrimitiveArrayCritical (e.g. libzip) see if they need the copy back when releasing?

I can immediately see code in `Java_java_util_zip_Inflater_inflateBytesBytes` that needs the same fix in relation to the input array. Even if there is no issue with read-only memory when writing back an unchanged array, we should avoid unnecessary copying.

That said I'm not sure it is up to this issue/PR to take responsibility for policing all uses of `ReleasePrimitiveArrayCritical` in the JDK libraries.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14117#issuecomment-1566418737

From jpai at openjdk.org  Mon May 29 06:55:56 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 29 May 2023 06:55:56 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java
In-Reply-To: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
Message-ID: <tTB9n3hVd4TnnsEGSOZXyBDI5hhdOdGpLpyLT2ZPnAY=.68c50c5a-f43c-4462-ab6e-4273a3e7e49d@github.com>

On Wed, 24 May 2023 19:18:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> UUID is very important class that is used to track identities of objects in large scale systems. Yet, the coverage in JDK test is disappointing: it tests only 100 of UUID instances per test, which is way too small to detect collisions due to the bad randomness for example.
> 
> I have some pending work to improve UUID performance, and tests should be improved. 
> 
> The improved test still runs in less than 5 seconds on my laptop.

Overall, this test-only change look OK to me. It updates the test to use a `Set` instead of `List` for "contains" checks, which detect random generated UUID collisions. The other part of this change is increasing the UUID generation count/repeatition and a new test method which generates the UUIDs in parallel and tries to detect any unexpected collisions.

I just have a couple of minor suggestions, which I have noted inline.

test/jdk/java/util/UUID/UUIDTest.java line 40:

> 38:     private static final int COUNT = 1_000_000;
> 39: 
> 40:     static final Random generator = new Random();

Hello Aleksey, I realize this is unrelated to the changes in this PR, but since we are updating this test, would using `jdk.test.lib.RandomFactory.getRandom()` from test library be a better idea here? That would then print the seed in the logs and could help debug any collisions more easily?

test/jdk/java/util/UUID/UUIDTest.java line 316:

> 314:             UUID u2 = UUID.fromString(u1.toString());
> 315:             if (u1.hashCode() != u2.hashCode()) {
> 316:                 throw new Exception("Equal UUIDs with different hash codes: " + u1 + " and " + u2);

Perhaps we should even print the hash codes that weren't matching to provide assistance when debugging?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14134#issuecomment-1566645445
PR Review Comment: https://git.openjdk.org/jdk/pull/14134#discussion_r1208977029
PR Review Comment: https://git.openjdk.org/jdk/pull/14134#discussion_r1208978832

From jlahoda at openjdk.org  Mon May 29 07:25:26 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 29 May 2023 07:25:26 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v3]
In-Reply-To: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
Message-ID: <c_WqMRntlvIay9bD2C8eWuIDSzO4qjzaj0sLRnncO-A=.b0644ca2-cc42-4919-b53e-1e4eff866398@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.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Reflecting review feedback.
 - Merge branch 'master' into JDK-8291966
 - Adding comments
 - Improving performance
 - Merge branch 'master' into JDK-8291966
 - 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=02
  Stats: 197 lines in 2 files changed: 110 ins; 15 del; 72 mod
  Patch: https://git.openjdk.org/jdk/pull/9779.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/9779/head:pull/9779

PR: https://git.openjdk.org/jdk/pull/9779

From jlahoda at openjdk.org  Mon May 29 07:28:06 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 29 May 2023 07:28:06 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v2]
In-Reply-To: <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
Message-ID: <jJnUaGT3BOOgnbTJ_5UtwR6-1bbt-_k3UOSHL4AIJOc=.3fe37805-118b-4411-9ee7-4754a169a1b2@github.com>

On Tue, 17 Jan 2023 15:55:40 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.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Adding comments
>  - Improving performance
>  - Merge branch 'master' into JDK-8291966
>  - 8291966: SwitchBootstrap.typeSwitch could be faster

I've merged with the current master, and tried to reflect the review feedback. I tried to run a performance test:
[PatternsOptimizationTest.java.txt](https://github.com/openjdk/jdk/files/11589470/PatternsOptimizationTest.java.txt)

with these changes (the test uses a patch javac, and an current (old) version of `SwitchBootstraps` - javac use the old bootstrap for classes that contain `Legacy` in their name, new bootstrap in all other cases). The results when I ran this were:

PatternsOptimizationTest.testHandleIndyLongSwitch   thrpt   25  2555536.273 ?   49471.586  ops/s
PatternsOptimizationTest.testLegacyIndyLongSwitch   thrpt   25  1341944.936 ?  163396.221  ops/s

PatternsOptimizationTest.testHandleIndyShortSwitch  thrpt   25  9746865.005 ?  115379.432  ops/s
PatternsOptimizationTest.testLegacyIndyShortSwitch  thrpt   25  5535534.370 ? 1275754.361  ops/s


So, this patch still seems to improve the state.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9779#issuecomment-1566682417

From duke at openjdk.org  Mon May 29 07:36:08 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Mon, 29 May 2023 07:36:08 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v2]
In-Reply-To: <I2onL10Ro48dfUZASSphE5PkWvaVQoWa4l2-EoxSZ5c=.dfe9629e-9b4f-46ff-8fa1-9404142da1f0@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
 <I2onL10Ro48dfUZASSphE5PkWvaVQoWa4l2-EoxSZ5c=.dfe9629e-9b4f-46ff-8fa1-9404142da1f0@github.com>
Message-ID: <KMys6Yuo20zpt9-NUcVdE9i0bK6h2Rx5XdL57sIWo1s=.7f52b357-882d-47e3-b1d2-059562490b02@github.com>

On Tue, 2 May 2023 13:57:37 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Adding comments
>>  - Improving performance
>>  - Merge branch 'master' into JDK-8291966
>>  - 8291966: SwitchBootstrap.typeSwitch could be faster
>
> Also there is a lot of use cases where the type switch is called only with instances of the same class, for those scenarii, the VM should be able to fully remove the type switch and inline the body of the corresponding case like this is done with a virtual call.
> 
> I don't think there is a way currently to explain to the VM that the a hash map really acts as a cache so if the key is a constant then the value is a constant too (this optimization is also missing when JITing ClassValue.get()).

@forax 

Hi! Sorry for this sudden message, but this one captured my attention

> and subtype checks are usually fast.

And I hope this PR to be the right place to raise this.

I was looking this PR to better understand how it applies to secondary supers and https://bugs.openjdk.org/browse/JDK-8180450 (that's still WIP) doesn't look like subtype checks are yet fast nor scalable (with multiple interfaces and > 1 receiver types observed) - see https://ionutbalosin.com/2023/03/jvm-performance-comparison-for-jdk-17/#typecheckscalabilitybenchmark that can be modified to use type switch too.
 
In addition, at least for secondary types, a missed `IsInstance` (ie which type isn't implemented) can cost O(n) over the secondary supers types (see https://ionutbalosin.com/2023/03/jvm-performance-comparison-for-jdk-17/#typecheckslowpathbenchmark) that's still not ideal, due to the high bootstrapping cost of `prnz scas`.

Hence, the implementation of type switch is likely to account for the existing (performance) deficiencies of the secondary supers type check or is relying on the fix https://bugs.openjdk.org/browse/JDK-8180450 that will appear at some point?

Hope to have interacted in the right way with this with the JDK dev community, and thanks again for your hard work on this wonderful piece of engineering!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9779#issuecomment-1566691245

From asotona at openjdk.org  Mon May 29 08:05:23 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 29 May 2023 08:05:23 GMT
Subject: RFR: 8308856: jdk.internal.classfile.impl.EntryMap::nextPowerOfTwo
 math problem [v2]
In-Reply-To: <A0SmHH6KU16n2rdxGrqQoPeCqwZxjJ6amYDMcZBC3Xo=.be307a1e-1007-4898-87e5-03a82bbac830@github.com>
References: <A0SmHH6KU16n2rdxGrqQoPeCqwZxjJ6amYDMcZBC3Xo=.be307a1e-1007-4898-87e5-03a82bbac830@github.com>
Message-ID: <z-p190FZCg7etZfM93G6dDG4WFNCDhugc0N0G0czzE0=.ee60798f-2a3a-4f41-8bf4-58c50e9c3ecd@github.com>

> Fix of jdk.internal.classfile.impl.EntryMap::nextPowerOfTwo returning correct zero power of two.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/jdk/internal/classfile/impl/EntryMap.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14148/files
  - new: https://git.openjdk.org/jdk/pull/14148/files/8e2754e2..c51b50d3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14148&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14148&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14148.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14148/head:pull/14148

PR: https://git.openjdk.org/jdk/pull/14148

From dfuchs at openjdk.org  Mon May 29 09:59:53 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 29 May 2023 09:59:53 GMT
Subject: RFR: 8308960: Decouple internal Version and OperatingSystem
 classes [v2]
In-Reply-To: <P954_kQ2SMc7QILMjC5yiVnQM9BJuX4KaYfnembec7c=.f5ac4360-f703-4d88-abd1-559ed3b98a58@github.com>
References: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
 <P954_kQ2SMc7QILMjC5yiVnQM9BJuX4KaYfnembec7c=.f5ac4360-f703-4d88-abd1-559ed3b98a58@github.com>
Message-ID: <6LQDT06PCVlY8slt6UPMI7WwpZzmGlZL5oFDwn5bseQ=.b507d593-e30b-494f-935f-163d02d3b722@github.com>

On Fri, 26 May 2023 16:54:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Decouple the jdk.internal.util OperatingSystem and Version classes to simplify class loading and avoid an indirect cyclic initialization.
>> 
>> Move the method to get the current OS version from OperatingSystem to the Version class and its initialization.
>> Revert to using String.toUpperCase() instead of custom code to uppercase.
>> 
>> Update the uses of OperatingSystem.version to be Version.current.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename jdk.internal.util.Version to OSVersion

Thanks for renaming the class. The renaming LGTM.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14181#pullrequestreview-1449236628

From mcimadamore at openjdk.org  Mon May 29 10:45:59 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 29 May 2023 10:45:59 GMT
Subject: RFR: 8309042: MemorySegment::reinterpret cleanup action is not called
 for all overloads
Message-ID: <GO-WQcxxoNyrLynuGrm1gD998Y_OkGLO0iJdXlOtiJQ=.2157f0de-ba42-40b2-b3aa-12ee661625fa@github.com>

There's an obvious bug in `AbstractMemorySegmentImpl::reinterpret(long, Arena, Consumer)`: this method does not pass the consumer down to the internal implementation method (it just passes `null`). As a result, the cleanup is not registered.

-------------

Commit messages:
 - Remove redundant import
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/14199/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14199&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309042
  Stats: 16 lines in 2 files changed: 15 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14199.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14199/head:pull/14199

PR: https://git.openjdk.org/jdk/pull/14199

From mcimadamore at openjdk.org  Mon May 29 10:53:52 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 29 May 2023 10:53:52 GMT
Subject: RFR: 8308645: Javadoc of FFM API needs to be refreshed [v4]
In-Reply-To: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
References: <Au7ZfwLw1ITKKjPnh4jcqj_-zEBaxxrvWNOEoqXnklg=.40499acc-34e1-4773-ae81-cd45729d0382@github.com>
Message-ID: <ZvLmBl64m-vthIUqFehBG8QexIkakIljPcCRZXqTRQg=.496f9839-e228-4e7a-962b-283e49e53037@github.com>

> As the FFM API evolved over time, some parts of the javadoc went out of sync. Now that most of the API is stable, it is a good time to look again at the javadoc as a whole, and bring some more consistency.
> 
> While most of the changes in this PR are stylistic, I'd like to call out few things which resulted in API changes:
> 
> * `MemorySegment::asSlice(long, long, long)` did not (incorrectly) specified requirement that its alignment parameter must be a power of two.
> 
> * `MemoryLayout::sliceHandle` did not require the absence of dereference paths in the provided layout path. While that is technically possible to allow, currently the method is specified as returning a "slice" corresponding to some "nested layout", so following pointers seems incompatible with the spec. I have decided to disallow for now - we can always compatibly enable it later, if required.
> 
> * `MemorySegment::copy` - most of the overloads did not specify that `UnsupportedOperationException` is thrown if the destination segment is read-only.
> 
> * In several places, an extra `@throws IllegalArgumentException` or `@throws IllegalArgumentException` has been added to capture cases where element size * index computation can overflow. This is true for all the element-wise segment copy methods, for the indexed accessors in memory segment (e.g. `MemorySegment.getAtIndex(ValueLayout.OfInt, long)`), as well as for `SegmentAllocator::allocateArray(MemoryLayout, long)`.
> 
> In all these cases (except for overflows), new tests have been added to cover the additional API changes (a CSR will also be filed to cover these).
> 
> The class with most changes is `MemoryLayout`. I realized that the javadoc there was a bit sloppy around the definition of "layout paths". Now there are several subsection in the class javadoc, which explain how different kinds of paths can be used. I have introduced the notion of "open path elements" to denote those path elements that are not fully specified, and result in additional var handle coordinates to be added. There is also now a definition of what it means for a layout path to be "well-formed", so that all methods accepting a layout path can simply refer to it (this definition is tricky to give inline in the javadoc of the various path-accepting methods, as it depends on many factors).
> 
> Another biggie change was in `MemorySegment` as now all dereference methods state precisely their spatial checks requirements, as well also specifying when the API can throw because of an ...

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix wrong link in layout well-formedness doc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14098/files
  - new: https://git.openjdk.org/jdk/pull/14098/files/6703eee9..265e0d5b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14098&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14098&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14098.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14098/head:pull/14098

PR: https://git.openjdk.org/jdk/pull/14098

From jvernee at openjdk.org  Mon May 29 17:29:54 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 29 May 2023 17:29:54 GMT
Subject: RFR: 8309042: MemorySegment::reinterpret cleanup action is not
 called for all overloads
In-Reply-To: <GO-WQcxxoNyrLynuGrm1gD998Y_OkGLO0iJdXlOtiJQ=.2157f0de-ba42-40b2-b3aa-12ee661625fa@github.com>
References: <GO-WQcxxoNyrLynuGrm1gD998Y_OkGLO0iJdXlOtiJQ=.2157f0de-ba42-40b2-b3aa-12ee661625fa@github.com>
Message-ID: <k9NW7kZszFXBGw97UVdjCkK1cR_xD52jPFd4Jq7lHoE=.57857c68-ddfb-4b1d-b61f-1892920237ac@github.com>

On Mon, 29 May 2023 10:39:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> There's an obvious bug in `AbstractMemorySegmentImpl::reinterpret(long, Arena, Consumer)`: this method does not pass the consumer down to the internal implementation method (it just passes `null`). As a result, the cleanup is not registered.

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14199#pullrequestreview-1449744149

From asemenov at openjdk.org  Mon May 29 22:29:26 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Mon, 29 May 2023 22:29:26 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v2]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <So49itlN8iwiVZ4-LlECl3FlQEgc_aCTxdIO3lcHW9k=.1d9e68b9-acec-4bb3-b5cc-8abb93482b35@github.com>

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/86077cdf..3f343c26

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=00-01

  Stats: 134 lines in 15 files changed: 12 ins; 122 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From duke at openjdk.org  Tue May 30 03:07:10 2023
From: duke at openjdk.org (duke)
Date: Tue, 30 May 2023 03:07:10 GMT
Subject: Withdrawn: 8304020: Speed up
 test/jdk/java/util/zip/ZipFile/TestTooManyEntries.java and clarify its purpose
In-Reply-To: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
References: <8Imbn5098NjdJMPtI2UD7BNSP3oRM4q8vB5_Lq1pLhs=.4686073b-207c-4e3b-b6c0-6227037b11b6@github.com>
Message-ID: <Aq18w7zE_FD_cWqyhq7uSOCigDvQByMFjHozxTnef0Y=.ec0bfa0e-d49d-44ab-adfb-d426e221b6de@github.com>

On Sun, 12 Mar 2023 08:31:26 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> Please review this PR which speeds up TestTooManyEntries and clarifies its purpose:
> 
> - The name 'TestTooManyEntries' does not clearly convey the purpose of the test. What is tested is the validation that the total CEN size fits in a Java byte array. Suggested rename: CenSizeTooLarge
> - The test creates DEFLATED entries which incurs zlib costs and File Data / Data Descriptors for no additional benefit. We can use STORED instead.
> - By creating a single LocalDateTime and setting it with `ZipEntry.setTimeLocal`, we can avoid repeated time zone calculations. 
> - The name of entries is generated by calling UUID.randomUUID, we could use simple counter instead.
> - The produced file is unnecessarily large. We know how large a CEN entry is, let's take advantage of that to create a file with the minimal size.
> - By adding a maximally large extra field to the CEN entries, we get away with fewer CEN records and save memory
> - The summary and comments of the test can be improved to help explain the purpose of the test and how we reach the limit being tested.
> 
> These speedups reduced the runtime from 4 min 17 sec to 4 seconds on my Macbook Pro. The produced ZIP size was reduced from 5.7 GB to 2 GB. Memory consumption is down from 8GB to something like 12MB.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12991

From duke at openjdk.org  Tue May 30 03:36:10 2023
From: duke at openjdk.org (duke)
Date: Tue, 30 May 2023 03:36:10 GMT
Subject: Withdrawn: 8302154: Hidden classes created by LambdaMetaFactory can't
 be unloaded
In-Reply-To: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
References: <YoZauVv8zvhdUw-LD25LrsMDItFbg3aXPU3deXwwFdQ=.c2839dea-12e5-4e0e-9579-eac9d8503932@github.com>
Message-ID: <9jRPyKZncBS0LhRp4bXnfJW3RtsurBuODi1eEtcaec4=.1448a4be-8e4d-4de0-8766-a027d39dba2f@github.com>

On Thu, 9 Feb 2023 15:20:23 GMT, Volker Simonis <simonis at openjdk.org> wrote:

> Prior to [JDK-8239384](https://bugs.openjdk.org/browse/JDK-8239384)/[JDK-8238358](https://bugs.openjdk.org/browse/JDK-8238358) LambdaMetaFactory has created VM-anonymous classes which could easily be unloaded once they were not referenced any more. Starting with JDK 15 and the new "hidden class" based implementation, this is not the case any more, because the hidden classes will be strongly tied to their defining class loader. If this is the default application class loader, these hidden classes can never be unloaded which can easily lead to Metaspace exhaustion (see the [test case in the JBS issue](https://bugs.openjdk.org/secure/attachment/102601/LambdaClassLeak.java)). This is a regression compared to previous JDK versions which some of our applications have been affected from when migrating to JDK 17.
> 
> The reason why the newly created hidden classes are strongly linked to their defining class loader is not clear to me. JDK-8239384 mentions it as an "implementation detail":
> 
>> *4. the lambda proxy class has the strong relationship with the class loader (that will share the VM metaspace for its defining loader - implementation details)*
> 
> From my current understanding the strong link between a hidden class created by `LambdaMetaFactory` and its defining class loader is not strictly required. In order to prevent potential OOMs and fix the regression compared the JDK 14 and earlier I propose to create these hidden classes without the `STRONG` option.
> 
> I'll be happy to add the test case as JTreg test to this PR if you think that would be useful.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12493

From eliu at openjdk.org  Tue May 30 03:44:54 2023
From: eliu at openjdk.org (Eric Liu)
Date: Tue, 30 May 2023 03:44:54 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
 [v4]
In-Reply-To: <ah2Znw6zKxUU7O0Qlsq86xaXFiv2wbw-dvkSKxnayfw=.8f07af5e-e6e2-4895-a71b-54fa801927bd@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
 <ah2Znw6zKxUU7O0Qlsq86xaXFiv2wbw-dvkSKxnayfw=.8f07af5e-e6e2-4895-a71b-54fa801927bd@github.com>
Message-ID: <qCj0JFH58oLm5QDdQCqn_iaWIo8T_PSG8fduyfgb4yQ=.332413e3-ff51-4931-8d0d-b18aedb794ea@github.com>

On Mon, 29 May 2023 02:20:07 GMT, Chang Peng <duke at openjdk.org> wrote:

>> In Vector API Java level, vector mask is represented as a boolean array with 0x00/0x01 (8 bits of each element) as values, aka in-memory format. When it is loaded into vector register, e.g. Neon, the in-memory format will be converted to in-register format with 0/-1 value for each lane (lane width aligned to its type) by VectorLoadMask [1] operation, and convert back to in-memory format by VectorStoreMask[2]. In Neon, a typical VectorStoreMask operation will first narrow given vector registers by xtn insn [3] into byte element type, and then do a vector negate to convert to 0x00/0x01 value for each element.
>> 
>> For most of the vector mask operations, the input mask is in-register format. And a vector mask also works in-register format all through the compilation. But for some operations like VectorMask.trueCount()[4] which counts the elements of true value, the expected input mask is in-memory format. So a VectorStoreMask is generated to convert the mask from in-register format to in-memory format before those operations.
>> 
>> However, for trueCount() these xtn instructions in VectorStoreMask can be saved, since the narrowing operations will not influence the number of active lane (value of 0x01) of its input.
>> 
>> This patch adds an optimized rule `VectorMaskTrueCount (VectorStoreMask mask)` to save the unnecessary narrowing operations.
>> 
>> For example,
>> 
>> 
>> var m = VectorMask.fromArray(IntVector.SPECIES_PREFERRED, ba, 0);
>> m.not().trueCount();
>> 
>> 
>> will produce following assembly on a Neon machine before this patch:
>> 
>> 
>> ...
>> mvn     v16.16b, v16.16b           // VectorMask.not()
>> xtn     v16.4h, v16.4s
>> xtn     v16.8b, v16.8h
>> neg     v16.8b, v16.8b             // VectorStoreMask
>> addv    b17, v16.8b
>> umov    w0, v17.b[0]               // VectorMask.trueCount()
>> ...
>> 
>> 
>> After this patch:
>> 
>> 
>> ...
>> mvn     v16.16b, v16.16b           // VectorMask.not()
>> addv    s17, v16.4s
>> smov    x0, v17.b[0]
>> neg     x0, x0                     // Optimized VectorMask.trueCount()
>> ...
>> 
>> 
>> In this case, we can save two xtn insns.
>> 
>> Performance:
>> 
>> Benchmark     Before               After                          Unit
>> testInt           723.822 ? 1.029  1182.375 ? 12.363    ops/ms
>> testLong       632.154 ? 0.197  1382.74 ? 2.188        ops/ms
>> testShort      788.665 ? 1.852   1152.38 ? 3.77         ops/ms
>> 
>> [1]: https://github.com/openjdk/jdk/blob/e1e758a7b43c29840296d337bd2f0213ab0ca3c9/src/hotspot/cpu/aarch64/aarch64_vect...
>
> Chang Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update aarch64_vector.ad

Still looks good to me.

-------------

Marked as reviewed by eliu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13974#pullrequestreview-1450026196

From avu at openjdk.org  Tue May 30 08:20:04 2023
From: avu at openjdk.org (Alexey Ushakov)
Date: Tue, 30 May 2023 08:20:04 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v2]
In-Reply-To: <So49itlN8iwiVZ4-LlECl3FlQEgc_aCTxdIO3lcHW9k=.1d9e68b9-acec-4bb3-b5cc-8abb93482b35@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <So49itlN8iwiVZ4-LlECl3FlQEgc_aCTxdIO3lcHW9k=.1d9e68b9-acec-4bb3-b5cc-8abb93482b35@github.com>
Message-ID: <fgcUzu1tyHuca8vlNWH_YqiTnDDHDvUZd7M3DB1vjsc=.b847b5af-1adb-414a-b4db-eca9d209f3a5@github.com>

On Mon, 29 May 2023 22:29:26 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

Changes requested by avu (Committer).

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 655:

> 653:       // linker loaded it. We use "base diff" in read_lib_segments call below.
> 654: 
> 655:                     if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_ADDR_OFFSET,

Extra white spaces before 'if'

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 662:

> 660: 
> 661:       // read address of the name
> 662:                       if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NAME_OFFSET,

Extra white-spaces before 'if'

src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 717:

> 715: 
> 716:     // read next link_map address
> 717:                     if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NEXT_OFFSET,

Extra white-spaces before 'if'

src/jdk.jpackage/share/native/common/tstrings.cpp line 60:

> 58: #endif
> 59:         // With g++ this compiles only with '-std=gnu++0x' option
> 60:                 ret = vsnprintf(&*fmtout.begin(), fmtout.size(), format, args);

Extra white-spaces before 'ret'

-------------

PR Review: https://git.openjdk.org/jdk/pull/14033#pullrequestreview-1450367357
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209893589
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209894667
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209895275
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1209895801

From duke at openjdk.org  Tue May 30 08:39:11 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 30 May 2023 08:39:11 GMT
Subject: RFR: 8289220: [Shenandoah] TestAllocObjectArrays fails intermittently
Message-ID: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>

command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
error info: 

Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
... 24 more

Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).

Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:

	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)

in LocaleObjectCache.java:64

	 62             if (key == null || newVal == null) {                                
	 63                 // subclass must return non-null key/value object               
	 64                 return null; // run here
	 65             }

-------------

Commit messages:
 - 8289220: [Shenandoah] TestAllocObjectArrays fails intermittently

Changes: https://git.openjdk.org/jdk/pull/14211/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14211&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289220
  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14211.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14211/head:pull/14211

PR: https://git.openjdk.org/jdk/pull/14211

From alanb at openjdk.org  Tue May 30 08:51:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 May 2023 08:51:55 GMT
Subject: RFR: 8289220: [Shenandoah] TestAllocObjectArrays fails
 intermittently
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <za3HlzGMKW5o7NUboUPHhEsyMeNaefos55IFuaeTueA=.a3fe492f-82b8-4ada-8cb6-07835fed56cb@github.com>

On Tue, 30 May 2023 08:31:08 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

I think Locale.forLanguageTag is specified to return null so you might have to do a bit more analysis to see what this issue is about. There are soft refs usages in the locale and it could be that there is some that doesn't handle cases where the ref is cleared.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1568027455

From shade at openjdk.org  Tue May 30 09:13:56 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 30 May 2023 09:13:56 GMT
Subject: RFR: 8289220: [Shenandoah] TestAllocObjectArrays fails
 intermittently
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <Khf56sSw3JSe8EOUBKrt9XozqF-hmHvegBsryx1zwi0=.7f8ee15a-73e6-42dc-9478-c7d9adc3c539@github.com>

On Tue, 30 May 2023 08:31:08 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

This also likely has little to do with Shenandoah itself, and it "only" reproduces because Shenandoah has the aggressively cleaning mode. So the synopsis should reflect the exact issue in `Locale`, once found.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1568070554

From shade at openjdk.org  Tue May 30 09:15:15 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 30 May 2023 09:15:15 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java [v2]
In-Reply-To: <tTB9n3hVd4TnnsEGSOZXyBDI5hhdOdGpLpyLT2ZPnAY=.68c50c5a-f43c-4462-ab6e-4273a3e7e49d@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
 <tTB9n3hVd4TnnsEGSOZXyBDI5hhdOdGpLpyLT2ZPnAY=.68c50c5a-f43c-4462-ab6e-4273a3e7e49d@github.com>
Message-ID: <7rDjvT0nfaLtg9VLvje7Y5lmG9rBbmYfzCbsiPfwz-M=.61a87f3b-a51d-4595-b89e-8552be4eb272@github.com>

On Mon, 29 May 2023 06:48:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> test/jdk/java/util/UUID/UUIDTest.java line 40:
> 
>> 38:     private static final int COUNT = 1_000_000;
>> 39: 
>> 40:     static final Random generator = new Random();
> 
> Hello Aleksey, I realize this is unrelated to the changes in this PR, but since we are updating this test, would using `jdk.test.lib.RandomFactory.getRandom()` from test library be a better idea here? That would then print the seed in the logs and could help debug any collisions more easily?

Yes, good idea, added.

> test/jdk/java/util/UUID/UUIDTest.java line 316:
> 
>> 314:             UUID u2 = UUID.fromString(u1.toString());
>> 315:             if (u1.hashCode() != u2.hashCode()) {
>> 316:                 throw new Exception("Equal UUIDs with different hash codes: " + u1 + " and " + u2);
> 
> Perhaps we should even print the hash codes that weren't matching to provide assistance when debugging?

Yes, added.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14134#discussion_r1209976093
PR Review Comment: https://git.openjdk.org/jdk/pull/14134#discussion_r1209978619

From shade at openjdk.org  Tue May 30 09:15:13 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 30 May 2023 09:15:13 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java [v2]
In-Reply-To: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
Message-ID: <yf5YFLRuy-uQWCyU6qxzN-miPEgrWogWJsBRU55Pv1M=.51bea42a-30ac-4c15-a077-7ba8f6818ed2@github.com>

> UUID is very important class that is used to track identities of objects in large scale systems. Yet, the coverage in JDK test is disappointing: it tests only 100 of UUID instances per test, which is way too small to detect collisions due to the bad randomness for example.
> 
> I have some pending work to improve UUID performance, and tests should be improved. 
> 
> The improved test still runs in less than 5 seconds on my laptop.

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/14134/files
  - new: https://git.openjdk.org/jdk/pull/14134/files/1d302502..48d6bc5c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14134&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14134&range=00-01

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/14134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14134/head:pull/14134

PR: https://git.openjdk.org/jdk/pull/14134

From shade at openjdk.org  Tue May 30 09:17:55 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 30 May 2023 09:17:55 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java
In-Reply-To: <tTB9n3hVd4TnnsEGSOZXyBDI5hhdOdGpLpyLT2ZPnAY=.68c50c5a-f43c-4462-ab6e-4273a3e7e49d@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
 <tTB9n3hVd4TnnsEGSOZXyBDI5hhdOdGpLpyLT2ZPnAY=.68c50c5a-f43c-4462-ab6e-4273a3e7e49d@github.com>
Message-ID: <jLN-Qej_jlYEk8xYSgYWLSxBqbexaWEx6JSTjj6AeNg=.6a06d007-bda8-4b59-834c-fba1c6399485@github.com>

On Mon, 29 May 2023 06:53:35 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Overall, this test-only change look OK to me. 

Thanks for looking at it! I believe I addressed the comments in the revision.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14134#issuecomment-1568078384

From jpai at openjdk.org  Tue May 30 09:27:58 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 May 2023 09:27:58 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java [v2]
In-Reply-To: <yf5YFLRuy-uQWCyU6qxzN-miPEgrWogWJsBRU55Pv1M=.51bea42a-30ac-4c15-a077-7ba8f6818ed2@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
 <yf5YFLRuy-uQWCyU6qxzN-miPEgrWogWJsBRU55Pv1M=.51bea42a-30ac-4c15-a077-7ba8f6818ed2@github.com>
Message-ID: <w8_UI3jN6Dty-ySenurQftBD9gTlTgepjAaKiTzmod0=.cdf03b06-448e-4057-aeb1-952436f7df3e@github.com>

On Tue, 30 May 2023 09:15:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> UUID is very important class that is used to track identities of objects in large scale systems. Yet, the coverage in JDK test is disappointing: it tests only 100 of UUID instances per test, which is way too small to detect collisions due to the bad randomness for example.
>> 
>> I have some pending work to improve UUID performance, and tests should be improved. 
>> 
>> The improved test still runs in less than 5 seconds on my laptop.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Thank you for the updates, Aleksey. This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14134#pullrequestreview-1450508507

From jlahoda at openjdk.org  Tue May 30 09:35:02 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 30 May 2023 09:35:02 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v2]
In-Reply-To: <KMys6Yuo20zpt9-NUcVdE9i0bK6h2Rx5XdL57sIWo1s=.7f52b357-882d-47e3-b1d2-059562490b02@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
 <I2onL10Ro48dfUZASSphE5PkWvaVQoWa4l2-EoxSZ5c=.dfe9629e-9b4f-46ff-8fa1-9404142da1f0@github.com>
 <KMys6Yuo20zpt9-NUcVdE9i0bK6h2Rx5XdL57sIWo1s=.7f52b357-882d-47e3-b1d2-059562490b02@github.com>
Message-ID: <4CAXWr5Ffw1orbTvcsHvyPFFVOBRPvDjrrWAVGVwFLA=.2963e519-8547-4101-84f5-d1a25273c785@github.com>

On Mon, 29 May 2023 07:33:36 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> Also there is a lot of use cases where the type switch is called only with instances of the same class, for those scenarii, the VM should be able to fully remove the type switch and inline the body of the corresponding case like this is done with a virtual call.
>> 
>> I don't think there is a way currently to explain to the VM that the a hash map really acts as a cache so if the key is a constant then the value is a constant too (this optimization is also missing when JITing ClassValue.get()).
>
> @forax 
> 
> Hi! Sorry for this sudden message, but this one captured my attention
> 
>> and subtype checks are usually fast.
> 
> And I hope this PR to be the right place to raise this.
> 
> I was looking this PR to better understand how it applies to secondary supers and https://bugs.openjdk.org/browse/JDK-8180450 (that's still WIP) doesn't look like subtype checks are yet fast nor scalable (with multiple interfaces and > 1 receiver types observed) - see https://ionutbalosin.com/2023/03/jvm-performance-comparison-for-jdk-17/#typecheckscalabilitybenchmark that can be modified to use type switch too.
>  
> In addition, at least for secondary types, a missed `IsInstance` (ie which type isn't implemented) can cost O(n) over the secondary supers types (see https://ionutbalosin.com/2023/03/jvm-performance-comparison-for-jdk-17/#typecheckslowpathbenchmark) that's still not ideal, due to the high bootstrapping cost of `prnz scas`.
> 
> Hence, the implementation of type switch is likely to account for the existing (performance) deficiencies of the secondary supers type check or is relying on the fix https://bugs.openjdk.org/browse/JDK-8180450 that will appear at some point?
> 
> Hope to have interacted in the right way with this with the JDK dev community, and thanks again for your hard work on this wonderful piece of engineering!

@franz1981, thanks for your comment. I am afraid I don't know much about JDK-8180450, but I suspect that it will affect the (type) switch lookup. Please correct me if I am wrong, but it seems this patch is still an improvement over the current state, and when JDK-8180450 is resolved, it should automatically improve the type switch lookup as well. So, this patch still seems useful to me, with a potential for future improvements, both inside and outside type switch bootstrap itself.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9779#issuecomment-1568108121

From duke at openjdk.org  Tue May 30 09:35:53 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 30 May 2023 09:35:53 GMT
Subject: RFR: 8289220: [Shenandoah] TestAllocObjectArrays fails
 intermittently
In-Reply-To: <za3HlzGMKW5o7NUboUPHhEsyMeNaefos55IFuaeTueA=.a3fe492f-82b8-4ada-8cb6-07835fed56cb@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <za3HlzGMKW5o7NUboUPHhEsyMeNaefos55IFuaeTueA=.a3fe492f-82b8-4ada-8cb6-07835fed56cb@github.com>
Message-ID: <KD9NeUlu0sYga1s4cKWCLyiM7Qg7k7I3j_bgwhyqyiw=.db670ab3-6db7-4d82-acd4-e4d1c3daeb35@github.com>

On Tue, 30 May 2023 08:49:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> I don't think Locale.forLanguageTag is specified to return null so you might have to do a bit more analysis to see what this issue is about. There are soft refs usages in the locale and it could be that there is some that doesn't handle cases where the ref is cleared.

as @AlanBateman said, this patch may not be the radical solution.  But once executed here, the ` return null` should be handled.

 62             if (key == null || newVal == null) {                                
 63                 // subclass must return non-null key/value object               
 64                 return null; // then what we can do?
 65             }

-XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot can trigger frequent GC without caring if the memory is really low. So the problem of soft references can be exposed. I suspect that this code is not executed under normal circumstances, so there is no exposure problem.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1568109270

From mcimadamore at openjdk.org  Tue May 30 10:27:05 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 30 May 2023 10:27:05 GMT
Subject: Integrated: 8309042: MemorySegment::reinterpret cleanup action is not
 called for all overloads
In-Reply-To: <GO-WQcxxoNyrLynuGrm1gD998Y_OkGLO0iJdXlOtiJQ=.2157f0de-ba42-40b2-b3aa-12ee661625fa@github.com>
References: <GO-WQcxxoNyrLynuGrm1gD998Y_OkGLO0iJdXlOtiJQ=.2157f0de-ba42-40b2-b3aa-12ee661625fa@github.com>
Message-ID: <KozD_T6orB68_ENOsMKZsauARfznVG-oof4pfXHYi00=.05a9e16f-216e-49fd-a65e-9265c8f2ccd1@github.com>

On Mon, 29 May 2023 10:39:19 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> There's an obvious bug in `AbstractMemorySegmentImpl::reinterpret(long, Arena, Consumer)`: this method does not pass the consumer down to the internal implementation method (it just passes `null`). As a result, the cleanup is not registered.

This pull request has now been integrated.

Changeset: 2b186e24
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b186e246e8c51d4fd8b659872c95044f15e6951
Stats:     16 lines in 2 files changed: 15 ins; 0 del; 1 mod

8309042: MemorySegment::reinterpret cleanup action is not called for all overloads

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/14199

From alanb at openjdk.org  Tue May 30 10:27:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 May 2023 10:27:57 GMT
Subject: RFR: 8289220: [Shenandoah] TestAllocObjectArrays fails
 intermittently
In-Reply-To: <za3HlzGMKW5o7NUboUPHhEsyMeNaefos55IFuaeTueA=.a3fe492f-82b8-4ada-8cb6-07835fed56cb@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <za3HlzGMKW5o7NUboUPHhEsyMeNaefos55IFuaeTueA=.a3fe492f-82b8-4ada-8cb6-07835fed56cb@github.com>
Message-ID: <fnimS7A_RdcattPNtIS1y0I5SZ5ERVlAjmPM-6kkqUE=.7c2a3636-19b5-4047-a079-373c74b59093@github.com>

On Tue, 30 May 2023 08:49:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> I don't think Locale.forLanguageTag is specified to return null so you might have to do a bit more analysis to see what this issue is about. There are soft refs usages in the locale and it could be that there is some that doesn't handle cases where the ref is cleared.

> as @AlanBateman said, this patch may not be the radical solution. But once executed here, the ` return null` should be handled.

No, we can't return null if the API isn't already specified to return null. I think you'll need to dig into soft ref usages in this code as I assume there is clearing happening at a time that the code doesn't expect. It's unlikely to be specific to ShenandoahGC.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1568186424

From duke at openjdk.org  Tue May 30 12:49:11 2023
From: duke at openjdk.org (Chang Peng)
Date: Tue, 30 May 2023 12:49:11 GMT
Subject: Integrated: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
In-Reply-To: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
Message-ID: <OSursyMyDJbMzboyYl86fQ9gh92yNV_l-MVv2ky4_dw=.4d6b36a4-fe8d-4984-854d-3281eb75b3bd@github.com>

On Mon, 15 May 2023 02:58:46 GMT, Chang Peng <duke at openjdk.org> wrote:

> In Vector API Java level, vector mask is represented as a boolean array with 0x00/0x01 (8 bits of each element) as values, aka in-memory format. When it is loaded into vector register, e.g. Neon, the in-memory format will be converted to in-register format with 0/-1 value for each lane (lane width aligned to its type) by VectorLoadMask [1] operation, and convert back to in-memory format by VectorStoreMask[2]. In Neon, a typical VectorStoreMask operation will first narrow given vector registers by xtn insn [3] into byte element type, and then do a vector negate to convert to 0x00/0x01 value for each element.
> 
> For most of the vector mask operations, the input mask is in-register format. And a vector mask also works in-register format all through the compilation. But for some operations like VectorMask.trueCount()[4] which counts the elements of true value, the expected input mask is in-memory format. So a VectorStoreMask is generated to convert the mask from in-register format to in-memory format before those operations.
> 
> However, for trueCount() these xtn instructions in VectorStoreMask can be saved, since the narrowing operations will not influence the number of active lane (value of 0x01) of its input.
> 
> This patch adds an optimized rule `VectorMaskTrueCount (VectorStoreMask mask)` to save the unnecessary narrowing operations.
> 
> For example,
> 
> 
> var m = VectorMask.fromArray(IntVector.SPECIES_PREFERRED, ba, 0);
> m.not().trueCount();
> 
> 
> will produce following assembly on a Neon machine before this patch:
> 
> 
> ...
> mvn     v16.16b, v16.16b           // VectorMask.not()
> xtn     v16.4h, v16.4s
> xtn     v16.8b, v16.8h
> neg     v16.8b, v16.8b             // VectorStoreMask
> addv    b17, v16.8b
> umov    w0, v17.b[0]               // VectorMask.trueCount()
> ...
> 
> After this patch:
> 
> 
> ...
> mvn     v16.16b, v16.16b           // VectorMask.not()
> addv    s17, v16.4s
> smov    x0, v17.b[0]
> neg     x0, x0                     // Optimized VectorMask.trueCount()
> ...
> 
> 
> In this case, we can save two xtn insns.
> 
> Performance:
> 
> Benchmark     Before               After                          Unit
> testInt           723.822 ? 1.029  1182.375 ? 12.363    ops/ms
> testLong       632.154 ? 0.197  1382.74 ? 2.188        ops/ms
> testShort      788.665 ? 1.852   1152.38 ? 3.77         ops/ms
> 
> [1]: https://github.com/openjdk/jdk/blob/e1e758a7b43c29840296d337bd2f0213ab0ca3c9/src/hotspot/cpu/aarch64/aarch64_vector.ad#L4740
> [2]: https://github.com/openjdk/jdk/blo...

This pull request has now been integrated.

Changeset: f600d036
Author:    changpeng1997 <Chang.Peng at arm.com>
Committer: Eric Liu <eliu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f600d0369a1f9ac78e62a328be4bbb598ffef62b
Stats:     235 lines in 5 files changed: 235 ins; 0 del; 0 mod

8307795: AArch64: Optimize VectorMask.truecount() on Neon

Reviewed-by: aph, eliu

-------------

PR: https://git.openjdk.org/jdk/pull/13974

From jvernee at openjdk.org  Tue May 30 12:50:24 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 30 May 2023 12:50:24 GMT
Subject: RFR: 8308992: New test TestHFA fails with zero
Message-ID: <P_pgCjr-32xEQbddgTW9HZYTCbZ6wG7DssmItlEpYcU=.e326e188-1dfc-46e7-a542-278f259139fa@github.com>

The issue is that the fallback linker uses `copyFrom` when copying a by-value struct argument to an internal buffer, without first adjusting the size of the argument segment. This means that if the argument segment is 'too large' (i.e. larger than the layout it was linked with) we fail with an exception since the internal buffer is too small for the entire argument segment to be copied into.

The fix is simply to use an exactly-sized copy instead, just like we do in other linker implementations. (The argument segment being too large is fine, all we care about is that it's large enough).

Testing: jdk-tier5

-------------

Commit messages:
 - Use exactly-sized copy in fallback linker for by-value structs

Changes: https://git.openjdk.org/jdk/pull/14215/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14215&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308992
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14215.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14215/head:pull/14215

PR: https://git.openjdk.org/jdk/pull/14215

From mdoerr at openjdk.org  Tue May 30 13:05:57 2023
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 30 May 2023 13:05:57 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v2]
In-Reply-To: <j3y1HjxREp6cAdoBMDbEikdF0aAuSWQfXyRqZYS20hM=.7d51faae-601d-4259-a73c-9755ec97740b@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
 <j3y1HjxREp6cAdoBMDbEikdF0aAuSWQfXyRqZYS20hM=.7d51faae-601d-4259-a73c-9755ec97740b@github.com>
Message-ID: <kJWILUZt2Q8JqCs1J_8nBKod6MhC_G_-ToZuh6KA6Jw=.21fcb32d-d57a-4a3e-9f4f-c960b707c9f6@github.com>

On Fri, 26 May 2023 15:45:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
>> 
>> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
>> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
>> The enum values directly reflect the build-time artifacts and resulting executables.
>> 
>> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions

Thanks for the updates! Unfortunately, there's still something going wrong on ppc64le:
- jdk/internal/util/ArchTest.java: System property os.arch: "ppc64le", Architecture.current(): "PPC64"
- tools/jlink/plugins/CDSPluginTest.java: Cannot generate CDS archives: target image platform linux-ppc64le is different from runtime platform linux-ppc64

Do you happen to know why Architecture.current() misses the "le"?

-------------

PR Review: https://git.openjdk.org/jdk/pull/14063#pullrequestreview-1450887127

From simonis at openjdk.org  Tue May 30 13:19:37 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 30 May 2023 13:19:37 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v8]
In-Reply-To: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
Message-ID: <yVKqFXJf9za_5tyPk84jCYhAKL_BplPd2PRK-USgCrs=.03492282-1aa6-4c87-9a82-b7fa6d43d2fe@github.com>

> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
> 
> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
> 
> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
> 
> Also did some cleanup:
>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.

Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:

  Enable JspawnhelperProtocol test on AIX as well because AIX also uses posix_spawn

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13956/files
  - new: https://git.openjdk.org/jdk/pull/13956/files/13fb0bf7..3a0e44b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13956&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13956&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13956.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13956/head:pull/13956

PR: https://git.openjdk.org/jdk/pull/13956

From simonis at openjdk.org  Tue May 30 13:20:09 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 30 May 2023 13:20:09 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v7]
In-Reply-To: <R6DVMij5x0AMpm-QIduWF1NnfmpP86FDRkXaZ2474Ms=.85ac8e8a-3d29-4c57-baa9-4e8e830dad5d@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <R6DVMij5x0AMpm-QIduWF1NnfmpP86FDRkXaZ2474Ms=.85ac8e8a-3d29-4c57-baa9-4e8e830dad5d@github.com>
Message-ID: <RDrVeK7ys0Nh49S8k8WaRssfHs8YwL9EKrDGBr0tKMg=.7ecdd964-17ee-4d68-b1de-e88e1b9a2475@github.com>

On Thu, 25 May 2023 15:25:40 GMT, Volker Simonis <simonis at openjdk.org> wrote:

>> Since JDK13, executing commands in a sub-process defaults to the so called `POSIX_SPAWN` launching mechanism (i.e. `-Djdk.lang.Process.launchMechanism=POSIX_SPAWN`) on Linux. This works by using `posix_spawn(3)` to firstly start a tiny helper program called `jspawnhelper` in a subprocess. In a second step, `jspawnhelper` reads the command data from the parent Java process over a Unix pipe and finally executes (i.e. `execvp(3)`) the requested command.
>> 
>> In cases where the parent process terminates abnormally before `jspawnhelper` has read all the expected data from the pipe, `jspawnhelper` will block indefinitely on the reading end of the pipe. This is especially harmful if the parent process had open sockets, because in that case, the forked `jspawnhelper` process will inherit them and keep all the corresponding ports open effectively preventing other processes to bind to them. Notice that this is not an abstract scenario. We've observed this regularly in production with services which couldn't be restarted after a crash after migrating to JDK 17.
>> 
>> The fix of the issue is rather trivial. `jspawnhelper` has to close its writing end of the pipe which connects it with the parent Java process *before* starting to read from that pipe such that reads from the pipe can immediately return with EOF if the parent process terminates abnormally.
>> 
>> Also did some cleanup:
>>  - in `jspawnhelper.c` correctly chek the result of `readFully()`
>>  - in `ProcessImpl_md.c` use `restartableWrite()` instead of `write()` to write the command data from the parent process to `jspawnhelper`
>>  - in `childproc.{c,h}` remove remaining traces of `MODE_CLONE` because that's long gone.
>
> Volker Simonis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix for failing CloseRace test

@TheRealMDoerr from SAP was so kind to run this PR through their test system and in particular verified that the new version including the test works fine on AIX as well (notice that AIX also uses posix_spawn by default).

I've therefor enabled the test on AIX as well.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1568420518

From simonis at openjdk.org  Tue May 30 13:28:05 2023
From: simonis at openjdk.org (Volker Simonis)
Date: Tue, 30 May 2023 13:28:05 GMT
Subject: RFR: 8307990: jspawnhelper must close its writing side of a pipe
 before reading from it [v7]
In-Reply-To: <Oi1ArfWySswooqIBtoqsG6TlsuOJCgvYHzkS-o-mWuk=.cb5beafd-adcc-46af-9440-785ca73749ec@github.com>
References: <vCfEoYf6K22OMl7bIXBQG2hO8mkfwFlrCb5--dFvrl4=.cd362b76-6f8a-4a66-b4c5-faf7c5d8c0aa@github.com>
 <R6DVMij5x0AMpm-QIduWF1NnfmpP86FDRkXaZ2474Ms=.85ac8e8a-3d29-4c57-baa9-4e8e830dad5d@github.com>
 <Oi1ArfWySswooqIBtoqsG6TlsuOJCgvYHzkS-o-mWuk=.cb5beafd-adcc-46af-9440-785ca73749ec@github.com>
Message-ID: <Elz1yDpVKiZh2MDj_GGFbLrjDQbHkx6yWCj4C9a4NcI=.7500bd79-679a-4389-88ae-e7ecf2366c82@github.com>

On Fri, 26 May 2023 17:23:01 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Still think it would be cleaner and simpler to set the FD in the parent to CLOEXEC, before doing posix_spawn, and at the same time set the childStuff variable to -1 to prevent the child from attempting to re-close it. Reconsider?

As you say yourself, this code is complex and I therefor hesitate to do any refactoring of the code just to make it "cleaner any simpler" (at least not now in this PR).

@tstuefe, do you still plan to look at the latest version? Otherwise I want to push this in the next day or two.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13956#issuecomment-1568432978

From jiefu at openjdk.org  Tue May 30 13:40:26 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 30 May 2023 13:40:26 GMT
Subject: RFR: 8309110: Build failure after JDK-8307795 due to warnings in
 micro-benchmark StoreMaskTrueCount.java
Message-ID: <0i0eIxqD5VUaxhQZMrvWAD1yko7iITRyhzTgdCXS6xA=.f8f176c2-6ba6-4dfb-b957-08c1e75cbaf7@github.com>

Just remove the `static` to fix the build failure.
Thanks.

-------------

Commit messages:
 - 8309110: Build failure after JDK-8307795 due to warnings in micro-bechmark StoreMaskTrueCount.java

Changes: https://git.openjdk.org/jdk/pull/14218/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14218&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309110
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14218.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14218/head:pull/14218

PR: https://git.openjdk.org/jdk/pull/14218

From thartmann at openjdk.org  Tue May 30 13:41:21 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 May 2023 13:41:21 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
 [v4]
In-Reply-To: <ah2Znw6zKxUU7O0Qlsq86xaXFiv2wbw-dvkSKxnayfw=.8f07af5e-e6e2-4895-a71b-54fa801927bd@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
 <ah2Znw6zKxUU7O0Qlsq86xaXFiv2wbw-dvkSKxnayfw=.8f07af5e-e6e2-4895-a71b-54fa801927bd@github.com>
Message-ID: <QEqzRX3aSLI38lY5pAVZmNjvkFAWLoZIINgeCJ8yXmc=.68b83a51-cd6b-4835-ae92-96eae91799fa@github.com>

On Mon, 29 May 2023 02:20:07 GMT, Chang Peng <duke at openjdk.org> wrote:

>> In Vector API Java level, vector mask is represented as a boolean array with 0x00/0x01 (8 bits of each element) as values, aka in-memory format. When it is loaded into vector register, e.g. Neon, the in-memory format will be converted to in-register format with 0/-1 value for each lane (lane width aligned to its type) by VectorLoadMask [1] operation, and convert back to in-memory format by VectorStoreMask[2]. In Neon, a typical VectorStoreMask operation will first narrow given vector registers by xtn insn [3] into byte element type, and then do a vector negate to convert to 0x00/0x01 value for each element.
>> 
>> For most of the vector mask operations, the input mask is in-register format. And a vector mask also works in-register format all through the compilation. But for some operations like VectorMask.trueCount()[4] which counts the elements of true value, the expected input mask is in-memory format. So a VectorStoreMask is generated to convert the mask from in-register format to in-memory format before those operations.
>> 
>> However, for trueCount() these xtn instructions in VectorStoreMask can be saved, since the narrowing operations will not influence the number of active lane (value of 0x01) of its input.
>> 
>> This patch adds an optimized rule `VectorMaskTrueCount (VectorStoreMask mask)` to save the unnecessary narrowing operations.
>> 
>> For example,
>> 
>> 
>> var m = VectorMask.fromArray(IntVector.SPECIES_PREFERRED, ba, 0);
>> m.not().trueCount();
>> 
>> 
>> will produce following assembly on a Neon machine before this patch:
>> 
>> 
>> ...
>> mvn     v16.16b, v16.16b           // VectorMask.not()
>> xtn     v16.4h, v16.4s
>> xtn     v16.8b, v16.8h
>> neg     v16.8b, v16.8b             // VectorStoreMask
>> addv    b17, v16.8b
>> umov    w0, v17.b[0]               // VectorMask.trueCount()
>> ...
>> 
>> After this patch:
>> 
>> 
>> ...
>> mvn     v16.16b, v16.16b           // VectorMask.not()
>> addv    s17, v16.4s
>> smov    x0, v17.b[0]
>> neg     x0, x0                     // Optimized VectorMask.trueCount()
>> ...
>> 
>> 
>> In this case, we can save two xtn insns.
>> 
>> Performance:
>> 
>> Benchmark     Before               After                          Unit
>> testInt           723.822 ? 1.029  1182.375 ? 12.363    ops/ms
>> testLong       632.154 ? 0.197  1382.74 ? 2.188        ops/ms
>> testShort      788.665 ? 1.852   1152.38 ? 3.77         ops/ms
>> 
>> [1]: https://github.com/openjdk/jdk/blob/e1e758a7b43c29840296d337bd2f0213ab0ca3c9/src/hotspot/cpu/aarch64/aarch64_vector....
>
> Chang Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update aarch64_vector.ad

This change broke the builds: [JDK-8309110](https://bugs.openjdk.org/browse/JDK-8309110).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13974#issuecomment-1568452973

From thartmann at openjdk.org  Tue May 30 13:46:09 2023
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Tue, 30 May 2023 13:46:09 GMT
Subject: RFR: 8309110: Build failure after JDK-8307795 due to warnings in
 micro-benchmark StoreMaskTrueCount.java
In-Reply-To: <0i0eIxqD5VUaxhQZMrvWAD1yko7iITRyhzTgdCXS6xA=.f8f176c2-6ba6-4dfb-b957-08c1e75cbaf7@github.com>
References: <0i0eIxqD5VUaxhQZMrvWAD1yko7iITRyhzTgdCXS6xA=.f8f176c2-6ba6-4dfb-b957-08c1e75cbaf7@github.com>
Message-ID: <Friidft_v0ipkUXVMrFOLLuMkjF8dryUuLdmV8nSg1g=.6a09c9e5-b802-452c-b323-fe9a885195fd@github.com>

On Tue, 30 May 2023 13:31:16 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Just remove the `static` to fix the build failure.
> Thanks.

Looks good and trivial.

-------------

Marked as reviewed by thartmann (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14218#pullrequestreview-1450983424

From jiefu at openjdk.org  Tue May 30 13:46:11 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 30 May 2023 13:46:11 GMT
Subject: RFR: 8309110: Build failure after JDK-8307795 due to warnings in
 micro-benchmark StoreMaskTrueCount.java
In-Reply-To: <Friidft_v0ipkUXVMrFOLLuMkjF8dryUuLdmV8nSg1g=.6a09c9e5-b802-452c-b323-fe9a885195fd@github.com>
References: <0i0eIxqD5VUaxhQZMrvWAD1yko7iITRyhzTgdCXS6xA=.f8f176c2-6ba6-4dfb-b957-08c1e75cbaf7@github.com>
 <Friidft_v0ipkUXVMrFOLLuMkjF8dryUuLdmV8nSg1g=.6a09c9e5-b802-452c-b323-fe9a885195fd@github.com>
Message-ID: <NRTQMjAtRfxprExZ46kEKL8p0vB8kc9hRRGghYG2H74=.0e4c1eb5-4edd-4365-8c6b-8f4ca1de550d@github.com>

On Tue, 30 May 2023 13:40:42 GMT, Tobias Hartmann <thartmann at openjdk.org> wrote:

> Looks good and trivial.

Thanks @TobiHartmann .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14218#issuecomment-1568458529

From jiefu at openjdk.org  Tue May 30 13:46:12 2023
From: jiefu at openjdk.org (Jie Fu)
Date: Tue, 30 May 2023 13:46:12 GMT
Subject: Integrated: 8309110: Build failure after JDK-8307795 due to warnings
 in micro-benchmark StoreMaskTrueCount.java
In-Reply-To: <0i0eIxqD5VUaxhQZMrvWAD1yko7iITRyhzTgdCXS6xA=.f8f176c2-6ba6-4dfb-b957-08c1e75cbaf7@github.com>
References: <0i0eIxqD5VUaxhQZMrvWAD1yko7iITRyhzTgdCXS6xA=.f8f176c2-6ba6-4dfb-b957-08c1e75cbaf7@github.com>
Message-ID: <bxebGFDNCod5vy2kFu6uIfswTbSTMLosq0VPGKpAhd0=.c7112f0b-324b-49c5-9d54-849a261398e7@github.com>

On Tue, 30 May 2023 13:31:16 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Just remove the `static` to fix the build failure.
> Thanks.

This pull request has now been integrated.

Changeset: 15e02853
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/15e028530ad6408693e9f21fb94daa705b951897
Stats:     4 lines in 1 file changed: 0 ins; 0 del; 4 mod

8309110: Build failure after JDK-8307795 due to warnings in micro-benchmark StoreMaskTrueCount.java

Reviewed-by: thartmann

-------------

PR: https://git.openjdk.org/jdk/pull/14218

From mcimadamore at openjdk.org  Tue May 30 14:40:58 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 30 May 2023 14:40:58 GMT
Subject: RFR: 8308992: New test TestHFA fails with zero
In-Reply-To: <P_pgCjr-32xEQbddgTW9HZYTCbZ6wG7DssmItlEpYcU=.e326e188-1dfc-46e7-a542-278f259139fa@github.com>
References: <P_pgCjr-32xEQbddgTW9HZYTCbZ6wG7DssmItlEpYcU=.e326e188-1dfc-46e7-a542-278f259139fa@github.com>
Message-ID: <e1jED6F9qsF8udNkGXiNfn0o7XYIcdpIwDJidce5kME=.33e92824-4127-4321-bad8-b4f0581540c2@github.com>

On Tue, 30 May 2023 12:17:00 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> The issue is that the fallback linker uses `copyFrom` when copying a by-value struct argument to an internal buffer, without first adjusting the size of the argument segment. This means that if the argument segment is 'too large' (i.e. larger than the layout it was linked with) we fail with an exception since the internal buffer is too small for the entire argument segment to be copied into.
> 
> The fix is simply to use an exactly-sized copy instead, just like we do in other linker implementations. (The argument segment being too large is fine, all we care about is that it's large enough).
> 
> Testing: jdk-tier5

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14215#pullrequestreview-1451127172

From kbarrett at openjdk.org  Tue May 30 14:42:59 2023
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 30 May 2023 14:42:59 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <Sd028nVao99R40f2WC1j159LGpWtcaUasdFWScfq4Fs=.87d3ca9e-2c13-4bbe-b8ab-c11ab0165d3f@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <Z6J__T8X9bDvrfFjUxNImPMEUwKQmbESvmzYUeDolkQ=.9309297e-ab60-4cd5-9a20-687d545101a8@github.com>
 <G0ZEvXBOXoDAbZOSj0zcDFxcADCi_Mk-hNOvsJiCw58=.443eb739-394c-44da-8e48-6b157ad59045@github.com>
 <nA6t5xQ1QqQJ9UEwtTbAcG9P705u1cjmnmBrWCtbXq4=.1bed9538-5073-4649-bfd6-0f5734b0a967@github.com>
 <IZ4YR_xufzTDcXxB951WwGkcF4icFdEg-fwalgd59qA=.787de67a-2d85-4319-bf74-d73c2bafdf3d@github.com>
 <_XilBe6ie0uDMER4oIjzTgKa2uMbjs-OjJGMH5exY-g=.78341a5f-d44a-49a4-ad82-0d3be2f2ffd3@github.com>
 <lc7fUJc3lm6GhV0G56hZd8ufG4RR1k1Q1cYonp4MAeI=.cef8ed54-11ef-4281-acc3-eb378547fd87@github.com>
 <Sd028nVao99R40f2WC1j159LGpWtcaUasdFWScfq4Fs=.87d3ca9e-2c13-4bbe-b8ab-c11ab0165d3f@github.com>
Message-ID: <s1uZER4abiqIuYdBe6igsIhfGBDTvP3-IkusjvQyaDg=.3184b764-297d-41bb-8056-ff4e5d56bae9@github.com>

On Sat, 27 May 2023 15:33:37 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> I am basically worried that undefining malloc, even if it seems harmless now, exposes us to difficult-to-investigate problems down the road, since it depends on how the libc devs will reform those macros in the future. I would prefer a simple solution that does not depend on how the libc includes evolve.
>
> Is it possible to see the stdlib.h source code that is being a problem?  Maybe more eyes can come up
> with a better solution, or at least come to a better understanding of why we have to go this way.

Technically it's our fault.  The standard library is permitted to provide a
macro replacements for (nearly?) any function.  (C99 7.1.3/1 3rd bullet) But
it's really annoying.  Presumably AIX is only doing so for a subset of the
allocation functions, e.g. not "free" for example.

Having "malloc" defined as a macro seems like it should raise all kinds of
havoc, not just around log tags.  Consider our "os::malloc" function?  The
preprocessor knows nothing about C++ namespace qualifiers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1210388482

From jvernee at openjdk.org  Tue May 30 15:32:07 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 30 May 2023 15:32:07 GMT
Subject: Integrated: 8308992: New test TestHFA fails with zero
In-Reply-To: <P_pgCjr-32xEQbddgTW9HZYTCbZ6wG7DssmItlEpYcU=.e326e188-1dfc-46e7-a542-278f259139fa@github.com>
References: <P_pgCjr-32xEQbddgTW9HZYTCbZ6wG7DssmItlEpYcU=.e326e188-1dfc-46e7-a542-278f259139fa@github.com>
Message-ID: <_e6icMm-OiXwraBunkXhCUPubsJGFWyh5HdGUAt1Whw=.c68df19c-3b8a-47b9-be5f-4d24812da938@github.com>

On Tue, 30 May 2023 12:17:00 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> The issue is that the fallback linker uses `copyFrom` when copying a by-value struct argument to an internal buffer, without first adjusting the size of the argument segment. This means that if the argument segment is 'too large' (i.e. larger than the layout it was linked with) we fail with an exception since the internal buffer is too small for the entire argument segment to be copied into.
> 
> The fix is simply to use an exactly-sized copy instead, just like we do in other linker implementations. (The argument segment being too large is fine, all we care about is that it's large enough).
> 
> Testing: jdk-tier5

This pull request has now been integrated.

Changeset: 804f198c
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/804f198c73794ffce34a8a10c255656c25cf6d79
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8308992: New test TestHFA fails with zero

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/14215

From shade at openjdk.org  Tue May 30 15:47:03 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 30 May 2023 15:47:03 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java [v2]
In-Reply-To: <yf5YFLRuy-uQWCyU6qxzN-miPEgrWogWJsBRU55Pv1M=.51bea42a-30ac-4c15-a077-7ba8f6818ed2@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
 <yf5YFLRuy-uQWCyU6qxzN-miPEgrWogWJsBRU55Pv1M=.51bea42a-30ac-4c15-a077-7ba8f6818ed2@github.com>
Message-ID: <X6kTXI-dOdDPsOkeIJojUyvWenniLF8m9C48TXgDXC4=.52bcd556-c56d-45c6-89a4-99c4f0345d71@github.com>

On Tue, 30 May 2023 09:15:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> UUID is very important class that is used to track identities of objects in large scale systems. Yet, the coverage in JDK test is disappointing: it tests only 100 of UUID instances per test, which is way too small to detect collisions due to the bad randomness for example.
>> 
>> I have some pending work to improve UUID performance, and tests should be improved. 
>> 
>> The improved test still runs in less than 5 seconds on my laptop.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

Thanks! Any other reviewers?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14134#issuecomment-1568666688

From bpb at openjdk.org  Tue May 30 16:20:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 30 May 2023 16:20:06 GMT
Subject: Integrated: 8290499: new File(parent,
 "/") breaks normalization =?UTF-8?B?4oCT?= creates File with slash at the end
In-Reply-To: <8xzVUmIbNYbHrO6ymEBcptZ4uK5saoxx0xXzmdVSc9E=.30439fa6-e4bb-46fb-b1be-0e103a31d6e5@github.com>
References: <8xzVUmIbNYbHrO6ymEBcptZ4uK5saoxx0xXzmdVSc9E=.30439fa6-e4bb-46fb-b1be-0e103a31d6e5@github.com>
Message-ID: <uepyYNXwaoiiihIFn2l3iLvTxDoT6J3uWFzL1bxFkV8=.a1602a94-8f4f-4024-ac6a-a6401c7b0a08@github.com>

On Tue, 23 May 2023 22:49:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `java.io.File`, change the constructors `File(File,String)` and `File(String,String)` so that they do not for typical cases return a `File` whose path has a trailing name separator.

This pull request has now been integrated.

Changeset: 21af8bae
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21af8bae38dd845d5cbeb2b2770e537b5b9bad22
Stats:     34 lines in 3 files changed: 28 ins; 0 del; 6 mod

8290499: new File(parent, "/") breaks normalization ? creates File with slash at the end

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14109

From darcy at openjdk.org  Tue May 30 16:32:57 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 16:32:57 GMT
Subject: RFR: JDK-8308987: Update java.lang.Class to use javadoc snippets
In-Reply-To: <LSlUS9g-UE67vhxSVAnWjS9gBNYS1bpAUrX8qCShn5Q=.9d938300-dfe9-4c09-8109-a93c97c72aa4@github.com>
References: <0yqeEu2-dyUcIiBDInyHLmsbtXmjtqcXiMIZNMDlOC4=.bc254a1d-51c5-4215-80bc-02132e810cab@github.com>
 <LSlUS9g-UE67vhxSVAnWjS9gBNYS1bpAUrX8qCShn5Q=.9d938300-dfe9-4c09-8109-a93c97c72aa4@github.com>
Message-ID: <DQeR9Ch53flb0MGAj8D8m8sIjHBCQaxglxuPKFieLUI=.008de40f-7f08-4d40-b9d1-5e37c778f90f@github.com>

On Sat, 27 May 2023 22:31:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Straightforward doc refactoring to use snippets.
>
> src/java.base/share/classes/java/lang/Class.java line 356:
> 
>> 354:      *
>> 355:      * {@snippet lang="java" :
>> 356:      *   Class<?> t = Class.forName("java.lang.Thread")
> 
> This should have a final semicolon, as it's already a variable declaration and initialization.

Sure; will fix in next push. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14194#discussion_r1210535293

From darcy at openjdk.org  Tue May 30 16:47:37 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 16:47:37 GMT
Subject: RFR: JDK-8308987: Update java.lang.Class to use javadoc snippets
 [v2]
In-Reply-To: <0yqeEu2-dyUcIiBDInyHLmsbtXmjtqcXiMIZNMDlOC4=.bc254a1d-51c5-4215-80bc-02132e810cab@github.com>
References: <0yqeEu2-dyUcIiBDInyHLmsbtXmjtqcXiMIZNMDlOC4=.bc254a1d-51c5-4215-80bc-02132e810cab@github.com>
Message-ID: <noKg7JZ8uhAXS0JbrV3LeSJHOAOVuDuCdDdrKrh2j3M=.ab9e7638-46ca-455d-ad8a-5b06cda996c2@github.com>

> Straightforward doc refactoring to use snippets.

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/14194/files
  - new: https://git.openjdk.org/jdk/pull/14194/files/1e3ee228..6b414c50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14194&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14194&range=00-01

  Stats: 10 lines in 1 file changed: 0 ins; 1 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/14194.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14194/head:pull/14194

PR: https://git.openjdk.org/jdk/pull/14194

From alanb at openjdk.org  Tue May 30 16:47:38 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 May 2023 16:47:38 GMT
Subject: RFR: JDK-8308987: Update java.lang.Class to use javadoc snippets
 [v2]
In-Reply-To: <noKg7JZ8uhAXS0JbrV3LeSJHOAOVuDuCdDdrKrh2j3M=.ab9e7638-46ca-455d-ad8a-5b06cda996c2@github.com>
References: <0yqeEu2-dyUcIiBDInyHLmsbtXmjtqcXiMIZNMDlOC4=.bc254a1d-51c5-4215-80bc-02132e810cab@github.com>
 <noKg7JZ8uhAXS0JbrV3LeSJHOAOVuDuCdDdrKrh2j3M=.ab9e7638-46ca-455d-ad8a-5b06cda996c2@github.com>
Message-ID: <ljMgZGNvFvsGYpUrC8VhgKJeINYbUNurznNsN_k28Kk=.3a179e52-4e9d-41c2-bbae-ce92cb4c97d3@github.com>

On Tue, 30 May 2023 16:42:05 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Straightforward doc refactoring to use snippets.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14194#pullrequestreview-1451378967

From darcy at openjdk.org  Tue May 30 16:47:42 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 16:47:42 GMT
Subject: RFR: JDK-8308987: Update java.lang.Class to use javadoc snippets
 [v2]
In-Reply-To: <mvaU7uAgrjUBsJd7G0OI6Yv1GWeVBEreCOW_uQqO0bU=.a4f61555-1e26-42a0-a344-6811bcf66c3e@github.com>
References: <0yqeEu2-dyUcIiBDInyHLmsbtXmjtqcXiMIZNMDlOC4=.bc254a1d-51c5-4215-80bc-02132e810cab@github.com>
 <mvaU7uAgrjUBsJd7G0OI6Yv1GWeVBEreCOW_uQqO0bU=.a4f61555-1e26-42a0-a344-6811bcf66c3e@github.com>
Message-ID: <SZHqrpfKyNjV7eY5EP3KKrVNB_Tw6XrymZzqta1WBQw=.7e790dc8-f91d-457e-ac7c-3aef7c53ccf8@github.com>

On Sun, 28 May 2023 18:50:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.base/share/classes/java/lang/Class.java line 426:
> 
>> 424:      * {@snippet lang="java" :
>> 425:      *  Class.forName("Foo", true, this.getClass().getClassLoader())
>> 426:      * }
> 
> Not important but there are at least 3 different indentation widths in the update. Does it look okay in the generated javadoc?

The previous blockquote tag normalized the space -- adjusted the leading whitespace to be consistent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14194#discussion_r1210545457

From darcy at openjdk.org  Tue May 30 16:50:05 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 16:50:05 GMT
Subject: Integrated: JDK-8308987: Update java.lang.Class to use javadoc
 snippets
In-Reply-To: <0yqeEu2-dyUcIiBDInyHLmsbtXmjtqcXiMIZNMDlOC4=.bc254a1d-51c5-4215-80bc-02132e810cab@github.com>
References: <0yqeEu2-dyUcIiBDInyHLmsbtXmjtqcXiMIZNMDlOC4=.bc254a1d-51c5-4215-80bc-02132e810cab@github.com>
Message-ID: <Kjif8_diY_3AVV3UHkFCq71Upnm8uP_59hHiIw90pOo=.9dd2325a-3885-49c9-bcb0-93bbe8cccbb5@github.com>

On Sat, 27 May 2023 21:04:51 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Straightforward doc refactoring to use snippets.

This pull request has now been integrated.

Changeset: 1b8e6bf3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1b8e6bf31ccc0eb2db3c26ed2fac2c406eda53be
Stats:     28 lines in 1 file changed: 0 ins; 1 del; 27 mod

8308987: Update java.lang.Class to use javadoc snippets

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/14194

From rriggs at openjdk.org  Tue May 30 17:06:05 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 30 May 2023 17:06:05 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v2]
In-Reply-To: <kJWILUZt2Q8JqCs1J_8nBKod6MhC_G_-ToZuh6KA6Jw=.21fcb32d-d57a-4a3e-9f4f-c960b707c9f6@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
 <j3y1HjxREp6cAdoBMDbEikdF0aAuSWQfXyRqZYS20hM=.7d51faae-601d-4259-a73c-9755ec97740b@github.com>
 <kJWILUZt2Q8JqCs1J_8nBKod6MhC_G_-ToZuh6KA6Jw=.21fcb32d-d57a-4a3e-9f4f-c960b707c9f6@github.com>
Message-ID: <aYE0oM5HDXu-3nH2XAhS_nZ-BWKDiOKy-5pUfjAzKbM=.7ddebacc-5448-42db-87a7-d36402bd9a1e@github.com>

On Tue, 30 May 2023 13:02:52 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Do you happen to know why Architecture.current() misses the "le"?

@TheRealMDoerr  The makefile that does the substitution (in GensrcMisc.gmk) for the OPENJDK_TARGET_CPU is using the _CANONICAL form of the architecture (that maps ppc64le to ppc64).
I'll work up a fix; note that we do want the canonical form for s390x and amd/x86_64.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14063#issuecomment-1568776504

From rriggs at openjdk.org  Tue May 30 17:10:11 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 30 May 2023 17:10:11 GMT
Subject: Integrated: 8308960: Decouple internal Version and OperatingSystem
 classes
In-Reply-To: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
References: <jRwdDut0nOKsjSk2DLFBjc9VQ1NCsLcyAa3TqF7Bexc=.aa136bfd-d48b-4e8e-b823-e004a583edad@github.com>
Message-ID: <f2PJWcmbcEwrgnlmx6xEIiAmj_hq2EmzSssZtdWwanc=.4e46e226-6a68-49e6-a94f-c52a427ddf6a@github.com>

On Fri, 26 May 2023 14:57:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Decouple the jdk.internal.util OperatingSystem and Version classes to simplify class loading and avoid an indirect cyclic initialization.
> 
> Move the method to get the current OS version from OperatingSystem to the Version class and its initialization.
> Revert to using String.toUpperCase() instead of custom code to uppercase.
> 
> Update the uses of OperatingSystem.version to be Version.current.

This pull request has now been integrated.

Changeset: 323d6ced
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/323d6ceda65910abff15e3358435533977519234
Stats:     310 lines in 6 files changed: 137 ins; 143 del; 30 mod

8308960: Decouple internal Version and OperatingSystem classes

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/14181

From lancea at openjdk.org  Tue May 30 17:17:59 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 30 May 2023 17:17:59 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v7]
In-Reply-To: <btivxm6byykZzzPFBTOCqD_7dM3rL0qK6bBDDYUEO-o=.fd151b43-45e9-4002-8b6f-727839674588@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <btivxm6byykZzzPFBTOCqD_7dM3rL0qK6bBDDYUEO-o=.fd151b43-45e9-4002-8b6f-727839674588@github.com>
Message-ID: <9G7z97rhtDyGaWAe8URHd8QhRjNM9QEdtEaTrL-6Hyg=.4a53668d-499e-4c73-bcaa-6c08e09c534a@github.com>

On Wed, 10 May 2023 14:52:58 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> Test is updated to create the binary files during test execution.
>
> Mahendra Chhipa has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented the review comments.

Apologies for the delay, with the RDP1. fast approaching, it has been difficult getting back to this due to other priorities.

Please see the comments below as I feel we can do more to make the tests more streamline/maintainable.

Another datapoint to consider is that this might be a good time to convert the test from _testng_ to _junit_ as that is the preferred direction for our future tests.

test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 114:

> 112:             // generatePseudoCodeForDurationSerBytes(baos2);
> 113:             // generatePseudoCodeForDurationSerBytesAsBase64(base64dur);
> 114:         }

I really do not like this being hidden in the setup method

I still would look to have a method that actually creates the classes.   One example of this:

`open/test/jdk/java/io/Serializable/failureAtomicity/FailureAtomicity.java` and the `createSrc` method

The intent is to make this easier to update/enhance going forward. I would probably have. separate utility class/template which can be run to create the saved serialization classes.

SerializationTest would have an introductory comment outlining how to add additional serialized at a via the utility class.

test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 125:

> 123:     @DataProvider(name = "GregorianCalendarData")
> 124:     public Object [][] gregorianCalendarDataBytes() {
> 125:         return new Object [][] {{System.getProperty("java.version"), gregorianCalendarAndDurationSerData[0], EXPECTED_CAL},

We really only need to call `System.getProperty("java.version")` once in the program and then save off its return value

test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 188:

> 186:         final ObjectInputStream ois = new ObjectInputStream(bais);
> 187:         final XMLGregorianCalendar xgc = (XMLGregorianCalendar) ois.readObject();
> 188:         Assert.assertEquals(xgc.toString(), gregorianDate);

if you:

`import static org.testng.Assert.*;`. then you can simply call `assertEquals`

-------------

PR Review: https://git.openjdk.org/jdk/pull/13537#pullrequestreview-1451413985
PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1210567715
PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1210569626
PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1210580188

From lancea at openjdk.org  Tue May 30 17:18:01 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 30 May 2023 17:18:01 GMT
Subject: RFR: JDK-8077371: Binary files in JAXP test should be removed [v6]
In-Reply-To: <buEZiLiHy_KemMd3F4-WMYJThr-hOop8xhKsL7kryzI=.d0bf52a6-2c40-4be2-8fad-6621cff32328@github.com>
References: <QOlrgHbzoHqNuFhnsTHGNbQfllIoNwyvUB2N4CJjhHI=.1c1d80e7-0870-436c-94ae-217383242059@github.com>
 <fhDJZ45cjHcgp2v9yZe4MFzBGmZxZV-wg4iyQad39fU=.e0a8da91-86cf-4bef-b608-28f9b41cdc5c@github.com>
 <7XeeodEv7RbZQqqbenSrqFrNpOrPY9Svh1xm9smxlCg=.fd871670-0d4d-42a5-add2-e4c73d931290@github.com>
 <buEZiLiHy_KemMd3F4-WMYJThr-hOop8xhKsL7kryzI=.d0bf52a6-2c40-4be2-8fad-6621cff32328@github.com>
Message-ID: <Ti8c2Qt407ORihW8Z-577kUEArn2DqEhKk-5z-oATmw=.69a311f7-e471-4da9-8b1d-7cc26d030429@github.com>

On Wed, 10 May 2023 14:41:02 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

>> test/jdk/javax/xml/jaxp/datatype/8033980/SerializationTest.java line 232:
>> 
>>> 230:      * JDK<version>GregorianCalendarAndDurationSerData.java files.
>>> 231:      * @param baos
>>> 232:      */
>> 
>> I think there needs to be a general comment describing how these methods are used to create the JDK<version>GregorianCalendarAndDurationSerData.java files.  There should also be a description/comment for the methods defined in GregorianCalendarAndDurationSerData.java
>> 
>> We need to try and put ourselves in the place of a future maintainer who needs to understand how to  create a version of one of these files.
>> 
>> You could probably also create a method which generates a JDK<version>GregorianCalendarAndDurationSerData.java file to save the developer from multiple cut an pastes.
>> 
>> At a minimum, there really should be a step by step guide
>
> How these methods can be used, added comment regarding this under setup method. Added description for the methods defined in GregorianCalendarAndDurationSerData.java file. Now developer should be able to create the <JDK version >GregorianCalendarAndDurationSerData.java file after reading these comments.

Please see comment above in the setUp method as I feel we can do more here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13537#discussion_r1210570990

From darcy at openjdk.org  Tue May 30 17:25:36 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 17:25:36 GMT
Subject: RFR: JDK-8308913: Update core reflection for JEP 445 (preview)
 [v2]
In-Reply-To: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
References: <bCiHjhOm7dga3_W1qNQRgJEkG1YdD1wIfY6B52wqgg8=.9c6402fe-e945-4c13-9038-6e29c1b42b54@github.com>
Message-ID: <7Tw13M0w5IYpZoA1B2vyyd1uz60jQ45tKtbVnoaltY8=.9c054121-7f9e-494d-aed1-73c6c4e56004@github.com>

> Explain in java.lang.Class how unnamed classes are modeled in 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 seven additional commits since the last revision:

 - Merge branch 'master' into JDK-8308913
 - Implement review feedback.
 - Merge branch 'master' into JDK-8308913
 - Cleanup and edit text.
 - Respond to review comments.
 - Appease jcheck.
 - JDK-8308913: Update core reflection for JEP 445 (preview)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14165/files
  - new: https://git.openjdk.org/jdk/pull/14165/files/1fcea4e4..ffdbbecd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14165&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14165&range=00-01

  Stats: 8218 lines in 181 files changed: 5707 ins; 635 del; 1876 mod
  Patch: https://git.openjdk.org/jdk/pull/14165.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14165/head:pull/14165

PR: https://git.openjdk.org/jdk/pull/14165

From xuelei at openjdk.org  Tue May 30 17:32:02 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 30 May 2023 17:32:02 GMT
Subject: RFR: 8308022: update for deprecated sprintf for java.base [v2]
In-Reply-To: <KoGd_keDUhRHvaB5YVqBVtzbuXxlaTdWdbrc1dylFK8=.6c7411d0-6c71-431f-8968-03e823774ca6@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
 <KoGd_keDUhRHvaB5YVqBVtzbuXxlaTdWdbrc1dylFK8=.6c7411d0-6c71-431f-8968-03e823774ca6@github.com>
Message-ID: <iil-LcffCXH_5m0NkgDeOYUH5IrULucc34oHX96Jyq4=.d3e682db-6065-4079-ba6b-7e0b123fa8fc@github.com>

On Wed, 24 May 2023 19:20:09 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   exclude update for libnet

ping ...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13963#issuecomment-1568809395

From forax at openjdk.org  Tue May 30 17:35:18 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 30 May 2023 17:35:18 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
 [v2]
In-Reply-To: <UW0KwW5uYPaaKzTgCRM2I6_R78E26N2SFDJPi-tjSvE=.4463ad73-3d3f-49c9-bc4f-c27c1decf11b@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
 <UW0KwW5uYPaaKzTgCRM2I6_R78E26N2SFDJPi-tjSvE=.4463ad73-3d3f-49c9-bc4f-c27c1decf11b@github.com>
Message-ID: <ahxbOuGvkLfyetjIRr1bWZcza0DGH0RBxGwf95--k3A=.0825afc3-e9e6-44f4-9b4e-4ee55669ee3c@github.com>

On Thu, 25 May 2023 08:21:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is the implementation of:
>> 
>> - JEP 453: Structured Concurrency (Preview)
>> - JEP 446: Scoped Values (Preview)
>> 
>> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
>> 
>> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
>> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Sync up from loom repo
>  - Remove csm.Threads
>  - Merge
>  - Test should not be in update for main line
>  - Sync with loom repo
>  - Sync up tests frmo loom repo
>  - Sync up with loom repo
>  - Sync update API/impl/tests
>  - Merge
>  - Sync up with loom repo
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/89f2d458...e92ba524

I've rewritten all my tests to use the new API, it works !
https://github.com/forax/loom-fiber/tree/java21

One surprising thing is that Subtask.get() give less leeway to the owner thread than to the other virtual threads so in onComplete() storing a Subtask to use it later by the owner thread does not work well if join() is not called yet.
This is perhaps a bit too much.

Anyway, good for me !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13932#issuecomment-1568813363

From mchung at openjdk.org  Tue May 30 17:37:24 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 30 May 2023 17:37:24 GMT
Subject: RFR: 8307944: ClassFileDumper should only load java.nio.file.Path
 if enabled [v2]
In-Reply-To: <jdahgZeAZtruycStvqWmSB3YbdTCN063GjMRXP9xJy0=.e3b786d2-d2be-47e1-a258-f7f5e0d61c7a@github.com>
References: <jdahgZeAZtruycStvqWmSB3YbdTCN063GjMRXP9xJy0=.e3b786d2-d2be-47e1-a258-f7f5e0d61c7a@github.com>
Message-ID: <jel6LZc8bw7gZ5sEZuNauyl3Njqa_J5BXZv_wS_fYrU=.94de6e21-14ac-4e5c-9b96-52313c8a336f@github.com>

> Change `ClassFileDumper` constructor to take a `String` rather than `Path` to avoid the file system implementation classes loaded during startup.  In addition, `FilePermission` also causes the default file system to be initialized. 
> 
> This patch changes `ClassFileDumper` to validate the given path only if it's enabled and not to use limited `doPrivileged` to avoid the initialization of `FilePermission` class and the file system implementation classes by default.
> 
> This patch also changes `ClassFileDumper::write` to use `File` instead of `Path` because of JDK-8306678.  `OperatingSystem::<clinit>` causes `Enum::valueOf` to be called which calls core reflection which in turns invokes method handles.   If `-Djdk.invoke.MethodHandle.dumpMethodHandleInternals` is set, VM initialization would fail because `BootLoader::<clinit>` causes `ClassLoaderHelper` to initialize which in turn causes `OperatingSystem` be initialized.   If additional LFs are spinned and dumped, if `ClassFileDumper` uses `Path` for writing, `FileSystems::getDefault` would fail with `NullPointerException` because it calls `BootLoader.loadLibrary` which is not fully initialized. 
> 
> A separate issue will be filed to follow up the startup overhead of `OperatingSystem`.

Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - minor clean up
 - Revert ClassFileDumper to use Path as JDK-8308960 removed the dependency to Enum::valueOf
 - Merge branch 'master' of https://github.com/openjdk/jdk into class-file-dumper
 - 8307944: ClassFileDumper should only load java.nio.file.Path if enabled

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14160/files
  - new: https://git.openjdk.org/jdk/pull/14160/files/b0502d6e..3529e2fa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14160&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14160&range=00-01

  Stats: 8727 lines in 195 files changed: 5998 ins; 795 del; 1934 mod
  Patch: https://git.openjdk.org/jdk/pull/14160.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14160/head:pull/14160

PR: https://git.openjdk.org/jdk/pull/14160

From mchung at openjdk.org  Tue May 30 17:40:58 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 30 May 2023 17:40:58 GMT
Subject: RFR: 8307944: ClassFileDumper should only load java.nio.file.Path
 if enabled [v2]
In-Reply-To: <jel6LZc8bw7gZ5sEZuNauyl3Njqa_J5BXZv_wS_fYrU=.94de6e21-14ac-4e5c-9b96-52313c8a336f@github.com>
References: <jdahgZeAZtruycStvqWmSB3YbdTCN063GjMRXP9xJy0=.e3b786d2-d2be-47e1-a258-f7f5e0d61c7a@github.com>
 <jel6LZc8bw7gZ5sEZuNauyl3Njqa_J5BXZv_wS_fYrU=.94de6e21-14ac-4e5c-9b96-52313c8a336f@github.com>
Message-ID: <rwMh1kQX0vgt-FQhm9Beeoe7OQXk-29Mq7qsC5nItDM=.c038a9cb-efad-4d2c-8de4-2bc1f3cd6732@github.com>

On Tue, 30 May 2023 17:37:24 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Change `ClassFileDumper` constructor to take a `String` rather than `Path` to avoid the file system implementation classes loaded during startup.  In addition, `FilePermission` also causes the default file system to be initialized. 
>> 
>> This patch changes `ClassFileDumper` to validate the given path only if it's enabled and not to use limited `doPrivileged` to avoid the initialization of `FilePermission` class and the file system implementation classes by default.
>> 
>> This patch also changes `ClassFileDumper::write` to use `File` instead of `Path` because of JDK-8306678.  `OperatingSystem::<clinit>` causes `Enum::valueOf` to be called which calls core reflection which in turns invokes method handles.   If `-Djdk.invoke.MethodHandle.dumpMethodHandleInternals` is set, VM initialization would fail because `BootLoader::<clinit>` causes `ClassLoaderHelper` to initialize which in turn causes `OperatingSystem` be initialized.   If additional LFs are spinned and dumped, if `ClassFileDumper` uses `Path` for writing, `FileSystems::getDefault` would fail with `NullPointerException` because it calls `BootLoader.loadLibrary` which is not fully initialized. 
>> 
>> A separate issue will be filed to follow up the startup overhead of `OperatingSystem`.
>
> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - minor clean up
>  - Revert ClassFileDumper to use Path as JDK-8308960 removed the dependency to Enum::valueOf
>  - Merge branch 'master' of https://github.com/openjdk/jdk into class-file-dumper
>  - 8307944: ClassFileDumper should only load java.nio.file.Path if enabled

#14181 decoupled `jdk.internal.util OperatingSystem` and `Version` classes such that the early startup would no longer load `OperatingSystem` class and avoid the cyclic initialization.  So `ClassFileDumper` is now reverted back to use `Path.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14160#issuecomment-1568819780

From alanb at openjdk.org  Tue May 30 17:51:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 May 2023 17:51:08 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
 [v3]
In-Reply-To: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
Message-ID: <9GP7th9xZMUhZLeE1T7EJuUgzLU0imK09b5UG8TsjZs=.f53d9c58-6579-469b-b458-644e6dc70438@github.com>

> This is the implementation of:
> 
> - JEP 453: Structured Concurrency (Preview)
> - JEP 446: Scoped Values (Preview)
> 
> For the most part, this is just moving code and tests.  StructuredTaskScope moves to j.u.concurrent as a preview API, ScopedValue moves to j.lang as a preview API, and module jdk.incubator.concurrent has been removed. The significant API changes since incubator are:
> 
> - StructuredTaskScope.fork returns Subtask instead of Future (JEP 453 has a section on this)
> - ScopedValue.where methods are replaced with runWhere, callWhere and getWhere

Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:

  Sync with loom repo, re-work ScopedValue class description

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13932/files
  - new: https://git.openjdk.org/jdk/pull/13932/files/e92ba524..fce838e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13932&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13932&range=01-02

  Stats: 176 lines in 5 files changed: 78 ins; 16 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/13932.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13932/head:pull/13932

PR: https://git.openjdk.org/jdk/pull/13932

From rriggs at openjdk.org  Tue May 30 18:03:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 30 May 2023 18:03:06 GMT
Subject: RFR: 8307944: ClassFileDumper should only load java.nio.file.Path
 if enabled [v2]
In-Reply-To: <jel6LZc8bw7gZ5sEZuNauyl3Njqa_J5BXZv_wS_fYrU=.94de6e21-14ac-4e5c-9b96-52313c8a336f@github.com>
References: <jdahgZeAZtruycStvqWmSB3YbdTCN063GjMRXP9xJy0=.e3b786d2-d2be-47e1-a258-f7f5e0d61c7a@github.com>
 <jel6LZc8bw7gZ5sEZuNauyl3Njqa_J5BXZv_wS_fYrU=.94de6e21-14ac-4e5c-9b96-52313c8a336f@github.com>
Message-ID: <aZ51KjAxVlmOliBiEO0pWF0I3tPWMwzLIkMAAinGqhM=.b919880c-239f-424e-af75-c4699cbec6b9@github.com>

On Tue, 30 May 2023 17:37:24 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Change `ClassFileDumper` constructor to take a `String` rather than `Path` to avoid the file system implementation classes loaded during startup.  In addition, `FilePermission` also causes the default file system to be initialized. 
>> 
>> This patch changes `ClassFileDumper` to validate the given path only if it's enabled and not to use limited `doPrivileged` to avoid the initialization of `FilePermission` class and the file system implementation classes by default.
>> 
>> This patch also changes `ClassFileDumper::write` to use `File` instead of `Path` because of JDK-8306678.  `OperatingSystem::<clinit>` causes `Enum::valueOf` to be called which calls core reflection which in turns invokes method handles.   If `-Djdk.invoke.MethodHandle.dumpMethodHandleInternals` is set, VM initialization would fail because `BootLoader::<clinit>` causes `ClassLoaderHelper` to initialize which in turn causes `OperatingSystem` be initialized.   If additional LFs are spinned and dumped, if `ClassFileDumper` uses `Path` for writing, `FileSystems::getDefault` would fail with `NullPointerException` because it calls `BootLoader.loadLibrary` which is not fully initialized. 
>> 
>> A separate issue will be filed to follow up the startup overhead of `OperatingSystem`.
>
> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - minor clean up
>  - Revert ClassFileDumper to use Path as JDK-8308960 removed the dependency to Enum::valueOf
>  - Merge branch 'master' of https://github.com/openjdk/jdk into class-file-dumper
>  - 8307944: ClassFileDumper should only load java.nio.file.Path if enabled

Path changes look fine.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14160#pullrequestreview-1451522642

From naoto at openjdk.org  Tue May 30 18:03:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 30 May 2023 18:03:05 GMT
Subject: RFR: 8308022: update for deprecated sprintf for java.base [v2]
In-Reply-To: <KoGd_keDUhRHvaB5YVqBVtzbuXxlaTdWdbrc1dylFK8=.6c7411d0-6c71-431f-8968-03e823774ca6@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
 <KoGd_keDUhRHvaB5YVqBVtzbuXxlaTdWdbrc1dylFK8=.6c7411d0-6c71-431f-8968-03e823774ca6@github.com>
Message-ID: <QQsFnUhNexYPsZhaq6z5PobdU2odJU_giEMq_Myh4ko=.3ba677c9-bdae-4a91-959c-615d778ebb65@github.com>

On Wed, 24 May 2023 19:20:09 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   exclude update for libnet

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13963#pullrequestreview-1451523287

From rriggs at openjdk.org  Tue May 30 18:32:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 30 May 2023 18:32:57 GMT
Subject: RFR: 8308316: Default decomposition mode in Collator [v3]
In-Reply-To: <uLvdxZ39JHYsB9F1t_qaLnWA7ckhC3wDeZ3y2KYPjUo=.824c2878-9566-49c1-876c-ace94217e03d@github.com>
References: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>
 <uLvdxZ39JHYsB9F1t_qaLnWA7ckhC3wDeZ3y2KYPjUo=.824c2878-9566-49c1-876c-ace94217e03d@github.com>
Message-ID: <Ic3G6GnvLGbK6ywuhDIIMOTGFkB1_eZSFm9pRQRcfoY=.42c7a653-a2a6-4d08-b4e2-52e67332c1c2@github.com>

On Thu, 25 May 2023 22:19:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Amending the description about the default decomposition mode in `Collator.NO_DECOMPOSITION` javadoc.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use present tense

Looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14049#pullrequestreview-1451577005

From darcy at openjdk.org  Tue May 30 18:35:44 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 18:35:44 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v2]
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <CceUBb64Lj4jtOMiLm2aEFMGWfNgnbe9SqKqX0nJpyE=.9fbe6d8a-d200-4e39-9288-a2e9891a7d4f@github.com>

> Time to get JDK 22 underway...

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:

 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Sync in symbol changes for JDK 21 build 24.
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Minor test fixes.
 - Merge branch 'master' into JDK-8306584
 - Update symbol files to JDK 21 b23.
 - Merge branch 'JDK-8306584' of https://github.com/jddarcy/jdk into JDK-8306584
 - ... and 13 more: https://git.openjdk.org/jdk/compare/1b8e6bf3...c7682791

-------------

Changes: https://git.openjdk.org/jdk/pull/13567/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=01
  Stats: 5829 lines in 69 files changed: 5775 ins; 0 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/13567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567

PR: https://git.openjdk.org/jdk/pull/13567

From coleenp at openjdk.org  Tue May 30 18:45:57 2023
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 30 May 2023 18:45:57 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
Message-ID: <-J0qbu5Ym0zr1WgUHHd2xw4qAwCsXrusMtlVCIH4snk=.d6571950-4708-430d-b119-150728407390@github.com>

On Fri, 26 May 2023 08:31:46 GMT, JoKern65 <duke at openjdk.org> wrote:

>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small adjustments.
>> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.
>
> JoKern65 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forgotton _

src/hotspot/share/runtime/javaThread.cpp line 115:

> 113: #include <alloca.h>
> 114: #endif
> 115: 

Could these conditionals be included in globalDefinitions_xlc.hpp instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1210684136

From darcy at openjdk.org  Tue May 30 20:17:57 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 20:17:57 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v2]
In-Reply-To: <RBMae1be7T6K2yEPsyGb3EesrzePOGDXQ_DndVutjtw=.3fc47616-9350-4d62-bf9d-6c7113937505@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <aOP4D56C1ZNMV0EF3tQVI1R_zCJmlbmMkoS_ZeTHgiI=.dd4fe3e6-849f-49c0-91da-6990e84a5c1f@github.com>
 <RBMae1be7T6K2yEPsyGb3EesrzePOGDXQ_DndVutjtw=.3fc47616-9350-4d62-bf9d-6c7113937505@github.com>
Message-ID: <k0ZR8EWeMZnm5DJ8hqcyRrmUFbGdq0i9OVLN62zruYM=.0260093c-a774-47c1-8007-dd3ff1db351f@github.com>

On Tue, 23 May 2023 20:49:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/langtools/tools/javac/versions/Versions.java line 93:
>> 
>>> 91:         TWENTY(false,    "64.0", "20", Versions::checksrc20),
>>> 92:         TWENTY_ONE(false,"65.0", "21", Versions::checksrc20),
>>> 93:         TWENTY_TWO(false,"66.0", "22", Versions::checksrc20);
>> 
>> when do these get updated?
>
> Ah, when new non-preview language structures are added. With two new language features in JDK 21, looks like it is time for me to add another one; thanks.

Better to fix this omission in JDK 21; please see https://github.com/openjdk/jdk/pull/14229.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1210778891

From rriggs at openjdk.org  Tue May 30 21:01:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 30 May 2023 21:01:57 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java [v2]
In-Reply-To: <yf5YFLRuy-uQWCyU6qxzN-miPEgrWogWJsBRU55Pv1M=.51bea42a-30ac-4c15-a077-7ba8f6818ed2@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
 <yf5YFLRuy-uQWCyU6qxzN-miPEgrWogWJsBRU55Pv1M=.51bea42a-30ac-4c15-a077-7ba8f6818ed2@github.com>
Message-ID: <f1N3rEFGq1NBbNtFhMNonuY0kx9NTylws4cYgrUk5Ao=.083a5c3c-9239-40fe-9cc4-3583a0ed066d@github.com>

On Tue, 30 May 2023 09:15:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> UUID is very important class that is used to track identities of objects in large scale systems. Yet, the coverage in JDK test is disappointing: it tests only 100 of UUID instances per test, which is way too small to detect collisions due to the bad randomness for example.
>> 
>> I have some pending work to improve UUID performance, and tests should be improved. 
>> 
>> The improved test still runs in less than 5 seconds on my laptop.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments

test/jdk/java/util/UUID/UUIDTest.java line 79:

> 77:             }
> 78:             if (!set.add(u)) {
> 79:                 throw new Exception("UUID collision: " + u);

I would be concerned that if this failure was reported, it would be intermittent, hard to track down, and not reproducible.  Without a hook for the generator and the seed, its just going to be noise in the testing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14134#discussion_r1210815388

From mchung at openjdk.org  Tue May 30 21:04:08 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 30 May 2023 21:04:08 GMT
Subject: Integrated: 8307944: ClassFileDumper should only load
 java.nio.file.Path if enabled
In-Reply-To: <jdahgZeAZtruycStvqWmSB3YbdTCN063GjMRXP9xJy0=.e3b786d2-d2be-47e1-a258-f7f5e0d61c7a@github.com>
References: <jdahgZeAZtruycStvqWmSB3YbdTCN063GjMRXP9xJy0=.e3b786d2-d2be-47e1-a258-f7f5e0d61c7a@github.com>
Message-ID: <0ZQ0JPTwOvryruejwG8g2gCEhHCB6DxVcig6UXW-u6U=.976c0436-5f53-4b85-a89b-87aa1b1fd7c7@github.com>

On Thu, 25 May 2023 20:23:27 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Change `ClassFileDumper` constructor to take a `String` rather than `Path` to avoid the file system implementation classes loaded during startup.  In addition, `FilePermission` also causes the default file system to be initialized. 
> 
> This patch changes `ClassFileDumper` to validate the given path only if it's enabled and not to use limited `doPrivileged` to avoid the initialization of `FilePermission` class and the file system implementation classes by default.
> 
> This patch also changes `ClassFileDumper::write` to use `File` instead of `Path` because of JDK-8306678.  `OperatingSystem::<clinit>` causes `Enum::valueOf` to be called which calls core reflection which in turns invokes method handles.   If `-Djdk.invoke.MethodHandle.dumpMethodHandleInternals` is set, VM initialization would fail because `BootLoader::<clinit>` causes `ClassLoaderHelper` to initialize which in turn causes `OperatingSystem` be initialized.   If additional LFs are spinned and dumped, if `ClassFileDumper` uses `Path` for writing, `FileSystems::getDefault` would fail with `NullPointerException` because it calls `BootLoader.loadLibrary` which is not fully initialized. 
> 
> A separate issue will be filed to follow up the startup overhead of `OperatingSystem`.

This pull request has now been integrated.

Changeset: de7fd1c3
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/de7fd1c3061cfbfdbd5d7cc2b1ba0ee8d432ee0a
Stats:     167 lines in 6 files changed: 75 ins; 58 del; 34 mod

8307944: ClassFileDumper should only load java.nio.file.Path if enabled

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14160

From iris at openjdk.org  Tue May 30 21:25:01 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 30 May 2023 21:25:01 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v2]
In-Reply-To: <CceUBb64Lj4jtOMiLm2aEFMGWfNgnbe9SqKqX0nJpyE=.9fbe6d8a-d200-4e39-9288-a2e9891a7d4f@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <CceUBb64Lj4jtOMiLm2aEFMGWfNgnbe9SqKqX0nJpyE=.9fbe6d8a-d200-4e39-9288-a2e9891a7d4f@github.com>
Message-ID: <B-XYZjhrXGGL92jI8shCVNJ4tsIZv_2LI3EIHkh7fWo=.45790a24-157b-46f5-9631-ae55f7c61dc7@github.com>

On Tue, 30 May 2023 18:35:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to get JDK 22 underway...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits:
> 
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Sync in symbol changes for JDK 21 build 24.
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Minor test fixes.
>  - Merge branch 'master' into JDK-8306584
>  - Update symbol files to JDK 21 b23.
>  - Merge branch 'JDK-8306584' of https://github.com/jddarcy/jdk into JDK-8306584
>  - ... and 13 more: https://git.openjdk.org/jdk/compare/1b8e6bf3...c7682791

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1451837705

From duke at openjdk.org  Tue May 30 21:46:59 2023
From: duke at openjdk.org (JoKern65)
Date: Tue, 30 May 2023 21:46:59 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <-J0qbu5Ym0zr1WgUHHd2xw4qAwCsXrusMtlVCIH4snk=.d6571950-4708-430d-b119-150728407390@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
 <-J0qbu5Ym0zr1WgUHHd2xw4qAwCsXrusMtlVCIH4snk=.d6571950-4708-430d-b119-150728407390@github.com>
Message-ID: <RH19eKhBFxIkco_bYkmWkLSBV9Zk0dAtk-Dg2NCJ0RU=.df71a699-6c44-4629-b3c2-08e286df1b0a@github.com>

On Tue, 30 May 2023 18:42:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> JoKern65 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   forgotton _
>
> src/hotspot/share/runtime/javaThread.cpp line 115:
> 
>> 113: #include <alloca.h>
>> 114: #endif
>> 115: 
> 
> Could these conditionals be included in globalDefinitions_xlc.hpp instead?

In principle the `#include <alloca.h>` could be included in globalDefinitions_xlc.hpp. But alloca.h implements it with a
`#undef  alloca`
`#define alloca(size)   __builtin_alloca (size)`
If this new global define does not introduce new trouble (even in future coding) when it is seen in every source, we can go this way.
Are there any obstacles from anyone else?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1210853233

From darcy at openjdk.org  Tue May 30 22:16:08 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 22:16:08 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3]
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <cynjYPdpmMlzG4z-zoqhUFun0Uf8Op52etkgvkVaVkg=.5d133ecd-056b-49c3-8655-6856d22d163f@github.com>

> Time to get JDK 22 underway...

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Sync in symbol changes for JDK 21 build 24.
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Minor test fixes.
 - Merge branch 'master' into JDK-8306584
 - Update symbol files to JDK 21 b23.
 - ... and 14 more: https://git.openjdk.org/jdk/compare/cb40db05...376dbe26

-------------

Changes: https://git.openjdk.org/jdk/pull/13567/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=02
  Stats: 5828 lines in 69 files changed: 5775 ins; 0 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/13567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567

PR: https://git.openjdk.org/jdk/pull/13567

From darcy at openjdk.org  Tue May 30 22:16:09 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 30 May 2023 22:16:09 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3]
In-Reply-To: <k0ZR8EWeMZnm5DJ8hqcyRrmUFbGdq0i9OVLN62zruYM=.0260093c-a774-47c1-8007-dd3ff1db351f@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <aOP4D56C1ZNMV0EF3tQVI1R_zCJmlbmMkoS_ZeTHgiI=.dd4fe3e6-849f-49c0-91da-6990e84a5c1f@github.com>
 <RBMae1be7T6K2yEPsyGb3EesrzePOGDXQ_DndVutjtw=.3fc47616-9350-4d62-bf9d-6c7113937505@github.com>
 <k0ZR8EWeMZnm5DJ8hqcyRrmUFbGdq0i9OVLN62zruYM=.0260093c-a774-47c1-8007-dd3ff1db351f@github.com>
Message-ID: <3jywj8fLCqTlr-mps0rsYBXgb4jhxQaDFNCcgXLpSUQ=.e0a59fa0-5307-4d4c-8b5e-87c9e4d42d74@github.com>

On Tue, 30 May 2023 20:14:59 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Ah, when new non-preview language structures are added. With two new language features in JDK 21, looks like it is time for me to add another one; thanks.
>
> Better to fix this omission in JDK 21; please see https://github.com/openjdk/jdk/pull/14229.

> Better to fix this omission in JDK 21; please see #14229.

Addressed by merge of JDK-8309134 into JDK 22; thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1210875483

From dholmes at openjdk.org  Tue May 30 22:23:08 2023
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 May 2023 22:23:08 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
 [v4]
In-Reply-To: <ah2Znw6zKxUU7O0Qlsq86xaXFiv2wbw-dvkSKxnayfw=.8f07af5e-e6e2-4895-a71b-54fa801927bd@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
 <ah2Znw6zKxUU7O0Qlsq86xaXFiv2wbw-dvkSKxnayfw=.8f07af5e-e6e2-4895-a71b-54fa801927bd@github.com>
Message-ID: <0qKKe4tsPcFoKhIyryX9PZTbdLdv1kCpmCkQ8r9Zrpc=.904a042e-dd3f-4cd9-916e-69b56447c2ab@github.com>

On Mon, 29 May 2023 02:20:07 GMT, Chang Peng <duke at openjdk.org> wrote:

>> In Vector API Java level, vector mask is represented as a boolean array with 0x00/0x01 (8 bits of each element) as values, aka in-memory format. When it is loaded into vector register, e.g. Neon, the in-memory format will be converted to in-register format with 0/-1 value for each lane (lane width aligned to its type) by VectorLoadMask [1] operation, and convert back to in-memory format by VectorStoreMask[2]. In Neon, a typical VectorStoreMask operation will first narrow given vector registers by xtn insn [3] into byte element type, and then do a vector negate to convert to 0x00/0x01 value for each element.
>> 
>> For most of the vector mask operations, the input mask is in-register format. And a vector mask also works in-register format all through the compilation. But for some operations like VectorMask.trueCount()[4] which counts the elements of true value, the expected input mask is in-memory format. So a VectorStoreMask is generated to convert the mask from in-register format to in-memory format before those operations.
>> 
>> However, for trueCount() these xtn instructions in VectorStoreMask can be saved, since the narrowing operations will not influence the number of active lane (value of 0x01) of its input.
>> 
>> This patch adds an optimized rule `VectorMaskTrueCount (VectorStoreMask mask)` to save the unnecessary narrowing operations.
>> 
>> For example,
>> 
>> 
>> var m = VectorMask.fromArray(IntVector.SPECIES_PREFERRED, ba, 0);
>> m.not().trueCount();
>> 
>> 
>> will produce following assembly on a Neon machine before this patch:
>> 
>> 
>> ...
>> mvn     v16.16b, v16.16b           // VectorMask.not()
>> xtn     v16.4h, v16.4s
>> xtn     v16.8b, v16.8h
>> neg     v16.8b, v16.8b             // VectorStoreMask
>> addv    b17, v16.8b
>> umov    w0, v17.b[0]               // VectorMask.trueCount()
>> ...
>> 
>> After this patch:
>> 
>> 
>> ...
>> mvn     v16.16b, v16.16b           // VectorMask.not()
>> addv    s17, v16.4s
>> smov    x0, v17.b[0]
>> neg     x0, x0                     // Optimized VectorMask.trueCount()
>> ...
>> 
>> 
>> In this case, we can save two xtn insns.
>> 
>> Performance:
>> 
>> Benchmark     Before               After                          Unit
>> testInt           723.822 ? 1.029  1182.375 ? 12.363    ops/ms
>> testLong       632.154 ? 0.197  1382.74 ? 2.188        ops/ms
>> testShort      788.665 ? 1.852   1152.38 ? 3.77         ops/ms
>> 
>> [1]: https://github.com/openjdk/jdk/blob/e1e758a7b43c29840296d337bd2f0213ab0ca3c9/src/hotspot/cpu/aarch64/aarch64_vector....
>
> Chang Peng has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update aarch64_vector.ad

What testing was done on this fix before integration? I don't even see Git Hub Actions being run.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13974#issuecomment-1569199589

From mchung at openjdk.org  Tue May 30 23:47:57 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 30 May 2023 23:47:57 GMT
Subject: RFR: 8299505: findVirtual on array classes incorrectly restricts
 the receiver type
In-Reply-To: <Mzve--7vLKag1ieybf8aCSQp3uBJ_g9aSmyrevTNhtA=.591264e8-1219-4c1b-86fd-acc75edfd553@github.com>
References: <Mzve--7vLKag1ieybf8aCSQp3uBJ_g9aSmyrevTNhtA=.591264e8-1219-4c1b-86fd-acc75edfd553@github.com>
Message-ID: <iruiU11IHVCHAS1haHhZNKOZlA4Gk8xWdlrBzdibvno=.7f53c087-b0ae-4ede-b9d4-93a993e134e9@github.com>

On Sat, 6 May 2023 18:15:56 GMT, Chen Liang <liach at openjdk.org> wrote:

> The access hack for array class clone is only applied to `checkAccess` but missing before call to `restrictProtectedReceiver`, causing the array receiver type to be incorrectly replaced by the lookupClass type. This patch fixes that and adds a test to ensure an original lookup resolves `clone` for both array classes (public) and Object (inherited protected) correctly, and restores the old MethodHandlesGeneralTest from [JDK-8001105](https://bugs.openjdk.org/browse/JDK-8001105) which ensures correctness for publicLookup (which is already correct).

Thanks for taking this.   The patch looks right.    It should special case `Object.clone` for array types not to restrict the receiver to the lookup class.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4023:

> 4021:             // The accessing class only has the right to use a protected member
> 4022:             // on itself or a subclass.  Enforce that restriction, from JVMS 5.4.4, etc.
> 4023:             // Since array have access hacks, need to guard against array clone() before

I suggest to move this new comment to `getDirectMethodCommon`, the relevant caller of this method.  See suggested wordings below.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 4112:

> 4110:                     (MethodHandleNatives.refKindHasReceiver(refKind) &&
> 4111:                             !isArrayClone(refKind, refc, method) &&
> 4112:                             restrictProtectedReceiver(method))) {

Suggestion:

                    (MethodHandleNatives.refKindHasReceiver(refKind) &&
                            restrictProtectedReceiver(method) &&
                            // All arrays simply inherit the protected Object.clone method.
                            // The leading argument is restricted to the requested array type
                            // (not the lookup class).
                            !isArrayClone(refKind, refc, method))) {

test/jdk/java/lang/invoke/findVirtual/FindVirtualArrayCloneTest.java line 28:

> 26:  * @bug 8299505
> 27:  * @run junit FindVirtualArrayCloneTest
> 28:  * @summary Ensures Arrays' clone doesn't have incorrect receiver type bound

Suggestion:

 * @summary Test invocation of Object.clone for arrays

-------------

PR Review: https://git.openjdk.org/jdk/pull/13855#pullrequestreview-1451988301
PR Review Comment: https://git.openjdk.org/jdk/pull/13855#discussion_r1210934822
PR Review Comment: https://git.openjdk.org/jdk/pull/13855#discussion_r1210935373
PR Review Comment: https://git.openjdk.org/jdk/pull/13855#discussion_r1210936278

From mchung at openjdk.org  Tue May 30 23:47:59 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Tue, 30 May 2023 23:47:59 GMT
Subject: RFR: 8299505: findVirtual on array classes incorrectly restricts
 the receiver type
In-Reply-To: <iruiU11IHVCHAS1haHhZNKOZlA4Gk8xWdlrBzdibvno=.7f53c087-b0ae-4ede-b9d4-93a993e134e9@github.com>
References: <Mzve--7vLKag1ieybf8aCSQp3uBJ_g9aSmyrevTNhtA=.591264e8-1219-4c1b-86fd-acc75edfd553@github.com>
 <iruiU11IHVCHAS1haHhZNKOZlA4Gk8xWdlrBzdibvno=.7f53c087-b0ae-4ede-b9d4-93a993e134e9@github.com>
Message-ID: <QfBW1aHSs195VUv4OdDZhMXk991fByE77CHSrKpNBmg=.fe311d18-44da-4d75-981f-cf96ff35b304@github.com>

On Tue, 30 May 2023 23:38:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> The access hack for array class clone is only applied to `checkAccess` but missing before call to `restrictProtectedReceiver`, causing the array receiver type to be incorrectly replaced by the lookupClass type. This patch fixes that and adds a test to ensure an original lookup resolves `clone` for both array classes (public) and Object (inherited protected) correctly, and restores the old MethodHandlesGeneralTest from [JDK-8001105](https://bugs.openjdk.org/browse/JDK-8001105) which ensures correctness for publicLookup (which is already correct).
>
> test/jdk/java/lang/invoke/findVirtual/FindVirtualArrayCloneTest.java line 28:
> 
>> 26:  * @bug 8299505
>> 27:  * @run junit FindVirtualArrayCloneTest
>> 28:  * @summary Ensures Arrays' clone doesn't have incorrect receiver type bound
> 
> Suggestion:
> 
>  * @summary Test invocation of Object.clone for arrays

Can you add test cases to verify that the invocation of `Object.clone` returns an array object with correct content for completeness?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13855#discussion_r1210936985

From cjplummer at openjdk.org  Tue May 30 23:51:01 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Tue, 30 May 2023 23:51:01 GMT
Subject: RFR: 8309146: extend JDI StackFrame.setValue() and JDWP
 StackFrame.setValues minimal support for virtual threads
Message-ID: <PTH8uTnjL0i6z3fUXEXGZpVlg-IvkaU-AQFsgZJeG0k=.65f1958f-9fe4-4b46-a214-cb79e1b04575@github.com>

The JDWP spec for StackFrame.SetValue currently states:

        "If the thread is a virtual thread then this command can be used to set "
        "the value of local variables in the top-most frame when the thread is "
        "suspended at a breakpoint or single step event. The target VM may support "
        "setting local variables in other cases."

The JDI spec for StackFrame.setValue() has similar wording. In [JDK-8308814](https://bugs.openjdk.org/browse/JDK-8308814) the JVMTI spec clarified support to be for a thread suspended at any event, not just a breakpoint or single step. That same clarification is needed in the JDWP and JDI specs. No implementation changes are needed.

-------------

Commit messages:
 - Clarify minimal suppoert for StackFrame.GetValue.

Changes: https://git.openjdk.org/jdk/pull/14235/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14235&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309146
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/14235.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14235/head:pull/14235

PR: https://git.openjdk.org/jdk/pull/14235

From mchung at openjdk.org  Wed May 31 00:05:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 31 May 2023 00:05:05 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <V4XJOEZR3VHnoecHXtdKTuNr8SDbNW2azd_q5rczddQ=.9548a2b3-7b9f-4c1d-a7bb-2c6491ca4207@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
 <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
 <NsNbY_G6Nb0x313vuzyiYg0ZLMz7wZc37zVBlw5XhVQ=.127f8d5b-5402-461b-b08e-0c1b4518fe0f@github.com>
 <98YBa_WBEwtCvYRDW5MGvaldIafXiTtF8NNtVntaDJ0=.0eb04101-f922-4ae8-b12b-1e8a926ec926@github.com>
 <f-DRv-zieo1-oPOMlGdcJkzXPQWQGohmGYd_Z7loJRQ=.bc7de20c-9627-44c9-9e37-c32da1905453@github.com>
 <hsjtEhKMBGFEYZQBM7exD58qbS5TBHtHj7w3utQu2Vw=.f83790b1-4cee-439d-a35c-d1365e799e84@github.com>
 <8P2hD5jJPd7oWhpg3AuFbjpXjJETdN_BR1ydkTySXlo=.2d0a8c28-9d9b-4a70-b54e-311e2bd86b7a@github.com>
 <V4XJOEZR3VHnoecHXtdKTuNr8SDbNW2azd_q5rczddQ=.9548a2b3-7b9f-4c1d-a7bb-2c6491ca4207@github.com>
Message-ID: <wh2olb_Z8wi36ioSkfZVtyTx5ljmeAVGINd_tcSXsHQ=.5c9bd39e-70f7-4ff4-8f45-f9b6a539c2b8@github.com>

On Fri, 26 May 2023 22:18:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> If we can avoid implementing `sun.invoke.WrapperInstance`, this package access check issue would go away.  Do you think you can look into it?
>
> I think we can probably insert a static final field in a wrapper instance class to point to the implemented class and verify with the `PROXY_CLASS_INFOS` ClassValue, much like VarForm field in VarHandle implementations. This should have less reflective impact than the annotation-based approach, and can be cached in a ClassValue as well. Should we cache it though?

Is it more straight-forward to keep a `ClassValue<Boolean>` and each wrapper instance class has an entry of `TRUE` value; otherwise, `FALSE`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1210952258

From liach at openjdk.org  Wed May 31 00:30:05 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 31 May 2023 00:30:05 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <wh2olb_Z8wi36ioSkfZVtyTx5ljmeAVGINd_tcSXsHQ=.5c9bd39e-70f7-4ff4-8f45-f9b6a539c2b8@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
 <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
 <NsNbY_G6Nb0x313vuzyiYg0ZLMz7wZc37zVBlw5XhVQ=.127f8d5b-5402-461b-b08e-0c1b4518fe0f@github.com>
 <98YBa_WBEwtCvYRDW5MGvaldIafXiTtF8NNtVntaDJ0=.0eb04101-f922-4ae8-b12b-1e8a926ec926@github.com>
 <f-DRv-zieo1-oPOMlGdcJkzXPQWQGohmGYd_Z7loJRQ=.bc7de20c-9627-44c9-9e37-c32da1905453@github.com>
 <hsjtEhKMBGFEYZQBM7exD58qbS5TBHtHj7w3utQu2Vw=.f83790b1-4cee-439d-a35c-d1365e799e84@github.com>
 <8P2hD5jJPd7oWhpg3AuFbjpXjJETdN_BR1ydkTySXlo=.2d0a8c28-9d9b-4a70-b54e-311e2bd86b7a@github.com>
 <V4XJOEZR3VHnoecHXtdKTuNr8SDbNW2azd_q5rczddQ=.9548a2b3-7b9f-4c1d-a7bb-2c6491ca4207@github.com>
 <wh2olb_Z8wi36ioSkfZVtyTx5ljmeAVGINd
 _tcSXsHQ=.5c9bd39e-70f7-4ff4-8f45-f9b6a539c2b8@github.com>
Message-ID: <iLsWKeK_UFv0-KJNnfLeDanU_61eetQRNpAKiXyoQpw=.ba48aebe-5723-44da-b79b-b1a1fe9ba0d4@github.com>

On Wed, 31 May 2023 00:01:56 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Is it more straight-forward to keep a `ClassValue<Boolean>` and each wrapper instance class has an entry of `TRUE` value; otherwise, `FALSE`?

Then we still need to obtain the implemented interface and original method handle information every time they are queried. Having these information (or the method handle providing access) computed early is more convenient.

> If we can avoid implementing sun.invoke.WrapperInstance, this package access check issue would go away. Do you think you can look into it?

Apparently, calling utility methods from `sun.invoke`, like the `ensureOriginalLookup` in this patch, also triggers this check. However, I still think removing the `WrapperInstance` supertype is better, as this makes the code cleaner in reflection.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1210963364

From mchung at openjdk.org  Wed May 31 00:55:06 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 31 May 2023 00:55:06 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <BmuyK2Yoay6gxrKDF37Di_T-VQmgdTeiyGuwigCKR2c=.df9d9a2e-05e6-4369-a48b-8065fe176ccc@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
 <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
 <NsNbY_G6Nb0x313vuzyiYg0ZLMz7wZc37zVBlw5XhVQ=.127f8d5b-5402-461b-b08e-0c1b4518fe0f@github.com>
 <98YBa_WBEwtCvYRDW5MGvaldIafXiTtF8NNtVntaDJ0=.0eb04101-f922-4ae8-b12b-1e8a926ec926@github.com>
 <f-DRv-zieo1-oPOMlGdcJkzXPQWQGohmGYd_Z7loJRQ=.bc7de20c-9627-44c9-9e37-c32da1905453@github.com>
 <hsjtEhKMBGFEYZQBM7exD58qbS5TBHtHj7w3utQu2Vw=.f83790b1-4cee-439d-a35c-d1365e799e84@github.com>
 <8P2hD5jJPd7oWhpg3AuFbjpXjJETdN_BR1ydkTySXlo=.2d0a8c28-9d9b-4a70-b54e-311e2bd86b7a@github.com>
 <V4XJOEZR3VHnoecHXtdKTuNr8SDbNW2azd_q5rczddQ=.9548a2b3-7b9f-4c1d-a7bb-2c6491ca4207@github.com>
 <wh2olb_Z8wi36ioSkfZVtyTx5ljmeAVGINd
 _tcSXsHQ=.5c9bd39e-70f7-4ff4-8f45-f9b6a539c2b8@github.com>
 <iLsWKeK_UFv0-KJNnfLeDanU_61eetQRNpAKiXyoQpw=.ba48aebe-5723-44da-b79b-b1a1fe9ba0d4@github.com>
 <BmuyK2Yoay6gxrKDF37Di_T-VQmgdTeiyGuwigCKR2c=.df9d9a2e-05e6-4369-a48b-8065fe176ccc@github.com>
Message-ID: <sGcDTasCYK1w1ERRGa36Y_S197b0QsAPAoIfmoiOwN4=.4f29d7fd-fde8-4b9f-bb0e-79c97950b37e@github.com>

On Wed, 31 May 2023 00:48:18 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> Is it more straight-forward to keep a `ClassValue<Boolean>` and each wrapper instance class has an entry of `TRUE` value; otherwise, `FALSE`?
>> 
>> Then we still need to obtain the implemented interface and original method handle information every time they are queried. Having these information (or the method handle providing access) computed early is more convenient.
>> 
>>> If we can avoid implementing sun.invoke.WrapperInstance, this package access check issue would go away. Do you think you can look into it?
>> 
>> Apparently, calling utility methods from `sun.invoke`, like the `ensureOriginalLookup` in this patch, also triggers this check. However, I still think removing the `WrapperInstance` supertype is better, as this makes the code cleaner in reflection.
>
>> Apparently, calling utility methods from sun.invoke, like the ensureOriginalLookup in this patch, also triggers this check. 
> 
> It should not trigger `checkPackageAccess` if it does not implement the interface AFAICT.
> 
> It would trigger module-access check.  `java.base` can export `sun.invoke` to the dynamic module (it may be worth considering putting the internal interface in a specific package for the dynamic module' use - `sun.invoke` is ok since it currently has one interface but hard to catch when someone adds a new class/interface in `sun.invoke` unintentionally and leak out sensitive API.

> Then we still need to obtain the implemented interface and original method handle information every time they are queried. Having these information (or the method handle providing access) computed early is more convenient.

I was thinking the wrapper instance class still implements some private methods to get the implemented interface and original method handle which can be accessed only `java.base` via deep reflection.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1210972245

From mchung at openjdk.org  Wed May 31 00:55:05 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 31 May 2023 00:55:05 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <iLsWKeK_UFv0-KJNnfLeDanU_61eetQRNpAKiXyoQpw=.ba48aebe-5723-44da-b79b-b1a1fe9ba0d4@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
 <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
 <NsNbY_G6Nb0x313vuzyiYg0ZLMz7wZc37zVBlw5XhVQ=.127f8d5b-5402-461b-b08e-0c1b4518fe0f@github.com>
 <98YBa_WBEwtCvYRDW5MGvaldIafXiTtF8NNtVntaDJ0=.0eb04101-f922-4ae8-b12b-1e8a926ec926@github.com>
 <f-DRv-zieo1-oPOMlGdcJkzXPQWQGohmGYd_Z7loJRQ=.bc7de20c-9627-44c9-9e37-c32da1905453@github.com>
 <hsjtEhKMBGFEYZQBM7exD58qbS5TBHtHj7w3utQu2Vw=.f83790b1-4cee-439d-a35c-d1365e799e84@github.com>
 <8P2hD5jJPd7oWhpg3AuFbjpXjJETdN_BR1ydkTySXlo=.2d0a8c28-9d9b-4a70-b54e-311e2bd86b7a@github.com>
 <V4XJOEZR3VHnoecHXtdKTuNr8SDbNW2azd_q5rczddQ=.9548a2b3-7b9f-4c1d-a7bb-2c6491ca4207@github.com>
 <wh2olb_Z8wi36ioSkfZVtyTx5ljmeAVGINd
 _tcSXsHQ=.5c9bd39e-70f7-4ff4-8f45-f9b6a539c2b8@github.com>
 <iLsWKeK_UFv0-KJNnfLeDanU_61eetQRNpAKiXyoQpw=.ba48aebe-5723-44da-b79b-b1a1fe9ba0d4@github.com>
Message-ID: <BmuyK2Yoay6gxrKDF37Di_T-VQmgdTeiyGuwigCKR2c=.df9d9a2e-05e6-4369-a48b-8065fe176ccc@github.com>

On Wed, 31 May 2023 00:27:24 GMT, Chen Liang <liach at openjdk.org> wrote:

> Apparently, calling utility methods from sun.invoke, like the ensureOriginalLookup in this patch, also triggers this check. 

It should not trigger `checkPackageAccess` if it does not implement the interface AFAICT.

It would trigger module-access check.  `java.base` can export `sun.invoke` to the dynamic module (it may be worth considering putting the internal interface in a specific package for the dynamic module' use - `sun.invoke` is ok since it currently has one interface but hard to catch when someone adds a new class/interface in `sun.invoke` unintentionally and leak out sensitive API.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1210971821

From liach at openjdk.org  Wed May 31 01:40:22 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 31 May 2023 01:40:22 GMT
Subject: RFR: 8299505: findVirtual on array classes incorrectly restricts
 the receiver type [v2]
In-Reply-To: <Mzve--7vLKag1ieybf8aCSQp3uBJ_g9aSmyrevTNhtA=.591264e8-1219-4c1b-86fd-acc75edfd553@github.com>
References: <Mzve--7vLKag1ieybf8aCSQp3uBJ_g9aSmyrevTNhtA=.591264e8-1219-4c1b-86fd-acc75edfd553@github.com>
Message-ID: <E9RUE-Pv9jg671yRQlk02ma9wruV0hcf5DetQgF1cC0=.62b0ec5a-3d2b-4005-ac4f-9b4c3b933930@github.com>

> The access hack for array class clone is only applied to `checkAccess` but missing before call to `restrictProtectedReceiver`, causing the array receiver type to be incorrectly replaced by the lookupClass type. This patch fixes that and adds a test to ensure an original lookup resolves `clone` for both array classes (public) and Object (inherited protected) correctly, and restores the old MethodHandlesGeneralTest from [JDK-8001105](https://bugs.openjdk.org/browse/JDK-8001105) which ensures correctness for publicLookup (which is already correct).

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Update per review
 - Merge branch 'master' into fix/lookup-array-clone
 - 8299505: findVirtual on array classes incorrectly restricts the receiver type

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13855/files
  - new: https://git.openjdk.org/jdk/pull/13855/files/789144dc..532ea964

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13855&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13855&range=00-01

  Stats: 169789 lines in 2935 files changed: 127292 ins; 20477 del; 22020 mod
  Patch: https://git.openjdk.org/jdk/pull/13855.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13855/head:pull/13855

PR: https://git.openjdk.org/jdk/pull/13855

From liach at openjdk.org  Wed May 31 01:40:22 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 31 May 2023 01:40:22 GMT
Subject: RFR: 8299505: findVirtual on array classes incorrectly restricts
 the receiver type [v2]
In-Reply-To: <QfBW1aHSs195VUv4OdDZhMXk991fByE77CHSrKpNBmg=.fe311d18-44da-4d75-981f-cf96ff35b304@github.com>
References: <Mzve--7vLKag1ieybf8aCSQp3uBJ_g9aSmyrevTNhtA=.591264e8-1219-4c1b-86fd-acc75edfd553@github.com>
 <iruiU11IHVCHAS1haHhZNKOZlA4Gk8xWdlrBzdibvno=.7f53c087-b0ae-4ede-b9d4-93a993e134e9@github.com>
 <QfBW1aHSs195VUv4OdDZhMXk991fByE77CHSrKpNBmg=.fe311d18-44da-4d75-981f-cf96ff35b304@github.com>
Message-ID: <o9CTjXbI1h1KZA5njsy4CrcMT7gRhUPHJzxra6yPAi8=.072e9adc-108c-4aac-b353-9f05c2ad8d5e@github.com>

On Tue, 30 May 2023 23:39:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/findVirtual/FindVirtualArrayCloneTest.java line 28:
>> 
>>> 26:  * @bug 8299505
>>> 27:  * @run junit FindVirtualArrayCloneTest
>>> 28:  * @summary Ensures Arrays' clone doesn't have incorrect receiver type bound
>> 
>> Suggestion:
>> 
>>  * @summary Test invocation of Object.clone for arrays
>
> Can you add test cases to verify that the invocation of `Object.clone` returns an array object with correct content for completeness?

I've done the requested changes and ran the invoke tests locally.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13855#discussion_r1210991713

From mchung at openjdk.org  Wed May 31 02:53:59 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 31 May 2023 02:53:59 GMT
Subject: RFR: 8299505: findVirtual on array classes incorrectly restricts
 the receiver type [v2]
In-Reply-To: <E9RUE-Pv9jg671yRQlk02ma9wruV0hcf5DetQgF1cC0=.62b0ec5a-3d2b-4005-ac4f-9b4c3b933930@github.com>
References: <Mzve--7vLKag1ieybf8aCSQp3uBJ_g9aSmyrevTNhtA=.591264e8-1219-4c1b-86fd-acc75edfd553@github.com>
 <E9RUE-Pv9jg671yRQlk02ma9wruV0hcf5DetQgF1cC0=.62b0ec5a-3d2b-4005-ac4f-9b4c3b933930@github.com>
Message-ID: <mqddpzv2u3KZuV-24KwjUnTC9kJZigfgEyTkUbM0J3Q=.14a7c088-5e6f-4b1e-8ddd-cb0ae5faa6d3@github.com>

On Wed, 31 May 2023 01:40:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The access hack for array class clone is only applied to `checkAccess` but missing before call to `restrictProtectedReceiver`, causing the array receiver type to be incorrectly replaced by the lookupClass type. This patch fixes that and adds a test to ensure an original lookup resolves `clone` for both array classes (public) and Object (inherited protected) correctly, and restores the old MethodHandlesGeneralTest from [JDK-8001105](https://bugs.openjdk.org/browse/JDK-8001105) which ensures correctness for publicLookup (which is already correct).
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Update per review
>  - Merge branch 'master' into fix/lookup-array-clone
>  - 8299505: findVirtual on array classes incorrectly restricts the receiver type

Looks good.

test/jdk/java/lang/invoke/findVirtual/FindVirtualArrayCloneTest.java line 70:

> 68:         var cloneMh = MethodHandles.lookup()
> 69:                 .findVirtual(String[].class, "clone", MethodType.methodType(Object.class));
> 70:         var mhClone = (String[]) (Object) cloneMh.invokeExact((String[]) array);

Suggestion:

        var mhClone = (String[]) cloneMh.invokeExact((String[]) array);

-------------

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13855#pullrequestreview-1452075058
PR Review Comment: https://git.openjdk.org/jdk/pull/13855#discussion_r1210994587

From duke at openjdk.org  Wed May 31 03:01:09 2023
From: duke at openjdk.org (Chang Peng)
Date: Wed, 31 May 2023 03:01:09 GMT
Subject: RFR: 8307795: AArch64: Optimize VectorMask.truecount() on Neon
 [v4]
In-Reply-To: <0qKKe4tsPcFoKhIyryX9PZTbdLdv1kCpmCkQ8r9Zrpc=.904a042e-dd3f-4cd9-916e-69b56447c2ab@github.com>
References: <3PN4wszSZLJa16IvdtCU4c21AomxisfiSzVKDS4mvHs=.c270f6e0-95f4-4cda-b79f-4df24de1e3db@github.com>
 <ah2Znw6zKxUU7O0Qlsq86xaXFiv2wbw-dvkSKxnayfw=.8f07af5e-e6e2-4895-a71b-54fa801927bd@github.com>
 <0qKKe4tsPcFoKhIyryX9PZTbdLdv1kCpmCkQ8r9Zrpc=.904a042e-dd3f-4cd9-916e-69b56447c2ab@github.com>
Message-ID: <BbGPbRoUFD6UaLd9-nZpJ91GQmiCzILsfgFfMQrra2Y=.6e764091-79f9-4324-94c5-c4c51787f008@github.com>

On Tue, 30 May 2023 22:20:23 GMT, David Holmes <dholmes at openjdk.org> wrote:

> What testing was done on this fix before integration? I don't even see Git Hub Actions being run.

@dholmes-ora 
I did see earlier that Github Action ran (In the 'Checks' tab) and finished, and I believed the Windows failure is not related to my patch. Perhaps GHA does not cover the jmh build. 

I ran the full jtreg tests in our internal ci with my first draft patch, but I realized that I forgot to have another run of full jtreg test after updating my patch to the current version. I only ran my new jtreg test before integration. Lesson learnt!

Thanks @DamonFool for the quick fix. I am working on JDK-8309129.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13974#issuecomment-1569424140

From liach at openjdk.org  Wed May 31 03:45:59 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 31 May 2023 03:45:59 GMT
Subject: RFR: 8299505: findVirtual on array classes incorrectly restricts
 the receiver type [v2]
In-Reply-To: <mqddpzv2u3KZuV-24KwjUnTC9kJZigfgEyTkUbM0J3Q=.14a7c088-5e6f-4b1e-8ddd-cb0ae5faa6d3@github.com>
References: <Mzve--7vLKag1ieybf8aCSQp3uBJ_g9aSmyrevTNhtA=.591264e8-1219-4c1b-86fd-acc75edfd553@github.com>
 <E9RUE-Pv9jg671yRQlk02ma9wruV0hcf5DetQgF1cC0=.62b0ec5a-3d2b-4005-ac4f-9b4c3b933930@github.com>
 <mqddpzv2u3KZuV-24KwjUnTC9kJZigfgEyTkUbM0J3Q=.14a7c088-5e6f-4b1e-8ddd-cb0ae5faa6d3@github.com>
Message-ID: <Wawt6fIliGThqUJZXNC4m7ikl4u30U3BcE1tkgLWdXY=.09d05fae-2765-45fd-a5f5-624d73fff89e@github.com>

On Wed, 31 May 2023 01:42:17 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Update per review
>>  - Merge branch 'master' into fix/lookup-array-clone
>>  - 8299505: findVirtual on array classes incorrectly restricts the receiver type
>
> test/jdk/java/lang/invoke/findVirtual/FindVirtualArrayCloneTest.java line 70:
> 
>> 68:         var cloneMh = MethodHandles.lookup()
>> 69:                 .findVirtual(String[].class, "clone", MethodType.methodType(Object.class));
>> 70:         var mhClone = (String[]) (Object) cloneMh.invokeExact((String[]) array);
> 
> Suggestion:
> 
>         var mhClone = (String[]) cloneMh.invokeExact((String[]) array);

the clone Method handle will have a type of `(String[])Object`, as `findVirtual` for `clone` uses the Object return method type, and there is no covariant override in array classes (which don't declare any methods)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13855#discussion_r1211053514

From mchung at openjdk.org  Wed May 31 04:09:56 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 31 May 2023 04:09:56 GMT
Subject: RFR: 8299505: findVirtual on array classes incorrectly restricts
 the receiver type [v2]
In-Reply-To: <Wawt6fIliGThqUJZXNC4m7ikl4u30U3BcE1tkgLWdXY=.09d05fae-2765-45fd-a5f5-624d73fff89e@github.com>
References: <Mzve--7vLKag1ieybf8aCSQp3uBJ_g9aSmyrevTNhtA=.591264e8-1219-4c1b-86fd-acc75edfd553@github.com>
 <E9RUE-Pv9jg671yRQlk02ma9wruV0hcf5DetQgF1cC0=.62b0ec5a-3d2b-4005-ac4f-9b4c3b933930@github.com>
 <mqddpzv2u3KZuV-24KwjUnTC9kJZigfgEyTkUbM0J3Q=.14a7c088-5e6f-4b1e-8ddd-cb0ae5faa6d3@github.com>
 <Wawt6fIliGThqUJZXNC4m7ikl4u30U3BcE1tkgLWdXY=.09d05fae-2765-45fd-a5f5-624d73fff89e@github.com>
Message-ID: <P39HXzOfGyIiTH8dcFty3sL-whyZj47XBmobkEsH27Y=.ecaaabe3-7420-4581-8b72-064d18043fbd@github.com>

On Wed, 31 May 2023 03:43:25 GMT, Chen Liang <liach at openjdk.org> wrote:

>> test/jdk/java/lang/invoke/findVirtual/FindVirtualArrayCloneTest.java line 70:
>> 
>>> 68:         var cloneMh = MethodHandles.lookup()
>>> 69:                 .findVirtual(String[].class, "clone", MethodType.methodType(Object.class));
>>> 70:         var mhClone = (String[]) (Object) cloneMh.invokeExact((String[]) array);
>> 
>> Suggestion:
>> 
>>         var mhClone = (String[]) cloneMh.invokeExact((String[]) array);
>
> the clone Method handle will have a type of `(String[])Object`, as `findVirtual` for `clone` uses the Object return method type, and there is no covariant override in array classes (which don't declare any methods)

You're right.  Alternatively (perhaps easier to read):


-                .findVirtual(String[].class, "clone", MethodType.methodType(Object.class));
-        var mhClone = (String[]) (Object) cloneMh.invokeExact((String[]) array);
+                .findVirtual(String[].class, "clone", MethodType.methodType(Object.class))
+                .asType(MethodType.methodType(String[].class, String[].class));
+        var mhClone = (String[]) cloneMh.invokeExact((String[]) array);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13855#discussion_r1211064561

From liach at openjdk.org  Wed May 31 05:25:32 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 31 May 2023 05:25:32 GMT
Subject: RFR: 8299505: findVirtual on array classes incorrectly restricts
 the receiver type [v3]
In-Reply-To: <Mzve--7vLKag1ieybf8aCSQp3uBJ_g9aSmyrevTNhtA=.591264e8-1219-4c1b-86fd-acc75edfd553@github.com>
References: <Mzve--7vLKag1ieybf8aCSQp3uBJ_g9aSmyrevTNhtA=.591264e8-1219-4c1b-86fd-acc75edfd553@github.com>
Message-ID: <9DzWs-rpNpFQKKJVHPva8SwHk2Dxf68vMWPAEBfW-nQ=.2e4cda42-6116-4ac7-b7e6-5d9118924f01@github.com>

> The access hack for array class clone is only applied to `checkAccess` but missing before call to `restrictProtectedReceiver`, causing the array receiver type to be incorrectly replaced by the lookupClass type. This patch fixes that and adds a test to ensure an original lookup resolves `clone` for both array classes (public) and Object (inherited protected) correctly, and restores the old MethodHandlesGeneralTest from [JDK-8001105](https://bugs.openjdk.org/browse/JDK-8001105) which ensures correctness for publicLookup (which is already correct).

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Make test MH invocation slightly more readable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13855/files
  - new: https://git.openjdk.org/jdk/pull/13855/files/532ea964..9687f01d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13855&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13855&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13855.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13855/head:pull/13855

PR: https://git.openjdk.org/jdk/pull/13855

From jwaters at openjdk.org  Wed May 31 07:08:55 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 31 May 2023 07:08:55 GMT
Subject: RFR: 8308780: Fix the Java Integer types on Windows
In-Reply-To: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
References: <-mAb3g-jnRbOa0PFdM8gVP-8zI8CRGwxPvSdXd3uPm8=.2e6ab688-3ca1-4b8a-8674-5245c3f7557f@github.com>
Message-ID: <h8YGLUmNNvmuIMgM7J6z91zLoRBZYZ8zmK8ENasi9DI=.7fd47ef7-976f-450f-aad2-6b2e6dbde52c@github.com>

On Wed, 24 May 2023 13:56:05 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> On Windows, the basic Java Integer types are defined as long and __int64 respectively. In particular, the former is rather problematic since it breaks compilation as the Visual C++ becomes stricter and more compliant with every release, which means the way Windows code treats long as a typedef for int is no longer correct, especially with -permissive- enabled. Instead of changing every piece of broken code to match the jint = long typedef, which is far too time consuming, we can instead change jint to an int (which is still the same 32 bit number type as long), as there are far fewer problems caused by this definition. It's better to get this over and done with sooner than later when a future version of Visual C++ finally starts to break on existing code

Bumping

:(

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14125#issuecomment-1569611758

From shade at openjdk.org  Wed May 31 07:41:58 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 31 May 2023 07:41:58 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java [v2]
In-Reply-To: <f1N3rEFGq1NBbNtFhMNonuY0kx9NTylws4cYgrUk5Ao=.083a5c3c-9239-40fe-9cc4-3583a0ed066d@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
 <yf5YFLRuy-uQWCyU6qxzN-miPEgrWogWJsBRU55Pv1M=.51bea42a-30ac-4c15-a077-7ba8f6818ed2@github.com>
 <f1N3rEFGq1NBbNtFhMNonuY0kx9NTylws4cYgrUk5Ao=.083a5c3c-9239-40fe-9cc4-3583a0ed066d@github.com>
Message-ID: <e_6uyjz6ulTW54MUGTtc0h529lqygC0ajJpw7hBbGkE=.56e93f81-cd1a-4806-967f-1d16df6aa51f@github.com>

On Tue, 30 May 2023 20:55:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review comments
>
> test/jdk/java/util/UUID/UUIDTest.java line 79:
> 
>> 77:             }
>> 78:             if (!set.add(u)) {
>> 79:                 throw new Exception("UUID collision: " + u);
> 
> I would be concerned that if this failure was reported, it would be intermittent, hard to track down, and not reproducible.  Without a hook for the generator and the seed, its just going to be noise in the testing.

This is a non-practical concern, IMO. By spec, `UUID.randomUUID` is generated from the cryptographically secure random, with >120 bits of randomness, so the collision is extremely unlikely. Collision math involves birthday paradox, but Wikipedia article on UUIDs fortunately gives us the approximated solutions already:  https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions 

Quote: "Thus, the probability to find a duplicate within 103 trillion version-4 UUIDs is one in a billion." 

In other words, finding a collision in this test with 1M UUIDs points to the implementation issue, not a test bug, with a very high probability. In yet another words, if a unit test with 1M UUIDs is able to find a collision, then this is a strong signal that many production systems that assume extremely low collision probability are up for subtle misbehavior.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14134#discussion_r1211223450

From dholmes at openjdk.org  Wed May 31 08:06:00 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 31 May 2023 08:06:00 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3]
In-Reply-To: <cynjYPdpmMlzG4z-zoqhUFun0Uf8Op52etkgvkVaVkg=.5d133ecd-056b-49c3-8655-6856d22d163f@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <cynjYPdpmMlzG4z-zoqhUFun0Uf8Op52etkgvkVaVkg=.5d133ecd-056b-49c3-8655-6856d22d163f@github.com>
Message-ID: <PXBZ7zJTTlZqtJ04-3pVjDwmEMuhPMxTkO2mYT3qiaQ=.0c1114e8-30a8-451b-bf8d-eb3089f2a476@github.com>

On Tue, 30 May 2023 22:16:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to get JDK 22 underway...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Sync in symbol changes for JDK 21 build 24.
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Minor test fixes.
>  - Merge branch 'master' into JDK-8306584
>  - Update symbol files to JDK 21 b23.
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/cb40db05...376dbe26

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1452455740

From duke at openjdk.org  Wed May 31 08:21:57 2023
From: duke at openjdk.org (JoKern65)
Date: Wed, 31 May 2023 08:21:57 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <RH19eKhBFxIkco_bYkmWkLSBV9Zk0dAtk-Dg2NCJ0RU=.df71a699-6c44-4629-b3c2-08e286df1b0a@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
 <-J0qbu5Ym0zr1WgUHHd2xw4qAwCsXrusMtlVCIH4snk=.d6571950-4708-430d-b119-150728407390@github.com>
 <RH19eKhBFxIkco_bYkmWkLSBV9Zk0dAtk-Dg2NCJ0RU=.df71a699-6c44-4629-b3c2-08e286df1b0a@github.com>
Message-ID: <eGdfPTVIjrcjRLogqQF27YWsRan7_qpaM1CvTun6J1c=.7cb28821-5183-467b-b374-9e19b50796d3@github.com>

On Tue, 30 May 2023 21:44:17 GMT, JoKern65 <duke at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.cpp line 115:
>> 
>>> 113: #include <alloca.h>
>>> 114: #endif
>>> 115: 
>> 
>> Could these conditionals be included in globalDefinitions_xlc.hpp instead?
>
> In principle the `#include <alloca.h>` could be included in globalDefinitions_xlc.hpp. But alloca.h implements it with a
> `#undef  alloca`
> `#define alloca(size)   __builtin_alloca (size)`
> If this new global define does not introduce new trouble (even in future coding) when it is seen in every source, we can go this way.
> Are there any obstacles from anyone else?

At least the whole jdk actually builds with `#include <alloca.h>` in globalDefinitions_xlc.hpp

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14146#discussion_r1211272616

From duke at openjdk.org  Wed May 31 10:04:59 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Wed, 31 May 2023 10:04:59 GMT
Subject: RFR: 8289220: [Shenandoah] TestAllocObjectArrays fails
 intermittently
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <GOxbhP3BXGBlNsKCAmnVF6hl0xg5oXpItR7WLtLJwOY=.1c8bbd73-8708-47e5-bdbb-3ce34cda7697@github.com>

On Tue, 30 May 2023 08:31:08 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

Jtreg tier1 can trigger the same error with vmoptions:"-Xcomp -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot
I found the GC occurs between when the soft reference is assigned and when it is used.
<pre><code class="shell">
         private BaseLocale getBaseLocale() {
-            return (holder == null) ? holderRef.get() : holder;
+//            return (holder == null) ? holderRef.get() : holder;
+            if (holder == null) {
+              System.out.println("getBaseLocale this=" + this + "  SoftReference=" + holderRef.get()); // null
+              return holderRef.get();
+            } else {
+              System.out.println("getBaseLocale return holder");
+              return holder;
+            }
         }
</code></pre>

The following modification verifies this.
<pre><code class="shell">
--- a/src/java.base/share/classes/sun/util/locale/BaseLocale.java
+++ b/src/java.base/share/classes/sun/util/locale/BaseLocale.java

@@ -257,19 +261,21 @@ public final class BaseLocale {

         private final boolean normalized;
         private final int hash;
-
+        private BaseLocale locale;    // make locale to a member variable
         private Key(String language, String script, String region,
                     String variant, boolean normalize) {
-            BaseLocale locale = new BaseLocale(language, script, region, variant, normalize);
+            locale = new BaseLocale(language, script, region, variant, normalize);
             this.normalized = normalize;
</code></pre>
But this should not be a reasonable solution. I think I should to find a better solution.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1569881913

From sspitsyn at openjdk.org  Wed May 31 10:16:39 2023
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 31 May 2023 10:16:39 GMT
Subject: RFR: 8304438: jcmd JVMTI.agent_load should obey
 EnableDynamicAgentLoading
Message-ID: <9H36lIpFiwG4v0oGPE2zCIawMJcNIhuGguz--qxjRnQ=.0fc08ed3-2d12-42d0-8b6c-3fa801d55427@github.com>

The VM option EnableDynamicAgentLoading was added in JDK 9, default true, to allow deployment to choose whether to allow agents to be loaded/started in the VM. The VM option does the right thing for tools using the Attach API but jcmd JVMTI.agent_load was missed. This should be fixed to disallow loading JVMTI agents when the EnableDynamicAgentLoading is false.

Testing:
 - run new test `test/jdk/sun/tools/jcmd/TestJcmdNoAgentLoad.java`
 - TBD: submit mach5 tiers 1-5 to make sure no new regressions are introduced

-------------

Commit messages:
 - 8304438: jcmd JVMTI.agent_load should obey EnableDynamicAgentLoading

Changes: https://git.openjdk.org/jdk/pull/14244/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14244&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304438
  Stats: 78 lines in 2 files changed: 78 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14244/head:pull/14244

PR: https://git.openjdk.org/jdk/pull/14244

From chagedorn at openjdk.org  Wed May 31 10:49:59 2023
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 31 May 2023 10:49:59 GMT
Subject: RFR: JDK-8027711: Unify wildcarding syntax for CompileCommand and
 CompileOnly [v2]
In-Reply-To: <3tF5Nlnp_YCBvjfj38WxdiRrYeOyfA9Wz4wJ8tm5z2o=.4719cce4-0d72-485b-9494-cd97594c42fa@github.com>
References: <PWRLbPe5zEASx4qyWU6uRb8BZVa-CIBSBXK7Uwai1jY=.7b430bbf-3db2-4942-9021-e39e6595a78a@github.com>
 <3tF5Nlnp_YCBvjfj38WxdiRrYeOyfA9Wz4wJ8tm5z2o=.4719cce4-0d72-485b-9494-cd97594c42fa@github.com>
Message-ID: <U4LGlKyA4rQjFztBgSMMkw0-8n9T1Uoh2R2nXCbF634=.041c5ad6-4837-4455-9682-8d7bc9c0b3cd@github.com>

On Tue, 23 May 2023 09:08:20 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> At the moment `CompileCommand` and `CompileOnly` use different syntax for matching methods. 
>> 
>> ### Old CompileOnly format
>> - matching a **method name** with **class name** and **package name**:
>> `-XX:CompileOnly=package/path/Class.method`
>> `-XX:CompileOnly=package/path/Class::method`
>> `-XX:CompileOnly=package.path.Class::method`
>> BUT NOT `-XX:CompileOnly=package.path.Class.method`
>> 
>> - just matching a **single method name**:
>> `-XX:CompileOnly=.hashCode`
>> `-XX:CompileOnly=::hashCode`
>> BUT NOT `-XX:CompileOnly=hashCode`
>> 
>> - Matching **all method names** in a **class name** with **package name**
>> `-XX:CompileOnly=java/lang/String`
>> BUT NOT `-XX:CompileOnly=java/lang/String.`
>> BUT NOT `-XX:CompileOnly=java.lang.String`
>> BUT NOT `-XX:CompileOnly=java.lang.String::` (This is actually a bug) 
>> BUT NOT `-XX:CompileOnly=String`
>> BUT NOT `-XX:CompileOnly=String.`
>> BUT NOT `-XX:CompileOnly=String::`
>> 
>> - Matching **all method names** in a **class name** with **NO package name**
>> `-XX:CompileOnly=String`
>> BUT NOT `-XX:CompileOnly=String.`
>> BUT NOT `-XX:CompileOnly=String::`
>> 
>> - There is a bug when `CompileOnly` ends with `::` where the `CompileOnly` is just ignored
>> e.g. `-XX:CompileOnly=String::` compiles as many methods as when omitting the `-XX:CompileOnly=` command
>> 
>> ### CompileCommand=compileonly format
>> `CompileCommand` allows two different forms for paths: 
>> - `package/path/Class.method`
>> - `package.path.Class::method`
>> 
>> In contrary to `CompileOnly` `CompileCommand` supports wildcard matching using `*`. `*` can appear at the beginning and/or end of a `package.path.Class` and `method` name. 
>> 
>>  Valid forms: 
>> `-XX:CompileCommand=compileonly,*.lang.*::*shCo*`
>> `-XX:CompileCommand=compileonly,*/lang/*.*shCo*` 
>> `-XX:CompileCommand=compileonly,java.lang.String::*`
>> `-XX:CompileCommand=compileonly,*::hashCode`
>> `-XX:CompileCommand=compileonly,*ng.String::hashC*`
>> `-XX:CompileCommand=compileonly,*String::hash*`
>> 
>>  Invalid forms (Error: Embedded * not allowed):
>>  `-XX:CompileCommand=compileonly,java.*.String::has*Code`
>> 
>> ### Use CompileCommand syntax for CompileOnly
>> At the moment, in some cases it is not possible to just take pattern used with `CompileOnly` and plug it into compile command file. Syntax used by CompileOnly is also not very intuitive. 
>> 
>> `CompileOnly` is convenient because it's shorter to write and takes lists of patterns, whereas `CompileCommand` only takes one pattern per command. 
>> 
>> W...
>
> Tobias Holenstein has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update Test8211698.java
>  - Update src/hotspot/share/compiler/compilerOracle.cpp
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>
>  - Update src/hotspot/share/compiler/compilerOracle.cpp
>    
>    Co-authored-by: Christian Hagedorn <christian.hagedorn at oracle.com>

Update looks good!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13802#pullrequestreview-1452864244

From chagedorn at openjdk.org  Wed May 31 10:54:00 2023
From: chagedorn at openjdk.org (Christian Hagedorn)
Date: Wed, 31 May 2023 10:54:00 GMT
Subject: RFR: JDK-8282797: CompileCommand parsing errors should exit VM
 [v3]
In-Reply-To: <4ZMRDekcK4Yc3dS9rHvpqj9NcU6dH30aR7u2wtrc_Ac=.4f6c76cd-636a-445f-99e3-973e6fc51360@github.com>
References: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
 <4ZMRDekcK4Yc3dS9rHvpqj9NcU6dH30aR7u2wtrc_Ac=.4f6c76cd-636a-445f-99e3-973e6fc51360@github.com>
Message-ID: <CZwRg-IexyWf4_L2s7F3UManzM8mNs1_vg9SvvisxmE=.92a5916f-4248-494b-8517-80df1b963d10@github.com>

On Wed, 24 May 2023 11:05:01 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> Currently, errors during compile command parsing just print an error but don't exit the VM. As a result, issues go unnoticed. 
>> 
>> With this PR the behavior is changed to exit the VM when an error occurs.
>> 
>> E.g. `java -XX:CompileCommand=compileonly,HashMap:: -version` will exit the VM after a parsing occurred.  
>> 
>> CompileCommand: An error occurred during parsing
>> Error: Could not parse method pattern
>> Line: 'compileonly,HashMap::'
>> 
>> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
>> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
>> Use:   '-XX:CompileCommand=help' for more information and to list all option.
>> 
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>> 
>> 
>> ### Updated Tests
>> Updated all tests to now expect an error code `1` for wrong `CompileCommand`
>
> Tobias Holenstein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update Scenario.java
>  - Update compilerOracle.cpp

Thanks for doing the updates, looks good!

-------------

Marked as reviewed by chagedorn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13753#pullrequestreview-1452870393

From duke at openjdk.org  Wed May 31 11:51:56 2023
From: duke at openjdk.org (Rudi Horn)
Date: Wed, 31 May 2023 11:51:56 GMT
Subject: RFR: 8308748: JNU_GetStringPlatformChars may write to String's
 internal memory array [v2]
In-Reply-To: <z-Sp5itXRBV0S__vZF5OAzZR5W-l3lo2B8u2j-oaYKs=.77813e70-66d9-4080-9448-63b1f19ebbe7@github.com>
References: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>
 <z-Sp5itXRBV0S__vZF5OAzZR5W-l3lo2B8u2j-oaYKs=.77813e70-66d9-4080-9448-63b1f19ebbe7@github.com>
Message-ID: <-XXQZS3DTQRNCh0bgkkX0bCep65VZTxkyho-j_FPCQw=.bfb344b3-26fd-47bc-9903-235fe224346a@github.com>

On Fri, 26 May 2023 19:54:07 GMT, Rudi Horn <duke at openjdk.org> wrote:

>> This change prevents the contents of the internal string array from being copied back when releasing it.
>
> Rudi Horn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Use JNI_ABORT to release string bytes

I have not checked other uses, but they are probably not as critical yet given the special status and frequent use of strings. I can possibly revisit this issue in the future in a further issue / PR if I find time at some stage.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14117#issuecomment-1570043153

From rgiulietti at openjdk.org  Wed May 31 11:57:19 2023
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 31 May 2023 11:57:19 GMT
Subject: RFR: 8302987: Add uniform and spatially equidistributed bounded
 double streams to RandomGenerator [v10]
In-Reply-To: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
References: <8B2_dePA34zyndM7SzuG6sanXNQmbge8DCIOIfpnTLs=.81cb4f5b-e3d0-4352-8209-eb1ac6197126@github.com>
Message-ID: <X9t6_xr33svBkqZB_IKmfw4XQuo7VTQWwM6VLI0LgvM=.af9d703c-8583-4f1d-bb64-d67067807d33@github.com>

> The `default` method `nextDouble(double origin, double bound)` in `java.util.random.RandomGenerator` aims at generating a uniformly and spatially equidistributed random `double` in the left-closed and right-open range [`origin`, `bound`). It does so by applying the affine transform `origin + (bound - origin) * r` to a uniformly and spatially equidistributed random `double` `r` in the range [0, 1).
> 
> Since floating-point arithmetic suffers from small but noticeable rounding errors, this ends up slightly deforming the distribution of `r` when applying the affine transform.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Correction in comment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12719/files
  - new: https://git.openjdk.org/jdk/pull/12719/files/b3667a95..80e49d41

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12719&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12719.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12719/head:pull/12719

PR: https://git.openjdk.org/jdk/pull/12719

From sgehwolf at openjdk.org  Wed May 31 12:10:59 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 31 May 2023 12:10:59 GMT
Subject: RFR: 8308090: Add container tests for on-the-fly resource quota
 updates [v2]
In-Reply-To: <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
References: <w8L1msIb1ImXE3bWx4ZLaX3mg4MH_shRsN3CObIb-Ew=.1841e10b-595a-4bbb-9368-68897e4306df@github.com>
 <wM_d0lw-QV0H7VsCiI0QdOM-PKynxEFgz6wOVSPoJAU=.72b784bf-3656-4551-a3c9-1c33eb748e28@github.com>
Message-ID: <WwBB6c7YIkNIkVPmQFpqJjEGwfZtTGV0Guty90S15ys=.884557e0-be15-430f-b742-43d412a833d5@github.com>

On Tue, 23 May 2023 09:04:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review these test changes which implement automatic testing of container resource updates without JVM restart. Note that this merely tests container detection code handling this case. It doesn't do anything special for the JVM itself, though it might make sense to add some sanity checks should we detect certain limits changing. In another PR, though.
>> 
>> As to the test design, it works similar to the shared temp tests: Interact between the two containers by virtue of a shared filesystem `/tmp` and creating marker files there in order to make them cooperate. Note that the new test needs `podman` version `4.3.0` and better (`4.5` is current).
>> 
>> Testing:
>>  - [x] GHA
>>  - [x] Linux x86_64 container tests on cg v1 and cg v2 system
>>  - [x] Newly added tests on Linux x86_64 cg v1 and cg v2 (`podman` and `docker`)
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8308090-tests-container-on-fly-updates
>  - Fix whitespace
>  - 8308090: Add container tests for on-the-fly resource quota updates

Anyone willing to review this?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14090#issuecomment-1570090062

From jkuhn at openjdk.org  Wed May 31 12:41:10 2023
From: jkuhn at openjdk.org (Johannes Kuhn)
Date: Wed, 31 May 2023 12:41:10 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <sGcDTasCYK1w1ERRGa36Y_S197b0QsAPAoIfmoiOwN4=.4f29d7fd-fde8-4b9f-bb0e-79c97950b37e@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
 <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
 <NsNbY_G6Nb0x313vuzyiYg0ZLMz7wZc37zVBlw5XhVQ=.127f8d5b-5402-461b-b08e-0c1b4518fe0f@github.com>
 <98YBa_WBEwtCvYRDW5MGvaldIafXiTtF8NNtVntaDJ0=.0eb04101-f922-4ae8-b12b-1e8a926ec926@github.com>
 <f-DRv-zieo1-oPOMlGdcJkzXPQWQGohmGYd_Z7loJRQ=.bc7de20c-9627-44c9-9e37-c32da1905453@github.com>
 <hsjtEhKMBGFEYZQBM7exD58qbS5TBHtHj7w3utQu2Vw=.f83790b1-4cee-439d-a35c-d1365e799e84@github.com>
 <8P2hD5jJPd7oWhpg3AuFbjpXjJETdN_BR1ydkTySXlo=.2d0a8c28-9d9b-4a70-b54e-311e2bd86b7a@github.com>
 <V4XJOEZR3VHnoecHXtdKTuNr8SDbNW2azd_q5rczddQ=.9548a2b3-7b9f-4c1d-a7bb-2c6491ca4207@github.com>
 <wh2olb_Z8wi36ioSkfZVtyTx5ljmeAVGINd
 _tcSXsHQ=.5c9bd39e-70f7-4ff4-8f45-f9b6a539c2b8@github.com>
 <iLsWKeK_UFv0-KJNnfLeDanU_61eetQRNpAKiXyoQpw=.ba48aebe-5723-44da-b79b-b1a1fe9ba0d4@github.com>
 <BmuyK2Yoay6gxrKDF37Di_T-VQmgdTeiyGuwigCKR2c=.df9d9a2e-05e6-4369-a48b-8065fe176ccc@github.com>
 <sGcDTasCYK1w1ERRGa36Y_S197b0QsAPAoIfmoiOwN4=.4f29d7fd-fde8-4b9f-bb0e-79c97950b37e@github.com>
Message-ID: <V5Tin_gzxxJXvTyhDoDeYQJ8OV0IEwLfTwhwJg8h9gw=.b08b9d9b-0da7-4676-8b9d-81954d290a5b@github.com>

On Wed, 31 May 2023 00:49:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>>> Apparently, calling utility methods from sun.invoke, like the ensureOriginalLookup in this patch, also triggers this check. 
>> 
>> It should not trigger `checkPackageAccess` if it does not implement the interface AFAICT.
>> 
>> It would trigger module-access check.  `java.base` can export `sun.invoke` to the dynamic module (it may be worth considering putting the internal interface in a specific package for the dynamic module' use - `sun.invoke` is ok since it currently has one interface but hard to catch when someone adds a new class/interface in `sun.invoke` unintentionally and leak out sensitive API.
>
>> Then we still need to obtain the implemented interface and original method handle information every time they are queried. Having these information (or the method handle providing access) computed early is more convenient.
> 
> I was thinking the wrapper instance class still implements some private methods to get the implemented interface and original method handle which can be accessed only `java.base` via deep reflection.

> It should not trigger `checkPackageAccess` if it does not implement the interface AFAICT.

`checkPackageAccess` is also called by the application class loader:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java#L174-L189

It should make it impossible to reference for example `sun.misc.Unsafe`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1211652282

From jlaskey at openjdk.org  Wed May 31 12:57:28 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 31 May 2023 12:57:28 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v23]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <LahlzTLMRfyNpCv0UAH9Yqkq2VTnqWlkkJfuoUgyh_k=.81b99909-9dfd-4e83-ab8b-f7cf9b563fcf@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Remove mandated flag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13689/files
  - new: https://git.openjdk.org/jdk/pull/13689/files/06aa43ec..a8b31010

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=21-22

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From jlaskey at openjdk.org  Wed May 31 13:01:47 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 31 May 2023 13:01:47 GMT
Subject: RFR: JDK-8306112 Implementation of JEP 445: Unnamed Classes and
 Instance Main Methods (Preview) [v24]
In-Reply-To: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
References: <rxXkRfOzBJRwywc_f7X17F7bulTBf2UbgbXtJ2M06_E=.69bbb350-e66c-432e-9842-b7b6b597679d@github.com>
Message-ID: <G4eGE92rD9LTA6mHjokrlQZ5pYmk6w2lurJGZ8B0jDU=.49579b4c-41ad-467b-b164-40b8838923c6@github.com>

> Add flexible main methods and anonymous main classes to the Java language.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:

 - Merge branch 'master' into 8306112
 - Remove mandated flag
 - Remove trailing whitespace
 - Add main  tests for inferface/enum/record
 - Improving error recovery in presence of less important syntactic errors in top-level methods and fields.
   
   Author: Jan Lahoda <jlahoda at openjdk.org>
 - Ignore SKIPs (semicolon class declarations)
 - Allow unqualified access to unnamed class (internally visible)
 - Fix missing constructor error messages and handle inner class launching
 - Merge branch 'master' into 8306112
 - Issue warning if traditional main not used.
 - ... and 30 more: https://git.openjdk.org/jdk/compare/4aea7dab...d0189fc2

-------------

Changes: https://git.openjdk.org/jdk/pull/13689/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13689&range=23
  Stats: 1299 lines in 31 files changed: 1134 ins; 32 del; 133 mod
  Patch: https://git.openjdk.org/jdk/pull/13689.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13689/head:pull/13689

PR: https://git.openjdk.org/jdk/pull/13689

From rriggs at openjdk.org  Wed May 31 13:13:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 31 May 2023 13:13:57 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java [v2]
In-Reply-To: <e_6uyjz6ulTW54MUGTtc0h529lqygC0ajJpw7hBbGkE=.56e93f81-cd1a-4806-967f-1d16df6aa51f@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
 <yf5YFLRuy-uQWCyU6qxzN-miPEgrWogWJsBRU55Pv1M=.51bea42a-30ac-4c15-a077-7ba8f6818ed2@github.com>
 <f1N3rEFGq1NBbNtFhMNonuY0kx9NTylws4cYgrUk5Ao=.083a5c3c-9239-40fe-9cc4-3583a0ed066d@github.com>
 <e_6uyjz6ulTW54MUGTtc0h529lqygC0ajJpw7hBbGkE=.56e93f81-cd1a-4806-967f-1d16df6aa51f@github.com>
Message-ID: <CGbRTKyluD5aacA7MPBp6PPOJRYJexTP_Xs-mcfarTU=.34c4d50f-10eb-4941-a1b6-91a2d44dc23e@github.com>

On Wed, 31 May 2023 07:38:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> test/jdk/java/util/UUID/UUIDTest.java line 79:
>> 
>>> 77:             }
>>> 78:             if (!set.add(u)) {
>>> 79:                 throw new Exception("UUID collision: " + u);
>> 
>> I would be concerned that if this failure was reported, it would be intermittent, hard to track down, and not reproducible.  Without a hook for the generator and the seed, its just going to be noise in the testing.
>
> This is a non-practical concern, IMO. By spec, `UUID.randomUUID` is generated from the cryptographically secure random, with >120 bits of randomness, so the collision is extremely unlikely. Collision math involves birthday paradox, but Wikipedia article on UUIDs fortunately gives us the approximated solutions already:  https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions 
> 
> Quote: "Thus, the probability to find a duplicate within 103 trillion version-4 UUIDs is one in a billion." 
> 
> In other words, finding a collision in this test with 1M UUIDs points to the implementation issue, not a test bug, with a very high probability. In yet another words, if a unit test with 1M UUIDs is able to find a collision, then this is a strong signal that many production systems that assume extremely low collision probability are up for subtle misbehavior.

My point was that its probably not practical to test (more than once).  
If it fails, it will be considered just as you propose and disregarded and in the meantime consumes test cycles in each of the test contexts. Either provide more information about the conditions under which it failed or remove it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14134#discussion_r1211696030

From duke at openjdk.org  Wed May 31 13:17:04 2023
From: duke at openjdk.org (Francesco Nigro)
Date: Wed, 31 May 2023 13:17:04 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v2]
In-Reply-To: <4CAXWr5Ffw1orbTvcsHvyPFFVOBRPvDjrrWAVGVwFLA=.2963e519-8547-4101-84f5-d1a25273c785@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <8ybU8McnoXBXndd9E-YGmWN1zHhMlvHxnX4AY4cT5H8=.eb542d39-ef1e-41a8-9044-ca3b45bfe385@github.com>
 <I2onL10Ro48dfUZASSphE5PkWvaVQoWa4l2-EoxSZ5c=.dfe9629e-9b4f-46ff-8fa1-9404142da1f0@github.com>
 <KMys6Yuo20zpt9-NUcVdE9i0bK6h2Rx5XdL57sIWo1s=.7f52b357-882d-47e3-b1d2-059562490b02@github.com>
 <4CAXWr5Ffw1orbTvcsHvyPFFVOBRPvDjrrWAVGVwFLA=.2963e519-8547-4101-84f5-d1a25273c785@github.com>
Message-ID: <HySlc2M8Ahr6dEdht_hpiWXeqBcd0COe8OBAn2kRHAg=.79dd01ae-f64e-40bd-ad55-192d3754e1b4@github.com>

On Tue, 30 May 2023 09:32:02 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> @forax 
>> 
>> Hi! Sorry for this sudden message, but this one captured my attention
>> 
>>> and subtype checks are usually fast.
>> 
>> And I hope this PR to be the right place to raise this.
>> 
>> I was looking this PR to better understand how it applies to secondary supers and https://bugs.openjdk.org/browse/JDK-8180450 (that's still WIP) doesn't look like subtype checks are yet fast nor scalable (with multiple interfaces and > 1 receiver types observed) - see https://ionutbalosin.com/2023/03/jvm-performance-comparison-for-jdk-17/#typecheckscalabilitybenchmark that can be modified to use type switch too.
>>  
>> In addition, at least for secondary types, a missed `IsInstance` (ie which type isn't implemented) can cost O(n) over the secondary supers types (see https://ionutbalosin.com/2023/03/jvm-performance-comparison-for-jdk-17/#typecheckslowpathbenchmark) that's still not ideal, due to the high bootstrapping cost of `prnz scas`.
>> 
>> Hence, the implementation of type switch is likely to account for the existing (performance) deficiencies of the secondary supers type check or is relying on the fix https://bugs.openjdk.org/browse/JDK-8180450 that will appear at some point?
>> 
>> Hope to have interacted in the right way with this with the JDK dev community, and thanks again for your hard work on this wonderful piece of engineering!
>
> @franz1981, thanks for your comment. I am afraid I don't know much about JDK-8180450, but I suspect that it will affect the (type) switch lookup. Please correct me if I am wrong, but it seems this patch is still an improvement over the current state, and when JDK-8180450 is resolved, it should automatically improve the type switch lookup as well. So, this patch still seems useful to me, with a potential for future improvements, both inside and outside type switch bootstrap itself.

@lahodaj 

> So, this patch still seems useful to me, with a potential for future improvements, both inside and outside type switch bootstrap itself.

Yep, it is indeed still valuable: sorry if I didn't make it clear.
My point is more related the need of the amount of type checks in some cases (reducing the impact of JDK-8180450); if a typecheck-like op is still required  to route to some case (and which cost depends by many factors really), any target `checkcast` could be maybe saved. 
I'm currently unaware if the current state of this PR bring any improvement on this front too (or if is even possible), but this would be welcome regardless  JDK-8180450 and much more if considering the mentioned issue too.
This can be left for a follow-up PR too, obviously. I'm bringing the attention to this exactly because regardless JDK-8180450, secondary supers negative type check still have costs that would be awesome if could be addressed while exposing this feature to final users.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9779#issuecomment-1570214110

From alanb at openjdk.org  Wed May 31 13:19:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 31 May 2023 13:19:00 GMT
Subject: RFR: 8306647: Implementation of Structured Concurrency (Preview)
 [v2]
In-Reply-To: <ahxbOuGvkLfyetjIRr1bWZcza0DGH0RBxGwf95--k3A=.0825afc3-e9e6-44f4-9b4e-4ee55669ee3c@github.com>
References: <6gZZEoP1WXdBcZUiL5890eNsgaRFzZNY_rBItZdXtNc=.5d8f7bd9-44d5-4074-8a5c-35f8203263b2@github.com>
 <UW0KwW5uYPaaKzTgCRM2I6_R78E26N2SFDJPi-tjSvE=.4463ad73-3d3f-49c9-bc4f-c27c1decf11b@github.com>
 <ahxbOuGvkLfyetjIRr1bWZcza0DGH0RBxGwf95--k3A=.0825afc3-e9e6-44f4-9b4e-4ee55669ee3c@github.com>
Message-ID: <H-qnUTgPPqGEXGWUJ_5FFlaZS95esGiSD6vN5Xc5ytc=.91e83415-90bf-4f91-911a-26733a750213@github.com>

On Tue, 30 May 2023 17:31:54 GMT, R?mi Forax <forax at openjdk.org> wrote:

> One surprising thing is that Subtask.get() give less leeway to the owner thread than to the other virtual threads so in onComplete() storing a Subtask to use it later by the owner thread does not work well if join() is not called yet. This is perhaps a bit too much.

Maybe but it would be a bug if the owner were to call Subtask::get before joining. This is easy to detect for subtasks that are forked by the owner. Time will tell how common it will be for subtasks to fork additional subtasks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13932#issuecomment-1570217584

From asemenov at openjdk.org  Wed May 31 13:37:06 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 31 May 2023 13:37:06 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
Message-ID: <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>

> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
> They can be fixed with small changes.

Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:

  update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14033/files
  - new: https://git.openjdk.org/jdk/pull/14033/files/3f343c26..d5b70cb2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14033&range=01-02

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/14033.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14033/head:pull/14033

PR: https://git.openjdk.org/jdk/pull/14033

From asemenov at openjdk.org  Wed May 31 13:40:57 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 31 May 2023 13:40:57 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <_RQshJQSfZfWSXTPvIjEekBkNIJCGy6UPHo_94bE5IM=.afc7036a-4553-45f2-b5d2-76758e69dbb4@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <_RQshJQSfZfWSXTPvIjEekBkNIJCGy6UPHo_94bE5IM=.afc7036a-4553-45f2-b5d2-76758e69dbb4@github.com>
Message-ID: <E-QSGAHArixYuyceaYoN2y82lb6c5I46k4zTUySaPxg=.85916dea-e82e-48b9-9dcf-988eb89c7d2a@github.com>

On Sun, 28 May 2023 03:57:40 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c line 1163:
> 
>> 1161: #if defined(__clang__)
>> 1162: #pragma clang diagnostic push
>> 1163: #pragma clang diagnostic ignored "-Wparentheses"
> 
> I think this warning is because of the several `if (init_result = ...)`?  Better would be to just add the extra parens.

done

> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 575:
> 
>> 573: if (ps_pdread(ph, (char *)link_map_addr + LINK_MAP_LD_OFFSET,
>> 574:                &lib_ld, sizeof(uintptr_t)) != PS_OK) {
>> 575: #else
> 
> What problem is being "fixed" by these?  I'm dubious that this is the best solution to whatever the problem
> is, but can't evaluate or suggest alternatives without knowing what it is.

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211733228
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211732832

From asemenov at openjdk.org  Wed May 31 13:41:04 2023
From: asemenov at openjdk.org (Artem Semenov)
Date: Wed, 31 May 2023 13:41:04 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v2]
In-Reply-To: <fgcUzu1tyHuca8vlNWH_YqiTnDDHDvUZd7M3DB1vjsc=.b847b5af-1adb-414a-b4db-eca9d209f3a5@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <So49itlN8iwiVZ4-LlECl3FlQEgc_aCTxdIO3lcHW9k=.1d9e68b9-acec-4bb3-b5cc-8abb93482b35@github.com>
 <fgcUzu1tyHuca8vlNWH_YqiTnDDHDvUZd7M3DB1vjsc=.b847b5af-1adb-414a-b4db-eca9d209f3a5@github.com>
Message-ID: <pvomQkHL-opfRcxvMmsLepCi6JxuDQJjxecSeLZQ56w=.5992045c-32ab-44a7-9a96-a5bdc0c9dae5@github.com>

On Tue, 30 May 2023 08:14:59 GMT, Alexey Ushakov <avu at openjdk.org> wrote:

>> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update
>
> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 655:
> 
>> 653:       // linker loaded it. We use "base diff" in read_lib_segments call below.
>> 654: 
>> 655:                     if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_ADDR_OFFSET,
> 
> Extra white spaces before 'if'

done

> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 662:
> 
>> 660: 
>> 661:       // read address of the name
>> 662:                       if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NAME_OFFSET,
> 
> Extra white-spaces before 'if'

done

> src/jdk.hotspot.agent/linux/native/libsaproc/ps_core.c line 717:
> 
>> 715: 
>> 716:     // read next link_map address
>> 717:                     if (ps_pdread(ph, (psaddr_t) link_map_addr + LINK_MAP_NEXT_OFFSET,
> 
> Extra white-spaces before 'if'

done

> src/jdk.jpackage/share/native/common/tstrings.cpp line 60:
> 
>> 58: #endif
>> 59:         // With g++ this compiles only with '-std=gnu++0x' option
>> 60:                 ret = vsnprintf(&*fmtout.begin(), fmtout.size(), format, args);
> 
> Extra white-spaces before 'ret'

done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211732345
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211734132
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211734711
PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211735111

From weijun at openjdk.org  Wed May 31 13:55:57 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Wed, 31 May 2023 13:55:57 GMT
Subject: RFR: 8308286 Fix clang warnings in linux code [v3]
In-Reply-To: <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
References: <oxkyrkqc4_kv2LVEoai7qwzSANzEDWpL-_KEXejl3T4=.644882aa-253f-4a32-b2cd-00c44c701073@github.com>
 <CKiRtl0qFJAta3S3Ysa1wQHfQI34FDAW6qLvb8p336U=.2f3cfe22-b050-4483-b95b-b53aa8e2e78d@github.com>
Message-ID: <XCV9wPHhv83rnla_Y8LoBYJ9EdcQfuAlClsvp01vHdg=.d8982ce2-253e-4ba5-93f5-ca12c489c38b@github.com>

On Wed, 31 May 2023 13:37:06 GMT, Artem Semenov <asemenov at openjdk.org> wrote:

>> When using the clang compiler to build OpenJDk on Linux, we encounter various "warnings as errors".
>> They can be fixed with small changes.
>
> Artem Semenov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update

src/java.security.jgss/share/native/libj2gss/gssapi.h line 47:

> 45: 
> 46: // Condition was copied from
> 47: // Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/gssapi/gssapi.h

In the current version of the file above, it's written as

#if defined(__APPLE__) && (defined(__ppc__) ||...

Is it better?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14033#discussion_r1211757380

From shade at openjdk.org  Wed May 31 14:07:56 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 31 May 2023 14:07:56 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java [v2]
In-Reply-To: <CGbRTKyluD5aacA7MPBp6PPOJRYJexTP_Xs-mcfarTU=.34c4d50f-10eb-4941-a1b6-91a2d44dc23e@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
 <yf5YFLRuy-uQWCyU6qxzN-miPEgrWogWJsBRU55Pv1M=.51bea42a-30ac-4c15-a077-7ba8f6818ed2@github.com>
 <f1N3rEFGq1NBbNtFhMNonuY0kx9NTylws4cYgrUk5Ao=.083a5c3c-9239-40fe-9cc4-3583a0ed066d@github.com>
 <e_6uyjz6ulTW54MUGTtc0h529lqygC0ajJpw7hBbGkE=.56e93f81-cd1a-4806-967f-1d16df6aa51f@github.com>
 <CGbRTKyluD5aacA7MPBp6PPOJRYJexTP_Xs-mcfarTU=.34c4d50f-10eb-4941-a1b6-91a2d44dc23e@github.com>
Message-ID: <jlNWYEDnCsAXyVsHDMIcgDPSFk0FFHiaIglRYGlr10c=.91f4ca0d-a596-436c-918c-dc4dded6bf78@github.com>

On Wed, 31 May 2023 13:11:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This is a non-practical concern, IMO. By spec, `UUID.randomUUID` is generated from the cryptographically secure random, with >120 bits of randomness, so the collision is extremely unlikely. Collision math involves birthday paradox, but Wikipedia article on UUIDs fortunately gives us the approximated solutions already:  https://en.wikipedia.org/wiki/Universally_unique_identifier#Collisions 
>> 
>> Quote: "Thus, the probability to find a duplicate within 103 trillion version-4 UUIDs is one in a billion." 
>> 
>> In other words, finding a collision in this test with 1M UUIDs points to the implementation issue, not a test bug, with a very high probability. In yet another words, if a unit test with 1M UUIDs is able to find a collision, then this is a strong signal that many production systems that assume extremely low collision probability are up for subtle misbehavior.
>
> My point was that its probably not practical to test (more than once).  
> If it fails, it will be considered just as you propose and disregarded and in the meantime consumes test cycles in each of the test contexts. Either provide more information about the conditions under which it failed or remove it.

Sorry, I have trouble following the argument here.

Let me re-iterate: the probability for bona-fide collision is so vanishingly low, the test failure here is a strong signal that something is wrong with the implementation. We can put more guidance in the test comments there, like "This is extremely unlikely to happen. If you see this failing, this highly likely points to the implementation bug, rather than the odd chance."

What I expect to happen when that test fails, is that it prompts the investigation with multiple stress tests to get a better estimate of the actual collision rate. Assuming we actually see a collision, it is likely to be caused by much higher probability error somewhere in the code. In fact, if this test is _actually noisy_ to the point it becomes a testing problem, this already gives us the signal that actual collision rate is many orders of magnitude higher than math predicts, and this becomes an even _stronger_ signal that random UUIDs are seriously broken for practical use.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14134#discussion_r1211776452

From jlahoda at openjdk.org  Wed May 31 14:09:11 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 31 May 2023 14:09:11 GMT
Subject: RFR: 8291966: SwitchBootstrap.typeSwitch could be faster [v3]
In-Reply-To: <c_WqMRntlvIay9bD2C8eWuIDSzO4qjzaj0sLRnncO-A=.b0644ca2-cc42-4919-b53e-1e4eff866398@github.com>
References: <Ly0HhOtDjDHsREhQwwHh7hnJX_YzwxLQlL9UgrFC8N0=.cd0e0ecb-4d3e-4ef6-b861-0c4a921c4f6f@github.com>
 <c_WqMRntlvIay9bD2C8eWuIDSzO4qjzaj0sLRnncO-A=.b0644ca2-cc42-4919-b53e-1e4eff866398@github.com>
Message-ID: <TWCccPKtK5maQ3__2M8m6crRhBaIQGR_YDQGsqqSliA=.eadf8f5e-2a4a-4c70-baad-2b2a645c0025@github.com>

On Mon, 29 May 2023 07:25:26 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.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Reflecting review feedback.
>  - Merge branch 'master' into JDK-8291966
>  - Adding comments
>  - Improving performance
>  - Merge branch 'master' into JDK-8291966
>  - 8291966: SwitchBootstrap.typeSwitch could be faster

This patch is intended to eliminate some consecutive unnecessary tests like in case like:

switch (o) {
    case Runnable r when ... -> {}
    case Runnable r when ... -> {}
    case Runnable r when ... -> {}
    case Object o -> {}
}


If `o` is not a `Runnable`, the `instanceof` will only happen for the first case, and the rest will be skipped, as these tests could not pass. But (as a current limitation), if it is not a consecutive run, the duplicate `instanceof` checks will still happen.

I am quite sure there are ways to improve the bootstrap further, but might be better to have some (more) real-world examples to know what to optimize for.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9779#issuecomment-1570306708

From rriggs at openjdk.org  Wed May 31 14:08:09 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 31 May 2023 14:08:09 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v3]
In-Reply-To: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
Message-ID: <dQcW74NULRclIU7NamukdU6-SjnL8FgoeflolXa6bKk=.d3c9017d-d6f0-413e-b61a-27dca4024224@github.com>

> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
> 
> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
> The enum values directly reflect the build-time artifacts and resulting executables.
> 
> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:

 - Don't map ppc64le to ppc64 when processing the PlatformProps.java.template
 - Merge branch 'master' into 8308452-cross-platform-arch
 - Correct handling of ppc64le/ppc64 using non-canonical architecture.
   Keep canonical architecture names for s390, amd/x86_64.
 - Merge branch 'master' into 8308452-cross-platform-arch
 - Merge branch 'master' into 8308452-cross-platform-arch
 - Review suggestions
 - Correct address size for ARM (32-bit)
 - 8308452: Extend internal Architecture enum with byte order and address size

-------------

Changes: https://git.openjdk.org/jdk/pull/14063/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14063&range=02
  Stats: 149 lines in 6 files changed: 116 ins; 19 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/14063.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14063/head:pull/14063

PR: https://git.openjdk.org/jdk/pull/14063

From jvernee at openjdk.org  Wed May 31 14:10:09 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 31 May 2023 14:10:09 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
Message-ID: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>

In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch restricts the layouts that can be used as variadic layouts to what is allowed by the C specification.

The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.

I've added a small paragraph to the Linker javadoc as well that explains the restriction. Comments on that are welcome, but please explain.

The tests are updated to no longer try to link variadic functions with the illegal layouts, and I've added some more negative tests to TestIllegalLink.

Testing:
- local testing on Windows/x64
- tier1-3 + jdk-tier5 (ongoing)
- manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.

-------------

Commit messages:
 - fix word order
 - adjust whitespace
 - simplify test changes
 - reject invalid variadic layouts
 - VA Fixes

Changes: https://git.openjdk.org/jdk/pull/14225/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14225&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8308031
  Stats: 108 lines in 11 files changed: 95 ins; 3 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/14225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14225/head:pull/14225

PR: https://git.openjdk.org/jdk/pull/14225

From rriggs at openjdk.org  Wed May 31 14:20:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 31 May 2023 14:20:57 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java [v2]
In-Reply-To: <jlNWYEDnCsAXyVsHDMIcgDPSFk0FFHiaIglRYGlr10c=.91f4ca0d-a596-436c-918c-dc4dded6bf78@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
 <yf5YFLRuy-uQWCyU6qxzN-miPEgrWogWJsBRU55Pv1M=.51bea42a-30ac-4c15-a077-7ba8f6818ed2@github.com>
 <f1N3rEFGq1NBbNtFhMNonuY0kx9NTylws4cYgrUk5Ao=.083a5c3c-9239-40fe-9cc4-3583a0ed066d@github.com>
 <e_6uyjz6ulTW54MUGTtc0h529lqygC0ajJpw7hBbGkE=.56e93f81-cd1a-4806-967f-1d16df6aa51f@github.com>
 <CGbRTKyluD5aacA7MPBp6PPOJRYJexTP_Xs-mcfarTU=.34c4d50f-10eb-4941-a1b6-91a2d44dc23e@github.com>
 <jlNWYEDnCsAXyVsHDMIcgDPSFk0FFHiaIglRYGlr10c=.91f4ca0d-a596-436c-918c-dc4dded6bf78@github.com>
Message-ID: <R9C1lFcMM6jn3Enq6LVzUspD6FZNNUFTMXlHov6Oe6M=.0a29feb5-6baa-4a29-bc29-31a8d825e6ff@github.com>

On Wed, 31 May 2023 14:05:20 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> My point was that its probably not practical to test (more than once).  
>> If it fails, it will be considered just as you propose and disregarded and in the meantime consumes test cycles in each of the test contexts. Either provide more information about the conditions under which it failed or remove it.
>
> Sorry, I have trouble following the argument here.
> 
> Let me re-iterate: the probability for bona-fide collision is so vanishingly low, the test failure here is a strong signal that something is wrong with the implementation. We can put more guidance in the test comments there, like "This is extremely unlikely to happen. If you see this failing, this highly likely points to the implementation bug, rather than the odd chance."
> 
> What I expect to happen when that test fails, is that it prompts the investigation with multiple stress tests to get a better estimate of the actual collision rate. Assuming we actually see a collision, it is likely to be caused by much higher probability error somewhere in the code. In fact, if this test is _actually noisy_ to the point it becomes a testing problem, this already gives us the signal that actual collision rate is many orders of magnitude higher than math predicts, and this becomes an even _stronger_ signal that random UUIDs are seriously broken for practical use.

Two thoughts here. 
The random number source (SecureRandom) should have its own tests, UUID has a simple dependency on a generator.  
The test for UUID is that it composes the bits into the UUID correctly.  The randomness of the generator should be factored out.

Second, to raise concern about collisions, then the test should not throw on the first detected collision but complete the cycle and provide the simple stats on the number of collisions per COUNT (1,000,000).

All those 5 second test runs add up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14134#discussion_r1211795871

From rriggs at openjdk.org  Wed May 31 14:27:27 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 31 May 2023 14:27:27 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v5]
In-Reply-To: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
Message-ID: <Nud_3kJ0mTF1LoAMBsSEhZ3s15ONY9j6nC8nieQaGVw=.346978bf-d8b6-48bc-b297-9d04fd4aa369@github.com>

> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
> 
> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
> Mac OS X 10.15 is the oldest version supported.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:

 - Update OperatingSystem.version() to OSVersion.current()
 - Merge branch 'master' into 8304914-os-jpackage
 - Merge branch 'master' into 8304914-os-jpackage
 - Revert "The OperatingSystem enum treats AIX separately from Linux."  AIX is NOT an alias for Linux.
   This reverts commit 802456d52a3c85a2abd8830ea80147b212d2a5b0.
 - Merge branch 'master' into 8304914-os-jpackage
 - The OperatingSystem enum treats AIX separately from Linux. The original Platform used the same enum for both.
   Whereever OperatingSystem.isLinux is used in jpackage it should include isAix as well.
 - Minor source code style cleanup
 - Merge branch 'master' into 8304914-os-jpackage
 - Merge branch '8306678-os-version' into 8304914-os-jpackage
 - Merge branch '8304915-arch-enum' into 8306678-os-version
 - ... and 28 more: https://git.openjdk.org/jdk/compare/25b98030...ab6e20ce

-------------

Changes: https://git.openjdk.org/jdk/pull/13586/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13586&range=04
  Stats: 235 lines in 23 files changed: 40 ins; 132 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/13586.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13586/head:pull/13586

PR: https://git.openjdk.org/jdk/pull/13586

From rriggs at openjdk.org  Wed May 31 14:32:25 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 31 May 2023 14:32:25 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v6]
In-Reply-To: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
Message-ID: <PYVwu_Zar6MrJoeYaIQmRjTvrOTFxdSM8oqfrIIFKUQ=.68b30a66-9c78-4af4-b774-17dba8ded092@github.com>

> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
> 
> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
> Mac OS X 10.15 is the oldest version supported.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Add missing import of OSVersion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13586/files
  - new: https://git.openjdk.org/jdk/pull/13586/files/ab6e20ce..14bf4776

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13586&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13586&range=04-05

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/13586.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13586/head:pull/13586

PR: https://git.openjdk.org/jdk/pull/13586

From shade at openjdk.org  Wed May 31 14:53:09 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 31 May 2023 14:53:09 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java [v3]
In-Reply-To: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
Message-ID: <1uO4gDP7bumdfeOHtKPz_jeu25sS0djvvpAmuI44XjU=.113adccc-9bff-421b-be26-5350e00126d5@github.com>

> UUID is very important class that is used to track identities of objects in large scale systems. Yet, the coverage in JDK test is disappointing: it tests only 100 of UUID instances per test, which is way too small to detect collisions due to the bad randomness for example.
> 
> I have some pending work to improve UUID performance, and tests should be improved. 
> 
> The improved test still runs in less than 5 seconds on my laptop.

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Collect collisions and report them once at the end

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14134/files
  - new: https://git.openjdk.org/jdk/pull/14134/files/48d6bc5c..40aa3118

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14134&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14134&range=01-02

  Stats: 30 lines in 1 file changed: 27 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/14134.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14134/head:pull/14134

PR: https://git.openjdk.org/jdk/pull/14134

From shade at openjdk.org  Wed May 31 14:53:10 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 31 May 2023 14:53:10 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java [v2]
In-Reply-To: <R9C1lFcMM6jn3Enq6LVzUspD6FZNNUFTMXlHov6Oe6M=.0a29feb5-6baa-4a29-bc29-31a8d825e6ff@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
 <yf5YFLRuy-uQWCyU6qxzN-miPEgrWogWJsBRU55Pv1M=.51bea42a-30ac-4c15-a077-7ba8f6818ed2@github.com>
 <f1N3rEFGq1NBbNtFhMNonuY0kx9NTylws4cYgrUk5Ao=.083a5c3c-9239-40fe-9cc4-3583a0ed066d@github.com>
 <e_6uyjz6ulTW54MUGTtc0h529lqygC0ajJpw7hBbGkE=.56e93f81-cd1a-4806-967f-1d16df6aa51f@github.com>
 <CGbRTKyluD5aacA7MPBp6PPOJRYJexTP_Xs-mcfarTU=.34c4d50f-10eb-4941-a1b6-91a2d44dc23e@github.com>
 <jlNWYEDnCsAXyVsHDMIcgDPSFk0FFHiaIglRYGlr10c=.91f4ca0d-a596-436c-918c-dc4dded6bf78@github.com>
 <R9C1lFcMM6jn3Enq6LVzUspD6FZNNUFTMXlHov6Oe6M=.0a29feb5-6baa-4a29-bc29-31a8d825e6ff@github.com>
Message-ID: <llrZRexcp8lt9v25CtYetCoPDrxNU1q-9o0ADJ3B9wU=.3d66c517-92df-42a3-a109-47b99455a6ee@github.com>

On Wed, 31 May 2023 14:17:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Two thoughts here. The random number source (SecureRandom) should have its own tests, UUID has a simple dependency on a generator. The test for UUID is that it composes the bits into the UUID correctly. The randomness of the generator should be factored out.

This test verifies the way UUID uses the SecureRandom. Think about this as the less of a unit, and more of the integration test. This would be even more important once things like https://bugs.openjdk.org/browse/JDK-8308804 show up.

> Second, to raise concern about collisions, then the test should not throw on the first detected collision but complete the cycle and provide the simple stats on the number of collisions per COUNT (1,000,000).

All right, that we can do. See new commit.

> All those 5 second test runs add up.

Yes, and it would be sad to waste those 5 seconds on something irrelevant. I would argue that `UUID.randomUUID` breakage would be very unfortunate for the real world systems. Spending 5 seconds per test run on it is a good investment here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14134#discussion_r1211842661

From mcimadamore at openjdk.org  Wed May 31 15:44:02 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 31 May 2023 15:44:02 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
In-Reply-To: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
Message-ID: <86g7ouwA8SkmICALXwySWBWCgL8x75uCAU7fk5G1Xdg=.b23bc5e8-a4a1-4f87-99c1-8de1136b0306@github.com>

On Tue, 30 May 2023 17:25:35 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch restricts the layouts that can be used as variadic layouts to what is allowed by the C specification.
> 
> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
> 
> I've added a small paragraph to the Linker javadoc as well that explains the restriction. Comments on that are welcome, but please explain.
> 
> The tests are updated to no longer try to link variadic functions with the illegal layouts, and I've added some more negative tests to TestIllegalLink.
> 
> Testing:
> - local testing on Windows/x64
> - tier1-3 + jdk-tier5 (ongoing)
> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.

Looks good

src/java.base/share/classes/java/lang/foreign/Linker.java line 415:

> 413:  * It should be noted that values passed as variadic arguments undergo default argument promotion in C. Each value of
> 414:  * type {@code float} is converted to {@code double}, and each integral type smaller than {@code int} is converted to
> 415:  * {@code int}. As such, the native linker will reject attempts to link a function with variadic parameters which have

maybe "will reject attempts to link a variadic function if one or more parameter layouts in the provided function descriptor which correspond to a variadic argument is a value layout such that ..."

test/jdk/java/foreign/StdLibTest.java line 386:

> 384:             return arena.allocateUtf8String("str");
> 385:         }, "str"),
> 386:         CHAR(int.class, C_INT, "%c", arena -> (int) 'h', (int) 'h'), // promote to int, per C spec

is it important to retain this, given that there's already an INT case?

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14225#pullrequestreview-1453564448
PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1211924259
PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1211927081

From mcimadamore at openjdk.org  Wed May 31 15:44:04 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 31 May 2023 15:44:04 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
In-Reply-To: <86g7ouwA8SkmICALXwySWBWCgL8x75uCAU7fk5G1Xdg=.b23bc5e8-a4a1-4f87-99c1-8de1136b0306@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <86g7ouwA8SkmICALXwySWBWCgL8x75uCAU7fk5G1Xdg=.b23bc5e8-a4a1-4f87-99c1-8de1136b0306@github.com>
Message-ID: <Eer3yJHpD1aBcg2jbEuwvkg3yA1GRqC3aSfG-7zv_Ec=.f5e22b2b-b252-4b8c-994d-024fac4603fb@github.com>

On Wed, 31 May 2023 15:39:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch restricts the layouts that can be used as variadic layouts to what is allowed by the C specification.
>> 
>> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
>> 
>> I've added a small paragraph to the Linker javadoc as well that explains the restriction. Comments on that are welcome, but please explain.
>> 
>> The tests are updated to no longer try to link variadic functions with the illegal layouts, and I've added some more negative tests to TestIllegalLink.
>> 
>> Testing:
>> - local testing on Windows/x64
>> - tier1-3 + jdk-tier5 (ongoing)
>> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.
>
> test/jdk/java/foreign/StdLibTest.java line 386:
> 
>> 384:             return arena.allocateUtf8String("str");
>> 385:         }, "str"),
>> 386:         CHAR(int.class, C_INT, "%c", arena -> (int) 'h', (int) 'h'), // promote to int, per C spec
> 
> is it important to retain this, given that there's already an INT case?

Maybe adding a long case would be more useful?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1211927710

From rriggs at openjdk.org  Wed May 31 15:50:00 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 31 May 2023 15:50:00 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v6]
In-Reply-To: <PYVwu_Zar6MrJoeYaIQmRjTvrOTFxdSM8oqfrIIFKUQ=.68b30a66-9c78-4af4-b774-17dba8ded092@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
 <PYVwu_Zar6MrJoeYaIQmRjTvrOTFxdSM8oqfrIIFKUQ=.68b30a66-9c78-4af4-b774-17dba8ded092@github.com>
Message-ID: <Lz4qsfTr-3IewdyQ1mppnNxWTszk9YS4aNLf6CqKQLo=.cae1a873-6453-48df-8df6-671f65a2fb29@github.com>

On Wed, 31 May 2023 14:32:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
>> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
>> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
>> 
>> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
>> Mac OS X 10.15 is the oldest version supported.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing import of OSVersion

Merged with current head and retested.  Any other concerns?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13586#issuecomment-1570484204

From naoto at openjdk.org  Wed May 31 16:00:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 31 May 2023 16:00:15 GMT
Subject: Integrated: 8308316: Default decomposition mode in Collator
In-Reply-To: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>
References: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>
Message-ID: <CHFd3WpcoLkajx9Gzd-x0PkXx1RBloRYlGyhyQirarA=.ba2bc889-5402-43d5-8221-452d40be2add@github.com>

On Thu, 18 May 2023 18:02:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Amending the description about the default decomposition mode in `Collator.NO_DECOMPOSITION` javadoc.

This pull request has now been integrated.

Changeset: 12649025
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/126490251721d131098a0bc2def8fd02f97cd5af
Stats:     5 lines in 1 file changed: 1 ins; 0 del; 4 mod

8308316: Default decomposition mode in Collator

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/14049

From mchung at openjdk.org  Wed May 31 16:02:10 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 31 May 2023 16:02:10 GMT
Subject: RFR: 6983726: Reimplement MethodHandleProxies.asInterfaceInstance
 [v16]
In-Reply-To: <V5Tin_gzxxJXvTyhDoDeYQJ8OV0IEwLfTwhwJg8h9gw=.b08b9d9b-0da7-4676-8b9d-81954d290a5b@github.com>
References: <T5t4U8Z7MRWkizXMAfO-GUC4f2g4q0akSSmyOgVzLVs=.d192aabd-88a6-4976-ba06-38c918550ae7@github.com>
 <aemFVWHp6VTuQL5er46IYVgA65lS8feViT-NjelZXPQ=.762f7693-1b5b-4518-8c62-a052a171b907@github.com>
 <bFyZLYKFyfpMGvrxxRuK-wVceAtzPvMEI-ScALx_sd4=.d848c4cf-55bd-4c03-a2e6-2cc978c1fafe@github.com>
 <nwgIHnHPZ0S4mTVSaaCcWjUGhkc5MFqqWDyJ4601cEQ=.d49543e2-c1a4-4a8f-aae0-5fedc248eefe@github.com>
 <NsNbY_G6Nb0x313vuzyiYg0ZLMz7wZc37zVBlw5XhVQ=.127f8d5b-5402-461b-b08e-0c1b4518fe0f@github.com>
 <98YBa_WBEwtCvYRDW5MGvaldIafXiTtF8NNtVntaDJ0=.0eb04101-f922-4ae8-b12b-1e8a926ec926@github.com>
 <f-DRv-zieo1-oPOMlGdcJkzXPQWQGohmGYd_Z7loJRQ=.bc7de20c-9627-44c9-9e37-c32da1905453@github.com>
 <hsjtEhKMBGFEYZQBM7exD58qbS5TBHtHj7w3utQu2Vw=.f83790b1-4cee-439d-a35c-d1365e799e84@github.com>
 <8P2hD5jJPd7oWhpg3AuFbjpXjJETdN_BR1ydkTySXlo=.2d0a8c28-9d9b-4a70-b54e-311e2bd86b7a@github.com>
 <V4XJOEZR3VHnoecHXtdKTuNr8SDbNW2azd_q5rczddQ=.9548a2b3-7b9f-4c1d-a7bb-2c6491ca4207@github.com>
 <wh2olb_Z8wi36ioSkfZVtyTx5ljmeAVGINd
 _tcSXsHQ=.5c9bd39e-70f7-4ff4-8f45-f9b6a539c2b8@github.com>
 <iLsWKeK_UFv0-KJNnfLeDanU_61eetQRNpAKiXyoQpw=.ba48aebe-5723-44da-b79b-b1a1fe9ba0d4@github.com>
 <BmuyK2Yoay6gxrKDF37Di_T-VQmgdTeiyGuwigCKR2c=.df9d9a2e-05e6-4369-a48b-8065fe176ccc@github.com>
 <sGcDTasCYK1w1ERRGa36Y_S197b0QsAPAoIfmoiOwN4=.4f29d7fd-fde8-4b9f-bb0e-79c97950b37e@github.com>
 <V5Tin_gzxxJXvTyhDoDeYQJ8OV0IEwLfTwhwJg8h9gw=.b08b9d9b-0da7-4676-8b9d-81954d290a5b@github.com>
Message-ID: <CSt-m0IKRHSpTsVy9QxmclkukOnCvXZ_cFUiasRAN9g=.fbaa8d6b-c50f-4b1c-91ed-7e54315483d1@github.com>

On Wed, 31 May 2023 12:38:14 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

>>> Then we still need to obtain the implemented interface and original method handle information every time they are queried. Having these information (or the method handle providing access) computed early is more convenient.
>> 
>> I was thinking the wrapper instance class still implements some private methods to get the implemented interface and original method handle which can be accessed only `java.base` via deep reflection.
>
>> It should not trigger `checkPackageAccess` if it does not implement the interface AFAICT.
> 
> `checkPackageAccess` is also called by the application class loader:
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/loader/ClassLoaders.java#L174-L189
> 
> It should make it impossible to reference for example `sun.misc.Unsafe`.

I'm referring to the private `ClassLoader.checkPackageAccess(Class<?> cls, ProtectionDomain pd)` method that is only invoked by the VM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13197#discussion_r1211956537

From naoto at openjdk.org  Wed May 31 16:04:02 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 31 May 2023 16:04:02 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v3]
In-Reply-To: <dQcW74NULRclIU7NamukdU6-SjnL8FgoeflolXa6bKk=.d3c9017d-d6f0-413e-b61a-27dca4024224@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
 <dQcW74NULRclIU7NamukdU6-SjnL8FgoeflolXa6bKk=.d3c9017d-d6f0-413e-b61a-27dca4024224@github.com>
Message-ID: <WquxSModp6xG2lyiwraJNknm6VuKOZg0gEGJroHXERs=.a76b037a-4d5a-459c-9493-6e9b992bad2d@github.com>

On Wed, 31 May 2023 14:08:09 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
>> 
>> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
>> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
>> The enum values directly reflect the build-time artifacts and resulting executables.
>> 
>> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Don't map ppc64le to ppc64 when processing the PlatformProps.java.template
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Correct handling of ppc64le/ppc64 using non-canonical architecture.
>    Keep canonical architecture names for s390, amd/x86_64.
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Merge branch 'master' into 8308452-cross-platform-arch
>  - Review suggestions
>  - Correct address size for ARM (32-bit)
>  - 8308452: Extend internal Architecture enum with byte order and address size

src/java.base/share/classes/jdk/internal/util/OperatingSystem.java line 29:

> 27: import jdk.internal.vm.annotation.ForceInline;
> 28: 
> 29: import java.util.Locale;

Nit: Stray import?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14063#discussion_r1211959219

From alanb at openjdk.org  Wed May 31 16:20:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 31 May 2023 16:20:55 GMT
Subject: RFR: 8289220: [Shenandoah] TestAllocObjectArrays fails
 intermittently
In-Reply-To: <GOxbhP3BXGBlNsKCAmnVF6hl0xg5oXpItR7WLtLJwOY=.1c8bbd73-8708-47e5-bdbb-3ce34cda7697@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <GOxbhP3BXGBlNsKCAmnVF6hl0xg5oXpItR7WLtLJwOY=.1c8bbd73-8708-47e5-bdbb-3ce34cda7697@github.com>
Message-ID: <My4tRq39smbhtJgChhGkmDaLZ0ARSG8MKOtdsf4eqkA=.9d68b39b-252e-4a79-9f94-4265edc1ac7f@github.com>

On Wed, 31 May 2023 10:00:18 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> Jtreg tier1 can trigger the same error with vmoptions:"-Xcomp -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot I found the GC occurs between when the soft reference is assigned and when it is used.

Yes, this seems to be a bug here so I think move the issue to core-libs/java.util:i18n as it looks like the caching done by BaseLocale needs to be re-examined.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1570534648

From xuelei at openjdk.org  Wed May 31 16:30:12 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 31 May 2023 16:30:12 GMT
Subject: Integrated: 8308022: update for deprecated sprintf for java.base
In-Reply-To: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
Message-ID: <rCdBonJOna_uEXj1KxzrDtAXDbLejGQXDRvZQKxABUQ=.f47b45c6-0e49-4fe7-bbd8-b17f20b95a6d@github.com>

On Fri, 12 May 2023 17:57:43 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.
> 
> Thanks,
> Xuelei

This pull request has now been integrated.

Changeset: 42ca6e69
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42ca6e69420e090cdec16f3bd1e5c70506511663
Stats:     37 lines in 6 files changed: 5 ins; 0 del; 32 mod

8308022: update for deprecated sprintf for java.base

Reviewed-by: naoto

-------------

PR: https://git.openjdk.org/jdk/pull/13963

From liach at openjdk.org  Wed May 31 16:32:09 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 31 May 2023 16:32:09 GMT
Subject: Integrated: 8299505: findVirtual on array classes incorrectly
 restricts the receiver type
In-Reply-To: <Mzve--7vLKag1ieybf8aCSQp3uBJ_g9aSmyrevTNhtA=.591264e8-1219-4c1b-86fd-acc75edfd553@github.com>
References: <Mzve--7vLKag1ieybf8aCSQp3uBJ_g9aSmyrevTNhtA=.591264e8-1219-4c1b-86fd-acc75edfd553@github.com>
Message-ID: <ZquK4tAHYZAC1mAyHyoQ4SyaeSKeZfVePIb30A7q6MU=.6d26523c-e8d0-4727-8eb5-fede9fdefdbf@github.com>

On Sat, 6 May 2023 18:15:56 GMT, Chen Liang <liach at openjdk.org> wrote:

> The access hack for array class clone is only applied to `checkAccess` but missing before call to `restrictProtectedReceiver`, causing the array receiver type to be incorrectly replaced by the lookupClass type. This patch fixes that and adds a test to ensure an original lookup resolves `clone` for both array classes (public) and Object (inherited protected) correctly, and restores the old MethodHandlesGeneralTest from [JDK-8001105](https://bugs.openjdk.org/browse/JDK-8001105) which ensures correctness for publicLookup (which is already correct).

This pull request has now been integrated.

Changeset: 78aa5f3f
Author:    Chen Liang <liach at openjdk.org>
Committer: Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78aa5f3fc1c7fc7929e0d2b5d94da0827483b7c5
Stats:     104 lines in 3 files changed: 88 ins; 9 del; 7 mod

8299505: findVirtual on array classes incorrectly restricts the receiver type

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/13855

From darcy at openjdk.org  Wed May 31 16:54:32 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 31 May 2023 16:54:32 GMT
Subject: Integrated: 8309230: ProblemList
 jdk/incubator/vector/Float64VectorTests.java on aarch64
In-Reply-To: <JfT9kSRrxVTsgf84yNnJ04v9tbc4RqusylpIc_JMOcM=.99cd76b3-554c-4b20-9179-1732031c99ef@github.com>
References: <JfT9kSRrxVTsgf84yNnJ04v9tbc4RqusylpIc_JMOcM=.99cd76b3-554c-4b20-9179-1732031c99ef@github.com>
Message-ID: <g5aHmlB4fI38fIwKSYI9xpWUazgZ95oCKugijSuXScA=.b1e0c05f-ff25-4d46-81f1-9443d0fe0f55@github.com>

On Wed, 31 May 2023 16:40:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A couple of trivial ProblemListings:
> [JDK-8309230](https://bugs.openjdk.org/browse/JDK-8309230) ProblemList jdk/incubator/vector/Float64VectorTests.java on aarch64
> [JDK-8309231](https://bugs.openjdk.org/browse/JDK-8309231) ProblemList vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/TestDescription.java

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14250#pullrequestreview-1453713285

From dcubed at openjdk.org  Wed May 31 16:54:32 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 31 May 2023 16:54:32 GMT
Subject: Integrated: 8309230: ProblemList
 jdk/incubator/vector/Float64VectorTests.java on aarch64
In-Reply-To: <g5aHmlB4fI38fIwKSYI9xpWUazgZ95oCKugijSuXScA=.b1e0c05f-ff25-4d46-81f1-9443d0fe0f55@github.com>
References: <JfT9kSRrxVTsgf84yNnJ04v9tbc4RqusylpIc_JMOcM=.99cd76b3-554c-4b20-9179-1732031c99ef@github.com>
 <g5aHmlB4fI38fIwKSYI9xpWUazgZ95oCKugijSuXScA=.b1e0c05f-ff25-4d46-81f1-9443d0fe0f55@github.com>
Message-ID: <M2O5Mj9TQndZADBhYXiWicdcZD2cuKb9uhB-FdwJznY=.63c137ed-5ebe-469c-98a3-7c94e87e2dc5@github.com>

On Wed, 31 May 2023 16:48:06 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> A couple of trivial ProblemListings:
>> [JDK-8309230](https://bugs.openjdk.org/browse/JDK-8309230) ProblemList jdk/incubator/vector/Float64VectorTests.java on aarch64
>> [JDK-8309231](https://bugs.openjdk.org/browse/JDK-8309231) ProblemList vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/TestDescription.java
>
> Marked as reviewed by darcy (Reviewer).

@jddarcy - Thanks for the fast review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14250#issuecomment-1570578322

From dcubed at openjdk.org  Wed May 31 16:54:32 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 31 May 2023 16:54:32 GMT
Subject: Integrated: 8309230: ProblemList
 jdk/incubator/vector/Float64VectorTests.java on aarch64
In-Reply-To: <JfT9kSRrxVTsgf84yNnJ04v9tbc4RqusylpIc_JMOcM=.99cd76b3-554c-4b20-9179-1732031c99ef@github.com>
References: <JfT9kSRrxVTsgf84yNnJ04v9tbc4RqusylpIc_JMOcM=.99cd76b3-554c-4b20-9179-1732031c99ef@github.com>
Message-ID: <2OqqZel510pZtVD9yrFJWq0bp9QG6gtye9d9_gIr_gw=.de9d9ad5-004e-43c2-9b67-121a5b0c50c4@github.com>

On Wed, 31 May 2023 16:40:54 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A couple of trivial ProblemListings:
> [JDK-8309230](https://bugs.openjdk.org/browse/JDK-8309230) ProblemList jdk/incubator/vector/Float64VectorTests.java on aarch64
> [JDK-8309231](https://bugs.openjdk.org/browse/JDK-8309231) ProblemList vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/TestDescription.java

This pull request has now been integrated.

Changeset: 45473ef2
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45473ef23520271954fa7196a5be588f88337aaf
Stats:     2 lines in 2 files changed: 1 ins; 0 del; 1 mod

8309230: ProblemList jdk/incubator/vector/Float64VectorTests.java on aarch64
8309231: ProblemList vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/TestDescription.java

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/14250

From dcubed at openjdk.org  Wed May 31 16:54:32 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 31 May 2023 16:54:32 GMT
Subject: Integrated: 8309230: ProblemList
 jdk/incubator/vector/Float64VectorTests.java on aarch64
Message-ID: <JfT9kSRrxVTsgf84yNnJ04v9tbc4RqusylpIc_JMOcM=.99cd76b3-554c-4b20-9179-1732031c99ef@github.com>

A couple of trivial ProblemListings:
[JDK-8309230](https://bugs.openjdk.org/browse/JDK-8309230) ProblemList jdk/incubator/vector/Float64VectorTests.java on aarch64
[JDK-8309231](https://bugs.openjdk.org/browse/JDK-8309231) ProblemList vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/TestDescription.java

-------------

Commit messages:
 - 8309231: ProblemList vmTestbase/nsk/jvmti/scenarios/jni_interception/JI05/ji05t001/TestDescription.java
 - 8309230: ProblemList jdk/incubator/vector/Float64VectorTests.java on aarch64

Changes: https://git.openjdk.org/jdk/pull/14250/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14250&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309230
  Stats: 2 lines in 2 files changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/14250.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14250/head:pull/14250

PR: https://git.openjdk.org/jdk/pull/14250

From asemenyuk at openjdk.org  Wed May 31 18:10:57 2023
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 31 May 2023 18:10:57 GMT
Subject: RFR: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage [v6]
In-Reply-To: <PYVwu_Zar6MrJoeYaIQmRjTvrOTFxdSM8oqfrIIFKUQ=.68b30a66-9c78-4af4-b774-17dba8ded092@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
 <PYVwu_Zar6MrJoeYaIQmRjTvrOTFxdSM8oqfrIIFKUQ=.68b30a66-9c78-4af4-b774-17dba8ded092@github.com>
Message-ID: <gIZVlCFPbyMGc0JEfZAKhUu3DwX0KsBKbx4fVEwaePw=.725189ae-26a7-46a7-8025-9886a2c495f9@github.com>

On Wed, 31 May 2023 14:32:25 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
>> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
>> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
>> 
>> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
>> Mac OS X 10.15 is the oldest version supported.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add missing import of OSVersion

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13586#pullrequestreview-1453868736

From jlahoda at openjdk.org  Wed May 31 18:16:00 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 31 May 2023 18:16:00 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3]
In-Reply-To: <cynjYPdpmMlzG4z-zoqhUFun0Uf8Op52etkgvkVaVkg=.5d133ecd-056b-49c3-8655-6856d22d163f@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <cynjYPdpmMlzG4z-zoqhUFun0Uf8Op52etkgvkVaVkg=.5d133ecd-056b-49c3-8655-6856d22d163f@github.com>
Message-ID: <dRojIK8Qr4KltCgwd9mW0AtH7W2BBdEGyIR87RLFb38=.4cf93d65-860c-4633-b855-e7b9f41c7226@github.com>

On Tue, 30 May 2023 22:16:08 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Time to get JDK 22 underway...
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
> 
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Sync in symbol changes for JDK 21 build 24.
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Merge branch 'master' into JDK-8306584
>  - Minor test fixes.
>  - Merge branch 'master' into JDK-8306584
>  - Update symbol files to JDK 21 b23.
>  - ... and 14 more: https://git.openjdk.org/jdk/compare/cb40db05...376dbe26

javac and symbol related changes seem reasonable to me. Two minor comments added for consideration.

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java line 127:

> 125:         V64(64, 0),   // JDK 20
> 126:         V65(65, 0),   // JDK 21
> 127:         V66(66, 0);   // JDK 22

A very small nit/suggestion - it should be possible to do:

V66(66, 0),   //JDK 22
;


(i.e. ending the enum constant with `,`, and putting the semicolon on a new line.) This way adding a new constant would mean just one line addition, no modification. (The same could be done for other enums.)

test/langtools/tools/javac/versions/Versions.java line 93:

> 91:         TWENTY(false,    "64.0", "20", Versions::checksrc20),
> 92:         TWENTY_ONE(false,"65.0", "21", Versions::checksrc21),
> 93:         TWENTY_TWO(false,"66.0", "22", Versions::checksrc21);

Should there be `checksrc22` instead of `checksrc21`? Or is that done later?

-------------

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13567#pullrequestreview-1453854784
PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1212101629
PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1212114188

From rriggs at openjdk.org  Wed May 31 18:25:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 31 May 2023 18:25:18 GMT
Subject: RFR: 8308452: Extend internal Architecture enum with byte order
 and address size [v4]
In-Reply-To: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
References: <_Fr_0vFGxkzKl26U0eh0V088HjtpWmOjR6E5vYrwVLw=.9d7b5195-778c-4546-92bf-1730a8550fbc@github.com>
Message-ID: <EBUrzkm_HMrEo7qEhu0QHeHB3pKu9QXfMN6hcfFkiTA=.5c8bb4cb-8c68-4591-a988-b167a9eb0e18@github.com>

> The internal enum jdk.internal.util.Architecture does not provide information about the big or little endianness or the address size (64 or 32 bits).  The endian-ness and address size are intrinsic to the architecture.
> 
> The values of the enum are extended to separately identify the big endian and little-endian uses of the ISA.
> For example, `PPC64` and `PPC64LE` for the big and little-endian versions.  
> The enum values directly reflect the build-time artifacts and resulting executables.
> 
> This information about an architecture will make the enum more useful especially to identify a target platform in a cross-platform use case. A method is added to map well known aliases for the platforms to the Architecture enum.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove duplicate import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14063/files
  - new: https://git.openjdk.org/jdk/pull/14063/files/a6abcdfe..aafcc7de

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14063&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14063&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14063.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14063/head:pull/14063

PR: https://git.openjdk.org/jdk/pull/14063

From mchung at openjdk.org  Wed May 31 18:29:00 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 31 May 2023 18:29:00 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale
In-Reply-To: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
Message-ID: <CUEFPa3b5IBtSoMuC_VdXMn1bbFu1Ud14rsiJr4-b9g=.e64eec94-db8c-4681-9eef-cf302242d54c@github.com>

On Sun, 29 Jan 2023 15:37:28 GMT, Glavo <duke at openjdk.org> wrote:

> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
> 
> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
> * The jimage command cannot obtain the help information of the `list` mode.

`jdk.jlink` uses `Locale.ROOT` in most calls.   I suggest to change the existing references of `Locale.ENGLISH` to use `Locale.ROOT` (one in JImageTask and one in JlinkTask).   Should consider also change `VersionPropsPlugin` although not strictly necessary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12281#issuecomment-1570709944

From rriggs at openjdk.org  Wed May 31 18:33:58 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 31 May 2023 18:33:58 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java [v2]
In-Reply-To: <llrZRexcp8lt9v25CtYetCoPDrxNU1q-9o0ADJ3B9wU=.3d66c517-92df-42a3-a109-47b99455a6ee@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
 <yf5YFLRuy-uQWCyU6qxzN-miPEgrWogWJsBRU55Pv1M=.51bea42a-30ac-4c15-a077-7ba8f6818ed2@github.com>
 <f1N3rEFGq1NBbNtFhMNonuY0kx9NTylws4cYgrUk5Ao=.083a5c3c-9239-40fe-9cc4-3583a0ed066d@github.com>
 <e_6uyjz6ulTW54MUGTtc0h529lqygC0ajJpw7hBbGkE=.56e93f81-cd1a-4806-967f-1d16df6aa51f@github.com>
 <CGbRTKyluD5aacA7MPBp6PPOJRYJexTP_Xs-mcfarTU=.34c4d50f-10eb-4941-a1b6-91a2d44dc23e@github.com>
 <jlNWYEDnCsAXyVsHDMIcgDPSFk0FFHiaIglRYGlr10c=.91f4ca0d-a596-436c-918c-dc4dded6bf78@github.com>
 <R9C1lFcMM6jn3Enq6LVzUspD6FZNNUFTMXlHov6Oe6M=.0a29feb5-6baa-4a29-bc29-31a8d825e6ff@github.com>
 <llrZRexcp8lt9v25CtYetCoPDrxNU1q-9o0ADJ3B9wU=.3d66c517-92df-42a3-a109-47b99455a6ee@github.com>
Message-ID: <SzVtoFWcFQa7NxbUy09_aZ5Bw_DEnQa_9ibKLmNlOUQ=.04b8973a-02f2-4c8e-bd86-db3c9b3c5fe6@github.com>

On Wed, 31 May 2023 14:46:59 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Two thoughts here. 
>> The random number source (SecureRandom) should have its own tests, UUID has a simple dependency on a generator.  
>> The test for UUID is that it composes the bits into the UUID correctly.  The randomness of the generator should be factored out.
>> 
>> Second, to raise concern about collisions, then the test should not throw on the first detected collision but complete the cycle and provide the simple stats on the number of collisions per COUNT (1,000,000).
>> 
>> All those 5 second test runs add up.
>
>> Two thoughts here. The random number source (SecureRandom) should have its own tests, UUID has a simple dependency on a generator. The test for UUID is that it composes the bits into the UUID correctly. The randomness of the generator should be factored out.
> 
> This test verifies the way UUID uses the SecureRandom. Think about this as the less of a unit, and more of the integration test. This would be even more important once things like https://bugs.openjdk.org/browse/JDK-8308804 show up.
> 
>> Second, to raise concern about collisions, then the test should not throw on the first detected collision but complete the cycle and provide the simple stats on the number of collisions per COUNT (1,000,000).
> 
> All right, that we can do. See new commit.
> 
>> All those 5 second test runs add up.
> 
> Yes, and it would be sad to waste those 5 seconds on something irrelevant. I would argue that `UUID.randomUUID` breakage would be very unfortunate for the real world systems. Spending 5 seconds per test run on it is a good investment here.

We're into the area of diminishing returns.  
I'd expect the implementation bug mentioned above would be found by far fewer iterations. 
Thanks for the test change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14134#discussion_r1212139442

From rriggs at openjdk.org  Wed May 31 18:33:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 31 May 2023 18:33:56 GMT
Subject: RFR: 8308803: Improve java/util/UUID/UUIDTest.java [v3]
In-Reply-To: <1uO4gDP7bumdfeOHtKPz_jeu25sS0djvvpAmuI44XjU=.113adccc-9bff-421b-be26-5350e00126d5@github.com>
References: <HI-H45vFdc1SQu2ob2Job_b94mrVHCwmli8WPOlcuG8=.fa1c1905-af02-446d-91e6-0f9d0eb3848d@github.com>
 <1uO4gDP7bumdfeOHtKPz_jeu25sS0djvvpAmuI44XjU=.113adccc-9bff-421b-be26-5350e00126d5@github.com>
Message-ID: <vn_xV3nUjOWVMT1gWriseQ3oaJu1CKU9Q7BvIoCl6Mk=.8c39b42e-78e5-4d2e-b301-2cb1f93cae5d@github.com>

On Wed, 31 May 2023 14:53:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> UUID is very important class that is used to track identities of objects in large scale systems. Yet, the coverage in JDK test is disappointing: it tests only 100 of UUID instances per test, which is way too small to detect collisions due to the bad randomness for example.
>> 
>> I have some pending work to improve UUID performance, and tests should be improved. 
>> 
>> The improved test still runs in less than 5 seconds on my laptop.
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Collect collisions and report them once at the end

Looks good, thanks for the updates.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14134#pullrequestreview-1453903860

From kvn at openjdk.org  Wed May 31 19:01:45 2023
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Wed, 31 May 2023 19:01:45 GMT
Subject: RFR: JDK-8282797: CompileCommand parsing errors should exit VM
 [v3]
In-Reply-To: <4ZMRDekcK4Yc3dS9rHvpqj9NcU6dH30aR7u2wtrc_Ac=.4f6c76cd-636a-445f-99e3-973e6fc51360@github.com>
References: <xFdMV-9La9W5y_n8qKWZ62Is4nksHO_VwdGFFH89VcU=.6dc032bf-1854-4cab-9fd9-628cecec8d73@github.com>
 <4ZMRDekcK4Yc3dS9rHvpqj9NcU6dH30aR7u2wtrc_Ac=.4f6c76cd-636a-445f-99e3-973e6fc51360@github.com>
Message-ID: <9JYXI2snHKlZ3prTgMdCUsugWnLCiWwc2_9DBUQoBrU=.bbd26296-2d87-4ac4-a915-c57ae2691be3@github.com>

On Wed, 24 May 2023 11:05:01 GMT, Tobias Holenstein <tholenstein at openjdk.org> wrote:

>> Currently, errors during compile command parsing just print an error but don't exit the VM. As a result, issues go unnoticed. 
>> 
>> With this PR the behavior is changed to exit the VM when an error occurs.
>> 
>> E.g. `java -XX:CompileCommand=compileonly,HashMap:: -version` will exit the VM after a parsing occurred.  
>> 
>> CompileCommand: An error occurred during parsing
>> Error: Could not parse method pattern
>> Line: 'compileonly,HashMap::'
>> 
>> Usage: '-XX:CompileCommand=<option>,<method pattern>' - to set boolean option to true
>> Usage: '-XX:CompileCommand=<option>,<method pattern>,<value>'
>> Use:   '-XX:CompileCommand=help' for more information and to list all option.
>> 
>> Error: Could not create the Java Virtual Machine.
>> Error: A fatal exception has occurred. Program will exit.
>> 
>> 
>> ### Updated Tests
>> Updated all tests to now expect an error code `1` for wrong `CompileCommand`
>
> Tobias Holenstein has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update Scenario.java
>  - Update compilerOracle.cpp

Update is good.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13753#pullrequestreview-1453939326

From rriggs at openjdk.org  Wed May 31 19:35:24 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 31 May 2023 19:35:24 GMT
Subject: Integrated: 8304914: Use OperatingSystem, Architecture,
 and Version in jpackage
In-Reply-To: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
References: <nWwauGTWPpxgsb_njfmoM3bB9A4j90kP8Q6w3LUf8jk=.996cc10b-ca62-4c7c-a2cd-c31a61b12201@github.com>
Message-ID: <NdY3PwKHBOAGXqajx-2RwzLI8pQDntkKPYjU_0XTD58=.318d4954-fadc-4332-a1a2-248f6a09e34d@github.com>

On Fri, 21 Apr 2023 17:28:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor the Platform class in jdk.jpackage to use the internal OperatingSystem, Architecture, and Version classes.
> The OperatingSystem.isXXX() and Architecture.isYYY() methods replace comparisons in the Platform class.
> The checks of the os.version are replaced but may not be needed if OpenJDK no longer supports them.
> 
> It is recommended to remove os version checks that apply only to Mac versions before 10.15.
> Mac OS X 10.15 is the oldest version supported.

This pull request has now been integrated.

Changeset: c3cd481a
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3cd481a9a51a55649ae4ffb2b98cb9eee8b3bbb
Stats:     236 lines in 23 files changed: 41 ins; 132 del; 63 mod

8304914: Use OperatingSystem, Architecture, and Version in jpackage

Reviewed-by: asemenyuk

-------------

PR: https://git.openjdk.org/jdk/pull/13586

From duke at openjdk.org  Wed May 31 19:49:27 2023
From: duke at openjdk.org (Glavo)
Date: Wed, 31 May 2023 19:49:27 GMT
Subject: RFR: 8301569: list mode of jmod and jimage cannot be used normally
 in turkish locale
In-Reply-To: <urKhB25OcB0cL8GsImcRZhD_yALNP8Hz1lXTwFJmDbo=.5318961c-5bbe-4be3-8811-af22b1415a83@github.com>
References: <v0uxR1eF4vFNvA8DMLlwG1x2M-oH3o-xTJgKPs25UNA=.35fe243b-db18-42b6-b32b-115b649340f6@github.com>
 <urKhB25OcB0cL8GsImcRZhD_yALNP8Hz1lXTwFJmDbo=.5318961c-5bbe-4be3-8811-af22b1415a83@github.com>
Message-ID: <eniFkv7itdCMUxDq9LYC-h4uDRlew67VWu3wiB4JzJQ=.efbfc32e-a54a-4d72-bdcc-b719e679fe71@github.com>

On Sun, 29 Jan 2023 23:54:21 GMT, Glavo <duke at openjdk.org> wrote:

>> When the default Locale is `tr`, the jmod and jimage commands have the following problems:
>> 
>> * The jmod command does not correctly recognize the `list` mode typed in lowercase;
>> * The jimage command cannot obtain the help information of the `list` mode.
>
> There are some similar hidden dangers in OpenJDK. I hope to clean them up.
> 
> These hidden dangers are scattered in many modules. Should I solve them in multiple PRs?

> Hello @Glavo, I see you reopened this PR, so I'm guessing you are still interested in pursuing this further. Are you considering updating this PR to implement Alan's suggestion to do similar changes in `JImageTask.java` and `JlinkTask.java` to use `Locale.ROOT` or update this proposed change to use `Locale.ENGLISH`?

@jaikiran Hi Jaikiran, as my previous reply, I do not agree that `Locale.ENGLISH` should be used here, I think `Locale.ROOT` is more reasonable.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12281#issuecomment-1570842199

From prr at openjdk.org  Wed May 31 20:28:18 2023
From: prr at openjdk.org (Phil Race)
Date: Wed, 31 May 2023 20:28:18 GMT
Subject: RFR: JDK-8308288: Fix xlc17 clang warnings in shared code [v2]
In-Reply-To: <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
References: <lNHo2PewF8t-2JtnoWdRVGVEMPgd5CvMrR1uc8ISTVw=.d0500da0-4f0c-4ef1-ba7b-63e38cb603f3@github.com>
 <DXI-Jv0XoZZiIRkrJtCOMFR_qOkm26JWAsmP6velqrY=.07c751e1-487a-48ea-bc1c-ad8c73eae3b1@github.com>
Message-ID: <CnEbXLV8P1e6sBiI8PAjzxd0xHp-WPnujxBfPUwkfP0=.92636352-9955-498c-b500-e9402ffa5e5b@github.com>

On Fri, 26 May 2023 08:31:46 GMT, JoKern65 <duke at openjdk.org> wrote:

>> When using the new xlc17 compiler (based on a recent clang) to build OpenJDk on AIX , we run into various "warnings as errors".
>> Some of those are in shared codebase and could be addressed by small adjustments.
>> A lot of those changes are in hotspot, some might be somewhere else in the OpenJDK C/C++ code.
>
> JoKern65 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   forgotton _

I am Ok with the client-libs changes here. I did not look at anything else.
So you'll need more approvals before its ready to push.

-------------

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14146#pullrequestreview-1454101589

From darcy at openjdk.org  Wed May 31 20:39:44 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 31 May 2023 20:39:44 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v4]
In-Reply-To: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
Message-ID: <2vhEXa4W2A-VkPRaEyqaidm2tKuWdhqvJOA2mgvvC4g=.0a0a7ffa-1e26-45b0-838c-865bb02a2b82@github.com>

> Time to get JDK 22 underway...

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Respond to review comments.
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Sync in symbol changes for JDK 21 build 24.
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Merge branch 'master' into JDK-8306584
 - Minor test fixes.
 - ... and 16 more: https://git.openjdk.org/jdk/compare/12649025...7b446793

-------------

Changes: https://git.openjdk.org/jdk/pull/13567/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13567&range=03
  Stats: 5843 lines in 69 files changed: 5789 ins; 0 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/13567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13567/head:pull/13567

PR: https://git.openjdk.org/jdk/pull/13567

From darcy at openjdk.org  Wed May 31 20:41:13 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 31 May 2023 20:41:13 GMT
Subject: RFR: JDK-8306584: Start of release updates for JDK 22 [v3]
In-Reply-To: <dRojIK8Qr4KltCgwd9mW0AtH7W2BBdEGyIR87RLFb38=.4cf93d65-860c-4633-b855-e7b9f41c7226@github.com>
References: <E7ZSYB5eSgZWqm644QpcYDxghqTB_t6Zr27yQ-JZkJQ=.bccf0c3a-2505-4313-8203-b181b89f0c81@github.com>
 <cynjYPdpmMlzG4z-zoqhUFun0Uf8Op52etkgvkVaVkg=.5d133ecd-056b-49c3-8655-6856d22d163f@github.com>
 <dRojIK8Qr4KltCgwd9mW0AtH7W2BBdEGyIR87RLFb38=.4cf93d65-860c-4633-b855-e7b9f41c7226@github.com>
Message-ID: <QovVhDh1rbYLfithuvHa_eoAFD3_fhGYJU1xZq2p3yk=.f6cc23f5-cc8e-4633-b276-fcb9e4f00f4f@github.com>

On Wed, 31 May 2023 18:02:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:
>> 
>>  - Merge branch 'master' into JDK-8306584
>>  - Merge branch 'master' into JDK-8306584
>>  - Merge branch 'master' into JDK-8306584
>>  - Sync in symbol changes for JDK 21 build 24.
>>  - Merge branch 'master' into JDK-8306584
>>  - Merge branch 'master' into JDK-8306584
>>  - Merge branch 'master' into JDK-8306584
>>  - Minor test fixes.
>>  - Merge branch 'master' into JDK-8306584
>>  - Update symbol files to JDK 21 b23.
>>  - ... and 14 more: https://git.openjdk.org/jdk/compare/cb40db05...376dbe26
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java line 127:
> 
>> 125:         V64(64, 0),   // JDK 20
>> 126:         V65(65, 0),   // JDK 21
>> 127:         V66(66, 0);   // JDK 22
> 
> A very small nit/suggestion - it should be possible to do:
> 
> V66(66, 0),   //JDK 22
> ;
> 
> 
> (i.e. ending the enum constant with `,`, and putting the semicolon on a new line.) This way adding a new constant would mean just one line addition, no modification. (The same could be done for other enums.)

Updated.

> test/langtools/tools/javac/versions/Versions.java line 93:
> 
>> 91:         TWENTY(false,    "64.0", "20", Versions::checksrc20),
>> 92:         TWENTY_ONE(false,"65.0", "21", Versions::checksrc21),
>> 93:         TWENTY_TWO(false,"66.0", "22", Versions::checksrc21);
> 
> Should there be `checksrc22` instead of `checksrc21`? Or is that done later?

Good catch. I have a refactoring of the test planned which will eliminate the explicit "checksrc$N" methods.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1212284124
PR Review Comment: https://git.openjdk.org/jdk/pull/13567#discussion_r1212283880

From dcubed at openjdk.org  Wed May 31 20:45:47 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 31 May 2023 20:45:47 GMT
Subject: Integrated: 8309236: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC
 again
Message-ID: <ZCZ9uKj5ZrLdBsPk0se6Ta3d-hPGloABp7MW_DIuwt8=.6bbc4593-df2f-48ad-b426-f26e9b66ae41@github.com>

A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC again

-------------

Commit messages:
 - 8309236: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC again

Changes: https://git.openjdk.org/jdk/pull/14253/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14253&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309236
  Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14253/head:pull/14253

PR: https://git.openjdk.org/jdk/pull/14253

From bpb at openjdk.org  Wed May 31 20:45:48 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 31 May 2023 20:45:48 GMT
Subject: Integrated: 8309236: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC
 again
In-Reply-To: <ZCZ9uKj5ZrLdBsPk0se6Ta3d-hPGloABp7MW_DIuwt8=.6bbc4593-df2f-48ad-b426-f26e9b66ae41@github.com>
References: <ZCZ9uKj5ZrLdBsPk0se6Ta3d-hPGloABp7MW_DIuwt8=.6bbc4593-df2f-48ad-b426-f26e9b66ae41@github.com>
Message-ID: <fFLBCzOZk27lkXw5WXnPAQLyP2Wzb4WpKuRtet1TFJY=.c2c34f5e-134f-4e6d-bfc1-0d750a8fb49d@github.com>

On Wed, 31 May 2023 20:34:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC again

Marked as reviewed by bpb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14253#pullrequestreview-1454119784

From azvegint at openjdk.org  Wed May 31 20:45:49 2023
From: azvegint at openjdk.org (Alexander Zvegintsev)
Date: Wed, 31 May 2023 20:45:49 GMT
Subject: Integrated: 8309236: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC
 again
In-Reply-To: <ZCZ9uKj5ZrLdBsPk0se6Ta3d-hPGloABp7MW_DIuwt8=.6bbc4593-df2f-48ad-b426-f26e9b66ae41@github.com>
References: <ZCZ9uKj5ZrLdBsPk0se6Ta3d-hPGloABp7MW_DIuwt8=.6bbc4593-df2f-48ad-b426-f26e9b66ae41@github.com>
Message-ID: <DjFrCBFVugrpKXwZle5GZ6P6GJLLvvAMqpMlD78OdBA=.aec9277d-5001-46c0-90be-ea1fbcf825eb@github.com>

On Wed, 31 May 2023 20:34:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC again

Marked as reviewed by azvegint (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14253#pullrequestreview-1454120005

From dcubed at openjdk.org  Wed May 31 20:45:50 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 31 May 2023 20:45:50 GMT
Subject: Integrated: 8309236: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC
 again
In-Reply-To: <fFLBCzOZk27lkXw5WXnPAQLyP2Wzb4WpKuRtet1TFJY=.c2c34f5e-134f-4e6d-bfc1-0d750a8fb49d@github.com>
References: <ZCZ9uKj5ZrLdBsPk0se6Ta3d-hPGloABp7MW_DIuwt8=.6bbc4593-df2f-48ad-b426-f26e9b66ae41@github.com>
 <fFLBCzOZk27lkXw5WXnPAQLyP2Wzb4WpKuRtet1TFJY=.c2c34f5e-134f-4e6d-bfc1-0d750a8fb49d@github.com>
Message-ID: <v8RsBednpw56b2FtOT_Mi6F_UYpo6T1-Z4IZzNzTYnI=.0c5ab7bc-8725-419c-a501-94e82f5f4c23@github.com>

On Wed, 31 May 2023 20:38:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC again
>
> Marked as reviewed by bpb (Reviewer).

@bplb and @azvegint - Thanks for the fast reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14253#issuecomment-1570917645

From dcubed at openjdk.org  Wed May 31 20:45:52 2023
From: dcubed at openjdk.org (Daniel D. Daugherty)
Date: Wed, 31 May 2023 20:45:52 GMT
Subject: Integrated: 8309236: ProblemList
 java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC
 again
In-Reply-To: <ZCZ9uKj5ZrLdBsPk0se6Ta3d-hPGloABp7MW_DIuwt8=.6bbc4593-df2f-48ad-b426-f26e9b66ae41@github.com>
References: <ZCZ9uKj5ZrLdBsPk0se6Ta3d-hPGloABp7MW_DIuwt8=.6bbc4593-df2f-48ad-b426-f26e9b66ae41@github.com>
Message-ID: <wi9PvcEDfgTX3jq8bzVxWsBQ-Er6C9qXKoKj7-UK5To=.ba9bee5b-93c9-4d7b-88c6-b1c0c4152eeb@github.com>

On Wed, 31 May 2023 20:34:07 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC again

This pull request has now been integrated.

Changeset: e42a4b65
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e42a4b659a78721567e4e882a26fe2972975bc80
Stats:     2 lines in 2 files changed: 2 ins; 0 del; 0 mod

8309236: ProblemList java/util/concurrent/locks/Lock/OOMEInAQS.java with ZGC and Generational ZGC again

Reviewed-by: bpb, azvegint

-------------

PR: https://git.openjdk.org/jdk/pull/14253

From joehw at openjdk.org  Wed May 31 21:09:57 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 31 May 2023 21:09:57 GMT
Subject: RFR: 8303530: Redefine JAXP Configuration File [v14]
In-Reply-To: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
Message-ID: <jv_6epDEwD18GXC6LQj-iz7rvSKZAmjEdBsECUrtqvM=.84f35bd2-43ee-43c1-97ae-0798dc04b0ba@github.com>

> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8303531
> 
> Tests: XML SQE and JCK tests passed.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  additional javadoc update

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12985/files
  - new: https://git.openjdk.org/jdk/pull/12985/files/98d9417b..277c49d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=12-13

  Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12985/head:pull/12985

PR: https://git.openjdk.org/jdk/pull/12985

From lancea at openjdk.org  Wed May 31 21:23:11 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 31 May 2023 21:23:11 GMT
Subject: RFR: 8303530: Redefine JAXP Configuration File [v14]
In-Reply-To: <jv_6epDEwD18GXC6LQj-iz7rvSKZAmjEdBsECUrtqvM=.84f35bd2-43ee-43c1-97ae-0798dc04b0ba@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <jv_6epDEwD18GXC6LQj-iz7rvSKZAmjEdBsECUrtqvM=.84f35bd2-43ee-43c1-97ae-0798dc04b0ba@github.com>
Message-ID: <EhCjKvOUqhmLUi7r9D7SXI3YQJKJmymxhsEKbEHtQ58=.19275352-a003-4305-8c98-ad9c211422e2@github.com>

On Wed, 31 May 2023 21:09:57 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
>> 
>> CSR: https://bugs.openjdk.org/browse/JDK-8303531
>> 
>> Tests: XML SQE and JCK tests passed.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   additional javadoc update

Marked as reviewed by lancea (Reviewer).

src/java.xml/share/classes/module-info.java line 153:

> 151:  * <h4 id="Conf_CF_SP">User-defined Configuration File</h4>
> 152:  * In addition to the {@code jaxp.properties} file, the system property
> 153:  * {@systemProperty java.xml.config.file} can be set on the command line or at run-time

I think we can simplify to  "...the system property  {@systemProperty java.xml.config.file} can be set to specify..."

src/java.xml/share/classes/module-info.java line 182:

> 180:  * <ul>
> 181:  * <li><p>
> 182:  *      With the APIs for factories or processors

I do not think "With" makes sense here. perhaps just remove it completely

src/java.xml/share/classes/module-info.java line 224:

> 222:  * </li>
> 223:  * <li><p>
> 224:  *      If the property is not set on the factory, or with its system property,

perhaps. "or using a system property"

-------------

PR Review: https://git.openjdk.org/jdk/pull/12985#pullrequestreview-1454179699
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1212327827
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1212323773
PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1212324452

From joehw at openjdk.org  Wed May 31 21:58:44 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 31 May 2023 21:58:44 GMT
Subject: RFR: 8303530: Redefine JAXP Configuration File [v15]
In-Reply-To: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
Message-ID: <3a89aGPMevtuww_1Dc3KZxJzEzw_6I1jS9fRyp05thM=.a86422a5-13da-4ebb-8e65-16c3e008148b@github.com>

> Add a system property, jdk.xml.config.file, to return the path to a custom JAXP configuration file. The current configuration file, jaxp.properties, that the JDK supports will become the default configuration file.
> 
> CSR: https://bugs.openjdk.org/browse/JDK-8303531
> 
> Tests: XML SQE and JCK tests passed.

Joe Wang has updated the pull request incrementally with one additional commit since the last revision:

  adjust javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12985/files
  - new: https://git.openjdk.org/jdk/pull/12985/files/277c49d0..115e62ed

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12985&range=13-14

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12985.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12985/head:pull/12985

PR: https://git.openjdk.org/jdk/pull/12985

From joehw at openjdk.org  Wed May 31 21:58:45 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 31 May 2023 21:58:45 GMT
Subject: RFR: 8303530: Redefine JAXP Configuration File [v14]
In-Reply-To: <EhCjKvOUqhmLUi7r9D7SXI3YQJKJmymxhsEKbEHtQ58=.19275352-a003-4305-8c98-ad9c211422e2@github.com>
References: <UfrSqmDT0FDPFk_VPhmYkOsv6lbaAJJKwZNZ_ixIm4c=.16f1ac17-201d-4bab-a55b-45974e33790f@github.com>
 <jv_6epDEwD18GXC6LQj-iz7rvSKZAmjEdBsECUrtqvM=.84f35bd2-43ee-43c1-97ae-0798dc04b0ba@github.com>
 <EhCjKvOUqhmLUi7r9D7SXI3YQJKJmymxhsEKbEHtQ58=.19275352-a003-4305-8c98-ad9c211422e2@github.com>
Message-ID: <KEu-rIEXDeCgQrz9buDV-kkKPVS4XfRQyKB4v0VwZk8=.9a9e33af-2c99-4664-890a-a76fe7f4dd55@github.com>

On Wed, 31 May 2023 21:19:42 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   additional javadoc update
>
> src/java.xml/share/classes/module-info.java line 153:
> 
>> 151:  * <h4 id="Conf_CF_SP">User-defined Configuration File</h4>
>> 152:  * In addition to the {@code jaxp.properties} file, the system property
>> 153:  * {@systemProperty java.xml.config.file} can be set on the command line or at run-time
> 
> I think we can simplify to  "...the system property  {@systemProperty java.xml.config.file} can be set to specify..."

Thanks Lance. Adjusted the javadoc accordingly.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12985#discussion_r1212355544

From duke at openjdk.org  Wed May 31 22:02:31 2023
From: duke at openjdk.org (Aleksandar =?UTF-8?B?UGVqb3ZpxIc=?=)
Date: Wed, 31 May 2023 22:02:31 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
Message-ID: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>

The current code for cgroup support in the JDK has large and expensive dependencies: it uses NIO, streams, and regular expressions. This leads to unnecessary class loading and slows down startup, especially when the code is executed early during an application startup. This is especially a problem for GraalVM, which executes this code during VM startup.

This PR reduces the dependencies:
- NIO is replaced with regular `java.io` for file access.
- Streams are replaced with loops (a side effect of this is that files are read in full whereas previously they could be read up to a certain point, e.g., until a match is found).
- Regular expressions are replaced with manual tokenization (and for usages of `String.split`, the "regex" is changed to single characters for which `String.split` has a fast-path implementation that avoids the regular expression engine).

-------------

Commit messages:
 - Merge branch 'master' into ap/cgroup-tweaks
 - Use simple loops to process cgroup files
 - Use java.io for reading cgroup files
 - Reimplement mountinfo parsing without using regex
 - Use simple patterns to parse cgroup files
 - Factor out logging from CgroupSubsystemFactory.create

Changes: https://git.openjdk.org/jdk/pull/14216/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14216&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8309191
  Stats: 163 lines in 6 files changed: 73 ins; 55 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/14216.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14216/head:pull/14216

PR: https://git.openjdk.org/jdk/pull/14216

From sgehwolf at openjdk.org  Wed May 31 22:02:31 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 31 May 2023 22:02:31 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
Message-ID: <ITtFb0He4_Dt75HmDzDTM7Z9cpZfKrrK82iUeEuATHk=.664eb125-b6a3-48ff-adbd-a00c5fc1b247@github.com>

On Tue, 30 May 2023 13:03:27 GMT, Aleksandar Pejovi? <duke at openjdk.org> wrote:

> The current code for cgroup support in the JDK has large and expensive dependencies: it uses NIO, streams, and regular expressions. This leads to unnecessary class loading and slows down startup, especially when the code is executed early during an application startup. This is especially a problem for GraalVM, which executes this code during VM startup.
> 
> This PR reduces the dependencies:
> - NIO is replaced with regular `java.io` for file access.
> - Streams are replaced with loops (a side effect of this is that files are read in full whereas previously they could be read up to a certain point, e.g., until a match is found).
> - Regular expressions are replaced with manual tokenization (and for usages of `String.split`, the "regex" is changed to single characters for which `String.split` has a fast-path implementation that avoids the regular expression engine).

@pejovica Please enable GHA testing on your fork. Once enabled, please merge latest master into your branch so as to trigger a GHA run. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1568469816

From duke at openjdk.org  Wed May 31 22:02:31 2023
From: duke at openjdk.org (Aleksandar =?UTF-8?B?UGVqb3ZpxIc=?=)
Date: Wed, 31 May 2023 22:02:31 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <ITtFb0He4_Dt75HmDzDTM7Z9cpZfKrrK82iUeEuATHk=.664eb125-b6a3-48ff-adbd-a00c5fc1b247@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <ITtFb0He4_Dt75HmDzDTM7Z9cpZfKrrK82iUeEuATHk=.664eb125-b6a3-48ff-adbd-a00c5fc1b247@github.com>
Message-ID: <sEYx0vBD3iLx0Dqd32yR5F64tcSZl4dpyMU-q_gjM1s=.d03ac471-3ea9-4df3-b696-8a766295fc8b@github.com>

On Tue, 30 May 2023 13:48:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> The current code for cgroup support in the JDK has large and expensive dependencies: it uses NIO, streams, and regular expressions. This leads to unnecessary class loading and slows down startup, especially when the code is executed early during an application startup. This is especially a problem for GraalVM, which executes this code during VM startup.
>> 
>> This PR reduces the dependencies:
>> - NIO is replaced with regular `java.io` for file access.
>> - Streams are replaced with loops (a side effect of this is that files are read in full whereas previously they could be read up to a certain point, e.g., until a match is found).
>> - Regular expressions are replaced with manual tokenization (and for usages of `String.split`, the "regex" is changed to single characters for which `String.split` has a fast-path implementation that avoids the regular expression engine).
>
> @pejovica Please enable GHA testing on your fork. Once enabled, please merge latest master into your branch so as to trigger a GHA run. Thanks!

@jerboaa I enabled G?A testing. Other than a couple of Windows errors (which seem unrelated), everything else seems to be fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1569844601

From sgehwolf at openjdk.org  Wed May 31 22:02:31 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 31 May 2023 22:02:31 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <sEYx0vBD3iLx0Dqd32yR5F64tcSZl4dpyMU-q_gjM1s=.d03ac471-3ea9-4df3-b696-8a766295fc8b@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <ITtFb0He4_Dt75HmDzDTM7Z9cpZfKrrK82iUeEuATHk=.664eb125-b6a3-48ff-adbd-a00c5fc1b247@github.com>
 <sEYx0vBD3iLx0Dqd32yR5F64tcSZl4dpyMU-q_gjM1s=.d03ac471-3ea9-4df3-b696-8a766295fc8b@github.com>
Message-ID: <NBWN0K4ixkizAhLmSgMnWITMBg9S4sa7Rckn-mFCPb0=.c7442730-9453-4488-8c1d-9ce4822df831@github.com>

On Wed, 31 May 2023 09:38:08 GMT, Aleksandar Pejovi? <duke at openjdk.org> wrote:

>> @pejovica Please enable GHA testing on your fork. Once enabled, please merge latest master into your branch so as to trigger a GHA run. Thanks!
>
> @jerboaa I enabled G?A testing. Other than a couple of Windows errors (which seem unrelated), everything else seems to be fine.

@pejovica There are some jcheck failures. See:
https://github.com/openjdk/jdk/pull/14216/checks?check_run_id=13870116111

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1569886416

From duke at openjdk.org  Wed May 31 22:02:31 2023
From: duke at openjdk.org (Aleksandar =?UTF-8?B?UGVqb3ZpxIc=?=)
Date: Wed, 31 May 2023 22:02:31 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <sEYx0vBD3iLx0Dqd32yR5F64tcSZl4dpyMU-q_gjM1s=.d03ac471-3ea9-4df3-b696-8a766295fc8b@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <ITtFb0He4_Dt75HmDzDTM7Z9cpZfKrrK82iUeEuATHk=.664eb125-b6a3-48ff-adbd-a00c5fc1b247@github.com>
 <sEYx0vBD3iLx0Dqd32yR5F64tcSZl4dpyMU-q_gjM1s=.d03ac471-3ea9-4df3-b696-8a766295fc8b@github.com>
Message-ID: <ReiS8ogZjIZKxuJNynkiF77HghFDsVTOfbd72sPuXLw=.c5d52edc-01ff-43d0-b199-70a3277b8abe@github.com>

On Wed, 31 May 2023 09:38:08 GMT, Aleksandar Pejovi? <duke at openjdk.org> wrote:

>> @pejovica Please enable GHA testing on your fork. Once enabled, please merge latest master into your branch so as to trigger a GHA run. Thanks!
>
> @jerboaa I enabled G?A testing. Other than a couple of Windows errors (which seem unrelated), everything else seems to be fine.

> @pejovica There are some jcheck failures. See: https://github.com/openjdk/jdk/pull/14216/checks?check_run_id=13870116111

@jerboaa One failure is due to a lack of reviewers, so would you be able to do a review? As for the rest, I've added an issue reference, so that's fixed, and I guess I'll have to wait for OCA verification.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1570124898

From sgehwolf at openjdk.org  Wed May 31 22:02:31 2023
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 31 May 2023 22:02:31 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <ReiS8ogZjIZKxuJNynkiF77HghFDsVTOfbd72sPuXLw=.c5d52edc-01ff-43d0-b199-70a3277b8abe@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <ITtFb0He4_Dt75HmDzDTM7Z9cpZfKrrK82iUeEuATHk=.664eb125-b6a3-48ff-adbd-a00c5fc1b247@github.com>
 <sEYx0vBD3iLx0Dqd32yR5F64tcSZl4dpyMU-q_gjM1s=.d03ac471-3ea9-4df3-b696-8a766295fc8b@github.com>
 <ReiS8ogZjIZKxuJNynkiF77HghFDsVTOfbd72sPuXLw=.c5d52edc-01ff-43d0-b199-70a3277b8abe@github.com>
Message-ID: <LZKxXGJafawMRhT7yMB1T4lRNu06OHsDm-CoscL3m3Y=.4878df0e-2247-4d0e-b650-2f1cce45c69f@github.com>

On Wed, 31 May 2023 12:21:13 GMT, Aleksandar Pejovi? <duke at openjdk.org> wrote:

> I guess I'll have to wait for OCA verification.

Yes.

> One failure is due to a lack of reviewers, so would you be able to do a review?

Yes, I'll try to do a review later today or tomorrow.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1570181616

From duke at openjdk.org  Wed May 31 22:02:31 2023
From: duke at openjdk.org (Aleksandar =?UTF-8?B?UGVqb3ZpxIc=?=)
Date: Wed, 31 May 2023 22:02:31 GMT
Subject: RFR: 8309191: Reduce JDK dependencies of cgroup support
In-Reply-To: <LZKxXGJafawMRhT7yMB1T4lRNu06OHsDm-CoscL3m3Y=.4878df0e-2247-4d0e-b650-2f1cce45c69f@github.com>
References: <Dg4qyiH4cEpCxGRYrtwb2xBXiIMDod5d1tP01OZ8iAs=.b2ca8b9f-1fc1-4595-900c-6c86dfcb9636@github.com>
 <ITtFb0He4_Dt75HmDzDTM7Z9cpZfKrrK82iUeEuATHk=.664eb125-b6a3-48ff-adbd-a00c5fc1b247@github.com>
 <sEYx0vBD3iLx0Dqd32yR5F64tcSZl4dpyMU-q_gjM1s=.d03ac471-3ea9-4df3-b696-8a766295fc8b@github.com>
 <ReiS8ogZjIZKxuJNynkiF77HghFDsVTOfbd72sPuXLw=.c5d52edc-01ff-43d0-b199-70a3277b8abe@github.com>
 <LZKxXGJafawMRhT7yMB1T4lRNu06OHsDm-CoscL3m3Y=.4878df0e-2247-4d0e-b650-2f1cce45c69f@github.com>
Message-ID: <9UqqGOmXLkrwGFFsrX1IdUCOzdHPOb_bh6rZTi5SgQw=.3b73ac88-8410-409a-b057-cb4837a4a48c@github.com>

On Wed, 31 May 2023 12:54:57 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Yes, I'll try to do a review later today or tomorrow.

Awesome, thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14216#issuecomment-1570276516

From jvernee at openjdk.org  Wed May 31 22:22:07 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 31 May 2023 22:22:07 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
In-Reply-To: <Eer3yJHpD1aBcg2jbEuwvkg3yA1GRqC3aSfG-7zv_Ec=.f5e22b2b-b252-4b8c-994d-024fac4603fb@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <86g7ouwA8SkmICALXwySWBWCgL8x75uCAU7fk5G1Xdg=.b23bc5e8-a4a1-4f87-99c1-8de1136b0306@github.com>
 <Eer3yJHpD1aBcg2jbEuwvkg3yA1GRqC3aSfG-7zv_Ec=.f5e22b2b-b252-4b8c-994d-024fac4603fb@github.com>
Message-ID: <DoudPbInQ3LknSVOss65RtSzP6rlpe7YoL--ZrfvXfE=.f9119b53-4ad5-4fb9-b897-052179441689@github.com>

On Wed, 31 May 2023 15:39:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> test/jdk/java/foreign/StdLibTest.java line 386:
>> 
>>> 384:             return arena.allocateUtf8String("str");
>>> 385:         }, "str"),
>>> 386:         CHAR(int.class, C_INT, "%c", arena -> (int) 'h', (int) 'h'), // promote to int, per C spec
>> 
>> is it important to retain this, given that there's already an INT case?
>
> Maybe adding a long case would be more useful?

Yes, good idea.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1212373879

From jvernee at openjdk.org  Wed May 31 22:44:52 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 31 May 2023 22:44:52 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v2]
In-Reply-To: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
Message-ID: <SQVyoJAF1wvFslk7EespmkmAdFZpBmP_jbcqwGOAX5g=.b3c65357-1f4d-4377-a957-3765f719a1a1@github.com>

> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch restricts the layouts that can be used as variadic layouts to what is allowed by the C specification.
> 
> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
> 
> I've added a small paragraph to the Linker javadoc as well that explains the restriction. Comments on that are welcome, but please explain.
> 
> The tests are updated to no longer try to link variadic functions with the illegal layouts, and I've added some more negative tests to TestIllegalLink.
> 
> Testing:
> - local testing on Windows/x64
> - tier1-3 + jdk-tier5 (ongoing)
> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14225/files
  - new: https://git.openjdk.org/jdk/pull/14225/files/c21ae49a..9415e2a1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14225&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14225&range=00-01

  Stats: 25 lines in 2 files changed: 8 ins; 9 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/14225.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14225/head:pull/14225

PR: https://git.openjdk.org/jdk/pull/14225

From jvernee at openjdk.org  Wed May 31 22:44:54 2023
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 31 May 2023 22:44:54 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v2]
In-Reply-To: <86g7ouwA8SkmICALXwySWBWCgL8x75uCAU7fk5G1Xdg=.b23bc5e8-a4a1-4f87-99c1-8de1136b0306@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <86g7ouwA8SkmICALXwySWBWCgL8x75uCAU7fk5G1Xdg=.b23bc5e8-a4a1-4f87-99c1-8de1136b0306@github.com>
Message-ID: <cXMKz-LUQSfsVaVrhZx-D4UXdoDuoSvJ7zUt5c5fUkY=.5cad741a-bb4b-4ace-ae0d-be23b39d1501@github.com>

On Wed, 31 May 2023 15:37:57 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 415:
> 
>> 413:  * It should be noted that values passed as variadic arguments undergo default argument promotion in C. Each value of
>> 414:  * type {@code float} is converted to {@code double}, and each integral type smaller than {@code int} is converted to
>> 415:  * {@code int}. As such, the native linker will reject attempts to link a function with variadic parameters which have
> 
> maybe "will reject attempts to link a variadic function if one or more parameter layouts in the provided function descriptor which correspond to a variadic argument is a value layout such that ..."

I did another pass over this. I went back to the first paragraph and defined the term "variadic argument layout" which I then use when explaining which layouts can not be used.

I've also moved the note to be directly after the first paragraph so that it appears closer to where the term is defined.

Hopefully there should be no gaps now.

P.S. I had to re-flow some of the lines in the doc, so they might appear changed in the diff.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1212384221

From dholmes at openjdk.org  Wed May 31 23:07:09 2023
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 31 May 2023 23:07:09 GMT
Subject: RFR: 8308748: JNU_GetStringPlatformChars may write to String's
 internal memory array [v2]
In-Reply-To: <z-Sp5itXRBV0S__vZF5OAzZR5W-l3lo2B8u2j-oaYKs=.77813e70-66d9-4080-9448-63b1f19ebbe7@github.com>
References: <RPNjnpwk_ck6uLK3M6qP4Mma35QpVxGslx5bUMHYlPk=.e3bb7037-a878-44f5-85df-f19f17d5702e@github.com>
 <z-Sp5itXRBV0S__vZF5OAzZR5W-l3lo2B8u2j-oaYKs=.77813e70-66d9-4080-9448-63b1f19ebbe7@github.com>
Message-ID: <b5cW7sCnNFNMcqJ_DhQgV5w73kBHESeomK2Hz3O6TpU=.538ba6e8-19be-47c1-9f94-2aab5a879c4e@github.com>

On Fri, 26 May 2023 19:54:07 GMT, Rudi Horn <duke at openjdk.org> wrote:

>> This change prevents the contents of the internal string array from being copied back when releasing it.
>
> Rudi Horn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Use JNI_ABORT to release string bytes

This change looks good to me.

Please await a core-libs review before integration though.

Thanks.

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14117#pullrequestreview-1454299683

From mcimadamore at openjdk.org  Wed May 31 23:39:07 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 31 May 2023 23:39:07 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v2]
In-Reply-To: <SQVyoJAF1wvFslk7EespmkmAdFZpBmP_jbcqwGOAX5g=.b3c65357-1f4d-4377-a957-3765f719a1a1@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <SQVyoJAF1wvFslk7EespmkmAdFZpBmP_jbcqwGOAX5g=.b3c65357-1f4d-4377-a957-3765f719a1a1@github.com>
Message-ID: <PrwfoKow8uEdN33e5T1d34Ogys6kqezIcSaf9hlanlo=.150e96f0-e463-4f51-addc-e3589c20d175@github.com>

On Wed, 31 May 2023 22:44:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch restricts the layouts that can be used as variadic layouts to what is allowed by the C specification.
>> 
>> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
>> 
>> I've added a small paragraph to the Linker javadoc as well that explains the restriction. Comments on that are welcome, but please explain.
>> 
>> The tests are updated to no longer try to link variadic functions with the illegal layouts, and I've added some more negative tests to TestIllegalLink.
>> 
>> Testing:
>> - local testing on Windows/x64
>> - tier1-3 + jdk-tier5 (ongoing)
>> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

src/java.base/share/classes/java/lang/foreign/Linker.java line 368:

> 366:  * <h3 id="variadic-funcs">Variadic functions</h3>
> 367:  *
> 368:  * Variadic functions (e.g. a C function declared with a trailing ellipses {@code ...} at the end of the formal parameter

Optional suggestion for improvement (maybe now, or maybe later). When reading this great para, I understand that there are two things that fall under the "variadic function" umbrella. Some are declared with `...` and some with `()`. This is a very good definition and I wonder if we should expand a bit more on it - e.g. in a way, we never explain what a variadic function is - we merely define it by saying how it is declared in C. I wonder if we might very very briefly explain that in C, some functions (variadic functions) can take a variable number of parameters. Then we go on to say that these functions can be declared in two ways (e.g. ellipsis and prototype-less). Perhaps if we used a bullet-list to define the two ways in which variadic function can be declared, the definition could stand out even more?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1212415909

From mcimadamore at openjdk.org  Wed May 31 23:39:08 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 31 May 2023 23:39:08 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v2]
In-Reply-To: <PrwfoKow8uEdN33e5T1d34Ogys6kqezIcSaf9hlanlo=.150e96f0-e463-4f51-addc-e3589c20d175@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <SQVyoJAF1wvFslk7EespmkmAdFZpBmP_jbcqwGOAX5g=.b3c65357-1f4d-4377-a957-3765f719a1a1@github.com>
 <PrwfoKow8uEdN33e5T1d34Ogys6kqezIcSaf9hlanlo=.150e96f0-e463-4f51-addc-e3589c20d175@github.com>
Message-ID: <mAeCBDbrGb6TzSKT5qUxvbCOIXl3Ws-quY_tT_eh5i0=.375335d1-ec5c-4d00-972a-8dd5cd2f8589@github.com>

On Wed, 31 May 2023 23:35:08 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments
>
> src/java.base/share/classes/java/lang/foreign/Linker.java line 368:
> 
>> 366:  * <h3 id="variadic-funcs">Variadic functions</h3>
>> 367:  *
>> 368:  * Variadic functions (e.g. a C function declared with a trailing ellipses {@code ...} at the end of the formal parameter
> 
> Optional suggestion for improvement (maybe now, or maybe later). When reading this great para, I understand that there are two things that fall under the "variadic function" umbrella. Some are declared with `...` and some with `()`. This is a very good definition and I wonder if we should expand a bit more on it - e.g. in a way, we never explain what a variadic function is - we merely define it by saying how it is declared in C. I wonder if we might very very briefly explain that in C, some functions (variadic functions) can take a variable number of parameters. Then we go on to say that these functions can be declared in two ways (e.g. ellipsis and prototype-less). Perhaps if we used a bullet-list to define the two ways in which variadic function can be declared, the definition could stand out even more?

Also, should we say somewhere that, for prototype-less functions, `firstVariadicArg` should always have an index of 0 (e.g. any other value is illegal, trivially). It's not super important, just one of those little things that can reinforce understanding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1212416524

From mcimadamore at openjdk.org  Wed May 31 23:45:08 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 31 May 2023 23:45:08 GMT
Subject: RFR: 8308031: Linkers should reject unpromoted variadic parameters
 [v2]
In-Reply-To: <SQVyoJAF1wvFslk7EespmkmAdFZpBmP_jbcqwGOAX5g=.b3c65357-1f4d-4377-a957-3765f719a1a1@github.com>
References: <kPZlTM4GOvnxPi7krFQ_B1_xQ5em44V0ukgjv22UvTg=.cfd4990a-1b65-47e3-955d-07f82bea7d0e@github.com>
 <SQVyoJAF1wvFslk7EespmkmAdFZpBmP_jbcqwGOAX5g=.b3c65357-1f4d-4377-a957-3765f719a1a1@github.com>
Message-ID: <dcy4iyl1NDUbIwBXJOL2p5n0FgiHXPctDjCf64RDmLM=.44f28ab4-d673-4d0f-82a5-4e263ae37a9e@github.com>

On Wed, 31 May 2023 22:44:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> In C, arguments smaller than `int` are promoted to (`unsigned`) `int`, and `float` is promoted to `double`, when being passed as variadic argument (see e.g. https://en.cppreference.com/w/c/language/conversion#Default_argument_promotions). This patch restricts the layouts that can be used as variadic layouts to what is allowed by the C specification.
>> 
>> The fallback linker is also updated to use to correct function to link variadic calls (not doing this turned out not to be a problem so far, but it is problematic for instance on Mac/AArch64 when using the fallback linker). Adding the restriction on layouts for all linkers is also partly motivated by the fallback linker rejecting such unsupported variadic layouts already.
>> 
>> I've added a small paragraph to the Linker javadoc as well that explains the restriction. Comments on that are welcome, but please explain.
>> 
>> The tests are updated to no longer try to link variadic functions with the illegal layouts, and I've added some more negative tests to TestIllegalLink.
>> 
>> Testing:
>> - local testing on Windows/x64
>> - tier1-3 + jdk-tier5 (ongoing)
>> - manual test run on mac/aarch64 with the fallback linker to verify the correctness of the fallback linker changes.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

src/java.base/share/classes/java/lang/foreign/Linker.java line 379:

> 377:  * type {@code float} is converted to {@code double}, and each integral type smaller than {@code int} is converted to
> 378:  * {@code int}. As such, the native linker will reject attempts to link function descriptors with certain variadic argument
> 379:  * layouts. Namely, {@linkplain ValueLayout value layouts} that have a carrier type of {@code boolean}, {@code byte},

Is there any reason as to why you decided to say which layouts are **not** allowed as variadic layouts? I'm wondering whether, if we add more carriers in the future, this list will probably need to be updated? Or do the restriction only involve these "small" types, and stuff like `long double` is always allowed? (in which case the set of unsupported layouts would remain stable over time)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14225#discussion_r1212419388