From shade at openjdk.java.net  Mon Mar  1 08:51:01 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 1 Mar 2021 08:51:01 GMT
Subject: RFR: 8261483:
 jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with
 "AssertionError: Should have GCd a method handle by now" [v4]
In-Reply-To: <IYVGcWafddwlmxXZe3z4whGghDmB2pQ3okDeuNVOsmg=.5c7d4f07-db9b-4fe1-8566-fb587005ae5b@github.com>
References: <slYYgswHIpdKuQw8Cn9CfDqBT-0v5MpntG7y1V8z7Fw=.5c82def9-9fc0-4914-8a05-082cb9e8fad2@github.com>
 <IYVGcWafddwlmxXZe3z4whGghDmB2pQ3okDeuNVOsmg=.5c7d4f07-db9b-4fe1-8566-fb587005ae5b@github.com>
Message-ID: <s7R0bHfTELx9FIp4zFmm9PfsLEhrYPK6HqXtGDSoo2w=.8ade8e81-ffad-4965-ac50-49f58a9a32e9@github.com>

On Sun, 28 Feb 2021 10:28:56 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now"
>
> Attila Szegedi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
> 
>   8261483: Eliminate flakiness of the tests by using iteration number limit and explicitly running GC

Good. Minor suggestion follows.

test/jdk/jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java line 25:

> 23: 
> 24: /*
> 25:  * @test id=with_SerialGC

No need to be that explicit ("with_SerialGC"). "id=serial" should be enough.

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

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2617

From pconcannon at openjdk.java.net  Mon Mar  1 09:48:26 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 1 Mar 2021 09:48:26 GMT
Subject: RFR: 8252399: Update mapMulti documentation to use type test
 pattern instead of instanceof once JEP 375 exits preview [v8]
In-Reply-To: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com>
References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com>
Message-ID: <e40ilFXzN4JzljiKBBURdRiUBisNmvCW6kascY0a8pM=.b1942566-1c10-4803-bb9b-3d57cac27bbf@github.com>

> Hi,
> 
> Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ?
> 
> This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375).
> 
> Kind regards,
> Patrick

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

 - Merge remote-tracking branch 'origin/master' into JDK-8252399
 - 8252399: Converted JavadocExamples to test
 - Merge remote-tracking branch 'origin/master' into JDK-8252399
 - 825399: Added wildcard to Iterable
 - Merge remote-tracking branch 'origin/master' into JDK-8252399
 - 8252399: Added more appropriate test stream for Expand Iterable example
 - 8252399: Corrected Expand Iterable Example
 - 8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2544/files
  - new: https://git.openjdk.java.net/jdk/pull/2544/files/47dd74df..c47fbf92

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=06-07

  Stats: 25663 lines in 916 files changed: 16302 ins; 5038 del; 4323 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2544.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2544/head:pull/2544

PR: https://git.openjdk.java.net/jdk/pull/2544

From pconcannon at openjdk.java.net  Mon Mar  1 10:16:04 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 1 Mar 2021 10:16:04 GMT
Subject: RFR: 8252399: Update mapMulti documentation to use type test
 pattern instead of instanceof once JEP 375 exits preview [v9]
In-Reply-To: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com>
References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com>
Message-ID: <IPHHT8iOTZW4yIeo5vUDO8lo_sAb-QWlF-mD0Z0chdg=.b01b61f3-db41-4a12-93e5-a2b5de2afbe0@github.com>

> Hi,
> 
> Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ?
> 
> This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375).
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8252399: Added note for keeping example in sync with test; updated example to use real values

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2544/files
  - new: https://git.openjdk.java.net/jdk/pull/2544/files/c47fbf92..944c7d5e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2544&range=07-08

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

PR: https://git.openjdk.java.net/jdk/pull/2544

From pconcannon at openjdk.java.net  Mon Mar  1 10:16:06 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 1 Mar 2021 10:16:06 GMT
Subject: RFR: 8252399: Update mapMulti documentation to use type test
 pattern instead of instanceof once JEP 375 exits preview [v7]
In-Reply-To: <d8JY9dhmBiPx_L8i6r96x3pzkmq3bClyjpeQrZZR-OQ=.10217768-d4ca-4e12-8d81-f91e7d98617a@github.com>
References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com>
 <2LBOP-zt5B6ANWX4Cworm_zZ2yEygYcaWnUUH2S1YsI=.84ea37e5-affa-48cb-b712-78db89195a88@github.com>
 <d8JY9dhmBiPx_L8i6r96x3pzkmq3bClyjpeQrZZR-OQ=.10217768-d4ca-4e12-8d81-f91e7d98617a@github.com>
Message-ID: <4W1v92FKsTGUZJeX8IAoklGTVoMm_pWwVePBZ_UImwg=.4b097543-5daa-4a4b-a5cf-d515ef417b81@github.com>

On Wed, 24 Feb 2021 19:26:02 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8252399: Converted JavadocExamples to test
>
> src/java.base/share/classes/java/util/stream/Stream.java line 414:
> 
>> 412:      *     }
>> 413:      * }
>> 414:      * }</pre>
> 
> I'd suggest putting a comment somewhere outside the javadoc that points to the test and has a statement similar to the one in the test, about keeping the example here in synch with the test. I'm not sure what the best way is to do this though. It probably cannot be after the javadoc comment, because the javadoc comment needs to be immediately prior to the method declaration. Maybe a // comment above the doc comment?

Good idea. I've added a comment above the javadoc as you've suggested. See 
944c7d5

> src/java.base/share/classes/java/util/stream/Stream.java line 410:
> 
>> 408:      *
>> 409:      *     public static void main(String[] args) {
>> 410:      *         var nestedList = ...;
> 
> I think it would be good to expand the RHS to use what you use in the test, namely
> 
> var nestedList = List.of(1, List.of(2, List.of(3, 4)), 5);
> 
> That would clarify the example quite a bit. Similar for the numbers example above.

Sounds good. I've added that to the example now. See 944c7d5

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

PR: https://git.openjdk.java.net/jdk/pull/2544

From aph at openjdk.java.net  Mon Mar  1 10:33:59 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 10:33:59 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]
In-Reply-To: <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
Message-ID: <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>

On Fri, 26 Feb 2021 19:17:12 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>  - Minor fixes

src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp line 62:

> 60: 
> 61: #if defined(__APPLE__) || defined(_WIN64)
> 62: #define R18_RESERVED

#define R18_RESERVED true```

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From attila at openjdk.java.net  Mon Mar  1 10:56:59 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Mon, 1 Mar 2021 10:56:59 GMT
Subject: RFR: 8262503: Support records in Dynalink
Message-ID: <yO1O4eJNyQhMbkx-h1gbgcvRbkrknAox4oMjkrGUi6U=.8ee56a7f-39b8-4a9b-a497-c2576767d090@github.com>

8262503: Support records in Dynalink

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

Commit messages:
 - Document behavior changes
 - Add support for records to Dynalink
 - Test the desired functionality

Changes: https://git.openjdk.java.net/jdk/pull/2767/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2767&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262503
  Stats: 165 lines in 8 files changed: 153 ins; 6 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2767.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2767/head:pull/2767

PR: https://git.openjdk.java.net/jdk/pull/2767

From aph at openjdk.java.net  Mon Mar  1 11:09:56 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 11:09:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <snefTFoz9nOu7pghwG_v5GiOsmMvFSiICF3Hr1UskCs=.e9df3841-8204-41f5-a2b7-d8b07569a646@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <snefTFoz9nOu7pghwG_v5GiOsmMvFSiICF3Hr1UskCs=.e9df3841-8204-41f5-a2b7-d8b07569a646@github.com>
Message-ID: <olzq5_KwRPyDE2-CoFcqPX9aR0wix5WogLrCo1bgD2I=.ceb47235-e205-4729-b59f-ec9b7033ebe6@github.com>

On Thu, 4 Feb 2021 23:01:52 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Add comments to WX transitions
>>    
>>    + minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 652:
> 
>> 650: 
>> 651: void os::setup_fpu() {
>> 652: }
> 
> Is there really nothing to do here, or does still need to be implemented? A clarification comment here would help/.

There is really nothing to do here.

> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 198:
> 
>> 196: 
>> 197: NOINLINE frame os::current_frame() {
>> 198:   intptr_t *fp = *(intptr_t **)__builtin_frame_address(0);
> 
> In the bsd_x86 counter part we initialize `fp` to `_get_previous_fp()` - do we need to implement it on aarch64 as well (and using address 0 is just a temp workaround) or is it doing the right thing here?

(0)``` looks right to me.

> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 291:
> 
>> 289:         bool is_unsafe_arraycopy = (thread->doing_unsafe_access() && UnsafeCopyMemory::contains_pc(pc));
>> 290:         if ((nm != NULL && nm->has_unsafe_access()) || is_unsafe_arraycopy) {
>> 291:           address next_pc = pc + NativeCall::instruction_size;
> 
> Replace
> 
> address next_pc = pc + NativeCall::instruction_size;
> 
> with
> 
> address next_pc = Assembler::locate_next_instruction(pc);
> 
> there is at least one other place that needs it.

Why is this change needed? AFAICS ```locate_next_instruction()``` is an x86 thing for variable-length instructions, and no other port uses it.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From aph at openjdk.java.net  Mon Mar  1 11:09:55 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 11:09:55 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]
In-Reply-To: <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
Message-ID: <5l97Ac1W-JbLiCBJMoWut-c-RZEPN6wBHABym2nHeRE=.6d060249-e315-486b-a0ab-1992de6f54d5@github.com>

On Fri, 26 Feb 2021 19:17:12 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>  - Minor fixes

Thanks. With this, I think we're done.

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

Changes requested by aph (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2200

From aph at openjdk.java.net  Mon Mar  1 11:09:57 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 11:09:57 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <x0F1vjGptkr-cbJzQ-3bS5zX7mFSgxIEDAjn6DxTfW4=.732c6cb4-7044-4561-821c-6ca63f9768a7@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <MlC0k95KyLxJCu7ZSluQlSdVrGTPolMjYG_rX3lpebU=.9ccf1fac-6fec-4479-80d7-9ee89d3bbb54@github.com>
 <x0F1vjGptkr-cbJzQ-3bS5zX7mFSgxIEDAjn6DxTfW4=.732c6cb4-7044-4561-821c-6ca63f9768a7@github.com>
Message-ID: <cJ0oJULLMQqSzHz-xHWMiJrivyH59QxUI2UQTN0PrdE=.77b688e8-52f1-4207-be64-3393922ecdb6@github.com>

On Fri, 5 Feb 2021 17:20:55 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/vm_version_aarch64.hpp line 93:
>> 
>>> 91:     CPU_MARVELL   = 'V',
>>> 92:     CPU_INTEL     = 'i',
>>> 93:     CPU_APPLE     = 'a',
>> 
>> The `ARM Architecture Reference Manual ARMv8, for ARMv8-A architecture profile` has 8538 pages, can we be more specific and point to the particular section of the document where the CPU codes are defined?
>
> They are defined in 13.2.95. MIDR_EL1, Main ID Register. Apple's code is not there, but "Arm can assign codes that are not published in this manual. All values not assigned by Arm are reserved and must not be used.". I assume the value was obtained by digging around https://github.com/apple/darwin-xnu/blob/main/osfmk/arm/cpuid.h#L62

Anton, this paragraph looks like an excellent comment.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From aph at openjdk.java.net  Mon Mar  1 11:09:58 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 1 Mar 2021 11:09:58 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <hwBUUi7NHd91Sc9fpH0hTqLXvp2H8ax9-YGqCo4fC2g=.bb995b11-1795-42e8-8a9a-d95406ed8513@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <9Nasu4m7orJoGYjX4EYCuz5-aevYNno3Ru3jPHgwkvc=.168cfdf0-648b-46e4-9cb4-b24956eeba7d@github.com>
 <hwBUUi7NHd91Sc9fpH0hTqLXvp2H8ax9-YGqCo4fC2g=.bb995b11-1795-42e8-8a9a-d95406ed8513@github.com>
Message-ID: <wl_FMfr8IuW0pM6APkV36vyWvmy4bsdaoSgWHA-yMmo=.d4ecb78c-e199-4e1c-9215-d68e2d25bc15@github.com>

On Fri, 12 Feb 2021 11:42:59 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 194:
>> 
>>> 192: // may get turned off by -fomit-frame-pointer.
>>> 193: frame os::get_sender_for_C_frame(frame* fr) {
>>> 194:   return frame(fr->link(), fr->link(), fr->sender_pc());
>> 
>> Why is it
>> 
>> return frame(fr->link(), fr->link(), fr->sender_pc());
>> 
>> and not 
>> 
>> return frame(fr->sender_sp(), fr->link(), fr->sender_pc());
>> 
>> like in the bsd-x86 counter part?
>
> bsd_aarcb64 was based on linux_aarch64, with addition of bsd-specific things from bsd_x86
> You think  the bsd-x86 way is better here ?

There's no point copying x86. We don't have any way to know what the sender's SP was in a C frame without using unwind info. I think this is just used when trying to print the stack in a crash dump.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From plevart at openjdk.java.net  Mon Mar  1 11:12:46 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Mon, 1 Mar 2021 11:12:46 GMT
Subject: RFR: 8261483:
 jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with
 "AssertionError: Should have GCd a method handle by now" [v4]
In-Reply-To: <IYVGcWafddwlmxXZe3z4whGghDmB2pQ3okDeuNVOsmg=.5c7d4f07-db9b-4fe1-8566-fb587005ae5b@github.com>
References: <slYYgswHIpdKuQw8Cn9CfDqBT-0v5MpntG7y1V8z7Fw=.5c82def9-9fc0-4914-8a05-082cb9e8fad2@github.com>
 <IYVGcWafddwlmxXZe3z4whGghDmB2pQ3okDeuNVOsmg=.5c7d4f07-db9b-4fe1-8566-fb587005ae5b@github.com>
Message-ID: <9ZO04vLHMT6rNlyuOHN7_5mLqrnsMo3glPHG05q1DJE=.cc962321-f440-4f9d-9d28-5c2232423d41@github.com>

On Sun, 28 Feb 2021 10:28:56 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now"
>
> Attila Szegedi has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8261483: Eliminate flakiness of the tests by using iteration number limit and explicitly running GC

I think this looks good to go, Attila.

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

Marked as reviewed by plevart (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2617

From sgehwolf at openjdk.java.net  Mon Mar  1 13:10:49 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 1 Mar 2021 13:10:49 GMT
Subject: RFR: 8262379: Add regression test for JDK-8257746
In-Reply-To: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>
References: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>
Message-ID: <T7U47gw9i7gi4zcdrEs0oQXOeV_A5QePU-MiPhFrBmg=.783e23ff-8dc7-48ba-87a8-fd0c2c8c732d@github.com>

On Thu, 25 Feb 2021 16:27:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Fails prior the patch of JDK-8257746, passes after. As expected.
> 
> Thoughts?

@poonamparhar @hseigel Could you please take a look? It's just a simple regression test for the JDK-8257746 NPE regression.

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

PR: https://git.openjdk.java.net/jdk/pull/2725

From jlaskey at openjdk.java.net  Mon Mar  1 13:27:54 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 1 Mar 2021 13:27:54 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v25]
In-Reply-To: <DamYpqiLVWIOiV0ov-kU2axAHGwNqeOrChjv3Upx5nw=.910c3544-082a-4ded-b8f1-4a9201257774@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <eAYgnQa5RffkAg-Rb4f3oWoOTOh1LFx-HE9y1MJJgus=.62ecf0ca-b589-4e8d-8c86-0d1020229e09@github.com>
 <DamYpqiLVWIOiV0ov-kU2axAHGwNqeOrChjv3Upx5nw=.910c3544-082a-4ded-b8f1-4a9201257774@github.com>
Message-ID: <FRFQbaq5_wNNFXuT_DHTaBEY5xydRkdWq-kmt7_OyFE=.5a371bef-36e8-4fa1-8184-6cec99fc3498@github.com>

On Fri, 26 Feb 2021 19:30:09 GMT, Roger Riggs <rriggs 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 57 commits:
>> 
>>  - Merge branch 'master' into 8248862
>>  - Adjust ThreadLocalRandom javadoc inheritence
>>  - L32X64StarStarRandom -> L32X64MixRandom
>>  - Various corrects
>>  - Revised javadoc per CSR reviews
>>  - Remove tabs from random/package-info.java
>>  - Correct copyright notice.
>>  - Merge branch 'master' into 8248862
>>  - Update tests for RandomGeneratorFactory.all()
>>  - Merge branch 'master' into 8248862
>>  - ... and 47 more: https://git.openjdk.java.net/jdk/compare/0257caad...b9094279
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 232:
> 
>> 230:         Provider<? extends RandomGenerator> provider = fm.get(name);
>> 231:         if (!isSubclass(category, provider)) {
>> 232:             throw new IllegalArgumentException(name + " is an unknown random number generator");
> 
> The message is a bit vague. How about:
> 
> "The random number generator does not support the category"

throw new IllegalArgumentException("The random number generator "" + name + "" can not be located");

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From jlaskey at openjdk.java.net  Mon Mar  1 13:37:58 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 1 Mar 2021 13:37:58 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v25]
In-Reply-To: <DamYpqiLVWIOiV0ov-kU2axAHGwNqeOrChjv3Upx5nw=.910c3544-082a-4ded-b8f1-4a9201257774@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <eAYgnQa5RffkAg-Rb4f3oWoOTOh1LFx-HE9y1MJJgus=.62ecf0ca-b589-4e8d-8c86-0d1020229e09@github.com>
 <DamYpqiLVWIOiV0ov-kU2axAHGwNqeOrChjv3Upx5nw=.910c3544-082a-4ded-b8f1-4a9201257774@github.com>
Message-ID: <KCPfLzkHBabKoyt2sQCwHxED21m1Tjb5t4DVIZXRMfM=.2da0d7f8-b9c1-4660-865a-bd98ebe84034@github.com>

On Fri, 26 Feb 2021 21:25:38 GMT, Roger Riggs <rriggs 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 57 commits:
>> 
>>  - Merge branch 'master' into 8248862
>>  - Adjust ThreadLocalRandom javadoc inheritence
>>  - L32X64StarStarRandom -> L32X64MixRandom
>>  - Various corrects
>>  - Revised javadoc per CSR reviews
>>  - Remove tabs from random/package-info.java
>>  - Correct copyright notice.
>>  - Merge branch 'master' into 8248862
>>  - Update tests for RandomGeneratorFactory.all()
>>  - Merge branch 'master' into 8248862
>>  - ... and 47 more: https://git.openjdk.java.net/jdk/compare/0257caad...b9094279
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 240:
> 
>> 238:      * Returns a {@link RandomGenerator} that utilizes the {@code name}
>> 239:      * <a href="package-summary.html#algorithms">algorithm</a>.
>> 240:      *
> 
> In javadoc, this seems like is should read as: "utilizes the named algorithm".
> The use of the parameter name is unnecessary in this case because it is obvious and readability suffers as is.

Modified.

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From jlaskey at openjdk.java.net  Mon Mar  1 13:59:53 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 1 Mar 2021 13:59:53 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v25]
In-Reply-To: <DamYpqiLVWIOiV0ov-kU2axAHGwNqeOrChjv3Upx5nw=.910c3544-082a-4ded-b8f1-4a9201257774@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <eAYgnQa5RffkAg-Rb4f3oWoOTOh1LFx-HE9y1MJJgus=.62ecf0ca-b589-4e8d-8c86-0d1020229e09@github.com>
 <DamYpqiLVWIOiV0ov-kU2axAHGwNqeOrChjv3Upx5nw=.910c3544-082a-4ded-b8f1-4a9201257774@github.com>
Message-ID: <ILTuns9L7Khu06Ulqr_2rqg7UwceWTUtpUsAPyRq_80=.57180409-9958-4417-a574-2e85a852b1dc@github.com>

On Fri, 26 Feb 2021 21:32:12 GMT, Roger Riggs <rriggs 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 57 commits:
>> 
>>  - Merge branch 'master' into 8248862
>>  - Adjust ThreadLocalRandom javadoc inheritence
>>  - L32X64StarStarRandom -> L32X64MixRandom
>>  - Various corrects
>>  - Revised javadoc per CSR reviews
>>  - Remove tabs from random/package-info.java
>>  - Correct copyright notice.
>>  - Merge branch 'master' into 8248862
>>  - Update tests for RandomGeneratorFactory.all()
>>  - Merge branch 'master' into 8248862
>>  - ... and 47 more: https://git.openjdk.java.net/jdk/compare/0257caad...b9094279
>
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1313:
> 
>> 1311:      * furthermore can easily <i>jump</i> to an arbitrarily specified distant
>> 1312:      * point in the state cycle.
>> 1313:      *
> 
> The similarity of the first sentence of each of the Jumpable, Leapable, and arbitrarlyJumpable interface is so similar as to obscure the differences. You have to read 25 words in to be able to find the description that makes them different. The italics help but should include the whole of the phrase that distinguishes them.
> Alternatively, move the phrase to the beginning of the sentence or drop the redundant phrasing.
> "provide a common protocol of objects that generate pseudorandom sequences of numbers of Boolean values", etc.

Jumpable:
     * This interface is designed to provide a common protocol for objects that
     * generate pseudorandom sequences of numbers (or Boolean values) and
     * furthermore can easily <i>jump</i> forward, by a moderate amount (ex.
     * 2<sup>64</sup>) to a distant point in the state cycle.

Leapable:
     * This interface is designed to provide a common protocol for objects that
     * generate sequences of pseudorandom numbers (or Boolean values) and
     * furthermore can easily not only jump but also
     * <i>leap</i> forward, by a large amount (ex. 2<sup>128</sup>), to a
     * very distant point in the state cycle.

ArbitrarilyJumpable:
     * This interface is designed to provide a common protocol for objects that
     * generate sequences of pseudorandom numbers (or Boolean values) and
     * furthermore can easily <i>jump</i> forward, by an arbitrary amount, to a
     * distant point in the state cycle.

> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 55:
> 
>> 53:  *
>> 54:  * A specific {@link RandomGeneratorFactory} can be located by using the
>> 55:  * {@link RandomGenerator#factoryOf(String)} method, where the argument string
> 
> Broken link: the method is in this class.  should be just "#factoryOf".

Modified

> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 600:
> 
>> 598:         try {
>> 599:             ensureConstructors();
>> 600:             return ctorBytes.newInstance((Object)seed);
> 
> IntelliJ warns that the cast to (Object) is redundant.

Modified

> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 29:
> 
>> 27: 
>> 28: import java.lang.reflect.Constructor;
>> 29: import java.lang.reflect.Method;
> 
> Used import.

Modified

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From hseigel at openjdk.java.net  Mon Mar  1 14:35:50 2021
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 1 Mar 2021 14:35:50 GMT
Subject: RFR: 8262379: Add regression test for JDK-8257746
In-Reply-To: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>
References: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>
Message-ID: <13E-0hnjHJ7_Ht5ZQIyKK0sybjCByABA1qM4dVJsj-k=.2f406244-5e05-44b5-8f76-629689e937b7@github.com>

On Thu, 25 Feb 2021 16:27:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Fails prior the patch of JDK-8257746, passes after. As expected.
> 
> Thoughts?

The new tests looks good.  Thanks for adding it.

Harold

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

Marked as reviewed by hseigel (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2725

From rriggs at openjdk.java.net  Mon Mar  1 15:15:59 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 1 Mar 2021 15:15:59 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v25]
In-Reply-To: <FRFQbaq5_wNNFXuT_DHTaBEY5xydRkdWq-kmt7_OyFE=.5a371bef-36e8-4fa1-8184-6cec99fc3498@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <eAYgnQa5RffkAg-Rb4f3oWoOTOh1LFx-HE9y1MJJgus=.62ecf0ca-b589-4e8d-8c86-0d1020229e09@github.com>
 <DamYpqiLVWIOiV0ov-kU2axAHGwNqeOrChjv3Upx5nw=.910c3544-082a-4ded-b8f1-4a9201257774@github.com>
 <FRFQbaq5_wNNFXuT_DHTaBEY5xydRkdWq-kmt7_OyFE=.5a371bef-36e8-4fa1-8184-6cec99fc3498@github.com>
Message-ID: <0dwfSfa8BoyK8VmDxjszhf1qmRX9nT6Rg5xtxbfBfWg=.3d7ddeb3-a6de-42d6-bb8d-82b1504d448d@github.com>

On Mon, 1 Mar 2021 13:23:48 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 232:
>> 
>>> 230:         Provider<? extends RandomGenerator> provider = fm.get(name);
>>> 231:         if (!isSubclass(category, provider)) {
>>> 232:             throw new IllegalArgumentException(name + " is an unknown random number generator");
>> 
>> The message is a bit vague. How about:
>> 
>> "The random number generator does not support the category"
>
> throw new IllegalArgumentException("The random number generator "" + name + "" can not be located");

The message only captures the failure if the result of `fm.get()` is null.
It does not capture the failure if the name is found but does not support the category.

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From sgehwolf at openjdk.java.net  Mon Mar  1 15:17:41 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 1 Mar 2021 15:17:41 GMT
Subject: Integrated: 8262379: Add regression test for JDK-8257746
In-Reply-To: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>
References: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>
Message-ID: <eOp38fWBGGldQljcHA9k9IvXok93lgqJ8R3qfYfa1No=.8002ac61-6283-4111-8de4-ca44ea6d20c4@github.com>

On Thu, 25 Feb 2021 16:27:20 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Fails prior the patch of JDK-8257746, passes after. As expected.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 4c9adce2
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4c9adce2
Stats:     56 lines in 1 file changed: 56 ins; 0 del; 0 mod

8262379: Add regression test for JDK-8257746

Reviewed-by: hseigel

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

PR: https://git.openjdk.java.net/jdk/pull/2725

From sgehwolf at openjdk.java.net  Mon Mar  1 15:17:40 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 1 Mar 2021 15:17:40 GMT
Subject: RFR: 8262379: Add regression test for JDK-8257746
In-Reply-To: <13E-0hnjHJ7_Ht5ZQIyKK0sybjCByABA1qM4dVJsj-k=.2f406244-5e05-44b5-8f76-629689e937b7@github.com>
References: <bePB-zu9tc6Pp6B_wqVakmQ_Ouh5iDJSdKyO4sWLDFQ=.78bdb2de-9d5a-47c6-8679-b1ac9304e3d4@github.com>
 <13E-0hnjHJ7_Ht5ZQIyKK0sybjCByABA1qM4dVJsj-k=.2f406244-5e05-44b5-8f76-629689e937b7@github.com>
Message-ID: <LYZLXzeqIBMqd25j-Ors4Qmqv4XrD_ma4hpj4xzJC2k=.8faf6737-d09a-4acd-bf96-337dec49b594@github.com>

On Mon, 1 Mar 2021 14:33:06 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

>> Fails prior the patch of JDK-8257746, passes after. As expected.
>> 
>> Thoughts?
>
> The new tests looks good.  Thanks for adding it.
> 
> Harold

Thanks for the review @hseigel!

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

PR: https://git.openjdk.java.net/jdk/pull/2725

From cgo at openjdk.java.net  Mon Mar  1 15:24:43 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Mon, 1 Mar 2021 15:24:43 GMT
Subject: RFR: JDK-8262471: Fix coding style in
 src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java
In-Reply-To: <zYXYhx46bm8g_dYCTXxlnrIIoOldQwc7giadIrKOxao=.22da3a8e-6349-473f-8015-a64488572469@github.com>
References: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>
 <zYXYhx46bm8g_dYCTXxlnrIIoOldQwc7giadIrKOxao=.22da3a8e-6349-473f-8015-a64488572469@github.com>
Message-ID: <WioKjap6ADDAdX_tFW3B7fwKuVaihCNA7P2yvMlZW9A=.4aa81ba1-821f-4c46-a32d-317c164c3336@github.com>

On Sat, 27 Feb 2021 08:03:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review this small patch which fixes the coding style of CharacterDataPrivateUse.java
>
> Looks fine. This source file was a .template until a few weeks ago, probably should have fixed the indentation issues when moving it to a .java file.

Thanks for the review.
Do we need a second reviewer? If not, could you please sponsor the change?

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

PR: https://git.openjdk.java.net/jdk/pull/2754

From jlaskey at openjdk.java.net  Mon Mar  1 15:42:43 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 1 Mar 2021 15:42:43 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v25]
In-Reply-To: <0dwfSfa8BoyK8VmDxjszhf1qmRX9nT6Rg5xtxbfBfWg=.3d7ddeb3-a6de-42d6-bb8d-82b1504d448d@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <eAYgnQa5RffkAg-Rb4f3oWoOTOh1LFx-HE9y1MJJgus=.62ecf0ca-b589-4e8d-8c86-0d1020229e09@github.com>
 <DamYpqiLVWIOiV0ov-kU2axAHGwNqeOrChjv3Upx5nw=.910c3544-082a-4ded-b8f1-4a9201257774@github.com>
 <FRFQbaq5_wNNFXuT_DHTaBEY5xydRkdWq-kmt7_OyFE=.5a371bef-36e8-4fa1-8184-6cec99fc3498@github.com>
 <0dwfSfa8BoyK8VmDxjszhf1qmRX9nT6Rg5xtxbfBfWg=.3d7ddeb3-a6de-42d6-bb8d-82b1504d448d@github.com>
Message-ID: <F6Z47X3Wmo0XOH0b4TELtb-lxNl9-8RPZpfF32lPoOE=.f1a6c3b4-4f3a-402d-8cb8-245d5e4025fc@github.com>

On Mon, 1 Mar 2021 15:12:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> throw new IllegalArgumentException("The random number generator "" + name + "" can not be located");
>
> The message only captures the failure if the result of `fm.get()` is null.
> It does not capture the failure if the name is found but does not support the category.

if (provider == null) {
            throw new IllegalArgumentException("No implementation of the random number generator algorithm "" +
                                                name +
                                                "" is available");
        } else if (!isSubclass(category, provider)) {
            throw new IllegalArgumentException("The random number generator algorithm "" +
                                                name +
                                                "" is not implemented with the interface "" +
                                                category.simpleName() +
                                                """);
        }

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From herrick at openjdk.java.net  Mon Mar  1 16:07:51 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 1 Mar 2021 16:07:51 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir when
 there is no module-path
Message-ID: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>

when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory.

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

Commit messages:
 - JDK-8261518: jpackage looks for main module in current dir when there is no module-path
 - JDK-8261518: jpackage looks for main module in current dir when there is no module-path

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

PR: https://git.openjdk.java.net/jdk/pull/2781

From kizune at openjdk.java.net  Mon Mar  1 18:04:02 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Mon, 1 Mar 2021 18:04:02 GMT
Subject: RFR: JDK-8261839: Error creating runtime package on macos without
 mac-package-identifier
In-Reply-To: <Ud381JAYMbX6g7bp0zyNCH0U8Z1pfJmUTzDyG8flRE4=.964557e6-f205-42b0-8170-290006e6476f@github.com>
References: <Ud381JAYMbX6g7bp0zyNCH0U8Z1pfJmUTzDyG8flRE4=.964557e6-f205-42b0-8170-290006e6476f@github.com>
Message-ID: <lSDg1I0suS2G8KnYEcA51VhoA-uazgXiEqWdIN0JnUo=.a69174d7-25a5-424f-ba07-0395a529bef8@github.com>

On Thu, 25 Feb 2021 21:15:44 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> ?age-identifier

Looks fine.

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

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2730

From asemenyuk at openjdk.java.net  Mon Mar  1 18:07:39 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 1 Mar 2021 18:07:39 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path
In-Reply-To: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
Message-ID: <lNZ7bWlo36L62fcG-LLWI4xGl9oqX0MjJIVJJ-q0uQ4=.6fc652b0-1166-4526-986a-d17c0384ecb7@github.com>

On Mon, 1 Mar 2021 15:55:39 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory.

Marked as reviewed by asemenyuk (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2781

From psandoz at openjdk.java.net  Mon Mar  1 18:16:45 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 1 Mar 2021 18:16:45 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v5]
In-Reply-To: <HvKNMr9928e7BprhljVpIsOli17oUJ0yAj8qXdPBFKk=.7f856b60-4c04-4c8e-b825-9be2a78eb73c@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <1Hd5G9-WTDa6JJoWajyvMoyAES1Kea2phVh6umYbov8=.bbf1a2f5-bb7b-40e2-ab66-5b6321b63a0d@github.com>
 <e3XY5rvnS7p0Y5ECjLhEOBaH8xivacWUYf3GygDm0g8=.2188907b-f848-4f64-8407-f7cafba966e2@github.com>
 <gL27OMIhX3PbFmqVri2tUrFGuj0RuIucdkkfTJh1jgo=.17a79b44-b65d-4344-bd5e-fe788f222c78@github.com>
 <HvKNMr9928e7BprhljVpIsOli17oUJ0yAj8qXdPBFKk=.7f856b60-4c04-4c8e-b825-9be2a78eb73c@github.com>
Message-ID: <cF33iptavigAazHD16LbEOmXwf7i6jbriTLLZfHkC_g=.ec76ec68-81ea-4ec3-b7e4-a4a36311a4ee@github.com>

On Sun, 28 Feb 2021 13:31:38 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> `@requires vm.compiler2.enabled` had been added.
>> Thanks.
>
> @PaulSandoz , are you also OK with the latest version?
> Thanks.

@DamonFool I think Vladimir is correct in the layering, in this respect i think we can make things a littler clearer. This seems like a small thing but i think its worth making very explicit as there is some hidden complexity.

What if we add the following method to `VectorShape`:

    /**
     * Returns the maximum vector bit size for a given element type.
     *
     * @param etype the element type.
     * @return the maximum vector bit.
     */
     /*package-private*/
    static int getMaxVectorBitSize(Class<?> etype) {
        // May return -1 if C2 is not enabled,
        // or a value smaller than the S_64_BIT.vectorBitSize / elementSizeInBits, on say 32-bit platforms
        // If so default to S_64_BIT
        int maxLaneCount = VectorSupport.getMaxLaneCount(etype);
        int elementSizeInBits = LaneType.of(etype).elementSize;
        return Math.max(maxLaneCount * elementSizeInBits, S_64_BIT.vectorBitSize);
    }

It is package private so it can be tested explicitly if need be.

Then we can reuse that method:
    S_Max_BIT(getMaxVectorBitSize(byte.class));

    static VectorShape largestShapeFor(Class<?> etype) {
        return VectorShape.forBitSize(getMaxVectorBitSize(etype));
    }

I think that's correct, but i have not tested. WDYT?

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From mcimadamore at openjdk.java.net  Mon Mar  1 19:30:00 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 1 Mar 2021 19:30:00 GMT
Subject: RFR: 8260869: Test java/foreign/TestHandshake.java fails
 intermittently [v2]
In-Reply-To: <mXyACmxchC_HsrnEgGBNmG1e5ggPpsIN5y-hxpU2Onc=.8c07c849-5deb-4b79-bf48-69251372c481@github.com>
References: <mXyACmxchC_HsrnEgGBNmG1e5ggPpsIN5y-hxpU2Onc=.8c07c849-5deb-4b79-bf48-69251372c481@github.com>
Message-ID: <Uo57iwPx-DCktiNZzD9-mMnwp4TQe02yPdL01hu95Jc=.130f4501-795a-431c-a13d-a18c84b37a19@github.com>

> This simple fix reduces the amount of concurrency on the foreign memory TestHandshake test. As this test spins a new accessor thread for each available processors, on machines which feature an high number of available processors (because of multi-threading), and which are slower in forking new threads (e.g. Windows), the test can sometimes timeout.
> 
> The sensible step, for now, is to introduce an hard limit on the number of concurrent accessor threads being created. I've looked at the test logs quite in depth, and there's nothing suggesting that something else is amiss - the number of concurrent threads just seem to be too high in some instances.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2748/files
  - new: https://git.openjdk.java.net/jdk/pull/2748/files/aa71dee6..df3346f5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2748&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2748&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2748

From mcimadamore at openjdk.java.net  Mon Mar  1 19:30:02 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 1 Mar 2021 19:30:02 GMT
Subject: RFR: 8260869: Test java/foreign/TestHandshake.java fails
 intermittently [v2]
In-Reply-To: <Abs3A1X9HZu1aaJRGNhEu6Eeq7BO8Xmrbxh6ftXia_s=.5750fa1b-043b-4590-baf5-4c400f1c296c@github.com>
References: <mXyACmxchC_HsrnEgGBNmG1e5ggPpsIN5y-hxpU2Onc=.8c07c849-5deb-4b79-bf48-69251372c481@github.com>
 <Abs3A1X9HZu1aaJRGNhEu6Eeq7BO8Xmrbxh6ftXia_s=.5750fa1b-043b-4590-baf5-4c400f1c296c@github.com>
Message-ID: <vn9ea87XKq2eSzG6aRXFy4F1xEPsxxix7eAfKbR75GI=.e6dadc0e-f39e-43b1-ad32-ec77c586158e@github.com>

On Fri, 26 Feb 2021 17:56:21 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> test/jdk/java/foreign/TestHandshake.java line 60:
> 
>> 58: 
>> 59:     static final int NUM_ACCESSORS = Math.max(10, Runtime.getRuntime().availableProcessors());
>> 60: 
> 
> `min` rather than `max` so as to clamp at a maximum of 10 accessors?

Whoops - of course :-)

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

PR: https://git.openjdk.java.net/jdk/pull/2748

From herrick at openjdk.java.net  Mon Mar  1 19:37:47 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 1 Mar 2021 19:37:47 GMT
Subject: Integrated: JDK-8261839: Error creating runtime package on macos
 without mac-package-identifier
In-Reply-To: <Ud381JAYMbX6g7bp0zyNCH0U8Z1pfJmUTzDyG8flRE4=.964557e6-f205-42b0-8170-290006e6476f@github.com>
References: <Ud381JAYMbX6g7bp0zyNCH0U8Z1pfJmUTzDyG8flRE4=.964557e6-f205-42b0-8170-290006e6476f@github.com>
Message-ID: <sPGUCQVtao6SNGOcAa7Wv_UNm-QLD4zppJq0yXGan7I=.d16f2716-18f6-4603-8ed0-cc7c77ca3d54@github.com>

On Thu, 25 Feb 2021 21:15:44 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> ?age-identifier

This pull request has now been integrated.

Changeset: 642f45f9
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/642f45f9
Stats:     24 lines in 4 files changed: 8 ins; 5 del; 11 mod

8261839: Error creating runtime package on macos without mac-package-identifier

Reviewed-by: asemenyuk, almatvee, kizune

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

PR: https://git.openjdk.java.net/jdk/pull/2730

From psandoz at openjdk.java.net  Mon Mar  1 19:44:54 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 1 Mar 2021 19:44:54 GMT
Subject: RFR: 8260869: Test java/foreign/TestHandshake.java fails
 intermittently [v2]
In-Reply-To: <Uo57iwPx-DCktiNZzD9-mMnwp4TQe02yPdL01hu95Jc=.130f4501-795a-431c-a13d-a18c84b37a19@github.com>
References: <mXyACmxchC_HsrnEgGBNmG1e5ggPpsIN5y-hxpU2Onc=.8c07c849-5deb-4b79-bf48-69251372c481@github.com>
 <Uo57iwPx-DCktiNZzD9-mMnwp4TQe02yPdL01hu95Jc=.130f4501-795a-431c-a13d-a18c84b37a19@github.com>
Message-ID: <TIgStWK31kesi_nsXGCupPGJ8s180Q2pH2kMGgDnoKU=.4534108a-380e-4018-ae18-1fdf155e6f68@github.com>

On Mon, 1 Mar 2021 19:30:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This simple fix reduces the amount of concurrency on the foreign memory TestHandshake test. As this test spins a new accessor thread for each available processors, on machines which feature an high number of available processors (because of multi-threading), and which are slower in forking new threads (e.g. Windows), the test can sometimes timeout.
>> 
>> The sensible step, for now, is to introduce an hard limit on the number of concurrent accessor threads being created. I've looked at the test logs quite in depth, and there's nothing suggesting that something else is amiss - the number of concurrent threads just seem to be too high in some instances.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by psandoz (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2748

From jlaskey at openjdk.java.net  Mon Mar  1 20:01:19 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 1 Mar 2021 20:01:19 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v26]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <kk0wuLzOWgzKqNpXkNJumj-O5W6rCxQtXtbmyTtr7O0=.0f35e580-29ba-4a66-a3ee-5686e482f288@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update javadoc

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/b9094279..99e92dd1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=25
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=24-25

  Stats: 460 lines in 7 files changed: 183 ins; 85 del; 192 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

PR: https://git.openjdk.java.net/jdk/pull/1292

From joe.darcy at oracle.com  Mon Mar  1 21:35:59 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 1 Mar 2021 13:35:59 -0800
Subject: Inconsistency in Constructor.getGenericParameterTypes()
In-Reply-To: <AC08AA43-3697-4B8F-92A1-AAEF8947A232@vmware.com>
References: <66A26523-6C41-4A11-B9DD-D90B69341E31@vmware.com>
 <4456C60B-A6B9-4AE8-A8D9-5EC5550A56E7@vmware.com>
 <b28b1db9-3678-35e7-bfbd-559bb1e22da4@oracle.com>
 <AC08AA43-3697-4B8F-92A1-AAEF8947A232@vmware.com>
Message-ID: <3b8f43f1-e993-2521-d5a7-b29d50c0e622@oracle.com>

Hi Oliver,

Perhaps the time has come to make a run at discussing this situation in 
the javadoc. One challenge in writing this material up is to phrase and 
structure the text so it offers a net-clarification of the situation. In 
other words, to not distract or confuse most readers on what is usually 
a tricky detail.

The @apiNote javadoc tag offers a mechanism to separate such discussion.

Thanks,

-Joe

On 2/26/2021 2:20 PM, Oliver Drotbohm wrote:
> Hi Joe,
>
> thanks for the explanation. We switched to rather iterating over ?.getParameters() and take it from there. Do you think it makes sense to leave a note about this in the Javadoc?
>
> Cheers,
> Ollie
>
>> Am 26.02.2021 um 22:38 schrieb Joe Darcy <joe.darcy at oracle.com>:
>>
>> Hello Oliver,
>>
>> This is long-standing if surprising and under-documented behavior.
>>
>> The getGenericFoo methods, when generic type information is present, give a source-level view of the element. At a source level, the implicit outer this parameter is not present and thus omitted by constructor.getGenericParameterTypes for the constructor in question.
>>
>> HTH,
>>
>> -Joe
>>
>> On 2/26/2021 5:41 AM, Oliver Drotbohm wrote:
>>> Previously sent to the wrong list. Sorry for the double post.
>>>
>>> Von: Oliver Drotbohm <odrotbohm at vmware.com>
>>> Betreff: Inconsistency in Constructor.getGenericParameterTypes()
>>> Datum: 25. Februar 2021 um 10:03:12 MEZ
>>> An: jdk-dev at openjdk.java.net
>>>
>>> Hi all,
>>>
>>> we've just ran into the following issue: for a non-static, generic inner class with a constructor declaring a generic parameter, a call to constructor.getGenericParameterTypes() does not return the enclosing class parameter type. Is that by intention? If so, what's the reasoning behind that?
>>>
>>> Here's a the output of a reproducer (below):
>>>
>>> static class StaticGeneric<T> - names: value, string
>>> static class StaticGeneric<T> - parameters: [class java.lang.Object, class java.lang.String]
>>> static class StaticGeneric<T> - generic parameters: [T, class java.lang.String]
>>>
>>> class NonStaticGeneric<T> - names: this$0, value, String
>>> class NonStaticGeneric<T> - parameters: [class Sample, class java.lang.Object, class java.lang.String]
>>> class NonStaticGeneric<T> - generic parameters: [T, class java.lang.String]
>>>
>>> class NonStaticNonGeneric - names: this$0, String
>>> class NonStaticNonGeneric - parameters: [class Sample, class java.lang.String]
>>> class NonStaticNonGeneric - generic parameters: [class Sample, class java.lang.String]
>>>
>>> Note how the constructor of the NonStaticGeneric<T> type exposes three parameter names, three parameter types but omits the enclosing class parameter in the list of generic parameter types.
>>>
>>> Tested on JDK 8 to 15. Same behavior.
>>>
>>> Cheers,
>>> Ollie
>>>
>>>
>>> class Sample {
>>>
>>> 	public static void main(String[] args) {
>>>
>>> 		Constructor<?> first = StaticGeneric.class.getDeclaredConstructors()[0];
>>>
>>> 		System.out.println("static class StaticGeneric<T> - names: "
>>> 				+ Arrays.stream(first.getParameters()).map(Parameter::getName).collect(Collectors.joining(", ")));
>>> 		System.out.println("static class StaticGeneric<T> - parameters: " + Arrays.toString(first.getParameterTypes()));
>>> 		System.out.println(
>>> 				"static class StaticGeneric<T> - generic parameters: " + Arrays.toString(first.getGenericParameterTypes()));
>>>
>>> 		System.out.println();
>>>
>>> 		Constructor<?> second = NonStaticGeneric.class.getDeclaredConstructors()[0];
>>> 		System.out.println("class NonStaticGeneric<T> - names: "
>>> 				+ Arrays.stream(second.getParameters()).map(Parameter::getName).collect(Collectors.joining(", ")));
>>> 		System.out.println("class NonStaticGeneric<T> - parameters: " + Arrays.toString(second.getParameterTypes()));
>>> 		System.out
>>> 				.println(
>>> 						"class NonStaticGeneric<T> - generic parameters: " + Arrays.toString(second.getGenericParameterTypes()));
>>>
>>> 		System.out.println();
>>>
>>> 		Constructor<?> third = NonStaticNonGeneric.class.getDeclaredConstructors()[0];
>>> 		System.out.println("class NonStaticNonGeneric - names: "
>>> 				+ Arrays.stream(third.getParameters()).map(Parameter::getName).collect(Collectors.joining(", ")));
>>> 		System.out.println("class NonStaticNonGeneric - parameters: " + Arrays.toString(third.getParameterTypes()));
>>> 		System.out
>>> 				.println(
>>> 						"class NonStaticNonGeneric - generic parameters: " + Arrays.toString(third.getGenericParameterTypes()));
>>> 	}
>>>
>>> 	static class StaticGeneric<T> {
>>> 		StaticGeneric(T value, String string) {}
>>> 	}
>>>
>>> 	class NonStaticGeneric<T> {
>>> 		NonStaticGeneric(T value, String String) {}
>>> 	}
>>>
>>> 	class NonStaticNonGeneric {
>>> 		NonStaticNonGeneric(String String) {}
>>> 	}
>>> }
>>>

From forax at univ-mlv.fr  Mon Mar  1 22:16:56 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 1 Mar 2021 23:16:56 +0100 (CET)
Subject: Inconsistency in Constructor.getGenericParameterTypes()
In-Reply-To: <3b8f43f1-e993-2521-d5a7-b29d50c0e622@oracle.com>
References: <66A26523-6C41-4A11-B9DD-D90B69341E31@vmware.com>
 <4456C60B-A6B9-4AE8-A8D9-5EC5550A56E7@vmware.com>
 <b28b1db9-3678-35e7-bfbd-559bb1e22da4@oracle.com>
 <AC08AA43-3697-4B8F-92A1-AAEF8947A232@vmware.com>
 <3b8f43f1-e993-2521-d5a7-b29d50c0e622@oracle.com>
Message-ID: <631807797.747772.1614637016703.JavaMail.zimbra@u-pem.fr>

Hi Joe,
i think the overview of the package java.lang.reflect should discuss the fact that the reflection view is what is stored in the classfile, not exactly a reflection of the java code.

So depending on what you are requesting, you can see synthetic parameters generated by javac or only the Java view because the Java view is directly stored in an attributes like with generics

R?mi

----- Mail original -----
> De: "joe darcy" <joe.darcy at oracle.com>
> ?: "Oliver Drotbohm" <odrotbohm at vmware.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Lundi 1 Mars 2021 22:35:59
> Objet: Re: Inconsistency in Constructor.getGenericParameterTypes()

> Hi Oliver,
> 
> Perhaps the time has come to make a run at discussing this situation in
> the javadoc. One challenge in writing this material up is to phrase and
> structure the text so it offers a net-clarification of the situation. In
> other words, to not distract or confuse most readers on what is usually
> a tricky detail.
> 
> The @apiNote javadoc tag offers a mechanism to separate such discussion.
> 
> Thanks,
> 
> -Joe
> 
> On 2/26/2021 2:20 PM, Oliver Drotbohm wrote:
>> Hi Joe,
>>
>> thanks for the explanation. We switched to rather iterating over
>> ?.getParameters() and take it from there. Do you think it makes sense to leave
>> a note about this in the Javadoc?
>>
>> Cheers,
>> Ollie
>>
>>> Am 26.02.2021 um 22:38 schrieb Joe Darcy <joe.darcy at oracle.com>:
>>>
>>> Hello Oliver,
>>>
>>> This is long-standing if surprising and under-documented behavior.
>>>
>>> The getGenericFoo methods, when generic type information is present, give a
>>> source-level view of the element. At a source level, the implicit outer this
>>> parameter is not present and thus omitted by
>>> constructor.getGenericParameterTypes for the constructor in question.
>>>
>>> HTH,
>>>
>>> -Joe
>>>
>>> On 2/26/2021 5:41 AM, Oliver Drotbohm wrote:
>>>> Previously sent to the wrong list. Sorry for the double post.
>>>>
>>>> Von: Oliver Drotbohm <odrotbohm at vmware.com>
>>>> Betreff: Inconsistency in Constructor.getGenericParameterTypes()
>>>> Datum: 25. Februar 2021 um 10:03:12 MEZ
>>>> An: jdk-dev at openjdk.java.net
>>>>
>>>> Hi all,
>>>>
>>>> we've just ran into the following issue: for a non-static, generic inner class
>>>> with a constructor declaring a generic parameter, a call to
>>>> constructor.getGenericParameterTypes() does not return the enclosing class
>>>> parameter type. Is that by intention? If so, what's the reasoning behind that?
>>>>
>>>> Here's a the output of a reproducer (below):
>>>>
>>>> static class StaticGeneric<T> - names: value, string
>>>> static class StaticGeneric<T> - parameters: [class java.lang.Object, class
>>>> java.lang.String]
>>>> static class StaticGeneric<T> - generic parameters: [T, class java.lang.String]
>>>>
>>>> class NonStaticGeneric<T> - names: this$0, value, String
>>>> class NonStaticGeneric<T> - parameters: [class Sample, class java.lang.Object,
>>>> class java.lang.String]
>>>> class NonStaticGeneric<T> - generic parameters: [T, class java.lang.String]
>>>>
>>>> class NonStaticNonGeneric - names: this$0, String
>>>> class NonStaticNonGeneric - parameters: [class Sample, class java.lang.String]
>>>> class NonStaticNonGeneric - generic parameters: [class Sample, class
>>>> java.lang.String]
>>>>
>>>> Note how the constructor of the NonStaticGeneric<T> type exposes three parameter
>>>> names, three parameter types but omits the enclosing class parameter in the
>>>> list of generic parameter types.
>>>>
>>>> Tested on JDK 8 to 15. Same behavior.
>>>>
>>>> Cheers,
>>>> Ollie
>>>>
>>>>
>>>> class Sample {
>>>>
>>>> 	public static void main(String[] args) {
>>>>
>>>> 		Constructor<?> first = StaticGeneric.class.getDeclaredConstructors()[0];
>>>>
>>>> 		System.out.println("static class StaticGeneric<T> - names: "
>>>> 				+
>>>> 				Arrays.stream(first.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
>>>> 				")));
>>>> 		System.out.println("static class StaticGeneric<T> - parameters: " +
>>>> 		Arrays.toString(first.getParameterTypes()));
>>>> 		System.out.println(
>>>> 				"static class StaticGeneric<T> - generic parameters: " +
>>>> 				Arrays.toString(first.getGenericParameterTypes()));
>>>>
>>>> 		System.out.println();
>>>>
>>>> 		Constructor<?> second = NonStaticGeneric.class.getDeclaredConstructors()[0];
>>>> 		System.out.println("class NonStaticGeneric<T> - names: "
>>>> 				+
>>>> 				Arrays.stream(second.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
>>>> 				")));
>>>> 		System.out.println("class NonStaticGeneric<T> - parameters: " +
>>>> 		Arrays.toString(second.getParameterTypes()));
>>>> 		System.out
>>>> 				.println(
>>>> 						"class NonStaticGeneric<T> - generic parameters: " +
>>>> 						Arrays.toString(second.getGenericParameterTypes()));
>>>>
>>>> 		System.out.println();
>>>>
>>>> 		Constructor<?> third = NonStaticNonGeneric.class.getDeclaredConstructors()[0];
>>>> 		System.out.println("class NonStaticNonGeneric - names: "
>>>> 				+
>>>> 				Arrays.stream(third.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
>>>> 				")));
>>>> 		System.out.println("class NonStaticNonGeneric - parameters: " +
>>>> 		Arrays.toString(third.getParameterTypes()));
>>>> 		System.out
>>>> 				.println(
>>>> 						"class NonStaticNonGeneric - generic parameters: " +
>>>> 						Arrays.toString(third.getGenericParameterTypes()));
>>>> 	}
>>>>
>>>> 	static class StaticGeneric<T> {
>>>> 		StaticGeneric(T value, String string) {}
>>>> 	}
>>>>
>>>> 	class NonStaticGeneric<T> {
>>>> 		NonStaticGeneric(T value, String String) {}
>>>> 	}
>>>>
>>>> 	class NonStaticNonGeneric {
>>>> 		NonStaticNonGeneric(String String) {}
>>>> 	}
>>>> }

From joehw at openjdk.java.net  Mon Mar  1 23:59:11 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 1 Mar 2021 23:59:11 GMT
Subject: RFR: 8261670: Add javadoc for the XML processing limits [v4]
In-Reply-To: <sd4qXAu9tsJfGmd_oBO97xX2iBIhJo0dhjN5jtDtn9U=.ad657cdd-2dcc-4136-84f0-4548ee0e1d89@github.com>
References: <sd4qXAu9tsJfGmd_oBO97xX2iBIhJo0dhjN5jtDtn9U=.ad657cdd-2dcc-4136-84f0-4548ee0e1d89@github.com>
Message-ID: <74lnD7a53htCRm3kTiG3PhjcWGexuRcqzww6c8r-Ppw=.e387e076-025f-4b73-99dd-49f73f488b31@github.com>

> Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide.

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

  Change the description of the property table to indicate that the list of the properties is not exhaustive

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2732/files
  - new: https://git.openjdk.java.net/jdk/pull/2732/files/3e555d20..9be83cb5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2732&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2732&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/2732

From lancea at openjdk.java.net  Tue Mar  2 00:13:48 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 2 Mar 2021 00:13:48 GMT
Subject: RFR: 8261670: Add javadoc for the XML processing limits [v4]
In-Reply-To: <74lnD7a53htCRm3kTiG3PhjcWGexuRcqzww6c8r-Ppw=.e387e076-025f-4b73-99dd-49f73f488b31@github.com>
References: <sd4qXAu9tsJfGmd_oBO97xX2iBIhJo0dhjN5jtDtn9U=.ad657cdd-2dcc-4136-84f0-4548ee0e1d89@github.com>
 <74lnD7a53htCRm3kTiG3PhjcWGexuRcqzww6c8r-Ppw=.e387e076-025f-4b73-99dd-49f73f488b31@github.com>
Message-ID: <VokV0Ackpv9ubxEuZDT2e3LR0SmL-rxbwTrUM3A8cFU=.35edabcd-e2de-4a1a-9af8-2009238e00ed@github.com>

On Mon, 1 Mar 2021 23:59:11 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the description of the property table to indicate that the list of the properties is not exhaustive

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2732

From iris at openjdk.java.net  Tue Mar  2 00:13:48 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 2 Mar 2021 00:13:48 GMT
Subject: RFR: 8261670: Add javadoc for the XML processing limits [v4]
In-Reply-To: <74lnD7a53htCRm3kTiG3PhjcWGexuRcqzww6c8r-Ppw=.e387e076-025f-4b73-99dd-49f73f488b31@github.com>
References: <sd4qXAu9tsJfGmd_oBO97xX2iBIhJo0dhjN5jtDtn9U=.ad657cdd-2dcc-4136-84f0-4548ee0e1d89@github.com>
 <74lnD7a53htCRm3kTiG3PhjcWGexuRcqzww6c8r-Ppw=.e387e076-025f-4b73-99dd-49f73f488b31@github.com>
Message-ID: <y4bmor8um_TnoMUPlcmdJzTZSslezhXatKoa1PAZ6LQ=.3ad1cd0f-4ce6-472d-a6a4-c2bfbbc25c93@github.com>

On Mon, 1 Mar 2021 23:59:11 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the description of the property table to indicate that the list of the properties is not exhaustive

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2732

From naoto at openjdk.java.net  Tue Mar  2 00:21:52 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 2 Mar 2021 00:21:52 GMT
Subject: RFR: 8261670: Add javadoc for the XML processing limits [v4]
In-Reply-To: <74lnD7a53htCRm3kTiG3PhjcWGexuRcqzww6c8r-Ppw=.e387e076-025f-4b73-99dd-49f73f488b31@github.com>
References: <sd4qXAu9tsJfGmd_oBO97xX2iBIhJo0dhjN5jtDtn9U=.ad657cdd-2dcc-4136-84f0-4548ee0e1d89@github.com>
 <74lnD7a53htCRm3kTiG3PhjcWGexuRcqzww6c8r-Ppw=.e387e076-025f-4b73-99dd-49f73f488b31@github.com>
Message-ID: <jace5uSJpB7jnJ3mUtHyTNiX3p2PbGn6PGKMLhOlFWw=.d861af74-d710-4fed-8684-5185892ef678@github.com>

On Mon, 1 Mar 2021 23:59:11 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change the description of the property table to indicate that the list of the properties is not exhaustive

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2732

From jiefu at openjdk.java.net  Tue Mar  2 02:11:09 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 2 Mar 2021 02:11:09 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v5]
In-Reply-To: <HvKNMr9928e7BprhljVpIsOli17oUJ0yAj8qXdPBFKk=.7f856b60-4c04-4c8e-b825-9be2a78eb73c@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <1Hd5G9-WTDa6JJoWajyvMoyAES1Kea2phVh6umYbov8=.bbf1a2f5-bb7b-40e2-ab66-5b6321b63a0d@github.com>
 <e3XY5rvnS7p0Y5ECjLhEOBaH8xivacWUYf3GygDm0g8=.2188907b-f848-4f64-8407-f7cafba966e2@github.com>
 <gL27OMIhX3PbFmqVri2tUrFGuj0RuIucdkkfTJh1jgo=.17a79b44-b65d-4344-bd5e-fe788f222c78@github.com>
 <HvKNMr9928e7BprhljVpIsOli17oUJ0yAj8qXdPBFKk=.7f856b60-4c04-4c8e-b825-9be2a78eb73c@github.com>
Message-ID: <YQYdO-brLPUTX-e7N6vEnVJgaSxQ_0e1w7QmppvmAW8=.98450e25-2188-468c-9f32-5a58d85683d6@github.com>

On Sun, 28 Feb 2021 13:31:38 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> `@requires vm.compiler2.enabled` had been added.
>> Thanks.
>
> @PaulSandoz , are you also OK with the latest version?
> Thanks.

> @DamonFool I think Vladimir is correct in the layering, in this respect i think we can make things a littler clearer. This seems like a small thing but i think its worth making very explicit as there is some hidden complexity.
> 
> What if we add the following method to `VectorShape`:
> 
> ```java
>     /**
>      * Returns the maximum vector bit size for a given element type.
>      *
>      * @param etype the element type.
>      * @return the maximum vector bit.
>      */
>      /*package-private*/
>     static int getMaxVectorBitSize(Class<?> etype) {
>         // May return -1 if C2 is not enabled,
>         // or a value smaller than the S_64_BIT.vectorBitSize / elementSizeInBits, on say 32-bit platforms
>         // If so default to S_64_BIT
>         int maxLaneCount = VectorSupport.getMaxLaneCount(etype);
>         int elementSizeInBits = LaneType.of(etype).elementSize;
>         return Math.max(maxLaneCount * elementSizeInBits, S_64_BIT.vectorBitSize);
>     }
> ```
> 
> It is package private so it can be tested explicitly if need be.
> 
> Then we can reuse that method:
> 
> ```
>     S_Max_BIT(getMaxVectorBitSize(byte.class));
> ```
> 
> ```
>     static VectorShape largestShapeFor(Class<?> etype) {
>         return VectorShape.forBitSize(getMaxVectorBitSize(etype));
>     }
> ```
> 
> I think that's correct, but i have not tested. WDYT?

Good suggestion.
Updated.

Testing:
 - jdk/incubator/vector with MaxVectorSize=default/8/4 on Linux/x64
 - jdk/incubator/vector without C2 on Linux/x64

Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From jiefu at openjdk.java.net  Tue Mar  2 02:11:08 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 2 Mar 2021 02:11:08 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v7]
In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
Message-ID: <A-WnLlIGApD007vIaJ80HU-Pv-EGLxnteB-uVgJuzhc=.269e29a4-329b-4d41-9136-5dcffc97e6dd@github.com>

> Hi all,
> 
> Vector API fails to work when:
>  - case 1: MaxVectorSize is set to <=8, or
>  - case 2: C2 is disabled
> 
> The reason is that {max/preferred} VectorShape initialization fails in both cases.
> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).
> 
> Vector API should not depend on C2 to run.
> It should work even there is no JIT compiler since it's a Java-level api.
> So let's fix it.
> 
> Testing:
>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

Jie Fu has updated the pull request incrementally with one additional commit since the last revision:

  Add VectorShape.getMaxVectorBitSize

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2722/files
  - new: https://git.openjdk.java.net/jdk/pull/2722/files/79402411..d3b4cc35

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2722&range=05-06

  Stats: 26 lines in 1 file changed: 16 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2722.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2722/head:pull/2722

PR: https://git.openjdk.java.net/jdk/pull/2722

From joe.darcy at oracle.com  Tue Mar  2 02:17:35 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 1 Mar 2021 18:17:35 -0800
Subject: Inconsistency in Constructor.getGenericParameterTypes()
In-Reply-To: <631807797.747772.1614637016703.JavaMail.zimbra@u-pem.fr>
References: <66A26523-6C41-4A11-B9DD-D90B69341E31@vmware.com>
 <4456C60B-A6B9-4AE8-A8D9-5EC5550A56E7@vmware.com>
 <b28b1db9-3678-35e7-bfbd-559bb1e22da4@oracle.com>
 <AC08AA43-3697-4B8F-92A1-AAEF8947A232@vmware.com>
 <3b8f43f1-e993-2521-d5a7-b29d50c0e622@oracle.com>
 <631807797.747772.1614637016703.JavaMail.zimbra@u-pem.fr>
Message-ID: <9923f771-26aa-ecd7-3f64-1cefc14092b1@oracle.com>

Hi Remi,

As package level statement would be helpful as long as it was linked to 
from specific types and methods (as java.lang.Class and 
java.lang.Package are part of core reflection but not the 
java.lang.reflect package).

As you state, core reflection is *mostly* a view of what is represented 
in the class file. However, the class file in general does not present 
sufficient information in all cases to recover a source-file view of the 
world even as an option. For example, as a compiler-internal contract 
javac had added two additional parameters to the private constructors of 
enums. Other Java compilers are required to do this and javac could, in 
principle, change this implementation detail at any time. There is no 
MANDATED or SYNTHETIC bit (see javax.lang.model.util.Elements.Origin) 
that can be used to reliably tease apart what is going on. The 
package-level specs of javax.lang.model.element discuss analogous issue 
for the language model API.

In any case, I've filed

 ??? JDK-8262807: Note assumptions of core reflection modeling and 
parameter handling

for core reflection.

Thanks,

-Joe

On 3/1/2021 2:16 PM, Remi Forax wrote:
> Hi Joe,
> i think the overview of the package java.lang.reflect should discuss the fact that the reflection view is what is stored in the classfile, not exactly a reflection of the java code.
>
> So depending on what you are requesting, you can see synthetic parameters generated by javac or only the Java view because the Java view is directly stored in an attributes like with generics
>
> R?mi
>
> ----- Mail original -----
>> De: "joe darcy" <joe.darcy at oracle.com>
>> ?: "Oliver Drotbohm" <odrotbohm at vmware.com>
>> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoy?: Lundi 1 Mars 2021 22:35:59
>> Objet: Re: Inconsistency in Constructor.getGenericParameterTypes()
>> Hi Oliver,
>>
>> Perhaps the time has come to make a run at discussing this situation in
>> the javadoc. One challenge in writing this material up is to phrase and
>> structure the text so it offers a net-clarification of the situation. In
>> other words, to not distract or confuse most readers on what is usually
>> a tricky detail.
>>
>> The @apiNote javadoc tag offers a mechanism to separate such discussion.
>>
>> Thanks,
>>
>> -Joe
>>
>> On 2/26/2021 2:20 PM, Oliver Drotbohm wrote:
>>> Hi Joe,
>>>
>>> thanks for the explanation. We switched to rather iterating over
>>> ?.getParameters() and take it from there. Do you think it makes sense to leave
>>> a note about this in the Javadoc?
>>>
>>> Cheers,
>>> Ollie
>>>
>>>> Am 26.02.2021 um 22:38 schrieb Joe Darcy <joe.darcy at oracle.com>:
>>>>
>>>> Hello Oliver,
>>>>
>>>> This is long-standing if surprising and under-documented behavior.
>>>>
>>>> The getGenericFoo methods, when generic type information is present, give a
>>>> source-level view of the element. At a source level, the implicit outer this
>>>> parameter is not present and thus omitted by
>>>> constructor.getGenericParameterTypes for the constructor in question.
>>>>
>>>> HTH,
>>>>
>>>> -Joe
>>>>
>>>> On 2/26/2021 5:41 AM, Oliver Drotbohm wrote:
>>>>> Previously sent to the wrong list. Sorry for the double post.
>>>>>
>>>>> Von: Oliver Drotbohm <odrotbohm at vmware.com>
>>>>> Betreff: Inconsistency in Constructor.getGenericParameterTypes()
>>>>> Datum: 25. Februar 2021 um 10:03:12 MEZ
>>>>> An: jdk-dev at openjdk.java.net
>>>>>
>>>>> Hi all,
>>>>>
>>>>> we've just ran into the following issue: for a non-static, generic inner class
>>>>> with a constructor declaring a generic parameter, a call to
>>>>> constructor.getGenericParameterTypes() does not return the enclosing class
>>>>> parameter type. Is that by intention? If so, what's the reasoning behind that?
>>>>>
>>>>> Here's a the output of a reproducer (below):
>>>>>
>>>>> static class StaticGeneric<T> - names: value, string
>>>>> static class StaticGeneric<T> - parameters: [class java.lang.Object, class
>>>>> java.lang.String]
>>>>> static class StaticGeneric<T> - generic parameters: [T, class java.lang.String]
>>>>>
>>>>> class NonStaticGeneric<T> - names: this$0, value, String
>>>>> class NonStaticGeneric<T> - parameters: [class Sample, class java.lang.Object,
>>>>> class java.lang.String]
>>>>> class NonStaticGeneric<T> - generic parameters: [T, class java.lang.String]
>>>>>
>>>>> class NonStaticNonGeneric - names: this$0, String
>>>>> class NonStaticNonGeneric - parameters: [class Sample, class java.lang.String]
>>>>> class NonStaticNonGeneric - generic parameters: [class Sample, class
>>>>> java.lang.String]
>>>>>
>>>>> Note how the constructor of the NonStaticGeneric<T> type exposes three parameter
>>>>> names, three parameter types but omits the enclosing class parameter in the
>>>>> list of generic parameter types.
>>>>>
>>>>> Tested on JDK 8 to 15. Same behavior.
>>>>>
>>>>> Cheers,
>>>>> Ollie
>>>>>
>>>>>
>>>>> class Sample {
>>>>>
>>>>> 	public static void main(String[] args) {
>>>>>
>>>>> 		Constructor<?> first = StaticGeneric.class.getDeclaredConstructors()[0];
>>>>>
>>>>> 		System.out.println("static class StaticGeneric<T> - names: "
>>>>> 				+
>>>>> 				Arrays.stream(first.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
>>>>> 				")));
>>>>> 		System.out.println("static class StaticGeneric<T> - parameters: " +
>>>>> 		Arrays.toString(first.getParameterTypes()));
>>>>> 		System.out.println(
>>>>> 				"static class StaticGeneric<T> - generic parameters: " +
>>>>> 				Arrays.toString(first.getGenericParameterTypes()));
>>>>>
>>>>> 		System.out.println();
>>>>>
>>>>> 		Constructor<?> second = NonStaticGeneric.class.getDeclaredConstructors()[0];
>>>>> 		System.out.println("class NonStaticGeneric<T> - names: "
>>>>> 				+
>>>>> 				Arrays.stream(second.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
>>>>> 				")));
>>>>> 		System.out.println("class NonStaticGeneric<T> - parameters: " +
>>>>> 		Arrays.toString(second.getParameterTypes()));
>>>>> 		System.out
>>>>> 				.println(
>>>>> 						"class NonStaticGeneric<T> - generic parameters: " +
>>>>> 						Arrays.toString(second.getGenericParameterTypes()));
>>>>>
>>>>> 		System.out.println();
>>>>>
>>>>> 		Constructor<?> third = NonStaticNonGeneric.class.getDeclaredConstructors()[0];
>>>>> 		System.out.println("class NonStaticNonGeneric - names: "
>>>>> 				+
>>>>> 				Arrays.stream(third.getParameters()).map(Parameter::getName).collect(Collectors.joining(",
>>>>> 				")));
>>>>> 		System.out.println("class NonStaticNonGeneric - parameters: " +
>>>>> 		Arrays.toString(third.getParameterTypes()));
>>>>> 		System.out
>>>>> 				.println(
>>>>> 						"class NonStaticNonGeneric - generic parameters: " +
>>>>> 						Arrays.toString(third.getGenericParameterTypes()));
>>>>> 	}
>>>>>
>>>>> 	static class StaticGeneric<T> {
>>>>> 		StaticGeneric(T value, String string) {}
>>>>> 	}
>>>>>
>>>>> 	class NonStaticGeneric<T> {
>>>>> 		NonStaticGeneric(T value, String String) {}
>>>>> 	}
>>>>>
>>>>> 	class NonStaticNonGeneric {
>>>>> 		NonStaticNonGeneric(String String) {}
>>>>> 	}
>>>>> }

From almatvee at openjdk.java.net  Tue Mar  2 02:38:49 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 2 Mar 2021 02:38:49 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path
In-Reply-To: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
Message-ID: <cNk5qbEoBmh6VMXMh7Jnx4AcSbf1m8xI1YUhrre2PdQ=.4a6351e0-3b85-482b-a99f-7f0ed38709d9@github.com>

On Mon, 1 Mar 2021 15:55:39 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory.

Marked as reviewed by almatvee (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2781

From joehw at openjdk.java.net  Tue Mar  2 03:29:41 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 2 Mar 2021 03:29:41 GMT
Subject: RFR: 8261670: Add javadoc for the XML processing limits [v4]
In-Reply-To: <jace5uSJpB7jnJ3mUtHyTNiX3p2PbGn6PGKMLhOlFWw=.d861af74-d710-4fed-8684-5185892ef678@github.com>
References: <sd4qXAu9tsJfGmd_oBO97xX2iBIhJo0dhjN5jtDtn9U=.ad657cdd-2dcc-4136-84f0-4548ee0e1d89@github.com>
 <74lnD7a53htCRm3kTiG3PhjcWGexuRcqzww6c8r-Ppw=.e387e076-025f-4b73-99dd-49f73f488b31@github.com>
 <jace5uSJpB7jnJ3mUtHyTNiX3p2PbGn6PGKMLhOlFWw=.d861af74-d710-4fed-8684-5185892ef678@github.com>
Message-ID: <jzykF73ZqNcfbulDIXiePHRD7sjkBF5jE6dqHtAh3CM=.6678e765-a69c-47a3-b330-c48ba131c6e0@github.com>

On Tue, 2 Mar 2021 00:19:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change the description of the property table to indicate that the list of the properties is not exhaustive
>
> Marked as reviewed by naoto (Reviewer).

Thanks all for the review.

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

PR: https://git.openjdk.java.net/jdk/pull/2732

From joehw at openjdk.java.net  Tue Mar  2 03:29:42 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 2 Mar 2021 03:29:42 GMT
Subject: Integrated: 8261670: Add javadoc for the XML processing limits
In-Reply-To: <sd4qXAu9tsJfGmd_oBO97xX2iBIhJo0dhjN5jtDtn9U=.ad657cdd-2dcc-4136-84f0-4548ee0e1d89@github.com>
References: <sd4qXAu9tsJfGmd_oBO97xX2iBIhJo0dhjN5jtDtn9U=.ad657cdd-2dcc-4136-84f0-4548ee0e1d89@github.com>
Message-ID: <aMMxvPGBWIwfWHQ_Va_hg6rKIuj8czkVCr0w0-4rGec=.5182a7f3-4fc9-4b1c-bcec-6814269f9423@github.com>

On Thu, 25 Feb 2021 22:04:41 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Add the documentation for XML processing limits to module summary. The limits were previously documented in Java tutorial and guide.

This pull request has now been integrated.

Changeset: 6635d7a5
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6635d7a5
Stats:     92 lines in 1 file changed: 83 ins; 0 del; 9 mod

8261670: Add javadoc for the XML processing limits

Reviewed-by: lancea, naoto, iris

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

PR: https://git.openjdk.java.net/jdk/pull/2732

From smarks at openjdk.java.net  Tue Mar  2 06:03:07 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 2 Mar 2021 06:03:07 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v3]
In-Reply-To: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
Message-ID: <xsGgROI5-N80WQug65AQx3Y3Dj5CcYSF_xwRnG3JX2Y=.9f0cc7b5-706d-4c2e-a952-d915df58d49c@github.com>

> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code:
> 
> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs!
> 
> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length.
> 
> Separately, I'll work on retrofitting various call sites around the JDK to use this method.

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

  Update with recommendations from Martin Buchholz.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1617/files
  - new: https://git.openjdk.java.net/jdk/pull/1617/files/bacb5f91..6710004c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1617&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1617&range=01-02

  Stats: 12 lines in 2 files changed: 1 ins; 4 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1617.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1617/head:pull/1617

PR: https://git.openjdk.java.net/jdk/pull/1617

From smarks at openjdk.java.net  Tue Mar  2 06:08:03 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 2 Mar 2021 06:08:03 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v4]
In-Reply-To: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
Message-ID: <U9lnfkpthvGay0doDbTkPxSceqQsKXoYW3fFGN7u9TQ=.1a86335f-0b27-4c01-8656-bc4dced582d2@github.com>

> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code:
> 
> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs!
> 
> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length.
> 
> Separately, I'll work on retrofitting various call sites around the JDK to use this method.

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

  Add newline at end of file.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1617/files
  - new: https://git.openjdk.java.net/jdk/pull/1617/files/6710004c..c520e8e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1617&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1617&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/1617

From smarks at openjdk.java.net  Tue Mar  2 06:29:07 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 2 Mar 2021 06:29:07 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v5]
In-Reply-To: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
Message-ID: <XtFTqL8gIc5KE9PlJAg8ebG4C9pFah8VqYNAJ6z58Ig=.701d54b4-10d2-4b05-9caa-bad73c637c23@github.com>

> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code:
> 
> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs!
> 
> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length.
> 
> Separately, I'll work on retrofitting various call sites around the JDK to use this method.

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

  Update copyright year.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1617/files
  - new: https://git.openjdk.java.net/jdk/pull/1617/files/c520e8e8..8892eb47

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1617&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1617&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/1617

From akozlov at openjdk.java.net  Tue Mar  2 07:48:33 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 07:48:33 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v22]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <v5pZx2-cL7w14ww7AUj0-aM3H0WLtdE9KQOMcmz3oXM=.de608aec-285e-420c-a0bd-87ff2621366a@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

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

  Update comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/663cb4a1..e42b82db

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=21
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=20-21

  Stats: 4 lines in 2 files changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Tue Mar  2 07:48:34 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 07:48:34 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <cJ0oJULLMQqSzHz-xHWMiJrivyH59QxUI2UQTN0PrdE=.77b688e8-52f1-4207-be64-3393922ecdb6@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <MlC0k95KyLxJCu7ZSluQlSdVrGTPolMjYG_rX3lpebU=.9ccf1fac-6fec-4479-80d7-9ee89d3bbb54@github.com>
 <x0F1vjGptkr-cbJzQ-3bS5zX7mFSgxIEDAjn6DxTfW4=.732c6cb4-7044-4561-821c-6ca63f9768a7@github.com>
 <cJ0oJULLMQqSzHz-xHWMiJrivyH59QxUI2UQTN0PrdE=.77b688e8-52f1-4207-be64-3393922ecdb6@github.com>
Message-ID: <M-kUXnyeRkWZF8-CcGTlKqCGerC7BpZ4KUFKbPEm9Dw=.0692eac6-4803-4110-b46b-0658cd0b10cd@github.com>

On Mon, 1 Mar 2021 10:46:34 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> They are defined in 13.2.95. MIDR_EL1, Main ID Register. Apple's code is not there, but "Arm can assign codes that are not published in this manual. All values not assigned by Arm are reserved and must not be used.". I assume the value was obtained by digging around https://github.com/apple/darwin-xnu/blob/main/osfmk/arm/cpuid.h#L62
>
> Anton, this paragraph looks like an excellent comment.

Thanks, I've added the comment.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Tue Mar  2 07:48:36 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 07:48:36 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <MF1iA9imUPiz__P2Xgl06D6uqX6m3yi5_LkRtVy0yYA=.985a8d8e-d585-4ca1-8c27-3752dc4f297a@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <MF1iA9imUPiz__P2Xgl06D6uqX6m3yi5_LkRtVy0yYA=.985a8d8e-d585-4ca1-8c27-3752dc4f297a@github.com>
Message-ID: <NMDh28nN07b-L4FvOo_lZSVr6WTbMjQtwXB4uOpbRgU=.e025620b-bb0e-4f81-aea4-7c023a268161@github.com>

On Mon, 15 Feb 2021 17:59:54 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 810:
>> 
>>> 808: #ifdef __APPLE__
>>> 809:           // Less-than word types are stored one after another.
>>> 810:           // The code unable to handle this, bailout.
>> 
>> Perhaps:  // The code is unable to handle this so bailout.
>
> Hello, we have updated PR, now this bailout is used only by the code which can handle it (native wrapper generator), for the rest it will cause guarantee failed if this bailout is triggered

I've fixed the spelling. Sorry for it to take so long :(

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 195:
>> 
>>> 193: frame os::get_sender_for_C_frame(frame* fr) {
>>> 194:   return frame(fr->link(), fr->link(), fr->sender_pc());
>>> 195: }
>> 
>> Is this file going to be built by GCC or just macOS compilers?
>
> there is no support for compiling java with gcc on macos since about jdk11, only clang.
> considering this and the absence of gcc for macos_m1, the answer is - just macOS compilers.

I've fixed the comment. Now it states `JVM compiled with -fno-omit-frame-pointer, so RFP is saved on the stack.`

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Tue Mar  2 08:06:49 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 08:06:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <gYlruHfPt3n_2sFsFzadoB-H9J1sZJQsspB9AjKeO2o=.ca9e5f03-7181-42cb-b2d9-4f3490f05235@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WI3MFWpvxNdYp4WRkhkagyWSmnIIAfvYWl3nS8AW_Y0=.b09073dd-cec3-4dbd-88c4-974d46b01737@github.com>
 <gYlruHfPt3n_2sFsFzadoB-H9J1sZJQsspB9AjKeO2o=.ca9e5f03-7181-42cb-b2d9-4f3490f05235@github.com>
Message-ID: <UNXam2gyH9Z3bgNClVHc956LquoEu1KkZ-89DQpu4ZE=.5a71445d-0dbd-4ae9-8fe8-0e279cb7fc61@github.com>

On Fri, 12 Feb 2021 12:40:09 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

>> only macos comiplers
>
> The comment is also wrong for glibc: The AArch64 ABI requires a 64 KiB guard region independently of page size, otherwise `-fstack-clash-protection` is not reliable.

Thanks, I deleted the comment. It describes implementation distinguishing initial and regular thread http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/548cb3b7b713#l12.7. I'm not sure why the comment was preserved for the bsd_x86, but I don't think it makes sense here.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Tue Mar  2 08:14:46 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 08:14:46 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <Ymv3QSLaT5H6CuKXfwuUkep_PKnO3Zj54kSQA0jcc6s=.59dc4d6d-a8d0-4016-8a59-a4d6cb8b57ac@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <Ymv3QSLaT5H6CuKXfwuUkep_PKnO3Zj54kSQA0jcc6s=.59dc4d6d-a8d0-4016-8a59-a4d6cb8b57ac@github.com>
Message-ID: <Ei8n5Xqt_Usrtyz-M4AudO6fuOV30FTSG6BCpNXUa2w=.fe6928be-256e-4448-b094-1f7c869e4b26@github.com>

On Fri, 12 Feb 2021 13:32:52 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 486:
>> 
>>> 484:         }
>>> 485:       }
>>> 486:     }
>> 
>> This appears to be a mix for Mavericks (10.9) and 10.12
>> work arounds. Is this code needed by this project?
>
> I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these workaround
> @gerard-ziemski, 8020753 was originally your fix, do you know if it still needed on intel-mac ?

The x86_bsd still carries the workaround https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L745. It's worth having macos ports to be aligned by features. I would propose to have this workaround for now, and decide on it later for macos/x86 and macos/aarch64 at once. Sorry for chiming in so late.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Tue Mar  2 09:02:10 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 09:02:10 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
Message-ID: <u7KDYpBsS8hE4DIlr86x1XP2jNk2evuzajQr66XXjYI=.e7caf1a7-c841-43aa-95dc-e8b96df309da@github.com>

On Tue, 2 Feb 2021 22:18:43 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   support macos_aarch64 in hsdis
>
> src/hotspot/os_cpu/bsd_aarch64/thread_bsd_aarch64.cpp line 43:
> 
>> 41:   assert(Thread::current() == this, "caller must be current thread");
>> 42:   return pd_get_top_frame(fr_addr, ucontext, isInJava);
>> 43: }
> 
> Is AsyncGetCallTrace() being supported by this port?

I assume answer to be yes (I have a little experience with AsyncGetCallTrace). This code is identical to one in bsd/x86 and linux/aarch64. After few changes in the build system, I got jtreg/serviceability/AsyncGetCallTrace test compiled and passed. I've filed JDK-8262839 to enable the test.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Tue Mar  2 09:36:51 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 09:36:51 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
Message-ID: <0dfmwagb4EGbnQnZIzpQ_36c9_fpvvebrgnKDW4E9Ps=.e54e9fb2-7500-40d8-8202-ce4903fd106f@github.com>

On Tue, 2 Feb 2021 22:47:04 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   support macos_aarch64 in hsdis
>
> src/hotspot/share/prims/nativeEntryPoint.cpp line 45:
> 
>> 43:   guarantee(status == JNI_OK && !env->ExceptionOccurred(),
>> 44:             "register jdk.internal.invoke.NativeEntryPoint natives");
>> 45: JNI_END
> 
> I thought that jcheck caught a missing new-line?

It seems it did not https://github.com/openjdk/jdk/commit/0fb31dbf3a2adc0f7fb2f9924083908724dcde5a#diff-f39cd3f794a337734adf30863f702725ee04182fee2345b2669e59ebed17a2ccR44. Anyway I reverted this change as it is the only change in the file, thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Tue Mar  2 11:07:56 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 11:07:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
Message-ID: <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>

On Tue, 2 Feb 2021 23:10:17 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> For platform files that were copied from other ports to this port, if the file wasn't
> changed I presume the copyright years are left alone. If the file required changes
> for this port, I expect the year to be updated to 2021. How are you verifying that
> these copyright years are being properly managed on the new files?

There are no exact copies, based on
git -c diff.renameLimit=10000000 diff --find-copies-harder -C75% --name-status upstream/master...

So every file changed in the branch potentially needs the copyright update. All file diffs are not trivial, IMHO.

I'll run the copyright update after we fix a few remaining issues with the PR, to avoid updating copyright and changing/reverting the actual content.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From attila at openjdk.java.net  Tue Mar  2 12:29:40 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Tue, 2 Mar 2021 12:29:40 GMT
Subject: RFR: 8261483:
 jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with
 "AssertionError: Should have GCd a method handle by now" [v4]
In-Reply-To: <9ZO04vLHMT6rNlyuOHN7_5mLqrnsMo3glPHG05q1DJE=.cc962321-f440-4f9d-9d28-5c2232423d41@github.com>
References: <slYYgswHIpdKuQw8Cn9CfDqBT-0v5MpntG7y1V8z7Fw=.5c82def9-9fc0-4914-8a05-082cb9e8fad2@github.com>
 <IYVGcWafddwlmxXZe3z4whGghDmB2pQ3okDeuNVOsmg=.5c7d4f07-db9b-4fe1-8566-fb587005ae5b@github.com>
 <9ZO04vLHMT6rNlyuOHN7_5mLqrnsMo3glPHG05q1DJE=.cc962321-f440-4f9d-9d28-5c2232423d41@github.com>
Message-ID: <-iDrl0_6BrphckBdrnjMAoUll698vULUFTLRJh8XJ0E=.0faa2eaa-c2de-4552-9db4-19a5cc16acaf@github.com>

On Mon, 1 Mar 2021 11:09:31 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Attila Szegedi has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
>> 
>>   8261483: Eliminate flakiness of the tests by using iteration number limit and explicitly running GC
>
> I think this looks good to go, Attila.

Thank you both @plevart and @shipilev for the help and suggestions!

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

PR: https://git.openjdk.java.net/jdk/pull/2617

From attila at openjdk.java.net  Tue Mar  2 12:29:41 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Tue, 2 Mar 2021 12:29:41 GMT
Subject: Integrated: 8261483:
 jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with
 "AssertionError: Should have GCd a method handle by now"
In-Reply-To: <slYYgswHIpdKuQw8Cn9CfDqBT-0v5MpntG7y1V8z7Fw=.5c82def9-9fc0-4914-8a05-082cb9e8fad2@github.com>
References: <slYYgswHIpdKuQw8Cn9CfDqBT-0v5MpntG7y1V8z7Fw=.5c82def9-9fc0-4914-8a05-082cb9e8fad2@github.com>
Message-ID: <4s17VKkI0XWlGlpTGyJSsr2gz-m9VtD17DUkfljQ7Vk=.f5d9f837-a186-4a45-808e-916ad0ecf1bb@github.com>

On Wed, 17 Feb 2021 19:44:35 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> 8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now"

This pull request has now been integrated.

Changeset: d185a6c5
Author:    Attila Szegedi <attila at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d185a6c5
Stats:     94 lines in 3 files changed: 71 ins; 10 del; 13 mod

8261483: jdk/dynalink/TypeConverterFactoryMemoryLeakTest.java failed with "AssertionError: Should have GCd a method handle by now"

Reviewed-by: shade, plevart

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

PR: https://git.openjdk.java.net/jdk/pull/2617

From jlaskey at openjdk.java.net  Tue Mar  2 13:19:13 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 2 Mar 2021 13:19:13 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v27]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <cXCjmeBFQfapjbPXQMqQTGc19imZnr-DpTWEE6Qt2ng=.286fb050-af9b-49c5-912b-8841c97a16a0@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Introduce isDeprecated

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/99e92dd1..7439c2ba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=26
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=25-26

  Stats: 25 lines in 1 file changed: 23 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

PR: https://git.openjdk.java.net/jdk/pull/1292

From akozlov at openjdk.java.net  Tue Mar  2 14:34:51 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 14:34:51 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <hEaFWHE_iOfvoT79PO1tsOkG0IVniyDakQlyH3_t70s=.a0083425-ef18-413b-be61-bfaa1eea8452@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <hEaFWHE_iOfvoT79PO1tsOkG0IVniyDakQlyH3_t70s=.a0083425-ef18-413b-be61-bfaa1eea8452@github.com>
Message-ID: <YYxKFpSFJVHj9FIQNUngREmO7aBwrmRWXrx5XIfeiEE=.b59b60c7-435b-4884-9f06-1c3b7c868d84@github.com>

On Thu, 4 Feb 2021 22:15:47 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Add comments to WX transitions
>>    
>>    + minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 322:
> 
>> 320: #ifdef __APPLE__
>> 321:       } else if (sig == SIGFPE && info->si_code == FPE_NOOP) {
>> 322:         Unimplemented();
> 
> Is there a follow up issue for this?

Thanks, this is a leftover from the development phase, it will be removed. In macos/x86, this looks like a workaround. We've never met with this condition and it looks recent darwin kernel should correctly report the cause in si_code: https://github.com/apple/darwin-xnu/blob/33eb9835cd948dbbcdd8741aa52457cbe507c765/bsd/dev/arm/unix_signal.c#L436.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From rriggs at openjdk.java.net  Tue Mar  2 14:53:41 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 2 Mar 2021 14:53:41 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v5]
In-Reply-To: <XtFTqL8gIc5KE9PlJAg8ebG4C9pFah8VqYNAJ6z58Ig=.701d54b4-10d2-4b05-9caa-bad73c637c23@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
 <XtFTqL8gIc5KE9PlJAg8ebG4C9pFah8VqYNAJ6z58Ig=.701d54b4-10d2-4b05-9caa-bad73c637c23@github.com>
Message-ID: <2liWrjmDoDyJfSto2qKiRtEWUL6yr18MmVqAg5hC4YY=.9dadc7ce-468d-49cc-be60-25987a683b62@github.com>

On Tue, 2 Mar 2021 06:29:07 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code:
>> 
>> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs!
>> 
>> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length.
>> 
>> Separately, I'll work on retrofitting various call sites around the JDK to use this method.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1617

From prappo at openjdk.java.net  Tue Mar  2 15:52:40 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 2 Mar 2021 15:52:40 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v5]
In-Reply-To: <XtFTqL8gIc5KE9PlJAg8ebG4C9pFah8VqYNAJ6z58Ig=.701d54b4-10d2-4b05-9caa-bad73c637c23@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
 <XtFTqL8gIc5KE9PlJAg8ebG4C9pFah8VqYNAJ6z58Ig=.701d54b4-10d2-4b05-9caa-bad73c637c23@github.com>
Message-ID: <95Ftj5VP86TBOjqROCftNhumk8KoF1AzjZ5mTNgOEEY=.74ae6a40-31a7-4e23-8412-ef1487d15109@github.com>

On Tue, 2 Mar 2021 06:29:07 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code:
>> 
>> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs!
>> 
>> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length.
>> 
>> Separately, I'll work on retrofitting various call sites around the JDK to use this method.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright year.

Overall this looks good.

src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 579:

> 577:     /**
> 578:      * A soft maximum array length imposed by array growth computations.
> 579:      * Some JVMs (such as Hotspot) have an implementation limit that will cause

The numbers of spellings "HotSpot" to that of "Hotspot" in the JDK codebase is 10 to 1 respectively. Also, on my machine I can see this:

$ java --version
java 15 2020-09-15
Java(TM) SE Runtime Environment (build 15+36-1562)
Java HotSpot(TM) 64-Bit Server VM (build 15+36-1562, mixed mode, sharing)

test/jdk/jdk/internal/util/ArraysSupport/NewLength.java line 100:

> 98:             int r = ArraysSupport.newLength(old, min, pref);
> 99:             fail("expected OutOfMemoryError, got normal return value of " + r);
> 100:         } catch (OutOfMemoryError success) { }

Consider using `expectThrows` or `assertThrows` from `org.testng.Assert`.

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

Marked as reviewed by prappo (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1617

From psandoz at openjdk.java.net  Tue Mar  2 17:20:54 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 2 Mar 2021 17:20:54 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v7]
In-Reply-To: <A-WnLlIGApD007vIaJ80HU-Pv-EGLxnteB-uVgJuzhc=.269e29a4-329b-4d41-9136-5dcffc97e6dd@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <A-WnLlIGApD007vIaJ80HU-Pv-EGLxnteB-uVgJuzhc=.269e29a4-329b-4d41-9136-5dcffc97e6dd@github.com>
Message-ID: <iRcr-DqLemEMG4Z8nkZ8DbTfeeS3t0tkh1RhlKHAI3M=.9c51b0cb-e7e9-429d-96d2-1ff52445dc55@github.com>

On Tue, 2 Mar 2021 02:11:08 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Hi all,
>> 
>> Vector API fails to work when:
>>  - case 1: MaxVectorSize is set to <=8, or
>>  - case 2: C2 is disabled
>> 
>> The reason is that {max/preferred} VectorShape initialization fails in both cases.
>> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).
>> 
>> Vector API should not depend on C2 to run.
>> It should work even there is no JIT compiler since it's a Java-level api.
>> So let's fix it.
>> 
>> Testing:
>>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364
>
> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add VectorShape.getMaxVectorBitSize

Marked as reviewed by psandoz (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From psandoz at openjdk.java.net  Tue Mar  2 17:20:54 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 2 Mar 2021 17:20:54 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception
In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
Message-ID: <ryTp-223TiOUG4y5lWCE-riLh5KhIvW5MOOsP4M1HHY=.b5e2ab2e-abc7-4bbb-a20d-bc4341453682@github.com>

On Thu, 25 Feb 2021 09:31:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Vector API fails to work when:
>  - case 1: MaxVectorSize is set to <=8, or
>  - case 2: C2 is disabled
> 
> The reason is that {max/preferred} VectorShape initialization fails in both cases.
> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).
> 
> Vector API should not depend on C2 to run.
> It should work even there is no JIT compiler since it's a Java-level api.
> So let's fix it.
> 
> Testing:
>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

@DamonFool that worked out better than i expected :-)

One last thing i missed last time. The `PreferredSpeciesTest` also needs to be executed with no HotSpot flags. No need for another round of review.

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From smarks at openjdk.java.net  Tue Mar  2 18:11:11 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 2 Mar 2021 18:11:11 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v6]
In-Reply-To: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
Message-ID: <VhaJJk_9vcvqL1DaUcsNDR2G9i2YqjVhm8T3UcvcWdc=.6317fa92-f759-483c-89f1-a0a5d1ce4e92@github.com>

> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code:
> 
> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs!
> 
> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length.
> 
> Separately, I'll work on retrofitting various call sites around the JDK to use this method.

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

  Fix spelling of HotSpot

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1617/files
  - new: https://git.openjdk.java.net/jdk/pull/1617/files/8892eb47..68318d46

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1617&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1617&range=04-05

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

PR: https://git.openjdk.java.net/jdk/pull/1617

From smarks at openjdk.java.net  Tue Mar  2 18:11:13 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 2 Mar 2021 18:11:13 GMT
Subject: RFR: 8247373: ArraysSupport.newLength doc, test,
 and exception message [v5]
In-Reply-To: <95Ftj5VP86TBOjqROCftNhumk8KoF1AzjZ5mTNgOEEY=.74ae6a40-31a7-4e23-8412-ef1487d15109@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
 <XtFTqL8gIc5KE9PlJAg8ebG4C9pFah8VqYNAJ6z58Ig=.701d54b4-10d2-4b05-9caa-bad73c637c23@github.com>
 <95Ftj5VP86TBOjqROCftNhumk8KoF1AzjZ5mTNgOEEY=.74ae6a40-31a7-4e23-8412-ef1487d15109@github.com>
Message-ID: <3FceBcNCgvvX-OtjUilCudtV6bhkxc5MNfSUmcwIpeE=.b9849110-ed3d-4824-931c-f14bb7b4741a@github.com>

On Tue, 2 Mar 2021 15:05:51 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update copyright year.
>
> src/java.base/share/classes/jdk/internal/util/ArraysSupport.java line 579:
> 
>> 577:     /**
>> 578:      * A soft maximum array length imposed by array growth computations.
>> 579:      * Some JVMs (such as Hotspot) have an implementation limit that will cause
> 
> The numbers of spellings "HotSpot" to that of "Hotspot" in the JDK codebase is 10 to 1 respectively. Also, on my machine I can see this:
> 
> $ java --version
> java 15 2020-09-15
> Java(TM) SE Runtime Environment (build 15+36-1562)
> Java HotSpot(TM) 64-Bit Server VM (build 15+36-1562, mixed mode, sharing)

Fixed.

> test/jdk/jdk/internal/util/ArraysSupport/NewLength.java line 100:
> 
>> 98:             int r = ArraysSupport.newLength(old, min, pref);
>> 99:             fail("expected OutOfMemoryError, got normal return value of " + r);
>> 100:         } catch (OutOfMemoryError success) { }
> 
> Consider using `expectThrows` or `assertThrows` from `org.testng.Assert`.

Good point. However, I actually tried to use assertThrows, but there doesn't seem to be a way to get the unexpected return value into the error message. I think having this value in the test output is important for diagnosing failures.

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

PR: https://git.openjdk.java.net/jdk/pull/1617

From smarks at openjdk.java.net  Tue Mar  2 18:11:15 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 2 Mar 2021 18:11:15 GMT
Subject: Integrated: 8247373: ArraysSupport.newLength doc, test,
 and exception message
In-Reply-To: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
References: <D9oU9mGK5su1atHT64_Hf8f3ZRF2rN1E8pueDRYlOHA=.067ec1c2-4fb9-4b06-82e5-e3243d2e065f@github.com>
Message-ID: <FrAoSBspJbmlmUnXOx8jg4XC8ugWTYPg_pQYEe25sZQ=.57e6dce6-84f0-4708-9306-64caa7274b00@github.com>

On Fri, 4 Dec 2020 06:50:14 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This rewrites the doc of ArraysSupport.newLength, adds detail to the exception message, and adds a test. In addition to some renaming and a bit of refactoring of the actual code, I also made two changes of substance to the code:
> 
> 1. I fixed a problem with overflow checking. In the original code, if oldLength and prefGrowth were both very large (say, Integer.MAX_VALUE), this method could return a negative value. It turns out that writing tests helps find bugs!
> 
> 2. Under the old policy, if oldLength and minGrowth required a length above SOFT_MAX_ARRAY_LENGTH but not above Integer.MAX_VALUE, this method would return Integer.MAX_VALUE. That doesn't make any sense, because attempting to allocate an array of that length will almost certainly cause the Hotspot to throw OOME because its implementation limit was exceeded. Instead, if the required length is in this range, this method returns that required length.
> 
> Separately, I'll work on retrofitting various call sites around the JDK to use this method.

This pull request has now been integrated.

Changeset: f18c0192
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f18c0192
Stats:     171 lines in 4 files changed: 135 ins; 2 del; 34 mod

8247373: ArraysSupport.newLength doc, test, and exception message

Reviewed-by: rriggs, psandoz, martin, prappo

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

PR: https://git.openjdk.java.net/jdk/pull/1617

From jjg at openjdk.java.net  Tue Mar  2 19:41:03 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 2 Mar 2021 19:41:03 GMT
Subject: RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base module
Message-ID: <GOUQ3xpHuNHaPXeRPE1riUsHp7-pE-qmf8rSIU8SPLQ=.1cef31d5-18cc-498f-8f28-b57aafb2cbbf@github.com>

Please review some minor doc fixes, for issues found by _doccheck_.    There are two kinds of errors that are addressed.

1. Incorrect use of `<p>`. In HTML, `<p>` marks the *beginning* of a paragraph. It is not a terminator, to mark the end of a paragraph, or a separator to mark the boundary between paragraphs.  In particular, it should not be used at the end of a description before a javadoc block tag, such as `@param` or before other HTML block tags, like `<ul>` or `<table>`.

2. References to the id `package-description`, following the recent standardization of all ids generated by javadoc,

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

Commit messages:
 - JDK-8262875: doccheck: empty paragraphs, etc in java.base module

Changes: https://git.openjdk.java.net/jdk/pull/2795/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2795&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262875
  Stats: 9 lines in 8 files changed: 0 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2795/head:pull/2795

PR: https://git.openjdk.java.net/jdk/pull/2795

From alanb at openjdk.java.net  Tue Mar  2 19:46:41 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 2 Mar 2021 19:46:41 GMT
Subject: RFR: JDK-8262875: doccheck: empty paragraphs,
 etc in java.base module
In-Reply-To: <GOUQ3xpHuNHaPXeRPE1riUsHp7-pE-qmf8rSIU8SPLQ=.1cef31d5-18cc-498f-8f28-b57aafb2cbbf@github.com>
References: <GOUQ3xpHuNHaPXeRPE1riUsHp7-pE-qmf8rSIU8SPLQ=.1cef31d5-18cc-498f-8f28-b57aafb2cbbf@github.com>
Message-ID: <L5dSFTyD-8GzcZ7wZ6tzEg168cjjoDiN6K7FhiapGzk=.167fe461-ec48-4b09-8a9b-6a8a74894a7f@github.com>

On Tue, 2 Mar 2021 19:35:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some minor doc fixes, for issues found by _doccheck_.    There are two kinds of errors that are addressed.
> 
> 1. Incorrect use of `<p>`. In HTML, `<p>` marks the *beginning* of a paragraph. It is not a terminator, to mark the end of a paragraph, or a separator to mark the boundary between paragraphs.  In particular, it should not be used at the end of a description before a javadoc block tag, such as `@param` or before other HTML block tags, like `<ul>` or `<table>`.
> 
> 2. References to the id `package-description`, following the recent standardization of all ids generated by javadoc,

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2795

From herrick at openjdk.java.net  Tue Mar  2 19:47:04 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 2 Mar 2021 19:47:04 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path [v2]
In-Reply-To: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
Message-ID: <m72-a53qYGt1PDIpuVy_IL-pFPh8QYlFhBFY9XWdnlE=.b4bcefc9-cec4-4fc3-ad05-45c5a2bcea13@github.com>

> when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory.

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8261518: jpackage looks for main module in current dir when there is no module-path

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2781/files
  - new: https://git.openjdk.java.net/jdk/pull/2781/files/c09775d9..f800c99f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2781&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2781&range=00-01

  Stats: 160 lines in 1 file changed: 160 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2781.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2781/head:pull/2781

PR: https://git.openjdk.java.net/jdk/pull/2781

From darcy at openjdk.java.net  Tue Mar  2 19:57:53 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 2 Mar 2021 19:57:53 GMT
Subject: RFR: JDK-8262875: doccheck: empty paragraphs,
 etc in java.base module
In-Reply-To: <GOUQ3xpHuNHaPXeRPE1riUsHp7-pE-qmf8rSIU8SPLQ=.1cef31d5-18cc-498f-8f28-b57aafb2cbbf@github.com>
References: <GOUQ3xpHuNHaPXeRPE1riUsHp7-pE-qmf8rSIU8SPLQ=.1cef31d5-18cc-498f-8f28-b57aafb2cbbf@github.com>
Message-ID: <xDNS6dOEfWP7lcr-ilTQoxdIEVYW-qFkG3TuZRUuCJ8=.64007be3-7960-42da-80d3-9c57108d7a44@github.com>

On Tue, 2 Mar 2021 19:35:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some minor doc fixes, for issues found by _doccheck_.    There are two kinds of errors that are addressed.
> 
> 1. Incorrect use of `<p>`. In HTML, `<p>` marks the *beginning* of a paragraph. It is not a terminator, to mark the end of a paragraph, or a separator to mark the boundary between paragraphs.  In particular, it should not be used at the end of a description before a javadoc block tag, such as `@param` or before other HTML block tags, like `<ul>` or `<table>`.
> 
> 2. References to the id `package-description`, following the recent standardization of all ids generated by javadoc,

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2795

From lancea at openjdk.java.net  Tue Mar  2 20:02:40 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 2 Mar 2021 20:02:40 GMT
Subject: RFR: JDK-8262875: doccheck: empty paragraphs,
 etc in java.base module
In-Reply-To: <GOUQ3xpHuNHaPXeRPE1riUsHp7-pE-qmf8rSIU8SPLQ=.1cef31d5-18cc-498f-8f28-b57aafb2cbbf@github.com>
References: <GOUQ3xpHuNHaPXeRPE1riUsHp7-pE-qmf8rSIU8SPLQ=.1cef31d5-18cc-498f-8f28-b57aafb2cbbf@github.com>
Message-ID: <tLMl1BoU6adUBftTcpJMFCTmHdhNx3ALoItsjSwznO8=.bdc67765-c526-4f22-9f82-1608c5ff4220@github.com>

On Tue, 2 Mar 2021 19:35:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some minor doc fixes, for issues found by _doccheck_.    There are two kinds of errors that are addressed.
> 
> 1. Incorrect use of `<p>`. In HTML, `<p>` marks the *beginning* of a paragraph. It is not a terminator, to mark the end of a paragraph, or a separator to mark the boundary between paragraphs.  In particular, it should not be used at the end of a description before a javadoc block tag, such as `@param` or before other HTML block tags, like `<ul>` or `<table>`.
> 
> 2. References to the id `package-description`, following the recent standardization of all ids generated by javadoc,

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2795

From ecki at zusammenkunft.net  Tue Mar  2 20:04:06 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Tue, 2 Mar 2021 20:04:06 +0000
Subject: RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base
 module
In-Reply-To: <GOUQ3xpHuNHaPXeRPE1riUsHp7-pE-qmf8rSIU8SPLQ=.1cef31d5-18cc-498f-8f28-b57aafb2cbbf@github.com>
References: <GOUQ3xpHuNHaPXeRPE1riUsHp7-pE-qmf8rSIU8SPLQ=.1cef31d5-18cc-498f-8f28-b57aafb2cbbf@github.com>
Message-ID: <AM0PR03MB4145D8814F28F0DFA9CCFF78FF999@AM0PR03MB4145.eurprd03.prod.outlook.com>

Hello,

Actually, in HTML <p> was a separator, and in xhtml it should enclose paragraphs. However I was under the impression Javadoc always used the separator style (it would be strange to start the first sentence in Javadoc with <p>. Is this doccheck enforcing a new policy?

This officially Oracle guide for example has a different example:

https://www.oracle.com/de/technical-resources/articles/java/javadoc-tool.html#format

Gruss
Bernd


--
http://bernd.eckenfels.net
________________________________
Von: net-dev <net-dev-retn at openjdk.java.net> im Auftrag von Jonathan Gibbons <jjg at openjdk.java.net>
Gesendet: Tuesday, March 2, 2021 8:41:03 PM
An: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; hotspot-compiler-dev at openjdk.java.net <hotspot-compiler-dev at openjdk.java.net>; net-dev at openjdk.java.net <net-dev at openjdk.java.net>; security-dev at openjdk.java.net <security-dev at openjdk.java.net>
Betreff: RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base module

Please review some minor doc fixes, for issues found by _doccheck_.    There are two kinds of errors that are addressed.

1. Incorrect use of `<p>`. In HTML, `<p>` marks the *beginning* of a paragraph. It is not a terminator, to mark the end of a paragraph, or a separator to mark the boundary between paragraphs.  In particular, it should not be used at the end of a description before a javadoc block tag, such as `@param` or before other HTML block tags, like `<ul>` or `<table>`.

2. References to the id `package-description`, following the recent standardization of all ids generated by javadoc,

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

Commit messages:
 - JDK-8262875: doccheck: empty paragraphs, etc in java.base module

Changes: https://git.openjdk.java.net/jdk/pull/2795/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2795&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262875
  Stats: 9 lines in 8 files changed: 0 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2795.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2795/head:pull/2795

PR: https://git.openjdk.java.net/jdk/pull/2795

From akozlov at openjdk.java.net  Tue Mar  2 20:32:49 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 20:32:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <9bn80xM9g41OytCtH71-krOZtAgy27TbvTFJHmfmKrE=.e9d223d5-2922-4891-8f45-ee039d88ced6@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <9bn80xM9g41OytCtH71-krOZtAgy27TbvTFJHmfmKrE=.e9d223d5-2922-4891-8f45-ee039d88ced6@github.com>
Message-ID: <FqG48k4wPLWnjZX7DO2Vi9utptmRaSSLKZvAFkXJVuA=.50cf018d-194a-4149-82b3-bcf6ce6aa8fd@github.com>

On Thu, 4 Feb 2021 22:34:16 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Add comments to WX transitions
>>    
>>    + minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 237:
> 
>> 235:       os::Posix::ucontext_set_pc(uc, StubRoutines::continuation_for_safefetch_fault(pc));
>> 236:       return true;
>> 237:     }
> 
> Isn't this case already handled by `JVM_HANDLE_XXX_SIGNAL()` ? Why do we need it here again?

Good point, thanks. We are missing a few fixes in os_cpu/bsd_aarch64. This was moved out recently. I'm going to align bsd_aarch64 with the rest of platforms.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From jonathan.gibbons at oracle.com  Tue Mar  2 20:34:37 2021
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 2 Mar 2021 12:34:37 -0800
Subject: RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base
 module
In-Reply-To: <AM0PR03MB4145D8814F28F0DFA9CCFF78FF999@AM0PR03MB4145.eurprd03.prod.outlook.com>
References: <GOUQ3xpHuNHaPXeRPE1riUsHp7-pE-qmf8rSIU8SPLQ=.1cef31d5-18cc-498f-8f28-b57aafb2cbbf@github.com>
 <AM0PR03MB4145D8814F28F0DFA9CCFF78FF999@AM0PR03MB4145.eurprd03.prod.outlook.com>
Message-ID: <0d6dffba-66c3-bb74-32c3-b83481b5f742@oracle.com>

Bernd,

With respect, I disagree.

There is a difference between `<body>text</body>` and 
`<body><p>text</p></body>`.

Anyway, the significant comment in this context is that it is being used 
as a terminator, at the logical end of the paragraph.

doccheck is using the standard `htmltidy` command to detect issues in 
HTML, and it is that program that is reporting the empty paragraphs.


As for the guide that you reference, it is very, very old. I note that 
it begins:

>
>       Introduction
>
> *Principles*
>
> At Java Software, we have several guidelines
>

i.e. note the "Java Software" ...

-- Jon

 ? On 3/2/21 12:04 PM, Bernd Eckenfels wrote:
> Hello,
>
> Actually, in HTML <p> was a separator, and in xhtml it should enclose paragraphs. However I was under the impression Javadoc always used the separator style (it would be strange to start the first sentence in Javadoc with <p>. Is this doccheck enforcing a new policy?
>
> This officially Oracle guide for example has a different example:
>
> https://www.oracle.com/de/technical-resources/articles/java/javadoc-tool.html#format
>
> Gruss
> Bernd
>
>
> --
> http://bernd.eckenfels.net
> ________________________________
> Von: net-dev <net-dev-retn at openjdk.java.net> im Auftrag von Jonathan Gibbons <jjg at openjdk.java.net>
> Gesendet: Tuesday, March 2, 2021 8:41:03 PM
> An: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; hotspot-compiler-dev at openjdk.java.net <hotspot-compiler-dev at openjdk.java.net>; net-dev at openjdk.java.net <net-dev at openjdk.java.net>; security-dev at openjdk.java.net <security-dev at openjdk.java.net>
> Betreff: RFR: JDK-8262875: doccheck: empty paragraphs, etc in java.base module
>
> Please review some minor doc fixes, for issues found by _doccheck_.    There are two kinds of errors that are addressed.
>
> 1. Incorrect use of `<p>`. In HTML, `<p>` marks the *beginning* of a paragraph. It is not a terminator, to mark the end of a paragraph, or a separator to mark the boundary between paragraphs.  In particular, it should not be used at the end of a description before a javadoc block tag, such as `@param` or before other HTML block tags, like `<ul>` or `<table>`.
>
> 2. References to the id `package-description`, following the recent standardization of all ids generated by javadoc,
>
> -------------
>
> Commit messages:
>   - JDK-8262875: doccheck: empty paragraphs, etc in java.base module
>
> Changes: https://git.openjdk.java.net/jdk/pull/2795/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2795&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8262875
>    Stats: 9 lines in 8 files changed: 0 ins; 1 del; 8 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/2795.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/2795/head:pull/2795
>
> PR: https://git.openjdk.java.net/jdk/pull/2795

From jjg at openjdk.java.net  Tue Mar  2 20:38:45 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 2 Mar 2021 20:38:45 GMT
Subject: Integrated: JDK-8262875: doccheck: empty paragraphs,
 etc in java.base module
In-Reply-To: <GOUQ3xpHuNHaPXeRPE1riUsHp7-pE-qmf8rSIU8SPLQ=.1cef31d5-18cc-498f-8f28-b57aafb2cbbf@github.com>
References: <GOUQ3xpHuNHaPXeRPE1riUsHp7-pE-qmf8rSIU8SPLQ=.1cef31d5-18cc-498f-8f28-b57aafb2cbbf@github.com>
Message-ID: <v5UVdgee-xfeaiFMrQ7K92IyGdx_yU5htDMhbqVNEAE=.caf04952-db4b-4dfc-b02f-3483d560cc9e@github.com>

On Tue, 2 Mar 2021 19:35:47 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review some minor doc fixes, for issues found by _doccheck_.    There are two kinds of errors that are addressed.
> 
> 1. Incorrect use of `<p>`. In HTML, `<p>` marks the *beginning* of a paragraph. It is not a terminator, to mark the end of a paragraph, or a separator to mark the boundary between paragraphs.  In particular, it should not be used at the end of a description before a javadoc block tag, such as `@param` or before other HTML block tags, like `<ul>` or `<table>`.
> 
> 2. References to the id `package-description`, following the recent standardization of all ids generated by javadoc,

This pull request has now been integrated.

Changeset: 20b9ba53
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/20b9ba53
Stats:     9 lines in 8 files changed: 0 ins; 1 del; 8 mod

8262875: doccheck: empty paragraphs, etc in java.base module

Reviewed-by: alanb, darcy, lancea

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

PR: https://git.openjdk.java.net/jdk/pull/2795

From akozlov at openjdk.java.net  Tue Mar  2 21:19:18 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 21:19:18 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v23]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with five additional commits since the last revision:

 - Fix after JDK-8259539, partially revert preconditions
 - JDK-8260471: bsd_aarch64 part
 - JDK-8259539: bsd_aarch64 part
 - JDK-8257828: bsd_aarch64 part
 - Cleanup os_bsd_aarch64 signal handling

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/e42b82db..4c37f068

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=22
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=21-22

  Stats: 31 lines in 1 file changed: 15 ins; 11 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Tue Mar  2 21:19:18 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 21:19:18 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <-PhzrEcgREcbXuZ5GrxAfVa6Uwil9YoOkZULt1154rw=.9689a79e-cf61-4f79-9b36-a3295fecab7b@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <i9UArB35vpHowW6HbtTkKLQX-wwfSx1dg1NKLHIRdGs=.5e08a151-8ad3-46cc-b006-34d750410c47@github.com>
 <-PhzrEcgREcbXuZ5GrxAfVa6Uwil9YoOkZULt1154rw=.9689a79e-cf61-4f79-9b36-a3295fecab7b@github.com>
Message-ID: <XOowePO_JQ-AQ342Gtf3w3J8nrin2YPdlj0ZP6gwYJM=.2884d345-3eab-4ba6-85f8-fde1d011df49@github.com>

On Fri, 12 Feb 2021 15:21:06 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 302:
>> 
>>> 300:         const uint64_t *detail_msg_ptr
>>> 301:           = (uint64_t*)(pc + NativeInstruction::instruction_size);
>>> 302:         const char *detail_msg = (const char *)*detail_msg_ptr;
>> 
>> Where is `detail_msg` used?
>
> Came from linux_arm64. was used in os_linux_aarch64.cpp on line 246 in report_and_die
> But became unused on bsd_arm64. I agree this needs to be removed

It seems we have merged master branch before JDK-8259539 was integrated. It brings back use of detail_msg. I reverted details_msg as well its following use.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Tue Mar  2 21:29:52 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 2 Mar 2021 21:29:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v10]
In-Reply-To: <snefTFoz9nOu7pghwG_v5GiOsmMvFSiICF3Hr1UskCs=.e9df3841-8204-41f5-a2b7-d8b07569a646@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <QZ7stXQpgmcHxvq5cmr2FB_R8lyy2xGDNK8m1cawvWk=.f436fe10-400b-4a6c-a41c-ebdb170a3248@github.com>
 <snefTFoz9nOu7pghwG_v5GiOsmMvFSiICF3Hr1UskCs=.e9df3841-8204-41f5-a2b7-d8b07569a646@github.com>
Message-ID: <k5nnBgnSMPy-3Zk3rnTAsmrFgMlO08wb_4wpfOYg4SM=.cf972a76-c5c6-4428-9574-66120fa79594@github.com>

On Thu, 4 Feb 2021 22:58:39 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Add comments to WX transitions
>>    
>>    + minor change of placements
>>  - Use macro conditionals instead of empty functions
>>  - Add W^X to tests
>>  - Do not require known W^X state
>>  - Revert w^x in gtests
>
> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 420:
> 
>> 418: size_t os::Posix::_compiler_thread_min_stack_allowed = 72 * K;
>> 419: size_t os::Posix::_java_thread_min_stack_allowed = 72 * K;
>> 420: size_t os::Posix::_vm_internal_thread_min_stack_allowed = 72 * K;
> 
> Those are slightly larger than their x86_64 counter parts. Are they conservative/aggressive values? How did we arrive at those?

These values were copied from linux_aarch64. The motivation is that clang on macos/aarch64 will likely to produce stack frames for C++ functions similar to frames generates by gcc on linux/aarch64. And sizes of java stack frames should not change.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From jjg at openjdk.java.net  Tue Mar  2 22:07:00 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 2 Mar 2021 22:07:00 GMT
Subject: RFR: JDK-8262892: minor typo in implSpec comment
Message-ID: <1Hq8F1e5xuQ4Xkm55HZCj5RThLdV9Cjy5ri2x0PfWIk=.9277e1a8-ec82-4b02-b910-4994c452ece7@github.com>

Please review a trivial fix to insert a missing word.

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

Commit messages:
 - JDK-8262892: minor typo in implSpec comment

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

PR: https://git.openjdk.java.net/jdk/pull/2798

From bpb at openjdk.java.net  Tue Mar  2 22:13:50 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 2 Mar 2021 22:13:50 GMT
Subject: RFR: JDK-8262892: minor typo in implSpec comment
In-Reply-To: <1Hq8F1e5xuQ4Xkm55HZCj5RThLdV9Cjy5ri2x0PfWIk=.9277e1a8-ec82-4b02-b910-4994c452ece7@github.com>
References: <1Hq8F1e5xuQ4Xkm55HZCj5RThLdV9Cjy5ri2x0PfWIk=.9277e1a8-ec82-4b02-b910-4994c452ece7@github.com>
Message-ID: <dkZNq00quJqbACW5ND-oqDNvxfSjTwvCpCXtWf3m0UM=.870951c0-4c1f-4504-9623-6e19f3fef407@github.com>

On Tue, 2 Mar 2021 22:01:49 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial fix to insert a missing word.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2798

From jiefu at openjdk.java.net  Tue Mar  2 22:38:41 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 2 Mar 2021 22:38:41 GMT
Subject: RFR: 8262096: Vector API fails to work due to VectorShape
 initialization exception [v7]
In-Reply-To: <iRcr-DqLemEMG4Z8nkZ8DbTfeeS3t0tkh1RhlKHAI3M=.9c51b0cb-e7e9-429d-96d2-1ff52445dc55@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
 <A-WnLlIGApD007vIaJ80HU-Pv-EGLxnteB-uVgJuzhc=.269e29a4-329b-4d41-9136-5dcffc97e6dd@github.com>
 <iRcr-DqLemEMG4Z8nkZ8DbTfeeS3t0tkh1RhlKHAI3M=.9c51b0cb-e7e9-429d-96d2-1ff52445dc55@github.com>
Message-ID: <Ekdvw6XypWQhvwtDn1MGckd-yZW1eEYA-n3BZvwlcuA=.2304b2f5-5a1b-4b04-b20b-a0d7e299a6ce@github.com>

On Tue, 2 Mar 2021 17:17:37 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jie Fu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add VectorShape.getMaxVectorBitSize
>
> Marked as reviewed by psandoz (Reviewer).

> The `PreferredSpeciesTest` also needs to be executed with no HotSpot flags.

Yes, we already have this one [1].
So no need to be updated and will push it later.
Thanks.

[1] https://github.com/openjdk/jdk/blob/master/test/jdk/jdk/incubator/vector/PreferredSpeciesTest.java#L33

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From jjg at openjdk.java.net  Tue Mar  2 22:56:45 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 2 Mar 2021 22:56:45 GMT
Subject: Integrated: JDK-8262892: minor typo in implSpec comment
In-Reply-To: <1Hq8F1e5xuQ4Xkm55HZCj5RThLdV9Cjy5ri2x0PfWIk=.9277e1a8-ec82-4b02-b910-4994c452ece7@github.com>
References: <1Hq8F1e5xuQ4Xkm55HZCj5RThLdV9Cjy5ri2x0PfWIk=.9277e1a8-ec82-4b02-b910-4994c452ece7@github.com>
Message-ID: <ieFiQ-HoXi3K081GynuKbUJNx_q_2YcVtvYXL14U2n0=.541316b2-2d8d-4fbd-858f-9b7d41742874@github.com>

On Tue, 2 Mar 2021 22:01:49 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a trivial fix to insert a missing word.

This pull request has now been integrated.

Changeset: 93ffe6a6
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/93ffe6a6
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8262892: minor typo in implSpec comment

Reviewed-by: bpb

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

PR: https://git.openjdk.java.net/jdk/pull/2798

From dholmes at openjdk.java.net  Tue Mar  2 23:25:08 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 2 Mar 2021 23:25:08 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v23]
In-Reply-To: <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>
Message-ID: <sL7Ru9rbNmfzeX-14ZZdvyVzmjIn3R-NCZypqjU5Amk=.7a077954-920c-46f0-bae2-b646e9b1b6ae@github.com>

On Tue, 2 Mar 2021 21:19:18 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Fix after JDK-8259539, partially revert preconditions
>  - JDK-8260471: bsd_aarch64 part
>  - JDK-8259539: bsd_aarch64 part
>  - JDK-8257828: bsd_aarch64 part
>  - Cleanup os_bsd_aarch64 signal handling

src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 207:

> 205:   // Enable WXWrite: this function is called by the signal handler at arbitrary
> 206:   // point of execution.
> 207:   ThreadWXEnable wx(WXWrite, thread);

Note that `thread` can be NULL here if the signal handler is running in a non-attached thread.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From jiefu at openjdk.java.net  Tue Mar  2 23:34:53 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 2 Mar 2021 23:34:53 GMT
Subject: Integrated: 8262096: Vector API fails to work due to VectorShape
 initialization exception
In-Reply-To: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
References: <1IGTrGJrdBrsekizG1jLeCKLMkHiGxqKEyzLlQJkZa4=.decd6165-9d52-4e8e-973c-8036295cecff@github.com>
Message-ID: <KMRUDSAlxGOOD5ojXomu1e2y34pSFKKW-3eNIhnzbPY=.d82b58b2-a101-4e16-9805-30fc49661b8b@github.com>

On Thu, 25 Feb 2021 09:31:01 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> Vector API fails to work when:
>  - case 1: MaxVectorSize is set to <=8, or
>  - case 2: C2 is disabled
> 
> The reason is that {max/preferred} VectorShape initialization fails in both cases.
> And the root cause is that VectorSupport_GetMaxLaneCount [1] returns unreasonable values (0 for case 1 and -1 for case 2).
> 
> Vector API should not depend on C2 to run.
> It should work even there is no JIT compiler since it's a Java-level api.
> So let's fix it.
> 
> Testing:
>   - jdk/incubator/vector with -XX:MaxVectorSize=default/8 on Linux/x64
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/src/hotspot/share/prims/vectorSupport.cpp#L364

This pull request has now been integrated.

Changeset: 40bdf52e
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/40bdf52e
Stats:     60 lines in 2 files changed: 38 ins; 10 del; 12 mod

8262096: Vector API fails to work due to VectorShape initialization exception

Reviewed-by: psandoz, vlivanov

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

PR: https://git.openjdk.java.net/jdk/pull/2722

From asemenyuk at openjdk.java.net  Wed Mar  3 00:42:41 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 3 Mar 2021 00:42:41 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path [v2]
In-Reply-To: <m72-a53qYGt1PDIpuVy_IL-pFPh8QYlFhBFY9XWdnlE=.b4bcefc9-cec4-4fc3-ad05-45c5a2bcea13@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
 <m72-a53qYGt1PDIpuVy_IL-pFPh8QYlFhBFY9XWdnlE=.b4bcefc9-cec4-4fc3-ad05-45c5a2bcea13@github.com>
Message-ID: <qjerVOxv5R9iVv_L2uKKyQfW4NoR3TDIqw1xNxJMZwY=.8c356a92-73aa-442a-a4fb-6da4a21e6695@github.com>

On Tue, 2 Mar 2021 19:47:04 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory.
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8261518: jpackage looks for main module in current dir when there is no module-path

Changes requested by asemenyuk (Committer).

test/jdk/tools/jpackage/share/jdk/jpackage/tests/NoMPathRuntimeTest.java line 137:

> 135:     public static Collection data() {
> 136:         final List<String> javaAppDescs = List.of("Hello",
> 137:                 "com.foo/com.foo.main.Aloha");

Why do you need "Hello" non-modular app?

test/jdk/tools/jpackage/share/jdk/jpackage/tests/NoMPathRuntimeTest.java line 125:

> 123:                 .addArguments("-cvf", "junk.jar",
> 124:                         "-C", tmpdir.toString(), "Hello.class")
> 125:                 .execute();

Single line `HelloApp.createBundle("junk.jar:Hello", tmpdir);` would compile source class and put it into "junk.jar" in `tmpdir` folder. It can be used to replace lines from [109, 125] range.

test/jdk/tools/jpackage/share/jdk/jpackage/tests/NoMPathRuntimeTest.java line 66:

> 64:         final Path tmpdir = TKit.createTempDirectory("tmpdir");
> 65:         try {
> 66:             Files.createFile(tmpdir.resolve("tmpfile"));

Is this leftover from something or on purpose?

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

PR: https://git.openjdk.java.net/jdk/pull/2781

From asemenyuk at openjdk.java.net  Wed Mar  3 00:49:39 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 3 Mar 2021 00:49:39 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path [v2]
In-Reply-To: <qjerVOxv5R9iVv_L2uKKyQfW4NoR3TDIqw1xNxJMZwY=.8c356a92-73aa-442a-a4fb-6da4a21e6695@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
 <m72-a53qYGt1PDIpuVy_IL-pFPh8QYlFhBFY9XWdnlE=.b4bcefc9-cec4-4fc3-ad05-45c5a2bcea13@github.com>
 <qjerVOxv5R9iVv_L2uKKyQfW4NoR3TDIqw1xNxJMZwY=.8c356a92-73aa-442a-a4fb-6da4a21e6695@github.com>
Message-ID: <vp8VF0Kxo1f9_zFocVBJGD0yxM23ReM-j-xjlp-3jEQ=.6bdd4af2-d91a-40a6-9b0a-5d5bb4d6fda5@github.com>

On Wed, 3 Mar 2021 00:40:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8261518: jpackage looks for main module in current dir when there is no module-path
>
> Changes requested by asemenyuk (Committer).

I don't quite understand what unit test is doing. It creates a runtime that includes app module. It builds "junk.jar". How these pieces are connected?

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

PR: https://git.openjdk.java.net/jdk/pull/2781

From mcimadamore at openjdk.java.net  Wed Mar  3 01:17:51 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 3 Mar 2021 01:17:51 GMT
Subject: Integrated: 8260869: Test java/foreign/TestHandshake.java fails
 intermittently
In-Reply-To: <mXyACmxchC_HsrnEgGBNmG1e5ggPpsIN5y-hxpU2Onc=.8c07c849-5deb-4b79-bf48-69251372c481@github.com>
References: <mXyACmxchC_HsrnEgGBNmG1e5ggPpsIN5y-hxpU2Onc=.8c07c849-5deb-4b79-bf48-69251372c481@github.com>
Message-ID: <aFtDJMmZnNS7Olz3AfHljxZuEYu4o8JDIJ4HDGmZcMI=.a3ac64d8-31b4-4138-833f-7226d7071cfc@github.com>

On Fri, 26 Feb 2021 14:25:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This simple fix reduces the amount of concurrency on the foreign memory TestHandshake test. As this test spins a new accessor thread for each available processors, on machines which feature an high number of available processors (because of multi-threading), and which are slower in forking new threads (e.g. Windows), the test can sometimes timeout.
> 
> The sensible step, for now, is to introduce an hard limit on the number of concurrent accessor threads being created. I've looked at the test logs quite in depth, and there's nothing suggesting that something else is amiss - the number of concurrent threads just seem to be too high in some instances.

This pull request has now been integrated.

Changeset: 5de0f4b2
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5de0f4b2
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8260869: Test java/foreign/TestHandshake.java fails intermittently

Reviewed-by: psandoz

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

PR: https://git.openjdk.java.net/jdk/pull/2748

From darcy at openjdk.java.net  Wed Mar  3 07:24:59 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 3 Mar 2021 07:24:59 GMT
Subject: RFR: 8261862: Expand discussion of rationale for BigDecimal
 equals/compareTo semantics
Message-ID: <S9X0Dvgt4dKoASkxK59Ht6XnOGMxl8NeUplGoWkLICU=.9cc47a66-4d7f-45a0-a51d-368dc5dc79d3@github.com>

I considered @stuart-marks previous suggestion during the code review of JDK-8261123 to include a more explicit discussion of why, say, different representations of 2 should not be regarded as equivalent. After contemplating several alternatives, I didn't find anything simpler than Stuart's 2/3 example so I used that as seen in the diff.

A short digression, BigDecimal supports both fixed-point style and floating-point style rounding. Floating-point rounding primarily replies on the number of precision digits, regards of their scale, while fixed-point style rounding prioritizes the scale. The number of digits of eventual output is a function of number number of digits in the inputs and the number of precision digits in a floating-point style rounding. A floating-point style rounding has a preferred scale, rather than a fixed scale based on the inputs. The fixed-point style divide method used in the example has a scale based on the dividend, allowing a relatively simple expression to show a distinction between 2.0 and 2.00.

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

Commit messages:
 - 8261862: Expand discussion of rationale for BigDecimal equals/compareTo semantics

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

PR: https://git.openjdk.java.net/jdk/pull/2804

From jai.forums2013 at gmail.com  Wed Mar  3 10:14:18 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 3 Mar 2021 15:44:18 +0530
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
Message-ID: <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>

Thank you Lance. So I think there's some level of agreement on using -C 
and --dir (or --directory) for the option names.

Anymore opinion on the directory creation semantics and any other 
aspects to consider?

-Jaikiran

On 28/02/21 5:38 pm, Lance Andersen wrote:
> Hi Jaikiran,
>
> Thank you for this. ?I went through this myself yesterday in addition 
> to what you have below here are a few more:
>
> 7zip: ? ? ? -o
> Info-zip: ?-d ?(MacOS version of zip)
> Bandzip: -o:{dir}
> jpackage: -d ?dest
> jlink ?output
>
>
> Thinking about this some more, I might suggest supporting
>
> -C
> ?dir
> ?directory
>
> Best
> Lance
>
>> On Feb 27, 2021, at 11:19 PM, Jaikiran Pai <jai.forums2013 at gmail.com 
>> <mailto:jai.forums2013 at gmail.com>> wrote:
>>
>> Hello Alan,
>>
>> On 27/02/21 2:23 pm, Alan Bateman wrote:
>>>
>>> Yes, the option name will need to be agreed. It would be useful to 
>>> enumerate the options that the other tools are using to specify the 
>>> location where to extract. If you see JBS issues mentioning tar -C 
>>> not supporting chdir when extracting then it might be Solaris tar, 
>>> which isn't the same as GNU tar which has different options. It 
>>> might be better to look at more main stream tools, like unzip 
>>> although jar -d is already taken. It would be nice if there were 
>>> some consistency with other tools in the JDK that doing extracting 
>>> (The jmod and jimage extract commands use use --dir for example).
>>
>> I had a look at both tar and unzip commands on MacOS and Linux 
>> (CentOS) setup that I had access to.
>>
>> --------------
>> tar on MacOS:
>> --------------
>>
>> tar --version
>> bsdtar 3.3.2 - libarchive 3.3.2 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.6
>>
>> The version of this tool has:
>>
>> -C directory, --cd directory, --directory directory
>> ???????????? In c and r mode, this changes the directory before 
>> adding the following files.
>> ???????????? In x mode, change directories after opening the archive 
>> but before extracting
>> ???????????? entries from the archive.
>>
>> A command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and 
>> extracts the foo.tar.gz from current directory to a target directory 
>> /tmp/bar/
>>
>> --------------
>> tar on CentOS:
>> --------------
>>
>> tar --version
>> tar (GNU tar) 1.26
>>
>> This version of the tool has:
>>
>> Common options:
>> ?????? -C, --directory=DIR
>> ????????????? change to directory DIR
>>
>> Although the wording isn't clear that, when used with -x, it extracts 
>> to the directory specified in -C, it does indeed behave that way.
>>
>> Specifically, a command like "tar -xzf foo.tar.gz -C /tmp/bar/" works 
>> fine and extracts the foo.tar.gz from current directory to a target 
>> directory /tmp/bar/
>>
>> -------------------------------
>> unzip on both MacOS and CentOS:
>> -------------------------------
>>
>> unzip -v
>> UnZip 6.00 of 20 April 2009, by Info-ZIP.? Maintained by C. Spieler.
>>
>> This version of the tool has:
>>
>> [-d exdir]
>> ????????????? An optional directory to which to extract files.? By 
>> default, all files and sub-
>> ????????????? directories are recreated in the current directory; the 
>> -d option allows extrac-
>> ????????????? tion in an arbitrary directory (always assuming one has 
>> permission to? write? to
>> ????????????? the? directory).? This option need not appear at the 
>> end of the command line; it
>> ????????????? is also accepted before the zipfile specification 
>> (with? the? normal? options),
>> ????????????? immediately? after? the zipfile specification, or 
>> between the file(s) and the -x
>> ????????????? option.? The option and directory may be concatenated 
>> without? any? white? space
>> ????????????? between? them,? but? note? that? this may cause normal 
>> shell behavior to be sup-
>> ????????????? pressed.? In particular, ``-d ~'' (tilde) is expanded 
>> by Unix C shells into? the
>> ????????????? name of the user's home directory, but ``-d~'' is 
>> treated as a literal subdirec-
>> ????????????? tory ``~'' of the current directory.
>>
>> unzip foo.zip -d /tmp/bar/ works fine and extracts the foo.zip from 
>> current directory to /tmp/bar/
>>
>> ---------------
>> jimage and jmod
>> ---------------
>>
>> The jimage and jmod as you note use the --dir option for extracting 
>> to that specified directory.
>>
>>
>> Those were the tools I looked at. I think using the -d option with -x 
>> for the jar command is ruled out since it already is used for a 
>> different purpose, although for a different "main" operation of the 
>> jar command.
>>
>> As for using --dir for this new feature, I don't think it alone will 
>> be enough. Specifically, I couldn't find a "short form" option for 
>> the --dir option in the jimage or jmod commands. For the jar extract 
>> feature that we are discussing here, I think having a short form 
>> option (in addition to the longer form) is necessary to have it match 
>> the usage expectations of similar other options that the jar command 
>> exposes. So even if we do choose --dir as the long form option, we 
>> would still need a short form for it and since -d is already taken 
>> for something else, we would still need to come up with a different 
>> one. The short form of this option could be -C (see below).
>>
>>
>> I think reusing the -C option, for this new feature, perhaps is a 
>> good thing. The -C is currently used by the update and create "main" 
>> operation of the jar command and the man page for this option states:
>>
>> -C dir
>> ????????????? When creating (c) or updating (u) a JAR file, this 
>> option temporarily changes
>> ????????????? the directory while processing files specified by the 
>> file operands. Its
>> ????????????? operation is intended to be similar to the -C option of 
>> the UNIX tar utility.For
>> ????????????? example, the following command changes to the classes 
>> directory and adds the
>> ????????????? Bar.class file from that directory to my.jar:
>>
>> ????????????? jar uf my.jar -C classes Bar.class
>> ....
>>
>> Using the -C option would indeed align it with the tar command. For 
>> the "long form" of this option, the tar command (both on MacOS and 
>> CentOS) uses --directory. For this jar extract feature though, we 
>> could perhaps just use --dir to have it align with the jimage and the 
>> jmod tools.
>>
>> So I think the combination of -C (short form) and --dir (long form) 
>> would perhaps be suitable for this feature.
>>
>>
>>>
>>> There are other discussion points around the behavior when the 
>>> target directory exists or does not exist, to ensure there is some 
>>> consistency with main stream tools.
>>
>> I'm guessing you mean the behaviour of creating a directory (or a 
>> hierarchy of directories) if the target directory is not present? My 
>> testing with the tar tool (both on MacOS and CentOS) shows that if 
>> the specified target directory doesn't exist, then the extract fails. 
>> The tar extract command doesn't create the target directory during 
>> extract. On the other hand, the unzip tool, does create the directory 
>> if it doesn't exist. However, interestingly, the unzip tool creates 
>> only one level of that directory if it doesn't exist. Specifically, 
>> if you specify:
>>
>> unzip foo.zip -d /tmp/blah/
>>
>> and if "blah/" isn't a directory inside /tmp/ directory, then it 
>> creates the "blah/" directory inside /tmp/ and then extracts the 
>> contents of the zip into it.
>>
>> However,
>>
>> unzip foo.zip -d /tmp/blah/hello/
>>
>> and if "blah/" isn't a directory inside /tmp/ directory, then this 
>> command fails with an error and it doesn't create the hierarchy of 
>> the target directories.
>>
>> Coming to the jimage and the jmod commands, both these commands 
>> create the entire directory hierarchy if the target directory 
>> specified during extract, using --dir, doesn't exist. So a command like:
>>
>> jimage extract --dir /tmp/blah/foo/bar/ jdkmodules
>>
>> will create the blah/foo/bar/ directory hierarchy if blah doesn't 
>> exist in /tmp/, while extracting the "jdkmodules" image.
>>
>> From the user point of view, I think this behaviour of creating the 
>> directories if the target directory doesn't exist, is probably the 
>> most intuitive and useful and if we did decide to use this approach 
>> for this new option for jar extract command, then it would align with 
>> what we already do in jimage and jmod commands.
>>
>> One another minor detail, while we are at this, is that, IMO we 
>> should let the jar extract command to continue to behave the way it 
>> currently does when it comes to overwriting existing files. If the 
>> jar being extracted contains a file by the same name, in the target 
>> directory (hierarchy) then it should continue to overwrite that file. 
>> In other words, I don't think we should change the way the jar 
>> extract command currently behaves where it overwrites existing files 
>> when extracting.
>>
>>
>> -Jaikiran
>>
>>
>
>
>
>
> Lance Andersen| Principal?Member of Technical Staff?| +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
>
>
>

From volker.simonis at gmail.com  Wed Mar  3 10:43:19 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 3 Mar 2021 11:43:19 +0100
Subject: Question about java.system.class.loader and the module system
Message-ID: <CA+3eh11wSfe5w7wpfx9r48iFDmdF6yt2=O4fqs0DjB4vMBgFFQ@mail.gmail.com>

Hi,

I have a question about how changing the system class loader by
setting "java.system.class.loader" interacts with the module system. I
couldn't find a lot of information on this topic but if it has been
discussed before please point me to the corresponding place.

Traditionally, setting "java.system.class.loader" to the name of a
class loader will instruct the JVM to use that class loader as the
system class loader which will be used to load the application main
class. But this class loader has to be loaded itself by a class
loader. So the JVM defines its own "default system class loader" which
will be used to load the custom system class loader and which will act
as delegation parent for it [1]. By writing a custom class loader
which intercepts calls to loadClass() and defining it as the system
class loader by setting "java.system.class.loader" it can be easily
verified that the JVM will load the applications main class with that
custom class loader.

This behaviour changes however if we use the new module syntax "-m
<module>/<class>" to start an application. In that case, the main
application class will always be loaded by the default system class
loader, no matter if we define  "java.system.class.loader" or not.
>From what I've found by looking into the sources, this is because the
application module will be added to the boot layer and associated with
the default system class loader early in the JVM boot process (i.e.
"initPhase2") when only classes from java.base can be loaded and the
custom class loader is therefore not available. The system class
loader is only initialized later in "initiPhase3" at which it seems to
be already to late to associate it with the application module (is
this really the case?).

My question now is if this is an inherent property of the module
system or merely an implementation detail? I.e. would it be possible
to put the application module into its own layer and initialize that
only later when the custom system class loader will be available? I
think this would be relatively easy if the custom class loader can be
found on the class path. If the custom class loader is in a module
itself, that module would have to be in the boot layer to make it
accessible to the default system class loader.

The current API documentation of the system class loader [1] mentions
that the system class loader "is typically the class loader used to
start the application". Shouldn't that be updated to mention that this
will not be the case for modular applications?

Thank you and best regards,
Volker

[1] https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getSystemClassLoader()

From Alan.Bateman at oracle.com  Wed Mar  3 12:38:35 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 3 Mar 2021 12:38:35 +0000
Subject: Question about java.system.class.loader and the module system
In-Reply-To: <CA+3eh11wSfe5w7wpfx9r48iFDmdF6yt2=O4fqs0DjB4vMBgFFQ@mail.gmail.com>
References: <CA+3eh11wSfe5w7wpfx9r48iFDmdF6yt2=O4fqs0DjB4vMBgFFQ@mail.gmail.com>
Message-ID: <1c05cc73-7c3b-dadb-ee6f-4b2db7d2dff7@oracle.com>

On 03/03/2021 10:43, Volker Simonis wrote:
> :
>
> My question now is if this is an inherent property of the module
> system or merely an implementation detail? I.e. would it be possible
> to put the application module into its own layer and initialize that
> only later when the custom system class loader will be available? I
> think this would be relatively easy if the custom class loader can be
> found on the class path. If the custom class loader is in a module
> itself, that module would have to be in the boot layer to make it
> accessible to the default system class loader.
The ability to set a custom class loader as the system class loader is 
somewhat legacy feature. There was consideration given to deprecating 
and removing it a few years ago but we ended up leaving it "as is" in 
case there are still application servers using it. So it should work the 
same in JDK 16 as it did in JDK 8/older releases. That is, it will be 
created with the built-in application class loader as parent and the 
custom system class loader will be the default parent class loader for 
delegation.

You are correct that an initial module on the application module path 
will be loaded by the built-in application class loader. All modules on 
the application module path are mapped to the built-in application class 
loader. If an initial module is specified to the java launcher (--module 
or -m) then it just locates the module in the boot layer and invokes its 
main class. There is no role for a custom system class loader here.

If you are looking to deploy a custom system class loader in a module on 
the module path then it should work as long as you export the package 
with the custom class loader to java.base. I'm not sure if you really 
want to do this or whether it's a means to an end. Maybe it would be 
easier to start with a summary on what you are looking it do? Are you 
looking to intercept all attempts to load classes? Is there a java agent 
in the picture too?



> The current API documentation of the system class loader [1] mentions
> that the system class loader "is typically the class loader used to
> start the application". Shouldn't that be updated to mention that this
> will not be the case for modular applications?
The javadoc is correct because it will be rare to deploy with 
java.system.class.loader set to a custom class loader. Assuming it is 
not set then you should find that the initial class will be defined by 
this class loader. This goes for both the class path and module path cases.


-Alan



From herrick at openjdk.java.net  Wed Mar  3 13:59:02 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 3 Mar 2021 13:59:02 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path [v2]
In-Reply-To: <qjerVOxv5R9iVv_L2uKKyQfW4NoR3TDIqw1xNxJMZwY=.8c356a92-73aa-442a-a4fb-6da4a21e6695@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
 <m72-a53qYGt1PDIpuVy_IL-pFPh8QYlFhBFY9XWdnlE=.b4bcefc9-cec4-4fc3-ad05-45c5a2bcea13@github.com>
 <qjerVOxv5R9iVv_L2uKKyQfW4NoR3TDIqw1xNxJMZwY=.8c356a92-73aa-442a-a4fb-6da4a21e6695@github.com>
Message-ID: <eQXU8nvluB_AFTuIuEgexOoCTIdTi-MCidUVO6ZR3y0=.64cc5f9a-f371-451b-8b18-64e410160280@github.com>

On Wed, 3 Mar 2021 00:31:34 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8261518: jpackage looks for main module in current dir when there is no module-path
>
> test/jdk/tools/jpackage/share/jdk/jpackage/tests/NoMPathRuntimeTest.java line 125:
> 
>> 123:                 .addArguments("-cvf", "junk.jar",
>> 124:                         "-C", tmpdir.toString(), "Hello.class")
>> 125:                 .execute();
> 
> Single line `HelloApp.createBundle("junk.jar:Hello", tmpdir);` would compile source class and put it into "junk.jar" in `tmpdir` folder. It can be used to replace lines from [109, 125] range.
> 
> What is the point to build "junk.jar"? I don't see how it is used in the test.

The bug is that when --module-path option is not used in a modular app, jpackage uses a module-path with "." on it.
Having a non-modular jar in the modular path is an error.
So with this non-modular Hello.jar in the current directory the jpackage command failed before the fix, and succeeds after the fix.

I can create the non-modular Hello.jar in the current directory with one line:
HelloApp.createBundle(JavaAppDesc.parse("junk.jar:Hello"), Path.of("."))

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

PR: https://git.openjdk.java.net/jdk/pull/2781

From github.com+194713+candrews at openjdk.java.net  Wed Mar  3 14:16:04 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Wed, 3 Mar 2021 14:16:04 GMT
Subject: RFR: 8262277: java.net.URLClassLoader.getResource throws undocumented
 IllegalArgumentException
Message-ID: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>

_NOTE_: I've reported this issue at https://bugreport.java.com/ (internal review ID : 9069151)

`java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.

According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.

Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
> Returns:
>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.

And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
> Returns:
>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.

Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.

Here's a stack trace:
java.lang.IllegalArgumentException: name
        at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
        at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
        at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
        at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
        at java.base/java.security.AccessController.doPrivileged(Native Method)
        at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)

Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
        URL findResource(final String name, boolean check) {
            URL url;
            try {
                url = new URL(base, ParseUtil.encodePath(name, false));
            } catch (MalformedURLException e) {
                throw new IllegalArgumentException("name");
            }

Instead of throwing `IllegalArgumentException`, that line should simply return `null`.

A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
        URL findResource(final String name, boolean check) {
            URL url;
            try {
                url = new URL(base, ParseUtil.encodePath(name, false));
            } catch (MalformedURLException e) {
                throw new IllegalArgumentException("name");
            }

Instead of throwing `IllegalArgumentException`, that line should simply return `null`.

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

Commit messages:
 - 8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From github.com+194713+candrews at openjdk.java.net  Wed Mar  3 14:16:04 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Wed, 3 Mar 2021 14:16:04 GMT
Subject: RFR: 8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException
In-Reply-To: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
Message-ID: <JSFythcNbnRGMBbki-ZW1EfLvwMWX3Lpukw2AIGtSUU=.4e82a23c-c1ad-47dc-a991-77d1627300d5@github.com>

On Sat, 20 Feb 2021 19:20:48 GMT, Craig Andrews <github.com+194713+candrews at openjdk.org> wrote:

> _NOTE_: I've reported this issue at https://bugreport.java.com/ (internal review ID : 9069151)
> 
> `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.
> 
> According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.
> 
> Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>> Returns:
>>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.
> 
> And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>> Returns:
>>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.
> 
> Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.
> 
> Here's a stack trace:
> java.lang.IllegalArgumentException: name
>         at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>         at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>         at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
> 
> Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>         URL findResource(final String name, boolean check) {
>             URL url;
>             try {
>                 url = new URL(base, ParseUtil.encodePath(name, false));
>             } catch (MalformedURLException e) {
>                 throw new IllegalArgumentException("name");
>             }
> 
> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
> 
> A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>         URL findResource(final String name, boolean check) {
>             URL url;
>             try {
>                 url = new URL(base, ParseUtil.encodePath(name, false));
>             } catch (MalformedURLException e) {
>                 throw new IllegalArgumentException("name");
>             }
> 
> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.

Submitted a bug report at https://bugreport.java.com/
Received internal review ID : 9069151

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From github.com+194713+candrews at openjdk.java.net  Wed Mar  3 14:16:04 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Wed, 3 Mar 2021 14:16:04 GMT
Subject: RFR: 8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException
In-Reply-To: <JSFythcNbnRGMBbki-ZW1EfLvwMWX3Lpukw2AIGtSUU=.4e82a23c-c1ad-47dc-a991-77d1627300d5@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <JSFythcNbnRGMBbki-ZW1EfLvwMWX3Lpukw2AIGtSUU=.4e82a23c-c1ad-47dc-a991-77d1627300d5@github.com>
Message-ID: <8KXnzNXiqY3SxKpwdsYGZB9MI7-qi9RwUoUWY_lgAI0=.07861148-0360-4355-9f80-5e826edda267@github.com>

On Sat, 20 Feb 2021 19:22:10 GMT, Craig Andrews <github.com+194713+candrews at openjdk.org> wrote:

>> _NOTE_: I've reported this issue at https://bugreport.java.com/ (internal review ID : 9069151)
>> 
>> `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.
>> 
>> According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.
>> 
>> Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>>> Returns:
>>>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.
>> 
>> And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>>> Returns:
>>>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.
>> 
>> Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.
>> 
>> Here's a stack trace:
>> java.lang.IllegalArgumentException: name
>>         at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>>         at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>>         at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
>> 
>> Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>>         URL findResource(final String name, boolean check) {
>>             URL url;
>>             try {
>>                 url = new URL(base, ParseUtil.encodePath(name, false));
>>             } catch (MalformedURLException e) {
>>                 throw new IllegalArgumentException("name");
>>             }
>> 
>> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
>> 
>> A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>>         URL findResource(final String name, boolean check) {
>>             URL url;
>>             try {
>>                 url = new URL(base, ParseUtil.encodePath(name, false));
>>             } catch (MalformedURLException e) {
>>                 throw new IllegalArgumentException("name");
>>             }
>> 
>> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
>
> Submitted a bug report at https://bugreport.java.com/
> Received internal review ID : 9069151

This one liner will reproduce this issue (you can easily use `jshell` to run it and see the problem):
new java.net.URLClassLoader(new java.net.URL[]{new java.net.URL("https://repo1.maven.org/anything-that-ends-with-slash/")}).findResource("c:/windows");

The key parts to reproduce the issue are:
1. The `URLClassLoader` URL must not start with `file:` or `jar:` and must end in `/`. See https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L493
2. The string passed to `findResource` must not be a valid URL component. Windows paths (which include a `:` making them invalid URL components) are a common and easy way to see this error.

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From isipka at openjdk.java.net  Wed Mar  3 14:16:24 2021
From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Wed, 3 Mar 2021 14:16:24 GMT
Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v13]
In-Reply-To: <Idcz1uT7CMcM5WM3JKoekIxUS_eLcnAzYXxhz-zJjtE=.5c22a60d-14a1-426d-a63d-06cb42f1718d@github.com>
References: <Idcz1uT7CMcM5WM3JKoekIxUS_eLcnAzYXxhz-zJjtE=.5c22a60d-14a1-426d-a63d-06cb42f1718d@github.com>
Message-ID: <9LOhfRSInaD3zLn3vKc5pzTxdpWGODPHIQOwI2fjlj8=.e74cf6b7-a5e0-45b7-b70a-279e84c0baf9@github.com>

> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test.

Ivan ?ipka has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8166026: Refactor java/lang shell tests to java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1577/files
  - new: https://git.openjdk.java.net/jdk/pull/1577/files/ad387755..80cc5f0b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=11-12

  Stats: 9 lines in 1 file changed: 2 ins; 6 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1577.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1577/head:pull/1577

PR: https://git.openjdk.java.net/jdk/pull/1577

From alanb at openjdk.java.net  Wed Mar  3 14:30:44 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 3 Mar 2021 14:30:44 GMT
Subject: RFR: 8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException
In-Reply-To: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
Message-ID: <M_HI6rHAd36Rsy0ZS_ya3iFig0vZcyO_s9aK11a2j48=.7513689b-a106-4238-8b6a-f6d0de2109e5@github.com>

On Sat, 20 Feb 2021 19:20:48 GMT, Craig Andrews <github.com+194713+candrews at openjdk.org> wrote:

> _NOTE_: I've reported this issue at https://bugreport.java.com/ (internal review ID : 9069151)
> 
> `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.
> 
> According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.
> 
> Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>> Returns:
>>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.
> 
> And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>> Returns:
>>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.
> 
> Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.
> 
> Here's a stack trace:
> java.lang.IllegalArgumentException: name
>         at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>         at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>         at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
> 
> Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>         URL findResource(final String name, boolean check) {
>             URL url;
>             try {
>                 url = new URL(base, ParseUtil.encodePath(name, false));
>             } catch (MalformedURLException e) {
>                 throw new IllegalArgumentException("name");
>             }
> 
> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
> 
> A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>         URL findResource(final String name, boolean check) {
>             URL url;
>             try {
>                 url = new URL(base, ParseUtil.encodePath(name, false));
>             } catch (MalformedURLException e) {
>                 throw new IllegalArgumentException("name");
>             }
> 
> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.

This seems to be a long standing bug, maybe goes all the way back to JDK 1.2. Are you planning to add a regression test?

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From herrick at openjdk.java.net  Wed Mar  3 14:47:02 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 3 Mar 2021 14:47:02 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path [v3]
In-Reply-To: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
Message-ID: <htJNRSnk_GKJ2xpbRQ4BxLELrf7ajx3RODyxPFiGDwI=.4a94605f-66f0-433d-bce5-b5f822b8bc96@github.com>

> when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory.

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8261518: jpackage looks for main module in current dir when there is no module-path

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2781/files
  - new: https://git.openjdk.java.net/jdk/pull/2781/files/f800c99f..a96d962c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2781&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2781&range=01-02

  Stats: 18 lines in 1 file changed: 1 ins; 15 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2781.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2781/head:pull/2781

PR: https://git.openjdk.java.net/jdk/pull/2781

From herrick at openjdk.java.net  Wed Mar  3 14:50:07 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 3 Mar 2021 14:50:07 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path [v4]
In-Reply-To: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
Message-ID: <X0mq3V3SIS9Rjo9EOC-qSaAG6Vgn5K3jFHCZiDdhV80=.575afaf7-8993-41c1-8c45-5b23e653d938@github.com>

> when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory.

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8261518: jpackage looks for main module in current dir when there is no module-path

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2781/files
  - new: https://git.openjdk.java.net/jdk/pull/2781/files/a96d962c..fa5b3622

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2781&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2781&range=02-03

  Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2781.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2781/head:pull/2781

PR: https://git.openjdk.java.net/jdk/pull/2781

From herrick at openjdk.java.net  Wed Mar  3 14:50:08 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 3 Mar 2021 14:50:08 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path [v2]
In-Reply-To: <qjerVOxv5R9iVv_L2uKKyQfW4NoR3TDIqw1xNxJMZwY=.8c356a92-73aa-442a-a4fb-6da4a21e6695@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
 <m72-a53qYGt1PDIpuVy_IL-pFPh8QYlFhBFY9XWdnlE=.b4bcefc9-cec4-4fc3-ad05-45c5a2bcea13@github.com>
 <qjerVOxv5R9iVv_L2uKKyQfW4NoR3TDIqw1xNxJMZwY=.8c356a92-73aa-442a-a4fb-6da4a21e6695@github.com>
Message-ID: <a9kb4QqnF_jatIkFhs76AyIABvjpYgw5QY8uGYyRANk=.7c32d420-dbea-4555-aaae-718f166b8d04@github.com>

On Wed, 3 Mar 2021 00:32:24 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8261518: jpackage looks for main module in current dir when there is no module-path
>
> test/jdk/tools/jpackage/share/jdk/jpackage/tests/NoMPathRuntimeTest.java line 66:
> 
>> 64:         final Path tmpdir = TKit.createTempDirectory("tmpdir");
>> 65:         try {
>> 66:             Files.createFile(tmpdir.resolve("tmpfile"));
> 
> Is this leftover from something or on purpose?

yes - was leftover - removed

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

PR: https://git.openjdk.java.net/jdk/pull/2781

From lance.andersen at oracle.com  Wed Mar  3 15:44:32 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 3 Mar 2021 15:44:32 +0000
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
Message-ID: <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>

Hi Jaikiran,

It should not be too difficult to support the options listed below via GNUStyleOptions.

Some other things needed to be defined and agreed upon in order to move forward


  *   The behavior if the path does not exist
  *   If the option is specified more than once on the command line
  *   Clarify the behavior if any of the files exist in the specified target directory.


Once you have a chance to consider the above, please send your proposal back to the alias to continue the discussion

Best
Lance

On Mar 3, 2021, at 5:14 AM, Jaikiran Pai <jai.forums2013 at gmail.com<mailto:jai.forums2013 at gmail.com>> wrote:


Thank you Lance. So I think there's some level of agreement on using -C and --dir (or --directory) for the option names.

Anymore opinion on the directory creation semantics and any other aspects to consider?

-Jaikiran

On 28/02/21 5:38 pm, Lance Andersen wrote:
Hi Jaikiran,

Thank you for this.  I went through this myself yesterday in addition to what you have below here are a few more:

7zip:       -o
Info-zip:  -d  (MacOS version of zip)
Bandzip: -o:{dir}
jpackage: -d ?dest
jlink ?output


Thinking about this some more, I might suggest supporting

-C
?dir
?directory

Best
Lance

On Feb 27, 2021, at 11:19 PM, Jaikiran Pai <jai.forums2013 at gmail.com<mailto:jai.forums2013 at gmail.com>> wrote:

Hello Alan,

On 27/02/21 2:23 pm, Alan Bateman wrote:

Yes, the option name will need to be agreed. It would be useful to enumerate the options that the other tools are using to specify the location where to extract. If you see JBS issues mentioning tar -C not supporting chdir when extracting then it might be Solaris tar, which isn't the same as GNU tar which has different options. It might be better to look at more main stream tools, like unzip although jar -d is already taken. It would be nice if there were some consistency with other tools in the JDK that doing extracting (The jmod and jimage extract commands use use --dir for example).

I had a look at both tar and unzip commands on MacOS and Linux (CentOS) setup that I had access to.

--------------
tar on MacOS:
--------------

tar --version
bsdtar 3.3.2 - libarchive 3.3.2 zlib/1.2.11 liblzma/5.0.5 bz2lib/1.0.6

The version of this tool has:

-C directory, --cd directory, --directory directory
             In c and r mode, this changes the directory before adding the following files.
             In x mode, change directories after opening the archive but before extracting
             entries from the archive.

A command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and extracts the foo.tar.gz from current directory to a target directory /tmp/bar/

--------------
tar on CentOS:
--------------

tar --version
tar (GNU tar) 1.26

This version of the tool has:

Common options:
       -C, --directory=DIR
              change to directory DIR

Although the wording isn't clear that, when used with -x, it extracts to the directory specified in -C, it does indeed behave that way.

Specifically, a command like "tar -xzf foo.tar.gz -C /tmp/bar/" works fine and extracts the foo.tar.gz from current directory to a target directory /tmp/bar/

-------------------------------
unzip on both MacOS and CentOS:
-------------------------------

unzip -v
UnZip 6.00 of 20 April 2009, by Info-ZIP.  Maintained by C. Spieler.

This version of the tool has:

[-d exdir]
              An optional directory to which to extract files.  By default, all files and sub-
              directories are recreated in the current directory; the -d option allows extrac-
              tion in an arbitrary directory (always assuming one has permission to  write  to
              the  directory).  This option need not appear at the end of the command line; it
              is also accepted before the zipfile specification (with  the  normal  options),
              immediately  after  the zipfile specification, or between the file(s) and the -x
              option.  The option and directory may be concatenated without  any  white  space
              between  them,  but  note  that  this may cause normal shell behavior to be sup-
              pressed.  In particular, ``-d ~'' (tilde) is expanded by Unix C shells into  the
              name of the user's home directory, but ``-d~'' is treated as a literal subdirec-
              tory ``~'' of the current directory.

unzip foo.zip -d /tmp/bar/ works fine and extracts the foo.zip from current directory to /tmp/bar/

---------------
jimage and jmod
---------------

The jimage and jmod as you note use the --dir option for extracting to that specified directory.


Those were the tools I looked at. I think using the -d option with -x for the jar command is ruled out since it already is used for a different purpose, although for a different "main" operation of the jar command.

As for using --dir for this new feature, I don't think it alone will be enough. Specifically, I couldn't find a "short form" option for the --dir option in the jimage or jmod commands. For the jar extract feature that we are discussing here, I think having a short form option (in addition to the longer form) is necessary to have it match the usage expectations of similar other options that the jar command exposes. So even if we do choose --dir as the long form option, we would still need a short form for it and since -d is already taken for something else, we would still need to come up with a different one. The short form of this option could be -C (see below).


I think reusing the -C option, for this new feature, perhaps is a good thing. The -C is currently used by the update and create "main" operation of the jar command and the man page for this option states:

-C dir
              When creating (c) or updating (u) a JAR file, this option temporarily changes
              the directory while processing files specified by the file operands. Its
              operation is intended to be similar to the -C option of the UNIX tar utility.For
              example, the following command changes to the classes directory and adds the
              Bar.class file from that directory to my.jar:

              jar uf my.jar -C classes Bar.class
....

Using the -C option would indeed align it with the tar command. For the "long form" of this option, the tar command (both on MacOS and CentOS) uses --directory. For this jar extract feature though, we could perhaps just use --dir to have it align with the jimage and the jmod tools.

So I think the combination of -C (short form) and --dir (long form) would perhaps be suitable for this feature.



There are other discussion points around the behavior when the target directory exists or does not exist, to ensure there is some consistency with main stream tools.

I'm guessing you mean the behaviour of creating a directory (or a hierarchy of directories) if the target directory is not present? My testing with the tar tool (both on MacOS and CentOS) shows that if the specified target directory doesn't exist, then the extract fails. The tar extract command doesn't create the target directory during extract. On the other hand, the unzip tool, does create the directory if it doesn't exist. However, interestingly, the unzip tool creates only one level of that directory if it doesn't exist. Specifically, if you specify:

unzip foo.zip -d /tmp/blah/

and if "blah/" isn't a directory inside /tmp/ directory, then it creates the "blah/" directory inside /tmp/ and then extracts the contents of the zip into it.

However,

unzip foo.zip -d /tmp/blah/hello/

and if "blah/" isn't a directory inside /tmp/ directory, then this command fails with an error and it doesn't create the hierarchy of the target directories.

Coming to the jimage and the jmod commands, both these commands create the entire directory hierarchy if the target directory specified during extract, using --dir, doesn't exist. So a command like:

jimage extract --dir /tmp/blah/foo/bar/ jdkmodules

will create the blah/foo/bar/ directory hierarchy if blah doesn't exist in /tmp/, while extracting the "jdkmodules" image.

From the user point of view, I think this behaviour of creating the directories if the target directory doesn't exist, is probably the most intuitive and useful and if we did decide to use this approach for this new option for jar extract command, then it would align with what we already do in jimage and jmod commands.

One another minor detail, while we are at this, is that, IMO we should let the jar extract command to continue to behave the way it currently does when it comes to overwriting existing files. If the jar being extracted contains a file by the same name, in the target directory (hierarchy) then it should continue to overwrite that file. In other words, I don't think we should change the way the jar extract command currently behaves where it overwrites existing files when extracting.


-Jaikiran



<oracle_sig_logo.gif>



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>




[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>




From isipka at openjdk.java.net  Wed Mar  3 15:55:03 2021
From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Wed, 3 Mar 2021 15:55:03 GMT
Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v14]
In-Reply-To: <Idcz1uT7CMcM5WM3JKoekIxUS_eLcnAzYXxhz-zJjtE=.5c22a60d-14a1-426d-a63d-06cb42f1718d@github.com>
References: <Idcz1uT7CMcM5WM3JKoekIxUS_eLcnAzYXxhz-zJjtE=.5c22a60d-14a1-426d-a63d-06cb42f1718d@github.com>
Message-ID: <_9FIWEqXk0PSS9yquhFjr9UTW2-WJsbA8BqsxwE7vWM=.49180560-7fca-483b-8541-62481b8faced@github.com>

> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test.

Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision:

  8166026: Refactor java/lang shell tests to java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1577/files
  - new: https://git.openjdk.java.net/jdk/pull/1577/files/80cc5f0b..8cad13df

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=12-13

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

PR: https://git.openjdk.java.net/jdk/pull/1577

From gziemski at openjdk.java.net  Wed Mar  3 16:00:00 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 3 Mar 2021 16:00:00 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v23]
In-Reply-To: <sL7Ru9rbNmfzeX-14ZZdvyVzmjIn3R-NCZypqjU5Amk=.7a077954-920c-46f0-bae2-b646e9b1b6ae@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>
 <sL7Ru9rbNmfzeX-14ZZdvyVzmjIn3R-NCZypqjU5Amk=.7a077954-920c-46f0-bae2-b646e9b1b6ae@github.com>
Message-ID: <SaFPzYzpXuZFUYhDvGg6PQHM-EUrSqbR02H5SzL6OvI=.77d3186b-74a5-404a-950f-95af6a13dabd@github.com>

On Tue, 2 Mar 2021 23:21:28 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Note that `thread` can be NULL here if the signal handler is running in a non-attached thread. If we then perform:
> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) : _thread(thread ? thread : Thread::current()),`
> we call Thread::current() on a non-attached thread and that will assert/crash if we get NULL. Either avoid using WX when the thread is NULL, or else change to use Thread::current_or_null_safe() and ensure all uses have a NULL check.

https://bugs.openjdk.java.net/browse/JDK-8262903 tracks this issue.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From dfuchs at openjdk.java.net  Wed Mar  3 16:32:40 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 3 Mar 2021 16:32:40 GMT
Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v14]
In-Reply-To: <_9FIWEqXk0PSS9yquhFjr9UTW2-WJsbA8BqsxwE7vWM=.49180560-7fca-483b-8541-62481b8faced@github.com>
References: <Idcz1uT7CMcM5WM3JKoekIxUS_eLcnAzYXxhz-zJjtE=.5c22a60d-14a1-426d-a63d-06cb42f1718d@github.com>
 <_9FIWEqXk0PSS9yquhFjr9UTW2-WJsbA8BqsxwE7vWM=.49180560-7fca-483b-8541-62481b8faced@github.com>
Message-ID: <aiXKfcJK6zsNbzLrUwS9GhNUbAAXTsK3bb832M9cNas=.2dec9c9e-4671-4fd3-ac5c-0159974cacdf@github.com>

On Wed, 3 Mar 2021 15:55:03 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

>> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test.
>
> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8166026: Refactor java/lang shell tests to java

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1577

From bpb at openjdk.java.net  Wed Mar  3 17:55:47 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 3 Mar 2021 17:55:47 GMT
Subject: RFR: 8261862: Expand discussion of rationale for BigDecimal
 equals/compareTo semantics
In-Reply-To: <S9X0Dvgt4dKoASkxK59Ht6XnOGMxl8NeUplGoWkLICU=.9cc47a66-4d7f-45a0-a51d-368dc5dc79d3@github.com>
References: <S9X0Dvgt4dKoASkxK59Ht6XnOGMxl8NeUplGoWkLICU=.9cc47a66-4d7f-45a0-a51d-368dc5dc79d3@github.com>
Message-ID: <6jZkJ5dGbVzVHdansLCo7yv8WUTjryaFIF43vA9U1XM=.f8b72240-b533-4447-b4a5-137e4f73e11b@github.com>

On Wed, 3 Mar 2021 07:20:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I considered @stuart-marks previous suggestion during the code review of JDK-8261123 to include a more explicit discussion of why, say, different representations of 2 should not be regarded as equivalent. After contemplating several alternatives, I didn't find anything simpler than Stuart's 2/3 example so I used that as seen in the diff.
> 
> A short digression, BigDecimal supports both fixed-point style and floating-point style rounding. Floating-point rounding primarily replies on the number of precision digits, regards of their scale, while fixed-point style rounding prioritizes the scale. The number of digits of eventual output is a function of number number of digits in the inputs and the number of precision digits in a floating-point style rounding. A floating-point style rounding has a preferred scale, rather than a fixed scale based on the inputs. The fixed-point style divide method used in the example has a scale based on the dividend, allowing a relatively simple expression to show a distinction between 2.0 and 2.00.

src/java.base/share/classes/java/math/BigDecimal.java line 3146:

> 3144:      * method since the former has [{@code BigInteger},
> 3145:      * {@code scale}] components equal to [20, 1] while the latter has
> 3146:      * components equals to [200, 2].

s/equals/equal/

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

PR: https://git.openjdk.java.net/jdk/pull/2804

From gziemski at openjdk.java.net  Wed Mar  3 17:56:15 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Wed, 3 Mar 2021 17:56:15 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
Message-ID: <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>

On Tue, 2 Mar 2021 11:05:20 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> For platform files that were copied from other ports to this port, if the file wasn't
>> changed I presume the copyright years are left alone. If the file required changes
>> for this port, I expect the year to be updated to 2021. How are you verifying that
>> these copyright years are being properly managed on the new files?
>> 
>> For the new W^X helpers, e.g., WXWriteFromExecSetter, a short comment
>> explaining why one was landed in a particular place would help reviewers.
>> Also see my comment about creating a new ThreadToNativeWithWXExecFromVM
>> helper.
>> 
>> I'm stopping my review with all the src/hotspot files done for now.
>
>> For platform files that were copied from other ports to this port, if the file wasn't
>> changed I presume the copyright years are left alone. If the file required changes
>> for this port, I expect the year to be updated to 2021. How are you verifying that
>> these copyright years are being properly managed on the new files?
> 
> There are no exact copies, based on
> git -c diff.renameLimit=10000000 diff --find-copies-harder -C75% --name-status upstream/master...
> 
> So every file changed in the branch potentially needs the copyright update. All file diffs are not trivial, IMHO.
> 
> I'll run the copyright update after we fix a few remaining issues with the PR, to avoid updating copyright and changing/reverting the actual content.

A list of the bugs that our internal testing revealed so far:

https://bugs.openjdk.java.net/browse/JDK-8262952
https://bugs.openjdk.java.net/browse/JDK-8262894
https://bugs.openjdk.java.net/browse/JDK-8262895
https://bugs.openjdk.java.net/browse/JDK-8262896
https://bugs.openjdk.java.net/browse/JDK-8262897
https://bugs.openjdk.java.net/browse/JDK-8262898
https://bugs.openjdk.java.net/browse/JDK-8262899
https://bugs.openjdk.java.net/browse/JDK-8262900
https://bugs.openjdk.java.net/browse/JDK-8262901
https://bugs.openjdk.java.net/browse/JDK-8262903
https://bugs.openjdk.java.net/browse/JDK-8262904

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From aph at openjdk.java.net  Wed Mar  3 17:56:15 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Wed, 3 Mar 2021 17:56:15 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
Message-ID: <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>

On Wed, 3 Mar 2021 17:39:28 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> A list of the bugs that our internal testing revealed so far:

Are any of these blockers for integration? Some of them are to do with things like features that aren't yet supported, and we can't fix what we can't see.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From jlaskey at openjdk.java.net  Wed Mar  3 17:57:11 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 3 Mar 2021 17:57:11 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v28]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <HhpSYS5MH2mQ_PWhinZSN8VjTqPhNUigD8bTsgsNPno=.9adb44fd-bda6-4bbd-837a-0bb276aa9d18@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Use isAnnotationPresent

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/7439c2ba..345a17cc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=27
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=26-27

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From bchristi at openjdk.java.net  Wed Mar  3 18:13:41 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 3 Mar 2021 18:13:41 GMT
Subject: RFR: 8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException
In-Reply-To: <M_HI6rHAd36Rsy0ZS_ya3iFig0vZcyO_s9aK11a2j48=.7513689b-a106-4238-8b6a-f6d0de2109e5@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <M_HI6rHAd36Rsy0ZS_ya3iFig0vZcyO_s9aK11a2j48=.7513689b-a106-4238-8b6a-f6d0de2109e5@github.com>
Message-ID: <iKdskMjHNKUrtpQW8tVlLXeasNBbE54041OYUPpTahA=.6bbe649a-25d6-4a79-af08-5a237ffcdfc8@github.com>

On Wed, 3 Mar 2021 14:28:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> _NOTE_: I've reported this issue at https://bugreport.java.com/ (internal review ID : 9069151)
>> 
>> `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.
>> 
>> According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.
>> 
>> Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>>> Returns:
>>>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.
>> 
>> And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>>> Returns:
>>>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.
>> 
>> Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.
>> 
>> Here's a stack trace:
>> java.lang.IllegalArgumentException: name
>>         at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>>         at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>>         at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
>> 
>> Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>>         URL findResource(final String name, boolean check) {
>>             URL url;
>>             try {
>>                 url = new URL(base, ParseUtil.encodePath(name, false));
>>             } catch (MalformedURLException e) {
>>                 throw new IllegalArgumentException("name");
>>             }
>> 
>> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
>> 
>> A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>>         URL findResource(final String name, boolean check) {
>>             URL url;
>>             try {
>>                 url = new URL(base, ParseUtil.encodePath(name, false));
>>             } catch (MalformedURLException e) {
>>                 throw new IllegalArgumentException("name");
>>             }
>> 
>> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
>
> This seems to be a long standing bug, maybe goes all the way back to JDK 1.2. Are you planning to add a regression test?

Hi, Craig
The commented-out lines should be removed from the change.

As Alan said, a regression test will be needed.  At minimum, it should test a method that returns a URL, as well as a method that returns an Enumeration<URL> (which can also lead to an IAE, as I noted in the bug report).

Also, though the compatibility risk is low, it would be good to include a CSR for this change to long-standing behavior.

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From bchristi at openjdk.java.net  Wed Mar  3 18:20:42 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 3 Mar 2021 18:20:42 GMT
Subject: RFR: 8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException
In-Reply-To: <iKdskMjHNKUrtpQW8tVlLXeasNBbE54041OYUPpTahA=.6bbe649a-25d6-4a79-af08-5a237ffcdfc8@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <M_HI6rHAd36Rsy0ZS_ya3iFig0vZcyO_s9aK11a2j48=.7513689b-a106-4238-8b6a-f6d0de2109e5@github.com>
 <iKdskMjHNKUrtpQW8tVlLXeasNBbE54041OYUPpTahA=.6bbe649a-25d6-4a79-af08-5a237ffcdfc8@github.com>
Message-ID: <ZlbcrUa-o2d02_j3-9wTncf66fHEGITHJZrLWXLKY0I=.cdfd1453-49da-40bf-af63-5c67bf9915ba@github.com>

On Wed, 3 Mar 2021 18:10:25 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> This seems to be a long standing bug, maybe goes all the way back to JDK 1.2. Are you planning to add a regression test?
>
> Hi, Craig
> The commented-out lines should be removed from the change.
> 
> As Alan said, a regression test will be needed.  At minimum, it should test a method that returns a URL, as well as a method that returns an Enumeration<URL> (which can also lead to an IAE, as I noted in the bug report).
> 
> Also, though the compatibility risk is low, it would be good to include a CSR for this change to long-standing behavior.

Also, the copyright year should be updated: 2019 -> 2021

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From smarks at openjdk.java.net  Wed Mar  3 18:24:43 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 3 Mar 2021 18:24:43 GMT
Subject: RFR: 8261862: Expand discussion of rationale for BigDecimal
 equals/compareTo semantics
In-Reply-To: <S9X0Dvgt4dKoASkxK59Ht6XnOGMxl8NeUplGoWkLICU=.9cc47a66-4d7f-45a0-a51d-368dc5dc79d3@github.com>
References: <S9X0Dvgt4dKoASkxK59Ht6XnOGMxl8NeUplGoWkLICU=.9cc47a66-4d7f-45a0-a51d-368dc5dc79d3@github.com>
Message-ID: <uUsoc98DVZANmjXoHZTdyBoNqj0YOC3heJ5KsxHufFY=.3d186b1e-a01b-4196-83f7-57e552b201ba@github.com>

On Wed, 3 Mar 2021 07:20:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I considered @stuart-marks previous suggestion during the code review of JDK-8261123 to include a more explicit discussion of why, say, different representations of 2 should not be regarded as equivalent. After contemplating several alternatives, I didn't find anything simpler than Stuart's 2/3 example so I used that as seen in the diff.
> 
> A short digression, BigDecimal supports both fixed-point style and floating-point style rounding. Floating-point rounding primarily replies on the number of precision digits, regards of their scale, while fixed-point style rounding prioritizes the scale. The number of digits of eventual output is a function of number number of digits in the inputs and the number of precision digits in a floating-point style rounding. A floating-point style rounding has a preferred scale, rather than a fixed scale based on the inputs. The fixed-point style divide method used in the example has a scale based on the dividend, allowing a relatively simple expression to show a distinction between 2.0 and 2.00.

Marked as reviewed by smarks (Reviewer).

src/java.base/share/classes/java/math/BigDecimal.java line 3155:

> 3153:      * {@code new BigDecimal("2.00").divide(BigDecimal.valueOf(3),
> 3154:      * HALF_UP)} which evaluates to 0.<b>6</b>7.
> 3155:      *

Should this be in an `@apiNote`?

I'm not sure adding the boldface 0.**6**7 is helpful; 0.7 is self-evidently unequal to 0.67.

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

PR: https://git.openjdk.java.net/jdk/pull/2804

From bpb at openjdk.java.net  Wed Mar  3 18:24:43 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 3 Mar 2021 18:24:43 GMT
Subject: RFR: 8261862: Expand discussion of rationale for BigDecimal
 equals/compareTo semantics
In-Reply-To: <S9X0Dvgt4dKoASkxK59Ht6XnOGMxl8NeUplGoWkLICU=.9cc47a66-4d7f-45a0-a51d-368dc5dc79d3@github.com>
References: <S9X0Dvgt4dKoASkxK59Ht6XnOGMxl8NeUplGoWkLICU=.9cc47a66-4d7f-45a0-a51d-368dc5dc79d3@github.com>
Message-ID: <LFZgN2tHNjviFKXvlOnoTxWC9CyDPi1vPjOjYRarKhY=.a7847816-adee-4f58-a4dd-10064be7fb9e@github.com>

On Wed, 3 Mar 2021 07:20:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I considered @stuart-marks previous suggestion during the code review of JDK-8261123 to include a more explicit discussion of why, say, different representations of 2 should not be regarded as equivalent. After contemplating several alternatives, I didn't find anything simpler than Stuart's 2/3 example so I used that as seen in the diff.
> 
> A short digression, BigDecimal supports both fixed-point style and floating-point style rounding. Floating-point rounding primarily replies on the number of precision digits, regards of their scale, while fixed-point style rounding prioritizes the scale. The number of digits of eventual output is a function of number number of digits in the inputs and the number of precision digits in a floating-point style rounding. A floating-point style rounding has a preferred scale, rather than a fixed scale based on the inputs. The fixed-point style divide method used in the example has a scale based on the dividend, allowing a relatively simple expression to show a distinction between 2.0 and 2.00.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2804

From iignatyev at openjdk.java.net  Wed Mar  3 18:28:44 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 3 Mar 2021 18:28:44 GMT
Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v14]
In-Reply-To: <_9FIWEqXk0PSS9yquhFjr9UTW2-WJsbA8BqsxwE7vWM=.49180560-7fca-483b-8541-62481b8faced@github.com>
References: <Idcz1uT7CMcM5WM3JKoekIxUS_eLcnAzYXxhz-zJjtE=.5c22a60d-14a1-426d-a63d-06cb42f1718d@github.com>
 <_9FIWEqXk0PSS9yquhFjr9UTW2-WJsbA8BqsxwE7vWM=.49180560-7fca-483b-8541-62481b8faced@github.com>
Message-ID: <4flFoeiAy7xBCqygoMFsZFJJabk66wd75NgbdbTl3UM=.b44eda29-afb2-48b1-b6f8-ab852d29c0ee@github.com>

On Wed, 3 Mar 2021 15:55:03 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

>> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test.
>
> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8166026: Refactor java/lang shell tests to java

test/jdk/java/lang/annotation/LoaderLeakTest.java line 74:

> 72:             catch (NullPointerException npe) {
> 73:                 throw new AssertionError("c.get() should never return null", npe);
> 74:             }

I don't think it's the right way to handle that, you don't know if this NPE is from `c.get`, so the exception messages might be misleading. I'd just remove try/catch, if NPE occurs jtreg will report the test as failed w/ NPE as a reason, so whoever analyzes it will be able to understand.

alternatively, you can save c.get into a local variable which you nulls later one, e.g.
 ```
static void doTest(boolean readAnn) throws Exception {
...
var tmp = c.get();
if (t == null) throw new AssertionError("c.get is null");
if (t.getClassLoader() != loader) throw new AssertionError("wrong classloader");
t = null;

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

PR: https://git.openjdk.java.net/jdk/pull/1577

From akozlov at openjdk.java.net  Wed Mar  3 19:13:59 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Wed, 3 Mar 2021 19:13:59 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
Message-ID: <_eNysRZporueV4wITFZra8ng_O6dvxAIc0moIWOh95U=.bd3e669d-8efc-41e1-8fb2-e9f2f8e4d1f8@github.com>

On Wed, 3 Mar 2021 17:46:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> A list of the bugs that our internal testing revealed so far ...

Thank you! Some of them look like test issues, but a few need more serious consideration. I want to resolve https://bugs.openjdk.java.net/browse/JDK-8262903 at least, along with a few remaining comments.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From darcy at openjdk.java.net  Wed Mar  3 19:33:14 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 3 Mar 2021 19:33:14 GMT
Subject: RFR: 8261862: Expand discussion of rationale for BigDecimal
 equals/compareTo semantics [v2]
In-Reply-To: <S9X0Dvgt4dKoASkxK59Ht6XnOGMxl8NeUplGoWkLICU=.9cc47a66-4d7f-45a0-a51d-368dc5dc79d3@github.com>
References: <S9X0Dvgt4dKoASkxK59Ht6XnOGMxl8NeUplGoWkLICU=.9cc47a66-4d7f-45a0-a51d-368dc5dc79d3@github.com>
Message-ID: <TdSyzURqYNEX7Fe2i7WxZ8TKe9iWZ8PpBRP23aOESho=.2e59e48e-e56a-47d7-a191-97803624b680@github.com>

> I considered @stuart-marks previous suggestion during the code review of JDK-8261123 to include a more explicit discussion of why, say, different representations of 2 should not be regarded as equivalent. After contemplating several alternatives, I didn't find anything simpler than Stuart's 2/3 example so I used that as seen in the diff.
> 
> A short digression, BigDecimal supports both fixed-point style and floating-point style rounding. Floating-point rounding primarily replies on the number of precision digits, regards of their scale, while fixed-point style rounding prioritizes the scale. The number of digits of eventual output is a function of number number of digits in the inputs and the number of precision digits in a floating-point style rounding. A floating-point style rounding has a preferred scale, rather than a fixed scale based on the inputs. The fixed-point style divide method used in the example has a scale based on the dividend, allowing a relatively simple expression to show a distinction between 2.0 and 2.00.

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

 - Respond to review feedback and reflow paragraphs.
 - Merge branch 'master' into 8261862
 - 8261862: Expand discussion of rationale for BigDecimal equals/compareTo semantics

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2804/files
  - new: https://git.openjdk.java.net/jdk/pull/2804/files/48b49386..75b27c3f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2804&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2804&range=00-01

  Stats: 774 lines in 17 files changed: 703 ins; 13 del; 58 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2804.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2804/head:pull/2804

PR: https://git.openjdk.java.net/jdk/pull/2804

From darcy at openjdk.java.net  Wed Mar  3 19:33:16 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 3 Mar 2021 19:33:16 GMT
Subject: RFR: 8261862: Expand discussion of rationale for BigDecimal
 equals/compareTo semantics [v2]
In-Reply-To: <uUsoc98DVZANmjXoHZTdyBoNqj0YOC3heJ5KsxHufFY=.3d186b1e-a01b-4196-83f7-57e552b201ba@github.com>
References: <S9X0Dvgt4dKoASkxK59Ht6XnOGMxl8NeUplGoWkLICU=.9cc47a66-4d7f-45a0-a51d-368dc5dc79d3@github.com>
 <uUsoc98DVZANmjXoHZTdyBoNqj0YOC3heJ5KsxHufFY=.3d186b1e-a01b-4196-83f7-57e552b201ba@github.com>
Message-ID: <AXWatq4jR6w9nDaZ8yndAuaEd4KEyZlXqMmEgmHDTFA=.646b63db-3d8a-4977-9d1b-2d9e1acb9f17@github.com>

On Wed, 3 Mar 2021 18:19:33 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Respond to review feedback and reflow paragraphs.
>>  - Merge branch 'master' into 8261862
>>  - 8261862: Expand discussion of rationale for BigDecimal equals/compareTo semantics
>
> src/java.base/share/classes/java/math/BigDecimal.java line 3155:
> 
>> 3153:      * {@code new BigDecimal("2.00").divide(BigDecimal.valueOf(3),
>> 3154:      * HALF_UP)} which evaluates to 0.<b>6</b>7.
>> 3155:      *
> 
> Should this be in an `@apiNote`?
> 
> I'm not sure adding the boldface 0.**6**7 is helpful; 0.7 is self-evidently unequal to 0.67.

Changed as suggested in final version.

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

PR: https://git.openjdk.java.net/jdk/pull/2804

From darcy at openjdk.java.net  Wed Mar  3 19:33:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 3 Mar 2021 19:33:18 GMT
Subject: RFR: 8261862: Expand discussion of rationale for BigDecimal
 equals/compareTo semantics [v2]
In-Reply-To: <6jZkJ5dGbVzVHdansLCo7yv8WUTjryaFIF43vA9U1XM=.f8b72240-b533-4447-b4a5-137e4f73e11b@github.com>
References: <S9X0Dvgt4dKoASkxK59Ht6XnOGMxl8NeUplGoWkLICU=.9cc47a66-4d7f-45a0-a51d-368dc5dc79d3@github.com>
 <6jZkJ5dGbVzVHdansLCo7yv8WUTjryaFIF43vA9U1XM=.f8b72240-b533-4447-b4a5-137e4f73e11b@github.com>
Message-ID: <vmpcippWTU6XLqvHOVutfGs7deoQce2128hHFwBJyxk=.65e2cd9a-c89e-47a1-a856-b273e082e743@github.com>

On Wed, 3 Mar 2021 17:49:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Respond to review feedback and reflow paragraphs.
>>  - Merge branch 'master' into 8261862
>>  - 8261862: Expand discussion of rationale for BigDecimal equals/compareTo semantics
>
> src/java.base/share/classes/java/math/BigDecimal.java line 3146:
> 
>> 3144:      * method since the former has [{@code BigInteger},
>> 3145:      * {@code scale}] components equal to [20, 1] while the latter has
>> 3146:      * components equals to [200, 2].
> 
> s/equals/equal/

Fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/2804

From darcy at openjdk.java.net  Wed Mar  3 19:33:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 3 Mar 2021 19:33:18 GMT
Subject: Integrated: 8261862: Expand discussion of rationale for BigDecimal
 equals/compareTo semantics
In-Reply-To: <S9X0Dvgt4dKoASkxK59Ht6XnOGMxl8NeUplGoWkLICU=.9cc47a66-4d7f-45a0-a51d-368dc5dc79d3@github.com>
References: <S9X0Dvgt4dKoASkxK59Ht6XnOGMxl8NeUplGoWkLICU=.9cc47a66-4d7f-45a0-a51d-368dc5dc79d3@github.com>
Message-ID: <fz_GuUJTIGq3hrSr5dtcqpPwip_ap30xzfmEPwsosyU=.15e12722-f538-446c-863c-66934c3dbd7f@github.com>

On Wed, 3 Mar 2021 07:20:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> I considered @stuart-marks previous suggestion during the code review of JDK-8261123 to include a more explicit discussion of why, say, different representations of 2 should not be regarded as equivalent. After contemplating several alternatives, I didn't find anything simpler than Stuart's 2/3 example so I used that as seen in the diff.
> 
> A short digression, BigDecimal supports both fixed-point style and floating-point style rounding. Floating-point rounding primarily replies on the number of precision digits, regards of their scale, while fixed-point style rounding prioritizes the scale. The number of digits of eventual output is a function of number number of digits in the inputs and the number of precision digits in a floating-point style rounding. A floating-point style rounding has a preferred scale, rather than a fixed scale based on the inputs. The fixed-point style divide method used in the example has a scale based on the dividend, allowing a relatively simple expression to show a distinction between 2.0 and 2.00.

This pull request has now been integrated.

Changeset: a1181852
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a1181852
Stats:     19 lines in 1 file changed: 11 ins; 0 del; 8 mod

8261862: Expand discussion of rationale for BigDecimal equals/compareTo semantics

Reviewed-by: smarks, bpb

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

PR: https://git.openjdk.java.net/jdk/pull/2804

From isipka at openjdk.java.net  Wed Mar  3 19:56:07 2021
From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Wed, 3 Mar 2021 19:56:07 GMT
Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v15]
In-Reply-To: <Idcz1uT7CMcM5WM3JKoekIxUS_eLcnAzYXxhz-zJjtE=.5c22a60d-14a1-426d-a63d-06cb42f1718d@github.com>
References: <Idcz1uT7CMcM5WM3JKoekIxUS_eLcnAzYXxhz-zJjtE=.5c22a60d-14a1-426d-a63d-06cb42f1718d@github.com>
Message-ID: <h0NBGYeM83EZkp6THfYbV9TuQpVqASJGre6_4wBbIC8=.0dd3baec-87fb-4b2f-9016-5b156c8f4afb@github.com>

> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test.

Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision:

  8166026: Refactor java/lang shell tests to java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1577/files
  - new: https://git.openjdk.java.net/jdk/pull/1577/files/8cad13df..b548e39f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1577&range=13-14

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

PR: https://git.openjdk.java.net/jdk/pull/1577

From isipka at openjdk.java.net  Wed Mar  3 19:56:08 2021
From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Wed, 3 Mar 2021 19:56:08 GMT
Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v14]
In-Reply-To: <4flFoeiAy7xBCqygoMFsZFJJabk66wd75NgbdbTl3UM=.b44eda29-afb2-48b1-b6f8-ab852d29c0ee@github.com>
References: <Idcz1uT7CMcM5WM3JKoekIxUS_eLcnAzYXxhz-zJjtE=.5c22a60d-14a1-426d-a63d-06cb42f1718d@github.com>
 <_9FIWEqXk0PSS9yquhFjr9UTW2-WJsbA8BqsxwE7vWM=.49180560-7fca-483b-8541-62481b8faced@github.com>
 <4flFoeiAy7xBCqygoMFsZFJJabk66wd75NgbdbTl3UM=.b44eda29-afb2-48b1-b6f8-ab852d29c0ee@github.com>
Message-ID: <XsNDAYn8jOfFMej4_6Jn6TOPJ52UYbhlzKoBE60Ksno=.94d3bc9d-ba00-4bbe-bea9-896c9a1f0982@github.com>

On Wed, 3 Mar 2021 18:26:19 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8166026: Refactor java/lang shell tests to java
>
> test/jdk/java/lang/annotation/LoaderLeakTest.java line 74:
> 
>> 72:             catch (NullPointerException npe) {
>> 73:                 throw new AssertionError("c.get() should never return null", npe);
>> 74:             }
> 
> I don't think it's the right way to handle that, you don't know if this NPE is from `c.get`, so the exception messages might be misleading. I'd just remove try/catch, if NPE occurs jtreg will report the test as failed w/ NPE as a reason, so whoever analyzes it will be able to understand.
> 
> alternatively, you can save c.get into a local variable which you nulls later one, e.g.
>  ```
> static void doTest(boolean readAnn) throws Exception {
> ...
> var tmp = c.get();
> if (t == null) throw new AssertionError("c.get is null");
> if (t.getClassLoader() != loader) throw new AssertionError("wrong classloader");
> t = null;

@iignatev I just reemove the try catch I think the comments are informative and will help with analysis with potential NPE

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

PR: https://git.openjdk.java.net/jdk/pull/1577

From iignatyev at openjdk.java.net  Wed Mar  3 19:58:42 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Wed, 3 Mar 2021 19:58:42 GMT
Subject: RFR: 8259267: Refactor LoaderLeak shell test as java test. [v15]
In-Reply-To: <h0NBGYeM83EZkp6THfYbV9TuQpVqASJGre6_4wBbIC8=.0dd3baec-87fb-4b2f-9016-5b156c8f4afb@github.com>
References: <Idcz1uT7CMcM5WM3JKoekIxUS_eLcnAzYXxhz-zJjtE=.5c22a60d-14a1-426d-a63d-06cb42f1718d@github.com>
 <h0NBGYeM83EZkp6THfYbV9TuQpVqASJGre6_4wBbIC8=.0dd3baec-87fb-4b2f-9016-5b156c8f4afb@github.com>
Message-ID: <-nq2pFi8sGqXEky0NcncTMSPIfgLur9pt4fftrw5ZTY=.68a02595-b395-4389-9ac7-8c7915eb459b@github.com>

On Wed, 3 Mar 2021 19:56:07 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

>> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test.
>
> Ivan ?ipka has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8166026: Refactor java/lang shell tests to java

Marked as reviewed by iignatyev (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/1577

From isipka at openjdk.java.net  Wed Mar  3 20:05:45 2021
From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Wed, 3 Mar 2021 20:05:45 GMT
Subject: Integrated: 8259267: Refactor LoaderLeak shell test as java test.
In-Reply-To: <Idcz1uT7CMcM5WM3JKoekIxUS_eLcnAzYXxhz-zJjtE=.5c22a60d-14a1-426d-a63d-06cb42f1718d@github.com>
References: <Idcz1uT7CMcM5WM3JKoekIxUS_eLcnAzYXxhz-zJjtE=.5c22a60d-14a1-426d-a63d-06cb42f1718d@github.com>
Message-ID: <lIbKS05NgkBFe_o_yYqQTzV6WYE1eUgBV6tKXJPeAXo=.a5ebb77e-a60b-4489-8d34-13e9072852cc@github.com>

On Wed, 2 Dec 2020 20:23:13 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> Refactor `test/jdk/java/lang/annotation/loaderLeak/LoaderLeak.sh` as java test.

This pull request has now been integrated.

Changeset: 75aa1546
Author:    Ivan ?ipka <isipka at openjdk.org>
Committer: Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/75aa1546
Stats:     440 lines in 6 files changed: 135 ins; 305 del; 0 mod

8259267: Refactor LoaderLeak shell test as java test.

Reviewed-by: rriggs, iignatyev, dfuchs

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

PR: https://git.openjdk.java.net/jdk/pull/1577

From volker.simonis at gmail.com  Wed Mar  3 20:12:36 2021
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 3 Mar 2021 21:12:36 +0100
Subject: Question about java.system.class.loader and the module system
In-Reply-To: <1c05cc73-7c3b-dadb-ee6f-4b2db7d2dff7@oracle.com>
References: <CA+3eh11wSfe5w7wpfx9r48iFDmdF6yt2=O4fqs0DjB4vMBgFFQ@mail.gmail.com>
 <1c05cc73-7c3b-dadb-ee6f-4b2db7d2dff7@oracle.com>
Message-ID: <CA+3eh13VwLPexL6NPQbkU2fN7WVE51gOUaM+zCDSpW8OPQ4ASA@mail.gmail.com>

Hi Alan,

thanks for the quick response. Please find my answers inline

On Wed, Mar 3, 2021 at 1:38 PM Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> On 03/03/2021 10:43, Volker Simonis wrote:
> > :
> >
> > My question now is if this is an inherent property of the module
> > system or merely an implementation detail? I.e. would it be possible
> > to put the application module into its own layer and initialize that
> > only later when the custom system class loader will be available? I
> > think this would be relatively easy if the custom class loader can be
> > found on the class path. If the custom class loader is in a module
> > itself, that module would have to be in the boot layer to make it
> > accessible to the default system class loader.
> The ability to set a custom class loader as the system class loader is
> somewhat legacy feature. There was consideration given to deprecating
> and removing it a few years ago but we ended up leaving it "as is" in
> case there are still application servers using it. So it should work the
> same in JDK 16 as it did in JDK 8/older releases. That is, it will be
> created with the built-in application class loader as parent and the
> custom system class loader will be the default parent class loader for
> delegation.
>
> You are correct that an initial module on the application module path
> will be loaded by the built-in application class loader. All modules on
> the application module path are mapped to the built-in application class
> loader. If an initial module is specified to the java launcher (--module
> or -m) then it just locates the module in the boot layer and invokes its
> main class. There is no role for a custom system class loader here.
>
> If you are looking to deploy a custom system class loader in a module on
> the module path then it should work as long as you export the package
> with the custom class loader to java.base. I'm not sure if you really
> want to do this or whether it's a means to an end. Maybe it would be
> easier to start with a summary on what you are looking it do? Are you
> looking to intercept all attempts to load classes? Is there a java agent
> in the picture too?

I have currently no specific use case in mind. I was just doing some
experiments and was hoping that I can intercept the loading of all
application classes by defining a custom system class loader. I'm
aware that I can use the JVMTI "ClassFileLoadHook" to intercept the
loading of ALL classes, but that's just a little more complicated :)

> > The current API documentation of the system class loader [1] mentions
> > that the system class loader "is typically the class loader used to
> > start the application". Shouldn't that be updated to mention that this
> > will not be the case for modular applications?
> The javadoc is correct because it will be rare to deploy with
> java.system.class.loader set to a custom class loader. Assuming it is
> not set then you should find that the initial class will be defined by
> this class loader. This goes for both the class path and module path cases.

Maybe I should have been more specific. I meant that the paragraph on
"java.system.class.loader" should contain one more sentence mentioning
that setting it will only have the desired effects for the loading of
application classes for non-modularized applications.

Thank you and best regards,
Volker

>
>
> -Alan
>
>

From asemenyuk at openjdk.java.net  Wed Mar  3 21:30:41 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 3 Mar 2021 21:30:41 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path [v4]
In-Reply-To: <X0mq3V3SIS9Rjo9EOC-qSaAG6Vgn5K3jFHCZiDdhV80=.575afaf7-8993-41c1-8c45-5b23e653d938@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
 <X0mq3V3SIS9Rjo9EOC-qSaAG6Vgn5K3jFHCZiDdhV80=.575afaf7-8993-41c1-8c45-5b23e653d938@github.com>
Message-ID: <3PHW98_-j6GMOJ7P0tJ74tN_GQnuGBnq6Yx61no-NSU=.86ea20e9-0dec-4f20-8062-f160cb0c2f3a@github.com>

On Wed, 3 Mar 2021 14:50:07 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory.
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8261518: jpackage looks for main module in current dir when there is no module-path

Changes requested by asemenyuk (Committer).

test/jdk/tools/jpackage/share/jdk/jpackage/tests/NoMPathRuntimeTest.java line 105:

> 103: 
> 104:         // create a non-modular jar in the current directory
> 105:         HelloApp.createBundle(JavaAppDesc.parse("junk.jar:Hello"), Path.of("."));

Test files must be created in test work directory (`TKit.workDir()`) and not in the current directory. Test harness creates empty work directory for every test run. In case of running this test multiple times and if previous test execution was aborted "junk.jar" will be in the current directory from the previous test run and the next test run will fail. 
Running test multiple times without running clean up is the case when the test is executed in IDE under debugger and debugging session is aborted.
If you absolutely must create "junk.jar" in the current directory, you need to remove it manually. Something like this:
Path junkJar = null;
try {
  junkJar = HelloApp.createBundle(JavaAppDesc.parse("junk.jar:Hello"), Path.of("."));
  ...
  cmd.executeAndAssertHelloAppImageCreated();
} finally {
    if (junkJar != null) {
      TKit.deleteIfExists(junkJar);
    }
}

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

PR: https://git.openjdk.java.net/jdk/pull/2781

From asemenyuk at openjdk.java.net  Wed Mar  3 21:41:41 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 3 Mar 2021 21:41:41 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path [v2]
In-Reply-To: <eQXU8nvluB_AFTuIuEgexOoCTIdTi-MCidUVO6ZR3y0=.64cc5f9a-f371-451b-8b18-64e410160280@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
 <m72-a53qYGt1PDIpuVy_IL-pFPh8QYlFhBFY9XWdnlE=.b4bcefc9-cec4-4fc3-ad05-45c5a2bcea13@github.com>
 <qjerVOxv5R9iVv_L2uKKyQfW4NoR3TDIqw1xNxJMZwY=.8c356a92-73aa-442a-a4fb-6da4a21e6695@github.com>
 <eQXU8nvluB_AFTuIuEgexOoCTIdTi-MCidUVO6ZR3y0=.64cc5f9a-f371-451b-8b18-64e410160280@github.com>
Message-ID: <wcM22HAGUc0G3_KqBURQJ3OtXEiOyp8x6QMctXPJRfQ=.0d02d574-4899-4d16-b290-820ac4639ea6@github.com>

On Wed, 3 Mar 2021 13:56:01 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> test/jdk/tools/jpackage/share/jdk/jpackage/tests/NoMPathRuntimeTest.java line 125:
>> 
>>> 123:                 .addArguments("-cvf", "junk.jar",
>>> 124:                         "-C", tmpdir.toString(), "Hello.class")
>>> 125:                 .execute();
>> 
>> Single line `HelloApp.createBundle("junk.jar:Hello", tmpdir);` would compile source class and put it into "junk.jar" in `tmpdir` folder. It can be used to replace lines from [109, 125] range.
>> 
>> What is the point to build "junk.jar"? I don't see how it is used in the test.
>
> The bug is that when --module-path option is not used in a modular app, jpackage uses a module-path with "." on it.
> Having a non-modular jar in the modular path is an error.
> So with this non-modular Hello.jar in the current directory the jpackage command failed before the fix, and succeeds after the fix.
> 
> I can create the non-modular Hello.jar in the current directory with one line:
> HelloApp.createBundle(JavaAppDesc.parse("junk.jar:Hello"), Path.of("."))

Another precondition for the test is that Java runtime used with jpackage command should include module with app main class, right?
Test arguments are: `List.of("Hello", "com.foo/com.foo.main.Aloha");`. The first argument is non-modular app, it is not used with jlink. What is the point to run the test for non-modular app?

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

PR: https://git.openjdk.java.net/jdk/pull/2781

From yano-masanori at fujitsu.com  Wed Mar  3 07:24:33 2021
From: yano-masanori at fujitsu.com (yano-masanori at fujitsu.com)
Date: Wed, 3 Mar 2021 07:24:33 +0000
Subject: [PING] RE: [PING] RE: 8250678: ModuleDescriptor.Version parsing
 treats empty segments inconsistently
Message-ID: <TYCPR01MB58233C054375564C30882E30E7989@TYCPR01MB5823.jpnprd01.prod.outlook.com>

Hello,

Please reply if anyone can be a sponsor.

Regards,
Masanori Yano

> -----Original Message-----
> From: Yano, Masanori 
> Sent: Tuesday, January 12, 2021 4:32 PM
> To: 'core-libs-dev at openjdk.java.net' <core-libs-dev at openjdk.java.net>
> Subject: RE: [PING] RE: 8250678: ModuleDescriptor.Version parsing treats empty
> segments inconsistently
> 
> Hello,
> 
> Please reply if anyone can be a sponsor.
> 
> Regards,
> Masanori Yano
> 
> > -----Original Message-----
> > From: Yano, Masanori
> > Sent: Wednesday, December 23, 2020 5:01 PM
> > To: 'core-libs-dev at openjdk.java.net' <core-libs-dev at openjdk.java.net>
> > Subject: [PING] RE: 8250678: ModuleDescriptor.Version parsing treats
> > empty segments inconsistently
> >
> > Hello,
> >
> > Please reply if anyone can be a sponsor.
> >
> > Regards,
> > Masanori Yano
> >
> > > -----Original Message-----
> > > From: Yano, Masanori
> > > Sent: Wednesday, November 4, 2020 6:03 PM
> > > To: 'core-libs-dev at openjdk.java.net'
> > > <core-libs-dev at openjdk.java.net>
> > > Subject: 8250678: ModuleDescriptor.Version parsing treats empty
> > > segments inconsistently
> > >
> > > Hello.
> > >
> > > I would like to contribute for JDK-8250678.
> > >
> > > The 'parse' method of ModuleDescriptor.Version class behaves
> > > incorrectly when the input string contains consecutive delimiters.
> > >
> > > The 'parse' method treats strings as three sections, but the parsing
> > > method differs between the method for the version sections and the ones for
> others.
> > > In version sections, the 'parse' method takes a single character in
> > > a loop and determines whether it is a delimiter. In pre and build
> > > sections, the parse method takes two characters in a loop and
> > > determines whether
> > the second character is the delimiter.
> > > Therefore, if the string contains a sequence of delimiters in pre or
> > > build section, the 'parse' method treats character at the
> > > odd-numbered position as a token and the one at even-numbered as a
> > > delimiter
> > >
> > > A string containing consecutive delimiters is an incorrect version
> > > string, but this behavior does not follow the API specification.
> > > https://download.java.net/java/early_access/jdk16/docs/api/java.base
> > > /j
> > > ava/lang/
> > > module/ModuleDescriptor.Version.html
> > >
> > > Therefore, I propose to fix the parsing method of the pre section
> > > and the build section in the same way as the version.
> > >
> > > Please sponsor the following change.
> > >
> > > diff -r bdc20ee1a68d
> > > src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
> > > --- a/src/java.base/share/classes/java/lang/module/ModuleDescriptor.java
> > > 	Fri Sep 04 23:51:26 2020 -0400
> > > +++ b/src/java.base/share/classes/java/lang/module/ModuleDescriptor.
> > > +++ ja
> > > +++ va
> > > 	Wed Oct 28 17:06:47 2020 +0900
> > > @@ -1053,13 +1053,6 @@
> > >
> > >              while (i < n) {
> > >                  c = v.charAt(i);
> > > -                if (c >= '0' && c <= '9')
> > > -                    i = takeNumber(v, i, pre);
> > > -                else
> > > -                    i = takeString(v, i, pre);
> > > -                if (i >= n)
> > > -                    break;
> > > -                c = v.charAt(i);
> > >                  if (c == '.' || c == '-') {
> > >                      i++;
> > >                      continue;
> > > @@ -1068,6 +1061,10 @@
> > >                      i++;
> > >                      break;
> > >                  }
> > > +                if (c >= '0' && c <= '9')
> > > +                    i = takeNumber(v, i, pre);
> > > +                else
> > > +                    i = takeString(v, i, pre);
> > >              }
> > >
> > >              if (c == '+' && i >= n) @@ -1075,17 +1072,14 @@
> > >
> > >              while (i < n) {
> > >                  c = v.charAt(i);
> > > +                if (c == '.' || c == '-' || c == '+') {
> > > +                    i++;
> > > +                    continue;
> > > +                }
> > >                  if (c >= '0' && c <= '9')
> > >                      i = takeNumber(v, i, build);
> > >                  else
> > >                      i = takeString(v, i, build);
> > > -                if (i >= n)
> > > -                    break;
> > > -                c = v.charAt(i);
> > > -                if (c == '.' || c == '-' || c == '+') {
> > > -                    i++;
> > > -                    continue;
> > > -                }
> > >              }
> > >
> > >              this.version = v;
> > > diff -r bdc20ee1a68d test/jdk/java/lang/module/VersionTest.java
> > > --- a/test/jdk/java/lang/module/VersionTest.java	Fri Sep 04 23:51:26 2020
> > > -0400
> > > +++ b/test/jdk/java/lang/module/VersionTest.java	Wed Oct 28 17:06:47
> > > 2020 +0900
> > > @@ -148,6 +148,8 @@
> > >              { "1",             "1.0.0" },
> > >              { "1.0",           "1.0.0" },
> > >              { "1.0-beta",      "1.0.0-beta" },
> > > +            { "1.0-1.1",       "1.0-1..1" },
> > > +            { "1.0-1+1",       "1.0-1.+1" },
> > >
> > >          };
> > >      }
> > >
> > > Regards,
> > > Masanori Yano

From darcy at openjdk.java.net  Wed Mar  3 22:24:55 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 3 Mar 2021 22:24:55 GMT
Subject: RFR: 8262927: Explicitly state fields examined for BigDecimal.hashCode
Message-ID: <C7q74qeu2gZgJJTDjtCi3Gl7nnzEKiQdNJ3u3I0ENgg=.75b4f73c-33e3-40c1-b39b-ccf313de8bab@github.com>

The class BigDecimal can be and sometimes is subclassed. The spec of BigDecimal.hashCode is improved slightly by explicitly stating it is a function of the unscaled value and the scale of the BigDecimal, the same fields examined by equals.

It is a conscious choice to *not* explicitly state what the exact hash function is.

As the behavior of hashCode is mostly implied from equals, I don't think a CSR is necessary in this case.

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

Commit messages:
 - 8262927: Explicitly state fields examined for BigDecimal.hashCode

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

PR: https://git.openjdk.java.net/jdk/pull/2817

From bpb at openjdk.java.net  Wed Mar  3 23:05:41 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 3 Mar 2021 23:05:41 GMT
Subject: RFR: 8262927: Explicitly state fields examined for
 BigDecimal.hashCode
In-Reply-To: <C7q74qeu2gZgJJTDjtCi3Gl7nnzEKiQdNJ3u3I0ENgg=.75b4f73c-33e3-40c1-b39b-ccf313de8bab@github.com>
References: <C7q74qeu2gZgJJTDjtCi3Gl7nnzEKiQdNJ3u3I0ENgg=.75b4f73c-33e3-40c1-b39b-ccf313de8bab@github.com>
Message-ID: <oCsYKK52mjy5jPUnffJeWKDYfpam9uMKby3-PDWbNCA=.aa579d1c-2fda-437c-9f76-3a7676142de0@github.com>

On Wed, 3 Mar 2021 22:20:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The class BigDecimal can be and sometimes is subclassed. The spec of BigDecimal.hashCode is improved slightly by explicitly stating it is a function of the unscaled value and the scale of the BigDecimal, the same fields examined by equals.
> 
> It is a conscious choice to *not* explicitly state what the exact hash function is.
> 
> As the behavior of hashCode is mostly implied from equals, I don't think a CSR is necessary in this case.

Looks fine.

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2817

From sviswanathan at openjdk.java.net  Wed Mar  3 23:13:00 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Wed, 3 Mar 2021 23:13:00 GMT
Subject: RFR: 8262989: Vectorize VectorShuffle checkIndexes,
 wrapIndexes and laneIsValid methods
Message-ID: <FoLkFrJ1Jt4Ew0TQ5Qs6eOfmxWbWjO17s75X4L-1DaY=.df5d6a4f-fc18-474d-805f-5fd18c343393@github.com>

The hot path of VectorShuffle checkIndexes, wrapIndexes and laneIsValid methods can be implemented using Vector API methods.

For the attached jmh TestSlice.java, performance improves as below.

Before: 
Benchmark                                     (size)   Mode  Cnt     Score    Error   Units
TestSlice.vectorSliceOrigin                     1024  thrpt    5  1224.698 ? 53.825  ops/ms
TestSlice.vectorSliceUnsliceOrigin              1024  thrpt    5   657.895 ? 31.945  ops/ms

After: 
Benchmark                                     (size)   Mode  Cnt      Score    Error   Units
TestSlice.vectorSliceOrigin                     1024  thrpt    5  11221.532 ? 88.616  ops/ms
TestSlice.vectorSliceUnsliceOrigin              1024  thrpt    5   6509.519 ? 18.102  ops/ms

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

Commit messages:
 - 8262989: Vectorize VectorShuffle checkIndexes, wrapIndexes and laneIsValid methods

Changes: https://git.openjdk.java.net/jdk/pull/2819/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2819&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262989
  Stats: 43 lines in 8 files changed: 7 ins; 9 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2819.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2819/head:pull/2819

PR: https://git.openjdk.java.net/jdk/pull/2819

From darcy at openjdk.java.net  Wed Mar  3 23:17:39 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 3 Mar 2021 23:17:39 GMT
Subject: Integrated: 8262927: Explicitly state fields examined for
 BigDecimal.hashCode
In-Reply-To: <C7q74qeu2gZgJJTDjtCi3Gl7nnzEKiQdNJ3u3I0ENgg=.75b4f73c-33e3-40c1-b39b-ccf313de8bab@github.com>
References: <C7q74qeu2gZgJJTDjtCi3Gl7nnzEKiQdNJ3u3I0ENgg=.75b4f73c-33e3-40c1-b39b-ccf313de8bab@github.com>
Message-ID: <HB5hhTVTugv9RUh8eI1GBwM-tk1mjLvoJRb8rDD8E2E=.ca4ca9c9-42ce-44b6-8387-a9c12e9b9aa5@github.com>

On Wed, 3 Mar 2021 22:20:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The class BigDecimal can be and sometimes is subclassed. The spec of BigDecimal.hashCode is improved slightly by explicitly stating it is a function of the unscaled value and the scale of the BigDecimal, the same fields examined by equals.
> 
> It is a conscious choice to *not* explicitly state what the exact hash function is.
> 
> As the behavior of hashCode is mostly implied from equals, I don't think a CSR is necessary in this case.

This pull request has now been integrated.

Changeset: 28489389
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/28489389
Stats:     7 lines in 1 file changed: 5 ins; 0 del; 2 mod

8262927: Explicitly state fields examined for BigDecimal.hashCode

Reviewed-by: bpb

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

PR: https://git.openjdk.java.net/jdk/pull/2817

From darcy at openjdk.java.net  Wed Mar  3 23:32:41 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 3 Mar 2021 23:32:41 GMT
Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and
 synchronized* [v5]
In-Reply-To: <dufSqG_pp-23CyVzrCNBi_CLGroZFoZ8Lc2Tx85t7dk=.46c6dbf0-017b-498c-a972-28a2061c23eb@github.com>
References: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
 <dufSqG_pp-23CyVzrCNBi_CLGroZFoZ8Lc2Tx85t7dk=.46c6dbf0-017b-498c-a972-28a2061c23eb@github.com>
Message-ID: <QybjuiwidMuxdsMCoBzrgTnYjTHVIta_A9mTpCJ0sfc=.3e667ba8-165b-4d76-a9ac-26b00e3c76dd@github.com>

On Fri, 26 Feb 2021 20:15:19 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test refactoring. Adding implNote to modified methods

src/java.base/share/classes/java/util/Collections.java line 1168:

> 1166:      */
> 1167:     public static <T> SortedSet<T> unmodifiableSortedSet(SortedSet<T> s) {
> 1168:         if (s.getClass() == UnmodifiableSortedSet.class) {

Should a check like this also included "|| == UnmodifiableNavigableSet.class" or was there an explicit decision that the cost/benefit is not worthwhile, unlike in the case of unmodifiableList below?

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

PR: https://git.openjdk.java.net/jdk/pull/2596

From igraves at openjdk.java.net  Thu Mar  4 02:04:43 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 4 Mar 2021 02:04:43 GMT
Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and
 synchronized* [v5]
In-Reply-To: <QybjuiwidMuxdsMCoBzrgTnYjTHVIta_A9mTpCJ0sfc=.3e667ba8-165b-4d76-a9ac-26b00e3c76dd@github.com>
References: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
 <dufSqG_pp-23CyVzrCNBi_CLGroZFoZ8Lc2Tx85t7dk=.46c6dbf0-017b-498c-a972-28a2061c23eb@github.com>
 <QybjuiwidMuxdsMCoBzrgTnYjTHVIta_A9mTpCJ0sfc=.3e667ba8-165b-4d76-a9ac-26b00e3c76dd@github.com>
Message-ID: <w4HnU_cXpQNJP3lLkJpD4Dl1VclMFVE3Y9hUf-3-Ukk=.97cadada-d881-44cb-80d7-ff5cd9ba2565@github.com>

On Wed, 3 Mar 2021 23:29:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test refactoring. Adding implNote to modified methods
>
> src/java.base/share/classes/java/util/Collections.java line 1168:
> 
>> 1166:      */
>> 1167:     public static <T> SortedSet<T> unmodifiableSortedSet(SortedSet<T> s) {
>> 1168:         if (s.getClass() == UnmodifiableSortedSet.class) {
> 
> Should a check like this also included "|| == UnmodifiableNavigableSet.class" or was there an explicit decision that the cost/benefit is not worthwhile, unlike in the case of unmodifiableList below?

This is a good point. The case of unmodifiableList is such because the method can return two different classes depending the nature of the argument. I feel as though if we made this change here, we should consider doing the same check for vanilla unmodifiableSet to ensure it, too, doesn't wrap its subclasses. I'm amenable to this.

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

PR: https://git.openjdk.java.net/jdk/pull/2596

From igraves at openjdk.java.net  Thu Mar  4 02:04:44 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 4 Mar 2021 02:04:44 GMT
Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and
 synchronized* [v5]
In-Reply-To: <w4HnU_cXpQNJP3lLkJpD4Dl1VclMFVE3Y9hUf-3-Ukk=.97cadada-d881-44cb-80d7-ff5cd9ba2565@github.com>
References: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
 <dufSqG_pp-23CyVzrCNBi_CLGroZFoZ8Lc2Tx85t7dk=.46c6dbf0-017b-498c-a972-28a2061c23eb@github.com>
 <QybjuiwidMuxdsMCoBzrgTnYjTHVIta_A9mTpCJ0sfc=.3e667ba8-165b-4d76-a9ac-26b00e3c76dd@github.com>
 <w4HnU_cXpQNJP3lLkJpD4Dl1VclMFVE3Y9hUf-3-Ukk=.97cadada-d881-44cb-80d7-ff5cd9ba2565@github.com>
Message-ID: <WxOt5OAkQW5KnrwUIrabkNEEhfXQdDj_v7LhssMpqIc=.6ba4dbff-d298-4167-836c-0ca48af79777@github.com>

On Thu, 4 Mar 2021 02:01:02 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Collections.java line 1168:
>> 
>>> 1166:      */
>>> 1167:     public static <T> SortedSet<T> unmodifiableSortedSet(SortedSet<T> s) {
>>> 1168:         if (s.getClass() == UnmodifiableSortedSet.class) {
>> 
>> Should a check like this also included "|| == UnmodifiableNavigableSet.class" or was there an explicit decision that the cost/benefit is not worthwhile, unlike in the case of unmodifiableList below?
>
> This is a good point. The case of unmodifiableList is such because the method can return two different classes depending the nature of the argument. I feel as though if we made this change here, we should consider doing the same check for vanilla unmodifiableSet to ensure it, too, doesn't wrap its subclasses. I'm amenable to this.

To the second part of the question, there was no explicit cost/benefit analysis RE List or this case.

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

PR: https://git.openjdk.java.net/jdk/pull/2596

From jai.forums2013 at gmail.com  Thu Mar  4 02:40:40 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Thu, 4 Mar 2021 08:10:40 +0530
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>
Message-ID: <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>

Hello Lance,

On 03/03/21 9:14 pm, Lance Andersen wrote:
>
>
> Some other things needed to be defined and agreed upon in order to 
> move forward
>
>   * The behavior if the path does not exist
>   * If the option is specified more than once on the command line
>   * Clarify the behavior if any of the files exist in the specified
>     target directory.
>
One of my previous reply included the details of how I think it should 
behave for 2 of the above cases. I'll paste that here again for easier 
visibility. As for how it should behave if the option is specified more 
than once, I'll spend some time today to see how the jar tool currently 
behaves for some of the other options in this aspect and send back my 
response. Thank you for your help so far. Pasting below my proposal from 
a previous reply for the other 2 cases:


>
> There are other discussion points around the behavior when the target 
> directory exists or does not exist, to ensure there is some 
> consistency with main stream tools.

I'm guessing you mean the behaviour of creating a directory (or a 
hierarchy of directories) if the target directory is not present? My 
testing with the tar tool (both on MacOS and CentOS) shows that if the 
specified target directory doesn't exist, then the extract fails. The 
tar extract command doesn't create the target directory during extract. 
On the other hand, the unzip tool, does create the directory if it 
doesn't exist. However, interestingly, the unzip tool creates only one 
level of that directory if it doesn't exist. Specifically, if you specify:

unzip foo.zip -d /tmp/blah/

and if "blah/" isn't a directory inside /tmp/ directory, then it creates 
the "blah/" directory inside /tmp/ and then extracts the contents of the 
zip into it.

However,

unzip foo.zip -d /tmp/blah/hello/

and if "blah/" isn't a directory inside /tmp/ directory, then this 
command fails with an error and it doesn't create the hierarchy of the 
target directories.

Coming to the jimage and the jmod commands, both these commands create 
the entire directory hierarchy if the target directory specified during 
extract, using --dir, doesn't exist. So a command like:

jimage extract --dir /tmp/blah/foo/bar/ jdkmodules

will create the blah/foo/bar/ directory hierarchy if blah doesn't exist 
in /tmp/, while extracting the "jdkmodules" image.

 From the user point of view, I think this behaviour of creating the 
directories if the target directory doesn't exist, is probably the most 
intuitive and useful and if we did decide to use this approach for this 
new option for jar extract command, then it would align with what we 
already do in jimage and jmod commands.

One another minor detail, while we are at this, is that, IMO we should 
let the jar extract command to continue to behave the way it currently 
does when it comes to overwriting existing files. If the jar being 
extracted contains a file by the same name, in the target directory 
(hierarchy) then it should continue to overwrite that file. In other 
words, I don't think we should change the way the jar extract command 
currently behaves where it overwrites existing files when extracting.

-Jaikiran


From igraves at openjdk.java.net  Thu Mar  4 03:45:14 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 4 Mar 2021 03:45:14 GMT
Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and
 synchronized* [v6]
In-Reply-To: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
References: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
Message-ID: <qZk5-TodEa98HUJXP9uOVOVU5wE-GcgO9b6WnMfYMtk=.b8f1df7b-8608-4c0c-a931-d818dfd5bdf1@github.com>

> Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Avoid wrapping subclasses where relevant. Updated tests.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2596/files
  - new: https://git.openjdk.java.net/jdk/pull/2596/files/8109e158..dda174c5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=04-05

  Stats: 46 lines in 2 files changed: 42 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2596.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2596/head:pull/2596

PR: https://git.openjdk.java.net/jdk/pull/2596

From smarks at openjdk.java.net  Thu Mar  4 04:04:40 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 4 Mar 2021 04:04:40 GMT
Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and
 synchronized* [v5]
In-Reply-To: <EDGCHFnoeqOj2GikdBwHSK7TmvLx0mBikMqPdFXW-RA=.eed84145-4e8a-4158-a6b9-b2aaf8866c7d@github.com>
References: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
 <dufSqG_pp-23CyVzrCNBi_CLGroZFoZ8Lc2Tx85t7dk=.46c6dbf0-017b-498c-a972-28a2061c23eb@github.com>
 <EDGCHFnoeqOj2GikdBwHSK7TmvLx0mBikMqPdFXW-RA=.eed84145-4e8a-4158-a6b9-b2aaf8866c7d@github.com>
Message-ID: <ujvdba26hy21e__Tw6JwP68Dlhq2hwKXMpgF5NECMzE=.ad73115a-608d-420b-9b51-df2d56bffbd5@github.com>

On Fri, 26 Feb 2021 21:37:14 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Test refactoring. Adding implNote to modified methods
>
> The `@implNote` additions are good, and the test rewrite looks good too.

Hm. I had thought of this previously but I was a bit suspicious, and it didn't seem like it would make much difference, so I didn't say anything. But thinking about this further, the following issues arose:

1. Suppose you have an UnmodifiableSortedSet and call unmodifiableSet() on it, it returns its argument, and then you hand it out. Its static type is Set but it's really a SortedSet, which means somebody can downcast it and get its comparator. This leaks some information. Offhand this doesn't look dangerous, but it's a bit of a surprise.

2. Thinking about this further, this allows heap pollution. (Ian, turns out our conversation from the other day wasn't just an idle digression.) If we have class X and class Y extends X, then `SortedSet<Y>` cannot safely be cast to an unmodifiable `SortedSet<X>`. That's because comparator() will return `Comparator<? super X>` which is incorrect, since the actual comparator might be of type `Comparator<Y>`. Actually the headSet(), subSet(), and tailSet() methods also cause problems, because they both consume and produce the collection element type E.

3. This can actually happen in practice with code in the JDK! PriorityBlockingQueue's copy constructor does exactly the above. It takes a Collection and does an instanceof check to see if it's a SortedSet; if it is, it does a downcast and uses its comparator. Thus if we do the following:

    SortedSet<Integer> set1 = new TreeSet<>(Integer::compare);
    Set<Number> set2 = Collections.unmodifiableSet(set1); // hypothetical version that returns its argument
    PriorityBlockingQueue<Number> pbq = new PriorityBlockingQueue<>(set2);
    pbq.addAll(Arrays.asList(1.0, 2.0));

this compiles without warnings, but it results in ClassCastException. The culprit is the new upcast that potentially allows `SortedSet<? extends T>` to be cast to `Set<T>`, which is slipped in under the already-existing warnings suppression.

In any case, the extra checking in the unmodifiableSortedSet and -Map methods needs to be taken out. Offhand I don't know if there's a similar issue between unmodifiableSortedSet and a NavigableSet (resp., Map), but on general principle I'd say to take it out too. It's likely not buying much anyway.

The UnmodifiableList and UnmodifiableRandomAccessList stuff should stay, since that's how the RandomAccess marker interface is preserved.

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

PR: https://git.openjdk.java.net/jdk/pull/2596

From almatvee at openjdk.java.net  Thu Mar  4 04:04:59 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 4 Mar 2021 04:04:59 GMT
Subject: RFR: 8261845: File permissions of packages built by jpackage
Message-ID: <oYWJ9E6hHLr-UGQNMIldrIqTBywjs4tKsFRZcdgATV4=.2300228a-be05-437d-9842-6c5cb13f9ca2@github.com>

- Fixed by adding write permissions to .exe package.

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

Commit messages:
 - 8261845: File permissions of packages built by jpackage

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

PR: https://git.openjdk.java.net/jdk/pull/2822

From igraves at openjdk.java.net  Thu Mar  4 04:08:45 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 4 Mar 2021 04:08:45 GMT
Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and
 synchronized* [v5]
In-Reply-To: <ujvdba26hy21e__Tw6JwP68Dlhq2hwKXMpgF5NECMzE=.ad73115a-608d-420b-9b51-df2d56bffbd5@github.com>
References: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
 <dufSqG_pp-23CyVzrCNBi_CLGroZFoZ8Lc2Tx85t7dk=.46c6dbf0-017b-498c-a972-28a2061c23eb@github.com>
 <EDGCHFnoeqOj2GikdBwHSK7TmvLx0mBikMqPdFXW-RA=.eed84145-4e8a-4158-a6b9-b2aaf8866c7d@github.com>
 <ujvdba26hy21e__Tw6JwP68Dlhq2hwKXMpgF5NECMzE=.ad73115a-608d-420b-9b51-df2d56bffbd5@github.com>
Message-ID: <tZH1KAh0EjpEWPYsGx05aJOti71GkNfl2bUUtVJphpg=.b5f419f5-fe70-4f9c-beed-69daed0b3e79@github.com>

On Thu, 4 Mar 2021 03:57:35 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> The `@implNote` additions are good, and the test rewrite looks good too.
>
> Hm. I had thought of this previously but I was a bit suspicious, and it didn't seem like it would make much difference, so I didn't say anything. But thinking about this further, the following issues arose:
> 
> 1. Suppose you have an UnmodifiableSortedSet and call unmodifiableSet() on it, it returns its argument, and then you hand it out. Its static type is Set but it's really a SortedSet, which means somebody can downcast it and get its comparator. This leaks some information. Offhand this doesn't look dangerous, but it's a bit of a surprise.
> 
> 2. Thinking about this further, this allows heap pollution. (Ian, turns out our conversation from the other day wasn't just an idle digression.) If we have class X and class Y extends X, then `SortedSet<Y>` cannot safely be cast to an unmodifiable `SortedSet<X>`. That's because comparator() will return `Comparator<? super X>` which is incorrect, since the actual comparator might be of type `Comparator<Y>`. Actually the headSet(), subSet(), and tailSet() methods also cause problems, because they both consume and produce the collection element type E.
> 
> 3. This can actually happen in practice with code in the JDK! PriorityBlockingQueue's copy constructor does exactly the above. It takes a Collection and does an instanceof check to see if it's a SortedSet; if it is, it does a downcast and uses its comparator. Thus if we do the following:
> 
>     SortedSet<Integer> set1 = new TreeSet<>(Integer::compare);
>     Set<Number> set2 = Collections.unmodifiableSet(set1); // hypothetical version that returns its argument
>     PriorityBlockingQueue<Number> pbq = new PriorityBlockingQueue<>(set2);
>     pbq.addAll(Arrays.asList(1.0, 2.0));
> 
> this compiles without warnings, but it results in ClassCastException. The culprit is the new upcast that potentially allows `SortedSet<? extends T>` to be cast to `Set<T>`, which is slipped in under the already-existing warnings suppression.
> 
> In any case, the extra checking in the unmodifiableSortedSet and -Map methods needs to be taken out. Offhand I don't know if there's a similar issue between unmodifiableSortedSet and a NavigableSet (resp., Map), but on general principle I'd say to take it out too. It's likely not buying much anyway.
> 
> The UnmodifiableList and UnmodifiableRandomAccessList stuff should stay, since that's how the RandomAccess marker interface is preserved.

Good thought on the heap pollution. I had only been considering point 1. I was thinking that perhaps if we could catch some of the wrapping of subclasses we might be able to guard against situations where rewrapping could occur if we were interleaving calls between subclass and superclass wrapper methods. That seems like a bit of a reach and in light of your point about heap pollution I think it makes sense to walk back the changes and stay with the original.

Likewise agree on the point about Lists.

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

PR: https://git.openjdk.java.net/jdk/pull/2596

From igraves at openjdk.java.net  Thu Mar  4 04:13:12 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 4 Mar 2021 04:13:12 GMT
Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and
 synchronized* [v7]
In-Reply-To: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
References: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
Message-ID: <YwkWpb8nKfggeA2QmK8y9KfSXrmk8jaxDX7nX6QusFE=.05c584ad-70ab-41ed-bbf5-cc86b18f3f85@github.com>

> Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Avoid wrapping subclasses where relevant. Updated tests."
  
  This reverts commit dda174c582590827cad3f4006a8ff9e7dd8a51ab.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2596/files
  - new: https://git.openjdk.java.net/jdk/pull/2596/files/dda174c5..88127ed5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=05-06

  Stats: 46 lines in 2 files changed: 0 ins; 42 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2596.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2596/head:pull/2596

PR: https://git.openjdk.java.net/jdk/pull/2596

From asemenyuk at openjdk.java.net  Thu Mar  4 04:13:40 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 4 Mar 2021 04:13:40 GMT
Subject: RFR: 8261845: File permissions of packages built by jpackage
In-Reply-To: <oYWJ9E6hHLr-UGQNMIldrIqTBywjs4tKsFRZcdgATV4=.2300228a-be05-437d-9842-6c5cb13f9ca2@github.com>
References: <oYWJ9E6hHLr-UGQNMIldrIqTBywjs4tKsFRZcdgATV4=.2300228a-be05-437d-9842-6c5cb13f9ca2@github.com>
Message-ID: <wb4LeAPzp15uHilX_qTp55b9-R1BrwX2KlLifawoJXE=.84eb3d5b-0bb4-45c0-8e48-45d6985eacfd@github.com>

On Thu, 4 Mar 2021 03:59:27 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Fixed by adding write permissions to .exe package.

Marked as reviewed by asemenyuk (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2822

From alanb at openjdk.java.net  Thu Mar  4 08:24:01 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 4 Mar 2021 08:24:01 GMT
Subject: RFR: 8261845: File permissions of packages built by jpackage
In-Reply-To: <oYWJ9E6hHLr-UGQNMIldrIqTBywjs4tKsFRZcdgATV4=.2300228a-be05-437d-9842-6c5cb13f9ca2@github.com>
References: <oYWJ9E6hHLr-UGQNMIldrIqTBywjs4tKsFRZcdgATV4=.2300228a-be05-437d-9842-6c5cb13f9ca2@github.com>
Message-ID: <xik39M1hbrSSJrDiASOyQZPHU90w23j_g91tyBBeIH0=.d389074d-c137-4428-95ed-f7402d6b39ab@github.com>

On Thu, 4 Mar 2021 03:59:27 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Fixed by adding write permissions to .exe package.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinExeBundler.java line 144:

> 142:         Files.copy(exePath, dstExePath);
> 143: 
> 144:         dstExePath.toFile().setWritable(true, true);

The jlink code in DefaultImageBuilder might be useful if you need finer control on the file permissions.

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

PR: https://git.openjdk.java.net/jdk/pull/2822

From lance.andersen at oracle.com  Thu Mar  4 12:01:35 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 4 Mar 2021 12:01:35 +0000
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
Message-ID: <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>

Hi Jaikiran

From https://docs.oracle.com/en/java/javase/15/docs/specs/man/jar.html

The jar man page includes the following :
 The syntax for the jar command resembles the syntax for the tar command.

Because of the above, I feel that we should support:

???
-C
?dir
?directory
????

The addition of ?-dir? adds support for an option used by some of the other java command line tools.

I would suggest for the next step is flush/write out your proposed  syntax  as it would be included in an updated version of the jar man page.

Given the other java command line tools create the directory if it does not exist, I think that is reasonable to propose that.

Your change should not modify the longstanding overwrite behavior of jar.

Another thing to think about is whether there should be any additional output when the -v option is specified

In summary, I think you are moving in the right direction.  The next step is to make a pass at creating the man page updates so that we can reach consensus on the syntax and behavior.

Thank you again for your efforts on this

Best
Lance

On Mar 3, 2021, at 9:40 PM, Jaikiran Pai <jai.forums2013 at gmail.com<mailto:jai.forums2013 at gmail.com>> wrote:


Hello Lance,

On 03/03/21 9:14 pm, Lance Andersen wrote:


Some other things needed to be defined and agreed upon in order to move forward


  *   The behavior if the path does not exist
  *   If the option is specified more than once on the command line
  *   Clarify the behavior if any of the files exist in the specified target directory.

One of my previous reply included the details of how I think it should behave for 2 of the above cases. I'll paste that here again for easier visibility. As for how it should behave if the option is specified more than once, I'll spend some time today to see how the jar tool currently behaves for some of the other options in this aspect and send back my response. Thank you for your help so far. Pasting below my proposal from a previous reply for the other 2 cases:


There are other discussion points around the behavior when the target directory exists or does not exist, to ensure there is some consistency with main stream tools.

I'm guessing you mean the behaviour of creating a directory (or a hierarchy of directories) if the target directory is not present? My testing with the tar tool (both on MacOS and CentOS) shows that if the specified target directory doesn't exist, then the extract fails. The tar extract command doesn't create the target directory during extract. On the other hand, the unzip tool, does create the directory if it doesn't exist. However, interestingly, the unzip tool creates only one level of that directory if it doesn't exist. Specifically, if you specify:

unzip foo.zip -d /tmp/blah/

and if "blah/" isn't a directory inside /tmp/ directory, then it creates the "blah/" directory inside /tmp/ and then extracts the contents of the zip into it.

However,

unzip foo.zip -d /tmp/blah/hello/

and if "blah/" isn't a directory inside /tmp/ directory, then this command fails with an error and it doesn't create the hierarchy of the target directories.

Coming to the jimage and the jmod commands, both these commands create the entire directory hierarchy if the target directory specified during extract, using --dir, doesn't exist. So a command like:

jimage extract --dir /tmp/blah/foo/bar/ jdkmodules

will create the blah/foo/bar/ directory hierarchy if blah doesn't exist in /tmp/, while extracting the "jdkmodules" image.

From the user point of view, I think this behaviour of creating the directories if the target directory doesn't exist, is probably the most intuitive and useful and if we did decide to use this approach for this new option for jar extract command, then it would align with what we already do in jimage and jmod commands.

One another minor detail, while we are at this, is that, IMO we should let the jar extract command to continue to behave the way it currently does when it comes to overwriting existing files. If the jar being extracted contains a file by the same name, in the target directory (hierarchy) then it should continue to overwrite that file. In other words, I don't think we should change the way the jar extract command currently behaves where it overwrites existing files when extracting.

-Jaikiran

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>




From asemenyuk at openjdk.java.net  Thu Mar  4 12:36:55 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 4 Mar 2021 12:36:55 GMT
Subject: RFR: 8262300: jpackage app-launcher fails on linux when using JDK11
 based runtime
Message-ID: <G_ZEkT4oFSK2er0qt-2TK6NvW6iUsf_zjlr_RMaxjDE=.f451e115-48d7-48c3-b281-62669d3f00e4@github.com>

Fix jpackage app launcher to also look for JLI lib in "lib/jli/libjli.so" subdirectory of runtime

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

Commit messages:
 - 8262300: jpackage app-launcher fails on linux when using JDK11 based runtime

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

PR: https://git.openjdk.java.net/jdk/pull/2827

From herrick at openjdk.java.net  Thu Mar  4 14:00:40 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 4 Mar 2021 14:00:40 GMT
Subject: RFR: 8261845: File permissions of packages built by jpackage
In-Reply-To: <oYWJ9E6hHLr-UGQNMIldrIqTBywjs4tKsFRZcdgATV4=.2300228a-be05-437d-9842-6c5cb13f9ca2@github.com>
References: <oYWJ9E6hHLr-UGQNMIldrIqTBywjs4tKsFRZcdgATV4=.2300228a-be05-437d-9842-6c5cb13f9ca2@github.com>
Message-ID: <BcOQ3TOvsn6UlSUemkCGVkn7TcsX0U9GFk_0He7hRkA=.021e0982-1845-4b97-91a4-6b3fcfd43d9f@github.com>

On Thu, 4 Mar 2021 03:59:27 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Fixed by adding write permissions to .exe package.

Marked as reviewed by herrick (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2822

From herrick at openjdk.java.net  Thu Mar  4 14:18:59 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 4 Mar 2021 14:18:59 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path [v5]
In-Reply-To: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
Message-ID: <mxQQQ6TWOyAFJX995VLfBW9cXndVrUsR64_0fOoAZNQ=.2e2547e1-1eb4-4fa2-ac67-25304e4636e2@github.com>

> when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory.

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8261518: jpackage looks for main module in current dir when there is no module-path

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2781/files
  - new: https://git.openjdk.java.net/jdk/pull/2781/files/fa5b3622..afd59c25

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2781&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2781&range=03-04

  Stats: 40 lines in 2 files changed: 12 ins; 16 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2781.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2781/head:pull/2781

PR: https://git.openjdk.java.net/jdk/pull/2781

From herrick at openjdk.java.net  Thu Mar  4 14:23:42 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 4 Mar 2021 14:23:42 GMT
Subject: RFR: 8262300: jpackage app-launcher fails on linux when using
 JDK11 based runtime
In-Reply-To: <G_ZEkT4oFSK2er0qt-2TK6NvW6iUsf_zjlr_RMaxjDE=.f451e115-48d7-48c3-b281-62669d3f00e4@github.com>
References: <G_ZEkT4oFSK2er0qt-2TK6NvW6iUsf_zjlr_RMaxjDE=.f451e115-48d7-48c3-b281-62669d3f00e4@github.com>
Message-ID: <VEhWu-O26mkNAA3YKMG6Tro5kRs1UxM6U0XZFdch1Cs=.b9497c98-f115-40b1-ab2f-5e999c4b409b@github.com>

On Thu, 4 Mar 2021 12:32:11 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix jpackage app launcher to also look for JLI lib in "lib/jli/libjli.so" subdirectory of runtime

Marked as reviewed by herrick (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2827

From gziemski at openjdk.java.net  Thu Mar  4 15:29:59 2021
From: gziemski at openjdk.java.net (Gerard Ziemski)
Date: Thu, 4 Mar 2021 15:29:59 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
Message-ID: <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>

On Wed, 3 Mar 2021 17:46:41 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > A list of the bugs that our internal testing revealed so far:
> 
> Are any of these blockers for integration? Some of them are to do with things like features that aren't yet supported, and we can't fix what we can't see.

I don't personally think any of these issues are blockers. It's a great effort as it is and very much appreciated. Anything else can be fixed as a followup.

There might be some legal requirements (i.e. JCK) that I'm not in position to comment on, however, so someone else might need to chime in here.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From psandoz at openjdk.java.net  Thu Mar  4 16:50:39 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 4 Mar 2021 16:50:39 GMT
Subject: RFR: 8262989: Vectorize VectorShuffle checkIndexes,
 wrapIndexes and laneIsValid methods
In-Reply-To: <FoLkFrJ1Jt4Ew0TQ5Qs6eOfmxWbWjO17s75X4L-1DaY=.df5d6a4f-fc18-474d-805f-5fd18c343393@github.com>
References: <FoLkFrJ1Jt4Ew0TQ5Qs6eOfmxWbWjO17s75X4L-1DaY=.df5d6a4f-fc18-474d-805f-5fd18c343393@github.com>
Message-ID: <ipCEN1i0bWa4t6kc-RqVoXgnTbtX7KdofbQsoBr3zcA=.d386d3f9-3ebc-4d56-b260-1f677970e054@github.com>

On Wed, 3 Mar 2021 22:32:48 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> The hot path of VectorShuffle checkIndexes, wrapIndexes and laneIsValid methods can be implemented using Vector API methods.
> 
> For the attached jmh TestSlice.java, performance improves as below.
> 
> Before: 
> Benchmark                                     (size)   Mode  Cnt     Score    Error   Units
> TestSlice.vectorSliceOrigin                     1024  thrpt    5  1224.698 ? 53.825  ops/ms
> TestSlice.vectorSliceUnsliceOrigin              1024  thrpt    5   657.895 ? 31.945  ops/ms
> 
> After: 
> Benchmark                                     (size)   Mode  Cnt      Score    Error   Units
> TestSlice.vectorSliceOrigin                     1024  thrpt    5  11221.532 ? 88.616  ops/ms
> TestSlice.vectorSliceUnsliceOrigin              1024  thrpt    5   6509.519 ? 18.102  ops/ms

Looks good, a nice incremental improvement.

I suppose `checkIndexes` and `wrapIndexes` could call `laneIsValid`, and then call `anyFalse` on the resulting mask. Dunno if that would affect the generated code.

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

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2819

From github.com+4146708+a74nh at openjdk.java.net  Thu Mar  4 17:39:01 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Thu, 4 Mar 2021 17:39:01 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
 <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
Message-ID: <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>

On Thu, 4 Mar 2021 15:27:25 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>>> A list of the bugs that our internal testing revealed so far:
>> 
>> Are any of these blockers for integration? Some of them are to do with things like features that aren't yet supported, and we can't fix what we can't see.
>
>> > A list of the bugs that our internal testing revealed so far:
>> 
>> Are any of these blockers for integration? Some of them are to do with things like features that aren't yet supported, and we can't fix what we can't see.
> 
> I don't personally think any of these issues are blockers. It's a great effort as it is and very much appreciated. Anything else can be fixed as a followup.
> 
> There might be some legal requirements (i.e. JCK) that I'm not in position to comment on, however, so someone else might need to chime in here.

I was building this PR on a new machine, and I now get the following error:

> /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31: error: cast to smaller integer type 'MIDIClientRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> static MIDIClientRef client = (MIDIClientRef) NULL;
>                               ^~~~~~~~~~~~~~~~~~~~
> /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:259:29: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> static MIDIPortRef inPort = (MIDIPortRef) NULL;
>                             ^~~~~~~~~~~~~~~~~~
> /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:260:30: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> static MIDIPortRef outPort = (MIDIPortRef) NULL;
>                              ^~~~~~~~~~~~~~~~~~
> /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:466:32: error: cast to smaller integer type 'MIDIEndpointRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>     MIDIEndpointRef endpoint = (MIDIEndpointRef) NULL;
>                                ^~~~~~~~~~~~~~~~~~~~~~
> 4 errors generated.

As far as I can tell the only difference between the two systems is the xcode version:

New system (failing)
% xcodebuild -version
Xcode 12.5
Build version 12E5244e

Old system (working)
% xcodebuild -version
Xcode 12.4
Build version 12D4e

Looks like the newer version of Xcode is being a little stricter with casting?
Replacing the NULL with 0 seems to fix the issue.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From redestad at openjdk.java.net  Thu Mar  4 17:46:56 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 4 Mar 2021 17:46:56 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers
Message-ID: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>

This patch optimizes String.format expressions that uses trivial specifiers. In the JDK, the most common variation of String.format is a variation of format("foo: %s", s), which gets a significant speed-up from this.

Various other cleanups and minor improvements reduce overhead further and ensure we get a small gain also for more complex format strings.

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

Commit messages:
 - Fix boundary condition
 - Add complex pattern micro
 - Harmonize micro to generate same length strings and mix trivial and non-trivial specifiers
 - Accidentally mutating Flags.NONE
 - Merge branch 'master' into format_opt
 - Fixes, cleanups, improvements
 - Consolidate slow path
 - Fix various edge cases
 - Improve Formatter for simple patterns

Changes: https://git.openjdk.java.net/jdk/pull/2830/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2830&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263038
  Stats: 265 lines in 2 files changed: 121 ins; 58 del; 86 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2830.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2830/head:pull/2830

PR: https://git.openjdk.java.net/jdk/pull/2830

From asemenyuk at openjdk.java.net  Thu Mar  4 18:06:42 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 4 Mar 2021 18:06:42 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path [v5]
In-Reply-To: <mxQQQ6TWOyAFJX995VLfBW9cXndVrUsR64_0fOoAZNQ=.2e2547e1-1eb4-4fa2-ac67-25304e4636e2@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
 <mxQQQ6TWOyAFJX995VLfBW9cXndVrUsR64_0fOoAZNQ=.2e2547e1-1eb4-4fa2-ac67-25304e4636e2@github.com>
Message-ID: <J5GfQ6NOPOZfmGYhJXsL403e4ZBQfFrFROuuGF3AKlA=.a29d7ed1-2916-4a6d-9223-1682442f4c9f@github.com>

On Thu, 4 Mar 2021 14:18:59 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory.
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8261518: jpackage looks for main module in current dir when there is no module-path

Marked as reviewed by asemenyuk (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2781

From vkempik at openjdk.java.net  Thu Mar  4 18:22:51 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Thu, 4 Mar 2021 18:22:51 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
 <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
 <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>
Message-ID: <yPuti6hI-2ryTux1GdrZHAcP0n0esc5E1PCPXvm389o=.70b78b9a-365e-4a80-8903-e9a0b822492f@github.com>

On Thu, 4 Mar 2021 17:36:22 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

> I was building this PR on a new machine, and I now get the following error:
> 
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31: error: cast to smaller integer type 'MIDIClientRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIClientRef client = (MIDIClientRef) NULL;
> > ^~~~~~~~~~~~~~~~~~~~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:259:29: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIPortRef inPort = (MIDIPortRef) NULL;
> > ^~~~~~~~~~~~~~~~~~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:260:30: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > static MIDIPortRef outPort = (MIDIPortRef) NULL;
> > ^~~~~~~~~~~~~~~~~~
> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:466:32: error: cast to smaller integer type 'MIDIEndpointRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
> > MIDIEndpointRef endpoint = (MIDIEndpointRef) NULL;
> > ^~~~~~~~~~~~~~~~~~~~~~
> > 4 errors generated.
> 
> As far as I can tell the only difference between the two systems is the xcode version:
> 
> New system (failing)
> % xcodebuild -version
> Xcode 12.5
> Build version 12E5244e
> 
> Old system (working)
> % xcodebuild -version
> Xcode 12.4
> Build version 12D4e
> 
> Looks like the newer version of Xcode is being a little stricter with casting?
> Replacing the NULL with 0 seems to fix the issue.

Hello
there is one issue with the info you provided, it's from Xcode12.5 beta.
And beta license agreement forbids sharing output of beta version of compiler&co
So we can't say we have issue with newer xcode beta until that beta went public & released.
Fixing issues you found now will mean someone have violated xcode beta license agreement and made these issues public.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From redestad at openjdk.java.net  Thu Mar  4 17:46:56 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 4 Mar 2021 17:46:56 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers
In-Reply-To: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
Message-ID: <dmxJ9ts3iGE5EpUeM0l8yhjSHcdpOPfGw5Nuzk2GgUk=.135c7a2d-532a-44d8-b6e6-371e02e6f8ba@github.com>

On Thu, 4 Mar 2021 17:20:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch optimizes String.format expressions that uses trivial specifiers. In the JDK, the most common variation of String.format is a variation of format("foo: %s", s), which gets a significant speed-up from this.
> 
> Various other cleanups and minor improvements reduce overhead further and ensure we get a small gain also for more complex format strings.

Microbench results - baseline:
Benchmark                                                           Mode  Cnt     Score      Error   Units
StringFormat.complexFormat                                          avgt    5  8842.917 ?  658.269   ns/op
StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt    5  2176.378 ?    0.483    B/op
StringFormat.stringFormat                                           avgt    5   859.863 ?   97.514   ns/op
StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt    5   560.091 ?    0.011    B/op
StringFormat.stringIntFormat                                        avgt    5  1619.772 ?  147.646   ns/op
StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt    5   728.132 ?    0.140    B/op
StringFormat.widthStringFormat                                      avgt    5  1060.200 ?  154.025   ns/op
StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt    5   592.108 ?    0.093    B/op
StringFormat.widthStringIntFormat                                   avgt    5  2045.215 ?  246.189   ns/op
StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt    5   784.144 ?    0.121    B/op

Patched:
Benchmark                                                           Mode  Cnt     Score      Error   Units
StringFormat.complexFormat                                          avgt    5  8023.314 ? 1387.475   ns/op
StringFormat.complexFormat:?gc.alloc.rate.norm                      avgt    5  2120.399 ?    0.417    B/op
StringFormat.stringFormat                                           avgt    5   286.776 ?   30.645   ns/op
StringFormat.stringFormat:?gc.alloc.rate.norm                       avgt    5   256.044 ?    0.017    B/op
StringFormat.stringIntFormat                                        avgt    5   626.083 ?   68.652   ns/op
StringFormat.stringIntFormat:?gc.alloc.rate.norm                    avgt    5   432.073 ?    0.039    B/op
StringFormat.widthStringFormat                                      avgt    5  1061.631 ?  156.444   ns/op
StringFormat.widthStringFormat:?gc.alloc.rate.norm                  avgt    5   560.103 ?    0.106    B/op
StringFormat.widthStringIntFormat                                   avgt    5  1380.208 ?  267.445   ns/op
StringFormat.widthStringIntFormat:?gc.alloc.rate.norm               avgt    5   736.134 ?    0.144    B/op

-Xint similarly sees no change on complexString, but a 3-3.5x speed-up on stringFormat

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

PR: https://git.openjdk.java.net/jdk/pull/2830

From sviswanathan at openjdk.java.net  Thu Mar  4 18:48:39 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 4 Mar 2021 18:48:39 GMT
Subject: RFR: 8262989: Vectorize VectorShuffle checkIndexes,
 wrapIndexes and laneIsValid methods
In-Reply-To: <ipCEN1i0bWa4t6kc-RqVoXgnTbtX7KdofbQsoBr3zcA=.d386d3f9-3ebc-4d56-b260-1f677970e054@github.com>
References: <FoLkFrJ1Jt4Ew0TQ5Qs6eOfmxWbWjO17s75X4L-1DaY=.df5d6a4f-fc18-474d-805f-5fd18c343393@github.com>
 <ipCEN1i0bWa4t6kc-RqVoXgnTbtX7KdofbQsoBr3zcA=.d386d3f9-3ebc-4d56-b260-1f677970e054@github.com>
Message-ID: <VrnWFuU1FexfLeq4tD3DPKS5hO3_nakkdPuyx7glHsc=.8c7241e2-0a94-4821-bd38-bbc0cb7ebc9a@github.com>

On Thu, 4 Mar 2021 16:47:30 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> The hot path of VectorShuffle checkIndexes, wrapIndexes and laneIsValid methods can be implemented using Vector API methods.
>> 
>> For the attached jmh TestSlice.java, performance improves as below.
>> 
>> Before: 
>> Benchmark                                     (size)   Mode  Cnt     Score    Error   Units
>> TestSlice.vectorSliceOrigin                     1024  thrpt    5  1224.698 ? 53.825  ops/ms
>> TestSlice.vectorSliceUnsliceOrigin              1024  thrpt    5   657.895 ? 31.945  ops/ms
>> 
>> After: 
>> Benchmark                                     (size)   Mode  Cnt      Score    Error   Units
>> TestSlice.vectorSliceOrigin                     1024  thrpt    5  11221.532 ? 88.616  ops/ms
>> TestSlice.vectorSliceUnsliceOrigin              1024  thrpt    5   6509.519 ? 18.102  ops/ms
>
> Looks good, a nice incremental improvement.
> 
> I suppose `checkIndexes` and `wrapIndexes` could call `laneIsValid`, and then call `anyFalse` on the resulting mask. Dunno if that would affect the generated code.

Calling laneIsValid from checkIndexes and wrapIndexes would look like as below:
        VectorMask<E> vecmask = this.laneIsValid();
        if (!vecmask.allTrue()) {
I observe a small overhead (~2%) due to couple of extra instructions generated for allTrue.

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

PR: https://git.openjdk.java.net/jdk/pull/2819

From psandoz at openjdk.java.net  Thu Mar  4 18:57:41 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 4 Mar 2021 18:57:41 GMT
Subject: RFR: 8262989: Vectorize VectorShuffle checkIndexes,
 wrapIndexes and laneIsValid methods
In-Reply-To: <VrnWFuU1FexfLeq4tD3DPKS5hO3_nakkdPuyx7glHsc=.8c7241e2-0a94-4821-bd38-bbc0cb7ebc9a@github.com>
References: <FoLkFrJ1Jt4Ew0TQ5Qs6eOfmxWbWjO17s75X4L-1DaY=.df5d6a4f-fc18-474d-805f-5fd18c343393@github.com>
 <ipCEN1i0bWa4t6kc-RqVoXgnTbtX7KdofbQsoBr3zcA=.d386d3f9-3ebc-4d56-b260-1f677970e054@github.com>
 <VrnWFuU1FexfLeq4tD3DPKS5hO3_nakkdPuyx7glHsc=.8c7241e2-0a94-4821-bd38-bbc0cb7ebc9a@github.com>
Message-ID: <rRNmsRIc1ASqxtUKQ2C_KcLNXMJ521YP_LGUeFyGxXQ=.0085b93e-70f3-4362-9c3f-e47004d93157@github.com>

On Thu, 4 Mar 2021 18:45:27 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Looks good, a nice incremental improvement.
>> 
>> I suppose `checkIndexes` and `wrapIndexes` could call `laneIsValid`, and then call `anyFalse` on the resulting mask. Dunno if that would affect the generated code.
>
> Calling laneIsValid from checkIndexes and wrapIndexes would look like as below:
>         VectorMask<E> vecmask = this.laneIsValid();
>         if (!vecmask.allTrue()) {
> I observe a small overhead (~2%) due to couple of extra instructions generated for allTrue.

Ok, I mistakenly thought there was a method `Vector.anyFalse`!

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

PR: https://git.openjdk.java.net/jdk/pull/2819

From kizune at openjdk.java.net  Thu Mar  4 19:33:52 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 4 Mar 2021 19:33:52 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path [v5]
In-Reply-To: <mxQQQ6TWOyAFJX995VLfBW9cXndVrUsR64_0fOoAZNQ=.2e2547e1-1eb4-4fa2-ac67-25304e4636e2@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
 <mxQQQ6TWOyAFJX995VLfBW9cXndVrUsR64_0fOoAZNQ=.2e2547e1-1eb4-4fa2-ac67-25304e4636e2@github.com>
Message-ID: <cWx3rokppbLILIh0QdniWgSfDXkG1nxwoDwYb_22uMQ=.94445074-1db5-438d-ac8c-26d34e95f413@github.com>

On Thu, 4 Mar 2021 14:18:59 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory.
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8261518: jpackage looks for main module in current dir when there is no module-path

Looks good. Please don't forget to fix the trailing whitespaces problem in the test.

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

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2781

From herrick at openjdk.java.net  Thu Mar  4 19:50:01 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 4 Mar 2021 19:50:01 GMT
Subject: RFR: JDK-8261518: jpackage looks for main module in current dir
 when there is no module-path [v6]
In-Reply-To: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
Message-ID: <YLsw5x2mbIMhRiVTudHe70Pstchj2GEKHXrWn3uEwsM=.c105a202-3fbd-4b45-b4d8-736dfcd76489@github.com>

> when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory.

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8261518: jpackage looks for main module in current dir when there is no module-path

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2781/files
  - new: https://git.openjdk.java.net/jdk/pull/2781/files/afd59c25..71c4341d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2781&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2781&range=04-05

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

PR: https://git.openjdk.java.net/jdk/pull/2781

From herrick at openjdk.java.net  Thu Mar  4 19:54:40 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 4 Mar 2021 19:54:40 GMT
Subject: Integrated: JDK-8261518: jpackage looks for main module in current
 dir when there is no module-path
In-Reply-To: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
References: <4SBdHmzMkLE5yrmBPo_WBUUGXmbAy3ZzFYtKrdDz8Xo=.c3be2047-6206-4b3c-a5d2-800a4d5a9ec7@github.com>
Message-ID: <E6vgDu8mMWHpu0dETD_-uySYda76nChC9IT8WJBPKdU=.c18b6a9f-2130-47c7-b06d-75385fd56025@github.com>

On Mon, 1 Mar 2021 15:55:39 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> when the app modules have already been jlinked with the runtime, and there is no need for module-path, jpackage was acting as if the module-path was "." and picking up jars in the current directory.

This pull request has now been integrated.

Changeset: 109af7b5
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/109af7b5
Stats:     142 lines in 2 files changed: 137 ins; 0 del; 5 mod

8261518: jpackage looks for main module in current dir when there is no module-path

Reviewed-by: asemenyuk, almatvee, kizune

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

PR: https://git.openjdk.java.net/jdk/pull/2781

From smarks at openjdk.java.net  Thu Mar  4 20:31:45 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 4 Mar 2021 20:31:45 GMT
Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and
 synchronized* [v7]
In-Reply-To: <YwkWpb8nKfggeA2QmK8y9KfSXrmk8jaxDX7nX6QusFE=.05c584ad-70ab-41ed-bbf5-cc86b18f3f85@github.com>
References: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
 <YwkWpb8nKfggeA2QmK8y9KfSXrmk8jaxDX7nX6QusFE=.05c584ad-70ab-41ed-bbf5-cc86b18f3f85@github.com>
Message-ID: <7xhHDLWOUdI4N-4kITQWNCZnSr5mbOTHT_u-sQmg4i8=.778e31ed-01e1-4b09-8063-eb329c432abf@github.com>

On Thu, 4 Mar 2021 04:13:12 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Avoid wrapping subclasses where relevant. Updated tests."
>   
>   This reverts commit dda174c582590827cad3f4006a8ff9e7dd8a51ab.

Marked as reviewed by smarks (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2596

From github.com+194713+candrews at openjdk.java.net  Thu Mar  4 21:16:03 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Thu, 4 Mar 2021 21:16:03 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v2]
In-Reply-To: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
Message-ID: <6Rp2Th-ShUiZwXKTfTZ3Jf7r3twQA0eqborGOVmDGVk=.a5c59483-bb17-4b35-a57c-c1966cd1e247@github.com>

> `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.
> 
> According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.
> 
> Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>> Returns:
>>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.
> 
> And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>> Returns:
>>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.
> 
> Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.
> 
> Here's a stack trace:
> java.lang.IllegalArgumentException: name
>         at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>         at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>         at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
> 
> Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>         URL findResource(final String name, boolean check) {
>             URL url;
>             try {
>                 url = new URL(base, ParseUtil.encodePath(name, false));
>             } catch (MalformedURLException e) {
>                 throw new IllegalArgumentException("name");
>             }
> 
> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
> 
> A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>         URL findResource(final String name, boolean check) {
>             URL url;
>             try {
>                 url = new URL(base, ParseUtil.encodePath(name, false));
>             } catch (MalformedURLException e) {
>                 throw new IllegalArgumentException("name");
>             }
> 
> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.

Craig Andrews has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2662/files
  - new: https://git.openjdk.java.net/jdk/pull/2662/files/d9506624..3f6a974e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2662&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2662&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From github.com+194713+candrews at openjdk.java.net  Thu Mar  4 21:16:04 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Thu, 4 Mar 2021 21:16:04 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v2]
In-Reply-To: <iKdskMjHNKUrtpQW8tVlLXeasNBbE54041OYUPpTahA=.6bbe649a-25d6-4a79-af08-5a237ffcdfc8@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <M_HI6rHAd36Rsy0ZS_ya3iFig0vZcyO_s9aK11a2j48=.7513689b-a106-4238-8b6a-f6d0de2109e5@github.com>
 <iKdskMjHNKUrtpQW8tVlLXeasNBbE54041OYUPpTahA=.6bbe649a-25d6-4a79-af08-5a237ffcdfc8@github.com>
Message-ID: <t3fUW2NfjjSjvTrQotLdG23BiQhQDNepd0M9LwEfM7c=.b53c2963-0978-4bc3-9346-93215a93ee19@github.com>

On Wed, 3 Mar 2021 18:10:25 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>The commented-out lines should be removed from the change.

Done! ?? 

> As Alan said, a regression test will be needed. At minimum, it should test a method that returns a URL, as well as a method that returns an Enumeration (which can also lead to an IAE, as I noted in the bug report).

I'll see what I can do ?? 

> Also, the copyright year should be updated: 2019 -> 2021

Done! ?? 

> @bchristi-git has indicated that a [compatibility and specification](https://wiki.openjdk.java.net/display/csr/Main) (CSR) request is needed for this pull request.
> @candrews please create a CSR request and add link to it in [JDK-8262277](https://bugs.openjdk.java.net/browse/JDK-8262277). This pull request cannot be integrated until the CSR request is approved.

I'm trying to figure out how to create a CSR and I'm not having much luck. According to the [CSR FAQs](https://wiki.openjdk.java.net/display/csr/CSR+FAQs):
> Q: How do I create a CSR ?
A: Do not directly create a CSR from the Create Menu. JIRA will let you do this right up until the moment you try to save it and find your typing was in vain.
Instead you should go to the target bug, select "More", and from the drop down menu select "Create CSR". This is required to properly associate the CSR with the main bug, just as is done for backports.

However, I don't have an account on https://bugs.openjdk.java.net so I can't do as instructed.

How do I create the CSR?

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From sviswanathan at openjdk.java.net  Thu Mar  4 21:27:39 2021
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 4 Mar 2021 21:27:39 GMT
Subject: Integrated: 8262989: Vectorize VectorShuffle checkIndexes,
 wrapIndexes and laneIsValid methods
In-Reply-To: <FoLkFrJ1Jt4Ew0TQ5Qs6eOfmxWbWjO17s75X4L-1DaY=.df5d6a4f-fc18-474d-805f-5fd18c343393@github.com>
References: <FoLkFrJ1Jt4Ew0TQ5Qs6eOfmxWbWjO17s75X4L-1DaY=.df5d6a4f-fc18-474d-805f-5fd18c343393@github.com>
Message-ID: <92YwvwQuGvQqTO7axd-UueZZaT3cwUsf5sKcusNsoxE=.f2452cf9-82fe-49d9-9b95-699ea429b796@github.com>

On Wed, 3 Mar 2021 22:32:48 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> The hot path of VectorShuffle checkIndexes, wrapIndexes and laneIsValid methods can be implemented using Vector API methods.
> 
> For the attached jmh TestSlice.java, performance improves as below.
> 
> Before: 
> Benchmark                                     (size)   Mode  Cnt     Score    Error   Units
> TestSlice.vectorSliceOrigin                     1024  thrpt    5  1224.698 ? 53.825  ops/ms
> TestSlice.vectorSliceUnsliceOrigin              1024  thrpt    5   657.895 ? 31.945  ops/ms
> 
> After: 
> Benchmark                                     (size)   Mode  Cnt      Score    Error   Units
> TestSlice.vectorSliceOrigin                     1024  thrpt    5  11221.532 ? 88.616  ops/ms
> TestSlice.vectorSliceUnsliceOrigin              1024  thrpt    5   6509.519 ? 18.102  ops/ms

This pull request has now been integrated.

Changeset: 718d4d48
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/718d4d48
Stats:     43 lines in 8 files changed: 7 ins; 9 del; 27 mod

8262989: Vectorize VectorShuffle checkIndexes, wrapIndexes and laneIsValid methods

Reviewed-by: psandoz

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

PR: https://git.openjdk.java.net/jdk/pull/2819

From darcy at openjdk.java.net  Thu Mar  4 21:40:42 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 4 Mar 2021 21:40:42 GMT
Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and
 synchronized* [v7]
In-Reply-To: <7xhHDLWOUdI4N-4kITQWNCZnSr5mbOTHT_u-sQmg4i8=.778e31ed-01e1-4b09-8063-eb329c432abf@github.com>
References: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
 <YwkWpb8nKfggeA2QmK8y9KfSXrmk8jaxDX7nX6QusFE=.05c584ad-70ab-41ed-bbf5-cc86b18f3f85@github.com>
 <7xhHDLWOUdI4N-4kITQWNCZnSr5mbOTHT_u-sQmg4i8=.778e31ed-01e1-4b09-8063-eb329c432abf@github.com>
Message-ID: <eTjJ1n1y-mLiyf2YoFDd2RTNGZeJF6p7NcqvZy3bhlg=.d98c221a-4e9c-4a99-9242-6fed4ef24e58@github.com>

On Thu, 4 Mar 2021 20:28:58 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert "Avoid wrapping subclasses where relevant. Updated tests."
>>   
>>   This reverts commit dda174c582590827cad3f4006a8ff9e7dd8a51ab.
>
> Marked as reviewed by smarks (Reviewer).

If the checks for Navigable set and the like are omitted, I'd prefer to a comment in the sources noting this is intention as a Navigable set is-a Sorted set.

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

PR: https://git.openjdk.java.net/jdk/pull/2596

From brent.christian at oracle.com  Thu Mar  4 22:00:05 2021
From: brent.christian at oracle.com (Brent Christian)
Date: Thu, 4 Mar 2021 14:00:05 -0800
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v2]
In-Reply-To: <t3fUW2NfjjSjvTrQotLdG23BiQhQDNepd0M9LwEfM7c=.b53c2963-0978-4bc3-9346-93215a93ee19@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <M_HI6rHAd36Rsy0ZS_ya3iFig0vZcyO_s9aK11a2j48=.7513689b-a106-4238-8b6a-f6d0de2109e5@github.com>
 <iKdskMjHNKUrtpQW8tVlLXeasNBbE54041OYUPpTahA=.6bbe649a-25d6-4a79-af08-5a237ffcdfc8@github.com>
 <t3fUW2NfjjSjvTrQotLdG23BiQhQDNepd0M9LwEfM7c=.b53c2963-0978-4bc3-9346-93215a93ee19@github.com>
Message-ID: <5753633a-b925-205b-d3d8-9a9cefb90252@oracle.com>

On 3/4/21 1:16 PM, Craig Andrews wrote:
> 
>> @bchristi-git has indicated that a [compatibility and specification](https://wiki.openjdk.java.net/display/csr/Main) (CSR) request is needed for this pull request.
>> @candrews please create a CSR request and add link to it in [JDK-8262277](https://bugs.openjdk.java.net/browse/JDK-8262277). This pull request cannot be integrated until the CSR request is approved.
> 
> I'm trying to figure out how to create a CSR and I'm not having much luck. According to the [CSR FAQs](https://wiki.openjdk.java.net/display/csr/CSR+FAQs):
>> Q: How do I create a CSR ?
> A: Do not directly create a CSR from the Create Menu. JIRA will let you do this right up until the moment you try to save it and find your typing was in vain.
> Instead you should go to the target bug, select "More", and from the drop down menu select "Create CSR". This is required to properly associate the CSR with the main bug, just as is done for backports.
> 
> However, I don't have an account on https://bugs.openjdk.java.net so I can't do as instructed.
> 
> How do I create the CSR?

OK, yeah - I can create the CSR.  If you can craft some content for the 
Summary, Problem, Solution, and maybe Compatibility Risk Description 
(the risk itself is Low), I can take it from there.

A recent CSR of a somewhat similar 
fix-the-implementation-to-match-the-spec flavor might be:
   https://bugs.openjdk.java.net/browse/JDK-8255997
(though the change there is to *start* throwing an exception :D ).
Anyway, perhaps that might helpful as a reference.

-Brent

From github.com+194713+candrews at openjdk.java.net  Thu Mar  4 22:16:10 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Thu, 4 Mar 2021 22:16:10 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v3]
In-Reply-To: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
Message-ID: <P2fMwQHSRMi8mHgZ1fhawDoBX5GXikUVAX6wnzQqe-s=.26d6d9cd-36e9-466a-b38a-82df7587ee7c@github.com>

> `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.
> 
> According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.
> 
> Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>> Returns:
>>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.
> 
> And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>> Returns:
>>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.
> 
> Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.
> 
> Here's a stack trace:
> java.lang.IllegalArgumentException: name
>         at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>         at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>         at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
> 
> Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>         URL findResource(final String name, boolean check) {
>             URL url;
>             try {
>                 url = new URL(base, ParseUtil.encodePath(name, false));
>             } catch (MalformedURLException e) {
>                 throw new IllegalArgumentException("name");
>             }
> 
> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
> 
> A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>         URL findResource(final String name, boolean check) {
>             URL url;
>             try {
>                 url = new URL(base, ParseUtil.encodePath(name, false));
>             } catch (MalformedURLException e) {
>                 throw new IllegalArgumentException("name");
>             }
> 
> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.

Craig Andrews has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2662/files
  - new: https://git.openjdk.java.net/jdk/pull/2662/files/3f6a974e..e456f886

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2662&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2662&range=01-02

  Stats: 53 lines in 1 file changed: 53 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2662.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2662/head:pull/2662

PR: https://git.openjdk.java.net/jdk/pull/2662

From igraves at openjdk.java.net  Thu Mar  4 22:35:09 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 4 Mar 2021 22:35:09 GMT
Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and
 synchronized* [v8]
In-Reply-To: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
References: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
Message-ID: <ZJDadrPQJTWxHI9GhthY_RBK567MKao0vOgkGx9JV2U=.82771e25-ad97-48f6-94ef-06d1d8cac309@github.com>

> Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Commenting intent to not check for subclasses

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2596/files
  - new: https://git.openjdk.java.net/jdk/pull/2596/files/88127ed5..47113ba0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2596&range=06-07

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

PR: https://git.openjdk.java.net/jdk/pull/2596

From igraves at openjdk.java.net  Thu Mar  4 22:35:10 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 4 Mar 2021 22:35:10 GMT
Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and
 synchronized* [v7]
In-Reply-To: <eTjJ1n1y-mLiyf2YoFDd2RTNGZeJF6p7NcqvZy3bhlg=.d98c221a-4e9c-4a99-9242-6fed4ef24e58@github.com>
References: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
 <YwkWpb8nKfggeA2QmK8y9KfSXrmk8jaxDX7nX6QusFE=.05c584ad-70ab-41ed-bbf5-cc86b18f3f85@github.com>
 <7xhHDLWOUdI4N-4kITQWNCZnSr5mbOTHT_u-sQmg4i8=.778e31ed-01e1-4b09-8063-eb329c432abf@github.com>
 <eTjJ1n1y-mLiyf2YoFDd2RTNGZeJF6p7NcqvZy3bhlg=.d98c221a-4e9c-4a99-9242-6fed4ef24e58@github.com>
Message-ID: <gLo2N2uRTLbESCREAKkv5BxFOx08PkXZpITz8lBORlo=.d4538f0b-2422-4db1-810c-16fa8e62ccfb@github.com>

On Thu, 4 Mar 2021 21:37:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Marked as reviewed by smarks (Reviewer).
>
> If the checks for Navigable set and the like are omitted, I'd prefer to a comment in the sources noting this is intention as a Navigable set is-a Sorted set.

Added comments to the relevant methods noting our intention not to check for subclasses with a little note why.

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

PR: https://git.openjdk.java.net/jdk/pull/2596

From darcy at openjdk.java.net  Thu Mar  4 22:40:51 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 4 Mar 2021 22:40:51 GMT
Subject: RFR: 6323374: (coll) Optimize Collections.unmodifiable* and
 synchronized* [v8]
In-Reply-To: <ZJDadrPQJTWxHI9GhthY_RBK567MKao0vOgkGx9JV2U=.82771e25-ad97-48f6-94ef-06d1d8cac309@github.com>
References: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
 <ZJDadrPQJTWxHI9GhthY_RBK567MKao0vOgkGx9JV2U=.82771e25-ad97-48f6-94ef-06d1d8cac309@github.com>
Message-ID: <vSEereunDYm4qyfiy-_hFY2CzX9lyBKeWGwHQNStThA=.fdd31a25-324b-4fde-b5a8-12fd34f9c5e1@github.com>

On Thu, 4 Mar 2021 22:35:09 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Commenting intent to not check for subclasses

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2596

From almatvee at openjdk.java.net  Thu Mar  4 23:52:38 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 4 Mar 2021 23:52:38 GMT
Subject: RFR: 8262300: jpackage app-launcher fails on linux when using
 JDK11 based runtime
In-Reply-To: <G_ZEkT4oFSK2er0qt-2TK6NvW6iUsf_zjlr_RMaxjDE=.f451e115-48d7-48c3-b281-62669d3f00e4@github.com>
References: <G_ZEkT4oFSK2er0qt-2TK6NvW6iUsf_zjlr_RMaxjDE=.f451e115-48d7-48c3-b281-62669d3f00e4@github.com>
Message-ID: <mupyssx6gYhKKJJUGNYNognsiGBJztvBWQccU2Ql2IY=.3d4b867e-279d-4914-ae56-72e3b7e8ebe4@github.com>

On Thu, 4 Mar 2021 12:32:11 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix jpackage app launcher to also look for JLI lib in "lib/jli/libjli.so" subdirectory of runtime

Marked as reviewed by almatvee (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2827

From asemenyuk at openjdk.java.net  Fri Mar  5 00:21:38 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 5 Mar 2021 00:21:38 GMT
Subject: Integrated: 8262300: jpackage app-launcher fails on linux when using
 JDK11 based runtime
In-Reply-To: <G_ZEkT4oFSK2er0qt-2TK6NvW6iUsf_zjlr_RMaxjDE=.f451e115-48d7-48c3-b281-62669d3f00e4@github.com>
References: <G_ZEkT4oFSK2er0qt-2TK6NvW6iUsf_zjlr_RMaxjDE=.f451e115-48d7-48c3-b281-62669d3f00e4@github.com>
Message-ID: <OhczHPrkKnSnyKdrNWkkad-LMGsvuit_nWwH0tamtAY=.877878a9-2c31-4267-907f-22cbb6c9e07c@github.com>

On Thu, 4 Mar 2021 12:32:11 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix jpackage app launcher to also look for JLI lib in "lib/jli/libjli.so" subdirectory of runtime

This pull request has now been integrated.

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

8262300: jpackage app-launcher fails on linux when using JDK11 based runtime

Reviewed-by: herrick, almatvee

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

PR: https://git.openjdk.java.net/jdk/pull/2827

From igraves at openjdk.java.net  Fri Mar  5 03:23:49 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 5 Mar 2021 03:23:49 GMT
Subject: Integrated: 6323374: (coll) Optimize Collections.unmodifiable* and
 synchronized*
In-Reply-To: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
References: <Hk_6PZRBxM5VfnG3DGQWSuvR--XOH41uDCMwoRK0Pm8=.10df6c1f-e8b3-4e69-9971-4ef4cef8fa0c@github.com>
Message-ID: <dJ6QMHG-Xziz4GsakX-LF7WAINaEYV7K0qZJ4lI9o3Q=.15a0d77c-097e-4a9a-a002-f86116b2bc6b@github.com>

On Tue, 16 Feb 2021 21:57:43 GMT, Ian Graves <igraves at openjdk.org> wrote:

> Modify the `unmodifiable*` methods in `java.util.Collections` to be idempotent. That is, when given an immutable collection from `java.util.ImmutableCollections` or `java.util.Collections`, these methods will return the reference instead of creating a new immutable collection that wraps the existing one.

This pull request has now been integrated.

Changeset: dbef0ec9
Author:    Ian Graves <igraves at openjdk.org>
Committer: Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dbef0ec9
Stats:     146 lines in 2 files changed: 145 ins; 0 del; 1 mod

6323374: (coll) Optimize Collections.unmodifiable* and synchronized*

Reviewed-by: redestad, smarks, darcy

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

PR: https://git.openjdk.java.net/jdk/pull/2596

From github.com+4146708+a74nh at openjdk.java.net  Fri Mar  5 11:14:49 2021
From: github.com+4146708+a74nh at openjdk.java.net (Alan Hayward)
Date: Fri, 5 Mar 2021 11:14:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <yPuti6hI-2ryTux1GdrZHAcP0n0esc5E1PCPXvm389o=.70b78b9a-365e-4a80-8903-e9a0b822492f@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
 <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
 <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>
 <yPuti6hI-2ryTux1GdrZHAcP0n0esc5E1PCPXvm389o=.70b78b9a-365e-4a80-8903-e9a0b822492f@github.com>
Message-ID: <ALwCIkHXaVHDCuuko2Vku6HZhRqcVV26sF52Jxl7VvI=.0ba86f48-03fd-46d1-93c3-f2a12effe999@github.com>

On Thu, 4 Mar 2021 18:19:33 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> Hello
> there is one issue with the info you provided, it's from Xcode12.5 beta.
> And beta license agreement forbids sharing output of beta version of compiler&co
> So we can't say we have issue with newer xcode beta until that beta went public & released.
> Fixing issues you found now will mean someone have violated xcode beta license agreement and made these issues public.

Ok, I wasn't aware of that. I'll downgrade back to the non-beta version.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From raffaello.giulietti at gmail.com  Fri Mar  5 15:08:15 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Fri, 5 Mar 2021 16:08:15 +0100
Subject: Contributing to 8259896: Base64 MIME decoder should allow
 unrecognised characters within padding
Message-ID: <c698e2c3-2835-05f0-326f-fd8149d6d1ad@gmail.com>

Hello,

I can contribute in solving the issue [1] mentioned in [2].

But before investing time, I just want to make sure that there is some 
consensus that it needs to be solved in the first place. Maybe there are 
diverging opinions that consider the current behavior as correct.


Greetings
Raffaello

----

[1] https://bugs.openjdk.java.net/browse/JDK-8259896
[2] 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-February/074407.html


> Hello Raffaello,
> 
> I have added this comment from you, to that JDK-8259896 issue.
> 
> -Jaikiran
> 
> On 02/02/21 12:43 am, Raffaello Giulietti wrote:
>> Hi,
>>
>> in my opinion, the reporter of [1] is right in requiring that 
>> extraneous characters be discarded, even inside the padding.
>>
>> Indeed, the first full paragraph on [2] reads:
>>
>> "Any characters outside of the base64 alphabet are to be ignored in
>> base64-encoded data."
>>
>> where "the base64 alphabet" also includes the padding character '=' 
>> and "base64-encoded data" extends to padding as well, because padding 
>> is an essential part of encoding.
>>
>> The legitimate doubt expressed in comment [3] should thus be solved in 
>> favor of a bug fix.
>>
>>
>> My 2 cents
>> Greetings
>> Raffaello
>>
>> ----
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8259896
>> [2] https://tools.ietf.org/html/rfc2045#page-26
>> [3] 
>> https://bugs.openjdk.java.net/browse/JDK-8259896?focusedCommentId=14395485&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14395485
>>
> 

From redestad at openjdk.java.net  Fri Mar  5 16:02:42 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 5 Mar 2021 16:02:42 GMT
Subject: RFR: 8263091: Remove CharacterData.isOtherUppercase/-Lowercase
In-Reply-To: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
References: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
Message-ID: <O2izZ1umCuor3NLuKOQoP-XxKENBh3Cp2jvBv3JbilU=.2101b6ee-dddf-40d5-a9cb-5c123bd88cfd@github.com>

On Fri, 5 Mar 2021 14:24:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch removes the CharacterData.isOtherUppercase and isOtherLowercase methods. It also exploits the fact that isOtherUppercase is always false for all codepoints in the CharacterDataLatin1 range for a small speed-up.
> 
> I have no means to test if this is correct on PPC, which has intrinsics for isLowerCase/isUpperCase, but unless I'm reading the code wrong the intrinsic for isLowerCase on PPC already appears to effectively do the fused logic of isLowerCase(ch) || isOtherLowerCase(ch) since it handles the two values where isLowerCase and isOtherLowercase disagrees (0xaa, 0xba), which means this change should make the intrinsic and the java code be in better agreement.

Microbenchmark results, org.openjdk.bench.java.lang.Characters

OOTB:
Benchmark               (codePoint)  Mode  Cnt   Score   Error  Units
Characters.isLowerCase          176  avgt    5  13.812 ? 0.060  ns/op
Characters.isUpperCase          176  avgt    5  13.812 ? 0.062  ns/op

Benchmark               (codePoint)  Mode  Cnt   Score   Error  Units
Characters.isLowerCase          176  avgt    5  13.825 ? 0.096  ns/op
Characters.isUpperCase          176  avgt    5  12.555 ? 0.033  ns/op
~1.1x speed-up for Character.isUpperCase in the latin 1 range

-Xint:
Benchmark               (codePoint)  Mode  Cnt    Score    Error  Units
Characters.isLowerCase          176  avgt    5  754.756 ? 20.815  ns/op
Characters.isUpperCase          176  avgt    5  755.403 ? 15.645  ns/op

Benchmark               (codePoint)  Mode  Cnt    Score   Error  Units
Characters.isLowerCase          176  avgt    5  606.923 ? 1.569  ns/op
Characters.isUpperCase          176  avgt    5  521.073 ? 7.439  ns/op
1.25x speed-up for isLowerCase and 1.45x speed-up for isUpperCase when interpreting, translating to minor startup / warmup win on some examined apps.

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

PR: https://git.openjdk.java.net/jdk/pull/2846

From redestad at openjdk.java.net  Fri Mar  5 16:02:29 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 5 Mar 2021 16:02:29 GMT
Subject: RFR: 8263091: Remove CharacterData.isOtherUppercase/-Lowercase
Message-ID: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>

This patch removes the CharacterData.isOtherUppercase and isOtherLowercase methods. It also exploits the fact that isOtherUppercase is always false for all codepoints in the CharacterDataLatin1 range for a small speed-up.

I have no means to test if this is correct on PPC, which has intrinsics for isLowerCase/isUpperCase, but unless I'm reading the code wrong the intrinsic for isLowerCase on PPC already appears to effectively do the fused logic of isLowerCase(ch) || isOtherLowerCase(ch) since it handles the two values where isLowerCase and isOtherLowercase disagrees (0xaa, 0xba), which means this change should make the intrinsic and the java code be in better agreement.

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

Commit messages:
 - Fold CharacterData.isOtherUpper-/Lowercase into isUpper-/LowerCase

Changes: https://git.openjdk.java.net/jdk/pull/2846/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2846&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263091
  Stats: 98 lines in 8 files changed: 1 ins; 71 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2846.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2846/head:pull/2846

PR: https://git.openjdk.java.net/jdk/pull/2846

From github.com+194713+candrews at openjdk.java.net  Fri Mar  5 16:02:49 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Fri, 5 Mar 2021 16:02:49 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v4]
In-Reply-To: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
Message-ID: <hNKo6pHM9KObvLVnSeUfvmWCnsu8Ep2NGOtd6BxcFsA=.e8f771e9-0ba5-433b-8bf4-29da54b2df93@github.com>

> `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.
> 
> According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.
> 
> Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>> Returns:
>>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.
> 
> And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>> Returns:
>>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.
> 
> Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.
> 
> Here's a stack trace:
> java.lang.IllegalArgumentException: name
>         at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>         at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>         at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
> 
> Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>         URL findResource(final String name, boolean check) {
>             URL url;
>             try {
>                 url = new URL(base, ParseUtil.encodePath(name, false));
>             } catch (MalformedURLException e) {
>                 throw new IllegalArgumentException("name");
>             }
> 
> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
> 
> A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>         URL findResource(final String name, boolean check) {
>             URL url;
>             try {
>                 url = new URL(base, ParseUtil.encodePath(name, false));
>             } catch (MalformedURLException e) {
>                 throw new IllegalArgumentException("name");
>             }
> 
> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.

Craig Andrews has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2662/files
  - new: https://git.openjdk.java.net/jdk/pull/2662/files/e456f886..79869e78

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2662&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2662&range=02-03

  Stats: 107 lines in 2 files changed: 54 ins; 53 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2662.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2662/head:pull/2662

PR: https://git.openjdk.java.net/jdk/pull/2662

From alanb at openjdk.java.net  Fri Mar  5 16:04:09 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 5 Mar 2021 16:04:09 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v3]
In-Reply-To: <P2fMwQHSRMi8mHgZ1fhawDoBX5GXikUVAX6wnzQqe-s=.26d6d9cd-36e9-466a-b38a-82df7587ee7c@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <P2fMwQHSRMi8mHgZ1fhawDoBX5GXikUVAX6wnzQqe-s=.26d6d9cd-36e9-466a-b38a-82df7587ee7c@github.com>
Message-ID: <fCB5v_PJD0ADN-kUPmvJKe8P3E9kXkx7UejtFGYVulU=.74707f5f-11c5-4f01-9cd8-dfa9c21b9cc6@github.com>

On Thu, 4 Mar 2021 22:16:10 GMT, Craig Andrews <github.com+194713+candrews at openjdk.org> wrote:

>> `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.
>> 
>> According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.
>> 
>> Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>>> Returns:
>>>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.
>> 
>> And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>>> Returns:
>>>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.
>> 
>> Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.
>> 
>> Here's a stack trace:
>> java.lang.IllegalArgumentException: name
>>         at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>>         at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>>         at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
>> 
>> Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>>         URL findResource(final String name, boolean check) {
>>             URL url;
>>             try {
>>                 url = new URL(base, ParseUtil.encodePath(name, false));
>>             } catch (MalformedURLException e) {
>>                 throw new IllegalArgumentException("name");
>>             }
>> 
>> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
>> 
>> A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>>         URL findResource(final String name, boolean check) {
>>             URL url;
>>             try {
>>                 url = new URL(base, ParseUtil.encodePath(name, false));
>>             } catch (MalformedURLException e) {
>>                 throw new IllegalArgumentException("name");
>>             }
>> 
>> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
>
> Craig Andrews has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException

test/jdk/java/net/URLClassLoader/TestBug8262277.java line 30:

> 28:  * @summary Test to see if URLClassLoader.getResource and URLClassLoader.getResources
> 29:  * throw IllegalArgumentException
> 30:  */

I'd prefer if the test checked that findResource returned null and that findResources returned an empty enumeration. I think we should be able to find a better name for the test too.
Do you really want the author tag in the test? I know they exist in some tests but they are impossible to remove, even when tests/code are significantly changed by someone else.

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From github.com+194713+candrews at openjdk.java.net  Fri Mar  5 16:04:27 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Fri, 5 Mar 2021 16:04:27 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v3]
In-Reply-To: <fCB5v_PJD0ADN-kUPmvJKe8P3E9kXkx7UejtFGYVulU=.74707f5f-11c5-4f01-9cd8-dfa9c21b9cc6@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <P2fMwQHSRMi8mHgZ1fhawDoBX5GXikUVAX6wnzQqe-s=.26d6d9cd-36e9-466a-b38a-82df7587ee7c@github.com>
 <fCB5v_PJD0ADN-kUPmvJKe8P3E9kXkx7UejtFGYVulU=.74707f5f-11c5-4f01-9cd8-dfa9c21b9cc6@github.com>
Message-ID: <6BSmo6vl6jtvCRfrnZn5ziXSLXZzoLjZjFytShM8QV8=.411e1b2f-2c51-454e-9213-ac9d309d06e1@github.com>

On Fri, 5 Mar 2021 15:42:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'd prefer if the test checked that findResource returned null and that findResources returned an empty enumeration.

I'll update the test accordingly.

>  think we should be able to find a better name for the test too.
> Do you really want the author tag in the test? I know they exist in some tests but they are impossible to remove, even when tests/code are significantly changed by someone else.

I can rename the test class to be something descriptive and remove the `@author` tag. I was following other tests which is why I did it this way.

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From github.com+194713+candrews at openjdk.java.net  Fri Mar  5 16:04:48 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Fri, 5 Mar 2021 16:04:48 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v3]
In-Reply-To: <6BSmo6vl6jtvCRfrnZn5ziXSLXZzoLjZjFytShM8QV8=.411e1b2f-2c51-454e-9213-ac9d309d06e1@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <P2fMwQHSRMi8mHgZ1fhawDoBX5GXikUVAX6wnzQqe-s=.26d6d9cd-36e9-466a-b38a-82df7587ee7c@github.com>
 <fCB5v_PJD0ADN-kUPmvJKe8P3E9kXkx7UejtFGYVulU=.74707f5f-11c5-4f01-9cd8-dfa9c21b9cc6@github.com>
 <6BSmo6vl6jtvCRfrnZn5ziXSLXZzoLjZjFytShM8QV8=.411e1b2f-2c51-454e-9213-ac9d309d06e1@github.com>
Message-ID: <RdlUaDVO3LfV30kC9q_IOOoo435DZMCbq0u8fQXaElA=.373517a2-0b79-4eaf-80ea-d5b5bdefbae0@github.com>

On Fri, 5 Mar 2021 15:46:40 GMT, Craig Andrews <github.com+194713+candrews at openjdk.org> wrote:

>> test/jdk/java/net/URLClassLoader/TestBug8262277.java line 30:
>> 
>>> 28:  * @summary Test to see if URLClassLoader.getResource and URLClassLoader.getResources
>>> 29:  * throw IllegalArgumentException
>>> 30:  */
>> 
>> I'd prefer if the test checked that findResource returned null and that findResources returned an empty enumeration. I think we should be able to find a better name for the test too.
>> Do you really want the author tag in the test? I know they exist in some tests but they are impossible to remove, even when tests/code are significantly changed by someone else.
>
>> I'd prefer if the test checked that findResource returned null and that findResources returned an empty enumeration.
> 
> I'll update the test accordingly.
> 
>>  think we should be able to find a better name for the test too.
>> Do you really want the author tag in the test? I know they exist in some tests but they are impossible to remove, even when tests/code are significantly changed by someone else.
> 
> I can rename the test class to be something descriptive and remove the `@author` tag. I was following other tests which is why I did it this way.

I've made the changes you requested.

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From redestad at openjdk.java.net  Fri Mar  5 16:05:57 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 5 Mar 2021 16:05:57 GMT
Subject: RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category)
In-Reply-To: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
Message-ID: <EWJC3tddBAKgivUj0vL70irZShN4dqXulLLkAHu8Ffg=.89f05c27-45b9-4a17-b120-1c5aff4fb582@github.com>

On Fri, 5 Mar 2021 14:14:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.

Results on the provided, simple microbenchmark

Baseline:
Benchmark                         Mode  Cnt   Score   Error  Units
LocaleDefaults.getDefault         avgt    5  11.142 ? 0.084  ns/op
LocaleDefaults.getDefaultDisplay  avgt    5  14.024 ? 0.063  ns/op
LocaleDefaults.getDefaultFormat   avgt    5  14.001 ? 0.072  ns/op
Patch:
Benchmark                         Mode  Cnt   Score   Error  Units
LocaleDefaults.getDefault         avgt    5  11.210 ? 0.057  ns/op
LocaleDefaults.getDefaultDisplay  avgt    5  12.597 ? 0.022  ns/op
LocaleDefaults.getDefaultFormat   avgt    5  12.608 ? 0.049  ns/op

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

PR: https://git.openjdk.java.net/jdk/pull/2845

From redestad at openjdk.java.net  Fri Mar  5 16:05:54 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 5 Mar 2021 16:05:54 GMT
Subject: RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category)
Message-ID: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>

This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.

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

Commit messages:
 - Add microbenchmark
 - Reduce volatile reads in Locale.getDefault(Category)

Changes: https://git.openjdk.java.net/jdk/pull/2845/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2845&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263090
  Stats: 92 lines in 2 files changed: 72 ins; 5 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2845.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2845/head:pull/2845

PR: https://git.openjdk.java.net/jdk/pull/2845

From rriggs at openjdk.java.net  Fri Mar  5 16:39:06 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 5 Mar 2021 16:39:06 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers
In-Reply-To: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
Message-ID: <KMwMpB2d88RVYH8eJJfVjiGKtB_Z1d1NeucsJWk6peM=.9edbc035-6e67-41a3-8a0f-d96a1092b588@github.com>

On Thu, 4 Mar 2021 17:20:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch optimizes String.format expressions that uses trivial specifiers. In the JDK, the most common variation of String.format is a variation of format("foo: %s", s), which gets a significant speed-up from this.
> 
> Various other cleanups and minor improvements reduce overhead further and ensure we get a small gain also for more complex format strings.

Looks good.

src/java.base/share/classes/java/util/Formatter.java line 3017:

> 3015:                 s = ((Character)arg).toString();
> 3016:             } else if (arg instanceof Byte) {
> 3017:                 byte i = (Byte) arg;

Can the pattern matching for instanceof be used here to remove explicit casts.  (Supported in JDK 16) 
 s = null;
            if (arg instanceof Character c) {
                s = c.toString();
            } else if (arg instanceof Byte i) {
                if (Character.isValidCodePoint(i))
                    s = new String(Character.toChars(i));
                else
                    throw new IllegalFormatCodePointException(i);
            } else if (arg instanceof Short i) {
                if (Character.isValidCodePoint(i))
                    s = new String(Character.toChars(i));
                else
                    throw new IllegalFormatCodePointException(i);
            } ```
etc..

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2830

From redestad at openjdk.java.net  Fri Mar  5 17:06:16 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 5 Mar 2021 17:06:16 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers
In-Reply-To: <KMwMpB2d88RVYH8eJJfVjiGKtB_Z1d1NeucsJWk6peM=.9edbc035-6e67-41a3-8a0f-d96a1092b588@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
 <KMwMpB2d88RVYH8eJJfVjiGKtB_Z1d1NeucsJWk6peM=.9edbc035-6e67-41a3-8a0f-d96a1092b588@github.com>
Message-ID: <KUXdjaIYgAuKQ8vywohqU8rbO3WboiRPrlDKI68cFaY=.490dbe62-dc39-4c68-8ba7-1fd875fc9e06@github.com>

On Fri, 5 Mar 2021 16:36:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This patch optimizes String.format expressions that uses trivial specifiers. In the JDK, the most common variation of String.format is a variation of format("foo: %s", s), which gets a significant speed-up from this.
>> 
>> Various other cleanups and minor improvements reduce overhead further and ensure we get a small gain also for more complex format strings.
>
> src/java.base/share/classes/java/util/Formatter.java line 3017:
> 
>> 3015:                 s = ((Character)arg).toString();
>> 3016:             } else if (arg instanceof Byte) {
>> 3017:                 byte i = (Byte) arg;
> 
> Can the pattern matching for instanceof be used here to remove explicit casts.  (Supported in JDK 16) 
>  s = null;
>             if (arg instanceof Character c) {
>                 s = c.toString();
>             } else if (arg instanceof Byte i) {
>                 if (Character.isValidCodePoint(i))
>                     s = new String(Character.toChars(i));
>                 else
>                     throw new IllegalFormatCodePointException(i);
>             } else if (arg instanceof Short i) {
>                 if (Character.isValidCodePoint(i))
>                     s = new String(Character.toChars(i));
>                 else
>                     throw new IllegalFormatCodePointException(i);
>             } ```
> etc..

I did think about it, but it seemed to stray a bit too far from the intent of this enhancement.

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

PR: https://git.openjdk.java.net/jdk/pull/2830

From rriggs at openjdk.java.net  Fri Mar  5 17:11:18 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 5 Mar 2021 17:11:18 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers
In-Reply-To: <KUXdjaIYgAuKQ8vywohqU8rbO3WboiRPrlDKI68cFaY=.490dbe62-dc39-4c68-8ba7-1fd875fc9e06@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
 <KMwMpB2d88RVYH8eJJfVjiGKtB_Z1d1NeucsJWk6peM=.9edbc035-6e67-41a3-8a0f-d96a1092b588@github.com>
 <KUXdjaIYgAuKQ8vywohqU8rbO3WboiRPrlDKI68cFaY=.490dbe62-dc39-4c68-8ba7-1fd875fc9e06@github.com>
Message-ID: <8xC024CKqz1b-NvGwL1HHudDIQFsKp1LZZ8MkljGB1k=.a2811f0b-6e88-4de7-8fa7-489e8f69fb29@github.com>

On Fri, 5 Mar 2021 17:03:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Formatter.java line 3017:
>> 
>>> 3015:                 s = ((Character)arg).toString();
>>> 3016:             } else if (arg instanceof Byte) {
>>> 3017:                 byte i = (Byte) arg;
>> 
>> Can the pattern matching for instanceof be used here to remove explicit casts.  (Supported in JDK 16) 
>>  s = null;
>>             if (arg instanceof Character c) {
>>                 s = c.toString();
>>             } else if (arg instanceof Byte i) {
>>                 if (Character.isValidCodePoint(i))
>>                     s = new String(Character.toChars(i));
>>                 else
>>                     throw new IllegalFormatCodePointException(i);
>>             } else if (arg instanceof Short i) {
>>                 if (Character.isValidCodePoint(i))
>>                     s = new String(Character.toChars(i));
>>                 else
>>                     throw new IllegalFormatCodePointException(i);
>>             } ```
>> etc..
>
> I did think about it, but it seemed to stray a bit too far from the intent of this enhancement.

I only looked at it because of the updates to use switch expressions...
ok, either way.

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

PR: https://git.openjdk.java.net/jdk/pull/2830

From rriggs at openjdk.java.net  Fri Mar  5 17:19:06 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 5 Mar 2021 17:19:06 GMT
Subject: RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category)
In-Reply-To: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
Message-ID: <S0enrGp7NE314TyzvIvfR91dEyJniWIV2sQA3JTMcD8=.d5b562dd-65e2-4272-9145-739851817988@github.com>

On Fri, 5 Mar 2021 14:14:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2845

From rriggs at openjdk.java.net  Fri Mar  5 17:22:07 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 5 Mar 2021 17:22:07 GMT
Subject: RFR: 8263091: Remove CharacterData.isOtherUppercase/-Lowercase
In-Reply-To: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
References: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
Message-ID: <6T0y3MQwo4256VsX9FBxM0QaDwI4FXqn_IBv1PVOBGg=.8c53ab06-617e-4d2c-9a2a-7361e449ad12@github.com>

On Fri, 5 Mar 2021 14:24:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch removes the CharacterData.isOtherUppercase and isOtherLowercase methods. It also exploits the fact that isOtherUppercase is always false for all codepoints in the CharacterDataLatin1 range for a small speed-up.
> 
> I have no means to test if this is correct on PPC, which has intrinsics for isLowerCase/isUpperCase, but unless I'm reading the code wrong the intrinsic for isLowerCase on PPC already appears to effectively do the fused logic of isLowerCase(ch) || isOtherLowerCase(ch) since it handles the two values where isLowerCase and isOtherLowercase disagrees (0xaa, 0xba), which means this change should make the intrinsic and the java code be in better agreement.

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2846

From rrich at openjdk.java.net  Fri Mar  5 17:28:24 2021
From: rrich at openjdk.java.net (Richard Reingruber)
Date: Fri, 5 Mar 2021 17:28:24 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <ALwCIkHXaVHDCuuko2Vku6HZhRqcVV26sF52Jxl7VvI=.0ba86f48-03fd-46d1-93c3-f2a12effe999@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <WlU-by8oEfoJIVOKjkhNLCPUuW4DdRMAFIO6PWIPzb4=.cbc4742c-d113-4d20-b5f3-9a42655f9b86@github.com>
 <DFLFDkNJ30yiF-YpFG6-NtwDi1iYo__6EgymUpCsXiM=.a622ede5-cd91-44a9-9c93-bc81e25872b4@github.com>
 <2vF8YcQ9CgnLxMus9tHTd4HmFITeH5wddBKzH-QNNEY=.dbfb2cd5-5997-4b79-88a5-d8292fc56965@github.com>
 <tBipBlvx8GoWStqMaVuNMNwr9KpINTecikQczUCv_wI=.18cc127c-8450-430c-a5a3-7dbcd2075ef1@github.com>
 <nPJsUts1-fZDvRZPsROWtSLOP7slGCUYUcjXcSu4d-E=.2b8a7229-13b4-4f07-82bc-fc762c55c526@github.com>
 <yPuti6hI-2ryTux1GdrZHAcP0n0esc5E1PCPXvm389o=.70b78b9a-365e-4a80-8903-e9a0b822492f@github.com>
 <ALwCIkHXaVHDCuuko2Vku6HZhRqcVV26sF52Jxl7VvI=.0ba86f48-03fd-46d1-93c3-f2a12effe999@github.com>
Message-ID: <lQbCTtxrMGtcQ9annTOJa_zUPL3db1ETRwVp2sBJ5qA=.611f9f30-fcfa-4f3d-b9b3-11a03b012fb3@github.com>

On Fri, 5 Mar 2021 11:11:44 GMT, Alan Hayward <github.com+4146708+a74nh at openjdk.org> wrote:

>>> I was building this PR on a new machine, and I now get the following error:
>>> 
>>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:258:31: error: cast to smaller integer type 'MIDIClientRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>>> > static MIDIClientRef client = (MIDIClientRef) NULL;
>>> > ^~~~~~~~~~~~~~~~~~~~
>>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:259:29: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>>> > static MIDIPortRef inPort = (MIDIPortRef) NULL;
>>> > ^~~~~~~~~~~~~~~~~~
>>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:260:30: error: cast to smaller integer type 'MIDIPortRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>>> > static MIDIPortRef outPort = (MIDIPortRef) NULL;
>>> > ^~~~~~~~~~~~~~~~~~
>>> > /Users/alahay01/java/gerrit_jdk/src/java.desktop/macosx/native/libjsound/PLATFORM_API_MacOSX_MidiUtils.c:466:32: error: cast to smaller integer type 'MIDIEndpointRef' (aka 'unsigned int') from 'void *' [-Werror,-Wvoid-pointer-to-int-cast]
>>> > MIDIEndpointRef endpoint = (MIDIEndpointRef) NULL;
>>> > ^~~~~~~~~~~~~~~~~~~~~~
>>> > 4 errors generated.
>>> 
>>> As far as I can tell the only difference between the two systems is the xcode version:
>>> 
>>> New system (failing)
>>> % xcodebuild -version
>>> Xcode 12.5
>>> Build version 12E5244e
>>> 
>>> Old system (working)
>>> % xcodebuild -version
>>> Xcode 12.4
>>> Build version 12D4e
>>> 
>>> Looks like the newer version of Xcode is being a little stricter with casting?
>>> Replacing the NULL with 0 seems to fix the issue.
>> 
>> Hello
>> there is one issue with the info you provided, it's from Xcode12.5 beta.
>> And beta license agreement forbids sharing output of beta version of compiler&co
>> So we can't say we have issue with newer xcode beta until that beta went public & released.
>> Fixing issues you found now will mean someone have violated xcode beta license agreement and made these issues public.
>
>> Hello
>> there is one issue with the info you provided, it's from Xcode12.5 beta.
>> And beta license agreement forbids sharing output of beta version of compiler&co
>> So we can't say we have issue with newer xcode beta until that beta went public & released.
>> Fixing issues you found now will mean someone have violated xcode beta license agreement and made these issues public.
> 
> Ok, I wasn't aware of that. I'll downgrade back to the non-beta version.

Hi,

@VladimirKempik reported failure of CompressedClassPointers.largeHeapAbove32GTest() with [JDK-8262895](https://bugs.openjdk.java.net/browse/JDK-8262895) on macos_aarch64.

He also helped analyzing the issue (thanks!).

Apparently the vm has difficulties mapping the heap of 31GB at one of the preferred addresses given in
[`get_attach_addresses_for_disjoint_mode()`](https://github.com/openjdk/jdk/blob/8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81/src/hotspot/share/memory/virtualspace.cpp#L477). This causes the test failure indirectly.

IMO it could be worth the effort to find out why the heap cannot be mapped at the preferred addresses. Reviewers should decide on it. I wouldn't be able to do it myself though as I don't have access to a macos_aarch64 system.

Alternatively I'd suggest to exlude macos_aarch64 from the subtest largeHeapAbove32GTest.

Best regards,
Richard.

--

#### Details of the analysis

In the following trace we see the vm trying to allocate the heap at addresses given in [`get_attach_addresses_for_disjoint_mode()`](https://github.com/openjdk/jdk/blob/8d3de4b1bdb5dc13bb7724596dc2123ba05bbb81/src/hotspot/share/memory/virtualspace.cpp#L477) without success:

images/jdk/bin/java  -XX:+UnlockDiagnosticVMOptions -XX:+UnlockExperimentalVMOptions -Xmx31g -XX:-UseAOT -Xlog:gc+metaspace=trace,cds=trace,heap+gc+exit=info,gc+heap+coops=trace -Xshare:off -XX:+VerifyBeforeGC -XX:HeapSearchSteps=40 -version
OpenJDK 64-Bit Server VM warning: Shared spaces are not supported in this VM
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000001000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000001800000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000002000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000004000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0000005000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0008000000000000 heap of size 0x7c1000000
[0.005s][trace][gc,heap,coops] Trying to allocate at address 0x0010000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0018000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0020000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0080000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0100000000000000 heap of size 0x7c1000000
[0.006s][trace][gc,heap,coops] Trying to allocate at address 0x0110000000000000 heap of size 0x7c1000000

Finally it gives up and lets the os chose the address:

[0.006s][trace][gc,heap,coops] Trying to allocate at address NULL heap of size 0x7c1000000
[0.006s][debug][gc,heap,coops] Protected page at the reserved heap base: 0x0000000280000000 / 16777216 bytes
[0.006s][debug][gc,heap,coops] Heap address: 0x0000000281000000, size: 31744 MB, Compressed Oops mode: Non-zero based: 0x0000000280000000, Oop shift amount: 3

The os chooses to map the heap at 0x0000000281000000 that is at 10GB. This leaves not much room for a 4GB (*) aligned compressed class space below 32G for a zero based encoding. And indeed we get a compressed class space with an encoding base that is not zero and largeHeapAbove32GTest fails then

[0.007s][info ][gc,metaspace ] Compressed class space mapped at: 0x0000007000000000-0x0000007040000000, reserved size: 1073741824
[0.007s][info ][gc,metaspace ] Narrow klass base: 0x0000007000000000, Narrow klass shift: 0, Narrow klass range: 0x40000000
On macos 10.15 (x86_64) the vm succeeds first try mapping the heap at address 0x0000001000000000.

(*) On aarch64 the encoding base has to be 4GB aligned. Unfortunately the 4GB alignment is enforced to strictly on the start address of the compressed class space instead of enforcing it on the encoding base. See [JDK-8258756](https://bugs.openjdk.java.net/browse/JDK-8258756)

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From naoto at openjdk.java.net  Fri Mar  5 17:32:06 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 5 Mar 2021 17:32:06 GMT
Subject: RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category)
In-Reply-To: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
Message-ID: <PGnyOMqtHpgWAEG1JAKP5oX6T1JHG9ZEvBLJxRnXfvQ=.9c69f8b3-646b-4941-b344-f5d8e5b85219@github.com>

On Fri, 5 Mar 2021 14:14:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.

src/java.base/share/classes/java/util/Locale.java line 959:

> 957:     }
> 958: 
> 959:     private static Locale getDisplayLocale() {

Should this be `synchronized`?

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

PR: https://git.openjdk.java.net/jdk/pull/2845

From vladimir.kozlov at oracle.com  Fri Mar  5 17:41:24 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 5 Mar 2021 09:41:24 -0800
Subject: ThreadLocal lookup elimination
In-Reply-To: <CA+pBWhsRSPhfV9MT_iz8Gddzz0jxU+f0U2sajvd5XNXum1kq0g@mail.gmail.com>
References: <CA+pBWhsRSPhfV9MT_iz8Gddzz0jxU+f0U2sajvd5XNXum1kq0g@mail.gmail.com>
Message-ID: <316f7179-6003-7db9-e934-918615691618@oracle.com>

Hi Erik,

The implementation of ThreadLocal is based on HashMap:
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/ThreadLocal.java#L76

Currently it is "impossible" for JIT compiler to reliably know that value stored by set() in hash map is the same as 
read by get().

Also because of ThreadLocal accessors's complex code, some calls may not be inlined and JIT does not know what side 
effect they may have - it assumes that they can modify a value.

Thanks,
Vladimir K

On 2/22/21 3:26 AM, Eirik Bj?rsn?s wrote:
> Hello,
> 
> ThreadLocals are commonly used to transfer state across method boundaries
> in situations where passing them as method parameters is impractical.
> Examples include crossing APIs you don't own, or instrumenting code you
> don't own.
> 
> Consider the following pseudo-instrumented code (where the original code
> calls a getter inside a loop):
> 
> public class Student {
> 
>      private int age;
> 
>      public int maxAge(Student[] students) {
> 
>          // Instrumented code:
>          ExpensiveObject expensive = new ExpensiveObject();
>          expensive.recordSomething();
>          threadLocal.set(expensive);
> 
>          // Original code:
>          int max = 0;
>          for (Student student : students) {
>              max = Math.max(max, student.getAge());
>          }
>          return max;
>      }
> 
>      public int getAge() {
>          // Instrumented code
>          ExpensiveObject exp = threadLocal.get();
>          exp.recordSomething();
> 
>          // Original code:
>          return age;
>      }
> 
>      // Instrumented field:
>      private static ThreadLocal<ExpensiveObject> threadLocal = new
> ThreadLocal<>();
> }
> 
> The ThreadLocal is used here to avoid constructing ExpensiveObject
> instances in each invocation of getAge.
> 
> However, once a compiler worth its salt sees this code, it immediately
> wants to inline the getAge method:
> 
> // Instrumented code:
> ExpensiveObject expensive = new ExpensiveObject();
> expensive.recordSomething();
> threadLocal.set(expensive);
> 
> for (Student student : students) {
>      // Instrumented code
>      ExpensiveObject exp = threadLocal.get();
>      exp.recordSomething();
>      // Original code
>      max = Math.max(max, student.age);
> }
> 
> At this point, we see that the last write to threadLocal is 'expensive', so
> any following  'threadLocal.get()' should be substitutable for 'expensive'.
> So we could do the following instead:
> 
> for (Student student : students) {
>      // Instrumented code
>      expensive.recordSomething();
>      // Original code
>      max = Math.max(max, student.age);
> }
> 
> More generally, a compiler could record the first lookup of a ThreadLocal
> in a scope and substitute any following lookup with the first read (until
> the next write).
> 
> I'm pretty sure this would be immensely useful for my current use case
> (which instruments methods to count invocations), but perhaps it is also a
> useful optimization in a more general sense? Examples that come to mind are
> enterprise apps where transaction and security contexts are passed around
> using ThreadLocals.
> 
> Has this type of optimization been discussed before? Is it even possible to
> implement, or did I miss some dragons hiding in the details? What would the
> estimated work for an implementation look like? Are we looking at
> bachelor's thesis? Master's thesis? PhD?
> 
> Would love to hear some thoughts on this idea.
> 
> Cheers,
> Eirik.
> 

From naoto at openjdk.java.net  Fri Mar  5 17:56:15 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 5 Mar 2021 17:56:15 GMT
Subject: RFR: 8263091: Remove CharacterData.isOtherUppercase/-Lowercase
In-Reply-To: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
References: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
Message-ID: <4BKu3uO5Oz4Lni3HAa3fbG4bv3hUKFjlAiLWQpNyskE=.a6fb7a27-629b-4b95-a972-a5e02f0653f9@github.com>

On Fri, 5 Mar 2021 14:24:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch removes the CharacterData.isOtherUppercase and isOtherLowercase methods. It also exploits the fact that isOtherUppercase is always false for all codepoints in the CharacterDataLatin1 range for a small speed-up.
> 
> I have no means to test if this is correct on PPC, which has intrinsics for isLowerCase/isUpperCase, but unless I'm reading the code wrong the intrinsic for isLowerCase on PPC already appears to effectively do the fused logic of isLowerCase(ch) || isOtherLowerCase(ch) since it handles the two values where isLowerCase and isOtherLowercase disagrees (0xaa, 0xba), which means this change should make the intrinsic and the java code be in better agreement.

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2846

From redestad at openjdk.java.net  Fri Mar  5 18:53:29 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 5 Mar 2021 18:53:29 GMT
Subject: RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
Message-ID: <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>

> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Fix omitted synchronized

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2845/files
  - new: https://git.openjdk.java.net/jdk/pull/2845/files/5d2f0da4..4980d2d6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2845&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2845&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2845

From redestad at openjdk.java.net  Fri Mar  5 18:53:30 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 5 Mar 2021 18:53:30 GMT
Subject: RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <PGnyOMqtHpgWAEG1JAKP5oX6T1JHG9ZEvBLJxRnXfvQ=.9c69f8b3-646b-4941-b344-f5d8e5b85219@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <PGnyOMqtHpgWAEG1JAKP5oX6T1JHG9ZEvBLJxRnXfvQ=.9c69f8b3-646b-4941-b344-f5d8e5b85219@github.com>
Message-ID: <HIB_uHhARw6PDJSkKL2po_YJGQKdaiDQnscfAilzDD8=.cbb9fd34-9673-439e-9da0-4cd96a4ca1c4@github.com>

On Fri, 5 Mar 2021 17:29:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix omitted synchronized
>
> src/java.base/share/classes/java/util/Locale.java line 959:
> 
>> 957:     }
>> 958: 
>> 959:     private static Locale getDisplayLocale() {
> 
> Should this be `synchronized`?

Good catch! Fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/2845

From naoto at openjdk.java.net  Fri Mar  5 19:01:09 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 5 Mar 2021 19:01:09 GMT
Subject: RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
Message-ID: <OAVGSb-KP7_gipVmNjpy-BxoTN_RRMe1hHid_-RMfL4=.5b6291d9-15f0-47b7-9d87-835273253152@github.com>

On Fri, 5 Mar 2021 18:53:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix omitted synchronized

Looks good.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2845

From eirbjo at gmail.com  Fri Mar  5 19:13:44 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 5 Mar 2021 20:13:44 +0100
Subject: ThreadLocal lookup elimination
In-Reply-To: <316f7179-6003-7db9-e934-918615691618@oracle.com>
References: <CA+pBWhsRSPhfV9MT_iz8Gddzz0jxU+f0U2sajvd5XNXum1kq0g@mail.gmail.com>
 <316f7179-6003-7db9-e934-918615691618@oracle.com>
Message-ID: <CA+pBWhsftyEZaidkhQpq5fN5QmZETwDidAvksSeP2z2paCSKeg@mail.gmail.com>

On Fri, Mar 5, 2021 at 6:41 PM Vladimir Kozlov <vladimir.kozlov at oracle.com>
wrote:

Vladimir,

Thanks a lot for taking time to consider this! Some comments inline:


> Currently it is "impossible" for JIT compiler to reliably know that value
> stored by set() in hash map is the same as
> read by get().
>

My layman (perhaps naive?) thinking was that a JIT could cheat and infer
this by definition. Since a ThreadLocal holds memory that is by definition
local to the executing thread, a JIT should have exclusive access to the
content of the ThreadLocal. Any back-to-back set/get (or get/get) should
therefore yield the same value (because no other thread can update the
contents of the ThreadLocal).

However, the JMM doesn't seem to mention ThreadLocals explicitly, so
perhaps a JIT would need to look at the implementation.. As a programmer I
would certainly be somewhat surprised if a ThreadLocal get yielded another
value than my immediately preceding set, or if my two consecutive gets
would yield different values.

What kind of access patterns could you see breaking this assumption?
Reflective access into Thread.threadLocals internals by clever frameworks,
similar to how final fields aren't really final?


> Also because of ThreadLocal accessors's complex code, some calls may not
> be inlined and JIT does not know what side
> effect they may have - it assumes that they can modify a value.
>

Not sure I'm following completely. Your concern is that the added "bulk" of
ThreadLocal.get could prevent inlining? But wouldn't this suggested
optimization simply replace the get with a local variable access, thus
removing the bulk. Or isn't this the order inlining happens in?

Thanks,
Eirik.

From github.com+194713+candrews at openjdk.java.net  Fri Mar  5 19:45:06 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Fri, 5 Mar 2021 19:45:06 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v4]
In-Reply-To: <t3fUW2NfjjSjvTrQotLdG23BiQhQDNepd0M9LwEfM7c=.b53c2963-0978-4bc3-9346-93215a93ee19@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <M_HI6rHAd36Rsy0ZS_ya3iFig0vZcyO_s9aK11a2j48=.7513689b-a106-4238-8b6a-f6d0de2109e5@github.com>
 <iKdskMjHNKUrtpQW8tVlLXeasNBbE54041OYUPpTahA=.6bbe649a-25d6-4a79-af08-5a237ffcdfc8@github.com>
 <t3fUW2NfjjSjvTrQotLdG23BiQhQDNepd0M9LwEfM7c=.b53c2963-0978-4bc3-9346-93215a93ee19@github.com>
Message-ID: <8KjQ40zxriZxNc0q9n28gL_kgtlhy1Jm6xH6FhFG7Pw=.edf26450-4f5b-4aad-82f0-1da8b2af4a8b@github.com>

On Thu, 4 Mar 2021 21:10:56 GMT, Craig Andrews <github.com+194713+candrews at openjdk.org> wrote:

>> Hi, Craig
>> The commented-out lines should be removed from the change.
>> 
>> As Alan said, a regression test will be needed.  At minimum, it should test a method that returns a URL, as well as a method that returns an Enumeration<URL> (which can also lead to an IAE, as I noted in the bug report).
>> 
>> Also, though the compatibility risk is low, it would be good to include a CSR for this change to long-standing behavior.
>
>>The commented-out lines should be removed from the change.
> 
> Done! ?? 
> 
>> As Alan said, a regression test will be needed. At minimum, it should test a method that returns a URL, as well as a method that returns an Enumeration (which can also lead to an IAE, as I noted in the bug report).
> 
> I've added a test.
> 
>> Also, the copyright year should be updated: 2019 -> 2021
> 
> Done! ?? 
> 
>> @bchristi-git has indicated that a [compatibility and specification](https://wiki.openjdk.java.net/display/csr/Main) (CSR) request is needed for this pull request.
>> @candrews please create a CSR request and add link to it in [JDK-8262277](https://bugs.openjdk.java.net/browse/JDK-8262277). This pull request cannot be integrated until the CSR request is approved.
> 
> I'm trying to figure out how to create a CSR and I'm not having much luck. According to the [CSR FAQs](https://wiki.openjdk.java.net/display/csr/CSR+FAQs):
>> Q: How do I create a CSR ?
> A: Do not directly create a CSR from the Create Menu. JIRA will let you do this right up until the moment you try to save it and find your typing was in vain.
> Instead you should go to the target bug, select "More", and from the drop down menu select "Create CSR". This is required to properly associate the CSR with the main bug, just as is done for backports.
> 
> However, I don't have an account on https://bugs.openjdk.java.net so I can't do as instructed.
> 
> How do I create the CSR?

# Summary
Modify implementation of `java.net.URLClassLoader` such that `findResource` and `java.net.URLClassLoader.html#findResources` do no longer throw undocumented `IllegalArgumentException`.

# Problem
The javadocs for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String)) and [`java.net.URLClassLoader.html#findResources`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResources(java.lang.String)) do not indicate that an `IllegalArgumentException` can be thrown. The implementation does throw such exceptions under specific conditions which, due to being undocumented, is unexpected behavior. The unexpected exception can cause incorrect behavior, particularly on Windows systems due to the Windows file system path format increasingly the likelihood of causing the unexpected exception. [An example of such a problem was discovered in Spring Framework necessitating a workaround.](https://github.com/spring-projects/spring-framework/pull/26574).

# Solution
Modify the implementation of `java.net.URLClassLoader` to not throw `IllegalArgumentException` when finding resources.

# Compatibility Risk
Low

# Compatibility Risk Description
It is possible that some code is catching the undocumented `IllegalArgumentException` and treating it in a specific way.

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From vladimir.kozlov at oracle.com  Fri Mar  5 19:50:14 2021
From: vladimir.kozlov at oracle.com (Vladimir Kozlov)
Date: Fri, 5 Mar 2021 11:50:14 -0800
Subject: [External] : Re: ThreadLocal lookup elimination
In-Reply-To: <CA+pBWhsftyEZaidkhQpq5fN5QmZETwDidAvksSeP2z2paCSKeg@mail.gmail.com>
References: <CA+pBWhsRSPhfV9MT_iz8Gddzz0jxU+f0U2sajvd5XNXum1kq0g@mail.gmail.com>
 <316f7179-6003-7db9-e934-918615691618@oracle.com>
 <CA+pBWhsftyEZaidkhQpq5fN5QmZETwDidAvksSeP2z2paCSKeg@mail.gmail.com>
Message-ID: <b384e8be-2e6c-ad6a-6556-ef6348e3449e@oracle.com>

Eirik

See my answers bellow.

But before that. Alan Bateman said to me that Loom project has much simpler implementation to what you want.
Thread local scopedCache which is Object[] array referenced from current thread:

https://github.com/openjdk/loom/blob/fibers/src/java.base/share/classes/java/lang/Thread.java#L310
https://github.com/openjdk/loom/blob/fibers/src/hotspot/share/prims/jvm.cpp#L3130

It will be much easy to optimize.

On 3/5/21 11:13 AM, Eirik Bj?rsn?s wrote:
> On Fri, Mar 5, 2021 at 6:41 PM Vladimir Kozlov <vladimir.kozlov at oracle.com <mailto:vladimir.kozlov at oracle.com>> wrote:
> 
> Vladimir,
> 
> Thanks a lot for taking time to consider this! Some comments inline:
> 
>     Currently it is "impossible" for JIT compiler to reliably know that value stored by set() in hash map is the same as
>     read by get().
> 
> 
> My layman (perhaps naive?) thinking was that a JIT could cheat and infer this by definition. Since a ThreadLocal holds 
> memory that is by definition local to the executing thread, a JIT should have exclusive access to the content of the 
> ThreadLocal. Any back-to-back set/get (or get/get) should therefore yield the same value (because no other thread can 
> update the contents of the ThreadLocal).
> 
> However, the JMM doesn't seem?to mention ThreadLocals explicitly, so perhaps a JIT would need to look at the 
> implementation.. As a programmer I would certainly be somewhat surprised if a ThreadLocal get yielded another value than 
> my immediately preceding set, or if my two consecutive gets would yield different values.
> 
> What kind of access patterns could you see breaking this assumption? Reflective access into Thread.threadLocals 
> internals by clever frameworks, similar to how final fields aren't really final?

Can't do that. JIT have to update underlying hash table to correctly execute application.

> 
>     Also because of ThreadLocal accessors's complex code, some calls may not be inlined and JIT does not know what side
>     effect they may have - it assumes that they can modify a value.
> 
> 
> Not sure I'm?following completely. Your?concern is that the added "bulk" of ThreadLocal.get could prevent inlining? But 
> wouldn't this suggested optimization simply replace the get with a local variable access, thus removing the bulk. Or 
> isn't this the order inlining happens in?

Note, currently JIT does not treat ThreadLocal as something special. It will inline set() and get() as normal methods.
It will try to inline all hot methods which are called. For example, ThreadLocalMap::getEntry()
https://github.com/openjdk/jdk/blob/e1cad97049642ab201d53ff608937f7e7ef3ff3e/src/java.base/share/classes/java/lang/ThreadLocal.java#L433

It has 2 paths: miss and not miss. Depending on profile of execution getEntryAfterMiss() method may not be called or 
called very little. It is considered cold call site - JIT will not inline it and it does not know what it will do with 
hash table and values in it.

Regards,
Vladimir

> 
> Thanks,
> Eirik.

From eirbjo at gmail.com  Fri Mar  5 20:25:05 2021
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 5 Mar 2021 21:25:05 +0100
Subject: [External] : Re: ThreadLocal lookup elimination
In-Reply-To: <b384e8be-2e6c-ad6a-6556-ef6348e3449e@oracle.com>
References: <CA+pBWhsRSPhfV9MT_iz8Gddzz0jxU+f0U2sajvd5XNXum1kq0g@mail.gmail.com>
 <316f7179-6003-7db9-e934-918615691618@oracle.com>
 <CA+pBWhsftyEZaidkhQpq5fN5QmZETwDidAvksSeP2z2paCSKeg@mail.gmail.com>
 <b384e8be-2e6c-ad6a-6556-ef6348e3449e@oracle.com>
Message-ID: <CA+pBWhu1CN2u4_mK61jbqBAKJLkAZxkDb-_VpKJ54ue8O+yBmg@mail.gmail.com>

>
> But before that. Alan Bateman said to me that Loom project has much
> simpler implementation to what you want.
>

Ahh! Another good reason why I'm seriously considering just going to the
beach and returning once Loom is shipped! :-)

Can't do that. JIT have to update underlying hash table to correctly
> execute application.
>

I don't think I suggested altering the write path, only the reads would be
optimized away. My understanding is those won't update the hash table or
have other side effects.

Cheers,
Eirik.

From iris at openjdk.java.net  Fri Mar  5 20:42:05 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 5 Mar 2021 20:42:05 GMT
Subject: RFR: 8263091: Remove CharacterData.isOtherUppercase/-Lowercase
In-Reply-To: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
References: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
Message-ID: <gzdn0qEUwApKItpsxkj13U5zOxkYQwtywZockqrATFE=.ed478c2f-27ae-4352-be50-ff6322213251@github.com>

On Fri, 5 Mar 2021 14:24:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch removes the CharacterData.isOtherUppercase and isOtherLowercase methods. It also exploits the fact that isOtherUppercase is always false for all codepoints in the CharacterDataLatin1 range for a small speed-up.
> 
> I have no means to test if this is correct on PPC, which has intrinsics for isLowerCase/isUpperCase, but unless I'm reading the code wrong the intrinsic for isLowerCase on PPC already appears to effectively do the fused logic of isLowerCase(ch) || isOtherLowerCase(ch) since it handles the two values where isLowerCase and isOtherLowercase disagrees (0xaa, 0xba), which means this change should make the intrinsic and the java code be in better agreement.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2846

From bchristi at openjdk.java.net  Fri Mar  5 23:39:07 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 5 Mar 2021 23:39:07 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v4]
In-Reply-To: <hNKo6pHM9KObvLVnSeUfvmWCnsu8Ep2NGOtd6BxcFsA=.e8f771e9-0ba5-433b-8bf4-29da54b2df93@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <hNKo6pHM9KObvLVnSeUfvmWCnsu8Ep2NGOtd6BxcFsA=.e8f771e9-0ba5-433b-8bf4-29da54b2df93@github.com>
Message-ID: <TQu51YyK6-DEARRhF8uDryoMl6VxSNnhJE-NHoYqCyg=.df15f8c9-6511-4217-bd65-d70566991d1b@github.com>

On Fri, 5 Mar 2021 16:02:49 GMT, Craig Andrews <github.com+194713+candrews at openjdk.org> wrote:

>> `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.
>> 
>> According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.
>> 
>> Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>>> Returns:
>>>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.
>> 
>> And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>>> Returns:
>>>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.
>> 
>> Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.
>> 
>> Here's a stack trace:
>> java.lang.IllegalArgumentException: name
>>         at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>>         at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>>         at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
>> 
>> Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>>         URL findResource(final String name, boolean check) {
>>             URL url;
>>             try {
>>                 url = new URL(base, ParseUtil.encodePath(name, false));
>>             } catch (MalformedURLException e) {
>>                 throw new IllegalArgumentException("name");
>>             }
>> 
>> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
>> 
>> A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>>         URL findResource(final String name, boolean check) {
>>             URL url;
>>             try {
>>                 url = new URL(base, ParseUtil.encodePath(name, false));
>>             } catch (MalformedURLException e) {
>>                 throw new IllegalArgumentException("name");
>>             }
>> 
>> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
>
> Craig Andrews has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException

Changes requested by bchristi (Reviewer).

test/jdk/java/net/URLClassLoader/FindResourceDoesNotThrowException.java line 27:

> 25:  * @test
> 26:  * @bug 8262277
> 27:  * @summary Test to see if URLClassLoader.getResource and URLClassLoader.getResources

The summary mentions the get* methods, but the test calls the find* methods.  I think it would be good to test all four methods (getResource, getResources, findResource, findResources), and update the summary e.g. "Test if URLClassLoader throws IllegalArgumentException when getting or finding resources."

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From github.com+194713+candrews at openjdk.java.net  Sat Mar  6 01:35:28 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Sat, 6 Mar 2021 01:35:28 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v5]
In-Reply-To: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
Message-ID: <EhUg_gwzyqIZ3IAPbWqm_s1yOyIW_I9oK_B1yKnqmm8=.a5cf7361-85d2-4656-9f70-6bcd06030bf3@github.com>

> `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.
> 
> According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.
> 
> Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>> Returns:
>>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.
> 
> And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>> Returns:
>>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.
> 
> Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.
> 
> Here's a stack trace:
> java.lang.IllegalArgumentException: name
>         at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>         at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>         at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
> 
> Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>         URL findResource(final String name, boolean check) {
>             URL url;
>             try {
>                 url = new URL(base, ParseUtil.encodePath(name, false));
>             } catch (MalformedURLException e) {
>                 throw new IllegalArgumentException("name");
>             }
> 
> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
> 
> A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>         URL findResource(final String name, boolean check) {
>             URL url;
>             try {
>                 url = new URL(base, ParseUtil.encodePath(name, false));
>             } catch (MalformedURLException e) {
>                 throw new IllegalArgumentException("name");
>             }
> 
> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.

Craig Andrews has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2662/files
  - new: https://git.openjdk.java.net/jdk/pull/2662/files/79869e78..944956c9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2662&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2662&range=03-04

  Stats: 9 lines in 1 file changed: 3 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2662.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2662/head:pull/2662

PR: https://git.openjdk.java.net/jdk/pull/2662

From github.com+194713+candrews at openjdk.java.net  Sat Mar  6 01:35:29 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Sat, 6 Mar 2021 01:35:29 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v4]
In-Reply-To: <TQu51YyK6-DEARRhF8uDryoMl6VxSNnhJE-NHoYqCyg=.df15f8c9-6511-4217-bd65-d70566991d1b@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <hNKo6pHM9KObvLVnSeUfvmWCnsu8Ep2NGOtd6BxcFsA=.e8f771e9-0ba5-433b-8bf4-29da54b2df93@github.com>
 <TQu51YyK6-DEARRhF8uDryoMl6VxSNnhJE-NHoYqCyg=.df15f8c9-6511-4217-bd65-d70566991d1b@github.com>
Message-ID: <2b45HskRcwBNp-f-gf6n8FcGqE3QZdc3GXp_Tpc4Mk8=.f2f6d563-4daa-4f72-b1db-4087efbfdcb2@github.com>

On Fri, 5 Mar 2021 23:35:46 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Craig Andrews has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException
>
> test/jdk/java/net/URLClassLoader/FindResourceDoesNotThrowException.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8262277
>> 27:  * @summary Test to see if URLClassLoader.getResource and URLClassLoader.getResources
> 
> The summary mentions the get* methods, but the test calls the find* methods.  I think it would be good to test all four methods (getResource, getResources, findResource, findResources), and update the summary e.g. "Test if URLClassLoader throws IllegalArgumentException when getting or finding resources."

Good point - thank you.

I've made the change and updated this PR accordingly.

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From serb at openjdk.java.net  Sat Mar  6 05:54:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 6 Mar 2021 05:54:07 GMT
Subject: RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
Message-ID: <lv7-qQPOMgVw5ccHrWV8Om_ZXZ-q6we-MJBSFRgZawo=.5099726c-0279-4a48-8fd4-b8dbfe2deb17@github.com>

On Fri, 5 Mar 2021 18:53:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix omitted synchronized

src/java.base/share/classes/java/util/Locale.java line 946:

> 944:             Locale loc = defaultDisplayLocale; // volatile read
> 945:             if (loc == null) {
> 946:                 loc = getDisplayLocale();

Just interesting how did you check that the performance difference is because of volatile read, and not because of replacing of the switch by the "if"?

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

PR: https://git.openjdk.java.net/jdk/pull/2845

From alanb at openjdk.java.net  Sat Mar  6 07:36:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 6 Mar 2021 07:36:06 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v5]
In-Reply-To: <EhUg_gwzyqIZ3IAPbWqm_s1yOyIW_I9oK_B1yKnqmm8=.a5cf7361-85d2-4656-9f70-6bcd06030bf3@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <EhUg_gwzyqIZ3IAPbWqm_s1yOyIW_I9oK_B1yKnqmm8=.a5cf7361-85d2-4656-9f70-6bcd06030bf3@github.com>
Message-ID: <QA-FoJ4mGRXfEkN_oMdixEOT_mHwAqF0PyhnEesy_NQ=.d3dc816f-cdcc-43e2-ba89-48f354293d84@github.com>

On Sat, 6 Mar 2021 01:35:28 GMT, Craig Andrews <github.com+194713+candrews at openjdk.org> wrote:

>> `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.
>> 
>> According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.
>> 
>> Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>>> Returns:
>>>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.
>> 
>> And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>>> Returns:
>>>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.
>> 
>> Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.
>> 
>> Here's a stack trace:
>> java.lang.IllegalArgumentException: name
>>         at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>>         at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>>         at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
>> 
>> Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>>         URL findResource(final String name, boolean check) {
>>             URL url;
>>             try {
>>                 url = new URL(base, ParseUtil.encodePath(name, false));
>>             } catch (MalformedURLException e) {
>>                 throw new IllegalArgumentException("name");
>>             }
>> 
>> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
>> 
>> A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>>         URL findResource(final String name, boolean check) {
>>             URL url;
>>             try {
>>                 url = new URL(base, ParseUtil.encodePath(name, false));
>>             } catch (MalformedURLException e) {
>>                 throw new IllegalArgumentException("name");
>>             }
>> 
>> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
>
> Craig Andrews has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

The fix looks good. Brent has created a CSR. It seems unlikely that anyone is depending the long standing/broken behavior but it seems release note worthy.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2662

From almatvee at openjdk.java.net  Sat Mar  6 08:57:09 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Sat, 6 Mar 2021 08:57:09 GMT
Subject: Integrated: 8261845: File permissions of packages built by jpackage
In-Reply-To: <oYWJ9E6hHLr-UGQNMIldrIqTBywjs4tKsFRZcdgATV4=.2300228a-be05-437d-9842-6c5cb13f9ca2@github.com>
References: <oYWJ9E6hHLr-UGQNMIldrIqTBywjs4tKsFRZcdgATV4=.2300228a-be05-437d-9842-6c5cb13f9ca2@github.com>
Message-ID: <MsBykNasrnIU56wy4_9sUxG3TfgSyyq91f07KLfahsE=.a9bdcf7d-9374-4780-8f16-e358efeb982d@github.com>

On Thu, 4 Mar 2021 03:59:27 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> - Fixed by adding write permissions to .exe package.

This pull request has now been integrated.

Changeset: fa43f926
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fa43f926
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8261845: File permissions of packages built by jpackage

Reviewed-by: asemenyuk, herrick

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

PR: https://git.openjdk.java.net/jdk/pull/2822

From jjg at openjdk.java.net  Sat Mar  6 09:15:16 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Sat, 6 Mar 2021 09:15:16 GMT
Subject: RFR: JDK-8263104: fix warnings for empty paragraphs
Message-ID: <pOVO9eKG44kNe-9b2khf_RCzjzu5mD0H2AeTM7thjog=.fecf709c-28c4-4321-9161-dc3c7892defa@github.com>

Please review some simple cleanup for empty `<p>` tags.

Two of the tags are completely redundant, and simply deleted.

The other three, in _package.html_ files are generally undesirable. Although the presumed intent of the `id` declaration is to label the `@see` info, proximity in the source code does not ensure proximity in the generated code. The actual result is an empty paragraph at the end of the enclosing generated `<div>`, and before the generated output for the `@since` tag.

The better solution is to move the `id` declaration into the `@see <a href...` and then delete the empty `<p>`.

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

Commit messages:
 - JDK-8263104: fix warnings for empty paragraphs

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

PR: https://git.openjdk.java.net/jdk/pull/2850

From dholmes at openjdk.java.net  Sat Mar  6 12:39:07 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 6 Mar 2021 12:39:07 GMT
Subject: RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <OAVGSb-KP7_gipVmNjpy-BxoTN_RRMe1hHid_-RMfL4=.5b6291d9-15f0-47b7-9d87-835273253152@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
 <OAVGSb-KP7_gipVmNjpy-BxoTN_RRMe1hHid_-RMfL4=.5b6291d9-15f0-47b7-9d87-835273253152@github.com>
Message-ID: <tslEliQLDG0knvBY5lnxXvza_L3qB2iup52LWwtsRII=.b7c89fc3-7a55-4608-a6a7-ccaaced16dff@github.com>

On Fri, 5 Mar 2021 18:58:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix omitted synchronized
>
> Looks good.

If I read the order right your benchmark findings were done before you added the missing synchronized - correct?

AFAICS the only unnecessary volatile read is on the return statement and you could fix that without doing the other refactoring. I don't see how introducing an extra method call can aid performance.

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

PR: https://git.openjdk.java.net/jdk/pull/2845

From redestad at openjdk.java.net  Sat Mar  6 13:13:04 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sat, 6 Mar 2021 13:13:04 GMT
Subject: RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <tslEliQLDG0knvBY5lnxXvza_L3qB2iup52LWwtsRII=.b7c89fc3-7a55-4608-a6a7-ccaaced16dff@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
 <OAVGSb-KP7_gipVmNjpy-BxoTN_RRMe1hHid_-RMfL4=.5b6291d9-15f0-47b7-9d87-835273253152@github.com>
 <tslEliQLDG0knvBY5lnxXvza_L3qB2iup52LWwtsRII=.b7c89fc3-7a55-4608-a6a7-ccaaced16dff@github.com>
Message-ID: <5Xsg7B24UVoI3bT0DNrA1G2yQINRO4i_6sgtIoxMU3k=.50404e21-bb47-45f9-a9eb-0d3a447b6a74@github.com>

On Sat, 6 Mar 2021 12:36:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

> If I read the order right your benchmark findings were done before you added the missing synchronized - correct?
> 
> AFAICS the only unnecessary volatile read is on the return statement and you could fix that without doing the other refactoring. I don't see how introducing an extra method call can aid performance.

Note that the score for the Display and the Format case were identical, even though one was missing synchronized. I've re-run the benchmarks after the fix and the same applies.

The methods will only ever be called during initialization, usually only once. Extracting them to separate methods helps outline initialization code from the hot path. Such outlining is a standard technique to help the JITs do the right thing, for example by ensuring you don't stumble on things like inlining thresholds.

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

PR: https://git.openjdk.java.net/jdk/pull/2845

From aph at redhat.com  Sat Mar  6 13:24:00 2021
From: aph at redhat.com (Andrew Haley)
Date: Sat, 6 Mar 2021 13:24:00 +0000
Subject: ThreadLocal lookup elimination
In-Reply-To: <CA+pBWhsftyEZaidkhQpq5fN5QmZETwDidAvksSeP2z2paCSKeg@mail.gmail.com>
References: <CA+pBWhsRSPhfV9MT_iz8Gddzz0jxU+f0U2sajvd5XNXum1kq0g@mail.gmail.com>
 <316f7179-6003-7db9-e934-918615691618@oracle.com>
 <CA+pBWhsftyEZaidkhQpq5fN5QmZETwDidAvksSeP2z2paCSKeg@mail.gmail.com>
Message-ID: <07abf37f-babf-f557-077d-b570f6142928@redhat.com>

On 3/5/21 7:13 PM, Eirik Bj?rsn?s wrote:
> My layman (perhaps naive?) thinking was that a JIT could cheat and infer
> this by definition. Since a ThreadLocal holds memory that is by definition
> local to the executing thread, a JIT should have exclusive access to the
> content of the ThreadLocal. Any back-to-back set/get (or get/get) should
> therefore yield the same value (because no other thread can update the
> contents of the ThreadLocal).

Mostly, but I think that ThreadLocal.createInheritedMap is called
from the Thread constructor.

> However, the JMM doesn't seem to mention ThreadLocals explicitly, so
> perhaps a JIT would need to look at the implementation.. As a programmer I
> would certainly be somewhat surprised if a ThreadLocal get yielded another
> value than my immediately preceding set, or if my two consecutive gets
> would yield different values.
> 
> What kind of access patterns could you see breaking this assumption?
> Reflective access into Thread.threadLocals internals by clever frameworks,
> similar to how final fields aren't really final?

There's that, but there's also the issue that ThreadLocalMap entries
are WeakReferences. We don't want to keep a ThreadLocal alive
beyond the lifetime of its key, and this considerably complicates
optimizing ThreadLocals.

The cache (in Loom) Vladimir pointed you to is part of my design
for scope locals, and it can be (and currently is) optimized in
the way you want.

-- 
Andrew Haley  (he/him)
Java Platform Lead Engineer
Red Hat UK Ltd. <https://www.redhat.com>
https://keybase.io/andrewhaley
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671


From redestad at openjdk.java.net  Sat Mar  6 13:37:07 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sat, 6 Mar 2021 13:37:07 GMT
Subject: RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <lv7-qQPOMgVw5ccHrWV8Om_ZXZ-q6we-MJBSFRgZawo=.5099726c-0279-4a48-8fd4-b8dbfe2deb17@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
 <lv7-qQPOMgVw5ccHrWV8Om_ZXZ-q6we-MJBSFRgZawo=.5099726c-0279-4a48-8fd4-b8dbfe2deb17@github.com>
Message-ID: <Ks16r3TISrfvlzTxW1KfHtfZKIwUa2cc-PbIcO227Dk=.3626629f-276d-4449-b60c-5c2c57e09f89@github.com>

On Sat, 6 Mar 2021 05:51:17 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix omitted synchronized
>
> src/java.base/share/classes/java/util/Locale.java line 946:
> 
>> 944:             Locale loc = defaultDisplayLocale; // volatile read
>> 945:             if (loc == null) {
>> 946:                 loc = getDisplayLocale();
> 
> Just interesting how did you check that the performance difference is because of volatile read, and not because of replacing of the switch by the "if"?

I started out with this variant, only removing the double volatile reads:

    public static Locale getDefault(Locale.Category category) {
        // do not synchronize this method - see 4071298
        Locale loc;
        switch (category) {
        case DISPLAY:
            loc = defaultDisplayLocale;
            if (loc == null) {
                synchronized(Locale.class) {
                    loc = defaultDisplayLocale;
                    if (loc == null) {
                        loc = defaultDisplayLocale = initDefault(category);
                    }
                }
            }
            return loc;
        case FORMAT:
            loc = defaultFormatLocale;
            if (loc == null) {
                synchronized(Locale.class) {
                    loc = defaultFormatLocale;
                    if (loc == null) {
                        loc = defaultFormatLocale = initDefault(category);
                    }
                }
            }
            return loc;
        default:
            assert false: "Unknown Category";
        }
        return getDefault();
    }

Scores were the same:
Benchmark                         Mode  Cnt   Score   Error  Units
LocaleDefaults.getDefault         avgt    5  10.045 ? 0.032  ns/op
LocaleDefaults.getDefaultDisplay  avgt    5  11.301 ? 0.053  ns/op
LocaleDefaults.getDefaultFormat   avgt    5  11.303 ? 0.054  ns/op

I then refactored and checked that the refactorings were performance neutral.

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

PR: https://git.openjdk.java.net/jdk/pull/2845

From darcy at openjdk.java.net  Sat Mar  6 16:19:15 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 6 Mar 2021 16:19:15 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge
Message-ID: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>

The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.

Once the text is agreed to; I'll update the copyright year as well.

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

Commit messages:
 - Fix trailing white space.
 - Rewording.
 - Update wording.
 - 8263102: Expand documention of Method.isBridg

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

PR: https://git.openjdk.java.net/jdk/pull/2852

From darcy at openjdk.java.net  Sat Mar  6 17:44:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Sat, 6 Mar 2021 17:44:18 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v2]
In-Reply-To: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
Message-ID: <DJdCpcG1ZMm84SIU1_CEIC5WYJDLz3RYSG4Ltb_TyXw=.3ef63e5c-fe0a-49f4-993d-75f7c08fb242@github.com>

> The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
> 
> Once the text is agreed to; I'll update the copyright year as well.

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

  Improve linkage for isSynethetic.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2852/files
  - new: https://git.openjdk.java.net/jdk/pull/2852/files/35fd6b06..d3b7a3c3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=00-01

  Stats: 4 lines in 3 files changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2852.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2852/head:pull/2852

PR: https://git.openjdk.java.net/jdk/pull/2852

From serb at openjdk.java.net  Sat Mar  6 20:39:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 6 Mar 2021 20:39:07 GMT
Subject: RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <Ks16r3TISrfvlzTxW1KfHtfZKIwUa2cc-PbIcO227Dk=.3626629f-276d-4449-b60c-5c2c57e09f89@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
 <lv7-qQPOMgVw5ccHrWV8Om_ZXZ-q6we-MJBSFRgZawo=.5099726c-0279-4a48-8fd4-b8dbfe2deb17@github.com>
 <Ks16r3TISrfvlzTxW1KfHtfZKIwUa2cc-PbIcO227Dk=.3626629f-276d-4449-b60c-5c2c57e09f89@github.com>
Message-ID: <QL50utyyHhNAF7KVp_h4rVjN1yHAKw6f6gA_AnbJA5k=.622fe80e-4e38-4974-b4cf-53cfac14016d@github.com>

On Sat, 6 Mar 2021 13:34:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Locale.java line 946:
>> 
>>> 944:             Locale loc = defaultDisplayLocale; // volatile read
>>> 945:             if (loc == null) {
>>> 946:                 loc = getDisplayLocale();
>> 
>> Just interesting how did you check that the performance difference is because of volatile read, and not because of replacing of the switch by the "if"?
>
> I started out with this variant, only removing the double volatile reads:
> 
>     public static Locale getDefault(Locale.Category category) {
>         // do not synchronize this method - see 4071298
>         Locale loc;
>         switch (category) {
>         case DISPLAY:
>             loc = defaultDisplayLocale;
>             if (loc == null) {
>                 synchronized(Locale.class) {
>                     loc = defaultDisplayLocale;
>                     if (loc == null) {
>                         loc = defaultDisplayLocale = initDefault(category);
>                     }
>                 }
>             }
>             return loc;
>         case FORMAT:
>             loc = defaultFormatLocale;
>             if (loc == null) {
>                 synchronized(Locale.class) {
>                     loc = defaultFormatLocale;
>                     if (loc == null) {
>                         loc = defaultFormatLocale = initDefault(category);
>                     }
>                 }
>             }
>             return loc;
>         default:
>             assert false: "Unknown Category";
>         }
>         return getDefault();
>     }
> 
> Scores were the same:
> Benchmark                         Mode  Cnt   Score   Error  Units
> LocaleDefaults.getDefault         avgt    5  10.045 ? 0.032  ns/op
> LocaleDefaults.getDefaultDisplay  avgt    5  11.301 ? 0.053  ns/op
> LocaleDefaults.getDefaultFormat   avgt    5  11.303 ? 0.054  ns/op
> 
> I then refactored and checked that the refactorings were performance neutral.

And it is faster than the final version?

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

PR: https://git.openjdk.java.net/jdk/pull/2845

From claes.redestad at oracle.com  Sat Mar  6 21:28:33 2021
From: claes.redestad at oracle.com (Claes Redestad)
Date: Sat, 6 Mar 2021 21:28:33 +0000
Subject: RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <QL50utyyHhNAF7KVp_h4rVjN1yHAKw6f6gA_AnbJA5k=.622fe80e-4e38-4974-b4cf-53cfac14016d@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
 <lv7-qQPOMgVw5ccHrWV8Om_ZXZ-q6we-MJBSFRgZawo=.5099726c-0279-4a48-8fd4-b8dbfe2deb17@github.com>
 <Ks16r3TISrfvlzTxW1KfHtfZKIwUa2cc-PbIcO227Dk=.3626629f-276d-4449-b60c-5c2c57e09f89@github.com>,
 <QL50utyyHhNAF7KVp_h4rVjN1yHAKw6f6gA_AnbJA5k=.622fe80e-4e38-4974-b4cf-53cfac14016d@github.com>
Message-ID: <DM5PR10MB2012E175161C83B6ADD58E83E1959@DM5PR10MB2012.namprd10.prod.outlook.com>

No, I accidentally posted numbers for an apples to oranges comparison (-t 1 vs -t 4 on the same system). The final version does not differ in performance from this version when comparing like for like.

H?mta Outlook f?r Android<https://aka.ms/ghei36>

________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.java.net> on behalf of Sergey Bylokhov <serb at openjdk.java.net>
Sent: Saturday, March 6, 2021 9:39:07 PM
To: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; i18n-dev at openjdk.java.net <i18n-dev at openjdk.java.net>
Subject: Re: RFR: 8263090: Avoid reading volatile fields twice in Locale.getDefault(Category) [v2]

On Sat, 6 Mar 2021 13:34:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Locale.java line 946:
>>
>>> 944:             Locale loc = defaultDisplayLocale; // volatile read
>>> 945:             if (loc == null) {
>>> 946:                 loc = getDisplayLocale();
>>
>> Just interesting how did you check that the performance difference is because of volatile read, and not because of replacing of the switch by the "if"?
>
> I started out with this variant, only removing the double volatile reads:
>
>     public static Locale getDefault(Locale.Category category) {
>         // do not synchronize this method - see 4071298
>         Locale loc;
>         switch (category) {
>         case DISPLAY:
>             loc = defaultDisplayLocale;
>             if (loc == null) {
>                 synchronized(Locale.class) {
>                     loc = defaultDisplayLocale;
>                     if (loc == null) {
>                         loc = defaultDisplayLocale = initDefault(category);
>                     }
>                 }
>             }
>             return loc;
>         case FORMAT:
>             loc = defaultFormatLocale;
>             if (loc == null) {
>                 synchronized(Locale.class) {
>                     loc = defaultFormatLocale;
>                     if (loc == null) {
>                         loc = defaultFormatLocale = initDefault(category);
>                     }
>                 }
>             }
>             return loc;
>         default:
>             assert false: "Unknown Category";
>         }
>         return getDefault();
>     }
>
> Scores were the same:
> Benchmark                         Mode  Cnt   Score   Error  Units
> LocaleDefaults.getDefault         avgt    5  10.045 ? 0.032  ns/op
> LocaleDefaults.getDefaultDisplay  avgt    5  11.301 ? 0.053  ns/op
> LocaleDefaults.getDefaultFormat   avgt    5  11.303 ? 0.054  ns/op
>
> I then refactored and checked that the refactorings were performance neutral.

And it is faster than the final version?

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

PR: https://git.openjdk.java.net/jdk/pull/2845

From serb at openjdk.java.net  Sat Mar  6 21:41:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 6 Mar 2021 21:41:07 GMT
Subject: RFR: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category) [v2]
In-Reply-To: <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
 <8VL9C4MIBkGejWQTMBZHpqJzzgRd_wJ3q069O3IEsgk=.0f68ad33-4627-49d9-8ede-174cc6812d4e@github.com>
Message-ID: <uHfI25yXeG4NTArErT8v35jpIqVOQZW-aVq0xjKS374=.e27ff260-87d4-49cc-a441-3f68b6fbf602@github.com>

On Fri, 5 Mar 2021 18:53:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix omitted synchronized

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2845

From github.com+7806504+liach at openjdk.java.net  Sun Mar  7 01:17:05 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Sun, 7 Mar 2021 01:17:05 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge
In-Reply-To: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
Message-ID: <DMMH7I-tCax5QZ55ZL7NmQXsq4BBGgW6x34S_1AxNm4=.f29dede4-ff92-4f29-b0d6-70e768d95ce9@github.com>

On Fri, 5 Mar 2021 21:25:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
> 
> Once the text is agreed to; I'll update the copyright year as well.

I suggest briefly mentioning generic specialization as an example as well.

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

PR: https://git.openjdk.java.net/jdk/pull/2852

From ysuenaga at openjdk.java.net  Sun Mar  7 06:27:24 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Sun, 7 Mar 2021 06:27:24 GMT
Subject: RFR: 8263135: unique_ptr should not be used for types that are not
 pointers
Message-ID: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>

I saw error during jpackage compilation with VS 2019 (16.9.0) as following (on Japanese locale):

c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): error C2440: '=': '_Other' ?? '_Ty' ?????????
        with
        [
            _Other=nullptr
        ]
        and
        [
            _Ty=unsigned long
        ]
c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): note: ?????? nullptr ?????????????? reinterpret_cast ??????????????????????
c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3423): note: ?????????? ?????? ??????? '_Ty std::exchange<_Ty2,nullptr>(_Ty &,_Other &&) noexcept(false)' ????????????????
        with
        [
            _Ty=unsigned long,
            _Ty2=unsigned long,
            _Other=nullptr
        ]
c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3422): note: ??? ??? ??? ?????? 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' ???????
d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.cpp(237): note: ?????????? ?????? ??????? 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' ????????????????
d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.h(119): note: ???????? ?? ? ?????? ??????? 'std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>' ????????????????

`UniqueMSIHANDLE` is declared in MsiUtils.h as `unique_ptr` for `MSIHANDLE`. `MSIHANDLE` seems to be declared as synonym for `unsigned long`, not a pointer type.
I think `MSIHANDLE` does not need to handle as `unique_ptr` if it releases at d'tor of the class which holds it (`Database`, `DatabaseRecord`).

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

Commit messages:
 - 8263135: unique_ptr should not be used for types that are not pointers

Changes: https://git.openjdk.java.net/jdk/pull/2858/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2858&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263135
  Stats: 77 lines in 4 files changed: 14 ins; 36 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2858.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2858/head:pull/2858

PR: https://git.openjdk.java.net/jdk/pull/2858

From github.com+741251+turbanoff at openjdk.java.net  Sun Mar  7 20:31:08 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sun, 7 Mar 2021 20:31:08 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v11]
In-Reply-To: <fPIf2TG2r9A2gJKfY2q8ifG4fHP7Ed1lHJ1KyExwI-U=.59c5f061-4e65-4db1-8a86-64a97a323b24@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <djPl7TL8j0qwyuLjwnZI96g7UPmw3XamdbVltf8fbos=.36a5bbe7-1fd0-496b-999f-7c49d06fc0a8@github.com>
 <6zhT8ySP8rFE4wV5vva0oKRDSxDnSYYZ-sXAQJ6F_DM=.b83a0f88-7231-4796-a0b5-d51b5950d316@github.com>
 <KKuuOtcyAwZLESU78ZnNaF5LmeoQeWzxj-yO-xCj5ZM=.ea9ff05f-ffea-477f-b7eb-b94df1f186f3@github.com>
 <fPIf2TG2r9A2gJKfY2q8ifG4fHP7Ed1lHJ1KyExwI-U=.59c5f061-4e65-4db1-8a86-64a97a323b24@github.com>
Message-ID: <FtDgzqkxbiUrEEutqoTjnbPiDE5VmJFH4pYDN97jbqA=.92524dca-6010-4d6b-8b29-6801297e1a34@github.com>

On Fri, 19 Feb 2021 15:03:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> As I can see only ByteArrayInputStream is actually passed in `InputStream` in current JDK code:
>> 
>>     PKCS7 pkcs7 = new PKCS7(is.readAllBytes());
>>         private static List<X509Certificate> parsePKCS7(InputStream is)
>>             certs = parsePKCS7(is);
>>                 public X509CertPath(InputStream is, String encoding)
>>                     return new X509CertPath(new ByteArrayInputStream(data), encoding);
>> 
>>     PKCS7 pkcs7 = new PKCS7(is.readAllBytes());
>>         private static List<X509Certificate> parsePKCS7(InputStream is)
>>             certs = parsePKCS7(is);
>>                 public X509CertPath(InputStream is, String encoding)
>>                     this(is, PKIPATH_ENCODING);
>>                         public X509CertPath(InputStream is) throws CertificateException {
>>                             return new X509CertPath(new ByteArrayInputStream(encoding));
>> 
>> ![???????????](https://user-images.githubusercontent.com/741251/108475587-f4f61080-72a1-11eb-91e0-ac2b98c7c490.png)
>> 
>> Perhaps original marking approach was lost during refactoring?
>
> You are right, the code was refactored (way back in 2010) [1] to read one block at a time, so this check on mark can be removed. So, in this case, I think it is probably safe to just pass the InputStream as-is to PKCS7(InputStream), but maybe you can add a comment that says this should always be a ByteArrayInputStream. We can look at refactoring this code and clean it up a bit more later.
> 
> [1] https://hg.openjdk.java.net/jdk/jdk/rev/337ae296b6d6

I find implementation of `sun.security.pkcs.PKCS7#PKCS7(java.io.InputStream)` a bit confusing (or even buggy). It uses only `InputStream.available()` to parse block.
So I would prefer to not use it.

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

PR: https://git.openjdk.java.net/jdk/pull/1853

From darcy at openjdk.java.net  Mon Mar  8 07:28:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 8 Mar 2021 07:28:18 GMT
Subject: RFR: 8261366: Add discussion of IEEE 754 to BigDecimal
Message-ID: <V7rgWBXO_3oihD9R4KQfeLoLqN62NvGIm7BEI5lwqL4=.f5026951-4312-4e2a-bd31-64f0491467c4@github.com>

Informative update to BigDecimal and related classes to latest IEEE 754 terminology, including a discussion of the similarities and differences of BigDecimal and IEEE 754 decimal arithmetic.

Once the wording is finalized, I'll reflow any modified paragraphs and update the copyright years, etc.

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

Commit messages:
 - 8261366: Add discussion of IEEE 754 to BigDecimal

Changes: https://git.openjdk.java.net/jdk/pull/2868/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2868&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261366
  Stats: 88 lines in 3 files changed: 60 ins; 3 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2868.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2868/head:pull/2868

PR: https://git.openjdk.java.net/jdk/pull/2868

From github.com+592810+efge at openjdk.java.net  Mon Mar  8 09:57:10 2021
From: github.com+592810+efge at openjdk.java.net (Florent Guillaume)
Date: Mon, 8 Mar 2021 09:57:10 GMT
Subject: RFR: 8261366: Add discussion of IEEE 754 to BigDecimal
In-Reply-To: <V7rgWBXO_3oihD9R4KQfeLoLqN62NvGIm7BEI5lwqL4=.f5026951-4312-4e2a-bd31-64f0491467c4@github.com>
References: <V7rgWBXO_3oihD9R4KQfeLoLqN62NvGIm7BEI5lwqL4=.f5026951-4312-4e2a-bd31-64f0491467c4@github.com>
Message-ID: <vcGuFZtf4fjL7K_j915HI0U_vLfiajiGGGt5n9zMdQQ=.f1713070-9572-4e5f-abb9-ee7c8a28f924@github.com>

On Mon, 8 Mar 2021 07:23:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Informative update to BigDecimal and related classes to latest IEEE 754 terminology, including a discussion of the similarities and differences of BigDecimal and IEEE 754 decimal arithmetic.
> 
> Once the wording is finalized, I'll reflow any modified paragraphs and update the copyright years, etc.

src/java.base/share/classes/java/math/BigDecimal.java line 250:

> 248:  * values of a given format and produce a result in the same format.
> 249:  * A {@code BigDecimal}'s {@linkplain scale() scale} is equivalent to
> 250:  * negating an IEEE 754 value's exponent. {@code BigDecimal} values to

_to_ -> _do_

src/java.base/share/classes/java/math/BigDecimal.java line 260:

> 258:  * in {@code BigDecimal}, if a nonzero three-digit number and a
> 259:  * nonzero four-digit number are multiplied together in the context of
> 260:  * a {@code MathContext} object has a precision of three, the result

_has_ -> _having_

src/java.base/share/classes/java/math/BigDecimal.java line 275:

> 273:  * numerical values computed can differ if the exponent range of the
> 274:  * IEEE 754 format being approximated is exceeded since a {@code
> 275:  * MathContext} does not curtail the scale {@code BigDecimal}

_the scale_ -> _the scale of_

Suggest using another word than _curtail_, whose meaning will not be immediately clear to non-native readers as it's not a technical term.

src/java.base/share/classes/java/math/BigDecimal.java line 277:

> 275:  * MathContext} does not curtail the scale {@code BigDecimal}
> 276:  * results. Operations that would generate a NaN or exact infinity,
> 277:  * such as dividing by zero, throw an {@code Arithmetic-Exception} in

`Arithmetic-Exception` -> `ArithmeticException`

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

PR: https://git.openjdk.java.net/jdk/pull/2868

From redestad at openjdk.java.net  Mon Mar  8 10:38:06 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Mar 2021 10:38:06 GMT
Subject: Integrated: 8263091: Remove CharacterData.isOtherUppercase/-Lowercase
In-Reply-To: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
References: <PfOld-3KR7jEOIkcYJZKH9DtUjvu3Fw2zZKLkyecfyE=.75c7446c-9b77-48fa-a9af-4d25a74ce6ae@github.com>
Message-ID: <5wplMw7Bh22b4bOORpZk6sE5nFsKDaVXmn25F7soeps=.ba21d564-40f0-43a4-be1c-12b51538c1fb@github.com>

On Fri, 5 Mar 2021 14:24:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch removes the CharacterData.isOtherUppercase and isOtherLowercase methods. It also exploits the fact that isOtherUppercase is always false for all codepoints in the CharacterDataLatin1 range for a small speed-up.
> 
> I have no means to test if this is correct on PPC, which has intrinsics for isLowerCase/isUpperCase, but unless I'm reading the code wrong the intrinsic for isLowerCase on PPC already appears to effectively do the fused logic of isLowerCase(ch) || isOtherLowerCase(ch) since it handles the two values where isLowerCase and isOtherLowercase disagrees (0xaa, 0xba), which means this change should make the intrinsic and the java code be in better agreement.

This pull request has now been integrated.

Changeset: a0c3f242
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a0c3f242
Stats:     98 lines in 8 files changed: 1 ins; 71 del; 26 mod

8263091: Remove CharacterData.isOtherUppercase/-Lowercase

Reviewed-by: rriggs, naoto, iris

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

PR: https://git.openjdk.java.net/jdk/pull/2846

From raffaello.giulietti at gmail.com  Mon Mar  8 10:52:41 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Mon, 8 Mar 2021 11:52:41 +0100
Subject: Comment on CSR 8251991: Hex formatting and parsing utility
Message-ID: <994ead35-6c49-8ceb-da9c-916f163feac3@gmail.com>

Hello,

it appears that all of the following API methods in [1] can be declared 
*static*, which makes them more useful in contexts where there's no 
instance of HexFormat available or none is desired.

As 17 has not yet entered any formal phase, the change should be harmless.

   public boolean isHexDigit(int);
   public int fromHexDigit(int);
   public int fromHexDigits(java.lang.CharSequence);
   public int fromHexDigits(java.lang.CharSequence, int, int);
   public long fromHexDigitsToLong(java.lang.CharSequence);
   public long fromHexDigitsToLong(java.lang.CharSequence, int, int);

Greetings
Raffaello

----

[1] https://bugs.openjdk.java.net/browse/JDK-8251991

From redestad at openjdk.java.net  Mon Mar  8 11:04:10 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Mar 2021 11:04:10 GMT
Subject: Integrated: 8263090: Avoid reading volatile fields twice in
 Locale.getDefault(Category)
In-Reply-To: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
References: <AxbSzAljA0tcmjhjpdUZEp_85NTiXSEsTWnPP8b6mIw=.72964eae-48bf-40ac-b00b-732eaf55ae4d@github.com>
Message-ID: <OtH0CLSitr9LXy0Se-e1XaYUQN1Ski2D5bV2R8p5QNA=.88de834c-1ac9-46b1-8fa3-af08d722cad2@github.com>

On Fri, 5 Mar 2021 14:14:14 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch refactors Locale.getDefault(Category) so that the volatile field holding the Locale is typically only read once. This has a small performance advantage, and might be more robust if initialization is racy.

This pull request has now been integrated.

Changeset: 13625beb
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/13625beb
Stats:     92 lines in 2 files changed: 72 ins; 5 del; 15 mod

8263090: Avoid reading volatile fields twice in Locale.getDefault(Category)

Reviewed-by: rriggs, naoto, serb

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

PR: https://git.openjdk.java.net/jdk/pull/2845

From redestad at openjdk.java.net  Mon Mar  8 12:13:07 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Mar 2021 12:13:07 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers
In-Reply-To: <8xC024CKqz1b-NvGwL1HHudDIQFsKp1LZZ8MkljGB1k=.a2811f0b-6e88-4de7-8fa7-489e8f69fb29@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
 <KMwMpB2d88RVYH8eJJfVjiGKtB_Z1d1NeucsJWk6peM=.9edbc035-6e67-41a3-8a0f-d96a1092b588@github.com>
 <KUXdjaIYgAuKQ8vywohqU8rbO3WboiRPrlDKI68cFaY=.490dbe62-dc39-4c68-8ba7-1fd875fc9e06@github.com>
 <8xC024CKqz1b-NvGwL1HHudDIQFsKp1LZZ8MkljGB1k=.a2811f0b-6e88-4de7-8fa7-489e8f69fb29@github.com>
Message-ID: <m1IFkR2KcnRH_m4ASMlTgbCC2UUj-U3hEFZrUl95Cd4=.2b45b448-5928-49b3-9089-c9c426d8d965@github.com>

On Fri, 5 Mar 2021 17:08:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I did think about it, but it seemed to stray a bit too far from the intent of this enhancement.
>
> I only looked at it because of the updates to use switch expressions...
> ok, either way.

I had reason to muck around with the switch expressions, since `Conversion.isValid` was inefficient (for startup) and subtly wrong (accepted `'t'`).

Getting rid of explicit unboxing - `.byteValue()` - is just a syntactic improvement, so I indulged in a few places.

Using instanceof pattern matching OTOH changes bytecode shape a fair bit by introducing locals and changing the execution order. The suggestions you made above also mean we'd unbox twice. Probably inconsequential, but I'm wary of such changes when I don't have benchmarks to assert they are performance neutral.

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

PR: https://git.openjdk.java.net/jdk/pull/2830

From Alan.Bateman at oracle.com  Mon Mar  8 13:44:11 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 8 Mar 2021 13:44:11 +0000
Subject: Question about java.system.class.loader and the module system
In-Reply-To: <CA+3eh13VwLPexL6NPQbkU2fN7WVE51gOUaM+zCDSpW8OPQ4ASA@mail.gmail.com>
References: <CA+3eh11wSfe5w7wpfx9r48iFDmdF6yt2=O4fqs0DjB4vMBgFFQ@mail.gmail.com>
 <1c05cc73-7c3b-dadb-ee6f-4b2db7d2dff7@oracle.com>
 <CA+3eh13VwLPexL6NPQbkU2fN7WVE51gOUaM+zCDSpW8OPQ4ASA@mail.gmail.com>
Message-ID: <f0f26485-c233-cb31-94ea-6ed40a932367@oracle.com>

On 03/03/2021 20:12, Volker Simonis wrote:
> :
> Maybe I should have been more specific. I meant that the paragraph on
> "java.system.class.loader" should contain one more sentence mentioning
> that setting it will only have the desired effects for the loading of
> application classes for non-modularized applications.
>

"... and is typically the class loader used to start the application" is 
correct is that it will almost always be the defining class loader of 
the main class, even if it is loaded from a named module.

The combination of -m and -Djava.system.class.loader= should be rare. If 
there is a compelling need then we could add another sentence to the 
@implNote to document that the java launcher uses the system class 
loader when loading the main class from the class path, it is not used 
when -m is specified.

-Alan

From rriggs at openjdk.java.net  Mon Mar  8 14:22:07 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 8 Mar 2021 14:22:07 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers
In-Reply-To: <m1IFkR2KcnRH_m4ASMlTgbCC2UUj-U3hEFZrUl95Cd4=.2b45b448-5928-49b3-9089-c9c426d8d965@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
 <KMwMpB2d88RVYH8eJJfVjiGKtB_Z1d1NeucsJWk6peM=.9edbc035-6e67-41a3-8a0f-d96a1092b588@github.com>
 <KUXdjaIYgAuKQ8vywohqU8rbO3WboiRPrlDKI68cFaY=.490dbe62-dc39-4c68-8ba7-1fd875fc9e06@github.com>
 <8xC024CKqz1b-NvGwL1HHudDIQFsKp1LZZ8MkljGB1k=.a2811f0b-6e88-4de7-8fa7-489e8f69fb29@github.com>
 <m1IFkR2KcnRH_m4ASMlTgbCC2UUj-U3hEFZrUl95Cd4=.2b45b448-5928-49b3-9089-c9c426d8d965@github.com>
Message-ID: <KZlhO_xQPUmhUYtO-j4Rwv5nTmciQZ7IPN1U3KgJ1eM=.6eee0fac-9147-4a08-8628-e13666b92f2d@github.com>

On Mon, 8 Mar 2021 12:10:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I only looked at it because of the updates to use switch expressions...
>> ok, either way.
>
> I had reason to muck around with the switch expressions, since `Conversion.isValid` was inefficient (for startup) and subtly wrong (accepted `'t'`).
> 
> Getting rid of explicit unboxing - `.byteValue()` - is just a syntactic improvement, so I indulged in a few places.
> 
> Using instanceof pattern matching OTOH changes bytecode shape a fair bit by introducing locals and changing the execution order. The suggestions you made above also mean we'd unbox twice. Probably inconsequential, but I'm wary of such changes when I don't have benchmarks to assert they are performance neutral.

Makes sense, good to know... slick language features *may* come at a cost.

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

PR: https://git.openjdk.java.net/jdk/pull/2830

From redestad at openjdk.java.net  Mon Mar  8 16:00:27 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Mar 2021 16:00:27 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers [v2]
In-Reply-To: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
Message-ID: <vmKUg12IjnZ96NEgkTPqbgALq_CusLRbtG5coyYLF-8=.b21c6ff2-8b82-45bd-8504-68456738aa89@github.com>

> This patch optimizes String.format expressions that uses trivial specifiers. In the JDK, the most common variation of String.format is a variation of format("foo: %s", s), which gets a significant speed-up from this.
> 
> Various other cleanups and minor improvements reduce overhead further and ensure we get a small gain also for more complex format strings.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Lazily evaluate zero

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2830/files
  - new: https://git.openjdk.java.net/jdk/pull/2830/files/0af863e8..834450dc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2830&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2830&range=00-01

  Stats: 13 lines in 1 file changed: 4 ins; 1 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2830.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2830/head:pull/2830

PR: https://git.openjdk.java.net/jdk/pull/2830

From redestad at openjdk.java.net  Mon Mar  8 16:38:07 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Mar 2021 16:38:07 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers [v2]
In-Reply-To: <KMwMpB2d88RVYH8eJJfVjiGKtB_Z1d1NeucsJWk6peM=.9edbc035-6e67-41a3-8a0f-d96a1092b588@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
 <KMwMpB2d88RVYH8eJJfVjiGKtB_Z1d1NeucsJWk6peM=.9edbc035-6e67-41a3-8a0f-d96a1092b588@github.com>
Message-ID: <ubi3049NJLz0M7N99dgk4dRV51YkxkLDMph_dJ8HbWY=.b8bb7aae-e6cc-4c05-98fd-90c9abb8ed90@github.com>

On Fri, 5 Mar 2021 16:36:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Lazily evaluate zero
>
> Looks good.

Piling on another optimization: The `getZero(..)` called eagerly in the constructor is rather expensive in non-US locales, e.g. running with "-Duser.language=fr":
Benchmark                  Mode  Cnt    Score     Error  Units
StringFormat.stringFormat  avgt    5  924.536 ? 253.151  ns/op
Since the zero value is only used when printing floating point number I refactored so that the localized zero is evaluated lazily, which gets numbers on the micros in line with the numbers for a US locale:
Benchmark                  Mode  Cnt    Score    Error  Units
StringFormat.stringFormat  avgt    5  291.385 ? 64.626  ns/op

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

PR: https://git.openjdk.java.net/jdk/pull/2830

From rriggs at openjdk.java.net  Mon Mar  8 16:44:08 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 8 Mar 2021 16:44:08 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers [v2]
In-Reply-To: <vmKUg12IjnZ96NEgkTPqbgALq_CusLRbtG5coyYLF-8=.b21c6ff2-8b82-45bd-8504-68456738aa89@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
 <vmKUg12IjnZ96NEgkTPqbgALq_CusLRbtG5coyYLF-8=.b21c6ff2-8b82-45bd-8504-68456738aa89@github.com>
Message-ID: <hWUOT9kS2y0b465mJegyXueYk9IEThj1XOqT3q9Hr9E=.c82c3046-b088-4c18-996b-f5a39d701b09@github.com>

On Mon, 8 Mar 2021 16:00:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch optimizes String.format expressions that uses trivial specifiers. In the JDK, the most common variation of String.format is a variation of format("foo: %s", s), which gets a significant speed-up from this.
>> 
>> Various other cleanups and minor improvements reduce overhead further and ensure we get a small gain also for more complex format strings.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lazily evaluate zero

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2830

From herrick at openjdk.java.net  Mon Mar  8 17:10:26 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 8 Mar 2021 17:10:26 GMT
Subject: RFR: JDK-8248904: Add support to jpackage for the Mac App Store
Message-ID: <Mr21WO6EZtgspQn31renDqAMna0HsTL8dlsnzPbnvas=.ad65953e-853f-454d-9689-a15d1a6a992e@github.com>

Implementation of Mac App Support including three new mac specific CLI options.

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

Commit messages:
 - JDK-8248904: Add support for Mac App Store
 - JDK-8248904: Add support for Mac App Store
 -     JDK-8248904: Add support for Mac App Store
 - JDK-8248904: Add support for Mac App Store
 - JDK-8248904: Add support for Mac App Store
 - JDK-8248904: Add support for Mac App Store

Changes: https://git.openjdk.java.net/jdk/pull/2716/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2716&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8248904
  Stats: 310 lines in 23 files changed: 205 ins; 41 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2716.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2716/head:pull/2716

PR: https://git.openjdk.java.net/jdk/pull/2716

From naoto at openjdk.java.net  Mon Mar  8 17:26:10 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 8 Mar 2021 17:26:10 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers [v2]
In-Reply-To: <vmKUg12IjnZ96NEgkTPqbgALq_CusLRbtG5coyYLF-8=.b21c6ff2-8b82-45bd-8504-68456738aa89@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
 <vmKUg12IjnZ96NEgkTPqbgALq_CusLRbtG5coyYLF-8=.b21c6ff2-8b82-45bd-8504-68456738aa89@github.com>
Message-ID: <z8j0cRgP_FdUFdAKXwi9njcExKYG6JBOmByM13Aet-4=.e1875c1d-5c61-4b72-9097-492c3066ce18@github.com>

On Mon, 8 Mar 2021 16:00:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch optimizes String.format expressions that uses trivial specifiers. In the JDK, the most common variation of String.format is a variation of format("foo: %s", s), which gets a significant speed-up from this.
>> 
>> Various other cleanups and minor improvements reduce overhead further and ensure we get a small gain also for more complex format strings.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Lazily evaluate zero

src/java.base/share/classes/java/util/Formatter.java line 2447:

> 2445:     private char zero() {
> 2446:         char zero = this.zero;
> 2447:         if (zero == 0) {

U+0000 is a valid character. Although it's almost no possibility where any locale assigns it as the zero in it, theoretically it is possible. It can be avoided by comparing it with a non-character, such as BOM (U+FFFE)

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

PR: https://git.openjdk.java.net/jdk/pull/2830

From asemenyuk at openjdk.java.net  Mon Mar  8 17:56:08 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 8 Mar 2021 17:56:08 GMT
Subject: RFR: JDK-8248904: Add support to jpackage for the Mac App Store
In-Reply-To: <Mr21WO6EZtgspQn31renDqAMna0HsTL8dlsnzPbnvas=.ad65953e-853f-454d-9689-a15d1a6a992e@github.com>
References: <Mr21WO6EZtgspQn31renDqAMna0HsTL8dlsnzPbnvas=.ad65953e-853f-454d-9689-a15d1a6a992e@github.com>
Message-ID: <bBGZQSVAaNYiNxxmRRgoh8o4XTt6cS0S1IMi9MLN0SA=.0a1698f4-05e1-4263-8f8a-7caad557a19b@github.com>

On Wed, 24 Feb 2021 21:59:22 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Implementation of Mac App Support including three new mac specific CLI options.

Marked as reviewed by asemenyuk (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2716

From redestad at openjdk.java.net  Mon Mar  8 18:52:19 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Mar 2021 18:52:19 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers [v3]
In-Reply-To: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
Message-ID: <16TwpFPu6eC2LFypi8xCsz0DewH-QAxWn5N9gQEepXk=.6c987f7c-f744-4522-a43f-fa329b0e3a07@github.com>

> This patch optimizes String.format expressions that uses trivial specifiers. In the JDK, the most common variation of String.format is a variation of format("foo: %s", s), which gets a significant speed-up from this.
> 
> Various other cleanups and minor improvements reduce overhead further and ensure we get a small gain also for more complex format strings.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Use a BOM as a sentinel for uninitialized zero

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2830/files
  - new: https://git.openjdk.java.net/jdk/pull/2830/files/834450dc..c0a7f911

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2830&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2830&range=01-02

  Stats: 8 lines in 1 file changed: 2 ins; 0 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2830.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2830/head:pull/2830

PR: https://git.openjdk.java.net/jdk/pull/2830

From pconcannon at openjdk.java.net  Mon Mar  8 18:53:19 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 8 Mar 2021 18:53:19 GMT
Subject: RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
Message-ID: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>

Hi,

Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?

Kind regards,
Patrick

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

Commit messages:
 - 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable

Changes: https://git.openjdk.java.net/jdk/pull/2879/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2879&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263190
  Stats: 60 lines in 15 files changed: 0 ins; 27 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2879.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2879/head:pull/2879

PR: https://git.openjdk.java.net/jdk/pull/2879

From redestad at openjdk.java.net  Mon Mar  8 18:58:10 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Mar 2021 18:58:10 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers [v2]
In-Reply-To: <z8j0cRgP_FdUFdAKXwi9njcExKYG6JBOmByM13Aet-4=.e1875c1d-5c61-4b72-9097-492c3066ce18@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
 <vmKUg12IjnZ96NEgkTPqbgALq_CusLRbtG5coyYLF-8=.b21c6ff2-8b82-45bd-8504-68456738aa89@github.com>
 <z8j0cRgP_FdUFdAKXwi9njcExKYG6JBOmByM13Aet-4=.e1875c1d-5c61-4b72-9097-492c3066ce18@github.com>
Message-ID: <LuzFgKyCU-YqjynsqffoLaiSNn_H6l3xgpoEk5shHL4=.81eaa05f-3899-40a6-80b2-4a855ed65b1c@github.com>

On Mon, 8 Mar 2021 17:23:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Lazily evaluate zero
>
> src/java.base/share/classes/java/util/Formatter.java line 2447:
> 
>> 2445:     private char zero() {
>> 2446:         char zero = this.zero;
>> 2447:         if (zero == 0) {
> 
> U+0000 is a valid character. Although it's almost no possibility where any locale assigns it as the zero in it, theoretically it is possible. It can be avoided by comparing it with a non-character, such as BOM (U+FFFE)

Ok, maybe a bit too defensive, but let's use BOM instead.

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

PR: https://git.openjdk.java.net/jdk/pull/2830

From brian.goetz at oracle.com  Mon Mar  8 18:58:50 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Mon, 8 Mar 2021 13:58:50 -0500
Subject: RFR: 8263190: Update java.io, java.math, and java.text to use
 instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <49b7bba1-3ed4-b96a-2561-b469314f47d1@oracle.com>

Looks good!? Glad to see the Amber features finding their way into the 
codebase.

On 3/8/2021 1:53 PM, Patrick Concannon wrote:
> Hi,
>
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
>
> Kind regards,
> Patrick
>
> -------------
>
> Commit messages:
>   - 8263190: Update java.io, java.math, and java.text to use instanceof pattern variable
>
> Changes: https://git.openjdk.java.net/jdk/pull/2879/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2879&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8263190
>    Stats: 60 lines in 15 files changed: 0 ins; 27 del; 33 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/2879.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/2879/head:pull/2879
>
> PR: https://git.openjdk.java.net/jdk/pull/2879


From asemenyuk at openjdk.java.net  Mon Mar  8 19:01:05 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 8 Mar 2021 19:01:05 GMT
Subject: RFR: 8263135: unique_ptr should not be used for types that are
 not pointers
In-Reply-To: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>
References: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>
Message-ID: <wffOIXVctFTX3iLZdKIDoG7O5lXs2f5pY_CIr9vOAy4=.cfda4408-075c-4d48-a093-ddfcf843ec67@github.com>

On Sun, 7 Mar 2021 03:15:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I saw error during jpackage compilation with VS 2019 (16.9.0) as following (on Japanese locale):
> 
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): error C2440: '=': '_Other' ?? '_Ty' ?????????
>         with
>         [
>             _Other=nullptr
>         ]
>         and
>         [
>             _Ty=unsigned long
>         ]
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): note: ?????? nullptr ?????????????? reinterpret_cast ??????????????????????
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3423): note: ?????????? ?????? ??????? '_Ty std::exchange<_Ty2,nullptr>(_Ty &,_Other &&) noexcept(false)' ????????????????
>         with
>         [
>             _Ty=unsigned long,
>             _Ty2=unsigned long,
>             _Other=nullptr
>         ]
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3422): note: ??? ??? ??? ?????? 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' ???????
> d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.cpp(237): note: ?????????? ?????? ??????? 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' ????????????????
> d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.h(119): note: ???????? ?? ? ?????? ??????? 'std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>' ????????????????
> 
> `UniqueMSIHANDLE` is declared in MsiUtils.h as `unique_ptr` for `MSIHANDLE`. `MSIHANDLE` seems to be declared as synonym for `unsigned long`, not a pointer type.
> I think `MSIHANDLE` does not need to handle as `unique_ptr` if it releases at d'tor of the class which holds it (`Database`, `DatabaseRecord`).

Marked as reviewed by asemenyuk (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2858

From herrick at openjdk.java.net  Mon Mar  8 19:08:08 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 8 Mar 2021 19:08:08 GMT
Subject: RFR: 8263135: unique_ptr should not be used for types that are
 not pointers
In-Reply-To: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>
References: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>
Message-ID: <BN9V4GIxcI1oWdcyeDvx27SqU5yaZKtTsvBQZiquJEY=.d0bfe300-e051-48b9-bf47-086ef7e4b635@github.com>

On Sun, 7 Mar 2021 03:15:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I saw error during jpackage compilation with VS 2019 (16.9.0) as following (on Japanese locale):
> 
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): error C2440: '=': '_Other' ?? '_Ty' ?????????
>         with
>         [
>             _Other=nullptr
>         ]
>         and
>         [
>             _Ty=unsigned long
>         ]
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): note: ?????? nullptr ?????????????? reinterpret_cast ??????????????????????
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3423): note: ?????????? ?????? ??????? '_Ty std::exchange<_Ty2,nullptr>(_Ty &,_Other &&) noexcept(false)' ????????????????
>         with
>         [
>             _Ty=unsigned long,
>             _Ty2=unsigned long,
>             _Other=nullptr
>         ]
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3422): note: ??? ??? ??? ?????? 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' ???????
> d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.cpp(237): note: ?????????? ?????? ??????? 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' ????????????????
> d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.h(119): note: ???????? ?? ? ?????? ??????? 'std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>' ????????????????
> 
> `UniqueMSIHANDLE` is declared in MsiUtils.h as `unique_ptr` for `MSIHANDLE`. `MSIHANDLE` seems to be declared as synonym for `unsigned long`, not a pointer type.
> I think `MSIHANDLE` does not need to handle as `unique_ptr` if it releases at d'tor of the class which holds it (`Database`, `DatabaseRecord`).

Marked as reviewed by herrick (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2858

From naoto at openjdk.java.net  Mon Mar  8 19:08:10 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 8 Mar 2021 19:08:10 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers [v3]
In-Reply-To: <16TwpFPu6eC2LFypi8xCsz0DewH-QAxWn5N9gQEepXk=.6c987f7c-f744-4522-a43f-fa329b0e3a07@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
 <16TwpFPu6eC2LFypi8xCsz0DewH-QAxWn5N9gQEepXk=.6c987f7c-f744-4522-a43f-fa329b0e3a07@github.com>
Message-ID: <4UxVOQb4o6A8mt-3deVgUX5MzeOywIOPJDWjVNIa4KU=.599b78b1-0f50-4670-bf47-c9bb2b03165b@github.com>

On Mon, 8 Mar 2021 18:52:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch optimizes String.format expressions that uses trivial specifiers. In the JDK, the most common variation of String.format is a variation of format("foo: %s", s), which gets a significant speed-up from this.
>> 
>> Various other cleanups and minor improvements reduce overhead further and ensure we get a small gain also for more complex format strings.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use a BOM as a sentinel for uninitialized zero

src/java.base/share/classes/java/util/Formatter.java line 1936:

> 1934:     private IOException lastException;
> 1935: 
> 1936:     // Non-unicode code point value used to mark zero as uninitialized

Sorry for being anal here, but BOM is a "noncharacter", a valid Unicode code point. So "noncharacter" over "Non-unicode code point" seems appropriate.
http://www.unicode.org/faq/private_use.html#nonchar1

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

PR: https://git.openjdk.java.net/jdk/pull/2830

From bpb at openjdk.java.net  Mon Mar  8 19:11:05 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 8 Mar 2021 19:11:05 GMT
Subject: RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <Aqqndb9HMLoLcTYy88-v-uauh9LHTJ53dFomiiUCAEg=.4529729a-2fa8-4058-9112-1591e34d947d@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Looks good and builds cleanly: approved.

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2879

From lancea at openjdk.java.net  Mon Mar  8 19:11:04 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 8 Mar 2021 19:11:04 GMT
Subject: RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <TnSlgqwnZqIqfY4VuyJn553m48F_9wvRM82kaOd7gGc=.d8d822ee-f2d6-457d-ad06-53fba9238163@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Looks good

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2879

From darcy at openjdk.java.net  Mon Mar  8 19:11:05 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 8 Mar 2021 19:11:05 GMT
Subject: RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <v78RbXoCvmvHol3MBqbv1N7fXYZnhoXWTg1zIxrlLWs=.610d5c20-6c3c-40b9-92fa-91f3f76b03ac@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Marked as reviewed by darcy (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2879

From naoto at openjdk.java.net  Mon Mar  8 19:11:06 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 8 Mar 2021 19:11:06 GMT
Subject: RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <AqEG0T-j7lNFizGqOnhUXFtzYanl7f_JJxxrlwOWELM=.23a81146-54f3-4b04-973d-72902cdac1cb@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2879

From dfuchs at openjdk.java.net  Mon Mar  8 19:18:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 8 Mar 2021 19:18:08 GMT
Subject: RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <MIMo3HnvFlOgftRF_iydqtysDP6ho_TI3YMl7tjoPXc=.ae449ceb-a9ec-4c7e-ae38-d1f2d1afc2d9@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Marked as reviewed by dfuchs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2879

From iris at openjdk.java.net  Mon Mar  8 19:18:07 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 8 Mar 2021 19:18:07 GMT
Subject: RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <vDee8ZhB2ZD28i-UmdqAhNrgTJTWoSPQRT8wW-v1wG4=.8abf79b0-293f-4406-93c9-7067755bb323@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2879

From bchristi at openjdk.java.net  Mon Mar  8 19:26:09 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Mon, 8 Mar 2021 19:26:09 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v5]
In-Reply-To: <EhUg_gwzyqIZ3IAPbWqm_s1yOyIW_I9oK_B1yKnqmm8=.a5cf7361-85d2-4656-9f70-6bcd06030bf3@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <EhUg_gwzyqIZ3IAPbWqm_s1yOyIW_I9oK_B1yKnqmm8=.a5cf7361-85d2-4656-9f70-6bcd06030bf3@github.com>
Message-ID: <TcMpjgibzE43w1XKFZxHBMY9UmtOjvOLb0dcdLw0epA=.0b519eb7-327d-44c3-8433-59531b250a0f@github.com>

On Sat, 6 Mar 2021 01:35:28 GMT, Craig Andrews <github.com+194713+candrews at openjdk.org> wrote:

>> `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.
>> 
>> According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.
>> 
>> Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>>> Returns:
>>>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.
>> 
>> And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>>> Returns:
>>>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.
>> 
>> Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.
>> 
>> Here's a stack trace:
>> java.lang.IllegalArgumentException: name
>>         at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>>         at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>>         at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
>> 
>> Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>>         URL findResource(final String name, boolean check) {
>>             URL url;
>>             try {
>>                 url = new URL(base, ParseUtil.encodePath(name, false));
>>             } catch (MalformedURLException e) {
>>                 throw new IllegalArgumentException("name");
>>             }
>> 
>> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
>> 
>> A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>>         URL findResource(final String name, boolean check) {
>>             URL url;
>>             try {
>>                 url = new URL(base, ParseUtil.encodePath(name, false));
>>             } catch (MalformedURLException e) {
>>                 throw new IllegalArgumentException("name");
>>             }
>> 
>> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
>
> Craig Andrews has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException

Looks good, thanks!

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

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2662

From smarks at openjdk.java.net  Mon Mar  8 19:26:08 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 8 Mar 2021 19:26:08 GMT
Subject: RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <hPAz8gUPr5mgSVviup8ZIJ9UpzbavgRnMpn5pYxPxHo=.409f8ff0-9b4e-4025-8685-332fe6b34ac0@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Marked as reviewed by smarks (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2879

From martin at openjdk.java.net  Mon Mar  8 20:15:10 2021
From: martin at openjdk.java.net (Martin Buchholz)
Date: Mon, 8 Mar 2021 20:15:10 GMT
Subject: Integrated: 8260664: Phaser.arrive() memory consistency effects
In-Reply-To: <bqalK1jqP68BUb-ynq9QI0jIdIXGUbLJ2voDylmEags=.1e13416b-5448-425b-ab87-cf91fd1efd1d@github.com>
References: <bqalK1jqP68BUb-ynq9QI0jIdIXGUbLJ2voDylmEags=.1e13416b-5448-425b-ab87-cf91fd1efd1d@github.com>
Message-ID: <fDJWdQKeBKzW9qTQhLyVyBNiHGJVtCSUb9WmDhZIRek=.25fc892d-0518-4d6d-a5c9-bd694daa082d@github.com>

On Wed, 3 Feb 2021 21:55:54 GMT, Martin Buchholz <martin at openjdk.org> wrote:

> 8260664: Phaser.arrive() memory consistency effects

This pull request has now been integrated.

Changeset: eb4a8af5
Author:    Martin Buchholz <martin at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eb4a8af5
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8260664: Phaser.arrive() memory consistency effects

Reviewed-by: dl

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

PR: https://git.openjdk.java.net/jdk/pull/2388

From redestad at openjdk.java.net  Mon Mar  8 20:39:08 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Mar 2021 20:39:08 GMT
Subject: RFR: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <rkddgafwznDNp7zDNXYqreQfKwFov1obgpdrxWmKFIY=.0fbd0612-b05d-455e-a8ec-044507760b4c@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Marked as reviewed by redestad (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2879

From redestad at openjdk.java.net  Mon Mar  8 20:42:21 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Mar 2021 20:42:21 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers [v4]
In-Reply-To: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
Message-ID: <LytT2rqoYoNmIT0qpaieZ-TRYZfNUvCT1EagvHjZrsM=.6ad515cb-fd97-4196-9be8-09bfdc0e2015@github.com>

> This patch optimizes String.format expressions that uses trivial specifiers. In the JDK, the most common variation of String.format is a variation of format("foo: %s", s), which gets a significant speed-up from this.
> 
> Various other cleanups and minor improvements reduce overhead further and ensure we get a small gain also for more complex format strings.

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Better words

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2830/files
  - new: https://git.openjdk.java.net/jdk/pull/2830/files/c0a7f911..cc62cc94

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2830&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2830&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/2830

From joe.darcy at oracle.com  Mon Mar  8 21:01:58 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 8 Mar 2021 13:01:58 -0800
Subject: RFR: 8261366: Add discussion of IEEE 754 to BigDecimal
In-Reply-To: <vcGuFZtf4fjL7K_j915HI0U_vLfiajiGGGt5n9zMdQQ=.f1713070-9572-4e5f-abb9-ee7c8a28f924@github.com>
References: <V7rgWBXO_3oihD9R4KQfeLoLqN62NvGIm7BEI5lwqL4=.f5026951-4312-4e2a-bd31-64f0491467c4@github.com>
 <vcGuFZtf4fjL7K_j915HI0U_vLfiajiGGGt5n9zMdQQ=.f1713070-9572-4e5f-abb9-ee7c8a28f924@github.com>
Message-ID: <d18217f0-d15d-4707-8f51-81a7a0561fd8@oracle.com>

Thanks for the review Florent; will fix in the next push,

-Joe

On 3/8/2021 1:57 AM, Florent Guillaume wrote:
> On Mon, 8 Mar 2021 07:23:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>> Informative update to BigDecimal and related classes to latest IEEE 754 terminology, including a discussion of the similarities and differences of BigDecimal and IEEE 754 decimal arithmetic.
>>
>> Once the wording is finalized, I'll reflow any modified paragraphs and update the copyright years, etc.
> src/java.base/share/classes/java/math/BigDecimal.java line 250:
>
>> 248:  * values of a given format and produce a result in the same format.
>> 249:  * A {@code BigDecimal}'s {@linkplain scale() scale} is equivalent to
>> 250:  * negating an IEEE 754 value's exponent. {@code BigDecimal} values to
> _to_ -> _do_
>
> src/java.base/share/classes/java/math/BigDecimal.java line 260:
>
>> 258:  * in {@code BigDecimal}, if a nonzero three-digit number and a
>> 259:  * nonzero four-digit number are multiplied together in the context of
>> 260:  * a {@code MathContext} object has a precision of three, the result
> _has_ -> _having_
>
> src/java.base/share/classes/java/math/BigDecimal.java line 275:
>
>> 273:  * numerical values computed can differ if the exponent range of the
>> 274:  * IEEE 754 format being approximated is exceeded since a {@code
>> 275:  * MathContext} does not curtail the scale {@code BigDecimal}
> _the scale_ -> _the scale of_
>
> Suggest using another word than _curtail_, whose meaning will not be immediately clear to non-native readers as it's not a technical term.
>
> src/java.base/share/classes/java/math/BigDecimal.java line 277:
>
>> 275:  * MathContext} does not curtail the scale {@code BigDecimal}
>> 276:  * results. Operations that would generate a NaN or exact infinity,
>> 277:  * such as dividing by zero, throw an {@code Arithmetic-Exception} in
> `Arithmetic-Exception` -> `ArithmeticException`
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/2868

From darcy at openjdk.java.net  Mon Mar  8 21:07:22 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 8 Mar 2021 21:07:22 GMT
Subject: RFR: 8261366: Add discussion of IEEE 754 to BigDecimal [v2]
In-Reply-To: <V7rgWBXO_3oihD9R4KQfeLoLqN62NvGIm7BEI5lwqL4=.f5026951-4312-4e2a-bd31-64f0491467c4@github.com>
References: <V7rgWBXO_3oihD9R4KQfeLoLqN62NvGIm7BEI5lwqL4=.f5026951-4312-4e2a-bd31-64f0491467c4@github.com>
Message-ID: <-nt3_djmx5slYvi9_cKDwXbPn0S3N53SWMvnSFKv6C8=.e71a6f70-19ed-46ff-84d9-ad73d097e1c1@github.com>

> Informative update to BigDecimal and related classes to latest IEEE 754 terminology, including a discussion of the similarities and differences of BigDecimal and IEEE 754 decimal arithmetic.
> 
> Once the wording is finalized, I'll reflow any modified paragraphs and update the copyright years, etc.

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

  Fix typos found in review.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2868/files
  - new: https://git.openjdk.java.net/jdk/pull/2868/files/1ff051bb..a29d60fd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2868&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2868&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2868

From igraves at openjdk.java.net  Mon Mar  8 21:30:28 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 8 Mar 2021 21:30:28 GMT
Subject: RFR: 8262351: Extra '0' in java.util.Formatter for '%012a' conversion
 with a sign character
Message-ID: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>

This fixes a zero-adding issue observed in the hex float conversion.

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

Commit messages:
 - Fixing zero-padding issue in hex float conversion

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

PR: https://git.openjdk.java.net/jdk/pull/2881

From naoto at openjdk.java.net  Mon Mar  8 21:45:08 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 8 Mar 2021 21:45:08 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers [v4]
In-Reply-To: <LytT2rqoYoNmIT0qpaieZ-TRYZfNUvCT1EagvHjZrsM=.6ad515cb-fd97-4196-9be8-09bfdc0e2015@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
 <LytT2rqoYoNmIT0qpaieZ-TRYZfNUvCT1EagvHjZrsM=.6ad515cb-fd97-4196-9be8-09bfdc0e2015@github.com>
Message-ID: <J0MSvxpwZgI7BT6C70fPwv21FocDSgsEbwqfKWr--zE=.f3a8ae73-4a42-437f-b57c-1dea5599a75a@github.com>

On Mon, 8 Mar 2021 20:42:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This patch optimizes String.format expressions that uses trivial specifiers. In the JDK, the most common variation of String.format is a variation of format("foo: %s", s), which gets a significant speed-up from this.
>> 
>> Various other cleanups and minor improvements reduce overhead further and ensure we get a small gain also for more complex format strings.
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Better words

Looks good!

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2830

From bpb at openjdk.java.net  Mon Mar  8 22:14:08 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 8 Mar 2021 22:14:08 GMT
Subject: RFR: 8261366: Add discussion of IEEE 754 to BigDecimal [v2]
In-Reply-To: <-nt3_djmx5slYvi9_cKDwXbPn0S3N53SWMvnSFKv6C8=.e71a6f70-19ed-46ff-84d9-ad73d097e1c1@github.com>
References: <V7rgWBXO_3oihD9R4KQfeLoLqN62NvGIm7BEI5lwqL4=.f5026951-4312-4e2a-bd31-64f0491467c4@github.com>
 <-nt3_djmx5slYvi9_cKDwXbPn0S3N53SWMvnSFKv6C8=.e71a6f70-19ed-46ff-84d9-ad73d097e1c1@github.com>
Message-ID: <xH6zn6W7TUz5NvTumV2JJ9HDmz3uBa9PpxB7BN43Ygc=.28a05ab5-3cd1-4c8e-96d9-3b20128931c0@github.com>

On Mon, 8 Mar 2021 21:07:22 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Informative update to BigDecimal and related classes to latest IEEE 754 terminology, including a discussion of the similarities and differences of BigDecimal and IEEE 754 decimal arithmetic.
>> 
>> Once the wording is finalized, I'll reflow any modified paragraphs and update the copyright years, etc.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos found in review.

Looks fine.

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2868

From darcy at openjdk.java.net  Mon Mar  8 22:34:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 8 Mar 2021 22:34:18 GMT
Subject: RFR: 8261366: Add discussion of IEEE 754 to BigDecimal [v3]
In-Reply-To: <V7rgWBXO_3oihD9R4KQfeLoLqN62NvGIm7BEI5lwqL4=.f5026951-4312-4e2a-bd31-64f0491467c4@github.com>
References: <V7rgWBXO_3oihD9R4KQfeLoLqN62NvGIm7BEI5lwqL4=.f5026951-4312-4e2a-bd31-64f0491467c4@github.com>
Message-ID: <MfmaicrzXjLWmLlrWLv86Y2pUlUmPC7WSpvzvdnWdV4=.0f7f859c-7924-4295-a447-f1428a2f88b1@github.com>

> Informative update to BigDecimal and related classes to latest IEEE 754 terminology, including a discussion of the similarities and differences of BigDecimal and IEEE 754 decimal arithmetic.
> 
> Once the wording is finalized, I'll reflow any modified paragraphs and update the copyright years, etc.

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

  Reflow paragraphs and update copyrights.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2868/files
  - new: https://git.openjdk.java.net/jdk/pull/2868/files/a29d60fd..39c20d67

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2868&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2868&range=01-02

  Stats: 20 lines in 3 files changed: 2 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2868.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2868/head:pull/2868

PR: https://git.openjdk.java.net/jdk/pull/2868

From darcy at openjdk.java.net  Mon Mar  8 22:34:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 8 Mar 2021 22:34:18 GMT
Subject: Integrated: 8261366: Add discussion of IEEE 754 to BigDecimal
In-Reply-To: <V7rgWBXO_3oihD9R4KQfeLoLqN62NvGIm7BEI5lwqL4=.f5026951-4312-4e2a-bd31-64f0491467c4@github.com>
References: <V7rgWBXO_3oihD9R4KQfeLoLqN62NvGIm7BEI5lwqL4=.f5026951-4312-4e2a-bd31-64f0491467c4@github.com>
Message-ID: <VmyZyK6rEy1fN4vNoWWjyxBdZ5bqR3xaYgR9tvYUnEg=.d267b3c1-88ea-4bb4-ba07-38b56f434b73@github.com>

On Mon, 8 Mar 2021 07:23:25 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Informative update to BigDecimal and related classes to latest IEEE 754 terminology, including a discussion of the similarities and differences of BigDecimal and IEEE 754 decimal arithmetic.
> 
> Once the wording is finalized, I'll reflow any modified paragraphs and update the copyright years, etc.

This pull request has now been integrated.

Changeset: 14cfbda3
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/14cfbda3
Stats:     104 lines in 3 files changed: 62 ins; 3 del; 39 mod

8261366: Add discussion of IEEE 754 to BigDecimal

Reviewed-by: bpb

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

PR: https://git.openjdk.java.net/jdk/pull/2868

From asemenyuk at openjdk.java.net  Mon Mar  8 23:00:42 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 8 Mar 2021 23:00:42 GMT
Subject: RFR: 8241716: Jpackage functionality to let users choose whether to
 create shortcuts
Message-ID: <Pt6oZISZR-tReWpxp2SHlIDJmcjH8oGMME216UPA8As=.18955590-8242-40fd-a04f-749a3bbef03b@github.com>

Add support to insert dialog with prompts to create shortcuts in dialog installation sequence of Windows installers created by jpackage.
As a side effect of the fix, UI-related WiX source code was moved from main.wxs into generated ui.wxf file. Users can override ui.wxf by placing a file with this name in resource directory.
Custom dialogs optionally inserted in dialog installation sequence were placed in distinct WiX sources: InstallDirNotEmptyDlg.wxs and ShortcutPromptDlg.wxs. They can be overridden if files with the corresponding names as placed in resource directory.
Moving source code of installer UI from main.wxs into ui.wxf, InstallDirNotEmptyDlg.wxs and ShortcutPromptDlg.wxs files supposed to simplify overriding of the default UI provided by jpackage.

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

Commit messages:
 - 8241716: Jpackage functionality to let users choose whether to create shortcuts
 - 8241716: Jpackage functionality to let users choose whether to create shortcuts

Changes: https://git.openjdk.java.net/jdk/pull/2882/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2882&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8241716
  Stats: 3069 lines in 23 files changed: 2062 ins; 988 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2882.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2882/head:pull/2882

PR: https://git.openjdk.java.net/jdk/pull/2882

From redestad at openjdk.java.net  Mon Mar  8 23:18:08 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Mar 2021 23:18:08 GMT
Subject: RFR: 8263038: Optimize String.format for simple specifiers [v4]
In-Reply-To: <J0MSvxpwZgI7BT6C70fPwv21FocDSgsEbwqfKWr--zE=.f3a8ae73-4a42-437f-b57c-1dea5599a75a@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
 <LytT2rqoYoNmIT0qpaieZ-TRYZfNUvCT1EagvHjZrsM=.6ad515cb-fd97-4196-9be8-09bfdc0e2015@github.com>
 <J0MSvxpwZgI7BT6C70fPwv21FocDSgsEbwqfKWr--zE=.f3a8ae73-4a42-437f-b57c-1dea5599a75a@github.com>
Message-ID: <_yst3N6O7W9u3JTxBF_nadbYlFQxRyRPBiQXuZisNv8=.be9407c6-f0e0-4877-a7bf-6ab3ab524976@github.com>

On Mon, 8 Mar 2021 21:42:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Better words
>
> Looks good!

Thank you for reviews, Roger and Naoto!

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

PR: https://git.openjdk.java.net/jdk/pull/2830

From redestad at openjdk.java.net  Mon Mar  8 23:18:11 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 8 Mar 2021 23:18:11 GMT
Subject: Integrated: 8263038: Optimize String.format for simple specifiers
In-Reply-To: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
References: <3PKvAU1NgxJM6ycc9FDDTAgF4UWT06SHJgoKVpVX_yE=.a546c246-456d-4e74-8998-82cc60712383@github.com>
Message-ID: <uPe4xVcqFKFcVhr0exnrHByUftEIvf5w0NbDjqAsrck=.ecddf1dc-a483-4886-bf01-9408616e911f@github.com>

On Thu, 4 Mar 2021 17:20:40 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch optimizes String.format expressions that uses trivial specifiers. In the JDK, the most common variation of String.format is a variation of format("foo: %s", s), which gets a significant speed-up from this.
> 
> Various other cleanups and minor improvements reduce overhead further and ensure we get a small gain also for more complex format strings.

This pull request has now been integrated.

Changeset: f71b21b0
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f71b21b0
Stats:     281 lines in 2 files changed: 126 ins; 58 del; 97 mod

8263038: Optimize String.format for simple specifiers

Reviewed-by: rriggs, naoto

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

PR: https://git.openjdk.java.net/jdk/pull/2830

From jjg at openjdk.java.net  Tue Mar  9 00:15:18 2021
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 9 Mar 2021 00:15:18 GMT
Subject: RFR: 8263105: security-libs doclint cleanup
In-Reply-To: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
Message-ID: <24gnlaRnK6HCVyWRR9rnjw4EQUbakQ3jZirWKBro4Vk=.a4e4b32d-ff12-4560-ab0a-608736d2e7dc@github.com>

On Sat, 6 Mar 2021 07:31:09 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Fix various things pointed out by the most recent doclint run in the security-libs area.
> 
> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.

I've read the first 10 files. The edits are definitely in the right direction, and will address the "missing comments" issues.

I'll leave it up to you and the others in your team to decide what level of stylistic consistency you would like for the new comments, but just having a relevant comment at all is a great start.

src/java.base/share/classes/java/security/BasicPermission.java line 497:

> 495:     /**
> 496:      * @serialData Default fields.
> 497:      */

FWIW, this doc comment will be ignored, because it will be superseded by the new comment on line 499.  At some point doen the road, you may get a warning from javac about an ignored doc comment.

src/java.base/share/classes/java/security/GuardedObject.java line 64:

> 62: 
> 63:     /**
> 64:      * The guard object

add a period?

src/java.base/share/classes/java/security/PermissionCollection.java line 105:

> 103:      * Whether this permission collection is read-only.
> 104:      * <p>
> 105:      * If set, add() will throw an exception.

maybe use `{@code}` or `{@link}` on add?

src/java.base/share/classes/java/security/Permissions.java line 581:

> 579:     /**
> 580:      * @serialData Default fields.
> 581:      */

Another ignored comment. I suggest just changing these to `/*` comments.

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

PR: https://git.openjdk.java.net/jdk/pull/2856

From wetmore at openjdk.java.net  Tue Mar  9 00:15:17 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 9 Mar 2021 00:15:17 GMT
Subject: RFR: 8263105: security-libs doclint cleanup
Message-ID: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>

Fix various things pointed out by the most recent doclint run in the security-libs area.

This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.

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

Commit messages:
 - Final First Draft
 - Only 100 warnings output by default
 - 8263105: security-libs doclint cleanup

Changes: https://git.openjdk.java.net/jdk/pull/2856/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2856&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263105
  Stats: 351 lines in 39 files changed: 270 ins; 2 del; 79 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2856.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2856/head:pull/2856

PR: https://git.openjdk.java.net/jdk/pull/2856

From wetmore at openjdk.java.net  Tue Mar  9 00:15:20 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 9 Mar 2021 00:15:20 GMT
Subject: RFR: 8263105: security-libs doclint cleanup
In-Reply-To: <24gnlaRnK6HCVyWRR9rnjw4EQUbakQ3jZirWKBro4Vk=.a4e4b32d-ff12-4560-ab0a-608736d2e7dc@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
 <24gnlaRnK6HCVyWRR9rnjw4EQUbakQ3jZirWKBro4Vk=.a4e4b32d-ff12-4560-ab0a-608736d2e7dc@github.com>
Message-ID: <7J0SCUfBXhQs33Dm0ALYoOE-N3g8uJn93_reCgbebPg=.15fa4742-58d0-44cf-a113-0df0e25b7663@github.com>

On Sat, 6 Mar 2021 19:20:39 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Fix various things pointed out by the most recent doclint run in the security-libs area.
>> 
>> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.
>
> src/java.base/share/classes/java/security/BasicPermission.java line 497:
> 
>> 495:     /**
>> 496:      * @serialData Default fields.
>> 497:      */
> 
> FWIW, this doc comment will be ignored, because it will be superseded by the new comment on line 499.  At some point doen the road, you may get a warning from javac about an ignored doc comment.

Ok

> src/java.base/share/classes/java/security/GuardedObject.java line 64:
> 
>> 62: 
>> 63:     /**
>> 64:      * The guard object
> 
> add a period?

Probably worth doing as it's the first sentence.

> src/java.base/share/classes/java/security/PermissionCollection.java line 105:
> 
>> 103:      * Whether this permission collection is read-only.
>> 104:      * <p>
>> 105:      * If set, add() will throw an exception.
> 
> maybe use `{@code}` or `{@link}` on add?

Done.

> src/java.base/share/classes/java/security/Permissions.java line 581:
> 
>> 579:     /**
>> 580:      * @serialData Default fields.
>> 581:      */
> 
> Another ignored comment. I suggest just changing these to `/*` comments.

Good idea.  Done.

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

PR: https://git.openjdk.java.net/jdk/pull/2856

From iris at openjdk.java.net  Tue Mar  9 00:49:08 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Tue, 9 Mar 2021 00:49:08 GMT
Subject: RFR: 8263105: security-libs doclint cleanup
In-Reply-To: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
Message-ID: <viBZ3LxB70nqlheSL2iFtC8DUzjqd2tyHddz_9S9AKs=.455ddfcb-4e78-4fc7-ae74-3e270cbf2a8a@github.com>

On Sat, 6 Mar 2021 07:31:09 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Fix various things pointed out by the most recent doclint run in the security-libs area.
> 
> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.

I'm happy to see a reduction in the number of warnings.

I suspect there are a few places where Object{In,Out}putStream is fully qualified when it's not strictly necessary; however, since this is in pre-existing code, I don't think this needs to be changed now.

src/java.base/share/classes/java/security/KeyPair.java line 53:

> 51: 
> 52:     /**
> 53:      *

Extra line?

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2856

From wetmore at openjdk.java.net  Tue Mar  9 00:56:25 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 9 Mar 2021 00:56:25 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v2]
In-Reply-To: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
Message-ID: <l_JSWYHwNTvKCTPRBF1vrsUiYKJzawtb_2j07-uwbI8=.e2cc1d68-2d15-4c35-a2a5-25aadf24067c@github.com>

> Fix various things pointed out by the most recent doclint run in the security-libs area.
> 
> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.

Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:

  Codereview Comment

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2856/files
  - new: https://git.openjdk.java.net/jdk/pull/2856/files/f2253d91..1fa29ea6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2856&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2856&range=00-01

  Stats: 7 lines in 1 file changed: 0 ins; 5 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2856.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2856/head:pull/2856

PR: https://git.openjdk.java.net/jdk/pull/2856

From ysuenaga at openjdk.java.net  Tue Mar  9 01:01:05 2021
From: ysuenaga at openjdk.java.net (Yasumasa Suenaga)
Date: Tue, 9 Mar 2021 01:01:05 GMT
Subject: Integrated: 8263135: unique_ptr should not be used for types that are
 not pointers
In-Reply-To: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>
References: <Bo3Up6OnH-2l-FKs0QhtNZPN0jfbDyBhPOoDYaFLr4Y=.ea38b58a-94a2-42e1-88e2-41308aa04587@github.com>
Message-ID: <-LaHsGOPopSmyI8F-Uh2TGQLrfAUlDEaENZOlbAsXW0=.56555887-ed48-4835-9839-58a1fe10617b@github.com>

On Sun, 7 Mar 2021 03:15:46 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I saw error during jpackage compilation with VS 2019 (16.9.0) as following (on Japanese locale):
> 
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): error C2440: '=': '_Other' ?? '_Ty' ?????????
>         with
>         [
>             _Other=nullptr
>         ]
>         and
>         [
>             _Ty=unsigned long
>         ]
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\utility(604): note: ?????? nullptr ?????????????? reinterpret_cast ??????????????????????
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3423): note: ?????????? ?????? ??????? '_Ty std::exchange<_Ty2,nullptr>(_Ty &,_Other &&) noexcept(false)' ????????????????
>         with
>         [
>             _Ty=unsigned long,
>             _Ty2=unsigned long,
>             _Other=nullptr
>         ]
> c:\progra~2\micros~2\2019\commun~1\vc\tools\msvc\1428~1.299\include\memory(3422): note: ??? ??? ??? ?????? 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' ???????
> d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.cpp(237): note: ?????????? ?????? ??????? 'unsigned long std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>::release(void) noexcept' ????????????????
> d:\github-forked\jdk\src\jdk.jpackage\windows\native\common\MsiDb.h(119): note: ???????? ?? ? ?????? ??????? 'std::unique_ptr<MSIHANDLE,msi::MsiHandleDeleter>' ????????????????
> 
> `UniqueMSIHANDLE` is declared in MsiUtils.h as `unique_ptr` for `MSIHANDLE`. `MSIHANDLE` seems to be declared as synonym for `unsigned long`, not a pointer type.
> I think `MSIHANDLE` does not need to handle as `unique_ptr` if it releases at d'tor of the class which holds it (`Database`, `DatabaseRecord`).

This pull request has now been integrated.

Changeset: 4e947607
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4e947607
Stats:     77 lines in 4 files changed: 14 ins; 36 del; 27 mod

8263135: unique_ptr should not be used for types that are not pointers

Reviewed-by: asemenyuk, herrick

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

PR: https://git.openjdk.java.net/jdk/pull/2858

From darcy at openjdk.java.net  Tue Mar  9 01:21:07 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 9 Mar 2021 01:21:07 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v2]
In-Reply-To: <l_JSWYHwNTvKCTPRBF1vrsUiYKJzawtb_2j07-uwbI8=.e2cc1d68-2d15-4c35-a2a5-25aadf24067c@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
 <l_JSWYHwNTvKCTPRBF1vrsUiYKJzawtb_2j07-uwbI8=.e2cc1d68-2d15-4c35-a2a5-25aadf24067c@github.com>
Message-ID: <cnpWf091JffkVMPYNCP0MkfpETZ9GunMtCeQvXBpMW4=.6f6b5858-25fd-428f-abc6-6b8c9d102ba5@github.com>

On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Fix various things pointed out by the most recent doclint run in the security-libs area.
>> 
>> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Codereview Comment

Looks fine.

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

Marked as reviewed by darcy (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2856

From amenkov at openjdk.java.net  Tue Mar  9 01:36:21 2021
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Tue, 9 Mar 2021 01:36:21 GMT
Subject: RFR: 8262001:
 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java failed with
 "RuntimeException: Current Peak = 14 Expected to be == previous peak = 7 + 8"
Message-ID: <TZBFsiqKOxxbp-tN07-glyx947_eN6jTUEJlFWZcpik=.043c257d-d7ec-4df2-8504-1914e55e3975@github.com>

The fix updates ResetPeakThreadCount.java test - increases number of threads, but relaxes conditions so start/termination of system threads don't cause failures.
Additional changes:
- store threads in a list instead of array (we need only to start/terminate some number of threads, so linked list works better);
- flags for thread termination are moved to thread class;
- store values from ThreadMXBean.getPeakThreadCount() and getThreadCount() in int instead of long (the methods return int values)

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

Commit messages:
 - Update ResetPeakThreadCount.java

Changes: https://git.openjdk.java.net/jdk/pull/2885/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2885&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262001
  Stats: 139 lines in 1 file changed: 20 ins; 61 del; 58 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2885.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2885/head:pull/2885

PR: https://git.openjdk.java.net/jdk/pull/2885

From smarks at openjdk.java.net  Tue Mar  9 02:02:15 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 9 Mar 2021 02:02:15 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v2]
In-Reply-To: <DJdCpcG1ZMm84SIU1_CEIC5WYJDLz3RYSG4Ltb_TyXw=.3ef63e5c-fe0a-49f4-993d-75f7c08fb242@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
 <DJdCpcG1ZMm84SIU1_CEIC5WYJDLz3RYSG4Ltb_TyXw=.3ef63e5c-fe0a-49f4-993d-75f7c08fb242@github.com>
Message-ID: <_TUF_2SZLkcwHdwQfpQVXT7IP73XWVnvtMw_x76MhrU=.1f147eea-ace2-496b-afea-bfcaa97283b7@github.com>

On Sat, 6 Mar 2021 17:44:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
>> 
>> Once the text is agreed to; I'll update the copyright year as well.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improve linkage for isSynethetic.

src/java.base/share/classes/java/lang/reflect/Method.java line 593:

> 591:      * result. (While the Java language specification forbids a class
> 592:      * declaring two methods with the same parameter types but a
> 593:      * different return type, the virtual machine does not.)

I'm of two minds about this. This is certainly a good example of a bridge method. It doesn't motivate _why_ a bridge method is necessary in this case. It think it's because the language says you should be able to write code like
    EnumSet<E> es2 = es.clone();
so there needs to be a method defined in the class file whose return type is assignment-compatible  with `EnumSet`. However, a `clone` method that returns `Object` is the only one that can override the `Object::clone` method. Thus, a something is necessary to span this gap -- a bridge method.

On the other hand, this might be too much detail for here. This is a really obscure location. It seems like somewhere else would be better, and where a full explanation with examples can be provided.

src/java.base/share/classes/java/lang/reflect/Method.java line 597:

> 595:      * <p>Bridge methods may also be used by Java compiler in other
> 596:      * circumstances to span across difference in Java Language
> 597:      * semantics and JVM semantics.

If you decide to put less detail here, you could start with this statement. I think the main point is that there are some semantic gaps between methods in the Java language and in the JVM; bridge methods are necessary to "span" this gap. You might simply list some examples without explaining them fully.

Would this be "used by **a** Java compiler" or "used by **the** Java compiler?

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

PR: https://git.openjdk.java.net/jdk/pull/2852

From github.com+7806504+liach at openjdk.java.net  Tue Mar  9 03:11:07 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Tue, 9 Mar 2021 03:11:07 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v2]
In-Reply-To: <_TUF_2SZLkcwHdwQfpQVXT7IP73XWVnvtMw_x76MhrU=.1f147eea-ace2-496b-afea-bfcaa97283b7@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
 <DJdCpcG1ZMm84SIU1_CEIC5WYJDLz3RYSG4Ltb_TyXw=.3ef63e5c-fe0a-49f4-993d-75f7c08fb242@github.com>
 <_TUF_2SZLkcwHdwQfpQVXT7IP73XWVnvtMw_x76MhrU=.1f147eea-ace2-496b-afea-bfcaa97283b7@github.com>
Message-ID: <juChKs_tUnCMCyhM4rXYUMpvp_AwYZuTxmwPCuGZa34=.32295e80-2b4c-4c83-9cdf-b14bd67ed027@github.com>

On Tue, 9 Mar 2021 01:58:38 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Improve linkage for isSynethetic.
>
> src/java.base/share/classes/java/lang/reflect/Method.java line 597:
> 
>> 595:      * <p>Bridge methods may also be used by Java compiler in other
>> 596:      * circumstances to span across difference in Java Language
>> 597:      * semantics and JVM semantics.
> 
> If you decide to put less detail here, you could start with this statement. I think the main point is that there are some semantic gaps between methods in the Java language and in the JVM; bridge methods are necessary to "span" this gap. You might simply list some examples without explaining them fully.
> 
> Would this be "used by **a** Java compiler" or "used by **the** Java compiler?

Imo "created" should be better. Is there any case where a java compiler accepts bridge methods generated?

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

PR: https://git.openjdk.java.net/jdk/pull/2852

From darcy at openjdk.java.net  Tue Mar  9 03:27:29 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 9 Mar 2021 03:27:29 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v3]
In-Reply-To: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
Message-ID: <js5Bx__Ca_9YXhTHieXFkXj8bpKP-Ko8caOK6eWXp78=.440f373b-ad63-48f7-81a4-8d6161f7bf3a@github.com>

> The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
> 
> Once the text is agreed to; I'll update the copyright year as well.

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

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2852/files
  - new: https://git.openjdk.java.net/jdk/pull/2852/files/d3b7a3c3..44552784

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=01-02

  Stats: 20 lines in 1 file changed: 9 ins; 7 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2852.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2852/head:pull/2852

PR: https://git.openjdk.java.net/jdk/pull/2852

From joe.darcy at oracle.com  Tue Mar  9 03:41:37 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Mon, 8 Mar 2021 19:41:37 -0800
Subject: RFR: 8263102: Expand documention of Method.isBridge [v2]
In-Reply-To: <_TUF_2SZLkcwHdwQfpQVXT7IP73XWVnvtMw_x76MhrU=.1f147eea-ace2-496b-afea-bfcaa97283b7@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
 <DJdCpcG1ZMm84SIU1_CEIC5WYJDLz3RYSG4Ltb_TyXw=.3ef63e5c-fe0a-49f4-993d-75f7c08fb242@github.com>
 <_TUF_2SZLkcwHdwQfpQVXT7IP73XWVnvtMw_x76MhrU=.1f147eea-ace2-496b-afea-bfcaa97283b7@github.com>
Message-ID: <1d956bb8-f2df-2326-e321-33b031cb543c@oracle.com>

Hi Stuart,

On 3/8/2021 6:02 PM, Stuart Marks wrote:
> On Sat, 6 Mar 2021 17:44:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>>> The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
>>>
>>> Once the text is agreed to; I'll update the copyright year as well.
>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>>
>>    Improve linkage for isSynethetic.
> src/java.base/share/classes/java/lang/reflect/Method.java line 593:
>
>> 591:      * result. (While the Java language specification forbids a class
>> 592:      * declaring two methods with the same parameter types but a
>> 593:      * different return type, the virtual machine does not.)
> I'm of two minds about this. This is certainly a good example of a bridge method. It doesn't motivate _why_ a bridge method is necessary in this case. It think it's because the language says you should be able to write code like
>      EnumSet<E> es2 = es.clone();
> so there needs to be a method defined in the class file whose return type is assignment-compatible  with `EnumSet`. However, a `clone` method that returns `Object` is the only one that can override the `Object::clone` method. Thus, a something is necessary to span this gap -- a bridge method.
>
> On the other hand, this might be too much detail for here. This is a really obscure location. It seems like somewhere else would be better, and where a full explanation with examples can be provided.


If someone is looking at isBridge and wondering what it does, having 
some discussion there some reasonable :-)

The text in question is not intended to be exhaustive and the exact use 
of bridge methods can, in principle, be Java compiler dependent.

Also, if in the future there are new JVM/platform facilities added so 
that bridge methods are not necessarily required for the cases where 
they are now used, I intended to write this text so it would still be 
correct.

Thanks,

-Joe


From github.com+828220+forax at openjdk.java.net  Tue Mar  9 07:23:07 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 9 Mar 2021 07:23:07 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v3]
In-Reply-To: <js5Bx__Ca_9YXhTHieXFkXj8bpKP-Ko8caOK6eWXp78=.440f373b-ad63-48f7-81a4-8d6161f7bf3a@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
 <js5Bx__Ca_9YXhTHieXFkXj8bpKP-Ko8caOK6eWXp78=.440f373b-ad63-48f7-81a4-8d6161f7bf3a@github.com>
Message-ID: <E18VrAU5VSA-aWeB2Go8VCzyh-REW9IqMYm418-1PeQ=.2b28078a-0332-4d7e-8f46-4819b3724bd1@github.com>

On Tue, 9 Mar 2021 03:27:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
>> 
>> Once the text is agreed to; I'll update the copyright year as well.
>
> 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/reflect/Method.java line 589:

> 587:      * different return type, the virtual machine does not.
> 588:      * A
> 589:      * common case where covariant overrides are used is for a {@link

I think the example should be clearer because here, you don't show the code of EnumSet.clone().
I wonder if it's not easier if all the code is visible
  interface I {
    Object m();
  }
  class A implements I {
    String m() { return "hello"; }
  }
so you can explain that the VM do the dispatch on I::m()Object so the compiler has to insert a method A::m()Object,
the bridge method with this pseudo-code
  class A implements I {
    /* bridge */ Object m() { return m(); } // calls m()String
    String m()  { return "hello"; }
  }

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

PR: https://git.openjdk.java.net/jdk/pull/2852

From almatvee at openjdk.java.net  Tue Mar  9 07:51:06 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 9 Mar 2021 07:51:06 GMT
Subject: RFR: JDK-8248904: Add support to jpackage for the Mac App Store
In-Reply-To: <Mr21WO6EZtgspQn31renDqAMna0HsTL8dlsnzPbnvas=.ad65953e-853f-454d-9689-a15d1a6a992e@github.com>
References: <Mr21WO6EZtgspQn31renDqAMna0HsTL8dlsnzPbnvas=.ad65953e-853f-454d-9689-a15d1a6a992e@github.com>
Message-ID: <MG2y_EDkNUCSulgWc0_OFEVA42aIvA-oAnJglBkhIh8=.ff5a499e-5372-4565-afcf-cfe3661c7c87@github.com>

On Wed, 24 Feb 2021 21:59:22 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Implementation of Mac App Support including three new mac specific CLI options.

Marked as reviewed by almatvee (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2716

From psadhukhan at openjdk.java.net  Tue Mar  9 08:43:13 2021
From: psadhukhan at openjdk.java.net (Prasanta Sadhukhan)
Date: Tue, 9 Mar 2021 08:43:13 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v5]
In-Reply-To: <EhUg_gwzyqIZ3IAPbWqm_s1yOyIW_I9oK_B1yKnqmm8=.a5cf7361-85d2-4656-9f70-6bcd06030bf3@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <EhUg_gwzyqIZ3IAPbWqm_s1yOyIW_I9oK_B1yKnqmm8=.a5cf7361-85d2-4656-9f70-6bcd06030bf3@github.com>
Message-ID: <lGB98jhhteSkUm91H1IdjbrJC2kpcPIDnkZsjPVvAdw=.ee6a5e7b-f3f4-4c9e-a382-2e760c836fc1@github.com>

On Sat, 6 Mar 2021 01:35:28 GMT, Craig Andrews <github.com+194713+candrews at openjdk.org> wrote:

>> `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.
>> 
>> According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.
>> 
>> Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>>> Returns:
>>>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.
>> 
>> And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>>> Returns:
>>>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.
>> 
>> Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.
>> 
>> Here's a stack trace:
>> java.lang.IllegalArgumentException: name
>>         at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>>         at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>>         at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
>> 
>> Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>>         URL findResource(final String name, boolean check) {
>>             URL url;
>>             try {
>>                 url = new URL(base, ParseUtil.encodePath(name, false));
>>             } catch (MalformedURLException e) {
>>                 throw new IllegalArgumentException("name");
>>             }
>> 
>> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
>> 
>> A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>>         URL findResource(final String name, boolean check) {
>>             URL url;
>>             try {
>>                 url = new URL(base, ParseUtil.encodePath(name, false));
>>             } catch (MalformedURLException e) {
>>                 throw new IllegalArgumentException("name");
>>             }
>> 
>> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
>
> Craig Andrews has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
> 
>   JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException

Marked as reviewed by psadhukhan (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From dfuchs at openjdk.java.net  Tue Mar  9 10:15:07 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 9 Mar 2021 10:15:07 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v2]
In-Reply-To: <l_JSWYHwNTvKCTPRBF1vrsUiYKJzawtb_2j07-uwbI8=.e2cc1d68-2d15-4c35-a2a5-25aadf24067c@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
 <l_JSWYHwNTvKCTPRBF1vrsUiYKJzawtb_2j07-uwbI8=.e2cc1d68-2d15-4c35-a2a5-25aadf24067c@github.com>
Message-ID: <t9RDEPIMR-49VwaB6rBuTo-RG5dI_Pk8zx6d0d8uL-Q=.f2eb1989-2a5c-4ca4-841a-7fbbb737f346@github.com>

On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Fix various things pointed out by the most recent doclint run in the security-libs area.
>> 
>> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Codereview Comment

I have recently gone through a similar exercise with `java.net`: what you have here looks good to me!

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2856

From pconcannon at openjdk.java.net  Tue Mar  9 11:12:13 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 9 Mar 2021 11:12:13 GMT
Subject: Integrated: 8252399: Update mapMulti documentation to use type test
 pattern instead of instanceof once JEP 375 exits preview
In-Reply-To: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com>
References: <38HWD-SI3_eYWKhHr_shQZ-82mf8BJ8pnADmYs153ok=.a83dcb1c-cd04-44c1-bf1a-385438160b90@github.com>
Message-ID: <hjjBQsIWiLmi475RKuMJmpuC6jBL5uDDZmS0S9ZnJII=.9f1af936-2f24-4a79-953f-7801b8268d24@github.com>

On Fri, 12 Feb 2021 11:46:09 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my changeset for JDK-8252399: 'Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview' ?
> 
> This change updates the example code displayed in the API documentation for mapMulti to use the type test pattern introduced in [JEP375](https://openjdk.java.net/jeps/375).
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: fbe40e89
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fbe40e89
Stats:     80 lines in 2 files changed: 74 ins; 0 del; 6 mod

8252399: Update mapMulti documentation to use type test pattern instead of instanceof once JEP 375 exits preview

Reviewed-by: dfuchs, psandoz, smarks

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

PR: https://git.openjdk.java.net/jdk/pull/2544

From pconcannon at openjdk.java.net  Tue Mar  9 11:12:10 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Tue, 9 Mar 2021 11:12:10 GMT
Subject: Integrated: 8263190: Update java.io, java.math,
 and java.text to use instanceof pattern variable
In-Reply-To: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
References: <Loc4GhPY-4PGLAm-qbjwhnFVrgZXBWuh7WP1KCxpilk=.9f2de6e7-22a7-4123-9e75-4edabb2c4a4f@github.com>
Message-ID: <mzs3TTj_bmfuXGy-LDSvZWnq9UtWH4mSRsopRP5NTho=.07979890-0a63-4a16-94ea-018d268a03fb@github.com>

On Mon, 8 Mar 2021 18:48:30 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.io`, `java.math`, and `java.text` packages to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: 0f2402d0
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0f2402d0
Stats:     59 lines in 15 files changed: 0 ins; 27 del; 32 mod

8263190: Update java.io, java.math, and java.text to use instanceof pattern variable

Reviewed-by: lancea, bpb, darcy, naoto, iris, dfuchs, smarks, redestad

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

PR: https://git.openjdk.java.net/jdk/pull/2879

From galder at redhat.com  Tue Mar  9 12:15:21 2021
From: galder at redhat.com (Galder Zamarreno)
Date: Tue, 9 Mar 2021 13:15:21 +0100
Subject: Subtle differences in System.getenv() between Windows and Linux
Message-ID: <CAAcPREtH5AF8bFvqHT=T1LNtFgwt=ucfbwEeXAcuUiOyXYHkKw@mail.gmail.com>

Hi all,

One of my colleagues discovered an intriguing difference between Linux and
Windows, in the context of GraalVM native-image, when it comes to the
returned value for System.getenv().

On windows, the native test he's encountered that a test fails with:

> Error: No instances of java.lang.ProcessEnvironment are allowed in the
image heap as this class should be initialized at image runtime

This does not happen on Linux.

The reason it fails on Windows it's because on that env the System.getenv()
method returns a ProcessEnvironment type, which happens to extend HashMap
[1]. On linux though it returns a plain map [2].

Any reason for this divergence? Is it due to historic reasons? I wondered
whether the windows and linux version of this shouldn't be more akin.

Galder

[1]
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/windows/classes/java/lang/ProcessEnvironment.java#L69
[2]
https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/unix/classes/java/lang/ProcessEnvironment.java#L90

From jpai at openjdk.java.net  Tue Mar  9 13:54:21 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 9 Mar 2021 13:54:21 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
Message-ID: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>

Can I please get a review for this proposed patch for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8263108?

As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and `java.lang.constant.ConstantDescs` can end up in a classloading deadlock due to the nature of the code involved in their static blocks. A thread dump of one such deadlock (reproduced using the code attached to that issue) is as follows:

"Thread A" #14 prio=5 os_prio=31 cpu=101.45ms elapsed=8.30s tid=0x00007ff88e01ca00 nid=0x6003 in Object.wait()  [0x000070000a4c6000]
   java.lang.Thread.State: RUNNABLE
	at java.lang.constant.DynamicConstantDesc.<clinit>(java.base at 16-ea/DynamicConstantDesc.java:67)
	- waiting on the Class initialization monitor for java.lang.constant.ConstantDescs
	at Deadlock.threadA(Deadlock.java:14)
	at Deadlock$$Lambda$1/0x0000000800c00a08.run(Unknown Source)
	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)

"Thread B" #15 prio=5 os_prio=31 cpu=103.15ms elapsed=8.30s tid=0x00007ff88b936a00 nid=0x9b03 in Object.wait()  [0x000070000a5c9000]
   java.lang.Thread.State: RUNNABLE
	at java.lang.constant.ClassDesc.ofDescriptor(java.base at 16-ea/ClassDesc.java:145)
	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc
	at java.lang.constant.ConstantDescs.<clinit>(java.base at 16-ea/ConstantDescs.java:239)
	at Deadlock.threadB(Deadlock.java:24)
	at Deadlock$$Lambda$2/0x0000000800c00c28.run(Unknown Source)
	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)

The commit in this PR resolves that deadlock by moving the `canonicalMap` initialization in `DynamicConstantDesc`, from the static block, to a lazily initialized map, into the `tryCanonicalize` (private) method of the same class. That's the only method which uses this map.

The implementation in `tryCanonicalize` carefully ensures that the deadlock isn't shifted from the static block to this method, by making sure that the `synchronization` on `DynamicConstantDesc` in this method happens only when it's time to write the state to the shared `canonicalMap`. This has an implication that the method local variable `canonDescs` can get initialized by multiple threads unnecessarily but from what I can see, that's the only way we can avoid this deadlock. This penalty of multiple threads initializing and then throwing away that map isn't too huge because that will happen only once when the `canonicalMap` is being initialized for the first time.

An alternate approach that I thought of was to completely get rid of this shared cache `canonicalMap` and instead just use method level map (that gets initialized each time) in the `tryCanonicalize` method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.

The commit in this PR also includes a jtreg testcase which (consistently) reproduces the deadlock without the fix and passes when this fix is applied. Extra manual testing has been done to verify that the classes of interest (noted in that testcase) are indeed getting loaded in those concurrent threads and not in the main thread. For future maintainers, there's a implementation note added on that testcase explaining why it cannot be moved into testng test.

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

Commit messages:
 - 8263108: Class initialization deadlock in java.lang.constant

Changes: https://git.openjdk.java.net/jdk/pull/2893/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2893&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263108
  Stats: 170 lines in 2 files changed: 160 ins; 7 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2893/head:pull/2893

PR: https://git.openjdk.java.net/jdk/pull/2893

From jpai at openjdk.java.net  Tue Mar  9 13:54:21 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 9 Mar 2021 13:54:21 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
In-Reply-To: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
Message-ID: <8FChJZaYDtB3yD19IizUsKq1DbFrRUAJOmUY0YWgu9o=.a4607ed0-8446-4184-a3b8-76cbf665a8e1@github.com>

On Tue, 9 Mar 2021 13:46:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> An alternate approach that I thought of was to completely get rid of this shared cache canonicalMap and instead just use method level map (that gets initialized each time) in the tryCanonicalize method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.


The benchmark code:

package org.myapp;

import org.openjdk.jmh.annotations.*;
import java.lang.constant.*;
import java.util.concurrent.TimeUnit;

public class MyBenchmark {

	enum MyEnum {A, B}

    @Benchmark
    @BenchmarkMode(Mode.AverageTime)
    @OutputTimeUnit(TimeUnit.NANOSECONDS)
    @Threads(10)
    @Fork(3)
    public void dynamicConstantDesc_ofCanonical() {
        final ConstantDesc desc = DynamicConstantDesc.ofCanonical(ConstantDescs.BSM_ENUM_CONSTANT, "A",
                        ClassDesc.of("org.myapp.MyBenchmark").nested("MyEnum"), new ConstantDesc[0]);
    }

}

Benchmark results:

Current proposed patch in this PR:

Benchmark                                    Mode  Cnt     Score     Error  Units
MyBenchmark.dynamicConstantDesc_ofCanonical  avgt   15  2295.714 ? 228.951  ns/op

Alternate approach of _not_ using the `canonicalMap` and instead using method level map:

Benchmark                                    Mode  Cnt     Score     Error  Units
MyBenchmark.dynamicConstantDesc_ofCanonical  avgt   15  4220.446 ? 831.905  ns/op

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From roger.riggs at oracle.com  Tue Mar  9 15:42:43 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Tue, 9 Mar 2021 10:42:43 -0500
Subject: Subtle differences in System.getenv() between Windows and Linux
In-Reply-To: <CAAcPREtH5AF8bFvqHT=T1LNtFgwt=ucfbwEeXAcuUiOyXYHkKw@mail.gmail.com>
References: <CAAcPREtH5AF8bFvqHT=T1LNtFgwt=ucfbwEeXAcuUiOyXYHkKw@mail.gmail.com>
Message-ID: <c77aec55-5e4e-9834-0fbf-2c277b470899@oracle.com>

Hi,

The code in both versions of ProcessEnvironment is mostly pre-2007
seem to have the same original author.

It is the typical inheritance vs delegation choice and likely driven by 
the details
of what was being stored and the OS specific details that need to be 
processed.
For example, Linux is case-sensitive vs Windows case-insensitive
and the handling needed to read the environment from the OS and
generate the environment for process launch.

$.02, Roger


On 3/9/21 7:15 AM, Galder Zamarreno wrote:
> Hi all,
>
> One of my colleagues discovered an intriguing difference between Linux and
> Windows, in the context of GraalVM native-image, when it comes to the
> returned value for System.getenv().
>
> On windows, the native test he's encountered that a test fails with:
>
>> Error: No instances of java.lang.ProcessEnvironment are allowed in the
> image heap as this class should be initialized at image runtime
>
> This does not happen on Linux.
>
> The reason it fails on Windows it's because on that env the System.getenv()
> method returns a ProcessEnvironment type, which happens to extend HashMap
> [1]. On linux though it returns a plain map [2].
>
> Any reason for this divergence? Is it due to historic reasons? I wondered
> whether the windows and linux version of this shouldn't be more akin.
>
> Galder
>
> [1]
> https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/windows/classes/java/lang/ProcessEnvironment.java#L69
> [2]
> https://github.com/AdoptOpenJDK/openjdk-jdk11/blob/master/src/java.base/unix/classes/java/lang/ProcessEnvironment.java#L90


From mullan at openjdk.java.net  Tue Mar  9 16:10:17 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 9 Mar 2021 16:10:17 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v2]
In-Reply-To: <l_JSWYHwNTvKCTPRBF1vrsUiYKJzawtb_2j07-uwbI8=.e2cc1d68-2d15-4c35-a2a5-25aadf24067c@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
 <l_JSWYHwNTvKCTPRBF1vrsUiYKJzawtb_2j07-uwbI8=.e2cc1d68-2d15-4c35-a2a5-25aadf24067c@github.com>
Message-ID: <nLDODNa7y3gvVr6XGihdJIYCeHZQDb7f5Aqfs9wbDk4=.b3932a2e-e47a-441a-8154-f641528a4a26@github.com>

On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Fix various things pointed out by the most recent doclint run in the security-libs area.
>> 
>> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Codereview Comment

src/java.base/share/classes/java/security/CodeSigner.java line 170:

> 168:     /**
> 169:      * Restores the state of this object from the stream, and explicitly
> 170:      * reset hash code value to -1.

Change "reset" to "resets".

src/java.base/share/classes/java/security/Timestamp.java line 160:

> 158:     /**
> 159:      * Restores the state of this object from the stream, and explicitly
> 160:      * reset hash code value to -1

s/reset/resets, and add period at end of sentence.

src/java.base/share/classes/java/security/cert/Certificate.java line 71:

> 69:     private final String type;
> 70: 
> 71:     /** Cache the hash code for the certiticate. */

I would drop the word "Cache". Also typo: s/certiticate/certificate.

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

PR: https://git.openjdk.java.net/jdk/pull/2856

From akozlov at openjdk.java.net  Tue Mar  9 16:12:36 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 16:12:36 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:

 - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
 - workaround JDK-8262895 by disabling subtest
 - Fix typo
 - Rename threadWXSetters.hpp -> threadWXSetters.inline.hpp
 - JDK-8259937: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Fix after JDK-8259539, partially revert preconditions
 - JDK-8260471: bsd_aarch64 part
 - JDK-8259539: bsd_aarch64 part
 - JDK-8257828: bsd_aarch64 part
 - ... and 95 more: https://git.openjdk.java.net/jdk/compare/a6e34b3d...a72f6834

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

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=23
  Stats: 2873 lines in 73 files changed: 2787 ins; 27 del; 59 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Tue Mar  9 16:12:37 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 16:12:37 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
In-Reply-To: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
Message-ID: <yi2biGsqSXqJPSCRZcsTxv1vVOnSZiGvtBK96gl6u14=.80dd4aa2-e6d1-49aa-a95a-020203b6fce5@github.com>

On Tue, 9 Feb 2021 09:06:26 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update signal handler part for debugger
>
> src/hotspot/share/runtime/threadWXSetters.hpp line 28:
> 
>> 26: #define SHARE_RUNTIME_THREADWXSETTERS_HPP
>> 27: 
>> 28: #include "runtime/thread.inline.hpp"
> 
> This breaks against our convention to forbid inline.hpp files from being included from being included from .hpp files. You need to rework this by either moving the implementation to a .cpp file, or convert this file into an .inline.hpp
> 
> See the Source Files section in:
> https://htmlpreview.github.io/?https://github.com/openjdk/jdk/blob/master/doc/hotspot-style.html

Thanks, I renamed the file to threadWXSetters.inline.hpp

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From wetmore at openjdk.java.net  Tue Mar  9 16:29:10 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 9 Mar 2021 16:29:10 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v2]
In-Reply-To: <MBSL5-QUsO-KilFG5O5ChGYl0d9tU9K--mHwxWiQUGg=.29c0c517-a7ec-4b9c-ae0a-e52c0e5db707@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
 <l_JSWYHwNTvKCTPRBF1vrsUiYKJzawtb_2j07-uwbI8=.e2cc1d68-2d15-4c35-a2a5-25aadf24067c@github.com>
 <MBSL5-QUsO-KilFG5O5ChGYl0d9tU9K--mHwxWiQUGg=.29c0c517-a7ec-4b9c-ae0a-e52c0e5db707@github.com>
Message-ID: <84xf3jGiaFYFF4FKellEHL4XypTHf8fEB-xjWLJ4q44=.a5b07185-6c1e-44d1-8239-3123a6eb490c@github.com>

On Tue, 9 Mar 2021 16:10:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Codereview Comment
>
> src/java.base/share/classes/javax/crypto/SealedObject.java line 428:
> 
>> 426:      * @throws IOException if an I/O error occurs
>> 427:      * @throws ClassNotFoundException if a serialized class cannot be loaded
>> 428:      * @throws NullPointerException if s is null.
> 
> Remove period for consistency with other throws. Actually, you probably don't need to say that it throws NPE. I don't see that any other readObject method declares that, even if they do throw NPE if the stream is null. Seems like something that should just be assumed or does not happen under normal circumstances.

It did seem really strange to me.  I'll remove.

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

PR: https://git.openjdk.java.net/jdk/pull/2856

From mullan at openjdk.java.net  Tue Mar  9 16:29:09 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Tue, 9 Mar 2021 16:29:09 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v2]
In-Reply-To: <l_JSWYHwNTvKCTPRBF1vrsUiYKJzawtb_2j07-uwbI8=.e2cc1d68-2d15-4c35-a2a5-25aadf24067c@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
 <l_JSWYHwNTvKCTPRBF1vrsUiYKJzawtb_2j07-uwbI8=.e2cc1d68-2d15-4c35-a2a5-25aadf24067c@github.com>
Message-ID: <MBSL5-QUsO-KilFG5O5ChGYl0d9tU9K--mHwxWiQUGg=.29c0c517-a7ec-4b9c-ae0a-e52c0e5db707@github.com>

On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Fix various things pointed out by the most recent doclint run in the security-libs area.
>> 
>> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Codereview Comment

src/java.base/share/classes/javax/crypto/SealedObject.java line 428:

> 426:      * @throws IOException if an I/O error occurs
> 427:      * @throws ClassNotFoundException if a serialized class cannot be loaded
> 428:      * @throws NullPointerException if s is null.

Remove period for consistency with other throws. Actually, you probably don't need to say that it throws NPE. I don't see that any other readObject method declares that, even if they do throw NPE if the stream is null. Seems like something that should just be assumed or does not happen under normal circumstances.

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

PR: https://git.openjdk.java.net/jdk/pull/2856

From asemenyuk at openjdk.java.net  Tue Mar  9 16:50:40 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 9 Mar 2021 16:50:40 GMT
Subject: RFR: 8241716: Jpackage functionality to let users choose whether
 to create shortcuts [v2]
In-Reply-To: <Pt6oZISZR-tReWpxp2SHlIDJmcjH8oGMME216UPA8As=.18955590-8242-40fd-a04f-749a3bbef03b@github.com>
References: <Pt6oZISZR-tReWpxp2SHlIDJmcjH8oGMME216UPA8As=.18955590-8242-40fd-a04f-749a3bbef03b@github.com>
Message-ID: <Xg81pemYejOaAAE9EdHEt33ZG0zRzvC4is6nhYjzgAM=.c5b10914-a94e-4355-84a6-45f411048e70@github.com>

> Add support to insert dialog with prompts to create shortcuts in dialog installation sequence of Windows installers created by jpackage.
> As a side effect of the fix, UI-related WiX source code was moved from main.wxs into generated ui.wxf file. Users can override ui.wxf by placing a file with this name in resource directory.
> Custom dialogs optionally inserted in dialog installation sequence were placed in distinct WiX sources: InstallDirNotEmptyDlg.wxs and ShortcutPromptDlg.wxs. They can be overridden if files with the corresponding names as placed in resource directory.
> Moving source code of installer UI from main.wxs into ui.wxf, InstallDirNotEmptyDlg.wxs and ShortcutPromptDlg.wxs files supposed to simplify overriding of the default UI provided by jpackage.

Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - 8241716: Jpackage functionality to let users choose whether to create shortcuts
 - 8241716: Jpackage functionality to let users choose whether to create shortcuts

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

Changes: https://git.openjdk.java.net/jdk/pull/2882/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2882&range=01
  Stats: 3069 lines in 23 files changed: 2062 ins; 988 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2882.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2882/head:pull/2882

PR: https://git.openjdk.java.net/jdk/pull/2882

From akozlov at openjdk.java.net  Tue Mar  9 16:58:19 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 16:58:19 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
In-Reply-To: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
Message-ID: <z9mnfpAEpe9fRFn8A_rmjYx3nU1mzbRsCiMPWsLEKkU=.b7a08d2b-fc4b-42a6-aabb-2b008427ba2c@github.com>

On Tue, 9 Feb 2021 09:12:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update signal handler part for debugger
>
> src/hotspot/share/runtime/thread.hpp line 848:
> 
>> 846:   void init_wx();
>> 847:   WXMode enable_wx(WXMode new_state);
>> 848: #endif // __APPLE__ && AARCH64
> 
> Now that this is only compiled into macOS/AArch64, could this be moved over to thread_bsd_aarch64.hpp? The same goes for the associated functions.

The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block belongs to Thread for now. Since W^X is an attribute of any operating system thread, I assumed Thread to be the right place for W^X bookkeeping. 

In most cases, we manage W^X state of JavaThread. But sometimes a GC thread needs the WXWrite state, or safefetch is called from non-JavaThread. Probably this can be dealt with (e.g. GCThread to always have the WXWrite state). But such change would be much more than a simple refactoring and it would require a significant amount of testing. Ideally, I would like to investigate this as a follow-up change, or at least after other fixes to this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From plevart at openjdk.java.net  Tue Mar  9 17:53:05 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Tue, 9 Mar 2021 17:53:05 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
In-Reply-To: <8FChJZaYDtB3yD19IizUsKq1DbFrRUAJOmUY0YWgu9o=.a4607ed0-8446-4184-a3b8-76cbf665a8e1@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <8FChJZaYDtB3yD19IizUsKq1DbFrRUAJOmUY0YWgu9o=.a4607ed0-8446-4184-a3b8-76cbf665a8e1@github.com>
Message-ID: <YLSeYqUAZr2W1scXt-9A_WATjbdLKehY0SYsz2HMWts=.a4ea356c-4bbd-4edf-b81f-66c1657ac974@github.com>

On Tue, 9 Mar 2021 13:50:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed patch for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8263108?
>> 
>> As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and `java.lang.constant.ConstantDescs` can end up in a classloading deadlock due to the nature of the code involved in their static blocks. A thread dump of one such deadlock (reproduced using the code attached to that issue) is as follows:
>> 
>> "Thread A" #14 prio=5 os_prio=31 cpu=101.45ms elapsed=8.30s tid=0x00007ff88e01ca00 nid=0x6003 in Object.wait()  [0x000070000a4c6000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.DynamicConstantDesc.<clinit>(java.base at 16-ea/DynamicConstantDesc.java:67)
>> 	- waiting on the Class initialization monitor for java.lang.constant.ConstantDescs
>> 	at Deadlock.threadA(Deadlock.java:14)
>> 	at Deadlock$$Lambda$1/0x0000000800c00a08.run(Unknown Source)
>> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
>> 
>> "Thread B" #15 prio=5 os_prio=31 cpu=103.15ms elapsed=8.30s tid=0x00007ff88b936a00 nid=0x9b03 in Object.wait()  [0x000070000a5c9000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.ClassDesc.ofDescriptor(java.base at 16-ea/ClassDesc.java:145)
>> 	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc
>> 	at java.lang.constant.ConstantDescs.<clinit>(java.base at 16-ea/ConstantDescs.java:239)
>> 	at Deadlock.threadB(Deadlock.java:24)
>> 	at Deadlock$$Lambda$2/0x0000000800c00c28.run(Unknown Source)
>> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
>> 
>> The commit in this PR resolves that deadlock by moving the `canonicalMap` initialization in `DynamicConstantDesc`, from the static block, to a lazily initialized map, into the `tryCanonicalize` (private) method of the same class. That's the only method which uses this map.
>> 
>> The implementation in `tryCanonicalize` carefully ensures that the deadlock isn't shifted from the static block to this method, by making sure that the `synchronization` on `DynamicConstantDesc` in this method happens only when it's time to write the state to the shared `canonicalMap`. This has an implication that the method local variable `canonDescs` can get initialized by multiple threads unnecessarily but from what I can see, that's the only way we can avoid this deadlock. This penalty of multiple threads initializing and then throwing away that map isn't too huge because that will happen only once when the `canonicalMap` is being initialized for the first time.
>> 
>> An alternate approach that I thought of was to completely get rid of this shared cache `canonicalMap` and instead just use method level map (that gets initialized each time) in the `tryCanonicalize` method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.
>> 
>> The commit in this PR also includes a jtreg testcase which (consistently) reproduces the deadlock without the fix and passes when this fix is applied. Extra manual testing has been done to verify that the classes of interest (noted in that testcase) are indeed getting loaded in those concurrent threads and not in the main thread. For future maintainers, there's a implementation note added on that testcase explaining why it cannot be moved into testng test.
>
>> An alternate approach that I thought of was to completely get rid of this shared cache canonicalMap and instead just use method level map (that gets initialized each time) in the tryCanonicalize method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.
> 
> 
> The benchmark code:
> 
> package org.myapp;
> 
> import org.openjdk.jmh.annotations.*;
> import java.lang.constant.*;
> import java.util.concurrent.TimeUnit;
> 
> public class MyBenchmark {
> 
> 	enum MyEnum {A, B}
> 
>     @Benchmark
>     @BenchmarkMode(Mode.AverageTime)
>     @OutputTimeUnit(TimeUnit.NANOSECONDS)
>     @Threads(10)
>     @Fork(3)
>     public void dynamicConstantDesc_ofCanonical() {
>         final ConstantDesc desc = DynamicConstantDesc.ofCanonical(ConstantDescs.BSM_ENUM_CONSTANT, "A",
>                         ClassDesc.of("org.myapp.MyBenchmark").nested("MyEnum"), new ConstantDesc[0]);
>     }
> 
> }
> 
> Benchmark results:
> 
> Current proposed patch in this PR:
> 
> Benchmark                                    Mode  Cnt     Score     Error  Units
> MyBenchmark.dynamicConstantDesc_ofCanonical  avgt   15  2295.714 ? 228.951  ns/op
> 
> Alternate approach of _not_ using the `canonicalMap` and instead using method level map:
> 
> Benchmark                                    Mode  Cnt     Score     Error  Units
> MyBenchmark.dynamicConstantDesc_ofCanonical  avgt   15  4220.446 ? 831.905  ns/op

Hi Jaikiran,

Since the object assigned to cannonicalMap is an immutable Map created with `Map.ofEntries()` which is able to be safely published via data-race, the `cannonicalMap` field need not be volatile which could be more optimal on ARM. In that case you must avoid reading the field twice outside the synchronized block. So you could remove the volatile modifier from the field and do the following:

    private ConstantDesc tryCanonicalize() {
        var canonDescs = canonicalMap;
        if (canonDescs == null) {
            canonDescs = Map.ofEntries(...);
            synchronized (DynamicConstantDesc.class) {
                if (canonicalMap == null) {
                    canonicalMap = canonDescs;
                } else {
                    canonDescs = canonicalMap;
                }
            }
        }
        ... use canonDescs ...
    }


Peter

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From akozlov at openjdk.java.net  Tue Mar  9 17:58:21 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 17:58:21 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
In-Reply-To: <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
Message-ID: <Dze4ZtrPI_OLkuExMIN1fl5u6eCryLmgNRgAHzN2kXE=.eee71cb4-1c81-46f8-b6ae-063659a28fc2@github.com>

On Tue, 9 Feb 2021 09:23:50 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update signal handler part for debugger
>
> src/hotspot/share/runtime/thread.cpp line 2515:
> 
>> 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread *thread) {
>> 2514:   // Enable WXWrite: called directly from interpreter native wrapper.
>> 2515:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, thread));
> 
> FWIW, I personally think that adding these MACOS_AARCH64_ONLY usages at the call sites increase the line-noise in the affected functions. I think I would have preferred a version:
> ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) {
>   MACOS_AARCH64_ONLY(initialize(new_mode, thread);) {}
> void initialize(...); // Implementation in thread_bsd_aarch64.cpp (alt. inline.hpp)
> With that said, I'm fine with taking this discussion as a follow-up.

The former version used no such macros. I like that now it's clear the W^X management is relevant to macos/aarch64 only. I see the point to move the pre-processor condition into the class implementation. But I think it will bring a bit of inconsistency, as the rest of W^X implementation is explicitly guarded by preprocessor conditionals. I've also tried to push macro conditionals as far as possible down to implementation, providing a kind of generalized W^X interface. That required a few artificial decisions, e.g. how would we call the mode we execute on the rest of platforms with write and execute allowed, WXWriteExec?.. I abandoned that attempt.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Tue Mar  9 18:04:19 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 9 Mar 2021 18:04:19 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]
In-Reply-To: <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
 <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>
Message-ID: <v33sSQcIVsvidIkYzaOsIhkjNhojCVastBXuUJJ67IM=.9123e430-657f-4c24-a201-4f457232c983@github.com>

On Mon, 1 Mar 2021 10:31:19 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/jdk/jdk-macos' into jdk-macos
>>  - Minor fixes
>
> src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp line 62:
> 
>> 60: 
>> 61: #if defined(__APPLE__) || defined(_WIN64)
>> 62: #define R18_RESERVED
> 
> #define R18_RESERVED true```

We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From darcy at openjdk.java.net  Tue Mar  9 19:16:11 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 9 Mar 2021 19:16:11 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v3]
In-Reply-To: <E18VrAU5VSA-aWeB2Go8VCzyh-REW9IqMYm418-1PeQ=.2b28078a-0332-4d7e-8f46-4819b3724bd1@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
 <js5Bx__Ca_9YXhTHieXFkXj8bpKP-Ko8caOK6eWXp78=.440f373b-ad63-48f7-81a4-8d6161f7bf3a@github.com>
 <E18VrAU5VSA-aWeB2Go8VCzyh-REW9IqMYm418-1PeQ=.2b28078a-0332-4d7e-8f46-4819b3724bd1@github.com>
Message-ID: <osEUOdAP8nDeUzn_YoGEbI0TI9elZaDbS0kZuuwjhcc=.406bc4ef-c86e-4c74-a9bc-4d518d124659@github.com>

On Tue, 9 Mar 2021 07:19:27 GMT, R?mi Forax <github.com+828220+forax 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/reflect/Method.java line 589:
> 
>> 587:      * different return type, the virtual machine does not.
>> 588:      * A
>> 589:      * common case where covariant overrides are used is for a {@link
> 
> I think the example should be clearer because here, you don't show the code of EnumSet.clone().
> I wonder if it's not easier if all the code is visible
>   interface I {
>     Object m();
>   }
>   class A implements I {
>     String m() { return "hello"; }
>   }
> so you can explain that the VM do the dispatch on I::m()Object so the compiler has to insert a method A::m()Object,
> the bridge method with this pseudo-code
>   class A implements I {
>     /* bridge */ Object m() { return m(); } // calls m()String
>     String m()  { return "hello"; }
>   }

Hi Remi,

Thanks for the feedback. I did consider that kind of approach of an example from scratch. I judged referencing instances of bridge methods in the base module to be helpful to demonstrate it wasn't too esoteric of a feature in terms of it is something you, as a developer, may already have seen. Also, given the likely audience of the reading Class.isBridge, I didn't think a stand-alone example was warranted.

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

PR: https://git.openjdk.java.net/jdk/pull/2852

From smarks at openjdk.java.net  Tue Mar  9 19:54:12 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 9 Mar 2021 19:54:12 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v3]
In-Reply-To: <js5Bx__Ca_9YXhTHieXFkXj8bpKP-Ko8caOK6eWXp78=.440f373b-ad63-48f7-81a4-8d6161f7bf3a@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
 <js5Bx__Ca_9YXhTHieXFkXj8bpKP-Ko8caOK6eWXp78=.440f373b-ad63-48f7-81a4-8d6161f7bf3a@github.com>
Message-ID: <BFODLAiu26RI-Tr846WwndukJaLLaV5KOd_84RZhUE4=.8ae39f33-5d14-49e0-8ec4-12a41c7b664e@github.com>

On Tue, 9 Mar 2021 03:27:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
>> 
>> Once the text is agreed to; I'll update the copyright year as well.
>
> 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/reflect/Method.java line 579:

> 577:      * Bridge methods are used by Java compilers in various
> 578:      * circumstances to span across differences in Java programming
> 579:      * language semantics and JVM semantics.

Quibble: "span across" => "span"

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

PR: https://git.openjdk.java.net/jdk/pull/2852

From smarks at openjdk.java.net  Tue Mar  9 20:03:09 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 9 Mar 2021 20:03:09 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v3]
In-Reply-To: <js5Bx__Ca_9YXhTHieXFkXj8bpKP-Ko8caOK6eWXp78=.440f373b-ad63-48f7-81a4-8d6161f7bf3a@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
 <js5Bx__Ca_9YXhTHieXFkXj8bpKP-Ko8caOK6eWXp78=.440f373b-ad63-48f7-81a4-8d6161f7bf3a@github.com>
Message-ID: <SVW_ADlp5Z6SPCGKFsFcGOt2qzQevh-H8e22Ews6hZ8=.4f68e277-18ca-495d-96db-4f67f694fa32@github.com>

On Tue, 9 Mar 2021 03:27:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
>> 
>> Once the text is agreed to; I'll update the copyright year as well.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Marked as reviewed by smarks (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2852

From smarks at openjdk.java.net  Tue Mar  9 20:03:09 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 9 Mar 2021 20:03:09 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v3]
In-Reply-To: <osEUOdAP8nDeUzn_YoGEbI0TI9elZaDbS0kZuuwjhcc=.406bc4ef-c86e-4c74-a9bc-4d518d124659@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
 <js5Bx__Ca_9YXhTHieXFkXj8bpKP-Ko8caOK6eWXp78=.440f373b-ad63-48f7-81a4-8d6161f7bf3a@github.com>
 <E18VrAU5VSA-aWeB2Go8VCzyh-REW9IqMYm418-1PeQ=.2b28078a-0332-4d7e-8f46-4819b3724bd1@github.com>
 <osEUOdAP8nDeUzn_YoGEbI0TI9elZaDbS0kZuuwjhcc=.406bc4ef-c86e-4c74-a9bc-4d518d124659@github.com>
Message-ID: <Wcb6cDumaYuJZPR4EH0uxCDIz_NYrNMlwywqoETZfTM=.94088790-8fbd-4421-8581-8c8643988384@github.com>

On Tue, 9 Mar 2021 19:13:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/Method.java line 589:
>> 
>>> 587:      * different return type, the virtual machine does not.
>>> 588:      * A
>>> 589:      * common case where covariant overrides are used is for a {@link
>> 
>> I think the example should be clearer because here, you don't show the code of EnumSet.clone().
>> I wonder if it's not easier if all the code is visible
>>   interface I {
>>     Object m();
>>   }
>>   class A implements I {
>>     String m() { return "hello"; }
>>   }
>> so you can explain that the VM do the dispatch on I::m()Object so the compiler has to insert a method A::m()Object,
>> the bridge method with this pseudo-code
>>   class A implements I {
>>     /* bridge */ Object m() { return m(); } // calls m()String
>>     String m()  { return "hello"; }
>>   }
>
> Hi Remi,
> 
> Thanks for the feedback. I did consider that kind of approach of an example from scratch. I judged referencing instances of bridge methods in the base module to be helpful to demonstrate it wasn't too esoteric of a feature in terms of it is something you, as a developer, may already have seen. Also, given the likely audience of the reading Class.isBridge, I didn't think a stand-alone example was warranted.

The prose description here and is still rather clumsy, though. If you're going to use EnumSet.clone() as an example, maybe run with that and list the methods directly instead of saying "EnumSet.clone() returns EnumSet rather than Object", be more explicit. Maybe something like the following:

The Object class has the method:
 clone()```
whereas the EnumSet class has this method:
<E> clone()```
>From the JVM's perspective, the second method doesn't override the first, because they have different return types. The Java compiler provides a proper override by inserting the following bridge method into the EnumSet class:
 clone()```
that simply calls the second method and returns its result.

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

PR: https://git.openjdk.java.net/jdk/pull/2852

From rriggs at openjdk.java.net  Tue Mar  9 21:44:25 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 9 Mar 2021 21:44:25 GMT
Subject: RFR: 8263320: [test] Add Object Stream Formatter to work with test
 utility HexPrinter
Message-ID: <3CZ34ALomv7XCnqx3b0DMXIrH0-cg8efhrNU8HRfBJg=.6710d795-1ee0-4f02-89f1-93d820389071@github.com>

ObjectStreamPrinter is a Formatter plugin to the test library HexPrinter.

A binary stream of serialized java objects is converted into a textual form by parsing the header, typecodes, and interpreting the stream contents. The formatter can be used standalone or with the HexPrinter to align the formatted stream with the corresponding hexadecimal bytes.

StreamDump is a test utility to pass the contents of a file to the HexPrinter utility. The format of the file is guessed from the encoding and initial bytes. ASN.1 and serialized object streams are supported.

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

Commit messages:
 - 8263320: [test] Add Object Stream Formatter to work with test utility HexPrinter

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

PR: https://git.openjdk.java.net/jdk/pull/2900

From rriggs at openjdk.java.net  Tue Mar  9 21:44:25 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 9 Mar 2021 21:44:25 GMT
Subject: RFR: 8263320: [test] Add Object Stream Formatter to work with
 test utility HexPrinter
In-Reply-To: <3CZ34ALomv7XCnqx3b0DMXIrH0-cg8efhrNU8HRfBJg=.6710d795-1ee0-4f02-89f1-93d820389071@github.com>
References: <3CZ34ALomv7XCnqx3b0DMXIrH0-cg8efhrNU8HRfBJg=.6710d795-1ee0-4f02-89f1-93d820389071@github.com>
Message-ID: <a4b6zgO2SyWtXw7QfsRP4xBkrs1IRvzkYQBjrTyoMj4=.9cb210f9-5abe-4841-b629-6503c555dc7a@github.com>

On Tue, 9 Mar 2021 21:37:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> ObjectStreamPrinter is a Formatter plugin to the test library HexPrinter.
> 
> A binary stream of serialized java objects is converted into a textual form by parsing the header, typecodes, and interpreting the stream contents. The formatter can be used standalone or with the HexPrinter to align the formatted stream with the corresponding hexadecimal bytes.
> 
> StreamDump is a test utility to pass the contents of a file to the HexPrinter utility. The format of the file is guessed from the encoding and initial bytes. ASN.1 and serialized object streams are supported.

The idea is to provide a fairly literal interpretation of the stream contents with annotations to make it easy to read and understand the nesting, object handle assignments, internal references, class descriptors, and block data usage.

A Hashmap with three key/value pairs is formatted:
    Map<String, String> map = new HashMap<>();
    map.put("1", "One");
    map.put("2", "Two");
    map.put("2.2", "Two");

0000: ac ed 00 05                                      // ObjectStream Version: 5
0004:             73 72 00 11 6a 61 76 61 2e 75 74 69  // READ CLASSDESC #0 java.util.HashMap
0010: 6c 2e 48 61 73 68 4d 61 70                       // 
0019:                            05 07 da c1 c3 16 60  //   svid: 362498820763181265L
0020: d1                                               // 
0021:    03                                            //   flags: WRITE_OBJECT, SERIALIZABLE
0022:       00 02                                      //   2 field(s) {
0024:             46 00 0a 6c 6f 61 64 46 61 63 74 6f  //     F loadFactor float; 
0030: 72                                               // 
0031:    49 00 09 74 68 72 65 73 68 6f 6c 64           //     I threshold int; 
003d:                                        78        //   } ENDBLOCK; 
003e:                                           70     //   Super: NULL; 
003f:                                                  // OBJ #1 java.util.HashMap 
003f:                                              3f  //   loadFactor:0.75 
0040: 40 00 00                                         // 
0043:          00 00 00 0c                             //   threshold:12 
0047:                                                  //   CustomData: 
0047:                      77 08 00 00 00 10 00 00 00  //     BLOCKDATA 8[ ........]; 
0050: 03                                               // 
0051:    74 00 01 31                                   //     STRING #2 "1" 
0055:                74 00 03 4f 6e 65                 //     STRING #3 "One" 
005b:                                  74 00 01 32     //     STRING #4 "2" 
005f:                                              74  //     STRING #5 "Two" 
0060: 00 03 54 77 6f                                   // 
0065:                74 00 03 32 2e 32                 //     STRING #6 "2.2" 
006b:                                  71 00 7e 00 05  //     REF #5 Two 
0070: 78                                               //     ENDBLOCK; 

The tests include a number of other examples.

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

PR: https://git.openjdk.java.net/jdk/pull/2900

From wetmore at openjdk.java.net  Tue Mar  9 22:19:28 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Tue, 9 Mar 2021 22:19:28 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v3]
In-Reply-To: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
Message-ID: <x6xplg1t8b0m7I_91vuDcYX6kTzQN4DpdVpiH5buNKA=.8d34a58d-274f-4c71-940a-e441cc7ced75@github.com>

> Fix various things pointed out by the most recent doclint run in the security-libs area.
> 
> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.

Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:

  More Codereview Comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2856/files
  - new: https://git.openjdk.java.net/jdk/pull/2856/files/1fa29ea6..ed0cf2ba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2856&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2856&range=01-02

  Stats: 52 lines in 8 files changed: 0 ins; 42 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2856.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2856/head:pull/2856

PR: https://git.openjdk.java.net/jdk/pull/2856

From joe.darcy at oracle.com  Tue Mar  9 22:33:39 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 9 Mar 2021 14:33:39 -0800
Subject: RFR: 8263102: Expand documention of Method.isBridge [v3]
In-Reply-To: <Wcb6cDumaYuJZPR4EH0uxCDIz_NYrNMlwywqoETZfTM=.94088790-8fbd-4421-8581-8c8643988384@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
 <js5Bx__Ca_9YXhTHieXFkXj8bpKP-Ko8caOK6eWXp78=.440f373b-ad63-48f7-81a4-8d6161f7bf3a@github.com>
 <E18VrAU5VSA-aWeB2Go8VCzyh-REW9IqMYm418-1PeQ=.2b28078a-0332-4d7e-8f46-4819b3724bd1@github.com>
 <osEUOdAP8nDeUzn_YoGEbI0TI9elZaDbS0kZuuwjhcc=.406bc4ef-c86e-4c74-a9bc-4d518d124659@github.com>
 <Wcb6cDumaYuJZPR4EH0uxCDIz_NYrNMlwywqoETZfTM=.94088790-8fbd-4421-8581-8c8643988384@github.com>
Message-ID: <f0cfc301-cdaf-b3cc-078b-606a9ddc1022@oracle.com>

On 3/9/2021 12:03 PM, Stuart Marks wrote:
> On Tue, 9 Mar 2021 19:13:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>>> src/java.base/share/classes/java/lang/reflect/Method.java line 589:
>>>
>>>> 587:      * different return type, the virtual machine does not.
>>>> 588:      * A
>>>> 589:      * common case where covariant overrides are used is for a {@link
>>> I think the example should be clearer because here, you don't show the code of EnumSet.clone().
>>> I wonder if it's not easier if all the code is visible
>>>    interface I {
>>>      Object m();
>>>    }
>>>    class A implements I {
>>>      String m() { return "hello"; }
>>>    }
>>> so you can explain that the VM do the dispatch on I::m()Object so the compiler has to insert a method A::m()Object,
>>> the bridge method with this pseudo-code
>>>    class A implements I {
>>>      /* bridge */ Object m() { return m(); } // calls m()String
>>>      String m()  { return "hello"; }
>>>    }
>> Hi Remi,
>>
>> Thanks for the feedback. I did consider that kind of approach of an example from scratch. I judged referencing instances of bridge methods in the base module to be helpful to demonstrate it wasn't too esoteric of a feature in terms of it is something you, as a developer, may already have seen. Also, given the likely audience of the reading Class.isBridge, I didn't think a stand-alone example was warranted.
> The prose description here and is still rather clumsy, though. If you're going to use EnumSet.clone() as an example, maybe run with that and list the methods directly instead of saying "EnumSet.clone() returns EnumSet rather than Object", be more explicit. Maybe something like the following:
>
> The Object class has the method:
>   clone()```
> whereas the EnumSet class has this method:
> <E> clone()```
>  From the JVM's perspective, the second method doesn't override the first, because they have different return types. The Java compiler provides a proper override by inserting the following bridge method into the EnumSet class:
>   clone()```
> that simply calls the second method and returns its result.

Pushed a refinement along those lines; new text:

A bridge method is a synthetic method created by a Java compiler 
alongside a method originating from the source code. Bridge methods are 
used by Java compilers in various circumstances to span differences in 
Java programming language semantics and JVM semantics. One example use 
of bridge methods is as technique for a Java compiler to support 
covariant overrides, where a subclass overrides a method and gives the 
new method a more specific return type than the method in the 
superclass. While the Java language specification forbids a class 
declaring two methods with the same parameter types but a different 
return type, the virtual machine does not. A common case where covariant 
overrides are used is for a Cloneable class where the clone method 
inherited from java.lang.Object is overridden and declared to return the 
type of the class. For example, Object declares
protected Object clone() throws CloneNotSupportedException {...}
and EnumSet<E> declares its language-level covariant override
public EnumSet<E> clone() {...}
If this technique was being used, the resulting class file for EnumSet 
would have two clone methods, one returning EnumSet<E> and the second a 
bridge method returning Object. The bridge method is a JVM-level 
override of Object.clone(). The body of the clone bridge method calls 
its non-bridge counterpart and returns its result.

-Joe


From darcy at openjdk.java.net  Tue Mar  9 22:35:19 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 9 Mar 2021 22:35:19 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v4]
In-Reply-To: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
Message-ID: <H0zfVH4W2Q8anl44wxmj2HMEYakFypu7N-SfTplJE8Y=.2e9b5496-29b4-4042-92e8-5d69f9559175@github.com>

> The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
> 
> Once the text is agreed to; I'll update the copyright year as well.

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

  Respond to review feedback.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2852/files
  - new: https://git.openjdk.java.net/jdk/pull/2852/files/44552784..7c8397e4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=02-03

  Stats: 11 lines in 1 file changed: 3 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2852.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2852/head:pull/2852

PR: https://git.openjdk.java.net/jdk/pull/2852

From bpb at openjdk.java.net  Tue Mar  9 22:55:08 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 9 Mar 2021 22:55:08 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v4]
In-Reply-To: <H0zfVH4W2Q8anl44wxmj2HMEYakFypu7N-SfTplJE8Y=.2e9b5496-29b4-4042-92e8-5d69f9559175@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
 <H0zfVH4W2Q8anl44wxmj2HMEYakFypu7N-SfTplJE8Y=.2e9b5496-29b4-4042-92e8-5d69f9559175@github.com>
Message-ID: <8db63AMrsP9uJbplyx3QlcFwNSxOPQXw4MNMXMSyN80=.fd6f5503-fdae-4541-9c01-fd0a976cdc3b@github.com>

On Tue, 9 Mar 2021 22:35:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
>> 
>> Once the text is agreed to; I'll update the copyright year as well.
>
> 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/reflect/Method.java line 581:

> 579:      * language semantics and JVM semantics.
> 580:      *
> 581:      * One example use of bridge methods is as technique for a

"a technique"

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

PR: https://git.openjdk.java.net/jdk/pull/2852

From github.com+828220+forax at openjdk.java.net  Tue Mar  9 23:14:07 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 9 Mar 2021 23:14:07 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v3]
In-Reply-To: <osEUOdAP8nDeUzn_YoGEbI0TI9elZaDbS0kZuuwjhcc=.406bc4ef-c86e-4c74-a9bc-4d518d124659@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
 <js5Bx__Ca_9YXhTHieXFkXj8bpKP-Ko8caOK6eWXp78=.440f373b-ad63-48f7-81a4-8d6161f7bf3a@github.com>
 <E18VrAU5VSA-aWeB2Go8VCzyh-REW9IqMYm418-1PeQ=.2b28078a-0332-4d7e-8f46-4819b3724bd1@github.com>
 <osEUOdAP8nDeUzn_YoGEbI0TI9elZaDbS0kZuuwjhcc=.406bc4ef-c86e-4c74-a9bc-4d518d124659@github.com>
Message-ID: <iE1VYwimoCkJ0sON_Cz8T4tTVNzqjA0cMOpsUZIlrc8=.7183d574-2047-42a3-9cdf-4591ef5beebb@github.com>

On Tue, 9 Mar 2021 19:13:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/Method.java line 589:
>> 
>>> 587:      * different return type, the virtual machine does not.
>>> 588:      * A
>>> 589:      * common case where covariant overrides are used is for a {@link
>> 
>> I think the example should be clearer because here, you don't show the code of EnumSet.clone().
>> I wonder if it's not easier if all the code is visible
>>   interface I {
>>     Object m();
>>   }
>>   class A implements I {
>>     String m() { return "hello"; }
>>   }
>> so you can explain that the VM do the dispatch on I::m()Object so the compiler has to insert a method A::m()Object,
>> the bridge method with this pseudo-code
>>   class A implements I {
>>     /* bridge */ Object m() { return m(); } // calls m()String
>>     String m()  { return "hello"; }
>>   }
>
> Hi Remi,
> 
> Thanks for the feedback. I did consider that kind of approach of an example from scratch. I judged referencing instances of bridge methods in the base module to be helpful to demonstrate it wasn't too esoteric of a feature in terms of it is something you, as a developer, may already have seen. Also, given the likely audience of the reading Class.isBridge, I didn't think a stand-alone example was warranted.

@jddarcy, the problem i see is that `EnumSet` is not used a lot and `clone` has another layer of complexity because of CloneNotSupportedException, etc.
So i'm not sure that using EnumSet.clone() is the right example here.

Perhaps String.compareTo()/Comparable.compareTo() is a better example ? But generics are in the middle too.

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

PR: https://git.openjdk.java.net/jdk/pull/2852

From bchristi at openjdk.java.net  Tue Mar  9 23:35:05 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 9 Mar 2021 23:35:05 GMT
Subject: RFR: 8262351: Extra '0' in java.util.Formatter for '%012a'
 conversion with a sign character
In-Reply-To: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
References: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
Message-ID: <vuiE9zNZYhOPaxBhLo1DbKxGEjS0RzuT3LjjBHvprhI=.79c4eaa7-afc8-4a52-93cf-8191861173f5@github.com>

On Mon, 8 Mar 2021 21:25:32 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This fixes a zero-adding issue observed in the hex float conversion.

This all looks fine - just update the copyright year in Formatter.java, please.

In my personal opinion, this behavior change does not rise to the level of needing a CSR, but since it is long-standing behavior, you might double-check with Joe.

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

Changes requested by bchristi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2881

From darcy at openjdk.java.net  Tue Mar  9 23:38:26 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 9 Mar 2021 23:38:26 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v5]
In-Reply-To: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
Message-ID: <mG_JhPxDFqmao8hGxwgDr2tSPdXyEaa_Ri8MoYCgcCg=.f29e01c9-9382-4c83-87d3-22885b14c451@github.com>

> The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
> 
> Once the text is agreed to; I'll update the copyright year as well.

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

  Fix typo noted by bpb.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2852/files
  - new: https://git.openjdk.java.net/jdk/pull/2852/files/7c8397e4..0425a2f3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/2852

From smarks at openjdk.java.net  Wed Mar 10 00:18:07 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 10 Mar 2021 00:18:07 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v5]
In-Reply-To: <mG_JhPxDFqmao8hGxwgDr2tSPdXyEaa_Ri8MoYCgcCg=.f29e01c9-9382-4c83-87d3-22885b14c451@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
 <mG_JhPxDFqmao8hGxwgDr2tSPdXyEaa_Ri8MoYCgcCg=.f29e01c9-9382-4c83-87d3-22885b14c451@github.com>
Message-ID: <p6YLKaFcuS1CeEWPehuC3QD9oiKK5uFjy3W-yCMWujc=.db81c3bf-efa3-4883-a864-9cb442c283d7@github.com>

On Tue, 9 Mar 2021 23:38:26 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
>> 
>> Once the text is agreed to; I'll update the copyright year as well.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo noted by bpb.

OK just a couple markup comments, otherwise good.

src/java.base/share/classes/java/lang/reflect/Method.java line 597:

> 595:      * and {@code EnumSet<E>} declares its language-level {@linkplain java.util.EnumSet#clone() covariant override}<br>
> 596:      * {@code public EnumSet<E> clone() {...}}<br>
> 597:      * If this technique was being used, the resulting class

Not sure what the preferred code block markup style is here; maybe `<pre>{@code ...}</pre>` instead of `<br>`.

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

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2852

From smarks at openjdk.java.net  Wed Mar 10 00:18:09 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 10 Mar 2021 00:18:09 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v3]
In-Reply-To: <BFODLAiu26RI-Tr846WwndukJaLLaV5KOd_84RZhUE4=.8ae39f33-5d14-49e0-8ec4-12a41c7b664e@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
 <js5Bx__Ca_9YXhTHieXFkXj8bpKP-Ko8caOK6eWXp78=.440f373b-ad63-48f7-81a4-8d6161f7bf3a@github.com>
 <BFODLAiu26RI-Tr846WwndukJaLLaV5KOd_84RZhUE4=.8ae39f33-5d14-49e0-8ec4-12a41c7b664e@github.com>
Message-ID: <mix-VYXVDUoraGEbiWhNZCRu-2a332i7whXe3RXiDC8=.c1d20819-b745-4d3e-a1e9-e06bb19d1f9f@github.com>

On Tue, 9 Mar 2021 19:51:42 GMT, Stuart Marks <smarks 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/reflect/Method.java line 579:
> 
>> 577:      * Bridge methods are used by Java compilers in various
>> 578:      * circumstances to span across differences in Java programming
>> 579:      * language semantics and JVM semantics.
> 
> Quibble: "span across" => "span"

Oh, also maybe need a <p> tag here.

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

PR: https://git.openjdk.java.net/jdk/pull/2852

From jpai at openjdk.java.net  Wed Mar 10 02:15:28 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 10 Mar 2021 02:15:28 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v2]
In-Reply-To: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
Message-ID: <8601DNFkEWL76jjuZpNosikeT-1L6fsoz9yf5B79uoU=.bfb92ddd-63d8-44b3-84b6-c73413ab342f@github.com>

> Can I please get a review for this proposed patch for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8263108?
> 
> As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and `java.lang.constant.ConstantDescs` can end up in a classloading deadlock due to the nature of the code involved in their static blocks. A thread dump of one such deadlock (reproduced using the code attached to that issue) is as follows:
> 
> "Thread A" #14 prio=5 os_prio=31 cpu=101.45ms elapsed=8.30s tid=0x00007ff88e01ca00 nid=0x6003 in Object.wait()  [0x000070000a4c6000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.constant.DynamicConstantDesc.<clinit>(java.base at 16-ea/DynamicConstantDesc.java:67)
> 	- waiting on the Class initialization monitor for java.lang.constant.ConstantDescs
> 	at Deadlock.threadA(Deadlock.java:14)
> 	at Deadlock$$Lambda$1/0x0000000800c00a08.run(Unknown Source)
> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
> 
> "Thread B" #15 prio=5 os_prio=31 cpu=103.15ms elapsed=8.30s tid=0x00007ff88b936a00 nid=0x9b03 in Object.wait()  [0x000070000a5c9000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.constant.ClassDesc.ofDescriptor(java.base at 16-ea/ClassDesc.java:145)
> 	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc
> 	at java.lang.constant.ConstantDescs.<clinit>(java.base at 16-ea/ConstantDescs.java:239)
> 	at Deadlock.threadB(Deadlock.java:24)
> 	at Deadlock$$Lambda$2/0x0000000800c00c28.run(Unknown Source)
> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
> 
> The commit in this PR resolves that deadlock by moving the `canonicalMap` initialization in `DynamicConstantDesc`, from the static block, to a lazily initialized map, into the `tryCanonicalize` (private) method of the same class. That's the only method which uses this map.
> 
> The implementation in `tryCanonicalize` carefully ensures that the deadlock isn't shifted from the static block to this method, by making sure that the `synchronization` on `DynamicConstantDesc` in this method happens only when it's time to write the state to the shared `canonicalMap`. This has an implication that the method local variable `canonDescs` can get initialized by multiple threads unnecessarily but from what I can see, that's the only way we can avoid this deadlock. This penalty of multiple threads initializing and then throwing away that map isn't too huge because that will happen only once when the `canonicalMap` is being initialized for the first time.
> 
> An alternate approach that I thought of was to completely get rid of this shared cache `canonicalMap` and instead just use method level map (that gets initialized each time) in the `tryCanonicalize` method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.
> 
> The commit in this PR also includes a jtreg testcase which (consistently) reproduces the deadlock without the fix and passes when this fix is applied. Extra manual testing has been done to verify that the classes of interest (noted in that testcase) are indeed getting loaded in those concurrent threads and not in the main thread. For future maintainers, there's a implementation note added on that testcase explaining why it cannot be moved into testng test.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Follow Peter Levart's review suggestion - remove volatile

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2893/files
  - new: https://git.openjdk.java.net/jdk/pull/2893/files/153139bc..1b59dc14

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2893&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2893&range=00-01

  Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2893/head:pull/2893

PR: https://git.openjdk.java.net/jdk/pull/2893

From jpai at openjdk.java.net  Wed Mar 10 02:15:28 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 10 Mar 2021 02:15:28 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
In-Reply-To: <YLSeYqUAZr2W1scXt-9A_WATjbdLKehY0SYsz2HMWts=.a4ea356c-4bbd-4edf-b81f-66c1657ac974@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <8FChJZaYDtB3yD19IizUsKq1DbFrRUAJOmUY0YWgu9o=.a4607ed0-8446-4184-a3b8-76cbf665a8e1@github.com>
 <YLSeYqUAZr2W1scXt-9A_WATjbdLKehY0SYsz2HMWts=.a4ea356c-4bbd-4edf-b81f-66c1657ac974@github.com>
Message-ID: <V6B3Z9xujK27EIeRDz17AN3yI0A2JNWfy7fv7OBM_H0=.9e934cb6-e269-4968-928b-3bd2cdf99ec9@github.com>

On Tue, 9 Mar 2021 17:50:26 GMT, Peter Levart <plevart at openjdk.org> wrote:

>>> An alternate approach that I thought of was to completely get rid of this shared cache canonicalMap and instead just use method level map (that gets initialized each time) in the tryCanonicalize method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.
>> 
>> 
>> The benchmark code:
>> 
>> package org.myapp;
>> 
>> import org.openjdk.jmh.annotations.*;
>> import java.lang.constant.*;
>> import java.util.concurrent.TimeUnit;
>> 
>> public class MyBenchmark {
>> 
>> 	enum MyEnum {A, B}
>> 
>>     @Benchmark
>>     @BenchmarkMode(Mode.AverageTime)
>>     @OutputTimeUnit(TimeUnit.NANOSECONDS)
>>     @Threads(10)
>>     @Fork(3)
>>     public void dynamicConstantDesc_ofCanonical() {
>>         final ConstantDesc desc = DynamicConstantDesc.ofCanonical(ConstantDescs.BSM_ENUM_CONSTANT, "A",
>>                         ClassDesc.of("org.myapp.MyBenchmark").nested("MyEnum"), new ConstantDesc[0]);
>>     }
>> 
>> }
>> 
>> Benchmark results:
>> 
>> Current proposed patch in this PR:
>> 
>> Benchmark                                    Mode  Cnt     Score     Error  Units
>> MyBenchmark.dynamicConstantDesc_ofCanonical  avgt   15  2295.714 ? 228.951  ns/op
>> 
>> Alternate approach of _not_ using the `canonicalMap` and instead using method level map:
>> 
>> Benchmark                                    Mode  Cnt     Score     Error  Units
>> MyBenchmark.dynamicConstantDesc_ofCanonical  avgt   15  4220.446 ? 831.905  ns/op
>
> Hi Jaikiran,
> 
> Since the object assigned to cannonicalMap is an immutable Map created with `Map.ofEntries()` which is able to be safely published via data-race, the `cannonicalMap` field need not be volatile which could be more optimal on ARM. In that case you must avoid reading the field twice outside the synchronized block. So you could remove the volatile modifier from the field and do the following:
> 
>     private ConstantDesc tryCanonicalize() {
>         var canonDescs = canonicalMap;
>         if (canonDescs == null) {
>             canonDescs = Map.ofEntries(...);
>             synchronized (DynamicConstantDesc.class) {
>                 if (canonicalMap == null) {
>                     canonicalMap = canonDescs;
>                 } else {
>                     canonDescs = canonicalMap;
>                 }
>             }
>         }
>         ... use canonDescs ...
>     }
> 
> 
> Peter

Hello Peter,

Thank you for your inputs. I think what you suggest is a good idea. I have updated the PR with this change.

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From igraves at openjdk.java.net  Wed Mar 10 02:31:28 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 10 Mar 2021 02:31:28 GMT
Subject: RFR: 8262351: Extra '0' in java.util.Formatter for '%012a'
 conversion with a sign character [v2]
In-Reply-To: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
References: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
Message-ID: <_zXRlwfKINjkuu-VroJV32HFCzKq2PRVjEOVzQt3g10=.77e90780-16c9-4b1e-a963-e4d347323ac0@github.com>

> This fixes a zero-adding issue observed in the hex float conversion.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Updating Formatter copyright date

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2881/files
  - new: https://git.openjdk.java.net/jdk/pull/2881/files/441c790e..308ae14b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2881&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2881&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2881

From almatvee at openjdk.java.net  Wed Mar 10 03:15:10 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 10 Mar 2021 03:15:10 GMT
Subject: RFR: 8241716: Jpackage functionality to let users choose whether
 to create shortcuts [v2]
In-Reply-To: <Xg81pemYejOaAAE9EdHEt33ZG0zRzvC4is6nhYjzgAM=.c5b10914-a94e-4355-84a6-45f411048e70@github.com>
References: <Pt6oZISZR-tReWpxp2SHlIDJmcjH8oGMME216UPA8As=.18955590-8242-40fd-a04f-749a3bbef03b@github.com>
 <Xg81pemYejOaAAE9EdHEt33ZG0zRzvC4is6nhYjzgAM=.c5b10914-a94e-4355-84a6-45f411048e70@github.com>
Message-ID: <3GAZ-Q6VOBR8DU66NkUOfZH_Br1DV3PJvWJsVlxHPCs=.f2554f9a-a13c-4f0b-9faa-dc702959df57@github.com>

On Tue, 9 Mar 2021 16:50:40 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Add support to insert dialog with prompts to create shortcuts in dialog installation sequence of Windows installers created by jpackage.
>> 
>> Dialog look:
>> ![shortcut_prompt](https://user-images.githubusercontent.com/69478316/110511049-d3828a80-80d1-11eb-8db5-392d5c11c670.png)
>> 
>> As a side effect of the fix, UI-related WiX source code was moved from main.wxs into generated ui.wxf file. Users can override ui.wxf by placing a file with this name in resource directory.
>> Source code of custom dialogs optionally inserted in dialog installation sequence were placed in distinct WiX sources: InstallDirNotEmptyDlg.wxs and ShortcutPromptDlg.wxs. They can be overridden if files with the corresponding names as placed in resource directory.
>> Moving source code of installer UI from main.wxs into ui.wxf, InstallDirNotEmptyDlg.wxs and ShortcutPromptDlg.wxs files supposed to simplify overriding of the default UI provided by jpackage.
>
> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8241716: Jpackage functionality to let users choose whether to create shortcuts
>  - 8241716: Jpackage functionality to let users choose whether to create shortcuts

Marked as reviewed by almatvee (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2882

From darcy at openjdk.java.net  Wed Mar 10 03:41:19 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 10 Mar 2021 03:41:19 GMT
Subject: RFR: 8263102: Expand documention of Method.isBridge [v6]
In-Reply-To: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
Message-ID: <jADcAqcLCktlfWXtKF1k_fBN2cjLesQh67xivOce8oY=.7adf1131-e32c-4730-8c82-4bd49135d5ab@github.com>

> The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
> 
> Once the text is agreed to; I'll update the copyright year as well.

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

  Respond to review feedback, reflow paragraphs, update copyrights.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2852/files
  - new: https://git.openjdk.java.net/jdk/pull/2852/files/0425a2f3..97c59502

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2852&range=04-05

  Stats: 29 lines in 3 files changed: 0 ins; 1 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2852.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2852/head:pull/2852

PR: https://git.openjdk.java.net/jdk/pull/2852

From darcy at openjdk.java.net  Wed Mar 10 03:47:09 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 10 Mar 2021 03:47:09 GMT
Subject: Integrated: 8263102: Expand documention of Method.isBridge
In-Reply-To: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
References: <80j_qe6kWPdc8Yp_jkyUfONzTQHkuUa_9K8cUxWZKAE=.0720ef47-c815-4a82-8d02-f745646f2db2@github.com>
Message-ID: <ykoJ0d0A_JTTIIldx_xcS00AG92o0oufapP6I_typQA=.6acefea4-4f21-48ea-8a60-b959040669bf@github.com>

On Fri, 5 Mar 2021 21:25:20 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The existing documentation of Method.isBridge isn't terribly helpful to the reader. This RFE proposes to given a common example of how bridge methods are used. The JLS does *not* have a section discussing bridge methods in detail; bridge methods are a compilation technique for lowering the Java language to the JVM, they are not a language feature per se. The example given is not exhaustive; there can be and are other uses of bridge methods.
> 
> Once the text is agreed to; I'll update the copyright year as well.

This pull request has now been integrated.

Changeset: 67ea3bd6
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/67ea3bd6
Stats:     42 lines in 3 files changed: 35 ins; 0 del; 7 mod

8263102: Expand documention of Method.isBridge

Reviewed-by: smarks

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

PR: https://git.openjdk.java.net/jdk/pull/2852

From vtewari at openjdk.java.net  Wed Mar 10 05:27:06 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Wed, 10 Mar 2021 05:27:06 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v2]
In-Reply-To: <8601DNFkEWL76jjuZpNosikeT-1L6fsoz9yf5B79uoU=.bfb92ddd-63d8-44b3-84b6-c73413ab342f@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <8601DNFkEWL76jjuZpNosikeT-1L6fsoz9yf5B79uoU=.bfb92ddd-63d8-44b3-84b6-c73413ab342f@github.com>
Message-ID: <veZ9YQ-6j7xY94mIER6D_yDNUTF0OxbY7VyVgZKAbw0=.5c4e095c-6d60-4099-8e0a-07697ba0a0fe@github.com>

On Wed, 10 Mar 2021 02:15:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed patch for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8263108?
>> 
>> As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and `java.lang.constant.ConstantDescs` can end up in a classloading deadlock due to the nature of the code involved in their static blocks. A thread dump of one such deadlock (reproduced using the code attached to that issue) is as follows:
>> 
>> "Thread A" #14 prio=5 os_prio=31 cpu=101.45ms elapsed=8.30s tid=0x00007ff88e01ca00 nid=0x6003 in Object.wait()  [0x000070000a4c6000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.DynamicConstantDesc.<clinit>(java.base at 16-ea/DynamicConstantDesc.java:67)
>> 	- waiting on the Class initialization monitor for java.lang.constant.ConstantDescs
>> 	at Deadlock.threadA(Deadlock.java:14)
>> 	at Deadlock$$Lambda$1/0x0000000800c00a08.run(Unknown Source)
>> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
>> 
>> "Thread B" #15 prio=5 os_prio=31 cpu=103.15ms elapsed=8.30s tid=0x00007ff88b936a00 nid=0x9b03 in Object.wait()  [0x000070000a5c9000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.ClassDesc.ofDescriptor(java.base at 16-ea/ClassDesc.java:145)
>> 	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc
>> 	at java.lang.constant.ConstantDescs.<clinit>(java.base at 16-ea/ConstantDescs.java:239)
>> 	at Deadlock.threadB(Deadlock.java:24)
>> 	at Deadlock$$Lambda$2/0x0000000800c00c28.run(Unknown Source)
>> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
>> 
>> The commit in this PR resolves that deadlock by moving the `canonicalMap` initialization in `DynamicConstantDesc`, from the static block, to a lazily initialized map, into the `tryCanonicalize` (private) method of the same class. That's the only method which uses this map.
>> 
>> The implementation in `tryCanonicalize` carefully ensures that the deadlock isn't shifted from the static block to this method, by making sure that the `synchronization` on `DynamicConstantDesc` in this method happens only when it's time to write the state to the shared `canonicalMap`. This has an implication that the method local variable `canonDescs` can get initialized by multiple threads unnecessarily but from what I can see, that's the only way we can avoid this deadlock. This penalty of multiple threads initializing and then throwing away that map isn't too huge because that will happen only once when the `canonicalMap` is being initialized for the first time.
>> 
>> An alternate approach that I thought of was to completely get rid of this shared cache `canonicalMap` and instead just use method level map (that gets initialized each time) in the `tryCanonicalize` method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.
>> 
>> The commit in this PR also includes a jtreg testcase which (consistently) reproduces the deadlock without the fix and passes when this fix is applied. Extra manual testing has been done to verify that the classes of interest (noted in that testcase) are indeed getting loaded in those concurrent threads and not in the main thread. For future maintainers, there's a implementation note added on that testcase explaining why it cannot be moved into testng test.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Follow Peter Levart's review suggestion - remove volatile

Your code change Looks reasonable  to me. Although i am not export in this area but what i observed is the test case which was attached by original submitter passes null to DynamicConstantDesc as follows "DynamicConstantDesc.of(null)". If you pass valid argument like(ConstantDescs.BSM_INVOKE) no deadlock.

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From darcy at openjdk.java.net  Wed Mar 10 06:30:12 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 10 Mar 2021 06:30:12 GMT
Subject: RFR: 8263333: Improve links from core reflection to JLS and JVMS
Message-ID: <dW_8EQYEGpQnC8k9KjkU8SvaCrdZCep8IbgibMNxCfw=.c92a6926-41c8-4008-abc1-4640d72db78a@github.com>

The javadoc of various methods in core reflection would be improved by links into the JLS.

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

Commit messages:
 - 8263333: Improve links from core reflection to JLS and JVMS

Changes: https://git.openjdk.java.net/jdk/pull/2906/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2906&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263333
  Stats: 21 lines in 5 files changed: 20 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2906.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2906/head:pull/2906

PR: https://git.openjdk.java.net/jdk/pull/2906

From jpai at openjdk.java.net  Wed Mar 10 06:40:06 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 10 Mar 2021 06:40:06 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v2]
In-Reply-To: <veZ9YQ-6j7xY94mIER6D_yDNUTF0OxbY7VyVgZKAbw0=.5c4e095c-6d60-4099-8e0a-07697ba0a0fe@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <8601DNFkEWL76jjuZpNosikeT-1L6fsoz9yf5B79uoU=.bfb92ddd-63d8-44b3-84b6-c73413ab342f@github.com>
 <veZ9YQ-6j7xY94mIER6D_yDNUTF0OxbY7VyVgZKAbw0=.5c4e095c-6d60-4099-8e0a-07697ba0a0fe@github.com>
Message-ID: <zwn1NgnhZkFVFgbTpiDgl5gkzK96X-Z67AhdQrdymRI=.fc52c761-7be4-4beb-883a-72e4a492d16d@github.com>

On Wed, 10 Mar 2021 05:23:51 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> but what i observed is the test case which was attached by original submitter passes null to DynamicConstantDesc as follows "DynamicConstantDesc.of(null)". If you pass valid argument like(ConstantDescs.BSM_INVOKE) no deadlock.

Hello Vyom,

The deadlock is reproducible with non-null params too. For example, the test case in this PR consistently reproduces this deadlock when the fix in the source code isn't applied. The `null` in the original report IMO was used just to explain the issue.

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From cgo at openjdk.java.net  Wed Mar 10 09:48:06 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Wed, 10 Mar 2021 09:48:06 GMT
Subject: RFR: JDK-8262471: Fix coding style in
 src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java
In-Reply-To: <WioKjap6ADDAdX_tFW3B7fwKuVaihCNA7P2yvMlZW9A=.4aa81ba1-821f-4c46-a32d-317c164c3336@github.com>
References: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>
 <zYXYhx46bm8g_dYCTXxlnrIIoOldQwc7giadIrKOxao=.22da3a8e-6349-473f-8015-a64488572469@github.com>
 <WioKjap6ADDAdX_tFW3B7fwKuVaihCNA7P2yvMlZW9A=.4aa81ba1-821f-4c46-a32d-317c164c3336@github.com>
Message-ID: <Z9deBge5p9mVlmoFiouefM5cwcsc2cmShNOf4QA0eNw=.a38221e3-1afb-4da3-9934-521a768a2abd@github.com>

On Mon, 1 Mar 2021 15:21:23 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

>> Looks fine. This source file was a .template until a few weeks ago, probably should have fixed the indentation issues when moving it to a .java file.
>
> Thanks for the review.
> Do we need a second reviewer? If not, could you please sponsor the change?

Could a second reviewer please look at this tiny, whitespace only change and sponsor it?

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

PR: https://git.openjdk.java.net/jdk/pull/2754

From kizune at openjdk.java.net  Wed Mar 10 11:49:08 2021
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Wed, 10 Mar 2021 11:49:08 GMT
Subject: RFR: JDK-8248904: Add support to jpackage for the Mac App Store
In-Reply-To: <Mr21WO6EZtgspQn31renDqAMna0HsTL8dlsnzPbnvas=.ad65953e-853f-454d-9689-a15d1a6a992e@github.com>
References: <Mr21WO6EZtgspQn31renDqAMna0HsTL8dlsnzPbnvas=.ad65953e-853f-454d-9689-a15d1a6a992e@github.com>
Message-ID: <7ocPbN0lyrNsl-bHC2wGu0DfIHYBezPfF9fQ-zxqnrQ=.97e53e20-a9b2-44e3-818c-191ca5d0cb8a@github.com>

On Wed, 24 Feb 2021 21:59:22 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Implementation of Mac App Support including three new mac specific CLI options.

Marked as reviewed by kizune (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2716

From herrick at openjdk.java.net  Wed Mar 10 12:29:09 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 10 Mar 2021 12:29:09 GMT
Subject: RFR: 8241716: Jpackage functionality to let users choose whether
 to create shortcuts [v2]
In-Reply-To: <Xg81pemYejOaAAE9EdHEt33ZG0zRzvC4is6nhYjzgAM=.c5b10914-a94e-4355-84a6-45f411048e70@github.com>
References: <Pt6oZISZR-tReWpxp2SHlIDJmcjH8oGMME216UPA8As=.18955590-8242-40fd-a04f-749a3bbef03b@github.com>
 <Xg81pemYejOaAAE9EdHEt33ZG0zRzvC4is6nhYjzgAM=.c5b10914-a94e-4355-84a6-45f411048e70@github.com>
Message-ID: <EQOcSWH2BXjCm1blLqQJb_ZdZa-h6na7E9Zw5ewQZwA=.31f8b822-8a03-40bd-a42e-3ba12b2dce71@github.com>

On Tue, 9 Mar 2021 16:50:40 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Add support to insert dialog with prompts to create shortcuts in dialog installation sequence of Windows installers created by jpackage.
>> 
>> Dialog look:
>> ![shortcut_prompt](https://user-images.githubusercontent.com/69478316/110511049-d3828a80-80d1-11eb-8db5-392d5c11c670.png)
>> 
>> As a side effect of the fix, UI-related WiX source code was moved from main.wxs into generated ui.wxf file. Users can override ui.wxf by placing a file with this name in resource directory.
>> Source code of custom dialogs optionally inserted in dialog installation sequence were placed in distinct WiX sources: InstallDirNotEmptyDlg.wxs and ShortcutPromptDlg.wxs. They can be overridden if files with the corresponding names as placed in resource directory.
>> Moving source code of installer UI from main.wxs into ui.wxf, InstallDirNotEmptyDlg.wxs and ShortcutPromptDlg.wxs files supposed to simplify overriding of the default UI provided by jpackage.
>
> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - 8241716: Jpackage functionality to let users choose whether to create shortcuts
>  - 8241716: Jpackage functionality to let users choose whether to create shortcuts

Marked as reviewed by herrick (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2882

From kcr at openjdk.java.net  Wed Mar 10 12:48:09 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 10 Mar 2021 12:48:09 GMT
Subject: RFR: JDK-8248904: Add support to jpackage for the Mac App Store
In-Reply-To: <Mr21WO6EZtgspQn31renDqAMna0HsTL8dlsnzPbnvas=.ad65953e-853f-454d-9689-a15d1a6a992e@github.com>
References: <Mr21WO6EZtgspQn31renDqAMna0HsTL8dlsnzPbnvas=.ad65953e-853f-454d-9689-a15d1a6a992e@github.com>
Message-ID: <hL9BxuJiKznaOhjn77PB_8tj0efzzLOHG8y6YfwUti4=.45e05698-3b3d-4eb3-8aed-e6dc138c0a97@github.com>

On Wed, 24 Feb 2021 21:59:22 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Implementation of Mac App Support including three new mac specific CLI options.

Looks good with a couple questions. Is `JavaApp.icns` intended to be an empty file (I see that the file it was renamed from was empty, so probably OK)? The rest are inline below.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties line 188:

> 186: \          over-ridden by adding replacement resources to this directory.\n\
> 187: \          (absolute path or relative to the current directory)\n\
> 188: \  --runtime-image <file path>\n\

This seems unrelated to this change.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties line 247:

> 245: \  --mac-app-store\n\
> 246: \          Indicates that the jpackage output is intended for the\n\
> 247: \          Mac App Store.\n\

Maybe `macOS App Store`?

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

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/2716

From herrick at openjdk.java.net  Wed Mar 10 12:59:08 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 10 Mar 2021 12:59:08 GMT
Subject: RFR: JDK-8248904: Add support to jpackage for the Mac App Store
In-Reply-To: <hL9BxuJiKznaOhjn77PB_8tj0efzzLOHG8y6YfwUti4=.45e05698-3b3d-4eb3-8aed-e6dc138c0a97@github.com>
References: <Mr21WO6EZtgspQn31renDqAMna0HsTL8dlsnzPbnvas=.ad65953e-853f-454d-9689-a15d1a6a992e@github.com>
 <hL9BxuJiKznaOhjn77PB_8tj0efzzLOHG8y6YfwUti4=.45e05698-3b3d-4eb3-8aed-e6dc138c0a97@github.com>
Message-ID: <4Xb2FjlkD7Q3GREcDWpN0wVtptgPTKXWi58m3xFA1RY=.6577f20b-33be-40ab-a3d3-e59cdd23356c@github.com>

On Wed, 10 Mar 2021 12:37:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Implementation of Mac App Support including three new mac specific CLI options.
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties line 188:
> 
>> 186: \          over-ridden by adding replacement resources to this directory.\n\
>> 187: \          (absolute path or relative to the current directory)\n\
>> 188: \  --runtime-image <file path>\n\
> 
> This seems unrelated to this change.

yes - it is unrelated, other than I was adding a new help text with the same syntax (--mac-entitlements <file path>) and was looking for consistent way to say "<file path>" and found that in all cases except this one we said <file path> not <file-path> so I fixed this one too to make them all consistent.

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

PR: https://git.openjdk.java.net/jdk/pull/2716

From pconcannon at openjdk.java.net  Wed Mar 10 13:04:19 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 10 Mar 2021 13:04:19 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
Message-ID: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>

Hi,

Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?

Kind regards,
Patrick

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

Commit messages:
 - 8263358: Update java.lang to use instanceof pattern variable

Changes: https://git.openjdk.java.net/jdk/pull/2913/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263358
  Stats: 62 lines in 18 files changed: 0 ins; 31 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2913.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2913/head:pull/2913

PR: https://git.openjdk.java.net/jdk/pull/2913

From herrick at openjdk.java.net  Wed Mar 10 13:05:08 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 10 Mar 2021 13:05:08 GMT
Subject: RFR: JDK-8248904: Add support to jpackage for the Mac App Store
In-Reply-To: <hL9BxuJiKznaOhjn77PB_8tj0efzzLOHG8y6YfwUti4=.45e05698-3b3d-4eb3-8aed-e6dc138c0a97@github.com>
References: <Mr21WO6EZtgspQn31renDqAMna0HsTL8dlsnzPbnvas=.ad65953e-853f-454d-9689-a15d1a6a992e@github.com>
 <hL9BxuJiKznaOhjn77PB_8tj0efzzLOHG8y6YfwUti4=.45e05698-3b3d-4eb3-8aed-e6dc138c0a97@github.com>
Message-ID: <VVAstZqlDOYDhMwVl5kmX5OttwPLNrpXS0ZxY1tIfR8=.ab5038ee-4cbc-49e2-a74d-33b48d0e85cf@github.com>

On Wed, 10 Mar 2021 12:37:32 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Implementation of Mac App Support including three new mac specific CLI options.
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties line 247:
> 
>> 245: \  --mac-app-store\n\
>> 246: \          Indicates that the jpackage output is intended for the\n\
>> 247: \          Mac App Store.\n\
> 
> Maybe `macOS App Store`?

Although I do see it referenced both ways (even by Apple) I see 10 times as many entries in Google for "Mac App Store" (1.7 billion) vs MacOS App Store (155 million)

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

PR: https://git.openjdk.java.net/jdk/pull/2716

From brian.goetz at oracle.com  Wed Mar 10 14:17:45 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 10 Mar 2021 09:17:45 -0500
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
In-Reply-To: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
Message-ID: <fa325771-52f2-9368-22b7-4ab55f199afa@oracle.com>

These patches are obviously minimally correct.? However, for equals 
methods at least, I would take them one step further, from:

 ??????????? if (!(o instanceof Key that)) return false;
 ??????????? //noinspection StringEquality (guaranteed interned String(s))
 ??????????? return name == that.name &&
 ?????????????????? Arrays.equals(ptypes, that.ptypes);

to

 ??? return (o instanceof Key that)
 ??????? && name == that.name
 ??????? && Arrays.equals(ptypes, that.ptypes);

The use of "if it's not, return false" is a holdover from when we 
couldn't express this as a single expression (which is almost always 
preferable), which means we had to fall back to control flow.? Now we 
don't have to.





On 3/10/2021 8:04 AM, Patrick Concannon wrote:
> Hi,
>
> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
>
> Kind regards,
> Patrick
>
> -------------
>
> Commit messages:
>   - 8263358: Update java.lang to use instanceof pattern variable
>
> Changes: https://git.openjdk.java.net/jdk/pull/2913/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8263358
>    Stats: 62 lines in 18 files changed: 0 ins; 31 del; 31 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/2913.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/2913/head:pull/2913
>
> PR: https://git.openjdk.java.net/jdk/pull/2913


From rriggs at openjdk.java.net  Wed Mar 10 14:50:08 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 10 Mar 2021 14:50:08 GMT
Subject: RFR: JDK-8262471: Fix coding style in
 src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java
In-Reply-To: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>
References: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>
Message-ID: <j3GPMUrozqWEDaXgAT3K2Gh7pM2-b7k6JRzeB5VchMQ=.ecf21307-8f49-4291-8bb8-338b1ec72bb5@github.com>

On Fri, 26 Feb 2021 17:50:19 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Please review this small patch which fixes the coding style of CharacterDataPrivateUse.java

For (most) core-libs changes, only 1 reviewer is required.
However, given the broad interest, please allow time (a day or weekend) for others to take a look.

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2754

From cgo at openjdk.java.net  Wed Mar 10 14:50:09 2021
From: cgo at openjdk.java.net (Christoph =?UTF-8?B?R8O2dHRzY2hrZXM=?=)
Date: Wed, 10 Mar 2021 14:50:09 GMT
Subject: Integrated: JDK-8262471: Fix coding style in
 src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java
In-Reply-To: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>
References: <-CfySrn_EM3XZgsW2XZVlnMAzYZLytWF6SMS9OlR1eM=.67c6fa1a-388c-475f-8bfe-ecded6d3a091@github.com>
Message-ID: <uHX-ItapkzOurcSBnXHzMKnwS-yE06rny42dFg-6_SE=.008de5d0-079f-4b87-aae3-ed62853d863b@github.com>

On Fri, 26 Feb 2021 17:50:19 GMT, Christoph G?ttschkes <cgo at openjdk.org> wrote:

> Please review this small patch which fixes the coding style of CharacterDataPrivateUse.java

This pull request has now been integrated.

Changeset: c8c0234b
Author:    Christoph G?ttschkes <cgo at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c8c0234b
Stats:     13 lines in 1 file changed: 0 ins; 2 del; 11 mod

8262471: Fix coding style in src/java.base/share/classes/java/lang/CharacterDataPrivateUse.java

Reviewed-by: alanb, rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/2754

From redestad at openjdk.java.net  Wed Mar 10 15:12:07 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 10 Mar 2021 15:12:07 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
In-Reply-To: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
Message-ID: <NtzXRMwH33SVLu7o8hsuSv72hAugar2jLX3V_eEEAp0=.6bb549c4-aeab-4347-8cff-0a58ddaacab2@github.com>

On Wed, 10 Mar 2021 12:59:18 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Great. I included some of these in #2300 - @mlchung has asked me to split out some of the changes in that PR to make them more focused and easier to review, so I'll just go ahead and remove the things you're patching up here.

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From rriggs at openjdk.java.net  Wed Mar 10 15:16:14 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 10 Mar 2021 15:16:14 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v2]
In-Reply-To: <l_JSWYHwNTvKCTPRBF1vrsUiYKJzawtb_2j07-uwbI8=.e2cc1d68-2d15-4c35-a2a5-25aadf24067c@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
 <l_JSWYHwNTvKCTPRBF1vrsUiYKJzawtb_2j07-uwbI8=.e2cc1d68-2d15-4c35-a2a5-25aadf24067c@github.com>
Message-ID: <1HxROk2UKTV_3Tqvor1JZDSRzNggXntkrXV61pXA0-4=.d0823cf0-9dc6-4eb2-ba8b-32cfd38834b3@github.com>

On Tue, 9 Mar 2021 00:56:25 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Fix various things pointed out by the most recent doclint run in the security-libs area.
>> 
>> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Codereview Comment

src/java.base/share/classes/javax/crypto/SealedObject.java line 425:

> 423:      * Restores the state of the SealedObject from a stream.
> 424:      *
> 425:      * @param s the object input stream.

Covert to @\throws but keep this declaration.  There is no spec that otherwise covers this and it is consistent with other methods.

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

PR: https://git.openjdk.java.net/jdk/pull/2856

From rriggs at openjdk.java.net  Wed Mar 10 15:16:12 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 10 Mar 2021 15:16:12 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v3]
In-Reply-To: <x6xplg1t8b0m7I_91vuDcYX6kTzQN4DpdVpiH5buNKA=.8d34a58d-274f-4c71-940a-e441cc7ced75@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
 <x6xplg1t8b0m7I_91vuDcYX6kTzQN4DpdVpiH5buNKA=.8d34a58d-274f-4c71-940a-e441cc7ced75@github.com>
Message-ID: <3D9QxdihO80TU6b0jEw_0oSaixV9zLDehI-weuDVy2U=.4b4c4b52-6b5f-4425-97b1-c5ab87f8dd0e@github.com>

On Tue, 9 Mar 2021 22:19:28 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Fix various things pointed out by the most recent doclint run in the security-libs area.
>> 
>> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More Codereview Comments

src/java.base/share/classes/java/security/AllPermission.java line 165:

> 163: 
> 164:     /**
> 165:      * true if any AllPermissions have been added

Please capitalize to make it a  sentence, and end in ".".

src/java.base/share/classes/java/security/BasicPermission.java line 261:

> 259: 
> 260:     /**
> 261:      * readObject is called to restore the state of the BasicPermission from

Please capitalize...  The readObject method...

src/java.base/share/classes/java/security/BasicPermission.java line 526:

> 524: 
> 525:     /**
> 526:      * readObject is called to restore the state of the

Ditto, capitalize.

src/java.base/share/classes/java/security/Permissions.java line 579:

> 577:     };
> 578: 
> 579:     /*

The @ serialData comment can be removed entirely. It is unused due to the "@serial exclude" above.

src/java.base/share/classes/java/security/UnresolvedPermissionCollection.java line 158:

> 156: 
> 157:     /*
> 158:      * @serialData Default field.

the comment block containing @\serialdata can be omitted entirely.

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

PR: https://git.openjdk.java.net/jdk/pull/2856

From redestad at openjdk.java.net  Wed Mar 10 15:38:21 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 10 Mar 2021 15:38:21 GMT
Subject: RFR: 8263380: Unintended use of Objects.nonNull in VarHandles
Message-ID: <Bo61vGnP0PGgG2NVhgn5BL0arCUctEiDwXYjHH7QBRk=.dd2e9f0b-d407-44a9-ba0c-852c2873aac8@github.com>

Use requireNonNull instead.

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

Commit messages:
 - Unintended use of Objects.nonNull in VarHandles

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

PR: https://git.openjdk.java.net/jdk/pull/2914

From rriggs at openjdk.java.net  Wed Mar 10 16:07:08 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 10 Mar 2021 16:07:08 GMT
Subject: RFR: 8263380: Unintended use of Objects.nonNull in VarHandles
In-Reply-To: <Bo61vGnP0PGgG2NVhgn5BL0arCUctEiDwXYjHH7QBRk=.dd2e9f0b-d407-44a9-ba0c-852c2873aac8@github.com>
References: <Bo61vGnP0PGgG2NVhgn5BL0arCUctEiDwXYjHH7QBRk=.dd2e9f0b-d407-44a9-ba0c-852c2873aac8@github.com>
Message-ID: <fZQamp1mJpLMkXQ7v4tLw9AW8t0v5ywG4uUIzxF7GqY=.c5768d60-a2b4-4c4c-88f2-aac91c5de99a@github.com>

On Wed, 10 Mar 2021 15:33:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Use requireNonNull instead.

Well spotted.

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2914

From jvernee at openjdk.java.net  Wed Mar 10 16:07:09 2021
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 10 Mar 2021 16:07:09 GMT
Subject: RFR: 8263380: Unintended use of Objects.nonNull in VarHandles
In-Reply-To: <fZQamp1mJpLMkXQ7v4tLw9AW8t0v5ywG4uUIzxF7GqY=.c5768d60-a2b4-4c4c-88f2-aac91c5de99a@github.com>
References: <Bo61vGnP0PGgG2NVhgn5BL0arCUctEiDwXYjHH7QBRk=.dd2e9f0b-d407-44a9-ba0c-852c2873aac8@github.com>
 <fZQamp1mJpLMkXQ7v4tLw9AW8t0v5ywG4uUIzxF7GqY=.c5768d60-a2b4-4c4c-88f2-aac91c5de99a@github.com>
Message-ID: <JxKIUkuJb7uaLP9rGvN-IbE34glYZ9HzvDFBWj2H-4c=.2cd9133f-5b1a-43a6-abae-8be3852c80b9@github.com>

On Wed, 10 Mar 2021 16:04:22 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Use requireNonNull instead.
>
> Well spotted.

Nice catch!

We have a test that is supposed to test this: https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java But it is only checking if an NPE is thrown, and not checking for a message, since `Objects::requireNonNull` does not set an exception message. I guess that test was still passing because NPEs are thrown at some other point during the call.

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

PR: https://git.openjdk.java.net/jdk/pull/2914

From redestad at openjdk.java.net  Wed Mar 10 16:34:39 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 10 Mar 2021 16:34:39 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups [v5]
In-Reply-To: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
Message-ID: <1RcjLNIE3UTsIOYOo2nxNcKG4_GNta2vLAbIXlrhXAc=.d8e39c90-8923-406f-9143-8b66c0361b81@github.com>

> - Remove unused code
> - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc)
> - Apply pattern matching to make some code more readable

Claes Redestad has updated the pull request with a new target base 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:

 - Revert pattern matching changes covered by #2913
 - Merge branch 'master' into invoke_cleanup
 - Missing .values
 - More cleanup, reduce allocations in InvokerBytecodeGenerator
 - Missing outstanding changes
 - Avoid unnecessary reboxing checks, inline and simplify class/mt invokes
 - j.l.invoke cleanups

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2300/files
  - new: https://git.openjdk.java.net/jdk/pull/2300/files/0e3768b8..b20073e3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=03-04

  Stats: 93145 lines in 2437 files changed: 48324 ins; 24814 del; 20007 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2300.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2300/head:pull/2300

PR: https://git.openjdk.java.net/jdk/pull/2300

From redestad at openjdk.java.net  Wed Mar 10 16:44:06 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 10 Mar 2021 16:44:06 GMT
Subject: RFR: 8263380: Unintended use of Objects.nonNull in VarHandles
In-Reply-To: <JxKIUkuJb7uaLP9rGvN-IbE34glYZ9HzvDFBWj2H-4c=.2cd9133f-5b1a-43a6-abae-8be3852c80b9@github.com>
References: <Bo61vGnP0PGgG2NVhgn5BL0arCUctEiDwXYjHH7QBRk=.dd2e9f0b-d407-44a9-ba0c-852c2873aac8@github.com>
 <fZQamp1mJpLMkXQ7v4tLw9AW8t0v5ywG4uUIzxF7GqY=.c5768d60-a2b4-4c4c-88f2-aac91c5de99a@github.com>
 <JxKIUkuJb7uaLP9rGvN-IbE34glYZ9HzvDFBWj2H-4c=.2cd9133f-5b1a-43a6-abae-8be3852c80b9@github.com>
Message-ID: <i120lUr-CBjXzwuD9iL41au-1tXKQE-pJRAzczpONSk=.fb866533-de61-45c3-8989-2593aa07c51a@github.com>

On Wed, 10 Mar 2021 16:04:59 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Nice catch!
> 
> We have a test that is supposed to test this: https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java But it is only checking if an NPE is thrown, and not checking for a message, since `Objects::requireNonNull` does not set an exception message. I guess that test was still passing because NPEs are thrown at some other point during the call.

Right, checked that passes (had only run the java/lang/invoke tests locally). An alternative approach here is to verify all methods already implicitly check null and remove all these, but being explicit is nice and reduces possibility of surprise.

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

PR: https://git.openjdk.java.net/jdk/pull/2914

From redestad at openjdk.java.net  Wed Mar 10 17:07:08 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 10 Mar 2021 17:07:08 GMT
Subject: Integrated: 8263380: Unintended use of Objects.nonNull in VarHandles
In-Reply-To: <Bo61vGnP0PGgG2NVhgn5BL0arCUctEiDwXYjHH7QBRk=.dd2e9f0b-d407-44a9-ba0c-852c2873aac8@github.com>
References: <Bo61vGnP0PGgG2NVhgn5BL0arCUctEiDwXYjHH7QBRk=.dd2e9f0b-d407-44a9-ba0c-852c2873aac8@github.com>
Message-ID: <Pphqk_PQJ_goyzULn2Xk7BKSRbxCxxiAaSrNQJpYsRM=.2cbcde1c-04e5-41fc-ae87-b8b656198f73@github.com>

On Wed, 10 Mar 2021 15:33:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Use requireNonNull instead.

This pull request has now been integrated.

Changeset: 7e52a6e8
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7e52a6e8
Stats:     14 lines in 1 file changed: 0 ins; 0 del; 14 mod

8263380: Unintended use of Objects.nonNull in VarHandles

Reviewed-by: rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/2914

From jfranck at openjdk.java.net  Wed Mar 10 17:29:11 2021
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Wed, 10 Mar 2021 17:29:11 GMT
Subject: RFR: 8263333: Improve links from core reflection to JLS and JVMS
In-Reply-To: <dW_8EQYEGpQnC8k9KjkU8SvaCrdZCep8IbgibMNxCfw=.c92a6926-41c8-4008-abc1-4640d72db78a@github.com>
References: <dW_8EQYEGpQnC8k9KjkU8SvaCrdZCep8IbgibMNxCfw=.c92a6926-41c8-4008-abc1-4640d72db78a@github.com>
Message-ID: <xWrQAcSiYUfaeR_H_9jpQv1LeeKyKK0TQVoTtEATaXk=.e9130686-c872-445c-ab72-931fac768b6b@github.com>

On Wed, 10 Mar 2021 06:19:27 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The javadoc of various methods in core reflection would be improved by links into the JLS.

Marked as reviewed by jfranck (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2906

From darcy at openjdk.java.net  Wed Mar 10 17:49:09 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 10 Mar 2021 17:49:09 GMT
Subject: Integrated: 8263333: Improve links from core reflection to JLS and
 JVMS
In-Reply-To: <dW_8EQYEGpQnC8k9KjkU8SvaCrdZCep8IbgibMNxCfw=.c92a6926-41c8-4008-abc1-4640d72db78a@github.com>
References: <dW_8EQYEGpQnC8k9KjkU8SvaCrdZCep8IbgibMNxCfw=.c92a6926-41c8-4008-abc1-4640d72db78a@github.com>
Message-ID: <08dOxlaB0kFn4vRV6x2691vrxEfsO5RodLi523vwYtE=.fcccda3e-0be5-4f5d-80d7-7e3127b66220@github.com>

On Wed, 10 Mar 2021 06:19:27 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> The javadoc of various methods in core reflection would be improved by links into the JLS.

This pull request has now been integrated.

Changeset: acda8129
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/acda8129
Stats:     21 lines in 5 files changed: 20 ins; 0 del; 1 mod

8263333: Improve links from core reflection to JLS and JVMS

Reviewed-by: jfranck

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

PR: https://git.openjdk.java.net/jdk/pull/2906

From naoto at openjdk.java.net  Wed Mar 10 17:54:07 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 10 Mar 2021 17:54:07 GMT
Subject: RFR: 8262351: Extra '0' in java.util.Formatter for '%012a'
 conversion with a sign character [v2]
In-Reply-To: <_zXRlwfKINjkuu-VroJV32HFCzKq2PRVjEOVzQt3g10=.77e90780-16c9-4b1e-a963-e4d347323ac0@github.com>
References: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
 <_zXRlwfKINjkuu-VroJV32HFCzKq2PRVjEOVzQt3g10=.77e90780-16c9-4b1e-a963-e4d347323ac0@github.com>
Message-ID: <bBlJx3OsyjLIiTTP0Mo-gKq8ZUb93kplOamq6yqp334=.0f0cbbc7-70c4-4cc8-82b2-2ee55d6c9c09@github.com>

On Wed, 10 Mar 2021 02:31:28 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This fixes a zero-adding issue observed in the hex float conversion.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating Formatter copyright date

Looks good to me.
BTW apart from this issue, I just noticed that in the chart in the `Formatter` class spec, there are two spaces (two NBSPs) for the `extra space` flag:
 * <tr><th scope="row" style="vertical-align:top"> <code>'&nbsp;&nbsp;'</code>
 *     <td style="vertical-align:top"> <code>'&#92;u0020'</code>
 *     <td> Requires the output to include a single extra space
 *     (<code>'&#92;u0020'</code>) for non-negative values.
 *
 *     <p> If both the {@code '+'} and <code>'&nbsp;&nbsp;'</code> flags are given
 *     then an {@link IllegalFormatFlagsException} will be thrown.
 ```
 This might be fixed sometime.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2881

From bchristi at openjdk.java.net  Wed Mar 10 18:08:09 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 10 Mar 2021 18:08:09 GMT
Subject: RFR: 8262351: Extra '0' in java.util.Formatter for '%012a'
 conversion with a sign character [v2]
In-Reply-To: <_zXRlwfKINjkuu-VroJV32HFCzKq2PRVjEOVzQt3g10=.77e90780-16c9-4b1e-a963-e4d347323ac0@github.com>
References: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
 <_zXRlwfKINjkuu-VroJV32HFCzKq2PRVjEOVzQt3g10=.77e90780-16c9-4b1e-a963-e4d347323ac0@github.com>
Message-ID: <FH9d4SWXbKBpk7d9Qg2ASWy_oH__wrvQ1_D3ohNteoo=.b9a317a2-a8d6-445f-b708-1d51ae5c06f7@github.com>

On Wed, 10 Mar 2021 02:31:28 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This fixes a zero-adding issue observed in the hex float conversion.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating Formatter copyright date

Marked as reviewed by bchristi (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2881

From github.com+741251+turbanoff at openjdk.java.net  Wed Mar 10 18:20:06 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Wed, 10 Mar 2021 18:20:06 GMT
Subject: RFR: 8263380: Unintended use of Objects.nonNull in VarHandles
In-Reply-To: <i120lUr-CBjXzwuD9iL41au-1tXKQE-pJRAzczpONSk=.fb866533-de61-45c3-8989-2593aa07c51a@github.com>
References: <Bo61vGnP0PGgG2NVhgn5BL0arCUctEiDwXYjHH7QBRk=.dd2e9f0b-d407-44a9-ba0c-852c2873aac8@github.com>
 <fZQamp1mJpLMkXQ7v4tLw9AW8t0v5ywG4uUIzxF7GqY=.c5768d60-a2b4-4c4c-88f2-aac91c5de99a@github.com>
 <JxKIUkuJb7uaLP9rGvN-IbE34glYZ9HzvDFBWj2H-4c=.2cd9133f-5b1a-43a6-abae-8be3852c80b9@github.com>
 <i120lUr-CBjXzwuD9iL41au-1tXKQE-pJRAzczpONSk=.fb866533-de61-45c3-8989-2593aa07c51a@github.com>
Message-ID: <gomvG8gaglU-2MDxvFy0W5_R-gzqaDv67TlDZAghZsU=.f273f23f-995b-4a69-bad2-4ac318deccc0@github.com>

On Wed, 10 Mar 2021 16:40:56 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Nice catch!
>> 
>> We have a test that is supposed to test this: https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java But it is only checking if an NPE is thrown, and not checking for a message, since `Objects::requireNonNull` does not set an exception message. I guess that test was still passing because NPEs are thrown at some other point during the call.
>
>> Nice catch!
>> 
>> We have a test that is supposed to test this: https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java But it is only checking if an NPE is thrown, and not checking for a message, since `Objects::requireNonNull` does not set an exception message. I guess that test was still passing because NPEs are thrown at some other point during the call.
> 
> Right, checked that passes (had only run the java/lang/invoke tests locally). An alternative approach here is to verify all methods already implicitly check null and remove all these, but being explicit is nice and reduces possibility of surprise.

I found few more similar places in JFR code, where `Objects.nonNull` is used incorrectly.
jdk.jfr.internal.consumer.AbstractEventStream#setStartTime
jdk.jfr.consumer.EventStream#openRepository(java.nio.file.Path)
jdk.jfr.Recording#setFlushInterval

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

PR: https://git.openjdk.java.net/jdk/pull/2914

From iris at openjdk.java.net  Wed Mar 10 18:51:08 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 10 Mar 2021 18:51:08 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v3]
In-Reply-To: <x6xplg1t8b0m7I_91vuDcYX6kTzQN4DpdVpiH5buNKA=.8d34a58d-274f-4c71-940a-e441cc7ced75@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
 <x6xplg1t8b0m7I_91vuDcYX6kTzQN4DpdVpiH5buNKA=.8d34a58d-274f-4c71-940a-e441cc7ced75@github.com>
Message-ID: <tA6EA1cgCgR2AOWh7NfdrtMnKXggJ2gn6uNA_Lxinc0=.4224e55b-4145-490e-a19d-beea7fa018a5@github.com>

On Tue, 9 Mar 2021 22:19:28 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Fix various things pointed out by the most recent doclint run in the security-libs area.
>> 
>> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More Codereview Comments

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2856

From rriggs at openjdk.java.net  Wed Mar 10 18:52:05 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 10 Mar 2021 18:52:05 GMT
Subject: RFR: 8263380: Unintended use of Objects.nonNull in VarHandles
In-Reply-To: <gomvG8gaglU-2MDxvFy0W5_R-gzqaDv67TlDZAghZsU=.f273f23f-995b-4a69-bad2-4ac318deccc0@github.com>
References: <Bo61vGnP0PGgG2NVhgn5BL0arCUctEiDwXYjHH7QBRk=.dd2e9f0b-d407-44a9-ba0c-852c2873aac8@github.com>
 <fZQamp1mJpLMkXQ7v4tLw9AW8t0v5ywG4uUIzxF7GqY=.c5768d60-a2b4-4c4c-88f2-aac91c5de99a@github.com>
 <JxKIUkuJb7uaLP9rGvN-IbE34glYZ9HzvDFBWj2H-4c=.2cd9133f-5b1a-43a6-abae-8be3852c80b9@github.com>
 <i120lUr-CBjXzwuD9iL41au-1tXKQE-pJRAzczpONSk=.fb866533-de61-45c3-8989-2593aa07c51a@github.com>
 <gomvG8gaglU-2MDxvFy0W5_R-gzqaDv67TlDZAghZsU=.f273f23f-995b-4a69-bad2-4ac318deccc0@github.com>
Message-ID: <TXxANzsq2fPgUhdo05njFjsU4yYsA2Xr9fcgNlCau2s=.82aaff0d-a028-4a90-b468-7fc2ea3642bf@github.com>

On Wed, 10 Mar 2021 18:16:49 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>>> Nice catch!
>>> 
>>> We have a test that is supposed to test this: https://github.com/openjdk/jdk/blob/master/test/jdk/java/foreign/TestNulls.java But it is only checking if an NPE is thrown, and not checking for a message, since `Objects::requireNonNull` does not set an exception message. I guess that test was still passing because NPEs are thrown at some other point during the call.
>> 
>> Right, checked that passes (had only run the java/lang/invoke tests locally). An alternative approach here is to verify all methods already implicitly check null and remove all these, but being explicit is nice and reduces possibility of surprise.
>
> I found few more similar places in JFR code, where `Objects.nonNull` is used incorrectly.
> jdk.jfr.internal.consumer.AbstractEventStream#setStartTime
> jdk.jfr.consumer.EventStream#openRepository(java.nio.file.Path)
> jdk.jfr.Recording#setFlushInterval

Created an issue:    JDK-8263395: Incorrect use of Objects.nonNull

> I found few more similar places in JFR code, where `Objects.nonNull` is used incorrectly.
> 
> ```
> jdk.jfr.internal.consumer.AbstractEventStream#setStartTime
> jdk.jfr.consumer.EventStream#openRepository(java.nio.file.Path)
> jdk.jfr.Recording#setFlushInterval
> ```

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

PR: https://git.openjdk.java.net/jdk/pull/2914

From mullan at openjdk.java.net  Wed Mar 10 19:12:09 2021
From: mullan at openjdk.java.net (Sean Mullan)
Date: Wed, 10 Mar 2021 19:12:09 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v3]
In-Reply-To: <x6xplg1t8b0m7I_91vuDcYX6kTzQN4DpdVpiH5buNKA=.8d34a58d-274f-4c71-940a-e441cc7ced75@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
 <x6xplg1t8b0m7I_91vuDcYX6kTzQN4DpdVpiH5buNKA=.8d34a58d-274f-4c71-940a-e441cc7ced75@github.com>
Message-ID: <UIg8lo_Kmt9JQseUoAXILIXofl278NGrsr-YlBUjAe8=.9b1e16e6-3b0b-41af-8dbc-0fcea04349bc@github.com>

On Tue, 9 Mar 2021 22:19:28 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> Fix various things pointed out by the most recent doclint run in the security-libs area.
>> 
>> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.
>
> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More Codereview Comments

Marked as reviewed by mullan (Reviewer).

src/java.base/share/classes/java/security/PrivilegedActionException.java line 101:

> 99:      * Serializable fields for UndeclaredThrowableException.
> 100:      *
> 101:      * @serialField exception Exception the undeclaredThrowable

The "undeclaredThrowable" is confusing and not defined anywhere in this class specification. Suggest changing this to: 

The exception thrown by the privileged computation that resulted in this {@code PrivilegedActionException}.

src/java.base/share/classes/java/security/PrivilegedActionException.java line 99:

> 97: 
> 98:     /**
> 99:      * Serializable fields for UndeclaredThrowableException.

The "UndeclaredThrowableException" is confusing and not defined anywhere in this class specification. Suggest changing this to: 

Serializable fields for this {@code PrivilegedActionException}.

src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyImpl.java line 183:

> 181:      * @serialData this {@code KeyImpl} is serialized by
> 182:      * writing out the ASN1 Encoded bytes of the encryption key.
> 183:      * The ASN1 encoding is defined in RFC4120 and as  follows:

Nit: s/ASN1/ASN.1 (also on line 182).

src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyImpl.java line 183:

> 181:      * @serialData this {@code KeyImpl} is serialized by
> 182:      * writing out the ASN1 Encoded bytes of the encryption key.
> 183:      * The ASN1 encoding is defined in RFC4120 and as  follows:

Remove "and" and extra space after "as"

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

PR: https://git.openjdk.java.net/jdk/pull/2856

From igraves at openjdk.java.net  Wed Mar 10 22:50:22 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 10 Mar 2021 22:50:22 GMT
Subject: Integrated: 8262351: Extra '0' in java.util.Formatter for '%012a'
 conversion with a sign character
In-Reply-To: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
References: <yGrCscWtCbjz68AqoLWbAtwu6L6v1sxdiyTfRNhdMFo=.dd31f406-ac3c-4d61-b6e8-d0c63f7ef45b@github.com>
Message-ID: <PD9PIl0BzLdwbu_U1G7_xwxNcxYYFSL0PqPVZ5h_TGk=.13bb0efe-a204-4eae-b858-dd8c38007e61@github.com>

On Mon, 8 Mar 2021 21:25:32 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This fixes a zero-adding issue observed in the hex float conversion.

This pull request has now been integrated.

Changeset: 6971c23a
Author:    Ian Graves <igraves at openjdk.org>
Committer: Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6971c23a
Stats:     56 lines in 2 files changed: 54 ins; 0 del; 2 mod

8262351: Extra '0' in java.util.Formatter for '%012a' conversion with a sign character

Reviewed-by: bchristi, naoto

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

PR: https://git.openjdk.java.net/jdk/pull/2881

From wetmore at openjdk.java.net  Wed Mar 10 22:54:11 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 10 Mar 2021 22:54:11 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v3]
In-Reply-To: <3D9QxdihO80TU6b0jEw_0oSaixV9zLDehI-weuDVy2U=.4b4c4b52-6b5f-4425-97b1-c5ab87f8dd0e@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
 <x6xplg1t8b0m7I_91vuDcYX6kTzQN4DpdVpiH5buNKA=.8d34a58d-274f-4c71-940a-e441cc7ced75@github.com>
 <3D9QxdihO80TU6b0jEw_0oSaixV9zLDehI-weuDVy2U=.4b4c4b52-6b5f-4425-97b1-c5ab87f8dd0e@github.com>
Message-ID: <gkNkwGhcpyqy6P7ng4jC2E4q5s5KsLreKsKeRrOvH90=.3814b7a2-6e17-451c-91d8-4b332842677e@github.com>

On Wed, 10 Mar 2021 14:53:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More Codereview Comments
>
> src/java.base/share/classes/java/security/AllPermission.java line 165:
> 
>> 163: 
>> 164:     /**
>> 165:      * true if any AllPermissions have been added
> 
> Please capitalize to make it a  sentence, and end in ".".

Done.

> src/java.base/share/classes/java/security/BasicPermission.java line 526:
> 
>> 524: 
>> 525:     /**
>> 526:      * readObject is called to restore the state of the
> 
> Ditto, capitalize.

It's the name of the method and the style is used in other packages.  Leaving as is.

> src/java.base/share/classes/java/security/Permissions.java line 579:
> 
>> 577:     };
>> 578: 
>> 579:     /*
> 
> The @ serialData comment can be removed entirely. It is unused due to the "@serial exclude" above.

Ok.

> src/java.base/share/classes/java/security/UnresolvedPermissionCollection.java line 158:
> 
>> 156: 
>> 157:     /*
>> 158:      * @serialData Default field.
> 
> the comment block containing @\serialdata can be omitted entirely.

ok

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

PR: https://git.openjdk.java.net/jdk/pull/2856

From wetmore at openjdk.java.net  Wed Mar 10 23:04:10 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 10 Mar 2021 23:04:10 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v2]
In-Reply-To: <1HxROk2UKTV_3Tqvor1JZDSRzNggXntkrXV61pXA0-4=.d0823cf0-9dc6-4eb2-ba8b-32cfd38834b3@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
 <l_JSWYHwNTvKCTPRBF1vrsUiYKJzawtb_2j07-uwbI8=.e2cc1d68-2d15-4c35-a2a5-25aadf24067c@github.com>
 <1HxROk2UKTV_3Tqvor1JZDSRzNggXntkrXV61pXA0-4=.d0823cf0-9dc6-4eb2-ba8b-32cfd38834b3@github.com>
Message-ID: <bQdqQEJ6JYJIpS_p-X663s4ctuD2Agi8SjnJKcDZrBc=.c8d3a907-b7f1-4507-8c16-bc43420dbe88@github.com>

On Wed, 10 Mar 2021 15:10:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Codereview Comment
>
> src/java.base/share/classes/javax/crypto/SealedObject.java line 425:
> 
>> 423:      * Restores the state of the SealedObject from a stream.
>> 424:      *
>> 425:      * @param s the object input stream.
> 
> Covert to @\throws but keep this declaration.  There is no spec that otherwise covers this and it is consistent with other methods.

Ok, I'll keep the NullPointerException and change to @throws, although I don't think it's used in many methods.

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

PR: https://git.openjdk.java.net/jdk/pull/2856

From bpb at openjdk.java.net  Wed Mar 10 23:07:25 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 10 Mar 2021 23:07:25 GMT
Subject: RFR: 8251942: PrintStream specification is not clear which flush
 method is automatically invoked
Message-ID: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>

Please review this minor change to the specification of `java.io.PrintStream`. The longstanding behavior for flushing is to invoke the `flush()` method of the underlying `OutputStream` rather than its override but this was not made explicit in the specification.

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

Commit messages:
 - 8251942: PrintStream specification is not clear which flush method is automatically invoked

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

PR: https://git.openjdk.java.net/jdk/pull/2926

From wetmore at openjdk.java.net  Wed Mar 10 23:12:11 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Wed, 10 Mar 2021 23:12:11 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v3]
In-Reply-To: <UIg8lo_Kmt9JQseUoAXILIXofl278NGrsr-YlBUjAe8=.9b1e16e6-3b0b-41af-8dbc-0fcea04349bc@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
 <x6xplg1t8b0m7I_91vuDcYX6kTzQN4DpdVpiH5buNKA=.8d34a58d-274f-4c71-940a-e441cc7ced75@github.com>
 <UIg8lo_Kmt9JQseUoAXILIXofl278NGrsr-YlBUjAe8=.9b1e16e6-3b0b-41af-8dbc-0fcea04349bc@github.com>
Message-ID: <0gleVXDrxNu-VoK8ZCNPi3CU5mqR9fo86X7WtPg3rlc=.b3f279a8-d3dc-4d32-a423-944628386150@github.com>

On Wed, 10 Mar 2021 19:02:40 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   More Codereview Comments
>
> src/java.base/share/classes/java/security/PrivilegedActionException.java line 101:
> 
>> 99:      * Serializable fields for UndeclaredThrowableException.
>> 100:      *
>> 101:      * @serialField exception Exception the undeclaredThrowable
> 
> The "undeclaredThrowable" is confusing and not defined anywhere in this class specification. Suggest changing this to: 
> 
> The exception thrown by the privileged computation that resulted in this {@code PrivilegedActionException}.

Sure, good idea.  Thanks.

> src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyImpl.java line 183:
> 
>> 181:      * @serialData this {@code KeyImpl} is serialized by
>> 182:      * writing out the ASN1 Encoded bytes of the encryption key.
>> 183:      * The ASN1 encoding is defined in RFC4120 and as  follows:
> 
> Nit: s/ASN1/ASN.1 (also on line 182).

Corrected.

> src/java.security.jgss/share/classes/javax/security/auth/kerberos/KeyImpl.java line 183:
> 
>> 181:      * @serialData this {@code KeyImpl} is serialized by
>> 182:      * writing out the ASN1 Encoded bytes of the encryption key.
>> 183:      * The ASN1 encoding is defined in RFC4120 and as  follows:
> 
> Remove "and" and extra space after "as"

Done.

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

PR: https://git.openjdk.java.net/jdk/pull/2856

From wetmore at openjdk.java.net  Thu Mar 11 00:19:24 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 11 Mar 2021 00:19:24 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v4]
In-Reply-To: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
Message-ID: <BHzyda6wxHW86a1gYwEmBEBO3EjUbWQ_IIL4BMqHoIA=.79c28131-de5c-46d3-a87f-43f65cbfe2fe@github.com>

> Fix various things pointed out by the most recent doclint run in the security-libs area.
> 
> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.

Bradford Wetmore has updated the pull request incrementally with one additional commit since the last revision:

  Final codereview comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2856/files
  - new: https://git.openjdk.java.net/jdk/pull/2856/files/ed0cf2ba..edac22b0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2856&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2856&range=02-03

  Stats: 15 lines in 6 files changed: 2 ins; 8 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2856.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2856/head:pull/2856

PR: https://git.openjdk.java.net/jdk/pull/2856

From wetmore at openjdk.java.net  Thu Mar 11 00:22:09 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 11 Mar 2021 00:22:09 GMT
Subject: RFR: 8263105: security-libs doclint cleanup [v4]
In-Reply-To: <7J0SCUfBXhQs33Dm0ALYoOE-N3g8uJn93_reCgbebPg=.15fa4742-58d0-44cf-a113-0df0e25b7663@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
 <24gnlaRnK6HCVyWRR9rnjw4EQUbakQ3jZirWKBro4Vk=.a4e4b32d-ff12-4560-ab0a-608736d2e7dc@github.com>
 <7J0SCUfBXhQs33Dm0ALYoOE-N3g8uJn93_reCgbebPg=.15fa4742-58d0-44cf-a113-0df0e25b7663@github.com>
Message-ID: <QiIfJuFgfbed6zmK2ZQxle8DuhBe0iGGVjwuRvy3n7M=.364866dc-c042-420b-baf9-3313e7dc23fd@github.com>

On Mon, 8 Mar 2021 19:50:06 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

>> src/java.base/share/classes/java/security/BasicPermission.java line 497:
>> 
>>> 495:     /**
>>> 496:      * @serialData Default fields.
>>> 497:      */
>> 
>> FWIW, this doc comment will be ignored, because it will be superseded by the new comment on line 499.  At some point doen the road, you may get a warning from javac about an ignored doc comment.
>
> Ok

Removed after received similar later comments.

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

PR: https://git.openjdk.java.net/jdk/pull/2856

From mark.reinhold at oracle.com  Thu Mar 11 00:27:05 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Wed, 10 Mar 2021 16:27:05 -0800 (PST)
Subject: New candidate JEP: 400: UTF-8 by Default
Message-ID: <20210311002705.12BF03DABE3@eggemoggin.niobe.net>

https://openjdk.java.net/jeps/400

  Summary: Use UTF-8 as the JDK's default charset, so that APIs that
  depend on the default charset behave consistently across all platforms
  and independently of the user???s locale and configuration.

- Mark

From wetmore at openjdk.java.net  Thu Mar 11 00:29:09 2021
From: wetmore at openjdk.java.net (Bradford Wetmore)
Date: Thu, 11 Mar 2021 00:29:09 GMT
Subject: Integrated: 8263105: security-libs doclint cleanup
In-Reply-To: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
References: <8JKqa2YdsN8z9O59Jht7FN9A6DpowhjBFBXTGHu6Bic=.f1bf3f90-8837-4c1d-a2ab-4c3e0f96bfc4@github.com>
Message-ID: <42W8U-0W1f-W0sxeXCKhmwvjGnV_-HUpcX0yUtlIZ1k=.f8443a8d-47b1-4efc-82c8-41ad5c8901c7@github.com>

On Sat, 6 Mar 2021 07:31:09 GMT, Bradford Wetmore <wetmore at openjdk.org> wrote:

> Fix various things pointed out by the most recent doclint run in the security-libs area.
> 
> This is docs only:  I will be checking doccheck/doclint, and will be running tier1/tier2 tests.  Minor spot checks on generated files.

This pull request has now been integrated.

Changeset: 32cbd193
Author:    Bradford Wetmore <wetmore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/32cbd193
Stats:     302 lines in 35 files changed: 223 ins; 8 del; 71 mod

8263105: security-libs doclint cleanup

Reviewed-by: iris, darcy, dfuchs, mullan

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

PR: https://git.openjdk.java.net/jdk/pull/2856

From ecki at zusammenkunft.net  Thu Mar 11 01:12:49 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 11 Mar 2021 01:12:49 +0000
Subject: New candidate JEP: 400: UTF-8 by Default
In-Reply-To: <20210311002705.12BF03DABE3@eggemoggin.niobe.net>
References: <20210311002705.12BF03DABE3@eggemoggin.niobe.net>
Message-ID: <AM0PR03MB4145FF6666B48693F3DB80EAFF909@AM0PR03MB4145.eurprd03.prod.outlook.com>

I like it. The only thing which I feel is missing would be an official API to get the operating environments default encoding (essentially to get the value used if COMPAT would have been specified).

For example, in our server application, we do have some code which is specified as using exactly this charset  (I.e. if user configures targetEncoding=PLATFORM we are using intentionally the no-arg APIs). We can change that code to specify a Charset, but then we need a way to retrieve that - without poking into unsupported system properties or environment properties. For example System.platformCharset().

I understand that this might have it?s own complications - as not all OS have this concept (for example on Windows there might be different codepages depending on the unicode status of an application). But falling back to today?s file.encoding code would at least be consistent and the behavior most implementer would desire when adapting legacy code to this JEP.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von mark.reinhold at oracle.com <mark.reinhold at oracle.com>
Gesendet: Thursday, March 11, 2021 1:27:05 AM
An: naoto.sato at oracle.com <naoto.sato at oracle.com>
Cc: core-libs-dev at openjdk.java.net <core-libs-dev at openjdk.java.net>; jdk-dev at openjdk.java.net <jdk-dev at openjdk.java.net>
Betreff: New candidate JEP: 400: UTF-8 by Default

https://openjdk.java.net/jeps/400

  Summary: Use UTF-8 as the JDK's default charset, so that APIs that
  depend on the default charset behave consistently across all platforms
  and independently of the user???s locale and configuration.

- Mark

From forax at univ-mlv.fr  Thu Mar 11 01:19:19 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 11 Mar 2021 02:19:19 +0100 (CET)
Subject: New candidate JEP: 400: UTF-8 by Default
In-Reply-To: <AM0PR03MB4145FF6666B48693F3DB80EAFF909@AM0PR03MB4145.eurprd03.prod.outlook.com>
References: <20210311002705.12BF03DABE3@eggemoggin.niobe.net>
 <AM0PR03MB4145FF6666B48693F3DB80EAFF909@AM0PR03MB4145.eurprd03.prod.outlook.com>
Message-ID: <763613412.4787.1615425559076.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Bernd Eckenfels" <ecki at zusammenkunft.net>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Jeudi 11 Mars 2021 02:12:49
> Objet: Re: New candidate JEP: 400: UTF-8 by Default

> I like it. The only thing which I feel is missing would be an official API to
> get the operating environments default encoding (essentially to get the value
> used if COMPAT would have been specified).
> 
> For example, in our server application, we do have some code which is specified
> as using exactly this charset  (I.e. if user configures targetEncoding=PLATFORM
> we are using intentionally the no-arg APIs). We can change that code to specify
> a Charset, but then we need a way to retrieve that - without poking into
> unsupported system properties or environment properties. For example
> System.platformCharset().
> 
> I understand that this might have it?s own complications - as not all OS have
> this concept (for example on Windows there might be different codepages
> depending on the unicode status of an application). But falling back to today?s
> file.encoding code would at least be consistent and the behavior most
> implementer would desire when adapting legacy code to this JEP.

Hi,
FileReader has a method named getEncoding()

> 
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net

regards,
R?mi

From ecki at zusammenkunft.net  Thu Mar 11 02:27:05 2021
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 11 Mar 2021 02:27:05 +0000
Subject: New candidate JEP: 400: UTF-8 by Default
In-Reply-To: <763613412.4787.1615425559076.JavaMail.zimbra@u-pem.fr>
References: <20210311002705.12BF03DABE3@eggemoggin.niobe.net>
 <AM0PR03MB4145FF6666B48693F3DB80EAFF909@AM0PR03MB4145.eurprd03.prod.outlook.com>,
 <763613412.4787.1615425559076.JavaMail.zimbra@u-pem.fr>
Message-ID: <AM0PR03MB4145BFDBC6A7DDD9026A1F80FF909@AM0PR03MB4145.eurprd03.prod.outlook.com>

Hello,

Thanks for the hint. The question is if this would return UTF-8 after the JEP is implemented or not (should probably be mentioned in the JEP). If it keeps returning the legacy/platform file encoding that would be a good API for my purpose (but sounds like that would be rather confusing in regards to the default constructor)


--
http://bernd.eckenfels.net
________________________________
Von: Remi Forax <forax at univ-mlv.fr>
Gesendet: Thursday, March 11, 2021 2:19:19 AM
An: Bernd Eckenfels <ecki at zusammenkunft.net>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net>; jdk-dev <jdk-dev at openjdk.java.net>
Betreff: Re: New candidate JEP: 400: UTF-8 by Default

----- Mail original -----
> De: "Bernd Eckenfels" <ecki at zusammenkunft.net>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Cc: "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoy?: Jeudi 11 Mars 2021 02:12:49
> Objet: Re: New candidate JEP: 400: UTF-8 by Default

> I like it. The only thing which I feel is missing would be an official API to
> get the operating environments default encoding (essentially to get the value
> used if COMPAT would have been specified).
>
> For example, in our server application, we do have some code which is specified
> as using exactly this charset  (I.e. if user configures targetEncoding=PLATFORM
> we are using intentionally the no-arg APIs). We can change that code to specify
> a Charset, but then we need a way to retrieve that - without poking into
> unsupported system properties or environment properties. For example
> System.platformCharset().
>
> I understand that this might have it?s own complications - as not all OS have
> this concept (for example on Windows there might be different codepages
> depending on the unicode status of an application). But falling back to today?s
> file.encoding code would at least be consistent and the behavior most
> implementer would desire when adapting legacy code to this JEP.

Hi,
FileReader has a method named getEncoding()

>
> Gruss
> Bernd
> --
> http://bernd.eckenfels.net

regards,
R?mi

From alanb at openjdk.java.net  Thu Mar 11 08:59:07 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 11 Mar 2021 08:59:07 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
In-Reply-To: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
Message-ID: <Le69NgbmU6sgLCa2RFfkOThhA-PdACYFhPx2JbNLsiI=.ce757890-f10d-405a-b7ec-e3f58cb96413@github.com>

On Wed, 10 Mar 2021 12:59:18 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 313:

> 311:         @Override
> 312:         public boolean equals(Object ob) {
> 313:             if (!(ob instanceof Requires that))

it would be nicer if you inverted this to return (ob instanced Requires that) && ...
Same thing for the equals methods in Exports, Opens, Provides, ...

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From dfuchs at openjdk.java.net  Thu Mar 11 10:45:11 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 11 Mar 2021 10:45:11 GMT
Subject: RFR: 8251942: PrintStream specification is not clear which flush
 method is automatically invoked
In-Reply-To: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>
References: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>
Message-ID: <IWhSCuRPz7FXEGRGeJoRl6F1gkx41c-6C0V9u7tfCbA=.60bd81cf-e648-4ad7-b7ec-ac63aa5d9b96@github.com>

On Wed, 10 Mar 2021 23:03:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this minor change to the specification of `java.io.PrintStream`. The longstanding behavior for flushing is to invoke the `flush()` method of the underlying `OutputStream` rather than its override but this was not made explicit in the specification.

src/java.base/share/classes/java/io/PrintStream.java line 45:

> 43:  * output stream is automatically invoked after a byte array is written, one
> 44:  * of the {@code append}, {@code print}, or {@code println} methods is invoked,
> 45:  * or a newline character or byte ({@code '\n'}) is written.

Though not wrong, this was a bit surprising. If I'm not mistaken in the case of `print` and `append` the `flush` method will be called by `write` only if the CharSequence (or String) contains a `\n` character. However, the complex layering where different output stream wrap themselves like Russian dolls (I'm talking about the use of `textOut` and `charOut` here) means that calling `print` or `append` eventually ends up in a call to `write(byte[], int, int)` on the PrintStream which causes a flush() to occur on the underlying stream. So in the case that the String contains a `\n` then flush will be called twice :-) 

I wonder how much of this is exposing arcane implementation details...

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

PR: https://git.openjdk.java.net/jdk/pull/2926

From akozlov at openjdk.java.net  Thu Mar 11 14:07:44 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 11 Mar 2021 14:07:44 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v23]
In-Reply-To: <SaFPzYzpXuZFUYhDvGg6PQHM-EUrSqbR02H5SzL6OvI=.77d3186b-74a5-404a-950f-95af6a13dabd@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ciwAT0uB2sME-WzcDx96ipa1QHDFCeru1pO847cdBrY=.a7f895c7-e7ed-45ce-babd-c9ba2f955dda@github.com>
 <sL7Ru9rbNmfzeX-14ZZdvyVzmjIn3R-NCZypqjU5Amk=.7a077954-920c-46f0-bae2-b646e9b1b6ae@github.com>
 <SaFPzYzpXuZFUYhDvGg6PQHM-EUrSqbR02H5SzL6OvI=.77d3186b-74a5-404a-950f-95af6a13dabd@github.com>
Message-ID: <5oHOwsaj5Jpg7ukRTFk7MG--w0_bq2qSwH6FN0WOZNY=.e519c482-ba19-4e24-955d-07743ab92359@github.com>

On Wed, 3 Mar 2021 15:57:13 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> src/hotspot/os_cpu/bsd_aarch64/os_bsd_aarch64.cpp line 207:
>> 
>>> 205:   // Enable WXWrite: this function is called by the signal handler at arbitrary
>>> 206:   // point of execution.
>>> 207:   ThreadWXEnable wx(WXWrite, thread);
>> 
>> Note that `thread` can be NULL here if the signal handler is running in a non-attached thread. If we then perform:
>> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) :
>>     _thread(thread ? thread : Thread::current()),`
>> we call Thread::current() on a non-attached thread and that will assert/crash if we get NULL. Either avoid using WX when the thread is NULL, or else change to use Thread::current_or_null_safe() and ensure all uses have a NULL check.
>
>> Note that `thread` can be NULL here if the signal handler is running in a non-attached thread. If we then perform:
>> `ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) : _thread(thread ? thread : Thread::current()),`
>> we call Thread::current() on a non-attached thread and that will assert/crash if we get NULL. Either avoid using WX when the thread is NULL, or else change to use Thread::current_or_null_safe() and ensure all uses have a NULL check.
> 
> https://bugs.openjdk.java.net/browse/JDK-8262903 tracks this issue.

Thanks for report and analysis! I fixed this in https://github.com/openjdk/jdk/pull/2200/commits/f6fb01b24f525e578692a1c6f2ff0a55b8233576

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Thu Mar 11 14:07:43 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 11 Mar 2021 14:07:43 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

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

  8262903: [macos_aarch64] Thread::current() called on detached thread

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/a72f6834..f6fb01b2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=24
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=23-24

  Stats: 13 lines in 5 files changed: 3 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From Alan.Bateman at oracle.com  Thu Mar 11 14:29:25 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Mar 2021 14:29:25 +0000
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
 <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
Message-ID: <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>



On 04/03/2021 12:01, Lance Andersen wrote:
> Hi Jaikiran
>
> From https://docs.oracle.com/en/java/javase/15/docs/specs/man/jar.html 
> <https://docs.oracle.com/en/java/javase/15/docs/specs/man/jar.html>
>
> The jar man page includes the following :
> ?The syntax for the |jar|?command resembles the syntax for the 
> |tar|?command.
>
> Because of the above, I feel that we should support:
>
> ???
> -C
> ?dir
> ?directory
> ????
>
> The addition of ?-dir? adds support for an option used by some of the 
> other java command line tools.
>
Is --directory needed with this proposal?

I agree with the suggest to create the directory so that it's consistent 
with other tools.

-Alan.

From redestad at openjdk.java.net  Thu Mar 11 14:55:17 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 11 Mar 2021 14:55:17 GMT
Subject: RFR: 8263450: Simplify LambdaForm.useCount
Message-ID: <u8_H4ZrBp-U0QfsWEHgaLZnlWGer-W_85UroyWbTSzY=.72bfdc0e-6cf3-408d-b3ef-c924801b522c@github.com>

Simplify useCount and avoid calling lastUseIndex for a small startup win.

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

Commit messages:
 - Simplify LambdaForm.useCount

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

PR: https://git.openjdk.java.net/jdk/pull/2940

From lance.andersen at oracle.com  Thu Mar 11 15:25:57 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 11 Mar 2021 15:25:57 +0000
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
 <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
 <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>
Message-ID: <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com>



On Mar 11, 2021, at 9:29 AM, Alan Bateman <alan.bateman at oracle.com<mailto:alan.bateman at oracle.com>> wrote:



On 04/03/2021 12:01, Lance Andersen wrote:
Hi Jaikiran

From https://docs.oracle.com/en/java/javase/15/docs/specs/man/jar.html

The jar man page includes the following :
 The syntax for the jar command resembles the syntax for the tar command.

Because of the above, I feel that we should support:

???
-C
?dir
?directory
????

The addition of ?-dir? adds support for an option used by some of the other java command line tools.

Is --directory needed with this proposal?

I agree with the suggest to create the directory so that it's consistent with other tools.

The only reason I included it is for completeness with tar which the jar options were originally derived from.

Could go either way though

Best
Lance

-Alan.

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>




From brian.burkhalter at oracle.com  Thu Mar 11 16:27:08 2021
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 11 Mar 2021 08:27:08 -0800
Subject: RFR: 8251942: PrintStream specification is not clear which flush
 method is automatically invoked
In-Reply-To: <IWhSCuRPz7FXEGRGeJoRl6F1gkx41c-6C0V9u7tfCbA=.60bd81cf-e648-4ad7-b7ec-ac63aa5d9b96@github.com>
References: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>
 <IWhSCuRPz7FXEGRGeJoRl6F1gkx41c-6C0V9u7tfCbA=.60bd81cf-e648-4ad7-b7ec-ac63aa5d9b96@github.com>
Message-ID: <3AD1C0D0-FB93-4314-9213-F13C272164D8@oracle.com>


> On Mar 11, 2021, at 2:45 AM, Daniel Fuchs <dfuchs at openjdk.java.net> wrote:
> 
> On Wed, 10 Mar 2021 23:03:03 GMT, Brian Burkhalter <bpb at openjdk.org <mailto:bpb at openjdk.org>> wrote:
> 
>> Please review this minor change to the specification of `java.io.PrintStream`. The longstanding behavior for flushing is to invoke the `flush()` method of the underlying `OutputStream` rather than its override but this was not made explicit in the specification.
> 
> src/java.base/share/classes/java/io/PrintStream.java line 45:
> 
>> 43:  * output stream is automatically invoked after a byte array is written, one
>> 44:  * of the {@code append}, {@code print}, or {@code println} methods is invoked,
>> 45:  * or a newline character or byte ({@code '\n'}) is written.
> 
> Though not wrong, this was a bit surprising. If I'm not mistaken in the case of `print` and `append` the `flush` method will be called by `write` only if the CharSequence (or String) contains a `\n` character. However, the complex layering where different output stream wrap themselves like Russian dolls (I'm talking about the use of `textOut` and `charOut` here) means that calling `print` or `append` eventually ends up in a call to `write(byte[], int, int)` on the PrintStream which causes a flush() to occur on the underlying stream. So in the case that the String contains a `\n` then flush will be called twice :-) 
> 
> I wonder how much of this is exposing arcane implementation details?


Yes, I noticed that as well. I didn?t think it was worth complicating things for the purpose of this issue to address it.


From pconcannon at openjdk.java.net  Thu Mar 11 16:31:27 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 11 Mar 2021 16:31:27 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v2]
In-Reply-To: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
Message-ID: <TzYyLgueiKjPk1tCqRQ2-dLGOmxtmp7iKh1dV60i1o0=.b68f2f95-aefe-47ce-ad73-247daf180a61@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

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

 - Merge remote-tracking branch 'origin/master' into JDK-8263358
 - 8263358: Update java.lang to use instanceof pattern variable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2913/files
  - new: https://git.openjdk.java.net/jdk/pull/2913/files/1ec49901..d5bcd253

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=00-01

  Stats: 2400 lines in 125 files changed: 1239 ins; 368 del; 793 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2913.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2913/head:pull/2913

PR: https://git.openjdk.java.net/jdk/pull/2913

From pconcannon at openjdk.java.net  Thu Mar 11 16:42:24 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 11 Mar 2021 16:42:24 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v3]
In-Reply-To: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
Message-ID: <6tewcd6fbSvTdow5ApGEkvVlDCmn6z9NQLnXE_ntH3Q=.ce2ba4c9-ef2a-4630-8622-8a7aefd93870@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8263358: Refactored equals methods

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2913/files
  - new: https://git.openjdk.java.net/jdk/pull/2913/files/d5bcd253..e9d91315

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=01-02

  Stats: 59 lines in 9 files changed: 2 ins; 16 del; 41 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2913.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2913/head:pull/2913

PR: https://git.openjdk.java.net/jdk/pull/2913

From pconcannon at openjdk.java.net  Thu Mar 11 16:42:24 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 11 Mar 2021 16:42:24 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
In-Reply-To: <NtzXRMwH33SVLu7o8hsuSv72hAugar2jLX3V_eEEAp0=.6bb549c4-aeab-4347-8cff-0a58ddaacab2@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <NtzXRMwH33SVLu7o8hsuSv72hAugar2jLX3V_eEEAp0=.6bb549c4-aeab-4347-8cff-0a58ddaacab2@github.com>
Message-ID: <KUBhTHjbSw42vC7E6ftO-9V1A78Srbw8W-8TXRclSxU=.5bd4fae9-46f4-42a1-81fe-a8176863828d@github.com>

On Wed, 10 Mar 2021 15:08:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Great. I included some of these in #2300 - @mlchung has asked me to split out some of the changes in that PR to make them more focused and easier to review, so I'll just go ahead and remove the things you're patching up here.

> _Mailing list message from [Brian Goetz](mailto:brian.goetz at oracle.com) on [hotspot-compiler-dev](mailto:hotspot-compiler-dev at openjdk.java.net):_
> 
> These patches are obviously minimally correct.? However, for equals
> methods at least, I would take them one step further, from:
> 
> ??????????? if (!(o instanceof Key that)) return false;
> ??????????? //noinspection StringEquality (guaranteed interned String(s))
> ??????????? return name == that.name &&
> ?????????????????? Arrays.equals(ptypes, that.ptypes);
> 
> to
> 
> ??? return (o instanceof Key that)
> ??????? && name == that.name
> ??????? && Arrays.equals(ptypes, that.ptypes);
> 
> The use of "if it's not, return false" is a holdover from when we
> couldn't express this as a single expression (which is almost always
> preferable), which means we had to fall back to control flow.? Now we
> don't have to.
> 
> On 3/10/2021 8:04 AM, Patrick Concannon wrote:

Thanks for the suggestion, Brian. I've done this now and it can be viewed in commit e9d9131

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From pconcannon at openjdk.java.net  Thu Mar 11 16:42:25 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 11 Mar 2021 16:42:25 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v3]
In-Reply-To: <Le69NgbmU6sgLCa2RFfkOThhA-PdACYFhPx2JbNLsiI=.ce757890-f10d-405a-b7ec-e3f58cb96413@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <Le69NgbmU6sgLCa2RFfkOThhA-PdACYFhPx2JbNLsiI=.ce757890-f10d-405a-b7ec-e3f58cb96413@github.com>
Message-ID: <wQwa1lbv4hBPlQkqRfUtllgOzC4CB4l2LyzbPmxfSMo=.b5089826-2230-4a68-a0ef-33357026dfc6@github.com>

On Thu, 11 Mar 2021 08:56:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8263358: Refactored equals methods
>
> src/java.base/share/classes/java/lang/module/ModuleDescriptor.java line 313:
> 
>> 311:         @Override
>> 312:         public boolean equals(Object ob) {
>> 313:             if (!(ob instanceof Requires that))
> 
> it would be nicer if you inverted this to return (ob instanced Requires that) && ...
> Same thing for the equals methods in Exports, Opens, Provides, ...

I've refactored the various equals methods now, and they can be viewed in commit e9d9131

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From asemenyuk at openjdk.java.net  Thu Mar 11 16:58:09 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 11 Mar 2021 16:58:09 GMT
Subject: Integrated: 8241716: Jpackage functionality to let users choose
 whether to create shortcuts
In-Reply-To: <Pt6oZISZR-tReWpxp2SHlIDJmcjH8oGMME216UPA8As=.18955590-8242-40fd-a04f-749a3bbef03b@github.com>
References: <Pt6oZISZR-tReWpxp2SHlIDJmcjH8oGMME216UPA8As=.18955590-8242-40fd-a04f-749a3bbef03b@github.com>
Message-ID: <uDGnvowBs79eQpPVVJg_rzO1pa3xVmMH8tnduD9hhwA=.65b6db42-1ca6-4a97-8907-36bc88d3562d@github.com>

On Mon, 8 Mar 2021 22:54:50 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add support to insert dialog with prompts to create shortcuts in dialog installation sequence of Windows installers created by jpackage.
> 
> Dialog look:
> ![shortcut_prompt](https://user-images.githubusercontent.com/69478316/110511049-d3828a80-80d1-11eb-8db5-392d5c11c670.png)
> 
> As a side effect of the fix, UI-related WiX source code was moved from main.wxs into generated ui.wxf file. Users can override ui.wxf by placing a file with this name in resource directory.
> Source code of custom dialogs optionally inserted in dialog installation sequence were placed in distinct WiX sources: InstallDirNotEmptyDlg.wxs and ShortcutPromptDlg.wxs. They can be overridden if files with the corresponding names as placed in resource directory.
> Moving source code of installer UI from main.wxs into ui.wxf, InstallDirNotEmptyDlg.wxs and ShortcutPromptDlg.wxs files supposed to simplify overriding of the default UI provided by jpackage.

This pull request has now been integrated.

Changeset: 7ed46bd0
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7ed46bd0
Stats:     3069 lines in 23 files changed: 2062 ins; 988 del; 19 mod

8241716: Jpackage functionality to let users choose whether to create shortcuts

Reviewed-by: almatvee, herrick

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

PR: https://git.openjdk.java.net/jdk/pull/2882

From dfuchs at openjdk.java.net  Thu Mar 11 19:12:07 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 11 Mar 2021 19:12:07 GMT
Subject: RFR: 8251942: PrintStream specification is not clear which flush
 method is automatically invoked
In-Reply-To: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>
References: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>
Message-ID: <_rcwtsbpgGeofhUDJtRWlQylkUmw78cwR9ZOy6dH470=.1826a6ba-d823-4ac1-90ff-e26f8d94dbc5@github.com>

On Wed, 10 Mar 2021 23:03:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this minor change to the specification of `java.io.PrintStream`. The longstanding behavior for flushing is to invoke the `flush()` method of the underlying `OutputStream` rather than its override but this was not made explicit in the specification.

> Yes, I noticed that as well. I didn?t think it was worth complicating things for the purpose of this issue to address it.

I guess what I was trying to ask is whether we should actually specify that `print` and `append` call `flush` - as this seems to be a side effect of some optimization.
Maybe we should say that the implementation ensures that flush is called when writing a byte array or when  a newline character or byte ({@code '\n'}) is written - but might call it in additional unspecified circumstances?

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

PR: https://git.openjdk.java.net/jdk/pull/2926

From iignatyev at openjdk.java.net  Thu Mar 11 20:22:28 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 11 Mar 2021 20:22:28 GMT
Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside of
 default package
Message-ID: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>

Hi all,

could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? 
to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls  `jdk.test.lib.helpers. ClassFileInstaller::main`. 

from JBS:
> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. 
> 
> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl.
>
> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8263412).

testing:
- [x] `:jdk_core` against `{macos,windows,linux}-x64`
- [x] `:jdk_svc` against `{macos,windows,linux}-x64`
- [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64`

Thanks,
-- Igor

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

Commit messages:
 - make ClassFileInstaller.Manifest::from* public
 - updated copyright years
 - import j.t.l.helpers.ClassFileInstaller
 - added jdk/test/lib/helpers/ClassFileInstaller

Changes: https://git.openjdk.java.net/jdk/pull/2932/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2932&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263412
  Stats: 473 lines in 114 files changed: 145 ins; 229 del; 99 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2932.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2932/head:pull/2932

PR: https://git.openjdk.java.net/jdk/pull/2932

From iris at openjdk.java.net  Thu Mar 11 20:25:08 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 11 Mar 2021 20:25:08 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v3]
In-Reply-To: <6tewcd6fbSvTdow5ApGEkvVlDCmn6z9NQLnXE_ntH3Q=.ce2ba4c9-ef2a-4630-8622-8a7aefd93870@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <6tewcd6fbSvTdow5ApGEkvVlDCmn6z9NQLnXE_ntH3Q=.ce2ba4c9-ef2a-4630-8622-8a7aefd93870@github.com>
Message-ID: <rl7WoE9vfGdB641OAvOZ7l2dIqaEj0q4ZYDsSQjotGA=.456bae82-c0e3-40aa-bcb8-8594fe487af9@github.com>

On Thu, 11 Mar 2021 16:42:24 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263358: Refactored equals methods

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From stefank at openjdk.java.net  Thu Mar 11 20:31:16 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 11 Mar 2021 20:31:16 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
In-Reply-To: <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
Message-ID: <gKoH7dS4tYmoRme7Wzbg1mH0ygHFKlaTQgS_JiIE_8A=.96b62223-ef50-43f5-9db1-d150e449e1b9@github.com>

On Thu, 11 Mar 2021 14:07:43 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8262903: [macos_aarch64] Thread::current() called on detached thread

Marked as reviewed by stefank (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From stefank at openjdk.java.net  Thu Mar 11 20:31:17 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Thu, 11 Mar 2021 20:31:17 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
In-Reply-To: <Dze4ZtrPI_OLkuExMIN1fl5u6eCryLmgNRgAHzN2kXE=.eee71cb4-1c81-46f8-b6ae-063659a28fc2@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
 <Dze4ZtrPI_OLkuExMIN1fl5u6eCryLmgNRgAHzN2kXE=.eee71cb4-1c81-46f8-b6ae-063659a28fc2@github.com>
Message-ID: <3NYUmXmjyZFhGJwrHfEjSRX1VRaPjt5cCp9HRBxODbM=.4880b6d1-f6dd-45db-95f4-9064e9204d87@github.com>

On Tue, 9 Mar 2021 17:55:12 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/share/runtime/thread.cpp line 2515:
>> 
>>> 2513: void JavaThread::check_special_condition_for_native_trans(JavaThread *thread) {
>>> 2514:   // Enable WXWrite: called directly from interpreter native wrapper.
>>> 2515:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXWrite, thread));
>> 
>> FWIW, I personally think that adding these MACOS_AARCH64_ONLY usages at the call sites increase the line-noise in the affected functions. I think I would have preferred a version:
>> ThreadWXEnable(WXMode new_mode, Thread* thread = NULL) {
>>   MACOS_AARCH64_ONLY(initialize(new_mode, thread);) {}
>> void initialize(...); // Implementation in thread_bsd_aarch64.cpp (alt. inline.hpp)
>> With that said, I'm fine with taking this discussion as a follow-up.
>
> The former version used no such macros. I like that now it's clear the W^X management is relevant to macos/aarch64 only. I see the point to move the pre-processor condition into the class implementation. But I think it will bring a bit of inconsistency, as the rest of W^X implementation is explicitly guarded by preprocessor conditionals. I've also tried to push macro conditionals as far as possible down to implementation, providing a kind of generalized W^X interface. That required a few artificial decisions, e.g. how would we call the mode we execute on the rest of platforms with write and execute allowed, WXWriteExec?.. I abandoned that attempt.

I think we would use the same names, but I haven't given it more thought. I might take a look at this after this has been integrated.

>> src/hotspot/share/runtime/thread.hpp line 848:
>> 
>>> 846:   void init_wx();
>>> 847:   WXMode enable_wx(WXMode new_state);
>>> 848: #endif // __APPLE__ && AARCH64
>> 
>> Now that this is only compiled into macOS/AArch64, could this be moved over to thread_bsd_aarch64.hpp? The same goes for the associated functions.
>
> The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block belongs to Thread for now. Since W^X is an attribute of any operating system thread, I assumed Thread to be the right place for W^X bookkeeping. 
> 
> In most cases, we manage W^X state of JavaThread. But sometimes a GC thread needs the WXWrite state, or safefetch is called from non-JavaThread. Probably this can be dealt with (e.g. GCThread to always have the WXWrite state). But such change would be much more than a simple refactoring and it would require a significant amount of testing. Ideally, I would like to investigate this as a follow-up change, or at least after other fixes to this PR.

Good point about Thread vs JavaThread. Yes, this can be looked into as follow-up cleanups.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From bpb at openjdk.java.net  Thu Mar 11 20:57:24 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 11 Mar 2021 20:57:24 GMT
Subject: RFR: 8251942: PrintStream specification is not clear which flush
 method is automatically invoked [v2]
In-Reply-To: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>
References: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>
Message-ID: <Fyc9SIrzDTiPDgvBUXkDKea01fTNRAxC0E07JvWQTn8=.b0e226ad-687e-4ab7-8659-b11fe5848807@github.com>

> Please review this minor change to the specification of `java.io.PrintStream`. The longstanding behavior for flushing is to invoke the `flush()` method of the underlying `OutputStream` rather than its override but this was not made explicit in the specification.

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

  8251942: Scale back class level spec change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2926/files
  - new: https://git.openjdk.java.net/jdk/pull/2926/files/3a42269a..2fb89ff8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2926&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2926&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2926

From bpb at openjdk.java.net  Thu Mar 11 20:57:24 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 11 Mar 2021 20:57:24 GMT
Subject: RFR: 8251942: PrintStream specification is not clear which flush
 method is automatically invoked
In-Reply-To: <_rcwtsbpgGeofhUDJtRWlQylkUmw78cwR9ZOy6dH470=.1826a6ba-d823-4ac1-90ff-e26f8d94dbc5@github.com>
References: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>
 <_rcwtsbpgGeofhUDJtRWlQylkUmw78cwR9ZOy6dH470=.1826a6ba-d823-4ac1-90ff-e26f8d94dbc5@github.com>
Message-ID: <uGvoyiqi8a4sNbQftdUO682Z-tnUROumajylIFFQ5aU=.15e88ed3-8d4d-4f98-ab83-0db18eb63a9f@github.com>

On Thu, 11 Mar 2021 19:09:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Please review this minor change to the specification of `java.io.PrintStream`. The longstanding behavior for flushing is to invoke the `flush()` method of the underlying `OutputStream` rather than its override but this was not made explicit in the specification.
>
>> Yes, I noticed that as well. I didn?t think it was worth complicating things for the purpose of this issue to address it.
> 
> I guess what I was trying to ask is whether we should actually specify that `print` and `append` call `flush` - as this seems to be a side effect of some optimization.
> Maybe we should say that the implementation ensures that flush is called when writing a byte array or when  a newline character or byte ({@code '\n'}) is written - but might call it in additional unspecified circumstances?

I think you are correct. In the second commit I scaled back the change to the class level specification. I left out any mention of "unspecified circumstances."

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

PR: https://git.openjdk.java.net/jdk/pull/2926

From iklam at openjdk.java.net  Thu Mar 11 20:58:07 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Thu, 11 Mar 2021 20:58:07 GMT
Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside
 of default package
In-Reply-To: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
References: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
Message-ID: <7P0MS1asoKJMsIEgliuJvza7mcz1z7aBeeF9RKccIK4=.d1dbefa1-3b4b-4adf-bf2e-24f7c61161cb@github.com>

On Thu, 11 Mar 2021 05:47:00 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? 
> to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls  `jdk.test.lib.helpers. ClassFileInstaller::main`. 
> 
> from JBS:
>> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. 
>> 
>> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl.
>>
>> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129).
> 
> testing:
> - [x] `:jdk_core` against `{macos,windows,linux}-x64`
> - [x] `:jdk_svc` against `{macos,windows,linux}-x64`
> - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64`
> 
> Thanks,
> -- Igor

The CDS test changes look good to me. It seems they are just adding a single line of import.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2932

From coleenp at openjdk.java.net  Thu Mar 11 21:18:11 2021
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Thu, 11 Mar 2021 21:18:11 GMT
Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside
 of default package
In-Reply-To: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
References: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
Message-ID: <D6kPlFFpjPlIKs2GeLZp2s6TSRitoXbzJvIfPuuyQb0=.c19ad48f-5613-46d6-ad29-59c8f55957ea@github.com>

On Thu, 11 Mar 2021 05:47:00 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? 
> to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls  `jdk.test.lib.helpers. ClassFileInstaller::main`. 
> 
> from JBS:
>> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. 
>> 
>> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl.
>>
>> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129).
> 
> testing:
> - [x] `:jdk_core` against `{macos,windows,linux}-x64`
> - [x] `:jdk_svc` against `{macos,windows,linux}-x64`
> - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64`
> 
> Thanks,
> -- Igor

Looks good.  I looked at the RedefineClasses tests also.

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

Marked as reviewed by coleenp (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2932

From dcubed at openjdk.java.net  Thu Mar 11 23:48:18 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 11 Mar 2021 23:48:18 GMT
Subject: RFR: 8263480: ProblemList two jpackage tests on Windows
Message-ID: <oYePvx4yNhPI9oz7w-r0vqLuaNGYQwPl-mdzoF8VIbw=.4f50ac9c-07bf-451f-a295-936932fd1404@github.com>

A trivial fix to ProblemList two new tests on Windows.

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

Commit messages:
 - 8263480: ProblemList two jpackage tests on Windows

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

PR: https://git.openjdk.java.net/jdk/pull/2952

From dcubed at openjdk.java.net  Thu Mar 11 23:48:18 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 11 Mar 2021 23:48:18 GMT
Subject: RFR: 8263480: ProblemList two jpackage tests on Windows
In-Reply-To: <oYePvx4yNhPI9oz7w-r0vqLuaNGYQwPl-mdzoF8VIbw=.4f50ac9c-07bf-451f-a295-936932fd1404@github.com>
References: <oYePvx4yNhPI9oz7w-r0vqLuaNGYQwPl-mdzoF8VIbw=.4f50ac9c-07bf-451f-a295-936932fd1404@github.com>
Message-ID: <kP9Nf3lfn7vg9eRjCpXkiMgZleXvPlO5wwi508nrWY4=.cdbe1b82-5693-4c3d-b9dd-a88fabb4b4c2@github.com>

On Thu, 11 Mar 2021 23:41:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList two new tests on Windows.

@alexeysemenyukoracle or @kevinrushforth - can either of you folks review this ProblemListing?

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

PR: https://git.openjdk.java.net/jdk/pull/2952

From kcr at openjdk.java.net  Thu Mar 11 23:54:07 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 11 Mar 2021 23:54:07 GMT
Subject: RFR: 8263480: ProblemList two jpackage tests on Windows
In-Reply-To: <oYePvx4yNhPI9oz7w-r0vqLuaNGYQwPl-mdzoF8VIbw=.4f50ac9c-07bf-451f-a295-936932fd1404@github.com>
References: <oYePvx4yNhPI9oz7w-r0vqLuaNGYQwPl-mdzoF8VIbw=.4f50ac9c-07bf-451f-a295-936932fd1404@github.com>
Message-ID: <w8rJ32EU7fmDN5kHcREulIPisxG983Ep8kkSBFi4A9g=.5ba91d5b-94f3-4d70-970a-fd99099a59e0@github.com>

On Thu, 11 Mar 2021 23:41:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList two new tests on Windows.

Marked as reviewed by kcr (Author).

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

PR: https://git.openjdk.java.net/jdk/pull/2952

From azvegint at openjdk.java.net  Thu Mar 11 23:54:07 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Thu, 11 Mar 2021 23:54:07 GMT
Subject: RFR: 8263480: ProblemList two jpackage tests on Windows
In-Reply-To: <oYePvx4yNhPI9oz7w-r0vqLuaNGYQwPl-mdzoF8VIbw=.4f50ac9c-07bf-451f-a295-936932fd1404@github.com>
References: <oYePvx4yNhPI9oz7w-r0vqLuaNGYQwPl-mdzoF8VIbw=.4f50ac9c-07bf-451f-a295-936932fd1404@github.com>
Message-ID: <uUPETp-vx-Ac4Eh5UBsKXLOdIIBb0bQzrxrFojDuZAE=.6b8fabf8-a739-4444-8369-8cc58c8a4965@github.com>

On Thu, 11 Mar 2021 23:41:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList two new tests on Windows.

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2952

From kcr at openjdk.java.net  Thu Mar 11 23:54:07 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 11 Mar 2021 23:54:07 GMT
Subject: RFR: 8263480: ProblemList two jpackage tests on Windows
In-Reply-To: <kP9Nf3lfn7vg9eRjCpXkiMgZleXvPlO5wwi508nrWY4=.cdbe1b82-5693-4c3d-b9dd-a88fabb4b4c2@github.com>
References: <oYePvx4yNhPI9oz7w-r0vqLuaNGYQwPl-mdzoF8VIbw=.4f50ac9c-07bf-451f-a295-936932fd1404@github.com>
 <kP9Nf3lfn7vg9eRjCpXkiMgZleXvPlO5wwi508nrWY4=.cdbe1b82-5693-4c3d-b9dd-a88fabb4b4c2@github.com>
Message-ID: <p9_l9r-b3enMrJXJY2H1BlnwbL-hEeUq4ptU3vELfXI=.2f2037f9-42e6-40c7-8e7a-25ff490ef41d@github.com>

On Thu, 11 Mar 2021 23:44:18 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> A trivial fix to ProblemList two new tests on Windows.
>
> @alexeysemenyukoracle or @kevinrushforth - can either of you folks review this ProblemListing?

Sure, although I a not a Reviewer in the jdk project, so it will need one more. Alexey just became a reviewer, but I don't think the census is updated yet.

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

PR: https://git.openjdk.java.net/jdk/pull/2952

From dcubed at openjdk.java.net  Thu Mar 11 23:54:08 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 11 Mar 2021 23:54:08 GMT
Subject: RFR: 8263480: ProblemList two jpackage tests on Windows
In-Reply-To: <w8rJ32EU7fmDN5kHcREulIPisxG983Ep8kkSBFi4A9g=.5ba91d5b-94f3-4d70-970a-fd99099a59e0@github.com>
References: <oYePvx4yNhPI9oz7w-r0vqLuaNGYQwPl-mdzoF8VIbw=.4f50ac9c-07bf-451f-a295-936932fd1404@github.com>
 <w8rJ32EU7fmDN5kHcREulIPisxG983Ep8kkSBFi4A9g=.5ba91d5b-94f3-4d70-970a-fd99099a59e0@github.com>
Message-ID: <cKuu_ot5e2oHZGl_c_zMJm9GKDQQ5IC6sLNguFIujF4=.d57894d6-a51a-451b-ab89-4473ba51dfda@github.com>

On Thu, 11 Mar 2021 23:50:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> A trivial fix to ProblemList two new tests on Windows.
>
> Marked as reviewed by kcr (Author).

@kevinrushforth - Thanks for the heads up. I've pinged in the jdk-gatekeeping Slack channel.

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

PR: https://git.openjdk.java.net/jdk/pull/2952

From dcubed at openjdk.java.net  Fri Mar 12 00:00:07 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 12 Mar 2021 00:00:07 GMT
Subject: RFR: 8263480: ProblemList two jpackage tests on Windows
In-Reply-To: <w8rJ32EU7fmDN5kHcREulIPisxG983Ep8kkSBFi4A9g=.5ba91d5b-94f3-4d70-970a-fd99099a59e0@github.com>
References: <oYePvx4yNhPI9oz7w-r0vqLuaNGYQwPl-mdzoF8VIbw=.4f50ac9c-07bf-451f-a295-936932fd1404@github.com>
 <w8rJ32EU7fmDN5kHcREulIPisxG983Ep8kkSBFi4A9g=.5ba91d5b-94f3-4d70-970a-fd99099a59e0@github.com>
Message-ID: <0YZfxUx_3OuclQqeMVUkicoEP_24ahDY-owp_Ake-5Y=.3301626f-e233-428f-b5e8-7d8fed0c07d2@github.com>

On Thu, 11 Mar 2021 23:50:03 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> A trivial fix to ProblemList two new tests on Windows.
>
> Marked as reviewed by kcr (Author).

@kevinrushforth and @azvegint - Thanks for the reviews!

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

PR: https://git.openjdk.java.net/jdk/pull/2952

From dcubed at openjdk.java.net  Fri Mar 12 00:00:08 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Fri, 12 Mar 2021 00:00:08 GMT
Subject: Integrated: 8263480: ProblemList two jpackage tests on Windows
In-Reply-To: <oYePvx4yNhPI9oz7w-r0vqLuaNGYQwPl-mdzoF8VIbw=.4f50ac9c-07bf-451f-a295-936932fd1404@github.com>
References: <oYePvx4yNhPI9oz7w-r0vqLuaNGYQwPl-mdzoF8VIbw=.4f50ac9c-07bf-451f-a295-936932fd1404@github.com>
Message-ID: <AP8tfIBK5I7smf2iJyaOPHTlfKqaK5CS_rdEteZBrds=.5866f4d5-bd2c-4d0f-9dc4-a2d207f4991f@github.com>

On Thu, 11 Mar 2021 23:41:53 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

> A trivial fix to ProblemList two new tests on Windows.

This pull request has now been integrated.

Changeset: cf1c0219
Author:    Daniel D. Daugherty <dcubed at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cf1c0219
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8263480: ProblemList two jpackage tests on Windows

Reviewed-by: kcr, azvegint

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

PR: https://git.openjdk.java.net/jdk/pull/2952

From mseledtsov at openjdk.java.net  Fri Mar 12 02:11:07 2021
From: mseledtsov at openjdk.java.net (Mikhailo Seledtsov)
Date: Fri, 12 Mar 2021 02:11:07 GMT
Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside
 of default package
In-Reply-To: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
References: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
Message-ID: <QhECb_U8iKcmnrdo8XuOpA1vGxpnusjuMVBo5X78Tq0=.53dc142a-f365-43dd-92b9-4ab22df68499@github.com>

On Thu, 11 Mar 2021 05:47:00 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? 
> to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls  `jdk.test.lib.helpers. ClassFileInstaller::main`. 
> 
> from JBS:
>> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. 
>> 
>> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl.
>>
>> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129).
> 
> testing:
> - [x] `:jdk_core` against `{macos,windows,linux}-x64`
> - [x] `:jdk_svc` against `{macos,windows,linux}-x64`
> - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64`
> 
> Thanks,
> -- Igor

Marked as reviewed by mseledtsov (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2932

From dholmes at openjdk.java.net  Fri Mar 12 05:27:17 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 12 Mar 2021 05:27:17 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
In-Reply-To: <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
Message-ID: <AXibtmRbVH_zQFoRBh8gkCTWU8bbLQ-0LGkhj1pnm-0=.bb57e91b-7738-499b-ac05-a93f4024e163@github.com>

On Thu, 11 Mar 2021 14:07:43 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8262903: [macos_aarch64] Thread::current() called on detached thread

src/hotspot/share/runtime/safefetch.inline.hpp line 35:

> 33: inline int SafeFetch32(int* adr, int errValue) {
> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
> 35:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current()));

I think you may have to use `Thread::current_or_null_safe()` here in case this gets called from a signal handling context - see vmError.cpp testing for TestSafeFetchInErrorHandler. Same possibly for SafeFetchN.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From jpai at openjdk.java.net  Fri Mar 12 06:35:05 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Fri, 12 Mar 2021 06:35:05 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v2]
In-Reply-To: <zwn1NgnhZkFVFgbTpiDgl5gkzK96X-Z67AhdQrdymRI=.fc52c761-7be4-4beb-883a-72e4a492d16d@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <8601DNFkEWL76jjuZpNosikeT-1L6fsoz9yf5B79uoU=.bfb92ddd-63d8-44b3-84b6-c73413ab342f@github.com>
 <veZ9YQ-6j7xY94mIER6D_yDNUTF0OxbY7VyVgZKAbw0=.5c4e095c-6d60-4099-8e0a-07697ba0a0fe@github.com>
 <zwn1NgnhZkFVFgbTpiDgl5gkzK96X-Z67AhdQrdymRI=.fc52c761-7be4-4beb-883a-72e4a492d16d@github.com>
Message-ID: <pKsQesKSFKR9Bc_sxOE3wAOY-P0UYQ_g4Kfr8ROMkAc=.e6091647-4dce-4f4b-b93d-8e7f8ec5557d@github.com>

On Wed, 10 Mar 2021 06:36:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Your code change Looks reasonable  to me. Although i am not export in this area but what i observed is the test case which was attached by original submitter passes null to DynamicConstantDesc as follows "DynamicConstantDesc.of(null)". If you pass valid argument like(ConstantDescs.BSM_INVOKE) no deadlock.
>
>> but what i observed is the test case which was attached by original submitter passes null to DynamicConstantDesc as follows "DynamicConstantDesc.of(null)". If you pass valid argument like(ConstantDescs.BSM_INVOKE) no deadlock.
> 
> Hello Vyom,
> 
> The deadlock is reproducible with non-null params too. For example, the test case in this PR consistently reproduces this deadlock when the fix in the source code isn't applied. The `null` in the original report IMO was used just to explain the issue.

Any reviews please?

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From akozlov at openjdk.java.net  Fri Mar 12 07:12:17 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 12 Mar 2021 07:12:17 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
In-Reply-To: <AXibtmRbVH_zQFoRBh8gkCTWU8bbLQ-0LGkhj1pnm-0=.bb57e91b-7738-499b-ac05-a93f4024e163@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
 <AXibtmRbVH_zQFoRBh8gkCTWU8bbLQ-0LGkhj1pnm-0=.bb57e91b-7738-499b-ac05-a93f4024e163@github.com>
Message-ID: <lPoCNtc83YmZudBHHRDi_pc4xqoTTIzA0b-TzxQXV9o=.1754abd9-5747-4528-a040-0abf5ff6af35@github.com>

On Fri, 12 Mar 2021 05:24:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8262903: [macos_aarch64] Thread::current() called on detached thread
>
> src/hotspot/share/runtime/safefetch.inline.hpp line 35:
> 
>> 33: inline int SafeFetch32(int* adr, int errValue) {
>> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
>> 35:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current()));
> 
> I think you may have to use `Thread::current_or_null_safe()` here in case this gets called from a signal handling context - see vmError.cpp testing for TestSafeFetchInErrorHandler. Same possibly for SafeFetchN.

I'm not sure about expected behavior then. We may crash trying to execute the generated code, since we may have no WXExec. If we switch to WXExec, we would need to go back to a previous W^X state, but we don't know which one without the thread.

BTW, the test passes, probably that's why it didn't get attention. All non-trivial actions in the current implementation of `pd_hotspot_signal_handler` (hhttps://github.com/openjdk/jdk/pull/2200/files#diff-9dcc5bcf908e2f8eb00b2c2837d667687a7540936d8f538ee1ea14e31ad50b40R215-R324) assume non-NULL thread. So AFAICS, we should always have a thread when the SafeFetch is called. 

Probably a fix to the https://bugs.openjdk.java.net/browse/JDK-8262903 could just move ThreadWXEnable under the `if`. But now after https://github.com/openjdk/jdk/pull/2200/commits/f6fb01b24f525e578692a1c6f2ff0a55b8233576is ThreadWXEnable allows optional W^X state change, like `MutexLocker` allows optional locking.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From david.holmes at oracle.com  Fri Mar 12 07:58:56 2021
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 12 Mar 2021 17:58:56 +1000
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
In-Reply-To: <lPoCNtc83YmZudBHHRDi_pc4xqoTTIzA0b-TzxQXV9o=.1754abd9-5747-4528-a040-0abf5ff6af35@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
 <AXibtmRbVH_zQFoRBh8gkCTWU8bbLQ-0LGkhj1pnm-0=.bb57e91b-7738-499b-ac05-a93f4024e163@github.com>
 <lPoCNtc83YmZudBHHRDi_pc4xqoTTIzA0b-TzxQXV9o=.1754abd9-5747-4528-a040-0abf5ff6af35@github.com>
Message-ID: <59c46a13-91d9-bd60-70dd-ff8fde81c0c7@oracle.com>

On 12/03/2021 5:12 pm, Anton Kozlov wrote:
> On Fri, 12 Mar 2021 05:24:10 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>>>
>>>    8262903: [macos_aarch64] Thread::current() called on detached thread
>>
>> src/hotspot/share/runtime/safefetch.inline.hpp line 35:
>>
>>> 33: inline int SafeFetch32(int* adr, int errValue) {
>>> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
>>> 35:   MACOS_AARCH64_ONLY(ThreadWXEnable wx(WXExec, Thread::current()));
>>
>> I think you may have to use `Thread::current_or_null_safe()` here in case this gets called from a signal handling context - see vmError.cpp testing for TestSafeFetchInErrorHandler. Same possibly for SafeFetchN.
> 
> I'm not sure about expected behavior then. We may crash trying to execute the generated code, since we may have no WXExec. If we switch to WXExec, we would need to go back to a previous W^X state, but we don't know which one without the thread.

The NULL check is only part of it. In a signal handling context 
Thread::current() is not safe to call, you have to use 
Thread::current_or_null_safe().

> BTW, the test passes, probably that's why it didn't get attention. All non-trivial actions in the current implementation of `pd_hotspot_signal_handler` (hhttps://github.com/openjdk/jdk/pull/2200/files#diff-9dcc5bcf908e2f8eb00b2c2837d667687a7540936d8f538ee1ea14e31ad50b40R215-R324) assume non-NULL thread. So AFAICS, we should always have a thread when the SafeFetch is called.

Okay but you still need to use Thread::current_or_null_safe().

Cheers,
David

> Probably a fix to the https://bugs.openjdk.java.net/browse/JDK-8262903 could just move ThreadWXEnable under the `if`. But now after https://github.com/openjdk/jdk/pull/2200/commits/f6fb01b24f525e578692a1c6f2ff0a55b8233576is ThreadWXEnable allows optional W^X state change, like `MutexLocker` allows optional locking.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2200
> 

From Alan.Bateman at oracle.com  Fri Mar 12 11:32:12 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Mar 2021 11:32:12 +0000
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
 <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
 <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>
 <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com>
Message-ID: <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com>

On 11/03/2021 15:25, Lance Andersen wrote:
>
> The only reason I included it is for completeness with tar which the 
> jar options were originally derived from.
>
I think it would be surprising to have two GNU-style long options so I 
think we should pick one.? "--dir" seems okay to me and is consistent 
with the other the other JDK tools that extract to a directory (although 
those tools might not be well known). If you prefer "--directory" then I 
think we'll should add it to the other tools and hide "--dir" from the 
usage output.

-Alan

From redestad at openjdk.java.net  Fri Mar 12 12:03:09 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 12 Mar 2021 12:03:09 GMT
Subject: Withdrawn: 8261031: Move some ClassLoader name checking to native/VM
In-Reply-To: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com>
References: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com>
Message-ID: <llpyl_2d9Xs4Y1J6oNjy77d2AjU20Lq6eNRsWeASZJw=.0d66d725-0763-41c0-8d7f-30c42f446ae5@github.com>

On Wed, 3 Feb 2021 12:21:30 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> This patch moves some sanity checking done in ClassLoader.java to the corresponding endpoints in native or VM code.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/2378

From redestad at openjdk.java.net  Fri Mar 12 12:03:07 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 12 Mar 2021 12:03:07 GMT
Subject: RFR: 8261031: Move some ClassLoader name checking to native/VM
 [v3]
In-Reply-To: <wa2Kx9P1qZ461N4UNqLWkUchwR9ddn-EzLxRkb_xwPk=.74669404-c019-440f-88c5-46dc8af0a79f@github.com>
References: <3fZUkpucpgdhZyyWDQ7Hp1oKthgl1ckXBq942wMNwxI=.7a3db0ca-03c0-44f9-ade9-3b4443cc6666@github.com>
 <eoOPiEFCvDPnUFlJlbf0tVtQJrSk0Mq5mCLuh9d5nfc=.b0db0d59-3c82-4763-ad7e-bcd6a92c4bbc@github.com>
 <osogswghChUOUofuCiHsTtggUdAUY2pZEU0mlCoR9lk=.eac6144e-8663-4b8c-863b-712f1ee1a271@github.com>
 <wa2Kx9P1qZ461N4UNqLWkUchwR9ddn-EzLxRkb_xwPk=.74669404-c019-440f-88c5-46dc8af0a79f@github.com>
Message-ID: <Ep6dzh4d_EZZRZMugLpFRnQScTXnwypsKyJYZsOpmpQ=.3fff6aa3-b966-4196-a994-ac22aba8ac56@github.com>

On Fri, 12 Feb 2021 22:48:51 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This more limited cleanup looks good.
>
> This patch changes `JVM_FindLoadedClass` interface to only accept a binary name.   It used to accept both a binary name and internal form.  Most, if not all, JVM entry points take the name of internal name.   So this change makes this JVM entry point inconsistent with others. 
> 
> Looking closer each API that involves `fixClassName` or `verifyXXXClassName`, the JVM entry points called expects the internal form except `JVM_FindLoadedClass` (see details below).   I think a better change is to change the native `JVM_FindLoadedClass` to accept the internal form only and have `findLoadedClass0` method to detect if the name contains '/' or '['.    
> 
> ClassLoader API does not allow loading of an array type whereas `Class::forName` allows to find an array type.  Perhaps `verifyFixClassName` should be renamed like `binaryNameToInternalForm`.   I think we don't need `fixClassname`?
> 
> ClassLoader::defineClass
> - `preDefineClass` checks the name and throws if it contains '/' or '['
> - no name check in `JVM_DefineClassWithSource` and `JVM_LookupDefineClass`
>      which expects the name is of internal form
> 
> native Class::forName0
> - converts the binary name to internal form (i.e. replace '.' with '/') 
> - throw if the name contains '/'
>  - no explicit name check in `JVM_FindClassFromCaller`
> 
> ClassLoader::loadClass
> - calls native `findLoadedClass0` that calls `JVM_FindLoadedClass` which        
>    accepts binary form and converts '.' to '/' but the current implementation
>    accepts both binary name and internal form
> - calls `native findBootstrapClass` which converts '.' to '/' and pass the internal
>    form to `JVM_FindBootstrapClass`.  
> 
> It'd be helpful to document the internal APIs and JVM entry points clearly what it expects for example binary name vs internal form and where it does the validation e.g. Class::forName0 allows array type and native library methods do the name validation.

Abandoning this. Sorry for wasting everyone's time.

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

PR: https://git.openjdk.java.net/jdk/pull/2378

From akozlov at openjdk.java.net  Fri Mar 12 12:17:39 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 12 Mar 2021 12:17:39 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v26]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <ioUfr36PoGR8ir-TiecioR9y0BI2GfmVq_aWST1b5Uc=.f69452f0-4289-4a29-9857-1b833070b80f@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request incrementally with three additional commits since the last revision:

 - Add Azul copyright
 - Update Oracle copyright years
 - Use Thread::current_or_null_safe in SafeFetch

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/f6fb01b2..29991c92

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=25
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=24-25

  Stats: 83 lines in 53 files changed: 41 ins; 0 del; 42 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From lance.andersen at oracle.com  Fri Mar 12 12:18:23 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Fri, 12 Mar 2021 12:18:23 +0000
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
 <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
 <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>
 <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com>
 <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com>
Message-ID: <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com>



On Mar 12, 2021, at 6:32 AM, Alan Bateman <alan.bateman at oracle.com<mailto:alan.bateman at oracle.com>> wrote:

On 11/03/2021 15:25, Lance Andersen wrote:

The only reason I included it is for completeness with tar which the jar options were originally derived from.

I think it would be surprising to have two GNU-style long options so I think we should pick one.  "--dir" seems okay to me and is consistent with the other the other JDK tools that extract to a directory (although those tools might not be well known). If you prefer "--directory" then I think we'll should add it to the other tools and hide "--dir" from the usage output.

I don?t have a strong preference but lean slightly towards ?-directory? as it is more descriptive, similar to the other GNU-style commands jar currently supports .  Tar supports ??cd?, ??directory? in addition to ?-C? which is why I suggested supporting  both GNU-style long options.

Perhaps jpackage should also support ?dir/directory in addition to ??dest' if we are looking at consistency between java tools.

I do agree that it would be nice to be consistent across the java tools for options so if we go the ?-directory?, we should follow your suggestion and make it the primary and remove ??dir? from the usage output.


-Alan

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>




From vkempik at openjdk.java.net  Fri Mar 12 13:38:17 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Fri, 12 Mar 2021 13:38:17 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v9]
In-Reply-To: <Ei8n5Xqt_Usrtyz-M4AudO6fuOV30FTSG6BCpNXUa2w=.fe6928be-256e-4448-b094-1f7c869e4b26@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <aw_4oHl25elIZ1oM85G6EpWJqswUyBTZRW8qI4UIw44=.d92335ad-c72c-4044-9ca5-cdb046f43697@github.com>
 <RPm5SnkwuGvrhCQxjnsSrdYPjnD4davqtqvkqYKE-tU=.3d4e4c80-0b71-489e-8ba0-2c4a6668e9c4@github.com>
 <Ymv3QSLaT5H6CuKXfwuUkep_PKnO3Zj54kSQA0jcc6s=.59dc4d6d-a8d0-4016-8a59-a4d6cb8b57ac@github.com>
 <Ei8n5Xqt_Usrtyz-M4AudO6fuOV30FTSG6BCpNXUa2w=.fe6928be-256e-4448-b094-1f7c869e4b26@github.com>
Message-ID: <YzgtINrzUk1D0dPpOvX2IZyIMhIMC4HqY3FoKtGO6TU=.377dfcb8-98d0-4fc5-ab40-11974e8266d0@github.com>

On Tue, 2 Mar 2021 08:12:10 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> I wasn't able to replicate JDK-8020753 and JDK-8186286. So will remove these workaround
>> @gerard-ziemski, 8020753 was originally your fix, do you know if it still needed on intel-mac ?
>
> The x86_bsd still carries the workaround https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/bsd_x86/os_bsd_x86.cpp#L745. It's worth having macos ports to be aligned by features. I would propose to have this workaround for now, and decide on it later for macos/x86 and macos/aarch64 at once. Sorry for chiming in so late.

Hello Anton.
Please keep JDK-8020753 away from this port, as JDK-8020753 was very intel-specific workaround and macos11.0 on aarch64 doesn't show any signs of original bug.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From plevart at openjdk.java.net  Fri Mar 12 13:26:07 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 12 Mar 2021 13:26:07 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v2]
In-Reply-To: <8601DNFkEWL76jjuZpNosikeT-1L6fsoz9yf5B79uoU=.bfb92ddd-63d8-44b3-84b6-c73413ab342f@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <8601DNFkEWL76jjuZpNosikeT-1L6fsoz9yf5B79uoU=.bfb92ddd-63d8-44b3-84b6-c73413ab342f@github.com>
Message-ID: <gLGKOnXo8i_FuwF2ahIwi6zlGzdzoZfXvyu9g3-BoWk=.3ff679bc-c900-4220-89bf-e3cf83a2bada@github.com>

On Wed, 10 Mar 2021 02:15:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed patch for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8263108?
>> 
>> As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and `java.lang.constant.ConstantDescs` can end up in a classloading deadlock due to the nature of the code involved in their static blocks. A thread dump of one such deadlock (reproduced using the code attached to that issue) is as follows:
>> 
>> "Thread A" #14 prio=5 os_prio=31 cpu=101.45ms elapsed=8.30s tid=0x00007ff88e01ca00 nid=0x6003 in Object.wait()  [0x000070000a4c6000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.DynamicConstantDesc.<clinit>(java.base at 16-ea/DynamicConstantDesc.java:67)
>> 	- waiting on the Class initialization monitor for java.lang.constant.ConstantDescs
>> 	at Deadlock.threadA(Deadlock.java:14)
>> 	at Deadlock$$Lambda$1/0x0000000800c00a08.run(Unknown Source)
>> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
>> 
>> "Thread B" #15 prio=5 os_prio=31 cpu=103.15ms elapsed=8.30s tid=0x00007ff88b936a00 nid=0x9b03 in Object.wait()  [0x000070000a5c9000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.ClassDesc.ofDescriptor(java.base at 16-ea/ClassDesc.java:145)
>> 	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc
>> 	at java.lang.constant.ConstantDescs.<clinit>(java.base at 16-ea/ConstantDescs.java:239)
>> 	at Deadlock.threadB(Deadlock.java:24)
>> 	at Deadlock$$Lambda$2/0x0000000800c00c28.run(Unknown Source)
>> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
>> 
>> The commit in this PR resolves that deadlock by moving the `canonicalMap` initialization in `DynamicConstantDesc`, from the static block, to a lazily initialized map, into the `tryCanonicalize` (private) method of the same class. That's the only method which uses this map.
>> 
>> The implementation in `tryCanonicalize` carefully ensures that the deadlock isn't shifted from the static block to this method, by making sure that the `synchronization` on `DynamicConstantDesc` in this method happens only when it's time to write the state to the shared `canonicalMap`. This has an implication that the method local variable `canonDescs` can get initialized by multiple threads unnecessarily but from what I can see, that's the only way we can avoid this deadlock. This penalty of multiple threads initializing and then throwing away that map isn't too huge because that will happen only once when the `canonicalMap` is being initialized for the first time.
>> 
>> An alternate approach that I thought of was to completely get rid of this shared cache `canonicalMap` and instead just use method level map (that gets initialized each time) in the `tryCanonicalize` method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.
>> 
>> The commit in this PR also includes a jtreg testcase which (consistently) reproduces the deadlock without the fix and passes when this fix is applied. Extra manual testing has been done to verify that the classes of interest (noted in that testcase) are indeed getting loaded in those concurrent threads and not in the main thread. For future maintainers, there's a implementation note added on that testcase explaining why it cannot be moved into testng test.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Follow Peter Levart's review suggestion - remove volatile

This looks good to me. Maybe if you wanted the previous performance back (when the `cannonicalMap` field was static final and therefore JIT could constant-fold the Map instance), you could now annotate the field with `@Stable` annotation to allow JIT to produce similar code. I would also move the `Map.ofEntries(...)` expression into a separate private static method since I believe it has substantial bytecode size. `tryCanonicalize()` method bytecode size would then more likely fall below the inlining threshold.

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From shade at openjdk.java.net  Fri Mar 12 13:31:16 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Fri, 12 Mar 2021 13:31:16 GMT
Subject: RFR: 8263509: LdapSchemaParser.readNextTag checks array length
 incorrectly
Message-ID: <l0_dFxE_8RDDQwx-dKwZcQ1D6B0UH1ZV8eUNAcpZ0Ic=.fab957ad-257f-427f-a228-2afbd50a00d6@github.com>

SonarCloud rightfully says:
  The length of "values" is always ">=0", so update this test to either "==0" or ">0".

        // make sure at least one value was returned
        if(values.length < 0) { // <--- here
            throw new InvalidAttributeValueException("no values for " +
                                                     "attribute "" +
                                                     tagName + """);
        }

There is a subsequent access to values[0], which means the failure would throw `AIOOB`, not `InvalidAttributeValueException`.

Additional testing:
 - [x] Linux x86_64 fastdebug, `com/sun/jndi`

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

Commit messages:
 - 8263509: LdapSchemaParser.readNextTag checks array length incorrectly

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

PR: https://git.openjdk.java.net/jdk/pull/2968

From akozlov at openjdk.java.net  Fri Mar 12 14:10:18 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 12 Mar 2021 14:10:18 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v25]
In-Reply-To: <gKoH7dS4tYmoRme7Wzbg1mH0ygHFKlaTQgS_JiIE_8A=.96b62223-ef50-43f5-9db1-d150e449e1b9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <f8RkGXsdhtld9TcoCNLInUUxZpFYleWuR5VIl3CqVs0=.1776f22d-a62b-4f8d-8fc6-0a43b8353e1c@github.com>
 <gKoH7dS4tYmoRme7Wzbg1mH0ygHFKlaTQgS_JiIE_8A=.96b62223-ef50-43f5-9db1-d150e449e1b9@github.com>
Message-ID: <ZSTPk6hVzz7glzH2jZYiRfbEJ0IYKpjWJFpPJ1evnJg=.09ce1d0a-a175-40e7-9005-c1b701f73154@github.com>

On Thu, 11 Mar 2021 20:28:46 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8262903: [macos_aarch64] Thread::current() called on detached thread
>
> Marked as reviewed by stefank (Reviewer).

> you still need to use Thread::current_or_null_safe() [for SafeFetch].

OK :) I fixed this in https://github.com/openjdk/jdk/pull/2200/commits/fd4812e585e0528010a8863df50956a3b64a6744

@dcubed-ojdk, I also updated copyrights, this concludes fixes for the review https://github.com/openjdk/jdk/pull/2200#pullrequestreview-581784107.

@theRealAph, could you elaborate on what is need to be done for https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066.

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From chegar at openjdk.java.net  Fri Mar 12 14:56:11 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 12 Mar 2021 14:56:11 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v2]
In-Reply-To: <gLGKOnXo8i_FuwF2ahIwi6zlGzdzoZfXvyu9g3-BoWk=.3ff679bc-c900-4220-89bf-e3cf83a2bada@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <8601DNFkEWL76jjuZpNosikeT-1L6fsoz9yf5B79uoU=.bfb92ddd-63d8-44b3-84b6-c73413ab342f@github.com>
 <gLGKOnXo8i_FuwF2ahIwi6zlGzdzoZfXvyu9g3-BoWk=.3ff679bc-c900-4220-89bf-e3cf83a2bada@github.com>
Message-ID: <BaNG8I3A5tjrXTveKKV9N7EpB1dZmjvVBnhd229zrx0=.a3b25438-34d2-46f4-8f62-40f1b2b8d454@github.com>

On Fri, 12 Mar 2021 13:23:39 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Follow Peter Levart's review suggestion - remove volatile
>
> This looks good to me. Maybe if you wanted the previous performance back (when the `cannonicalMap` field was static final and therefore JIT could constant-fold the Map instance), you could now annotate the field with `@Stable` annotation to allow JIT to produce similar code. I would also move the `Map.ofEntries(...)` expression into a separate private static method since I believe it has substantial bytecode size. `tryCanonicalize()` method bytecode size would then more likely fall below the inlining threshold.

What you have is probably fine, but has any consideration been given to using the initialization-on-demand holder idiom? e.g.

     static private class CanonicalMapHolder {
        static final Map<MethodHandleDesc, Function<DynamicConstantDesc<?>, ConstantDesc>> CANONICAL_MAP
              = Map.ofEntries(..);
     }

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From redestad at openjdk.java.net  Fri Mar 12 13:32:17 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 12 Mar 2021 13:32:17 GMT
Subject: RFR: 8263508: Remove dead code in MethodHandleImpl
Message-ID: <YF2pmiSguRiaE9wznG13pveAZvQKo_CbbrsFgdtBRzM=.fc5242e3-9471-4597-9eee-e4b7835a211e@github.com>

Remove unused methods.

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

Commit messages:
 - Revert assertSame removal (used from InvokerByteCodeGenerator)
 - Remove dead code in MethodHandleImpl

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

PR: https://git.openjdk.java.net/jdk/pull/2969

From alanb at openjdk.java.net  Fri Mar 12 14:31:07 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 12 Mar 2021 14:31:07 GMT
Subject: RFR: 8263509: LdapSchemaParser.readNextTag checks array length
 incorrectly
In-Reply-To: <l0_dFxE_8RDDQwx-dKwZcQ1D6B0UH1ZV8eUNAcpZ0Ic=.fab957ad-257f-427f-a228-2afbd50a00d6@github.com>
References: <l0_dFxE_8RDDQwx-dKwZcQ1D6B0UH1ZV8eUNAcpZ0Ic=.fab957ad-257f-427f-a228-2afbd50a00d6@github.com>
Message-ID: <ujzcpKTLDv_gxB-3-E4WLPUVy46uSPGMQsYwmMxc3no=.035023e6-cada-4b46-99b9-7c8efcdf25b2@github.com>

On Fri, 12 Mar 2021 13:25:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud rightfully says:
>   The length of "values" is always ">=0", so update this test to either "==0" or ">0".
> 
>         // make sure at least one value was returned
>         if(values.length < 0) { // <--- here
>             throw new InvalidAttributeValueException("no values for " +
>                                                      "attribute "" +
>                                                      tagName + """);
>         }
> 
> There is a subsequent access to values[0], which means the failure would throw `AIOOB`, not `InvalidAttributeValueException`.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `com/sun/jndi`

This looks right but I'm surprised it isn't caught by tests (@AlekseiEfimov - do you have suggests for tests that would be useful to add here?)

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

PR: https://git.openjdk.java.net/jdk/pull/2968

From aph at openjdk.java.net  Fri Mar 12 16:35:23 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 12 Mar 2021 16:35:23 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]
In-Reply-To: <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
Message-ID: <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>

On Tue, 9 Mar 2021 16:12:36 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:
> 
>  - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
>  - workaround JDK-8262895 by disabling subtest
>  - Fix typo
>  - Rename threadWXSetters.hpp -> threadWXSetters.inline.hpp
>  - JDK-8259937: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Fix after JDK-8259539, partially revert preconditions
>  - JDK-8260471: bsd_aarch64 part
>  - JDK-8259539: bsd_aarch64 part
>  - JDK-8257828: bsd_aarch64 part
>  - ... and 95 more: https://git.openjdk.java.net/jdk/compare/a6e34b3d...a72f6834

> @theRealAph, could you elaborate on what is need to be done for [#2200 (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).

I think that what you've got now is fine.

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

Marked as reviewed by aph (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2200

From herrick at openjdk.java.net  Fri Mar 12 16:13:36 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 12 Mar 2021 16:13:36 GMT
Subject: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations
Message-ID: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>

implementation of
JDK-8256145: JEP 398: Deprecate the Applet API for Removal

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

Commit messages:
 - 8189198: Add "forRemoval = true" to Applet API deprecations

Changes: https://git.openjdk.java.net/jdk/pull/2920/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2920&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8189198
  Stats: 74 lines in 22 files changed: 14 ins; 0 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2920.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2920/head:pull/2920

PR: https://git.openjdk.java.net/jdk/pull/2920

From stuefe at openjdk.java.net  Fri Mar 12 16:13:16 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 12 Mar 2021 16:13:16 GMT
Subject: RFR: 8263509: LdapSchemaParser.readNextTag checks array length
 incorrectly
In-Reply-To: <l0_dFxE_8RDDQwx-dKwZcQ1D6B0UH1ZV8eUNAcpZ0Ic=.fab957ad-257f-427f-a228-2afbd50a00d6@github.com>
References: <l0_dFxE_8RDDQwx-dKwZcQ1D6B0UH1ZV8eUNAcpZ0Ic=.fab957ad-257f-427f-a228-2afbd50a00d6@github.com>
Message-ID: <jvFM-MYm3iBf7GdEJmjHq7WekLOtOWtS6vkp-ecLxHg=.7828375d-dab3-40fd-8d7a-6f8b4b9ed1ef@github.com>

On Fri, 12 Mar 2021 13:25:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud rightfully says:
>   The length of "values" is always ">=0", so update this test to either "==0" or ">0".
> 
>         // make sure at least one value was returned
>         if(values.length < 0) { // <--- here
>             throw new InvalidAttributeValueException("no values for " +
>                                                      "attribute "" +
>                                                      tagName + """);
>         }
> 
> There is a subsequent access to values[0], which means the failure would throw `AIOOB`, not `InvalidAttributeValueException`.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `com/sun/jndi`

Seems fine. Lets hope no caller relies on this throwing AIOOBE. 

..Thomas

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

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2968

From asemenyuk at openjdk.java.net  Fri Mar 12 17:58:18 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 12 Mar 2021 17:58:18 GMT
Subject: RFR: 8263536: Add missing @compile tags to jpackage tests
Message-ID: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>

8263536: Add missing @compile tags to jpackage tests

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

Commit messages:
 - 8263536: Add missing @compile tags to jpackage tests

Changes: https://git.openjdk.java.net/jdk/pull/2975/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2975&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263536
  Stats: 15 lines in 14 files changed: 13 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2975.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2975/head:pull/2975

PR: https://git.openjdk.java.net/jdk/pull/2975

From aph at openjdk.java.net  Fri Mar 12 16:35:24 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Fri, 12 Mar 2021 16:35:24 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]
In-Reply-To: <v33sSQcIVsvidIkYzaOsIhkjNhojCVastBXuUJJ67IM=.9123e430-657f-4c24-a201-4f457232c983@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
 <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>
 <v33sSQcIVsvidIkYzaOsIhkjNhojCVastBXuUJJ67IM=.9123e430-657f-4c24-a201-4f457232c983@github.com>
Message-ID: <SXXcMmMTXbltmXqeaDgF6g8EJvECwqtlNokXpNJ0CNI=.f358e952-3186-4503-a632-834ec4343c6d@github.com>

On Tue, 9 Mar 2021 18:01:11 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp line 62:
>> 
>>> 60: 
>>> 61: #if defined(__APPLE__) || defined(_WIN64)
>>> 62: #define R18_RESERVED
>> 
>> #define R18_RESERVED true```
>
> We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?

Robustness, clarity, maintainability, convention. Why not?

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Fri Mar 12 16:44:38 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Fri, 12 Mar 2021 16:44:38 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v27]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <TRklBppvcFXK3TUe1dkT2FCn2b9m57pRFAGHR-Vt-8U=.13d4dcc9-deb4-4227-95ec-d9c7a8fc279d@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

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

  Fix most of issues in java/foreign/ tests
  
  Failures related to va_args are tracked in JDK-8263512.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2200/files
  - new: https://git.openjdk.java.net/jdk/pull/2200/files/29991c92..5bfe0f08

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=26
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=25-26

  Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From chegar at openjdk.java.net  Fri Mar 12 17:41:11 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 12 Mar 2021 17:41:11 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v3]
In-Reply-To: <6tewcd6fbSvTdow5ApGEkvVlDCmn6z9NQLnXE_ntH3Q=.ce2ba4c9-ef2a-4630-8622-8a7aefd93870@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <6tewcd6fbSvTdow5ApGEkvVlDCmn6z9NQLnXE_ntH3Q=.ce2ba4c9-ef2a-4630-8622-8a7aefd93870@github.com>
Message-ID: <tvF63A3GU78kXg4Xr-GftwJG6jzUZfK0honst1dE2iA=.9670320a-dda8-4058-b80c-471e2c5ba4fd@github.com>

On Thu, 11 Mar 2021 16:42:24 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263358: Refactored equals methods

src/java.base/share/classes/java/lang/ProcessHandleImpl.java line 525:

> 523:             return (pid == other.pid) &&
> 524:                     (startTime == other.startTime
> 525:                         || startTime == 0

This one can be a single expression. Otherwise, looks good.

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From iris at openjdk.java.net  Fri Mar 12 18:20:06 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 12 Mar 2021 18:20:06 GMT
Subject: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <ZSNT5qc_BugwWIZl4x2ueqQObQFJgUQ6jzi5TZTrPhg=.57cc693b-41f8-43f2-92fb-f7c9d6b4d493@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2920

From jlaskey at openjdk.java.net  Fri Mar 12 19:05:28 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 12 Mar 2021 19:05:28 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v29]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <O5L69Nsq2lIdwdQsilifdVHEFkiq3Gozt_-snw-89lo=.d7e3867a-79bf-48b8-af19-f0c73a4d8380@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 63 commits:

 - Review requested changes
 - Merge branch 'master' into 8248862
 - Remove conflicts
 - Use isAnnotationPresent
 - Introduce isDeprecated
 - Update javadoc
 - Merge branch 'master' into 8248862
 - Adjust ThreadLocalRandom javadoc inheritence
 - L32X64StarStarRandom -> L32X64MixRandom
 - Various corrects
 - ... and 53 more: https://git.openjdk.java.net/jdk/compare/273f8bdf...e5b87227

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

Changes: https://git.openjdk.java.net/jdk/pull/1292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=28
  Stats: 13827 lines in 26 files changed: 11646 ins; 1849 del; 332 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

PR: https://git.openjdk.java.net/jdk/pull/1292

From jkuhn at openjdk.java.net  Fri Mar 12 17:00:07 2021
From: jkuhn at openjdk.java.net (Johannes Kuhn)
Date: Fri, 12 Mar 2021 17:00:07 GMT
Subject: RFR: 8263508: Remove dead code in MethodHandleImpl
In-Reply-To: <YF2pmiSguRiaE9wznG13pveAZvQKo_CbbrsFgdtBRzM=.fc5242e3-9471-4597-9eee-e4b7835a211e@github.com>
References: <YF2pmiSguRiaE9wznG13pveAZvQKo_CbbrsFgdtBRzM=.fc5242e3-9471-4597-9eee-e4b7835a211e@github.com>
Message-ID: <iAbYedE3D7zazCfR5WCw1Cgwft4PTCW3Fo4CD49MQyw=.66fb28a4-4d28-4cd3-9d74-ed9b328ad514@github.com>

On Fri, 12 Mar 2021 13:27:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Remove unused methods.

LGTM

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

Marked as reviewed by jkuhn (Author).

PR: https://git.openjdk.java.net/jdk/pull/2969

From iignatyev at openjdk.java.net  Fri Mar 12 23:16:08 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 12 Mar 2021 23:16:08 GMT
Subject: Integrated: 8263412: ClassFileInstaller can't be used by classes
 outside of default package
In-Reply-To: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
References: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
Message-ID: <l15ZNjVg8ZFzigmDWVK5uFbQxf7H66k-tU1pgYTM6zE=.a64bc9c0-f2d3-4db6-ab8c-9a42a804e050@github.com>

On Thu, 11 Mar 2021 05:47:00 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? 
> to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls  `jdk.test.lib.helpers. ClassFileInstaller::main`. 
> 
> from JBS:
>> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. 
>> 
>> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl.
>>
>> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129).
> 
> testing:
> - [x] `:jdk_core` against `{macos,windows,linux}-x64`
> - [x] `:jdk_svc` against `{macos,windows,linux}-x64`
> - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64`
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: e834f99d
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e834f99d
Stats:     472 lines in 114 files changed: 145 ins; 229 del; 98 mod

8263412: ClassFileInstaller can't be used by classes outside of default package

Reviewed-by: iklam, coleenp, mseledtsov

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

PR: https://git.openjdk.java.net/jdk/pull/2932

From iignatyev at openjdk.java.net  Fri Mar 12 23:16:06 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 12 Mar 2021 23:16:06 GMT
Subject: RFR: 8263412: ClassFileInstaller can't be used by classes outside
 of default package
In-Reply-To: <QhECb_U8iKcmnrdo8XuOpA1vGxpnusjuMVBo5X78Tq0=.53dc142a-f365-43dd-92b9-4ab22df68499@github.com>
References: <UHCEvPvTuTw75Lwzs763iCkp0I-2YnwOCt3V7yZxvPk=.a15d9bf6-1385-46d8-889f-a227e0d2f9e2@github.com>
 <QhECb_U8iKcmnrdo8XuOpA1vGxpnusjuMVBo5X78Tq0=.53dc142a-f365-43dd-92b9-4ab22df68499@github.com>
Message-ID: <fiFhFmTFqI0VwtDvIlfzFd-yvzzZNmYGO4T7y16tsMk=.36069165-be2a-4fe9-9518-36a0d5dd0507@github.com>

On Fri, 12 Mar 2021 02:08:09 GMT, Mikhailo Seledtsov <mseledtsov at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review the patch which moves `ClassFileInstaller` class to `jdk.test.lib.helpers` package? 
>> to reduce changes in the tests, `ClassFileInstaller` in the default package is kept w/ just `main` method that calls  `jdk.test.lib.helpers. ClassFileInstaller::main`. 
>> 
>> from JBS:
>>> ClassFileInstaller is in the default package hence it's impossible to use it directly by classes in any other package. although ClassFileInstaller is mainly used directly from jtreg test description, there are cases when one needs to use it in another "driver" class (e.g. to reduce boilerplate), yet to do. that these driver classes have to either be in a default package or use reflection, both approaches have drawbacks. 
>>> 
>>> to solve that, we can move ClassFileInstaller implementation to a package, and to avoid unneeded churn, keep package-less ClassFileInstaller class which will call package-full impl.
>>>
>>> the need for this patch has raised as part of [JDK-8254129](https://bugs.openjdk.java.net/browse/JDK-8254129).
>> 
>> testing:
>> - [x] `:jdk_core` against `{macos,windows,linux}-x64`
>> - [x] `:jdk_svc` against `{macos,windows,linux}-x64`
>> - [x] `test/hotspot/jtreg` w/o `applications` and `vmTestbase` directories against `{macos,windows,linux}-x64`
>> 
>> Thanks,
>> -- Igor
>
> Marked as reviewed by mseledtsov (Committer).

Ioi, Coleen, Misha, thanks for your reviews.

-- Igor

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

PR: https://git.openjdk.java.net/jdk/pull/2932

From almatvee at openjdk.java.net  Sat Mar 13 00:45:06 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Sat, 13 Mar 2021 00:45:06 GMT
Subject: RFR: 8263536: Add missing @compile tags to jpackage tests
In-Reply-To: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
Message-ID: <4d-qaQFSR7FDwmiS880pi1Lj6UFfCzoEL2RxrORNL9g=.ed6734b8-0049-4edd-8f5d-add3d1c316bd@github.com>

On Fri, 12 Mar 2021 17:52:30 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8263536: Add missing @compile tags to jpackage tests

Marked as reviewed by almatvee (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2975

From almatvee at openjdk.java.net  Sat Mar 13 00:46:07 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Sat, 13 Mar 2021 00:46:07 GMT
Subject: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

Marked as reviewed by almatvee (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2920

From asemenyuk at openjdk.java.net  Sat Mar 13 00:51:19 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Sat, 13 Mar 2021 00:51:19 GMT
Subject: RFR: 8263536: Add missing @compile tags to jpackage tests [v2]
In-Reply-To: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
Message-ID: <ooB29iVuRdxt3fLeso4Sv-z2Ob6gFpgnUqY2_DWkNs4=.f7939815-271f-4367-9dbc-229ba2076183@github.com>

> 8263536: Add missing @compile tags to jpackage tests

Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8263536: Add missing @compile tags to jpackage tests

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

Changes: https://git.openjdk.java.net/jdk/pull/2975/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2975&range=01
  Stats: 15 lines in 14 files changed: 13 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2975.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2975/head:pull/2975

PR: https://git.openjdk.java.net/jdk/pull/2975

From kcr at openjdk.java.net  Sat Mar 13 00:55:08 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Sat, 13 Mar 2021 00:55:08 GMT
Subject: RFR: 8263536: Add missing @compile tags to jpackage tests [v2]
In-Reply-To: <4d-qaQFSR7FDwmiS880pi1Lj6UFfCzoEL2RxrORNL9g=.ed6734b8-0049-4edd-8f5d-add3d1c316bd@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
 <4d-qaQFSR7FDwmiS880pi1Lj6UFfCzoEL2RxrORNL9g=.ed6734b8-0049-4edd-8f5d-add3d1c316bd@github.com>
Message-ID: <TYQeeY2FEvGA8B2G1YWj9Uwe70EiSnlJLArASDiudyw=.6d106a29-ae21-4450-94d0-95f7bf494ecd@github.com>

On Sat, 13 Mar 2021 00:42:13 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:
>> 
>>   8263536: Add missing @compile tags to jpackage tests
>
> Marked as reviewed by almatvee (Committer).

Since you are removing the problem listing, would it be better to use the parent bug ID -- 8263474 -- rather than a sub-task? How do you plan to resolve the parent bug? Manually as "Delivered"? Something else?

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

PR: https://git.openjdk.java.net/jdk/pull/2975

From vdyakov at openjdk.java.net  Sat Mar 13 01:02:05 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Sat, 13 Mar 2021 01:02:05 GMT
Subject: RFR: 8263536: Add missing @compile tags to jpackage tests [v2]
In-Reply-To: <TYQeeY2FEvGA8B2G1YWj9Uwe70EiSnlJLArASDiudyw=.6d106a29-ae21-4450-94d0-95f7bf494ecd@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
 <4d-qaQFSR7FDwmiS880pi1Lj6UFfCzoEL2RxrORNL9g=.ed6734b8-0049-4edd-8f5d-add3d1c316bd@github.com>
 <TYQeeY2FEvGA8B2G1YWj9Uwe70EiSnlJLArASDiudyw=.6d106a29-ae21-4450-94d0-95f7bf494ecd@github.com>
Message-ID: <_UzPs-4Wb7DQnyW7nmVaNPuNFamzhklo3qwD1ioawzY=.49be50a3-2d98-438a-97a6-e299dc259f69@github.com>

On Sat, 13 Mar 2021 00:52:44 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Marked as reviewed by almatvee (Committer).
>
> Since you are removing the problem listing, would it be better to use the parent bug ID -- 8263474 -- rather than a sub-task? How do you plan to resolve the parent bug? Manually as "Delivered"? Something else?

..and deproblemlist mach5 failed tests

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

PR: https://git.openjdk.java.net/jdk/pull/2975

From iignatyev at openjdk.java.net  Sat Mar 13 04:38:48 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 13 Mar 2021 04:38:48 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split
Message-ID: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>

Hi all,

could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used).

from JBS:
> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. 

testing:
- [x]  `grep ' ClassFileInstaller[^.]`
- [ ] tier1-3

Thanks,
-- Igor

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

Commit messages:
 - fixup
 - update copyright year
 - rm test/lib/ClassFileInstaller.java
 - 's/ ClassFileInstaller / jdk.test.lib.helpers.ClassFileInstaller /g'

Changes: https://git.openjdk.java.net/jdk/pull/2985/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2985&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263549
  Stats: 1736 lines in 867 files changed: 0 ins; 67 del; 1669 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2985.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2985/head:pull/2985

PR: https://git.openjdk.java.net/jdk/pull/2985

From iignatyev at openjdk.java.net  Sat Mar 13 04:42:08 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 13 Mar 2021 04:42:08 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split
In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
Message-ID: <dEaJYzwXo6IiFslhETMamL51NDQcfBQ7BCfiE_ccsvk=.f5062de3-b0bb-459b-9391-e3bb44a73b33@github.com>

On Sat, 13 Mar 2021 04:31:31 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used).
> 
> from JBS:
>> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. 
> 
> testing:
> - [x]  `grep ' ClassFileInstaller[^.]`
> - [ ] tier1-3
> 
> Thanks,
> -- Igor

note for reviewers: the big part of the patch is just `sed -i  's/ ClassFileInstaller / jdk.test.lib.helpers.ClassFileInstaller /g'`

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

PR: https://git.openjdk.java.net/jdk/pull/2985

From dholmes at openjdk.java.net  Sat Mar 13 05:52:22 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sat, 13 Mar 2021 05:52:22 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v27]
In-Reply-To: <TRklBppvcFXK3TUe1dkT2FCn2b9m57pRFAGHR-Vt-8U=.13d4dcc9-deb4-4227-95ec-d9c7a8fc279d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <TRklBppvcFXK3TUe1dkT2FCn2b9m57pRFAGHR-Vt-8U=.13d4dcc9-deb4-4227-95ec-d9c7a8fc279d@github.com>
Message-ID: <FB2pev3OL8y-AYtFw1i8n3Np5ny9bYb8wdduqVtiXhA=.84f450cc-6891-4a0b-a84d-1abb8a2eaf00@github.com>

On Fri, 12 Mar 2021 16:44:38 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix most of issues in java/foreign/ tests
>   
>   Failures related to va_args are tracked in JDK-8263512.

src/hotspot/share/runtime/safefetch.inline.hpp line 35:

> 33: inline int SafeFetch32(int* adr, int errValue) {
> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
> 35:   Thread* thread = Thread::current_or_null_safe();

Sorry but this should be MACOS_AARCH64 only. All three lines need to be ifdef'd if you are going to include the assertion.

Thanks,
David

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From iklam at openjdk.java.net  Sat Mar 13 06:19:06 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 13 Mar 2021 06:19:06 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split
In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
Message-ID: <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com>

On Sat, 13 Mar 2021 04:31:31 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used).
> 
> from JBS:
>> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. 
> 
> testing:
> - [x]  `grep ' ClassFileInstaller[^.]`
> - [ ] tier1-3
> 
> Thanks,
> -- Igor

I did this and scanned the differences (with the diff file from the webrev) and it looks reasonable to me.

grep '^[+-]' diff.txt | grep -v Copyright | grep -v '^.[+-]' | less

It looks like most of the changes are mechanical. There were only a few cases where manual changes were made. I trusted that you have tested those cases individually.

But I don't understand why this error can happen. It seems like jtreg would allow two test cases to interfere with each other.

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2985

From iignatyev at openjdk.java.net  Sat Mar 13 06:30:00 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 13 Mar 2021 06:30:00 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split [v2]
In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
Message-ID: <At8rU6AnwStuhNrALmVmVvxaqOvNe-PqnnddIqLkOB4=.66b0d17b-6f4f-4cf8-b6bf-a5592f9a46e3@github.com>

> Hi all,
> 
> could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used).
> 
> from JBS:
>> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. 
> 
> testing:
> - [x]  `grep ' ClassFileInstaller[^.]`
> - [ ] tier1-3
> 
> Thanks,
> -- Igor

Igor Ignatyev has updated the pull request incrementally with one additional commit since the last revision:

  fix compilation error in IncorrectAOTLibraryTest test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2985/files
  - new: https://git.openjdk.java.net/jdk/pull/2985/files/6e53ad97..ff6d4f91

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2985&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2985&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2985

From iignatyev at openjdk.java.net  Sat Mar 13 06:44:12 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 13 Mar 2021 06:44:12 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split [v3]
In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
Message-ID: <c3UIWUcXOnH5Hd_Th0_YIiKCTklnxTtWFyPOC6QfCpQ=.dae1c7f3-0f63-4047-9df9-79ab0e2306f8@github.com>

> Hi all,
> 
> could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used).
> 
> from JBS:
>> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. 
> 
> testing:
> - [x]  `grep ' ClassFileInstaller[^.]`
> - [ ] tier1-3
> 
> Thanks,
> -- Igor

Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  fix compilation error in IncorrectAOTLibraryTest test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2985/files
  - new: https://git.openjdk.java.net/jdk/pull/2985/files/ff6d4f91..3a3b7a84

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2985&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2985&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/2985

From iignatyev at openjdk.java.net  Sat Mar 13 06:44:13 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 13 Mar 2021 06:44:13 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split [v3]
In-Reply-To: <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
 <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com>
Message-ID: <FmxUanOC2tsK13CBu-bdeJ6gziFttKoyMFipgjTdAEM=.c1bc20fa-7173-44ae-8ea6-60bbc2ac5b6d@github.com>

On Sat, 13 Mar 2021 06:16:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   fix compilation error in IncorrectAOTLibraryTest test
>
> I did this and scanned the differences (with the diff file from the webrev) and it looks reasonable to me.
> 
> grep '^[+-]' diff.txt | grep -v Copyright | grep -v '^.[+-]' | less
> 
> It looks like most of the changes are mechanical. There were only a few cases where manual changes were made. I trusted that you have tested those cases individually.
> 
> But I don't understand why this error can happen. It seems like jtreg would allow two test cases to interfere with each other.

Hi Ioi,

thanks for review this, I ran the whole tier1-3 jobs which should provide enough coverage. as oracle builds don't have AOT feature enabled, I missed a compilation error in `IncorrectAOTLibraryTest` test. the test failed in GitHub action and should be fixed by [3a3b7a8](https://github.com/openjdk/jdk/pull/2985/commits/3a3b7a846289181b466b3c1eb478a0a571d9468b).

-- Igor

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

PR: https://git.openjdk.java.net/jdk/pull/2985

From iklam at openjdk.java.net  Sat Mar 13 07:14:09 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 13 Mar 2021 07:14:09 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split [v3]
In-Reply-To: <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
 <2ydx9TUT868fiCQNxF6IaEsq9toXBiDJjJK3GqWRREE=.77fc9c8d-efed-47e8-8f53-02255da6e97e@github.com>
Message-ID: <uz8GwSfLLDJa8FwDhUBymXo4YkgbnT59TEjSYdHv15Y=.7cc79134-b687-477b-8e72-7dc65cfa8ef7@github.com>

On Sat, 13 Mar 2021 06:16:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> But I don't understand why this error can happen. It seems like jtreg would allow two test cases to interfere with each other.

The root cause seems to be https://bugs.openjdk.java.net/browse/CODETOOLS-7902847

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

PR: https://git.openjdk.java.net/jdk/pull/2985

From iklam at openjdk.java.net  Sat Mar 13 08:41:13 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Sat, 13 Mar 2021 08:41:13 GMT
Subject: RFR: 8263536: Add missing @compile tags to jpackage tests [v2]
In-Reply-To: <ooB29iVuRdxt3fLeso4Sv-z2Ob6gFpgnUqY2_DWkNs4=.f7939815-271f-4367-9dbc-229ba2076183@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
 <ooB29iVuRdxt3fLeso4Sv-z2Ob6gFpgnUqY2_DWkNs4=.f7939815-271f-4367-9dbc-229ba2076183@github.com>
Message-ID: <_A2MzMPm-ueagZbFm1_ea9c5uKJNKU1pqzmq3SQPCnQ=.0440bf7d-a5b2-4aa9-a35a-18085c70e4f6@github.com>

On Sat, 13 Mar 2021 00:51:19 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> 8263536: Add missing @compile tags to jpackage tests
>
> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   8263536: Add missing @compile tags to jpackage tests

Changes requested by iklam (Reviewer).

test/jdk/tools/jpackage/windows/WinDirChooserTest.java line 44:

> 42:  * @requires (os.family == "windows")
> 43:  * @modules jdk.jpackage/jdk.jpackage.internal
> 44:  * @compile WinDirChooserTest.java

Changes like this one is not necessary. `@run` will build WinDirChooserTest automatically.

`@compile` should be added only when necessary, like WinInstallerUiTest.java

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

PR: https://git.openjdk.java.net/jdk/pull/2975

From orionllmain at gmail.com  Sat Mar 13 09:07:05 2021
From: orionllmain at gmail.com (Zheka Kozlov)
Date: Sat, 13 Mar 2021 16:07:05 +0700
Subject: java.io.Serial vs java.io.Serializable javadoc
Message-ID: <CAF2POUdV1E16Qonk-OE5E4Y48UMawdrU-SD+Z-i7v79TsW9YZg@mail.gmail.com>

Hi!

The javadoc of java.io.Serial [1] says that serialVersionUID is private.
But the javadoc of Serializable [2] says it can have any access modifier.
Who is right here? When I write the following code, should there be a
warning or not?

import java.io.Serial;import java.io.Serializable;
public class SerExample implements Serializable {
    @Serial // warning or not?
    public static final long serialVersionUID = 2L;}


This question originated in this [3] discussion in the IDEA bugtracker.

With best regards, Zheka.

[1]
https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/io/Serial.html
[2]
https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/io/Serializable.html
[3] https://youtrack.jetbrains.com/issue/IDEA-230392

From github.com+471021+marschall at openjdk.java.net  Sat Mar 13 14:22:38 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Sat, 13 Mar 2021 14:22:38 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v8]
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <eV_83X_XKECqfNt8aDpPrKtV3sLyY7kmGfR7kIsbR_4=.e0d0585a-2c84-4774-ad1e-aa79cb90376c@github.com>

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

Philippe Marschall has updated the pull request incrementally with three additional commits since the last revision:

 - Fix bug in CharArrayReader and add unit test
 - Clean up unit tests
 - Revert off-heap code path

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1915/files
  - new: https://git.openjdk.java.net/jdk/pull/1915/files/fc29f3e6..5fa832b1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=06-07

  Stats: 134 lines in 5 files changed: 100 ins; 19 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915

PR: https://git.openjdk.java.net/jdk/pull/1915

From dcubed at openjdk.java.net  Sat Mar 13 14:23:08 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Sat, 13 Mar 2021 14:23:08 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split [v3]
In-Reply-To: <c3UIWUcXOnH5Hd_Th0_YIiKCTklnxTtWFyPOC6QfCpQ=.dae1c7f3-0f63-4047-9df9-79ab0e2306f8@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
 <c3UIWUcXOnH5Hd_Th0_YIiKCTklnxTtWFyPOC6QfCpQ=.dae1c7f3-0f63-4047-9df9-79ab0e2306f8@github.com>
Message-ID: <HflI5BUCqXAwVWrhyNcQFIwzvsdBUcUX7AB6Xp5RxQU=.5439c807-612d-4c01-b502-6e075ca70ab2@github.com>

On Sat, 13 Mar 2021 06:44:12 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used).
>> 
>> from JBS:
>>> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. 
>> 
>> testing:
>> - [x]  `grep ' ClassFileInstaller[^.]`
>> - [ ] tier1-3
>> 
>> Thanks,
>> -- Igor
>
> Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

I downloaded the patch and used Ioi's cmd pattern to scroll through
the changes. I can't honestly say that I looked at every line since 867
changed files would overwhelm anyone's brain...

I did notice a couple of `@run main` instead of `@run driver` calls
to the ClassFileInstaller, but those are pre-existing.

Thumbs up.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2985

From github.com+10835776+stsypanov at openjdk.java.net  Sat Mar 13 14:27:17 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sat, 13 Mar 2021 14:27:17 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversion in
 ObjectStreamClass
Message-ID: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>

This is a very simple and trivial improvement about getting rid of pointless char wrapping into array

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

Commit messages:
 - Fix other occurences
 - Use String.valueOf() for char-to-String conversion in ObjectStreamClass

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From github.com+741251+turbanoff at openjdk.java.net  Sat Mar 13 14:27:17 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Sat, 13 Mar 2021 14:27:17 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversion
 in ObjectStreamClass
In-Reply-To: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
Message-ID: <o8Og6cc_d0IksrIINM8m6ssjltxk3zEtueFPM7OO5eE=.a8f2c693-a1ba-49c9-8288-86bff6d8b2be@github.com>

On Sat, 20 Feb 2021 12:17:32 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array

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

I think it's worth to cleanup other places with similar code too.
I found 6 places in JDK codebase:
![???????????](https://user-images.githubusercontent.com/741251/109499351-d6fc8d00-7aa5-11eb-9306-a70cb6754d55.png)

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From github.com+10835776+stsypanov at openjdk.java.net  Sat Mar 13 14:27:17 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sat, 13 Mar 2021 14:27:17 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversion
 in ObjectStreamClass
In-Reply-To: <o8Og6cc_d0IksrIINM8m6ssjltxk3zEtueFPM7OO5eE=.a8f2c693-a1ba-49c9-8288-86bff6d8b2be@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <o8Og6cc_d0IksrIINM8m6ssjltxk3zEtueFPM7OO5eE=.a8f2c693-a1ba-49c9-8288-86bff6d8b2be@github.com>
Message-ID: <hCZNS33bg-mcr_ncNEahEeqn20MjUtdAjPR6nWln3MM=.687608ff-f188-473e-a6f7-39bce313cd26@github.com>

On Mon, 1 Mar 2021 12:50:35 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> I think it's worth to cleanup other places with similar code too.

Done

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From ccleary at openjdk.java.net  Sat Mar 13 14:27:18 2021
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Sat, 13 Mar 2021 14:27:18 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversion
 in ObjectStreamClass
In-Reply-To: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
Message-ID: <372Xgh6uNFLbqika1TXdVN1frfL4POjbF9z8CMYOEnQ=.86cc768b-3247-4340-b436-5ecf6692d974@github.com>

On Sat, 20 Feb 2021 12:17:32 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array

src/java.base/share/classes/java/io/ObjectStreamClass.java line 833:

> 831:             String fname = in.readUTF();
> 832:             String signature = ((tcode == 'L') || (tcode == '[')) ?
> 833:                 in.readTypeString() : String.valueOf(tcode);

Certainly more readable and it seems that the call to valueOf is equivalent to whay takes place with the original code. I can't see any difference semantically or performance-wise at a glance. LGTM

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From github.com+10835776+stsypanov at openjdk.java.net  Sat Mar 13 14:27:19 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sat, 13 Mar 2021 14:27:19 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversion
 in ObjectStreamClass
In-Reply-To: <372Xgh6uNFLbqika1TXdVN1frfL4POjbF9z8CMYOEnQ=.86cc768b-3247-4340-b436-5ecf6692d974@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <372Xgh6uNFLbqika1TXdVN1frfL4POjbF9z8CMYOEnQ=.86cc768b-3247-4340-b436-5ecf6692d974@github.com>
Message-ID: <ygTA5Fa7GkO_GmCOIeKcyR5lrd9MkM4OK4CQgmKUHds=.f5f03d89-dda2-4f34-88db-a467480b357a@github.com>

On Mon, 22 Feb 2021 12:04:14 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array
>
> src/java.base/share/classes/java/io/ObjectStreamClass.java line 833:
> 
>> 831:             String fname = in.readUTF();
>> 832:             String signature = ((tcode == 'L') || (tcode == '[')) ?
>> 833:                 in.readTypeString() : String.valueOf(tcode);
> 
> Certainly more readable and it seems that the call to valueOf is equivalent to whay takes place with the original code. I can't see any difference semantically or performance-wise at a glance. LGTM

@c-cleary Thanks for review. The difference is about intermediate array: `String.valueOf()` doesn't allocate it being slightly faster and less memory-consuming.

Could you file an issue to track this? I'm not an Oracle employee and not able to do it myself.

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From yyang at openjdk.java.net  Sat Mar 13 14:27:19 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sat, 13 Mar 2021 14:27:19 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversion
 in ObjectStreamClass
In-Reply-To: <372Xgh6uNFLbqika1TXdVN1frfL4POjbF9z8CMYOEnQ=.86cc768b-3247-4340-b436-5ecf6692d974@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <372Xgh6uNFLbqika1TXdVN1frfL4POjbF9z8CMYOEnQ=.86cc768b-3247-4340-b436-5ecf6692d974@github.com>
Message-ID: <h49awIwaD_Sy-PLPurIe1-7atskiqKv8BTMqWjVS3vs=.f61ff209-4c2c-4438-9558-57298da1c2e8@github.com>

On Mon, 22 Feb 2021 12:04:14 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array
>
> src/java.base/share/classes/java/io/ObjectStreamClass.java line 833:
> 
>> 831:             String fname = in.readUTF();
>> 832:             String signature = ((tcode == 'L') || (tcode == '[')) ?
>> 833:                 in.readTypeString() : String.valueOf(tcode);
> 
> Certainly more readable and it seems that the call to valueOf is equivalent to whay takes place with the original code. I can't see any difference semantically or performance-wise at a glance. LGTM

Nice cleanup. I can help file a JBS issue if @c-cleary doesn't notice your comment.

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From github.com+10835776+stsypanov at openjdk.java.net  Sat Mar 13 14:27:20 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sat, 13 Mar 2021 14:27:20 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversion
 in ObjectStreamClass
In-Reply-To: <h49awIwaD_Sy-PLPurIe1-7atskiqKv8BTMqWjVS3vs=.f61ff209-4c2c-4438-9558-57298da1c2e8@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <372Xgh6uNFLbqika1TXdVN1frfL4POjbF9z8CMYOEnQ=.86cc768b-3247-4340-b436-5ecf6692d974@github.com>
 <h49awIwaD_Sy-PLPurIe1-7atskiqKv8BTMqWjVS3vs=.f61ff209-4c2c-4438-9558-57298da1c2e8@github.com>
Message-ID: <g9qBtcqE1JoHufcrcMYNoZ9MIrVHSt8OEfvtYvkG-fg=.ee89518f-fcae-41df-94e7-b426ed047012@github.com>

On Sat, 13 Mar 2021 03:12:32 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/ObjectStreamClass.java line 833:
>> 
>>> 831:             String fname = in.readUTF();
>>> 832:             String signature = ((tcode == 'L') || (tcode == '[')) ?
>>> 833:                 in.readTypeString() : String.valueOf(tcode);
>> 
>> Certainly more readable and it seems that the call to valueOf is equivalent to whay takes place with the original code. I can't see any difference semantically or performance-wise at a glance. LGTM
>
> Nice cleanup. I can help file a JBS issue if @c-cleary doesn't notice your comment.

@kelthuzadx hi! I'd appreciate this, as there's no JBS issue for this (

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From yyang at openjdk.java.net  Sat Mar 13 14:27:20 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sat, 13 Mar 2021 14:27:20 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversion
 in ObjectStreamClass
In-Reply-To: <g9qBtcqE1JoHufcrcMYNoZ9MIrVHSt8OEfvtYvkG-fg=.ee89518f-fcae-41df-94e7-b426ed047012@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <372Xgh6uNFLbqika1TXdVN1frfL4POjbF9z8CMYOEnQ=.86cc768b-3247-4340-b436-5ecf6692d974@github.com>
 <h49awIwaD_Sy-PLPurIe1-7atskiqKv8BTMqWjVS3vs=.f61ff209-4c2c-4438-9558-57298da1c2e8@github.com>
 <g9qBtcqE1JoHufcrcMYNoZ9MIrVHSt8OEfvtYvkG-fg=.ee89518f-fcae-41df-94e7-b426ed047012@github.com>
Message-ID: <QBLHoxtb4oEjHuPBePruZrpBQNvslSkd0I200ClGqQE=.07edce35-850b-4f2c-a491-8ee28ff02c84@github.com>

On Sat, 13 Mar 2021 11:35:48 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Nice cleanup. I can help file a JBS issue if @c-cleary doesn't notice your comment.
>
> @kelthuzadx hi! I'd appreciate this, as there's no JBS issue for this (

Hi @stsypanov, I've created it https://bugs.openjdk.java.net/browse/JDK-8263552. Good luck :-)

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From github.com+10835776+stsypanov at openjdk.java.net  Sat Mar 13 14:27:20 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sat, 13 Mar 2021 14:27:20 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversion
 in ObjectStreamClass
In-Reply-To: <QBLHoxtb4oEjHuPBePruZrpBQNvslSkd0I200ClGqQE=.07edce35-850b-4f2c-a491-8ee28ff02c84@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <372Xgh6uNFLbqika1TXdVN1frfL4POjbF9z8CMYOEnQ=.86cc768b-3247-4340-b436-5ecf6692d974@github.com>
 <h49awIwaD_Sy-PLPurIe1-7atskiqKv8BTMqWjVS3vs=.f61ff209-4c2c-4438-9558-57298da1c2e8@github.com>
 <g9qBtcqE1JoHufcrcMYNoZ9MIrVHSt8OEfvtYvkG-fg=.ee89518f-fcae-41df-94e7-b426ed047012@github.com>
 <QBLHoxtb4oEjHuPBePruZrpBQNvslSkd0I200ClGqQE=.07edce35-850b-4f2c-a491-8ee28ff02c84@github.com>
Message-ID: <cWFNpGdzy00ypHTHV6joaaBc74nfSpnHro8G6-2RSDE=.73adede5-9e1f-45ae-87c1-474f79fefaf5@github.com>

On Sat, 13 Mar 2021 12:16:57 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> @kelthuzadx hi! I'd appreciate this, as there's no JBS issue for this (
>
> Hi @stsypanov, I've created it https://bugs.openjdk.java.net/browse/JDK-8263552. Good luck :-)

Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From github.com+471021+marschall at openjdk.java.net  Sat Mar 13 14:28:26 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Sat, 13 Mar 2021 14:28:26 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]
In-Reply-To: <cZvuz7rqH6oCKMQZIWGTlS4gbaNil4LlNaoU1NcwE-w=.3a08ce05-02fa-4bcb-8d73-d404f0fe592f@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <u8q3xImge2DoQ4pbYtaZx89g-5vINdfZuB7TJTl7-jI=.68124acf-f23b-46f7-9cf4-8d2717e7009e@github.com>
 <cZvuz7rqH6oCKMQZIWGTlS4gbaNil4LlNaoU1NcwE-w=.3a08ce05-02fa-4bcb-8d73-d404f0fe592f@github.com>
Message-ID: <JPqzxNykL_j6WPta-YXlkMmbqIYtoF2cKPYVnwVA0qE=.6bc86489-ffa9-4e9a-9c27-df2141915d25@github.com>

On Tue, 16 Feb 2021 23:50:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Replace c-style array declarations
>>  - Share work buffer between #skip and #read
>
> test/jdk/java/io/InputStreamReader/ReadCharBuffer.java line 34:
> 
>> 32: import org.testng.annotations.Test;
>> 33: 
>> 34: import java.io.*;
> 
> It's generally better not to use a wild card.

Done

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

PR: https://git.openjdk.java.net/jdk/pull/1915

From github.com+471021+marschall at openjdk.java.net  Sat Mar 13 14:28:25 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Sat, 13 Mar 2021 14:28:25 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v9]
In-Reply-To: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
Message-ID: <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>

> Implement three optimiztations for Reader.read(CharBuffer)
> 
> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.

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

 - Merge master
 - Fix bug in CharArrayReader and add unit test
 - Clean up unit tests
 - Revert off-heap code path
 - Replace c-style array declarations
 - Share work buffer between #skip and #read
 - Update copyright year
 - Implement review comment
 - Revert StreamDecoder changes
 - Implement CharArrayReader#read(CharBuffer)
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d339320e...c4c859e0

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

Changes: https://git.openjdk.java.net/jdk/pull/1915/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1915&range=08
  Stats: 371 lines in 6 files changed: 361 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1915.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1915/head:pull/1915

PR: https://git.openjdk.java.net/jdk/pull/1915

From github.com+471021+marschall at openjdk.java.net  Sat Mar 13 14:33:07 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Sat, 13 Mar 2021 14:33:07 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]
In-Reply-To: <cZvuz7rqH6oCKMQZIWGTlS4gbaNil4LlNaoU1NcwE-w=.3a08ce05-02fa-4bcb-8d73-d404f0fe592f@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <u8q3xImge2DoQ4pbYtaZx89g-5vINdfZuB7TJTl7-jI=.68124acf-f23b-46f7-9cf4-8d2717e7009e@github.com>
 <cZvuz7rqH6oCKMQZIWGTlS4gbaNil4LlNaoU1NcwE-w=.3a08ce05-02fa-4bcb-8d73-d404f0fe592f@github.com>
Message-ID: <ldCoy3o2fYCYwo-9_1zqKV2sB5rccaSY0CCsg-_ZzQk=.1631aaa0-6221-41be-acb8-1e538886de5a@github.com>

On Tue, 16 Feb 2021 23:52:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Philippe Marschall has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Replace c-style array declarations
>>  - Share work buffer between #skip and #read
>
> test/jdk/java/io/InputStreamReader/ReadCharBuffer.java line 73:
> 
>> 71:         }
>> 72: 
>> 73:         buffer.clear();
> 
> I think `buffer.rewind()` would be more in keeping with the specification verbiage although there will be no practical effect here. Same comment applies below and in the other test `ReadCharBuffer`.

`buffer.rewind()` would not work in this specific case as it does not reset the limit. I want to assert the entire buffers content to make sure the method didn't accidentally write where it shouldn't have. Therefore limit needs to be set to capacity.

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

PR: https://git.openjdk.java.net/jdk/pull/1915

From github.com+471021+marschall at openjdk.java.net  Sat Mar 13 14:33:08 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Sat, 13 Mar 2021 14:33:08 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v7]
In-Reply-To: <ccNpuYEQ4J-igWvxBK36eAWY7GWRCf0FcZyeYgYsvN8=.d8c1e57a-e145-4270-b948-cf676b5d61a7@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <u8q3xImge2DoQ4pbYtaZx89g-5vINdfZuB7TJTl7-jI=.68124acf-f23b-46f7-9cf4-8d2717e7009e@github.com>
 <pteinqoQqYmWLjX6qjyhIVl3MMqyQxcoKSsIMlF9XK8=.3a55575e-2d76-4692-9b2f-9acaf874f05b@github.com>
 <GKi4tkOIYe--ZT77birhG2W9jPJf3m23xwEmgNvN6Ug=.c20a1072-0ebe-4f27-84de-83d4f647bf5e@github.com>
 <ccNpuYEQ4J-igWvxBK36eAWY7GWRCf0FcZyeYgYsvN8=.d8c1e57a-e145-4270-b948-cf676b5d61a7@github.com>
Message-ID: <7-5p_NwXkjFzYt2IJquxXXtxSG7IGgVSUrOpJyvg2Sk=.f43bec66-33bc-413c-b2d0-e9d6f8e18454@github.com>

On Fri, 19 Feb 2021 07:34:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I think that's what @AlanBateman intended. The `skip()` changes would revert also (I think) but the C-style array changes can stay. Thanks.
>
> Yes, let's bring it back to just eliminating the intermediate array when the buffer has a backing array. The other case that been examined separated if needed but we can't use the approach proposed in the current PR because it changes the semantics of read when there is a short-read followed by a blocking or exception throwing read.

Done

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

PR: https://git.openjdk.java.net/jdk/pull/1915

From github.com+471021+marschall at openjdk.java.net  Sat Mar 13 14:43:07 2021
From: github.com+471021+marschall at openjdk.java.net (Philippe Marschall)
Date: Sat, 13 Mar 2021 14:43:07 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer)
In-Reply-To: <Wi1oVqQQU2X7y_jCkhKBgiU9b41jTIHyimz5YFUntgw=.f66745a3-95a8-4986-b1df-dd873a829427@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <4qIH_bGcy898jYpAfO_Ahwpv63-gDAcA-XEQX-O30pg=.8ad77702-353c-4c6b-8010-1b89f729c691@github.com>
 <FhXV1UKPiHE7wey3jjBBJjQzLpKZPhe5aD4sGKneMz0=.16c382e1-b55c-4d63-8538-4e68adfca109@github.com>
 <Wi1oVqQQU2X7y_jCkhKBgiU9b41jTIHyimz5YFUntgw=.f66745a3-95a8-4986-b1df-dd873a829427@github.com>
Message-ID: <P8SvYYoQHyWbRw20r-0kJO0eJtMy5pL7zhmpgqj5HZw=.ebef09a9-a705-4e91-9e07-148c62bc1442@github.com>

On Tue, 16 Feb 2021 23:49:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I think the implementation changes here look good. I don't know however whether there is enough coverage in the tests. These should verify that the `Reader`, `CharArrayReader`, and `InputStreamReader` implementations of `read(CharBuffer)` are accurate. If there is already sufficient coverage in the tests in `test/jdk/java/io` then that is good enough and nothing need be added.

`CharArrayReader` was lacking a test. I added a test which found a bug and fixed the bug. The PR also contains new tests for `Reader` and `InputStreamReader`. They cover on-heap and off-heap cases.

Is there a way to get test coverage with JTReg tests? I only found [1] which seems out of date and points to an Oracle internal wiki.

 [1] https://wiki.openjdk.java.net/display/CodeTools/JCov+FAQ#JCovFAQ-HowdoIuseJCovwithjtreg?

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

PR: https://git.openjdk.java.net/jdk/pull/1915

From herrick at openjdk.java.net  Sat Mar 13 14:45:22 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Sat, 13 Mar 2021 14:45:22 GMT
Subject: RFR: JDK-8263154: [macos] DMG builds have finder errors
Message-ID: <q_q2hdnvfEfyo76kIREN-tRxST60tLWyUYvOh3Xipws=.9e37f1ba-fa6f-4914-94bf-fa94c5de2b47@github.com>

JDK-8263154: [macos] DMG builds have finder errors

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

Commit messages:
 - JDK-8263154: [macos] DMG builds have finder errors

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

PR: https://git.openjdk.java.net/jdk/pull/2987

From iignatyev at openjdk.java.net  Sat Mar 13 14:56:06 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 13 Mar 2021 14:56:06 GMT
Subject: RFR: 8263549:  8263412 can cause jtreg testlibrary split [v3]
In-Reply-To: <HflI5BUCqXAwVWrhyNcQFIwzvsdBUcUX7AB6Xp5RxQU=.5439c807-612d-4c01-b502-6e075ca70ab2@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
 <c3UIWUcXOnH5Hd_Th0_YIiKCTklnxTtWFyPOC6QfCpQ=.dae1c7f3-0f63-4047-9df9-79ab0e2306f8@github.com>
 <HflI5BUCqXAwVWrhyNcQFIwzvsdBUcUX7AB6Xp5RxQU=.5439c807-612d-4c01-b502-6e075ca70ab2@github.com>
Message-ID: <cWG4uOCEDr5X77Jm1uCxyw-Z1jjgtU4JUsieDCX1py0=.c6cea055-3a06-4a73-aa82-53fe44e0fd77@github.com>

On Sat, 13 Mar 2021 14:20:20 GMT, Daniel D. Daugherty <dcubed at openjdk.org> wrote:

>> Igor Ignatyev has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.
>
> I downloaded the patch and used Ioi's cmd pattern to scroll through
> the changes. I can't honestly say that I looked at every line since 867
> changed files would overwhelm anyone's brain...
> 
> I did notice a couple of `@run main` instead of `@run driver` calls
> to the ClassFileInstaller, but those are pre-existing.
> 
> Thumbs up.

Hi Dan,

Thanks for your review!

> I did notice a couple of @run main instead of @run driver calls to the ClassFileInstaller, but those are pre-existing.

I noticed this too, planning to fix that with a separate RFE.

-- Igor

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

PR: https://git.openjdk.java.net/jdk/pull/2985

From iignatyev at openjdk.java.net  Sat Mar 13 14:56:07 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 13 Mar 2021 14:56:07 GMT
Subject: Integrated: 8263549:  8263412 can cause jtreg testlibrary split
In-Reply-To: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
References: <68VznhnTGY9ALWqvXzAulGxWtvI5-z2ljGj8zy07SKc=.1b9ef93b-f288-4e96-8ea7-b7080c93fa4f@github.com>
Message-ID: <_mpUEh9QVZbxsshQP1hNQlstVSmOwqImgOwhZV4lvIQ=.f49472ae-9d8e-4058-beb8-77e0f7b4fd3a@github.com>

On Sat, 13 Mar 2021 04:31:31 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this dull patch that replaces `ClassFileInstaller` w/ `jdk.test.lib.helpers.ClassFileInstaller` in all jtreg test descriptions to ensure we won't get split testlibrary, and removes `jdk/test/lib/ClassFileInstaller.java` (so it won't be accidentally used).
> 
> from JBS:
>> after JDK-8263412, we might (again) encounter NCDFE b/c parts of testlibraries aren't on the classpath. this happens when jtreg builds `jdk.test.lib.helpers.ClassFileInstaller` as a part of test-specific code, but `ClassFileInstaller` as part of shared testibrary directory in one test, when in the following test, jtreg sees `ClassFileInstaller` in the shared directory, hence javac won't recompile it/its dependencies, but in runtime `jdk.test.lib.helpers.ClassFileInstaller` is nowhere to be found, hence we get NCDFE. 
> 
> testing:
> - [x]  `grep ' ClassFileInstaller[^.]`
> - [ ] tier1-3
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: a7aba2b6
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a7aba2b6
Stats:     1738 lines in 867 files changed: 2 ins; 67 del; 1669 mod

8263549: 8263412 can cause jtreg testlibrary split

Reviewed-by: iklam, dcubed

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

PR: https://git.openjdk.java.net/jdk/pull/2985

From redestad at openjdk.java.net  Sat Mar 13 15:22:08 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sat, 13 Mar 2021 15:22:08 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversion
 in ObjectStreamClass
In-Reply-To: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
Message-ID: <mPDSY0J8ZkHazzBv6PWN4HPt-uuvx0FIyTGOVKvgjUU=.f3e27cbe-8a04-494a-9d67-06d48512d897@github.com>

On Sat, 20 Feb 2021 12:17:32 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array

LGTM

src/java.base/share/classes/java/io/ObjectStreamClass.java line 833:

> 831:             String fname = in.readUTF();
> 832:             String signature = ((tcode == 'L') || (tcode == '[')) ?
> 833:                 in.readTypeString() : String.valueOf(tcode);

Since the result of String.valueOf here will be equal to one of the primitive signatures strings ("I", "J", ...) (otherwise ObjectStreamField will throw an exception) it might make sense to turn this into a switch expression and simplify the whole thing. I can't tell how performance sensitive this piece of code is, though.

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

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2660

From github.com+10835776+stsypanov at openjdk.java.net  Sat Mar 13 15:56:08 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sat, 13 Mar 2021 15:56:08 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversion
 in ObjectStreamClass
In-Reply-To: <mPDSY0J8ZkHazzBv6PWN4HPt-uuvx0FIyTGOVKvgjUU=.f3e27cbe-8a04-494a-9d67-06d48512d897@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <mPDSY0J8ZkHazzBv6PWN4HPt-uuvx0FIyTGOVKvgjUU=.f3e27cbe-8a04-494a-9d67-06d48512d897@github.com>
Message-ID: <VuzFbMSi1PtToBmHe1GaotOCzne8plEczAVShPtnu2o=.286a0ba5-38fa-4588-9b30-6127c45ddc10@github.com>

On Sat, 13 Mar 2021 15:18:59 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array
>
> src/java.base/share/classes/java/io/ObjectStreamClass.java line 833:
> 
>> 831:             String fname = in.readUTF();
>> 832:             String signature = ((tcode == 'L') || (tcode == '[')) ?
>> 833:                 in.readTypeString() : String.valueOf(tcode);
> 
> Since the result of String.valueOf here will be equal to one of the primitive signatures strings ("I", "J", ...) (otherwise ObjectStreamField will throw an exception) it might make sense to turn this into a switch expression and simplify the whole thing. I can't tell how performance sensitive this piece of code is, though.

Hi, I'll check and add one more PR if it makes sense

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From mchung at openjdk.java.net  Sat Mar 13 21:02:06 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Sat, 13 Mar 2021 21:02:06 GMT
Subject: RFR: 8263508: Remove dead code in MethodHandleImpl
In-Reply-To: <YF2pmiSguRiaE9wznG13pveAZvQKo_CbbrsFgdtBRzM=.fc5242e3-9471-4597-9eee-e4b7835a211e@github.com>
References: <YF2pmiSguRiaE9wznG13pveAZvQKo_CbbrsFgdtBRzM=.fc5242e3-9471-4597-9eee-e4b7835a211e@github.com>
Message-ID: <LMbigi35BrlEvy-mxRTMMSepQTLkeknebu7UuJkfxW8=.96c7970f-fab7-468d-8999-82a24b0e5980@github.com>

On Fri, 12 Mar 2021 13:27:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Remove unused methods.

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2969

From redestad at openjdk.java.net  Sun Mar 14 00:03:06 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 14 Mar 2021 00:03:06 GMT
Subject: RFR: 8263508: Remove dead code in MethodHandleImpl
In-Reply-To: <iAbYedE3D7zazCfR5WCw1Cgwft4PTCW3Fo4CD49MQyw=.66fb28a4-4d28-4cd3-9d74-ed9b328ad514@github.com>
References: <YF2pmiSguRiaE9wznG13pveAZvQKo_CbbrsFgdtBRzM=.fc5242e3-9471-4597-9eee-e4b7835a211e@github.com>
 <iAbYedE3D7zazCfR5WCw1Cgwft4PTCW3Fo4CD49MQyw=.66fb28a4-4d28-4cd3-9d74-ed9b328ad514@github.com>
Message-ID: <FJBkKyfqgSuQlVGO-eg8YGmsFJK12i4nHySNcxiRyV0=.00d9efe0-cb48-4873-8bbf-6030c836e20b@github.com>

On Fri, 12 Mar 2021 16:57:38 GMT, Johannes Kuhn <jkuhn at openjdk.org> wrote:

>> Remove unused methods.
>
> LGTM

Thanks for reviewing, @DasBrain and @mlchung.

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

PR: https://git.openjdk.java.net/jdk/pull/2969

From redestad at openjdk.java.net  Sun Mar 14 00:05:07 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 14 Mar 2021 00:05:07 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversion
 in ObjectStreamClass
In-Reply-To: <mPDSY0J8ZkHazzBv6PWN4HPt-uuvx0FIyTGOVKvgjUU=.f3e27cbe-8a04-494a-9d67-06d48512d897@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <mPDSY0J8ZkHazzBv6PWN4HPt-uuvx0FIyTGOVKvgjUU=.f3e27cbe-8a04-494a-9d67-06d48512d897@github.com>
Message-ID: <hCj2wgg1ufKSvex73ZhVxHbJo4sxkBdrylwt79bT6yY=.eeec6588-2974-4ce5-bc89-5d30adfc9f30@github.com>

On Sat, 13 Mar 2021 15:19:18 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array
>
> LGTM

I'll sponsor when I'm back to work on Monday, assuming there are no objections.

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From ojdk at player.to  Sun Mar 14 11:00:15 2021
From: ojdk at player.to (Marco)
Date: Sun, 14 Mar 2021 12:00:15 +0100
Subject: Insufficiencies in JEP: 400: UTF-8 by Default
Message-ID: <18156557.eyI8ViUcyn@m>

Hi all,

the JEP generally paints the picture that using the OS charset would be 
incorrect or useless, it is however the right and perfectly valid choice for 
communicating with other local programs where no other charset was specified. 
It is the same as UTF-8 most of the time, but not always and especially not on 
Windows, using UTF-8 every time would be strictly less correct.

Per [1] LC_CTYPE defines the charset to use for transforming between binary 
data and text. Given that the file.encoding system property doesn't exist 
within Java SE, LC_CTYPE combined with the current specification of 
Charset.defaultCharset() is the only compliant way to change the default 
charset in Java SE outside some custom application specific handling. Ignoring 
LC_CTYPE obviously leaves no standard approach. From the program's POV the 
same applies in reverse, currently one could only use Charset.defaultCharset() 
to determine the OS charset or let the java.io methods infer it through the 
charset-less constructors, then potentially read it back through e.g. 
InputStreamReader.getEncoding().

The OS charset is still relevant for text interaction on System.in/out/err, 
sub-process stdin/stdout/stderr and files with unknown encoding. Programs like 
grep assume the files are encoded according to LC_CTYPE, much like a similarly 
designed Java program that uses the OS charset on purpose. Constructing a 
Reader for stdin properly requires some way to determine the relevant OS 
encoding.

I'm perfectly happy with changing the charset-less methods to use UTF-8 since 
it's the best choice outside the above scenarios, despite the compatibility 
impact. Dropping standardized support for the OS charset however not only 
breaks the above interactions, but also leaves no nice migration path. The -
Dfile.encoding=COMPAT workaround is explicitly not standardized and isn't 
available to the Java application itself, only to whoever starts the JVM to 
presumably work around outdated code.

IMO Charset should provide standardized getters for the OS charset and the 
console charset. The latter being different has been a long standing issue on 
Windows where the codepage differs between its CLI and regular environments. 
OpenJDK has the necessary data already available in its custom system 
properties.

The console charset is currently hidden behind PrintStream not exposing the 
underlying OSWriter and not offering getEncoding() itself. The OS charset 
would be hidden in the future by Charset.getDefaultCharset()'s specification 
change in JEP 400.

Please consider the above minor additions to fix those issues for good.

Best regards,

Marco

[1] https://pubs.opengroup.org/onlinepubs/7908799/xbd/envvar.html



From mik3hall at gmail.com  Sun Mar 14 12:01:53 2021
From: mik3hall at gmail.com (Michael Hall)
Date: Sun, 14 Mar 2021 07:01:53 -0500
Subject: RFR: JDK-8263154: [macos] DMG builds have finder errors
In-Reply-To: <q_q2hdnvfEfyo76kIREN-tRxST60tLWyUYvOh3Xipws=.9e37f1ba-fa6f-4914-94bf-fa94c5de2b47@github.com>
References: <q_q2hdnvfEfyo76kIREN-tRxST60tLWyUYvOh3Xipws=.9e37f1ba-fa6f-4914-94bf-fa94c5de2b47@github.com>
Message-ID: <FF1A1CC0-B6B7-4D08-9A6E-40695C9EE5E0@gmail.com>

Thanks

> On Mar 13, 2021, at 8:45 AM, Andy Herrick <herrick at openjdk.java.net> wrote:
> 
> JDK-8263154: [macos] DMG builds have finder errors
> 
> -------------
> 
> Commit messages:
> - JDK-8263154: [macos] DMG builds have finder errors
> 
> Changes: https://git.openjdk.java.net/jdk/pull/2987/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2987&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8263154
>  Stats: 11 lines in 2 files changed: 7 ins; 0 del; 4 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/2987.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2987/head:pull/2987
> 
> PR: https://git.openjdk.java.net/jdk/pull/2987


From Alan.Bateman at oracle.com  Sun Mar 14 12:01:54 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 14 Mar 2021 12:01:54 +0000
Subject: Insufficiencies in JEP: 400: UTF-8 by Default
In-Reply-To: <18156557.eyI8ViUcyn@m>
References: <18156557.eyI8ViUcyn@m>
Message-ID: <633eb370-6252-475c-167b-1d4cb5873dc6@oracle.com>

On 14/03/2021 11:00, Marco wrote:
> :
>
> IMO Charset should provide standardized getters for the OS charset and the
> console charset. The latter being different has been a long standing issue on
> Windows where the codepage differs between its CLI and regular environments.
> OpenJDK has the necessary data already available in its custom system
> properties.
>
> The console charset is currently hidden behind PrintStream not exposing the
> underlying OSWriter and not offering getEncoding() itself. The OS charset
> would be hidden in the future by Charset.getDefaultCharset()'s specification
> change in JEP 400.
The intention that there will be little or no impact to the console 
streams. This means that java.io.Console reader/writer methods should 
continue to return a Reader/PrintWriter that uses the platform encoding 
(or code page is on Windows). Same thing for the System.out/System.err 
print streams. We need to make this clearer in the JEP.

There has been discussion on this mailing list about adding a 
Console::charset method but it didn't come to a consensus. Naoto Sato 
and I have been chatting about it again recently as there may be a need 
to add an API in advance of proposing to target the JEP.

One case that we are still mulling over is code that creates an 
InputStreamReader on System.in without specifying the charset. This 
might be older code that pre-dates java.io.Console or maybe code that 
wasn't tested on a wide range or platforms. Options range from a spec 
change to doing nothing (the latter meaning running with "COMPACT" or 
migrating the code to use the 2-arg constructor as the default charset 
is not the right choice).

-Alan




From alanb at openjdk.java.net  Sun Mar 14 12:09:05 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 14 Mar 2021 12:09:05 GMT
Subject: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations
In-Reply-To: <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
Message-ID: <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>

On Sat, 13 Mar 2021 00:43:33 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Marked as reviewed by almatvee (Committer).

Have you looked at narrowing the use of the SuppressWarnings to local variable declarations to avoid adding it to some of these methods?

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

PR: https://git.openjdk.java.net/jdk/pull/2920

From Alan.Bateman at oracle.com  Sun Mar 14 12:51:35 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 14 Mar 2021 12:51:35 +0000
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
 <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
 <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>
 <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com>
 <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com>
 <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com>
Message-ID: <237e6c14-8593-69df-5866-4a238e020fce@oracle.com>

On 12/03/2021 12:18, Lance Andersen wrote:
>
> :
>
> I don?t have a strong preference but lean slightly towards 
> ?-directory? as it is more descriptive, similar to the other GNU-style 
> commands jar currently supports . ?Tar supports ??cd?, ??directory? in 
> addition to ?-C? which is why I suggested supporting ?both GNU-style 
> long options.
>
> Perhaps jpackage should also support ?dir/directory in addition to 
> ??dest' if we are looking at consistency between java tools.
>
> I do agree that it would be nice to be consistent across the java 
> tools for options so if we go the ?-directory?, we should follow your 
> suggestion and make it the primary and remove ??dir? from the usage 
> output.
My comment on consistency was limited to the long option to specify the 
directory when extracting, didn't mean to suggest doing anything with 
the other tools that specify an output/destination directory. In any 
case, I think we have enough to make progress on this issue now.

-Alan


From alanb at openjdk.java.net  Sun Mar 14 13:00:15 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 14 Mar 2021 13:00:15 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v9]
In-Reply-To: <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>
Message-ID: <84oaCizi9wr-vVk-L4OwgmBH8kdLBx5gzy7pejtfko8=.a3d79db9-f147-450e-8d3c-fc491cfa12fe@github.com>

On Sat, 13 Mar 2021 14:28:25 GMT, Philippe Marschall <github.com+471021+marschall at openjdk.org> wrote:

>> Implement three optimiztations for Reader.read(CharBuffer)
>> 
>> * Add a code path for heap buffers in Reader#read to use the backing array instead of allocating a new one.
>> * Change the code path for direct buffers in Reader#read to limit the intermediate allocation to `TRANSFER_BUFFER_SIZE`.
>> * Implement `InputStreamReader#read(CharBuffer)` and delegate to `StreamDecoder`.
>> * Implement `StreamDecoder#read(CharBuffer)` and avoid buffer allocation.
>
> Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Merge master
>  - Fix bug in CharArrayReader and add unit test
>  - Clean up unit tests
>  - Revert off-heap code path
>  - Replace c-style array declarations
>  - Share work buffer between #skip and #read
>  - Update copyright year
>  - Implement review comment
>  - Revert StreamDecoder changes
>  - Implement CharArrayReader#read(CharBuffer)
>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d339320e...c4c859e0

src/java.base/share/classes/java/io/Reader.java line 205:

> 203:                 target.put(cbuf, 0, nread);
> 204:         }
> 205:         return nread;

Thanks for bringing this back to just the heap buffer case. This part looks good now.

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

PR: https://git.openjdk.java.net/jdk/pull/1915

From jlaskey at openjdk.java.net  Sun Mar 14 14:57:29 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Sun, 14 Mar 2021 14:57:29 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v30]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <t4f2e65wob2ssGPbMOpcfTy3jLuzpgYiNBOVWbaridg=.d9b8ba88-086f-40ae-ac7a-5adee5e6d4e2@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Review revisions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/e5b87227..ddb1a30c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=29
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=28-29

  Stats: 321 lines in 4 files changed: 79 ins; 203 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

PR: https://git.openjdk.java.net/jdk/pull/1292

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 17:09:21 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 17:09:21 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
In-Reply-To: <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
Message-ID: <9WzDHjb3E5Afwj-g73SsX2P2rSbsNk0HCflWjpi0Or4=.55abfbfe-9e91-445c-ad38-7afb169c3365@github.com>

On Sun, 14 Mar 2021 07:51:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
>> 
>> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.
>
> src/java.base/share/classes/jdk/internal/jmod/JmodFile.java line 57:
> 
>> 55:             // validate the header
>> 56:             byte[] magic = new byte[4];
>> 57:             in.read(magic);
> 
> While you are there, this can be changed to magic = in.readNBytes(4) and throw IOException if magic.length != 4.

Done.

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From alanb at openjdk.java.net  Sun Mar 14 17:09:20 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 14 Mar 2021 17:09:20 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
In-Reply-To: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
Message-ID: <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>

On Sat, 13 Mar 2021 22:29:23 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
> 
> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

src/java.base/share/classes/jdk/internal/jmod/JmodFile.java line 57:

> 55:             // validate the header
> 56:             byte[] magic = new byte[4];
> 57:             in.read(magic);

While you are there, this can be changed to magic = in.readNBytes(4) and throw IOException if magic.length != 4.

src/java.base/share/classes/jdk/internal/jmod/JmodFile.java line 58:

> 56:             byte[] magic = in.readNBytes(4);
> 57:             if (magic.length != 4) {
> 58:                 throw new IOException("Header expected to be of length 4, but was " + magic.length);

Thanks for the update. If magic != 4 then it means the file is not a JMOD file or that it has been truncated.

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 17:09:20 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 17:09:20 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
Message-ID: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>

In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.

Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

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

Commit messages:
 - Use InputStream.readNBytes()
 - Drop unnecessary BufferedInputStream-wrapping where possible

Changes: https://git.openjdk.java.net/jdk/pull/2992/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263560
  Stats: 14 lines in 3 files changed: 2 ins; 7 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2992.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2992/head:pull/2992

PR: https://git.openjdk.java.net/jdk/pull/2992

From github.com+7806504+liach at openjdk.java.net  Sun Mar 14 17:10:23 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Sun, 14 Mar 2021 17:10:23 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: <qM2_hboz6gdDK2b146mFO0LrHSDgoji1F15qIHr23yg=.2d891359-4b5b-4e15-99fb-325c32658ff1@github.com>

On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

Are linked lists worse for addition even in cases where addition to array list or deque requires resize and copying? i thought that's the advantage of linked list.

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

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 17:10:23 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 17:10:23 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
Message-ID: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>

The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.

jdk:tier1 and jdk:tier2 are both ok

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

Commit messages:
 - Remove remaining usages of LinkedList in java.base

Changes: https://git.openjdk.java.net/jdk/pull/2744/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2744&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263561
  Stats: 40 lines in 9 files changed: 0 ins; 2 del; 38 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2744.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2744/head:pull/2744

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 17:10:23 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 17:10:23 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <qM2_hboz6gdDK2b146mFO0LrHSDgoji1F15qIHr23yg=.2d891359-4b5b-4e15-99fb-325c32658ff1@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <qM2_hboz6gdDK2b146mFO0LrHSDgoji1F15qIHr23yg=.2d891359-4b5b-4e15-99fb-325c32658ff1@github.com>
Message-ID: <I9rVR_oIdc2Bc7QeD1smsXIU1jJFn5dQI4dzk0FeMBw=.0aeea223-cfea-4155-b960-27118210456d@github.com>

On Fri, 26 Feb 2021 15:32:57 GMT, liach <github.com+7806504+liach at openjdk.org> wrote:

> Are linked lists worse for addition even in cases where addition to array list or deque requires resize and copying? i thought that's the advantage of linked list.

As far as I know `LinkedList` is always worse than `ArrayList` and discouraged from being used.

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

PR: https://git.openjdk.java.net/jdk/pull/2744

From yyang at openjdk.java.net  Sun Mar 14 17:10:24 2021
From: yyang at openjdk.java.net (Yi Yang)
Date: Sun, 14 Mar 2021 17:10:24 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
Message-ID: <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>

On Fri, 26 Feb 2021 10:48:33 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
> 
> jdk:tier1 and jdk:tier2 are both ok

src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 220:

> 218:             return Collections.emptyList();
> 219:         }
> 220:         List<IOException> result = new ArrayList<>();

We'd better be cautious about this replacement since its [caller](https://github.com/openjdk/jdk/blob/73029fe10a8a814a8c5f5221f2e667fd14a5b379/src/java.base/share/classes/java/net/URLClassLoader.java#L363) will remove the first element of this array, that's one of the scenarios where LinkedList usually has better performance than ArrayList.

Just IMHO, I suggest replacing them only if there is a performance improvement(e.g. benchmark reports). Changing field types will break users' existing application code, they might reflectively modify these values.

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

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+7806504+liach at openjdk.java.net  Sun Mar 14 17:10:24 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Sun, 14 Mar 2021 17:10:24 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>
Message-ID: <WXYtwL5kJ19rmoNeVi0yWfKsMZhNzQe_xaAjEq8HkG4=.606a21d6-727b-4d90-874e-b791f1c739a6@github.com>

On Sun, 14 Mar 2021 14:58:11 GMT, Yi Yang <yyang at openjdk.org> wrote:

>> The usage of `LinkedList` is senseless and can be replaced with either `ArrayList` or `ArrayDeque` which are both more compact and effective.
>> 
>> jdk:tier1 and jdk:tier2 are both ok
>
> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 220:
> 
>> 218:             return Collections.emptyList();
>> 219:         }
>> 220:         List<IOException> result = new ArrayList<>();
> 
> We'd better be cautious about this replacement since its [caller](https://github.com/openjdk/jdk/blob/73029fe10a8a814a8c5f5221f2e667fd14a5b379/src/java.base/share/classes/java/net/URLClassLoader.java#L363) will remove the first element of this array, that's one of the scenarios where LinkedList usually has better performance than ArrayList.
> 
> Just IMHO, I suggest replacing them only if there is a performance improvement(e.g. benchmark reports). Changing field types will break users' existing application code, they might reflectively modify these values.

If that's the only use case, I recommend changing the return type to a deque, and replace the linked list with an array deque instead (as done elsewhere in this pr)

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

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 17:21:11 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 17:21:11 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <WXYtwL5kJ19rmoNeVi0yWfKsMZhNzQe_xaAjEq8HkG4=.606a21d6-727b-4d90-874e-b791f1c739a6@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>
 <WXYtwL5kJ19rmoNeVi0yWfKsMZhNzQe_xaAjEq8HkG4=.606a21d6-727b-4d90-874e-b791f1c739a6@github.com>
Message-ID: <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com>

On Sun, 14 Mar 2021 15:02:03 GMT, liach <github.com+7806504+liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 220:
>> 
>>> 218:             return Collections.emptyList();
>>> 219:         }
>>> 220:         List<IOException> result = new ArrayList<>();
>> 
>> We'd better be cautious about this replacement since its [caller](https://github.com/openjdk/jdk/blob/73029fe10a8a814a8c5f5221f2e667fd14a5b379/src/java.base/share/classes/java/net/URLClassLoader.java#L363) will remove the first element of this array, that's one of the scenarios where LinkedList usually has better performance than ArrayList.
>> 
>> Just IMHO, I suggest replacing them only if there is a performance improvement(e.g. benchmark reports). Changing field types will break users' existing application code, they might reflectively modify these values.
>
> If that's the only use case, I recommend changing the return type to a deque, and replace the linked list with an array deque instead (as done elsewhere in this pr)

Looks like it's never specified in JavaDoc which particular implementation of List is used in fields of affected classes, so it's quite odd to me that someone would rely on that when using reflection. But your point about backward compatibility is reasonable, so I'll revert mentioned changes.

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

PR: https://git.openjdk.java.net/jdk/pull/2744

From alanb at openjdk.java.net  Sun Mar 14 17:29:06 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 14 Mar 2021 17:29:06 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>
 <WXYtwL5kJ19rmoNeVi0yWfKsMZhNzQe_xaAjEq8HkG4=.606a21d6-727b-4d90-874e-b791f1c739a6@github.com>
 <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com>
Message-ID: <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com>

On Sun, 14 Mar 2021 17:18:11 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> If that's the only use case, I recommend changing the return type to a deque, and replace the linked list with an array deque instead (as done elsewhere in this pr)
>
> Looks like it's never specified in JavaDoc which particular implementation of List is used in fields of affected classes, so it's quite odd to me that someone would rely on that when using reflection. But your point about backward compatibility is reasonable, so I'll revert mentioned changes.

Nothing outside of the JDK should be hacking into this private field of a non-exposed class, this should not be a concern here.

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

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 17:39:25 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 17:39:25 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v2]
In-Reply-To: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
Message-ID: <7MZ3DNHaLzsGrqQcbUo2l8Uj5hzlRMToZXF9_NoIAB0=.5fedbf9f-bf5d-4712-952f-82a02283d1e4@github.com>

> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
> 
> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

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

  Revert usage of InputStream.readNBytes()

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2992/files
  - new: https://git.openjdk.java.net/jdk/pull/2992/files/4c608737..12505d05

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 17:39:26 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 17:39:26 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v2]
In-Reply-To: <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
Message-ID: <-SbLgW2n90cLQIGHulyofX7nRzvFZxw_Hej14jTbJDQ=.a4942343-3dfb-459c-baed-bad73a1229c5@github.com>

On Sun, 14 Mar 2021 11:16:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert usage of InputStream.readNBytes()
>
> src/java.base/share/classes/jdk/internal/jmod/JmodFile.java line 58:
> 
>> 56:             byte[] magic = in.readNBytes(4);
>> 57:             if (magic.length != 4) {
>> 58:                 throw new IOException("Header expected to be of length 4, but was " + magic.length);
> 
> Thanks for the update. If magic != 4 then it means the file is not a JMOD file or that it has been truncated.

It turned out, that with this latest update some of tier2_tools tests are failing, e.g. `JLinkNegativeTest`:
test JLinkNegativeTest.testMalformedJmod(): failure
java.lang.AssertionError: Output does not fit regexp: Error: java.io.IOException: Invalid JMOD file
	at tests.Result.assertFailure(Result.java:70)
	at JLinkNegativeTest.testMalformedJmod(JLinkNegativeTest.java:201)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
	at org.testng.TestRunner.privateRun(TestRunner.java:773)
	at org.testng.TestRunner.run(TestRunner.java:623)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
	at org.testng.TestNG.run(TestNG.java:1018)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
	at java.base/java.lang.Thread.run(Thread.java:831)
...
java.lang.module.FindException: java.io.IOException: Invalid JMOD file: /home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/test-support/jtreg_test_jdk_tier2/scratch/3/jmods/hacked4.jmod
	at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:253)
	at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190)
	at java.base/jdk.internal.module.ModulePath.find(ModulePath.java:154)
	at java.base/java.lang.module.Resolver.findWithBeforeFinder(Resolver.java:842)
	at java.base/java.lang.module.Resolver.resolve(Resolver.java:119)
	at java.base/java.lang.module.Configuration.resolve(Configuration.java:421)
	at java.base/java.lang.module.Configuration.resolve(Configuration.java:255)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.limitFinder(JlinkTask.java:545)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.newModuleFinder(JlinkTask.java:466)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.initJlinkConfig(JlinkTask.java:374)
	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:267)
	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54)
	at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:65)
	at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:715)
	at tests.Helper.generateDefaultImage(Helper.java:257)
	at tests.Helper.generateDefaultImage(Helper.java:244)
	at JLinkNegativeTest.testSectionsAreFiles(JLinkNegativeTest.java:307)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
	at org.testng.TestRunner.privateRun(TestRunner.java:773)
	at org.testng.TestRunner.run(TestRunner.java:623)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
	at org.testng.TestNG.run(TestNG.java:1018)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
	at java.base/java.lang.Thread.run(Thread.java:831)
Caused by: java.io.IOException: Invalid JMOD file: /home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/test-support/jtreg_test_jdk_tier2/scratch/3/jmods/hacked4.jmod
	at java.base/jdk.internal.jmod.JmodFile.checkMagic(JmodFile.java:62)
	at java.base/jdk.internal.jmod.JmodFile.<init>(JmodFile.java:180)
	at java.base/jdk.internal.module.ModulePath.readJMod(ModulePath.java:392)
	at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:343)
	at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284)
	at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232)
	... 44 more

java.lang.Exception: failures: 1
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
	at java.base/java.lang.Thread.run(Thread.java:831)

So if you don't mind, I'll revert the latest commit

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From alanb at openjdk.java.net  Sun Mar 14 17:43:07 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 14 Mar 2021 17:43:07 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v2]
In-Reply-To: <-SbLgW2n90cLQIGHulyofX7nRzvFZxw_Hej14jTbJDQ=.a4942343-3dfb-459c-baed-bad73a1229c5@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
 <-SbLgW2n90cLQIGHulyofX7nRzvFZxw_Hej14jTbJDQ=.a4942343-3dfb-459c-baed-bad73a1229c5@github.com>
Message-ID: <-D4lEMJ8ZdR4BK89uxgUfXDuoQI9qRsbYW6_5QS2-FY=.7f408f1d-fca1-48a4-b59f-a5fba532b94e@github.com>

On Sun, 14 Mar 2021 17:34:12 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jmod/JmodFile.java line 58:
>> 
>>> 56:             byte[] magic = in.readNBytes(4);
>>> 57:             if (magic.length != 4) {
>>> 58:                 throw new IOException("Header expected to be of length 4, but was " + magic.length);
>> 
>> Thanks for the update. If magic != 4 then it means the file is not a JMOD file or that it has been truncated.
>
> It turned out, that with this latest update some of tier2_tools tests are failing, e.g. `JLinkNegativeTest`:
> test JLinkNegativeTest.testMalformedJmod(): failure
> java.lang.AssertionError: Output does not fit regexp: Error: java.io.IOException: Invalid JMOD file
> 	at tests.Result.assertFailure(Result.java:70)
> 	at JLinkNegativeTest.testMalformedJmod(JLinkNegativeTest.java:201)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
> 	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
> 	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
> 	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
> 	at org.testng.TestRunner.privateRun(TestRunner.java:773)
> 	at org.testng.TestRunner.run(TestRunner.java:623)
> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
> 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
> 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
> 	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
> 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
> 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
> 	at org.testng.TestNG.run(TestNG.java:1018)
> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
> 	at java.base/java.lang.Thread.run(Thread.java:831)
> ...
> java.lang.module.FindException: java.io.IOException: Invalid JMOD file: /home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/test-support/jtreg_test_jdk_tier2/scratch/3/jmods/hacked4.jmod
> 	at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:253)
> 	at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190)
> 	at java.base/jdk.internal.module.ModulePath.find(ModulePath.java:154)
> 	at java.base/java.lang.module.Resolver.findWithBeforeFinder(Resolver.java:842)
> 	at java.base/java.lang.module.Resolver.resolve(Resolver.java:119)
> 	at java.base/java.lang.module.Configuration.resolve(Configuration.java:421)
> 	at java.base/java.lang.module.Configuration.resolve(Configuration.java:255)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.limitFinder(JlinkTask.java:545)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.newModuleFinder(JlinkTask.java:466)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.initJlinkConfig(JlinkTask.java:374)
> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:267)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54)
> 	at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:65)
> 	at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:715)
> 	at tests.Helper.generateDefaultImage(Helper.java:257)
> 	at tests.Helper.generateDefaultImage(Helper.java:244)
> 	at JLinkNegativeTest.testSectionsAreFiles(JLinkNegativeTest.java:307)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
> 	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
> 	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
> 	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
> 	at org.testng.TestRunner.privateRun(TestRunner.java:773)
> 	at org.testng.TestRunner.run(TestRunner.java:623)
> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
> 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
> 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
> 	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
> 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
> 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
> 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
> 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
> 	at org.testng.TestNG.run(TestNG.java:1018)
> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
> 	at java.base/java.lang.Thread.run(Thread.java:831)
> Caused by: java.io.IOException: Invalid JMOD file: /home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/test-support/jtreg_test_jdk_tier2/scratch/3/jmods/hacked4.jmod
> 	at java.base/jdk.internal.jmod.JmodFile.checkMagic(JmodFile.java:62)
> 	at java.base/jdk.internal.jmod.JmodFile.<init>(JmodFile.java:180)
> 	at java.base/jdk.internal.module.ModulePath.readJMod(ModulePath.java:392)
> 	at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:343)
> 	at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284)
> 	at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232)
> 	... 44 more
> 
> java.lang.Exception: failures: 1
> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
> 	at java.base/java.lang.Thread.run(Thread.java:831)
> 
> So if you don't mind, I'll revert the latest commit

JLinkNegativeTest depends on the exception message, it should be easy to update.

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From vtewari at openjdk.java.net  Sun Mar 14 17:48:07 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Sun, 14 Mar 2021 17:48:07 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversion
 in ObjectStreamClass
In-Reply-To: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
Message-ID: <7gdjb_onDfovaFwTFHONcf_r-zYx80Lp13JZmbjx0Gw=.0f0225b1-2fba-43ff-ae80-a754a62372c2@github.com>

On Sat, 20 Feb 2021 12:17:32 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array

LGTM

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

Marked as reviewed by vtewari (Committer).

PR: https://git.openjdk.java.net/jdk/pull/2660

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 18:24:17 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 18:24:17 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>
 <WXYtwL5kJ19rmoNeVi0yWfKsMZhNzQe_xaAjEq8HkG4=.606a21d6-727b-4d90-874e-b791f1c739a6@github.com>
 <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com>
 <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com>
Message-ID: <FnmswLcLaHsAq8Gl6qOAFd2fFFQUaGp14wDcjsmfOog=.6eb4e680-d64c-4774-9bf2-76b7806d48ff@github.com>

On Sun, 14 Mar 2021 17:26:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Looks like it's never specified in JavaDoc which particular implementation of List is used in fields of affected classes, so it's quite odd to me that someone would rely on that when using reflection. But your point about backward compatibility is reasonable, so I'll revert mentioned changes.
>
> Nothing outside of the JDK should be hacking into this private field of a non-exposed class, this should not be a concern here.

@AlanBateman so is it ok to keep `ArrayLists`?

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

PR: https://git.openjdk.java.net/jdk/pull/2744

From igraves at openjdk.java.net  Sun Mar 14 18:28:20 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Sun, 14 Mar 2021 18:28:20 GMT
Subject: RFR: JDK-8263545: Convert jpackage to use Stream.toList()
Message-ID: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>

This converts jpackage to use `Stream.toList()` instead of `Stream.collect(Collectors.toList())`. One piece of code was modified to not mutate a list in addition to one test that used a mutating sort on a list. The rest of the changes are simple substitutions.

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

Commit messages:
 - Converting jpackage to use Stream.toList()

Changes: https://git.openjdk.java.net/jdk/pull/2997/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2997&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263545
  Stats: 47 lines in 17 files changed: 1 ins; 3 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2997.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2997/head:pull/2997

PR: https://git.openjdk.java.net/jdk/pull/2997

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 19:35:25 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 19:35:25 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v3]
In-Reply-To: <-D4lEMJ8ZdR4BK89uxgUfXDuoQI9qRsbYW6_5QS2-FY=.7f408f1d-fca1-48a4-b59f-a5fba532b94e@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
 <-SbLgW2n90cLQIGHulyofX7nRzvFZxw_Hej14jTbJDQ=.a4942343-3dfb-459c-baed-bad73a1229c5@github.com>
 <-D4lEMJ8ZdR4BK89uxgUfXDuoQI9qRsbYW6_5QS2-FY=.7f408f1d-fca1-48a4-b59f-a5fba532b94e@github.com>
Message-ID: <mBzztFpUt7brdGHXQz2gvLsU2GM8xiNI8K8cSESuxKU=.4928c4bf-7cef-4213-92b8-b6cfa63cb889@github.com>

On Sun, 14 Mar 2021 17:40:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> It turned out, that with this latest update some of tier2_tools tests are failing, e.g. `JLinkNegativeTest`:
>> test JLinkNegativeTest.testMalformedJmod(): failure
>> java.lang.AssertionError: Output does not fit regexp: Error: java.io.IOException: Invalid JMOD file
>> 	at tests.Result.assertFailure(Result.java:70)
>> 	at JLinkNegativeTest.testMalformedJmod(JLinkNegativeTest.java:201)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>> 	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>> 	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>> 	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>> 	at org.testng.TestRunner.privateRun(TestRunner.java:773)
>> 	at org.testng.TestRunner.run(TestRunner.java:623)
>> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>> 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>> 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>> 	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>> 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>> 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>> 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>> 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>> 	at org.testng.TestNG.run(TestNG.java:1018)
>> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
>> 	at java.base/java.lang.Thread.run(Thread.java:831)
>> ...
>> java.lang.module.FindException: java.io.IOException: Invalid JMOD file: /home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/test-support/jtreg_test_jdk_tier2/scratch/3/jmods/hacked4.jmod
>> 	at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:253)
>> 	at java.base/jdk.internal.module.ModulePath.scanNextEntry(ModulePath.java:190)
>> 	at java.base/jdk.internal.module.ModulePath.find(ModulePath.java:154)
>> 	at java.base/java.lang.module.Resolver.findWithBeforeFinder(Resolver.java:842)
>> 	at java.base/java.lang.module.Resolver.resolve(Resolver.java:119)
>> 	at java.base/java.lang.module.Configuration.resolve(Configuration.java:421)
>> 	at java.base/java.lang.module.Configuration.resolve(Configuration.java:255)
>> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.limitFinder(JlinkTask.java:545)
>> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.newModuleFinder(JlinkTask.java:466)
>> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.initJlinkConfig(JlinkTask.java:374)
>> 	at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:267)
>> 	at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:54)
>> 	at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:65)
>> 	at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:715)
>> 	at tests.Helper.generateDefaultImage(Helper.java:257)
>> 	at tests.Helper.generateDefaultImage(Helper.java:244)
>> 	at JLinkNegativeTest.testSectionsAreFiles(JLinkNegativeTest.java:307)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85)
>> 	at org.testng.internal.Invoker.invokeMethod(Invoker.java:639)
>> 	at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821)
>> 	at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131)
>> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:125)
>> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108)
>> 	at org.testng.TestRunner.privateRun(TestRunner.java:773)
>> 	at org.testng.TestRunner.run(TestRunner.java:623)
>> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:357)
>> 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352)
>> 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310)
>> 	at org.testng.SuiteRunner.run(SuiteRunner.java:259)
>> 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52)
>> 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86)
>> 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185)
>> 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1110)
>> 	at org.testng.TestNG.run(TestNG.java:1018)
>> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
>> 	at java.base/java.lang.Thread.run(Thread.java:831)
>> Caused by: java.io.IOException: Invalid JMOD file: /home/s.tsypanov/IdeaProjects/jdk-github/build/linux-x86_64-server-release/test-support/jtreg_test_jdk_tier2/scratch/3/jmods/hacked4.jmod
>> 	at java.base/jdk.internal.jmod.JmodFile.checkMagic(JmodFile.java:62)
>> 	at java.base/jdk.internal.jmod.JmodFile.<init>(JmodFile.java:180)
>> 	at java.base/jdk.internal.module.ModulePath.readJMod(ModulePath.java:392)
>> 	at java.base/jdk.internal.module.ModulePath.readModule(ModulePath.java:343)
>> 	at java.base/jdk.internal.module.ModulePath.scanDirectory(ModulePath.java:284)
>> 	at java.base/jdk.internal.module.ModulePath.scan(ModulePath.java:232)
>> 	... 44 more
>> 
>> java.lang.Exception: failures: 1
>> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:78)
>> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:568)
>> 	at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:298)
>> 	at java.base/java.lang.Thread.run(Thread.java:831)
>> 
>> So if you don't mind, I'll revert the latest commit
>
> JLinkNegativeTest depends on the exception message, it should be easy to update.

Done

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From github.com+10835776+stsypanov at openjdk.java.net  Sun Mar 14 19:35:25 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 14 Mar 2021 19:35:25 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v3]
In-Reply-To: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
Message-ID: <JuQsjcKBqVGQAANu4UFRwfDDx0dh8QnvxFBuMhBYvTk=.31eb331e-f0f8-446f-8c8b-4ffd75acd6d7@github.com>

> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
> 
> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

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

  Use InputStream.readNBytes() and fix JLinkNegativeTest

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2992/files
  - new: https://git.openjdk.java.net/jdk/pull/2992/files/12505d05..a016d2ac

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From prr at openjdk.java.net  Sun Mar 14 20:04:08 2021
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 14 Mar 2021 20:04:08 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v3]
In-Reply-To: <JuQsjcKBqVGQAANu4UFRwfDDx0dh8QnvxFBuMhBYvTk=.31eb331e-f0f8-446f-8c8b-4ffd75acd6d7@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <JuQsjcKBqVGQAANu4UFRwfDDx0dh8QnvxFBuMhBYvTk=.31eb331e-f0f8-446f-8c8b-4ffd75acd6d7@github.com>
Message-ID: <qu-3wpCTWHtKie-OZiBFMOUARfH_Y5HBfYJBAtxjh1o=.e77e6651-d64f-44fd-a375-f18206425718@github.com>

On Sun, 14 Mar 2021 19:35:25 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
>> 
>> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use InputStream.readNBytes() and fix JLinkNegativeTest

2d change is fine.

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

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2992

From serb at openjdk.java.net  Sun Mar 14 22:51:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sun, 14 Mar 2021 22:51:10 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v3]
In-Reply-To: <JuQsjcKBqVGQAANu4UFRwfDDx0dh8QnvxFBuMhBYvTk=.31eb331e-f0f8-446f-8c8b-4ffd75acd6d7@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <JuQsjcKBqVGQAANu4UFRwfDDx0dh8QnvxFBuMhBYvTk=.31eb331e-f0f8-446f-8c8b-4ffd75acd6d7@github.com>
Message-ID: <lkZKaO6k53B25_oeC4aJO48gsmHH2MGnLi4q-Pl4WCA=.17a4f496-bf5f-4a66-aa3d-40ef746869a2@github.com>

On Sun, 14 Mar 2021 19:35:25 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
>> 
>> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use InputStream.readNBytes() and fix JLinkNegativeTest

src/java.desktop/share/classes/sun/awt/image/ByteArrayImageSource.java line 54:

> 52: 
> 53:     protected ImageDecoder getDecoder() {
> 54:         InputStream is = new ByteArrayInputStream(imagedata, imageoffset, imagelength);

This file use 80 chars per line code style.

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From henryjen at openjdk.java.net  Sun Mar 14 23:40:21 2021
From: henryjen at openjdk.java.net (Henry Jen)
Date: Sun, 14 Mar 2021 23:40:21 GMT
Subject: RFR: 8261785: Calling "main" method in anonymous nested class crashes
 the JVM
Message-ID: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>

This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS.

As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the launcher trying to grab class name to be displayed as the Application name on the menu.

The fix is to not setting name, test shows that GUI java application shows 'bin' as the application name. It's possible for us to set the name to something more friendly, for example, "Java", but I am not sure that should be launcher's responsibility to choose such a default name. It seems to me the consumer of the JAVA_MAIN_CLASS_%d environment variable should be responsible to pick such name in case the environment variable is not set.

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

Commit messages:
 - 8261785: Calling "main" method in anonymous nested class crashes the JVM

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

PR: https://git.openjdk.java.net/jdk/pull/2999

From david.holmes at oracle.com  Mon Mar 15 00:17:18 2021
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 15 Mar 2021 10:17:18 +1000
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM
In-Reply-To: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
Message-ID: <aaccdd89-6d43-cba1-d9b8-4b4500f1ea2a@oracle.com>

Hi Henry,

On 15/03/2021 9:40 am, Henry Jen wrote:
> This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS.
> 
> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the launcher trying to grab class name to be displayed as the Application name on the menu.
> 
> The fix is to not setting name, test shows that GUI java application shows 'bin' as the application name. It's possible for us to set the name to something more friendly, for example, "Java", but I am not sure that should be launcher's responsibility to choose such a default name. It seems to me the consumer of the JAVA_MAIN_CLASS_%d environment variable should be responsible to pick such name in case the environment variable is not set.

Maybe the AWT folk should decide what name should be displayed in this 
case. The canonical name was chosen when all main classes had to have a 
canonical name. So perhaps a simple name will suffice in the case where 
there is no canonical name?

Cheers,
David

> -------------
> 
> Commit messages:
>   - 8261785: Calling "main" method in anonymous nested class crashes the JVM
> 
> Changes: https://git.openjdk.java.net/jdk/pull/2999/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2999&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8261785
>    Stats: 111 lines in 3 files changed: 110 ins; 0 del; 1 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/2999.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/2999/head:pull/2999
> 
> PR: https://git.openjdk.java.net/jdk/pull/2999
> 

From jai.forums2013 at gmail.com  Mon Mar 15 01:31:17 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 15 Mar 2021 07:01:17 +0530
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <237e6c14-8593-69df-5866-4a238e020fce@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
 <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
 <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>
 <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com>
 <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com>
 <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com>
 <237e6c14-8593-69df-5866-4a238e020fce@oracle.com>
Message-ID: <925a9e7e-ce07-843f-1673-19ddd0d43375@gmail.com>


On 14/03/21 6:21 pm, Alan Bateman wrote:
> On 12/03/2021 12:18, Lance Andersen wrote:
>>
>> :
>>
>> I don?t have a strong preference but lean slightly towards 
>> ?-directory? as it is more descriptive, similar to the other 
>> GNU-style commands jar currently supports . ?Tar supports ??cd?, 
>> ??directory? in addition to ?-C? which is why I suggested supporting 
>> ?both GNU-style long options.
>>
>> Perhaps jpackage should also support ?dir/directory in addition to 
>> ??dest' if we are looking at consistency between java tools.
>>
>> I do agree that it would be nice to be consistent across the java 
>> tools for options so if we go the ?-directory?, we should follow your 
>> suggestion and make it the primary and remove ??dir? from the usage 
>> output.
> My comment on consistency was limited to the long option to specify 
> the directory when extracting, didn't mean to suggest doing anything 
> with the other tools that specify an output/destination directory. In 
> any case, I think we have enough to make progress on this issue now.

I'll sending the man page content that I have been working on, shortly 
and will then go ahead with changing the PR to incorporate some of the 
feedback received in this discussion.

-Jaikiran


From iignatyev at openjdk.java.net  Mon Mar 15 05:03:20 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 15 Mar 2021 05:03:20 GMT
Subject: RFR: 8263556: remove `@modules java.base` from tests
Message-ID: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>

Hi all,

could you please review this trivial cleanup?
from JBS:

> jtreg `@modules X` directive does two things: 
>  - exclude a test from execution if JDK under test doesn't have module X 
>  - if JDK under test has module X, make sure it's resolved 
> 
> both these things have no sense for `java.base` module as it's always available and is always resolved.


Thanks,
-- Igor

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

Commit messages:
 - update copyright year
 - 8263556: remove `@modules java.base` from tests

Changes: https://git.openjdk.java.net/jdk/pull/2990/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2990&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263556
  Stats: 21 lines in 13 files changed: 0 ins; 13 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2990.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2990/head:pull/2990

PR: https://git.openjdk.java.net/jdk/pull/2990

From alanb at openjdk.java.net  Mon Mar 15 06:59:07 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 15 Mar 2021 06:59:07 GMT
Subject: RFR: 8263561: Re-examine uses of LinkedList
In-Reply-To: <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com>
References: <-lwwnneyhUB3qMqORpmnCC2vhWNTuURohJWvKb7xEtY=.a1e980bd-fc7a-49c8-89ed-4b8f294e83f6@github.com>
 <6ZglAu_W4knnRCE5IzZiYkFgZn-mbf72HM4aF5ehnFU=.0b120039-1967-4d4c-939e-b1d52a884a51@github.com>
 <WXYtwL5kJ19rmoNeVi0yWfKsMZhNzQe_xaAjEq8HkG4=.606a21d6-727b-4d90-874e-b791f1c739a6@github.com>
 <7nIzoaMqTkfI8ia87qvQv_zzkcHsewGEkSZo-TYTMn4=.dad9bbf0-3513-43c7-826e-cb918beb39eb@github.com>
 <8nMvQUI3qPfR-VTlVG3i0Pfm7w_xZ5aDUAotA4a3Yvs=.5ac6563e-d7fb-4b8f-8b0d-c0d7701860ac@github.com>
Message-ID: <VSPKLm1HjhCkd_WmlFJCikNyedxejJnBZ0JOwUxb87k=.35ea99d2-b3d4-4203-b9f2-2a2548262dcb@github.com>

On Sun, 14 Mar 2021 17:26:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Looks like it's never specified in JavaDoc which particular implementation of List is used in fields of affected classes, so it's quite odd to me that someone would rely on that when using reflection. But your point about backward compatibility is reasonable, so I'll revert mentioned changes.
>
> Nothing outside of the JDK should be hacking into this private field of a non-exposed class, this should not be a concern here.

> @AlanBateman so is it ok to keep `ArrayLists`?

One thing to look out for is usages of 2-arg add method that inserts at a specific position. This shouldn't be a concern in URLClassPath.closeLoaders (assuming this is this usage where the question arises).

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

PR: https://git.openjdk.java.net/jdk/pull/2744

From github.com+828220+forax at openjdk.java.net  Mon Mar 15 08:20:11 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 15 Mar 2021 08:20:11 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <5IW2VsaVaqCMqkD6qkNxdWpL1qJM8daN1yf9a-Ivxk8=.d15e95c1-183d-4d50-98ff-e112beadf602@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
 <6h9eeR6HFk03eD3DCtXjJo9Wg81zWH1090paXb-Yp1k=.da9e5ecd-377a-488f-a2f6-b43876af6f60@github.com>
 <2I2HK8tDFSLtPqs0JFLKLgh3QmMTkM1HKuvKQNmsfIg=.a383a449-18e3-413a-a6ba-91dc80fde86a@github.com>
 <I21iHk0o_E19xgFXNA4DkmfU4rx29l10Nb47w5GMjjY=.5600fa62-ded1-4286-90fb-ccf32801ce7b@github.com>
 <5IW2VsaVaqCMqkD6qkNxdWpL1qJM8daN1yf9a-Ivxk8=.d15e95c1-183d-4d50-98ff-e112beadf602@github.com>
Message-ID: <JIzUrwWQ2E0_SO5joMKuky0bqhCt8J3vRiuKW3izogo=.a4a9b63c-063f-47f6-b039-1ecdf8b89dce@github.com>

On Wed, 18 Nov 2020 13:45:46 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Need rebase
>
> Created new PR because of forced push: https://github.com/openjdk/jdk/pull/1292

LGTM

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

PR: https://git.openjdk.java.net/jdk/pull/1273

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 08:36:29 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 08:36:29 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v3]
In-Reply-To: <lkZKaO6k53B25_oeC4aJO48gsmHH2MGnLi4q-Pl4WCA=.17a4f496-bf5f-4a66-aa3d-40ef746869a2@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <JuQsjcKBqVGQAANu4UFRwfDDx0dh8QnvxFBuMhBYvTk=.31eb331e-f0f8-446f-8c8b-4ffd75acd6d7@github.com>
 <lkZKaO6k53B25_oeC4aJO48gsmHH2MGnLi4q-Pl4WCA=.17a4f496-bf5f-4a66-aa3d-40ef746869a2@github.com>
Message-ID: <LJayKKKnqxrRLYqVf5Kp3hGiZszs6pcuu71lAIwY7KQ=.c6b6d825-23a8-47e0-b13b-01e26f3e704a@github.com>

On Sun, 14 Mar 2021 22:48:18 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use InputStream.readNBytes() and fix JLinkNegativeTest
>
> src/java.desktop/share/classes/sun/awt/image/ByteArrayImageSource.java line 54:
> 
>> 52: 
>> 53:     protected ImageDecoder getDecoder() {
>> 54:         InputStream is = new ByteArrayInputStream(imagedata, imageoffset, imagelength);
> 
> This file use 80 chars per line code style.

Fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 08:36:28 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 08:36:28 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v4]
In-Reply-To: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
Message-ID: <1QWRbOB-L164PKNpRWeJ9pY5AILrguO6Dv-OLhBB8UI=.d879ff21-7338-466e-9635-b69d9e5dcc9c@github.com>

> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
> 
> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

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

  Fix formatting

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2992/files
  - new: https://git.openjdk.java.net/jdk/pull/2992/files/a016d2ac..f69c8ff4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From jpai at openjdk.java.net  Mon Mar 15 08:58:29 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 15 Mar 2021 08:58:29 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v3]
In-Reply-To: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
Message-ID: <jV746lsRyrXKWBRx1vU0oePcaeHn6KegRDYrieejYrc=.3f904112-6231-4983-8664-3d6dce9d33fb@github.com>

> Can I please get a review for this proposed patch for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8263108?
> 
> As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and `java.lang.constant.ConstantDescs` can end up in a classloading deadlock due to the nature of the code involved in their static blocks. A thread dump of one such deadlock (reproduced using the code attached to that issue) is as follows:
> 
> "Thread A" #14 prio=5 os_prio=31 cpu=101.45ms elapsed=8.30s tid=0x00007ff88e01ca00 nid=0x6003 in Object.wait()  [0x000070000a4c6000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.constant.DynamicConstantDesc.<clinit>(java.base at 16-ea/DynamicConstantDesc.java:67)
> 	- waiting on the Class initialization monitor for java.lang.constant.ConstantDescs
> 	at Deadlock.threadA(Deadlock.java:14)
> 	at Deadlock$$Lambda$1/0x0000000800c00a08.run(Unknown Source)
> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
> 
> "Thread B" #15 prio=5 os_prio=31 cpu=103.15ms elapsed=8.30s tid=0x00007ff88b936a00 nid=0x9b03 in Object.wait()  [0x000070000a5c9000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.constant.ClassDesc.ofDescriptor(java.base at 16-ea/ClassDesc.java:145)
> 	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc
> 	at java.lang.constant.ConstantDescs.<clinit>(java.base at 16-ea/ConstantDescs.java:239)
> 	at Deadlock.threadB(Deadlock.java:24)
> 	at Deadlock$$Lambda$2/0x0000000800c00c28.run(Unknown Source)
> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
> 
> The commit in this PR resolves that deadlock by moving the `canonicalMap` initialization in `DynamicConstantDesc`, from the static block, to a lazily initialized map, into the `tryCanonicalize` (private) method of the same class. That's the only method which uses this map.
> 
> The implementation in `tryCanonicalize` carefully ensures that the deadlock isn't shifted from the static block to this method, by making sure that the `synchronization` on `DynamicConstantDesc` in this method happens only when it's time to write the state to the shared `canonicalMap`. This has an implication that the method local variable `canonDescs` can get initialized by multiple threads unnecessarily but from what I can see, that's the only way we can avoid this deadlock. This penalty of multiple threads initializing and then throwing away that map isn't too huge because that will happen only once when the `canonicalMap` is being initialized for the first time.
> 
> An alternate approach that I thought of was to completely get rid of this shared cache `canonicalMap` and instead just use method level map (that gets initialized each time) in the `tryCanonicalize` method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.
> 
> The commit in this PR also includes a jtreg testcase which (consistently) reproduces the deadlock without the fix and passes when this fix is applied. Extra manual testing has been done to verify that the classes of interest (noted in that testcase) are indeed getting loaded in those concurrent threads and not in the main thread. For future maintainers, there's a implementation note added on that testcase explaining why it cannot be moved into testng test.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Update the testcase to improve the chances of triggering a deadlock

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2893/files
  - new: https://git.openjdk.java.net/jdk/pull/2893/files/1b59dc14..2b51ec9d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2893&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2893&range=01-02

  Stats: 15 lines in 1 file changed: 13 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2893/head:pull/2893

PR: https://git.openjdk.java.net/jdk/pull/2893

From jpai at openjdk.java.net  Mon Mar 15 08:58:30 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 15 Mar 2021 08:58:30 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v2]
In-Reply-To: <BaNG8I3A5tjrXTveKKV9N7EpB1dZmjvVBnhd229zrx0=.a3b25438-34d2-46f4-8f62-40f1b2b8d454@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <8601DNFkEWL76jjuZpNosikeT-1L6fsoz9yf5B79uoU=.bfb92ddd-63d8-44b3-84b6-c73413ab342f@github.com>
 <gLGKOnXo8i_FuwF2ahIwi6zlGzdzoZfXvyu9g3-BoWk=.3ff679bc-c900-4220-89bf-e3cf83a2bada@github.com>
 <BaNG8I3A5tjrXTveKKV9N7EpB1dZmjvVBnhd229zrx0=.a3b25438-34d2-46f4-8f62-40f1b2b8d454@github.com>
Message-ID: <zMZdl4V9pFvTiqeVfGa1ba7tux0Oa89AV0ndfNLmlnw=.1205a1c3-fe8d-4320-b767-f0816898491d@github.com>

On Fri, 12 Mar 2021 14:53:45 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> What you have is probably fine, but has any consideration been given to using the initialization-on-demand holder idiom? e.g.
> 
> ```
>  static private class CanonicalMapHolder {
>     static final Map<MethodHandleDesc, Function<DynamicConstantDesc<?>, ConstantDesc>> CANONICAL_MAP
>           = Map.ofEntries(..);
>  }
> ```

Hello Chris,

Although I had thought of some other alternate ways to fix this, this idiom isn't something that I had thought of. Now that you showed this, I thought about it a bit more and it does look a lot more "natural" to read and maintain as compared to the current changes in this PR which does some juggling to avoid this deadlock. However, having thought about your proposed solution, I think _in theory_ it still leaves open the possibility of a deadlock.

Here's what the patch looks like with your suggested change:

diff --git a/src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java b/src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java
index 976b09e5665..c7bdcf4ce32 100644
--- a/src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java
+++ b/src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java
@@ -64,8 +64,6 @@ public abstract class DynamicConstantDesc<T>
     private final String constantName;
     private final ClassDesc constantType;
 
-    private static Map<MethodHandleDesc, Function<DynamicConstantDesc<?>, ConstantDesc>> canonicalMap;
-
     /**
      * Creates a nominal descriptor for a dynamic constant.
      *
@@ -274,25 +272,7 @@ public abstract class DynamicConstantDesc<T>
     }
 
     private ConstantDesc tryCanonicalize() {
-        var canonDescs = canonicalMap;
-        if (canonDescs == null) {
-            canonDescs = Map.ofEntries(
-                    Map.entry(ConstantDescs.BSM_PRIMITIVE_CLASS, DynamicConstantDesc::canonicalizePrimitiveClass),
-                    Map.entry(ConstantDescs.BSM_ENUM_CONSTANT, DynamicConstantDesc::canonicalizeEnum),
-                    Map.entry(ConstantDescs.BSM_NULL_CONSTANT, DynamicConstantDesc::canonicalizeNull),
-                    Map.entry(ConstantDescs.BSM_VARHANDLE_STATIC_FIELD, DynamicConstantDesc::canonicalizeStaticFieldVarHandle),
-                    Map.entry(ConstantDescs.BSM_VARHANDLE_FIELD, DynamicConstantDesc::canonicalizeFieldVarHandle),
-                    Map.entry(ConstantDescs.BSM_VARHANDLE_ARRAY, DynamicConstantDesc::canonicalizeArrayVarHandle));
-            synchronized (DynamicConstantDesc.class) {
-                if (canonicalMap == null) {
-                    canonicalMap = canonDescs;
-                } else {
-                    canonDescs = canonicalMap;
-                }
-            }
-        }
-
-        Function<DynamicConstantDesc<?>, ConstantDesc> f = canonDescs.get(bootstrapMethod);
+        Function<DynamicConstantDesc<?>, ConstantDesc> f = CanonicalMapHolder.CANONICAL_MAP.get(bootstrapMethod);
         if (f != null) {
             try {
                 return f.apply(this);
@@ -405,4 +385,15 @@ public abstract class DynamicConstantDesc<T>
             super(bootstrapMethod, constantName, constantType, bootstrapArgs);
         }
     }
+
+    private static final class CanonicalMapHolder {
+        static final Map<MethodHandleDesc, Function<DynamicConstantDesc<?>, ConstantDesc>> CANONICAL_MAP =
+                Map.ofEntries(
+                    Map.entry(ConstantDescs.BSM_PRIMITIVE_CLASS, DynamicConstantDesc::canonicalizePrimitiveClass),
+                    Map.entry(ConstantDescs.BSM_ENUM_CONSTANT, DynamicConstantDesc::canonicalizeEnum),
+                    Map.entry(ConstantDescs.BSM_NULL_CONSTANT, DynamicConstantDesc::canonicalizeNull),
+                    Map.entry(ConstantDescs.BSM_VARHANDLE_STATIC_FIELD, DynamicConstantDesc::canonicalizeStaticFieldVarHandle),
+                    Map.entry(ConstantDescs.BSM_VARHANDLE_FIELD, DynamicConstantDesc::canonicalizeFieldVarHandle),
+                    Map.entry(ConstantDescs.BSM_VARHANDLE_ARRAY, DynamicConstantDesc::canonicalizeArrayVarHandle));
+    }
 }


Please consider the following, where I try and explain the theoretical possibility of a deadlock with this approach:

1. Let's consider 2 threads T1 and T2 doing concurrent execution

2. Let's for a moment assume that neither `DynamicConstantDesc` nor `ConstantDescs` classes have been initialized.

3. T1 does a call to `DynamicConstantDesc.ofCanonical(...)` and T2 does a call to something/anything on `ConstantDescs`, which triggers a class initialization of `ConstantDescs`.

4. T1 (which called `DynamicConstantDesc.ofCanonical(...)`) will reach the `tryCanonicalize` and will access `CanonicalMapHolder.CANONICAL_MAP` in the implementation of that method. Because of this access (and since `CanonicalMapHolder` hasn't yet been initialized), T1 will obtain (an implicit) lock on the `CanonicalMapHolder` class (for the class initialization). Let's assume T1 is granted this lock on `CanonicalMapHolder` class and it goes ahead into the static block of that holder class to do the initialization of `CANONICAL_MAP`. To do so, because of the code in the static block of `CanonicalMapHolder`, it now requires a class initialization lock on `ConstantDescs` (since `ConstantDescs` hasn't yet been initialized). So it requests for that lock on `ConstantDescs` class.

5. Concurrently, let's say T2 has initiated a class initialization of `ConstantDescs`. So T2 is currently holding a class initialization lock on `ConstantDescs`. While the static initialization of `ConstantDescs` is going on, let's assume (in theory), due to the whole lot of code in the static initialization of `ConstantDescs`, it either directly or indirectly ends up calling `DynamicConstantDesc.ofCanonical(...)`. This then means that T2 now enters the `tryCanonicalize` and accesses `CanonicalMapHolder.CANONICAL_MAP` and since `CanonicalMapHolder` hasn't yet been (fully) initialized (remember T1 is still in the static block of `CanonicalMapHolder`), it tries to obtain a class initialization lock on `CanonicalMapHolder` which is currently held by T1. T1 won't let go that lock since it wants the lock on `ConstantDescs` which is currently held by T2. This effectively ends up triggering the deadlock.

This deadlock isn't possible with the current approach that this PR has.

I want to clarify that, the deadlock that I explain above with your proposed approach is just a theoretical possibility. The `ConstantDescs` doesn't currently have any direct call to `DynamicConstantDesc.ofCanonical` in its static initialization nor can I see or think of any indirect calls to `DynamicConstantDesc.ofCanonical` from its static block. I need input from you whether I should keep aside this theoretic issue and deal with it if/when we run into it (the test case in this PR, IMO, is robust enough to catch that deadlock if/when it happens due to any future code changes in this area). If you and others think that we can ignore this case, then your proposed approach of using this lazy holder for initialization, IMO, is much cleaner and natural to read and I will go ahead and update this PR to use it.

For those interested in seeing this potential theoretical deadlock with the lazy holder approach in action, I just created a separate branch here https://github.com/jaikiran/jdk/commits/8263108-demo-deadlock-theory which consistently reproduces the deadlock when the `DynamicConstantDescTest` jtreg test is run. The crucial part is that I introduced the following (dummy) call in `ConstantDescs`:

diff --git a/src/java.base/share/classes/java/lang/constant/ConstantDescs.java b/src/java.base/share/classes/java/lang/constant/ConstantDescs.java
index 3a000d1bd4a..3f793f5a8b3 100644
--- a/src/java.base/share/classes/java/lang/constant/ConstantDescs.java
+++ b/src/java.base/share/classes/java/lang/constant/ConstantDescs.java
@@ -286,6 +286,13 @@ public final class ConstantDescs {
     static final DirectMethodHandleDesc MHD_METHODHANDLE_ASTYPE
             = MethodHandleDesc.ofMethod(Kind.VIRTUAL, CD_MethodHandle, "asType",
                                         MethodTypeDesc.of(CD_MethodHandle, CD_MethodType));
+
+    static {
+        // just a dummy call to DynamicConstantDesc.ofCanonical
+        DynamicConstantDesc.ofCanonical(ConstantDescs.BSM_ENUM_CONSTANT, "SHOW_REFLECT_FRAMES",
+                ClassDesc.of("java.lang.StackWalker").nested("Option"), new ConstantDesc[0]);
+    }
+


The following thread dump shows the deadlock with that lazy holder approach:

"MainThread" #15 prio=5 os_prio=31 cpu=6.26ms elapsed=120.18s tid=0x00007fe0e58df800 nid=0x5e03 waiting on condition  [0x000070000d71d000]
   java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park(java.base at 17-internal/Native Method)
	- parking to wait for  <0x000000070ff65d90> (a java.util.concurrent.FutureTask)
	at java.util.concurrent.locks.LockSupport.park(java.base at 17-internal/LockSupport.java:211)
	at java.util.concurrent.FutureTask.awaitDone(java.base at 17-internal/FutureTask.java:447)
	at java.util.concurrent.FutureTask.get(java.base at 17-internal/FutureTask.java:190)
	at DynamicConstantDescTest.main(DynamicConstantDescTest.java:80)
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 17-internal/Native Method)
	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 17-internal/NativeMethodAccessorImpl.java:78)
	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 17-internal/DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(java.base at 17-internal/Method.java:566)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
	at java.lang.Thread.run(java.base at 17-internal/Thread.java:831)

"pool-1-thread-1" #16 prio=5 os_prio=31 cpu=14.32ms elapsed=120.18s tid=0x00007fe0e58dea00 nid=0x9903 waiting on condition  [0x000070000d820000]
   java.lang.Thread.State: WAITING (parking)
	at jdk.internal.misc.Unsafe.park(java.base at 17-internal/Native Method)
	- parking to wait for  <0x000000070ff59d30> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
	at java.util.concurrent.locks.LockSupport.park(java.base at 17-internal/LockSupport.java:341)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 17-internal/AbstractQueuedSynchronizer.java:506)
	at java.util.concurrent.ForkJoinPool.unmanagedBlock(java.base at 17-internal/ForkJoinPool.java:3454)
	at java.util.concurrent.ForkJoinPool.managedBlock(java.base at 17-internal/ForkJoinPool.java:3425)
	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 17-internal/AbstractQueuedSynchronizer.java:1623)
	at java.util.concurrent.LinkedBlockingQueue.take(java.base at 17-internal/LinkedBlockingQueue.java:435)
	at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 17-internal/ThreadPoolExecutor.java:1061)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 17-internal/ThreadPoolExecutor.java:1121)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 17-internal/ThreadPoolExecutor.java:635)
	at java.lang.Thread.run(java.base at 17-internal/Thread.java:831)

"pool-1-thread-2" #17 prio=5 os_prio=31 cpu=7.88ms elapsed=120.18s tid=0x00007fe0e4012c00 nid=0x6003 in Object.wait()  [0x000070000d923000]
   java.lang.Thread.State: RUNNABLE
	at java.lang.constant.DynamicConstantDesc.tryCanonicalize(java.base at 17-internal/DynamicConstantDesc.java:275)
	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc$CanonicalMapHolder
	at java.lang.constant.DynamicConstantDesc.ofCanonical(java.base at 17-internal/DynamicConstantDesc.java:136)
	at DynamicConstantDescTest$InvokeOfCanonical.call(DynamicConstantDescTest.java:129)
	at java.util.concurrent.FutureTask.run(java.base at 17-internal/FutureTask.java:264)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 17-internal/ThreadPoolExecutor.java:1135)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 17-internal/ThreadPoolExecutor.java:635)
	at java.lang.Thread.run(java.base at 17-internal/Thread.java:831)

"pool-1-thread-3" #18 prio=5 os_prio=31 cpu=15.43ms elapsed=120.18s tid=0x00007fe0e4070600 nid=0x9803 in Object.wait()  [0x000070000da26000]
   java.lang.Thread.State: RUNNABLE
	at java.lang.constant.DynamicConstantDesc.tryCanonicalize(java.base at 17-internal/DynamicConstantDesc.java:275)
	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc$CanonicalMapHolder
	at java.lang.constant.DynamicConstantDesc.ofCanonical(java.base at 17-internal/DynamicConstantDesc.java:136)
	at java.lang.constant.ConstantDescs.<clinit>(java.base at 17-internal/ConstantDescs.java:292)
	at java.lang.Class.forName0(java.base at 17-internal/Native Method)
	at java.lang.Class.forName(java.base at 17-internal/Class.java:375)
	at DynamicConstantDescTest$Task.call(DynamicConstantDescTest.java:104)
	at DynamicConstantDescTest$Task.call(DynamicConstantDescTest.java:87)
	at java.util.concurrent.FutureTask.run(java.base at 17-internal/FutureTask.java:264)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 17-internal/ThreadPoolExecutor.java:1135)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 17-internal/ThreadPoolExecutor.java:635)
	at java.lang.Thread.run(java.base at 17-internal/Thread.java:831)

"pool-1-thread-4" #19 prio=5 os_prio=31 cpu=5.39ms elapsed=120.18s tid=0x00007fe0e4070c00 nid=0x9603 in Object.wait()  [0x000070000db29000]
   java.lang.Thread.State: RUNNABLE
	at java.lang.constant.DynamicConstantDesc$CanonicalMapHolder.<clinit>(java.base at 17-internal/DynamicConstantDesc.java:390)
	- waiting on the Class initialization monitor for java.lang.constant.ConstantDescs
	at java.lang.constant.DynamicConstantDesc.tryCanonicalize(java.base at 17-internal/DynamicConstantDesc.java:275)
	at java.lang.constant.DynamicConstantDesc.ofCanonical(java.base at 17-internal/DynamicConstantDesc.java:136)
	at DynamicConstantDescTest$InvokeOfCanonical.call(DynamicConstantDescTest.java:129)
	at java.util.concurrent.FutureTask.run(java.base at 17-internal/FutureTask.java:264)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 17-internal/ThreadPoolExecutor.java:1135)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 17-internal/ThreadPoolExecutor.java:635)
	at java.lang.Thread.run(java.base at 17-internal/Thread.java:831)

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From pconcannon at openjdk.java.net  Mon Mar 15 09:15:39 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 15 Mar 2021 09:15:39 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v4]
In-Reply-To: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
Message-ID: <pd1Zg7zf0DBUWYnRXkcj53KymAzKm6i5LaHvDJZX5Y0=.5aec988c-0928-496d-8487-cb89e538a4c4@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request with a new target base 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 remote-tracking branch 'origin/master' into JDK-8263358
 - 8263358: Refactored equals methods
 - Merge remote-tracking branch 'origin/master' into JDK-8263358
 - 8263358: Update java.lang to use instanceof pattern variable

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2913/files
  - new: https://git.openjdk.java.net/jdk/pull/2913/files/e9d91315..071fe1eb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=02-03

  Stats: 24696 lines in 1136 files changed: 20879 ins; 1644 del; 2173 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2913.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2913/head:pull/2913

PR: https://git.openjdk.java.net/jdk/pull/2913

From pconcannon at openjdk.java.net  Mon Mar 15 09:21:23 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 15 Mar 2021 09:21:23 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v3]
In-Reply-To: <tvF63A3GU78kXg4Xr-GftwJG6jzUZfK0honst1dE2iA=.9670320a-dda8-4058-b80c-471e2c5ba4fd@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <6tewcd6fbSvTdow5ApGEkvVlDCmn6z9NQLnXE_ntH3Q=.ce2ba4c9-ef2a-4630-8622-8a7aefd93870@github.com>
 <tvF63A3GU78kXg4Xr-GftwJG6jzUZfK0honst1dE2iA=.9670320a-dda8-4058-b80c-471e2c5ba4fd@github.com>
Message-ID: <4khshcFGDoQRfZlq7BklSc8JpyScOdAMI7zOa0oMNd0=.fb3d280c-cbee-49a8-85f5-fd705905eb60@github.com>

On Fri, 12 Mar 2021 17:38:30 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8263358: Refactored equals methods
>
> src/java.base/share/classes/java/lang/ProcessHandleImpl.java line 525:
> 
>> 523:             return (pid == other.pid) &&
>> 524:                     (startTime == other.startTime
>> 525:                         || startTime == 0
> 
> This one can be a single expression. Otherwise, looks good.

Well spotted, Chris. Fixed in commit f7924d2

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From pconcannon at openjdk.java.net  Mon Mar 15 09:21:22 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 15 Mar 2021 09:21:22 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
Message-ID: <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8263358: Refactored missed equals method

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2913/files
  - new: https://git.openjdk.java.net/jdk/pull/2913/files/071fe1eb..f7924d27

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=03-04

  Stats: 7 lines in 1 file changed: 0 ins; 4 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2913.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2913/head:pull/2913

PR: https://git.openjdk.java.net/jdk/pull/2913

From azvegint at openjdk.java.net  Mon Mar 15 09:32:12 2021
From: azvegint at openjdk.java.net (Alexander Zvegintsev)
Date: Mon, 15 Mar 2021 09:32:12 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversion
 in ObjectStreamClass
In-Reply-To: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
Message-ID: <EtwbH_n_U-IvQEls9X-BIc64aDgoeG9cID_z4Znl_R8=.69bbcedf-6ec8-497d-826b-698d41fea3ba@github.com>

On Sat, 20 Feb 2021 12:17:32 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array

Marked as reviewed by azvegint (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From chegar at openjdk.java.net  Mon Mar 15 09:32:11 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 15 Mar 2021 09:32:11 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
Message-ID: <pVfZHWnpLpUX9e4117WEyeQPNtkEE4dBDHlRLHuMSzo=.71de1dd6-2d7b-4d14-a129-268f16106946@github.com>

On Mon, 15 Mar 2021 09:21:22 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263358: Refactored missed equals method

Marked as reviewed by chegar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From github.com+828220+forax at openjdk.java.net  Mon Mar 15 09:35:10 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 15 Mar 2021 09:35:10 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
Message-ID: <tqJTgA567Bmq7ki1OSyRR-T0aZLf6xEB4AaQa2OFp0o=.c05e8419-cf23-4010-8cfa-78b29f1bffed@github.com>

On Mon, 15 Mar 2021 09:21:22 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263358: Refactored missed equals method

src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java line 360:

> 358:     public final boolean equals(Object o) {
> 359:         if (this == o) return true;
> 360:         return (o instanceof DynamicConstantDesc desc)

should be
  `(o instanceof DynamicConstantDesc<?> desc)`

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From github.com+828220+forax at openjdk.java.net  Mon Mar 15 09:38:19 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 15 Mar 2021 09:38:19 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
Message-ID: <-0824MCtSuH7aJ_Ea4gf3Ggs5CGPSjcG6E5HS4WWuZE=.220abbbb-31d5-4ac1-9300-8621455fd285@github.com>

On Mon, 15 Mar 2021 09:21:22 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263358: Refactored missed equals method

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

> 411:                 && Objects.equals(moduleName, e.moduleName)
> 412:                 && Objects.equals(moduleVersion, e.moduleVersion)
> 413:                 && e.declaringClass.equals(declaringClass)

testing the declaring class and the line number should be done first given they are primitive values, it will be a little more efficient if two StackTraceElement are not equals and one is using non interned String.
  return (obj instanceof StackTraceElement e)
     && e.lineNumber == lineNumber
     && e.declaringClass == declaringClass
     && ...

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From prappo at openjdk.java.net  Mon Mar 15 10:21:08 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 15 Mar 2021 10:21:08 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <tqJTgA567Bmq7ki1OSyRR-T0aZLf6xEB4AaQa2OFp0o=.c05e8419-cf23-4010-8cfa-78b29f1bffed@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
 <tqJTgA567Bmq7ki1OSyRR-T0aZLf6xEB4AaQa2OFp0o=.c05e8419-cf23-4010-8cfa-78b29f1bffed@github.com>
Message-ID: <7M1a_-toj0cuTbLnwxcqEGZopF92y-8piQkrl-_EXa8=.bab041cf-4e26-42bc-bf7d-bd67ce3f8000@github.com>

On Mon, 15 Mar 2021 09:32:33 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8263358: Refactored missed equals method
>
> src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java line 360:
> 
>> 358:     public final boolean equals(Object o) {
>> 359:         if (this == o) return true;
>> 360:         return (o instanceof DynamicConstantDesc desc)
> 
> should be
>   `(o instanceof DynamicConstantDesc<?> desc)`

I noticed that too initially. However, `javac` does not seem to produce a "rawtypes" warning. Which makes sense, if you think about it.

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From github.com+828220+forax at openjdk.java.net  Mon Mar 15 10:50:09 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 15 Mar 2021 10:50:09 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <7M1a_-toj0cuTbLnwxcqEGZopF92y-8piQkrl-_EXa8=.bab041cf-4e26-42bc-bf7d-bd67ce3f8000@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
 <tqJTgA567Bmq7ki1OSyRR-T0aZLf6xEB4AaQa2OFp0o=.c05e8419-cf23-4010-8cfa-78b29f1bffed@github.com>
 <7M1a_-toj0cuTbLnwxcqEGZopF92y-8piQkrl-_EXa8=.bab041cf-4e26-42bc-bf7d-bd67ce3f8000@github.com>
Message-ID: <EB3BACJqC1S88itLaCIfLKtjtmp3FPDYxaD3wzUalok=.54b6f6d1-f0c9-4b42-8277-90c2571f5865@github.com>

On Mon, 15 Mar 2021 10:18:26 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java line 360:
>> 
>>> 358:     public final boolean equals(Object o) {
>>> 359:         if (this == o) return true;
>>> 360:         return (o instanceof DynamicConstantDesc desc)
>> 
>> should be
>>   `(o instanceof DynamicConstantDesc<?> desc)`
>
> I noticed that too initially. However, `javac` does not seem to produce a "rawtypes" warning. Which makes sense, if you think about it.

The problem is that `desc` is a raw type and raw types doesn't play well with the rest of the language (in particular with inference).

I think it's a bug in javac, it should not even raise a warning but an error.
But the spec is not fully clear.

The spec says that the narrow conversion should not be unchecked
https://docs.oracle.com/javase/specs/jls/se15/preview/specs/patterns-instanceof-jls.html#jls-14.30.2
it depends if you consider the raw conversion as unchecked or not.

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 10:54:07 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 10:54:07 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversions
In-Reply-To: <BJqCMMGcUYg78Kk-SggLkooddMLE35GZUnjf_g9g5GI=.1d96cfad-9b28-4b06-a59f-5607619eb33d@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <EtwbH_n_U-IvQEls9X-BIc64aDgoeG9cID_z4Znl_R8=.69bbcedf-6ec8-497d-826b-698d41fea3ba@github.com>
 <BJqCMMGcUYg78Kk-SggLkooddMLE35GZUnjf_g9g5GI=.1d96cfad-9b28-4b06-a59f-5607619eb33d@github.com>
Message-ID: <Hv_MEmDU3ku0pbMDZTiDamhQyMwAamWXUdEUtsDUvhY=.2882b823-9b17-4876-b742-e4a079b692de@github.com>

On Mon, 15 Mar 2021 10:51:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Marked as reviewed by azvegint (Reviewer).
>
> Ok if we change the summary to "Use String.valueOf() for char-to-String conversions"?

@cl4es done

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From redestad at openjdk.java.net  Mon Mar 15 10:54:07 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 15 Mar 2021 10:54:07 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversions
In-Reply-To: <EtwbH_n_U-IvQEls9X-BIc64aDgoeG9cID_z4Znl_R8=.69bbcedf-6ec8-497d-826b-698d41fea3ba@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <EtwbH_n_U-IvQEls9X-BIc64aDgoeG9cID_z4Znl_R8=.69bbcedf-6ec8-497d-826b-698d41fea3ba@github.com>
Message-ID: <BJqCMMGcUYg78Kk-SggLkooddMLE35GZUnjf_g9g5GI=.1d96cfad-9b28-4b06-a59f-5607619eb33d@github.com>

On Mon, 15 Mar 2021 09:29:00 GMT, Alexander Zvegintsev <azvegint at openjdk.org> wrote:

>> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array
>
> Marked as reviewed by azvegint (Reviewer).

Ok if we change the summary to "Use String.valueOf() for char-to-String conversions"?

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From redestad at openjdk.java.net  Mon Mar 15 10:56:07 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 15 Mar 2021 10:56:07 GMT
Subject: Integrated: 8263508: Remove dead code in MethodHandleImpl
In-Reply-To: <YF2pmiSguRiaE9wznG13pveAZvQKo_CbbrsFgdtBRzM=.fc5242e3-9471-4597-9eee-e4b7835a211e@github.com>
References: <YF2pmiSguRiaE9wznG13pveAZvQKo_CbbrsFgdtBRzM=.fc5242e3-9471-4597-9eee-e4b7835a211e@github.com>
Message-ID: <vsKrUO8RXrv0fUWKIGlRAy74l5nfUcV3-W1lYMO8qeg=.b1f39e00-1ff7-4e5c-b7af-8dc428a31e9e@github.com>

On Fri, 12 Mar 2021 13:27:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Remove unused methods.

This pull request has now been integrated.

Changeset: fac39fe9
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fac39fe9
Stats:     103 lines in 1 file changed: 0 ins; 103 del; 0 mod

8263508: Remove dead code in MethodHandleImpl

Reviewed-by: jkuhn, mchung

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

PR: https://git.openjdk.java.net/jdk/pull/2969

From chegar at openjdk.java.net  Mon Mar 15 10:58:07 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 15 Mar 2021 10:58:07 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversions
In-Reply-To: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
Message-ID: <xIQgEqCqv172qDtja19_KNFvA-GI3iY-7OQzIqbw-zc=.a1fbeb74-4cd9-418f-b240-1e4b543aceb9@github.com>

On Sat, 20 Feb 2021 12:17:32 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array

Marked as reviewed by chegar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From prappo at openjdk.java.net  Mon Mar 15 11:04:08 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 15 Mar 2021 11:04:08 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <EB3BACJqC1S88itLaCIfLKtjtmp3FPDYxaD3wzUalok=.54b6f6d1-f0c9-4b42-8277-90c2571f5865@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
 <tqJTgA567Bmq7ki1OSyRR-T0aZLf6xEB4AaQa2OFp0o=.c05e8419-cf23-4010-8cfa-78b29f1bffed@github.com>
 <7M1a_-toj0cuTbLnwxcqEGZopF92y-8piQkrl-_EXa8=.bab041cf-4e26-42bc-bf7d-bd67ce3f8000@github.com>
 <EB3BACJqC1S88itLaCIfLKtjtmp3FPDYxaD3wzUalok=.54b6f6d1-f0c9-4b42-8277-90c2571f5865@github.com>
Message-ID: <V4M_1KPi4i2nUUYL1SLLvnluQwlBe0QI3fg73OSm_iU=.33bd47b5-0689-47e7-9e8e-b148d4a4892f@github.com>

On Mon, 15 Mar 2021 10:47:10 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

> I think it's a bug in javac, it should not even raise a warning but an error.
> But the spec is not fully clear.

If you think that it's a bug, consider providing feedback to authors of JEP 394:

> Other refinements may be incorporated based on further feedback.

I find it hard to believe that authors didn't consider generic use case (even though JEP 394 doesn't have examples of that).

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From github.com+828220+forax at openjdk.java.net  Mon Mar 15 11:12:08 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 15 Mar 2021 11:12:08 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <V4M_1KPi4i2nUUYL1SLLvnluQwlBe0QI3fg73OSm_iU=.33bd47b5-0689-47e7-9e8e-b148d4a4892f@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
 <tqJTgA567Bmq7ki1OSyRR-T0aZLf6xEB4AaQa2OFp0o=.c05e8419-cf23-4010-8cfa-78b29f1bffed@github.com>
 <7M1a_-toj0cuTbLnwxcqEGZopF92y-8piQkrl-_EXa8=.bab041cf-4e26-42bc-bf7d-bd67ce3f8000@github.com>
 <EB3BACJqC1S88itLaCIfLKtjtmp3FPDYxaD3wzUalok=.54b6f6d1-f0c9-4b42-8277-90c2571f5865@github.com>
 <V4M_1KPi4i2nUUYL1SLLvnluQwlBe0QI3fg73OSm_iU=.33bd47b5-0689-47e7-9e8e-b148d4a4892f@github.com>
Message-ID: <xC2ZpmH0eWLyVQTQ43nif3mjfITV1-gaaiXGx6Csbn4=.ff1d3a53-2760-45f4-9412-f9f7d959b263@github.com>

On Mon, 15 Mar 2021 11:01:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> The problem is that `desc` is a raw type and raw types doesn't play well with the rest of the language (in particular with inference).
>> 
>> I think it's a bug in javac, it should not even raise a warning but an error.
>> But the spec is not fully clear.
>> 
>> The spec says that the narrow conversion should not be unchecked
>> https://docs.oracle.com/javase/specs/jls/se15/preview/specs/patterns-instanceof-jls.html#jls-14.30.2
>> it depends if you consider the raw conversion as unchecked or not.
>
>> I think it's a bug in javac, it should not even raise a warning but an error.
>> But the spec is not fully clear.
> 
> If you think that it's a bug, consider providing feedback to authors of JEP 394:
> 
>> Other refinements may be incorporated based on further feedback.
> 
> I find it hard to believe that authors didn't consider generic use case (even though JEP 394 doesn't have examples of that).

We have considered generics, that why parameterized generics with another type arguments are forbidden, but i think we have forgotten raw types.

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From redestad at openjdk.java.net  Mon Mar 15 11:17:06 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 15 Mar 2021 11:17:06 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversions
In-Reply-To: <xIQgEqCqv172qDtja19_KNFvA-GI3iY-7OQzIqbw-zc=.a1fbeb74-4cd9-418f-b240-1e4b543aceb9@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <xIQgEqCqv172qDtja19_KNFvA-GI3iY-7OQzIqbw-zc=.a1fbeb74-4cd9-418f-b240-1e4b543aceb9@github.com>
Message-ID: <pOxo62rJLFCeKk5mzRhK6RXopd7a7S37Y8hA4Hdl0M4=.22f1f0a1-3b98-49ba-8508-a3b5a0fca8b7@github.com>

On Mon, 15 Mar 2021 10:55:12 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array
>
> Marked as reviewed by chegar (Reviewer).

It seems the bots haven't seen that I changed the bug summary to match yet.

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 11:17:06 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 11:17:06 GMT
Subject: RFR: 8263552: Use String.valueOf() for char-to-String conversions
In-Reply-To: <pOxo62rJLFCeKk5mzRhK6RXopd7a7S37Y8hA4Hdl0M4=.22f1f0a1-3b98-49ba-8508-a3b5a0fca8b7@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
 <xIQgEqCqv172qDtja19_KNFvA-GI3iY-7OQzIqbw-zc=.a1fbeb74-4cd9-418f-b240-1e4b543aceb9@github.com>
 <pOxo62rJLFCeKk5mzRhK6RXopd7a7S37Y8hA4Hdl0M4=.22f1f0a1-3b98-49ba-8508-a3b5a0fca8b7@github.com>
Message-ID: <hL7EElcYSd1bH0vuMfE4MpnZG8TPLMLCpdrFUqOdKo8=.44395a4c-e76d-4474-a55e-bf549388dcc6@github.com>

On Mon, 15 Mar 2021 11:11:21 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Marked as reviewed by chegar (Reviewer).
>
> It seems the bots haven't seen that I changed the bug summary to match yet.

@cl4es could you try `/sponsor` again? I think this time it should be fine.

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 11:22:11 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 11:22:11 GMT
Subject: Integrated: 8263552: Use String.valueOf() for char-to-String
 conversions
In-Reply-To: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
References: <T-Ppyj943YuwNN02lHlGUQCwiaCVoxD-1xxnNd5QyJQ=.1e521eb0-0ef5-4c83-843b-00318cc26779@github.com>
Message-ID: <WUyCZxO8OLLd2sylZrUbGrKpqcnn_8E0nz-hB4nQcNY=.7422c3e9-0b26-4095-b1bb-398a2f7434c3@github.com>

On Sat, 20 Feb 2021 12:17:32 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> This is a very simple and trivial improvement about getting rid of pointless char wrapping into array

This pull request has now been integrated.

Changeset: c0176c42
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c0176c42
Stats:     6 lines in 6 files changed: 0 ins; 0 del; 6 mod

8263552: Use String.valueOf() for char-to-String conversions

Reviewed-by: redestad, vtewari, azvegint, chegar

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

PR: https://git.openjdk.java.net/jdk/pull/2660

From jlahoda at openjdk.java.net  Mon Mar 15 11:42:08 2021
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 15 Mar 2021 11:42:08 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <xC2ZpmH0eWLyVQTQ43nif3mjfITV1-gaaiXGx6Csbn4=.ff1d3a53-2760-45f4-9412-f9f7d959b263@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
 <tqJTgA567Bmq7ki1OSyRR-T0aZLf6xEB4AaQa2OFp0o=.c05e8419-cf23-4010-8cfa-78b29f1bffed@github.com>
 <7M1a_-toj0cuTbLnwxcqEGZopF92y-8piQkrl-_EXa8=.bab041cf-4e26-42bc-bf7d-bd67ce3f8000@github.com>
 <EB3BACJqC1S88itLaCIfLKtjtmp3FPDYxaD3wzUalok=.54b6f6d1-f0c9-4b42-8277-90c2571f5865@github.com>
 <V4M_1KPi4i2nUUYL1SLLvnluQwlBe0QI3fg73OSm_iU=.33bd47b5-0689-47e7-9e8e-b148d4a4892f@github.com>
 <xC2ZpmH0eWLyVQTQ43nif3mjfITV1-gaaiXGx6Csbn4=.ff1d3a53-2760-45f4-9412-f9f7d959b263@github.com>
Message-ID: <vv2SyuK5RxMBEl5ACrKE4AvEa09erdnpzAlAvJJ0RB4=.85ad4384-3e09-4154-8bdd-a34151515e4d@github.com>

On Mon, 15 Mar 2021 11:09:45 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>>> I think it's a bug in javac, it should not even raise a warning but an error.
>>> But the spec is not fully clear.
>> 
>> If you think that it's a bug, consider providing feedback to authors of JEP 394:
>> 
>>> Other refinements may be incorporated based on further feedback.
>> 
>> I find it hard to believe that authors didn't consider generic use case (even though JEP 394 doesn't have examples of that).
>
> We have considered generics, that why parameterized generics with another type arguments are forbidden, but i think we have forgotten raw types.

I don't think that cast from `Object` to a raw type is unchecked, so as error does not seem warranted to me.

However, I agree javac should produce the rawtype warning for rawtypes in pattern matching instanceof, because we are introducing a new variable (and casting). I've filled:
https://bugs.openjdk.java.net/browse/JDK-8263590

Note the non-pattern matching instanceof does not produce the rawtype warning, and I don't think it should produce it.

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From alanb at openjdk.java.net  Mon Mar 15 11:45:09 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 15 Mar 2021 11:45:09 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v4]
In-Reply-To: <mBzztFpUt7brdGHXQz2gvLsU2GM8xiNI8K8cSESuxKU=.4928c4bf-7cef-4213-92b8-b6cfa63cb889@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
 <-SbLgW2n90cLQIGHulyofX7nRzvFZxw_Hej14jTbJDQ=.a4942343-3dfb-459c-baed-bad73a1229c5@github.com>
 <-D4lEMJ8ZdR4BK89uxgUfXDuoQI9qRsbYW6_5QS2-FY=.7f408f1d-fca1-48a4-b59f-a5fba532b94e@github.com>
 <mBzztFpUt7brdGHXQz2gvLsU2GM8xiNI8K8cSESuxKU=.4928c4bf-7cef-4213-92b8-b6cfa63cb889@github.com>
Message-ID: <kTM5ChOIIfycb1HMhVPL8X-J5wwTUiQ2E5g_ivfNGE8=.ae6076bc-e8ea-4167-bc46-12fae4ace359@github.com>

On Sun, 14 Mar 2021 19:32:11 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> Done

I think I'd prefer if the exception message would say that the JMOD is invalid or that the JMOD file is truncated (because I don't think anyone seeing this exception will know anything about the header).

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 12:19:19 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 12:19:19 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v5]
In-Reply-To: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
Message-ID: <-sGRvFheVqAlzk64IjfZpMhR0-UDJunrr2HtzYZ3yCM=.3235f9f4-e8f2-44b8-9e20-b7904f53a5b6@github.com>

> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
> 
> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

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

  Fix error message

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2992/files
  - new: https://git.openjdk.java.net/jdk/pull/2992/files/f69c8ff4..ff25cc4d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 12:19:20 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 12:19:20 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v5]
In-Reply-To: <kTM5ChOIIfycb1HMhVPL8X-J5wwTUiQ2E5g_ivfNGE8=.ae6076bc-e8ea-4167-bc46-12fae4ace359@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <fWJAdm0y88plQELIXKkHhbl7ylQNhFZOmKyVjifd60s=.8a1af854-1804-415a-90f4-c19073eb4146@github.com>
 <-SbLgW2n90cLQIGHulyofX7nRzvFZxw_Hej14jTbJDQ=.a4942343-3dfb-459c-baed-bad73a1229c5@github.com>
 <-D4lEMJ8ZdR4BK89uxgUfXDuoQI9qRsbYW6_5QS2-FY=.7f408f1d-fca1-48a4-b59f-a5fba532b94e@github.com>
 <mBzztFpUt7brdGHXQz2gvLsU2GM8xiNI8K8cSESuxKU=.4928c4bf-7cef-4213-92b8-b6cfa63cb889@github.com>
 <kTM5ChOIIfycb1HMhVPL8X-J5wwTUiQ2E5g_ivfNGE8=.ae6076bc-e8ea-4167-bc46-12fae4ace359@github.com>
Message-ID: <yMAfv0SBA75CqMmGml8nR6Gcbc0vtlEFzV8xX98yb_o=.695245e8-4b85-4f12-a351-810fcb50f2a5@github.com>

On Mon, 15 Mar 2021 11:41:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Done
>
>> Done
> 
> I think I'd prefer if the exception message would say that the JMOD is invalid or that the JMOD file is truncated (because I don't think anyone seeing this exception will know anything about the header).

Fixed

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From redestad at openjdk.java.net  Mon Mar 15 12:40:16 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 15 Mar 2021 12:40:16 GMT
Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings
In-Reply-To: <MsyGNERwG_diNSKYaPDUvJbS28dFAHy10UfXtGl_EYA=.c0b3b510-e0c2-43b5-a0e0-0e69570c69b5@github.com>
References: <V3-_ghd9MJZQxCWSiSwpVXHs-u4DaQo_g3mSjH9wOX0=.08042cfb-bce0-4885-8f58-049450952b1e@github.com>
 <RBydfhue4iiVq9uTQcMPxkYWaJZZAUfQfZa497lKhQ4=.32eb0e60-0961-494b-87e4-01e048e2fcc3@github.com>
 <MsyGNERwG_diNSKYaPDUvJbS28dFAHy10UfXtGl_EYA=.c0b3b510-e0c2-43b5-a0e0-0e69570c69b5@github.com>
Message-ID: <CCqD6Fp8scZ1ra0RLefsKVKNkgInqy09gm-nb4URAGY=.5da92578-7f4a-40aa-bfb3-cbdc126ccbcb@github.com>

On Thu, 18 Feb 2021 20:14:12 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Some of these changes conflict with #2334, which suggest removing the `coder` and `isLatin1` methods from `String`. 
>> 
>> As a more general point I think it would be good to explore options that does not increase leakage of the implementation detail that `Strings` are latin1- or utf16-encoded outside of java.lang.
>
> Hi @cl4es,
>> Some of these changes conflict with #2334, which suggest removing the `coder` and `isLatin1` methods from `String`.
> 
> I've checked out Aleksey's branch and applied my changes onto it, the only thing that I changed to make it work is replacing
> public boolean isLatin1(String str) {
>     return str.isLatin1();
> }
> with
> public boolean isLatin1(String str) {
>     return str.coder == String.LATIN1;
> }
> The rest of the code was left intact. `jdk:tier1` is OK after the change.
>> As a more general point I think it would be good to explore options that does not increase leakage of the implementation detail that `Strings` are latin1- or utf16-encoded outside of java.lang.
> 
> Apart from `JavaLangAccess` the only thing that comes to my mind is reflection, but it will destroy all the improvement. Otherwise I cannot figure out any other way to access somehow package-private latin/non-latin functionality of `j.l.String` in `java.util` package. I wonder, whether I'm missing any other opportunities?

A less intrusive alternative would be to use a `StringBuilder`, see changes in this branch: https://github.com/openjdk/jdk/compare/master...cl4es:stringjoin_improvement?expand=1 (I adapted your StringJoinerBenchmark to work with the ascii-only build constraint)

This underperforms compared to your patch since StringBuilder.toString needs to do a copy, but improves over the baseline:
Benchmark                                                            (count)  (length)  (mode)  Mode  Cnt      Score      Error   Units
StringJoinerBenchmark.stringJoiner                                       100        64   latin  avgt    5   5420.701 ? 1433.485   ns/op
StringJoinerBenchmark.stringJoiner:?gc.alloc.rate.norm                   100        64   latin  avgt    5  20640.428 ?    0.130    B/op
Patch:
Benchmark                                                            (count)  (length)  (mode)  Mode  Cnt      Score      Error   Units
StringJoinerBenchmark.stringJoiner                                       100        64   latin  avgt    5   4271.401 ?  677.560   ns/op
StringJoinerBenchmark.stringJoiner:?gc.alloc.rate.norm                   100        64   latin  avgt    5  14136.294 ?    0.095    B/op

The comparative benefit is that we'd avoid punching more holes into String implementation details for now. Not ruling that out indefinitely, but I think it needs a stronger motivation than to improve StringJoiner alone.

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

PR: https://git.openjdk.java.net/jdk/pull/2627

From jlaskey at openjdk.java.net  Mon Mar 15 12:54:32 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 15 Mar 2021 12:54:32 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v31]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <VKucCe2YRlRl3S6HDMxN5_q9xx6450oLSs2eHsfEFIA=.3dc00672-45c9-4f1e-b5bd-1968aa0bf63b@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Missing @since

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/ddb1a30c..9d05aa56

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=30
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=29-30

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From jboes at openjdk.java.net  Mon Mar 15 12:55:11 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 15 Mar 2021 12:55:11 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy
In-Reply-To: <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>
 <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
Message-ID: <yTKkQHWG8Qd3WtteVvA2tqZz4hH1c_qA1jOhtHl9NjM=.6d67bde5-0fa3-4973-857b-f539cab13a32@github.com>

On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed?
>> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422
>> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746
>
> @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)?

@turbanoff Given that this PR has been lingering for a while, you could drop the change in `X509CertPath.java` for now and integrate the remaining changes. I'm happy to sponsor in that case.

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

PR: https://git.openjdk.java.net/jdk/pull/1853

From dcubed at openjdk.java.net  Mon Mar 15 13:33:09 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Mon, 15 Mar 2021 13:33:09 GMT
Subject: RFR: 8263556: remove `@modules java.base` from tests
In-Reply-To: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
References: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
Message-ID: <vt_ig8proE47pyW_GO65iNSBJze1J1lth7funqC5hLY=.767f73f0-c662-40de-961d-8f6e542abdff@github.com>

On Sat, 13 Mar 2021 20:26:42 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial cleanup?
> from JBS:
> 
>> jtreg `@modules X` directive does two things: 
>>  - exclude a test from execution if JDK under test doesn't have module X 
>>  - if JDK under test has module X, make sure it's resolved 
>> 
>> both these things have no sense for `java.base` module as it's always available and is always resolved.
> 
> 
> Thanks,
> -- Igor

Thumbs up.

I agree that this is a trivial change.

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

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2990

From github.com+828220+forax at openjdk.java.net  Mon Mar 15 13:37:12 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Mon, 15 Mar 2021 13:37:12 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <vv2SyuK5RxMBEl5ACrKE4AvEa09erdnpzAlAvJJ0RB4=.85ad4384-3e09-4154-8bdd-a34151515e4d@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
 <tqJTgA567Bmq7ki1OSyRR-T0aZLf6xEB4AaQa2OFp0o=.c05e8419-cf23-4010-8cfa-78b29f1bffed@github.com>
 <7M1a_-toj0cuTbLnwxcqEGZopF92y-8piQkrl-_EXa8=.bab041cf-4e26-42bc-bf7d-bd67ce3f8000@github.com>
 <EB3BACJqC1S88itLaCIfLKtjtmp3FPDYxaD3wzUalok=.54b6f6d1-f0c9-4b42-8277-90c2571f5865@github.com>
 <V4M_1KPi4i2nUUYL1SLLvnluQwlBe0QI3fg73OSm_iU=.33bd47b5-0689-47e7-9e8e-b148d4a4892f@github.com>
 <xC2ZpmH0eWLyVQTQ43nif3mjfITV1-gaaiXGx6Csbn4=.ff1d3a53-2760-45f4-9412-f9f7d959b263@github.com>
 <vv2SyuK5RxMBEl5ACrKE4AvEa09erdnpzAlAvJJ0RB4=.85ad4384-3e09-4154-8bdd-a34151515e4d@github.com>
Message-ID: <HtduJdTzDVuHdDa70KDPZicD-opgSDK7EHWZPCraZSI=.0e2bd9a9-4109-4627-8c3c-7a7b0f29f143@github.com>

On Mon, 15 Mar 2021 11:39:20 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> We have considered generics, that why parameterized generics with another type arguments are forbidden, but i think we have forgotten raw types.
>
> I don't think that cast from `Object` to a raw type is unchecked, so as error does not seem warranted to me.
> 
> However, I agree javac should produce the rawtype warning for rawtypes in pattern matching instanceof, because we are introducing a new variable (and casting). I've filled:
> https://bugs.openjdk.java.net/browse/JDK-8263590
> 
> Note the non-pattern matching instanceof does not produce the rawtype warning, and I don't think it should produce it.

yes,
javac should emit a warning in that case, that also the answer of Brian.

https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-March/002925.html

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From alanb at openjdk.java.net  Mon Mar 15 13:48:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 15 Mar 2021 13:48:08 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v5]
In-Reply-To: <-sGRvFheVqAlzk64IjfZpMhR0-UDJunrr2HtzYZ3yCM=.3235f9f4-e8f2-44b8-9e20-b7904f53a5b6@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <-sGRvFheVqAlzk64IjfZpMhR0-UDJunrr2HtzYZ3yCM=.3235f9f4-e8f2-44b8-9e20-b7904f53a5b6@github.com>
Message-ID: <m9HYVx65pZQEN8sqoGogPmWS-15d2Ox0_10QtvBWGn0=.058a5e84-3dee-4e22-95c1-fa488aea1b70@github.com>

On Mon, 15 Mar 2021 12:19:19 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
>> 
>> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix error message

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From prappo at openjdk.java.net  Mon Mar 15 13:53:16 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 15 Mar 2021 13:53:16 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <HtduJdTzDVuHdDa70KDPZicD-opgSDK7EHWZPCraZSI=.0e2bd9a9-4109-4627-8c3c-7a7b0f29f143@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
 <tqJTgA567Bmq7ki1OSyRR-T0aZLf6xEB4AaQa2OFp0o=.c05e8419-cf23-4010-8cfa-78b29f1bffed@github.com>
 <7M1a_-toj0cuTbLnwxcqEGZopF92y-8piQkrl-_EXa8=.bab041cf-4e26-42bc-bf7d-bd67ce3f8000@github.com>
 <EB3BACJqC1S88itLaCIfLKtjtmp3FPDYxaD3wzUalok=.54b6f6d1-f0c9-4b42-8277-90c2571f5865@github.com>
 <V4M_1KPi4i2nUUYL1SLLvnluQwlBe0QI3fg73OSm_iU=.33bd47b5-0689-47e7-9e8e-b148d4a4892f@github.com>
 <xC2ZpmH0eWLyVQTQ43nif3mjfITV1-gaaiXGx6Csbn4=.ff1d3a53-2760-45f4-9412-f9f7d959b263@github.com>
 <vv2SyuK5RxMBEl5ACrKE4AvEa09erdnpzAlAvJJ0RB4=.85ad4384-3e09-4154-8bdd-a34151515e4d@github.com>
 <HtduJdTzDVuHdDa70KDPZicD-opgSDK7EHWZPCraZSI=.0e2bd9a9-4109-4627-8c3c-7a7b0f29f143@github.com>
Message-ID: <vSVVMKXLSecZvJj9_yKie9XTL49Is0hFpVtfWosCT8s=.8703bc88-d187-4378-b517-ecb5a71bba6f@github.com>

On Mon, 15 Mar 2021 13:34:45 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> I don't think that cast from `Object` to a raw type is unchecked, so as error does not seem warranted to me.
>> 
>> However, I agree javac should produce the rawtype warning for rawtypes in pattern matching instanceof, because we are introducing a new variable (and casting). I've filled:
>> https://bugs.openjdk.java.net/browse/JDK-8263590
>> 
>> Note the non-pattern matching instanceof does not produce the rawtype warning, and I don't think it should produce it.
>
> yes,
> javac should emit a warning in that case, that also the answer of Brian.
> 
> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-March/002925.html

Then we should use an unbounded wildcard here and in similar places to avoid "rawtype" warnings in the future.

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 13:56:08 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 13:56:08 GMT
Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings
In-Reply-To: <CCqD6Fp8scZ1ra0RLefsKVKNkgInqy09gm-nb4URAGY=.5da92578-7f4a-40aa-bfb3-cbdc126ccbcb@github.com>
References: <V3-_ghd9MJZQxCWSiSwpVXHs-u4DaQo_g3mSjH9wOX0=.08042cfb-bce0-4885-8f58-049450952b1e@github.com>
 <RBydfhue4iiVq9uTQcMPxkYWaJZZAUfQfZa497lKhQ4=.32eb0e60-0961-494b-87e4-01e048e2fcc3@github.com>
 <MsyGNERwG_diNSKYaPDUvJbS28dFAHy10UfXtGl_EYA=.c0b3b510-e0c2-43b5-a0e0-0e69570c69b5@github.com>
 <CCqD6Fp8scZ1ra0RLefsKVKNkgInqy09gm-nb4URAGY=.5da92578-7f4a-40aa-bfb3-cbdc126ccbcb@github.com>
Message-ID: <vl8lNoVuXYbiwxECvX4BFVlR_LZlwWLPmpNh1sZ_aLw=.948e1e18-6ed2-4fef-afe4-8cc9a064d31c@github.com>

On Mon, 15 Mar 2021 12:36:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Hi @cl4es,
>>> Some of these changes conflict with #2334, which suggest removing the `coder` and `isLatin1` methods from `String`.
>> 
>> I've checked out Aleksey's branch and applied my changes onto it, the only thing that I changed to make it work is replacing
>> public boolean isLatin1(String str) {
>>     return str.isLatin1();
>> }
>> with
>> public boolean isLatin1(String str) {
>>     return str.coder == String.LATIN1;
>> }
>> The rest of the code was left intact. `jdk:tier1` is OK after the change.
>>> As a more general point I think it would be good to explore options that does not increase leakage of the implementation detail that `Strings` are latin1- or utf16-encoded outside of java.lang.
>> 
>> Apart from `JavaLangAccess` the only thing that comes to my mind is reflection, but it will destroy all the improvement. Otherwise I cannot figure out any other way to access somehow package-private latin/non-latin functionality of `j.l.String` in `java.util` package. I wonder, whether I'm missing any other opportunities?
>
> A less intrusive alternative would be to use a `StringBuilder`, see changes in this branch: https://github.com/openjdk/jdk/compare/master...cl4es:stringjoin_improvement?expand=1 (I adapted your StringJoinerBenchmark to work with the ascii-only build constraint)
> 
> This underperforms compared to your patch since StringBuilder.toString needs to do a copy, but improves over the baseline:
> Benchmark                                                            (count)  (length)  (mode)  Mode  Cnt      Score      Error   Units
> StringJoinerBenchmark.stringJoiner                                       100        64   latin  avgt    5   5420.701 ? 1433.485   ns/op
> StringJoinerBenchmark.stringJoiner:?gc.alloc.rate.norm                   100        64   latin  avgt    5  20640.428 ?    0.130    B/op
> Patch:
> Benchmark                                                            (count)  (length)  (mode)  Mode  Cnt      Score      Error   Units
> StringJoinerBenchmark.stringJoiner                                       100        64   latin  avgt    5   4271.401 ?  677.560   ns/op
> StringJoinerBenchmark.stringJoiner:?gc.alloc.rate.norm                   100        64   latin  avgt    5  14136.294 ?    0.095    B/op
> 
> The comparative benefit is that we'd avoid punching more holes into String implementation details for now. Not ruling that out indefinitely, but I think it needs a stronger motivation than to improve StringJoiner alone.

I was thinking about `StringBuilder` at the very beginning but then decided to have no bounds checks and reallocations. Indeed from maintainability point of view your solution is much more attractive. I have one minor comment about `append()`: I think we should do more chaining, e.g. 
StringBuilder sb = new StringBuilder(len);
sb.append(elts[0]);
should be
StringBuilder sb = new StringBuilder(len).append(elts[0]);
etc. to have less bytecode.

E.g. if we take 
public String sb() {
  StringBuilder sb = new StringBuilder();
  
  sb.append("a");
  sb.append("b");
  
  return sb.toString();
}
`sb.append()` gets compiled into
L1
 LINENUMBER 23 L1
 ALOAD 1
 LDC "a"
 INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
 POP
L2
 LINENUMBER 24 L2
 ALOAD 1
 LDC "b"
 INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
 POP
 ```
 and in case we have
 ```
 sb.append("a").append("b");
 ```
 the amount of byte code is reduced:
 ```
 L1
 LINENUMBER 23 L1
 ALOAD 1
 LDC "a"
 INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
 LDC "b"
 INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
 POP
 ```
 
 Also I'd change
if (addLen == 0) {
    compactElts();
    return size == 0 ? "" : elts[0];
}
to
if (size == 0) {
    if (addLen == 0) {
        return "";
    }
    return prefix + suffix;
}
The second variant is more understandable to me and likely to be slightly faster.

And finally, should I close this PR and you'll create a new one from your branch, or I need to copy your changes here?

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

PR: https://git.openjdk.java.net/jdk/pull/2627

From redestad at openjdk.java.net  Mon Mar 15 14:10:09 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 15 Mar 2021 14:10:09 GMT
Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings
In-Reply-To: <vl8lNoVuXYbiwxECvX4BFVlR_LZlwWLPmpNh1sZ_aLw=.948e1e18-6ed2-4fef-afe4-8cc9a064d31c@github.com>
References: <V3-_ghd9MJZQxCWSiSwpVXHs-u4DaQo_g3mSjH9wOX0=.08042cfb-bce0-4885-8f58-049450952b1e@github.com>
 <RBydfhue4iiVq9uTQcMPxkYWaJZZAUfQfZa497lKhQ4=.32eb0e60-0961-494b-87e4-01e048e2fcc3@github.com>
 <MsyGNERwG_diNSKYaPDUvJbS28dFAHy10UfXtGl_EYA=.c0b3b510-e0c2-43b5-a0e0-0e69570c69b5@github.com>
 <CCqD6Fp8scZ1ra0RLefsKVKNkgInqy09gm-nb4URAGY=.5da92578-7f4a-40aa-bfb3-cbdc126ccbcb@github.com>
 <vl8lNoVuXYbiwxECvX4BFVlR_LZlwWLPmpNh1sZ_aLw=.948e1e18-6ed2-4fef-afe4-8cc9a064d31c@github.com>
Message-ID: <DUKI1X0giFYCkYBQtHjhcVHIQGfzXw2x0tePTp6MOv4=.30a93b32-0f26-42a8-a48c-e1734932a6cf@github.com>

On Mon, 15 Mar 2021 13:52:57 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> A less intrusive alternative would be to use a `StringBuilder`, see changes in this branch: https://github.com/openjdk/jdk/compare/master...cl4es:stringjoin_improvement?expand=1 (I adapted your StringJoinerBenchmark to work with the ascii-only build constraint)
>> 
>> This underperforms compared to your patch since StringBuilder.toString needs to do a copy, but improves over the baseline:
>> Benchmark                                                            (count)  (length)  (mode)  Mode  Cnt      Score      Error   Units
>> StringJoinerBenchmark.stringJoiner                                       100        64   latin  avgt    5   5420.701 ? 1433.485   ns/op
>> StringJoinerBenchmark.stringJoiner:?gc.alloc.rate.norm                   100        64   latin  avgt    5  20640.428 ?    0.130    B/op
>> Patch:
>> Benchmark                                                            (count)  (length)  (mode)  Mode  Cnt      Score      Error   Units
>> StringJoinerBenchmark.stringJoiner                                       100        64   latin  avgt    5   4271.401 ?  677.560   ns/op
>> StringJoinerBenchmark.stringJoiner:?gc.alloc.rate.norm                   100        64   latin  avgt    5  14136.294 ?    0.095    B/op
>> 
>> The comparative benefit is that we'd avoid punching more holes into String implementation details for now. Not ruling that out indefinitely, but I think it needs a stronger motivation than to improve StringJoiner alone.
>
> I was thinking about `StringBuilder` at the very beginning but then decided to have no bounds checks and reallocations. Indeed from maintainability point of view your solution is much more attractive. I have one minor comment about `append()`: I think we should do more chaining, e.g. 
> StringBuilder sb = new StringBuilder(len);
> sb.append(elts[0]);
> should be
> StringBuilder sb = new StringBuilder(len).append(elts[0]);
> etc. to have less bytecode.
> 
> E.g. if we take 
> public String sb() {
>   StringBuilder sb = new StringBuilder();
>   
>   sb.append("a");
>   sb.append("b");
>   
>   return sb.toString();
> }
> `sb.append()` gets compiled into
> L1
>  LINENUMBER 23 L1
>  ALOAD 1
>  LDC "a"
>  INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>  POP
> L2
>  LINENUMBER 24 L2
>  ALOAD 1
>  LDC "b"
>  INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>  POP
>  ```
>  and in case we have
>  ```
>  sb.append("a").append("b");
>  ```
>  the amount of byte code is reduced:
>  ```
>  L1
>  LINENUMBER 23 L1
>  ALOAD 1
>  LDC "a"
>  INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>  LDC "b"
>  INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>  POP
>  ```
>  
>  Also I'd change
> if (addLen == 0) {
>     compactElts();
>     return size == 0 ? "" : elts[0];
> }
> to
> if (size == 0) {
>     if (addLen == 0) {
>         return "";
>     }
>     return prefix + suffix;
> }
> The second variant is more understandable to me and likely to be slightly faster.
> 
> And finally, should I close this PR and you'll create a new one from your branch, or I need to copy your changes here?

Up to you. If you adapt your PR to use a StringBuilder as suggested I can review and sponsor.

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

PR: https://git.openjdk.java.net/jdk/pull/2627

From roger.riggs at oracle.com  Mon Mar 15 14:35:34 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 15 Mar 2021 10:35:34 -0400
Subject: java.io.Serial vs java.io.Serializable javadoc
In-Reply-To: <CAF2POUdV1E16Qonk-OE5E4Y48UMawdrU-SD+Z-i7v79TsW9YZg@mail.gmail.com>
References: <CAF2POUdV1E16Qonk-OE5E4Y48UMawdrU-SD+Z-i7v79TsW9YZg@mail.gmail.com>
Message-ID: <631666b7-d6ff-0a64-b1e9-92053aaab682@oracle.com>

Hi,

The serialVersionUID is recommended to be declared as "private" and 
warrant a warning.
There's no value to it being public or protected and it is just noise in 
the javadoc of the class.
The Serialized Form of each class documents the value of the 
serialVersionUID regardless of the
access modifier.

Similarly, the writeReplace and readResolve methods that are specified to
allow ANY-ACCESS-MODIFIER are recommended to be private also, for the 
same reasons.

Regards, Roger

On 3/13/21 4:07 AM, Zheka Kozlov wrote:
> Hi!
>
> The javadoc of java.io.Serial [1] says that serialVersionUID is private.
> But the javadoc of Serializable [2] says it can have any access modifier.
> Who is right here? When I write the following code, should there be a
> warning or not?
>
> import java.io.Serial;import java.io.Serializable;
> public class SerExample implements Serializable {
>      @Serial // warning or not?
>      public static final long serialVersionUID = 2L;}
>
>
> This question originated in this [3] discussion in the IDEA bugtracker.
>
> With best regards, Zheka.
>
> [1]
> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/io/Serial.html
> [2]
> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/io/Serializable.html
> [3] https://youtrack.jetbrains.com/issue/IDEA-230392


From github.com+741251+turbanoff at openjdk.java.net  Mon Mar 15 14:50:24 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 15 Mar 2021 14:50:24 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy [v13]
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <IuYcSqYk7zxG7hAU605DouLqEQ7zCfLH1VsulI-Zk0A=.aeb9dcfd-d720-4fd2-9577-8bc454dd77a1@github.com>

> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8080272 Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy
  drop changes in X509CertPath

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1853/files
  - new: https://git.openjdk.java.net/jdk/pull/1853/files/1b30471d..96920ee6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1853&range=11-12

  Stats: 25 lines in 1 file changed: 22 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1853.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1853/head:pull/1853

PR: https://git.openjdk.java.net/jdk/pull/1853

From dfuchs at openjdk.java.net  Mon Mar 15 15:08:10 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 15 Mar 2021 15:08:10 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v5]
In-Reply-To: <-sGRvFheVqAlzk64IjfZpMhR0-UDJunrr2HtzYZ3yCM=.3235f9f4-e8f2-44b8-9e20-b7904f53a5b6@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <-sGRvFheVqAlzk64IjfZpMhR0-UDJunrr2HtzYZ3yCM=.3235f9f4-e8f2-44b8-9e20-b7904f53a5b6@github.com>
Message-ID: <bt6JnxMDiLjVjJ64IfNcMFlTT9a_s8ttcrqOCtCNIMw=.0b9a12d7-4b8d-4c93-9ed8-32f4b59e2053@github.com>

On Mon, 15 Mar 2021 12:19:19 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
>> 
>> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix error message

Changes requested by dfuchs (Reviewer).

src/java.base/share/classes/sun/net/www/http/HttpClient.java line 434:

> 432:                 int r = tmpbuf.read();
> 433:                 if (r == -1) {
> 434:                     logFinest("HttpClient.available(): " +

There are some subtle things going on there. Using a `BufferedInputStream` ensures that all the bytes available on the socket will be read, up to the buffer capacity. Can you revert this change? I'd rather that this clean up be handled separately. I have logged https://bugs.openjdk.java.net/browse/JDK-8263599.

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From rriggs at openjdk.java.net  Mon Mar 15 15:32:07 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 15 Mar 2021 15:32:07 GMT
Subject: RFR: 8263450: Simplify LambdaForm.useCount
In-Reply-To: <u8_H4ZrBp-U0QfsWEHgaLZnlWGer-W_85UroyWbTSzY=.72bfdc0e-6cf3-408d-b3ef-c924801b522c@github.com>
References: <u8_H4ZrBp-U0QfsWEHgaLZnlWGer-W_85UroyWbTSzY=.72bfdc0e-6cf3-408d-b3ef-c924801b522c@github.com>
Message-ID: <XR2_eJfQpR4tjdw0N3lbXKLwjPqoEmQNM0KhvV8mSB8=.38ba345f-a010-40d2-8c74-8681896fc4ba@github.com>

On Thu, 11 Mar 2021 14:50:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Simplify useCount and avoid calling lastUseIndex for a small startup win.

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2940

From raffaello.giulietti at gmail.com  Mon Mar 15 16:06:37 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Mon, 15 Mar 2021 17:06:37 +0100
Subject: Comment on CSR 8251991: Hex formatting and parsing utility
In-Reply-To: <994ead35-6c49-8ceb-da9c-916f163feac3@gmail.com>
References: <994ead35-6c49-8ceb-da9c-916f163feac3@gmail.com>
Message-ID: <3f09d0bd-cb53-fa66-1450-d949a9ebfe5d@gmail.com>

Hi,

the javadoc of most of the methods listed in my previous post below reads:
     "The delimiter, prefix, suffix, and uppercase parameters are not used."

As these eventually constitute the whole state of an instance of this 
final class and as the state is not involved, it is possible to declare 
the methods as static.


If, for some reason, declaring the methods as static is not a choice, 
the next best thing is to clarify that
* HexFormat.of() always returns the same instance and thus
* absent any other instance, the recommended idiom for invoking any of 
the methods below is, for example,
     HexFormat.of().isHexDigit('F')
(because there are almost no additional costs wrt static methods.)

But I don't see a reason why they should be non-static. Just oversight?


Greetings
Raffaello


On 2021-03-08 11:52, Raffaello Giulietti wrote:
> Hello,
> 
> it appears that all of the following API methods in [1] can be declared 
> *static*, which makes them more useful in contexts where there's no 
> instance of HexFormat available or none is desired.
> 
> As 17 has not yet entered any formal phase, the change should be harmless.
> 
>  ? public boolean isHexDigit(int);
>  ? public int fromHexDigit(int);
>  ? public int fromHexDigits(java.lang.CharSequence);
>  ? public int fromHexDigits(java.lang.CharSequence, int, int);
>  ? public long fromHexDigitsToLong(java.lang.CharSequence);
>  ? public long fromHexDigitsToLong(java.lang.CharSequence, int, int);
> 
> Greetings
> Raffaello
> 
> ----
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8251991

From naoto at openjdk.java.net  Mon Mar 15 16:21:08 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 15 Mar 2021 16:21:08 GMT
Subject: RFR: 8263556: remove `@modules java.base` from tests
In-Reply-To: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
References: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
Message-ID: <HyuCdO-YEWWAPBA0aMaYStTr9sbkPq4CLtDhDDKFOqo=.d48cb16a-9c44-43bc-9982-8caaa5cb77ea@github.com>

On Sat, 13 Mar 2021 20:26:42 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial cleanup?
> from JBS:
> 
>> jtreg `@modules X` directive does two things: 
>>  - exclude a test from execution if JDK under test doesn't have module X 
>>  - if JDK under test has module X, make sure it's resolved 
>> 
>> both these things have no sense for `java.base` module as it's always available and is always resolved.
> 
> 
> Thanks,
> -- Igor

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2990

From github.com+194713+candrews at openjdk.java.net  Mon Mar 15 16:22:16 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Mon, 15 Mar 2021 16:22:16 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v5]
In-Reply-To: <lGB98jhhteSkUm91H1IdjbrJC2kpcPIDnkZsjPVvAdw=.ee6a5e7b-f3f4-4c9e-a382-2e760c836fc1@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <EhUg_gwzyqIZ3IAPbWqm_s1yOyIW_I9oK_B1yKnqmm8=.a5cf7361-85d2-4656-9f70-6bcd06030bf3@github.com>
 <lGB98jhhteSkUm91H1IdjbrJC2kpcPIDnkZsjPVvAdw=.ee6a5e7b-f3f4-4c9e-a382-2e760c836fc1@github.com>
Message-ID: <ZnBiCIP9eKfGYiXh1bohuLdNdjFHfKKp2aMVC2T7v34=.c939b778-4585-4e30-b7b4-a4b7cbf1120f@github.com>

On Tue, 9 Mar 2021 08:40:47 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Craig Andrews has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:
>> 
>>   JDK-8262277: java.net.URLClassLoader.getResource throws undocumented IllegalArgumentException
>
> Marked as reviewed by psadhukhan (Reviewer).

What's the next step in the process for this PR?

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From iris at openjdk.java.net  Mon Mar 15 16:28:08 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 15 Mar 2021 16:28:08 GMT
Subject: RFR: 8263556: remove `@modules java.base` from tests
In-Reply-To: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
References: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
Message-ID: <THNM-XilKIXLEJ5ppuFH13GRabVhgx82vU7VYnNygJA=.70eb2d24-6ab2-4e0c-ac7f-2f1776513d97@github.com>

On Sat, 13 Mar 2021 20:26:42 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial cleanup?
> from JBS:
> 
>> jtreg `@modules X` directive does two things: 
>>  - exclude a test from execution if JDK under test doesn't have module X 
>>  - if JDK under test has module X, make sure it's resolved 
>> 
>> both these things have no sense for `java.base` module as it's always available and is always resolved.
> 
> 
> Thanks,
> -- Igor

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2990

From kcr at openjdk.java.net  Mon Mar 15 16:29:09 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 15 Mar 2021 16:29:09 GMT
Subject: RFR: JDK-8262277: java.net.URLClassLoader.getResource throws
 undocumented IllegalArgumentException [v5]
In-Reply-To: <ZnBiCIP9eKfGYiXh1bohuLdNdjFHfKKp2aMVC2T7v34=.c939b778-4585-4e30-b7b4-a4b7cbf1120f@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <EhUg_gwzyqIZ3IAPbWqm_s1yOyIW_I9oK_B1yKnqmm8=.a5cf7361-85d2-4656-9f70-6bcd06030bf3@github.com>
 <lGB98jhhteSkUm91H1IdjbrJC2kpcPIDnkZsjPVvAdw=.ee6a5e7b-f3f4-4c9e-a382-2e760c836fc1@github.com>
 <ZnBiCIP9eKfGYiXh1bohuLdNdjFHfKKp2aMVC2T7v34=.c939b778-4585-4e30-b7b4-a4b7cbf1120f@github.com>
Message-ID: <IQ0JlJMYjPz3V8z7RgL8l5rHQEmMMFQbWRocbTwrvrA=.642d4564-8d72-4865-8c14-caad219693d1@github.com>

On Mon, 15 Mar 2021 16:19:20 GMT, Craig Andrews <github.com+194713+candrews at openjdk.org> wrote:

>> Marked as reviewed by psadhukhan (Reviewer).
>
> What's the next step in the process for this PR?

You need to fix this error:

>  Title mismatch between PR and JBS for issue JDK-8262277

by changing the title of this PR to match the JBS title. Then you should be able to integrate it.

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From github.com+194713+candrews at openjdk.java.net  Mon Mar 15 16:33:15 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Mon, 15 Mar 2021 16:33:15 GMT
Subject: RFR: JDK-8262277: URLClassLoader.getResource throws undocumented
 IllegalArgumentException [v5]
In-Reply-To: <IQ0JlJMYjPz3V8z7RgL8l5rHQEmMMFQbWRocbTwrvrA=.642d4564-8d72-4865-8c14-caad219693d1@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <EhUg_gwzyqIZ3IAPbWqm_s1yOyIW_I9oK_B1yKnqmm8=.a5cf7361-85d2-4656-9f70-6bcd06030bf3@github.com>
 <lGB98jhhteSkUm91H1IdjbrJC2kpcPIDnkZsjPVvAdw=.ee6a5e7b-f3f4-4c9e-a382-2e760c836fc1@github.com>
 <ZnBiCIP9eKfGYiXh1bohuLdNdjFHfKKp2aMVC2T7v34=.c939b778-4585-4e30-b7b4-a4b7cbf1120f@github.com>
 <IQ0JlJMYjPz3V8z7RgL8l5rHQEmMMFQbWRocbTwrvrA=.642d4564-8d72-4865-8c14-caad219693d1@github.com>
Message-ID: <zPLZ0doBvrsXoHY9QVvmKiBUhwD-XD9xsY5D5YYcq3M=.8af71177-0f7a-41f7-af2d-6bd6cd1e9388@github.com>

On Mon, 15 Mar 2021 16:26:35 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> You need to fix this error:
> 
> > Title mismatch between PR and JBS for issue JDK-8262277
> 
> by changing the title of this PR to match the JBS title. Then you should be able to integrate it.

Done - how's it look now?

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From kcr at openjdk.java.net  Mon Mar 15 16:39:09 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 15 Mar 2021 16:39:09 GMT
Subject: RFR: JDK-8262277: URLClassLoader.getResource throws undocumented
 IllegalArgumentException [v5]
In-Reply-To: <zPLZ0doBvrsXoHY9QVvmKiBUhwD-XD9xsY5D5YYcq3M=.8af71177-0f7a-41f7-af2d-6bd6cd1e9388@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
 <EhUg_gwzyqIZ3IAPbWqm_s1yOyIW_I9oK_B1yKnqmm8=.a5cf7361-85d2-4656-9f70-6bcd06030bf3@github.com>
 <lGB98jhhteSkUm91H1IdjbrJC2kpcPIDnkZsjPVvAdw=.ee6a5e7b-f3f4-4c9e-a382-2e760c836fc1@github.com>
 <ZnBiCIP9eKfGYiXh1bohuLdNdjFHfKKp2aMVC2T7v34=.c939b778-4585-4e30-b7b4-a4b7cbf1120f@github.com>
 <IQ0JlJMYjPz3V8z7RgL8l5rHQEmMMFQbWRocbTwrvrA=.642d4564-8d72-4865-8c14-caad219693d1@github.com>
 <zPLZ0doBvrsXoHY9QVvmKiBUhwD-XD9xsY5D5YYcq3M=.8af71177-0f7a-41f7-af2d-6bd6cd1e9388@github.com>
Message-ID: <qKDfn5lCB5pZxrFwCcvOoxff7Eq5Ttx2GCLoKn1j0U8=.0a2a3c27-c5a6-4dc4-9de3-c71571ee539f@github.com>

On Mon, 15 Mar 2021 16:29:54 GMT, Craig Andrews <github.com+194713+candrews at openjdk.org> wrote:

>> You need to fix this error:
>> 
>>>  Title mismatch between PR and JBS for issue JDK-8262277
>> 
>> by changing the title of this PR to match the JBS title. Then you should be able to integrate it.
>
>> You need to fix this error:
>> 
>> > Title mismatch between PR and JBS for issue JDK-8262277
>> 
>> by changing the title of this PR to match the JBS title. Then you should be able to integrate it.
> 
> Done - how's it look now?

You don't need to add yourself as a contributor. The only thing you need to do is integrate. Then it is ready to be sponsored.

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From iignatyev at openjdk.java.net  Mon Mar 15 17:08:09 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 15 Mar 2021 17:08:09 GMT
Subject: RFR: 8263556: remove `@modules java.base` from tests
In-Reply-To: <THNM-XilKIXLEJ5ppuFH13GRabVhgx82vU7VYnNygJA=.70eb2d24-6ab2-4e0c-ac7f-2f1776513d97@github.com>
References: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
 <THNM-XilKIXLEJ5ppuFH13GRabVhgx82vU7VYnNygJA=.70eb2d24-6ab2-4e0c-ac7f-2f1776513d97@github.com>
Message-ID: <W4rj4p-NDWVUTm1bihvZuOXxeH550Oks3UZbs7G5Am0=.db3e6087-440d-4da4-8b21-a55780dfe190@github.com>

On Mon, 15 Mar 2021 16:25:48 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Hi all,
>> 
>> could you please review this trivial cleanup?
>> from JBS:
>> 
>>> jtreg `@modules X` directive does two things: 
>>>  - exclude a test from execution if JDK under test doesn't have module X 
>>>  - if JDK under test has module X, make sure it's resolved 
>>> 
>>> both these things have no sense for `java.base` module as it's always available and is always resolved.
>> 
>> 
>> Thanks,
>> -- Igor
>
> Marked as reviewed by iris (Reviewer).

Iris, Naoto, Dan, thank you for your reviews!

-- Igor

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

PR: https://git.openjdk.java.net/jdk/pull/2990

From iignatyev at openjdk.java.net  Mon Mar 15 17:08:10 2021
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 15 Mar 2021 17:08:10 GMT
Subject: Integrated: 8263556: remove `@modules java.base` from tests
In-Reply-To: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
References: <mhVD9GRUgDYhNnaeM4_mNSg3jUjqrk9HV48wBI0cO2E=.ce4baf13-aed3-4a44-8482-9b2930bc94d8@github.com>
Message-ID: <47c19e0cAuCEtsxE3PtvwXJdmbdvqPSj7oZglqg5c_E=.6d397d21-b62d-4c77-a6fb-7d682b983870@github.com>

On Sat, 13 Mar 2021 20:26:42 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

> Hi all,
> 
> could you please review this trivial cleanup?
> from JBS:
> 
>> jtreg `@modules X` directive does two things: 
>>  - exclude a test from execution if JDK under test doesn't have module X 
>>  - if JDK under test has module X, make sure it's resolved 
>> 
>> both these things have no sense for `java.base` module as it's always available and is always resolved.
> 
> 
> Thanks,
> -- Igor

This pull request has now been integrated.

Changeset: d825198e
Author:    Igor Ignatyev <iignatyev at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d825198e
Stats:     21 lines in 13 files changed: 0 ins; 13 del; 8 mod

8263556: remove `@modules java.base` from tests

Reviewed-by: dcubed, naoto, iris

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

PR: https://git.openjdk.java.net/jdk/pull/2990

From chegar at openjdk.java.net  Mon Mar 15 17:19:08 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 15 Mar 2021 17:19:08 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v2]
In-Reply-To: <zMZdl4V9pFvTiqeVfGa1ba7tux0Oa89AV0ndfNLmlnw=.1205a1c3-fe8d-4320-b767-f0816898491d@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <8601DNFkEWL76jjuZpNosikeT-1L6fsoz9yf5B79uoU=.bfb92ddd-63d8-44b3-84b6-c73413ab342f@github.com>
 <gLGKOnXo8i_FuwF2ahIwi6zlGzdzoZfXvyu9g3-BoWk=.3ff679bc-c900-4220-89bf-e3cf83a2bada@github.com>
 <BaNG8I3A5tjrXTveKKV9N7EpB1dZmjvVBnhd229zrx0=.a3b25438-34d2-46f4-8f62-40f1b2b8d454@github.com>
 <zMZdl4V9pFvTiqeVfGa1ba7tux0Oa89AV0ndfNLmlnw=.1205a1c3-fe8d-4320-b767-f0816898491d@github.com>
Message-ID: <OiZ8iko9D0za8sU_cfO1vT9dvQWilq4BpVINcb75HHE=.c654474f-f01a-425e-badf-a867454bf1cc@github.com>

On Mon, 15 Mar 2021 08:53:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> If you and others think that we can ignore this case, then your proposed approach of using this lazy holder for initialization, IMO, is much cleaner and natural to read and I will go ahead and update this PR to use it.

For me, at least, the holder pattern is clearer. I'm happy with that approach.   ( I don't have an objection to the alternative, just a mild preference for the holder )

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From asemenyuk at openjdk.java.net  Mon Mar 15 17:36:15 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 15 Mar 2021 17:36:15 GMT
Subject: RFR: JDK-8263545: Convert jpackage to use Stream.toList()
In-Reply-To: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
References: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
Message-ID: <UxJmdCQmgxgcn-eGei7EABKV--91CTwpfybIGhwKZOs=.bd461f87-487f-44fc-b05e-4df03f87f1a4@github.com>

On Sun, 14 Mar 2021 18:22:50 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This converts jpackage to use `Stream.toList()` instead of `Stream.collect(Collectors.toList())`. One piece of code was modified to not mutate a list in addition to one test that used a mutating sort on a list. The rest of the changes are simple substitutions.

Looks good. Minor improvements suggested.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java line 200:

> 198:         ).map(e -> {
> 199:             e.getValue().setOutputFileName(e.getKey());
> 200:             return (WixFragmentBuilder) e.getValue();

Why this explicit cast is needed here?

src/jdk.jpackage/share/classes/jdk/jpackage/internal/DottedVersion.java line 151:

> 149:             components.add(BigInteger.ZERO);
> 150:         }
> 151:         return components.stream().toList().toArray(BigInteger[]::new);

I guess this can be simplified down to `components.stream().toArray(BigInteger[]::new);`

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

PR: https://git.openjdk.java.net/jdk/pull/2997

From igraves at openjdk.java.net  Mon Mar 15 17:55:10 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 15 Mar 2021 17:55:10 GMT
Subject: RFR: JDK-8263545: Convert jpackage to use Stream.toList()
In-Reply-To: <UxJmdCQmgxgcn-eGei7EABKV--91CTwpfybIGhwKZOs=.bd461f87-487f-44fc-b05e-4df03f87f1a4@github.com>
References: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
 <UxJmdCQmgxgcn-eGei7EABKV--91CTwpfybIGhwKZOs=.bd461f87-487f-44fc-b05e-4df03f87f1a4@github.com>
Message-ID: <GSSifLCc-IIpbTaI7pmGz5TPBzeOp4DJPfQG8VEe3Qc=.87e7b0b8-4858-44e4-a860-255786658100@github.com>

On Mon, 15 Mar 2021 17:31:10 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> This converts jpackage to use `Stream.toList()` instead of `Stream.collect(Collectors.toList())`. One piece of code was modified to not mutate a list in addition to one test that used a mutating sort on a list. The rest of the changes are simple substitutions.
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/DottedVersion.java line 151:
> 
>> 149:             components.add(BigInteger.ZERO);
>> 150:         }
>> 151:         return components.stream().toList().toArray(BigInteger[]::new);
> 
> I guess this can be simplified down to `components.stream().toArray(BigInteger[]::new);`

Good catch!

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

PR: https://git.openjdk.java.net/jdk/pull/2997

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 17:56:11 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 17:56:11 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v5]
In-Reply-To: <bt6JnxMDiLjVjJ64IfNcMFlTT9a_s8ttcrqOCtCNIMw=.0b9a12d7-4b8d-4c93-9ed8-32f4b59e2053@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <-sGRvFheVqAlzk64IjfZpMhR0-UDJunrr2HtzYZ3yCM=.3235f9f4-e8f2-44b8-9e20-b7904f53a5b6@github.com>
 <bt6JnxMDiLjVjJ64IfNcMFlTT9a_s8ttcrqOCtCNIMw=.0b9a12d7-4b8d-4c93-9ed8-32f4b59e2053@github.com>
Message-ID: <fnnHKy_PXoUoF5XhxlLinChVMRSa3t0Ap7km0xtHB5w=.5c9b320e-88f3-486e-a9c3-fb760b3afc0f@github.com>

On Mon, 15 Mar 2021 15:04:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix error message
>
> src/java.base/share/classes/sun/net/www/http/HttpClient.java line 434:
> 
>> 432:                 int r = tmpbuf.read();
>> 433:                 if (r == -1) {
>> 434:                     logFinest("HttpClient.available(): " +
> 
> There are some subtle things going on there. Using a `BufferedInputStream` ensures that all the bytes available on the socket will be read, up to the buffer capacity. Can you revert this change? I'd rather that this clean up be handled separately. I have logged https://bugs.openjdk.java.net/browse/JDK-8263599.

Sure, I'll revert this.

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 18:00:27 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 18:00:27 GMT
Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings [v2]
In-Reply-To: <V3-_ghd9MJZQxCWSiSwpVXHs-u4DaQo_g3mSjH9wOX0=.08042cfb-bce0-4885-8f58-049450952b1e@github.com>
References: <V3-_ghd9MJZQxCWSiSwpVXHs-u4DaQo_g3mSjH9wOX0=.08042cfb-bce0-4885-8f58-049450952b1e@github.com>
Message-ID: <RuwRUTqLndnJduD4RdMhxYq006a0GsITIZB3crliZYU=.645d9f89-d189-4695-b003-a031af309765@github.com>

> Hello,
> 
> as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings.
> 
> This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols.
> 
> As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called:
> String delimiter = this.delimiter;
> char[] chars = new char[this.len + addLen];
> int k = getChars(this.prefix, chars, 0);
> if (size > 0) {
>     k += getChars(elts[0], chars, k);        // inflate byte[]
> 
>     for(int i = 1; i < size; ++i) {
>         k += getChars(delimiter, chars, k);
>         k += getChars(elts[i], chars, k);
>     }
> }
> 
> k += getChars(this.suffix, chars, k);
> return new String(chars);                    // compress char[] -> byte[]
> This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082)
> covering both cases when resulting String is Latin1 or UTF-16
> 
> I've prepared a patch along with benchmark proving that this change is correct and brings improvement.
> 
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class StringJoinerBenchmark {
> 
>   @Benchmark
>   public String stringJoiner(Data data) {
>     String[] stringArray = data.stringArray;
>     return Joiner.joinWithStringJoiner(stringArray);
>   }
> 
>   @State(Scope.Thread)
>   public static class Data {
> 
>     @Param({"latin", "cyrillic", "mixed"})
>     private String mode;
> 
>     @Param({"8", "32", "64"})
>     private int length;
> 
>     @Param({"5", "10", "100"})
>     private int count;
> 
>     private String[] stringArray;
> 
>     @Setup
>     public void setup() {
>       RandomStringGenerator generator = new RandomStringGenerator();
> 
>       stringArray = new String[count];
> 
>       for (int i = 0; i < count; i++) {
>         String alphabet = getAlphabet(i, mode);
>         stringArray[i] = generator.randomString(alphabet, length);
>       }
>     }
> 
>     private static String getAlphabet(int index, String mode) {
>       var latin = "abcdefghijklmnopqrstuvwxyz"; //English
>       var cyrillic = "????????????????????????????????"; // Russian
> 
>       String alphabet;
>       switch (mode) {
>         case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin;
>         case "latin" -> alphabet = latin;
>         case "cyrillic" -> alphabet = cyrillic;
>         default -> throw new RuntimeException("Illegal mode " + mode);
>       }
>       return alphabet;
>     }
>   }
> }
> 
> public class Joiner {
> 
>   public static String joinWithStringJoiner(String[] stringArray) {
>     StringJoiner joiner = new StringJoiner(",", "[", "]");
>     for (String str : stringArray) {
>       joiner.add(str);
>     }
>     return joiner.toString();
>   }
> }
> 
> 
>                                     (count)  (length)    (mode)                Java 14                 patched     Units
> stringJoiner                              5         8     latin       78.836 ?   0.208        67.546 ?   0.500     ns/op
> stringJoiner                              5        32     latin       92.877 ?   0.422        66.760 ?   0.498     ns/op
> stringJoiner                              5        64     latin      115.423 ?   0.883        73.224 ?   0.289     ns/op
> stringJoiner                             10         8     latin      152.587 ?   0.429       161.427 ?   0.635     ns/op
> stringJoiner                             10        32     latin      189.998 ?   0.478       164.099 ?   0.963     ns/op
> stringJoiner                             10        64     latin      238.679 ?   1.419       176.825 ?   0.533     ns/op
> stringJoiner                            100         8     latin     1215.612 ?  17.413      1541.802 ? 126.166     ns/op
> stringJoiner                            100        32     latin     1699.998 ?  28.407      1563.341 ?   4.439     ns/op
> stringJoiner                            100        64     latin     2289.388 ?  45.319      2215.931 ? 137.583     ns/op
> stringJoiner                              5         8  cyrillic       96.692 ?   0.947        80.946 ?   0.371     ns/op
> stringJoiner                              5        32  cyrillic      107.806 ?   0.429        84.717 ?   0.541     ns/op
> stringJoiner                              5        64  cyrillic      150.762 ?   2.267        96.214 ?   1.251     ns/op
> stringJoiner                             10         8  cyrillic      190.570 ?   0.381       182.754 ?   0.678     ns/op
> stringJoiner                             10        32  cyrillic      240.239 ?   1.110       187.991 ?   1.575     ns/op
> stringJoiner                             10        64  cyrillic      382.493 ?   2.692       219.358 ?   0.967     ns/op
> stringJoiner                            100         8  cyrillic     1737.435 ?  16.171      1658.379 ?  56.225     ns/op
> stringJoiner                            100        32  cyrillic     2321.106 ?  13.583      1942.028 ?   3.418     ns/op
> stringJoiner                            100        64  cyrillic     3189.563 ?  10.135      2484.796 ?   7.572     ns/op
> stringJoiner                              5         8     mixed       88.743 ?   0.709        76.049 ?   0.685     ns/op
> stringJoiner                              5        32     mixed      103.425 ?   0.745        81.006 ?   0.184     ns/op
> stringJoiner                              5        64     mixed      146.441 ?   0.763        93.071 ?   0.858     ns/op
> stringJoiner                             10         8     mixed      169.262 ?   0.482       158.890 ?   0.598     ns/op
> stringJoiner                             10        32     mixed      218.566 ?   0.945       170.415 ?   1.172     ns/op
> stringJoiner                             10        64     mixed      361.412 ?   1.546       200.374 ?   0.683     ns/op
> stringJoiner                            100         8     mixed     1594.544 ?   5.761      1476.689 ?   2.004     ns/op
> stringJoiner                            100        32     mixed     2221.333 ?  28.320      1879.071 ?  52.729     ns/op
> stringJoiner                            100        64     mixed     3115.786 ?  22.485      2400.644 ?   4.401     ns/op
> 
> stringJoiner:?gc.alloc.rate.norm          5         8     latin      248.023 ?   0.001       136.015 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        32     latin      608.045 ?   0.001       256.022 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        64     latin     1088.067 ?   0.002       416.030 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10         8     latin      464.044 ?   0.001       264.029 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        32     latin     1184.085 ?   0.003       504.044 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        64     latin     2144.123 ?   0.005       824.065 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm        100         8     latin     3872.367 ?   8.002      2024.269 ?   8.016      B/op
> stringJoiner:?gc.alloc.rate.norm        100        32     latin    11048.803 ?   7.988      4416.393 ?   0.004      B/op
> stringJoiner:?gc.alloc.rate.norm        100        64     latin    20657.194 ?   9.775      7640.642 ?   9.819      B/op
> stringJoiner:?gc.alloc.rate.norm          5         8  cyrillic      360.029 ?   0.001       184.020 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        32  cyrillic      960.060 ?   0.002       424.032 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        64  cyrillic     1760.088 ?   0.003       744.043 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10         8  cyrillic      664.063 ?   0.001       352.038 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        32  cyrillic     1864.128 ?   0.003       832.067 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        64  cyrillic     3464.206 ?   0.007      1472.094 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm        100         8  cyrillic     5704.541 ?   0.006      2928.317 ?   8.002      B/op
> stringJoiner:?gc.alloc.rate.norm        100        32  cyrillic    17705.090 ?   0.045      7720.658 ?   0.007      B/op
> stringJoiner:?gc.alloc.rate.norm        100        64  cyrillic    33689.855 ?   9.786     14121.042 ?   0.015      B/op
> stringJoiner:?gc.alloc.rate.norm          5         8     mixed      360.028 ?   0.001       184.016 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        32     mixed      960.059 ?   0.002       424.031 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        64     mixed     1760.088 ?   0.003       744.041 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10         8     mixed      664.052 ?   0.001       352.035 ?   0.002      B/op
> stringJoiner:?gc.alloc.rate.norm         10        32     mixed     1864.116 ?   0.005       832.064 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        64     mixed     3464.196 ?   0.006      1472.088 ?   0.002      B/op
> stringJoiner:?gc.alloc.rate.norm        100         8     mixed     5672.448 ?   8.002      2920.314 ?   0.006      B/op
> stringJoiner:?gc.alloc.rate.norm        100        32     mixed    17681.092 ?   9.824      7728.653 ?   8.008      B/op
> stringJoiner:?gc.alloc.rate.norm        100        64     mixed    33697.818 ?   8.011     14120.977 ?   0.034      B/op

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

 - 8148937: (str) Use StringBuilder as cl4es suggests
 - 8148937: (str) Check also delimiter, prefix and suffix
 - 8148937: (str) Adapt StringJoiner for Compact Strings

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

Changes: https://git.openjdk.java.net/jdk/pull/2627/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2627&range=01
  Stats: 135 lines in 2 files changed: 114 ins; 10 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2627.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2627/head:pull/2627

PR: https://git.openjdk.java.net/jdk/pull/2627

From dfuchs at openjdk.java.net  Mon Mar 15 18:04:27 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 15 Mar 2021 18:04:27 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v6]
In-Reply-To: <12UOgMQ-mVVH7usEXj3a-GAW56QmG54t6chEIVQTJRI=.e7821199-ea42-4c0a-b1f8-27453fc8d02e@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <12UOgMQ-mVVH7usEXj3a-GAW56QmG54t6chEIVQTJRI=.e7821199-ea42-4c0a-b1f8-27453fc8d02e@github.com>
Message-ID: <PD2i1PmLCggQzIlT8L_3Frc84BO-rR02_EAMZlPzOeU=.78f43282-f265-4c09-8eb1-7b009f7ca710@github.com>

On Mon, 15 Mar 2021 18:01:20 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
>> 
>> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert HttpClient

LGTM. Thanks!

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2992

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 18:04:26 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 18:04:26 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v6]
In-Reply-To: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
Message-ID: <12UOgMQ-mVVH7usEXj3a-GAW56QmG54t6chEIVQTJRI=.e7821199-ea42-4c0a-b1f8-27453fc8d02e@github.com>

> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
> 
> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

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

  Revert HttpClient

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2992/files
  - new: https://git.openjdk.java.net/jdk/pull/2992/files/ff25cc4d..af4fcce4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2992&range=04-05

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From akozlov at openjdk.java.net  Mon Mar 15 18:23:35 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Mar 2021 18:23:35 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v28]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <hz2vrgXQiBRvuTHp7eiZpkHoAcoMYXlEk-X-hfoJsYo=.a43951e9-c93b-4659-b2b1-ecfdedffad20@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 114 commits:

 - JDK-8262491: bsd_aarch64 part
 - JDK-8263002: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Wider #ifdef block
 - Fix most of issues in java/foreign/ tests
   
   Failures related to va_args are tracked in JDK-8263512.
 - Add Azul copyright
 - Update Oracle copyright years
 - Use Thread::current_or_null_safe in SafeFetch
 - 8262903: [macos_aarch64] Thread::current() called on detached thread
 - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
 - ... and 104 more: https://git.openjdk.java.net/jdk/compare/d825198e...806fc618

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

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=27
  Stats: 2949 lines in 75 files changed: 2839 ins; 27 del; 83 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From mchung at openjdk.java.net  Mon Mar 15 18:30:20 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 15 Mar 2021 18:30:20 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups [v5]
In-Reply-To: <1RcjLNIE3UTsIOYOo2nxNcKG4_GNta2vLAbIXlrhXAc=.d8e39c90-8923-406f-9143-8b66c0361b81@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
 <1RcjLNIE3UTsIOYOo2nxNcKG4_GNta2vLAbIXlrhXAc=.d8e39c90-8923-406f-9143-8b66c0361b81@github.com>
Message-ID: <fI5otZLn-AT6frAJO6TRSRVhmJJmIDMn0eiQJxGzj78=.635016a6-7550-442e-b077-ceae03b8e7b1@github.com>

On Wed, 10 Mar 2021 16:34:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - Remove unused code
>> - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc)
>> - Apply pattern matching to make some code more readable
>
> Claes Redestad has updated the pull request with a new target base 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:
> 
>  - Revert pattern matching changes covered by #2913
>  - Merge branch 'master' into invoke_cleanup
>  - Missing .values
>  - More cleanup, reduce allocations in InvokerBytecodeGenerator
>  - Missing outstanding changes
>  - Avoid unnecessary reboxing checks, inline and simplify class/mt invokes
>  - j.l.invoke cleanups

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 342:

> 340:         setClassWriter(cw);
> 341:         cw.visit(Opcodes.V1_8, NOT_ACC_PUBLIC + Opcodes.ACC_FINAL + Opcodes.ACC_SUPER,
> 342:                 CLASS_PREFIX.concat(className), null, INVOKER_SUPER_NAME, null);

I prefer to use the existing common pattern using `+` as I believe this gain is in the noise.

src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 151:

> 149:                     maybeReBoxElements(argv);
> 150:                     if (argv.length > 6) {
> 151:                         result = invokeWithManyArguments(bootstrapMethod, caller, name, type, argv);

it'd be cleaner to move this to the default case in line 162 and 174 instead of having this special if-block.

src/java.base/share/classes/java/lang/invoke/MethodType.java line 418:

> 416: 
> 417:     /**
> 418:      * Finds or creates a method type with additional parameter types.

`nptype` is never void but  what  about the check if `nptype` is not null?

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

PR: https://git.openjdk.java.net/jdk/pull/2300

From github.com+194713+candrews at openjdk.java.net  Mon Mar 15 18:38:12 2021
From: github.com+194713+candrews at openjdk.java.net (Craig Andrews)
Date: Mon, 15 Mar 2021 18:38:12 GMT
Subject: Integrated: JDK-8262277: URLClassLoader.getResource throws
 undocumented IllegalArgumentException
In-Reply-To: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
References: <vK93nvV1dBEJM4pu-G_syrc9sXu0jCVGL_nPpenDoKg=.82d0f9e8-a468-4f4b-a67e-bc9229fc0e60@github.com>
Message-ID: <pxuuzcDgk7EbWbw4vvG26BhgHWwhJDrXAMxDReQ4r9U=.c878f947-bd12-4de9-9f4b-ed65acf74cac@github.com>

On Sat, 20 Feb 2021 19:20:48 GMT, Craig Andrews <github.com+194713+candrews at openjdk.org> wrote:

> `java.net.URLClassLoader.getResource` can throw an undocumented `IllegalArgumentException`.
> 
> According to the javadoc for the `getResource` and `findResource` methods, neither should be throwing `IllegalArgumentException` - they should return null if the resource can't be resolved.
> 
> Quoting the javadoc for [`URLClassLoader.html#findResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/net/URLClassLoader.html#findResource(java.lang.String))
>> Returns:
>>     a URL for the resource, or null if the resource could not be found, or if the loader is closed.
> 
> And quoting the javadoc for [`ClassLoader.html#getResource`](https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/lang/ClassLoader.html#getResource(java.lang.String))
>> Returns:
>>     URL object for reading the resource; null if the resource could not be found, a URL could not be constructed to locate the resource, the resource is in a package that is not opened unconditionally, or access to the resource is denied by the security manager.
> 
> Neither mentions throwing `IllegalArgumentException` and both are clear that when URL can't be constructed, `null` should be returned.
> 
> Here's a stack trace:
> java.lang.IllegalArgumentException: name
>         at java.base/jdk.internal.loader.URLClassPath$Loader.findResource(URLClassPath.java:600)
>         at java.base/jdk.internal.loader.URLClassPath.findResource(URLClassPath.java:291)
>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:655)
>         at java.base/java.net.URLClassLoader$2.run(URLClassLoader.java:653)
>         at java.base/java.security.AccessController.doPrivileged(Native Method)
>         at java.base/java.net.URLClassLoader.findResource(URLClassLoader.java:652)
> 
> Looking at [`URLClassPath.findResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L603)
>         URL findResource(final String name, boolean check) {
>             URL url;
>             try {
>                 url = new URL(base, ParseUtil.encodePath(name, false));
>             } catch (MalformedURLException e) {
>                 throw new IllegalArgumentException("name");
>             }
> 
> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.
> 
> A similar issue exists at [`URLClassPath.getResource`](https://github.com/openjdk/jdk/blob/2b00367e1154feb2c05b84a11d62fb5750e46acf/src/java.base/share/classes/jdk/internal/loader/URLClassPath.java#L639)
>         URL findResource(final String name, boolean check) {
>             URL url;
>             try {
>                 url = new URL(base, ParseUtil.encodePath(name, false));
>             } catch (MalformedURLException e) {
>                 throw new IllegalArgumentException("name");
>             }
> 
> Instead of throwing `IllegalArgumentException`, that line should simply return `null`.

This pull request has now been integrated.

Changeset: 0c718ab2
Author:    Craig Andrews <candrews at integralblue.com>
Committer: Brent Christian <bchristi at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0c718ab2
Stats:     60 lines in 2 files changed: 57 ins; 0 del; 3 mod

8262277: URLClassLoader.getResource throws undocumented IllegalArgumentException

Reviewed-by: alanb, bchristi, psadhukhan

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

PR: https://git.openjdk.java.net/jdk/pull/2662

From roger.riggs at oracle.com  Mon Mar 15 18:49:50 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 15 Mar 2021 14:49:50 -0400
Subject: Comment on CSR 8251991: Hex formatting and parsing utility
In-Reply-To: <3f09d0bd-cb53-fa66-1450-d949a9ebfe5d@gmail.com>
References: <994ead35-6c49-8ceb-da9c-916f163feac3@gmail.com>
 <3f09d0bd-cb53-fa66-1450-d949a9ebfe5d@gmail.com>
Message-ID: <6f3f1de2-2740-1a92-8490-6a8d5dda3510@oracle.com>

Hi,

The question about static vs instance methods was raised during the review.
At the time, my rationale for the current API is summarized in this email.
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.html

It comes down to choosing one kind of consistency vs another.

I was/am looking for additional comments to weigh one or the other 
alternative.
I did receive one offline comment in support of static methods on the 
rationale of
convenience.

Regards, Roger


On 3/15/21 12:06 PM, Raffaello Giulietti wrote:
> Hi,
>
> the javadoc of most of the methods listed in my previous post below 
> reads:
> ??? "The delimiter, prefix, suffix, and uppercase parameters are not 
> used."
>
> As these eventually constitute the whole state of an instance of this 
> final class and as the state is not involved, it is possible to 
> declare the methods as static.
>
>
> If, for some reason, declaring the methods as static is not a choice, 
> the next best thing is to clarify that
> * HexFormat.of() always returns the same instance and thus
> * absent any other instance, the recommended idiom for invoking any of 
> the methods below is, for example,
> ??? HexFormat.of().isHexDigit('F')
> (because there are almost no additional costs wrt static methods.)
Note that HexFormat is specified as a value based class and
any statement related to identity is out of place.

Incidentally, its generally discouraged and can cause a warning when a 
static method is invoked using a reference.

>
> But I don't see a reason why they should be non-static. Just oversight?
>
>
> Greetings
> Raffaello
>
>
> On 2021-03-08 11:52, Raffaello Giulietti wrote:
>> Hello,
>>
>> it appears that all of the following API methods in [1] can be 
>> declared *static*, which makes them more useful in contexts where 
>> there's no instance of HexFormat available or none is desired.
>>
>> As 17 has not yet entered any formal phase, the change should be 
>> harmless.
>>
>> ?? public boolean isHexDigit(int);
>> ?? public int fromHexDigit(int);
>> ?? public int fromHexDigits(java.lang.CharSequence);
>> ?? public int fromHexDigits(java.lang.CharSequence, int, int);
>> ?? public long fromHexDigitsToLong(java.lang.CharSequence);
>> ?? public long fromHexDigitsToLong(java.lang.CharSequence, int, int);
>>
>> Greetings
>> Raffaello
>>
>> ----
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8251991


From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 18:51:11 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 18:51:11 GMT
Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings
In-Reply-To: <DUKI1X0giFYCkYBQtHjhcVHIQGfzXw2x0tePTp6MOv4=.30a93b32-0f26-42a8-a48c-e1734932a6cf@github.com>
References: <V3-_ghd9MJZQxCWSiSwpVXHs-u4DaQo_g3mSjH9wOX0=.08042cfb-bce0-4885-8f58-049450952b1e@github.com>
 <RBydfhue4iiVq9uTQcMPxkYWaJZZAUfQfZa497lKhQ4=.32eb0e60-0961-494b-87e4-01e048e2fcc3@github.com>
 <MsyGNERwG_diNSKYaPDUvJbS28dFAHy10UfXtGl_EYA=.c0b3b510-e0c2-43b5-a0e0-0e69570c69b5@github.com>
 <CCqD6Fp8scZ1ra0RLefsKVKNkgInqy09gm-nb4URAGY=.5da92578-7f4a-40aa-bfb3-cbdc126ccbcb@github.com>
 <vl8lNoVuXYbiwxECvX4BFVlR_LZlwWLPmpNh1sZ_aLw=.948e1e18-6ed2-4fef-afe4-8cc9a064d31c@github.com>
 <DUKI1X0giFYCkYBQtHjhcVHIQGfzXw2x0tePTp6MOv4=.30a93b32-0f26-42a8-a48c-e1734932a6cf@github.com>
Message-ID: <rKnrd8fnPatVleV-OiK1H3iR5wBwKvvRaEX17hj0TIM=.f2979caf-63cc-4326-9371-f43a32d0e815@github.com>

On Mon, 15 Mar 2021 14:07:29 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I was thinking about `StringBuilder` at the very beginning but then decided to have no bounds checks and reallocations. Indeed from maintainability point of view your solution is much more attractive. I have one minor comment about `append()`: I think we should do more chaining, e.g. 
>> StringBuilder sb = new StringBuilder(len);
>> sb.append(elts[0]);
>> should be
>> StringBuilder sb = new StringBuilder(len).append(elts[0]);
>> etc. to have less bytecode.
>> 
>> E.g. if we take 
>> public String sb() {
>>   StringBuilder sb = new StringBuilder();
>>   
>>   sb.append("a");
>>   sb.append("b");
>>   
>>   return sb.toString();
>> }
>> `sb.append()` gets compiled into
>> L1
>>  LINENUMBER 23 L1
>>  ALOAD 1
>>  LDC "a"
>>  INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>>  POP
>> L2
>>  LINENUMBER 24 L2
>>  ALOAD 1
>>  LDC "b"
>>  INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>>  POP
>>  ```
>>  and in case we have
>>  ```
>>  sb.append("a").append("b");
>>  ```
>>  the amount of byte code is reduced:
>>  ```
>>  L1
>>  LINENUMBER 23 L1
>>  ALOAD 1
>>  LDC "a"
>>  INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>>  LDC "b"
>>  INVOKEVIRTUAL java/lang/StringBuilder.append (Ljava/lang/String;)Ljava/lang/StringBuilder;
>>  POP
>>  ```
>>  
>>  Also I'd change
>> if (addLen == 0) {
>>     compactElts();
>>     return size == 0 ? "" : elts[0];
>> }
>> to
>> if (size == 0) {
>>     if (addLen == 0) {
>>         return "";
>>     }
>>     return prefix + suffix;
>> }
>> The second variant is more understandable to me and likely to be slightly faster.
>> 
>> And finally, should I close this PR and you'll create a new one from your branch, or I need to copy your changes here?
>
> Up to you. If you adapt your PR to use a StringBuilder as suggested I can review and sponsor.

I'll reuse existing PR then.

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

PR: https://git.openjdk.java.net/jdk/pull/2627

From jboes at openjdk.java.net  Mon Mar 15 18:52:17 2021
From: jboes at openjdk.java.net (Julia Boes)
Date: Mon, 15 Mar 2021 18:52:17 GMT
Subject: RFR: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy
In-Reply-To: <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
 <5s4i5725zJd8QrefwYyc8sn2fQXad3hAGLVflkFttmY=.abe55236-e258-482b-b8be-be75e1eb086c@github.com>
 <klPrlAvPsVYcAtWjox3cWGgbEIjbHXoaFtYu7iBPCxc=.22a22c0a-7d04-4abf-b9ff-0e2a423a6b18@github.com>
Message-ID: <4Bae_Uh8Zakn4cnmbXkUcV9xRTus1hgHCEPVthHuEyc=.fb959963-ff7a-4067-b888-e178d9f70e91@github.com>

On Thu, 18 Feb 2021 07:12:34 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> Hi @turbanoff, I'm happy to sponsor but I see two comments by @marschall - have they been addressed?
>> https://github.com/openjdk/jdk/pull/1853#discussion_r572815422
>> https://github.com/openjdk/jdk/pull/1853#discussion_r572380746
>
> @FrauBoes fixed in the last commit. Is there any way to de-_integrate_ PR (to include last commit)?

@turbanoff  Tier 1-3 still all clear. If you /integrate, I will sponsor this tomorrow.

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

PR: https://git.openjdk.java.net/jdk/pull/1853

From igraves at openjdk.java.net  Mon Mar 15 18:53:26 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 15 Mar 2021 18:53:26 GMT
Subject: RFR: JDK-8263545: Convert jpackage to use Stream.toList() [v2]
In-Reply-To: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
References: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
Message-ID: <6Q7RKg86uh-Tg0GRsMF0gUK9IQVsw3spvLyPb9p0jQo=.33d10404-894a-46b7-9e83-3eb235bde456@github.com>

> This converts jpackage to use `Stream.toList()` instead of `Stream.collect(Collectors.toList())`. One piece of code was modified to not mutate a list in addition to one test that used a mutating sort on a list. The rest of the changes are simple substitutions.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Clarifying type argument and shorting a toArray invocation

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2997/files
  - new: https://git.openjdk.java.net/jdk/pull/2997/files/1bb46b54..ce11489b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2997&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2997&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2997

From igraves at openjdk.java.net  Mon Mar 15 18:53:27 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Mon, 15 Mar 2021 18:53:27 GMT
Subject: RFR: JDK-8263545: Convert jpackage to use Stream.toList() [v2]
In-Reply-To: <UxJmdCQmgxgcn-eGei7EABKV--91CTwpfybIGhwKZOs=.bd461f87-487f-44fc-b05e-4df03f87f1a4@github.com>
References: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
 <UxJmdCQmgxgcn-eGei7EABKV--91CTwpfybIGhwKZOs=.bd461f87-487f-44fc-b05e-4df03f87f1a4@github.com>
Message-ID: <m-qV8KSTuUtpCNbeQv9mTcu9tgZarYlq69lmNqloDjQ=.72562d1b-d1db-4840-8e95-fc1820e0afd2@github.com>

On Mon, 15 Mar 2021 17:29:46 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarifying type argument and shorting a toArray invocation
>
> src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java line 200:
> 
>> 198:         ).map(e -> {
>> 199:             e.getValue().setOutputFileName(e.getKey());
>> 200:             return (WixFragmentBuilder) e.getValue();
> 
> Why this explicit cast is needed here?

The explicit cast is needed because `Stream.toList()` is invariant, but the stream is producing a covariant type (by way of the type inferencer and `Stream.of(..)` accepting two subclasses of `WixFragmentBuilder`). We need to introduce a hint to bring the type back to the invariant form. On second thought I'm going to make this explicit type argument instead so it's clear that the casting isn't part to what the code is otherwise doing.

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

PR: https://git.openjdk.java.net/jdk/pull/2997

From akozlov at openjdk.java.net  Mon Mar 15 18:56:18 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Mar 2021 18:56:18 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v12]
In-Reply-To: <3NYUmXmjyZFhGJwrHfEjSRX1VRaPjt5cCp9HRBxODbM=.4880b6d1-f6dd-45db-95f4-9064e9204d87@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <Vg27jHtpjAQ36mYoE5MyolUJUi8K9lSb_c3grH_DLvM=.df18633b-2124-44b0-ac51-e5405a3f745d@github.com>
 <8MnBLkES1lapB4b01NDzU9nhOk8_9_V--NSCM5H_bg8=.7bdb576b-4acd-4e5b-be14-b363a2ef47bf@github.com>
 <Dze4ZtrPI_OLkuExMIN1fl5u6eCryLmgNRgAHzN2kXE=.eee71cb4-1c81-46f8-b6ae-063659a28fc2@github.com>
 <3NYUmXmjyZFhGJwrHfEjSRX1VRaPjt5cCp9HRBxODbM=.4880b6d1-f6dd-45db-95f4-9064e9204d87@github.com>
Message-ID: <v4LN5mBL_UaL1YxXlwj4CLuvo9lQU5yHY_3e5MQQ1g8=.0783fcae-d399-4a76-94e7-73ef68133941@github.com>

On Thu, 11 Mar 2021 20:27:51 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> The thread_bsd_aarch64.hpp describes a part of JavaThread, while this block belongs to Thread for now. Since W^X is an attribute of any operating system thread, I assumed Thread to be the right place for W^X bookkeeping. 
>> 
>> In most cases, we manage W^X state of JavaThread. But sometimes a GC thread needs the WXWrite state, or safefetch is called from non-JavaThread. Probably this can be dealt with (e.g. GCThread to always have the WXWrite state). But such change would be much more than a simple refactoring and it would require a significant amount of testing. Ideally, I would like to investigate this as a follow-up change, or at least after other fixes to this PR.
>
> Good point about Thread vs JavaThread. Yes, this can be looked into as follow-up cleanups.

The enhancement is tracked in https://bugs.openjdk.java.net/browse/JDK-8263492

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Mon Mar 15 18:56:17 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Mar 2021 18:56:17 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v21]
In-Reply-To: <SXXcMmMTXbltmXqeaDgF6g8EJvECwqtlNokXpNJ0CNI=.f358e952-3186-4503-a632-834ec4343c6d@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <ZfRwLBDhh3K6u3NaWzLWVyoYqBuZVJbipXCZKzPclBs=.bedc9c24-2178-400a-8868-fbbb61b298cc@github.com>
 <yMUjWudRugP8LTAT5fuc25Q7R1M9iTCBFMFvXGjRWlQ=.2a6cf189-5bb6-4f41-9e49-d859b85534b6@github.com>
 <v33sSQcIVsvidIkYzaOsIhkjNhojCVastBXuUJJ67IM=.9123e430-657f-4c24-a201-4f457232c983@github.com>
 <SXXcMmMTXbltmXqeaDgF6g8EJvECwqtlNokXpNJ0CNI=.f358e952-3186-4503-a632-834ec4343c6d@github.com>
Message-ID: <4EryfweVy9Q97cbm7rAcsSIXuK2XImbIfuPeloJuXEA=.90a1f396-299c-43d2-922b-9af36ca43467@github.com>

On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?
>
> Robustness, clarity, maintainability, convention. Why not?

I've tried to implement the suggestion, but it pulled more unnecessary changes. It makes the intended way to check the condition less clear (`#ifdef` and not `#if`). The rest of the defines in this file follows the pattern: a define without a value to be checked with `#ifdef` and define with a value to be checked with `#if`. To be consistent, I would need to add `#define R18_RESERVED false` to the `#else` clause and change every `#ifdef R18_RESERVED`/`#ifndef R18_RESERVED` to `#if R18_RESERVED`/`#if !R18_RESERVED`. I think we'll win in clarity in the long term if I will not implement the suggestion without related changes. (And related changes would introduce additional noise, which we are fighting with).

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Mon Mar 15 18:56:23 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 15 Mar 2021 18:56:23 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v28]
In-Reply-To: <FB2pev3OL8y-AYtFw1i8n3Np5ny9bYb8wdduqVtiXhA=.84f450cc-6891-4a0b-a84d-1abb8a2eaf00@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <TRklBppvcFXK3TUe1dkT2FCn2b9m57pRFAGHR-Vt-8U=.13d4dcc9-deb4-4227-95ec-d9c7a8fc279d@github.com>
 <FB2pev3OL8y-AYtFw1i8n3Np5ny9bYb8wdduqVtiXhA=.84f450cc-6891-4a0b-a84d-1abb8a2eaf00@github.com>
Message-ID: <0dFnMCcGeahDTezdMqNQ2ZtipjeEaCpNezow6Kqy5xE=.ec72c0d8-8252-4abf-ab7a-8ce4b89ca527@github.com>

On Sat, 13 Mar 2021 05:49:53 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 114 commits:
>> 
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
>>  - ... and 104 more: https://git.openjdk.java.net/jdk/compare/d825198e...806fc618
>
> src/hotspot/share/runtime/safefetch.inline.hpp line 35:
> 
>> 33: inline int SafeFetch32(int* adr, int errValue) {
>> 34:   assert(StubRoutines::SafeFetch32_stub(), "stub not yet generated");
>> 35:   Thread* thread = Thread::current_or_null_safe();
> 
> Sorry but this should be MACOS_AARCH64 only. All three lines need to be ifdef'd if you are going to include the assertion.
> 
> Thanks,
> David

Right, thanks! Fixed in https://github.com/openjdk/jdk/pull/2200/commits/3d0f4d2342adc867eaf762fa83a9c3035d6439bd

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

PR: https://git.openjdk.java.net/jdk/pull/2200

From asemenyuk at openjdk.java.net  Mon Mar 15 19:28:11 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 15 Mar 2021 19:28:11 GMT
Subject: RFR: JDK-8263545: Convert jpackage to use Stream.toList() [v2]
In-Reply-To: <6Q7RKg86uh-Tg0GRsMF0gUK9IQVsw3spvLyPb9p0jQo=.33d10404-894a-46b7-9e83-3eb235bde456@github.com>
References: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
 <6Q7RKg86uh-Tg0GRsMF0gUK9IQVsw3spvLyPb9p0jQo=.33d10404-894a-46b7-9e83-3eb235bde456@github.com>
Message-ID: <Xiy5Mp_Adi_DLPhSAhyqfyfXYzzRM3rLnxpYNYlGO_E=.71b343b6-2da8-4952-a4bf-9e29f083c4b3@github.com>

On Mon, 15 Mar 2021 18:53:26 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This converts jpackage to use `Stream.toList()` instead of `Stream.collect(Collectors.toList())`. One piece of code was modified to not mutate a list in addition to one test that used a mutating sort on a list. The rest of the changes are simple substitutions.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarifying type argument and shorting a toArray invocation

Marked as reviewed by asemenyuk (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2997

From asemenyuk at openjdk.java.net  Mon Mar 15 19:46:19 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 15 Mar 2021 19:46:19 GMT
Subject: RFR: 8263536: Add missing @compile tags to jpackage tests [v2]
In-Reply-To: <_A2MzMPm-ueagZbFm1_ea9c5uKJNKU1pqzmq3SQPCnQ=.0440bf7d-a5b2-4aa9-a35a-18085c70e4f6@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
 <ooB29iVuRdxt3fLeso4Sv-z2Ob6gFpgnUqY2_DWkNs4=.f7939815-271f-4367-9dbc-229ba2076183@github.com>
 <_A2MzMPm-ueagZbFm1_ea9c5uKJNKU1pqzmq3SQPCnQ=.0440bf7d-a5b2-4aa9-a35a-18085c70e4f6@github.com>
Message-ID: <TVizGxORmaXh0pOuFOHRpF-cqYmBDMkw0QBHu0Ii9zo=.59624f2e-af36-4b57-b77a-042b17347119@github.com>

On Sat, 13 Mar 2021 08:38:16 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   8263536: Add missing @compile tags to jpackage tests
>
> Changes requested by iklam (Reviewer).

@kevinrushforth I plan to resolve JDK-8263474 manually as "Delivered". Would this work?

> test/jdk/tools/jpackage/windows/WinDirChooserTest.java line 44:
> 
>> 42:  * @requires (os.family == "windows")
>> 43:  * @modules jdk.jpackage/jdk.jpackage.internal
>> 44:  * @compile WinDirChooserTest.java
> 
> Changes like this one is not necessary. `@run` will build WinDirChooserTest automatically.
> 
> `@compile` should be added only when necessary, like WinInstallerUiTest.java

It is better to have `@compile` everywhere for consistency. 

The proper way to run tests is by passing test class name as an argument for test runner, test class should not have `main()` and should have `@Test` annotation for test methods. Some tests have not been updated to follow this design and adding `@compile` to them doesn't make a difference now. But eventually they will be updated and they will need `@compile` anyways.

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

PR: https://git.openjdk.java.net/jdk/pull/2975

From iklam at openjdk.java.net  Mon Mar 15 19:58:09 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 15 Mar 2021 19:58:09 GMT
Subject: RFR: 8263536: Add missing @compile tags to jpackage tests [v2]
In-Reply-To: <TVizGxORmaXh0pOuFOHRpF-cqYmBDMkw0QBHu0Ii9zo=.59624f2e-af36-4b57-b77a-042b17347119@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
 <ooB29iVuRdxt3fLeso4Sv-z2Ob6gFpgnUqY2_DWkNs4=.f7939815-271f-4367-9dbc-229ba2076183@github.com>
 <_A2MzMPm-ueagZbFm1_ea9c5uKJNKU1pqzmq3SQPCnQ=.0440bf7d-a5b2-4aa9-a35a-18085c70e4f6@github.com>
 <TVizGxORmaXh0pOuFOHRpF-cqYmBDMkw0QBHu0Ii9zo=.59624f2e-af36-4b57-b77a-042b17347119@github.com>
Message-ID: <9V48WPCaQyZKB4Pr42mLfZ9dpByojVUH9gjjF-sicdw=.afa77515-e84d-44eb-84b5-43be04491f73@github.com>

On Mon, 15 Mar 2021 19:41:06 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> test/jdk/tools/jpackage/windows/WinDirChooserTest.java line 44:
>> 
>>> 42:  * @requires (os.family == "windows")
>>> 43:  * @modules jdk.jpackage/jdk.jpackage.internal
>>> 44:  * @compile WinDirChooserTest.java
>> 
>> Changes like this one is not necessary. `@run` will build WinDirChooserTest automatically.
>> 
>> `@compile` should be added only when necessary, like WinInstallerUiTest.java
>
> It is better to have `@compile` everywhere for consistency. 
> 
> The proper way to run tests is by passing test class name as an argument for test runner, test class should not have `main()` and should have `@Test` annotation for test methods. Some tests have not been updated to follow this design and adding `@compile` to them doesn't make a difference now. But eventually they will be updated and they will need `@compile` anyways.

If this is the plan please update the bug description to reflect this. Otherwise it's not clear why this is done. The `@compile` in those files aren't really "missing" since they are not required. I would suggest changing the bug title to "Add @compile tags to jpackage tests"

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

PR: https://git.openjdk.java.net/jdk/pull/2975

From iklam at openjdk.java.net  Mon Mar 15 20:05:08 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 15 Mar 2021 20:05:08 GMT
Subject: RFR: 8263536: Add missing @compile tags to jpackage tests [v2]
In-Reply-To: <9V48WPCaQyZKB4Pr42mLfZ9dpByojVUH9gjjF-sicdw=.afa77515-e84d-44eb-84b5-43be04491f73@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
 <ooB29iVuRdxt3fLeso4Sv-z2Ob6gFpgnUqY2_DWkNs4=.f7939815-271f-4367-9dbc-229ba2076183@github.com>
 <_A2MzMPm-ueagZbFm1_ea9c5uKJNKU1pqzmq3SQPCnQ=.0440bf7d-a5b2-4aa9-a35a-18085c70e4f6@github.com>
 <TVizGxORmaXh0pOuFOHRpF-cqYmBDMkw0QBHu0Ii9zo=.59624f2e-af36-4b57-b77a-042b17347119@github.com>
 <9V48WPCaQyZKB4Pr42mLfZ9dpByojVUH9gjjF-sicdw=.afa77515-e84d-44eb-84b5-43be04491f73@github.com>
Message-ID: <NN2VbTlYGgLa52X1UG9sm0jiVVn2yBjbVSJl3TqvR6k=.627b7859-166d-4fa9-96c3-09d4a68444bf@github.com>

On Mon, 15 Mar 2021 19:55:03 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> It is better to have `@compile` everywhere for consistency. 
>> 
>> The proper way to run tests is by passing test class name as an argument for test runner, test class should not have `main()` and should have `@Test` annotation for test methods. Some tests have not been updated to follow this design and adding `@compile` to them doesn't make a difference now. But eventually they will be updated and they will need `@compile` anyways.
>
> If this is the plan please update the bug description to reflect this. Otherwise it's not clear why this is done. The `@compile` in those files aren't really "missing" since they are not required. I would suggest changing the bug title to "Add @compile tags to jpackage tests"

> adding `@compile` to them doesn't make a difference now

Also, the above is not true. `@compile` will always run javac every time you run the test. I think you should use `@build` instead -- if the class doesn't exist, it will be compiled. If it already exists (you run jtreg a second time), the class won't be compiled again, so it will run a little faster.

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

PR: https://git.openjdk.java.net/jdk/pull/2975

From kcr at openjdk.java.net  Mon Mar 15 20:15:10 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Mon, 15 Mar 2021 20:15:10 GMT
Subject: RFR: 8263536: Add missing @compile tags to jpackage tests [v2]
In-Reply-To: <TVizGxORmaXh0pOuFOHRpF-cqYmBDMkw0QBHu0Ii9zo=.59624f2e-af36-4b57-b77a-042b17347119@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
 <ooB29iVuRdxt3fLeso4Sv-z2Ob6gFpgnUqY2_DWkNs4=.f7939815-271f-4367-9dbc-229ba2076183@github.com>
 <_A2MzMPm-ueagZbFm1_ea9c5uKJNKU1pqzmq3SQPCnQ=.0440bf7d-a5b2-4aa9-a35a-18085c70e4f6@github.com>
 <TVizGxORmaXh0pOuFOHRpF-cqYmBDMkw0QBHu0Ii9zo=.59624f2e-af36-4b57-b77a-042b17347119@github.com>
Message-ID: <85xPz0BDUrACx1dwITPNGe_wxzUbqy45_NnMTe8EIKc=.f5469ba8-91a5-4ebf-aaa4-d8e3acb5e61b@github.com>

On Mon, 15 Mar 2021 19:43:12 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Changes requested by iklam (Reviewer).
>
> @kevinrushforth I plan to resolve JDK-8263474 manually as "Delivered". Would this work?

Yes, that should work.

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

PR: https://git.openjdk.java.net/jdk/pull/2975

From raffaello.giulietti at gmail.com  Mon Mar 15 20:26:42 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Mon, 15 Mar 2021 21:26:42 +0100
Subject: Comment on CSR 8251991: Hex formatting and parsing utility
Message-ID: <cff8a2aa-df5e-278f-1f5f-00a60c4a7298@gmail.com>

Hello,

I understand your points expressed in 
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.html

On the other hand, it kind of hurts when the javadoc spec implies that 
the fromXXX() methods do not logically depend on the state and yet one 
has to invoke them on some instance anyway.


As for HexFormat.of() to always return the same instance, you are of 
course right in observing that this is out of place for value-based 
classes. The intent was to describe a static-like idiom that would deter 
programmers to rewrite their own static version of these methods.


Greetings
Raffaello


> Hi,
> 
> The question about static vs instance methods was raised during the review.
> At the time, my rationale for the current API is summarized in this email.
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.html
> 
> It comes down to choosing one kind of consistency vs another.
> 
> I was/am looking for additional comments to weigh one or the other 
> alternative.
> I did receive one offline comment in support of static methods on the 
> rationale of
> convenience.
> 
> Regards, Roger
> 
> 
> On 3/15/21 12:06 PM, Raffaello Giulietti wrote:
>> Hi,
>>
>> the javadoc of most of the methods listed in my previous post below 
>> reads:
>>     "The delimiter, prefix, suffix, and uppercase parameters are not 
>> used."
>>
>> As these eventually constitute the whole state of an instance of this 
>> final class and as the state is not involved, it is possible to 
>> declare the methods as static.
>>
>>
>> If, for some reason, declaring the methods as static is not a choice, 
>> the next best thing is to clarify that
>> * HexFormat.of() always returns the same instance and thus
>> * absent any other instance, the recommended idiom for invoking any of 
>> the methods below is, for example,
>>     HexFormat.of().isHexDigit('F')
>> (because there are almost no additional costs wrt static methods.)
> Note that HexFormat is specified as a value based class and
> any statement related to identity is out of place.
> 
> Incidentally, its generally discouraged and can cause a warning when a 
> static method is invoked using a reference.
> 
>>
>> But I don't see a reason why they should be non-static. Just oversight?
>>
>>
>> Greetings
>> Raffaello
>>
>>
>> On 2021-03-08 11:52, Raffaello Giulietti wrote:
>>> Hello,
>>>
>>> it appears that all of the following API methods in [1] can be 
>>> declared *static*, which makes them more useful in contexts where 
>>> there's no instance of HexFormat available or none is desired.
>>>
>>> As 17 has not yet entered any formal phase, the change should be 
>>> harmless.
>>>
>>>    public boolean isHexDigit(int);
>>>    public int fromHexDigit(int);
>>>    public int fromHexDigits(java.lang.CharSequence);
>>>    public int fromHexDigits(java.lang.CharSequence, int, int);
>>>    public long fromHexDigitsToLong(java.lang.CharSequence);
>>>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);
>>>
>>> Greetings
>>> Raffaello
>>>
>>> ----
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8251991

From mchung at openjdk.java.net  Mon Mar 15 20:35:11 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 15 Mar 2021 20:35:11 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
Message-ID: <TN65WlBSjZCdhFCnzxsZNwV59kU7h84XS2sMtGTXf0o=.3edeb04b-26dd-4513-b0f9-f8be2934baca@github.com>

On Mon, 15 Mar 2021 09:21:22 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263358: Refactored missed equals method

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From psandoz at openjdk.java.net  Mon Mar 15 20:48:12 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 15 Mar 2021 20:48:12 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <56ArMzotFOIbGr5mG6B-2PuwSh7I2gTbdcduv1GimdY=.108e2245-2423-4888-8409-262ec17481c5@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <8dxwtqYBhApNqL8YPdxd7DD2vSCh4l7Uty-yC5GQL1k=.c46a32df-87db-4bdb-a741-3a576061fbb8@github.com>
 <eQMIbyH4Iuhv5awo3y8hrVFFIQ3mle3fT5yc3uq9vSE=.3fc66dcc-79e8-4a55-9e0f-cca6242ecad1@github.com>
 <56ArMzotFOIbGr5mG6B-2PuwSh7I2gTbdcduv1GimdY=.108e2245-2423-4888-8409-262ec17481c5@github.com>
Message-ID: <mjjAAlWx7OAPh-tkaRdXqBzlVqmEvtR9dWEZ1JS11O8=.fab27b0a-81bd-4ea6-9e17-3a9fb50bf250@github.com>

On Fri, 26 Feb 2021 13:15:28 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Looking for some final code reviews.
>
> I still don't like the fact that the factory uses reflection but i don't see how to do better

This is now looking very nicely structured.

The only thing i am unsure are the details around `RandomGenerator` being a service provider interface. The documentation mentions this at various points (mostly as implementation notes), but it's not really called out on `RandomGenerator`. 

Trying out the patch, I can implement `RandomGenerator` and register it as a service:

public class AlwaysZero implements RandomGenerator {
    @Override
    public long nextLong() {
        return 0;
    }
}
...
        RandomGenerator alwaysZero = RandomGenerator.of("AlwaysZero");
 

Is that intended? (esp. since the annotation `RandomGeneratorProperties` is not public). If i rename the above to `L32X64MixRandom` an `ExceptionInInitializerError` is produced due to duplicate keys.

I suspect you want to filter out the service providers to those that only declare `RandomGeneratorProperties`, thereby restricting to providers only supplied by the platform.

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From redestad at openjdk.java.net  Mon Mar 15 20:58:10 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 15 Mar 2021 20:58:10 GMT
Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings [v2]
In-Reply-To: <RuwRUTqLndnJduD4RdMhxYq006a0GsITIZB3crliZYU=.645d9f89-d189-4695-b003-a031af309765@github.com>
References: <V3-_ghd9MJZQxCWSiSwpVXHs-u4DaQo_g3mSjH9wOX0=.08042cfb-bce0-4885-8f58-049450952b1e@github.com>
 <RuwRUTqLndnJduD4RdMhxYq006a0GsITIZB3crliZYU=.645d9f89-d189-4695-b003-a031af309765@github.com>
Message-ID: <FWwZceMHPTBjuRX5BqJX9gEpLduWcMkZL-4T2cSEeb0=.4390ce57-a9ce-4592-b263-12982dd9d4bb@github.com>

On Mon, 15 Mar 2021 18:00:27 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Hello,
>> 
>> as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings.
>> 
>> This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols.
>> 
>> As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called:
>> String delimiter = this.delimiter;
>> char[] chars = new char[this.len + addLen];
>> int k = getChars(this.prefix, chars, 0);
>> if (size > 0) {
>>     k += getChars(elts[0], chars, k);        // inflate byte[]
>> 
>>     for(int i = 1; i < size; ++i) {
>>         k += getChars(delimiter, chars, k);
>>         k += getChars(elts[i], chars, k);
>>     }
>> }
>> 
>> k += getChars(this.suffix, chars, k);
>> return new String(chars);                    // compress char[] -> byte[]
>> This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082)
>> covering both cases when resulting String is Latin1 or UTF-16
>> 
>> I've prepared a patch along with benchmark proving that this change is correct and brings improvement.
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>> public class StringJoinerBenchmark {
>> 
>>   @Benchmark
>>   public String stringJoiner(Data data) {
>>     String[] stringArray = data.stringArray;
>>     return Joiner.joinWithStringJoiner(stringArray);
>>   }
>> 
>>   @State(Scope.Thread)
>>   public static class Data {
>> 
>>     @Param({"latin", "cyrillic", "mixed"})
>>     private String mode;
>> 
>>     @Param({"8", "32", "64"})
>>     private int length;
>> 
>>     @Param({"5", "10", "100"})
>>     private int count;
>> 
>>     private String[] stringArray;
>> 
>>     @Setup
>>     public void setup() {
>>       RandomStringGenerator generator = new RandomStringGenerator();
>> 
>>       stringArray = new String[count];
>> 
>>       for (int i = 0; i < count; i++) {
>>         String alphabet = getAlphabet(i, mode);
>>         stringArray[i] = generator.randomString(alphabet, length);
>>       }
>>     }
>> 
>>     private static String getAlphabet(int index, String mode) {
>>       var latin = "abcdefghijklmnopqrstuvwxyz"; //English
>>       var cyrillic = "????????????????????????????????"; // Russian
>> 
>>       String alphabet;
>>       switch (mode) {
>>         case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin;
>>         case "latin" -> alphabet = latin;
>>         case "cyrillic" -> alphabet = cyrillic;
>>         default -> throw new RuntimeException("Illegal mode " + mode);
>>       }
>>       return alphabet;
>>     }
>>   }
>> }
>> 
>> public class Joiner {
>> 
>>   public static String joinWithStringJoiner(String[] stringArray) {
>>     StringJoiner joiner = new StringJoiner(",", "[", "]");
>>     for (String str : stringArray) {
>>       joiner.add(str);
>>     }
>>     return joiner.toString();
>>   }
>> }
>> 
>> 
>>                                     (count)  (length)    (mode)                Java 14                 patched     Units
>> stringJoiner                              5         8     latin       78.836 ?   0.208        67.546 ?   0.500     ns/op
>> stringJoiner                              5        32     latin       92.877 ?   0.422        66.760 ?   0.498     ns/op
>> stringJoiner                              5        64     latin      115.423 ?   0.883        73.224 ?   0.289     ns/op
>> stringJoiner                             10         8     latin      152.587 ?   0.429       161.427 ?   0.635     ns/op
>> stringJoiner                             10        32     latin      189.998 ?   0.478       164.099 ?   0.963     ns/op
>> stringJoiner                             10        64     latin      238.679 ?   1.419       176.825 ?   0.533     ns/op
>> stringJoiner                            100         8     latin     1215.612 ?  17.413      1541.802 ? 126.166     ns/op
>> stringJoiner                            100        32     latin     1699.998 ?  28.407      1563.341 ?   4.439     ns/op
>> stringJoiner                            100        64     latin     2289.388 ?  45.319      2215.931 ? 137.583     ns/op
>> stringJoiner                              5         8  cyrillic       96.692 ?   0.947        80.946 ?   0.371     ns/op
>> stringJoiner                              5        32  cyrillic      107.806 ?   0.429        84.717 ?   0.541     ns/op
>> stringJoiner                              5        64  cyrillic      150.762 ?   2.267        96.214 ?   1.251     ns/op
>> stringJoiner                             10         8  cyrillic      190.570 ?   0.381       182.754 ?   0.678     ns/op
>> stringJoiner                             10        32  cyrillic      240.239 ?   1.110       187.991 ?   1.575     ns/op
>> stringJoiner                             10        64  cyrillic      382.493 ?   2.692       219.358 ?   0.967     ns/op
>> stringJoiner                            100         8  cyrillic     1737.435 ?  16.171      1658.379 ?  56.225     ns/op
>> stringJoiner                            100        32  cyrillic     2321.106 ?  13.583      1942.028 ?   3.418     ns/op
>> stringJoiner                            100        64  cyrillic     3189.563 ?  10.135      2484.796 ?   7.572     ns/op
>> stringJoiner                              5         8     mixed       88.743 ?   0.709        76.049 ?   0.685     ns/op
>> stringJoiner                              5        32     mixed      103.425 ?   0.745        81.006 ?   0.184     ns/op
>> stringJoiner                              5        64     mixed      146.441 ?   0.763        93.071 ?   0.858     ns/op
>> stringJoiner                             10         8     mixed      169.262 ?   0.482       158.890 ?   0.598     ns/op
>> stringJoiner                             10        32     mixed      218.566 ?   0.945       170.415 ?   1.172     ns/op
>> stringJoiner                             10        64     mixed      361.412 ?   1.546       200.374 ?   0.683     ns/op
>> stringJoiner                            100         8     mixed     1594.544 ?   5.761      1476.689 ?   2.004     ns/op
>> stringJoiner                            100        32     mixed     2221.333 ?  28.320      1879.071 ?  52.729     ns/op
>> stringJoiner                            100        64     mixed     3115.786 ?  22.485      2400.644 ?   4.401     ns/op
>> 
>> stringJoiner:?gc.alloc.rate.norm          5         8     latin      248.023 ?   0.001       136.015 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        32     latin      608.045 ?   0.001       256.022 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        64     latin     1088.067 ?   0.002       416.030 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10         8     latin      464.044 ?   0.001       264.029 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        32     latin     1184.085 ?   0.003       504.044 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        64     latin     2144.123 ?   0.005       824.065 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm        100         8     latin     3872.367 ?   8.002      2024.269 ?   8.016      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        32     latin    11048.803 ?   7.988      4416.393 ?   0.004      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        64     latin    20657.194 ?   9.775      7640.642 ?   9.819      B/op
>> stringJoiner:?gc.alloc.rate.norm          5         8  cyrillic      360.029 ?   0.001       184.020 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        32  cyrillic      960.060 ?   0.002       424.032 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        64  cyrillic     1760.088 ?   0.003       744.043 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10         8  cyrillic      664.063 ?   0.001       352.038 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        32  cyrillic     1864.128 ?   0.003       832.067 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        64  cyrillic     3464.206 ?   0.007      1472.094 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm        100         8  cyrillic     5704.541 ?   0.006      2928.317 ?   8.002      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        32  cyrillic    17705.090 ?   0.045      7720.658 ?   0.007      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        64  cyrillic    33689.855 ?   9.786     14121.042 ?   0.015      B/op
>> stringJoiner:?gc.alloc.rate.norm          5         8     mixed      360.028 ?   0.001       184.016 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        32     mixed      960.059 ?   0.002       424.031 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        64     mixed     1760.088 ?   0.003       744.041 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10         8     mixed      664.052 ?   0.001       352.035 ?   0.002      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        32     mixed     1864.116 ?   0.005       832.064 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        64     mixed     3464.196 ?   0.006      1472.088 ?   0.002      B/op
>> stringJoiner:?gc.alloc.rate.norm        100         8     mixed     5672.448 ?   8.002      2920.314 ?   0.006      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        32     mixed    17681.092 ?   9.824      7728.653 ?   8.008      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        64     mixed    33697.818 ?   8.011     14120.977 ?   0.034      B/op
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - 8148937: (str) Use StringBuilder as cl4es suggests
>  - 8148937: (str) Check also delimiter, prefix and suffix
>  - 8148937: (str) Adapt StringJoiner for Compact Strings

The copyright year and description of the microbenchmark needs to be updated (my copy-paste error). I'd also consider narrowing down the parameter combinations and iteration times so that default execution times is more reasonable (currently ~45 minutes even though these micros stabilize in seconds)

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

Changes requested by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2627

From iris at openjdk.java.net  Mon Mar 15 20:57:11 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Mon, 15 Mar 2021 20:57:11 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
Message-ID: <Ud-IMVh0npTQZfJllaY6Q47vKnV9-CKxv_Bx46FkOB0=.9f1c0566-95e7-441e-b527-c4f1f323fdda@github.com>

On Mon, 15 Mar 2021 09:21:22 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8263358: Refactored missed equals method

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From almatvee at openjdk.java.net  Mon Mar 15 21:42:09 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Mon, 15 Mar 2021 21:42:09 GMT
Subject: RFR: JDK-8263154: [macos] DMG builds have finder errors
In-Reply-To: <q_q2hdnvfEfyo76kIREN-tRxST60tLWyUYvOh3Xipws=.9e37f1ba-fa6f-4914-94bf-fa94c5de2b47@github.com>
References: <q_q2hdnvfEfyo76kIREN-tRxST60tLWyUYvOh3Xipws=.9e37f1ba-fa6f-4914-94bf-fa94c5de2b47@github.com>
Message-ID: <MGRjyjL-6TirMFrrcU6XyOlz_aeUel-EnD0MxYySY3c=.2c554d21-6504-4e6d-8dd6-5451802f5728@github.com>

On Sat, 13 Mar 2021 14:39:40 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8263154: [macos] DMG builds have finder errors

Can you explain what problem is and how it is fixed? Does it fails when "install-dir" is specified? "install-dir" is not relevant for DMG image and we should ignore it.

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

PR: https://git.openjdk.java.net/jdk/pull/2987

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 21:47:28 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 21:47:28 GMT
Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings [v3]
In-Reply-To: <V3-_ghd9MJZQxCWSiSwpVXHs-u4DaQo_g3mSjH9wOX0=.08042cfb-bce0-4885-8f58-049450952b1e@github.com>
References: <V3-_ghd9MJZQxCWSiSwpVXHs-u4DaQo_g3mSjH9wOX0=.08042cfb-bce0-4885-8f58-049450952b1e@github.com>
Message-ID: <nT8kSj_A3NsRoeUJWcV-X84baViZx_sluhPOrRVBJow=.af055b84-230d-4976-8501-3b9dd3e28fdf@github.com>

> Hello,
> 
> as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings.
> 
> This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols.
> 
> As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called:
> String delimiter = this.delimiter;
> char[] chars = new char[this.len + addLen];
> int k = getChars(this.prefix, chars, 0);
> if (size > 0) {
>     k += getChars(elts[0], chars, k);        // inflate byte[]
> 
>     for(int i = 1; i < size; ++i) {
>         k += getChars(delimiter, chars, k);
>         k += getChars(elts[i], chars, k);
>     }
> }
> 
> k += getChars(this.suffix, chars, k);
> return new String(chars);                    // compress char[] -> byte[]
> This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082)
> covering both cases when resulting String is Latin1 or UTF-16
> 
> I've prepared a patch along with benchmark proving that this change is correct and brings improvement.
> 
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class StringJoinerBenchmark {
> 
>   @Benchmark
>   public String stringJoiner(Data data) {
>     String[] stringArray = data.stringArray;
>     return Joiner.joinWithStringJoiner(stringArray);
>   }
> 
>   @State(Scope.Thread)
>   public static class Data {
> 
>     @Param({"latin", "cyrillic", "mixed"})
>     private String mode;
> 
>     @Param({"8", "32", "64"})
>     private int length;
> 
>     @Param({"5", "10", "100"})
>     private int count;
> 
>     private String[] stringArray;
> 
>     @Setup
>     public void setup() {
>       RandomStringGenerator generator = new RandomStringGenerator();
> 
>       stringArray = new String[count];
> 
>       for (int i = 0; i < count; i++) {
>         String alphabet = getAlphabet(i, mode);
>         stringArray[i] = generator.randomString(alphabet, length);
>       }
>     }
> 
>     private static String getAlphabet(int index, String mode) {
>       var latin = "abcdefghijklmnopqrstuvwxyz"; //English
>       var cyrillic = "????????????????????????????????"; // Russian
> 
>       String alphabet;
>       switch (mode) {
>         case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin;
>         case "latin" -> alphabet = latin;
>         case "cyrillic" -> alphabet = cyrillic;
>         default -> throw new RuntimeException("Illegal mode " + mode);
>       }
>       return alphabet;
>     }
>   }
> }
> 
> public class Joiner {
> 
>   public static String joinWithStringJoiner(String[] stringArray) {
>     StringJoiner joiner = new StringJoiner(",", "[", "]");
>     for (String str : stringArray) {
>       joiner.add(str);
>     }
>     return joiner.toString();
>   }
> }
> 
> 
>                                     (count)  (length)    (mode)                Java 14                 patched     Units
> stringJoiner                              5         8     latin       78.836 ?   0.208        67.546 ?   0.500     ns/op
> stringJoiner                              5        32     latin       92.877 ?   0.422        66.760 ?   0.498     ns/op
> stringJoiner                              5        64     latin      115.423 ?   0.883        73.224 ?   0.289     ns/op
> stringJoiner                             10         8     latin      152.587 ?   0.429       161.427 ?   0.635     ns/op
> stringJoiner                             10        32     latin      189.998 ?   0.478       164.099 ?   0.963     ns/op
> stringJoiner                             10        64     latin      238.679 ?   1.419       176.825 ?   0.533     ns/op
> stringJoiner                            100         8     latin     1215.612 ?  17.413      1541.802 ? 126.166     ns/op
> stringJoiner                            100        32     latin     1699.998 ?  28.407      1563.341 ?   4.439     ns/op
> stringJoiner                            100        64     latin     2289.388 ?  45.319      2215.931 ? 137.583     ns/op
> stringJoiner                              5         8  cyrillic       96.692 ?   0.947        80.946 ?   0.371     ns/op
> stringJoiner                              5        32  cyrillic      107.806 ?   0.429        84.717 ?   0.541     ns/op
> stringJoiner                              5        64  cyrillic      150.762 ?   2.267        96.214 ?   1.251     ns/op
> stringJoiner                             10         8  cyrillic      190.570 ?   0.381       182.754 ?   0.678     ns/op
> stringJoiner                             10        32  cyrillic      240.239 ?   1.110       187.991 ?   1.575     ns/op
> stringJoiner                             10        64  cyrillic      382.493 ?   2.692       219.358 ?   0.967     ns/op
> stringJoiner                            100         8  cyrillic     1737.435 ?  16.171      1658.379 ?  56.225     ns/op
> stringJoiner                            100        32  cyrillic     2321.106 ?  13.583      1942.028 ?   3.418     ns/op
> stringJoiner                            100        64  cyrillic     3189.563 ?  10.135      2484.796 ?   7.572     ns/op
> stringJoiner                              5         8     mixed       88.743 ?   0.709        76.049 ?   0.685     ns/op
> stringJoiner                              5        32     mixed      103.425 ?   0.745        81.006 ?   0.184     ns/op
> stringJoiner                              5        64     mixed      146.441 ?   0.763        93.071 ?   0.858     ns/op
> stringJoiner                             10         8     mixed      169.262 ?   0.482       158.890 ?   0.598     ns/op
> stringJoiner                             10        32     mixed      218.566 ?   0.945       170.415 ?   1.172     ns/op
> stringJoiner                             10        64     mixed      361.412 ?   1.546       200.374 ?   0.683     ns/op
> stringJoiner                            100         8     mixed     1594.544 ?   5.761      1476.689 ?   2.004     ns/op
> stringJoiner                            100        32     mixed     2221.333 ?  28.320      1879.071 ?  52.729     ns/op
> stringJoiner                            100        64     mixed     3115.786 ?  22.485      2400.644 ?   4.401     ns/op
> 
> stringJoiner:?gc.alloc.rate.norm          5         8     latin      248.023 ?   0.001       136.015 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        32     latin      608.045 ?   0.001       256.022 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        64     latin     1088.067 ?   0.002       416.030 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10         8     latin      464.044 ?   0.001       264.029 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        32     latin     1184.085 ?   0.003       504.044 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        64     latin     2144.123 ?   0.005       824.065 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm        100         8     latin     3872.367 ?   8.002      2024.269 ?   8.016      B/op
> stringJoiner:?gc.alloc.rate.norm        100        32     latin    11048.803 ?   7.988      4416.393 ?   0.004      B/op
> stringJoiner:?gc.alloc.rate.norm        100        64     latin    20657.194 ?   9.775      7640.642 ?   9.819      B/op
> stringJoiner:?gc.alloc.rate.norm          5         8  cyrillic      360.029 ?   0.001       184.020 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        32  cyrillic      960.060 ?   0.002       424.032 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        64  cyrillic     1760.088 ?   0.003       744.043 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10         8  cyrillic      664.063 ?   0.001       352.038 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        32  cyrillic     1864.128 ?   0.003       832.067 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        64  cyrillic     3464.206 ?   0.007      1472.094 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm        100         8  cyrillic     5704.541 ?   0.006      2928.317 ?   8.002      B/op
> stringJoiner:?gc.alloc.rate.norm        100        32  cyrillic    17705.090 ?   0.045      7720.658 ?   0.007      B/op
> stringJoiner:?gc.alloc.rate.norm        100        64  cyrillic    33689.855 ?   9.786     14121.042 ?   0.015      B/op
> stringJoiner:?gc.alloc.rate.norm          5         8     mixed      360.028 ?   0.001       184.016 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        32     mixed      960.059 ?   0.002       424.031 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        64     mixed     1760.088 ?   0.003       744.041 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10         8     mixed      664.052 ?   0.001       352.035 ?   0.002      B/op
> stringJoiner:?gc.alloc.rate.norm         10        32     mixed     1864.116 ?   0.005       832.064 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        64     mixed     3464.196 ?   0.006      1472.088 ?   0.002      B/op
> stringJoiner:?gc.alloc.rate.norm        100         8     mixed     5672.448 ?   8.002      2920.314 ?   0.006      B/op
> stringJoiner:?gc.alloc.rate.norm        100        32     mixed    17681.092 ?   9.824      7728.653 ?   8.008      B/op
> stringJoiner:?gc.alloc.rate.norm        100        64     mixed    33697.818 ?   8.011     14120.977 ?   0.034      B/op

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

  8148937: (str) Update copyright year

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2627/files
  - new: https://git.openjdk.java.net/jdk/pull/2627/files/e0d7d122..b600ea62

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2627&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2627&range=01-02

  Stats: 7 lines in 2 files changed: 0 ins; 1 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2627.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2627/head:pull/2627

PR: https://git.openjdk.java.net/jdk/pull/2627

From github.com+10835776+stsypanov at openjdk.java.net  Mon Mar 15 21:47:31 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Mon, 15 Mar 2021 21:47:31 GMT
Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings [v2]
In-Reply-To: <FWwZceMHPTBjuRX5BqJX9gEpLduWcMkZL-4T2cSEeb0=.4390ce57-a9ce-4592-b263-12982dd9d4bb@github.com>
References: <V3-_ghd9MJZQxCWSiSwpVXHs-u4DaQo_g3mSjH9wOX0=.08042cfb-bce0-4885-8f58-049450952b1e@github.com>
 <RuwRUTqLndnJduD4RdMhxYq006a0GsITIZB3crliZYU=.645d9f89-d189-4695-b003-a031af309765@github.com>
 <FWwZceMHPTBjuRX5BqJX9gEpLduWcMkZL-4T2cSEeb0=.4390ce57-a9ce-4592-b263-12982dd9d4bb@github.com>
Message-ID: <dC2zmPxH29LtaHJ2kvpoom6nbvEqOBvEhfynb1UfjTI=.75e4ba80-2fff-47dd-b395-5ab4eee5e135@github.com>

On Mon, 15 Mar 2021 20:54:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request with a new target base 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:
>> 
>>  - 8148937: (str) Use StringBuilder as cl4es suggests
>>  - 8148937: (str) Check also delimiter, prefix and suffix
>>  - 8148937: (str) Adapt StringJoiner for Compact Strings
>
> The copyright year and description of the microbenchmark needs to be updated (my copy-paste error). I'd also consider narrowing down the parameter combinations and iteration times so that default execution times is more reasonable (currently ~45 minutes even though these micros stabilize in seconds)

Done. I've removed mixed mode from benchmark, anyway it falls back to non-latin1 case

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

PR: https://git.openjdk.java.net/jdk/pull/2627

From redestad at openjdk.java.net  Mon Mar 15 22:28:09 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 15 Mar 2021 22:28:09 GMT
Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings [v3]
In-Reply-To: <nT8kSj_A3NsRoeUJWcV-X84baViZx_sluhPOrRVBJow=.af055b84-230d-4976-8501-3b9dd3e28fdf@github.com>
References: <V3-_ghd9MJZQxCWSiSwpVXHs-u4DaQo_g3mSjH9wOX0=.08042cfb-bce0-4885-8f58-049450952b1e@github.com>
 <nT8kSj_A3NsRoeUJWcV-X84baViZx_sluhPOrRVBJow=.af055b84-230d-4976-8501-3b9dd3e28fdf@github.com>
Message-ID: <1XB3J7cc36ryVjr0mAqJNXi4qkzoEPvv6epleEvJGTs=.df2d2d20-97f1-437a-87df-ee7c74dfae68@github.com>

On Mon, 15 Mar 2021 21:47:28 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Hello,
>> 
>> as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings.
>> 
>> This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols.
>> 
>> As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called:
>> String delimiter = this.delimiter;
>> char[] chars = new char[this.len + addLen];
>> int k = getChars(this.prefix, chars, 0);
>> if (size > 0) {
>>     k += getChars(elts[0], chars, k);        // inflate byte[]
>> 
>>     for(int i = 1; i < size; ++i) {
>>         k += getChars(delimiter, chars, k);
>>         k += getChars(elts[i], chars, k);
>>     }
>> }
>> 
>> k += getChars(this.suffix, chars, k);
>> return new String(chars);                    // compress char[] -> byte[]
>> This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082)
>> covering both cases when resulting String is Latin1 or UTF-16
>> 
>> I've prepared a patch along with benchmark proving that this change is correct and brings improvement.
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>> public class StringJoinerBenchmark {
>> 
>>   @Benchmark
>>   public String stringJoiner(Data data) {
>>     String[] stringArray = data.stringArray;
>>     return Joiner.joinWithStringJoiner(stringArray);
>>   }
>> 
>>   @State(Scope.Thread)
>>   public static class Data {
>> 
>>     @Param({"latin", "cyrillic", "mixed"})
>>     private String mode;
>> 
>>     @Param({"8", "32", "64"})
>>     private int length;
>> 
>>     @Param({"5", "10", "100"})
>>     private int count;
>> 
>>     private String[] stringArray;
>> 
>>     @Setup
>>     public void setup() {
>>       RandomStringGenerator generator = new RandomStringGenerator();
>> 
>>       stringArray = new String[count];
>> 
>>       for (int i = 0; i < count; i++) {
>>         String alphabet = getAlphabet(i, mode);
>>         stringArray[i] = generator.randomString(alphabet, length);
>>       }
>>     }
>> 
>>     private static String getAlphabet(int index, String mode) {
>>       var latin = "abcdefghijklmnopqrstuvwxyz"; //English
>>       var cyrillic = "????????????????????????????????"; // Russian
>> 
>>       String alphabet;
>>       switch (mode) {
>>         case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin;
>>         case "latin" -> alphabet = latin;
>>         case "cyrillic" -> alphabet = cyrillic;
>>         default -> throw new RuntimeException("Illegal mode " + mode);
>>       }
>>       return alphabet;
>>     }
>>   }
>> }
>> 
>> public class Joiner {
>> 
>>   public static String joinWithStringJoiner(String[] stringArray) {
>>     StringJoiner joiner = new StringJoiner(",", "[", "]");
>>     for (String str : stringArray) {
>>       joiner.add(str);
>>     }
>>     return joiner.toString();
>>   }
>> }
>> 
>> 
>>                                     (count)  (length)    (mode)                Java 14                 patched     Units
>> stringJoiner                              5         8     latin       78.836 ?   0.208        67.546 ?   0.500     ns/op
>> stringJoiner                              5        32     latin       92.877 ?   0.422        66.760 ?   0.498     ns/op
>> stringJoiner                              5        64     latin      115.423 ?   0.883        73.224 ?   0.289     ns/op
>> stringJoiner                             10         8     latin      152.587 ?   0.429       161.427 ?   0.635     ns/op
>> stringJoiner                             10        32     latin      189.998 ?   0.478       164.099 ?   0.963     ns/op
>> stringJoiner                             10        64     latin      238.679 ?   1.419       176.825 ?   0.533     ns/op
>> stringJoiner                            100         8     latin     1215.612 ?  17.413      1541.802 ? 126.166     ns/op
>> stringJoiner                            100        32     latin     1699.998 ?  28.407      1563.341 ?   4.439     ns/op
>> stringJoiner                            100        64     latin     2289.388 ?  45.319      2215.931 ? 137.583     ns/op
>> stringJoiner                              5         8  cyrillic       96.692 ?   0.947        80.946 ?   0.371     ns/op
>> stringJoiner                              5        32  cyrillic      107.806 ?   0.429        84.717 ?   0.541     ns/op
>> stringJoiner                              5        64  cyrillic      150.762 ?   2.267        96.214 ?   1.251     ns/op
>> stringJoiner                             10         8  cyrillic      190.570 ?   0.381       182.754 ?   0.678     ns/op
>> stringJoiner                             10        32  cyrillic      240.239 ?   1.110       187.991 ?   1.575     ns/op
>> stringJoiner                             10        64  cyrillic      382.493 ?   2.692       219.358 ?   0.967     ns/op
>> stringJoiner                            100         8  cyrillic     1737.435 ?  16.171      1658.379 ?  56.225     ns/op
>> stringJoiner                            100        32  cyrillic     2321.106 ?  13.583      1942.028 ?   3.418     ns/op
>> stringJoiner                            100        64  cyrillic     3189.563 ?  10.135      2484.796 ?   7.572     ns/op
>> stringJoiner                              5         8     mixed       88.743 ?   0.709        76.049 ?   0.685     ns/op
>> stringJoiner                              5        32     mixed      103.425 ?   0.745        81.006 ?   0.184     ns/op
>> stringJoiner                              5        64     mixed      146.441 ?   0.763        93.071 ?   0.858     ns/op
>> stringJoiner                             10         8     mixed      169.262 ?   0.482       158.890 ?   0.598     ns/op
>> stringJoiner                             10        32     mixed      218.566 ?   0.945       170.415 ?   1.172     ns/op
>> stringJoiner                             10        64     mixed      361.412 ?   1.546       200.374 ?   0.683     ns/op
>> stringJoiner                            100         8     mixed     1594.544 ?   5.761      1476.689 ?   2.004     ns/op
>> stringJoiner                            100        32     mixed     2221.333 ?  28.320      1879.071 ?  52.729     ns/op
>> stringJoiner                            100        64     mixed     3115.786 ?  22.485      2400.644 ?   4.401     ns/op
>> 
>> stringJoiner:?gc.alloc.rate.norm          5         8     latin      248.023 ?   0.001       136.015 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        32     latin      608.045 ?   0.001       256.022 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        64     latin     1088.067 ?   0.002       416.030 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10         8     latin      464.044 ?   0.001       264.029 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        32     latin     1184.085 ?   0.003       504.044 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        64     latin     2144.123 ?   0.005       824.065 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm        100         8     latin     3872.367 ?   8.002      2024.269 ?   8.016      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        32     latin    11048.803 ?   7.988      4416.393 ?   0.004      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        64     latin    20657.194 ?   9.775      7640.642 ?   9.819      B/op
>> stringJoiner:?gc.alloc.rate.norm          5         8  cyrillic      360.029 ?   0.001       184.020 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        32  cyrillic      960.060 ?   0.002       424.032 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        64  cyrillic     1760.088 ?   0.003       744.043 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10         8  cyrillic      664.063 ?   0.001       352.038 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        32  cyrillic     1864.128 ?   0.003       832.067 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        64  cyrillic     3464.206 ?   0.007      1472.094 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm        100         8  cyrillic     5704.541 ?   0.006      2928.317 ?   8.002      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        32  cyrillic    17705.090 ?   0.045      7720.658 ?   0.007      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        64  cyrillic    33689.855 ?   9.786     14121.042 ?   0.015      B/op
>> stringJoiner:?gc.alloc.rate.norm          5         8     mixed      360.028 ?   0.001       184.016 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        32     mixed      960.059 ?   0.002       424.031 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        64     mixed     1760.088 ?   0.003       744.041 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10         8     mixed      664.052 ?   0.001       352.035 ?   0.002      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        32     mixed     1864.116 ?   0.005       832.064 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        64     mixed     3464.196 ?   0.006      1472.088 ?   0.002      B/op
>> stringJoiner:?gc.alloc.rate.norm        100         8     mixed     5672.448 ?   8.002      2920.314 ?   0.006      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        32     mixed    17681.092 ?   9.824      7728.653 ?   8.008      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        64     mixed    33697.818 ?   8.011     14120.977 ?   0.034      B/op
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8148937: (str) Update copyright year

Marked as reviewed by redestad (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2627

From almatvee at openjdk.java.net  Mon Mar 15 22:42:10 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Mon, 15 Mar 2021 22:42:10 GMT
Subject: RFR: JDK-8263545: Convert jpackage to use Stream.toList() [v2]
In-Reply-To: <6Q7RKg86uh-Tg0GRsMF0gUK9IQVsw3spvLyPb9p0jQo=.33d10404-894a-46b7-9e83-3eb235bde456@github.com>
References: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
 <6Q7RKg86uh-Tg0GRsMF0gUK9IQVsw3spvLyPb9p0jQo=.33d10404-894a-46b7-9e83-3eb235bde456@github.com>
Message-ID: <1tMOWDXgTUTRWDu7EroamDSKLoRB6j3ztFiLqs-q2qw=.ff9e3c10-5e74-468c-a685-f3a1c96aa4a5@github.com>

On Mon, 15 Mar 2021 18:53:26 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This converts jpackage to use `Stream.toList()` instead of `Stream.collect(Collectors.toList())`. One piece of code was modified to not mutate a list in addition to one test that used a mutating sort on a list. The rest of the changes are simple substitutions.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarifying type argument and shorting a toArray invocation

Marked as reviewed by almatvee (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2997

From darcy at openjdk.java.net  Mon Mar 15 23:05:14 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 15 Mar 2021 23:05:14 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v31]
In-Reply-To: <VKucCe2YRlRl3S6HDMxN5_q9xx6450oLSs2eHsfEFIA=.3dc00672-45c9-4f1e-b5bd-1968aa0bf63b@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <VKucCe2YRlRl3S6HDMxN5_q9xx6450oLSs2eHsfEFIA=.3dc00672-45c9-4f1e-b5bd-1968aa0bf63b@github.com>
Message-ID: <IYSxEORgZ1DDRwoVjgbVOyR_hqkAHZfEunugKpVk23Q=.56473b65-2fff-4eea-bc38-d299b00fbdc2@github.com>

On Mon, 15 Mar 2021 12:54:32 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
>> 
>> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>> 
>> old PR:  https://github.com/openjdk/jdk/pull/1273
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing @since

src/java.base/share/classes/java/util/Random.java line 135:

> 133:      * number generator which is maintained by method {@link #next}.
> 134:      *
> 135:      * @implSpec <p>The invocation {@code new Random(seed)} is equivalent to:

This is not conventional formatting for an implSpec section. I suggest putting implSpec on its own line and then left-justifying the text as normal. A new paragraph tag is no needed at the beginning of implSpec.

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From darcy at openjdk.java.net  Mon Mar 15 23:11:14 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 15 Mar 2021 23:11:14 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v31]
In-Reply-To: <VKucCe2YRlRl3S6HDMxN5_q9xx6450oLSs2eHsfEFIA=.3dc00672-45c9-4f1e-b5bd-1968aa0bf63b@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <VKucCe2YRlRl3S6HDMxN5_q9xx6450oLSs2eHsfEFIA=.3dc00672-45c9-4f1e-b5bd-1968aa0bf63b@github.com>
Message-ID: <qd5H4ke7UsQlKhgmxSa9ssITkjopLucGg3bVmP1SKNs=.9b49cd22-25a0-44de-984c-3b3ca5a0f0c2@github.com>

On Mon, 15 Mar 2021 12:54:32 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
>> 
>> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>> 
>> old PR:  https://github.com/openjdk/jdk/pull/1273
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Missing @since

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 62:

> 60:     @Retention(RetentionPolicy.RUNTIME)
> 61:     @Target(ElementType.TYPE)
> 62:     public @interface RandomGeneratorProperties {

Should the is-deprecated information be stored here?

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From serb at openjdk.java.net  Tue Mar 16 00:36:10 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 16 Mar 2021 00:36:10 GMT
Subject: RFR: 8263560: Remove needless wrapping with BufferedInputStream
 [v6]
In-Reply-To: <12UOgMQ-mVVH7usEXj3a-GAW56QmG54t6chEIVQTJRI=.e7821199-ea42-4c0a-b1f8-27453fc8d02e@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
 <12UOgMQ-mVVH7usEXj3a-GAW56QmG54t6chEIVQTJRI=.e7821199-ea42-4c0a-b1f8-27453fc8d02e@github.com>
Message-ID: <ymP892-NKnsza-5llGFP9_uSdg7BR3SW4Fvmqan23V4=.b1864466-478e-4404-af7e-18cbd59c13b5@github.com>

On Mon, 15 Mar 2021 18:04:26 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
>> 
>> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert HttpClient

Marked as reviewed by serb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2992

From joehw at openjdk.java.net  Tue Mar 16 00:58:14 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 16 Mar 2021 00:58:14 GMT
Subject: RFR: 8261673: Move javadoc for the lookup mechanism to module-info
Message-ID: <wg6xvhZiamooKkIS_HhsC0zOcFl9LN82cg3Xc_QBbqM=.b09e8950-6c4e-477d-a2b3-455eab6046f1@github.com>

Consolidate and move javadoc for the lookup mechanism to the module summary.

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

Commit messages:
 - 8261673: Move javadoc for the lookup mechanism to module-info

Changes: https://git.openjdk.java.net/jdk/pull/3020/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3020&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8261673
  Stats: 602 lines in 9 files changed: 197 ins; 361 del; 44 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3020.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3020/head:pull/3020

PR: https://git.openjdk.java.net/jdk/pull/3020

From serb at openjdk.java.net  Tue Mar 16 01:58:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 16 Mar 2021 01:58:08 GMT
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM
In-Reply-To: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
Message-ID: <acZoevVQtNOwkvpYhhWU6sx2Rh1K7bnAxVKRRZrTykQ=.73760624-f0f2-495a-b6e4-4e5639896a0d@github.com>

On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS.
> 
> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the launcher trying to grab class name to be displayed as the Application name on the menu.
> 
> The fix is to not setting name, test shows that GUI java application shows 'bin' as the application name. It's possible for us to set the name to something more friendly, for example, "Java", but I am not sure that should be launcher's responsibility to choose such a default name. It seems to me the consumer of the JAVA_MAIN_CLASS_%d environment variable should be responsible to pick such name in case the environment variable is not set.

This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8076264, and the fix looks fine.

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

PR: https://git.openjdk.java.net/jdk/pull/2999

From serb at openjdk.java.net  Tue Mar 16 02:04:11 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 16 Mar 2021 02:04:11 GMT
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM
In-Reply-To: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
Message-ID: <yFP3B1qIjH9bc7sz1rO9lRs3nQTQN8SIIxXISpd9DoI=.4f15814e-f0e4-48d4-8fb5-e35648e79dd8@github.com>

On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS.
> 
> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the launcher trying to grab class name to be displayed as the Application name on the menu.
> 
> The fix is to not setting name, test shows that GUI java application shows 'bin' as the application name. It's possible for us to set the name to something more friendly, for example, "Java", but I am not sure that should be launcher's responsibility to choose such a default name. It seems to me the consumer of the JAVA_MAIN_CLASS_%d environment variable should be responsible to pick such name in case the environment variable is not set.

test/jdk/tools/launcher/8261785/CrashTheJVM.java line 1:

> 1: import java.io.IOException;

Copyright?

test/jdk/tools/launcher/8261785/Test8261785.java line 5:

> 3:  * COPYRIGHT NOTICES OR THIS FILE HEADER.
> 4:  *
> 5:  * This code is free software; you can redistribute it and/or modify it under the terms of the GNU

Looks like formatting much wider than usual

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

PR: https://git.openjdk.java.net/jdk/pull/2999

From jpai at openjdk.java.net  Tue Mar 16 02:37:24 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 16 Mar 2021 02:37:24 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v4]
In-Reply-To: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
Message-ID: <l3Mvo9AR7XtaaWG3Sthfw7iOj3GnHOhzdRkP9OLwCRY=.9617e8ea-5ada-4d9a-966f-7a425952d766@github.com>

> Can I please get a review for this proposed patch for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8263108?
> 
> As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and `java.lang.constant.ConstantDescs` can end up in a classloading deadlock due to the nature of the code involved in their static blocks. A thread dump of one such deadlock (reproduced using the code attached to that issue) is as follows:
> 
> "Thread A" #14 prio=5 os_prio=31 cpu=101.45ms elapsed=8.30s tid=0x00007ff88e01ca00 nid=0x6003 in Object.wait()  [0x000070000a4c6000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.constant.DynamicConstantDesc.<clinit>(java.base at 16-ea/DynamicConstantDesc.java:67)
> 	- waiting on the Class initialization monitor for java.lang.constant.ConstantDescs
> 	at Deadlock.threadA(Deadlock.java:14)
> 	at Deadlock$$Lambda$1/0x0000000800c00a08.run(Unknown Source)
> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
> 
> "Thread B" #15 prio=5 os_prio=31 cpu=103.15ms elapsed=8.30s tid=0x00007ff88b936a00 nid=0x9b03 in Object.wait()  [0x000070000a5c9000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.constant.ClassDesc.ofDescriptor(java.base at 16-ea/ClassDesc.java:145)
> 	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc
> 	at java.lang.constant.ConstantDescs.<clinit>(java.base at 16-ea/ConstantDescs.java:239)
> 	at Deadlock.threadB(Deadlock.java:24)
> 	at Deadlock$$Lambda$2/0x0000000800c00c28.run(Unknown Source)
> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
> 
> The commit in this PR resolves that deadlock by moving the `canonicalMap` initialization in `DynamicConstantDesc`, from the static block, to a lazily initialized map, into the `tryCanonicalize` (private) method of the same class. That's the only method which uses this map.
> 
> The implementation in `tryCanonicalize` carefully ensures that the deadlock isn't shifted from the static block to this method, by making sure that the `synchronization` on `DynamicConstantDesc` in this method happens only when it's time to write the state to the shared `canonicalMap`. This has an implication that the method local variable `canonDescs` can get initialized by multiple threads unnecessarily but from what I can see, that's the only way we can avoid this deadlock. This penalty of multiple threads initializing and then throwing away that map isn't too huge because that will happen only once when the `canonicalMap` is being initialized for the first time.
> 
> An alternate approach that I thought of was to completely get rid of this shared cache `canonicalMap` and instead just use method level map (that gets initialized each time) in the `tryCanonicalize` method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.
> 
> The commit in this PR also includes a jtreg testcase which (consistently) reproduces the deadlock without the fix and passes when this fix is applied. Extra manual testing has been done to verify that the classes of interest (noted in that testcase) are indeed getting loaded in those concurrent threads and not in the main thread. For future maintainers, there's a implementation note added on that testcase explaining why it cannot be moved into testng test.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Use Chris' suggested solution of avoiding deadlock

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2893/files
  - new: https://git.openjdk.java.net/jdk/pull/2893/files/2b51ec9d..3b8e4a5d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2893&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2893&range=02-03

  Stats: 32 lines in 1 file changed: 11 ins; 20 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2893.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2893/head:pull/2893

PR: https://git.openjdk.java.net/jdk/pull/2893

From jpai at openjdk.java.net  Tue Mar 16 02:37:24 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 16 Mar 2021 02:37:24 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v2]
In-Reply-To: <OiZ8iko9D0za8sU_cfO1vT9dvQWilq4BpVINcb75HHE=.c654474f-f01a-425e-badf-a867454bf1cc@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <8601DNFkEWL76jjuZpNosikeT-1L6fsoz9yf5B79uoU=.bfb92ddd-63d8-44b3-84b6-c73413ab342f@github.com>
 <gLGKOnXo8i_FuwF2ahIwi6zlGzdzoZfXvyu9g3-BoWk=.3ff679bc-c900-4220-89bf-e3cf83a2bada@github.com>
 <BaNG8I3A5tjrXTveKKV9N7EpB1dZmjvVBnhd229zrx0=.a3b25438-34d2-46f4-8f62-40f1b2b8d454@github.com>
 <zMZdl4V9pFvTiqeVfGa1ba7tux0Oa89AV0ndfNLmlnw=.1205a1c3-fe8d-4320-b767-f0816898491d@github.com>
 <OiZ8iko9D0za8sU_cfO1vT9dvQWilq4BpVINcb75HHE=.c654474f-f01a-425e-badf-a867454bf1cc@github.com>
Message-ID: <n6FlS_u9-kZhidUeT6oNgP3qgEdbshT0X-LfAGsP7Ic=.b65b5165-a97b-4952-82ba-0c1687657302@github.com>

On Mon, 15 Mar 2021 17:15:59 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>>> What you have is probably fine, but has any consideration been given to using the initialization-on-demand holder idiom? e.g.
>>> 
>>> ```
>>>  static private class CanonicalMapHolder {
>>>     static final Map<MethodHandleDesc, Function<DynamicConstantDesc<?>, ConstantDesc>> CANONICAL_MAP
>>>           = Map.ofEntries(..);
>>>  }
>>> ```
>> 
>> Hello Chris,
>> 
>> Although I had thought of some other alternate ways to fix this, this idiom isn't something that I had thought of. Now that you showed this, I thought about it a bit more and it does look a lot more "natural" to read and maintain as compared to the current changes in this PR which does some juggling to avoid this deadlock. However, having thought about your proposed solution, I think _in theory_ it still leaves open the possibility of a deadlock.
>> 
>> Here's what the patch looks like with your suggested change:
>> 
>> diff --git a/src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java b/src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java
>> index 976b09e5665..c7bdcf4ce32 100644
>> --- a/src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java
>> +++ b/src/java.base/share/classes/java/lang/constant/DynamicConstantDesc.java
>> @@ -64,8 +64,6 @@ public abstract class DynamicConstantDesc<T>
>>      private final String constantName;
>>      private final ClassDesc constantType;
>>  
>> -    private static Map<MethodHandleDesc, Function<DynamicConstantDesc<?>, ConstantDesc>> canonicalMap;
>> -
>>      /**
>>       * Creates a nominal descriptor for a dynamic constant.
>>       *
>> @@ -274,25 +272,7 @@ public abstract class DynamicConstantDesc<T>
>>      }
>>  
>>      private ConstantDesc tryCanonicalize() {
>> -        var canonDescs = canonicalMap;
>> -        if (canonDescs == null) {
>> -            canonDescs = Map.ofEntries(
>> -                    Map.entry(ConstantDescs.BSM_PRIMITIVE_CLASS, DynamicConstantDesc::canonicalizePrimitiveClass),
>> -                    Map.entry(ConstantDescs.BSM_ENUM_CONSTANT, DynamicConstantDesc::canonicalizeEnum),
>> -                    Map.entry(ConstantDescs.BSM_NULL_CONSTANT, DynamicConstantDesc::canonicalizeNull),
>> -                    Map.entry(ConstantDescs.BSM_VARHANDLE_STATIC_FIELD, DynamicConstantDesc::canonicalizeStaticFieldVarHandle),
>> -                    Map.entry(ConstantDescs.BSM_VARHANDLE_FIELD, DynamicConstantDesc::canonicalizeFieldVarHandle),
>> -                    Map.entry(ConstantDescs.BSM_VARHANDLE_ARRAY, DynamicConstantDesc::canonicalizeArrayVarHandle));
>> -            synchronized (DynamicConstantDesc.class) {
>> -                if (canonicalMap == null) {
>> -                    canonicalMap = canonDescs;
>> -                } else {
>> -                    canonDescs = canonicalMap;
>> -                }
>> -            }
>> -        }
>> -
>> -        Function<DynamicConstantDesc<?>, ConstantDesc> f = canonDescs.get(bootstrapMethod);
>> +        Function<DynamicConstantDesc<?>, ConstantDesc> f = CanonicalMapHolder.CANONICAL_MAP.get(bootstrapMethod);
>>          if (f != null) {
>>              try {
>>                  return f.apply(this);
>> @@ -405,4 +385,15 @@ public abstract class DynamicConstantDesc<T>
>>              super(bootstrapMethod, constantName, constantType, bootstrapArgs);
>>          }
>>      }
>> +
>> +    private static final class CanonicalMapHolder {
>> +        static final Map<MethodHandleDesc, Function<DynamicConstantDesc<?>, ConstantDesc>> CANONICAL_MAP =
>> +                Map.ofEntries(
>> +                    Map.entry(ConstantDescs.BSM_PRIMITIVE_CLASS, DynamicConstantDesc::canonicalizePrimitiveClass),
>> +                    Map.entry(ConstantDescs.BSM_ENUM_CONSTANT, DynamicConstantDesc::canonicalizeEnum),
>> +                    Map.entry(ConstantDescs.BSM_NULL_CONSTANT, DynamicConstantDesc::canonicalizeNull),
>> +                    Map.entry(ConstantDescs.BSM_VARHANDLE_STATIC_FIELD, DynamicConstantDesc::canonicalizeStaticFieldVarHandle),
>> +                    Map.entry(ConstantDescs.BSM_VARHANDLE_FIELD, DynamicConstantDesc::canonicalizeFieldVarHandle),
>> +                    Map.entry(ConstantDescs.BSM_VARHANDLE_ARRAY, DynamicConstantDesc::canonicalizeArrayVarHandle));
>> +    }
>>  }
>> 
>> 
>> Please consider the following, where I try and explain the theoretical possibility of a deadlock with this approach:
>> 
>> 1. Let's consider 2 threads T1 and T2 doing concurrent execution
>> 
>> 2. Let's for a moment assume that neither `DynamicConstantDesc` nor `ConstantDescs` classes have been initialized.
>> 
>> 3. T1 does a call to `DynamicConstantDesc.ofCanonical(...)` and T2 does a call to something/anything on `ConstantDescs`, which triggers a class initialization of `ConstantDescs`.
>> 
>> 4. T1 (which called `DynamicConstantDesc.ofCanonical(...)`) will reach the `tryCanonicalize` and will access `CanonicalMapHolder.CANONICAL_MAP` in the implementation of that method. Because of this access (and since `CanonicalMapHolder` hasn't yet been initialized), T1 will obtain (an implicit) lock on the `CanonicalMapHolder` class (for the class initialization). Let's assume T1 is granted this lock on `CanonicalMapHolder` class and it goes ahead into the static block of that holder class to do the initialization of `CANONICAL_MAP`. To do so, because of the code in the static block of `CanonicalMapHolder`, it now requires a class initialization lock on `ConstantDescs` (since `ConstantDescs` hasn't yet been initialized). So it requests for that lock on `ConstantDescs` class.
>> 
>> 5. Concurrently, let's say T2 has initiated a class initialization of `ConstantDescs`. So T2 is currently holding a class initialization lock on `ConstantDescs`. While the static initialization of `ConstantDescs` is going on, let's assume (in theory), due to the whole lot of code in the static initialization of `ConstantDescs`, it either directly or indirectly ends up calling `DynamicConstantDesc.ofCanonical(...)`. This then means that T2 now enters the `tryCanonicalize` and accesses `CanonicalMapHolder.CANONICAL_MAP` and since `CanonicalMapHolder` hasn't yet been (fully) initialized (remember T1 is still in the static block of `CanonicalMapHolder`), it tries to obtain a class initialization lock on `CanonicalMapHolder` which is currently held by T1. T1 won't let go that lock since it wants the lock on `ConstantDescs` which is currently held by T2. This effectively ends up triggering the deadlock.
>> 
>> This deadlock isn't possible with the current approach that this PR has.
>> 
>> I want to clarify that, the deadlock that I explain above with your proposed approach is just a theoretical possibility. The `ConstantDescs` doesn't currently have any direct call to `DynamicConstantDesc.ofCanonical` in its static initialization nor can I see or think of any indirect calls to `DynamicConstantDesc.ofCanonical` from its static block. I need input from you whether I should keep aside this theoretic issue and deal with it if/when we run into it (the test case in this PR, IMO, is robust enough to catch that deadlock if/when it happens due to any future code changes in this area). If you and others think that we can ignore this case, then your proposed approach of using this lazy holder for initialization, IMO, is much cleaner and natural to read and I will go ahead and update this PR to use it.
>> 
>> For those interested in seeing this potential theoretical deadlock with the lazy holder approach in action, I just created a separate branch here https://github.com/jaikiran/jdk/commits/8263108-demo-deadlock-theory which consistently reproduces the deadlock when the `DynamicConstantDescTest` jtreg test is run. The crucial part is that I introduced the following (dummy) call in `ConstantDescs`:
>> 
>> diff --git a/src/java.base/share/classes/java/lang/constant/ConstantDescs.java b/src/java.base/share/classes/java/lang/constant/ConstantDescs.java
>> index 3a000d1bd4a..3f793f5a8b3 100644
>> --- a/src/java.base/share/classes/java/lang/constant/ConstantDescs.java
>> +++ b/src/java.base/share/classes/java/lang/constant/ConstantDescs.java
>> @@ -286,6 +286,13 @@ public final class ConstantDescs {
>>      static final DirectMethodHandleDesc MHD_METHODHANDLE_ASTYPE
>>              = MethodHandleDesc.ofMethod(Kind.VIRTUAL, CD_MethodHandle, "asType",
>>                                          MethodTypeDesc.of(CD_MethodHandle, CD_MethodType));
>> +
>> +    static {
>> +        // just a dummy call to DynamicConstantDesc.ofCanonical
>> +        DynamicConstantDesc.ofCanonical(ConstantDescs.BSM_ENUM_CONSTANT, "SHOW_REFLECT_FRAMES",
>> +                ClassDesc.of("java.lang.StackWalker").nested("Option"), new ConstantDesc[0]);
>> +    }
>> +
>> 
>> 
>> The following thread dump shows the deadlock with that lazy holder approach:
>> 
>> "MainThread" #15 prio=5 os_prio=31 cpu=6.26ms elapsed=120.18s tid=0x00007fe0e58df800 nid=0x5e03 waiting on condition  [0x000070000d71d000]
>>    java.lang.Thread.State: WAITING (parking)
>> 	at jdk.internal.misc.Unsafe.park(java.base at 17-internal/Native Method)
>> 	- parking to wait for  <0x000000070ff65d90> (a java.util.concurrent.FutureTask)
>> 	at java.util.concurrent.locks.LockSupport.park(java.base at 17-internal/LockSupport.java:211)
>> 	at java.util.concurrent.FutureTask.awaitDone(java.base at 17-internal/FutureTask.java:447)
>> 	at java.util.concurrent.FutureTask.get(java.base at 17-internal/FutureTask.java:190)
>> 	at DynamicConstantDescTest.main(DynamicConstantDescTest.java:80)
>> 	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base at 17-internal/Native Method)
>> 	at jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base at 17-internal/NativeMethodAccessorImpl.java:78)
>> 	at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(java.base at 17-internal/DelegatingMethodAccessorImpl.java:43)
>> 	at java.lang.reflect.Method.invoke(java.base at 17-internal/Method.java:566)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127)
>> 	at java.lang.Thread.run(java.base at 17-internal/Thread.java:831)
>> 
>> "pool-1-thread-1" #16 prio=5 os_prio=31 cpu=14.32ms elapsed=120.18s tid=0x00007fe0e58dea00 nid=0x9903 waiting on condition  [0x000070000d820000]
>>    java.lang.Thread.State: WAITING (parking)
>> 	at jdk.internal.misc.Unsafe.park(java.base at 17-internal/Native Method)
>> 	- parking to wait for  <0x000000070ff59d30> (a java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
>> 	at java.util.concurrent.locks.LockSupport.park(java.base at 17-internal/LockSupport.java:341)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionNode.block(java.base at 17-internal/AbstractQueuedSynchronizer.java:506)
>> 	at java.util.concurrent.ForkJoinPool.unmanagedBlock(java.base at 17-internal/ForkJoinPool.java:3454)
>> 	at java.util.concurrent.ForkJoinPool.managedBlock(java.base at 17-internal/ForkJoinPool.java:3425)
>> 	at java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(java.base at 17-internal/AbstractQueuedSynchronizer.java:1623)
>> 	at java.util.concurrent.LinkedBlockingQueue.take(java.base at 17-internal/LinkedBlockingQueue.java:435)
>> 	at java.util.concurrent.ThreadPoolExecutor.getTask(java.base at 17-internal/ThreadPoolExecutor.java:1061)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 17-internal/ThreadPoolExecutor.java:1121)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 17-internal/ThreadPoolExecutor.java:635)
>> 	at java.lang.Thread.run(java.base at 17-internal/Thread.java:831)
>> 
>> "pool-1-thread-2" #17 prio=5 os_prio=31 cpu=7.88ms elapsed=120.18s tid=0x00007fe0e4012c00 nid=0x6003 in Object.wait()  [0x000070000d923000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.DynamicConstantDesc.tryCanonicalize(java.base at 17-internal/DynamicConstantDesc.java:275)
>> 	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc$CanonicalMapHolder
>> 	at java.lang.constant.DynamicConstantDesc.ofCanonical(java.base at 17-internal/DynamicConstantDesc.java:136)
>> 	at DynamicConstantDescTest$InvokeOfCanonical.call(DynamicConstantDescTest.java:129)
>> 	at java.util.concurrent.FutureTask.run(java.base at 17-internal/FutureTask.java:264)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 17-internal/ThreadPoolExecutor.java:1135)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 17-internal/ThreadPoolExecutor.java:635)
>> 	at java.lang.Thread.run(java.base at 17-internal/Thread.java:831)
>> 
>> "pool-1-thread-3" #18 prio=5 os_prio=31 cpu=15.43ms elapsed=120.18s tid=0x00007fe0e4070600 nid=0x9803 in Object.wait()  [0x000070000da26000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.DynamicConstantDesc.tryCanonicalize(java.base at 17-internal/DynamicConstantDesc.java:275)
>> 	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc$CanonicalMapHolder
>> 	at java.lang.constant.DynamicConstantDesc.ofCanonical(java.base at 17-internal/DynamicConstantDesc.java:136)
>> 	at java.lang.constant.ConstantDescs.<clinit>(java.base at 17-internal/ConstantDescs.java:292)
>> 	at java.lang.Class.forName0(java.base at 17-internal/Native Method)
>> 	at java.lang.Class.forName(java.base at 17-internal/Class.java:375)
>> 	at DynamicConstantDescTest$Task.call(DynamicConstantDescTest.java:104)
>> 	at DynamicConstantDescTest$Task.call(DynamicConstantDescTest.java:87)
>> 	at java.util.concurrent.FutureTask.run(java.base at 17-internal/FutureTask.java:264)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 17-internal/ThreadPoolExecutor.java:1135)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 17-internal/ThreadPoolExecutor.java:635)
>> 	at java.lang.Thread.run(java.base at 17-internal/Thread.java:831)
>> 
>> "pool-1-thread-4" #19 prio=5 os_prio=31 cpu=5.39ms elapsed=120.18s tid=0x00007fe0e4070c00 nid=0x9603 in Object.wait()  [0x000070000db29000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.DynamicConstantDesc$CanonicalMapHolder.<clinit>(java.base at 17-internal/DynamicConstantDesc.java:390)
>> 	- waiting on the Class initialization monitor for java.lang.constant.ConstantDescs
>> 	at java.lang.constant.DynamicConstantDesc.tryCanonicalize(java.base at 17-internal/DynamicConstantDesc.java:275)
>> 	at java.lang.constant.DynamicConstantDesc.ofCanonical(java.base at 17-internal/DynamicConstantDesc.java:136)
>> 	at DynamicConstantDescTest$InvokeOfCanonical.call(DynamicConstantDescTest.java:129)
>> 	at java.util.concurrent.FutureTask.run(java.base at 17-internal/FutureTask.java:264)
>> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 17-internal/ThreadPoolExecutor.java:1135)
>> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 17-internal/ThreadPoolExecutor.java:635)
>> 	at java.lang.Thread.run(java.base at 17-internal/Thread.java:831)
>
>> If you and others think that we can ignore this case, then your proposed approach of using this lazy holder for initialization, IMO, is much cleaner and natural to read and I will go ahead and update this PR to use it.
> 
> For me, at least, the holder pattern is clearer. I'm happy with that approach.   ( I don't have an objection to the alternative, just a mild preference for the holder )

Hello Chris, using the holder pattern sounds fine to me then. I've updated this PR accordingly. The test continues to pass with this fix.

Peter, I didn't get a chance to try out the `@Stable` for the previous approach but given that we decided to use this holder pattern, we will no longer need the performance tweaks.

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From jpai at openjdk.java.net  Tue Mar 16 03:22:08 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 16 Mar 2021 03:22:08 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v2]
In-Reply-To: <n6FlS_u9-kZhidUeT6oNgP3qgEdbshT0X-LfAGsP7Ic=.b65b5165-a97b-4952-82ba-0c1687657302@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <8601DNFkEWL76jjuZpNosikeT-1L6fsoz9yf5B79uoU=.bfb92ddd-63d8-44b3-84b6-c73413ab342f@github.com>
 <gLGKOnXo8i_FuwF2ahIwi6zlGzdzoZfXvyu9g3-BoWk=.3ff679bc-c900-4220-89bf-e3cf83a2bada@github.com>
 <BaNG8I3A5tjrXTveKKV9N7EpB1dZmjvVBnhd229zrx0=.a3b25438-34d2-46f4-8f62-40f1b2b8d454@github.com>
 <zMZdl4V9pFvTiqeVfGa1ba7tux0Oa89AV0ndfNLmlnw=.1205a1c3-fe8d-4320-b767-f0816898491d@github.com>
 <OiZ8iko9D0za8sU_cfO1vT9dvQWilq4BpVINcb75HHE=.c654474f-f01a-425e-badf-a867454bf1cc@github.com>
 <n6FlS_u9-kZhidUeT6oNgP3qgEdbshT0X-LfAGsP7Ic=.b65b5165-a97b-4952-82ba-0c1687657302@github.com>
Message-ID: <zCAb8MAk5LVeSW4jS9fLwIxfUXzKhCBkOaibAV4r75I=.5189947d-45ab-43eb-b074-282df8dbb8af@github.com>

On Tue, 16 Mar 2021 02:34:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>>> If you and others think that we can ignore this case, then your proposed approach of using this lazy holder for initialization, IMO, is much cleaner and natural to read and I will go ahead and update this PR to use it.
>> 
>> For me, at least, the holder pattern is clearer. I'm happy with that approach.   ( I don't have an objection to the alternative, just a mild preference for the holder )
>
> Hello Chris, using the holder pattern sounds fine to me then. I've updated this PR accordingly. The test continues to pass with this fix.
> 
> Peter, I didn't get a chance to try out the `@Stable` for the previous approach but given that we decided to use this holder pattern, we will no longer need the performance tweaks.

Failure in Linux x86 build in GitHub Actions is unrelated to this change and looks like an environmental issue:

2021-03-16T02:35:22.3488438Z Err:59 https://dl.bintray.com/sbt/debian  Release.gpg
2021-03-16T02:35:22.3489341Z   502  Bad Gateway [IP: 35.161.90.47 443]
2021-03-16T02:35:30.2615937Z Reading package lists...
2021-03-16T02:35:30.2842714Z E: The repository 'https://dl.bintray.com/sbt/debian  Release' is no longer signed.

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From david.holmes at oracle.com  Tue Mar 16 04:59:31 2021
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 16 Mar 2021 14:59:31 +1000
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM
In-Reply-To: <acZoevVQtNOwkvpYhhWU6sx2Rh1K7bnAxVKRRZrTykQ=.73760624-f0f2-495a-b6e4-4e5639896a0d@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
 <acZoevVQtNOwkvpYhhWU6sx2Rh1K7bnAxVKRRZrTykQ=.73760624-f0f2-495a-b6e4-4e5639896a0d@github.com>
Message-ID: <e574db83-fca7-9284-8533-1bc2388abcc6@oracle.com>

On 16/03/2021 11:58 am, Sergey Bylokhov wrote:
> On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen <henryjen at openjdk.org> wrote:
> 
>> This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS.
>>
>> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the launcher trying to grab class name to be displayed as the Application name on the menu.
>>
>> The fix is to not setting name, test shows that GUI java application shows 'bin' as the application name. It's possible for us to set the name to something more friendly, for example, "Java", but I am not sure that should be launcher's responsibility to choose such a default name. It seems to me the consumer of the JAVA_MAIN_CLASS_%d environment variable should be responsible to pick such name in case the environment variable is not set.
> 
> This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8076264, and the fix looks fine.

Both issues involve a problem trying to use the canonical name, but I'd 
consider both fixes deficient when an alternative name could be used. 
But this isn't my code so ...

David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/2999
> 

From igraves at openjdk.java.net  Tue Mar 16 04:55:23 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 16 Mar 2021 04:55:23 GMT
Subject: RFR: JDK-8263545: Convert jpackage to use Stream.toList() [v3]
In-Reply-To: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
References: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
Message-ID: <62Ef-iVsd0mI5YTduK-5OZXBSZOilNW8w58FlFt31Kc=.24dc8681-21bb-4b80-94d7-7f4f85c51efc@github.com>

> This converts jpackage to use `Stream.toList()` instead of `Stream.collect(Collectors.toList())`. One piece of code was modified to not mutate a list in addition to one test that used a mutating sort on a list. The rest of the changes are simple substitutions.

Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Clarifying type argument and shorting a toArray invocation
 - Converting jpackage to use Stream.toList()

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

Changes: https://git.openjdk.java.net/jdk/pull/2997/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2997&range=02
  Stats: 47 lines in 17 files changed: 1 ins; 3 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2997.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2997/head:pull/2997

PR: https://git.openjdk.java.net/jdk/pull/2997

From vtewari at openjdk.java.net  Tue Mar 16 07:32:16 2021
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Tue, 16 Mar 2021 07:32:16 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v4]
In-Reply-To: <l3Mvo9AR7XtaaWG3Sthfw7iOj3GnHOhzdRkP9OLwCRY=.9617e8ea-5ada-4d9a-966f-7a425952d766@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <l3Mvo9AR7XtaaWG3Sthfw7iOj3GnHOhzdRkP9OLwCRY=.9617e8ea-5ada-4d9a-966f-7a425952d766@github.com>
Message-ID: <9DkSomkP4Sh6IE1FfQyE6DG9gcw3FlztIasU3XhtPP8=.ce3ceac2-8dac-46b2-b0b4-b100180bd362@github.com>

On Tue, 16 Mar 2021 02:37:24 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed patch for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8263108?
>> 
>> As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and `java.lang.constant.ConstantDescs` can end up in a classloading deadlock due to the nature of the code involved in their static blocks. A thread dump of one such deadlock (reproduced using the code attached to that issue) is as follows:
>> 
>> "Thread A" #14 prio=5 os_prio=31 cpu=101.45ms elapsed=8.30s tid=0x00007ff88e01ca00 nid=0x6003 in Object.wait()  [0x000070000a4c6000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.DynamicConstantDesc.<clinit>(java.base at 16-ea/DynamicConstantDesc.java:67)
>> 	- waiting on the Class initialization monitor for java.lang.constant.ConstantDescs
>> 	at Deadlock.threadA(Deadlock.java:14)
>> 	at Deadlock$$Lambda$1/0x0000000800c00a08.run(Unknown Source)
>> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
>> 
>> "Thread B" #15 prio=5 os_prio=31 cpu=103.15ms elapsed=8.30s tid=0x00007ff88b936a00 nid=0x9b03 in Object.wait()  [0x000070000a5c9000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.ClassDesc.ofDescriptor(java.base at 16-ea/ClassDesc.java:145)
>> 	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc
>> 	at java.lang.constant.ConstantDescs.<clinit>(java.base at 16-ea/ConstantDescs.java:239)
>> 	at Deadlock.threadB(Deadlock.java:24)
>> 	at Deadlock$$Lambda$2/0x0000000800c00c28.run(Unknown Source)
>> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
>> 
>> The commit in this PR resolves that deadlock by moving the `canonicalMap` initialization in `DynamicConstantDesc`, from the static block, to a lazily initialized map, into the `tryCanonicalize` (private) method of the same class. That's the only method which uses this map.
>> 
>> The implementation in `tryCanonicalize` carefully ensures that the deadlock isn't shifted from the static block to this method, by making sure that the `synchronization` on `DynamicConstantDesc` in this method happens only when it's time to write the state to the shared `canonicalMap`. This has an implication that the method local variable `canonDescs` can get initialized by multiple threads unnecessarily but from what I can see, that's the only way we can avoid this deadlock. This penalty of multiple threads initializing and then throwing away that map isn't too huge because that will happen only once when the `canonicalMap` is being initialized for the first time.
>> 
>> An alternate approach that I thought of was to completely get rid of this shared cache `canonicalMap` and instead just use method level map (that gets initialized each time) in the `tryCanonicalize` method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.
>> 
>> The commit in this PR also includes a jtreg testcase which (consistently) reproduces the deadlock without the fix and passes when this fix is applied. Extra manual testing has been done to verify that the classes of interest (noted in that testcase) are indeed getting loaded in those concurrent threads and not in the main thread. For future maintainers, there's a implementation note added on that testcase explaining why it cannot be moved into testng test.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Chris' suggested solution of avoiding deadlock

Looks good to me.

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

Marked as reviewed by vtewari (Committer).

PR: https://git.openjdk.java.net/jdk/pull/2893

From serb at openjdk.java.net  Tue Mar 16 07:47:08 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 16 Mar 2021 07:47:08 GMT
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM
In-Reply-To: <acZoevVQtNOwkvpYhhWU6sx2Rh1K7bnAxVKRRZrTykQ=.73760624-f0f2-495a-b6e4-4e5639896a0d@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
 <acZoevVQtNOwkvpYhhWU6sx2Rh1K7bnAxVKRRZrTykQ=.73760624-f0f2-495a-b6e4-4e5639896a0d@github.com>
Message-ID: <w7vA_cJ9W2ibNeh_wG5rImAhCC_LWS2oUdypz1mrehY=.9d2ff66e-87fe-4602-8dbe-ae155d8c3fb5@github.com>

On Tue, 16 Mar 2021 01:55:49 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS.
>> 
>> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the launcher trying to grab class name to be displayed as the Application name on the menu.
>> 
>> The fix is to not setting name, test shows that GUI java application shows 'bin' as the application name. It's possible for us to set the name to something more friendly, for example, "Java", but I am not sure that should be launcher's responsibility to choose such a default name. It seems to me the consumer of the JAVA_MAIN_CLASS_%d environment variable should be responsible to pick such name in case the environment variable is not set.
>
> This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8076264, and the fix looks fine.

> Maybe the AWT folk should decide what name should be displayed in this
> case. The canonical name was chosen when all main classes had to have a
> canonical name. So perhaps a simple name will suffice in the case where
> there is no canonical name?

This is not the last attempt to set the name, the JAVA_MAIN_CLASS_ variable is used in the middle of the name selection, there are some others. And the "bin" is selected by some of the next step, I agree it is not a friendly name that could be improved.

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

PR: https://git.openjdk.java.net/jdk/pull/2999

From shade at openjdk.java.net  Tue Mar 16 08:59:04 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 16 Mar 2021 08:59:04 GMT
Subject: RFR: 8263509: LdapSchemaParser.readNextTag checks array length
 incorrectly
In-Reply-To: <jvFM-MYm3iBf7GdEJmjHq7WekLOtOWtS6vkp-ecLxHg=.7828375d-dab3-40fd-8d7a-6f8b4b9ed1ef@github.com>
References: <l0_dFxE_8RDDQwx-dKwZcQ1D6B0UH1ZV8eUNAcpZ0Ic=.fab957ad-257f-427f-a228-2afbd50a00d6@github.com>
 <jvFM-MYm3iBf7GdEJmjHq7WekLOtOWtS6vkp-ecLxHg=.7828375d-dab3-40fd-8d7a-6f8b4b9ed1ef@github.com>
Message-ID: <y1ZLLvk0sE_I-iMWHUbEAj76LF2QAzTqAmEvWbSiqUs=.c1822ff0-56f1-48c0-8a54-ba17ba04d8f6@github.com>

On Fri, 12 Mar 2021 15:28:03 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> SonarCloud rightfully says:
>>   The length of "values" is always ">=0", so update this test to either "==0" or ">0".
>> 
>>         // make sure at least one value was returned
>>         if(values.length < 0) { // <--- here
>>             throw new InvalidAttributeValueException("no values for " +
>>                                                      "attribute "" +
>>                                                      tagName + """);
>>         }
>> 
>> There is a subsequent access to values[0], which means the failure would throw `AIOOB`, not `InvalidAttributeValueException`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `com/sun/jndi`
>
> Seems fine. Lets hope no caller relies on this throwing AIOOBE. 
> 
> ..Thomas

> This looks right but I'm surprised it isn't caught by tests (@AlekseiEfimov - do you have suggests for tests that would be useful to add here?)

Can we go without adding tests here? This seems quite trivial.

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

PR: https://git.openjdk.java.net/jdk/pull/2968

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 16 10:13:11 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 16 Mar 2021 10:13:11 GMT
Subject: Integrated: 8080272 Refactor I/O stream copying to use
 InputStream.transferTo/readAllBytes and Files.copy
In-Reply-To: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
References: <nrKRrpNRBVmVwklAY2VJkFI2ZMpeti686KW6mMMnWBE=.994d8e4a-bfd9-4375-b7ed-59c9c64a8752@github.com>
Message-ID: <Gm7s8Wp6sP7u0kYiTeTblJgRC5aCdi2LSB3zUiWWhKc=.a19637ca-c449-4176-96af-ae7dc0e09b26@github.com>

On Sun, 20 Dec 2020 17:05:21 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> 8080272  Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

This pull request has now been integrated.

Changeset: 68deb24b
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Julia Boes <jboes at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/68deb24b
Stats:     105 lines in 7 files changed: 3 ins; 78 del; 24 mod

8080272: Refactor I/O stream copying to use InputStream.transferTo/readAllBytes and Files.copy

Reviewed-by: mcimadamore, alanb

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

PR: https://git.openjdk.java.net/jdk/pull/1853

From aefimov at openjdk.java.net  Tue Mar 16 10:57:09 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 16 Mar 2021 10:57:09 GMT
Subject: RFR: 8263509: LdapSchemaParser.readNextTag checks array length
 incorrectly
In-Reply-To: <l0_dFxE_8RDDQwx-dKwZcQ1D6B0UH1ZV8eUNAcpZ0Ic=.fab957ad-257f-427f-a228-2afbd50a00d6@github.com>
References: <l0_dFxE_8RDDQwx-dKwZcQ1D6B0UH1ZV8eUNAcpZ0Ic=.fab957ad-257f-427f-a228-2afbd50a00d6@github.com>
Message-ID: <hO9hvInMyyAaWQB0T99xPrJEfqpB33GmnAk5AA64qKk=.fd118e59-357f-4358-8714-0a32bb526eaf@github.com>

On Fri, 12 Mar 2021 13:25:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud rightfully says:
>   The length of "values" is always ">=0", so update this test to either "==0" or ">0".
> 
>         // make sure at least one value was returned
>         if(values.length < 0) { // <--- here
>             throw new InvalidAttributeValueException("no values for " +
>                                                      "attribute "" +
>                                                      tagName + """);
>         }
> 
> There is a subsequent access to values[0], which means the failure would throw `AIOOB`, not `InvalidAttributeValueException`.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `com/sun/jndi`

Marked as reviewed by aefimov (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2968

From aefimov at openjdk.java.net  Tue Mar 16 10:57:10 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 16 Mar 2021 10:57:10 GMT
Subject: RFR: 8263509: LdapSchemaParser.readNextTag checks array length
 incorrectly
In-Reply-To: <y1ZLLvk0sE_I-iMWHUbEAj76LF2QAzTqAmEvWbSiqUs=.c1822ff0-56f1-48c0-8a54-ba17ba04d8f6@github.com>
References: <l0_dFxE_8RDDQwx-dKwZcQ1D6B0UH1ZV8eUNAcpZ0Ic=.fab957ad-257f-427f-a228-2afbd50a00d6@github.com>
 <jvFM-MYm3iBf7GdEJmjHq7WekLOtOWtS6vkp-ecLxHg=.7828375d-dab3-40fd-8d7a-6f8b4b9ed1ef@github.com>
 <y1ZLLvk0sE_I-iMWHUbEAj76LF2QAzTqAmEvWbSiqUs=.c1822ff0-56f1-48c0-8a54-ba17ba04d8f6@github.com>
Message-ID: <seOIHJiD8E7wf6uAjZv0pYXc3wNddGUKItieBlFR3T4=.347b7370-013c-428e-845b-55c0f8815a54@github.com>

On Tue, 16 Mar 2021 08:56:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Seems fine. Lets hope no caller relies on this throwing AIOOBE. 
>> 
>> ..Thomas
>
>> This looks right but I'm surprised it isn't caught by tests (@AlekseiEfimov - do you have suggests for tests that would be useful to add here?)
> 
> Can we go without adding tests here? This seems quite trivial.

Hi @shipilev,

We do not have tests for LDAP schema parser, and creating one wouldn't be trivial: environment with real LDAP server will be needed for, at least, to collect LDAP message dumps with required schema value. Therefore, I think it is reasonable to continue without a test here.

-Aleksei

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

PR: https://git.openjdk.java.net/jdk/pull/2968

From shade at openjdk.java.net  Tue Mar 16 10:57:11 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 16 Mar 2021 10:57:11 GMT
Subject: RFR: 8263509: LdapSchemaParser.readNextTag checks array length
 incorrectly
In-Reply-To: <hO9hvInMyyAaWQB0T99xPrJEfqpB33GmnAk5AA64qKk=.fd118e59-357f-4358-8714-0a32bb526eaf@github.com>
References: <l0_dFxE_8RDDQwx-dKwZcQ1D6B0UH1ZV8eUNAcpZ0Ic=.fab957ad-257f-427f-a228-2afbd50a00d6@github.com>
 <hO9hvInMyyAaWQB0T99xPrJEfqpB33GmnAk5AA64qKk=.fd118e59-357f-4358-8714-0a32bb526eaf@github.com>
Message-ID: <Lbnt_IREWLdT7hAZbkECRn-3sIBQZI8uO68xncd9kaE=.74e0be4c-72c3-4138-89fc-a9caffa46c77@github.com>

On Tue, 16 Mar 2021 10:52:25 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> SonarCloud rightfully says:
>>   The length of "values" is always ">=0", so update this test to either "==0" or ">0".
>> 
>>         // make sure at least one value was returned
>>         if(values.length < 0) { // <--- here
>>             throw new InvalidAttributeValueException("no values for " +
>>                                                      "attribute "" +
>>                                                      tagName + """);
>>         }
>> 
>> There is a subsequent access to values[0], which means the failure would throw `AIOOB`, not `InvalidAttributeValueException`.
>> 
>> Additional testing:
>>  - [x] Linux x86_64 fastdebug, `com/sun/jndi`
>
> Marked as reviewed by aefimov (Committer).

Thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/2968

From shade at openjdk.java.net  Tue Mar 16 10:57:11 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 16 Mar 2021 10:57:11 GMT
Subject: Integrated: 8263509: LdapSchemaParser.readNextTag checks array length
 incorrectly
In-Reply-To: <l0_dFxE_8RDDQwx-dKwZcQ1D6B0UH1ZV8eUNAcpZ0Ic=.fab957ad-257f-427f-a228-2afbd50a00d6@github.com>
References: <l0_dFxE_8RDDQwx-dKwZcQ1D6B0UH1ZV8eUNAcpZ0Ic=.fab957ad-257f-427f-a228-2afbd50a00d6@github.com>
Message-ID: <e_0-tlNX5TMnxZZ3w1SWG-Iy57pcaOt1K0XVX44-ulQ=.cba0f558-4aa2-4961-b9fc-cd92033bbce7@github.com>

On Fri, 12 Mar 2021 13:25:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> SonarCloud rightfully says:
>   The length of "values" is always ">=0", so update this test to either "==0" or ">0".
> 
>         // make sure at least one value was returned
>         if(values.length < 0) { // <--- here
>             throw new InvalidAttributeValueException("no values for " +
>                                                      "attribute "" +
>                                                      tagName + """);
>         }
> 
> There is a subsequent access to values[0], which means the failure would throw `AIOOB`, not `InvalidAttributeValueException`.
> 
> Additional testing:
>  - [x] Linux x86_64 fastdebug, `com/sun/jndi`

This pull request has now been integrated.

Changeset: 83a9a029
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/83a9a029
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8263509: LdapSchemaParser.readNextTag checks array length incorrectly

Reviewed-by: stuefe, aefimov

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

PR: https://git.openjdk.java.net/jdk/pull/2968

From lancea at openjdk.java.net  Tue Mar 16 11:05:07 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 16 Mar 2021 11:05:07 GMT
Subject: RFR: 8261673: Move javadoc for the lookup mechanism to module-info
In-Reply-To: <wg6xvhZiamooKkIS_HhsC0zOcFl9LN82cg3Xc_QBbqM=.b09e8950-6c4e-477d-a2b3-455eab6046f1@github.com>
References: <wg6xvhZiamooKkIS_HhsC0zOcFl9LN82cg3Xc_QBbqM=.b09e8950-6c4e-477d-a2b3-455eab6046f1@github.com>
Message-ID: <FxHvzcsniutuZysHvt6lKvX2PKhXi6b2labnrRpJoRU=.8966c5d5-2f63-4b39-b04d-baec02c43b82@github.com>

On Tue, 16 Mar 2021 00:52:24 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Consolidate and move javadoc for the lookup mechanism to the module summary.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3020

From dfuchs at openjdk.java.net  Tue Mar 16 11:17:08 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 16 Mar 2021 11:17:08 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <-0824MCtSuH7aJ_Ea4gf3Ggs5CGPSjcG6E5HS4WWuZE=.220abbbb-31d5-4ac1-9300-8621455fd285@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
 <-0824MCtSuH7aJ_Ea4gf3Ggs5CGPSjcG6E5HS4WWuZE=.220abbbb-31d5-4ac1-9300-8621455fd285@github.com>
Message-ID: <GmxIoXvFUQ7qcW_i3ZonMvHAA8eWnhoVelR_35mGXLg=.cd01c8a3-d7e9-4913-9696-48cecd0b28ae@github.com>

On Mon, 15 Mar 2021 09:35:27 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8263358: Refactored missed equals method
>
> src/java.base/share/classes/java/lang/StackTraceElement.java line 413:
> 
>> 411:                 && Objects.equals(moduleName, e.moduleName)
>> 412:                 && Objects.equals(moduleVersion, e.moduleVersion)
>> 413:                 && e.declaringClass.equals(declaringClass)
> 
> testing the declaring class and the line number should be done first given they are primitive values, it will be a little more efficient if two StackTraceElement are not equals and one is using non interned String.
>   return (obj instanceof StackTraceElement e)
>      && e.lineNumber == lineNumber
>      && e.declaringClass == declaringClass
>      && ...

Hi R?mi,
There seems to be a deeper issue here - Patrick pointed that out to me - the specification of equals above speaks of comparing class names where the actual implementation compares classes. Maybe the specification should be updated - but that would be better done in a separate issue with CSR etc... Maybe we can do the optimization you suggest at the same time?

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From plevart at openjdk.java.net  Tue Mar 16 12:22:17 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Tue, 16 Mar 2021 12:22:17 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v4]
In-Reply-To: <9DkSomkP4Sh6IE1FfQyE6DG9gcw3FlztIasU3XhtPP8=.ce3ceac2-8dac-46b2-b0b4-b100180bd362@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <l3Mvo9AR7XtaaWG3Sthfw7iOj3GnHOhzdRkP9OLwCRY=.9617e8ea-5ada-4d9a-966f-7a425952d766@github.com>
 <9DkSomkP4Sh6IE1FfQyE6DG9gcw3FlztIasU3XhtPP8=.ce3ceac2-8dac-46b2-b0b4-b100180bd362@github.com>
Message-ID: <rMoOWtGf_8-IKpbZ5UchMErqoGzi0tzaGbfMLrEbD_Q=.83f2e8c9-f1c1-4337-a586-0148c4aea50b@github.com>

On Tue, 16 Mar 2021 07:29:34 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Chris' suggested solution of avoiding deadlock
>
> Looks good to me.

Holder pattern is easier to understand, I agree. Perhaps you could just add a warning to the DynamicConstantDesc.ofCanonical() method javadoc/comment about what *NOT* to do in order to not fall into the deadlock trap again... (like: don't call this method from static initializer of ConstantDescs or such).
Otherwise it looks good to me to.

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From herrick at openjdk.java.net  Tue Mar 16 14:12:25 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 16 Mar 2021 14:12:25 GMT
Subject: RFR: JDK-8263154: [macos] DMG builds have finder errors
In-Reply-To: <MGRjyjL-6TirMFrrcU6XyOlz_aeUel-EnD0MxYySY3c=.2c554d21-6504-4e6d-8dd6-5451802f5728@github.com>
References: <q_q2hdnvfEfyo76kIREN-tRxST60tLWyUYvOh3Xipws=.9e37f1ba-fa6f-4914-94bf-fa94c5de2b47@github.com>
 <MGRjyjL-6TirMFrrcU6XyOlz_aeUel-EnD0MxYySY3c=.2c554d21-6504-4e6d-8dd6-5451802f5728@github.com>
Message-ID: <ccATyd_rqKkv2w7yl1WJabuUnBgyU1IWXliz_VkB1kg=.5ba2caef-2376-4817-be9b-ac9f6b3d6f0f@github.com>

On Mon, 15 Mar 2021 21:39:15 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> 
> 
> Can you explain what problem is and how it is fixed? Does it fails when "install-dir" is specified? "install-dir" is not relevant for DMG image and we should ignore it.

1.) The problem is, at least on Catalina, when in AppleScript you tell Finder to:
'make new alias file at POSIX file <payload path\> to POSIX file <install dir\> with properties {name:"<label to use\>"}'
if <install dir\> and <label to use\> are the same string, it fails
result is you don't see the folder icon to drag payload into.

This is where "install dir" does mater on DMG.  It is the folder the AppleScript will show in finder to suggest user to drag payload to.  By default this is "/Applications" but behavior is exactly the same if I set it to, for example, "~/LocalApplications". 
The fix only removes the leading slash from the label, so the folder will be labeled either "Applications" or (in my example) "Users/aherrick/LocalApplications".

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

PR: https://git.openjdk.java.net/jdk/pull/2987

From jpai at openjdk.java.net  Tue Mar 16 14:47:29 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 16 Mar 2021 14:47:29 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v5]
In-Reply-To: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
Message-ID: <KW2gXeCkU_TaF2Y4WMfXdTEwgVCDSFubBU1xtkw54Q0=.4124ed7d-f482-4112-aa09-443507b6c77f@github.com>

> Can I please get a review for this proposed patch for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8263108?
> 
> As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and `java.lang.constant.ConstantDescs` can end up in a classloading deadlock due to the nature of the code involved in their static blocks. A thread dump of one such deadlock (reproduced using the code attached to that issue) is as follows:
> 
> "Thread A" #14 prio=5 os_prio=31 cpu=101.45ms elapsed=8.30s tid=0x00007ff88e01ca00 nid=0x6003 in Object.wait()  [0x000070000a4c6000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.constant.DynamicConstantDesc.<clinit>(java.base at 16-ea/DynamicConstantDesc.java:67)
> 	- waiting on the Class initialization monitor for java.lang.constant.ConstantDescs
> 	at Deadlock.threadA(Deadlock.java:14)
> 	at Deadlock$$Lambda$1/0x0000000800c00a08.run(Unknown Source)
> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
> 
> "Thread B" #15 prio=5 os_prio=31 cpu=103.15ms elapsed=8.30s tid=0x00007ff88b936a00 nid=0x9b03 in Object.wait()  [0x000070000a5c9000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.constant.ClassDesc.ofDescriptor(java.base at 16-ea/ClassDesc.java:145)
> 	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc
> 	at java.lang.constant.ConstantDescs.<clinit>(java.base at 16-ea/ConstantDescs.java:239)
> 	at Deadlock.threadB(Deadlock.java:24)
> 	at Deadlock$$Lambda$2/0x0000000800c00c28.run(Unknown Source)
> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
> 
> The commit in this PR resolves that deadlock by moving the `canonicalMap` initialization in `DynamicConstantDesc`, from the static block, to a lazily initialized map, into the `tryCanonicalize` (private) method of the same class. That's the only method which uses this map.
> 
> The implementation in `tryCanonicalize` carefully ensures that the deadlock isn't shifted from the static block to this method, by making sure that the `synchronization` on `DynamicConstantDesc` in this method happens only when it's time to write the state to the shared `canonicalMap`. This has an implication that the method local variable `canonDescs` can get initialized by multiple threads unnecessarily but from what I can see, that's the only way we can avoid this deadlock. This penalty of multiple threads initializing and then throwing away that map isn't too huge because that will happen only once when the `canonicalMap` is being initialized for the first time.
> 
> An alternate approach that I thought of was to completely get rid of this shared cache `canonicalMap` and instead just use method level map (that gets initialized each time) in the `tryCanonicalize` method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.
> 
> The commit in this PR also includes a jtreg testcase which (consistently) reproduces the deadlock without the fix and passes when this fix is applied. Extra manual testing has been done to verify that the classes of interest (noted in that testcase) are indeed getting loaded in those concurrent threads and not in the main thread. For future maintainers, there's a implementation note added on that testcase explaining why it cannot be moved into testng test.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Add a comment to instruct future maintainers of the code to avoid calling DynamicConstantDesc.ofCanonical() from static initialization of java.lang.constant.ConstantDescs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2893/files
  - new: https://git.openjdk.java.net/jdk/pull/2893/files/3b8e4a5d..ed8a3045

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2893&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2893&range=03-04

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From jpai at openjdk.java.net  Tue Mar 16 14:50:07 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Tue, 16 Mar 2021 14:50:07 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v4]
In-Reply-To: <rMoOWtGf_8-IKpbZ5UchMErqoGzi0tzaGbfMLrEbD_Q=.83f2e8c9-f1c1-4337-a586-0148c4aea50b@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <l3Mvo9AR7XtaaWG3Sthfw7iOj3GnHOhzdRkP9OLwCRY=.9617e8ea-5ada-4d9a-966f-7a425952d766@github.com>
 <9DkSomkP4Sh6IE1FfQyE6DG9gcw3FlztIasU3XhtPP8=.ce3ceac2-8dac-46b2-b0b4-b100180bd362@github.com>
 <rMoOWtGf_8-IKpbZ5UchMErqoGzi0tzaGbfMLrEbD_Q=.83f2e8c9-f1c1-4337-a586-0148c4aea50b@github.com>
Message-ID: <DheutRu-alUZBIumnaJP_W8W48cN1A7Bzv7ti1JCpj0=.de74bdfd-bc0d-49a5-a6eb-264b8b507c8a@github.com>

On Tue, 16 Mar 2021 12:19:11 GMT, Peter Levart <plevart at openjdk.org> wrote:

> Perhaps you could just add a warning to the DynamicConstantDesc.ofCanonical() method javadoc/comment about what NOT to do in order to not fall into the deadlock trap again... (like: don't call this method from static initializer of ConstantDescs or such).

I think that's a good idea. I went ahead and added a regular comment at the top of that method to warn about this potential deadlock. I decided not to use a javadoc comment since IMO, this is too much of an internal implementation detail to end up being part of the javadoc.

I ran `make docs-jdk` after this change just to sure this comment doesn't cause any javadoc generation failures. The build went fine and the generated javadoc isn't impacted.

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From redestad at openjdk.java.net  Tue Mar 16 14:59:09 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 16 Mar 2021 14:59:09 GMT
Subject: RFR: 8263450: Simplify LambdaForm.useCount
In-Reply-To: <XR2_eJfQpR4tjdw0N3lbXKLwjPqoEmQNM0KhvV8mSB8=.38ba345f-a010-40d2-8c74-8681896fc4ba@github.com>
References: <u8_H4ZrBp-U0QfsWEHgaLZnlWGer-W_85UroyWbTSzY=.72bfdc0e-6cf3-408d-b3ef-c924801b522c@github.com>
 <XR2_eJfQpR4tjdw0N3lbXKLwjPqoEmQNM0KhvV8mSB8=.38ba345f-a010-40d2-8c74-8681896fc4ba@github.com>
Message-ID: <tdUSm8zHZOj6YMhVFqM1LVh1HWQ7b7dZMzHMBPYThjQ=.8e0c255a-b099-436d-a10f-095b35c68fb8@github.com>

On Mon, 15 Mar 2021 15:29:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Simplify useCount and avoid calling lastUseIndex for a small startup win.
>
> Marked as reviewed by rriggs (Reviewer).

Thanks, Roger!

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

PR: https://git.openjdk.java.net/jdk/pull/2940

From redestad at openjdk.java.net  Tue Mar 16 14:59:10 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 16 Mar 2021 14:59:10 GMT
Subject: Integrated: 8263450: Simplify LambdaForm.useCount
In-Reply-To: <u8_H4ZrBp-U0QfsWEHgaLZnlWGer-W_85UroyWbTSzY=.72bfdc0e-6cf3-408d-b3ef-c924801b522c@github.com>
References: <u8_H4ZrBp-U0QfsWEHgaLZnlWGer-W_85UroyWbTSzY=.72bfdc0e-6cf3-408d-b3ef-c924801b522c@github.com>
Message-ID: <Yr-75iZe38TANMTcZkf4lPudTO3SRW0baKmU2TQIIB0=.711e8033-5add-474b-bc1c-fa03380d3aed@github.com>

On Thu, 11 Mar 2021 14:50:46 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Simplify useCount and avoid calling lastUseIndex for a small startup win.

This pull request has now been integrated.

Changeset: e33bfb39
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e33bfb39
Stats:     16 lines in 1 file changed: 4 ins; 6 del; 6 mod

8263450: Simplify LambdaForm.useCount

Reviewed-by: rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/2940

From alanb at openjdk.java.net  Tue Mar 16 15:36:08 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 16 Mar 2021 15:36:08 GMT
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM
In-Reply-To: <w7vA_cJ9W2ibNeh_wG5rImAhCC_LWS2oUdypz1mrehY=.9d2ff66e-87fe-4602-8dbe-ae155d8c3fb5@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
 <acZoevVQtNOwkvpYhhWU6sx2Rh1K7bnAxVKRRZrTykQ=.73760624-f0f2-495a-b6e4-4e5639896a0d@github.com>
 <w7vA_cJ9W2ibNeh_wG5rImAhCC_LWS2oUdypz1mrehY=.9d2ff66e-87fe-4602-8dbe-ae155d8c3fb5@github.com>
Message-ID: <m50f_ObBCNHRlAqsv8QjTyYfpUHkshCZCEUsZdpcCYk=.6eb47d59-e698-47b4-9a07-0f8f8dc98bb0@github.com>

On Tue, 16 Mar 2021 07:43:54 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This bug is similar to https://bugs.openjdk.java.net/browse/JDK-8076264, and the fix looks fine.
>
>> Maybe the AWT folk should decide what name should be displayed in this
>> case. The canonical name was chosen when all main classes had to have a
>> canonical name. So perhaps a simple name will suffice in the case where
>> there is no canonical name?
> 
> This is not the last attempt to set the name, the JAVA_MAIN_CLASS_ variable is used in the middle of the name selection, there are some others. And the "bin" is selected by some of the next step, I agree it is not a friendly name that could be improved.

Using an anonymous class for the main class looks strange and hard to believe anyone is relying on this.  I wonder if we should do more checking LauncherHelper.validateMainClass to reject cases like this.

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

PR: https://git.openjdk.java.net/jdk/pull/2999

From asemenyuk at openjdk.java.net  Tue Mar 16 16:21:09 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 16 Mar 2021 16:21:09 GMT
Subject: RFR: 8263536: Add @compile tags to jpackage tests [v2]
In-Reply-To: <NN2VbTlYGgLa52X1UG9sm0jiVVn2yBjbVSJl3TqvR6k=.627b7859-166d-4fa9-96c3-09d4a68444bf@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
 <ooB29iVuRdxt3fLeso4Sv-z2Ob6gFpgnUqY2_DWkNs4=.f7939815-271f-4367-9dbc-229ba2076183@github.com>
 <_A2MzMPm-ueagZbFm1_ea9c5uKJNKU1pqzmq3SQPCnQ=.0440bf7d-a5b2-4aa9-a35a-18085c70e4f6@github.com>
 <TVizGxORmaXh0pOuFOHRpF-cqYmBDMkw0QBHu0Ii9zo=.59624f2e-af36-4b57-b77a-042b17347119@github.com>
 <9V48WPCaQyZKB4Pr42mLfZ9dpByojVUH9gjjF-sicdw=.afa77515-e84d-44eb-84b5-43be04491f73@github.com>
 <NN2VbTlYGgLa52X1UG9sm0jiVVn2yBjbVSJl3TqvR6k=.627b7859-166d-4fa9-96c3-09d4a68444bf@github.com>
Message-ID: <ZofE2D5up3Fq8Uj3LKt_QSMbsuDl6Rfgz6lb7gR5fgM=.13c8fc06-ef37-4018-8127-0edcf914aa89@github.com>

On Mon, 15 Mar 2021 20:02:02 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> @compile will always run javac every time you run the test
Didn't know that. Thank you for explanation. Would this be OK to leave `@compile` tags?

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

PR: https://git.openjdk.java.net/jdk/pull/2975

From iklam at openjdk.java.net  Tue Mar 16 16:42:10 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 16 Mar 2021 16:42:10 GMT
Subject: RFR: 8263536: Add @compile tags to jpackage tests [v2]
In-Reply-To: <ZofE2D5up3Fq8Uj3LKt_QSMbsuDl6Rfgz6lb7gR5fgM=.13c8fc06-ef37-4018-8127-0edcf914aa89@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
 <ooB29iVuRdxt3fLeso4Sv-z2Ob6gFpgnUqY2_DWkNs4=.f7939815-271f-4367-9dbc-229ba2076183@github.com>
 <_A2MzMPm-ueagZbFm1_ea9c5uKJNKU1pqzmq3SQPCnQ=.0440bf7d-a5b2-4aa9-a35a-18085c70e4f6@github.com>
 <TVizGxORmaXh0pOuFOHRpF-cqYmBDMkw0QBHu0Ii9zo=.59624f2e-af36-4b57-b77a-042b17347119@github.com>
 <9V48WPCaQyZKB4Pr42mLfZ9dpByojVUH9gjjF-sicdw=.afa77515-e84d-44eb-84b5-43be04491f73@github.com>
 <NN2VbTlYGgLa52X1UG9sm0jiVVn2yBjbVSJl3TqvR6k=.627b7859-166d-4fa9-96c3-09d4a68444bf@github.com>
 <ZofE2D5up3Fq8Uj3LKt_QSMbsuDl6Rfgz6lb7gR5fgM=.13c8fc06-ef37-4018-8127-0edcf914aa89@github.com>
Message-ID: <88Vs1KlAD4jMMBttKkwX1cOc3pyb7zWQDiIFBQairAE=.ff346537-ccce-4e8d-923e-82d48c5452dc@github.com>

On Tue, 16 Mar 2021 16:18:48 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> > @compile will always run javac every time you run the test
> > Didn't know that. Thank you for explanation. Would this be OK to leave `@compile` tags?

Since you're making changes, I think we should do it correctly. We should use `@build` tags.

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

PR: https://git.openjdk.java.net/jdk/pull/2975

From naoto at openjdk.java.net  Tue Mar 16 17:07:10 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 16 Mar 2021 17:07:10 GMT
Subject: RFR: 8261673: Move javadoc for the lookup mechanism to module-info
In-Reply-To: <wg6xvhZiamooKkIS_HhsC0zOcFl9LN82cg3Xc_QBbqM=.b09e8950-6c4e-477d-a2b3-455eab6046f1@github.com>
References: <wg6xvhZiamooKkIS_HhsC0zOcFl9LN82cg3Xc_QBbqM=.b09e8950-6c4e-477d-a2b3-455eab6046f1@github.com>
Message-ID: <17rIuXpaCfuUKn6CGIvX_TE4_JKiiOAq_E4HwMeZq0Y=.3fbdcf9d-a76f-4541-a314-05bffcc5aa9b@github.com>

On Tue, 16 Mar 2021 00:52:24 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Consolidate and move javadoc for the lookup mechanism to the module summary.

src/java.xml/share/classes/javax/xml/stream/XMLInputFactory.java line 172:

> 170:    * Creates a new instance of the factory. This method uses the
> 171:    * <a href="../../../module-summary.html#LookupMechanism">JAXP Lookup Mechanism</a>
> 172:    * to determine the {@code XMLEventFactory} implementation class to load.

Should it be `XMLInputFactory`?

src/java.xml/share/classes/javax/xml/stream/XMLOutputFactory.java line 149:

> 147:    * Creates a new instance of the factory. This method uses the
> 148:    * <a href="../../../module-summary.html#LookupMechanism">JAXP Lookup Mechanism</a>
> 149:    * to determine the {@code XMLEventFactory} implementation class to load.

And this one as `XMLOutputFactory`?

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

PR: https://git.openjdk.java.net/jdk/pull/3020

From mchung at openjdk.java.net  Tue Mar 16 17:28:10 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 16 Mar 2021 17:28:10 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <GmxIoXvFUQ7qcW_i3ZonMvHAA8eWnhoVelR_35mGXLg=.cd01c8a3-d7e9-4913-9696-48cecd0b28ae@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
 <-0824MCtSuH7aJ_Ea4gf3Ggs5CGPSjcG6E5HS4WWuZE=.220abbbb-31d5-4ac1-9300-8621455fd285@github.com>
 <GmxIoXvFUQ7qcW_i3ZonMvHAA8eWnhoVelR_35mGXLg=.cd01c8a3-d7e9-4913-9696-48cecd0b28ae@github.com>
Message-ID: <y0Y_kY5l8LzhG1SkFDu-9T2Po1KB-DUIbk2QvhVOUJA=.0de08a0a-7ed6-4ec1-ae0c-85ad0493b787@github.com>

On Tue, 16 Mar 2021 11:13:50 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StackTraceElement.java line 413:
>> 
>>> 411:                 && Objects.equals(moduleName, e.moduleName)
>>> 412:                 && Objects.equals(moduleVersion, e.moduleVersion)
>>> 413:                 && e.declaringClass.equals(declaringClass)
>> 
>> testing the declaring class and the line number should be done first given they are primitive values, it will be a little more efficient if two StackTraceElement are not equals and one is using non interned String.
>>   return (obj instanceof StackTraceElement e)
>>      && e.lineNumber == lineNumber
>>      && e.declaringClass == declaringClass
>>      && ...
>
> Hi R?mi,
> There seems to be a deeper issue here - Patrick pointed that out to me - the specification of equals above speaks of comparing class names where the actual implementation compares classes. Maybe the specification should be updated - but that would be better done in a separate issue with CSR etc... Maybe we can do the optimization you suggest at the same time?

`declaringClass` is a string representing the class name (not the `Class` object).   The variable name indeed causes confusion.

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From herrick at openjdk.java.net  Tue Mar 16 17:30:10 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 16 Mar 2021 17:30:10 GMT
Subject: Integrated: JDK-8248904: Add support to jpackage for the Mac App Store
In-Reply-To: <Mr21WO6EZtgspQn31renDqAMna0HsTL8dlsnzPbnvas=.ad65953e-853f-454d-9689-a15d1a6a992e@github.com>
References: <Mr21WO6EZtgspQn31renDqAMna0HsTL8dlsnzPbnvas=.ad65953e-853f-454d-9689-a15d1a6a992e@github.com>
Message-ID: <cneSSkcmc4q_q0s6_bmnxBS_f8I4H-jNu1HJ6RTTmI4=.bec0eadd-b763-4a08-a840-8ae7bc4d1fc8@github.com>

On Wed, 24 Feb 2021 21:59:22 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Implementation of Mac App Support including three new mac specific CLI options.

This pull request has now been integrated.

Changeset: 11c8c78c
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/11c8c78c
Stats:     310 lines in 23 files changed: 205 ins; 41 del; 64 mod

8248904: Add support to jpackage for the Mac App Store

Reviewed-by: asemenyuk, almatvee, kizune, kcr

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

PR: https://git.openjdk.java.net/jdk/pull/2716

From darcy at openjdk.java.net  Tue Mar 16 17:31:12 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 16 Mar 2021 17:31:12 GMT
Subject: RFR: 8262807: Note assumptions of core reflection modeling and
 parameter handling
Message-ID: <ae56zoC6twGvS0nhTEk_6G41yGfaHHUYV_Wx1V1hdYc=.a1d4a49c-38e4-4ef2-8b7b-f3fb1814fb56@github.com>

Please review the javadoc change below, written in response to recent discussion on core-libs.

The bulk of the change is to add a discussion to java.lang.reflect's package-info file about a language vs JVM model for core reflection. That discussion is then linked to from several relevant locations core reflection. A discussion of generic parameter handling is also added along with various small cleanups.

I'll update copyright, etc. after agreement on the text is reached.

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

Commit messages:
 - Appease jcheck.
 - 8262807: Note assumptions of core reflection modeling and parameter handling

Changes: https://git.openjdk.java.net/jdk/pull/3036/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3036&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262807
  Stats: 90 lines in 4 files changed: 69 ins; 6 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3036.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3036/head:pull/3036

PR: https://git.openjdk.java.net/jdk/pull/3036

From henryjen at openjdk.java.net  Tue Mar 16 17:42:08 2021
From: henryjen at openjdk.java.net (Henry Jen)
Date: Tue, 16 Mar 2021 17:42:08 GMT
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM
In-Reply-To: <yFP3B1qIjH9bc7sz1rO9lRs3nQTQN8SIIxXISpd9DoI=.4f15814e-f0e4-48d4-8fb5-e35648e79dd8@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
 <yFP3B1qIjH9bc7sz1rO9lRs3nQTQN8SIIxXISpd9DoI=.4f15814e-f0e4-48d4-8fb5-e35648e79dd8@github.com>
Message-ID: <UbPmMkt7hUiwg18X1MF9WG2oAXK3wUAJgSiIbd71OEo=.6a1f3676-aedd-4cf8-a9f1-be73e26159d5@github.com>

On Tue, 16 Mar 2021 01:59:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS.
>> 
>> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the launcher trying to grab class name to be displayed as the Application name on the menu.
>> 
>> The fix is to not setting name, test shows that GUI java application shows 'bin' as the application name. It's possible for us to set the name to something more friendly, for example, "Java", but I am not sure that should be launcher's responsibility to choose such a default name. It seems to me the consumer of the JAVA_MAIN_CLASS_%d environment variable should be responsible to pick such name in case the environment variable is not set.
>
> test/jdk/tools/launcher/8261785/CrashTheJVM.java line 1:
> 
>> 1: import java.io.IOException;
> 
> Copyright?

This file is mostly based on the bug report as I just adjust static keyword to make sure we cover different cases, thus I am not sure whether to add copyright or not.

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

PR: https://git.openjdk.java.net/jdk/pull/2999

From asemenyuk at openjdk.java.net  Tue Mar 16 17:50:26 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 16 Mar 2021 17:50:26 GMT
Subject: RFR: 8263536: Add @build tags to jpackage tests [v3]
In-Reply-To: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
Message-ID: <iH52W7E_kDAEfCedDGEEEcAlfTp74MZtgxZirjK49nk=.8eafdde3-527f-495d-86c0-2db3fa92a327@github.com>

> 8263536: Add @build tags to jpackage tests

Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8263536: Add @build tags to jpackage tests

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2975/files
  - new: https://git.openjdk.java.net/jdk/pull/2975/files/34960c62..537d407a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2975&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2975&range=01-02

  Stats: 26 lines in 13 files changed: 13 ins; 13 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2975.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2975/head:pull/2975

PR: https://git.openjdk.java.net/jdk/pull/2975

From henryjen at openjdk.java.net  Tue Mar 16 17:52:08 2021
From: henryjen at openjdk.java.net (Henry Jen)
Date: Tue, 16 Mar 2021 17:52:08 GMT
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM
In-Reply-To: <m50f_ObBCNHRlAqsv8QjTyYfpUHkshCZCEUsZdpcCYk=.6eb47d59-e698-47b4-9a07-0f8f8dc98bb0@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
 <acZoevVQtNOwkvpYhhWU6sx2Rh1K7bnAxVKRRZrTykQ=.73760624-f0f2-495a-b6e4-4e5639896a0d@github.com>
 <w7vA_cJ9W2ibNeh_wG5rImAhCC_LWS2oUdypz1mrehY=.9d2ff66e-87fe-4602-8dbe-ae155d8c3fb5@github.com>
 <m50f_ObBCNHRlAqsv8QjTyYfpUHkshCZCEUsZdpcCYk=.6eb47d59-e698-47b4-9a07-0f8f8dc98bb0@github.com>
Message-ID: <4Y_dUFl3dSRd0X7ateyN1REIuBROwnA1_iPey9bkkc4=.c90dce28-515a-4b69-8966-25d50a281394@github.com>

On Tue, 16 Mar 2021 15:33:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Using an anonymous class for the main class looks strange and hard to believe anyone is relying on this. I wonder if we should do more checking LauncherHelper.validateMainClass to reject cases like this.

I raised that same question, and people tends to agree launcher could reject anonymous/local classes. But pointed out that should require a CSR review. Therefore I chose to  fix crash first, and we can file another ticket to address main class requirements.

> This is not the last attempt to set the name, the JAVA_MAIN_CLASS_ variable is used in the middle of the name selection, there are some others. And the "bin" is selected by some of the next step, I agree it is not a friendly name that could be improved.

I tried to do a quick search on JAVA_MAIN_CLASS_%pid variable, didn't find other code to set this. I had a version that would set the variable to "Java", I can extend that to cover exception case as well.

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

PR: https://git.openjdk.java.net/jdk/pull/2999

From henryjen at openjdk.java.net  Tue Mar 16 17:57:30 2021
From: henryjen at openjdk.java.net (Henry Jen)
Date: Tue, 16 Mar 2021 17:57:30 GMT
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM [v2]
In-Reply-To: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
Message-ID: <a3oSEhQpTvjt_POhFKab74dyU-3kHAdYn_vUb1RcrEA=.28114188-a4b1-4688-96f7-ec68d504e7fb@github.com>

> This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS.
> 
> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the launcher trying to grab class name to be displayed as the Application name on the menu.
> 
> The fix is to not setting name, test shows that GUI java application shows 'bin' as the application name. It's possible for us to set the name to something more friendly, for example, "Java", but I am not sure that should be launcher's responsibility to choose such a default name. It seems to me the consumer of the JAVA_MAIN_CLASS_%d environment variable should be responsible to pick such name in case the environment variable is not set.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Adjust width used for Copyright

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2999/files
  - new: https://git.openjdk.java.net/jdk/pull/2999/files/0fdea41c..58f197f4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2999&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2999&range=00-01

  Stats: 15 lines in 1 file changed: 3 ins; 0 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2999.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2999/head:pull/2999

PR: https://git.openjdk.java.net/jdk/pull/2999

From iklam at openjdk.java.net  Tue Mar 16 18:40:08 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Tue, 16 Mar 2021 18:40:08 GMT
Subject: RFR: 8263536: Add @build tags to jpackage tests [v3]
In-Reply-To: <iH52W7E_kDAEfCedDGEEEcAlfTp74MZtgxZirjK49nk=.8eafdde3-527f-495d-86c0-2db3fa92a327@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
 <iH52W7E_kDAEfCedDGEEEcAlfTp74MZtgxZirjK49nk=.8eafdde3-527f-495d-86c0-2db3fa92a327@github.com>
Message-ID: <DpPjzuYVrvq-3Szw6nzUxzWEvCwATBsd9uHp3gjrYjU=.c7f256e4-8677-4477-a1da-df52232b14ef@github.com>

On Tue, 16 Mar 2021 17:50:26 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> 8263536: Add @build tags to jpackage tests
>
> Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Marked as reviewed by iklam (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2975

From herrick at openjdk.java.net  Tue Mar 16 18:59:14 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 16 Mar 2021 18:59:14 GMT
Subject: RFR: 8263536: Add @build tags to jpackage tests [v3]
In-Reply-To: <iH52W7E_kDAEfCedDGEEEcAlfTp74MZtgxZirjK49nk=.8eafdde3-527f-495d-86c0-2db3fa92a327@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
 <iH52W7E_kDAEfCedDGEEEcAlfTp74MZtgxZirjK49nk=.8eafdde3-527f-495d-86c0-2db3fa92a327@github.com>
Message-ID: <CS0rEIZVMxlCmQig8op0bFYb0_Qi7Pu9NSoE87_jbh8=.f9c3932e-63e0-47dd-9656-ce0867d64d40@github.com>

On Tue, 16 Mar 2021 17:50:26 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> 8263536: Add @build tags to jpackage tests
>
> Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

could update the copyrights at the same time, but OK.

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

Marked as reviewed by herrick (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2975

From asemenyuk at openjdk.java.net  Tue Mar 16 19:18:08 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 16 Mar 2021 19:18:08 GMT
Subject: Integrated: 8263536: Add @build tags to jpackage tests
In-Reply-To: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
References: <WyLXgAPHFmgwqsqo59nmxjaea24fXqOFUx8Gxk2vsnc=.6fa223be-2823-48c4-85b5-7aafb12fbed7@github.com>
Message-ID: <bcfSMdrt6AFk1T_3d0ivkcSzqbiVbMfgU7IFIA-NLjY=.b0156140-d04c-48df-a11d-d76d8f4df491@github.com>

On Fri, 12 Mar 2021 17:52:30 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8263536: Add @build tags to jpackage tests

This pull request has now been integrated.

Changeset: 422eba81
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/422eba81
Stats:     15 lines in 14 files changed: 13 ins; 2 del; 0 mod

8263536: Add @build tags to jpackage tests

Reviewed-by: almatvee, iklam, herrick

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

PR: https://git.openjdk.java.net/jdk/pull/2975

From dfuchs at openjdk.java.net  Tue Mar 16 19:29:07 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 16 Mar 2021 19:29:07 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <y0Y_kY5l8LzhG1SkFDu-9T2Po1KB-DUIbk2QvhVOUJA=.0de08a0a-7ed6-4ec1-ae0c-85ad0493b787@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
 <-0824MCtSuH7aJ_Ea4gf3Ggs5CGPSjcG6E5HS4WWuZE=.220abbbb-31d5-4ac1-9300-8621455fd285@github.com>
 <GmxIoXvFUQ7qcW_i3ZonMvHAA8eWnhoVelR_35mGXLg=.cd01c8a3-d7e9-4913-9696-48cecd0b28ae@github.com>
 <y0Y_kY5l8LzhG1SkFDu-9T2Po1KB-DUIbk2QvhVOUJA=.0de08a0a-7ed6-4ec1-ae0c-85ad0493b787@github.com>
Message-ID: <kiOUpebha_W79n4KwsMJaNPyNwtP2Oirq1eEyU6UGtI=.c1a64a0a-3491-4a96-b644-42d62a157912@github.com>

On Tue, 16 Mar 2021 17:24:56 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Hi R?mi,
>> There seems to be a deeper issue here - Patrick pointed that out to me - the specification of equals above speaks of comparing class names where the actual implementation compares classes. Maybe the specification should be updated - but that would be better done in a separate issue with CSR etc... Maybe we can do the optimization you suggest at the same time?
>
> `declaringClass` is a string representing the class name (not the `Class` object).   The variable name indeed causes confusion.

Doh. My mistake. Was thinking about `StackFrame`. Thanks Mandy!

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

PR: https://git.openjdk.java.net/jdk/pull/2913

From serb at openjdk.java.net  Tue Mar 16 19:45:07 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Tue, 16 Mar 2021 19:45:07 GMT
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM [v2]
In-Reply-To: <UbPmMkt7hUiwg18X1MF9WG2oAXK3wUAJgSiIbd71OEo=.6a1f3676-aedd-4cf8-a9f1-be73e26159d5@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
 <yFP3B1qIjH9bc7sz1rO9lRs3nQTQN8SIIxXISpd9DoI=.4f15814e-f0e4-48d4-8fb5-e35648e79dd8@github.com>
 <UbPmMkt7hUiwg18X1MF9WG2oAXK3wUAJgSiIbd71OEo=.6a1f3676-aedd-4cf8-a9f1-be73e26159d5@github.com>
Message-ID: <7iSWGGru9wL-6fDuAcDZ2IKuBtglnbYX5GRY2rPrmAQ=.7cd19dd9-a819-45ec-b7c0-35ee7a6407a6@github.com>

On Tue, 16 Mar 2021 17:39:34 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> test/jdk/tools/launcher/8261785/CrashTheJVM.java line 1:
>> 
>>> 1: import java.io.IOException;
>> 
>> Copyright?
>
> This file is mostly based on the bug report as I just adjust static keyword to make sure we cover different cases, thus I am not sure whether to add copyright or not.

you need to clarify this, if we cannot add copyright here, we should not use this file.

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

PR: https://git.openjdk.java.net/jdk/pull/2999

From rriggs at openjdk.java.net  Tue Mar 16 20:08:08 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 16 Mar 2021 20:08:08 GMT
Subject: RFR: 8262807: Note assumptions of core reflection modeling and
 parameter handling
In-Reply-To: <ae56zoC6twGvS0nhTEk_6G41yGfaHHUYV_Wx1V1hdYc=.a1d4a49c-38e4-4ef2-8b7b-f3fb1814fb56@github.com>
References: <ae56zoC6twGvS0nhTEk_6G41yGfaHHUYV_Wx1V1hdYc=.a1d4a49c-38e4-4ef2-8b7b-f3fb1814fb56@github.com>
Message-ID: <EhcZzW74aa0JeDCqAziNhg1WMZ0prJRn1v6cHZjIS7s=.04c9f10b-b703-428e-8a59-0a32029aa638@github.com>

On Tue, 16 Mar 2021 17:22:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review the javadoc change below, written in response to recent discussion on core-libs.
> 
> The bulk of the change is to add a discussion to java.lang.reflect's package-info file about a language vs JVM model for core reflection. That discussion is then linked to from several relevant locations core reflection. A discussion of generic parameter handling is also added along with various small cleanups.
> 
> I'll update copyright, etc. after agreement on the text is reached.

src/java.base/share/classes/java/lang/reflect/package-info.java line 79:

> 77:  * differ from the modifiers on the originating element in the source
> 78:  * language, including {@link Modifier#FINAL final} on a {@linkplain
> 79:  * Parameter#getModifiers() parameter} and and {@code protected},

and and  -> "and"

src/java.base/share/classes/java/lang/reflect/package-info.java line 85:

> 83:  * <p>Besides differences in structural representation between the
> 84:  * source language and the JVM representation, core reflection also
> 85:  * exposed runtime specific information. For example, the {@linkplain

exposed -> exposes

src/java.base/share/classes/java/lang/reflect/Executable.java line 262:

> 260:      * Returns an array of {@code Type} objects that represent the
> 261:      * formal parameter types, in declaration order, of the executable
> 262:      * represented by this object. Returns an array of length 0 if the

Missing subject of the sentence?  "This method returns"...
Or "An array of length 0 is returned"...

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

PR: https://git.openjdk.java.net/jdk/pull/3036

From darcy at openjdk.java.net  Tue Mar 16 20:41:24 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 16 Mar 2021 20:41:24 GMT
Subject: RFR: 8262807: Note assumptions of core reflection modeling and
 parameter handling [v2]
In-Reply-To: <ae56zoC6twGvS0nhTEk_6G41yGfaHHUYV_Wx1V1hdYc=.a1d4a49c-38e4-4ef2-8b7b-f3fb1814fb56@github.com>
References: <ae56zoC6twGvS0nhTEk_6G41yGfaHHUYV_Wx1V1hdYc=.a1d4a49c-38e4-4ef2-8b7b-f3fb1814fb56@github.com>
Message-ID: <8LziHw1I6zHCX27JKe5ax1Oz73pR3SPDYAzlDRmyHbg=.3ea70358-ff86-4dca-9022-3604523924b1@github.com>

> Please review the javadoc change below, written in response to recent discussion on core-libs.
> 
> The bulk of the change is to add a discussion to java.lang.reflect's package-info file about a language vs JVM model for core reflection. That discussion is then linked to from several relevant locations core reflection. A discussion of generic parameter handling is also added along with various small cleanups.
> 
> I'll update copyright, etc. after agreement on the text is reached.

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.java.net/jdk/pull/3036/files
  - new: https://git.openjdk.java.net/jdk/pull/3036/files/74b2bd59..3f102171

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3036&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3036&range=00-01

  Stats: 19 lines in 3 files changed: 0 ins; 9 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3036.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3036/head:pull/3036

PR: https://git.openjdk.java.net/jdk/pull/3036

From github.com+160684+tommyettinger at openjdk.java.net  Tue Mar 16 21:04:12 2021
From: github.com+160684+tommyettinger at openjdk.java.net (Tommy Ettinger)
Date: Tue, 16 Mar 2021 21:04:12 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <mjjAAlWx7OAPh-tkaRdXqBzlVqmEvtR9dWEZ1JS11O8=.fab27b0a-81bd-4ea6-9e17-3a9fb50bf250@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <8dxwtqYBhApNqL8YPdxd7DD2vSCh4l7Uty-yC5GQL1k=.c46a32df-87db-4bdb-a741-3a576061fbb8@github.com>
 <eQMIbyH4Iuhv5awo3y8hrVFFIQ3mle3fT5yc3uq9vSE=.3fc66dcc-79e8-4a55-9e0f-cca6242ecad1@github.com>
 <56ArMzotFOIbGr5mG6B-2PuwSh7I2gTbdcduv1GimdY=.108e2245-2423-4888-8409-262ec17481c5@github.com>
 <mjjAAlWx7OAPh-tkaRdXqBzlVqmEvtR9dWEZ1JS11O8=.fab27b0a-81bd-4ea6-9e17-3a9fb50bf250@github.com>
Message-ID: <O4jMMzjrPSRXP5Yiqng6qmelNqpyKwyVz1ihebhfnDA=.a463dc84-da83-40d5-9ae2-c6f0b69b6a3e@github.com>

On Mon, 15 Mar 2021 20:45:30 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> I still don't like the fact that the factory uses reflection but i don't see how to do better
>
> This is now looking very nicely structured.
> 
> The only thing i am unsure are the details around `RandomGenerator` being a service provider interface. The documentation mentions this at various points (mostly as implementation notes), but it's not really called out on `RandomGenerator`. 
> 
> Trying out the patch, I can implement `RandomGenerator` and register it as a service:
> 
> public class AlwaysZero implements RandomGenerator {
>     @Override
>     public long nextLong() {
>         return 0;
>     }
> }
> ...
>         RandomGenerator alwaysZero = RandomGenerator.of("AlwaysZero");
>  
> 
> Is that intended? (esp. since the annotation `RandomGeneratorProperties` is not public). If i rename the above to `L32X64MixRandom` an `ExceptionInInitializerError` is produced due to duplicate keys.
> 
> I suspect you want to filter out the service providers to those that only declare `RandomGeneratorProperties`, thereby restricting to providers only supplied by the platform.

Has anyone here benchmarked this? I've run BumbleBench benchmarks (one of the AdoptOpenJDK team's tools, [available here](https://github.com/adoptium/bumblebench)) and I'm skeptical of the original claims in [JEP 356](https://openjdk.java.net/jeps/356), namely:

> ...a new class of splittable PRNG algorithms (LXM) has also been discovered that are almost as fast [as SplittableRandom]...

On my machine, L64X128MixRandom's algorithm is 53% slower than SplittableRandom, a halving in performance that I think would be inaccurate to describe as "almost as fast." I've benchmarked on Java 8 HotSpot (Windows 10, x64) and Java 15 OpenJ9 (same machine). On HotSpot, which I think is the main concern, I go from 1021770880 (over 1 billion) random longs per second with SplittableRandom to 479769280 (over 479 million) with my (I believe faithful) implementation of L64X128MixRandom. That is where I observed the 53% reduction. While SplittableRandom specifically seems to perform relatively badly on OpenJ9, with 893283072 longs per second (893 million), other similar random number generators do extremely well on OpenJ9; [LaserRandom](https://github.com/tommyettinger/jdkgdxds/blob/master/src/main/java/com/github/tommyettinger/ds/support/LaserRandom.java) generates 4232752128 random longs per second (4.2 billion) where L64X128MixRandom gets 840015872 (840 million). My benchmark repo is a
  mess, but if anyone wants to see and verify, [here it is](https://github.com/tommyettinger/assorted-benchmarks/tree/master/src/main/java/net/adoptopenjdk/bumblebench/examples). JMH benchmarks might provide different or just additional useful information; I've only run BumbleBench.

One could make the argument that getting a random long from a PRNG takes so little time in the first place that it is unlikely to be a bottleneck, and by that logic, LXM is "almost as fast." However, if random generation is not being called often enough for its speed to matter, you are exceedingly unlikely to need so many (over 9 quintillion) parallel streams or such a long period per stream ((2 to the 192) minus (2 to the 64)). LXM is also 1-dimensionally equidistributed, while the foundation it is built on should allow 4-dimensional equidistribution (with the caveat of any LFSR that an all-zero state is impossible), with the same memory use per generator (4 longs), a longer period, and comparable quality using `xoshiro256**`, or possibly `xoshiro256++`, giving up streams but permitting twice as many leaps as LXM has streams if you maintain the same period as L64X128MixRandom.

If I were implementing a PRNG to operate in a future official version of the JVM, I would definitely look into ways to use AES-NI, and I think the interfaces provided here should be valuable for any similar addition, even if I disagree with the provided implementations of those interfaces. Thank you for your time.

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From joehw at openjdk.java.net  Tue Mar 16 21:39:26 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 16 Mar 2021 21:39:26 GMT
Subject: RFR: 8261673: Move javadoc for the lookup mechanism to
 module-info [v2]
In-Reply-To: <wg6xvhZiamooKkIS_HhsC0zOcFl9LN82cg3Xc_QBbqM=.b09e8950-6c4e-477d-a2b3-455eab6046f1@github.com>
References: <wg6xvhZiamooKkIS_HhsC0zOcFl9LN82cg3Xc_QBbqM=.b09e8950-6c4e-477d-a2b3-455eab6046f1@github.com>
Message-ID: <uizasGEylOf-piUXzrClK1LDuhd5olHp-HcTnkMf69Q=.1705834c-96f2-45e4-862b-8e8f9c52a375@github.com>

> Consolidate and move javadoc for the lookup mechanism to the module summary.

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

  Fix typos: s/XMLEventFactory/XMLInputFactory s/XMLEventFactory/XMLOutputFactory

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3020/files
  - new: https://git.openjdk.java.net/jdk/pull/3020/files/9884e8ce..5554c8df

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3020&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3020&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/3020

From lancea at openjdk.java.net  Tue Mar 16 21:39:26 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 16 Mar 2021 21:39:26 GMT
Subject: RFR: 8261673: Move javadoc for the lookup mechanism to
 module-info [v2]
In-Reply-To: <uizasGEylOf-piUXzrClK1LDuhd5olHp-HcTnkMf69Q=.1705834c-96f2-45e4-862b-8e8f9c52a375@github.com>
References: <wg6xvhZiamooKkIS_HhsC0zOcFl9LN82cg3Xc_QBbqM=.b09e8950-6c4e-477d-a2b3-455eab6046f1@github.com>
 <uizasGEylOf-piUXzrClK1LDuhd5olHp-HcTnkMf69Q=.1705834c-96f2-45e4-862b-8e8f9c52a375@github.com>
Message-ID: <vS3zWt4zwmoFHadt9ftFLLp8eLVizRg5ENOPBrcJzxw=.b7a405d7-618c-4e43-83ed-4a6511293728@github.com>

On Tue, 16 Mar 2021 21:36:40 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Consolidate and move javadoc for the lookup mechanism to the module summary.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos: s/XMLEventFactory/XMLInputFactory s/XMLEventFactory/XMLOutputFactory

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3020

From naoto at openjdk.java.net  Tue Mar 16 21:49:07 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 16 Mar 2021 21:49:07 GMT
Subject: RFR: 8261673: Move javadoc for the lookup mechanism to
 module-info [v2]
In-Reply-To: <uizasGEylOf-piUXzrClK1LDuhd5olHp-HcTnkMf69Q=.1705834c-96f2-45e4-862b-8e8f9c52a375@github.com>
References: <wg6xvhZiamooKkIS_HhsC0zOcFl9LN82cg3Xc_QBbqM=.b09e8950-6c4e-477d-a2b3-455eab6046f1@github.com>
 <uizasGEylOf-piUXzrClK1LDuhd5olHp-HcTnkMf69Q=.1705834c-96f2-45e4-862b-8e8f9c52a375@github.com>
Message-ID: <mCsPRl6OfVsLF83_r8B2AZ1qgOprKJ2CGzpZp3s9x9s=.6356c373-8c87-49da-8894-8a19451ee803@github.com>

On Tue, 16 Mar 2021 21:39:26 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Consolidate and move javadoc for the lookup mechanism to the module summary.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos: s/XMLEventFactory/XMLInputFactory s/XMLEventFactory/XMLOutputFactory

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3020

From joehw at openjdk.java.net  Tue Mar 16 21:49:08 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 16 Mar 2021 21:49:08 GMT
Subject: RFR: 8261673: Move javadoc for the lookup mechanism to
 module-info [v2]
In-Reply-To: <17rIuXpaCfuUKn6CGIvX_TE4_JKiiOAq_E4HwMeZq0Y=.3fbdcf9d-a76f-4541-a314-05bffcc5aa9b@github.com>
References: <wg6xvhZiamooKkIS_HhsC0zOcFl9LN82cg3Xc_QBbqM=.b09e8950-6c4e-477d-a2b3-455eab6046f1@github.com>
 <17rIuXpaCfuUKn6CGIvX_TE4_JKiiOAq_E4HwMeZq0Y=.3fbdcf9d-a76f-4541-a314-05bffcc5aa9b@github.com>
Message-ID: <rF8egmqtOxKweuxSrwyzn9yvY65SaS_tXMaQnhCVFkg=.bea4c9b3-49b4-46aa-8ee6-90462020bd57@github.com>

On Tue, 16 Mar 2021 16:59:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typos: s/XMLEventFactory/XMLInputFactory s/XMLEventFactory/XMLOutputFactory
>
> src/java.xml/share/classes/javax/xml/stream/XMLInputFactory.java line 172:
> 
>> 170:    * Creates a new instance of the factory. This method uses the
>> 171:    * <a href="../../../module-summary.html#LookupMechanism">JAXP Lookup Mechanism</a>
>> 172:    * to determine the {@code XMLEventFactory} implementation class to load.
> 
> Should it be `XMLInputFactory`?

Fixed. Updated CSR as well.

> src/java.xml/share/classes/javax/xml/stream/XMLOutputFactory.java line 149:
> 
>> 147:    * Creates a new instance of the factory. This method uses the
>> 148:    * <a href="../../../module-summary.html#LookupMechanism">JAXP Lookup Mechanism</a>
>> 149:    * to determine the {@code XMLEventFactory} implementation class to load.
> 
> And this one as `XMLOutputFactory`?

Fixed. Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/3020

From darcy at openjdk.java.net  Tue Mar 16 22:30:13 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 16 Mar 2021 22:30:13 GMT
Subject: RFR: 8254979: Class.getSimpleName() returns non-empty for lambda and
 method
Message-ID: <Thw0UcKlw3o568qxq0flp2d5grp9Kx80hSMVuo9fITw=.730127b3-e187-499c-86e9-de85bca1a2c5@github.com>

java.lang.Class has a number of methods to return some kind of textual token associated with the class, including a type name, canonical name, simple name, and separately the results of toString().

Bug 8254979 notes that getSimpleName mentions returning the name in source code, but operationally returns a non-null result for synthetic classes, ones without benefit of source code representation. Since it is useful to return a non-null result in such cases, I've updated the spec to mention this case. The names of synthetic classes are not covered by the JLS; using a "$" in such names is customary, but not strictly required. The synthetic classes used to implement lambdas and method references as cited in the bug report include "$"'s.

Looking over the other "getFooName" methods, I don't think they need to be updated to handle this case.

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

Commit messages:
 - 8254979: Class.getSimpleName() returns non-empty for lambda and method

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

PR: https://git.openjdk.java.net/jdk/pull/3038

From almatvee at openjdk.java.net  Tue Mar 16 22:48:06 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 16 Mar 2021 22:48:06 GMT
Subject: RFR: JDK-8263154: [macos] DMG builds have finder errors
In-Reply-To: <q_q2hdnvfEfyo76kIREN-tRxST60tLWyUYvOh3Xipws=.9e37f1ba-fa6f-4914-94bf-fa94c5de2b47@github.com>
References: <q_q2hdnvfEfyo76kIREN-tRxST60tLWyUYvOh3Xipws=.9e37f1ba-fa6f-4914-94bf-fa94c5de2b47@github.com>
Message-ID: <WqlZxbXFMwBHdGu9suuOg_TJvk7vLhyUNFvIpBdmwrg=.0549008f-27a1-4e18-8dbc-554d5b677476@github.com>

On Sat, 13 Mar 2021 14:39:40 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8263154: [macos] DMG builds have finder errors

Marked as reviewed by almatvee (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/2987

From iris at openjdk.java.net  Wed Mar 17 00:08:09 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 17 Mar 2021 00:08:09 GMT
Subject: RFR: 8261673: Move javadoc for the lookup mechanism to
 module-info [v2]
In-Reply-To: <uizasGEylOf-piUXzrClK1LDuhd5olHp-HcTnkMf69Q=.1705834c-96f2-45e4-862b-8e8f9c52a375@github.com>
References: <wg6xvhZiamooKkIS_HhsC0zOcFl9LN82cg3Xc_QBbqM=.b09e8950-6c4e-477d-a2b3-455eab6046f1@github.com>
 <uizasGEylOf-piUXzrClK1LDuhd5olHp-HcTnkMf69Q=.1705834c-96f2-45e4-862b-8e8f9c52a375@github.com>
Message-ID: <OS_dLlujg0tNfW-hbYibmZBOu1vgr-6NRDbq2UAYD1Q=.4970e97b-5ec9-4ce1-b9e7-3359e71b8c85@github.com>

On Tue, 16 Mar 2021 21:39:26 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Consolidate and move javadoc for the lookup mechanism to the module summary.
>
> Joe Wang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typos: s/XMLEventFactory/XMLInputFactory s/XMLEventFactory/XMLOutputFactory

Nice consolidation.  I've added myself as a reviewer of the CSR too.

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3020

From henryjen at openjdk.java.net  Wed Mar 17 00:57:24 2021
From: henryjen at openjdk.java.net (Henry Jen)
Date: Wed, 17 Mar 2021 00:57:24 GMT
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM [v3]
In-Reply-To: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
Message-ID: <xzF8mo-yZRT80DOkBXW9rcjz0BgLdOSc3LdLZmdoKdQ=.80194f1e-757e-40aa-aa6b-e0f2e3ca901d@github.com>

> This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS.
> 
> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the launcher trying to grab class name to be displayed as the Application name on the menu.
> 
> The fix is to not setting name, test shows that GUI java application shows 'bin' as the application name. It's possible for us to set the name to something more friendly, for example, "Java", but I am not sure that should be launcher's responsibility to choose such a default name. It seems to me the consumer of the JAVA_MAIN_CLASS_%d environment variable should be responsible to pick such name in case the environment variable is not set.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Add copyright and another test case

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2999/files
  - new: https://git.openjdk.java.net/jdk/pull/2999/files/58f197f4..f68b0919

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2999&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2999&range=01-02

  Stats: 30 lines in 2 files changed: 29 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2999.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2999/head:pull/2999

PR: https://git.openjdk.java.net/jdk/pull/2999

From david.holmes at oracle.com  Wed Mar 17 01:09:28 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Mar 2021 11:09:28 +1000
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM
In-Reply-To: <e574db83-fca7-9284-8533-1bc2388abcc6@oracle.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
 <acZoevVQtNOwkvpYhhWU6sx2Rh1K7bnAxVKRRZrTykQ=.73760624-f0f2-495a-b6e4-4e5639896a0d@github.com>
 <e574db83-fca7-9284-8533-1bc2388abcc6@oracle.com>
Message-ID: <22b02d29-624e-ba4c-ffeb-1e577e82befd@oracle.com>

On 16/03/2021 2:59 pm, David Holmes wrote:
> On 16/03/2021 11:58 am, Sergey Bylokhov wrote:
>> On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen <henryjen at openjdk.org> wrote:
>>
>>> This patch ensure launcher won't crash JVM for the new static Methods 
>>> from local/anonymous class on MacOS.
>>>
>>> As @dholmes-ora pointed out in the analysis, this is a MacOS specific 
>>> bug when the launcher trying to grab class name to be displayed as 
>>> the Application name on the menu.
>>>
>>> The fix is to not setting name, test shows that GUI java application 
>>> shows 'bin' as the application name. It's possible for us to set the 
>>> name to something more friendly, for example, "Java", but I am not 
>>> sure that should be launcher's responsibility to choose such a 
>>> default name. It seems to me the consumer of the JAVA_MAIN_CLASS_%d 
>>> environment variable should be responsible to pick such name in case 
>>> the environment variable is not set.
>>
>> This bug is similar to 
>> https://bugs.openjdk.java.net/browse/JDK-8076264, and the fix looks fine.
> 
> Both issues involve a problem trying to use the canonical name, but I'd 
> consider both fixes deficient when an alternative name could be used. 

Except I overlooked that this is an anonymous class so no simple name 
either. I agree with Henry's later proposal - fix the crash simply then 
outlaw the usecase later.

Cheers,
David

> But this isn't my code so ...
> 
> David
> 
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/2999
>>

From jai.forums2013 at gmail.com  Wed Mar 17 03:21:40 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 17 Mar 2021 08:51:40 +0530
Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null
 device)?
Message-ID: <dd06d633-1f12-7613-86ba-c7a25bf31203@gmail.com>

Please consider this trivial code:

import java.io.*;
import java.nio.file.*;

public class FileTest {
 ??? public static void main(final String[] args) throws Exception {
 ??????? System.getProperties().list(System.out);
 ??????? final File f = new File("NUL:");
 ??????? try (final InputStream fis = Files.newInputStream(f.toPath())) {
 ?? ??? ??? ??? ?int numBytes = 0;
 ?? ??? ??? ??? ?while (fis.read() != -1) {
 ?? ??? ??? ??? ??? ?System.out.println("Files.newInputStream - Read a 
byte from " + f);
 ?? ??? ??? ??? ??? ?numBytes++;
 ?? ??? ??? ??? ?}
 ?? ??? ??? ??? ?System.out.println("Files.newInputStream - Done reading 
" + numBytes + " bytes from " + f);
 ?? ??? ?}
 ?? ?}
}


The code tries to read from NUL: on a Windows setup. This code runs into 
the following exception on Windows when the java.io.File#toPath() gets 
invoked:


Exception in thread "main" java.nio.file.InvalidPathException: Illegal 
char <:> at index 3: NUL:
 ??? at 
java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
 ??? at 
java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
 ??? at 
java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
 ??? at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
 ??? at 
java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230)
 ??? at java.base/java.io.File.toPath(File.java:2316)
 ??? at FileTest.main(FileTest.java:18)


So it looks like java.io.File.toPath() on Windows isn't able to 
recognize the null device construct?

Just to make sure this issue resides only this specific API 
implementation, I switched the above code to use new FileInputStream(f) 
as follows and that works as expected - reads 0 bytes and completes 
successfully. So the NUL: construct is indeed understood by the other APIs.


public class FileTest {
 ??? public static void main(final String[] args) throws Exception {
 ??????? System.getProperties().list(System.out);
 ??????? final File f = new File("NUL:");
 ??????? try (final FileInputStream fis = new FileInputStream(f)) {
 ??? ??? ??? ??? int numBytes = 0;
 ??? ??? ??? ??? while (fis.read() != -1) {
 ??? ??? ??? ??? ??? System.out.println("FileInputStream() - Read a byte 
from " + f);
 ??? ??? ??? ??? ??? numBytes++;
 ??? ??? ??? ??? }
 ??? ??? ??? ??? System.out.println("FileInputStream() - Done reading " 
+ numBytes + " bytes from " + f);
 ??? ??? }
 ??? }
}

Output:

FileInputStream() - Done reading 0 bytes from NUL:

Test results are from latest Java 16 release on a Windows setup.

-Jaikiran


From jai.forums2013 at gmail.com  Wed Mar 17 03:26:52 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 17 Mar 2021 08:56:52 +0530
Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null
 device)?
In-Reply-To: <dd06d633-1f12-7613-86ba-c7a25bf31203@gmail.com>
References: <dd06d633-1f12-7613-86ba-c7a25bf31203@gmail.com>
Message-ID: <65f61d07-df6a-56c0-7f5b-ca6cd8da85cf@gmail.com>


On 17/03/21 8:51 am, Jaikiran Pai wrote:
>
> Test results are from latest Java 16 release on a Windows setup.

Just gave a quick try against Java 8 (java.version=1.8.0_252) and it 
fails on that version too with the same error:

Exception in thread "main" java.nio.file.InvalidPathException: Illegal 
char <:> at index 3: NUL:
 ??? at sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
 ??? at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
 ??? at sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
 ??? at sun.nio.fs.WindowsPath.parse(WindowsPath.java:94)
 ??? at sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:255)
 ??? at java.io.File.toPath(File.java:2234)
 ??? at FileTest.main(FileTest.java:18)


-Jaikiran


From david.holmes at oracle.com  Wed Mar 17 07:13:53 2021
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 17 Mar 2021 17:13:53 +1000
Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null
 device)?
In-Reply-To: <dd06d633-1f12-7613-86ba-c7a25bf31203@gmail.com>
References: <dd06d633-1f12-7613-86ba-c7a25bf31203@gmail.com>
Message-ID: <247e84e9-63b1-c8ab-1e15-1f7dc1cc69df@oracle.com>

https://bugs.openjdk.java.net/browse/JDK-8022671

Cheers,
David

On 17/03/2021 1:21 pm, Jaikiran Pai wrote:
> Please consider this trivial code:
> 
> import java.io.*;
> import java.nio.file.*;
> 
> public class FileTest {
>  ??? public static void main(final String[] args) throws Exception {
>  ??????? System.getProperties().list(System.out);
>  ??????? final File f = new File("NUL:");
>  ??????? try (final InputStream fis = Files.newInputStream(f.toPath())) {
>  ?? ??? ??? ??? ?int numBytes = 0;
>  ?? ??? ??? ??? ?while (fis.read() != -1) {
>  ?? ??? ??? ??? ??? ?System.out.println("Files.newInputStream - Read a 
> byte from " + f);
>  ?? ??? ??? ??? ??? ?numBytes++;
>  ?? ??? ??? ??? ?}
>  ?? ??? ??? ??? ?System.out.println("Files.newInputStream - Done reading 
> " + numBytes + " bytes from " + f);
>  ?? ??? ?}
>  ?? ?}
> }
> 
> 
> The code tries to read from NUL: on a Windows setup. This code runs into 
> the following exception on Windows when the java.io.File#toPath() gets 
> invoked:
> 
> 
> Exception in thread "main" java.nio.file.InvalidPathException: Illegal 
> char <:> at index 3: NUL:
>  ??? at 
> java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182) 
> 
>  ??? at 
> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
>  ??? at 
> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
>  ??? at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
>  ??? at 
> java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230)
>  ??? at java.base/java.io.File.toPath(File.java:2316)
>  ??? at FileTest.main(FileTest.java:18)
> 
> 
> So it looks like java.io.File.toPath() on Windows isn't able to 
> recognize the null device construct?
> 
> Just to make sure this issue resides only this specific API 
> implementation, I switched the above code to use new FileInputStream(f) 
> as follows and that works as expected - reads 0 bytes and completes 
> successfully. So the NUL: construct is indeed understood by the other APIs.
> 
> 
> public class FileTest {
>  ??? public static void main(final String[] args) throws Exception {
>  ??????? System.getProperties().list(System.out);
>  ??????? final File f = new File("NUL:");
>  ??????? try (final FileInputStream fis = new FileInputStream(f)) {
>  ??? ??? ??? ??? int numBytes = 0;
>  ??? ??? ??? ??? while (fis.read() != -1) {
>  ??? ??? ??? ??? ??? System.out.println("FileInputStream() - Read a byte 
> from " + f);
>  ??? ??? ??? ??? ??? numBytes++;
>  ??? ??? ??? ??? }
>  ??? ??? ??? ??? System.out.println("FileInputStream() - Done reading " 
> + numBytes + " bytes from " + f);
>  ??? ??? }
>  ??? }
> }
> 
> Output:
> 
> FileInputStream() - Done reading 0 bytes from NUL:
> 
> Test results are from latest Java 16 release on a Windows setup.
> 
> -Jaikiran
> 

From Alan.Bateman at oracle.com  Wed Mar 17 07:56:58 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Mar 2021 07:56:58 +0000
Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null
 device)?
In-Reply-To: <dd06d633-1f12-7613-86ba-c7a25bf31203@gmail.com>
References: <dd06d633-1f12-7613-86ba-c7a25bf31203@gmail.com>
Message-ID: <e9a89da8-b625-8797-8a21-d5ab65e49283@oracle.com>

On 17/03/2021 03:21, Jaikiran Pai wrote:
> :
>
>
> The code tries to read from NUL: on a Windows setup. This code runs 
> into the following exception on Windows when the java.io.File#toPath() 
> gets invoked:
>
>
> Exception in thread "main" java.nio.file.InvalidPathException: Illegal 
> char <:> at index 3: NUL:
> ??? at 
> java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> ??? at 
> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> ??? at 
> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> ??? at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
> ??? at 
> java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230)
> ??? at java.base/java.io.File.toPath(File.java:2316)
> ??? at FileTest.main(FileTest.java:18)
>
>
> So it looks like java.io.File.toPath() on Windows isn't able to 
> recognize the null device construct?

Special devices, esp. those historical devices from the DOS era, are 
very problematic.

NUL is somewhat benign compared to the other and you use "NUL" (not 
"NUL:") then should work as you expect. Changing the path parser to 
allow ":" in places other than after drive letters is a slippery slope 
as it brings all a lot of the issues that plagued the older code.

-Alan


From jai.forums2013 at gmail.com  Wed Mar 17 08:21:14 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 17 Mar 2021 13:51:14 +0530
Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null
 device)?
In-Reply-To: <e9a89da8-b625-8797-8a21-d5ab65e49283@oracle.com>
References: <dd06d633-1f12-7613-86ba-c7a25bf31203@gmail.com>
 <e9a89da8-b625-8797-8a21-d5ab65e49283@oracle.com>
Message-ID: <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com>


On 17/03/21 1:26 pm, Alan Bateman wrote:
> On 17/03/2021 03:21, Jaikiran Pai wrote:
>> :
>>
>>
>> The code tries to read from NUL: on a Windows setup. This code runs 
>> into the following exception on Windows when the 
>> java.io.File#toPath() gets invoked:
>>
>>
>> Exception in thread "main" java.nio.file.InvalidPathException: 
>> Illegal char <:> at index 3: NUL:
>> ??? at 
>> java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
>> ??? at 
>> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
>> ??? at 
>> java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
>> ??? at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
>> ??? at 
>> java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:230)
>> ??? at java.base/java.io.File.toPath(File.java:2316)
>> ??? at FileTest.main(FileTest.java:18)
>>
>>
>> So it looks like java.io.File.toPath() on Windows isn't able to 
>> recognize the null device construct?
>
> Special devices, esp. those historical devices from the DOS era, are 
> very problematic.
>
> NUL is somewhat benign compared to the other and you use "NUL" (not 
> "NUL:") then should work as you expect. 

Thank you David and Alan.

I can confirm that using "NUL" or "nul" work fine in the above code, 
with the FileInputStream/FileOutputStream constructors as well as 
Files.newInputStream(f.toPath()) and Files.newOutputStream(f.toPath()).


> Changing the path parser to allow ":" in places other than after drive 
> letters is a slippery slope as it brings all a lot of the issues that 
> plagued the older code.

Understood.


-Jaikiran


From alanb at openjdk.java.net  Wed Mar 17 08:59:09 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 17 Mar 2021 08:59:09 GMT
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM [v3]
In-Reply-To: <4Y_dUFl3dSRd0X7ateyN1REIuBROwnA1_iPey9bkkc4=.c90dce28-515a-4b69-8966-25d50a281394@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
 <acZoevVQtNOwkvpYhhWU6sx2Rh1K7bnAxVKRRZrTykQ=.73760624-f0f2-495a-b6e4-4e5639896a0d@github.com>
 <w7vA_cJ9W2ibNeh_wG5rImAhCC_LWS2oUdypz1mrehY=.9d2ff66e-87fe-4602-8dbe-ae155d8c3fb5@github.com>
 <m50f_ObBCNHRlAqsv8QjTyYfpUHkshCZCEUsZdpcCYk=.6eb47d59-e698-47b4-9a07-0f8f8dc98bb0@github.com>
 <4Y_dUFl3dSRd0X7ateyN1REIuBROwnA1_iPey9bkkc4=.c90dce28-515a-4b69-8966-25d50a281394@github.com>
Message-ID: <1aIl1nXHZZQ4hR_8XQRoVjKVdm4CsuWxwSn_o1u-msY=.29573402-0112-41e4-9f3a-fcdf9c5bec92@github.com>

On Tue, 16 Mar 2021 17:49:42 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> > Using an anonymous class for the main class looks strange and hard to believe anyone is relying on this. I wonder if we should do more checking LauncherHelper.validateMainClass to reject cases like this.
> 
> I raised that same question, and people tends to agree launcher could reject anonymous/local classes. But pointed out that should require a CSR review. Therefore I chose to fix crash first, and we can file another ticket to address main class requirements.

The requirement for a CSR and release note should not be a concern here. I don't object to the fix but I think it would be very useful to document the main class and whether local or anonymous classes can be used, its accessibility, and the accessibility of the main method. We had to do something similar recently with the premain method (java.lang.instrument).

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

PR: https://git.openjdk.java.net/jdk/pull/2999

From Alan.Bateman at oracle.com  Wed Mar 17 09:15:21 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 17 Mar 2021 09:15:21 +0000
Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null
 device)?
In-Reply-To: <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com>
References: <dd06d633-1f12-7613-86ba-c7a25bf31203@gmail.com>
 <e9a89da8-b625-8797-8a21-d5ab65e49283@oracle.com>
 <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com>
Message-ID: <154fbc5c-77a9-9abf-5971-4785c9dd5415@oracle.com>

On 17/03/2021 08:21, Jaikiran Pai wrote:
> :
>
> I can confirm that using "NUL" or "nul" work fine in the above code,

I don't know the context for your question but just to mention 
InputStream.nullInputStream() or Reader.nullReader() may be useful if 
you have something that wants to read from a null stream.

-Alan.


From jai.forums2013 at gmail.com  Wed Mar 17 09:40:04 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 17 Mar 2021 15:10:04 +0530
Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null
 device)?
In-Reply-To: <154fbc5c-77a9-9abf-5971-4785c9dd5415@oracle.com>
References: <dd06d633-1f12-7613-86ba-c7a25bf31203@gmail.com>
 <e9a89da8-b625-8797-8a21-d5ab65e49283@oracle.com>
 <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com>
 <154fbc5c-77a9-9abf-5971-4785c9dd5415@oracle.com>
Message-ID: <2f8cec59-e49b-b304-3686-a695439a9db8@gmail.com>

Hello Alan,

On 17/03/21 2:45 pm, Alan Bateman wrote:
> On 17/03/2021 08:21, Jaikiran Pai wrote:
>> :
>>
>> I can confirm that using "NUL" or "nul" work fine in the above code,
>
> I don't know the context for your question 

A while back Apache Ant switched to using the 
Files.newInputStream/Files.newOutputStream construct as a replacement 
for the FileInputStream and FileOutputStream constructors[1]. That 
commit seems to have introduced an regression in Ant as noted here[2]. 
It appears that users of Ant were using "nul" (and even "nul:") as 
destination file to have Ant write the data to that destination. 
Internally Ant constructs an instance of java.io.File from the user 
provided path string ("nul" or "nul:" in this case) and constructs a 
OutputStream out of it. Previously (before we made that commit in Ant), 
it would be using the FileOutputStream constructor (and would succeed) 
and now it uses the Files.newOuputStream(...) which expects a Path 
instance and this where our usage of java.io.File.toPath() ran into the 
issue I note in this mail, when I started investigating this.

I didn't mention this context in my mail because the error noted in 
those user reports is surprisingly a bit different than what I have seen 
in my experiments on Windows and I don't think I have so far narrowed it 
down to a JDK issue (if any). In their case, it appears the call went 
past the issue we are discussing this mail and instead failed later with 
something like:

java.nio.file.FileSystemException: E:\nul: Incorrect function.
 ??????? at 
sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
 ??????? at 
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
 ??????? at 
sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
 ??????? at 
sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:230)
 ??????? at 
java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434)
 ??????? at java.nio.file.Files.newOutputStream(Files.java:216)


I'm not yet sure how they managed to get to that stage and am waiting to 
see if they can provide us with a reproducible build file to reproduce this.


> but just to mention InputStream.nullInputStream() or 
> Reader.nullReader() may be useful if you have something that wants to 
> read from a null stream.

We have had a recent discussion in Ant dev mailing list[3] to introduce 
such a construct in some of our Ant tasks where users can tell us that 
they want the output/error output discarded (that's what they are using 
/dev/null and "nul:" for). That will prevent all these platform specific 
usages of null device representations. Internally, in the 
implementation, we will use the APIs like the one you note and avoid 
having to deal with null devices.


[1] 
https://github.com/apache/ant/commit/af74d1f6b882cef5f4167d972638ad886d12d58c

[2] https://bz.apache.org/bugzilla/show_bug.cgi?id=62330

[3] https://www.mail-archive.com/dev at ant.apache.org/msg48730.html


-Jaikiran



From jai.forums2013 at gmail.com  Wed Mar 17 09:46:31 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 17 Mar 2021 15:16:31 +0530
Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null
 device)?
In-Reply-To: <2f8cec59-e49b-b304-3686-a695439a9db8@gmail.com>
References: <dd06d633-1f12-7613-86ba-c7a25bf31203@gmail.com>
 <e9a89da8-b625-8797-8a21-d5ab65e49283@oracle.com>
 <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com>
 <154fbc5c-77a9-9abf-5971-4785c9dd5415@oracle.com>
 <2f8cec59-e49b-b304-3686-a695439a9db8@gmail.com>
Message-ID: <1d19e40b-1cad-00f3-0f8a-a11e4bf32a31@gmail.com>


On 17/03/21 3:10 pm, Jaikiran Pai wrote:
> Hello Alan,
>
> On 17/03/21 2:45 pm, Alan Bateman wrote:
>> On 17/03/2021 08:21, Jaikiran Pai wrote:
>>> :
>>>
>>> I can confirm that using "NUL" or "nul" work fine in the above code,
>>
>> I don't know the context for your question 
>
> A while back Apache Ant switched to using the 
> Files.newInputStream/Files.newOutputStream construct as a replacement 
> for the FileInputStream and FileOutputStream constructors[1]. That 
> commit seems to have introduced an regression in Ant as noted here[2]. 
> It appears that users of Ant were using "nul" (and even "nul:") as 
> destination file to have Ant write the data to that destination. 
> Internally Ant constructs an instance of java.io.File from the user 
> provided path string ("nul" or "nul:" in this case) and constructs a 
> OutputStream out of it. Previously (before we made that commit in 
> Ant), it would be using the FileOutputStream constructor (and would 
> succeed) and now it uses the Files.newOuputStream(...) which expects a 
> Path instance and this where our usage of java.io.File.toPath() ran 
> into the issue I note in this mail, when I started investigating this.
>
> I didn't mention this context in my mail because the error noted in 
> those user reports is surprisingly a bit different than what I have 
> seen in my experiments on Windows and I don't think I have so far 
> narrowed it down to a JDK issue (if any). In their case, it appears 
> the call went past the issue we are discussing this mail and instead 
> failed later with something like:
>
> java.nio.file.FileSystemException: E:\nul: Incorrect function.
> ??????? at 
> sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:86)
> ??????? at 
> sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
> ??????? at 
> sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
> ??????? at 
> sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:230)
> ??????? at 
> java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434)
> ??????? at java.nio.file.Files.newOutputStream(Files.java:216)
>
>
> I'm not yet sure how they managed to get to that stage and am waiting 
> to see if they can provide us with a reproducible build file to 
> reproduce this.
>
FWIW - that bug report states that they ran into this even when using 
"nul" and not just "nul:". So there might be something more going on 
here and am just waiting to see if they can provide us a build file to 
reproduce this issue.


-Jaikiran


From jiefu at openjdk.java.net  Wed Mar 17 11:23:49 2021
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 17 Mar 2021 11:23:49 GMT
Subject: Withdrawn: 8259925: [Vector API] Unreasonable
 IndexOutOfBoundsException message when length < vlen
In-Reply-To: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
References: <IXlGGauVhUjxPJXm8CjZ0Eo4-ySUttJ_EqYpxiW7p8E=.32dc9082-78ad-4407-a6a2-3652dfef8a4c@github.com>
Message-ID: <RMpSZwh31_uG0PWai9n6pycYtc8JBGPspzs6OvTXHC4=.9ea46480-fdd2-4273-81a6-d695e71bb135@github.com>

On Mon, 18 Jan 2021 13:32:24 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> For this reproducer:
> 
> import jdk.incubator.vector.ByteVector;
> import jdk.incubator.vector.VectorSpecies;
> 
> public class Test {
>     static final VectorSpecies<Byte> SPECIES_128 = ByteVector.SPECIES_128;
>     static byte[] a = new byte[8];
>     static byte[] b = new byte[8];
> 
>     public static void main(String[] args) {
>         ByteVector av = ByteVector.fromArray(SPECIES_128, a, 0);
>         av.intoArray(b, 0);
>         System.out.println("b: " + b[0]);
>     }
> }
> 
> The following IndexOutOfBoundsException message (length -7) is unreasonable.
> 
> Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length -7
> 
> It might be better to fix it like this.
> 
> Exception in thread "main" java.lang.IndexOutOfBoundsException: Index 0 out of bounds for length 0
> 
> Thanks.
> Best regards,
> Jie

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/2127

From github.com+76791+alblue at openjdk.java.net  Wed Mar 17 12:17:00 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Wed, 17 Mar 2021 12:17:00 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base
Message-ID: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>

Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.

This fixes the issues in the `java.base` package for ease of reviewing.

https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

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

Commit messages:
 - 8263658: Use the blessed modifier order in java.base

Changes: https://git.openjdk.java.net/jdk/pull/2993/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2993&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263658
  Stats: 140 lines in 29 files changed: 0 ins; 0 del; 140 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2993.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2993/head:pull/2993

PR: https://git.openjdk.java.net/jdk/pull/2993

From shade at openjdk.java.net  Wed Mar 17 12:17:00 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 17 Mar 2021 12:17:00 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base
In-Reply-To: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
Message-ID: <YHFo0zT_eq_LraNsD7z8BqjL1xU-VUdlS0Gt2wBmOxc=.e1da1bb5-33b4-4e10-bd7f-68c85761a20b@github.com>

On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
> 
> This fixes the issues in the `java.base` package for ease of reviewing.
> 
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

Please change the synopsis to "8263658: Use the blessed modifier order in java.base" to get this PR hooked properly to the new bug. Also configure the run the testing, see "Pre-submit test status" in "Checks".

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

PR: https://git.openjdk.java.net/jdk/pull/2993

From rriggs at openjdk.java.net  Wed Mar 17 13:31:50 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 17 Mar 2021 13:31:50 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base
In-Reply-To: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
Message-ID: <VTJtQ5OoCu2esV2ccxoFEYezFV_MK59j8F_JnbsBcqk=.ac951e53-5c44-4083-b662-7e4c92bd8bb5@github.com>

On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
> 
> This fixes the issues in the `java.base` package for ease of reviewing.
> 
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2993

From chegar at openjdk.java.net  Wed Mar 17 13:32:54 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 17 Mar 2021 13:32:54 GMT
Subject: RFR: 8148937: (str) Adapt StringJoiner for Compact Strings [v3]
In-Reply-To: <nT8kSj_A3NsRoeUJWcV-X84baViZx_sluhPOrRVBJow=.af055b84-230d-4976-8501-3b9dd3e28fdf@github.com>
References: <V3-_ghd9MJZQxCWSiSwpVXHs-u4DaQo_g3mSjH9wOX0=.08042cfb-bce0-4885-8f58-049450952b1e@github.com>
 <nT8kSj_A3NsRoeUJWcV-X84baViZx_sluhPOrRVBJow=.af055b84-230d-4976-8501-3b9dd3e28fdf@github.com>
Message-ID: <4T_9Q1V9-NxupS0kBhqrUrh6XjBmSTxSqtjKW9zRb0g=.49910022-dcb6-4e36-966a-ea197b0c57a2@github.com>

On Mon, 15 Mar 2021 21:47:28 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Hello,
>> 
>> as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings.
>> 
>> This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols.
>> 
>> As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called:
>> String delimiter = this.delimiter;
>> char[] chars = new char[this.len + addLen];
>> int k = getChars(this.prefix, chars, 0);
>> if (size > 0) {
>>     k += getChars(elts[0], chars, k);        // inflate byte[]
>> 
>>     for(int i = 1; i < size; ++i) {
>>         k += getChars(delimiter, chars, k);
>>         k += getChars(elts[i], chars, k);
>>     }
>> }
>> 
>> k += getChars(this.suffix, chars, k);
>> return new String(chars);                    // compress char[] -> byte[]
>> This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082)
>> covering both cases when resulting String is Latin1 or UTF-16
>> 
>> I've prepared a patch along with benchmark proving that this change is correct and brings improvement.
>> 
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>> public class StringJoinerBenchmark {
>> 
>>   @Benchmark
>>   public String stringJoiner(Data data) {
>>     String[] stringArray = data.stringArray;
>>     return Joiner.joinWithStringJoiner(stringArray);
>>   }
>> 
>>   @State(Scope.Thread)
>>   public static class Data {
>> 
>>     @Param({"latin", "cyrillic", "mixed"})
>>     private String mode;
>> 
>>     @Param({"8", "32", "64"})
>>     private int length;
>> 
>>     @Param({"5", "10", "100"})
>>     private int count;
>> 
>>     private String[] stringArray;
>> 
>>     @Setup
>>     public void setup() {
>>       RandomStringGenerator generator = new RandomStringGenerator();
>> 
>>       stringArray = new String[count];
>> 
>>       for (int i = 0; i < count; i++) {
>>         String alphabet = getAlphabet(i, mode);
>>         stringArray[i] = generator.randomString(alphabet, length);
>>       }
>>     }
>> 
>>     private static String getAlphabet(int index, String mode) {
>>       var latin = "abcdefghijklmnopqrstuvwxyz"; //English
>>       var cyrillic = "????????????????????????????????"; // Russian
>> 
>>       String alphabet;
>>       switch (mode) {
>>         case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin;
>>         case "latin" -> alphabet = latin;
>>         case "cyrillic" -> alphabet = cyrillic;
>>         default -> throw new RuntimeException("Illegal mode " + mode);
>>       }
>>       return alphabet;
>>     }
>>   }
>> }
>> 
>> public class Joiner {
>> 
>>   public static String joinWithStringJoiner(String[] stringArray) {
>>     StringJoiner joiner = new StringJoiner(",", "[", "]");
>>     for (String str : stringArray) {
>>       joiner.add(str);
>>     }
>>     return joiner.toString();
>>   }
>> }
>> 
>> 
>>                                     (count)  (length)    (mode)                Java 14                 patched     Units
>> stringJoiner                              5         8     latin       78.836 ?   0.208        67.546 ?   0.500     ns/op
>> stringJoiner                              5        32     latin       92.877 ?   0.422        66.760 ?   0.498     ns/op
>> stringJoiner                              5        64     latin      115.423 ?   0.883        73.224 ?   0.289     ns/op
>> stringJoiner                             10         8     latin      152.587 ?   0.429       161.427 ?   0.635     ns/op
>> stringJoiner                             10        32     latin      189.998 ?   0.478       164.099 ?   0.963     ns/op
>> stringJoiner                             10        64     latin      238.679 ?   1.419       176.825 ?   0.533     ns/op
>> stringJoiner                            100         8     latin     1215.612 ?  17.413      1541.802 ? 126.166     ns/op
>> stringJoiner                            100        32     latin     1699.998 ?  28.407      1563.341 ?   4.439     ns/op
>> stringJoiner                            100        64     latin     2289.388 ?  45.319      2215.931 ? 137.583     ns/op
>> stringJoiner                              5         8  cyrillic       96.692 ?   0.947        80.946 ?   0.371     ns/op
>> stringJoiner                              5        32  cyrillic      107.806 ?   0.429        84.717 ?   0.541     ns/op
>> stringJoiner                              5        64  cyrillic      150.762 ?   2.267        96.214 ?   1.251     ns/op
>> stringJoiner                             10         8  cyrillic      190.570 ?   0.381       182.754 ?   0.678     ns/op
>> stringJoiner                             10        32  cyrillic      240.239 ?   1.110       187.991 ?   1.575     ns/op
>> stringJoiner                             10        64  cyrillic      382.493 ?   2.692       219.358 ?   0.967     ns/op
>> stringJoiner                            100         8  cyrillic     1737.435 ?  16.171      1658.379 ?  56.225     ns/op
>> stringJoiner                            100        32  cyrillic     2321.106 ?  13.583      1942.028 ?   3.418     ns/op
>> stringJoiner                            100        64  cyrillic     3189.563 ?  10.135      2484.796 ?   7.572     ns/op
>> stringJoiner                              5         8     mixed       88.743 ?   0.709        76.049 ?   0.685     ns/op
>> stringJoiner                              5        32     mixed      103.425 ?   0.745        81.006 ?   0.184     ns/op
>> stringJoiner                              5        64     mixed      146.441 ?   0.763        93.071 ?   0.858     ns/op
>> stringJoiner                             10         8     mixed      169.262 ?   0.482       158.890 ?   0.598     ns/op
>> stringJoiner                             10        32     mixed      218.566 ?   0.945       170.415 ?   1.172     ns/op
>> stringJoiner                             10        64     mixed      361.412 ?   1.546       200.374 ?   0.683     ns/op
>> stringJoiner                            100         8     mixed     1594.544 ?   5.761      1476.689 ?   2.004     ns/op
>> stringJoiner                            100        32     mixed     2221.333 ?  28.320      1879.071 ?  52.729     ns/op
>> stringJoiner                            100        64     mixed     3115.786 ?  22.485      2400.644 ?   4.401     ns/op
>> 
>> stringJoiner:?gc.alloc.rate.norm          5         8     latin      248.023 ?   0.001       136.015 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        32     latin      608.045 ?   0.001       256.022 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        64     latin     1088.067 ?   0.002       416.030 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10         8     latin      464.044 ?   0.001       264.029 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        32     latin     1184.085 ?   0.003       504.044 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        64     latin     2144.123 ?   0.005       824.065 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm        100         8     latin     3872.367 ?   8.002      2024.269 ?   8.016      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        32     latin    11048.803 ?   7.988      4416.393 ?   0.004      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        64     latin    20657.194 ?   9.775      7640.642 ?   9.819      B/op
>> stringJoiner:?gc.alloc.rate.norm          5         8  cyrillic      360.029 ?   0.001       184.020 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        32  cyrillic      960.060 ?   0.002       424.032 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        64  cyrillic     1760.088 ?   0.003       744.043 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10         8  cyrillic      664.063 ?   0.001       352.038 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        32  cyrillic     1864.128 ?   0.003       832.067 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        64  cyrillic     3464.206 ?   0.007      1472.094 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm        100         8  cyrillic     5704.541 ?   0.006      2928.317 ?   8.002      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        32  cyrillic    17705.090 ?   0.045      7720.658 ?   0.007      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        64  cyrillic    33689.855 ?   9.786     14121.042 ?   0.015      B/op
>> stringJoiner:?gc.alloc.rate.norm          5         8     mixed      360.028 ?   0.001       184.016 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        32     mixed      960.059 ?   0.002       424.031 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm          5        64     mixed     1760.088 ?   0.003       744.041 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10         8     mixed      664.052 ?   0.001       352.035 ?   0.002      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        32     mixed     1864.116 ?   0.005       832.064 ?   0.001      B/op
>> stringJoiner:?gc.alloc.rate.norm         10        64     mixed     3464.196 ?   0.006      1472.088 ?   0.002      B/op
>> stringJoiner:?gc.alloc.rate.norm        100         8     mixed     5672.448 ?   8.002      2920.314 ?   0.006      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        32     mixed    17681.092 ?   9.824      7728.653 ?   8.008      B/op
>> stringJoiner:?gc.alloc.rate.norm        100        64     mixed    33697.818 ?   8.011     14120.977 ?   0.034      B/op
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8148937: (str) Update copyright year

Marked as reviewed by chegar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2627

From github.com+10835776+stsypanov at openjdk.java.net  Wed Mar 17 13:37:52 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 17 Mar 2021 13:37:52 GMT
Subject: Integrated: 8148937: (str) Adapt StringJoiner for Compact Strings
In-Reply-To: <V3-_ghd9MJZQxCWSiSwpVXHs-u4DaQo_g3mSjH9wOX0=.08042cfb-bce0-4885-8f58-049450952b1e@github.com>
References: <V3-_ghd9MJZQxCWSiSwpVXHs-u4DaQo_g3mSjH9wOX0=.08042cfb-bce0-4885-8f58-049450952b1e@github.com>
Message-ID: <5bem8C3JNFJeVXKjolHcGMWeNhnykzQvKvym7yFVLV8=.0f1bf64e-dfb3-4687-ad7b-be1d0f628376@github.com>

On Thu, 18 Feb 2021 14:30:15 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> Hello,
> 
> as of now `java.util.StringJoiner` still uses `char[]` as a storage for joined Strings.
> 
> This applies for the cases when all joined Strings as well as delimiter, prefix and suffix contain only ASCII symbols.
> 
> As a result when `StringJoiner.toString()` is called `byte[]` stored in Strings is inflated in order to fill in `char[]` and after that `char[]` is compressed when constructor of String is called:
> String delimiter = this.delimiter;
> char[] chars = new char[this.len + addLen];
> int k = getChars(this.prefix, chars, 0);
> if (size > 0) {
>     k += getChars(elts[0], chars, k);        // inflate byte[]
> 
>     for(int i = 1; i < size; ++i) {
>         k += getChars(delimiter, chars, k);
>         k += getChars(elts[i], chars, k);
>     }
> }
> 
> k += getChars(this.suffix, chars, k);
> return new String(chars);                    // compress char[] -> byte[]
> This can be improved by utilizing new method `String.getBytes(byte[], int, int, byte, int)` [introduced](https://github.com/openjdk/jdk/pull/402) in [JDK-8224986](https://bugs.openjdk.java.net/browse/JDK-8254082)
> covering both cases when resulting String is Latin1 or UTF-16
> 
> I've prepared a patch along with benchmark proving that this change is correct and brings improvement.
> 
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class StringJoinerBenchmark {
> 
>   @Benchmark
>   public String stringJoiner(Data data) {
>     String[] stringArray = data.stringArray;
>     return Joiner.joinWithStringJoiner(stringArray);
>   }
> 
>   @State(Scope.Thread)
>   public static class Data {
> 
>     @Param({"latin", "cyrillic", "mixed"})
>     private String mode;
> 
>     @Param({"8", "32", "64"})
>     private int length;
> 
>     @Param({"5", "10", "100"})
>     private int count;
> 
>     private String[] stringArray;
> 
>     @Setup
>     public void setup() {
>       RandomStringGenerator generator = new RandomStringGenerator();
> 
>       stringArray = new String[count];
> 
>       for (int i = 0; i < count; i++) {
>         String alphabet = getAlphabet(i, mode);
>         stringArray[i] = generator.randomString(alphabet, length);
>       }
>     }
> 
>     private static String getAlphabet(int index, String mode) {
>       var latin = "abcdefghijklmnopqrstuvwxyz"; //English
>       var cyrillic = "????????????????????????????????"; // Russian
> 
>       String alphabet;
>       switch (mode) {
>         case "mixed" -> alphabet = index % 2 == 0 ? cyrillic : latin;
>         case "latin" -> alphabet = latin;
>         case "cyrillic" -> alphabet = cyrillic;
>         default -> throw new RuntimeException("Illegal mode " + mode);
>       }
>       return alphabet;
>     }
>   }
> }
> 
> public class Joiner {
> 
>   public static String joinWithStringJoiner(String[] stringArray) {
>     StringJoiner joiner = new StringJoiner(",", "[", "]");
>     for (String str : stringArray) {
>       joiner.add(str);
>     }
>     return joiner.toString();
>   }
> }
> 
> 
>                                     (count)  (length)    (mode)                Java 14                 patched     Units
> stringJoiner                              5         8     latin       78.836 ?   0.208        67.546 ?   0.500     ns/op
> stringJoiner                              5        32     latin       92.877 ?   0.422        66.760 ?   0.498     ns/op
> stringJoiner                              5        64     latin      115.423 ?   0.883        73.224 ?   0.289     ns/op
> stringJoiner                             10         8     latin      152.587 ?   0.429       161.427 ?   0.635     ns/op
> stringJoiner                             10        32     latin      189.998 ?   0.478       164.099 ?   0.963     ns/op
> stringJoiner                             10        64     latin      238.679 ?   1.419       176.825 ?   0.533     ns/op
> stringJoiner                            100         8     latin     1215.612 ?  17.413      1541.802 ? 126.166     ns/op
> stringJoiner                            100        32     latin     1699.998 ?  28.407      1563.341 ?   4.439     ns/op
> stringJoiner                            100        64     latin     2289.388 ?  45.319      2215.931 ? 137.583     ns/op
> stringJoiner                              5         8  cyrillic       96.692 ?   0.947        80.946 ?   0.371     ns/op
> stringJoiner                              5        32  cyrillic      107.806 ?   0.429        84.717 ?   0.541     ns/op
> stringJoiner                              5        64  cyrillic      150.762 ?   2.267        96.214 ?   1.251     ns/op
> stringJoiner                             10         8  cyrillic      190.570 ?   0.381       182.754 ?   0.678     ns/op
> stringJoiner                             10        32  cyrillic      240.239 ?   1.110       187.991 ?   1.575     ns/op
> stringJoiner                             10        64  cyrillic      382.493 ?   2.692       219.358 ?   0.967     ns/op
> stringJoiner                            100         8  cyrillic     1737.435 ?  16.171      1658.379 ?  56.225     ns/op
> stringJoiner                            100        32  cyrillic     2321.106 ?  13.583      1942.028 ?   3.418     ns/op
> stringJoiner                            100        64  cyrillic     3189.563 ?  10.135      2484.796 ?   7.572     ns/op
> stringJoiner                              5         8     mixed       88.743 ?   0.709        76.049 ?   0.685     ns/op
> stringJoiner                              5        32     mixed      103.425 ?   0.745        81.006 ?   0.184     ns/op
> stringJoiner                              5        64     mixed      146.441 ?   0.763        93.071 ?   0.858     ns/op
> stringJoiner                             10         8     mixed      169.262 ?   0.482       158.890 ?   0.598     ns/op
> stringJoiner                             10        32     mixed      218.566 ?   0.945       170.415 ?   1.172     ns/op
> stringJoiner                             10        64     mixed      361.412 ?   1.546       200.374 ?   0.683     ns/op
> stringJoiner                            100         8     mixed     1594.544 ?   5.761      1476.689 ?   2.004     ns/op
> stringJoiner                            100        32     mixed     2221.333 ?  28.320      1879.071 ?  52.729     ns/op
> stringJoiner                            100        64     mixed     3115.786 ?  22.485      2400.644 ?   4.401     ns/op
> 
> stringJoiner:?gc.alloc.rate.norm          5         8     latin      248.023 ?   0.001       136.015 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        32     latin      608.045 ?   0.001       256.022 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        64     latin     1088.067 ?   0.002       416.030 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10         8     latin      464.044 ?   0.001       264.029 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        32     latin     1184.085 ?   0.003       504.044 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        64     latin     2144.123 ?   0.005       824.065 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm        100         8     latin     3872.367 ?   8.002      2024.269 ?   8.016      B/op
> stringJoiner:?gc.alloc.rate.norm        100        32     latin    11048.803 ?   7.988      4416.393 ?   0.004      B/op
> stringJoiner:?gc.alloc.rate.norm        100        64     latin    20657.194 ?   9.775      7640.642 ?   9.819      B/op
> stringJoiner:?gc.alloc.rate.norm          5         8  cyrillic      360.029 ?   0.001       184.020 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        32  cyrillic      960.060 ?   0.002       424.032 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        64  cyrillic     1760.088 ?   0.003       744.043 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10         8  cyrillic      664.063 ?   0.001       352.038 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        32  cyrillic     1864.128 ?   0.003       832.067 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        64  cyrillic     3464.206 ?   0.007      1472.094 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm        100         8  cyrillic     5704.541 ?   0.006      2928.317 ?   8.002      B/op
> stringJoiner:?gc.alloc.rate.norm        100        32  cyrillic    17705.090 ?   0.045      7720.658 ?   0.007      B/op
> stringJoiner:?gc.alloc.rate.norm        100        64  cyrillic    33689.855 ?   9.786     14121.042 ?   0.015      B/op
> stringJoiner:?gc.alloc.rate.norm          5         8     mixed      360.028 ?   0.001       184.016 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        32     mixed      960.059 ?   0.002       424.031 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm          5        64     mixed     1760.088 ?   0.003       744.041 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10         8     mixed      664.052 ?   0.001       352.035 ?   0.002      B/op
> stringJoiner:?gc.alloc.rate.norm         10        32     mixed     1864.116 ?   0.005       832.064 ?   0.001      B/op
> stringJoiner:?gc.alloc.rate.norm         10        64     mixed     3464.196 ?   0.006      1472.088 ?   0.002      B/op
> stringJoiner:?gc.alloc.rate.norm        100         8     mixed     5672.448 ?   8.002      2920.314 ?   0.006      B/op
> stringJoiner:?gc.alloc.rate.norm        100        32     mixed    17681.092 ?   9.824      7728.653 ?   8.008      B/op
> stringJoiner:?gc.alloc.rate.norm        100        64     mixed    33697.818 ?   8.011     14120.977 ?   0.034      B/op

This pull request has now been integrated.

Changeset: 000012a3
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/000012a3
Stats:     135 lines in 2 files changed: 113 ins; 10 del; 12 mod

8148937: (str) Adapt StringJoiner for Compact Strings

Reviewed-by: redestad, chegar

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

PR: https://git.openjdk.java.net/jdk/pull/2627

From rriggs at openjdk.java.net  Wed Mar 17 14:22:00 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 17 Mar 2021 14:22:00 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child in
 ProcssBuilder Basic test
Message-ID: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>

Intermittent failures on Windows in a test of destroying the child warrant extending the time the parent waits after starting the child before destroying the child.

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

Commit messages:
 - 8263729: [test] Extend time to wait before destroying child in ProcessBuilder Basic test

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From plevart at openjdk.java.net  Wed Mar 17 14:37:50 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 17 Mar 2021 14:37:50 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v5]
In-Reply-To: <KW2gXeCkU_TaF2Y4WMfXdTEwgVCDSFubBU1xtkw54Q0=.4124ed7d-f482-4112-aa09-443507b6c77f@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <KW2gXeCkU_TaF2Y4WMfXdTEwgVCDSFubBU1xtkw54Q0=.4124ed7d-f482-4112-aa09-443507b6c77f@github.com>
Message-ID: <26jh4Bu8tVmijpMfV7AiFspkehwYOg_oEM3fFE5vQ2I=.32f73af4-3207-465a-acf0-c0a591ea5201@github.com>

On Tue, 16 Mar 2021 14:47:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed patch for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8263108?
>> 
>> As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and `java.lang.constant.ConstantDescs` can end up in a classloading deadlock due to the nature of the code involved in their static blocks. A thread dump of one such deadlock (reproduced using the code attached to that issue) is as follows:
>> 
>> "Thread A" #14 prio=5 os_prio=31 cpu=101.45ms elapsed=8.30s tid=0x00007ff88e01ca00 nid=0x6003 in Object.wait()  [0x000070000a4c6000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.DynamicConstantDesc.<clinit>(java.base at 16-ea/DynamicConstantDesc.java:67)
>> 	- waiting on the Class initialization monitor for java.lang.constant.ConstantDescs
>> 	at Deadlock.threadA(Deadlock.java:14)
>> 	at Deadlock$$Lambda$1/0x0000000800c00a08.run(Unknown Source)
>> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
>> 
>> "Thread B" #15 prio=5 os_prio=31 cpu=103.15ms elapsed=8.30s tid=0x00007ff88b936a00 nid=0x9b03 in Object.wait()  [0x000070000a5c9000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.ClassDesc.ofDescriptor(java.base at 16-ea/ClassDesc.java:145)
>> 	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc
>> 	at java.lang.constant.ConstantDescs.<clinit>(java.base at 16-ea/ConstantDescs.java:239)
>> 	at Deadlock.threadB(Deadlock.java:24)
>> 	at Deadlock$$Lambda$2/0x0000000800c00c28.run(Unknown Source)
>> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
>> 
>> The commit in this PR resolves that deadlock by moving the `canonicalMap` initialization in `DynamicConstantDesc`, from the static block, to a lazily initialized map, into the `tryCanonicalize` (private) method of the same class. That's the only method which uses this map.
>> 
>> The implementation in `tryCanonicalize` carefully ensures that the deadlock isn't shifted from the static block to this method, by making sure that the `synchronization` on `DynamicConstantDesc` in this method happens only when it's time to write the state to the shared `canonicalMap`. This has an implication that the method local variable `canonDescs` can get initialized by multiple threads unnecessarily but from what I can see, that's the only way we can avoid this deadlock. This penalty of multiple threads initializing and then throwing away that map isn't too huge because that will happen only once when the `canonicalMap` is being initialized for the first time.
>> 
>> An alternate approach that I thought of was to completely get rid of this shared cache `canonicalMap` and instead just use method level map (that gets initialized each time) in the `tryCanonicalize` method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.
>> 
>> The commit in this PR also includes a jtreg testcase which (consistently) reproduces the deadlock without the fix and passes when this fix is applied. Extra manual testing has been done to verify that the classes of interest (noted in that testcase) are indeed getting loaded in those concurrent threads and not in the main thread. For future maintainers, there's a implementation note added on that testcase explaining why it cannot be moved into testng test.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment to instruct future maintainers of the code to avoid calling DynamicConstantDesc.ofCanonical() from static initialization of java.lang.constant.ConstantDescs

This looks good, Jaikiran.

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

Marked as reviewed by plevart (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2893

From plevart at openjdk.java.net  Wed Mar 17 14:58:52 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 17 Mar 2021 14:58:52 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
Message-ID: <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>

On Wed, 17 Mar 2021 14:16:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Intermittent failures on Windows in a test of destroying the child warrant extending the time the parent waits after starting the child before destroying the child.

test/jdk/java/lang/ProcessBuilder/Basic.java line 2183:

> 2181:                 latch.await();
> 2182:                 Thread.sleep(100L);     // Wait for child initialization to settle
> 2183: 

Hi Roger,
Shouldn't the code that follows this sleep already be enough to wait for child thread to get a lock on the stream?

                Thread.sleep(100L);     // Wait for child initialization to settle

                if (s instanceof BufferedInputStream) {
                    // Wait until after the s.read occurs in "thread" by
                    // checking when the input stream monitor is acquired
                    // (BufferedInputStream.read is synchronized)
                    while (!isLocked(s, 10)) {
                        Thread.sleep(100);
                    }
                }
  

>From 1st glance I would conclude that the 1st sleep is unnecessary. Is there a platform where Input/Error stream is not a BufferedInputStream?

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From jpai at openjdk.java.net  Wed Mar 17 15:14:50 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 17 Mar 2021 15:14:50 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v5]
In-Reply-To: <26jh4Bu8tVmijpMfV7AiFspkehwYOg_oEM3fFE5vQ2I=.32f73af4-3207-465a-acf0-c0a591ea5201@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <KW2gXeCkU_TaF2Y4WMfXdTEwgVCDSFubBU1xtkw54Q0=.4124ed7d-f482-4112-aa09-443507b6c77f@github.com>
 <26jh4Bu8tVmijpMfV7AiFspkehwYOg_oEM3fFE5vQ2I=.32f73af4-3207-465a-acf0-c0a591ea5201@github.com>
Message-ID: <aYb2Xqwiw8MAVt7Ai1GqFFT837FDtKH0Dtx-ocb2HkM=.e8c247a3-9fdf-48a6-88c4-63e854338328@github.com>

On Wed, 17 Mar 2021 14:34:41 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add a comment to instruct future maintainers of the code to avoid calling DynamicConstantDesc.ofCanonical() from static initialization of java.lang.constant.ConstantDescs
>
> This looks good, Jaikiran.

Thank you Peter, Chris and Vyom for the reviews. I'll go ahead and integrate this in a few hours.

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From rriggs at openjdk.java.net  Wed Mar 17 15:21:50 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 17 Mar 2021 15:21:50 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
Message-ID: <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>

On Wed, 17 Mar 2021 14:52:36 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Intermittent failures on Windows in a test of destroying the child warrant extending the time the parent waits after starting the child before destroying the child.
>
> test/jdk/java/lang/ProcessBuilder/Basic.java line 2183:
> 
>> 2181:                 latch.await();
>> 2182:                 Thread.sleep(100L);     // Wait for child initialization to settle
>> 2183: 
> 
> Hi Roger,
> Shouldn't the code that follows this sleep already be enough to wait for child thread to get a lock on the stream?
> 
>                 Thread.sleep(100L);     // Wait for child initialization to settle
> 
>                 if (s instanceof BufferedInputStream) {
>                     // Wait until after the s.read occurs in "thread" by
>                     // checking when the input stream monitor is acquired
>                     // (BufferedInputStream.read is synchronized)
>                     while (!isLocked(s, 10)) {
>                         Thread.sleep(100);
>                     }
>                 }
>   
> 
> From 1st glance I would conclude that the 1st sleep is unnecessary. Is there a platform where Input/Error stream is not a BufferedInputStream? Or is it calling Process.destory() immediately after the child thread enters BufferedInputStream.read synchronized method perhaps too early to trigger appropriate exception in the child thread? In that case the additional sleep should be added after the while(!isLocked... loop.

That loop is checking that the Thread (in the parent) reading from the child is in the correct state (blocked).  On Windows, it is a BufferedInputStream.

But it does not indicate anything about the state of the child process.
>From the scant information from previous failures, it appears that the the creation of some thread (not a java thread) in the child has failed.
The additional time is to avoid destroying the child while it is still initializing.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From herrick at openjdk.java.net  Wed Mar 17 15:35:49 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 15:35:49 GMT
Subject: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations
In-Reply-To: <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
Message-ID: <4WfIqOQTCLxtbCQnD2xn4Doku9I1K5cnZ3FOv_JfeJQ=.09c24289-7e79-4592-9043-36b3b790701f@github.com>

On Sun, 14 Mar 2021 12:06:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> the

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

PR: https://git.openjdk.java.net/jdk/pull/2920

From herrick at openjdk.java.net  Wed Mar 17 15:35:49 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 15:35:49 GMT
Subject: Withdrawn: 8189198: Add "forRemoval = true" to Applet API deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <HTWVY7MhXEo0XsFT0RVMz53wTcGRnOg8SwGNghVgDtk=.7c738703-a42a-4f3e-9466-df2cf05cf2d0@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/2920

From henryjen at openjdk.java.net  Wed Mar 17 15:48:55 2021
From: henryjen at openjdk.java.net (Henry Jen)
Date: Wed, 17 Mar 2021 15:48:55 GMT
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM [v3]
In-Reply-To: <1aIl1nXHZZQ4hR_8XQRoVjKVdm4CsuWxwSn_o1u-msY=.29573402-0112-41e4-9f3a-fcdf9c5bec92@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
 <acZoevVQtNOwkvpYhhWU6sx2Rh1K7bnAxVKRRZrTykQ=.73760624-f0f2-495a-b6e4-4e5639896a0d@github.com>
 <w7vA_cJ9W2ibNeh_wG5rImAhCC_LWS2oUdypz1mrehY=.9d2ff66e-87fe-4602-8dbe-ae155d8c3fb5@github.com>
 <m50f_ObBCNHRlAqsv8QjTyYfpUHkshCZCEUsZdpcCYk=.6eb47d59-e698-47b4-9a07-0f8f8dc98bb0@github.com>
 <4Y_dUFl3dSRd0X7ateyN1REIuBROwnA1_iPey9bkkc4=.c90dce28-515a-4b69-8966-25d50a281394@github.com>
 <1aIl1nXHZZQ4hR_8XQRoVjKVdm4CsuWxwSn_o1u-msY=.29573402-0112-41e4-9f3a-fcdf9c5bec92@github.com>
Message-ID: <kQaunT8lxOWJTjynSdCnGdm3HEfaeZtUgJjwQdmkp9w=.9af2e200-8498-4815-a8d0-40131fc4a9c7@github.com>

On Wed, 17 Mar 2021 08:55:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > > Using an anonymous class for the main class looks strange and hard to believe anyone is relying on this. I wonder if we should do more checking LauncherHelper.validateMainClass to reject cases like this.
> > 
> > 
> > I raised that same question, and people tends to agree launcher could reject anonymous/local classes. But pointed out that should require a CSR review. Therefore I chose to fix crash first, and we can file another ticket to address main class requirements.
> 
> The requirement for a CSR and release note should not be a concern here. I don't object to the fix but I think it would be very useful to document the main class and whether local or anonymous classes can be used, its accessibility, and the accessibility of the main method. We had to do something similar recently with the premain method (java.lang.instrument).

Absolutely we need to clarify that, however, the discussion of what should or should not be allowed may take some time. For example, if we limit such usage in launcher, should it be possible for custom launcher to start such a main method? Thus the recommendation to have a separate ticket for that.

The current java document mostly only say to load the specify the class name, however there is a sentence `By default, the first argument that isn't an option of the java command is the fully qualified name of the class to be called. If -jar is specified, then its argument is the name of the JAR file containing class and resource files for the application. The startup class must be indicated by the Main-Class manifest header in its manifest file.`. Not that it says `fully qualified name of the class`.

Filed [JDK-8263735](https://bugs.openjdk.java.net/browse/JDK-8263735) for the follow up, in the mean time, we should get this crash resolved.

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

PR: https://git.openjdk.java.net/jdk/pull/2999

From rriggs at openjdk.java.net  Wed Mar 17 16:32:48 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 17 Mar 2021 16:32:48 GMT
Subject: RFR: 8254979: Class.getSimpleName() returns non-empty for lambda
 and method
In-Reply-To: <Thw0UcKlw3o568qxq0flp2d5grp9Kx80hSMVuo9fITw=.730127b3-e187-499c-86e9-de85bca1a2c5@github.com>
References: <Thw0UcKlw3o568qxq0flp2d5grp9Kx80hSMVuo9fITw=.730127b3-e187-499c-86e9-de85bca1a2c5@github.com>
Message-ID: <tOg47aXaXC0vsjADO3lRX9V3mnlLPF3HuI8q35x-Vas=.2285b863-0a60-4458-b721-9056bc9cf481@github.com>

On Tue, 16 Mar 2021 22:24:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> java.lang.Class has a number of methods to return some kind of textual token associated with the class, including a type name, canonical name, simple name, and separately the results of toString().
> 
> Bug 8254979 notes that getSimpleName mentions returning the name in source code, but operationally returns a non-null result for synthetic classes, ones without benefit of source code representation. Since it is useful to return a non-null result in such cases, I've updated the spec to mention this case. The names of synthetic classes are not covered by the JLS; using a "$" in such names is customary, but not strictly required. The synthetic classes used to implement lambdas and method references as cited in the bug report include "$"'s.
> 
> Looking over the other "getFooName" methods, I don't think they need to be updated to handle this case.

Marked as reviewed by rriggs (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3038

From iklam at openjdk.java.net  Wed Mar 17 16:38:48 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 17 Mar 2021 16:38:48 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
Message-ID: <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>

On Wed, 17 Mar 2021 15:18:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> test/jdk/java/lang/ProcessBuilder/Basic.java line 2183:
>> 
>>> 2181:                 latch.await();
>>> 2182:                 Thread.sleep(100L);     // Wait for child initialization to settle
>>> 2183: 
>> 
>> Hi Roger,
>> Shouldn't the code that follows this sleep already be enough to wait for child thread to get a lock on the stream?
>> 
>>                 Thread.sleep(100L);     // Wait for child initialization to settle
>> 
>>                 if (s instanceof BufferedInputStream) {
>>                     // Wait until after the s.read occurs in "thread" by
>>                     // checking when the input stream monitor is acquired
>>                     // (BufferedInputStream.read is synchronized)
>>                     while (!isLocked(s, 10)) {
>>                         Thread.sleep(100);
>>                     }
>>                 }
>>   
>> 
>> From 1st glance I would conclude that the 1st sleep is unnecessary. Is there a platform where Input/Error stream is not a BufferedInputStream? Or is it calling Process.destory() immediately after the child thread enters BufferedInputStream.read synchronized method perhaps too early to trigger appropriate exception in the child thread? In that case the additional sleep should be added after the while(!isLocked... loop.
>
> That loop is checking that the Thread (in the parent) reading from the child is in the correct state (blocked).  On Windows, it is a BufferedInputStream.
> 
> But it does not indicate anything about the state of the child process.
> From the scant information from previous failures, it appears that the the creation of some thread (not a java thread) in the child has failed.
> The additional time is to avoid destroying the child while it is still initializing.

The failures happened in tiers 6 and 8. The system may be overloaded so even 100ms may not be enough for the child process to start sleeping. From the error log, the child process tried to spawn a thread (probably one of those usually started during VM bootstrap) at around 118ms

[0.118s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: 

The test runs 4 times. Each time it checks only STDOUT or STDERR, but not both. So I think we can use the other stream to signal to the main process that the child process is ready. That would be more reliable than an arbitrary wait time.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From mchung at openjdk.java.net  Wed Mar 17 16:42:51 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 17 Mar 2021 16:42:51 GMT
Subject: RFR: 8254979: Class.getSimpleName() returns non-empty for lambda
 and method
In-Reply-To: <Thw0UcKlw3o568qxq0flp2d5grp9Kx80hSMVuo9fITw=.730127b3-e187-499c-86e9-de85bca1a2c5@github.com>
References: <Thw0UcKlw3o568qxq0flp2d5grp9Kx80hSMVuo9fITw=.730127b3-e187-499c-86e9-de85bca1a2c5@github.com>
Message-ID: <KMKa_jnlXGt2yL22d2G_3UMGxIJ4Dp9-xnkKsAdkNkc=.bc28b6e4-0d90-4fbb-8a11-c85f9f13a288@github.com>

On Tue, 16 Mar 2021 22:24:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> java.lang.Class has a number of methods to return some kind of textual token associated with the class, including a type name, canonical name, simple name, and separately the results of toString().
> 
> Bug 8254979 notes that getSimpleName mentions returning the name in source code, but operationally returns a non-null result for synthetic classes, ones without benefit of source code representation. Since it is useful to return a non-null result in such cases, I've updated the spec to mention this case. The names of synthetic classes are not covered by the JLS; using a "$" in such names is customary, but not strictly required. The synthetic classes used to implement lambdas and method references as cited in the bug report include "$"'s.
> 
> Looking over the other "getFooName" methods, I don't think they need to be updated to handle this case.

Marked as reviewed by mchung (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3038

From rriggs at openjdk.java.net  Wed Mar 17 16:43:49 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 17 Mar 2021 16:43:49 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
Message-ID: <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>

On Wed, 17 Mar 2021 16:36:19 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> That loop is checking that the Thread (in the parent) reading from the child is in the correct state (blocked).  On Windows, it is a BufferedInputStream.
>> 
>> But it does not indicate anything about the state of the child process.
>> From the scant information from previous failures, it appears that the the creation of some thread (not a java thread) in the child has failed.
>> The additional time is to avoid destroying the child while it is still initializing.
>
> The failures happened in tiers 6 and 8. The system may be overloaded so even 100ms may not be enough for the child process to start sleeping. From the error log, the child process tried to spawn a thread (probably one of those usually started during VM bootstrap) at around 118ms
> 
> [0.118s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: 
> 
> The test runs 4 times. Each time it checks only STDOUT or STDERR, but not both. So I think we can use the other stream to signal to the main process that the child process is ready. That would be more reliable than an arbitrary wait time.

That complicates the test and the child quite a bit for minimal gain.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From herrick at openjdk.java.net  Wed Mar 17 16:46:49 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 16:46:49 GMT
Subject: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations
In-Reply-To: <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
Message-ID: <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>

On Sun, 14 Mar 2021 12:06:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 
> 
> Have you looked at narrowing the use of the SuppressWarnings to local variable declarations to avoid adding it to some of these methods?

in all cases either:
 - the class or method itself is being deprecated
 - the method takes a deprecated arg .
 - there is no local variable involved, such as testing if something  is an instanceOf a class being deprecated, or calling a deprecated method.

I cannot find any instances where the scope can be narrowed

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

PR: https://git.openjdk.java.net/jdk/pull/2920

From darcy at openjdk.java.net  Wed Mar 17 16:50:00 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 17 Mar 2021 16:50:00 GMT
Subject: RFR: 8263726: divideToIntegralValue typo on BigDecimal documentation
Message-ID: <se4T2wCOeOrcXlQAk8eDbSzGBZcKOZFSib-WRySvNaU=.69c2e5cf-6bb1-469a-ae86-ecccd020a525@github.com>

Fix typos in references to the method's name in the javadoc.

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

Commit messages:
 - 8263726: divideToIntegralValue typo on BigDecimal documentation

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

PR: https://git.openjdk.java.net/jdk/pull/3051

From bpb at openjdk.java.net  Wed Mar 17 16:53:52 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 17 Mar 2021 16:53:52 GMT
Subject: RFR: 8263726: divideToIntegralValue typo on BigDecimal
 documentation
In-Reply-To: <se4T2wCOeOrcXlQAk8eDbSzGBZcKOZFSib-WRySvNaU=.69c2e5cf-6bb1-469a-ae86-ecccd020a525@github.com>
References: <se4T2wCOeOrcXlQAk8eDbSzGBZcKOZFSib-WRySvNaU=.69c2e5cf-6bb1-469a-ae86-ecccd020a525@github.com>
Message-ID: <hW7fknNVrS9vtssr2Nhi6_q51YB3zo6CMCe_3WhEHoA=.f43a31d7-5d27-44ec-98fd-5814cb0a6fa8@github.com>

On Wed, 17 Mar 2021 16:43:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix typos in references to the method's name in the javadoc.

Looks fine.

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3051

From darcy at openjdk.java.net  Wed Mar 17 17:01:50 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 17 Mar 2021 17:01:50 GMT
Subject: Integrated: 8263726: divideToIntegralValue typo on BigDecimal
 documentation
In-Reply-To: <se4T2wCOeOrcXlQAk8eDbSzGBZcKOZFSib-WRySvNaU=.69c2e5cf-6bb1-469a-ae86-ecccd020a525@github.com>
References: <se4T2wCOeOrcXlQAk8eDbSzGBZcKOZFSib-WRySvNaU=.69c2e5cf-6bb1-469a-ae86-ecccd020a525@github.com>
Message-ID: <gyEk80lpqcSlWDImtPtScH6ZDOMLHEU6w2pVQ6IeZiA=.033a91cf-07cb-444e-9a28-0a4006049fa1@github.com>

On Wed, 17 Mar 2021 16:43:42 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Fix typos in references to the method's name in the javadoc.

This pull request has now been integrated.

Changeset: 24afa36d
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/24afa36d
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8263726: divideToIntegralValue typo on BigDecimal documentation

Reviewed-by: bpb

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

PR: https://git.openjdk.java.net/jdk/pull/3051

From bpb at openjdk.java.net  Wed Mar 17 17:01:49 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 17 Mar 2021 17:01:49 GMT
Subject: RFR: 8251942: PrintStream specification is not clear which flush
 method is automatically invoked
In-Reply-To: <uGvoyiqi8a4sNbQftdUO682Z-tnUROumajylIFFQ5aU=.15e88ed3-8d4d-4f98-ab83-0db18eb63a9f@github.com>
References: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>
 <_rcwtsbpgGeofhUDJtRWlQylkUmw78cwR9ZOy6dH470=.1826a6ba-d823-4ac1-90ff-e26f8d94dbc5@github.com>
 <uGvoyiqi8a4sNbQftdUO682Z-tnUROumajylIFFQ5aU=.15e88ed3-8d4d-4f98-ab83-0db18eb63a9f@github.com>
Message-ID: <wOj7QqqLT8BEWmvqoOuKcILWuUp4d-R5ZLbSzIWhv3w=.70b03fd1-edea-4d51-8107-26ddae4488fa@github.com>

On Thu, 11 Mar 2021 20:54:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> Yes, I noticed that as well. I didn?t think it was worth complicating things for the purpose of this issue to address it.
>> 
>> I guess what I was trying to ask is whether we should actually specify that `print` and `append` call `flush` - as this seems to be a side effect of some optimization.
>> Maybe we should say that the implementation ensures that flush is called when writing a byte array or when  a newline character or byte ({@code '\n'}) is written - but might call it in additional unspecified circumstances?
>
> I think you are correct. In the second commit I scaled back the change to the class level specification. I left out any mention of "unspecified circumstances."

Is there any further comment on this request? Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/2926

From iklam at openjdk.java.net  Wed Mar 17 17:16:48 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 17 Mar 2021 17:16:48 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
Message-ID: <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>

On Wed, 17 Mar 2021 16:40:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The failures happened in tiers 6 and 8. The system may be overloaded so even 100ms may not be enough for the child process to start sleeping. From the error log, the child process tried to spawn a thread (probably one of those usually started during VM bootstrap) at around 118ms
>> 
>> [0.118s][warning][os,thread] Failed to start thread - _beginthreadex failed (EACCES) for attributes: stacksize: default, flags: 
>> 
>> The test runs 4 times. Each time it checks only STDOUT or STDERR, but not both. So I think we can use the other stream to signal to the main process that the child process is ready. That would be more reliable than an arbitrary wait time.
>
> That complicates the test and the child quite a bit for minimal gain.

Arbitrary time out has been a reliable source of intermittent failures.

Since we have spent a lot of time analyzing this failure, I think it's worthwhile to fix it properly, which doesn't seem that complicated. That's better than the same bug happening again a year later and a different set of people would spend hours to analyze it again.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From stuefe at openjdk.java.net  Wed Mar 17 17:32:49 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 17 Mar 2021 17:32:49 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
Message-ID: <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>

On Wed, 17 Mar 2021 17:14:22 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> That complicates the test and the child quite a bit for minimal gain.
>
> Arbitrary time out has been a reliable source of intermittent failures.
> 
> Since we have spent a lot of time analyzing this failure, I think it's worthwhile to fix it properly, which doesn't seem that complicated. That's better than the same bug happening again a year later and a different set of people would spend hours to analyze it again.

I don't think this is CPU starvation but memory exhaustion. _beginthreadex fails with EACCES if it has no resources to start the thread, which in this case probably means memory (the other possibility would be out-of-HANDLE-space but seeing that the child just started I don't see how this could be).

Should we harden tests against resource starvation like this, or rather require the test machine to be beefy enough for tests? Also, I don't understand, if the child has not enough resources to bring the VM fully up how waiting on either stream would help.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From rriggs at openjdk.java.net  Wed Mar 17 17:43:48 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 17 Mar 2021 17:43:48 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
 <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
Message-ID: <S-tjnHtUp4kSXWbXJ-y5BbXh99niDflP0KAPrH-EjIo=.e1ac30ac-eefe-4619-9e29-9a65dd847e07@github.com>

On Wed, 17 Mar 2021 17:30:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Arbitrary time out has been a reliable source of intermittent failures.
>> 
>> Since we have spent a lot of time analyzing this failure, I think it's worthwhile to fix it properly, which doesn't seem that complicated. That's better than the same bug happening again a year later and a different set of people would spend hours to analyze it again.
>
> I don't think this is CPU starvation but memory exhaustion. _beginthreadex fails with EACCES if it has no resources to start the thread, which in this case probably means memory (the other possibility would be out-of-HANDLE-space but seeing that the child just started I don't see how this could be).
> 
> Should we harden tests against resource starvation like this, or rather require the test machine to be beefy enough for tests? Also, I don't understand, if the child has not enough resources to bring the VM fully up how waiting on either stream would help.

I'm not sure what part of the system or tests should be more robust.
If the VM can't tolerate the failure of a thread to start, then it should be a fatal VM error, not just an unexpected line on stdout (or it should be able to proceed without the extra thread).
It is a reasonable position to take that when a process is destroyed, there can be unpredictable effects.
Though in various iterations, attempts have been made to shutdown in an orderly fashion, coupled to calls to System.exit() or SIGTERM.
(It would be nice if Windows had a way to do a cleanly request process termination - a SIGTERM equivalent does not exist.)
Avoidance may be easiest but may just hide another problem.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From iklam at openjdk.java.net  Wed Mar 17 17:55:54 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 17 Mar 2021 17:55:54 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
 <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
Message-ID: <Qj6Ch7nKS2pBcAw0Du-ZD8_CeyOEviSOSwxMGyCX_q4=.aa182b6d-f2d3-4cbf-a9d6-8374ace9e177@github.com>

On Wed, 17 Mar 2021 17:30:25 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Arbitrary time out has been a reliable source of intermittent failures.
>> 
>> Since we have spent a lot of time analyzing this failure, I think it's worthwhile to fix it properly, which doesn't seem that complicated. That's better than the same bug happening again a year later and a different set of people would spend hours to analyze it again.
>
> I don't think this is CPU starvation but memory exhaustion. _beginthreadex fails with EACCES if it has no resources to start the thread, which in this case probably means memory (the other possibility would be out-of-HANDLE-space but seeing that the child just started I don't see how this could be).
> 
> Should we harden tests against resource starvation like this, or rather require the test machine to be beefy enough for tests? Also, I don't understand, if the child has not enough resources to bring the VM fully up how waiting on either stream would help.

@tstuefe It's unlikely that _beginthreadex failed due to lack of memory. We are running on a machine with more than 50GB ram with only concurrency of 6.  Extracts from the logs:

$ jtreg -vmoption:-Xmx512m -concurrency:6 -vmoption:-XX:MaxRAMPercentage=4 .... open/test/jdk:jdk_lang

start = Wed Mar 10 22:54:53 GMT 2021
end = Wed Mar 10 22:56:36 GMT 2021
elapsed= 102932 0:01:42.932

----------------------------------------
[2021-03-10 22:57:07] [C:\cygwin\bin\free.exe] timeout=20000
----------------------------------------
              total used free shared buff/cache available
Mem: 50068964 19974888 30094076 0 0 30094076
Swap: 8388608 105048 8283560
----------------------------------------
[2021-03-10 22:57:07] exit code: 0 time: 33 ms
----------------------------------------

My theory is that `TerminateProcess` has made it impossible for the child process to spawn new threads, but somehow existing threads are still able to run a little bit and produce the log message.

Of course this is just a theory, and I cannot find any supporting docs from MS. However, if we implement the work around and make sure we don't kill the child until it has finished bootstrapping, and the bug doesn't happen anymore, then we know something more.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From redestad at openjdk.java.net  Wed Mar 17 17:57:08 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 17 Mar 2021 17:57:08 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups [v6]
In-Reply-To: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
Message-ID: <bGd_ewe18lzTbzeWgZs_bGn58382PYWe3a57UeyzEq8=.549d5373-46a2-4be5-afd0-158e344a40f0@github.com>

> - Remove unused code
> - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc)
> - Apply pattern matching to make some code more readable

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Mandy review + additional cleanup

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2300/files
  - new: https://git.openjdk.java.net/jdk/pull/2300/files/b20073e3..62ec7a40

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=04-05

  Stats: 56 lines in 2 files changed: 11 ins; 17 del; 28 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2300.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2300/head:pull/2300

PR: https://git.openjdk.java.net/jdk/pull/2300

From redestad at openjdk.java.net  Wed Mar 17 18:00:56 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 17 Mar 2021 18:00:56 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups [v5]
In-Reply-To: <fI5otZLn-AT6frAJO6TRSRVhmJJmIDMn0eiQJxGzj78=.635016a6-7550-442e-b077-ceae03b8e7b1@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
 <1RcjLNIE3UTsIOYOo2nxNcKG4_GNta2vLAbIXlrhXAc=.d8e39c90-8923-406f-9143-8b66c0361b81@github.com>
 <fI5otZLn-AT6frAJO6TRSRVhmJJmIDMn0eiQJxGzj78=.635016a6-7550-442e-b077-ceae03b8e7b1@github.com>
Message-ID: <n-cpk_gG5IGQPJKSvt30Hjiunbj2iIq_3Sw8tIJ5WpQ=.5796f4ad-6aaa-4a3d-a7d9-e1bfe33f0497@github.com>

On Mon, 15 Mar 2021 18:10:56 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Claes Redestad has updated the pull request with a new target base 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:
>> 
>>  - Revert pattern matching changes covered by #2913
>>  - Merge branch 'master' into invoke_cleanup
>>  - Missing .values
>>  - More cleanup, reduce allocations in InvokerBytecodeGenerator
>>  - Missing outstanding changes
>>  - Avoid unnecessary reboxing checks, inline and simplify class/mt invokes
>>  - j.l.invoke cleanups
>
> src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 151:
> 
>> 149:                     maybeReBoxElements(argv);
>> 150:                     if (argv.length > 6) {
>> 151:                         result = invokeWithManyArguments(bootstrapMethod, caller, name, type, argv);
> 
> it'd be cleaner to move this to the default case in line 162 and 174 instead of having this special if-block.

Good catch!

> src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 342:
> 
>> 340:         setClassWriter(cw);
>> 341:         cw.visit(Opcodes.V1_8, NOT_ACC_PUBLIC + Opcodes.ACC_FINAL + Opcodes.ACC_SUPER,
>> 342:                 CLASS_PREFIX.concat(className), null, INVOKER_SUPER_NAME, null);
> 
> I prefer to use the existing common pattern using `+` as I believe this gain is in the noise.

The goal here was to remove/reduce allocations and excess calls - and using String.concat might have been excessive.

The bulk of the overhead is the potentially many `CLASS_PREFIX + className` calls, often via `className()`. Calculating this once and storing it in an instance field `prefixedClassName` is more profitable and help better disambiguates between `className` and `className()` - which sound like they should be the same but aren't.

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

PR: https://git.openjdk.java.net/jdk/pull/2300

From redestad at openjdk.java.net  Wed Mar 17 18:04:49 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 17 Mar 2021 18:04:49 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups [v6]
In-Reply-To: <fI5otZLn-AT6frAJO6TRSRVhmJJmIDMn0eiQJxGzj78=.635016a6-7550-442e-b077-ceae03b8e7b1@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
 <1RcjLNIE3UTsIOYOo2nxNcKG4_GNta2vLAbIXlrhXAc=.d8e39c90-8923-406f-9143-8b66c0361b81@github.com>
 <fI5otZLn-AT6frAJO6TRSRVhmJJmIDMn0eiQJxGzj78=.635016a6-7550-442e-b077-ceae03b8e7b1@github.com>
Message-ID: <clD4cEZFr4HLpaqQJ-WRKlfiqik8etd0POOZr_yrjwc=.ef84f1ce-9219-4fb8-b9ee-3ae8d6b3a1ff@github.com>

On Mon, 15 Mar 2021 18:27:04 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Mandy review + additional cleanup
>
> src/java.base/share/classes/java/lang/invoke/MethodType.java line 418:
> 
>> 416:     public MethodType changeParameterType(int num, Class<?> nptype) {
>> 417:         if (parameterType(num) == nptype)  return this;
>> 418:         checkPtype(nptype);
> 
> `nptype` is never void but  what  about the check if `nptype` is not null?

Other methods that delegate to `makeImpl` aren't doing up-front validation, so this change was made to get things more in line. It might be good to spell out that `makeImpl` does these checks for all its callers, though. (The `makeImpl` fast-path that execute before the validation can never return an invalid MethodType)

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

PR: https://git.openjdk.java.net/jdk/pull/2300

From mchung at openjdk.java.net  Wed Mar 17 18:18:51 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 17 Mar 2021 18:18:51 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups [v6]
In-Reply-To: <clD4cEZFr4HLpaqQJ-WRKlfiqik8etd0POOZr_yrjwc=.ef84f1ce-9219-4fb8-b9ee-3ae8d6b3a1ff@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
 <1RcjLNIE3UTsIOYOo2nxNcKG4_GNta2vLAbIXlrhXAc=.d8e39c90-8923-406f-9143-8b66c0361b81@github.com>
 <fI5otZLn-AT6frAJO6TRSRVhmJJmIDMn0eiQJxGzj78=.635016a6-7550-442e-b077-ceae03b8e7b1@github.com>
 <clD4cEZFr4HLpaqQJ-WRKlfiqik8etd0POOZr_yrjwc=.ef84f1ce-9219-4fb8-b9ee-3ae8d6b3a1ff@github.com>
Message-ID: <d-a_3vLfi1ENW0rB7rVaYdy1e5SsIDrqcBi0PrK8xdc=.eae6b053-90f9-4d3b-8eb7-67d12fbda1f8@github.com>

On Wed, 17 Mar 2021 18:02:07 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodType.java line 418:
>> 
>>> 416:     public MethodType changeParameterType(int num, Class<?> nptype) {
>>> 417:         if (parameterType(num) == nptype)  return this;
>>> 418:         checkPtype(nptype);
>> 
>> `nptype` is never void but  what  about the check if `nptype` is not null?
>
> Other methods that delegate to `makeImpl` aren't doing up-front validation, so this change was made to get things more in line. It might be good to spell out that `makeImpl` does these checks for all its callers, though. (The `makeImpl` fast-path that execute before the validation can never return an invalid MethodType)

Generally we have a public API implementation to check the arguments upfront for readability.  In particular for this case, the validation cost is negligible and removing the validation makes the code unclear where the validation is done.  I prefer to keep the validation there.   It should check that `nptype` is non-null and not `void.class`.

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

PR: https://git.openjdk.java.net/jdk/pull/2300

From chegar at openjdk.java.net  Wed Mar 17 18:20:48 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 17 Mar 2021 18:20:48 GMT
Subject: RFR: 8263108: Class initialization deadlock in java.lang.constant
 [v5]
In-Reply-To: <KW2gXeCkU_TaF2Y4WMfXdTEwgVCDSFubBU1xtkw54Q0=.4124ed7d-f482-4112-aa09-443507b6c77f@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
 <KW2gXeCkU_TaF2Y4WMfXdTEwgVCDSFubBU1xtkw54Q0=.4124ed7d-f482-4112-aa09-443507b6c77f@github.com>
Message-ID: <VfODp7wzjb83bNATgHTchIK5tmtIcRWQi51guJon2vU=.89eb48e7-6bc4-4acf-9436-b17665e0a27e@github.com>

On Tue, 16 Mar 2021 14:47:29 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this proposed patch for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8263108?
>> 
>> As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and `java.lang.constant.ConstantDescs` can end up in a classloading deadlock due to the nature of the code involved in their static blocks. A thread dump of one such deadlock (reproduced using the code attached to that issue) is as follows:
>> 
>> "Thread A" #14 prio=5 os_prio=31 cpu=101.45ms elapsed=8.30s tid=0x00007ff88e01ca00 nid=0x6003 in Object.wait()  [0x000070000a4c6000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.DynamicConstantDesc.<clinit>(java.base at 16-ea/DynamicConstantDesc.java:67)
>> 	- waiting on the Class initialization monitor for java.lang.constant.ConstantDescs
>> 	at Deadlock.threadA(Deadlock.java:14)
>> 	at Deadlock$$Lambda$1/0x0000000800c00a08.run(Unknown Source)
>> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
>> 
>> "Thread B" #15 prio=5 os_prio=31 cpu=103.15ms elapsed=8.30s tid=0x00007ff88b936a00 nid=0x9b03 in Object.wait()  [0x000070000a5c9000]
>>    java.lang.Thread.State: RUNNABLE
>> 	at java.lang.constant.ClassDesc.ofDescriptor(java.base at 16-ea/ClassDesc.java:145)
>> 	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc
>> 	at java.lang.constant.ConstantDescs.<clinit>(java.base at 16-ea/ConstantDescs.java:239)
>> 	at Deadlock.threadB(Deadlock.java:24)
>> 	at Deadlock$$Lambda$2/0x0000000800c00c28.run(Unknown Source)
>> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
>> 
>> The commit in this PR resolves that deadlock by moving the `canonicalMap` initialization in `DynamicConstantDesc`, from the static block, to a lazily initialized map, into the `tryCanonicalize` (private) method of the same class. That's the only method which uses this map.
>> 
>> The implementation in `tryCanonicalize` carefully ensures that the deadlock isn't shifted from the static block to this method, by making sure that the `synchronization` on `DynamicConstantDesc` in this method happens only when it's time to write the state to the shared `canonicalMap`. This has an implication that the method local variable `canonDescs` can get initialized by multiple threads unnecessarily but from what I can see, that's the only way we can avoid this deadlock. This penalty of multiple threads initializing and then throwing away that map isn't too huge because that will happen only once when the `canonicalMap` is being initialized for the first time.
>> 
>> An alternate approach that I thought of was to completely get rid of this shared cache `canonicalMap` and instead just use method level map (that gets initialized each time) in the `tryCanonicalize` method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.
>> 
>> The commit in this PR also includes a jtreg testcase which (consistently) reproduces the deadlock without the fix and passes when this fix is applied. Extra manual testing has been done to verify that the classes of interest (noted in that testcase) are indeed getting loaded in those concurrent threads and not in the main thread. For future maintainers, there's a implementation note added on that testcase explaining why it cannot be moved into testng test.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a comment to instruct future maintainers of the code to avoid calling DynamicConstantDesc.ofCanonical() from static initialization of java.lang.constant.ConstantDescs

Marked as reviewed by chegar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From mchung at openjdk.java.net  Wed Mar 17 18:28:55 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 17 Mar 2021 18:28:55 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups [v6]
In-Reply-To: <bGd_ewe18lzTbzeWgZs_bGn58382PYWe3a57UeyzEq8=.549d5373-46a2-4be5-afd0-158e344a40f0@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
 <bGd_ewe18lzTbzeWgZs_bGn58382PYWe3a57UeyzEq8=.549d5373-46a2-4be5-afd0-158e344a40f0@github.com>
Message-ID: <Sr50I4gXO5bfTDa3uHf1Q6WVE2GblXK7RZJXv0SzhlE=.ab4b7a48-6ba0-4ae8-b2bc-90ef2dfe27c0@github.com>

On Wed, 17 Mar 2021 17:57:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - Remove unused code
>> - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc)
>> - Apply pattern matching to make some code more readable
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Mandy review + additional cleanup

src/java.base/share/classes/java/lang/invoke/InvokerBytecodeGenerator.java line 88:

> 86:     /** Name of new class */
> 87:     private final String className;
> 88:     private final String prefixedClassName;

Adding a field for the class name is a good change.   I was tempted to rename `className` at one point to `name` which can be a class name in internal form or a simple name.   It now makes more sense to do the renaming `s/className/name` and `s/prefixedClassName/className`.   What do you think?

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

PR: https://git.openjdk.java.net/jdk/pull/2300

From alanb at openjdk.java.net  Wed Mar 17 19:05:52 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 17 Mar 2021 19:05:52 GMT
Subject: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations
In-Reply-To: <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
 <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
Message-ID: <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>

On Wed, 17 Mar 2021 16:44:19 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> I cannot find any instances where the scope can be narrowed

Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?

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

PR: https://git.openjdk.java.net/jdk/pull/2920

From redestad at openjdk.java.net  Wed Mar 17 19:12:10 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 17 Mar 2021 19:12:10 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups [v7]
In-Reply-To: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
Message-ID: <sI24oJz0ZwCe9ls3DD5_rgM1uKYCmg8XV2gklxZfES4=.ab63c41b-64a7-48a9-9056-3e9df221a1ce@github.com>

> - Remove unused code
> - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc)
> - Apply pattern matching to make some code more readable

Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:

  Rename className -> name, prefixedClassName -> className, makeImpl input validation commentary

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2300/files
  - new: https://git.openjdk.java.net/jdk/pull/2300/files/62ec7a40..0f9f5efa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2300&range=05-06

  Stats: 34 lines in 2 files changed: 5 ins; 5 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2300.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2300/head:pull/2300

PR: https://git.openjdk.java.net/jdk/pull/2300

From stuefe at openjdk.java.net  Wed Mar 17 19:15:47 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 17 Mar 2021 19:15:47 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <Qj6Ch7nKS2pBcAw0Du-ZD8_CeyOEviSOSwxMGyCX_q4=.aa182b6d-f2d3-4cbf-a9d6-8374ace9e177@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
 <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
 <Qj6Ch7nKS2pBcAw0Du-ZD8_CeyOEviSOSwxMGyCX_q4=.aa182b6d-f2d3-4cbf-a9d6-8374ace9e177@github.com>
Message-ID: <umSS-izv_LUAJodEw_jSxvK9CrSArZxbjhcB-2OB6G4=.88e925b0-0001-4b7c-ba9c-fd2a3dff9afb@github.com>

On Wed, 17 Mar 2021 17:53:14 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> I don't think this is CPU starvation but memory exhaustion. _beginthreadex fails with EACCES if it has no resources to start the thread, which in this case probably means memory (the other possibility would be out-of-HANDLE-space but seeing that the child just started I don't see how this could be).
>> 
>> Should we harden tests against resource starvation like this, or rather require the test machine to be beefy enough for tests? Also, I don't understand, if the child has not enough resources to bring the VM fully up how waiting on either stream would help.
>
> @tstuefe It's unlikely that _beginthreadex failed due to lack of memory. We are running on a machine with more than 50GB ram with only concurrency of 6.  Extracts from the logs:
> 
> $ jtreg -vmoption:-Xmx512m -concurrency:6 -vmoption:-XX:MaxRAMPercentage=4 .... open/test/jdk:jdk_lang
> 
> start = Wed Mar 10 22:54:53 GMT 2021
> end = Wed Mar 10 22:56:36 GMT 2021
> elapsed= 102932 0:01:42.932
> 
> ----------------------------------------
> [2021-03-10 22:57:07] [C:\cygwin\bin\free.exe] timeout=20000
> ----------------------------------------
>               total used free shared buff/cache available
> Mem: 50068964 19974888 30094076 0 0 30094076
> Swap: 8388608 105048 8283560
> ----------------------------------------
> [2021-03-10 22:57:07] exit code: 0 time: 33 ms
> ----------------------------------------
> 
> My theory is that `TerminateProcess` has made it impossible for the child process to spawn new threads, but somehow existing threads are still able to run a little bit and produce the log message.
> 
> Of course this is just a theory, and I cannot find any supporting docs from MS. However, if we implement the work around and make sure we don't kill the child until it has finished bootstrapping, and the bug doesn't happen anymore, then we know something more.

Hmm. That's strange. 

One issue I don't understand with this test, should the parent not read from both streams simultaneously, because if the child is sending output to the stream the parent is not reading from the child may block on write? 

This depends on file io buffer size of course but if the child writes some larger output into e.g. stderr while the parent reads stdout, parent will wait on stdout and child will wait on the write to stderr finishing. So, either we should read both streams or redirect the stream we are not interested in to paren'ts stdout/stderr where hopefully the testrunner itself would read it.

I may misunderstand the test completely; if yes, sorry for the confusion!

Thomas

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From rriggs at openjdk.java.net  Wed Mar 17 19:15:47 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 17 Mar 2021 19:15:47 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <umSS-izv_LUAJodEw_jSxvK9CrSArZxbjhcB-2OB6G4=.88e925b0-0001-4b7c-ba9c-fd2a3dff9afb@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
 <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
 <Qj6Ch7nKS2pBcAw0Du-ZD8_CeyOEviSOSwxMGyCX_q4=.aa182b6d-f2d3-4cbf-a9d6-8374ace9e177@github.com>
 <umSS-izv_LUAJodEw_jSxvK9CrSArZxbjhcB-2OB6G4=.88e925b0-0001-4b7c-ba9c-fd2a3dff9afb@github.com>
Message-ID: <xDMPEwAZVeVlclHy7JVUHnT6KiGMj0eDO1Fom8R3VIA=.7ac05900-a527-4e73-8206-ceed49cf8961@github.com>

On Wed, 17 Mar 2021 19:10:24 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> @tstuefe It's unlikely that _beginthreadex failed due to lack of memory. We are running on a machine with more than 50GB ram with only concurrency of 6.  Extracts from the logs:
>> 
>> $ jtreg -vmoption:-Xmx512m -concurrency:6 -vmoption:-XX:MaxRAMPercentage=4 .... open/test/jdk:jdk_lang
>> 
>> start = Wed Mar 10 22:54:53 GMT 2021
>> end = Wed Mar 10 22:56:36 GMT 2021
>> elapsed= 102932 0:01:42.932
>> 
>> ----------------------------------------
>> [2021-03-10 22:57:07] [C:\cygwin\bin\free.exe] timeout=20000
>> ----------------------------------------
>>               total used free shared buff/cache available
>> Mem: 50068964 19974888 30094076 0 0 30094076
>> Swap: 8388608 105048 8283560
>> ----------------------------------------
>> [2021-03-10 22:57:07] exit code: 0 time: 33 ms
>> ----------------------------------------
>> 
>> My theory is that `TerminateProcess` has made it impossible for the child process to spawn new threads, but somehow existing threads are still able to run a little bit and produce the log message.
>> 
>> Of course this is just a theory, and I cannot find any supporting docs from MS. However, if we implement the work around and make sure we don't kill the child until it has finished bootstrapping, and the bug doesn't happen anymore, then we know something more.
>
> Hmm. That's strange. 
> 
> One issue I don't understand with this test, should the parent not read from both streams simultaneously, because if the child is sending output to the stream the parent is not reading from the child may block on write? 
> 
> This depends on file io buffer size of course but if the child writes some larger output into e.g. stderr while the parent reads stdout, parent will wait on stdout and child will wait on the write to stderr finishing. So, either we should read both streams or redirect the stream we are not interested in to paren'ts stdout/stderr where hopefully the testrunner itself would read it.
> 
> I may misunderstand the test completely; if yes, sorry for the confusion!
> 
> Thomas

The child does no (zero) writes to either stream.  It is invoked only to sleep until it is destroyed.
The purpose of the test is to verify the exception that is thrown when the other end(child) of the pipe is closed (because the process has been forcibly terminated).

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From iklam at openjdk.java.net  Wed Mar 17 19:33:49 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Wed, 17 Mar 2021 19:33:49 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <xDMPEwAZVeVlclHy7JVUHnT6KiGMj0eDO1Fom8R3VIA=.7ac05900-a527-4e73-8206-ceed49cf8961@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
 <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
 <Qj6Ch7nKS2pBcAw0Du-ZD8_CeyOEviSOSwxMGyCX_q4=.aa182b6d-f2d3-4cbf-a9d6-8374ace9e177@github.com>
 <umSS-izv_LUAJodEw_jSxvK9CrSArZxbjhcB-2OB6G4=.88e925b0-0001-4b7c-ba9c-fd2a3dff9afb@github.com>
 <xDMPEwAZVeVlclHy7JVUHnT6KiGMj0eDO1Fom8R3VIA=.7ac05900-a527-4e73-8206-ceed49cf8961@github.com>
Message-ID: <4rkO_Fy5XHnekf9M8tDb2FX5xq4T5Xs73MitVYQUM-M=.7f2c40ef-a5c4-4a5a-8dc6-4b491b2fc294@github.com>

On Wed, 17 Mar 2021 19:13:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Hmm. That's strange. 
>> 
>> One issue I don't understand with this test, should the parent not read from both streams simultaneously, because if the child is sending output to the stream the parent is not reading from the child may block on write? 
>> 
>> This depends on file io buffer size of course but if the child writes some larger output into e.g. stderr while the parent reads stdout, parent will wait on stdout and child will wait on the write to stderr finishing. So, either we should read both streams or redirect the stream we are not interested in to paren'ts stdout/stderr where hopefully the testrunner itself would read it.
>> 
>> I may misunderstand the test completely; if yes, sorry for the confusion!
>> 
>> Thomas
>
> The child does no (zero) writes to either stream.  It is invoked only to sleep until it is destroyed.
> The purpose of the test is to verify the exception that is thrown when the other end(child) of the pipe is closed (because the process has been forcibly terminated).

Hmm, maybe the child can create a file to indicate that bootstrap has finished.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From mchung at openjdk.java.net  Wed Mar 17 19:33:52 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 17 Mar 2021 19:33:52 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups [v7]
In-Reply-To: <sI24oJz0ZwCe9ls3DD5_rgM1uKYCmg8XV2gklxZfES4=.ab63c41b-64a7-48a9-9056-3e9df221a1ce@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
 <sI24oJz0ZwCe9ls3DD5_rgM1uKYCmg8XV2gklxZfES4=.ab63c41b-64a7-48a9-9056-3e9df221a1ce@github.com>
Message-ID: <Fia4Wh5cerCH-fMRdnISU4bQajt9D3DnJW-8syTyK4w=.3f08932b-d82d-419f-a2db-400d1c35af6c@github.com>

On Wed, 17 Mar 2021 19:12:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> - Remove unused code
>> - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc)
>> - Apply pattern matching to make some code more readable
>
> Claes Redestad has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename className -> name, prefixedClassName -> className, makeImpl input validation commentary

Thanks for doing the renames.   Looks good.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2300

From mchung at openjdk.java.net  Wed Mar 17 19:33:53 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 17 Mar 2021 19:33:53 GMT
Subject: RFR: 8260605: Various java.lang.invoke cleanups [v7]
In-Reply-To: <d-a_3vLfi1ENW0rB7rVaYdy1e5SsIDrqcBi0PrK8xdc=.eae6b053-90f9-4d3b-8eb7-67d12fbda1f8@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
 <1RcjLNIE3UTsIOYOo2nxNcKG4_GNta2vLAbIXlrhXAc=.d8e39c90-8923-406f-9143-8b66c0361b81@github.com>
 <fI5otZLn-AT6frAJO6TRSRVhmJJmIDMn0eiQJxGzj78=.635016a6-7550-442e-b077-ceae03b8e7b1@github.com>
 <clD4cEZFr4HLpaqQJ-WRKlfiqik8etd0POOZr_yrjwc=.ef84f1ce-9219-4fb8-b9ee-3ae8d6b3a1ff@github.com>
 <d-a_3vLfi1ENW0rB7rVaYdy1e5SsIDrqcBi0PrK8xdc=.eae6b053-90f9-4d3b-8eb7-67d12fbda1f8@github.com>
Message-ID: <qvuXFU7Vf_TzhnmTw1UEltktWXj4486h6qGazEhC0h8=.35bf5bf9-82a8-450b-bfec-a392250b4269@github.com>

On Wed, 17 Mar 2021 18:15:37 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Other methods that delegate to `makeImpl` aren't doing up-front validation, so this change was made to get things more in line. It might be good to spell out that `makeImpl` does these checks for all its callers, though. (The `makeImpl` fast-path that execute before the validation can never return an invalid MethodType)
>
> Generally we have a public API implementation to check the arguments upfront for readability.  In particular for this case, the validation cost is negligible and removing the validation makes the code unclear where the validation is done.  I prefer to keep the validation there.   It should check that `nptype` is non-null and not `void.class`.

Ah, I mis-read your comment.   I now see that `makeImpl` does the argument validation.  Adding the comment would be helpful.

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

PR: https://git.openjdk.java.net/jdk/pull/2300

From stuefe at openjdk.java.net  Wed Mar 17 19:37:47 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 17 Mar 2021 19:37:47 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <4rkO_Fy5XHnekf9M8tDb2FX5xq4T5Xs73MitVYQUM-M=.7f2c40ef-a5c4-4a5a-8dc6-4b491b2fc294@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
 <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
 <Qj6Ch7nKS2pBcAw0Du-ZD8_CeyOEviSOSwxMGyCX_q4=.aa182b6d-f2d3-4cbf-a9d6-8374ace9e177@github.com>
 <umSS-izv_LUAJodEw_jSxvK9CrSArZxbjhcB-2OB6G4=.88e925b0-0001-4b7c-ba9c-fd2a3dff9afb@github.com>
 <xDMPEwAZVeVlclHy7JVUHnT6KiGMj0eDO1Fom8R3VIA=.7ac05900-a527-4e73-8206-ceed49cf8961@github.com>
 <4rkO_Fy5XHnekf9M8tDb2FX5xq4T5Xs73Mi
 tVYQUM-M=.7f2c40ef-a5c4-4a5a-8dc6-4b491b2fc294@github.com>
Message-ID: <MrSuzVAmYlo6IZzVaeO2v5t0bvypYkdrnZNj16MdcyQ=.fe36d884-d6a1-468b-852a-6627d7eab9ff@github.com>

On Wed, 17 Mar 2021 19:30:54 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> The child does no (zero) writes to either stream.  It is invoked only to sleep until it is destroyed.
>> The purpose of the test is to verify the exception that is thrown when the other end(child) of the pipe is closed (because the process has been forcibly terminated).
>
> Hmm, maybe the child can create a file to indicate that bootstrap has finished.

> The child does no (zero) writes to either stream. It is invoked only to sleep until it is destroyed.
> The purpose of the test is to verify the exception that is thrown when the other end(child) of the pipe is closed (because the process has been forcibly terminated).

I meant as a consequence of an error. E.g. a crash or a native OOM could cause the child to write an error report to stderr.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From stuefe at openjdk.java.net  Wed Mar 17 19:37:47 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 17 Mar 2021 19:37:47 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <MrSuzVAmYlo6IZzVaeO2v5t0bvypYkdrnZNj16MdcyQ=.fe36d884-d6a1-468b-852a-6627d7eab9ff@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
 <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
 <Qj6Ch7nKS2pBcAw0Du-ZD8_CeyOEviSOSwxMGyCX_q4=.aa182b6d-f2d3-4cbf-a9d6-8374ace9e177@github.com>
 <umSS-izv_LUAJodEw_jSxvK9CrSArZxbjhcB-2OB6G4=.88e925b0-0001-4b7c-ba9c-fd2a3dff9afb@github.com>
 <xDMPEwAZVeVlclHy7JVUHnT6KiGMj0eDO1Fom8R3VIA=.7ac05900-a527-4e73-8206-ceed49cf8961@github.com>
 <4rkO_Fy5XHnekf9M8tDb2FX5xq4T5Xs73Mi
 tVYQUM-M=.7f2c40ef-a5c4-4a5a-8dc6-4b491b2fc294@github.com>
 <MrSuzVAmYlo6IZzVaeO2v5t0bvypYkdrnZNj16MdcyQ=.fe36d884-d6a1-468b-852a-6627d7eab9ff@github.com>
Message-ID: <VQ0bYxUrhUZMo4_1XtPfits0bahno0-2MYGJ1J5N6IM=.6bbae6b3-ff6e-4e87-8c27-5a889d762566@github.com>

On Wed, 17 Mar 2021 19:34:19 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Hmm, maybe the child can create a file to indicate that bootstrap has finished.
>
>> The child does no (zero) writes to either stream. It is invoked only to sleep until it is destroyed.
>> The purpose of the test is to verify the exception that is thrown when the other end(child) of the pipe is closed (because the process has been forcibly terminated).
> 
> I meant as a consequence of an error. E.g. a crash or a native OOM could cause the child to write an error report to stderr.

> Hmm, maybe the child can create a file to indicate that bootstrap has finished.

Why does the child even have to be a java VM?

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From rriggs at openjdk.java.net  Wed Mar 17 19:55:46 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 17 Mar 2021 19:55:46 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <VQ0bYxUrhUZMo4_1XtPfits0bahno0-2MYGJ1J5N6IM=.6bbae6b3-ff6e-4e87-8c27-5a889d762566@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
 <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
 <Qj6Ch7nKS2pBcAw0Du-ZD8_CeyOEviSOSwxMGyCX_q4=.aa182b6d-f2d3-4cbf-a9d6-8374ace9e177@github.com>
 <umSS-izv_LUAJodEw_jSxvK9CrSArZxbjhcB-2OB6G4=.88e925b0-0001-4b7c-ba9c-fd2a3dff9afb@github.com>
 <xDMPEwAZVeVlclHy7JVUHnT6KiGMj0eDO1Fom8R3VIA=.7ac05900-a527-4e73-8206-ceed49cf8961@github.com>
 <4rkO_Fy5XHnekf9M8tDb2FX5xq4T5Xs73Mi
 tVYQUM-M=.7f2c40ef-a5c4-4a5a-8dc6-4b491b2fc294@github.com>
 <MrSuzVAmYlo6IZzVaeO2v5t0bvypYkdrnZNj16MdcyQ=.fe36d884-d6a1-468b-852a-6627d7eab9ff@github.com>
 <VQ0bYxUrhUZMo4_1XtPfits0bahno0-2MYGJ1J5N6IM=.6bbae6b3-ff6e-4e87-8c27-5a889d762566@github.com>
Message-ID: <MJ-sZyYo6VT7EBS5ztBISVpsAH3ciC5Rb15kyFyC-e8=.2776543d-00c8-413d-8ef1-8b5d4532d0d8@github.com>

On Wed, 17 Mar 2021 19:35:14 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> The child does no (zero) writes to either stream. It is invoked only to sleep until it is destroyed.
>>> The purpose of the test is to verify the exception that is thrown when the other end(child) of the pipe is closed (because the process has been forcibly terminated).
>> 
>> I meant as a consequence of an error. E.g. a crash or a native OOM could cause the child to write an error report to stderr.
>
>> Hmm, maybe the child can create a file to indicate that bootstrap has finished.
> 
> Why does the child even have to be a java VM?

Its a Java Child for consistency across tests and across OS's.  
The JavaChild executes a number of specialized commands to consume or provide data to the parent.
Piecing that together on different OS's would add more variables to the tests.
In this particular case, assuming it's well understood could probably be handled by some native program
as long its available on all platforms consistently.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From stuefe at openjdk.java.net  Wed Mar 17 20:05:48 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Wed, 17 Mar 2021 20:05:48 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <MJ-sZyYo6VT7EBS5ztBISVpsAH3ciC5Rb15kyFyC-e8=.2776543d-00c8-413d-8ef1-8b5d4532d0d8@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
 <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
 <Qj6Ch7nKS2pBcAw0Du-ZD8_CeyOEviSOSwxMGyCX_q4=.aa182b6d-f2d3-4cbf-a9d6-8374ace9e177@github.com>
 <umSS-izv_LUAJodEw_jSxvK9CrSArZxbjhcB-2OB6G4=.88e925b0-0001-4b7c-ba9c-fd2a3dff9afb@github.com>
 <xDMPEwAZVeVlclHy7JVUHnT6KiGMj0eDO1Fom8R3VIA=.7ac05900-a527-4e73-8206-ceed49cf8961@github.com>
 <4rkO_Fy5XHnekf9M8tDb2FX5xq4T5Xs73Mi
 tVYQUM-M=.7f2c40ef-a5c4-4a5a-8dc6-4b491b2fc294@github.com>
 <MrSuzVAmYlo6IZzVaeO2v5t0bvypYkdrnZNj16MdcyQ=.fe36d884-d6a1-468b-852a-6627d7eab9ff@github.com>
 <VQ0bYxUrhUZMo4_1XtPfits0bahno0-2MYGJ1J5N6IM=.6bbae6b3-ff6e-4e87-8c27-5a889d762566@github.com>
 <MJ-sZyYo6VT7EBS5ztBISVpsAH3ciC5Rb15kyFyC-e8=.2776543d-00c8-413d-8ef1-8b5d4532d0d8@github.com>
Message-ID: <7YDRSzPjxbpksqlloBM-PoHpYXGQFKMJOWcPw4T8POY=.9a4a2957-6730-473b-8c7f-371b9fcaa922@github.com>

On Wed, 17 Mar 2021 19:52:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Its a Java Child for consistency across tests and across OS's.
> The JavaChild executes a number of specialized commands to consume or provide data to the parent.
> Piecing that together on different OS's would add more variables to the tests.
> In this particular case, assuming it's well understood could probably be handled by some native program
> as long its available on all platforms consistently.

Thanks Roger for explaining. Sorry for the questions. We are bugged regularly by similar intermittent errors and I am curious and interested in getting tests stable.

I'm still thinking reading both stdout and stderr simultaneously would be more defensive in case the child dies of unnatural circumstances, or prints out unexpected output. The VM does this sometimes (eg unconditonal logging, or crashing), and we have seen blockages like these when childs waited on unflushed write buffers. Since you have all parts already there - a thread to drain the childs output - why not just spawn two of those instead of one and make sure both are closed as expected when the child is gone. That way you also cut down on execution time.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From darcy at openjdk.java.net  Wed Mar 17 20:27:47 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 17 Mar 2021 20:27:47 GMT
Subject: Integrated: 8254979: Class.getSimpleName() returns non-empty for
 lambda and method
In-Reply-To: <Thw0UcKlw3o568qxq0flp2d5grp9Kx80hSMVuo9fITw=.730127b3-e187-499c-86e9-de85bca1a2c5@github.com>
References: <Thw0UcKlw3o568qxq0flp2d5grp9Kx80hSMVuo9fITw=.730127b3-e187-499c-86e9-de85bca1a2c5@github.com>
Message-ID: <3xGy4yfC9ey3NvK6nTQrlkm83iLxLhYrmEoEFkumfcg=.e73c5ad7-5fee-46ff-b266-1726793a1403@github.com>

On Tue, 16 Mar 2021 22:24:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> java.lang.Class has a number of methods to return some kind of textual token associated with the class, including a type name, canonical name, simple name, and separately the results of toString().
> 
> Bug 8254979 notes that getSimpleName mentions returning the name in source code, but operationally returns a non-null result for synthetic classes, ones without benefit of source code representation. Since it is useful to return a non-null result in such cases, I've updated the spec to mention this case. The names of synthetic classes are not covered by the JLS; using a "$" in such names is customary, but not strictly required. The synthetic classes used to implement lambdas and method references as cited in the bug report include "$"'s.
> 
> Looking over the other "getFooName" methods, I don't think they need to be updated to handle this case.

This pull request has now been integrated.

Changeset: 26234b53
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/26234b53
Stats:     10 lines in 1 file changed: 3 ins; 1 del; 6 mod

8254979: Class.getSimpleName() returns non-empty for lambda and method

Reviewed-by: rriggs, mchung

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

PR: https://git.openjdk.java.net/jdk/pull/3038

From herrick at openjdk.java.net  Wed Mar 17 20:35:54 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 17 Mar 2021 20:35:54 GMT
Subject: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations
In-Reply-To: <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
 <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
 <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>
Message-ID: <qiZi_Vbv_HUnvOdDXWkOYXX34-TZXgn5RfVZ10RKPbA=.2a14f73b-832e-4dbb-92c9-bee2ff7b62ec@github.com>

On Wed, 17 Mar 2021 19:02:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 
> 
> > I cannot find any instances where the scope can be narrowed
> 
> Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?

These have the code pattern such as: 
} else if (c instanceof JApplet) {
putting '@SuppressWarnings("removal")' before the declaration of 'c' does not help, because the code is not an assignment to 'c'

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

PR: https://git.openjdk.java.net/jdk/pull/2920

From rriggs at openjdk.java.net  Wed Mar 17 21:16:48 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 17 Mar 2021 21:16:48 GMT
Subject: RFR: 8262807: Note assumptions of core reflection modeling and
 parameter handling [v2]
In-Reply-To: <8LziHw1I6zHCX27JKe5ax1Oz73pR3SPDYAzlDRmyHbg=.3ea70358-ff86-4dca-9022-3604523924b1@github.com>
References: <ae56zoC6twGvS0nhTEk_6G41yGfaHHUYV_Wx1V1hdYc=.a1d4a49c-38e4-4ef2-8b7b-f3fb1814fb56@github.com>
 <8LziHw1I6zHCX27JKe5ax1Oz73pR3SPDYAzlDRmyHbg=.3ea70358-ff86-4dca-9022-3604523924b1@github.com>
Message-ID: <xi42FYY2smpCi4IPE-euvRZ5zvWJI8iR8gWkjqd1c4o=.2eb93a36-2920-470e-987c-89178a3d312c@github.com>

On Tue, 16 Mar 2021 20:41:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Please review the javadoc change below, written in response to recent discussion on core-libs.
>> 
>> The bulk of the change is to add a discussion to java.lang.reflect's package-info file about a language vs JVM model for core reflection. That discussion is then linked to from several relevant locations core reflection. A discussion of generic parameter handling is also added along with various small cleanups.
>> 
>> I'll update copyright, etc. after agreement on the text is reached.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3036

From darcy at openjdk.java.net  Wed Mar 17 21:44:06 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 17 Mar 2021 21:44:06 GMT
Subject: RFR: 8262807: Note assumptions of core reflection modeling and
 parameter handling [v3]
In-Reply-To: <ae56zoC6twGvS0nhTEk_6G41yGfaHHUYV_Wx1V1hdYc=.a1d4a49c-38e4-4ef2-8b7b-f3fb1814fb56@github.com>
References: <ae56zoC6twGvS0nhTEk_6G41yGfaHHUYV_Wx1V1hdYc=.a1d4a49c-38e4-4ef2-8b7b-f3fb1814fb56@github.com>
Message-ID: <E6woDprcCxepiWc1UzBefWED9iLKYE47XI6f5lLtMXQ=.7d801369-f297-44ae-85c3-6077dc4efc31@github.com>

> Please review the javadoc change below, written in response to recent discussion on core-libs.
> 
> The bulk of the change is to add a discussion to java.lang.reflect's package-info file about a language vs JVM model for core reflection. That discussion is then linked to from several relevant locations core reflection. A discussion of generic parameter handling is also added along with various small cleanups.
> 
> I'll update copyright, etc. after agreement on the text is reached.

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 five additional commits since the last revision:

 - Merge and update copyright year.
 - Merge branch 'master' into 8262807
 - Respond to review feedback.
 - Appease jcheck.
 - 8262807: Note assumptions of core reflection modeling and parameter handling

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3036/files
  - new: https://git.openjdk.java.net/jdk/pull/3036/files/3f102171..c2bf7434

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3036&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3036&range=01-02

  Stats: 2708 lines in 204 files changed: 1275 ins; 709 del; 724 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3036.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3036/head:pull/3036

PR: https://git.openjdk.java.net/jdk/pull/3036

From darcy at openjdk.java.net  Wed Mar 17 22:03:08 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 17 Mar 2021 22:03:08 GMT
Subject: Integrated: 8262807: Note assumptions of core reflection modeling and
 parameter handling
In-Reply-To: <ae56zoC6twGvS0nhTEk_6G41yGfaHHUYV_Wx1V1hdYc=.a1d4a49c-38e4-4ef2-8b7b-f3fb1814fb56@github.com>
References: <ae56zoC6twGvS0nhTEk_6G41yGfaHHUYV_Wx1V1hdYc=.a1d4a49c-38e4-4ef2-8b7b-f3fb1814fb56@github.com>
Message-ID: <jzvuCFJfFaw5Ac66WUh81NcU4vDzBdJ8x9ugbA3t3lU=.c9e28c28-5921-4d17-b386-e9952d3b2bf9@github.com>

On Tue, 16 Mar 2021 17:22:13 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Please review the javadoc change below, written in response to recent discussion on core-libs.
> 
> The bulk of the change is to add a discussion to java.lang.reflect's package-info file about a language vs JVM model for core reflection. That discussion is then linked to from several relevant locations core reflection. A discussion of generic parameter handling is also added along with various small cleanups.
> 
> I'll update copyright, etc. after agreement on the text is reached.

This pull request has now been integrated.

Changeset: 99b39aad
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/99b39aad
Stats:     108 lines in 4 files changed: 69 ins; 15 del; 24 mod

8262807: Note assumptions of core reflection modeling and parameter handling

Reviewed-by: rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/3036

From darcy at openjdk.java.net  Wed Mar 17 22:03:07 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 17 Mar 2021 22:03:07 GMT
Subject: RFR: 8262807: Note assumptions of core reflection modeling and
 parameter handling [v4]
In-Reply-To: <ae56zoC6twGvS0nhTEk_6G41yGfaHHUYV_Wx1V1hdYc=.a1d4a49c-38e4-4ef2-8b7b-f3fb1814fb56@github.com>
References: <ae56zoC6twGvS0nhTEk_6G41yGfaHHUYV_Wx1V1hdYc=.a1d4a49c-38e4-4ef2-8b7b-f3fb1814fb56@github.com>
Message-ID: <J5eE_1zDdQBYZw7CgFfgRBJnSLcWX3S3bp_J4xilOGw=.6a4dfc95-7ca7-4098-8bc3-efaf50f84879@github.com>

> Please review the javadoc change below, written in response to recent discussion on core-libs.
> 
> The bulk of the change is to add a discussion to java.lang.reflect's package-info file about a language vs JVM model for core reflection. That discussion is then linked to from several relevant locations core reflection. A discussion of generic parameter handling is also added along with various small cleanups.
> 
> I'll update copyright, etc. after agreement on the text is reached.

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

  Per current terminology conventions, "types" -> "classes and interfaces" in package-info.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3036/files
  - new: https://git.openjdk.java.net/jdk/pull/3036/files/c2bf7434..cd6fd6fe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3036&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3036&range=02-03

  Stats: 18 lines in 1 file changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3036.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3036/head:pull/3036

PR: https://git.openjdk.java.net/jdk/pull/3036

From github.com+28367473+jmehrens at openjdk.java.net  Wed Mar 17 22:56:48 2021
From: github.com+28367473+jmehrens at openjdk.java.net (jmehrens)
Date: Wed, 17 Mar 2021 22:56:48 GMT
Subject: RFR: 8254979: Class.getSimpleName() returns non-empty for lambda
 and method
In-Reply-To: <Thw0UcKlw3o568qxq0flp2d5grp9Kx80hSMVuo9fITw=.730127b3-e187-499c-86e9-de85bca1a2c5@github.com>
References: <Thw0UcKlw3o568qxq0flp2d5grp9Kx80hSMVuo9fITw=.730127b3-e187-499c-86e9-de85bca1a2c5@github.com>
Message-ID: <oKDglfZTYqOA1zdvQWLKG1ZgiLYns_NXJ6X0qdak424=.876b4bdc-b63a-4b1d-955d-1c99ee8c2208@github.com>

On Tue, 16 Mar 2021 22:24:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> java.lang.Class has a number of methods to return some kind of textual token associated with the class, including a type name, canonical name, simple name, and separately the results of toString().
> 
> Bug 8254979 notes that getSimpleName mentions returning the name in source code, but operationally returns a non-null result for synthetic classes, ones without benefit of source code representation. Since it is useful to return a non-null result in such cases, I've updated the spec to mention this case. The names of synthetic classes are not covered by the JLS; using a "$" in such names is customary, but not strictly required. The synthetic classes used to implement lambdas and method references as cited in the bug report include "$"'s.
> 
> Looking over the other "getFooName" methods, I don't think they need to be updated to handle this case.

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

> 780: 
> 781:     /**
> 782:      *{@return {@code true} if and only if this class has the synthetic modifier

The braces around return tag are allowed?  "{@return ...} vs. "@return ..." Seems inconsistent with other uses of return tags.

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

PR: https://git.openjdk.java.net/jdk/pull/3038

From joe.darcy at oracle.com  Wed Mar 17 23:26:16 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 17 Mar 2021 16:26:16 -0700
Subject: RFR: 8254979: Class.getSimpleName() returns non-empty for lambda
 and method
In-Reply-To: <oKDglfZTYqOA1zdvQWLKG1ZgiLYns_NXJ6X0qdak424=.876b4bdc-b63a-4b1d-955d-1c99ee8c2208@github.com>
References: <Thw0UcKlw3o568qxq0flp2d5grp9Kx80hSMVuo9fITw=.730127b3-e187-499c-86e9-de85bca1a2c5@github.com>
 <oKDglfZTYqOA1zdvQWLKG1ZgiLYns_NXJ6X0qdak424=.876b4bdc-b63a-4b1d-955d-1c99ee8c2208@github.com>
Message-ID: <69222e5b-c3fb-1a58-1330-2907be898553@oracle.com>

Hello,

On 3/17/2021 3:56 PM, jmehrens wrote:
> On Tue, 16 Mar 2021 22:24:55 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>
[snip]

>> 780:
>> 781:     /**
>> 782:      *{@return {@code true} if and only if this class has the synthetic modifier
> The braces around return tag are allowed?  "{@return ...} vs. "@return ..." Seems inconsistent with other uses of return tags.

Yes; after a recently-added javadoc feature in JDK 16:

 ??? JDK-8075778: Add javadoc tag to avoid duplication of return 
information in simple situations.
 ??? https://bugs.openjdk.java.net/browse/JDK-8075778

The usage allow an explicit @return tag to be elided when it is the same 
as the first sentence of the javadoc.

The docs in the java.compiler module have been updated to use the feature.

HTH,

-Joe


From jpai at openjdk.java.net  Thu Mar 18 01:47:50 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Thu, 18 Mar 2021 01:47:50 GMT
Subject: Integrated: 8263108: Class initialization deadlock in
 java.lang.constant
In-Reply-To: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
References: <5CrDrW7F2MBDlnKAy4mC0qYL9rg8gnSnRt8TvdyskLM=.aa65de3a-434e-4e33-a748-4013b7ada46a@github.com>
Message-ID: <gGMAGp2OsXEC8j3W8eXJBhfBM5nDW44961AawlW9fYc=.b421110c-a66a-44b3-a722-108ba8186adc@github.com>

On Tue, 9 Mar 2021 13:46:04 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this proposed patch for the issue reported in https://bugs.openjdk.java.net/browse/JDK-8263108?
> 
> As noted in that issue, the `java.lang.constant.DynamicConstantDesc` and `java.lang.constant.ConstantDescs` can end up in a classloading deadlock due to the nature of the code involved in their static blocks. A thread dump of one such deadlock (reproduced using the code attached to that issue) is as follows:
> 
> "Thread A" #14 prio=5 os_prio=31 cpu=101.45ms elapsed=8.30s tid=0x00007ff88e01ca00 nid=0x6003 in Object.wait()  [0x000070000a4c6000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.constant.DynamicConstantDesc.<clinit>(java.base at 16-ea/DynamicConstantDesc.java:67)
> 	- waiting on the Class initialization monitor for java.lang.constant.ConstantDescs
> 	at Deadlock.threadA(Deadlock.java:14)
> 	at Deadlock$$Lambda$1/0x0000000800c00a08.run(Unknown Source)
> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
> 
> "Thread B" #15 prio=5 os_prio=31 cpu=103.15ms elapsed=8.30s tid=0x00007ff88b936a00 nid=0x9b03 in Object.wait()  [0x000070000a5c9000]
>    java.lang.Thread.State: RUNNABLE
> 	at java.lang.constant.ClassDesc.ofDescriptor(java.base at 16-ea/ClassDesc.java:145)
> 	- waiting on the Class initialization monitor for java.lang.constant.DynamicConstantDesc
> 	at java.lang.constant.ConstantDescs.<clinit>(java.base at 16-ea/ConstantDescs.java:239)
> 	at Deadlock.threadB(Deadlock.java:24)
> 	at Deadlock$$Lambda$2/0x0000000800c00c28.run(Unknown Source)
> 	at java.lang.Thread.run(java.base at 16-ea/Thread.java:831)
> 
> The commit in this PR resolves that deadlock by moving the `canonicalMap` initialization in `DynamicConstantDesc`, from the static block, to a lazily initialized map, into the `tryCanonicalize` (private) method of the same class. That's the only method which uses this map.
> 
> The implementation in `tryCanonicalize` carefully ensures that the deadlock isn't shifted from the static block to this method, by making sure that the `synchronization` on `DynamicConstantDesc` in this method happens only when it's time to write the state to the shared `canonicalMap`. This has an implication that the method local variable `canonDescs` can get initialized by multiple threads unnecessarily but from what I can see, that's the only way we can avoid this deadlock. This penalty of multiple threads initializing and then throwing away that map isn't too huge because that will happen only once when the `canonicalMap` is being initialized for the first time.
> 
> An alternate approach that I thought of was to completely get rid of this shared cache `canonicalMap` and instead just use method level map (that gets initialized each time) in the `tryCanonicalize` method (thus requiring no locks/synchronization). I ran a JMH benchmark with the current change proposed in this PR and with the alternate approach of using the method level map. The performance number from that run showed that the approach of using the method level map has relatively big impact on performance (even when there's a cache hit in that method). So I decided to not pursue that approach. I'll include the benchmark code and the numbers in a comment in this PR, for reference.
> 
> The commit in this PR also includes a jtreg testcase which (consistently) reproduces the deadlock without the fix and passes when this fix is applied. Extra manual testing has been done to verify that the classes of interest (noted in that testcase) are indeed getting loaded in those concurrent threads and not in the main thread. For future maintainers, there's a implementation note added on that testcase explaining why it cannot be moved into testng test.

This pull request has now been integrated.

Changeset: 9225a230
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9225a230
Stats:     180 lines in 2 files changed: 169 ins; 9 del; 2 mod

8263108: Class initialization deadlock in java.lang.constant

Reviewed-by: vtewari, plevart, chegar

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

PR: https://git.openjdk.java.net/jdk/pull/2893

From lzang at openjdk.java.net  Thu Mar 18 10:57:49 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 18 Mar 2021 10:57:49 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts,
 use of optional GZIP fields
Message-ID: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>

4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields

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

Commit messages:
 - remove trailing spaces
 - 4890732: support optional GZIP fields in GZIPOutputStream

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

PR: https://git.openjdk.java.net/jdk/pull/3072

From lzang at openjdk.java.net  Thu Mar 18 10:57:49 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Thu, 18 Mar 2021 10:57:49 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts,
 use of optional GZIP fields
In-Reply-To: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
Message-ID: <QElbJnPDSD8Uv2oHcQMB0gadwAfdK3RlavXt-v42lts=.c0c00f64-a05e-45df-b0db-75e307a38ce4@github.com>

On Thu, 18 Mar 2021 10:46:04 GMT, Lin Zang <lzang at openjdk.org> wrote:

> 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields

Dear All, 
This PR introduce new constructor of GZIPOutputStream to support adding extra field info in gzip file header, as decribed in RFC 1952 gzip spec (https://tools.ietf.org/html/rfc1952).
BTW, does a CSR required for this PR?  

Thanks!
Lin

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

PR: https://git.openjdk.java.net/jdk/pull/3072

From dfuchs at openjdk.java.net  Thu Mar 18 11:49:41 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 18 Mar 2021 11:49:41 GMT
Subject: RFR: 8251942: PrintStream specification is not clear which flush
 method is automatically invoked [v2]
In-Reply-To: <Fyc9SIrzDTiPDgvBUXkDKea01fTNRAxC0E07JvWQTn8=.b0e226ad-687e-4ab7-8659-b11fe5848807@github.com>
References: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>
 <Fyc9SIrzDTiPDgvBUXkDKea01fTNRAxC0E07JvWQTn8=.b0e226ad-687e-4ab7-8659-b11fe5848807@github.com>
Message-ID: <CavQwN3NrCDXCgo8E0HQ8L68q7sik3aRKKStL_oyddA=.34a2a7b1-2f57-4e1d-a02c-499fc8ab8798@github.com>

On Thu, 11 Mar 2021 20:57:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this minor change to the specification of `java.io.PrintStream`. The longstanding behavior for flushing is to invoke the `flush()` method of the underlying `OutputStream` rather than its override but this was not made explicit in the specification.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8251942: Scale back class level spec change

Looks good to me Brian!

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2926

From alanb at openjdk.java.net  Thu Mar 18 11:59:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 18 Mar 2021 11:59:39 GMT
Subject: RFR: 8251942: PrintStream specification is not clear which flush
 method is automatically invoked [v2]
In-Reply-To: <Fyc9SIrzDTiPDgvBUXkDKea01fTNRAxC0E07JvWQTn8=.b0e226ad-687e-4ab7-8659-b11fe5848807@github.com>
References: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>
 <Fyc9SIrzDTiPDgvBUXkDKea01fTNRAxC0E07JvWQTn8=.b0e226ad-687e-4ab7-8659-b11fe5848807@github.com>
Message-ID: <s8ZkvbKj2uOiD4fa70x7iNy8u6XSdsuYtSAQ8EWnyXQ=.f99a1cf6-5b64-4471-a74b-dd49d271c7c6@github.com>

On Thu, 11 Mar 2021 20:57:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this minor change to the specification of `java.io.PrintStream`. The longstanding behavior for flushing is to invoke the `flush()` method of the underlying `OutputStream` rather than its override but this was not made explicit in the specification.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8251942: Scale back class level spec change

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2926

From redestad at openjdk.java.net  Thu Mar 18 12:51:41 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Mar 2021 12:51:41 GMT
Subject: Integrated: 8260605: Various java.lang.invoke cleanups
In-Reply-To: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
References: <_nKSvOkUmpblUv3wP4_NMR8FnOEIWbifvs6SyJuV4ao=.642878bb-b8c5-4051-9177-e500217fe0a6@github.com>
Message-ID: <jMjriFIuXEFkvWj_yvLXY2foNtXrY_j_8DKCaTbR1AY=.5311ea4d-c996-4a9d-87ae-d05becdb04f9@github.com>

On Thu, 28 Jan 2021 19:21:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Remove unused code
> - Inline and simplify the bootstrap method invocation code (remove pointless reboxing checks etc)
> - Apply pattern matching to make some code more readable

This pull request has now been integrated.

Changeset: 63eae8fa
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/63eae8fa
Stats:     286 lines in 4 files changed: 40 ins; 168 del; 78 mod

8260605: Various java.lang.invoke cleanups

Reviewed-by: mchung

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

PR: https://git.openjdk.java.net/jdk/pull/2300

From jlaskey at openjdk.java.net  Thu Mar 18 12:59:44 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 18 Mar 2021 12:59:44 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v31]
In-Reply-To: <qd5H4ke7UsQlKhgmxSa9ssITkjopLucGg3bVmP1SKNs=.9b49cd22-25a0-44de-984c-3b3ca5a0f0c2@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <VKucCe2YRlRl3S6HDMxN5_q9xx6450oLSs2eHsfEFIA=.3dc00672-45c9-4f1e-b5bd-1968aa0bf63b@github.com>
 <qd5H4ke7UsQlKhgmxSa9ssITkjopLucGg3bVmP1SKNs=.9b49cd22-25a0-44de-984c-3b3ca5a0f0c2@github.com>
Message-ID: <7yvwMppH8E53dxxutLQCRKg6UpiXwjzobRmjz9hOOHM=.d4b62b25-849e-4539-a207-f136a6e96b52@github.com>

On Mon, 15 Mar 2021 23:07:53 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing @since
>
> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 62:
> 
>> 60:     @Retention(RetentionPolicy.RUNTIME)
>> 61:     @Target(ElementType.TYPE)
>> 62:     public @interface RandomGeneratorProperties {
> 
> Should the is-deprecated information be stored here?

I don't think so. That would require the deprecation state be stored in two places. I think it's sufficient to rely on the presence of @Deprecated.

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From jlaskey at openjdk.java.net  Thu Mar 18 13:04:43 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 18 Mar 2021 13:04:43 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v31]
In-Reply-To: <IYSxEORgZ1DDRwoVjgbVOyR_hqkAHZfEunugKpVk23Q=.56473b65-2fff-4eea-bc38-d299b00fbdc2@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <VKucCe2YRlRl3S6HDMxN5_q9xx6450oLSs2eHsfEFIA=.3dc00672-45c9-4f1e-b5bd-1968aa0bf63b@github.com>
 <IYSxEORgZ1DDRwoVjgbVOyR_hqkAHZfEunugKpVk23Q=.56473b65-2fff-4eea-bc38-d299b00fbdc2@github.com>
Message-ID: <nIiGaebMH2_b9HlC4Z0DNea47lFvS327EthLtjQil9k=.ee30b68a-372a-449a-be83-21f82b197def@github.com>

On Mon, 15 Mar 2021 23:02:33 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Missing @since
>
> src/java.base/share/classes/java/util/Random.java line 135:
> 
>> 133:      * number generator which is maintained by method {@link #next}.
>> 134:      *
>> 135:      * @implSpec <p>The invocation {@code new Random(seed)} is equivalent to:
> 
> This is not conventional formatting for an implSpec section. I suggest putting implSpec on its own line and then left-justifying the text as normal. A new paragraph tag is no needed at the beginning of implSpec.

Adjusted

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From jlaskey at openjdk.java.net  Thu Mar 18 13:11:43 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 18 Mar 2021 13:11:43 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <O4jMMzjrPSRXP5Yiqng6qmelNqpyKwyVz1ihebhfnDA=.a463dc84-da83-40d5-9ae2-c6f0b69b6a3e@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <8dxwtqYBhApNqL8YPdxd7DD2vSCh4l7Uty-yC5GQL1k=.c46a32df-87db-4bdb-a741-3a576061fbb8@github.com>
 <eQMIbyH4Iuhv5awo3y8hrVFFIQ3mle3fT5yc3uq9vSE=.3fc66dcc-79e8-4a55-9e0f-cca6242ecad1@github.com>
 <56ArMzotFOIbGr5mG6B-2PuwSh7I2gTbdcduv1GimdY=.108e2245-2423-4888-8409-262ec17481c5@github.com>
 <mjjAAlWx7OAPh-tkaRdXqBzlVqmEvtR9dWEZ1JS11O8=.fab27b0a-81bd-4ea6-9e17-3a9fb50bf250@github.com>
 <O4jMMzjrPSRXP5Yiqng6qmelNqpyKwyVz1ihebhfnDA=.a463dc84-da83-40d5-9ae2-c6f0b69b6a3e@github.com>
Message-ID: <YXbXVW2m-geKQDGtg16_PaZFgsVZJmLlis_APDtI4Sk=.30eba4ee-a363-4fc6-aace-90938f5c60a1@github.com>

On Tue, 16 Mar 2021 20:37:57 GMT, Tommy Ettinger <github.com+160684+tommyettinger at openjdk.org> wrote:

>> This is now looking very nicely structured.
>> 
>> The only thing i am unsure are the details around `RandomGenerator` being a service provider interface. The documentation mentions this at various points (mostly as implementation notes), but it's not really called out on `RandomGenerator`. 
>> 
>> Trying out the patch, I can implement `RandomGenerator` and register it as a service:
>> 
>> public class AlwaysZero implements RandomGenerator {
>>     @Override
>>     public long nextLong() {
>>         return 0;
>>     }
>> }
>> ...
>>         RandomGenerator alwaysZero = RandomGenerator.of("AlwaysZero");
>>  
>> 
>> Is that intended? (esp. since the annotation `RandomGeneratorProperties` is not public). If i rename the above to `L32X64MixRandom` an `ExceptionInInitializerError` is produced due to duplicate keys.
>> 
>> I suspect you want to filter out the service providers to those that only declare `RandomGeneratorProperties`, thereby restricting to providers only supplied by the platform.
>
> Has anyone here benchmarked this? I've run BumbleBench benchmarks (one of the AdoptOpenJDK team's tools, [available here](https://github.com/adoptium/bumblebench)) and I'm skeptical of the original claims in [JEP 356](https://openjdk.java.net/jeps/356), namely:
> 
>> ...a new class of splittable PRNG algorithms (LXM) has also been discovered that are almost as fast [as SplittableRandom]...
> 
> On my machine, L64X128MixRandom's algorithm is 53% slower than SplittableRandom, a halving in performance that I think would be inaccurate to describe as "almost as fast." I've benchmarked on Java 8 HotSpot (Windows 10, x64) and Java 15 OpenJ9 (same machine). On HotSpot, which I think is the main concern, I go from 1021770880 (over 1 billion) random longs per second with SplittableRandom to 479769280 (over 479 million) with my (I believe faithful) implementation of L64X128MixRandom. That is where I observed the 53% reduction. While SplittableRandom specifically seems to perform relatively badly on OpenJ9, with 893283072 longs per second (893 million), other similar random number generators do extremely well on OpenJ9; [LaserRandom](https://github.com/tommyettinger/jdkgdxds/blob/master/src/main/java/com/github/tommyettinger/ds/support/LaserRandom.java) generates 4232752128 random longs per second (4.2 billion) where L64X128MixRandom gets 840015872 (840 million). My benchmark repo is
  a mess, but if anyone wants to see and verify, [here it is](https://github.com/tommyettinger/assorted-benchmarks/tree/master/src/main/java/net/adoptopenjdk/bumblebench/examples). JMH benchmarks might provide different or just additional useful information; I've only run BumbleBench.
> 
> One could make the argument that getting a random long from a PRNG takes so little time in the first place that it is unlikely to be a bottleneck, and by that logic, LXM is "almost as fast." However, if random generation is not being called often enough for its speed to matter, you are exceedingly unlikely to need so many (over 9 quintillion) parallel streams or such a long period per stream ((2 to the 192) minus (2 to the 64)). LXM is also 1-dimensionally equidistributed, while the foundation it is built on should allow 4-dimensional equidistribution (with the caveat of any LFSR that an all-zero state is impossible), with the same memory use per generator (4 longs), a longer period, and comparable quality using `xoshiro256**`, or possibly `xoshiro256++`, giving up streams but permitting twice as many leaps as LXM has streams if you maintain the same period as L64X128MixRandom.
> 
> If I were implementing a PRNG to operate in a future official version of the JVM, I would definitely look into ways to use AES-NI, and I think the interfaces provided here should be valuable for any similar addition, even if I disagree with the provided implementations of those interfaces. Thank you for your time.

> This is now looking very nicely structured.
> 
> The only thing i am unsure are the details around `RandomGenerator` being a service provider interface. The documentation mentions this at various points (mostly as implementation notes), but it's not really called out on `RandomGenerator`.
> 
> Trying out the patch, I can implement `RandomGenerator` and register it as a service:
> 
> ```java
> public class AlwaysZero implements RandomGenerator {
>     @Override
>     public long nextLong() {
>         return 0;
>     }
> }
> ...
>         RandomGenerator alwaysZero = RandomGenerator.of("AlwaysZero");
> ```
> 
> Is that intended? (esp. since the annotation `RandomGeneratorProperties` is not public). If i rename the above to `L32X64MixRandom` an `ExceptionInInitializerError` is produced due to duplicate keys.
> 
> I suspect you want to filter out the service providers to those that only declare `RandomGeneratorProperties`, thereby restricting to providers only supplied by the platform.

Added the filter.

> Has anyone here benchmarked this? I've run BumbleBench benchmarks (one of the AdoptOpenJDK team's tools, [available here](https://github.com/adoptium/bumblebench)) and I'm skeptical of the original claims in [JEP 356](https://openjdk.java.net/jeps/356), namely:
> 
> > ...a new class of splittable PRNG algorithms (LXM) has also been discovered that are almost as fast [as SplittableRandom]...
> 
> On my machine, L64X128MixRandom's algorithm is 53% slower than SplittableRandom, a halving in performance that I think would be inaccurate to describe as "almost as fast." I've benchmarked on Java 8 HotSpot (Windows 10, x64) and Java 15 OpenJ9 (same machine). On HotSpot, which I think is the main concern, I go from 1021770880 (over 1 billion) random longs per second with SplittableRandom to 479769280 (over 479 million) with my (I believe faithful) implementation of L64X128MixRandom. That is where I observed the 53% reduction. While SplittableRandom specifically seems to perform relatively badly on OpenJ9, with 893283072 longs per second (893 million), other similar random number generators do extremely well on OpenJ9; [LaserRandom](https://github.com/tommyettinger/jdkgdxds/blob/master/src/main/java/com/github/tommyettinger/ds/support/LaserRandom.java) generates 4232752128 random longs per second (4.2 billion) where L64X128MixRandom gets 840015872 (840 million). My benchmark repo is
  a mess, but if anyone wants to see and verify, [here it is](https://github.com/tommyettinger/assorted-benchmarks/tree/master/src/main/java/net/adoptopenjdk/bumblebench/examples). JMH benchmarks might provide different or just additional useful information; I've only run BumbleBench.
> 
> One could make the argument that getting a random long from a PRNG takes so little time in the first place that it is unlikely to be a bottleneck, and by that logic, LXM is "almost as fast." However, if random generation is not being called often enough for its speed to matter, you are exceedingly unlikely to need so many (over 9 quintillion) parallel streams or such a long period per stream ((2 to the 192) minus (2 to the 64)). LXM is also 1-dimensionally equidistributed, while the foundation it is built on should allow 4-dimensional equidistribution (with the caveat of any LFSR that an all-zero state is impossible), with the same memory use per generator (4 longs), a longer period, and comparable quality using `xoshiro256**`, or possibly `xoshiro256++`, giving up streams but permitting twice as many leaps as LXM has streams if you maintain the same period as L64X128MixRandom.
> 
> If I were implementing a PRNG to operate in a future official version of the JVM, I would definitely look into ways to use AES-NI, and I think the interfaces provided here should be valuable for any similar addition, even if I disagree with the provided implementations of those interfaces. Thank you for your time.

Thanks for this feedback.  -- Guy

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From rriggs at openjdk.java.net  Thu Mar 18 13:43:38 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 18 Mar 2021 13:43:38 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <7YDRSzPjxbpksqlloBM-PoHpYXGQFKMJOWcPw4T8POY=.9a4a2957-6730-473b-8c7f-371b9fcaa922@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
 <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
 <Qj6Ch7nKS2pBcAw0Du-ZD8_CeyOEviSOSwxMGyCX_q4=.aa182b6d-f2d3-4cbf-a9d6-8374ace9e177@github.com>
 <umSS-izv_LUAJodEw_jSxvK9CrSArZxbjhcB-2OB6G4=.88e925b0-0001-4b7c-ba9c-fd2a3dff9afb@github.com>
 <xDMPEwAZVeVlclHy7JVUHnT6KiGMj0eDO1Fom8R3VIA=.7ac05900-a527-4e73-8206-ceed49cf8961@github.com>
 <4rkO_Fy5XHnekf9M8tDb2FX5xq4T5Xs73Mi
 tVYQUM-M=.7f2c40ef-a5c4-4a5a-8dc6-4b491b2fc294@github.com>
 <MrSuzVAmYlo6IZzVaeO2v5t0bvypYkdrnZNj16MdcyQ=.fe36d884-d6a1-468b-852a-6627d7eab9ff@github.com>
 <VQ0bYxUrhUZMo4_1XtPfits0bahno0-2MYGJ1J5N6IM=.6bbae6b3-ff6e-4e87-8c27-5a889d762566@github.com>
 <MJ-sZyYo6VT7EBS5ztBISVpsAH3ciC5Rb15kyFyC-e8=.2776543d-00c8-413d-8ef1-8b5d4532d0d8@github.com>
 <7YDRSzPjxbpksqlloBM-PoHpYXGQFKMJOWcPw4T8POY=.9a4a2957-6730-473b-8c7f-371b9fcaa922@github.com>
Message-ID: <nBQOoItXVg7T5x9hvGqMIwjI5kLDsMbJYxdsIdszzG4=.b023d5f7-0b9c-4bc4-9251-beb856867530@github.com>

On Wed, 17 Mar 2021 20:03:16 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Its a Java Child for consistency across tests and across OS's.  
>> The JavaChild executes a number of specialized commands to consume or provide data to the parent.
>> Piecing that together on different OS's would add more variables to the tests.
>> In this particular case, assuming it's well understood could probably be handled by some native program
>> as long its available on all platforms consistently.
>
>> Its a Java Child for consistency across tests and across OS's.
>> The JavaChild executes a number of specialized commands to consume or provide data to the parent.
>> Piecing that together on different OS's would add more variables to the tests.
>> In this particular case, assuming it's well understood could probably be handled by some native program
>> as long its available on all platforms consistently.
> 
> Thanks Roger for explaining. Sorry for the questions. We are bugged regularly by similar intermittent errors and I am curious and interested in getting tests stable.
> 
> I'm still thinking reading both stdout and stderr simultaneously would be more defensive in case the child dies of unnatural circumstances, or prints out unexpected output. The VM does this sometimes (eg unconditonal logging, or crashing), and we have seen blockages like these when childs waited on unflushed write buffers. Since you have all parts already there - a thread to drain the childs output - why not just spawn two of those instead of one and make sure both are closed as expected when the child is gone. That way you also cut down on execution time.

The test expects there to be zero output from the child (and it doesn't matter what state the child is in).
Can the logging from the VM be disabled or re-directed?

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From stuefe at openjdk.java.net  Thu Mar 18 14:33:51 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Thu, 18 Mar 2021 14:33:51 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <nBQOoItXVg7T5x9hvGqMIwjI5kLDsMbJYxdsIdszzG4=.b023d5f7-0b9c-4bc4-9251-beb856867530@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
 <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
 <Qj6Ch7nKS2pBcAw0Du-ZD8_CeyOEviSOSwxMGyCX_q4=.aa182b6d-f2d3-4cbf-a9d6-8374ace9e177@github.com>
 <umSS-izv_LUAJodEw_jSxvK9CrSArZxbjhcB-2OB6G4=.88e925b0-0001-4b7c-ba9c-fd2a3dff9afb@github.com>
 <xDMPEwAZVeVlclHy7JVUHnT6KiGMj0eDO1Fom8R3VIA=.7ac05900-a527-4e73-8206-ceed49cf8961@github.com>
 <4rkO_Fy5XHnekf9M8tDb2FX5xq4T5Xs73Mi
 tVYQUM-M=.7f2c40ef-a5c4-4a5a-8dc6-4b491b2fc294@github.com>
 <MrSuzVAmYlo6IZzVaeO2v5t0bvypYkdrnZNj16MdcyQ=.fe36d884-d6a1-468b-852a-6627d7eab9ff@github.com>
 <VQ0bYxUrhUZMo4_1XtPfits0bahno0-2MYGJ1J5N6IM=.6bbae6b3-ff6e-4e87-8c27-5a889d762566@github.com>
 <MJ-sZyYo6VT7EBS5ztBISVpsAH3ciC5Rb15kyFyC-e8=.2776543d-00c8-413d-8ef1-8b5d4532d0d8@github.com>
 <7YDRSzPjxbpksqlloBM-PoHpYXGQFKMJOWcPw4T8POY=.9a4a2957-6730-473b-8c7f-371b9fcaa922@github.com>
 <nBQOoItXVg7T5x9hvGqMIwjI5kLDsMbJYxdsIdszzG4=.b023d5f7-0b9c-4bc4-9251-beb856867530@github.com>
Message-ID: <4ERJk_t6CBOc2jTd369rGi0uqKAGfD3ue947W5Kdl3Y=.aa5b8918-b21f-4716-998f-6d29205a243a@github.com>

On Thu, 18 Mar 2021 13:41:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The test expects there to be zero output from the child (and it doesn't matter what state the child is in).
> Can the logging from the VM be disabled or re-directed?

Not to the extend that it would be guaranteed never to happen. Even if we control all output in the hotspot, there are other libraries. E.g. glibc writes a lengthy report to stderr in case of a heap corruption, which I believe does not result in a hs-err file.

One simple solution, simpler than using two threads, could be to use ProcessBuilder::redirectError(Redirect.INHERIT) if reading stdout resp. ProcessBuilder::redirectOutput(Redirect.INHERIT) if reading stderr. One line, takes care of the stream you don't read does not block, and, we can see the child output in the parent stdout/err.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From redestad at openjdk.java.net  Thu Mar 18 14:53:45 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Mar 2021 14:53:45 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base
In-Reply-To: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
Message-ID: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>

On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
> 
> This fixes the issues in the `java.base` package for ease of reviewing.
> 
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

Marked as reviewed by redestad (Reviewer).

src/java.base/share/classes/com/sun/security/ntlm/NTLMException.java line 52:

> 50:      * from server.
> 51:      */
> 52:     //public static final int DOMAIN_UNMATCH = 3;

Maybe this one ought to be removed instead?

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

PR: https://git.openjdk.java.net/jdk/pull/2993

From jlaskey at openjdk.java.net  Thu Mar 18 15:08:56 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 18 Mar 2021 15:08:56 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v32]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <VVXJ__O-21yfNiFV8dNhGSkb3i-h4XLjc5-XQd73gWA=.be82decd-6ddd-48fb-9c9b-b68ac3e96248@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:

 - Merge branch 'master' into 8248862
 - Review revisions
 - Missing @since
 - Review revisions
 - Review requested changes
 - Merge branch 'master' into 8248862
 - Remove conflicts
 - Use isAnnotationPresent
 - Introduce isDeprecated
 - Update javadoc
 - ... and 57 more: https://git.openjdk.java.net/jdk/compare/8c8d1b31...63094f9d

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

Changes: https://git.openjdk.java.net/jdk/pull/1292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=31
  Stats: 13653 lines in 26 files changed: 11537 ins; 1821 del; 295 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

PR: https://git.openjdk.java.net/jdk/pull/1292

From shade at openjdk.java.net  Thu Mar 18 15:10:38 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 18 Mar 2021 15:10:38 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base
In-Reply-To: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
Message-ID: <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com>

On Wed, 17 Mar 2021 12:31:22 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
>> 
>> This fixes the issues in the `java.base` package for ease of reviewing.
>> 
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124
>
> src/java.base/share/classes/com/sun/security/ntlm/NTLMException.java line 52:
> 
>> 50:      * from server.
>> 51:      */
>> 52:     //public static final int DOMAIN_UNMATCH = 3;
> 
> Maybe this one ought to be removed instead?

Yeah, I agree.

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

PR: https://git.openjdk.java.net/jdk/pull/2993

From plevart at openjdk.java.net  Thu Mar 18 15:21:37 2021
From: plevart at openjdk.java.net (Peter Levart)
Date: Thu, 18 Mar 2021 15:21:37 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <4ERJk_t6CBOc2jTd369rGi0uqKAGfD3ue947W5Kdl3Y=.aa5b8918-b21f-4716-998f-6d29205a243a@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
 <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
 <Qj6Ch7nKS2pBcAw0Du-ZD8_CeyOEviSOSwxMGyCX_q4=.aa182b6d-f2d3-4cbf-a9d6-8374ace9e177@github.com>
 <umSS-izv_LUAJodEw_jSxvK9CrSArZxbjhcB-2OB6G4=.88e925b0-0001-4b7c-ba9c-fd2a3dff9afb@github.com>
 <xDMPEwAZVeVlclHy7JVUHnT6KiGMj0eDO1Fom8R3VIA=.7ac05900-a527-4e73-8206-ceed49cf8961@github.com>
 <4rkO_Fy5XHnekf9M8tDb2FX5xq4T5Xs73Mi
 tVYQUM-M=.7f2c40ef-a5c4-4a5a-8dc6-4b491b2fc294@github.com>
 <MrSuzVAmYlo6IZzVaeO2v5t0bvypYkdrnZNj16MdcyQ=.fe36d884-d6a1-468b-852a-6627d7eab9ff@github.com>
 <VQ0bYxUrhUZMo4_1XtPfits0bahno0-2MYGJ1J5N6IM=.6bbae6b3-ff6e-4e87-8c27-5a889d762566@github.com>
 <MJ-sZyYo6VT7EBS5ztBISVpsAH3ciC5Rb15kyFyC-e8=.2776543d-00c8-413d-8ef1-8b5d4532d0d8@github.com>
 <7YDRSzPjxbpksqlloBM-PoHpYXGQFKMJOWcPw4T8POY=.9a4a2957-6730-473b-8c7f-371b9fcaa922@github.com>
 <nBQOoItXVg7T5x9hvGqMIwjI5kLDsMbJYxdsIdszzG4=.b023d5f7-0b9c-4bc4-9251-beb856867530@github.com>
 <4ERJk_t6CBOc2jTd369rGi0uqKAGfD3ue947W5Kdl3Y=.aa5b8918-b21f-4716-998f-6d29205a243a@github.com>
Message-ID: <zTLqQOMy_JpFrGstrn-D9R-DKpTg1zukV3zh9P84cqU=.b2e28e84-7f1c-407e-93f3-2ae836983bff@github.com>

On Thu, 18 Mar 2021 14:30:21 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> The test expects there to be zero output from the child (and it doesn't matter what state the child is in).
>> Can the logging from the VM be disabled or re-directed?
>
>> The test expects there to be zero output from the child (and it doesn't matter what state the child is in).
>> Can the logging from the VM be disabled or re-directed?
> 
> Not to the extend that it would be guaranteed never to happen. Even if we control all output in the hotspot, there are other libraries. E.g. glibc writes a lengthy report to stderr in case of a heap corruption, which I believe does not result in a hs-err file.
> 
> One simple solution, simpler than using two threads, could be to use ProcessBuilder::redirectError(Redirect.INHERIT) if reading stdout resp. ProcessBuilder::redirectOutput(Redirect.INHERIT) if reading stderr. One line, takes care of the stream you don't read does not block, and, we can see the child output in the parent stdout/err.

> That complicates the test and the child quite a bit for minimal gain.

Suppose that the child process writes 1 byte to STDOUT and 1 byte to STDERR. In the monitoring thread in the parent process, you could read 1 byte from either STDOUT or STDERR, then count-down the latch and then block in next read. The main thread could then just wait for the latch, wait for the monitoring thread to re-enter the synchronized read method and then destroy the process... It doesn't sound too complicated. WDYT?

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From lance.andersen at oracle.com  Thu Mar 18 15:24:44 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Thu, 18 Mar 2021 15:24:44 +0000
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts, 
 use of optional GZIP fields
In-Reply-To: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
Message-ID: <0AF856C1-BDD0-4B13-9F0E-27143D2C4E49@oracle.com>

Hi Lin,

Thank you for your contribution.


I have no looked at this in any detail.  A few general comments:


  *   This will require a CSR
  *   Please update your PR to include test coverage demonstrating that the data can be written and then read back


Best,
Lance

On Mar 18, 2021, at 6:57 AM, Lin Zang <lzang at openjdk.java.net<mailto:lzang at openjdk.java.net>> wrote:

4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields

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

Commit messages:
- remove trailing spaces
- 4890732: support optional GZIP fields in GZIPOutputStream

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

PR: https://git.openjdk.java.net/jdk/pull/3072

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>




From rriggs at openjdk.java.net  Thu Mar 18 15:43:37 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 18 Mar 2021 15:43:37 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <zTLqQOMy_JpFrGstrn-D9R-DKpTg1zukV3zh9P84cqU=.b2e28e84-7f1c-407e-93f3-2ae836983bff@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
 <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
 <Qj6Ch7nKS2pBcAw0Du-ZD8_CeyOEviSOSwxMGyCX_q4=.aa182b6d-f2d3-4cbf-a9d6-8374ace9e177@github.com>
 <umSS-izv_LUAJodEw_jSxvK9CrSArZxbjhcB-2OB6G4=.88e925b0-0001-4b7c-ba9c-fd2a3dff9afb@github.com>
 <xDMPEwAZVeVlclHy7JVUHnT6KiGMj0eDO1Fom8R3VIA=.7ac05900-a527-4e73-8206-ceed49cf8961@github.com>
 <4rkO_Fy5XHnekf9M8tDb2FX5xq4T5Xs73Mi
 tVYQUM-M=.7f2c40ef-a5c4-4a5a-8dc6-4b491b2fc294@github.com>
 <MrSuzVAmYlo6IZzVaeO2v5t0bvypYkdrnZNj16MdcyQ=.fe36d884-d6a1-468b-852a-6627d7eab9ff@github.com>
 <VQ0bYxUrhUZMo4_1XtPfits0bahno0-2MYGJ1J5N6IM=.6bbae6b3-ff6e-4e87-8c27-5a889d762566@github.com>
 <MJ-sZyYo6VT7EBS5ztBISVpsAH3ciC5Rb15kyFyC-e8=.2776543d-00c8-413d-8ef1-8b5d4532d0d8@github.com>
 <7YDRSzPjxbpksqlloBM-PoHpYXGQFKMJOWcPw4T8POY=.9a4a2957-6730-473b-8c7f-371b9fcaa922@github.com>
 <nBQOoItXVg7T5x9hvGqMIwjI5kLDsMbJYxdsIdszzG4=.b023d5f7-0b9c-4bc4-9251-beb856867530@github.com>
 <4ERJk_t6CBOc2jTd369rGi0uqKAGfD3ue947W5Kdl3Y=.aa5b8918-b21f-4716-998f-6d29205a243a@github.com>
 <zTLqQOMy_JpFrGstrn-D9R-DKpTg1zukV3zh9P84cqU=.b2e28e84-7f1c-407e-93f3-2ae836983bff@github.com>
Message-ID: <TxsTbHcLsLV7ygR87SJ6z8dAZYmS3kcBeCYPYmaCfn8=.1211acd0-1147-4301-8fce-bd0ac701a5e6@github.com>

On Thu, 18 Mar 2021 15:19:20 GMT, Peter Levart <plevart at openjdk.org> wrote:

>>> The test expects there to be zero output from the child (and it doesn't matter what state the child is in).
>>> Can the logging from the VM be disabled or re-directed?
>> 
>> Not to the extend that it would be guaranteed never to happen. Even if we control all output in the hotspot, there are other libraries. E.g. glibc writes a lengthy report to stderr in case of a heap corruption, which I believe does not result in a hs-err file.
>> 
>> One simple solution, simpler than using two threads, could be to use ProcessBuilder::redirectError(Redirect.INHERIT) if reading stdout resp. ProcessBuilder::redirectOutput(Redirect.INHERIT) if reading stderr. One line, takes care of the stream you don't read does not block, and, we can see the child output in the parent stdout/err.
>
>> That complicates the test and the child quite a bit for minimal gain.
> 
> Suppose that the child process writes 1 byte to STDOUT and 1 byte to STDERR. In the monitoring thread in the parent process, you could read 1 byte from either STDOUT or STDERR, then count-down the latch and then block in next read. The main thread could then just wait for the latch, wait for the monitoring thread to re-enter the synchronized read method and then destroy the process... It doesn't sound too complicated. WDYT?

Redirecting the stream not being tested to INHERIT may be useful.
But the failing case is when the vm output is being directed to the stream being tested.
The command line arguments are:
    Arrays.asList(javaExe,
        "-XX:+DisplayVMOutputToStderr",
        "-classpath", absolutifyPath(classpath),
        "Basic$JavaChild");```
A combination of redirecting to inherited and sending the VM output to the same (untested) stream seems like a good option.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From rriggs at openjdk.java.net  Thu Mar 18 15:46:38 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 18 Mar 2021 15:46:38 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test
In-Reply-To: <zTLqQOMy_JpFrGstrn-D9R-DKpTg1zukV3zh9P84cqU=.b2e28e84-7f1c-407e-93f3-2ae836983bff@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <JRw4vpPwRcwAYDOmpigCwu0_0JmXkMIy0A3J_E4N_L0=.13311440-3ce4-4ac6-955a-3b18553b7ec7@github.com>
 <swndWMovZpU3b-UtmwBJFcDSlBzNYU1I9q4KNawlQO0=.20741cb7-afe4-41f1-9997-509c91b9c39b@github.com>
 <DODL_sUJSjkTM6B6H0FDW2zVb01NL0Fx1wu9Bifgpv8=.aa0eae03-6aa0-41fd-8549-168d6a408906@github.com>
 <UJdnSM1M2qIpaeGTcpAa-yyBAv6jjvHVuRxHRXFxdTc=.661a1dd7-ef79-4c18-8562-8da611e2e522@github.com>
 <8ueGFC0A9b_oGTn76gpmfB6LwpcuzwjNFuJK7b-5qWY=.4852df58-f5bc-4bba-bf3b-b9882afe973d@github.com>
 <cQk8MYhNV-sKguU7ukQ8gHL6xhbwFHrUORrdsX1U-NQ=.8433b88d-515d-4f34-a890-55c21b0b92af@github.com>
 <Qj6Ch7nKS2pBcAw0Du-ZD8_CeyOEviSOSwxMGyCX_q4=.aa182b6d-f2d3-4cbf-a9d6-8374ace9e177@github.com>
 <umSS-izv_LUAJodEw_jSxvK9CrSArZxbjhcB-2OB6G4=.88e925b0-0001-4b7c-ba9c-fd2a3dff9afb@github.com>
 <xDMPEwAZVeVlclHy7JVUHnT6KiGMj0eDO1Fom8R3VIA=.7ac05900-a527-4e73-8206-ceed49cf8961@github.com>
 <4rkO_Fy5XHnekf9M8tDb2FX5xq4T5Xs73Mi
 tVYQUM-M=.7f2c40ef-a5c4-4a5a-8dc6-4b491b2fc294@github.com>
 <MrSuzVAmYlo6IZzVaeO2v5t0bvypYkdrnZNj16MdcyQ=.fe36d884-d6a1-468b-852a-6627d7eab9ff@github.com>
 <VQ0bYxUrhUZMo4_1XtPfits0bahno0-2MYGJ1J5N6IM=.6bbae6b3-ff6e-4e87-8c27-5a889d762566@github.com>
 <MJ-sZyYo6VT7EBS5ztBISVpsAH3ciC5Rb15kyFyC-e8=.2776543d-00c8-413d-8ef1-8b5d4532d0d8@github.com>
 <7YDRSzPjxbpksqlloBM-PoHpYXGQFKMJOWcPw4T8POY=.9a4a2957-6730-473b-8c7f-371b9fcaa922@github.com>
 <nBQOoItXVg7T5x9hvGqMIwjI5kLDsMbJYxdsIdszzG4=.b023d5f7-0b9c-4bc4-9251-beb856867530@github.com>
 <4ERJk_t6CBOc2jTd369rGi0uqKAGfD3ue947W5Kdl3Y=.aa5b8918-b21f-4716-998f-6d29205a243a@github.com>
 <zTLqQOMy_JpFrGstrn-D9R-DKpTg1zukV3zh9P84cqU=.b2e28e84-7f1c-407e-93f3-2ae836983bff@github.com>
Message-ID: <O6Wc6YsVRDWYjUhrfwVraFM7uo05jKjTpdtZRJg8T_w=.15a55097-e892-4f03-b348-b82c76aa5a97@github.com>

On Thu, 18 Mar 2021 15:19:20 GMT, Peter Levart <plevart at openjdk.org> wrote:

>>> The test expects there to be zero output from the child (and it doesn't matter what state the child is in).
>>> Can the logging from the VM be disabled or re-directed?
>> 
>> Not to the extend that it would be guaranteed never to happen. Even if we control all output in the hotspot, there are other libraries. E.g. glibc writes a lengthy report to stderr in case of a heap corruption, which I believe does not result in a hs-err file.
>> 
>> One simple solution, simpler than using two threads, could be to use ProcessBuilder::redirectError(Redirect.INHERIT) if reading stdout resp. ProcessBuilder::redirectOutput(Redirect.INHERIT) if reading stderr. One line, takes care of the stream you don't read does not block, and, we can see the child output in the parent stdout/err.
>
>> That complicates the test and the child quite a bit for minimal gain.
> 
> Suppose that the child process writes 1 byte to STDOUT and 1 byte to STDERR. In the monitoring thread in the parent process, you could read 1 byte from either STDOUT or STDERR, then count-down the latch and then block in next read. The main thread could then just wait for the latch, wait for the monitoring thread to re-enter the synchronized read method and then destroy the process... It doesn't sound too complicated. WDYT?

@plevart, I prototyped using that technique but was concerned that it might change the test case to be different in some subtle way from the original. It adds a new subcommand to the JavaChild to add the specific behavior.
Not particularly complex but more code and dependencies to explain.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From redestad at openjdk.java.net  Thu Mar 18 15:48:49 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Mar 2021 15:48:49 GMT
Subject: RFR: 8263821: Remove unused MethodTypeForm canonicalization codes
Message-ID: <0iZG4phq9RT6OIda3yovG9ckRuJUPRXe0A06FwO6dK0=.f46539f1-a770-4d72-bff1-84939e59f8e0@github.com>

MethodTypeForm.INTS, LONGS and RAW_RETURN are effectively unused. This removes these canonicalization codes and cleans up related code.

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

Commit messages:
 - Minor simplifications
 - Remove unused MethodTypeForm canonicalization codes

Changes: https://git.openjdk.java.net/jdk/pull/3075/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3075&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263821
  Stats: 45 lines in 2 files changed: 0 ins; 35 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3075.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3075/head:pull/3075

PR: https://git.openjdk.java.net/jdk/pull/3075

From chegar at openjdk.java.net  Thu Mar 18 16:03:37 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 18 Mar 2021 16:03:37 GMT
Subject: RFR: 8263320: [test] Add Object Stream Formatter to work with
 test utility HexPrinter
In-Reply-To: <3CZ34ALomv7XCnqx3b0DMXIrH0-cg8efhrNU8HRfBJg=.6710d795-1ee0-4f02-89f1-93d820389071@github.com>
References: <3CZ34ALomv7XCnqx3b0DMXIrH0-cg8efhrNU8HRfBJg=.6710d795-1ee0-4f02-89f1-93d820389071@github.com>
Message-ID: <-4kTFdhk5I0tCBB5SbzhRePt2Qc0SN_jGOibQf0f8lE=.cfa00078-acb2-46fd-b996-5ed3150339dc@github.com>

On Tue, 9 Mar 2021 21:37:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> ObjectStreamPrinter is a Formatter plugin to the test library HexPrinter.
> 
> A binary stream of serialized java objects is converted into a textual form by parsing the header, typecodes, and interpreting the stream contents. The formatter can be used standalone or with the HexPrinter to align the formatted stream with the corresponding hexadecimal bytes.
> 
> StreamDump is a test utility to pass the contents of a file to the HexPrinter utility. The format of the file is guessed from the encoding and initial bytes. ASN.1 and serialized object streams are supported.

Marked as reviewed by chegar (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2900

From github.com+76791+alblue at openjdk.java.net  Thu Mar 18 16:47:40 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Thu, 18 Mar 2021 16:47:40 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base
In-Reply-To: <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
 <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com>
Message-ID: <PCW2pC2AmLfkdrDob6soWkFfcRVeWlIBjfZyN6tadAs=.dc680f4c-c7d3-47b3-94ec-426ae6e78a36@github.com>

On Thu, 18 Mar 2021 15:08:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/com/sun/security/ntlm/NTLMException.java line 52:
>> 
>>> 50:      * from server.
>>> 51:      */
>>> 52:     //public static final int DOMAIN_UNMATCH = 3;
>> 
>> Maybe this one ought to be removed instead?
>
> Yeah, I agree.

Is that there to indicate a placeholder value that was once used and is kept for documentation purposes? Should the corresponding JavaDoc be removed as well? Should I do this in the same commit/PR as this one, or submit a new PR? Would prefer to avoid conflating fixes if possible so that if one needs to be reverted we don't revert the related changes.

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

PR: https://git.openjdk.java.net/jdk/pull/2993

From github.com+76791+alblue at openjdk.java.net  Thu Mar 18 16:53:40 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Thu, 18 Mar 2021 16:53:40 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base
In-Reply-To: <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
Message-ID: <cQhh6XQ7ChvJpba-tsdO7loOgsxGLydO7adILe3x48U=.776f12d7-68cf-405f-9ad1-68ad6f318c14@github.com>

On Thu, 18 Mar 2021 14:50:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
>> 
>> This fixes the issues in the `java.base` package for ease of reviewing.
>> 
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124
>
> Marked as reviewed by redestad (Reviewer).

If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them?

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

PR: https://git.openjdk.java.net/jdk/pull/2993

From redestad at openjdk.java.net  Thu Mar 18 16:53:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Mar 2021 16:53:40 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base
In-Reply-To: <PCW2pC2AmLfkdrDob6soWkFfcRVeWlIBjfZyN6tadAs=.dc680f4c-c7d3-47b3-94ec-426ae6e78a36@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
 <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com>
 <PCW2pC2AmLfkdrDob6soWkFfcRVeWlIBjfZyN6tadAs=.dc680f4c-c7d3-47b3-94ec-426ae6e78a36@github.com>
Message-ID: <8b1iG392QXVE705Fh071XyEU99mPpJjeH55zezkMJuo=.3b938f60-e903-4332-88e7-aa0fcfab871a@github.com>

On Thu, 18 Mar 2021 16:42:39 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> Yeah, I agree.
>
> Is that there to indicate a placeholder value that was once used and is kept for documentation purposes? Should the corresponding JavaDoc be removed as well? Should I do this in the same commit/PR as this one, or submit a new PR? Would prefer to avoid conflating fixes if possible so that if one needs to be reverted we don't revert the related changes.

There's another constant with value 3 defined, so I think this is just some left-over. 

If you prefer separating out the removal to another RFE I'd remove this particular change from this PR.

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

PR: https://git.openjdk.java.net/jdk/pull/2993

From joe.darcy at oracle.com  Thu Mar 18 17:02:46 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Thu, 18 Mar 2021 10:02:46 -0700
Subject: RFR: 8263658: Use the blessed modifier order in java.base
In-Reply-To: <cQhh6XQ7ChvJpba-tsdO7loOgsxGLydO7adILe3x48U=.776f12d7-68cf-405f-9ad1-68ad6f318c14@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
 <cQhh6XQ7ChvJpba-tsdO7loOgsxGLydO7adILe3x48U=.776f12d7-68cf-405f-9ad1-68ad6f318c14@github.com>
Message-ID: <2fe3dce7-7870-d4d1-2976-e73c53caf8a3@oracle.com>


On 3/18/2021 9:53 AM, Alex Blewitt wrote:
> On Thu, 18 Mar 2021 14:50:43 GMT, Claes Redestad <redestad at openjdk.org> wrote:
>
>>> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
>>>
>>> This fixes the issues in the `java.base` package for ease of reviewing.
>>>
>>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124
>> Marked as reviewed by redestad (Reviewer).
> If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them?
>

Separate bug numbers please. It is also possible to use an umbrella 
issue and have issues for, say each module, be subtasks.

-Joe


From github.com+76791+alblue at openjdk.java.net  Thu Mar 18 17:02:57 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Thu, 18 Mar 2021 17:02:57 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base [v2]
In-Reply-To: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
Message-ID: <9zvCrhqv5puk_W3QQHLWsguLs9YWvPcOF1Tn1PMtbnA=.05b22d28-3605-48b8-ad83-576951497b6a@github.com>

> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
> 
> This fixes the issues in the `java.base` package for ease of reviewing.
> 
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

Alex Blewitt has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8263658: Use the blessed modifier order in java.base

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2993/files
  - new: https://git.openjdk.java.net/jdk/pull/2993/files/470f7066..86aa9a34

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2993&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2993&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/2993

From github.com+76791+alblue at openjdk.java.net  Thu Mar 18 17:02:57 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Thu, 18 Mar 2021 17:02:57 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base [v2]
In-Reply-To: <8b1iG392QXVE705Fh071XyEU99mPpJjeH55zezkMJuo=.3b938f60-e903-4332-88e7-aa0fcfab871a@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
 <4gAAct3X4MZpTACWxcAFiMhpJe8DENCZmbnMdrx-mL8=.b2dcc664-952b-4e8d-9a30-5c2b2cf5970c@github.com>
 <PCW2pC2AmLfkdrDob6soWkFfcRVeWlIBjfZyN6tadAs=.dc680f4c-c7d3-47b3-94ec-426ae6e78a36@github.com>
 <8b1iG392QXVE705Fh071XyEU99mPpJjeH55zezkMJuo=.3b938f60-e903-4332-88e7-aa0fcfab871a@github.com>
Message-ID: <3uerJX_48Cm81fytVhYU__vSyWnHNBkBkjVyhvkwAIw=.0d4c85de-ff4e-4d10-883c-156ebc9b13a3@github.com>

On Thu, 18 Mar 2021 16:50:39 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Is that there to indicate a placeholder value that was once used and is kept for documentation purposes? Should the corresponding JavaDoc be removed as well? Should I do this in the same commit/PR as this one, or submit a new PR? Would prefer to avoid conflating fixes if possible so that if one needs to be reverted we don't revert the related changes.
>
> There's another constant with value 3 defined, so I think this is just some left-over. 
> 
> If you prefer separating out the removal to another RFE I'd remove this particular change from this PR.

Filed #3076 for the removal and updated this PR without it

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

PR: https://git.openjdk.java.net/jdk/pull/2993

From redestad at openjdk.java.net  Thu Mar 18 17:08:39 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Mar 2021 17:08:39 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base [v2]
In-Reply-To: <cQhh6XQ7ChvJpba-tsdO7loOgsxGLydO7adILe3x48U=.776f12d7-68cf-405f-9ad1-68ad6f318c14@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
 <cQhh6XQ7ChvJpba-tsdO7loOgsxGLydO7adILe3x48U=.776f12d7-68cf-405f-9ad1-68ad6f318c14@github.com>
Message-ID: <1qy9Ms9DJhOnDv1p22zymoMefV7fSUxAF_tmultwtMc=.452d3c2a-b5d6-4a82-9523-9e82a2409abc@github.com>

On Thu, 18 Mar 2021 16:51:35 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them?

Separate bug numbers is necessary. Unless you repurpose / widen this PR to include more modules.

A word of advice: Avoid git rebase + force push after opening a PR for review, since it might mess up the review context. Preferably either merge in changes from main, or just keep adding commits without syncing up - the system will ensure your patch can be merged in without conflicts.

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

PR: https://git.openjdk.java.net/jdk/pull/2993

From github.com+76791+alblue at openjdk.java.net  Thu Mar 18 17:08:40 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Thu, 18 Mar 2021 17:08:40 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base [v2]
In-Reply-To: <1qy9Ms9DJhOnDv1p22zymoMefV7fSUxAF_tmultwtMc=.452d3c2a-b5d6-4a82-9523-9e82a2409abc@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
 <cQhh6XQ7ChvJpba-tsdO7loOgsxGLydO7adILe3x48U=.776f12d7-68cf-405f-9ad1-68ad6f318c14@github.com>
 <1qy9Ms9DJhOnDv1p22zymoMefV7fSUxAF_tmultwtMc=.452d3c2a-b5d6-4a82-9523-9e82a2409abc@github.com>
Message-ID: <iixvb7a-v-TTS82u63lXVg0sYDy7eEdFuUg0awEBBhw=.7f604fe7-3a13-4bf1-8e23-407d869bc709@github.com>

On Thu, 18 Mar 2021 17:03:28 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them?
>
>> If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them?
> 
> Separate bug numbers is necessary. Unless you repurpose / widen this PR to include more modules.
> 
> A word of advice: Avoid git rebase + force push after opening a PR for review, since it might mess up the review context. Preferably either merge in changes from main, or just keep adding commits without syncing up - the system will ensure your patch can be merged in without conflicts.

I'm happy to either widen the scope of this PR or to submit multiple but I have to rely on the kindness of strangers to create appropriate bugs in the system. On the one hand I don't want to cause a lot of noise but  on the other having smaller independent commits (particularly if they hit a lot of files/modules) seems like a more sensible plan to me.

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

PR: https://git.openjdk.java.net/jdk/pull/2993

From redestad at openjdk.java.net  Thu Mar 18 17:15:38 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Mar 2021 17:15:38 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base [v2]
In-Reply-To: <iixvb7a-v-TTS82u63lXVg0sYDy7eEdFuUg0awEBBhw=.7f604fe7-3a13-4bf1-8e23-407d869bc709@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <8WpG-zsel1-0-OwXEJTG7lr_KA56wCTOCb8J_QppvAo=.84f4bc0f-cced-4a8f-b137-70075f07e359@github.com>
 <cQhh6XQ7ChvJpba-tsdO7loOgsxGLydO7adILe3x48U=.776f12d7-68cf-405f-9ad1-68ad6f318c14@github.com>
 <1qy9Ms9DJhOnDv1p22zymoMefV7fSUxAF_tmultwtMc=.452d3c2a-b5d6-4a82-9523-9e82a2409abc@github.com>
 <iixvb7a-v-TTS82u63lXVg0sYDy7eEdFuUg0awEBBhw=.7f604fe7-3a13-4bf1-8e23-407d869bc709@github.com>
Message-ID: <VNNCEP8MHTTbceAlsIr8bc7TEXn8v4YFgsxmuM-s-EQ=.2649f7d8-d081-4a76-8529-1fe3e52bbbb9@github.com>

On Thu, 18 Mar 2021 17:06:04 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>>> If I have other fixes for different modules, should I file PRs with the same bug number e.g. "8263658: Use the blessed modifier order in java.logging/java.desktop" or should we have separate bug numbers for them?
>> 
>> Separate bug numbers is necessary. Unless you repurpose / widen this PR to include more modules.
>> 
>> A word of advice: Avoid git rebase + force push after opening a PR for review, since it might mess up the review context. Preferably either merge in changes from main, or just keep adding commits without syncing up - the system will ensure your patch can be merged in without conflicts.
>
> I'm happy to either widen the scope of this PR or to submit multiple but I have to rely on the kindness of strangers to create appropriate bugs in the system. On the one hand I don't want to cause a lot of noise but  on the other having smaller independent commits (particularly if they hit a lot of files/modules) seems like a more sensible plan to me.

There's some extra churn in splitting it up, sure, but different modules are often maintained by different people so getting changes that span the entire JDK reviewed might actually take you longer.  YMMV. I can assist creating RFEs.

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

PR: https://git.openjdk.java.net/jdk/pull/2993

From redestad at openjdk.java.net  Thu Mar 18 17:51:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Mar 2021 17:51:40 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base [v2]
In-Reply-To: <9zvCrhqv5puk_W3QQHLWsguLs9YWvPcOF1Tn1PMtbnA=.05b22d28-3605-48b8-ad83-576951497b6a@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
 <9zvCrhqv5puk_W3QQHLWsguLs9YWvPcOF1Tn1PMtbnA=.05b22d28-3605-48b8-ad83-576951497b6a@github.com>
Message-ID: <dNc9yaucF2HGdAruXlcTdHs0It9pyZRe4GZmcxA0NMQ=.a3b9f61e-e26b-49c8-83a4-ae6fda1f375e@github.com>

On Thu, 18 Mar 2021 17:02:57 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
>> 
>> This fixes the issues in the `java.base` package for ease of reviewing.
>> 
>> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124
>
> Alex Blewitt has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR.

Marked as reviewed by redestad (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2993

From kcr at openjdk.java.net  Thu Mar 18 19:45:39 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 18 Mar 2021 19:45:39 GMT
Subject: RFR: JDK-8263545: Convert jpackage to use Stream.toList()
In-Reply-To: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
References: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
Message-ID: <uSGCdlveDeoyhgr1Lt2-VAJuKh0cSfgoC_7UxJnzupI=.679dd7cf-7b9f-4ef0-86f6-5dc57ac92546@github.com>

On Sun, 14 Mar 2021 18:22:50 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This converts jpackage to use `Stream.toList()` instead of `Stream.collect(Collectors.toList())`. One piece of code was modified to not mutate a list in addition to one test that used a mutating sort on a list. The rest of the changes are simple substitutions.

@igraves as a "best practice" try to avoid doing a force-push to a branch with an active code review. It makes it hard for reviewers to see what has changed. If you need to merge changes from master, use "git merge master" instead.

@alexeysemenyukoracle @sashamatveev Can you re-review this so Ian can integrate it?

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

PR: https://git.openjdk.java.net/jdk/pull/2997

From igraves at openjdk.java.net  Thu Mar 18 19:53:39 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 18 Mar 2021 19:53:39 GMT
Subject: RFR: JDK-8263545: Convert jpackage to use Stream.toList()
In-Reply-To: <uSGCdlveDeoyhgr1Lt2-VAJuKh0cSfgoC_7UxJnzupI=.679dd7cf-7b9f-4ef0-86f6-5dc57ac92546@github.com>
References: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
 <uSGCdlveDeoyhgr1Lt2-VAJuKh0cSfgoC_7UxJnzupI=.679dd7cf-7b9f-4ef0-86f6-5dc57ac92546@github.com>
Message-ID: <gs7em8kE2l9H6gS5lzY1MsxaYd3XwmnhmxmxQetiwlU=.d959ffda-d3e1-42f7-9faa-096040570a3e@github.com>

On Thu, 18 Mar 2021 19:43:10 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> This converts jpackage to use `Stream.toList()` instead of `Stream.collect(Collectors.toList())`. One piece of code was modified to not mutate a list in addition to one test that used a mutating sort on a list. The rest of the changes are simple substitutions.
>
> @igraves as a "best practice" try to avoid doing a force-push to a branch with an active code review. It makes it hard for reviewers to see what has changed. If you need to merge changes from master, use "git merge master" instead.
> 
> @alexeysemenyukoracle @sashamatveev Can you re-review this so Ian can integrate it?

@kevinrushforth Understood, thanks!

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

PR: https://git.openjdk.java.net/jdk/pull/2997

From winterhalter at openjdk.java.net  Thu Mar 18 21:08:48 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Thu, 18 Mar 2021 21:08:48 GMT
Subject: RFR: 8263763: Synthetic constructor parameters of enum are not
 considered for annotation indices
Message-ID: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>

8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices.

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

Commit messages:
 - 8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices.

Changes: https://git.openjdk.java.net/jdk/pull/3082/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3082&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263763
  Stats: 65 lines in 3 files changed: 60 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3082.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3082/head:pull/3082

PR: https://git.openjdk.java.net/jdk/pull/3082

From rriggs at openjdk.java.net  Thu Mar 18 21:29:41 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 18 Mar 2021 21:29:41 GMT
Subject: Integrated: 8263320: [test] Add Object Stream Formatter to work with
 test utility HexPrinter
In-Reply-To: <3CZ34ALomv7XCnqx3b0DMXIrH0-cg8efhrNU8HRfBJg=.6710d795-1ee0-4f02-89f1-93d820389071@github.com>
References: <3CZ34ALomv7XCnqx3b0DMXIrH0-cg8efhrNU8HRfBJg=.6710d795-1ee0-4f02-89f1-93d820389071@github.com>
Message-ID: <mHVKLHriAFxHPiAFm-NBKqeJnkGOmtyCukhbZToP80o=.094bc870-9b72-49b3-90ff-d649b4cabcca@github.com>

On Tue, 9 Mar 2021 21:37:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> ObjectStreamPrinter is a Formatter plugin to the test library HexPrinter.
> 
> A binary stream of serialized java objects is converted into a textual form by parsing the header, typecodes, and interpreting the stream contents. The formatter can be used standalone or with the HexPrinter to align the formatted stream with the corresponding hexadecimal bytes.
> 
> StreamDump is a test utility to pass the contents of a file to the HexPrinter utility. The format of the file is guessed from the encoding and initial bytes. ASN.1 and serialized object streams are supported.

This pull request has now been integrated.

Changeset: 788e30c1
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/788e30c1
Stats:     1684 lines in 4 files changed: 1684 ins; 0 del; 0 mod

8263320: [test] Add Object Stream Formatter to work with test utility HexPrinter

Reviewed-by: chegar

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

PR: https://git.openjdk.java.net/jdk/pull/2900

From mchung at openjdk.java.net  Thu Mar 18 21:40:39 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 18 Mar 2021 21:40:39 GMT
Subject: RFR: 8263821: Remove unused MethodTypeForm canonicalization codes
In-Reply-To: <0iZG4phq9RT6OIda3yovG9ckRuJUPRXe0A06FwO6dK0=.f46539f1-a770-4d72-bff1-84939e59f8e0@github.com>
References: <0iZG4phq9RT6OIda3yovG9ckRuJUPRXe0A06FwO6dK0=.f46539f1-a770-4d72-bff1-84939e59f8e0@github.com>
Message-ID: <L9SxJpWGZn0Ive9Fzi1JMuo_WRxASVmmV4jQUl-VZzw=.c6c910db-f00d-4568-97bf-6c565e505b59@github.com>

On Thu, 18 Mar 2021 15:42:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> MethodTypeForm.INTS, LONGS and RAW_RETURN are effectively unused. This removes these canonicalization codes and cleans up related code.

I don't object this dead code elimination.  I don't know the design/thought when these unused canonicalization codes were defined.

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

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3075

From darcy at openjdk.java.net  Thu Mar 18 21:54:46 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 18 Mar 2021 21:54:46 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v32]
In-Reply-To: <VVXJ__O-21yfNiFV8dNhGSkb3i-h4XLjc5-XQd73gWA=.be82decd-6ddd-48fb-9c9b-b68ac3e96248@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <VVXJ__O-21yfNiFV8dNhGSkb3i-h4XLjc5-XQd73gWA=.be82decd-6ddd-48fb-9c9b-b68ac3e96248@github.com>
Message-ID: <_uMAp-rI5lz4tzevS6jXiPsD_X6SSqequ5Gd5tc0lg8=.7cceb178-3fdc-46ee-86c4-99b2944d9e04@github.com>

On Thu, 18 Mar 2021 15:08:56 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
>> 
>> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>> 
>> old PR:  https://github.com/openjdk/jdk/pull/1273
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 67 commits:
> 
>  - Merge branch 'master' into 8248862
>  - Review revisions
>  - Missing @since
>  - Review revisions
>  - Review requested changes
>  - Merge branch 'master' into 8248862
>  - Remove conflicts
>  - Use isAnnotationPresent
>  - Introduce isDeprecated
>  - Update javadoc
>  - ... and 57 more: https://git.openjdk.java.net/jdk/compare/8c8d1b31...63094f9d

Changes requested by darcy (Reviewer).

src/java.base/share/classes/java/util/random/RandomGenerator.java line 1290:

> 1288:          * @return a new object that is a copy of this generator
> 1289:          */
> 1290:         LeapableGenerator copy();

Suggest adding an Override annotation here and possibly to inheritDoc the text from Jumpable.copy.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 1455:

> 1453:          *                                  period of this generator
> 1454:          */
> 1455:         void jump(double distance);

Suggest Override and inheritDoc combo.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 1465:

> 1463:          * @implSpec The default implementation invokes jump(jumpDistance()).
> 1464:          */
> 1465:         default void jump() { jump(jumpDistance()); }

Should be able to avoid defining the jump method in this subinterface.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 1486:

> 1484:          * ({@link Long#MAX_VALUE Long.MAX_VALUE}).
> 1485:          */
> 1486:         default Stream<ArbitrarilyJumpableGenerator> jumps(double distance) {

Suggest adding an Override annotation.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 1521:

> 1519:          * {@link ArbitrarilyJumpableGenerator#leapDistance() leapDistance}().
> 1520:          */
> 1521:         default void leap() { jump(leapDistance()); }

Should need to define this method in the subinterface of Leapable.

src/java.base/share/classes/java/util/random/RandomGenerator.java line 1538:

> 1536:          * returns the copy.
> 1537:          */
> 1538:         default ArbitrarilyJumpableGenerator copyAndJump(double distance) {

Suggest Override and inheritDoc.

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

PR: https://git.openjdk.java.net/jdk/pull/1292

From almatvee at openjdk.java.net  Thu Mar 18 22:02:41 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 18 Mar 2021 22:02:41 GMT
Subject: RFR: JDK-8263545: Convert jpackage to use Stream.toList()
In-Reply-To: <gs7em8kE2l9H6gS5lzY1MsxaYd3XwmnhmxmxQetiwlU=.d959ffda-d3e1-42f7-9faa-096040570a3e@github.com>
References: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
 <uSGCdlveDeoyhgr1Lt2-VAJuKh0cSfgoC_7UxJnzupI=.679dd7cf-7b9f-4ef0-86f6-5dc57ac92546@github.com>
 <gs7em8kE2l9H6gS5lzY1MsxaYd3XwmnhmxmxQetiwlU=.d959ffda-d3e1-42f7-9faa-096040570a3e@github.com>
Message-ID: <4-KL8rh4TI1iiVedDhL065na6SVJgp9hFD3V-VTJg0E=.e8b8ea54-e8fe-4d37-b04f-c3f306d35d08@github.com>

On Thu, 18 Mar 2021 19:51:06 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> @igraves as a "best practice" try to avoid doing a force-push to a branch with an active code review. It makes it hard for reviewers to see what has changed. If you need to merge changes from master, use "git merge master" instead.
>> 
>> @alexeysemenyukoracle @sashamatveev Can you re-review this so Ian can integrate it?
>
> @kevinrushforth Understood, thanks!

Looks fine.

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

PR: https://git.openjdk.java.net/jdk/pull/2997

From bpb at openjdk.java.net  Thu Mar 18 22:28:40 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 18 Mar 2021 22:28:40 GMT
Subject: RFR: 8251942: PrintStream specification is not clear which flush
 method is automatically invoked [v2]
In-Reply-To: <s8ZkvbKj2uOiD4fa70x7iNy8u6XSdsuYtSAQ8EWnyXQ=.f99a1cf6-5b64-4471-a74b-dd49d271c7c6@github.com>
References: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>
 <Fyc9SIrzDTiPDgvBUXkDKea01fTNRAxC0E07JvWQTn8=.b0e226ad-687e-4ab7-8659-b11fe5848807@github.com>
 <s8ZkvbKj2uOiD4fa70x7iNy8u6XSdsuYtSAQ8EWnyXQ=.f99a1cf6-5b64-4471-a74b-dd49d271c7c6@github.com>
Message-ID: <a1gklNulKSTe8jHBYv2ERDs1Z9iCq5M5eFRiLSmyGEQ=.7004824f-0f87-4cc9-9291-a9f0bc862eee@github.com>

On Thu, 18 Mar 2021 11:56:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8251942: Scale back class level spec change
>
> Marked as reviewed by alanb (Reviewer).

CSR filed: https://bugs.openjdk.java.net/browse/JDK-8263835.

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

PR: https://git.openjdk.java.net/jdk/pull/2926

From serb at openjdk.java.net  Thu Mar 18 22:51:38 2021
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 18 Mar 2021 22:51:38 GMT
Subject: RFR: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM [v3]
In-Reply-To: <xzF8mo-yZRT80DOkBXW9rcjz0BgLdOSc3LdLZmdoKdQ=.80194f1e-757e-40aa-aa6b-e0f2e3ca901d@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
 <xzF8mo-yZRT80DOkBXW9rcjz0BgLdOSc3LdLZmdoKdQ=.80194f1e-757e-40aa-aa6b-e0f2e3ca901d@github.com>
Message-ID: <M7d2Q4GK-elvrWm8fDcHIPt6d5I2pDeFi1ahcBolpBc=.8ff3354d-8760-45ea-83f5-2ea380cc6652@github.com>

On Wed, 17 Mar 2021 00:57:24 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS.
>> 
>> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the launcher trying to grab class name to be displayed as the Application name on the menu.
>> 
>> The fix is to not setting name, test shows that GUI java application shows 'bin' as the application name. It's possible for us to set the name to something more friendly, for example, "Java", but I am not sure that should be launcher's responsibility to choose such a default name. It seems to me the consumer of the JAVA_MAIN_CLASS_%d environment variable should be responsible to pick such name in case the environment variable is not set.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add copyright and another test case

Looks fine from the client point of view.

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

Marked as reviewed by serb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2999

From redestad at openjdk.java.net  Thu Mar 18 22:59:38 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 18 Mar 2021 22:59:38 GMT
Subject: RFR: 8263821: Remove unused MethodTypeForm canonicalization codes
In-Reply-To: <L9SxJpWGZn0Ive9Fzi1JMuo_WRxASVmmV4jQUl-VZzw=.c6c910db-f00d-4568-97bf-6c565e505b59@github.com>
References: <0iZG4phq9RT6OIda3yovG9ckRuJUPRXe0A06FwO6dK0=.f46539f1-a770-4d72-bff1-84939e59f8e0@github.com>
 <L9SxJpWGZn0Ive9Fzi1JMuo_WRxASVmmV4jQUl-VZzw=.c6c910db-f00d-4568-97bf-6c565e505b59@github.com>
Message-ID: <VOLPQ6i_rELEAxXLdNqxptAd-9r1z6R6zlNZm5DrW2Q=.baf19397-a473-4580-b9ed-0c4a6f63e479@github.com>

On Thu, 18 Mar 2021 21:37:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> MethodTypeForm.INTS, LONGS and RAW_RETURN are effectively unused. This removes these canonicalization codes and cleans up related code.
>
> I don't object this dead code elimination.  I don't know the design/thought when these unused canonicalization codes were defined.

This code appear to have been initially introduced with the JDK 7 implementation of JSR 292, which implemented different ways of adapting to and from generic types than the current code: https://bugs.openjdk.java.net/browse/JDK-6839872

Many uses (possibly all) were removed in https://bugs.openjdk.java.net/browse/JDK-6983728 (8-b01) where adapters were reworked. This was backported to 7, so the code I'm removing here is probably dead in all active releases.

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

PR: https://git.openjdk.java.net/jdk/pull/3075

From mchung at openjdk.java.net  Thu Mar 18 23:04:45 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 18 Mar 2021 23:04:45 GMT
Subject: RFR: 8263821: Remove unused MethodTypeForm canonicalization codes
In-Reply-To: <VOLPQ6i_rELEAxXLdNqxptAd-9r1z6R6zlNZm5DrW2Q=.baf19397-a473-4580-b9ed-0c4a6f63e479@github.com>
References: <0iZG4phq9RT6OIda3yovG9ckRuJUPRXe0A06FwO6dK0=.f46539f1-a770-4d72-bff1-84939e59f8e0@github.com>
 <L9SxJpWGZn0Ive9Fzi1JMuo_WRxASVmmV4jQUl-VZzw=.c6c910db-f00d-4568-97bf-6c565e505b59@github.com>
 <VOLPQ6i_rELEAxXLdNqxptAd-9r1z6R6zlNZm5DrW2Q=.baf19397-a473-4580-b9ed-0c4a6f63e479@github.com>
Message-ID: <g77hxAkzY_R3V7FLFkfNZV1AC25DpkzK_TAvr6uEID0=.66ee76b1-0962-4602-9111-2a521d70e32e@github.com>

On Thu, 18 Mar 2021 22:56:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> I don't object this dead code elimination.  I don't know the design/thought when these unused canonicalization codes were defined.
>
> This code appear to have been initially introduced with the JDK 7 implementation of JSR 292, which implemented different ways of adapting to and from generic types than the current code: https://bugs.openjdk.java.net/browse/JDK-6839872
> 
> Many uses (possibly all) were removed in https://bugs.openjdk.java.net/browse/JDK-6983728 (8-b01) where adapters were reworked. This was backported to 7, so the code I'm removing here is probably dead in all active releases.

Thanks for the history.

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

PR: https://git.openjdk.java.net/jdk/pull/3075

From asemenyuk at openjdk.java.net  Fri Mar 19 01:20:39 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 19 Mar 2021 01:20:39 GMT
Subject: RFR: JDK-8263545: Convert jpackage to use Stream.toList() [v3]
In-Reply-To: <62Ef-iVsd0mI5YTduK-5OZXBSZOilNW8w58FlFt31Kc=.24dc8681-21bb-4b80-94d7-7f4f85c51efc@github.com>
References: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
 <62Ef-iVsd0mI5YTduK-5OZXBSZOilNW8w58FlFt31Kc=.24dc8681-21bb-4b80-94d7-7f4f85c51efc@github.com>
Message-ID: <GFcs4P-yGlqxigHuBhA8Mha-6gxqZoVDV7s8oRZYeh4=.beb4fec3-0114-4ba2-9bc2-ffc7b7f4b4d5@github.com>

On Tue, 16 Mar 2021 04:55:23 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> This converts jpackage to use `Stream.toList()` instead of `Stream.collect(Collectors.toList())`. One piece of code was modified to not mutate a list in addition to one test that used a mutating sort on a list. The rest of the changes are simple substitutions.
>
> Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Clarifying type argument and shorting a toArray invocation
>  - Converting jpackage to use Stream.toList()

Marked as reviewed by asemenyuk (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/2997

From linzang at tencent.com  Fri Mar 19 02:28:21 2021
From: linzang at tencent.com (=?utf-8?B?bGluemFuZyjoh6fnkLMp?=)
Date: Fri, 19 Mar 2021 02:28:21 +0000
Subject: 4890732: GZIPOutputStream doesn't support, in fact thwarts, use
 of optional GZIP fields(Internet mail)
Message-ID: <762124D0-C1AD-4B92-8C56-6B2DFD646808@tencent.com>

Hi Lance,
Thanks a lot for your comments!
The CSR has been proposed at https://bugs.openjdk.java.net/browse/JDK-8263793, but it seems I can not add it to the github PR.
I am WIP on the test coverage, will update the PR when it is ready.

BRs,
Lin

From: Lance Andersen <lance.andersen at oracle.com>
Date: Thursday, March 18, 2021 at 11:25 PM
To: Lin Zang <lzang at openjdk.java.net>
Cc: "core-libs-dev at openjdk.java.net" <core-libs-dev at openjdk.java.net>
Subject: Re: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields(Internet mail)

Hi Lin,

Thank you for your contribution.


I have no looked at this in any detail.  A few general comments:

?         This will require a CSR
?         Please update your PR to include test coverage demonstrating that the data can be written and then read back


Best,
Lance


On Mar 18, 2021, at 6:57 AM, Lin Zang <lzang at openjdk.java.net<mailto:lzang at openjdk.java.net>> wrote:

4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields

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

Commit messages:
- remove trailing spaces
- 4890732: support optional GZIP fields in GZIPOutputStream

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

PR: https://git.openjdk.java.net/jdk/pull/3072

[cid:image001.gif at 01D71CAA.9557DB60]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>



From darcy at openjdk.java.net  Fri Mar 19 05:27:38 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 19 Mar 2021 05:27:38 GMT
Subject: RFR: 8263763: Synthetic constructor parameters of enum are not
 considered for annotation indices
In-Reply-To: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>
References: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>
Message-ID: <fVXkjoj54yxGaLUucXUWruPLGhfzavFUBCgocbQ7obM=.66b25271-c306-46d8-a5ed-d7b4d2ccf608@github.com>

On Thu, 18 Mar 2021 21:03:20 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> 8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices.

A general comment, the enum constructor situation is a bit tricky as

1) There is no 100% reliable way to determine which of a enum constructor's args are synthetic.

2) How a Java compiler generates enum constructors is a compiler-internal contract since all the enum constructors must be private.

It is true that javac has consistently added two extra parameters as an implementation detail. Offhand, I don't know if ecj in particular has made the same choice. javac is not obliged to continue implementing enum constructors in this manner, so for better robustness, I think a fix in this space needs to be able to accommodate situations other than exactly N+2 parameters.

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

PR: https://git.openjdk.java.net/jdk/pull/3082

From lzang at openjdk.java.net  Fri Mar 19 06:53:44 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 19 Mar 2021 06:53:44 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts,
 use of optional GZIP fields
In-Reply-To: <QElbJnPDSD8Uv2oHcQMB0gadwAfdK3RlavXt-v42lts=.c0c00f64-a05e-45df-b0db-75e307a38ce4@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <QElbJnPDSD8Uv2oHcQMB0gadwAfdK3RlavXt-v42lts=.c0c00f64-a05e-45df-b0db-75e307a38ce4@github.com>
Message-ID: <uKyCvOx7irWAUS6ApoGDcypgDSPk2tgTA4YRhb_zjYg=.fc0a2301-0f67-4722-ba8e-857104711bcb@github.com>

On Thu, 18 Mar 2021 10:50:05 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields
>
> Dear All, 
> This PR introduce new constructor of GZIPOutputStream to support adding extra field info in gzip file header, as decribed in RFC 1952 gzip spec (https://tools.ietf.org/html/rfc1952).
> BTW, does a CSR required for this PR?  
> 
> Thanks!
> Lin

The CSR has been submitted at https://bugs.openjdk.java.net/browse/JDK-8263793

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

PR: https://git.openjdk.java.net/jdk/pull/3072

From lzang at openjdk.java.net  Fri Mar 19 08:10:51 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 19 Mar 2021 08:10:51 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts,
 use of optional GZIP fields [v2]
In-Reply-To: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
Message-ID: <HRXE-AXon0-RPQUZA88cMNG-xrv9FgwmwsNNlQGBSP0=.cd60da74-ae9e-4a27-9d78-84351f63d85a@github.com>

> 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields

Lin Zang has updated the pull request incrementally with one additional commit since the last revision:

  add test case

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3072/files
  - new: https://git.openjdk.java.net/jdk/pull/3072/files/8cdc1fa6..533199ef

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=00-01

  Stats: 62 lines in 1 file changed: 58 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3072.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3072/head:pull/3072

PR: https://git.openjdk.java.net/jdk/pull/3072

From lzang at openjdk.java.net  Fri Mar 19 08:19:58 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 19 Mar 2021 08:19:58 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts,
 use of optional GZIP fields [v3]
In-Reply-To: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
Message-ID: <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>

> 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields

Lin Zang has updated the pull request incrementally with two additional commits since the last revision:

 - update copyright
 - reuse arguments constructor for non-argument one.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3072/files
  - new: https://git.openjdk.java.net/jdk/pull/3072/files/533199ef..9b7dabfe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3072&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/3072

From redestad at openjdk.java.net  Fri Mar 19 10:55:38 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 10:55:38 GMT
Subject: Integrated: 8263821: Remove unused MethodTypeForm canonicalization
 codes
In-Reply-To: <0iZG4phq9RT6OIda3yovG9ckRuJUPRXe0A06FwO6dK0=.f46539f1-a770-4d72-bff1-84939e59f8e0@github.com>
References: <0iZG4phq9RT6OIda3yovG9ckRuJUPRXe0A06FwO6dK0=.f46539f1-a770-4d72-bff1-84939e59f8e0@github.com>
Message-ID: <e17XdQwTprh7P6xOgvMLwSAly84J7IHZupyCUwhFl0Q=.10b01cc6-4e7b-479c-ae74-68c8f187dbfc@github.com>

On Thu, 18 Mar 2021 15:42:49 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> MethodTypeForm.INTS, LONGS and RAW_RETURN are effectively unused. This removes these canonicalization codes and cleans up related code.

This pull request has now been integrated.

Changeset: 57497ab0
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/57497ab0
Stats:     45 lines in 2 files changed: 0 ins; 35 del; 10 mod

8263821: Remove unused MethodTypeForm canonicalization codes

Reviewed-by: mchung

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

PR: https://git.openjdk.java.net/jdk/pull/3075

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:09:40 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:09:40 GMT
Subject: Integrated: 8263658: Use the blessed modifier order in java.base
In-Reply-To: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
References: <FJwAna4bf4Md96OjyI81k3oaMcqQ367m7BszVWc-m_8=.eca90fbe-7c71-49d4-b315-b59bb6e2a9d9@github.com>
Message-ID: <8mDze9YmhXvmW4gbfQLalR266LqHkNACv0ggx-z8d9E=.b33aab37-39ce-4e3c-85c4-8f5a6ebc53d7@github.com>

On Sat, 13 Mar 2021 22:45:30 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Sonar displays a warning message that modifiers should be declared in the order listed in the JLS; specifically, that isntead of using `final static` the `static final` should be preferred.
> 
> This fixes the issues in the `java.base` package for ease of reviewing.
> 
> https://sonarcloud.io/project/issues?id=shipilev_jdk&languages=java&resolved=false&rules=java%3AS1124

This pull request has now been integrated.

Changeset: b49c5893
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b49c5893
Stats:     139 lines in 28 files changed: 0 ins; 0 del; 139 mod

8263658: Use the blessed modifier order in java.base

Reviewed-by: rriggs, redestad

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

PR: https://git.openjdk.java.net/jdk/pull/2993

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:11:45 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:11:45 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
Message-ID: <WZ-BfQasElpWpPLI4ACQCdznD25ms1EGTmHTjn-Q2Ss=.6a890ef4-a1fe-4216-a114-a9962dee28de@github.com>

On Thu, 18 Mar 2021 18:26:20 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

Would someone mind creating a bug for me? In addition, if it would help, we could create a parent bug for applying cleanups  and associate #2993 and #2991.

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

PR: https://git.openjdk.java.net/jdk/pull/3078

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:11:45 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:11:45 GMT
Subject: RFR: 8263855: Use the blessed modifier order in java.management/naming
Message-ID: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>

As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

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

Commit messages:
 - Use the blessed modifier order in java.management/naming

Changes: https://git.openjdk.java.net/jdk/pull/3078/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3078&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263855
  Stats: 158 lines in 39 files changed: 0 ins; 0 del; 158 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3078.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3078/head:pull/3078

PR: https://git.openjdk.java.net/jdk/pull/3078

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:11:45 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:11:45 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <WZ-BfQasElpWpPLI4ACQCdznD25ms1EGTmHTjn-Q2Ss=.6a890ef4-a1fe-4216-a114-a9962dee28de@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <WZ-BfQasElpWpPLI4ACQCdznD25ms1EGTmHTjn-Q2Ss=.6a890ef4-a1fe-4216-a114-a9962dee28de@github.com>
Message-ID: <ywDO5blMUHP4cs9Yyome20z6r4zPUYxKu5sDkQYrBrE=.447a7f01-fd2e-4319-a083-07a72a722dff@github.com>

On Thu, 18 Mar 2021 19:33:59 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.
>
> Would someone mind creating a bug for me? In addition, if it would help, we could create a parent bug for applying cleanups  and associate #2993 and #2991.

@cl4es would you mind creating a parent task of something like "Source code cleanups" and then another sub task for this change please?

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

PR: https://git.openjdk.java.net/jdk/pull/3078

From redestad at openjdk.java.net  Fri Mar 19 13:11:46 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 13:11:46 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <ywDO5blMUHP4cs9Yyome20z6r4zPUYxKu5sDkQYrBrE=.447a7f01-fd2e-4319-a083-07a72a722dff@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <WZ-BfQasElpWpPLI4ACQCdznD25ms1EGTmHTjn-Q2Ss=.6a890ef4-a1fe-4216-a114-a9962dee28de@github.com>
 <ywDO5blMUHP4cs9Yyome20z6r4zPUYxKu5sDkQYrBrE=.447a7f01-fd2e-4319-a083-07a72a722dff@github.com>
Message-ID: <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>

On Fri, 19 Mar 2021 10:20:39 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> Would someone mind creating a bug for me? In addition, if it would help, we could create a parent bug for applying cleanups  and associate #2993 and #2991.
>
> @cl4es would you mind creating a parent task of something like "Source code cleanups" and then another sub task for this change please?

Created the subtask https://bugs.openjdk.java.net/browse/JDK-8263855 for this along with an umbrella RFE.

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

PR: https://git.openjdk.java.net/jdk/pull/3078

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:11:46 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:11:46 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <WZ-BfQasElpWpPLI4ACQCdznD25ms1EGTmHTjn-Q2Ss=.6a890ef4-a1fe-4216-a114-a9962dee28de@github.com>
 <ywDO5blMUHP4cs9Yyome20z6r4zPUYxKu5sDkQYrBrE=.447a7f01-fd2e-4319-a083-07a72a722dff@github.com>
 <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>
Message-ID: <zOTCpEofKS0qHGhwHjUXpDnO1ySeTely4K7Fjbwc7Ms=.442e8b8f-55a3-485f-ac68-c1138f8d0bb6@github.com>

On Fri, 19 Mar 2021 11:01:45 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> @cl4es would you mind creating a parent task of something like "Source code cleanups" and then another sub task for this change please?
>
> Created the subtask https://bugs.openjdk.java.net/browse/JDK-8263855 for this along with an umbrella RFE.

Thanks @cl4es -- do I need to update the git commit message as well, or is updating the title of the PR sufficient? I recall you suggesting not to do amend/rebases previously.

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

PR: https://git.openjdk.java.net/jdk/pull/3078

From redestad at openjdk.java.net  Fri Mar 19 13:30:39 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 13:30:39 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <zOTCpEofKS0qHGhwHjUXpDnO1ySeTely4K7Fjbwc7Ms=.442e8b8f-55a3-485f-ac68-c1138f8d0bb6@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <WZ-BfQasElpWpPLI4ACQCdznD25ms1EGTmHTjn-Q2Ss=.6a890ef4-a1fe-4216-a114-a9962dee28de@github.com>
 <ywDO5blMUHP4cs9Yyome20z6r4zPUYxKu5sDkQYrBrE=.447a7f01-fd2e-4319-a083-07a72a722dff@github.com>
 <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>
 <zOTCpEofKS0qHGhwHjUXpDnO1ySeTely4K7Fjbwc7Ms=.442e8b8f-55a3-485f-ac68-c1138f8d0bb6@github.com>
Message-ID: <xQ55QiAmbH2FQWrJk3zsSS1EwCFS5V1MNN6Z4WKKoSM=.bb3f4dbd-48d3-4e7d-a692-a9d5d92f3e7e@github.com>

On Fri, 19 Mar 2021 13:08:24 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> Created the subtask https://bugs.openjdk.java.net/browse/JDK-8263855 for this along with an umbrella RFE.
>
> Thanks @cl4es -- do I need to update the git commit message as well, or is updating the title of the PR sufficient? I recall you suggesting not to do amend/rebases previously.

No, the git commit messages here doesn't matter, the bots will use the PR name when merging into master. It's good form to use reasonably consistent commit messages as you add commits to a PR, but altering commit history is not necessary and might even be disruptive once a PR has been opened.

There's the /summary command you could use to add additional comments to the final commit, see https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/summary

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

PR: https://git.openjdk.java.net/jdk/pull/3078

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 13:34:46 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 13:34:46 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <xQ55QiAmbH2FQWrJk3zsSS1EwCFS5V1MNN6Z4WKKoSM=.bb3f4dbd-48d3-4e7d-a692-a9d5d92f3e7e@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <WZ-BfQasElpWpPLI4ACQCdznD25ms1EGTmHTjn-Q2Ss=.6a890ef4-a1fe-4216-a114-a9962dee28de@github.com>
 <ywDO5blMUHP4cs9Yyome20z6r4zPUYxKu5sDkQYrBrE=.447a7f01-fd2e-4319-a083-07a72a722dff@github.com>
 <7ty0ud28Z7ozfWLhyqFcrZV7kmDp43KHakhBjcu2FAU=.f56134f2-d2ea-46b7-85a8-4b965a904e1b@github.com>
 <zOTCpEofKS0qHGhwHjUXpDnO1ySeTely4K7Fjbwc7Ms=.442e8b8f-55a3-485f-ac68-c1138f8d0bb6@github.com>
 <xQ55QiAmbH2FQWrJk3zsSS1EwCFS5V1MNN6Z4WKKoSM=.bb3f4dbd-48d3-4e7d-a692-a9d5d92f3e7e@github.com>
Message-ID: <mvf3ZlfloBYu0vGA-b8gmlIGU8Kbjtnm1EyYljDi6pM=.71fe03be-41a4-48d1-9097-e784c6ea91a3@github.com>

On Fri, 19 Mar 2021 13:28:12 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Thanks @cl4es -- do I need to update the git commit message as well, or is updating the title of the PR sufficient? I recall you suggesting not to do amend/rebases previously.
>
> No, the git commit messages here doesn't matter, the bots will use the PR name when merging into master. It's good form to use reasonably consistent commit messages as you add commits to a PR, but altering commit history is not necessary and might even be disruptive once a PR has been opened.
> 
> There's the /summary command you could use to add additional comments to the final commit, see https://wiki.openjdk.java.net/display/SKARA/Pull+Request+Commands#PullRequestCommands-/summary

Thanks @cl4es will adjust my submissions appropriately in the future.

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

PR: https://git.openjdk.java.net/jdk/pull/3078

From redestad at openjdk.java.net  Fri Mar 19 14:13:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 14:13:40 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
Message-ID: <S1mUeGX1323bhwIudf7rhQb0OExKYEQ5aSwmR0py0fQ=.fa39716f-40c0-4421-ae70-611e14f30c8c@github.com>

On Thu, 18 Mar 2021 18:26:20 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

Overall good - found a few cases where the private modifier is in the wrong place that ought to be fixed as well.

src/java.naming/share/classes/com/sun/jndi/ldap/EventQueue.java line 48:

> 46:  */
> 47: final class EventQueue implements Runnable {
> 48:     static final private boolean debug = false;

Move private to the front?

src/java.naming/share/classes/com/sun/jndi/ldap/EventSupport.java line 116:

> 114:  */
> 115: final class EventSupport {
> 116:     static final private boolean debug = false;

Move private to the front?

src/java.naming/share/classes/com/sun/jndi/ldap/LdapSchemaCtx.java line 389:

> 387:     }
> 388: 
> 389:     static final private class SchemaInfo {

Move private to the front?

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

Changes requested by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3078

From rriggs at openjdk.java.net  Fri Mar 19 14:23:55 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 19 Mar 2021 14:23:55 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test [v2]
In-Reply-To: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
Message-ID: <D2_HoA6cv0FZ6G-f3QXpM6kEYg-BcdsTgED94qLKvB8=.dd64bb8f-d043-414a-ad1b-0cabd2e7eb11@github.com>

> Intermittent failures on Windows in a test of destroying the child warrant extending the time the parent waits after starting the child before destroying the child.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Redirect VM output away from stream under test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3049/files
  - new: https://git.openjdk.java.net/jdk/pull/3049/files/ba3d9479..d8d4fccc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3049&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3049&range=00-01

  Stats: 28 lines in 1 file changed: 23 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3049.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3049/head:pull/3049

PR: https://git.openjdk.java.net/jdk/pull/3049

From winterhalter at openjdk.java.net  Fri Mar 19 15:20:00 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Fri, 19 Mar 2021 15:20:00 GMT
Subject: RFR: 8263763: Synthetic constructor parameters of enum are not
 considered for annotation indices [v2]
In-Reply-To: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>
References: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>
Message-ID: <wkvUYUR9nw4dCBh0TKp2pOyIM1XEQAX3_E1EU3rgIys=.7309e577-1157-4cb4-987c-04c69aa15545@github.com>

> 8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices.

Rafael Winterhalter has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3082/files
  - new: https://git.openjdk.java.net/jdk/pull/3082/files/1170d79d..d50d5f4c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3082&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3082&range=00-01

  Stats: 8 lines in 3 files changed: 3 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3082.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3082/head:pull/3082

PR: https://git.openjdk.java.net/jdk/pull/3082

From winterhalter at openjdk.java.net  Fri Mar 19 15:20:00 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Fri, 19 Mar 2021 15:20:00 GMT
Subject: RFR: 8263763: Synthetic constructor parameters of enum are not
 considered for annotation indices
In-Reply-To: <fVXkjoj54yxGaLUucXUWruPLGhfzavFUBCgocbQ7obM=.66b25271-c306-46d8-a5ed-d7b4d2ccf608@github.com>
References: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>
 <fVXkjoj54yxGaLUucXUWruPLGhfzavFUBCgocbQ7obM=.66b25271-c306-46d8-a5ed-d7b4d2ccf608@github.com>
Message-ID: <oO4DMxm6_qVXVfjPnU_h9ZbPIgfZ9D5reRfmrkb02iA=.12b844e3-2a67-4156-8ed2-3299a096ba18@github.com>

On Fri, 19 Mar 2021 05:24:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> 8263763: The constructor of an enumeration prefixes with two synthetic arguments for constant name and ordinal index. For this reason, the constructor annotations need to be shifted two indices to the right, such that the annotation indices match with the parameter indices.
>
> A general comment, the enum constructor situation is a bit tricky as
> 
> 1) There is no 100% reliable way to determine which of a enum constructor's args are synthetic.
> 
> 2) How a Java compiler generates enum constructors is a compiler-internal contract since all the enum constructors must be private.
> 
> It is true that javac has consistently added two extra parameters as an implementation detail. Offhand, I don't know if ecj in particular has made the same choice. javac is not obliged to continue implementing enum constructors in this manner, so for better robustness, I think a fix in this space needs to be able to accommodate situations other than exactly N+2 parameters.

*ejc* issues the same constructor that prefixes a `String` and an `int` parameter. I agree that the solution is not perfect, but I would prefer it over the reflection API throwing an `IndexOutOfBoundsException` upon calling `getAnnotations()`, which nobody really expects upon a getter invocation.

I added a check to see if the enum constructor in question starts with a `String` and `int` parameter after checking if there are two excess parameters. I believe that that's at least an improvement over today's state where it's very unlikely that an enum constructor  yields an incorrect result in the reflection API whereas the result it is always incorrect today, given the implementation of both *ejc* and *javac*.

Ideally, this would of course also be fixed by javac (and ejc) such that the annotations are placed on the correct indices, but I still argue that the fix is an improvement for being able to properly process enum constructors for older class files also.

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

PR: https://git.openjdk.java.net/jdk/pull/3082

From stuefe at openjdk.java.net  Fri Mar 19 16:58:41 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 19 Mar 2021 16:58:41 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test [v2]
In-Reply-To: <D2_HoA6cv0FZ6G-f3QXpM6kEYg-BcdsTgED94qLKvB8=.dd64bb8f-d043-414a-ad1b-0cabd2e7eb11@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <D2_HoA6cv0FZ6G-f3QXpM6kEYg-BcdsTgED94qLKvB8=.dd64bb8f-d043-414a-ad1b-0cabd2e7eb11@github.com>
Message-ID: <g2GCS5RF48yaKf7IYiKh0Z6u_VggBOjJ8lUSSusSAMY=.d898fb57-84b0-4984-91e4-3c3d625aab7d@github.com>

On Fri, 19 Mar 2021 14:23:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Intermittent failures on Windows in a test of destroying the child warrant extending the time the parent waits after starting the child before destroying the child.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Redirect VM output away from stream under test

Hi Roger, thanks for taking my suggestion. Minor point below.

Cheers, Thomas

test/jdk/java/lang/ProcessBuilder/Basic.java line 2156:

> 2154:                         case 1:
> 2155:                             childArgs.set(1, "-XX:+DisplayVMOutputToStdout");
> 2156:                             pb.redirectInput(INHERIT);

not `redirectOutput()` ?

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From rriggs at openjdk.java.net  Fri Mar 19 17:04:40 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 19 Mar 2021 17:04:40 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test [v2]
In-Reply-To: <g2GCS5RF48yaKf7IYiKh0Z6u_VggBOjJ8lUSSusSAMY=.d898fb57-84b0-4984-91e4-3c3d625aab7d@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <D2_HoA6cv0FZ6G-f3QXpM6kEYg-BcdsTgED94qLKvB8=.dd64bb8f-d043-414a-ad1b-0cabd2e7eb11@github.com>
 <g2GCS5RF48yaKf7IYiKh0Z6u_VggBOjJ8lUSSusSAMY=.d898fb57-84b0-4984-91e4-3c3d625aab7d@github.com>
Message-ID: <2zkXOQXnhCvbikcZ3BGkJLqGwwDgQOPCa09tjreui_w=.87e5849d-bb3a-4bc5-9573-059421d99df5@github.com>

On Fri, 19 Mar 2021 16:54:43 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Redirect VM output away from stream under test
>
> test/jdk/java/lang/ProcessBuilder/Basic.java line 2156:
> 
>> 2154:                         case 1:
>> 2155:                             childArgs.set(1, "-XX:+DisplayVMOutputToStdout");
>> 2156:                             pb.redirectInput(INHERIT);
> 
> not `redirectOutput()` ?

The naming of the methods is from the point of view of the parent, not the child.
So it seems backward, but is correct.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 17:13:58 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 17:13:58 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming [v2]
In-Reply-To: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
Message-ID: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>

> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

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

  Added more replacements of 'final public' with 'public final'

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3078/files
  - new: https://git.openjdk.java.net/jdk/pull/3078/files/f1bc7269..1c900d2d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3078&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3078&range=00-01

  Stats: 106 lines in 37 files changed: 0 ins; 0 del; 106 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3078.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3078/head:pull/3078

PR: https://git.openjdk.java.net/jdk/pull/3078

From rriggs at openjdk.java.net  Fri Mar 19 17:17:02 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 19 Mar 2021 17:17:02 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test [v3]
In-Reply-To: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
Message-ID: <oAe8Vtz2bkRrxSvoW4-Hxq0oEKJ4q53HqNChZZUfVg0=.2822c626-09e6-4b57-851e-27bfe886da22@github.com>

> Intermittent failures on Windows in a test of destroying the child warrant extending the time the parent waits after starting the child before destroying the child.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Correct redirect of stdout

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3049/files
  - new: https://git.openjdk.java.net/jdk/pull/3049/files/d8d4fccc..6313399c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3049&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3049&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From igraves at openjdk.java.net  Fri Mar 19 17:22:39 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 19 Mar 2021 17:22:39 GMT
Subject: RFR: JDK-8263545: Convert jpackage to use Stream.toList() [v3]
In-Reply-To: <GFcs4P-yGlqxigHuBhA8Mha-6gxqZoVDV7s8oRZYeh4=.beb4fec3-0114-4ba2-9bc2-ffc7b7f4b4d5@github.com>
References: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
 <62Ef-iVsd0mI5YTduK-5OZXBSZOilNW8w58FlFt31Kc=.24dc8681-21bb-4b80-94d7-7f4f85c51efc@github.com>
 <GFcs4P-yGlqxigHuBhA8Mha-6gxqZoVDV7s8oRZYeh4=.beb4fec3-0114-4ba2-9bc2-ffc7b7f4b4d5@github.com>
Message-ID: <wAAOwkFIRqkLYNGpSQTQQD2iULJYd3AXTxe78knzOOQ=.3b37ce8b-2dea-4e57-b46a-89d33e1a85eb@github.com>

On Fri, 19 Mar 2021 01:17:34 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
>> 
>>  - Clarifying type argument and shorting a toArray invocation
>>  - Converting jpackage to use Stream.toList()
>
> Marked as reviewed by asemenyuk (Reviewer).

Ready for sponsoring when you all are.

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

PR: https://git.openjdk.java.net/jdk/pull/2997

From stuefe at openjdk.java.net  Fri Mar 19 17:32:40 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Fri, 19 Mar 2021 17:32:40 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test [v2]
In-Reply-To: <2zkXOQXnhCvbikcZ3BGkJLqGwwDgQOPCa09tjreui_w=.87e5849d-bb3a-4bc5-9573-059421d99df5@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <D2_HoA6cv0FZ6G-f3QXpM6kEYg-BcdsTgED94qLKvB8=.dd64bb8f-d043-414a-ad1b-0cabd2e7eb11@github.com>
 <g2GCS5RF48yaKf7IYiKh0Z6u_VggBOjJ8lUSSusSAMY=.d898fb57-84b0-4984-91e4-3c3d625aab7d@github.com>
 <2zkXOQXnhCvbikcZ3BGkJLqGwwDgQOPCa09tjreui_w=.87e5849d-bb3a-4bc5-9573-059421d99df5@github.com>
Message-ID: <1iJoj8t_71bFmd5rUpcVibF4lGlzH6ukPZlBz0WLR24=.6b4eb112-2528-48a7-a170-a4337211ecd6@github.com>

On Fri, 19 Mar 2021 17:01:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> test/jdk/java/lang/ProcessBuilder/Basic.java line 2156:
>> 
>>> 2154:                         case 1:
>>> 2155:                             childArgs.set(1, "-XX:+DisplayVMOutputToStdout");
>>> 2156:                             pb.redirectInput(INHERIT);
>> 
>> not `redirectOutput()` ?
>
> You are correct. will fix.
> (The Process streams are from the point of view of parent).

Yes, I have to look this up every time. Its not intuitive.

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From redestad at openjdk.java.net  Fri Mar 19 18:02:41 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 18:02:41 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming [v2]
In-Reply-To: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
Message-ID: <rInyl7rpONuJlsuBSgPQe142X9s8N040ZraY73FMXCI=.17c07e75-07f4-464b-a50e-891cd6ce78d7@github.com>

On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.
>
> Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added more replacements of 'final public' with 'public final'

Marked as reviewed by redestad (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3078

From naoto at openjdk.java.net  Fri Mar 19 18:02:47 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Mar 2021 18:02:47 GMT
Subject: RFR: 8263890: Broken links to Unicode.org
Message-ID: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>

Fixed several broken links to Unicode.org.

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

Commit messages:
 - 8263890: Broken links to Unicode.org

Changes: https://git.openjdk.java.net/jdk/pull/3093/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3093&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263890
  Stats: 22 lines in 8 files changed: 0 ins; 0 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3093.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3093/head:pull/3093

PR: https://git.openjdk.java.net/jdk/pull/3093

From redestad at openjdk.java.net  Fri Mar 19 18:10:43 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 18:10:43 GMT
Subject: RFR: 8263890: Broken links to Unicode.org
In-Reply-To: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
References: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
Message-ID: <XmFHKPQipAOnCL-2AIp3T8L2xItuaRevAETKB_l_5I4=.920f1d21-37d3-4cf8-accb-ccb6b09585ef@github.com>

On Fri, 19 Mar 2021 17:57:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed several broken links to Unicode.org.

Marked as reviewed by redestad (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3093

From iklam at openjdk.java.net  Fri Mar 19 18:13:40 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Fri, 19 Mar 2021 18:13:40 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test [v3]
In-Reply-To: <oAe8Vtz2bkRrxSvoW4-Hxq0oEKJ4q53HqNChZZUfVg0=.2822c626-09e6-4b57-851e-27bfe886da22@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <oAe8Vtz2bkRrxSvoW4-Hxq0oEKJ4q53HqNChZZUfVg0=.2822c626-09e6-4b57-851e-27bfe886da22@github.com>
Message-ID: <27Y0Mm1tyF4KYojEq92L50EEdAOXyFKsyPFHfNpQ1k0=.44a58cbb-b5e2-43d9-af32-80299fae964c@github.com>

On Fri, 19 Mar 2021 17:17:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Intermittent failures on Windows in a test of destroying the child warrant extending the time the parent waits after starting the child before destroying the child.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct redirect of stdout

LGTM. Just a small nit.

test/jdk/java/lang/ProcessBuilder/Basic.java line 2140:

> 2138:                 List<String> childArgs = new ArrayList<>(javaChildArgs);
> 2139:                 final ProcessBuilder pb = new ProcessBuilder(childArgs);
> 2140:                 {

I was a little confused until I looked up the JavaDoc of ProcessBuilder.

Maybe add a comment like "ProcessBuilder does NOT make a copy of childArgs so it's OK to modify it below"?

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

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3049

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 18:19:48 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 18:19:48 GMT
Subject: RFR: 8263885: Use the blessed modifier order in
 java.sql/rowset/transation.xa
Message-ID: <ZkOTNushZpPCLmNXLMokd1qi9xMNDRzSqgqmM-7__GQ=.32f5c175-5594-424f-97b7-a87a6f65f67d@github.com>

Fixes for the `java.sql`, `java.sql.rowset` and `java.transaction.xa` packages.

@cl4es would you mind creating a subtask of JDK-8263854 so I can update the PR title?

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

Commit messages:
 - Use the blessed modifier order in java.sql/rowset/transation.xa

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

PR: https://git.openjdk.java.net/jdk/pull/3090

From redestad at openjdk.java.net  Fri Mar 19 18:19:48 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 18:19:48 GMT
Subject: RFR: 8263885: Use the blessed modifier order in
 java.sql/rowset/transation.xa
In-Reply-To: <ZkOTNushZpPCLmNXLMokd1qi9xMNDRzSqgqmM-7__GQ=.32f5c175-5594-424f-97b7-a87a6f65f67d@github.com>
References: <ZkOTNushZpPCLmNXLMokd1qi9xMNDRzSqgqmM-7__GQ=.32f5c175-5594-424f-97b7-a87a6f65f67d@github.com>
Message-ID: <hBamdbmKNaoPcXOL-2GGe3WOcodk0iZnkUCgJ9OnlxY=.bb413a96-420e-448c-92db-9bb196c53bd4@github.com>

On Fri, 19 Mar 2021 15:27:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Fixes for the `java.sql`, `java.sql.rowset` and `java.transaction.xa` packages.
> 
> @cl4es would you mind creating a subtask of JDK-8263854 so I can update the PR title?

8263885

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

PR: https://git.openjdk.java.net/jdk/pull/3090

From redestad at openjdk.java.net  Fri Mar 19 18:27:39 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 18:27:39 GMT
Subject: RFR: 8263885: Use the blessed modifier order in
 java.sql/rowset/transation.xa
In-Reply-To: <ZkOTNushZpPCLmNXLMokd1qi9xMNDRzSqgqmM-7__GQ=.32f5c175-5594-424f-97b7-a87a6f65f67d@github.com>
References: <ZkOTNushZpPCLmNXLMokd1qi9xMNDRzSqgqmM-7__GQ=.32f5c175-5594-424f-97b7-a87a6f65f67d@github.com>
Message-ID: <lWMbLy7oaPMkFQ1Nh02zfsBl4sRuHfHQnlv_EI-hAp4=.0a02ac22-9190-4b45-a5eb-975fe4cae215@github.com>

On Fri, 19 Mar 2021 15:27:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Fixes for the `java.sql`, `java.sql.rowset` and `java.transaction.xa` packages.
> 
> @cl4es would you mind creating a subtask of JDK-8263854 so I can update the PR title?

Marked as reviewed by redestad (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3090

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 18:28:46 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 18:28:46 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base
Message-ID: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>

Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

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

Commit messages:
 - 8263658: Use the blessed modifier order in java.base

Changes: https://git.openjdk.java.net/jdk/pull/3094/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3094&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263658
  Stats: 19 lines in 5 files changed: 0 ins; 0 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3094.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3094/head:pull/3094

PR: https://git.openjdk.java.net/jdk/pull/3094

From naoto at openjdk.java.net  Fri Mar 19 18:33:38 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Mar 2021 18:33:38 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base
In-Reply-To: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
References: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
Message-ID: <WeJYWJVAt79HmlePFH6QIxKGhhuoxh1U4pKMzeJ-YP8=.5ba7a4f6-ce72-4291-a2ed-5f71535a9de5@github.com>

On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

Marked as reviewed by naoto (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3094

From redestad at openjdk.java.net  Fri Mar 19 18:36:40 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 18:36:40 GMT
Subject: RFR: 8263658: Use the blessed modifier order in java.base
In-Reply-To: <WeJYWJVAt79HmlePFH6QIxKGhhuoxh1U4pKMzeJ-YP8=.5ba7a4f6-ce72-4291-a2ed-5f71535a9de5@github.com>
References: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
 <WeJYWJVAt79HmlePFH6QIxKGhhuoxh1U4pKMzeJ-YP8=.5ba7a4f6-ce72-4291-a2ed-5f71535a9de5@github.com>
Message-ID: <WxErbi_jgld4GOO8LNVX2qglJgfmpjOQDg1ImAIS-vk=.e259caa7-7060-489a-a6d2-9a8a3fa9aebb@github.com>

On Fri, 19 Mar 2021 18:31:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.
>
> Marked as reviewed by naoto (Reviewer).

Can't reuse the bug IDs, sadly. Filed https://bugs.openjdk.java.net/browse/JDK-8263892 (note the new summary name to disambiguate)

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

PR: https://git.openjdk.java.net/jdk/pull/3094

From rriggs at openjdk.java.net  Fri Mar 19 18:41:51 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 19 Mar 2021 18:41:51 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test [v4]
In-Reply-To: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
Message-ID: <VS4eIruAE4HiLhc4LProaPiEczJf62yZRQz0gs5W_50=.f2faa8bb-5520-484d-a581-8b17d3cbaf25@github.com>

> Intermittent failures on Windows in a test of destroying the child warrant extending the time the parent waits after starting the child before destroying the child.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Clarify modification of argument list after creating ProcessBuilder

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3049/files
  - new: https://git.openjdk.java.net/jdk/pull/3049/files/6313399c..31c35beb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3049&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3049&range=02-03

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

PR: https://git.openjdk.java.net/jdk/pull/3049

From joehw at openjdk.java.net  Fri Mar 19 18:46:41 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 19 Mar 2021 18:46:41 GMT
Subject: RFR: 8263890: Broken links to Unicode.org
In-Reply-To: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
References: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
Message-ID: <RyyqvQ-TP0Rc31L8srfPTP0C5s26rqV-xTwCvCxO6ZA=.d007a872-42ae-4bba-9992-08c56eae306c@github.com>

On Fri, 19 Mar 2021 17:57:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed several broken links to Unicode.org.

Some minor comments.

src/java.base/share/classes/java/text/Collator.java line 211:

> 209:      * FULL_DECOMPOSITION corresponds to Normalization Form KD as
> 210:      * described in
> 211:      * <a href="http://www.unicode.org/reports/tr15/tr15-23.html">Unicode

While the previous "Unicode Technical Report #15" was in http://unicode.org/reports/tr15/tr15-15.html, by tr15-23 it was "approved by the Unicode Technical Committee as a Unicode Standard Annex". Do we want to change the title to "Unicode Standard Annex #15"? Also, is Collator stuck with a particular revision (e.g. 23) or do we refer to the latest, e.g. "http://www.unicode.org/reports/tr15/"?

src/java.base/share/classes/jdk/internal/icu/text/BidiLine.java line 50:

> 48:      * which has already been processed according to
> 49:      * the Unicode 3.0 Bidi algorithm as defined in
> 50:      * http://www.unicode.org/reports/tr9/ , version 13,

Previous references provided links e.g. "<a href="http://www.unicode.org/unicode/reports/tr9/">Unicode Standard Annex #9</a>" instead of URL.

src/java.base/share/classes/jdk/internal/icu/text/Normalizer2.java line 46:

> 44:  * a string is already normalized.
> 45:  * The most commonly used normalization forms are those defined in
> 46:  * http://www.unicode.org/reports/tr15/

Same as above.

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegularExpression.java line 476:

> 474:  * <h3>TODO</h3>
> 475:  * <ul>
> 476:  *   <li><a href="http://www.unicode.org/reports/tr18/">Unicode Regular Expression Guidelines</a>

Just a note that the references had been report numbers, e.g. Report/Annex #15, while this one the Title (by the way, the official title was "Unicode Regular Expressions"). The only exception seems to be the one in NormalizerBase.java where it referred to the number + title.

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

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3093

From iris at openjdk.java.net  Fri Mar 19 18:49:39 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 19 Mar 2021 18:49:39 GMT
Subject: RFR: 8263890: Broken links to Unicode.org
In-Reply-To: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
References: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
Message-ID: <8LHQ2ODp9B_zd5EYnCVgGDQRFE_OiA-xrMUkMO7D2lA=.62332eea-65a9-452d-aa3a-cc8eaeaff93a@github.com>

On Fri, 19 Mar 2021 17:57:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed several broken links to Unicode.org.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3093

From lancea at openjdk.java.net  Fri Mar 19 19:32:38 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 19 Mar 2021 19:32:38 GMT
Subject: RFR: 8263885: Use the blessed modifier order in
 java.sql/rowset/transation.xa
In-Reply-To: <ZkOTNushZpPCLmNXLMokd1qi9xMNDRzSqgqmM-7__GQ=.32f5c175-5594-424f-97b7-a87a6f65f67d@github.com>
References: <ZkOTNushZpPCLmNXLMokd1qi9xMNDRzSqgqmM-7__GQ=.32f5c175-5594-424f-97b7-a87a6f65f67d@github.com>
Message-ID: <ii788EpFS7OuXtdBIAv1U6-p_crYehNo4WPHP6Lg_gw=.b78c7bef-781c-4941-aee3-9690008263f1@github.com>

On Fri, 19 Mar 2021 15:27:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Fixes for the `java.sql`, `java.sql.rowset` and `java.transaction.xa` packages.
> 
> @cl4es would you mind creating a subtask of JDK-8263854 so I can update the PR title?

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3090

From igraves at openjdk.java.net  Fri Mar 19 19:54:40 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 19 Mar 2021 19:54:40 GMT
Subject: Integrated: JDK-8263545: Convert jpackage to use Stream.toList()
In-Reply-To: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
References: <HZUz-lFBZhiTFsAaH1AnjTFozu8vyeU--kQQCCAgUo0=.8a5a5552-8f09-4aa0-846d-3d74bd12c1d6@github.com>
Message-ID: <RHKlwPmqz8goDI-qzVSauH02hWzcXdwqjELUyCeyV-o=.815b4715-a2b2-42ad-bf30-204677f6d5ed@github.com>

On Sun, 14 Mar 2021 18:22:50 GMT, Ian Graves <igraves at openjdk.org> wrote:

> This converts jpackage to use `Stream.toList()` instead of `Stream.collect(Collectors.toList())`. One piece of code was modified to not mutate a list in addition to one test that used a mutating sort on a list. The rest of the changes are simple substitutions.

This pull request has now been integrated.

Changeset: 0b5216a9
Author:    Ian Graves <igraves at openjdk.org>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0b5216a9
Stats:     47 lines in 17 files changed: 1 ins; 3 del; 43 mod

8263545: Convert jpackage to use Stream.toList()

Reviewed-by: asemenyuk, almatvee

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

PR: https://git.openjdk.java.net/jdk/pull/2997

From iris at openjdk.java.net  Fri Mar 19 20:04:39 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 19 Mar 2021 20:04:39 GMT
Subject: RFR: 8263892: More modifier order fixes in java.base
In-Reply-To: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
References: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
Message-ID: <WW8Uiz7VWT63fRllDsyyOIM_jcce7igUiZ9GZ2WVVH8=.46a4ff02-0c9e-49ca-bf13-dc7de32c497b@github.com>

On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3094

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 21:07:43 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 21:07:43 GMT
Subject: Integrated: 8263885: Use the blessed modifier order in
 java.sql/rowset/transation.xa
In-Reply-To: <ZkOTNushZpPCLmNXLMokd1qi9xMNDRzSqgqmM-7__GQ=.32f5c175-5594-424f-97b7-a87a6f65f67d@github.com>
References: <ZkOTNushZpPCLmNXLMokd1qi9xMNDRzSqgqmM-7__GQ=.32f5c175-5594-424f-97b7-a87a6f65f67d@github.com>
Message-ID: <rJXNbuwV9u735o8NGWDhUO_Ru9hPCuOxixVkGwYWsPk=.19cf0e9e-0c85-4230-a4d7-37d99913a05a@github.com>

On Fri, 19 Mar 2021 15:27:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Fixes for the `java.sql`, `java.sql.rowset` and `java.transaction.xa` packages.
> 
> @cl4es would you mind creating a subtask of JDK-8263854 so I can update the PR title?

This pull request has now been integrated.

Changeset: 80d3ea02
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/80d3ea02
Stats:     133 lines in 6 files changed: 0 ins; 0 del; 133 mod

8263885: Use the blessed modifier order in java.sql/rowset/transation.xa

Reviewed-by: redestad, lancea

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

PR: https://git.openjdk.java.net/jdk/pull/3090

From github.com+76791+alblue at openjdk.java.net  Fri Mar 19 21:09:42 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Fri, 19 Mar 2021 21:09:42 GMT
Subject: Integrated: 8263892: More modifier order fixes in java.base
In-Reply-To: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
References: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
Message-ID: <3DMY9iQ9ES67nDcNnpKUWpfQ_3HwoQ-7LSkJ-hZCNtA=.027dd909-930c-4b61-bee3-62345ac73c25@github.com>

On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

This pull request has now been integrated.

Changeset: 77ebc110
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/77ebc110
Stats:     19 lines in 5 files changed: 0 ins; 0 del; 19 mod

8263892: More modifier order fixes in java.base

Reviewed-by: naoto, iris, redestad

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

PR: https://git.openjdk.java.net/jdk/pull/3094

From redestad at openjdk.java.net  Fri Mar 19 21:09:41 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 19 Mar 2021 21:09:41 GMT
Subject: RFR: 8263892: More modifier order fixes in java.base
In-Reply-To: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
References: <GNUkZ74IdfOcQcV2ApnWyDgzN5L4eeqKHOrA4cb2dYk=.b67a4568-13e2-469f-911b-256b206248cf@github.com>
Message-ID: <ju3pqamjIIrrIhgVETmEzWBlXQgibYhLCkHqJEDurGc=.3bc3ed82-b34d-48ae-835d-c7126f9fd165@github.com>

On Fri, 19 Mar 2021 18:23:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> Additional changes found in `java.base` of `final private` -> `private final`. Filed with existing bug because it's the same module; can change to a different bug number if required.

Marked as reviewed by redestad (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/3094

From naoto at openjdk.java.net  Fri Mar 19 21:23:03 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Mar 2021 21:23:03 GMT
Subject: RFR: 8263890: Broken links to Unicode.org [v2]
In-Reply-To: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
References: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
Message-ID: <0jlj0Svj0A2dteB8XDfJm4194KRtyWpoOx5Y4r-Y1ls=.fb544b73-3342-48fa-b9e1-a97dbb58267a@github.com>

> Fixed several broken links to Unicode.org.

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

  Addressed review comments.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3093/files
  - new: https://git.openjdk.java.net/jdk/pull/3093/files/2b32b86a..37093a4d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3093&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3093&range=00-01

  Stats: 24 lines in 6 files changed: 4 ins; 0 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3093.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3093/head:pull/3093

PR: https://git.openjdk.java.net/jdk/pull/3093

From naoto at openjdk.java.net  Fri Mar 19 21:25:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Mar 2021 21:25:40 GMT
Subject: RFR: 8263890: Broken links to Unicode.org [v2]
In-Reply-To: <RyyqvQ-TP0Rc31L8srfPTP0C5s26rqV-xTwCvCxO6ZA=.d007a872-42ae-4bba-9992-08c56eae306c@github.com>
References: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
 <RyyqvQ-TP0Rc31L8srfPTP0C5s26rqV-xTwCvCxO6ZA=.d007a872-42ae-4bba-9992-08c56eae306c@github.com>
Message-ID: <nmF3Hn8yJhlcdffba40xZNyaiLG_z5M0CIePDiM7CBM=.66102792-3935-4fe5-b0b4-04f14a0e07e7@github.com>

On Fri, 19 Mar 2021 18:43:30 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Some minor comments.

Thanks, Joe. Addressed them as suggested.

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

PR: https://git.openjdk.java.net/jdk/pull/3093

From joehw at openjdk.java.net  Fri Mar 19 21:33:45 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 19 Mar 2021 21:33:45 GMT
Subject: RFR: 8263890: Broken links to Unicode.org [v2]
In-Reply-To: <0jlj0Svj0A2dteB8XDfJm4194KRtyWpoOx5Y4r-Y1ls=.fb544b73-3342-48fa-b9e1-a97dbb58267a@github.com>
References: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
 <0jlj0Svj0A2dteB8XDfJm4194KRtyWpoOx5Y4r-Y1ls=.fb544b73-3342-48fa-b9e1-a97dbb58267a@github.com>
Message-ID: <QgPsbRGEQrTkudnMTcKFh-HO4c4uUXj4MO2WQZ4YL2I=.a657b09b-6f82-4759-abb3-08925ac75ae3@github.com>

On Fri, 19 Mar 2021 21:23:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixed several broken links to Unicode.org.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed review comments.

Looks all good. Thanks Naoto.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3093

From bpb at openjdk.java.net  Fri Mar 19 21:44:43 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 19 Mar 2021 21:44:43 GMT
Subject: RFR: 4926314: Optimize Reader.read(CharBuffer) [v9]
In-Reply-To: <84oaCizi9wr-vVk-L4OwgmBH8kdLBx5gzy7pejtfko8=.a3d79db9-f147-450e-8d3c-fc491cfa12fe@github.com>
References: <Nn0aXEqs7Dys4bAQwMTrB3e4-ZWAs2QX0mKD9tpzFSg=.6e3f239c-086f-4b28-a21b-848548910b20@github.com>
 <EUUFMQU57_NWpHrEHMZqSk3CAKyv1HMrZd1_MN-ytpQ=.f2082a86-d7d1-4d7f-81ad-f725e15f1e35@github.com>
 <84oaCizi9wr-vVk-L4OwgmBH8kdLBx5gzy7pejtfko8=.a3d79db9-f147-450e-8d3c-fc491cfa12fe@github.com>
Message-ID: <ub2YN6oky_doUEosFvVe-978qwfo_OC3kHHbOkMb3yo=.93bb70c4-987f-432d-b0d4-7cea9f322097@github.com>

On Sun, 14 Mar 2021 12:57:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Philippe Marschall has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
>> 
>>  - Merge master
>>  - Fix bug in CharArrayReader and add unit test
>>  - Clean up unit tests
>>  - Revert off-heap code path
>>  - Replace c-style array declarations
>>  - Share work buffer between #skip and #read
>>  - Update copyright year
>>  - Implement review comment
>>  - Revert StreamDecoder changes
>>  - Implement CharArrayReader#read(CharBuffer)
>>  - ... and 5 more: https://git.openjdk.java.net/jdk/compare/d339320e...c4c859e0
>
> src/java.base/share/classes/java/io/Reader.java line 205:
> 
>> 203:                 target.put(cbuf, 0, nread);
>> 204:         }
>> 205:         return nread;
> 
> Thanks for bringing this back to just the heap buffer case. This part looks good now.

Agreed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1915

From naoto at openjdk.java.net  Fri Mar 19 21:51:40 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 19 Mar 2021 21:51:40 GMT
Subject: Integrated: 8263890: Broken links to Unicode.org
In-Reply-To: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
References: <hVVKboPF6E8Le-3jUBzzgHTzdY3YuaQnDf1_JXJES2g=.bd19bfd0-0024-47ef-9a24-52fe2fa4bf6c@github.com>
Message-ID: <NW7A-ciQHcW2ldPntwUqyC-ef7GP6Ow1zpSK935dMY8=.7e10e82e-80de-4ab4-be4e-4d5bdcaa2c45@github.com>

On Fri, 19 Mar 2021 17:57:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixed several broken links to Unicode.org.

This pull request has now been integrated.

Changeset: 96e5c3f1
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/96e5c3f1
Stats:     37 lines in 8 files changed: 4 ins; 0 del; 33 mod

8263890: Broken links to Unicode.org

Reviewed-by: redestad, joehw, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/3093

From stuefe at openjdk.java.net  Sat Mar 20 05:57:40 2021
From: stuefe at openjdk.java.net (Thomas Stuefe)
Date: Sat, 20 Mar 2021 05:57:40 GMT
Subject: RFR: 8263729: [test] Extend time to wait before destroying child
 in ProcssBuilder Basic test [v4]
In-Reply-To: <VS4eIruAE4HiLhc4LProaPiEczJf62yZRQz0gs5W_50=.f2faa8bb-5520-484d-a581-8b17d3cbaf25@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <VS4eIruAE4HiLhc4LProaPiEczJf62yZRQz0gs5W_50=.f2faa8bb-5520-484d-a581-8b17d3cbaf25@github.com>
Message-ID: <RXxDpfJwBl2w64TVA4QwIv9fE5kWl3YGCzpUEhajoGs=.1700f9a3-c345-4790-97f6-d9443ebb171e@github.com>

On Fri, 19 Mar 2021 18:41:51 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Intermittent failures on Windows in a test of destroying the child warrant extending the time the parent waits after starting the child before destroying the child.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify modification of argument list after creating ProcessBuilder

Looks good to me, if the intent was to fix potential write blockages in the child process (in which case maybe reformulate the issue title). 

I'm sorry I derailed your original wait idea, as well as Ioi's ideas of syncing with the child. Both may still be needed after this fix.

Cheers, Thomas

-------------

Marked as reviewed by stuefe (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3049

From snihalani4 at gmail.com  Sat Mar 20 06:31:53 2021
From: snihalani4 at gmail.com (Suren Nihalani)
Date: Fri, 19 Mar 2021 23:31:53 -0700
Subject: Looking for a starter task. Maybe JDK-8253396 ?
Message-ID: <CAF807Oe4UjShjBToVqudr_=W96NOWcPE8MU3VvPTZsznzfEXyQ@mail.gmail.com>

Hi,

I am new openjdk (I've been using java for 7 years but I am new to
contributing to openjdk!). I was looking for interesting starter tasks to
help out with. JDK-8253396 looked like an easy to implement candidate. I am
open to other suggestions too (feel free to little r as well)!

The contribution guide suggested I socialize my change before I code it up.
Seems like the implementation would be straightforward and similar to
Predicate.java. Are folks okay with this change?

Thanks for looking into this!

From jai.forums2013 at gmail.com  Sat Mar 20 07:16:01 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sat, 20 Mar 2021 12:46:01 +0530
Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null
 device)?
In-Reply-To: <1d19e40b-1cad-00f3-0f8a-a11e4bf32a31@gmail.com>
References: <dd06d633-1f12-7613-86ba-c7a25bf31203@gmail.com>
 <e9a89da8-b625-8797-8a21-d5ab65e49283@oracle.com>
 <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com>
 <154fbc5c-77a9-9abf-5971-4785c9dd5415@oracle.com>
 <2f8cec59-e49b-b304-3686-a695439a9db8@gmail.com>
 <1d19e40b-1cad-00f3-0f8a-a11e4bf32a31@gmail.com>
Message-ID: <d21a76a8-5004-4925-1224-fc8e31664101@gmail.com>


On 17/03/21 3:16 pm, Jaikiran Pai wrote:
>
> On 17/03/21 3:10 pm, Jaikiran Pai wrote:
>> Hello Alan,
>>
>> On 17/03/21 2:45 pm, Alan Bateman wrote:
>>> On 17/03/2021 08:21, Jaikiran Pai wrote:
>>>> :
>>>>
>>>> I can confirm that using "NUL" or "nul" work fine in the above code,
>>>
>>> I don't know the context for your question 
>>
>> ...
>>
> FWIW - that bug report states that they ran into this even when using 
> "nul" and not just "nul:". So there might be something more going on 
> here and am just waiting to see if they can provide us a build file to 
> reproduce this issue.

I received some inputs on that Ant bugzilla issue. Based on that, I was 
able to reproduce the exception and IMO it's a bug in 
Files.newOutputStream() API. I have opened 
https://bugs.openjdk.java.net/browse/JDK-8263898 with the relevant 
details. I considered this a bug and took the liberty of opening that 
JBS issue because as I note in that issue, this only happens 
specifically when TRUNCATE_EXISTING (default) option gets used against 
"nul" on Windows.


-Jaikiran



From szegedia at gmail.com  Sat Mar 20 16:17:07 2021
From: szegedia at gmail.com (Attila Szegedi)
Date: Sat, 20 Mar 2021 17:17:07 +0100
Subject: Class.getRecordComponents security checks
In-Reply-To: <838938525.1918410.1613941022924.JavaMail.zimbra@u-pem.fr>
References: <87EA37FD-B688-4EB3-B8E1-F51F6FB4273C@gmail.com>
 <838938525.1918410.1613941022924.JavaMail.zimbra@u-pem.fr>
Message-ID: <9754590D-790D-4AED-88C8-24E292BA7AAC@gmail.com>


> On 2021. Feb 21., at 21:57, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> ----- Mail original -----
>> De: "Attila Szegedi" <szegedia at gmail.com>
>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoy?: Dimanche 21 F?vrier 2021 21:14:48
>> Objet: Class.getRecordComponents security checks
> 
>> Hey folks,
>> 
>> Why are security checks for Class.getRecordComponents as strict as those for
>> e.g. getDeclaredMethods? I would?ve expected they?d be as strict as those for
>> e.g. getMethods. Specifically, the difference is the:
>> 
>>> ?the caller's class loader is not the same as the class loader of this class and
>>> invocation of s.checkPermission method with
>>> RuntimePermission("accessDeclaredMembers") denies access to the declared
>>> methods within this class?
> 
> Good question, getRecordComponents() list the record components not the record accessors,
> while each record component has a corresponding accessor method, the reverse is not true.
> 
> so here, what you are asking is more like asking fields than methods, so it's more like getDeclaredFields() than getMethods(),
> hence the runtime check if there is a SecurityManager enabled.

But the whole point is that accessors are methods, and not fields, I thought. And even if it were so, we have a distinction between getFields and getDeclaredFields. There?s no separation of getRecordComponents vs. hypothetical getDeclaredRecordComponents.

I?m convinced I don?t understand this issue completely, and I remain confused. I appreciate you trying to clear it up, the problem of continued failure to understand is most likely inside my head :-)

> 
>> 
>> step. Aren?t record accessors supposed to be public?
> 
> yes, at least for the code generated by javac, accessors are always public
> (the class itself may be non public, and the package may not be exported).

Right, but for non-record classes you could also invoke e.g. getMethods() on it.

Attila.


From kbarrett at openjdk.java.net  Sun Mar 21 04:00:07 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 21 Mar 2021 04:00:07 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread
Message-ID: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>

Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.

In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.

Testing:
mach5 tier1
New AutoStop test verifies the specified cleanup behavior.
(There are existing tests involving Timer.cancel.)

-------------

Commit messages:
 - Use cleaner instead of finalize to auto stop Timer thread

Changes: https://git.openjdk.java.net/jdk/pull/3106/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3106&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263903
  Stats: 110 lines in 2 files changed: 96 ins; 3 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3106.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3106/head:pull/3106

PR: https://git.openjdk.java.net/jdk/pull/3106

From zlatinb at gmail.com  Sat Mar 20 17:25:04 2021
From: zlatinb at gmail.com (Zlatin Balevsky)
Date: Sat, 20 Mar 2021 17:25:04 +0000
Subject: Production use of "jpackage.app-path" property
Message-ID: <CAG03-8FX-MWX5+PSdU=QaWysitEhZGwRq6TQNDKNieCmQ0S=JA@mail.gmail.com>

Hi,

In my application I need to know the absolute path of the executable
generated by jpackage at runtime.  I found the "jpackage.app-path" system
property and it is exactly what I was looking for.  However, I found no
documentation relating to it and am concerned that since it's undocumented
it may go away in future JDK versions.

Is that a valid concern?  Can I count on it being there in the next LTS
release of the JDK?

Thank you in advance
Zlatin Balevsky

From dholmes at openjdk.java.net  Sun Mar 21 22:52:50 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 21 Mar 2021 22:52:50 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread
In-Reply-To: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
Message-ID: <g--gkqG85koWEoF4jnp8gKwqrECb_yQTnsghM2oqdNk=.ae50e379-b5a2-42a6-95d1-be485b9c1b4d@github.com>

On Sun, 21 Mar 2021 03:53:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
> 
> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
> 
> Testing:
> mach5 tier1
> New AutoStop test verifies the specified cleanup behavior.
> (There are existing tests involving Timer.cancel.)

test/jdk/java/util/Timer/AutoStop.java line 67:

> 65:             t.schedule(new TimerTask() {
> 66:                     public void run() {
> 67:                         ++counter;

This is not thread-safe. Operations on volatile variables are not atomic.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3106

From dholmes at openjdk.java.net  Sun Mar 21 22:59:42 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Sun, 21 Mar 2021 22:59:42 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread
In-Reply-To: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
Message-ID: <0ql5y-R-IOMNjyA_1dV9nWE-_-o1oBPSzs3ci4o_qP0=.5723dc2f-3a88-4c68-b36f-46158197e01f@github.com>

On Sun, 21 Mar 2021 03:53:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
> 
> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
> 
> Testing:
> mach5 tier1
> New AutoStop test verifies the specified cleanup behavior.
> (There are existing tests involving Timer.cancel.)

test/jdk/java/util/Timer/AutoStop.java line 47:

> 45:                 public void run() {
> 46:                     tdThread = Thread.currentThread();
> 47:                     synchronized(wakeup) {

tdThread should be set inside the sync block, and then doesn't need to be declared volatile

-------------

PR: https://git.openjdk.java.net/jdk/pull/3106

From kbarrett at openjdk.java.net  Mon Mar 22 05:39:42 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 22 Mar 2021 05:39:42 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread
In-Reply-To: <g--gkqG85koWEoF4jnp8gKwqrECb_yQTnsghM2oqdNk=.ae50e379-b5a2-42a6-95d1-be485b9c1b4d@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
 <g--gkqG85koWEoF4jnp8gKwqrECb_yQTnsghM2oqdNk=.ae50e379-b5a2-42a6-95d1-be485b9c1b4d@github.com>
Message-ID: <Kd5-7FaaDNtecMsSYABqIB4hBMK_V_3Y4KujTiydcPg=.e3359a5f-8458-4da5-b8de-b9ec12de5fad@github.com>

On Sun, 21 Mar 2021 22:49:37 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>> 
>> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
>> 
>> Testing:
>> mach5 tier1
>> New AutoStop test verifies the specified cleanup behavior.
>> (There are existing tests involving Timer.cancel.)
>
> test/jdk/java/util/Timer/AutoStop.java line 67:
> 
>> 65:             t.schedule(new TimerTask() {
>> 66:                     public void run() {
>> 67:                         ++counter;
> 
> This is not thread-safe. Operations on volatile variables are not atomic.

Only one thread (the timer's thread) is writing, via a sequential series of task executions, so the simple increments are fine.  I made `counter` volatile because it's being written by one thread and read by a different thread.  Happy to drop the qualifier if that's not needed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3106

From kbarrett at openjdk.java.net  Mon Mar 22 05:42:40 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 22 Mar 2021 05:42:40 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread
In-Reply-To: <0ql5y-R-IOMNjyA_1dV9nWE-_-o1oBPSzs3ci4o_qP0=.5723dc2f-3a88-4c68-b36f-46158197e01f@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
 <0ql5y-R-IOMNjyA_1dV9nWE-_-o1oBPSzs3ci4o_qP0=.5723dc2f-3a88-4c68-b36f-46158197e01f@github.com>
Message-ID: <j8YisrJ_ymxy5ObTqaRq8mgJZwg8XRmP3u32yiuOAxQ=.057761db-b55b-4b64-8bcb-899e08f4a57b@github.com>

On Sun, 21 Mar 2021 22:57:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>> 
>> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
>> 
>> Testing:
>> mach5 tier1
>> New AutoStop test verifies the specified cleanup behavior.
>> (There are existing tests involving Timer.cancel.)
>
> test/jdk/java/util/Timer/AutoStop.java line 47:
> 
>> 45:                 public void run() {
>> 46:                     tdThread = Thread.currentThread();
>> 47:                     synchronized(wakeup) {
> 
> tdThread should be set inside the sync block, and then doesn't need to be declared volatile

Without volatile is the while loop still okay?  And the read for the join call?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3106

From dholmes at openjdk.java.net  Mon Mar 22 06:16:42 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 22 Mar 2021 06:16:42 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread
In-Reply-To: <j8YisrJ_ymxy5ObTqaRq8mgJZwg8XRmP3u32yiuOAxQ=.057761db-b55b-4b64-8bcb-899e08f4a57b@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
 <0ql5y-R-IOMNjyA_1dV9nWE-_-o1oBPSzs3ci4o_qP0=.5723dc2f-3a88-4c68-b36f-46158197e01f@github.com>
 <j8YisrJ_ymxy5ObTqaRq8mgJZwg8XRmP3u32yiuOAxQ=.057761db-b55b-4b64-8bcb-899e08f4a57b@github.com>
Message-ID: <izy2AQesqSrafW3pYMpTsmQtMP0fae3Eo6pOR5ROJSI=.e23d4777-ff42-4226-bc97-33070f17e2f9@github.com>

On Mon, 22 Mar 2021 05:40:10 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> test/jdk/java/util/Timer/AutoStop.java line 47:
>> 
>>> 45:                 public void run() {
>>> 46:                     tdThread = Thread.currentThread();
>>> 47:                     synchronized(wakeup) {
>> 
>> tdThread should be set inside the sync block, and then doesn't need to be declared volatile
>
> Without volatile is the while loop still okay?  And the read for the join call?

Yes the while loop is okay because the access is within a synchronized block.

When the loop exits tdThread is seen as non-null by the current thread, and that field is never written to again, so when the current thread does the join() it has to be using the non-null value of tdThread that it previously saw.

>> test/jdk/java/util/Timer/AutoStop.java line 67:
>> 
>>> 65:             t.schedule(new TimerTask() {
>>> 66:                     public void run() {
>>> 67:                         ++counter;
>> 
>> This is not thread-safe. Operations on volatile variables are not atomic.
>
> Only one thread (the timer's thread) is writing, via a sequential series of task executions, so the simple increments are fine.  I made `counter` volatile because it's being written by one thread and read by a different thread.  Happy to drop the qualifier if that's not needed.

Apologies - I thought there was real concurrency going on there. :)
The volatile is correct for the reason you cited.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3106

From zlatinb at gmail.com  Sun Mar 21 14:16:42 2021
From: zlatinb at gmail.com (Zlatin Balevsky)
Date: Sun, 21 Mar 2021 14:16:42 +0000
Subject: Problem signing Windows JPackage installers
Message-ID: <CAG03-8GjLGyKpvveA3vPQPYh1Q9aSrQk-tA=L7wDFc_8W8guZQ@mail.gmail.com>

Hi,

The installers that JPackage 16 generates seem to just extract an .msi
which performs the actual installation.  There are two problems with that:

1. The .msi is extracted to a temporary location and has a temporary name.
So the windows prompt that shows up and asks the user whether they are sure
they want to perform the installation does not show the name of the
installer/application.
2. Furthermore, even if the .exe installer is signed with a code signing
certificate, since the window prompts on the extracted .msi, the prompt is
still colored yellow instead of blue (which is what it should be when the
installer is signed)

In my use case it is essential that the prompt appears blue, so I'm forced
to use a hybrid approach of generating the app image with JPackage and then
using a different installer framework (like NSIS) to generate the final
distributable.  Of course this is far from ideal.

Just thought I'd let you know and best regards,
Zlatin Balevsky

From kbarrett at openjdk.java.net  Mon Mar 22 07:19:28 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 22 Mar 2021 07:19:28 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread [v2]
In-Reply-To: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
Message-ID: <8GZqLhOohWvt6kS6lh27ZviQprQGEW-Ca0JjG7TK9AM=.55d865e7-8210-4255-8ca2-89c23cce522b@github.com>

> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
> 
> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
> 
> Testing:
> mach5 tier1
> New AutoStop test verifies the specified cleanup behavior.
> (There are existing tests involving Timer.cancel.)

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  dholmes review

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3106/files
  - new: https://git.openjdk.java.net/jdk/pull/3106/files/0d120f56..2153a4c3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3106&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3106&range=00-01

  Stats: 5 lines in 1 file changed: 2 ins; 1 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3106.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3106/head:pull/3106

PR: https://git.openjdk.java.net/jdk/pull/3106

From kbarrett at openjdk.java.net  Mon Mar 22 07:19:31 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 22 Mar 2021 07:19:31 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread [v2]
In-Reply-To: <8GZqLhOohWvt6kS6lh27ZviQprQGEW-Ca0JjG7TK9AM=.55d865e7-8210-4255-8ca2-89c23cce522b@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
 <8GZqLhOohWvt6kS6lh27ZviQprQGEW-Ca0JjG7TK9AM=.55d865e7-8210-4255-8ca2-89c23cce522b@github.com>
Message-ID: <jabWIlSLkxCtllsti235zSd24K_Ubh0gGc8ZDwOnXQ0=.62f7b94e-c3da-448e-8dc0-6520bbf74a9a@github.com>

On Mon, 22 Mar 2021 07:15:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>> 
>> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
>> 
>> Testing:
>> mach5 tier1
>> New AutoStop test verifies the specified cleanup behavior.
>> (There are existing tests involving Timer.cancel.)
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dholmes review

test/jdk/java/util/Timer/AutoStop.java line 27:

> 25:  * @test
> 26:  * @bug 8263903
> 27:  * @requires vm.gc != "Epsilon"

I added the `@requires` late in dev/test and used the wrong test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3106

From dholmes at openjdk.java.net  Mon Mar 22 07:38:38 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 22 Mar 2021 07:38:38 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread [v2]
In-Reply-To: <8GZqLhOohWvt6kS6lh27ZviQprQGEW-Ca0JjG7TK9AM=.55d865e7-8210-4255-8ca2-89c23cce522b@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
 <8GZqLhOohWvt6kS6lh27ZviQprQGEW-Ca0JjG7TK9AM=.55d865e7-8210-4255-8ca2-89c23cce522b@github.com>
Message-ID: <Dz72pcdvy4-kEC1yfg8RMKud_boyZ7qpP-XjDbq4vaQ=.7c9c6af6-37dc-4f03-beaf-e685523b5fb4@github.com>

On Mon, 22 Mar 2021 07:19:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>> 
>> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
>> 
>> Testing:
>> mach5 tier1
>> New AutoStop test verifies the specified cleanup behavior.
>> (There are existing tests involving Timer.cancel.)
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dholmes review

This looks good to me, but of course core-libs folk need to review.

Thanks,
David

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3106

From tvaleev at openjdk.java.net  Mon Mar 22 07:55:39 2021
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Mon, 22 Mar 2021 07:55:39 GMT
Subject: RFR: 8263763: Synthetic constructor parameters of enum are not
 considered for annotation indices
In-Reply-To: <oO4DMxm6_qVXVfjPnU_h9ZbPIgfZ9D5reRfmrkb02iA=.12b844e3-2a67-4156-8ed2-3299a096ba18@github.com>
References: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>
 <fVXkjoj54yxGaLUucXUWruPLGhfzavFUBCgocbQ7obM=.66b25271-c306-46d8-a5ed-d7b4d2ccf608@github.com>
 <oO4DMxm6_qVXVfjPnU_h9ZbPIgfZ9D5reRfmrkb02iA=.12b844e3-2a67-4156-8ed2-3299a096ba18@github.com>
Message-ID: <AQ1P_Sd0dJiUpaUZPYM-ZMCw8Nc8427IxLMmdycYnRk=.00d9e163-4c38-4509-aed1-8c24bc1c27e6@github.com>

On Fri, 19 Mar 2021 14:34:00 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> A general comment, the enum constructor situation is a bit tricky as
>> 
>> 1) There is no 100% reliable way to determine which of a enum constructor's args are synthetic.
>> 
>> 2) How a Java compiler generates enum constructors is a compiler-internal contract since all the enum constructors must be private.
>> 
>> It is true that javac has consistently added two extra parameters as an implementation detail. Offhand, I don't know if ecj in particular has made the same choice. javac is not obliged to continue implementing enum constructors in this manner, so for better robustness, I think a fix in this space needs to be able to accommodate situations other than exactly N+2 parameters.
>
> *ejc* issues the same constructor that prefixes a `String` and an `int` parameter. I agree that the solution is not perfect, but I would prefer it over the reflection API throwing an `IndexOutOfBoundsException` upon calling `getAnnotations()`, which nobody really expects upon a getter invocation.
> 
> I added a check to see if the enum constructor in question starts with a `String` and `int` parameter after checking if there are two excess parameters. I believe that that's at least an improvement over today's state where it's very unlikely that an enum constructor  yields an incorrect result in the reflection API whereas the result it is always incorrect today, given the implementation of both *ejc* and *javac*.
> 
> Ideally, this would of course also be fixed by javac (and ejc) such that the annotations are placed on the correct indices, but I still argue that the fix is an improvement for being able to properly process enum constructors for older class files also.

@raphw a duplicate? https://bugs.openjdk.java.net/browse/JDK-8246586

-------------

PR: https://git.openjdk.java.net/jdk/pull/3082

From Alan.Bateman at oracle.com  Mon Mar 22 09:06:58 2021
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Mar 2021 09:06:58 +0000
Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null
 device)?
In-Reply-To: <d21a76a8-5004-4925-1224-fc8e31664101@gmail.com>
References: <dd06d633-1f12-7613-86ba-c7a25bf31203@gmail.com>
 <e9a89da8-b625-8797-8a21-d5ab65e49283@oracle.com>
 <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com>
 <154fbc5c-77a9-9abf-5971-4785c9dd5415@oracle.com>
 <2f8cec59-e49b-b304-3686-a695439a9db8@gmail.com>
 <1d19e40b-1cad-00f3-0f8a-a11e4bf32a31@gmail.com>
 <d21a76a8-5004-4925-1224-fc8e31664101@gmail.com>
Message-ID: <1a500843-8b90-91e5-3257-b64f4fd0ef49@oracle.com>

On 20/03/2021 07:16, Jaikiran Pai wrote:
> :
>
> I received some inputs on that Ant bugzilla issue. Based on that, I 
> was able to reproduce the exception and IMO it's a bug in 
> Files.newOutputStream() API. I have opened 
> https://bugs.openjdk.java.net/browse/JDK-8263898 with the relevant 
> details. I considered this a bug and took the liberty of opening that 
> JBS issue because as I note in that issue, this only happens 
> specifically when TRUNCATE_EXISTING (default) option gets used against 
> "nul" on Windows.

OutputStream.nullOutputStream() may be a better and more portable 
alternative. In general, the DOS era reserved names (including NUL) are 
very under specified and many file operations lead to surprising 
behavior (this isn't solely a JDK issue, I think other runtimes and 
languages also get tripped up). In this case, the attempt to truncate 
the file to zero length is failing. Sure, it can be be worked around but 
workarounds like this tend to cause issues in other unusual cases so 
care is required.

-Alan.

From pconcannon at openjdk.java.net  Mon Mar 22 09:15:06 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 22 Mar 2021 09:15:06 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v6]
In-Reply-To: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
Message-ID: <vwQGsx8o7YlaAAzM-iT6TM0mR_ELxGikbPIN8O9RRIY=.767c7add-3414-477b-900e-f779c34cc6ac@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge remote-tracking branch 'origin/master' into JDK-8263358
 - 8263358: Refactored missed equals method
 - Merge remote-tracking branch 'origin/master' into JDK-8263358
 - 8263358: Refactored equals methods
 - Merge remote-tracking branch 'origin/master' into JDK-8263358
 - 8263358: Update java.lang to use instanceof pattern variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2913/files
  - new: https://git.openjdk.java.net/jdk/pull/2913/files/f7924d27..e6746c9f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=04-05

  Stats: 16598 lines in 622 files changed: 7556 ins; 5892 del; 3150 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2913.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2913/head:pull/2913

PR: https://git.openjdk.java.net/jdk/pull/2913

From jai.forums2013 at gmail.com  Mon Mar 22 09:50:50 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 22 Mar 2021 15:20:50 +0530
Subject: java.io.File#toPath() on Windows doesn't understand "NUL:" (null
 device)?
In-Reply-To: <1a500843-8b90-91e5-3257-b64f4fd0ef49@oracle.com>
References: <dd06d633-1f12-7613-86ba-c7a25bf31203@gmail.com>
 <e9a89da8-b625-8797-8a21-d5ab65e49283@oracle.com>
 <9678ac3c-047f-533f-f4a9-e6056223d2d8@gmail.com>
 <154fbc5c-77a9-9abf-5971-4785c9dd5415@oracle.com>
 <2f8cec59-e49b-b304-3686-a695439a9db8@gmail.com>
 <1d19e40b-1cad-00f3-0f8a-a11e4bf32a31@gmail.com>
 <d21a76a8-5004-4925-1224-fc8e31664101@gmail.com>
 <1a500843-8b90-91e5-3257-b64f4fd0ef49@oracle.com>
Message-ID: <5614738c-34d5-73bb-ce84-31678528be40@gmail.com>


On 22/03/21 2:36 pm, Alan Bateman wrote:
> On 20/03/2021 07:16, Jaikiran Pai wrote:
>> :
>>
>> I received some inputs on that Ant bugzilla issue. Based on that, I 
>> was able to reproduce the exception and IMO it's a bug in 
>> Files.newOutputStream() API. I have opened 
>> https://bugs.openjdk.java.net/browse/JDK-8263898 with the relevant 
>> details. I considered this a bug and took the liberty of opening that 
>> JBS issue because as I note in that issue, this only happens 
>> specifically when TRUNCATE_EXISTING (default) option gets used 
>> against "nul" on Windows.
>
> OutputStream.nullOutputStream() may be a better and more portable 
> alternative. In general, the DOS era reserved names (including NUL) 
> are very under specified and many file operations lead to surprising 
> behavior (this isn't solely a JDK issue, I think other runtimes and 
> languages also get tripped up). In this case, the attempt to truncate 
> the file to zero length is failing. Sure, it can be be worked around 
> but workarounds like this tend to cause issues in other unusual cases 
> so care is required.


Understood. Thank you Alan for those inputs. Just yesterday, Stefan (one 
of the Ant developers) has implemented a way where we allow users to 
discard output without relying on null devices. It uses the approach 
that you note (although we use an internal NullOutputStream, since we 
want Ant to be usable in Java 8 where OutputStream.nullOutputStream() 
isn't present). We will be asking our users to move to this new 
way/attribute instead of relying on null devices.

-Jaikiran


From github.com+34924738+mahendrachhipa at openjdk.java.net  Mon Mar 22 10:40:52 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Mon, 22 Mar 2021 10:40:52 GMT
Subject: RFR: JDK-8064681 : Jaxp unit test need to be improved
Message-ID: <V9kOzORMX8sH7Goli5bUISPnubjBkl1Ej_ZAc5WJLeU=.3ed5bbf0-f840-4f63-8105-5f09e0bfbed8@github.com>

https://bugs.openjdk.java.net/browse/JDK-8064681

-------------

Commit messages:
 - JDK-8064681 : Jaxp unit test need to be improved

Changes: https://git.openjdk.java.net/jdk/pull/3115/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3115&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8064681
  Stats: 541 lines in 6 files changed: 125 ins; 268 del; 148 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3115.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3115/head:pull/3115

PR: https://git.openjdk.java.net/jdk/pull/3115

From pconcannon at openjdk.java.net  Mon Mar 22 11:07:07 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 22 Mar 2021 11:07:07 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v7]
In-Reply-To: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
Message-ID: <HahWl9jBH3myNwUZXQV97a43OBvpkwLvk90a2DaBVB4=.681084d5-54c7-409c-9f1b-c0fdb55941fd@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request incrementally with one additional commit since the last revision:

  8263358: Added wildcard to instanceof check; reordered primitive equality check

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2913/files
  - new: https://git.openjdk.java.net/jdk/pull/2913/files/e6746c9f..b89027c4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=05-06

  Stats: 3 lines in 2 files changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2913.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2913/head:pull/2913

PR: https://git.openjdk.java.net/jdk/pull/2913

From alanb at openjdk.java.net  Mon Mar 22 11:45:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 22 Mar 2021 11:45:40 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread [v2]
In-Reply-To: <8GZqLhOohWvt6kS6lh27ZviQprQGEW-Ca0JjG7TK9AM=.55d865e7-8210-4255-8ca2-89c23cce522b@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
 <8GZqLhOohWvt6kS6lh27ZviQprQGEW-Ca0JjG7TK9AM=.55d865e7-8210-4255-8ca2-89c23cce522b@github.com>
Message-ID: <98yJAJl8-VfQeJSsm--9OZRcoRCoAPLiJj9-xfJdedg=.8ee22f69-de88-4f87-8aee-879a8f2cf833@github.com>

On Mon, 22 Mar 2021 07:19:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>> 
>> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
>> 
>> Testing:
>> mach5 tier1
>> New AutoStop test verifies the specified cleanup behavior.
>> (There are existing tests involving Timer.cancel.)
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dholmes review

The update to java.util.Timer looks okay. A minor comment is that the ThreadReaper constructor does not need to be public.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3106

From aefimov at openjdk.java.net  Mon Mar 22 12:16:40 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 22 Mar 2021 12:16:40 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming [v2]
In-Reply-To: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
Message-ID: <o_BVfcyKADFKHvcuIpccL3UlxojhCklcVrG2MCHC0SY=.9be0d226-6ede-4360-a1b7-633bb6ebf97b@github.com>

On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.
>
> Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added more replacements of 'final public' with 'public final'

`java.naming` module changes look good to me.

-------------

Marked as reviewed by aefimov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/3078

From akozlov at openjdk.java.net  Mon Mar 22 12:50:14 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Mon, 22 Mar 2021 12:50:14 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:

 - Merge branch 'master' into jdk-macos
 - JDK-8262491: bsd_aarch64 part
 - JDK-8263002: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Wider #ifdef block
 - Fix most of issues in java/foreign/ tests
   
   Failures related to va_args are tracked in JDK-8263512.
 - Add Azul copyright
 - Update Oracle copyright years
 - Use Thread::current_or_null_safe in SafeFetch
 - 8262903: [macos_aarch64] Thread::current() called on detached thread
 - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=28
  Stats: 2947 lines in 75 files changed: 2838 ins; 27 del; 82 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From dfuchs at openjdk.java.net  Mon Mar 22 13:09:40 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 22 Mar 2021 13:09:40 GMT
Subject: RFR: 8263855: Use the blessed modifier order in
 java.management/naming [v2]
In-Reply-To: <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
 <6ITH9DKMFtUme7hcRYi9iw8SZgF6d9jE_OJfjtfGsPI=.5c05ae45-f88c-4abf-9786-8520f66f2ab5@github.com>
Message-ID: <QTMtp48vG2xbXUGjxEioHO3SemUybTwf4fWP3UgajA0=.92085ad2-a27b-47c8-a4a4-3c92fa65c8c2@github.com>

On Fri, 19 Mar 2021 17:13:58 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.
>
> Alex Blewitt has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added more replacements of 'final public' with 'public final'

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3078

From herrick at openjdk.java.net  Mon Mar 22 13:09:56 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 22 Mar 2021 13:09:56 GMT
Subject: RFR: JDK-8263887: Re-create default icons
Message-ID: <8v_kn43vqUCfHMiqY5uu3DF2tN8CV14bD5JL3YNqmFE=.3deac616-e000-488d-828d-50802dfcc99a@github.com>

JDK-8263887: Re-create default icons

-------------

Commit messages:
 - JDK-8263887: Re-create default icons

Changes: https://git.openjdk.java.net/jdk/pull/3118/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3118&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263887
  Stats: 32 lines in 2 files changed: 7 ins; 21 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3118.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3118/head:pull/3118

PR: https://git.openjdk.java.net/jdk/pull/3118

From github.com+76791+alblue at openjdk.java.net  Mon Mar 22 13:41:39 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Mon, 22 Mar 2021 13:41:39 GMT
Subject: Integrated: 8263855: Use the blessed modifier order in
 java.management/naming
In-Reply-To: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
References: <JLuVOtf8yGtuIzmGxboMPvjWTTE-HEX5GtajHSOs0xk=.3a37598d-765f-48c6-97ce-95e26b4c3d56@github.com>
Message-ID: <lOh9blbaBQM3sn-pNHzWhwpooqD8vj4DJ5uDL12gShg=.477d7f94-12a4-4ac2-a3aa-9dfab4499fee@github.com>

On Thu, 18 Mar 2021 18:26:20 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> As with #2993 changing the order of `final static` to `static final` for the `java.management`, `java.management.rmi` and `java.naming` modules.

This pull request has now been integrated.

Changeset: 5262d95b
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5262d95b
Stats:     261 lines in 69 files changed: 0 ins; 0 del; 261 mod

8263855: Use the blessed modifier order in java.management/naming

Reviewed-by: redestad, aefimov, dfuchs

-------------

PR: https://git.openjdk.java.net/jdk/pull/3078

From jlaskey at openjdk.java.net  Mon Mar 22 14:29:05 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 22 Mar 2021 14:29:05 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v33]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <FEOeteUZnaHi0li7RN0FN5Zl1q-sxlqtP3ZzzSd_XKY=.ffbfdcd2-54e4-4b60-bb94-b0910afae866@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Cleaned up ints(), longs(), doubles()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/63094f9d..5e98d915

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=32
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=31-32

  Stats: 782 lines in 4 files changed: 310 ins; 416 del; 56 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

PR: https://git.openjdk.java.net/jdk/pull/1292

From jlaskey at openjdk.java.net  Mon Mar 22 14:42:49 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 22 Mar 2021 14:42:49 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v32]
In-Reply-To: <_uMAp-rI5lz4tzevS6jXiPsD_X6SSqequ5Gd5tc0lg8=.7cceb178-3fdc-46ee-86c4-99b2944d9e04@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <VVXJ__O-21yfNiFV8dNhGSkb3i-h4XLjc5-XQd73gWA=.be82decd-6ddd-48fb-9c9b-b68ac3e96248@github.com>
 <_uMAp-rI5lz4tzevS6jXiPsD_X6SSqequ5Gd5tc0lg8=.7cceb178-3fdc-46ee-86c4-99b2944d9e04@github.com>
Message-ID: <pOZHaqz8fj7beKhpU3d14h4AImPEzlRHSbeaAlyJjeA=.88672edc-2281-45bc-8c16-f8a4f27a30f2@github.com>

On Thu, 18 Mar 2021 21:43:16 GMT, Joe Darcy <darcy 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 67 commits:
>> 
>>  - Merge branch 'master' into 8248862
>>  - Review revisions
>>  - Missing @since
>>  - Review revisions
>>  - Review requested changes
>>  - Merge branch 'master' into 8248862
>>  - Remove conflicts
>>  - Use isAnnotationPresent
>>  - Introduce isDeprecated
>>  - Update javadoc
>>  - ... and 57 more: https://git.openjdk.java.net/jdk/compare/8c8d1b31...63094f9d
>
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1290:
> 
>> 1288:          * @return a new object that is a copy of this generator
>> 1289:          */
>> 1290:         LeapableGenerator copy();
> 
> Suggest adding an Override annotation here and possibly to inheritDoc the text from Jumpable.copy.

Fails due to result variance.

> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1455:
> 
>> 1453:          *                                  period of this generator
>> 1454:          */
>> 1455:         void jump(double distance);
> 
> Suggest Override and inheritDoc combo.

jump(double distance) does not occur in superinterface. The ability to jump arbitrarily is specific to ArbitrarilyJumpableGenerator.

> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1465:
> 
>> 1463:          * @implSpec The default implementation invokes jump(jumpDistance()).
>> 1464:          */
>> 1465:         default void jump() { jump(jumpDistance()); }
> 
> Should be able to avoid defining the jump method in this subinterface.

jump(double distance) does not occur in superinterface. The ability to jump arbitrarily is specific to ArbitrarilyJumpableGenerator.

> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1486:
> 
>> 1484:          * ({@link Long#MAX_VALUE Long.MAX_VALUE}).
>> 1485:          */
>> 1486:         default Stream<ArbitrarilyJumpableGenerator> jumps(double distance) {
> 
> Suggest adding an Override annotation.

jump(double distance) does not occur in superinterface. The ability to jump arbitrarily is specific to ArbitrarilyJumpableGenerator.

> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1521:
> 
>> 1519:          * {@link ArbitrarilyJumpableGenerator#leapDistance() leapDistance}().
>> 1520:          */
>> 1521:         default void leap() { jump(leapDistance()); }
> 
> Should need to define this method in the subinterface of Leapable.

jump(double distance) does not occur in superinterface. The ability to jump arbitrarily is specific to ArbitrarilyJumpableGenerator.

> src/java.base/share/classes/java/util/random/RandomGenerator.java line 1538:
> 
>> 1536:          * returns the copy.
>> 1537:          */
>> 1538:         default ArbitrarilyJumpableGenerator copyAndJump(double distance) {
> 
> Suggest Override and inheritDoc.

jump(double distance) does not occur in superinterface. The ability to jump arbitrarily is specific to ArbitrarilyJumpableGenerator.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From rriggs at openjdk.java.net  Mon Mar 22 14:53:41 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 22 Mar 2021 14:53:41 GMT
Subject: RFR: 8263729: [test] divert spurious output away from stream
 under test in ProcessBuilder Basic test [v4]
In-Reply-To: <RXxDpfJwBl2w64TVA4QwIv9fE5kWl3YGCzpUEhajoGs=.1700f9a3-c345-4790-97f6-d9443ebb171e@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
 <VS4eIruAE4HiLhc4LProaPiEczJf62yZRQz0gs5W_50=.f2faa8bb-5520-484d-a581-8b17d3cbaf25@github.com>
 <RXxDpfJwBl2w64TVA4QwIv9fE5kWl3YGCzpUEhajoGs=.1700f9a3-c345-4790-97f6-d9443ebb171e@github.com>
Message-ID: <rLXPlkPg729SrYFpXriPeubpXlw9RbPvWkWnfQfbF3c=.b9ab66da-35f7-4d41-afaf-1b347ce0f05a@github.com>

On Sat, 20 Mar 2021 05:55:08 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarify modification of argument list after creating ProcessBuilder
>
> Looks good to me, if the intent was to fix potential write blockages in the child process (in which case maybe reformulate the issue title). 
> 
> I'm sorry I derailed your original wait idea, as well as Ioi's ideas of syncing with the child. Both may still be needed after this fix.
> 
> Cheers, Thomas

Thanks for the reviews and the suggestion to redirect the output to the inherited streams.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3049

From rriggs at openjdk.java.net  Mon Mar 22 14:53:43 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 22 Mar 2021 14:53:43 GMT
Subject: Integrated: 8263729: [test] divert spurious output away from stream
 under test in ProcessBuilder Basic test
In-Reply-To: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
References: <nomTBnyzR9CqzI3VA2j13TGn-ZwE5gRK4t9cuK8QVjk=.77d17ff5-3553-4a72-a3a9-6d5b24a72591@github.com>
Message-ID: <B7CrFvKmv8r8tuNFDZpvn_IJzCjwMg1qR24n5pn6fVc=.f4b1929e-9ade-4351-b407-3c02834f4bdb@github.com>

On Wed, 17 Mar 2021 14:16:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Intermittent failures on Windows in a test of destroying the child warrant extending the time the parent waits after starting the child before destroying the child.

This pull request has now been integrated.

Changeset: 0abbfb2f
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0abbfb2f
Stats:     28 lines in 1 file changed: 24 ins; 0 del; 4 mod

8263729: [test] divert spurious output away from stream under test in ProcessBuilder Basic test

Reviewed-by: stuefe, iklam

-------------

PR: https://git.openjdk.java.net/jdk/pull/3049

From henryjen at openjdk.java.net  Mon Mar 22 16:03:42 2021
From: henryjen at openjdk.java.net (Henry Jen)
Date: Mon, 22 Mar 2021 16:03:42 GMT
Subject: Integrated: 8261785: Calling "main" method in anonymous nested class
 crashes the JVM
In-Reply-To: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
References: <5KwtgLZmtIywrw_aOGJ7QQiHmXKGvHPmalhpHfcIpOg=.3108f900-d120-42a6-bb35-702247795b44@github.com>
Message-ID: <JDvRpx5U3KluI1mIrABk4kIH1NOiMWPU_c17EgqqJBI=.53980e1e-810c-4004-bba2-c71d204bd4b2@github.com>

On Sun, 14 Mar 2021 23:34:55 GMT, Henry Jen <henryjen at openjdk.org> wrote:

> This patch ensure launcher won't crash JVM for the new static Methods from local/anonymous class on MacOS.
> 
> As @dholmes-ora pointed out in the analysis, this is a MacOS specific bug when the launcher trying to grab class name to be displayed as the Application name on the menu.
> 
> The fix is to not setting name, test shows that GUI java application shows 'bin' as the application name. It's possible for us to set the name to something more friendly, for example, "Java", but I am not sure that should be launcher's responsibility to choose such a default name. It seems to me the consumer of the JAVA_MAIN_CLASS_%d environment variable should be responsible to pick such name in case the environment variable is not set.

This pull request has now been integrated.

Changeset: b2df5137
Author:    Henry Jen <henryjen at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b2df5137
Stats:     143 lines in 3 files changed: 142 ins; 0 del; 1 mod

8261785: Calling "main" method in anonymous nested class crashes the JVM

Reviewed-by: serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/2999

From jbachorik at openjdk.java.net  Mon Mar 22 16:05:15 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Mon, 22 Mar 2021 16:05:15 GMT
Subject: RFR: 8203359: Container level resources events
Message-ID: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>

With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.

Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
* CPU related metrics
* Memory related metrics
* I/O related metrics

For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).

-------------

Commit messages:
 - Formatting spaces
 - 8203359: Container level resources events

Changes: https://git.openjdk.java.net/jdk/pull/3126/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8203359
  Stats: 389 lines in 8 files changed: 386 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3126/head:pull/3126

PR: https://git.openjdk.java.net/jdk/pull/3126

From herrick at openjdk.java.net  Mon Mar 22 16:12:45 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 22 Mar 2021 16:12:45 GMT
Subject: Withdrawn: JDK-8263154: [macos] DMG builds have finder errors
In-Reply-To: <q_q2hdnvfEfyo76kIREN-tRxST60tLWyUYvOh3Xipws=.9e37f1ba-fa6f-4914-94bf-fa94c5de2b47@github.com>
References: <q_q2hdnvfEfyo76kIREN-tRxST60tLWyUYvOh3Xipws=.9e37f1ba-fa6f-4914-94bf-fa94c5de2b47@github.com>
Message-ID: <7DDNGR3ILUCgCbS1Nj22SoV22nHxXvKJn81rsua-Lt0=.a1c74f9b-29e6-4066-8749-da4ae199431c@github.com>

On Sat, 13 Mar 2021 14:39:40 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8263154: [macos] DMG builds have finder errors

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2987

From pconcannon at openjdk.java.net  Mon Mar 22 17:33:44 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 22 Mar 2021 17:33:44 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <kiOUpebha_W79n4KwsMJaNPyNwtP2Oirq1eEyU6UGtI=.c1a64a0a-3491-4a96-b644-42d62a157912@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
 <-0824MCtSuH7aJ_Ea4gf3Ggs5CGPSjcG6E5HS4WWuZE=.220abbbb-31d5-4ac1-9300-8621455fd285@github.com>
 <GmxIoXvFUQ7qcW_i3ZonMvHAA8eWnhoVelR_35mGXLg=.cd01c8a3-d7e9-4913-9696-48cecd0b28ae@github.com>
 <y0Y_kY5l8LzhG1SkFDu-9T2Po1KB-DUIbk2QvhVOUJA=.0de08a0a-7ed6-4ec1-ae0c-85ad0493b787@github.com>
 <kiOUpebha_W79n4KwsMJaNPyNwtP2Oirq1eEyU6UGtI=.c1a64a0a-3491-4a96-b644-42d62a157912@github.com>
Message-ID: <Bt0E3DyG3vEo4f_KwYL1hga523sg1WkEjhunQKSrtdU=.f1f190be-8d85-4a55-9164-427b7466fead@github.com>

On Tue, 16 Mar 2021 19:26:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> `declaringClass` is a string representing the class name (not the `Class` object).   The variable name indeed causes confusion.
>
> Doh. My mistake. Was thinking about `StackFrame`. Thanks Mandy!

I've reordered the checks as suggested and the updated code can be found in commit b89027c

-------------

PR: https://git.openjdk.java.net/jdk/pull/2913

From pconcannon at openjdk.java.net  Mon Mar 22 17:33:44 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 22 Mar 2021 17:33:44 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v5]
In-Reply-To: <vSVVMKXLSecZvJj9_yKie9XTL49Is0hFpVtfWosCT8s=.8703bc88-d187-4378-b517-ecb5a71bba6f@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <QS_pMVXT_jH59iUt4xwgNgfJsDkYQXZFPl_bdyotD7c=.f5d05e93-25ba-4827-8409-daf25ac26dcf@github.com>
 <tqJTgA567Bmq7ki1OSyRR-T0aZLf6xEB4AaQa2OFp0o=.c05e8419-cf23-4010-8cfa-78b29f1bffed@github.com>
 <7M1a_-toj0cuTbLnwxcqEGZopF92y-8piQkrl-_EXa8=.bab041cf-4e26-42bc-bf7d-bd67ce3f8000@github.com>
 <EB3BACJqC1S88itLaCIfLKtjtmp3FPDYxaD3wzUalok=.54b6f6d1-f0c9-4b42-8277-90c2571f5865@github.com>
 <V4M_1KPi4i2nUUYL1SLLvnluQwlBe0QI3fg73OSm_iU=.33bd47b5-0689-47e7-9e8e-b148d4a4892f@github.com>
 <xC2ZpmH0eWLyVQTQ43nif3mjfITV1-gaaiXGx6Csbn4=.ff1d3a53-2760-45f4-9412-f9f7d959b263@github.com>
 <vv2SyuK5RxMBEl5ACrKE4AvEa09erdnpzAlAvJJ0RB4=.85ad4384-3e09-4154-8bdd-a34151515e4d@github.com>
 <HtduJdTzDVuHdDa70KDPZicD-opgSDK7EHWZPCraZSI=.0e2bd9a9-4109-4627-8c3c-7a7b0f29f143@github.com>
 <vSVVMKXLSecZvJj9_yKie9XTL49Is0hFpVtfWosCT8s=.8703bc88-d187-4378-b517-ecb5a71bba6f@github.com>
Message-ID: <UwTdIycP_HF5nTaGMM0ddnsH1_5NiOML397Qmnd3OQw=.e75bdada-674c-435f-9b04-009fb1a5ecc9@github.com>

On Mon, 15 Mar 2021 13:49:56 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> yes,
>> javac should emit a warning in that case, that also the answer of Brian.
>> 
>> https://mail.openjdk.java.net/pipermail/amber-spec-experts/2021-March/002925.html
>
> Then we should use an unbounded wildcard here and in similar places to avoid "rawtype" warnings in the future.

I've added the wildcard to the pattern variable check now. See b89027c

-------------

PR: https://git.openjdk.java.net/jdk/pull/2913

From pconcannon at openjdk.java.net  Mon Mar 22 17:47:10 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Mon, 22 Mar 2021 17:47:10 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v8]
In-Reply-To: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
Message-ID: <iqi5Ygw4O-ZMYgvpIEfXHt2MQTzGqB-f1ezx_FlNF14=.e39ace3a-fc0e-45c5-a034-aad7ce40adb5@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request with a new target base 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:

 - 8263358: Moved check for declaringClass to after lineNumber
 - Merge remote-tracking branch 'origin/master' into JDK-8263358
 - 8263358: Added wildcard to instanceof check; reordered primitive equality check
 - Merge remote-tracking branch 'origin/master' into JDK-8263358
 - 8263358: Refactored missed equals method
 - Merge remote-tracking branch 'origin/master' into JDK-8263358
 - 8263358: Refactored equals methods
 - Merge remote-tracking branch 'origin/master' into JDK-8263358
 - 8263358: Update java.lang to use instanceof pattern variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2913/files
  - new: https://git.openjdk.java.net/jdk/pull/2913/files/b89027c4..a45233e8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2913&range=06-07

  Stats: 545 lines in 83 files changed: 236 ins; 22 del; 287 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2913.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2913/head:pull/2913

PR: https://git.openjdk.java.net/jdk/pull/2913

From dfuchs at openjdk.java.net  Mon Mar 22 17:52:43 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Mon, 22 Mar 2021 17:52:43 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v8]
In-Reply-To: <iqi5Ygw4O-ZMYgvpIEfXHt2MQTzGqB-f1ezx_FlNF14=.e39ace3a-fc0e-45c5-a034-aad7ce40adb5@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <iqi5Ygw4O-ZMYgvpIEfXHt2MQTzGqB-f1ezx_FlNF14=.e39ace3a-fc0e-45c5-a034-aad7ce40adb5@github.com>
Message-ID: <Q0yCk2r9g2th7P3Vs38De_AKPm9h39TM3R-N3725oz0=.b624d5f0-6c25-4f6f-8912-3196aa446ff4@github.com>

On Mon, 22 Mar 2021 17:47:10 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request with a new target base 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:
> 
>  - 8263358: Moved check for declaringClass to after lineNumber
>  - Merge remote-tracking branch 'origin/master' into JDK-8263358
>  - 8263358: Added wildcard to instanceof check; reordered primitive equality check
>  - Merge remote-tracking branch 'origin/master' into JDK-8263358
>  - 8263358: Refactored missed equals method
>  - Merge remote-tracking branch 'origin/master' into JDK-8263358
>  - 8263358: Refactored equals methods
>  - Merge remote-tracking branch 'origin/master' into JDK-8263358
>  - 8263358: Update java.lang to use instanceof pattern variable

The new changes look good to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2913

From mchung at openjdk.java.net  Mon Mar 22 18:05:45 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 22 Mar 2021 18:05:45 GMT
Subject: RFR: 8263358: Update java.lang to use instanceof pattern variable
 [v8]
In-Reply-To: <iqi5Ygw4O-ZMYgvpIEfXHt2MQTzGqB-f1ezx_FlNF14=.e39ace3a-fc0e-45c5-a034-aad7ce40adb5@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
 <iqi5Ygw4O-ZMYgvpIEfXHt2MQTzGqB-f1ezx_FlNF14=.e39ace3a-fc0e-45c5-a034-aad7ce40adb5@github.com>
Message-ID: <2skq8WYij_yv9VzXC0cKX4tLaNJbm_nSq71yIWbYBu4=.d2781736-ed41-418e-bc84-4737315b2f52@github.com>

On Mon, 22 Mar 2021 17:47:10 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

>> Hi,
>> 
>> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
>> 
>> Kind regards,
>> Patrick
>
> Patrick Concannon has updated the pull request with a new target base 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:
> 
>  - 8263358: Moved check for declaringClass to after lineNumber
>  - Merge remote-tracking branch 'origin/master' into JDK-8263358
>  - 8263358: Added wildcard to instanceof check; reordered primitive equality check
>  - Merge remote-tracking branch 'origin/master' into JDK-8263358
>  - 8263358: Refactored missed equals method
>  - Merge remote-tracking branch 'origin/master' into JDK-8263358
>  - 8263358: Refactored equals methods
>  - Merge remote-tracking branch 'origin/master' into JDK-8263358
>  - 8263358: Update java.lang to use instanceof pattern variable

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2913

From jlaskey at openjdk.java.net  Mon Mar 22 18:14:09 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 22 Mar 2021 18:14:09 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v34]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <HO8K7YLSCbf-uUewgAHaIgS4A8unUyq_HyDX2g-dJlQ=.186fca69-64d8-47bf-aacf-855d7aec9fec@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - RandomGeneratorFactory::all(Class<T> category) @implNote was out of date
 - Clarify all()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/5e98d915..4562dd13

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=33
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=32-33

  Stats: 16 lines in 2 files changed: 3 ins; 0 del; 13 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

PR: https://git.openjdk.java.net/jdk/pull/1292

From chris.w.dennis at gmail.com  Mon Mar 22 16:11:59 2021
From: chris.w.dennis at gmail.com (Chris Dennis)
Date: Mon, 22 Mar 2021 16:11:59 +0000
Subject: 8214761: Bug in parallel Kahan summation implementation
Message-ID: <BLAPR20MB4177F862D3DEBFE859D533B7AE659@BLAPR20MB4177.namprd20.prod.outlook.com>

I created a PR for 8214761: https://github.com/openjdk/jdk/pull/2988 - but have been stuck waiting on OCA signatory status to be confirmed. Did something get lost in the shuffle or do I just need to be more patient.

Thanks,

Chris

From avoitylov at openjdk.java.net  Mon Mar 22 19:55:51 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Mon, 22 Mar 2021 19:55:51 GMT
Subject: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be
 singleton
Message-ID: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>

With CDS and G1, test api/java_lang/ModuleLayer/Boot.html fails in JDK 16. 

After JDK-8253081 with CDS enabled two instances of empty layer appear in the runtime. One comes from default initialization of java/lang/ModuleLayer.EMPTY_LAYER, another one comes from CDS archive and is returned by ModuleLayer.boot().parents().get(0). The fix makes java/lang/ModuleLayer.EMPTY_LAYER a singleton with both CDS on and off, similar to java/lang/module/Configuration.EMPTY_CONFIGURATION.

Testing: JCK 16, jtreg (including newly added test), pre-submit GitHub actions tests.

-------------

Commit messages:
 - fix jcheck requirements
 - JDK-8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be singleton

Changes: https://git.openjdk.java.net/jdk/pull/3131/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3131&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263968
  Stats: 24 lines in 3 files changed: 21 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3131.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3131/head:pull/3131

PR: https://git.openjdk.java.net/jdk/pull/3131

From iklam at openjdk.java.net  Mon Mar 22 20:32:39 2021
From: iklam at openjdk.java.net (Ioi Lam)
Date: Mon, 22 Mar 2021 20:32:39 GMT
Subject: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be
 singleton
In-Reply-To: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
References: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
Message-ID: <MKnitJiYOZa8NDMhJ-cg9RbVwCmadBNGbYHPRO8KSyM=.10eeba36-7c2c-475b-9f91-e96d89c51ca9@github.com>

On Mon, 22 Mar 2021 19:40:19 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> With CDS and G1, test api/java_lang/ModuleLayer/Boot.html fails in JDK 16. 
> 
> After JDK-8253081 with CDS enabled two instances of empty layer appear in the runtime. One comes from default initialization of java/lang/ModuleLayer.EMPTY_LAYER, another one comes from CDS archive and is returned by ModuleLayer.boot().parents().get(0). The fix makes java/lang/ModuleLayer.EMPTY_LAYER a singleton with both CDS on and off, similar to java/lang/module/Configuration.EMPTY_CONFIGURATION.
> 
> Testing: JCK 16, jtreg (including newly added test), pre-submit GitHub actions tests.

LGTM. Thanks for fixing this!

-------------

Marked as reviewed by iklam (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3131

From herrick at openjdk.java.net  Mon Mar 22 20:46:53 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 22 Mar 2021 20:46:53 GMT
Subject: RFR: JDK-8259926: Error in jpackage sample usage in the help text
Message-ID: <svG94wkAg8fU0l80Xkbqyt3YK8QNge9Evov56PiViQ8=.48a24253-0b29-4832-a6f0-df3211bc32bb@github.com>

JDK-8259926: Error in jpackage sample usage in the help text

-------------

Commit messages:
 - JDK-8259926: Error in jpackage sample usage in the help text

Changes: https://git.openjdk.java.net/jdk/pull/3132/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3132&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8259926
  Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3132.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3132/head:pull/3132

PR: https://git.openjdk.java.net/jdk/pull/3132

From almatvee at openjdk.java.net  Mon Mar 22 20:51:39 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Mon, 22 Mar 2021 20:51:39 GMT
Subject: RFR: JDK-8263887: Re-create default icons
In-Reply-To: <8v_kn43vqUCfHMiqY5uu3DF2tN8CV14bD5JL3YNqmFE=.3deac616-e000-488d-828d-50802dfcc99a@github.com>
References: <8v_kn43vqUCfHMiqY5uu3DF2tN8CV14bD5JL3YNqmFE=.3deac616-e000-488d-828d-50802dfcc99a@github.com>
Message-ID: <LU2C4yUEZzeAdT7ElMLfjgobwksesG4say0xKIbuVGk=.889fe780-c203-44f8-8247-6da51626d62f@github.com>

On Mon, 22 Mar 2021 13:03:10 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8263887: Re-create default icons

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3118

From winterhalter at openjdk.java.net  Mon Mar 22 21:35:38 2021
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Mon, 22 Mar 2021 21:35:38 GMT
Subject: RFR: 8263763: Synthetic constructor parameters of enum are not
 considered for annotation indices
In-Reply-To: <AQ1P_Sd0dJiUpaUZPYM-ZMCw8Nc8427IxLMmdycYnRk=.00d9e163-4c38-4509-aed1-8c24bc1c27e6@github.com>
References: <tbA8Aa1SyqPSBODwSBvRgaR1SX_bumZmTC58nDGjfRk=.a50ac5fd-1152-40dc-890a-0675f6864ee0@github.com>
 <fVXkjoj54yxGaLUucXUWruPLGhfzavFUBCgocbQ7obM=.66b25271-c306-46d8-a5ed-d7b4d2ccf608@github.com>
 <oO4DMxm6_qVXVfjPnU_h9ZbPIgfZ9D5reRfmrkb02iA=.12b844e3-2a67-4156-8ed2-3299a096ba18@github.com>
 <AQ1P_Sd0dJiUpaUZPYM-ZMCw8Nc8427IxLMmdycYnRk=.00d9e163-4c38-4509-aed1-8c24bc1c27e6@github.com>
Message-ID: <-NBIVKPDeblNyT3JlqrGir26sSeXrrUoLMIbWWBjxyo=.71f7c5bd-fa43-4d2e-9f7a-c471852210aa@github.com>

On Mon, 22 Mar 2021 07:52:45 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> *ejc* issues the same constructor that prefixes a `String` and an `int` parameter. I agree that the solution is not perfect, but I would prefer it over the reflection API throwing an `IndexOutOfBoundsException` upon calling `getAnnotations()`, which nobody really expects upon a getter invocation.
>> 
>> I added a check to see if the enum constructor in question starts with a `String` and `int` parameter after checking if there are two excess parameters. I believe that that's at least an improvement over today's state where it's very unlikely that an enum constructor  yields an incorrect result in the reflection API whereas the result it is always incorrect today, given the implementation of both *ejc* and *javac*.
>> 
>> Ideally, this would of course also be fixed by javac (and ejc) such that the annotations are placed on the correct indices, but I still argue that the fix is an improvement for being able to properly process enum constructors for older class files also.
>
> @raphw a duplicate? https://bugs.openjdk.java.net/browse/JDK-8246586

Yes, indeed a duplicate. I linked the issue up against the original.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3082

From lancea at openjdk.java.net  Mon Mar 22 21:41:41 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 22 Mar 2021 21:41:41 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts,
 use of optional GZIP fields [v3]
In-Reply-To: <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
Message-ID: <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>

On Fri, 19 Mar 2021 08:19:58 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> 4890732: GZIPOutputStream doesn't support, in fact thwarts, use of optional GZIP fields
>
> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update copyright
>  - reuse arguments constructor for non-argument one.

Hi Lin,
 
Again, thank you for taking on this 19+ year feature request.

I have not done a deep dive on the CSR, but wanted to get a few comments back to you on a quick scan of the last PR update.

Personally, I would like to see more testing for a change such as this given the age of the code:

- Please do not modify the existing test, you can either create  a new test(s) or add tests to the existing test class
- We should capture Gzip files with these headers set from other tools and store the Gzip in an array within the test which can then be written to disk so the tests can validate interoperability.  Please see some of the other Zip tests for an example
- We should have tests that include some , but not all of the additional fields as I believe they are all optional according to the RFC.
- Please include some negative tests


I have also include some additional comments within the code

src/java.base/share/classes/java/util/zip/GZIPOutputStream.java line 193:

> 191:      * @param generateHeaderCRC
> 192:      *        if {@code true} the header will include the CRC16 of the header.
> 193:      * @param extraFieldBytes the byte array of extra filed,

filed -> field

src/java.base/share/classes/java/util/zip/GZIPOutputStream.java line 195:

> 193:      * @param extraFieldBytes the byte array of extra filed,
> 194:      *                        the generated header would calculate the byte[] size
> 195:      *                        and fill it before the byte[] in header.

This is not clear what you are trying to articulate here

src/java.base/share/classes/java/util/zip/GZIPOutputStream.java line 269:

> 267:      * @param generateHeaderCRC
> 268:      *        if {@code true} the header will include the CRC16 of the header.
> 269:      * @param extraFieldBytes the byte array of extra filed,

filed -> field

src/java.base/share/classes/java/util/zip/GZIPOutputStream.java line 320:

> 318:              *     +---+---+=================================+
> 319:              */
> 320:             int xlen = extraFieldBytes.length;

On a quick look at the RFC,  I noticed the following:

------------------------
2.3.1.1. Extra field

         If the FLG.FEXTRA bit is set, an "extra field" is present in
         the header, with total length XLEN bytes.  It consists of a
         series of subfields, each of the form:

            +---+---+---+---+==================================+
            |SI1|SI2|  LEN  |... LEN bytes of subfield data ...|
            +---+---+---+---+==================================+

         SI1 and SI2 provide a subfield ID, typically two ASCII letters
         with some mnemonic value.  Jean-Loup Gailly
         <gzip at prep.ai.mit.edu> is maintaining a registry of subfield
         IDs; please send him any subfield ID you wish to use.  Subfield
         IDs with SI2 = 0 are reserved for future use.  The following
         IDs are currently defined:


---------------

This does not seem to be accounted for or is it?

src/java.base/share/classes/java/util/zip/GZIPOutputStream.java line 323:

> 321:             if (xlen > 0xffff) {
> 322:                 throw new ZipException("extra field size out of range");
> 323:             }

Where is the ZipException documented that is being thrown?

src/java.base/share/classes/java/util/zip/GZIPOutputStream.java line 342:

> 340:              *    +=========================================+
> 341:              */
> 342:             out.write(filename);

The RFC indicates:

             If FNAME is set, an original file name is present,
            terminated by a zero byte.  The name must consist of ISO
            8859-1 (LATIN-1) characters; on operating systems using
            EBCDIC or any other character set for file names, the name
            must be translated to the ISO LATIN-1 character set.  This
            is the original name of the file being compressed, with any
            directory components removed, and, if the file being
            compressed is on a file system with case insensitive names,
            forced to lower case. There is no original file name if the
            data was compressed from a source other than a named file;
            for example, if the source was stdin on a Unix system, there
            is no file name.


It looks like there is no validation being done so I am not sure what the expectation is.

src/java.base/share/classes/java/util/zip/GZIPOutputStream.java line 357:

> 355:              */
> 356:             out.write(fileComment);
> 357:             out.write(0);

The RFC states:

            If FCOMMENT is set, a zero-terminated file comment is
            present.  This comment is not interpreted; it is only
            intended for human consumption.  The comment must consist of
            ISO 8859-1 (LATIN-1) characters.  Line breaks should be
            denoted by a single line feed character (10 decimal).


So should the characters be validates as well as line breaks?

test/jdk/java/util/zip/GZIP/GZIPOutputStreamHeaderTest.java line 3:

> 1: /*
> 2:  * Copyright (c) 2021, Oracle and/or its affiliates. All rights reserved.
> 3:  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.

The copyright would be 2020, 2021,

-------------

Changes requested by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3072

From asemenyuk at openjdk.java.net  Mon Mar 22 21:58:43 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 22 Mar 2021 21:58:43 GMT
Subject: RFR: JDK-8263887: Re-create default icons
In-Reply-To: <8v_kn43vqUCfHMiqY5uu3DF2tN8CV14bD5JL3YNqmFE=.3deac616-e000-488d-828d-50802dfcc99a@github.com>
References: <8v_kn43vqUCfHMiqY5uu3DF2tN8CV14bD5JL3YNqmFE=.3deac616-e000-488d-828d-50802dfcc99a@github.com>
Message-ID: <nGzl2U7n5m5FMdjNxja-2NWhrILL5Pf8mALxwsBDDzA=.70d19688-82fb-4824-912e-756d367fc6b5@github.com>

On Mon, 22 Mar 2021 13:03:10 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8263887: Re-create default icons

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3118

From asemenyuk at openjdk.java.net  Mon Mar 22 21:58:42 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 22 Mar 2021 21:58:42 GMT
Subject: RFR: JDK-8259926: Error in jpackage sample usage in the help text
In-Reply-To: <svG94wkAg8fU0l80Xkbqyt3YK8QNge9Evov56PiViQ8=.48a24253-0b29-4832-a6f0-df3211bc32bb@github.com>
References: <svG94wkAg8fU0l80Xkbqyt3YK8QNge9Evov56PiViQ8=.48a24253-0b29-4832-a6f0-df3211bc32bb@github.com>
Message-ID: <rpUNNBi2_6dCqNJPYMUq79vkbH0ZB55PjAYawhfBw60=.46db60e2-4897-419d-8c73-cf747f682e33@github.com>

On Mon, 22 Mar 2021 20:40:09 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8259926: Error in jpackage sample usage in the help text

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3132

From bchristi at openjdk.java.net  Mon Mar 22 22:07:45 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Mon, 22 Mar 2021 22:07:45 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread [v2]
In-Reply-To: <8GZqLhOohWvt6kS6lh27ZviQprQGEW-Ca0JjG7TK9AM=.55d865e7-8210-4255-8ca2-89c23cce522b@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
 <8GZqLhOohWvt6kS6lh27ZviQprQGEW-Ca0JjG7TK9AM=.55d865e7-8210-4255-8ca2-89c23cce522b@github.com>
Message-ID: <5loxTH0dz-_QjBpgKn3BTOzTn6a7Ax4v9KqUES5Ww5g=.4aa09f93-9d6f-46dc-95b6-76934ab324aa@github.com>

On Mon, 22 Mar 2021 07:19:28 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>> 
>> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
>> 
>> Testing:
>> mach5 tier1
>> New AutoStop test verifies the specified cleanup behavior.
>> (There are existing tests involving Timer.cancel.)
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   dholmes review

The change looks good to me (though making the ThreadReaper ctor non-public would be nice).

-------------

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3106

From almatvee at openjdk.java.net  Mon Mar 22 22:38:39 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Mon, 22 Mar 2021 22:38:39 GMT
Subject: RFR: JDK-8259926: Error in jpackage sample usage in the help text
In-Reply-To: <svG94wkAg8fU0l80Xkbqyt3YK8QNge9Evov56PiViQ8=.48a24253-0b29-4832-a6f0-df3211bc32bb@github.com>
References: <svG94wkAg8fU0l80Xkbqyt3YK8QNge9Evov56PiViQ8=.48a24253-0b29-4832-a6f0-df3211bc32bb@github.com>
Message-ID: <GW6gv0qu2qtXU2rHhgbEYeM0_hedKAIG5DUPqElVYnk=.99c532df-0d55-42e9-ad69-d995f5fb18b1@github.com>

On Mon, 22 Mar 2021 20:40:09 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8259926: Error in jpackage sample usage in the help text

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3132

From naoto at openjdk.java.net  Mon Mar 22 22:55:41 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 22 Mar 2021 22:55:41 GMT
Subject: RFR: JDK-8259926: Error in jpackage sample usage in the help text
In-Reply-To: <svG94wkAg8fU0l80Xkbqyt3YK8QNge9Evov56PiViQ8=.48a24253-0b29-4832-a6f0-df3211bc32bb@github.com>
References: <svG94wkAg8fU0l80Xkbqyt3YK8QNge9Evov56PiViQ8=.48a24253-0b29-4832-a6f0-df3211bc32bb@github.com>
Message-ID: <R0AdRk7TZmSMdf0wlXqxfnFNOabqban-4HsYKgbiOUE=.7849a0cc-8519-409d-831e-583260ce0ffd@github.com>

On Mon, 22 Mar 2021 20:40:09 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8259926: Error in jpackage sample usage in the help text

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3132

From kbarrett at openjdk.java.net  Tue Mar 23 01:03:55 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 23 Mar 2021 01:03:55 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread [v3]
In-Reply-To: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
Message-ID: <fkEB2yc_f0R5YoueQPKmJriw73IshFeWo8f2s-bnEE4=.2e5d4596-2c0d-4802-ab4b-c82f8d9ff6e4@github.com>

> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
> 
> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
> 
> Testing:
> mach5 tier1
> New AutoStop test verifies the specified cleanup behavior.
> (There are existing tests involving Timer.cancel.)

Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:

  make ThreadReaper constructor non-public

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3106/files
  - new: https://git.openjdk.java.net/jdk/pull/3106/files/2153a4c3..57500464

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3106&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3106&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3106.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3106/head:pull/3106

PR: https://git.openjdk.java.net/jdk/pull/3106

From dholmes at openjdk.java.net  Tue Mar 23 03:09:41 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 23 Mar 2021 03:09:41 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread [v3]
In-Reply-To: <fkEB2yc_f0R5YoueQPKmJriw73IshFeWo8f2s-bnEE4=.2e5d4596-2c0d-4802-ab4b-c82f8d9ff6e4@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
 <fkEB2yc_f0R5YoueQPKmJriw73IshFeWo8f2s-bnEE4=.2e5d4596-2c0d-4802-ab4b-c82f8d9ff6e4@github.com>
Message-ID: <EGZ9jMnGsD_VdtLEvP3f4SXJwJGW0ZwWXK_fL7Z83NM=.c3ac6e07-eb2c-4e03-bab3-e0d855ef2fc5@github.com>

On Tue, 23 Mar 2021 01:03:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>> 
>> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
>> 
>> Testing:
>> mach5 tier1
>> New AutoStop test verifies the specified cleanup behavior.
>> (There are existing tests involving Timer.cancel.)
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make ThreadReaper constructor non-public

Marked as reviewed by dholmes (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3106

From dholmes at openjdk.java.net  Tue Mar 23 03:15:39 2021
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 23 Mar 2021 03:15:39 GMT
Subject: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be
 singleton
In-Reply-To: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
References: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
Message-ID: <daNBliDCc0ocQ-MLahmFQOrprJUrsWWeL4Nu_QB8Qzc=.0a9947e4-929f-4a1d-9358-4cd167c12ec9@github.com>

On Mon, 22 Mar 2021 19:40:19 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> With CDS and G1, test api/java_lang/ModuleLayer/Boot.html fails in JDK 16. 
> 
> After JDK-8253081 with CDS enabled two instances of empty layer appear in the runtime. One comes from default initialization of java/lang/ModuleLayer.EMPTY_LAYER, another one comes from CDS archive and is returned by ModuleLayer.boot().parents().get(0). The fix makes java/lang/ModuleLayer.EMPTY_LAYER a singleton with both CDS on and off, similar to java/lang/module/Configuration.EMPTY_CONFIGURATION.
> 
> Testing: JCK 16, jtreg (including newly added test), pre-submit GitHub actions tests.

Seems reasonable.

Though I hadn't realized CDS intruded into the Java layer that way!

-------------

Marked as reviewed by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3131

From alanb at openjdk.java.net  Tue Mar 23 06:50:43 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 23 Mar 2021 06:50:43 GMT
Subject: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be
 singleton
In-Reply-To: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
References: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
Message-ID: <pv02diq50ntFdq66X2jxAz9l2qmb3yzDAvHWCu5nl5w=.67f6822d-6d83-452c-a62e-5fb02a234e82@github.com>

On Mon, 22 Mar 2021 19:40:19 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> With CDS and G1, test api/java_lang/ModuleLayer/Boot.html fails in JDK 16. 
> 
> After JDK-8253081 with CDS enabled two instances of empty layer appear in the runtime. One comes from default initialization of java/lang/ModuleLayer.EMPTY_LAYER, another one comes from CDS archive and is returned by ModuleLayer.boot().parents().get(0). The fix makes java/lang/ModuleLayer.EMPTY_LAYER a singleton with both CDS on and off, similar to java/lang/module/Configuration.EMPTY_CONFIGURATION.
> 
> Testing: JCK 16, jtreg (including newly added test), pre-submit GitHub actions tests.

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/lang/ModuleLayer.java line 156:

> 154: 
> 155:     static {
> 156:         // Initialize EMPTY_LAYER from the archive.

Style wide you can drop L154 and L156 and the comment on EMPTY_LAYER will cover its initialization too.

Otherwise looks okay but the more archiving we add does make it harder to change this code.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3131

From alanb at openjdk.java.net  Tue Mar 23 06:52:47 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 23 Mar 2021 06:52:47 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread [v3]
In-Reply-To: <fkEB2yc_f0R5YoueQPKmJriw73IshFeWo8f2s-bnEE4=.2e5d4596-2c0d-4802-ab4b-c82f8d9ff6e4@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
 <fkEB2yc_f0R5YoueQPKmJriw73IshFeWo8f2s-bnEE4=.2e5d4596-2c0d-4802-ab4b-c82f8d9ff6e4@github.com>
Message-ID: <Muk70gQyLSYRO0_pX5DJPfpStLMWU12j1I-BE_vsyXY=.94d685ac-03e1-43eb-abc6-b400232e97ac@github.com>

On Tue, 23 Mar 2021 01:03:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>> 
>> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
>> 
>> Testing:
>> mach5 tier1
>> New AutoStop test verifies the specified cleanup behavior.
>> (There are existing tests involving Timer.cancel.)
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make ThreadReaper constructor non-public

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3106

From joehw at openjdk.java.net  Tue Mar 23 06:55:44 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 23 Mar 2021 06:55:44 GMT
Subject: Integrated: 8261673: Move javadoc for the lookup mechanism to
 module-info
In-Reply-To: <wg6xvhZiamooKkIS_HhsC0zOcFl9LN82cg3Xc_QBbqM=.b09e8950-6c4e-477d-a2b3-455eab6046f1@github.com>
References: <wg6xvhZiamooKkIS_HhsC0zOcFl9LN82cg3Xc_QBbqM=.b09e8950-6c4e-477d-a2b3-455eab6046f1@github.com>
Message-ID: <VUo-y7v45vnXVN255EEHlzQKh8aj_p9g4P_kVByF0-k=.e7bd8edf-e07c-44c9-8d75-d03e8b3d9f26@github.com>

On Tue, 16 Mar 2021 00:52:24 GMT, Joe Wang <joehw at openjdk.org> wrote:

> Consolidate and move javadoc for the lookup mechanism to the module summary.

This pull request has now been integrated.

Changeset: 289d48ae
Author:    Joe Wang <joehw at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/289d48ae
Stats:     602 lines in 9 files changed: 197 ins; 361 del; 44 mod

8261673: Move javadoc for the lookup mechanism to module-info

Reviewed-by: lancea, naoto, iris

-------------

PR: https://git.openjdk.java.net/jdk/pull/3020

From github.com+76791+alblue at openjdk.java.net  Tue Mar 23 07:07:14 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Tue, 23 Mar 2021 07:07:14 GMT
Subject: RFR: 8264019: Use the blessed modifier order in java.xml
Message-ID: <pyRUfAzGFBDQxvfpjDhK-32rwGuuXBEDQyYXTP9LDY8=.413db9c7-3090-4d70-a3ef-0e1409a16e56@github.com>

As a subtask of JDK-8263854 this cleans up the `java.xml` module to used the blessed modifier order.

-------------

Commit messages:
 - Reordered final static to static final
 - Use the blessed modifier order in java.xml

Changes: https://git.openjdk.java.net/jdk/pull/3091/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3091&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264019
  Stats: 336 lines in 85 files changed: 0 ins; 0 del; 336 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3091.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3091/head:pull/3091

PR: https://git.openjdk.java.net/jdk/pull/3091

From github.com+76791+alblue at openjdk.java.net  Tue Mar 23 07:07:15 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Tue, 23 Mar 2021 07:07:15 GMT
Subject: RFR: 8264019: Use the blessed modifier order in java.xml
In-Reply-To: <pyRUfAzGFBDQxvfpjDhK-32rwGuuXBEDQyYXTP9LDY8=.413db9c7-3090-4d70-a3ef-0e1409a16e56@github.com>
References: <pyRUfAzGFBDQxvfpjDhK-32rwGuuXBEDQyYXTP9LDY8=.413db9c7-3090-4d70-a3ef-0e1409a16e56@github.com>
Message-ID: <53tEGZbggxrU6PJ-QYK6_lBMIMZt3CbZ_31P7hKBzJ0=.c8ff1420-84a5-4cab-98ab-b1d5dd8757bf@github.com>

On Fri, 19 Mar 2021 16:17:40 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> As a subtask of JDK-8263854 this cleans up the `java.xml` module to used the blessed modifier order.

Would someone mind creating a bug for me under the parent bug JDK-8263854?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3091

From github.com+76791+alblue at openjdk.java.net  Tue Mar 23 07:07:15 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Tue, 23 Mar 2021 07:07:15 GMT
Subject: RFR: 8264019: Use the blessed modifier order in java.xml
In-Reply-To: <53tEGZbggxrU6PJ-QYK6_lBMIMZt3CbZ_31P7hKBzJ0=.c8ff1420-84a5-4cab-98ab-b1d5dd8757bf@github.com>
References: <pyRUfAzGFBDQxvfpjDhK-32rwGuuXBEDQyYXTP9LDY8=.413db9c7-3090-4d70-a3ef-0e1409a16e56@github.com>
 <53tEGZbggxrU6PJ-QYK6_lBMIMZt3CbZ_31P7hKBzJ0=.c8ff1420-84a5-4cab-98ab-b1d5dd8757bf@github.com>
Message-ID: <Jc0cZp57oOE5qrEfWcrG_Nemw1dzAajboLXMNd3EDLg=.ddd22a8a-7a0f-4320-a6a3-30d158123776@github.com>

On Fri, 19 Mar 2021 23:40:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> As a subtask of JDK-8263854 this cleans up the `java.xml` module to used the blessed modifier order.
>
> Would someone mind creating a bug for me under the parent bug JDK-8263854?

@shipilev would you mind creating a bug for me please?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3091

From shade at openjdk.java.net  Tue Mar 23 07:07:15 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 23 Mar 2021 07:07:15 GMT
Subject: RFR: 8264019: Use the blessed modifier order in java.xml
In-Reply-To: <Jc0cZp57oOE5qrEfWcrG_Nemw1dzAajboLXMNd3EDLg=.ddd22a8a-7a0f-4320-a6a3-30d158123776@github.com>
References: <pyRUfAzGFBDQxvfpjDhK-32rwGuuXBEDQyYXTP9LDY8=.413db9c7-3090-4d70-a3ef-0e1409a16e56@github.com>
 <53tEGZbggxrU6PJ-QYK6_lBMIMZt3CbZ_31P7hKBzJ0=.c8ff1420-84a5-4cab-98ab-b1d5dd8757bf@github.com>
 <Jc0cZp57oOE5qrEfWcrG_Nemw1dzAajboLXMNd3EDLg=.ddd22a8a-7a0f-4320-a6a3-30d158123776@github.com>
Message-ID: <0DzFRjrn4hDo6jI7uJiMpyAsgjRn0ro5ydcl-86wZOo=.a6b0d388-5e4a-42ef-b9c9-4bd6f07019d7@github.com>

On Mon, 22 Mar 2021 20:55:55 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> Would someone mind creating a bug for me under the parent bug JDK-8263854?
>
> @shipilev would you mind creating a bug for me please?

Sure, here it is: https://bugs.openjdk.java.net/browse/JDK-8264019

-------------

PR: https://git.openjdk.java.net/jdk/pull/3091

From alanb at openjdk.java.net  Tue Mar 23 07:27:42 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 23 Mar 2021 07:27:42 GMT
Subject: RFR: 8264019: Use the blessed modifier order in java.xml
In-Reply-To: <0DzFRjrn4hDo6jI7uJiMpyAsgjRn0ro5ydcl-86wZOo=.a6b0d388-5e4a-42ef-b9c9-4bd6f07019d7@github.com>
References: <pyRUfAzGFBDQxvfpjDhK-32rwGuuXBEDQyYXTP9LDY8=.413db9c7-3090-4d70-a3ef-0e1409a16e56@github.com>
 <53tEGZbggxrU6PJ-QYK6_lBMIMZt3CbZ_31P7hKBzJ0=.c8ff1420-84a5-4cab-98ab-b1d5dd8757bf@github.com>
 <Jc0cZp57oOE5qrEfWcrG_Nemw1dzAajboLXMNd3EDLg=.ddd22a8a-7a0f-4320-a6a3-30d158123776@github.com>
 <0DzFRjrn4hDo6jI7uJiMpyAsgjRn0ro5ydcl-86wZOo=.a6b0d388-5e4a-42ef-b9c9-4bd6f07019d7@github.com>
Message-ID: <_Dm04Xn2Cu3JjRuNfDKIFjWx2jQJQmwiFX0S6yGDKT8=.4433aa36-e3a3-42d7-8eb7-e0062d4ee602@github.com>

On Tue, 23 Mar 2021 06:53:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> @shipilev would you mind creating a bug for me please?
>
> Sure, here it is: https://bugs.openjdk.java.net/browse/JDK-8264019

The JDK's copy of the xalan and xerces code has diverged significantly from upstream so maybe this change is okay, Joe Wang can say.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3091

From avoitylov at openjdk.java.net  Tue Mar 23 08:04:09 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Tue, 23 Mar 2021 08:04:09 GMT
Subject: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be
 singleton [v2]
In-Reply-To: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
References: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
Message-ID: <C6roaR7ZxyPk0pJIPt2arP5KpOsVzIO8KF0uXfrv9Lw=.a4b75f9a-3da1-4df9-a0a5-1ad7880d209c@github.com>

> With CDS and G1, test api/java_lang/ModuleLayer/Boot.html fails in JDK 16. 
> 
> After JDK-8253081 with CDS enabled two instances of empty layer appear in the runtime. One comes from default initialization of java/lang/ModuleLayer.EMPTY_LAYER, another one comes from CDS archive and is returned by ModuleLayer.boot().parents().get(0). The fix makes java/lang/ModuleLayer.EMPTY_LAYER a singleton with both CDS on and off, similar to java/lang/module/Configuration.EMPTY_CONFIGURATION.
> 
> Testing: JCK 16, jtreg (including newly added test), pre-submit GitHub actions tests.

Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:

  fix style

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3131/files
  - new: https://git.openjdk.java.net/jdk/pull/3131/files/3a69084a..0cae1a2d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3131&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3131&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3131.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3131/head:pull/3131

PR: https://git.openjdk.java.net/jdk/pull/3131

From avoitylov at openjdk.java.net  Tue Mar 23 08:06:43 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Tue, 23 Mar 2021 08:06:43 GMT
Subject: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be
 singleton [v2]
In-Reply-To: <pv02diq50ntFdq66X2jxAz9l2qmb3yzDAvHWCu5nl5w=.67f6822d-6d83-452c-a62e-5fb02a234e82@github.com>
References: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
 <pv02diq50ntFdq66X2jxAz9l2qmb3yzDAvHWCu5nl5w=.67f6822d-6d83-452c-a62e-5fb02a234e82@github.com>
Message-ID: <WaxxQEppkpd1jM0VrRcMB9RRKUJSTjxmiig6bK6oAcU=.93c82629-cf42-49e5-b987-eb427c7ef7a2@github.com>

On Tue, 23 Mar 2021 06:47:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix style
>
> src/java.base/share/classes/java/lang/ModuleLayer.java line 156:
> 
>> 154: 
>> 155:     static {
>> 156:         // Initialize EMPTY_LAYER from the archive.
> 
> Style wide you can drop L154 and L156 and the comment on EMPTY_LAYER will cover its initialization too.
> 
> Otherwise looks okay but the more archiving we add does make it harder to change this code.

Fixed according to your comments. Thanks! 

I was surprised to find CDS specific code in the java layer as well, but it's not the design choice I believe I can make with this bug fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3131

From alanb at openjdk.java.net  Tue Mar 23 08:24:39 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 23 Mar 2021 08:24:39 GMT
Subject: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be
 singleton [v2]
In-Reply-To: <C6roaR7ZxyPk0pJIPt2arP5KpOsVzIO8KF0uXfrv9Lw=.a4b75f9a-3da1-4df9-a0a5-1ad7880d209c@github.com>
References: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
 <C6roaR7ZxyPk0pJIPt2arP5KpOsVzIO8KF0uXfrv9Lw=.a4b75f9a-3da1-4df9-a0a5-1ad7880d209c@github.com>
Message-ID: <NuvbIaK4AJ8avuLsGSAe3hJv5x_82VVhArQz3MiHfe4=.f7a1185f-3f6b-4403-aa54-acf24f665fe7@github.com>

On Tue, 23 Mar 2021 08:04:09 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> With CDS and G1, test api/java_lang/ModuleLayer/Boot.html fails in JDK 16. 
>> 
>> After JDK-8253081 with CDS enabled two instances of empty layer appear in the runtime. One comes from default initialization of java/lang/ModuleLayer.EMPTY_LAYER, another one comes from CDS archive and is returned by ModuleLayer.boot().parents().get(0). The fix makes java/lang/ModuleLayer.EMPTY_LAYER a singleton with both CDS on and off, similar to java/lang/module/Configuration.EMPTY_CONFIGURATION.
>> 
>> Testing: JCK 16, jtreg (including newly added test), pre-submit GitHub actions tests.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix style

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3131

From aph at openjdk.java.net  Tue Mar 23 09:56:56 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 09:56:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]
In-Reply-To: <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
 <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>
Message-ID: <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>

On Fri, 12 Mar 2021 16:32:10 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 105 commits:
>> 
>>  - Merge commit 'refs/pull/11/head' of https://github.com/AntonKozlov/jdk into jdk-macos
>>  - workaround JDK-8262895 by disabling subtest
>>  - Fix typo
>>  - Rename threadWXSetters.hpp -> threadWXSetters.inline.hpp
>>  - JDK-8259937: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Fix after JDK-8259539, partially revert preconditions
>>  - JDK-8260471: bsd_aarch64 part
>>  - JDK-8259539: bsd_aarch64 part
>>  - JDK-8257828: bsd_aarch64 part
>>  - ... and 95 more: https://git.openjdk.java.net/jdk/compare/a6e34b3d...a72f6834
>
>> @theRealAph, could you elaborate on what is need to be done for [#2200 (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).
> 
> I think that what you've got now is fine.

> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
> 
> On 3/15/21 6:56 PM, Anton Kozlov wrote:
> 
> > On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley <aph at openjdk.org> wrote:
> > > > We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?
> > > 
> > > 
> > > Robustness, clarity, maintainability, convention. Why not?
> > 
> > 
> > I've tried to implement the suggestion, but it pulled more unnecessary changes. It makes the intended way to check the condition less clear (`#ifdef` and not `#if`).
> 
> No, no, no! I am not suggesting you change anything else, just that
> you do not define contentless macros. You might as well define it
> to be something, and true is a reasonable default, that's all. It's
> not terribly important, it's just good practice.

I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From aph at openjdk.java.net  Tue Mar 23 09:56:57 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 09:56:57 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]
In-Reply-To: <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
 <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>
 <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>
Message-ID: <YVVYsQezst6QHcY0q_q-dmOYnzGiMdXaqabDahOmqO4=.1c0a67c6-1db1-4975-8c87-fb5308ac18dc@github.com>

On Tue, 23 Mar 2021 09:53:54 GMT, Andrew Haley <aph at openjdk.org> wrote:

>>> @theRealAph, could you elaborate on what is need to be done for [#2200 (review)](https://github.com/openjdk/jdk/pull/2200#pullrequestreview-600597066).
>> 
>> I think that what you've got now is fine.
>
>> _Mailing list message from [Andrew Haley](mailto:aph at redhat.com) on [build-dev](mailto:build-dev at openjdk.java.net):_
>> 
>> On 3/15/21 6:56 PM, Anton Kozlov wrote:
>> 
>> > On Wed, 10 Mar 2021 11:21:44 GMT, Andrew Haley <aph at openjdk.org> wrote:
>> > > > We always check for `R18_RESERVED` with `#if(n)def`, is there any reason to define the value for the macro?
>> > > 
>> > > 
>> > > Robustness, clarity, maintainability, convention. Why not?
>> > 
>> > 
>> > I've tried to implement the suggestion, but it pulled more unnecessary changes. It makes the intended way to check the condition less clear (`#ifdef` and not `#if`).
>> 
>> No, no, no! I am not suggesting you change anything else, just that
>> you do not define contentless macros. You might as well define it
>> to be something, and true is a reasonable default, that's all. It's
>> not terribly important, it's just good practice.
> 
> I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.

So, where are we up to now? Are we done yet?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Tue Mar 23 11:20:52 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 23 Mar 2021 11:20:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v24]
In-Reply-To: <YVVYsQezst6QHcY0q_q-dmOYnzGiMdXaqabDahOmqO4=.1c0a67c6-1db1-4975-8c87-fb5308ac18dc@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <LMAOpd9DlD4esG9l4lwxtOe5_j1Cpi6aU33tVWCz3bE=.b4ab8215-55c0-43b4-a222-03e5aa0862e3@github.com>
 <Lw_ar-Qr7JWxNWFgRc4qBWYsL12i8-eRmarTyB3gGto=.f3c76e3e-626d-468b-9c03-e4ce9f7ecf33@github.com>
 <3fAiKgcWOdYNUYMfY0LSvyMswzjlKJWJaxZgGf7tdYE=.aa5e7ae8-2744-4c2c-9e66-b72e19d9ebec@github.com>
 <YVVYsQezst6QHcY0q_q-dmOYnzGiMdXaqabDahOmqO4=.1c0a67c6-1db1-4975-8c87-fb5308ac18dc@github.com>
Message-ID: <Rdc-1pvRQKF9q1HEI0zkO7Dgn5GAu1rgDZ_vH-5J5nM=.637e4903-b31d-4f06-8e98-473a057f13fc@github.com>

On Tue, 23 Mar 2021 09:54:16 GMT, Andrew Haley <aph at openjdk.org> wrote:

> So, where are we up to now? Are we done yet?

Hello
we would like to get approval for the final version we have now and then integrate this pr as soon as Mark will target it to jdk17

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From jlaskey at openjdk.java.net  Tue Mar 23 11:32:08 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 23 Mar 2021 11:32:08 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v35]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <fui2AWnHI-8lt57CT-A_qjhk6vfLpFZ5FFyPjZkHATI=.3e184e15-1c2d-46aa-8e59-acc095f3dfd9@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Removed @since from nextDouble ThreadLocalRandom

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/4562dd13..22ea21d2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=34
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=33-34

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

PR: https://git.openjdk.java.net/jdk/pull/1292

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 23 12:24:01 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Mar 2021 12:24:01 GMT
Subject: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in
 java.base
Message-ID: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com>

Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.base`
Similar cleanup in the past - https://bugs.openjdk.java.net/browse/JDK-8041679

-------------

Commit messages:
 - [PATCH] Replaces usages of StringBuffer with StringBuilder where appropriate in java.base

Changes: https://git.openjdk.java.net/jdk/pull/2922/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2922&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264029
  Stats: 12 lines in 3 files changed: 0 ins; 3 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2922.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2922/head:pull/2922

PR: https://git.openjdk.java.net/jdk/pull/2922

From shade at openjdk.java.net  Tue Mar 23 12:24:02 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 23 Mar 2021 12:24:02 GMT
Subject: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in
 java.base
In-Reply-To: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com>
References: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com>
Message-ID: <rQnPP7gZtZnx7dP7nG67k_YEgzMf2URXnoTT4LMTNm4=.d5f1020f-38fe-49fb-a4b3-c7e3b46fb64f@github.com>

On Wed, 10 Mar 2021 19:47:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.base`
> Similar cleanup in the past - https://bugs.openjdk.java.net/browse/JDK-8041679

This looks good to me.

I have created the bug for it: https://bugs.openjdk.java.net/browse/JDK-8264029 -- please change the PR synopsis to "8264029: Replace uses of StringBuffer with StringBuilder in java.base"

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2922

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 23 12:25:53 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Mar 2021 12:25:53 GMT
Subject: RFR: 8264032: Improve thread safety of Runtime.version()
Message-ID: <C-lDpE5mWiPgEQ5bRmZRAeLGoUcBrzTzm3oRr4Zj3S0=.326da3ff-ca74-437b-83b2-ca7c32579805@github.com>

Avoid double-read non volatile static field

-------------

Commit messages:
 - [PATCH] Thread-safe initialization of Runtime.version

Changes: https://git.openjdk.java.net/jdk/pull/2691/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2691&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264032
  Stats: 6 lines in 1 file changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2691.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2691/head:pull/2691

PR: https://git.openjdk.java.net/jdk/pull/2691

From shade at openjdk.java.net  Tue Mar 23 12:25:53 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 23 Mar 2021 12:25:53 GMT
Subject: RFR: 8264032: Improve thread safety of Runtime.version()
In-Reply-To: <C-lDpE5mWiPgEQ5bRmZRAeLGoUcBrzTzm3oRr4Zj3S0=.326da3ff-ca74-437b-83b2-ca7c32579805@github.com>
References: <C-lDpE5mWiPgEQ5bRmZRAeLGoUcBrzTzm3oRr4Zj3S0=.326da3ff-ca74-437b-83b2-ca7c32579805@github.com>
Message-ID: <rxlTiU_kS-CEIyFtX_u0XeGr_fztx9xe6fuOIltdWd0=.92c3bcfc-7944-428c-bff4-b227b04f5f8d@github.com>

On Tue, 23 Feb 2021 13:23:44 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Avoid double-read non volatile static field

This looks fine to me.

I created the bug for this: https://bugs.openjdk.java.net/browse/JDK-8264032 -- please change the PR synopsis to "8264032: Improve thread safety of Runtime.version()".

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2691

From github.com+7806504+liach at openjdk.java.net  Tue Mar 23 12:25:54 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Tue, 23 Mar 2021 12:25:54 GMT
Subject: RFR: 8264032: Improve thread safety of Runtime.version()
In-Reply-To: <C-lDpE5mWiPgEQ5bRmZRAeLGoUcBrzTzm3oRr4Zj3S0=.326da3ff-ca74-437b-83b2-ca7c32579805@github.com>
References: <C-lDpE5mWiPgEQ5bRmZRAeLGoUcBrzTzm3oRr4Zj3S0=.326da3ff-ca74-437b-83b2-ca7c32579805@github.com>
Message-ID: <fLwVJCvBOuIB4d2KWpfioUJWr4t75-ZF6CBYxANJny8=.ff324bf4-3f01-4b0a-8bf4-32088e4dc6ab@github.com>

On Tue, 23 Feb 2021 13:23:44 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Avoid double-read non volatile static field

This shouldn't be a problem. Version is a pojo and value based, and the computed result may be different instances but would return `true` for `equals` and should have no problems

src/java.base/share/classes/java/lang/Runtime.java line 824:

> 822:                     VersionProps.pre(), VersionProps.build(),
> 823:                     VersionProps.optional());
> 824:             version = v;

Can't this just be `return version = new Version(...` than reassigning to a local variable for no good?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2691

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 23 12:25:54 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Mar 2021 12:25:54 GMT
Subject: RFR: 8264032: Improve thread safety of Runtime.version()
In-Reply-To: <fLwVJCvBOuIB4d2KWpfioUJWr4t75-ZF6CBYxANJny8=.ff324bf4-3f01-4b0a-8bf4-32088e4dc6ab@github.com>
References: <C-lDpE5mWiPgEQ5bRmZRAeLGoUcBrzTzm3oRr4Zj3S0=.326da3ff-ca74-437b-83b2-ca7c32579805@github.com>
 <fLwVJCvBOuIB4d2KWpfioUJWr4t75-ZF6CBYxANJny8=.ff324bf4-3f01-4b0a-8bf4-32088e4dc6ab@github.com>
Message-ID: <cvpP6MIbLHnoG26oQ4ReVfCTje6QwdkoxJ1vD5N9VzA=.656dd8cd-c63b-463a-9c63-463a90494cd3@github.com>

On Tue, 23 Feb 2021 16:13:21 GMT, liach <github.com+7806504+liach at openjdk.org> wrote:

>This shouldn't be a problem.

What do you mean by "this"? Double racy read?
There are 2 separate reads of fields. First can return non-null value, while second still can get `null`

> src/java.base/share/classes/java/lang/Runtime.java line 824:
> 
>> 822:                     VersionProps.pre(), VersionProps.build(),
>> 823:                     VersionProps.optional());
>> 824:             version = v;
> 
> Can't this just be `return version = new Version(...` than reassigning to a local variable for no good?

It's matter of style. I've seen both styles are acceptable in JDK codebase. I personally prefer placing assigning each variable into separate lines.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2691

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 23 12:25:55 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Mar 2021 12:25:55 GMT
Subject: RFR: 8264032: Improve thread safety of Runtime.version()
In-Reply-To: <sa89aXWQNZLoBE1kAlPwLxIby94EbJOqtuMC7Sx1hkQ=.3b99f2aa-57e6-44ec-bf56-ffe515e3b556@github.com>
References: <C-lDpE5mWiPgEQ5bRmZRAeLGoUcBrzTzm3oRr4Zj3S0=.326da3ff-ca74-437b-83b2-ca7c32579805@github.com>
 <fLwVJCvBOuIB4d2KWpfioUJWr4t75-ZF6CBYxANJny8=.ff324bf4-3f01-4b0a-8bf4-32088e4dc6ab@github.com>
 <cvpP6MIbLHnoG26oQ4ReVfCTje6QwdkoxJ1vD5N9VzA=.656dd8cd-c63b-463a-9c63-463a90494cd3@github.com>
 <sa89aXWQNZLoBE1kAlPwLxIby94EbJOqtuMC7Sx1hkQ=.3b99f2aa-57e6-44ec-bf56-ffe515e3b556@github.com>
Message-ID: <_itkkSEVcrzHjE_byhHwHXhApKQFGWvew7ZgwYGOUR8=.eb12143c-8f8d-42d9-b34a-8faf3d389f1c@github.com>

On Tue, 23 Feb 2021 16:59:45 GMT, liach <github.com+7806504+liach at openjdk.org> wrote:

>>>This shouldn't be a problem.
>> 
>> What do you mean by "this"? Double racy read?
>> There are 2 separate reads of fields. First can return non-null value, while second still can get `null`
>
>> There are 2 separate reads of fields. First can return non-null value, while second still can get null
> 
> Can this really happen? If this `version` field has been updated, its value is definitely no longer `null`. And before the second field read the field is always set to a non-null value on the current thread. I fail to understand why the second read can still yield a null given the fact that the current thread has updated it to a non-null value and other threads may have updated it to a non-null value.

I'm not really a JMM mastermind, but I know that @shipilev knows a thing or two about it :)
See https://shipilev.net/blog/2016/close-encounters-of-jmm-kind/#wishful-benign-is-resilient

-------------

PR: https://git.openjdk.java.net/jdk/pull/2691

From github.com+7806504+liach at openjdk.java.net  Tue Mar 23 12:25:55 2021
From: github.com+7806504+liach at openjdk.java.net (liach)
Date: Tue, 23 Mar 2021 12:25:55 GMT
Subject: RFR: 8264032: Improve thread safety of Runtime.version()
In-Reply-To: <cvpP6MIbLHnoG26oQ4ReVfCTje6QwdkoxJ1vD5N9VzA=.656dd8cd-c63b-463a-9c63-463a90494cd3@github.com>
References: <C-lDpE5mWiPgEQ5bRmZRAeLGoUcBrzTzm3oRr4Zj3S0=.326da3ff-ca74-437b-83b2-ca7c32579805@github.com>
 <fLwVJCvBOuIB4d2KWpfioUJWr4t75-ZF6CBYxANJny8=.ff324bf4-3f01-4b0a-8bf4-32088e4dc6ab@github.com>
 <cvpP6MIbLHnoG26oQ4ReVfCTje6QwdkoxJ1vD5N9VzA=.656dd8cd-c63b-463a-9c63-463a90494cd3@github.com>
Message-ID: <sa89aXWQNZLoBE1kAlPwLxIby94EbJOqtuMC7Sx1hkQ=.3b99f2aa-57e6-44ec-bf56-ffe515e3b556@github.com>

On Tue, 23 Feb 2021 16:46:06 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> There are 2 separate reads of fields. First can return non-null value, while second still can get null

Can this really happen? If this `version` field has been updated, its value is definitely no longer `null`. And before the second field read the field is always set to a non-null value on the current thread. I fail to understand why the second read can still yield a null given the fact that the current thread has updated it to a non-null value and other threads may have updated it to a non-null value.

>> src/java.base/share/classes/java/lang/Runtime.java line 824:
>> 
>>> 822:                     VersionProps.pre(), VersionProps.build(),
>>> 823:                     VersionProps.optional());
>>> 824:             version = v;
>> 
>> Can't this just be `return version = new Version(...` than reassigning to a local variable for no good?
>
> It's matter of style. I've seen both styles are acceptable in JDK codebase. I personally prefer placing assigning each variable into separate lines.

Doesn't using `return version = new Version(...` allow one local variable to be effectively final and save two aload/astore opcodes? Guess jvm optimizes it

-------------

PR: https://git.openjdk.java.net/jdk/pull/2691

From prappo at openjdk.java.net  Tue Mar 23 12:40:41 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 23 Mar 2021 12:40:41 GMT
Subject: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in
 java.base
In-Reply-To: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com>
References: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com>
Message-ID: <yNg9GtLV_kyvs_xdWSxdjOYAiC2Awa7PZQCG-L_AwA8=.b20ca7ba-fd49-46cf-bd61-c2db366cdff5@github.com>

On Wed, 10 Mar 2021 19:47:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.base`
> Similar cleanup in the past - https://bugs.openjdk.java.net/browse/JDK-8041679

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1954:

> 1952:             for (int i = 0; i < 4; ++i) {
> 1953:                 if (i > 0) {
> 1954:                     sb.append("       ");

Consider using `String.repeat` here and on L1960 for clarity.

src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1954:

> 1952:             for (int i = 0; i < 4; ++i) {
> 1953:                 if (i > 0) {
> 1954:                     sb.append("       ");

Consider using `String.repeat` here and on L1960 for clarity.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2922

From ihse at openjdk.java.net  Tue Mar 23 12:52:56 2021
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 23 Mar 2021 12:52:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <ee0H_EQKtLdriO2ohEbSJTCgQLo6pkpNrM4q8gZkq1M=.6a33a0af-4134-4216-97fd-188bbfb7124b@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Build changes still look good. Hope you can get this done now! :)

-------------

Marked as reviewed by ihse (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2200

From erikj at openjdk.java.net  Tue Mar 23 12:52:55 2021
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 23 Mar 2021 12:52:55 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <Xu_AFSUmt_tBHnpdHhAaUZOzuYq-L4_nGbwq_OMQk78=.8f69da0c-abd5-4688-855f-69cbbdc87770@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Build changes look good.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2200

From alanb at openjdk.java.net  Tue Mar 23 12:59:40 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 23 Mar 2021 12:59:40 GMT
Subject: RFR: 8264032: Improve thread safety of Runtime.version()
In-Reply-To: <C-lDpE5mWiPgEQ5bRmZRAeLGoUcBrzTzm3oRr4Zj3S0=.326da3ff-ca74-437b-83b2-ca7c32579805@github.com>
References: <C-lDpE5mWiPgEQ5bRmZRAeLGoUcBrzTzm3oRr4Zj3S0=.326da3ff-ca74-437b-83b2-ca7c32579805@github.com>
Message-ID: <zYDCYFnFuJO007yp2Mb6ZEf8DP_ZJXmVWa8z4ti4VGM=.41b0678a-066e-406c-9155-f3736fd1d440@github.com>

On Tue, 23 Feb 2021 13:23:44 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Avoid double-read non volatile static field

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2691

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 23 13:24:40 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Mar 2021 13:24:40 GMT
Subject: Integrated: 8264032: Improve thread safety of Runtime.version()
In-Reply-To: <C-lDpE5mWiPgEQ5bRmZRAeLGoUcBrzTzm3oRr4Zj3S0=.326da3ff-ca74-437b-83b2-ca7c32579805@github.com>
References: <C-lDpE5mWiPgEQ5bRmZRAeLGoUcBrzTzm3oRr4Zj3S0=.326da3ff-ca74-437b-83b2-ca7c32579805@github.com>
Message-ID: <Te4i46ZHBXfN6Pu1CXFdjg-nVgR0_I5NSVlcbs2GNXQ=.5e9b8f73-cec2-4677-99e3-a3534ce5eaf4@github.com>

On Tue, 23 Feb 2021 13:23:44 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Avoid double-read non volatile static field

This pull request has now been integrated.

Changeset: 23353626
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/23353626
Stats:     6 lines in 1 file changed: 2 ins; 0 del; 4 mod

8264032: Improve thread safety of Runtime.version()

Reviewed-by: shade, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/2691

From akozlov at openjdk.java.net  Tue Mar 23 13:28:52 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Tue, 23 Mar 2021 13:28:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <ee0H_EQKtLdriO2ohEbSJTCgQLo6pkpNrM4q8gZkq1M=.6a33a0af-4134-4216-97fd-188bbfb7124b@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <ee0H_EQKtLdriO2ohEbSJTCgQLo6pkpNrM4q8gZkq1M=.6a33a0af-4134-4216-97fd-188bbfb7124b@github.com>
Message-ID: <VELjoQXnn9AqZJ5xS5fBeZITIpOuJ7_AyRr7Vxl5m0I=.8ec3a1cd-6af2-4bb7-9c43-2fa4a1474a24@github.com>

On Tue, 23 Mar 2021 12:49:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Build changes still look good. Hope you can get this done now! :)

> > No, no, no! I am not suggesting you change anything else, just that
> > you do not define contentless macros. You might as well define it
> > to be something, and true is a reasonable default, that's all. It's
> > not terribly important, it's just good practice.
> 
> I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.

Sorry, I missed your reply.

R18_RESERVED is also defined in https://github.com/openjdk/jdk/blob/master/make/hotspot/gensrc/GensrcAdlc.gmk#L96. I think changing the value here and there would be slightly out of the scope of this PR, so I would prefer to avoid the suggested change. 

The biggest argument from my side is that the current macro value is consistent with the rest of the macros in this file. For example https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L35
and https://github.com/openjdk/jdk/blob/b7b391b2ac4208eabdee4e93acd5b0e364953f94/src/hotspot/share/runtime/mutexLocker.cpp#L137

But https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L59
and       
https://github.com/openjdk/jdk/blob/b23228d152ff8fa27bd32d9ef1307bf315039dea/src/hotspot/share/runtime/arguments.cpp#L1540

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From rriggs at openjdk.java.net  Tue Mar 23 13:47:41 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 23 Mar 2021 13:47:41 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread [v3]
In-Reply-To: <fkEB2yc_f0R5YoueQPKmJriw73IshFeWo8f2s-bnEE4=.2e5d4596-2c0d-4802-ab4b-c82f8d9ff6e4@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
 <fkEB2yc_f0R5YoueQPKmJriw73IshFeWo8f2s-bnEE4=.2e5d4596-2c0d-4802-ab4b-c82f8d9ff6e4@github.com>
Message-ID: <zGFbUd_JMXA3dbbCcX6g7BDH5ALw7XjbWrGV9OjxsvI=.211169eb-af78-4376-97e7-eeaa9dd1b4ef@github.com>

On Tue, 23 Mar 2021 01:03:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>> 
>> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
>> 
>> Testing:
>> mach5 tier1
>> New AutoStop test verifies the specified cleanup behavior.
>> (There are existing tests involving Timer.cancel.)
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make ThreadReaper constructor non-public

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3106

From vkempik at openjdk.java.net  Tue Mar 23 13:47:49 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 23 Mar 2021 13:47:49 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <VELjoQXnn9AqZJ5xS5fBeZITIpOuJ7_AyRr7Vxl5m0I=.8ec3a1cd-6af2-4bb7-9c43-2fa4a1474a24@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <ee0H_EQKtLdriO2ohEbSJTCgQLo6pkpNrM4q8gZkq1M=.6a33a0af-4134-4216-97fd-188bbfb7124b@github.com>
 <VELjoQXnn9AqZJ5xS5fBeZITIpOuJ7_AyRr7Vxl5m0I=.8ec3a1cd-6af2-4bb7-9c43-2fa4a1474a24@github.com>
Message-ID: <T87R9g8k9sUgph0vNreusY9OU1KJ438OoWvqz75qNfY=.05d35de2-8566-4f10-8780-86e79bbce005@github.com>

On Tue, 23 Mar 2021 13:26:19 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Build changes still look good. Hope you can get this done now! :)
>
>> > No, no, no! I am not suggesting you change anything else, just that
>> > you do not define contentless macros. You might as well define it
>> > to be something, and true is a reasonable default, that's all. It's
>> > not terribly important, it's just good practice.
>> 
>> I'm quite prepared to drop this if it's holding up the port. It's a style thing, but it's not critical.
> 
> Sorry, I missed your reply.
> 
> R18_RESERVED is also defined in https://github.com/openjdk/jdk/blob/master/make/hotspot/gensrc/GensrcAdlc.gmk#L96. I think changing the value here and there would be slightly out of the scope of this PR, so I would prefer to avoid the suggested change. 
> 
> The biggest argument from my side is that the current macro value is consistent with the rest of the macros in this file. For example https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L35
> and https://github.com/openjdk/jdk/blob/b7b391b2ac4208eabdee4e93acd5b0e364953f94/src/hotspot/share/runtime/mutexLocker.cpp#L137
> 
> But https://github.com/openjdk/jdk/blob/8c1ab38ee20ed61fefbb64b6a9ee605c52d2cb4e/src/hotspot/cpu/aarch64/globalDefinitions_aarch64.hpp#L59
> and       
> https://github.com/openjdk/jdk/blob/b23228d152ff8fa27bd32d9ef1307bf315039dea/src/hotspot/share/runtime/arguments.cpp#L1540

Hello
That depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.

> 23 ????? 2021 ?., ? 16:39, drej1 ***@***.***> ???????(?):
> 
> 
> So, where are we up to now? Are we done yet?
> 
> Hello
> we would like to get approval for the final version we have now and then integrate this pr as soon as Mark will target it to jdk17
> 
> Hi there, will this be also supported backwards? To support java11 LTS version?
> 
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://github.com/openjdk/jdk/pull/2200#issuecomment-804910300>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQS2KRC6LT7BKA37RMS5I5DTFCKX7ANCNFSM4WO4SQXQ>.
>

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From aph at openjdk.java.net  Tue Mar 23 13:56:59 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 13:56:59 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by aph (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From aph at openjdk.java.net  Tue Mar 23 14:00:58 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 14:00:58 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>
Message-ID: <EV4vZgtlo7uhG-pv-x40pOoE9_JNS_4sm1q-xtA1x2w=.4e7eb6ea-fefb-452c-b127-dc478c629eaa@github.com>

On Tue, 23 Mar 2021 13:54:24 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Marked as reviewed by aph (Reviewer).

> [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.

To the extent that 11u has fixed policies :)  we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From vkempik at openjdk.java.net  Tue Mar 23 14:03:52 2021
From: vkempik at openjdk.java.net (Vladimir Kempik)
Date: Tue, 23 Mar 2021 14:03:52 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <EV4vZgtlo7uhG-pv-x40pOoE9_JNS_4sm1q-xtA1x2w=.4e7eb6ea-fefb-452c-b127-dc478c629eaa@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>
 <EV4vZgtlo7uhG-pv-x40pOoE9_JNS_4sm1q-xtA1x2w=.4e7eb6ea-fefb-452c-b127-dc478c629eaa@github.com>
Message-ID: <sEsT_ZQ0CBgs8Xc8h1NE32bgZ9SGwyIZ2o8Jl8Hx5cY=.3febcdec-8b29-457a-82fa-123c2a98c328@github.com>

On Tue, 23 Mar 2021 13:58:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
> 
> To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.

@lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From info at j-kuhn.de  Tue Mar 23 14:08:37 2021
From: info at j-kuhn.de (Johannes Kuhn)
Date: Tue, 23 Mar 2021 15:08:37 +0100
Subject: Looking for a starter task. Maybe JDK-8253396 (Please add `not()`
 method to `java.util.function.BiPredicate`)?
In-Reply-To: <CAF807Oe4UjShjBToVqudr_=W96NOWcPE8MU3VvPTZsznzfEXyQ@mail.gmail.com>
References: <CAF807Oe4UjShjBToVqudr_=W96NOWcPE8MU3VvPTZsznzfEXyQ@mail.gmail.com>
Message-ID: <ae154bed-37d1-c836-78d0-2a276f1f9dca@j-kuhn.de>

Hi and welcome.

I would not consider JDK-8253396 (Please add `not()` method to 
`java.util.function.BiPredicate`) a good starter bug.

Generally, any bug that tries to add new APIs are hard, and require a 
lot of time and effort.

While the implementation of java.util.function.BiPredicate.not() is 
probably trivial, doing this task requires much more work:

* There should be some discussion if this feature is needed - this 
mailing list is the right place for that.
* The method needs a well written specification, in form of a javadoc 
comment.
* Tests need to be written to ensure conformance with the specification.

This is my current understanding on how to add new APIs. If I am wrong, 
please correct me.

I would not recommend adding a new API as a starter bug. From my limited 
experience, great starter bugs are bugs where the wrong exception is 
thrown - they are easy to fix, but still require you to write additional 
tests.

But if you find a sponsor who helps you implement JDK-8253396, then go 
for it.

- Johannes


On 20-Mar-21 7:31, Suren Nihalani wrote:
> Hi,
> 
> I am new openjdk (I've been using java for 7 years but I am new to
> contributing to openjdk!). I was looking for interesting starter tasks to
> help out with. JDK-8253396 looked like an easy to implement candidate. I am
> open to other suggestions too (feel free to little r as well)!
> 
> The contribution guide suggested I socialize my change before I code it up.
> Seems like the implementation would be straightforward and similar to
> Predicate.java. Are folks okay with this change?
> 
> Thanks for looking into this!
> 

From mbeckwit at openjdk.java.net  Tue Mar 23 14:27:53 2021
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Tue, 23 Mar 2021 14:27:53 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <sEsT_ZQ0CBgs8Xc8h1NE32bgZ9SGwyIZ2o8Jl8Hx5cY=.3febcdec-8b29-457a-82fa-123c2a98c328@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RJPhWu2ZJPvYw-KPhSNjl-pzzrgjplu6BKzBIqaaydc=.c94c5bac-4490-4b86-a619-2e53253abdce@github.com>
 <EV4vZgtlo7uhG-pv-x40pOoE9_JNS_4sm1q-xtA1x2w=.4e7eb6ea-fefb-452c-b127-dc478c629eaa@github.com>
 <sEsT_ZQ0CBgs8Xc8h1NE32bgZ9SGwyIZ2o8Jl8Hx5cY=.3febcdec-8b29-457a-82fa-123c2a98c328@github.com>
Message-ID: <yPvOw_97zvTpNmDvNRx0B8qqBIoqlnbJY5erdMrSTog=.0be084ee-92cd-4466-9120-9079aa5d9db3@github.com>

On Tue, 23 Mar 2021 14:01:12 GMT, Vladimir Kempik <vkempik at openjdk.org> wrote:

> > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
> > 
> > 
> > To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.
> 
> @lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)

Thanks, @theRealAph, and @VladimirKempik . We are on it!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From mbeckwit at openjdk.java.net  Tue Mar 23 15:27:56 2021
From: mbeckwit at openjdk.java.net (Monica Beckwith)
Date: Tue, 23 Mar 2021 15:27:56 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <8y8WYVmVF_qrroxDo516Ucz1qWX5kMpPQHeqZgJNI2Q=.004fe86c-2b18-4a90-8499-1a34e64da3db@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by mbeckwit (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From bpb at openjdk.java.net  Tue Mar 23 16:09:40 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 23 Mar 2021 16:09:40 GMT
Subject: Integrated: 8251942: PrintStream specification is not clear which
 flush method is automatically invoked
In-Reply-To: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>
References: <YXHitqCVp1B36aweOGYaJVLbR_SVgKfGHNLBKqm6Uqs=.14b7bf86-a6df-4159-a513-5d23228fe278@github.com>
Message-ID: <76mF5GZt7Tejv5RCtoJfEZnpr2prJmKXrproe9tDUmE=.cb444834-6860-4be0-98b3-57ca6d570e29@github.com>

On Wed, 10 Mar 2021 23:03:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this minor change to the specification of `java.io.PrintStream`. The longstanding behavior for flushing is to invoke the `flush()` method of the underlying `OutputStream` rather than its override but this was not made explicit in the specification.

This pull request has now been integrated.

Changeset: d7268fa3
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d7268fa3
Stats:     9 lines in 1 file changed: 1 ins; 0 del; 8 mod

8251942: PrintStream specification is not clear which flush method is automatically invoked

Reviewed-by: dfuchs, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/2926

From luhenry at openjdk.java.net  Tue Mar 23 16:23:54 2021
From: luhenry at openjdk.java.net (Ludovic Henry)
Date: Tue, 23 Mar 2021 16:23:54 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
Message-ID: <RIXlvES_OOQ47-4YI1CLX7kLG4JJ70NRr0g0G0X6zb0=.4a106aa2-8e76-4b5a-9206-cebc6f17472e@github.com>

On Mon, 22 Mar 2021 12:50:14 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

>> Please review the implementation of JEP 391: macOS/AArch64 Port.
>> 
>> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
>> 
>> Major changes are in:
>> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
>> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
>> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
>> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)
>
> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
> 
>  - Merge branch 'master' into jdk-macos
>  - JDK-8262491: bsd_aarch64 part
>  - JDK-8263002: bsd_aarch64 part
>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>  - Wider #ifdef block
>  - Fix most of issues in java/foreign/ tests
>    
>    Failures related to va_args are tracked in JDK-8263512.
>  - Add Azul copyright
>  - Update Oracle copyright years
>  - Use Thread::current_or_null_safe in SafeFetch
>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269

Marked as reviewed by luhenry (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From aph at openjdk.java.net  Tue Mar 23 16:36:55 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Tue, 23 Mar 2021 16:36:55 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <RIXlvES_OOQ47-4YI1CLX7kLG4JJ70NRr0g0G0X6zb0=.4a106aa2-8e76-4b5a-9206-cebc6f17472e@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RIXlvES_OOQ47-4YI1CLX7kLG4JJ70NRr0g0G0X6zb0=.4a106aa2-8e76-4b5a-9206-cebc6f17472e@github.com>
Message-ID: <HVuUWfsnr8fqATnVU2b4S7VdSOwuKg1xxEZW-islB2g=.56d118c4-745d-4371-91a9-3bb250c9b7a3@github.com>

On Tue, 23 Mar 2021 16:20:47 GMT, Ludovic Henry <luhenry at openjdk.org> wrote:

>> Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 115 commits:
>> 
>>  - Merge branch 'master' into jdk-macos
>>  - JDK-8262491: bsd_aarch64 part
>>  - JDK-8263002: bsd_aarch64 part
>>  - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
>>  - Wider #ifdef block
>>  - Fix most of issues in java/foreign/ tests
>>    
>>    Failures related to va_args are tracked in JDK-8263512.
>>  - Add Azul copyright
>>  - Update Oracle copyright years
>>  - Use Thread::current_or_null_safe in SafeFetch
>>  - 8262903: [macos_aarch64] Thread::current() called on detached thread
>>  - ... and 105 more: https://git.openjdk.java.net/jdk/compare/a9d2267f...5add9269
>
> Marked as reviewed by luhenry (Author).

> > > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
> > > 
> > > 
> > > To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.
> > 
> > 
> > @lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)
> 
> Thanks, @theRealAph, and @VladimirKempik . We are on it!

It's going to be tricky to do in a really clean way, given some of the weirdnesses of the ABI. However, I think there's probably a need for it

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From herrick at openjdk.java.net  Tue Mar 23 17:17:00 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 23 Mar 2021 17:17:00 GMT
Subject: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with
 additional attribution.
Message-ID: <vZ7AszKiC69h_mtowQ2nfd6u3-ByLt0pR1Z4LiKVvtM=.f90e8fd0-2df6-474d-9327-b0c70bdd6d04@github.com>

We are backing out the fix to "JDK-8248904 Add support to jpackage for the Mac App Store " in order to resubmit with added contributor attribution for Erwin Morrhey
This is the backout.

-------------

Commit messages:
 - JDK-8264055: backout JDK-8248904 in order to resubmit with additional attribution.

Changes: https://git.openjdk.java.net/jdk/pull/3159/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3159&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264055
  Stats: 310 lines in 22 files changed: 41 ins; 205 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3159.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3159/head:pull/3159

PR: https://git.openjdk.java.net/jdk/pull/3159

From joehw at openjdk.java.net  Tue Mar 23 17:21:40 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Tue, 23 Mar 2021 17:21:40 GMT
Subject: RFR: 8264019: Use the blessed modifier order in java.xml
In-Reply-To: <_Dm04Xn2Cu3JjRuNfDKIFjWx2jQJQmwiFX0S6yGDKT8=.4433aa36-e3a3-42d7-8eb7-e0062d4ee602@github.com>
References: <pyRUfAzGFBDQxvfpjDhK-32rwGuuXBEDQyYXTP9LDY8=.413db9c7-3090-4d70-a3ef-0e1409a16e56@github.com>
 <53tEGZbggxrU6PJ-QYK6_lBMIMZt3CbZ_31P7hKBzJ0=.c8ff1420-84a5-4cab-98ab-b1d5dd8757bf@github.com>
 <Jc0cZp57oOE5qrEfWcrG_Nemw1dzAajboLXMNd3EDLg=.ddd22a8a-7a0f-4320-a6a3-30d158123776@github.com>
 <0DzFRjrn4hDo6jI7uJiMpyAsgjRn0ro5ydcl-86wZOo=.a6b0d388-5e4a-42ef-b9c9-4bd6f07019d7@github.com>
 <_Dm04Xn2Cu3JjRuNfDKIFjWx2jQJQmwiFX0S6yGDKT8=.4433aa36-e3a3-42d7-8eb7-e0062d4ee602@github.com>
Message-ID: <Je7cMYqFagLtuSgEk7KFAppSQ9GarNKZ0Y9uMB2rybo=.fb7cf98e-cf00-4ade-ac2a-690632f17819@github.com>

On Tue, 23 Mar 2021 07:24:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Sure, here it is: https://bugs.openjdk.java.net/browse/JDK-8264019
>
> The JDK's copy of the xalan and xerces code has diverged significantly from upstream so maybe this change is okay, Joe Wang can say.

Hi Alex,  thanks for looking into this. As Alan mentioned, these code came from Apache, while we've made changes, we refrained from making minor ones (code style, format and etc.) as it would add unnecessary burden for future merges. I'd prefer not taking the changes to the source files that came from Apache. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3091

From mchung at openjdk.java.net  Tue Mar 23 17:48:50 2021
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 23 Mar 2021 17:48:50 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread [v3]
In-Reply-To: <fkEB2yc_f0R5YoueQPKmJriw73IshFeWo8f2s-bnEE4=.2e5d4596-2c0d-4802-ab4b-c82f8d9ff6e4@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
 <fkEB2yc_f0R5YoueQPKmJriw73IshFeWo8f2s-bnEE4=.2e5d4596-2c0d-4802-ab4b-c82f8d9ff6e4@github.com>
Message-ID: <5exLasvXiWQL6Ko42xXXnkEqSkt2Q7ueR62jSlymH4I=.86b036e4-9ae0-467f-9919-4e07096b22fe@github.com>

On Tue, 23 Mar 2021 01:03:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>> 
>> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
>> 
>> Testing:
>> mach5 tier1
>> New AutoStop test verifies the specified cleanup behavior.
>> (There are existing tests involving Timer.cancel.)
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make ThreadReaper constructor non-public

Looks good.  Glad to more use of finalization being removed.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3106

From kcr at openjdk.java.net  Tue Mar 23 17:58:40 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 23 Mar 2021 17:58:40 GMT
Subject: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with
 additional attribution.
In-Reply-To: <vZ7AszKiC69h_mtowQ2nfd6u3-ByLt0pR1Z4LiKVvtM=.f90e8fd0-2df6-474d-9327-b0c70bdd6d04@github.com>
References: <vZ7AszKiC69h_mtowQ2nfd6u3-ByLt0pR1Z4LiKVvtM=.f90e8fd0-2df6-474d-9327-b0c70bdd6d04@github.com>
Message-ID: <n-Cky_Pp3swrowLNAvaW4TuZ9CQBVZU4jjPlAlLBva4=.0eaeecfc-e0cb-4492-8c46-c66e46da17eb@github.com>

On Tue, 23 Mar 2021 17:09:20 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> We are backing out the fix to "JDK-8248904 Add support to jpackage for the Mac App Store " in order to resubmit with added contributor attribution for Erwin Morrhey
> This is the backout.

Looks good, although i see the following wasn't backed out:

src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/JavaApp.icns

If this is intentional, then no need to worry about it.

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/3159

From herrick at openjdk.java.net  Tue Mar 23 18:19:38 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 23 Mar 2021 18:19:38 GMT
Subject: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with
 additional attribution.
In-Reply-To: <n-Cky_Pp3swrowLNAvaW4TuZ9CQBVZU4jjPlAlLBva4=.0eaeecfc-e0cb-4492-8c46-c66e46da17eb@github.com>
References: <vZ7AszKiC69h_mtowQ2nfd6u3-ByLt0pR1Z4LiKVvtM=.f90e8fd0-2df6-474d-9327-b0c70bdd6d04@github.com>
 <n-Cky_Pp3swrowLNAvaW4TuZ9CQBVZU4jjPlAlLBva4=.0eaeecfc-e0cb-4492-8c46-c66e46da17eb@github.com>
Message-ID: <3QpAQEevXZPLgLvnNt0VSjKpR6v6ZT4IDwZu_n0i9I0=.329f342c-0586-41b8-9ada-6e74dc1623d6@github.com>

On Tue, 23 Mar 2021 17:55:24 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

> Looks good, although i see the following wasn't backed out:
> 
> ```
> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/JavaApp.icns
> ```

yes - look again - it was renamed back to java.icns (the 12'th or 22 files changed above)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3159

From github.com+76791+alblue at openjdk.java.net  Tue Mar 23 18:20:41 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Tue, 23 Mar 2021 18:20:41 GMT
Subject: RFR: 8264019: Use the blessed modifier order in java.xml
In-Reply-To: <Je7cMYqFagLtuSgEk7KFAppSQ9GarNKZ0Y9uMB2rybo=.fb7cf98e-cf00-4ade-ac2a-690632f17819@github.com>
References: <pyRUfAzGFBDQxvfpjDhK-32rwGuuXBEDQyYXTP9LDY8=.413db9c7-3090-4d70-a3ef-0e1409a16e56@github.com>
 <53tEGZbggxrU6PJ-QYK6_lBMIMZt3CbZ_31P7hKBzJ0=.c8ff1420-84a5-4cab-98ab-b1d5dd8757bf@github.com>
 <Jc0cZp57oOE5qrEfWcrG_Nemw1dzAajboLXMNd3EDLg=.ddd22a8a-7a0f-4320-a6a3-30d158123776@github.com>
 <0DzFRjrn4hDo6jI7uJiMpyAsgjRn0ro5ydcl-86wZOo=.a6b0d388-5e4a-42ef-b9c9-4bd6f07019d7@github.com>
 <_Dm04Xn2Cu3JjRuNfDKIFjWx2jQJQmwiFX0S6yGDKT8=.4433aa36-e3a3-42d7-8eb7-e0062d4ee602@github.com>
 <Je7cMYqFagLtuSgEk7KFAppSQ9GarNKZ0Y9uMB2rybo=.fb7cf98e-cf00-4ade-ac2a-690632f17819@github.com>
Message-ID: <CLOjRNIcpBYTOQgv5VImYanv-kBpKk-F39-MwxItVb8=.1c096de2-7a4a-4a9f-a82e-f1acf52d998d@github.com>

On Tue, 23 Mar 2021 17:19:10 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> The JDK's copy of the xalan and xerces code has diverged significantly from upstream so maybe this change is okay, Joe Wang can say.
>
> Hi Alex,  thanks for looking into this. As Alan mentioned, these code came from Apache, while we've made changes, we refrained from making minor ones (code style, format and etc.) as it would add unnecessary burden for future merges. I'd prefer not taking the changes to the source files that came from Apache. Thanks.

OK, will abandon it. If someone could close the associated bug that would be appreciated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3091

From github.com+76791+alblue at openjdk.java.net  Tue Mar 23 18:20:42 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Tue, 23 Mar 2021 18:20:42 GMT
Subject: Withdrawn: 8264019: Use the blessed modifier order in java.xml
In-Reply-To: <pyRUfAzGFBDQxvfpjDhK-32rwGuuXBEDQyYXTP9LDY8=.413db9c7-3090-4d70-a3ef-0e1409a16e56@github.com>
References: <pyRUfAzGFBDQxvfpjDhK-32rwGuuXBEDQyYXTP9LDY8=.413db9c7-3090-4d70-a3ef-0e1409a16e56@github.com>
Message-ID: <ZNTOzQdTTemU5ZL_8Vk6z6CDvNsrf7jmTdAKnDid23M=.c17d7085-9269-4e70-a960-82a2edf62251@github.com>

On Fri, 19 Mar 2021 16:17:40 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> As a subtask of JDK-8263854 this cleans up the `java.xml` module to used the blessed modifier order.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3091

From bchristi at openjdk.java.net  Tue Mar 23 18:39:40 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Tue, 23 Mar 2021 18:39:40 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread [v3]
In-Reply-To: <fkEB2yc_f0R5YoueQPKmJriw73IshFeWo8f2s-bnEE4=.2e5d4596-2c0d-4802-ab4b-c82f8d9ff6e4@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
 <fkEB2yc_f0R5YoueQPKmJriw73IshFeWo8f2s-bnEE4=.2e5d4596-2c0d-4802-ab4b-c82f8d9ff6e4@github.com>
Message-ID: <BTrUsgn7fLfZx-lN_BDEw5RQxC7j1GVutF1ezil4TUo=.139a6239-2e44-4848-a456-e1b69b509be1@github.com>

On Tue, 23 Mar 2021 01:03:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
>> 
>> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
>> 
>> Testing:
>> mach5 tier1
>> New AutoStop test verifies the specified cleanup behavior.
>> (There are existing tests involving Timer.cancel.)
>
> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
> 
>   make ThreadReaper constructor non-public

Marked as reviewed by bchristi (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3106

From kcr at openjdk.java.net  Tue Mar 23 19:43:41 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 23 Mar 2021 19:43:41 GMT
Subject: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with
 additional attribution.
In-Reply-To: <3QpAQEevXZPLgLvnNt0VSjKpR6v6ZT4IDwZu_n0i9I0=.329f342c-0586-41b8-9ada-6e74dc1623d6@github.com>
References: <vZ7AszKiC69h_mtowQ2nfd6u3-ByLt0pR1Z4LiKVvtM=.f90e8fd0-2df6-474d-9327-b0c70bdd6d04@github.com>
 <n-Cky_Pp3swrowLNAvaW4TuZ9CQBVZU4jjPlAlLBva4=.0eaeecfc-e0cb-4492-8c46-c66e46da17eb@github.com>
 <3QpAQEevXZPLgLvnNt0VSjKpR6v6ZT4IDwZu_n0i9I0=.329f342c-0586-41b8-9ada-6e74dc1623d6@github.com>
Message-ID: <ZwzGu8MIe9WPUv3aMVzUmLEOYkXprpsEYqkNi4leeZY=.614df4ee-89a1-44ac-b9ba-0ec0c9d03484@github.com>

On Tue, 23 Mar 2021 18:17:00 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> Looks good, although i see the following wasn't backed out:
>> 
>> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/JavaApp.icns
>> 
>> If this is intentional, then no need to worry about it.
>
>> Looks good, although i see the following wasn't backed out:
>> 
>> ```
>> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/JavaApp.icns
>> ```
> 
> yes - look again - it was renamed back to java.icns (the 12'th or 22 files changed above)

As long as there are no transient build/test failures, it will be fine. I was just comparing the results with what `git revert 11c8c78c47f21fcd87a5969a859b5c4fced5e47d` generated and noticed this difference.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3159

From vdyakov at openjdk.java.net  Tue Mar 23 20:46:40 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Tue, 23 Mar 2021 20:46:40 GMT
Subject: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with
 additional attribution.
In-Reply-To: <ZwzGu8MIe9WPUv3aMVzUmLEOYkXprpsEYqkNi4leeZY=.614df4ee-89a1-44ac-b9ba-0ec0c9d03484@github.com>
References: <vZ7AszKiC69h_mtowQ2nfd6u3-ByLt0pR1Z4LiKVvtM=.f90e8fd0-2df6-474d-9327-b0c70bdd6d04@github.com>
 <n-Cky_Pp3swrowLNAvaW4TuZ9CQBVZU4jjPlAlLBva4=.0eaeecfc-e0cb-4492-8c46-c66e46da17eb@github.com>
 <3QpAQEevXZPLgLvnNt0VSjKpR6v6ZT4IDwZu_n0i9I0=.329f342c-0586-41b8-9ada-6e74dc1623d6@github.com>
 <ZwzGu8MIe9WPUv3aMVzUmLEOYkXprpsEYqkNi4leeZY=.614df4ee-89a1-44ac-b9ba-0ec0c9d03484@github.com>
Message-ID: <eofM8LhXGHGt_s-yXC2EdE6-cxgFxYwCeSEeEIrqMNc=.a541c2d8-85c4-472a-9581-ace7c14637ef@github.com>

On Tue, 23 Mar 2021 19:40:38 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>>> Looks good, although i see the following wasn't backed out:
>>> 
>>> ```
>>> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/JavaApp.icns
>>> ```
>> 
>> yes - look again - it was renamed back to java.icns (the 12'th or 22 files changed above)
>
> As long as there are no transient build/test failures, it will be fine. I was just comparing the results with what `git revert 11c8c78c47f21fcd87a5969a859b5c4fced5e47d` generated and noticed this difference.

@sashamatveev please review

-------------

PR: https://git.openjdk.java.net/jdk/pull/3159

From vdyakov at openjdk.java.net  Tue Mar 23 20:46:41 2021
From: vdyakov at openjdk.java.net (Victor Dyakov)
Date: Tue, 23 Mar 2021 20:46:41 GMT
Subject: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with
 additional attribution.
In-Reply-To: <eofM8LhXGHGt_s-yXC2EdE6-cxgFxYwCeSEeEIrqMNc=.a541c2d8-85c4-472a-9581-ace7c14637ef@github.com>
References: <vZ7AszKiC69h_mtowQ2nfd6u3-ByLt0pR1Z4LiKVvtM=.f90e8fd0-2df6-474d-9327-b0c70bdd6d04@github.com>
 <n-Cky_Pp3swrowLNAvaW4TuZ9CQBVZU4jjPlAlLBva4=.0eaeecfc-e0cb-4492-8c46-c66e46da17eb@github.com>
 <3QpAQEevXZPLgLvnNt0VSjKpR6v6ZT4IDwZu_n0i9I0=.329f342c-0586-41b8-9ada-6e74dc1623d6@github.com>
 <ZwzGu8MIe9WPUv3aMVzUmLEOYkXprpsEYqkNi4leeZY=.614df4ee-89a1-44ac-b9ba-0ec0c9d03484@github.com>
 <eofM8LhXGHGt_s-yXC2EdE6-cxgFxYwCeSEeEIrqMNc=.a541c2d8-85c4-472a-9581-ace7c14637ef@github.com>
Message-ID: <NkYPBkQXs_jOzkSV1Wj3fYh8pWdLd3ImqXRMw8EkTz0=.9828ec06-894f-4ac7-bdda-213b6673c65b@github.com>

On Tue, 23 Mar 2021 20:42:22 GMT, Victor Dyakov <vdyakov at openjdk.org> wrote:

>> As long as there are no transient build/test failures, it will be fine. I was just comparing the results with what `git revert 11c8c78c47f21fcd87a5969a859b5c4fced5e47d` generated and noticed this difference.
>
> @sashamatveev please review

@alexeysemenyukoracle please review

-------------

PR: https://git.openjdk.java.net/jdk/pull/3159

From github.com+741251+turbanoff at openjdk.java.net  Tue Mar 23 20:49:46 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Tue, 23 Mar 2021 20:49:46 GMT
Subject: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in
 java.base
In-Reply-To: <yNg9GtLV_kyvs_xdWSxdjOYAiC2Awa7PZQCG-L_AwA8=.b20ca7ba-fd49-46cf-bd61-c2db366cdff5@github.com>
References: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com>
 <yNg9GtLV_kyvs_xdWSxdjOYAiC2Awa7PZQCG-L_AwA8=.b20ca7ba-fd49-46cf-bd61-c2db366cdff5@github.com>
Message-ID: <gfqT-B96j8Wl-Jd6txZhV8xuLKjJz11PxgorIVJ9BG4=.d5a5e9aa-8632-43ba-a6cf-45d69eba67d9@github.com>

On Tue, 23 Mar 2021 12:38:06 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
>> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.base`
>> Similar cleanup in the past - https://bugs.openjdk.java.net/browse/JDK-8041679
>
> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1954:
> 
>> 1952:             for (int i = 0; i < 4; ++i) {
>> 1953:                 if (i > 0) {
>> 1954:                     sb.append("       ");
> 
> Consider using `String.repeat` here and on L1960 for clarity.

I'm not sure how String.repeat can be used here. Repeated String is not constant and different for each iteration.

> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1954:
> 
>> 1952:             for (int i = 0; i < 4; ++i) {
>> 1953:                 if (i > 0) {
>> 1954:                     sb.append("       ");
> 
> Consider using `String.repeat` here and on L1960 for clarity.

I don't think it can be used here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2922

From kbarrett at openjdk.java.net  Tue Mar 23 20:59:41 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 23 Mar 2021 20:59:41 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread [v3]
In-Reply-To: <BTrUsgn7fLfZx-lN_BDEw5RQxC7j1GVutF1ezil4TUo=.139a6239-2e44-4848-a456-e1b69b509be1@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
 <fkEB2yc_f0R5YoueQPKmJriw73IshFeWo8f2s-bnEE4=.2e5d4596-2c0d-4802-ab4b-c82f8d9ff6e4@github.com>
 <BTrUsgn7fLfZx-lN_BDEw5RQxC7j1GVutF1ezil4TUo=.139a6239-2e44-4848-a456-e1b69b509be1@github.com>
Message-ID: <l9QD3mNhSrthyMCfiAlYOYVqFrv1SAhO_v7DtzREalI=.e1f434dc-a2e1-4583-b2fa-4574d5085551@github.com>

On Tue, 23 Mar 2021 18:36:24 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   make ThreadReaper constructor non-public
>
> Marked as reviewed by bchristi (Reviewer).

Thanks all for reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3106

From kbarrett at openjdk.java.net  Tue Mar 23 21:14:02 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 23 Mar 2021 21:14:02 GMT
Subject: RFR: 8263903: Use Cleaner instead of finalize to auto stop Timer
 thread [v4]
In-Reply-To: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
Message-ID: <7I8a7gyjCU0YHZPtnNrBqKRDHzYgPmDsmxlUJHR1N4U=.4428d9d2-4cca-4fff-ae71-d9547d897540@github.com>

> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
> 
> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
> 
> Testing:
> mach5 tier1
> New AutoStop test verifies the specified cleanup behavior.
> (There are existing tests involving Timer.cancel.)

Kim Barrett has updated the pull request with a new target base 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 nofinalize
 - make ThreadReaper constructor non-public
 - dholmes review
 - Use cleaner instead of finalize to auto stop Timer thread

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3106/files
  - new: https://git.openjdk.java.net/jdk/pull/3106/files/57500464..f62aa2f0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3106&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3106&range=02-03

  Stats: 2955 lines in 191 files changed: 1549 ins; 748 del; 658 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3106.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3106/head:pull/3106

PR: https://git.openjdk.java.net/jdk/pull/3106

From kbarrett at openjdk.java.net  Tue Mar 23 21:19:40 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 23 Mar 2021 21:19:40 GMT
Subject: Integrated: 8263903: Use Cleaner instead of finalize to auto stop
 Timer thread
In-Reply-To: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
References: <wP25_Mz4Fp7x1zWwtutqH8ObNzxQ74T-iaOKp065Y5Q=.29306e64-406f-439e-8bf4-3f76976461a1@github.com>
Message-ID: <xjByYBUTTS5yJ2NCqyR4kUV-B2z8qYwmL0yHICFsLqs=.edb697b2-dc86-49a5-866b-83eda673f1d1@github.com>

On Sun, 21 Mar 2021 03:53:24 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to java.util.Timer, replacing the use of deprecated finalization-based cleanup with use of java.lang.ref.Cleaner.
> 
> In addition, Timer.cancel now cancels any later execution of the the no longer relevant cleanup.
> 
> Testing:
> mach5 tier1
> New AutoStop test verifies the specified cleanup behavior.
> (There are existing tests involving Timer.cancel.)

This pull request has now been integrated.

Changeset: 2425462a
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2425462a
Stats:     111 lines in 2 files changed: 97 ins; 3 del; 11 mod

8263903: Use Cleaner instead of finalize to auto stop Timer thread

Reviewed-by: dholmes, alanb, bchristi, rriggs, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/3106

From asemenyuk at openjdk.java.net  Tue Mar 23 21:35:39 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 23 Mar 2021 21:35:39 GMT
Subject: RFR: JDK-8264055: backout JDK-8248904 in order to resubmit with
 additional attribution.
In-Reply-To: <vZ7AszKiC69h_mtowQ2nfd6u3-ByLt0pR1Z4LiKVvtM=.f90e8fd0-2df6-474d-9327-b0c70bdd6d04@github.com>
References: <vZ7AszKiC69h_mtowQ2nfd6u3-ByLt0pR1Z4LiKVvtM=.f90e8fd0-2df6-474d-9327-b0c70bdd6d04@github.com>
Message-ID: <mJku618rY2saMzFYSzLyPhOaRkBE111sgCNm8JROitQ=.75c249c1-9916-464a-88fb-3dabf51375e1@github.com>

On Tue, 23 Mar 2021 17:09:20 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> We are backing out the fix to "JDK-8248904 Add support to jpackage for the Mac App Store " in order to resubmit with added contributor attribution for Erwin Morrhey
> This is the backout.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3159

From github.com+76791+alblue at openjdk.java.net  Tue Mar 23 21:47:47 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Tue, 23 Mar 2021 21:47:47 GMT
Subject: RFR: 8264091: Use the blessed modifier order in java.logging
Message-ID: <gRegnUXDSo4HfLMVVAvkTT2tlShhypJh5Y8a2fRYjGQ=.24cc626e-b531-4aff-9230-9b5163b09925@github.com>

8264091: Use the blessed modifier order in java.logging

-------------

Commit messages:
 - 8264091: Use the blessed modifier order in java.logging

Changes: https://git.openjdk.java.net/jdk/pull/3163/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3163&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264091
  Stats: 10 lines in 3 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3163.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3163/head:pull/3163

PR: https://git.openjdk.java.net/jdk/pull/3163

From herrick at openjdk.java.net  Tue Mar 23 21:48:41 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 23 Mar 2021 21:48:41 GMT
Subject: Integrated: JDK-8264055: backout JDK-8248904 in order to resubmit
 with additional attribution.
In-Reply-To: <vZ7AszKiC69h_mtowQ2nfd6u3-ByLt0pR1Z4LiKVvtM=.f90e8fd0-2df6-474d-9327-b0c70bdd6d04@github.com>
References: <vZ7AszKiC69h_mtowQ2nfd6u3-ByLt0pR1Z4LiKVvtM=.f90e8fd0-2df6-474d-9327-b0c70bdd6d04@github.com>
Message-ID: <PayBptRTyvjIzyDKgc9utYJ4yETCUKNbUXV5udkc9YU=.ce6668a7-aec0-4626-a12a-dfd552aa4dc8@github.com>

On Tue, 23 Mar 2021 17:09:20 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> We are backing out the fix to "JDK-8248904 Add support to jpackage for the Mac App Store " in order to resubmit with added contributor attribution for Erwin Morrhey
> This is the backout.

This pull request has now been integrated.

Changeset: 15bcf6d9
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/15bcf6d9
Stats:     310 lines in 22 files changed: 41 ins; 205 del; 64 mod

8264055: backout JDK-8248904 in order to resubmit with additional attribution.

Reviewed-by: kcr, asemenyuk

-------------

PR: https://git.openjdk.java.net/jdk/pull/3159

From prappo at openjdk.java.net  Tue Mar 23 21:57:39 2021
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 23 Mar 2021 21:57:39 GMT
Subject: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in
 java.base
In-Reply-To: <gfqT-B96j8Wl-Jd6txZhV8xuLKjJz11PxgorIVJ9BG4=.d5a5e9aa-8632-43ba-a6cf-45d69eba67d9@github.com>
References: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com>
 <yNg9GtLV_kyvs_xdWSxdjOYAiC2Awa7PZQCG-L_AwA8=.b20ca7ba-fd49-46cf-bd61-c2db366cdff5@github.com>
 <gfqT-B96j8Wl-Jd6txZhV8xuLKjJz11PxgorIVJ9BG4=.d5a5e9aa-8632-43ba-a6cf-45d69eba67d9@github.com>
Message-ID: <gxM0BMtMo8hpXcC2yNZeyYYG5aVEJUQnnAKl_rRooMM=.c930bf8e-03df-47dd-b9c0-ef2acf929139@github.com>

On Tue, 23 Mar 2021 20:44:17 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 1954:
>> 
>>> 1952:             for (int i = 0; i < 4; ++i) {
>>> 1953:                 if (i > 0) {
>>> 1954:                     sb.append("       ");
>> 
>> Consider using `String.repeat` here and on L1960 for clarity.
>
> I'm not sure how String.repeat can be used here. Repeated String is not constant and different for each iteration.

Long runs of whitespace, especially in blank strings, may have poor readability. I was thinking that

" ".repeat(7) and " ".repeat(10)
 

might read better than 

"       " and "          "

respectively. If you don't agree, then simply disregard what I said. If you agree but worry about negative performance implications, consider creating these strings before the respective for-loops.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2922

From lancea at openjdk.java.net  Tue Mar 23 21:58:38 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 23 Mar 2021 21:58:38 GMT
Subject: RFR: 8264091: Use the blessed modifier order in java.logging
In-Reply-To: <gRegnUXDSo4HfLMVVAvkTT2tlShhypJh5Y8a2fRYjGQ=.24cc626e-b531-4aff-9230-9b5163b09925@github.com>
References: <gRegnUXDSo4HfLMVVAvkTT2tlShhypJh5Y8a2fRYjGQ=.24cc626e-b531-4aff-9230-9b5163b09925@github.com>
Message-ID: <LZDy4Qd2TqzzjlwjwUnNKbjGcmS4A-vYBUQf_RDdTzc=.67b61ca5-fd32-4900-aee0-fbc975f01f57@github.com>

On Tue, 23 Mar 2021 21:41:32 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264091: Use the blessed modifier order in java.logging

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3163

From iris at openjdk.java.net  Wed Mar 24 02:03:41 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Wed, 24 Mar 2021 02:03:41 GMT
Subject: RFR: 8264091: Use the blessed modifier order in java.logging
In-Reply-To: <gRegnUXDSo4HfLMVVAvkTT2tlShhypJh5Y8a2fRYjGQ=.24cc626e-b531-4aff-9230-9b5163b09925@github.com>
References: <gRegnUXDSo4HfLMVVAvkTT2tlShhypJh5Y8a2fRYjGQ=.24cc626e-b531-4aff-9230-9b5163b09925@github.com>
Message-ID: <_1i0bXEOnBOv98yoc90ZmUZABAU9I6ipCI7HhLs1su4=.d101029e-f7a4-4db0-ab3a-15f330ce3c90@github.com>

On Tue, 23 Mar 2021 21:41:32 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264091: Use the blessed modifier order in java.logging

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3163

From github.com+76791+alblue at openjdk.java.net  Wed Mar 24 06:52:39 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Wed, 24 Mar 2021 06:52:39 GMT
Subject: RFR: 8264091: Use the blessed modifier order in java.logging
In-Reply-To: <_1i0bXEOnBOv98yoc90ZmUZABAU9I6ipCI7HhLs1su4=.d101029e-f7a4-4db0-ab3a-15f330ce3c90@github.com>
References: <gRegnUXDSo4HfLMVVAvkTT2tlShhypJh5Y8a2fRYjGQ=.24cc626e-b531-4aff-9230-9b5163b09925@github.com>
 <_1i0bXEOnBOv98yoc90ZmUZABAU9I6ipCI7HhLs1su4=.d101029e-f7a4-4db0-ab3a-15f330ce3c90@github.com>
Message-ID: <19eEz_A06xrpW9bE096c2ytBGvd8YlrKP5Z3JSAEdJ0=.da090359-6638-4c25-9c1c-e5177c04b8fe@github.com>

On Wed, 24 Mar 2021 02:00:28 GMT, Iris Clark <iris at openjdk.org> wrote:

>> 8264091: Use the blessed modifier order in java.logging
>
> Marked as reviewed by iris (Reviewer).

> 
> On 24 Mar 2021, at 02:00, Iris Clark ***@***.***> wrote:
> 
> ?
> @irisclark approved this pull request.
> 
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or unsubscribe.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3163

From lzang at openjdk.java.net  Wed Mar 24 06:53:42 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Wed, 24 Mar 2021 06:53:42 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts,
 use of optional GZIP fields [v3]
In-Reply-To: <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
Message-ID: <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>

On Mon, 22 Mar 2021 21:37:27 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update copyright
>>  - reuse arguments constructor for non-argument one.
>
> Hi Lin,
>  
> Again, thank you for taking on this 19+ year feature request.
> 
> I have not done a deep dive on the CSR, but wanted to get a few comments back to you on a quick scan of the last PR update.
> 
> Personally, I would like to see more testing for a change such as this given the age of the code:
> 
> - Please do not modify the existing test, you can either create  a new test(s) or add tests to the existing test class
> - We should capture Gzip files with these headers set from other tools and store the Gzip in an array within the test which can then be written to disk so the tests can validate interoperability.  Please see some of the other Zip tests for an example
> - We should have tests that include some , but not all of the additional fields as I believe they are all optional according to the RFC.
> - Please include some negative tests
> 
> 
> I have also include some additional comments within the code

Hi Lance?
Thanks a lot for your review. I will update the PR ASAP. 
May I ask your help to also review the CSR? Thanks!

BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

From shade at openjdk.java.net  Wed Mar 24 07:24:40 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 24 Mar 2021 07:24:40 GMT
Subject: RFR: 8264091: Use the blessed modifier order in java.logging
In-Reply-To: <gRegnUXDSo4HfLMVVAvkTT2tlShhypJh5Y8a2fRYjGQ=.24cc626e-b531-4aff-9230-9b5163b09925@github.com>
References: <gRegnUXDSo4HfLMVVAvkTT2tlShhypJh5Y8a2fRYjGQ=.24cc626e-b531-4aff-9230-9b5163b09925@github.com>
Message-ID: <ZzehJ8RLW3cFFQO_6Xoh7817LdQV_xELmeIdanKlsL0=.07974920-3092-40ae-a762-5bf1bb48b340@github.com>

On Tue, 23 Mar 2021 21:41:32 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264091: Use the blessed modifier order in java.logging

Marked as reviewed by shade (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3163

From github.com+76791+alblue at openjdk.java.net  Wed Mar 24 07:28:38 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Wed, 24 Mar 2021 07:28:38 GMT
Subject: Integrated: 8264091: Use the blessed modifier order in java.logging
In-Reply-To: <gRegnUXDSo4HfLMVVAvkTT2tlShhypJh5Y8a2fRYjGQ=.24cc626e-b531-4aff-9230-9b5163b09925@github.com>
References: <gRegnUXDSo4HfLMVVAvkTT2tlShhypJh5Y8a2fRYjGQ=.24cc626e-b531-4aff-9230-9b5163b09925@github.com>
Message-ID: <r5jhr5VNkNKqxJgJmYZtiRy5L1sSDuP6qecY89Ei_-Q=.b7c4b630-b4d8-4a16-9244-8d8dc5221758@github.com>

On Tue, 23 Mar 2021 21:41:32 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264091: Use the blessed modifier order in java.logging

This pull request has now been integrated.

Changeset: 45e1bab8
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/45e1bab8
Stats:     10 lines in 3 files changed: 0 ins; 0 del; 10 mod

8264091: Use the blessed modifier order in java.logging

Reviewed-by: lancea, iris, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/3163

From pconcannon at openjdk.java.net  Wed Mar 24 10:01:40 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 24 Mar 2021 10:01:40 GMT
Subject: Integrated: 8263358: Update java.lang to use instanceof pattern
 variable
In-Reply-To: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
References: <-dyYVr8dcZapq9tBikh_b8porICw5D0zVirwDWgvjZ0=.4bf682dc-5cd6-4e81-a569-33da79470f50@github.com>
Message-ID: <7BS0eOxZgGVbXzGTvX8ELFMu38KLugURCtrx_vQn6AQ=.3afe94ea-9921-4fc9-a647-91f570272e27@github.com>

On Wed, 10 Mar 2021 12:59:18 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.lang` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

This pull request has now been integrated.

Changeset: 329697b0
Author:    Patrick Concannon <pconcannon at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/329697b0
Stats:     113 lines in 18 files changed: 1 ins; 50 del; 62 mod

8263358: Update java.lang to use instanceof pattern variable

Reviewed-by: iris, chegar, mchung, dfuchs

-------------

PR: https://git.openjdk.java.net/jdk/pull/2913

From pconcannon at openjdk.java.net  Wed Mar 24 10:01:56 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Wed, 24 Mar 2021 10:01:56 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
Message-ID: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>

Hi,

Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?

Kind regards,
Patrick

-------------

Commit messages:
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - 8263668: Update java.time to use instanceof pattern variable

Changes: https://git.openjdk.java.net/jdk/pull/3170/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263668
  Stats: 170 lines in 34 files changed: 0 ins; 47 del; 123 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3170/head:pull/3170

PR: https://git.openjdk.java.net/jdk/pull/3170

From lancea at openjdk.java.net  Wed Mar 24 10:28:39 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 24 Mar 2021 10:28:39 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts,
 use of optional GZIP fields [v3]
In-Reply-To: <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
 <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>
Message-ID: <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>

On Wed, 24 Mar 2021 06:51:16 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Hi Lin,
>>  
>> Again, thank you for taking on this 19+ year feature request.
>> 
>> I have not done a deep dive on the CSR, but wanted to get a few comments back to you on a quick scan of the last PR update.
>> 
>> Personally, I would like to see more testing for a change such as this given the age of the code:
>> 
>> - Please do not modify the existing test, you can either create  a new test(s) or add tests to the existing test class
>> - We should capture Gzip files with these headers set from other tools and store the Gzip in an array within the test which can then be written to disk so the tests can validate interoperability.  Please see some of the other Zip tests for an example
>> - We should have tests that include some , but not all of the additional fields as I believe they are all optional according to the RFC.
>> - Please include some negative tests
>> 
>> 
>> I have also include some additional comments within the code
>
> Hi Lance?
> Thanks a lot for your review. I will update the PR ASAP. 
> May I ask your help to also review the CSR? Thanks!
> 
> BRs,
> Lin

Hi Lin,

On Mar 24, 2021, at 2:51 AM, Lin Zang ***@***.******@***.***>> wrote:



Hi Lance?
Thanks a lot for your review. I will update the PR ASAP.
May I ask your help to also review the CSR?

I believe we need to flush out some of the issues I raised that were not test related as they will result in updates to the javadoc which will require an update to the CSR.



Thanks!

BRs,
Lin

?
You are receiving this because you commented.
Reply to this email directly, view it on GitHub<https://github.com/openjdk/jdk/pull/3072#issuecomment-805549600>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABQPFO5R4INTAUFZ3QS6WL3TFGDXHANCNFSM4ZMLU6SA>.

***@***.***



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
***@***.******@***.***>

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

From jbachorik at openjdk.java.net  Wed Mar 24 10:34:24 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 24 Mar 2021 10:34:24 GMT
Subject: RFR: 8203359: Container level resources events [v2]
In-Reply-To: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
Message-ID: <9_2MB3MaDFpBiwoAAQkxaKOEa9YgYVcXh-JZCIcwdBs=.e2c15f2e-073b-4f7b-a680-4ece79990710@github.com>

> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
> 
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
> * CPU related metrics
> * Memory related metrics
> * I/O related metrics
> 
> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).

Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:

  Split off the CPU throttling metrics

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3126/files
  - new: https://git.openjdk.java.net/jdk/pull/3126/files/9ba3c5a6..90de0d8c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=00-01

  Stats: 88 lines in 3 files changed: 73 ins; 15 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3126/head:pull/3126

PR: https://git.openjdk.java.net/jdk/pull/3126

From jai.forums2013 at gmail.com  Wed Mar 24 10:40:23 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Wed, 24 Mar 2021 16:10:23 +0530
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <237e6c14-8593-69df-5866-4a238e020fce@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
 <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
 <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>
 <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com>
 <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com>
 <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com>
 <237e6c14-8593-69df-5866-4a238e020fce@oracle.com>
Message-ID: <b10be763-cf85-a144-87bb-0653f3a0a1ec@gmail.com>

Based on the inputs so far, I've updated the PR to include the provided 
feedback. Since the PR code review hadn't yet started, I decided to do a 
force push to the PR so that we can start it afresh.

Command option:

In this current discussion, we seem to have an agreement for using -C 
and --dir as the short and long options for this feature. The 
implementation in this PR now uses these options. There was also a 
suggestion to additionally allow --directory as an option too. I haven't 
added that yet, since I wasn't sure if we really want that. It was 
suggested that if we do use --directory, we should "hide" --dir. If we 
do need the --directory option, I can add that in, in subsequent updates 
to this PR.


Directories creation:

There was an agreement in our discussion that if the destination 
directory hierarchy isn't present, then we should create that whole 
hierarchy and extract the jar into it. The implementation in this PR 
matches this decision.


Verbose logging:

During the discussion, there was a question whether this feature should 
introduce any new verbose logs during extraction. IMO, it's a good idea 
to log the target directory to which the jar is being extracted. So, in 
the implementation, I have introduced a new (resource bundle backed) 
verbose log message which prints the absolute path to which the jar will 
be extracted. Do note that this verbose log message will be printed even 
if you don't explicitly specify any target directory. i.e. even when the 
default current directory is used, this verbose log message will be 
printed if the "-v" option is used.

Repeatability of the newly introduce options:

Unlike in the other main operations of the jar command, the -C option 
that we use during the extract main operation, IMO, shouldn't be allowed 
to be used more than once. More specifically the destination directory 
to which the jar needs to be extracted must only be specified once, 
irrespective of whether it's through the use of -C or --dir. The code in 
the PR, explicitly throws an error when such repeatition is encountered.

An alternate approach would have been to allow the -C and/or --dir 
option to be repeated, but use the last specified value of these 
options. However, I decided not to pursue that approach, to keep it 
simple as well as to avoid any confusion on the command usage.


Overwriting of contents in existing target directory:

No specific change has been done when it comes to dealing with the 
extraction logic itself. Specifically, when the explicitly specified or 
the default current directory already has directories/files that belong 
to the jar being extracted, those files/dirs will continue to be 
overwritten.

Compatibility mode:

The code in this PR also supports the compatibility mode for this 
option. Specifically, a command like:

jar -xvf somejar.jar -C /tmp/foo/

will work fine and the jar will be extracted into /tmp/foo directory.


Message/error internationalization:

I have only updated the jar.properties for the English version of the 
new output and error messages. I don't know what the process is for 
adding this to other languages, if at all that needs to be done in this PR.


jar --help output:

Currently the jar --help output only talks about creation and updation 
of the jar. There's no mention of using the tool for extracting the jar 
content:

"jar creates an archive for classes and resources, and can manipulate or
restore individual classes or resources from an archive."

It does mention "manipulate" but doesn't specifically say extraction. 
The examples in the help command output don't have any examples for 
extraction. Should we add an example for extracting the jar file, in 
this help output?


Testing:

A new jtreg test has been introduced which tests various aspects of this 
feature. It runs most of those tests against both absolute and relative 
paths.

A couple of tests in the new introduced test case, check for the 
output/error messages. The jar tool uses resource bundles to print out 
these messages. I need input on whether I should enforce a specific 
locale to run these tests so that I can compare the error/output 
messages for expected strings? See testExtractFailWithMultipleDir() or 
testHelpOutput() for what I mean.


Man page:

This one I need input on. I have tried to see how these man pages are 
generated and from what I can understand it looks like these man pages 
are autogenerated during the build process using pandoc. Is that right? 
The hints that I see in the Docs.gmk seems to suggest that there are 
some markdown source files from which these man pages get generated. 
However, I can't seem to locate any such markdown files for this or 
other tools, from which the man pages get generated. Any help on how I 
should go about editing/updating the man page for the jar tool?


Example usage:

Here are some example usages:

jar -x -f somejar.jar -C /tmp/foo/bar/

This command extracts the somejar.jar file to the /tmp/foo/bar/ 
directory, creating it if necessary.


jar -x -f somejar.jar --dir /tmp/foo/bar/

Same as above, except uses the long form --dir option


jar -x -f somejar.jar -C /tmp/foo/bar/ f1.txt d1/f2.txt

Assuming somejar.jar contains "f1.txt" (at root), "d1/f2.txt" and other 
files, then the above command extracts only "f1.txt" and "d1/f2.txt" 
into the /tmp/foo/bar/ directory.


-Jaikiran

On 14/03/21 6:21 pm, Alan Bateman wrote:
> On 12/03/2021 12:18, Lance Andersen wrote:
>>
>> :
>>
>> I don?t have a strong preference but lean slightly towards 
>> ?-directory? as it is more descriptive, similar to the other 
>> GNU-style commands jar currently supports . ?Tar supports ??cd?, 
>> ??directory? in addition to ?-C? which is why I suggested supporting 
>> ?both GNU-style long options.
>>
>> Perhaps jpackage should also support ?dir/directory in addition to 
>> ??dest' if we are looking at consistency between java tools.
>>
>> I do agree that it would be nice to be consistent across the java 
>> tools for options so if we go the ?-directory?, we should follow your 
>> suggestion and make it the primary and remove ??dir? from the usage 
>> output.
> My comment on consistency was limited to the long option to specify 
> the directory when extracting, didn't mean to suggest doing anything 
> with the other tools that specify an output/destination directory. In 
> any case, I think we have enough to make progress on this issue now.
>
> -Alan
>

From lancea at openjdk.java.net  Wed Mar 24 10:44:41 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 24 Mar 2021 10:44:41 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <W7TTMn5vZTP7CwsgIdsEXxoTtkIQXtweQIW_SF3h7qk=.88aeee95-cd17-418d-9041-da141ae41232@github.com>

On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Changes look good Patrick.

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3170

From jpai at openjdk.java.net  Wed Mar 24 10:45:09 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 24 Mar 2021 10:45:09 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a
 directory [v2]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <meFutvzak1vZH5GImfEtLovcxXS5VuWAZYoXf-KoHxw=.c1c21965-9039-4b65-9a12-663d2123d23f@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains one additional commit since the last revision:

  8173970: jar tool should have a way to extract to a directory

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2752/files
  - new: https://git.openjdk.java.net/jdk/pull/2752/files/3a8e329d..a9954240

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=00-01

  Stats: 62407 lines in 2851 files changed: 39040 ins; 14156 del; 9211 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2752/head:pull/2752

PR: https://git.openjdk.java.net/jdk/pull/2752

From github.com+828220+forax at openjdk.java.net  Wed Mar 24 11:03:51 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 24 Mar 2021 11:03:51 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <Dpzk0f63E8tPAC1zjmQ29kGopHHsyjozKI3AP_EpWCg=.079e6cda-ad0f-4b80-a254-5b3f2888a2eb@github.com>

On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

src/java.base/share/classes/java/time/LocalDateTime.java line 1686:

> 1684:     public long until(Temporal endExclusive, TemporalUnit unit) {
> 1685:         LocalDateTime end = LocalDateTime.from(endExclusive);
> 1686:         if (unit instanceof ChronoUnit u) {

`chronoUnit` is perhaps a better variable name than `u`

src/java.base/share/classes/java/time/LocalTime.java line 1412:

> 1410:         if (unit instanceof ChronoUnit u) {
> 1411:             long nanosUntil = end.toNanoOfDay() - toNanoOfDay();  // no overflow
> 1412:             switch (u) {

same comment as above

src/java.base/share/classes/java/time/MonthDay.java line 448:

> 446:     public long getLong(TemporalField field) {
> 447:         if (field instanceof ChronoField f) {
> 448:             switch (f) {

as above, `chronoField` instead of `f`

src/java.base/share/classes/java/time/OffsetDateTime.java line 599:

> 597:     @Override
> 598:     public int get(TemporalField field) {
> 599:         if (field instanceof ChronoField f) {

see above

src/java.base/share/classes/java/time/OffsetDateTime.java line 636:

> 634:     @Override
> 635:     public long getLong(TemporalField field) {
> 636:         if (field instanceof ChronoField f) {

see above

src/java.base/share/classes/java/time/OffsetTime.java line 1182:

> 1180:         OffsetTime end = OffsetTime.from(endExclusive);
> 1181:         if (unit instanceof ChronoUnit u) {
> 1182:             long nanosUntil = end.toEpochNano() - toEpochNano();  // no overflow

see above

src/java.base/share/classes/java/time/Year.java line 500:

> 498:     public long getLong(TemporalField field) {
> 499:         if (field instanceof ChronoField f) {
> 500:             switch (f) {

see above

src/java.base/share/classes/java/time/Year.java line 711:

> 709:     @Override
> 710:     public Year plus(long amountToAdd, TemporalUnit unit) {
> 711:         if (unit instanceof ChronoUnit u) {

see above

src/java.base/share/classes/java/time/Year.java line 917:

> 915:     public long until(Temporal endExclusive, TemporalUnit unit) {
> 916:         Year end = Year.from(endExclusive);
> 917:         if (unit instanceof ChronoUnit u) {

see above

src/java.base/share/classes/java/time/YearMonth.java line 488:

> 486:     @Override
> 487:     public long getLong(TemporalField field) {
> 488:         if (field instanceof ChronoField f) {

see above

src/java.base/share/classes/java/time/YearMonth.java line 808:

> 806:     @Override
> 807:     public YearMonth plus(long amountToAdd, TemporalUnit unit) {
> 808:         if (unit instanceof ChronoUnit u) {

see above

src/java.base/share/classes/java/time/YearMonth.java line 1049:

> 1047:     public long until(Temporal endExclusive, TemporalUnit unit) {
> 1048:         YearMonth end = YearMonth.from(endExclusive);
> 1049:         if (unit instanceof ChronoUnit u) {

see above

src/java.base/share/classes/java/time/ZonedDateTime.java line 816:

> 814:     @Override  // override for Javadoc and performance
> 815:     public int get(TemporalField field) {
> 816:         if (field instanceof ChronoField f) {

see above

src/java.base/share/classes/java/time/ZonedDateTime.java line 853:

> 851:     @Override
> 852:     public long getLong(TemporalField field) {
> 853:         if (field instanceof ChronoField f) {

see above

src/java.base/share/classes/java/time/chrono/ChronoLocalDateImpl.java line 380:

> 378:         Objects.requireNonNull(endExclusive, "endExclusive");
> 379:         ChronoLocalDate end = getChronology().date(endExclusive);
> 380:         if (unit instanceof ChronoUnit u) {

see above

src/java.base/share/classes/java/time/chrono/ChronoLocalDateTimeImpl.java line 379:

> 377:             if (unit.isTimeBased()) {
> 378:                 long amount = end.getLong(EPOCH_DAY) - date.getLong(EPOCH_DAY);
> 379:                 switch (u) {

see above

src/java.base/share/classes/java/time/chrono/ChronoZonedDateTime.java line 198:

> 196:     @Override
> 197:     default int get(TemporalField field) {
> 198:         if (field instanceof ChronoField f) {

see above

src/java.base/share/classes/java/time/chrono/ChronoZonedDateTime.java line 212:

> 210:     @Override
> 211:     default long getLong(TemporalField field) {
> 212:         if (field instanceof ChronoField f) {

see above

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From herrick at openjdk.java.net  Wed Mar 24 11:08:56 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 24 Mar 2021 11:08:56 GMT
Subject: RFR: JDK-8264057: [redo] JDK-8248904: Add support to jpackage for the
 Mac App Store.
Message-ID: <nzHAIbuRE9irzlnp1qqIAKMfSLnxZM7-83vOw5xc6LQ=.ee1d9889-3b79-4871-8fe4-56b77e43bf50@github.com>

Restoring fix to JDK-8248904: Add support to jpackage for the Mac App Store.

-------------

Commit messages:
 - JDK-8264057: [redo] JDK-8248904: Add support to jpackage for the Mac App Store.

Changes: https://git.openjdk.java.net/jdk/pull/3172/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3172&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264057
  Stats: 296 lines in 22 files changed: 189 ins; 43 del; 64 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3172.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3172/head:pull/3172

PR: https://git.openjdk.java.net/jdk/pull/3172

From github.com+828220+forax at openjdk.java.net  Wed Mar 24 11:09:42 2021
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 24 Mar 2021 11:09:42 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <QHBgB4c8fVfPhihJFROw2JI0osAegG8lgeggKUhSKtE=.ea2029d7-cc1b-4a75-a8d1-cb3d6efca5a5@github.com>

On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 168:

> 166:     private static final TemporalQuery<ZoneId> QUERY_REGION_ONLY = (temporal) -> {
> 167:         ZoneId zone = temporal.query(TemporalQueries.zoneId());
> 168:         return (zone != null && (!(zone instanceof ZoneOffset)) ? zone : null);

i find this code hard to read
`return (zone != null && (!(zone instanceof ZoneOffset))) ? zone : null;`
seems better`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From kcr at openjdk.java.net  Wed Mar 24 11:23:39 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Wed, 24 Mar 2021 11:23:39 GMT
Subject: RFR: JDK-8264057: [redo] JDK-8248904: Add support to jpackage for
 the Mac App Store.
In-Reply-To: <nzHAIbuRE9irzlnp1qqIAKMfSLnxZM7-83vOw5xc6LQ=.ee1d9889-3b79-4871-8fe4-56b77e43bf50@github.com>
References: <nzHAIbuRE9irzlnp1qqIAKMfSLnxZM7-83vOw5xc6LQ=.ee1d9889-3b79-4871-8fe4-56b77e43bf50@github.com>
Message-ID: <D7TeVrrQwvugW37XIke5jiElzg9bBRCH1cUAVtbSwm8=.3e57601b-db36-44e3-b02f-073827b83dab@github.com>

On Wed, 24 Mar 2021 11:00:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Restoring fix to JDK-8248904: Add support to jpackage for the Mac App Store.

I can confirm that this restores the fix for JDK-8248904. There are no diffs in any jpackage file between the commit prior to the backout and this PR.

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/3172

From jdk at fiolino.de  Wed Mar 24 12:23:08 2021
From: jdk at fiolino.de (Michael Kuhlmann)
Date: Wed, 24 Mar 2021 13:23:08 +0100
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
In-Reply-To: <QHBgB4c8fVfPhihJFROw2JI0osAegG8lgeggKUhSKtE=.ea2029d7-cc1b-4a75-a8d1-cb3d6efca5a5@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <QHBgB4c8fVfPhihJFROw2JI0osAegG8lgeggKUhSKtE=.ea2029d7-cc1b-4a75-a8d1-cb3d6efca5a5@github.com>
Message-ID: <9bb2b13b-c703-09b2-5782-91cf48a73977@fiolino.de>



On 3/24/21 12:09 PM, R?mi Forax wrote:
> On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:
> 
>> Hi,
>>
>> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
>>
>> Kind regards,
>> Patrick
> 
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 168:
> 
>> 166:     private static final TemporalQuery<ZoneId> QUERY_REGION_ONLY = (temporal) -> {
>> 167:         ZoneId zone = temporal.query(TemporalQueries.zoneId());
>> 168:         return (zone != null && (!(zone instanceof ZoneOffset)) ? zone : null);
> 
> i find this code hard to read
> `return (zone != null && (!(zone instanceof ZoneOffset))) ? zone : null;`
> seems better`

The whole null check is not necessary.

`return zone instanceof ZoneOffset ? null : zone;`

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/3170
> 

From jbachorik at openjdk.java.net  Wed Mar 24 12:29:22 2021
From: jbachorik at openjdk.java.net (Jaroslav Bachorik)
Date: Wed, 24 Mar 2021 12:29:22 GMT
Subject: RFR: 8203359: Container level resources events [v3]
In-Reply-To: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
Message-ID: <SHvchBNTL5_6g5dtt1v_DxH3AZ8EksX5JMilglI4aZ8=.7a685f01-35c1-4e2c-b67d-b1438500c0c2@github.com>

> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
> 
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
> * CPU related metrics
> * Memory related metrics
> * I/O related metrics
> 
> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).

Jaroslav Bachorik has updated the pull request incrementally with one additional commit since the last revision:

  Update the JFR control files

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3126/files
  - new: https://git.openjdk.java.net/jdk/pull/3126/files/90de0d8c..82570022

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3126&range=01-02

  Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3126.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3126/head:pull/3126

PR: https://git.openjdk.java.net/jdk/pull/3126

From ryadav at openjdk.java.net  Wed Mar 24 12:36:40 2021
From: ryadav at openjdk.java.net (Rahul Yadav)
Date: Wed, 24 Mar 2021 12:36:40 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <0z3is7ycda29bAweHVyYf4foAwjU8uCHCwM0Cq5t6hg=.988e5c6d-b422-4232-b78b-2a0446c328fc@github.com>

On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

LGTM!

-------------

Marked as reviewed by ryadav (Committer).

PR: https://git.openjdk.java.net/jdk/pull/3170

From forax at univ-mlv.fr  Wed Mar 24 12:56:45 2021
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 24 Mar 2021 13:56:45 +0100 (CET)
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
In-Reply-To: <9bb2b13b-c703-09b2-5782-91cf48a73977@fiolino.de>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
 <QHBgB4c8fVfPhihJFROw2JI0osAegG8lgeggKUhSKtE=.ea2029d7-cc1b-4a75-a8d1-cb3d6efca5a5@github.com>
 <9bb2b13b-c703-09b2-5782-91cf48a73977@fiolino.de>
Message-ID: <2066054938.2493130.1616590605713.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Michael Kuhlmann" <jdk at fiolino.de>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mercredi 24 Mars 2021 13:23:08
> Objet: Re: RFR: 8263668: Update java.time to use instanceof pattern variable

> On 3/24/21 12:09 PM, R?mi Forax wrote:
>> On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org>
>> wrote:
>> 
>>> Hi,
>>>
>>> Could someone please review my code for updating the code in the `java.time`
>>> package to make use of the `instanceof` pattern variable?
>>>
>>> Kind regards,
>>> Patrick
>> 
>> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line
>> 168:
>> 
>>> 166:     private static final TemporalQuery<ZoneId> QUERY_REGION_ONLY =
>>> (temporal) -> {
>>> 167:         ZoneId zone = temporal.query(TemporalQueries.zoneId());
>>> 168:         return (zone != null && (!(zone instanceof ZoneOffset)) ? zone :
>>> null);
>> 
>> i find this code hard to read
>> `return (zone != null && (!(zone instanceof ZoneOffset))) ? zone : null;`
>> seems better`
> 
> The whole null check is not necessary.
> 
> `return zone instanceof ZoneOffset ? null : zone;`

yes,
you are right !

> 
>> -------------
>> 
>> PR: https://git.openjdk.java.net/jdk/pull/3170

R?mi

From naoto at openjdk.java.net  Wed Mar 24 13:05:39 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 24 Mar 2021 13:05:39 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <4uNOFiXg4J3VGd26cDhJ2s7FFrOgNAzjx7yWU57omb8=.9a943351-1ed1-4a68-8114-3ea1c05a76bb@github.com>

On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

LGTM. Thanks for the cleanup!

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3170

From rriggs at openjdk.java.net  Wed Mar 24 14:00:42 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 24 Mar 2021 14:00:42 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <wnSAgogvub7uNdnY8-w7gtbWP_G7_Fmto3S2yxFQWm0=.fbc2ded4-61d4-4340-b142-c63c0f673a48@github.com>

On Wed, 24 Mar 2021 09:56:16 GMT, Patrick Concannon <pconcannon at openjdk.org> wrote:

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

In addition to the other suggestions, java.time could use a round of cleanup to use switch expressions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3170

From msheppar at openjdk.java.net  Wed Mar 24 14:50:39 2021
From: msheppar at openjdk.java.net (Mark Sheppard)
Date: Wed, 24 Mar 2021 14:50:39 GMT
Subject: RFR: JDK-8064681 : Jaxp unit test need to be improved
In-Reply-To: <V9kOzORMX8sH7Goli5bUISPnubjBkl1Ej_ZAc5WJLeU=.3ed5bbf0-f840-4f63-8105-5f09e0bfbed8@github.com>
References: <V9kOzORMX8sH7Goli5bUISPnubjBkl1Ej_ZAc5WJLeU=.3ed5bbf0-f840-4f63-8105-5f09e0bfbed8@github.com>
Message-ID: <VnWbnpfehcz0m0yTfpUKJqyFdliX6akY-TC6e900OWo=.f93cc5b7-34bf-4338-abc5-8c7b6398a70a@github.com>

On Mon, 22 Mar 2021 10:35:03 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8064681

the tests set a system property and then clear that system property at the end of the test.  Is it always the case that the property being set in the test does not have a value prior to be being set? Or is it more appropriate to save the current value of the property, set the new value and then restore the original value, rather than clearing the property?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3115

From asemenyuk at openjdk.java.net  Wed Mar 24 14:57:42 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 24 Mar 2021 14:57:42 GMT
Subject: RFR: JDK-8264057: [redo] JDK-8248904: Add support to jpackage for
 the Mac App Store.
In-Reply-To: <nzHAIbuRE9irzlnp1qqIAKMfSLnxZM7-83vOw5xc6LQ=.ee1d9889-3b79-4871-8fe4-56b77e43bf50@github.com>
References: <nzHAIbuRE9irzlnp1qqIAKMfSLnxZM7-83vOw5xc6LQ=.ee1d9889-3b79-4871-8fe4-56b77e43bf50@github.com>
Message-ID: <gCnrtsYxmoFz2jI2YUhoyzq9rtISUxcOYi9USj58yJ8=.204ed5fc-5054-49b8-bdcf-db5afbbb3d43@github.com>

On Wed, 24 Mar 2021 11:00:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Restoring fix to JDK-8248904: Add support to jpackage for the Mac App Store.

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3172

From herrick at openjdk.java.net  Wed Mar 24 15:43:43 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 24 Mar 2021 15:43:43 GMT
Subject: Integrated: JDK-8264057: [redo] JDK-8248904: Add support to jpackage
 for the Mac App Store.
In-Reply-To: <nzHAIbuRE9irzlnp1qqIAKMfSLnxZM7-83vOw5xc6LQ=.ee1d9889-3b79-4871-8fe4-56b77e43bf50@github.com>
References: <nzHAIbuRE9irzlnp1qqIAKMfSLnxZM7-83vOw5xc6LQ=.ee1d9889-3b79-4871-8fe4-56b77e43bf50@github.com>
Message-ID: <sH2Hu93xUIIiC1RNzdyEl4HS-0jSq0VvpG7rr_FZwyU=.5176895f-c727-4e56-8b70-80d08c8ae3f0@github.com>

On Wed, 24 Mar 2021 11:00:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Restoring fix to JDK-8248904: Add support to jpackage for the Mac App Store.

This pull request has now been integrated.

Changeset: deda80f0
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/deda80f0
Stats:     296 lines in 22 files changed: 189 ins; 43 del; 64 mod

8264057: [redo] JDK-8248904: Add support to jpackage for the Mac App Store.

Co-authored-by: Erwin Morrhey <erwin.morrhey at gluonhq.com>
Reviewed-by: kcr, asemenyuk

-------------

PR: https://git.openjdk.java.net/jdk/pull/3172

From avoitylov at openjdk.java.net  Wed Mar 24 15:59:49 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Wed, 24 Mar 2021 15:59:49 GMT
Subject: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be
 singleton [v2]
In-Reply-To: <NuvbIaK4AJ8avuLsGSAe3hJv5x_82VVhArQz3MiHfe4=.f7a1185f-3f6b-4403-aa54-acf24f665fe7@github.com>
References: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
 <C6roaR7ZxyPk0pJIPt2arP5KpOsVzIO8KF0uXfrv9Lw=.a4b75f9a-3da1-4df9-a0a5-1ad7880d209c@github.com>
 <NuvbIaK4AJ8avuLsGSAe3hJv5x_82VVhArQz3MiHfe4=.f7a1185f-3f6b-4403-aa54-acf24f665fe7@github.com>
Message-ID: <U_zTqUf05nKmF982bZH-orDsO3XURb9Xzm_EgefjaGA=.672124e0-655c-43b5-a3d8-f9e7cb9502c4@github.com>

On Tue, 23 Mar 2021 08:21:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix style
>
> Marked as reviewed by alanb (Reviewer).

Thanks Ioi, David and Alan for your reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3131

From redestad at openjdk.java.net  Wed Mar 24 16:35:44 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 24 Mar 2021 16:35:44 GMT
Subject: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be
 singleton [v2]
In-Reply-To: <C6roaR7ZxyPk0pJIPt2arP5KpOsVzIO8KF0uXfrv9Lw=.a4b75f9a-3da1-4df9-a0a5-1ad7880d209c@github.com>
References: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
 <C6roaR7ZxyPk0pJIPt2arP5KpOsVzIO8KF0uXfrv9Lw=.a4b75f9a-3da1-4df9-a0a5-1ad7880d209c@github.com>
Message-ID: <5ddGQm8sn2u7O1sUIRV89eoBMVHjmIyrGHhrDXUJwNY=.df28dbeb-65e1-4c9d-8383-64557d028487@github.com>

On Tue, 23 Mar 2021 08:04:09 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

>> With CDS and G1, test api/java_lang/ModuleLayer/Boot.html fails in JDK 16. 
>> 
>> After JDK-8253081 with CDS enabled two instances of empty layer appear in the runtime. One comes from default initialization of java/lang/ModuleLayer.EMPTY_LAYER, another one comes from CDS archive and is returned by ModuleLayer.boot().parents().get(0). The fix makes java/lang/ModuleLayer.EMPTY_LAYER a singleton with both CDS on and off, similar to java/lang/module/Configuration.EMPTY_CONFIGURATION.
>> 
>> Testing: JCK 16, jtreg (including newly added test), pre-submit GitHub actions tests.
>
> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix style

Looks good. The need to retain singleton/identity semantics of constants like this when archiving in CDS has bitten us in the past.

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3131

From avoitylov at openjdk.java.net  Wed Mar 24 16:35:44 2021
From: avoitylov at openjdk.java.net (Aleksei Voitylov)
Date: Wed, 24 Mar 2021 16:35:44 GMT
Subject: Integrated: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be
 singleton
In-Reply-To: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
References: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
Message-ID: <1PjK-kaL2lZFtDA71I6_PNUee7n-alhxkFmaZll2iRc=.87e5f341-b981-467e-9174-1e98d3f9c635@github.com>

On Mon, 22 Mar 2021 19:40:19 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> With CDS and G1, test api/java_lang/ModuleLayer/Boot.html fails in JDK 16. 
> 
> After JDK-8253081 with CDS enabled two instances of empty layer appear in the runtime. One comes from default initialization of java/lang/ModuleLayer.EMPTY_LAYER, another one comes from CDS archive and is returned by ModuleLayer.boot().parents().get(0). The fix makes java/lang/ModuleLayer.EMPTY_LAYER a singleton with both CDS on and off, similar to java/lang/module/Configuration.EMPTY_CONFIGURATION.
> 
> Testing: JCK 16, jtreg (including newly added test), pre-submit GitHub actions tests.

This pull request has now been integrated.

Changeset: 133a63b4
Author:    Aleksei Voitylov <avoitylov at openjdk.org>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/133a63b4
Stats:     22 lines in 3 files changed: 19 ins; 0 del; 3 mod

8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be singleton

Reviewed-by: iklam, dholmes, alanb, redestad

-------------

PR: https://git.openjdk.java.net/jdk/pull/3131

From herrick at openjdk.java.net  Wed Mar 24 16:37:42 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 24 Mar 2021 16:37:42 GMT
Subject: Integrated: JDK-8263887: Re-create default icons
In-Reply-To: <8v_kn43vqUCfHMiqY5uu3DF2tN8CV14bD5JL3YNqmFE=.3deac616-e000-488d-828d-50802dfcc99a@github.com>
References: <8v_kn43vqUCfHMiqY5uu3DF2tN8CV14bD5JL3YNqmFE=.3deac616-e000-488d-828d-50802dfcc99a@github.com>
Message-ID: <VOsep7hKVNYLa5--l4usGcnxhU8VuXrR2fhpTTibL6Q=.2cf3adad-7219-4aa6-8a95-2cd364f74dfe@github.com>

On Mon, 22 Mar 2021 13:03:10 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8263887: Re-create default icons

This pull request has now been integrated.

Changeset: 70d34017
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/70d34017
Stats:     32 lines in 2 files changed: 7 ins; 21 del; 4 mod

8263887: Re-create default icons

Reviewed-by: almatvee, asemenyuk

-------------

PR: https://git.openjdk.java.net/jdk/pull/3118

From herrick at openjdk.java.net  Wed Mar 24 16:39:40 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 24 Mar 2021 16:39:40 GMT
Subject: Integrated: JDK-8259926: Error in jpackage sample usage in the help
 text
In-Reply-To: <svG94wkAg8fU0l80Xkbqyt3YK8QNge9Evov56PiViQ8=.48a24253-0b29-4832-a6f0-df3211bc32bb@github.com>
References: <svG94wkAg8fU0l80Xkbqyt3YK8QNge9Evov56PiViQ8=.48a24253-0b29-4832-a6f0-df3211bc32bb@github.com>
Message-ID: <1TypUvJXTpG3CudyYxHG3VkaxeC-wAbWhHsEpBW15YY=.86254e08-f89e-48cc-8f7b-782365913208@github.com>

On Mon, 22 Mar 2021 20:40:09 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8259926: Error in jpackage sample usage in the help text

This pull request has now been integrated.

Changeset: 5ca5962d
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5ca5962d
Stats:     4 lines in 3 files changed: 1 ins; 0 del; 3 mod

8259926: Error in jpackage sample usage in the help text

Reviewed-by: asemenyuk, almatvee, naoto

-------------

PR: https://git.openjdk.java.net/jdk/pull/3132

From alexey.semenyuk at oracle.com  Wed Mar 24 16:53:33 2021
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 24 Mar 2021 12:53:33 -0400
Subject: Production use of "jpackage.app-path" property
In-Reply-To: <CAG03-8FX-MWX5+PSdU=QaWysitEhZGwRq6TQNDKNieCmQ0S=JA@mail.gmail.com>
References: <CAG03-8FX-MWX5+PSdU=QaWysitEhZGwRq6TQNDKNieCmQ0S=JA@mail.gmail.com>
Message-ID: <50340ea3-5c7c-0ef3-c67a-1b69dd38617f@oracle.com>

Hi Zlatin,

There are no plans to deprecate "jpackage.app-path" system property. It 
will be available in the next LTS release.

- Alexey

On 3/20/2021 1:25 PM, Zlatin Balevsky wrote:
> Hi,
>
> In my application I need to know the absolute path of the executable
> generated by jpackage at runtime.  I found the "jpackage.app-path" system
> property and it is exactly what I was looking for.  However, I found no
> documentation relating to it and am concerned that since it's undocumented
> it may go away in future JDK versions.
>
> Is that a valid concern?  Can I count on it being there in the next LTS
> release of the JDK?
>
> Thank you in advance
> Zlatin Balevsky


From shade at openjdk.java.net  Wed Mar 24 18:14:49 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 24 Mar 2021 18:14:49 GMT
Subject: RFR: 8264029: Replace uses of StringBuffer with StringBuilder in
 java.base
In-Reply-To: <gxM0BMtMo8hpXcC2yNZeyYYG5aVEJUQnnAKl_rRooMM=.c930bf8e-03df-47dd-b9c0-ef2acf929139@github.com>
References: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com>
 <yNg9GtLV_kyvs_xdWSxdjOYAiC2Awa7PZQCG-L_AwA8=.b20ca7ba-fd49-46cf-bd61-c2db366cdff5@github.com>
 <gfqT-B96j8Wl-Jd6txZhV8xuLKjJz11PxgorIVJ9BG4=.d5a5e9aa-8632-43ba-a6cf-45d69eba67d9@github.com>
 <gxM0BMtMo8hpXcC2yNZeyYYG5aVEJUQnnAKl_rRooMM=.c930bf8e-03df-47dd-b9c0-ef2acf929139@github.com>
Message-ID: <TSgWID1AkWGeqt7MhDwTjtCBz2kTuyy8dyf-rjpg2gE=.77764ca0-07ad-4e06-8704-88189587b030@github.com>

On Tue, 23 Mar 2021 21:54:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> I'm not sure how String.repeat can be used here. Repeated String is not constant and different for each iteration.
>
> Long runs of whitespace, especially in blank strings, may have poor readability. I was thinking that
> 
> " ".repeat(7) and " ".repeat(10)
>  
> 
> might read better than 
> 
> "       " and "          "
> 
> respectively. If you don't agree, then simply disregard what I said. If you agree but worry about negative performance implications, consider creating these strings before the respective for-loops.

I suggest we ignore the use case for `String.repeat` here, and leave the patch as is.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2922

From sgehwolf at openjdk.java.net  Wed Mar 24 18:41:40 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Wed, 24 Mar 2021 18:41:40 GMT
Subject: RFR: 8203359: Container level resources events
In-Reply-To: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
Message-ID: <32-BO7tExbAStlYsma_g-oc8kw-kj3HSyhJOP-qAjLk=.6c4d8c45-1a64-4b5a-8767-7307c297b3d8@github.com>

On Mon, 22 Mar 2021 15:57:12 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
> 
> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
> * CPU related metrics
> * Memory related metrics
> * I/O related metrics
> 
> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).

@jbachorik Would it make sense for `ContainerConfigurationEvent` to include the underlying cgroup version info (v1 or legacy vs. v2 or unified)? `Metrics.getProvider()` should give that info.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From asemenyuk at openjdk.java.net  Wed Mar 24 19:07:00 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 24 Mar 2021 19:07:00 GMT
Subject: RFR: 8220266: add support for additional metadata in add/remove
 programs
Message-ID: <rB3ZqiaDcaNY3LmUlsxgoG-nsTLXGWto5EjHQxyddMY=.776ed8f1-39b3-4030-84cc-dfd12e6a41bd@github.com>

Add support for --about-url, --win-update-url and --win-help-url parameters

-------------

Commit messages:
 - Remove unused import-s
 - 8220266: add support for additional metadata in add/remove programs

Changes: https://git.openjdk.java.net/jdk/pull/3178/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3178&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8220266
  Stats: 573 lines in 9 files changed: 563 ins; 0 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3178.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3178/head:pull/3178

PR: https://git.openjdk.java.net/jdk/pull/3178

From herrick at openjdk.java.net  Wed Mar 24 21:04:46 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 24 Mar 2021 21:04:46 GMT
Subject: RFR: 8220266: add support for additional metadata in add/remove
 programs
In-Reply-To: <rB3ZqiaDcaNY3LmUlsxgoG-nsTLXGWto5EjHQxyddMY=.776ed8f1-39b3-4030-84cc-dfd12e6a41bd@github.com>
References: <rB3ZqiaDcaNY3LmUlsxgoG-nsTLXGWto5EjHQxyddMY=.776ed8f1-39b3-4030-84cc-dfd12e6a41bd@github.com>
Message-ID: <ZPqUBJg0s-I8ICPX7B-okO420D36Dxb8i23xGbRC3jU=.7e85d95b-f20f-465c-8eab-f7b15580bf4d@github.com>

On Wed, 24 Mar 2021 19:01:04 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add support for `--about-url`, `--win-update-url` and `--win-help-url` parameters.
> Implementation for `--about-url` is provided on Windows only.
> This parameter may be supported on Linux as well. https://bugs.openjdk.java.net/browse/JDK-8264144 is tracking this task.

Looks OK.

-------------

Marked as reviewed by herrick (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3178

From almatvee at openjdk.java.net  Wed Mar 24 23:03:39 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 24 Mar 2021 23:03:39 GMT
Subject: RFR: 8220266: add support for additional metadata in add/remove
 programs
In-Reply-To: <rB3ZqiaDcaNY3LmUlsxgoG-nsTLXGWto5EjHQxyddMY=.776ed8f1-39b3-4030-84cc-dfd12e6a41bd@github.com>
References: <rB3ZqiaDcaNY3LmUlsxgoG-nsTLXGWto5EjHQxyddMY=.776ed8f1-39b3-4030-84cc-dfd12e6a41bd@github.com>
Message-ID: <DbR0pQv2DbGc6kD4cKOrShP_LliQCzl2X7WaTg0GTao=.43c9cdd7-c578-4b92-943a-ed4809e8620e@github.com>

On Wed, 24 Mar 2021 19:01:04 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add support for `--about-url`, `--win-update-url` and `--win-help-url` parameters.
> Implementation for `--about-url` is provided on Windows only.
> This parameter may be supported on Linux as well. https://bugs.openjdk.java.net/browse/JDK-8264144 is tracking this task.

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3178

From asemenyuk at openjdk.java.net  Wed Mar 24 23:24:43 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 24 Mar 2021 23:24:43 GMT
Subject: Integrated: 8220266: add support for additional metadata in
 add/remove programs
In-Reply-To: <rB3ZqiaDcaNY3LmUlsxgoG-nsTLXGWto5EjHQxyddMY=.776ed8f1-39b3-4030-84cc-dfd12e6a41bd@github.com>
References: <rB3ZqiaDcaNY3LmUlsxgoG-nsTLXGWto5EjHQxyddMY=.776ed8f1-39b3-4030-84cc-dfd12e6a41bd@github.com>
Message-ID: <AbKOyGao9aWh5m2hzNFJLzgdglzQTZtXgGZ-cxspSRI=.487a8d54-7854-49ae-8d42-99ded7be3a47@github.com>

On Wed, 24 Mar 2021 19:01:04 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add support for `--about-url`, `--win-update-url` and `--win-help-url` parameters.
> Implementation for `--about-url` is provided on Windows only.
> This parameter may be supported on Linux as well. https://bugs.openjdk.java.net/browse/JDK-8264144 is tracking this task.

This pull request has now been integrated.

Changeset: 3d7f9122
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3d7f9122
Stats:     573 lines in 9 files changed: 563 ins; 0 del; 10 mod

8220266: add support for additional metadata in add/remove programs

Reviewed-by: herrick, almatvee

-------------

PR: https://git.openjdk.java.net/jdk/pull/3178

From github.com+782446+simon04 at openjdk.java.net  Wed Mar 24 23:31:52 2021
From: github.com+782446+simon04 at openjdk.java.net (Simon Legner)
Date: Wed, 24 Mar 2021 23:31:52 GMT
Subject: RFR: 8264031: Fix typo in ZipFileSystem.deleteFile ZipException
Message-ID: <nyT0VApFvwWtkRnpbAJXbsDUxsL4xzGbHNuYsNZTbkc=.40ded7f1-3830-4816-bac1-d76be26de687@github.com>

8264031: Fix typo in ZipFileSystem.deleteFile ZipException

-------------

Commit messages:
 - ZipFileSystem: fix typo in ZipException

Changes: https://git.openjdk.java.net/jdk/pull/2588/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2588&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264031
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2588.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2588/head:pull/2588

PR: https://git.openjdk.java.net/jdk/pull/2588

From shade at openjdk.java.net  Wed Mar 24 23:31:52 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 24 Mar 2021 23:31:52 GMT
Subject: RFR: 8264031: Fix typo in ZipFileSystem.deleteFile ZipException
In-Reply-To: <nyT0VApFvwWtkRnpbAJXbsDUxsL4xzGbHNuYsNZTbkc=.40ded7f1-3830-4816-bac1-d76be26de687@github.com>
References: <nyT0VApFvwWtkRnpbAJXbsDUxsL4xzGbHNuYsNZTbkc=.40ded7f1-3830-4816-bac1-d76be26de687@github.com>
Message-ID: <1LnH8R14r589cROzzn8xPopc22rSVOGPy5OBKwlQDZA=.73fa4a36-0e0b-46d3-bd6c-ddda8d55df92@github.com>

On Tue, 16 Feb 2021 13:48:20 GMT, Simon Legner <github.com+782446+simon04 at openjdk.org> wrote:

> 8264031: Fix typo in ZipFileSystem.deleteFile ZipException

This looks good to me. Are you willing to continue with this PR? I see that OCA is still pending. I have created the bug for this issue: https://bugs.openjdk.java.net/browse/JDK-8264031 -- please change PR synopsis to "8264031: Fix typo in ZipFileSystem.deleteFile ZipException" to get it hooked appropriately.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2588

From shade at openjdk.java.net  Thu Mar 25 06:16:39 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 25 Mar 2021 06:16:39 GMT
Subject: RFR: 8264031: Fix typo in ZipFileSystem.deleteFile ZipException
In-Reply-To: <nyT0VApFvwWtkRnpbAJXbsDUxsL4xzGbHNuYsNZTbkc=.40ded7f1-3830-4816-bac1-d76be26de687@github.com>
References: <nyT0VApFvwWtkRnpbAJXbsDUxsL4xzGbHNuYsNZTbkc=.40ded7f1-3830-4816-bac1-d76be26de687@github.com>
Message-ID: <IjxgIcH47QoqsoHDcBxfe2bqD8p0fOXA8Y0aPc9msSo=.671787bc-499d-4bbc-83dc-cdd972757286@github.com>

On Tue, 16 Feb 2021 13:48:20 GMT, Simon Legner <github.com+782446+simon04 at openjdk.org> wrote:

> 8264031: Fix typo in ZipFileSystem.deleteFile ZipException

Looks fine to me.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2588

From shade at openjdk.java.net  Thu Mar 25 06:16:39 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 25 Mar 2021 06:16:39 GMT
Subject: RFR: 8264031: Fix typo in ZipFileSystem.deleteFile ZipException
In-Reply-To: <IjxgIcH47QoqsoHDcBxfe2bqD8p0fOXA8Y0aPc9msSo=.671787bc-499d-4bbc-83dc-cdd972757286@github.com>
References: <nyT0VApFvwWtkRnpbAJXbsDUxsL4xzGbHNuYsNZTbkc=.40ded7f1-3830-4816-bac1-d76be26de687@github.com>
 <IjxgIcH47QoqsoHDcBxfe2bqD8p0fOXA8Y0aPc9msSo=.671787bc-499d-4bbc-83dc-cdd972757286@github.com>
Message-ID: <OJc21XTxyYNMtmDI_W4INkyNzxp2_6AmwBiJeFe6PJY=.64aa62bb-c9c4-479e-bb5f-f77360ec737e@github.com>

On Thu, 25 Mar 2021 06:13:28 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> 8264031: Fix typo in ZipFileSystem.deleteFile ZipException
>
> Looks fine to me.

Note that the PR synopsis should now match the bug title, as bot says in "Integration Blocker". I think "(zipfs)" is missing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2588

From lancea at openjdk.java.net  Thu Mar 25 10:43:52 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 25 Mar 2021 10:43:52 GMT
Subject: RFR: 8264031: Fix typo in ZipFileSystem.deleteFile ZipException
In-Reply-To: <nyT0VApFvwWtkRnpbAJXbsDUxsL4xzGbHNuYsNZTbkc=.40ded7f1-3830-4816-bac1-d76be26de687@github.com>
References: <nyT0VApFvwWtkRnpbAJXbsDUxsL4xzGbHNuYsNZTbkc=.40ded7f1-3830-4816-bac1-d76be26de687@github.com>
Message-ID: <iuzPxX8UmAizWtyohtciTNYHV17kZFHLa8cseWflYwE=.1ee03310-4084-4efa-b7ba-c627b363ac83@github.com>

On Tue, 16 Feb 2021 13:48:20 GMT, Simon Legner <github.com+782446+simon04 at openjdk.org> wrote:

> 8264031: Fix typo in ZipFileSystem.deleteFile ZipException

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2588

From pconcannon at openjdk.java.net  Thu Mar 25 11:18:08 2021
From: pconcannon at openjdk.java.net (Patrick Concannon)
Date: Thu, 25 Mar 2021 11:18:08 GMT
Subject: RFR: 8263668: Update java.time to use instanceof pattern variable
 [v2]
In-Reply-To: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
References: <zrMmeF7bgzg9K9ijr_otaozUYO5kPm3iQGxMDHfWJc8=.da69bbc3-80a7-4dfe-99ed-e9a67597b6aa@github.com>
Message-ID: <hFla6TFxNWyQzHAQWBeT3KY59ImtCMfBVoJW4jJpO2E=.4ec483e2-dd29-4551-8ff8-b260b53c2b12@github.com>

> Hi,
> 
> Could someone please review my code for updating the code in the `java.time` package to make use of the `instanceof` pattern variable?
> 
> Kind regards,
> Patrick

Patrick Concannon has updated the pull request with a new target base 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 remote-tracking branch 'origin/master' into JDK-8263668
 - Merge remote-tracking branch 'origin/master' into JDK-8263668
 - 8263668: Update java.time to use instanceof pattern variable

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3170/files
  - new: https://git.openjdk.java.net/jdk/pull/3170/files/43a57378..b72e658e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3170&range=00-01

  Stats: 4370 lines in 292 files changed: 2129 ins; 651 del; 1590 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3170.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3170/head:pull/3170

PR: https://git.openjdk.java.net/jdk/pull/3170

From asemenyuk at openjdk.java.net  Thu Mar 25 13:41:48 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 25 Mar 2021 13:41:48 GMT
Subject: RFR: 8264165: jpackage BasicTest fails after JDK-8220266: Check help
 text contains plaform specific parameters
Message-ID: <zB4TY97sarjX8LZqzTbuZNu0O5huyDDhVr_OV3cTCcY=.68e2acc3-8789-4998-b2d7-0394f7f39394@github.com>

Add missing escape single quote (') and typo fix

-------------

Commit messages:
 - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters

Changes: https://git.openjdk.java.net/jdk/pull/3193/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3193&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264165
  Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3193.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3193/head:pull/3193

PR: https://git.openjdk.java.net/jdk/pull/3193

From herrick at openjdk.java.net  Thu Mar 25 14:04:27 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 25 Mar 2021 14:04:27 GMT
Subject: RFR: 8264165: jpackage BasicTest fails after JDK-8220266: Check
 help text contains plaform specific parameters
In-Reply-To: <zB4TY97sarjX8LZqzTbuZNu0O5huyDDhVr_OV3cTCcY=.68e2acc3-8789-4998-b2d7-0394f7f39394@github.com>
References: <zB4TY97sarjX8LZqzTbuZNu0O5huyDDhVr_OV3cTCcY=.68e2acc3-8789-4998-b2d7-0394f7f39394@github.com>
Message-ID: <-rl40TFbr1DDq7L7sowp8woIS-PUWS8PRjrcMthyhHU=.3581c148-299d-4f22-81d6-5b51d508398b@github.com>

On Thu, 25 Mar 2021 13:27:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add missing escape single quote (') and typo fix

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3193

From dcubed at openjdk.java.net  Thu Mar 25 15:08:24 2021
From: dcubed at openjdk.java.net (Daniel D.Daugherty)
Date: Thu, 25 Mar 2021 15:08:24 GMT
Subject: RFR: 8264165: jpackage BasicTest fails after JDK-8220266: Check
 help text contains plaform specific parameters
In-Reply-To: <zB4TY97sarjX8LZqzTbuZNu0O5huyDDhVr_OV3cTCcY=.68e2acc3-8789-4998-b2d7-0394f7f39394@github.com>
References: <zB4TY97sarjX8LZqzTbuZNu0O5huyDDhVr_OV3cTCcY=.68e2acc3-8789-4998-b2d7-0394f7f39394@github.com>
Message-ID: <-hClCUaGT0-Cw_yCRW111sQf7SzISQphMWRXIwh0NeA=.3283f894-18ea-41d1-85e3-33599753e572@github.com>

On Thu, 25 Mar 2021 13:27:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add missing escape single quote (') and typo fix

The original change in JDK-8220266 shows the introduction
of three single quotes and this fix addresses all three along
with another typo.

Thumbs up.

-------------

Marked as reviewed by dcubed (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3193

From asemenyuk at openjdk.java.net  Thu Mar 25 15:27:26 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 25 Mar 2021 15:27:26 GMT
Subject: Integrated: 8264165: jpackage BasicTest fails after JDK-8220266:
 Check help text contains plaform specific parameters
In-Reply-To: <zB4TY97sarjX8LZqzTbuZNu0O5huyDDhVr_OV3cTCcY=.68e2acc3-8789-4998-b2d7-0394f7f39394@github.com>
References: <zB4TY97sarjX8LZqzTbuZNu0O5huyDDhVr_OV3cTCcY=.68e2acc3-8789-4998-b2d7-0394f7f39394@github.com>
Message-ID: <fMTbAvRvRl7syjALu0vIBdK1aKd8pyFuGmW7p2eaxjA=.ed20813d-37b3-4eb1-90fa-42f7c8a77c99@github.com>

On Thu, 25 Mar 2021 13:27:45 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Add missing escape single quote (') and typo fix

This pull request has now been integrated.

Changeset: 8307aa6d
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8307aa6d
Stats:     4 lines in 4 files changed: 0 ins; 0 del; 4 mod

8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters

Reviewed-by: herrick, dcubed

-------------

PR: https://git.openjdk.java.net/jdk/pull/3193

From jlaskey at openjdk.java.net  Thu Mar 25 17:13:51 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 25 Mar 2021 17:13:51 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v36]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <VCaKFBicStpews5jcPMqMsyimtRfMcdbVYbSor1p2AY=.4ab20f6d-ac58-4aaf-adf0-c4f7160168cf@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  CSR review updates

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/22ea21d2..be9536ce

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=35
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=34-35

  Stats: 12 lines in 2 files changed: 6 ins; 2 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

PR: https://git.openjdk.java.net/jdk/pull/1292

From naoto at openjdk.java.net  Thu Mar 25 17:53:38 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 25 Mar 2021 17:53:38 GMT
Subject: RFR: 8262110: DST starts from incorrect time in 2038
Message-ID: <EMl1RAfjTfftzQCREsPNQlurue7qly6B_k1mHJCdO94=.e10e693d-dcc9-46e3-839a-554eadd55757@github.com>

Please review the fix to the DST transition bug after the year 2037. The logic had the side effect that it adjusted the dst offset every time the method `getOffsets()` is issued. Only adjust the offset when issued with wall time.

-------------

Commit messages:
 - Set time zone to the formatter.
 - Added eof
 - Added a test case for 8073446
 - 8262110: DST starts from incorrect time in 2038

Changes: https://git.openjdk.java.net/jdk/pull/3165/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3165&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8262110
  Stats: 75 lines in 2 files changed: 73 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3165.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3165/head:pull/3165

PR: https://git.openjdk.java.net/jdk/pull/3165

From akozlov at openjdk.java.net  Thu Mar 25 18:14:06 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 25 Mar 2021 18:14:06 GMT
Subject: Integrated: 8253795: Implementation of JEP 391: macOS/AArch64 Port
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <n4vzkDG9kXNf_qMitLPTjoo8F7Zxd2W6FwBS2P-v5WA=.d5639e5b-2912-4d6f-9b8a-1f1bf79669a7@github.com>

On Fri, 22 Jan 2021 18:49:42 GMT, Anton Kozlov <akozlov at openjdk.org> wrote:

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

This pull request has now been integrated.

Changeset: dbc9e4b5
Author:    Anton Kozlov <akozlov at openjdk.org>
Committer: Vladimir Kempik <vkempik at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dbc9e4b5
Stats:     2960 lines in 75 files changed: 2851 ins; 27 del; 82 mod

8253795: Implementation of JEP 391: macOS/AArch64 Port
8253816: Support macOS W^X
8253817: Support macOS Aarch64 ABI in Interpreter
8253818: Support macOS Aarch64 ABI for compiled wrappers
8253819: Implement os/cpu for macOS/AArch64
8253839: Update tests and JDK code for macOS/Aarch64
8254941: Implement Serviceability Agent for macOS/AArch64
8255776: Change build system for macOS/AArch64
8262903: [macos_aarch64] Thread::current() called on detached thread

Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Thu Mar 25 18:14:03 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 25 Mar 2021 18:14:03 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v30]
In-Reply-To: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
Message-ID: <Jrz4tirzLXG971FqxgjEXuaXq0W2bgIfFIdmHi7iTxE=.5f3847bc-e82d-49b7-829d-b160167e6ef2@github.com>

> Please review the implementation of JEP 391: macOS/AArch64 Port.
> 
> It's heavily based on existing ports to linux/aarch64, macos/x86_64, and windows/aarch64. 
> 
> Major changes are in:
> * src/hotspot/cpu/aarch64: support of the new calling convention (subtasks JDK-8253817, JDK-8253818)
> * src/hotspot/os_cpu/bsd_aarch64: copy of os_cpu/linux_aarch64 with necessary adjustments (JDK-8253819)
> * src/hotspot/share, test/hotspot/gtest: support of write-xor-execute (W^X), required on macOS/AArch64 platform. It's implemented with pthread_jit_write_protect_np provided by Apple. The W^X mode is local to a thread, so W^X mode change relates to the java thread state change (for java threads). In most cases, JVM executes in write-only mode, except when calling a generated stub like SafeFetch, which requires a temporary switch to execute-only mode. The same execute-only mode is enabled when a java thread executes in java or native states. This approach of managing W^X mode turned out to be simple and efficient enough.
> * src/jdk.hotspot.agent: serviceability agent implementation (JDK-8254941)

Anton Kozlov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 117 commits:

 - JDK-8261397: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Merge branch 'master' into jdk-macos
 - JDK-8262491: bsd_aarch64 part
 - JDK-8263002: bsd_aarch64 part
 - Merge remote-tracking branch 'upstream/jdk/master' into jdk-macos
 - Wider #ifdef block
 - Fix most of issues in java/foreign/ tests
   
   Failures related to va_args are tracked in JDK-8263512.
 - Add Azul copyright
 - Update Oracle copyright years
 - ... and 107 more: https://git.openjdk.java.net/jdk/compare/b006f22f...d3629967

-------------

Changes: https://git.openjdk.java.net/jdk/pull/2200/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=2200&range=29
  Stats: 2960 lines in 75 files changed: 2851 ins; 27 del; 82 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2200/head:pull/2200

PR: https://git.openjdk.java.net/jdk/pull/2200

From akozlov at openjdk.java.net  Thu Mar 25 18:14:03 2021
From: akozlov at openjdk.java.net (Anton Kozlov)
Date: Thu, 25 Mar 2021 18:14:03 GMT
Subject: RFR: 8253795: Implementation of JEP 391: macOS/AArch64 Port [v29]
In-Reply-To: <HVuUWfsnr8fqATnVU2b4S7VdSOwuKg1xxEZW-islB2g=.56d118c4-745d-4371-91a9-3bb250c9b7a3@github.com>
References: <MPpncRa-2UthpEPAIsGGhKNU5lQP8KSRUacPjD-QhpY=.48ea5f8a-269b-4db9-813d-43dcb1427613@github.com>
 <CUAQ2DG86yoo-Blum6Au7vVN_4QTEVI2FS9UTHC2xKg=.1d1aaf5d-1a81-41d3-88eb-786741fbf1e9@github.com>
 <RIXlvES_OOQ47-4YI1CLX7kLG4JJ70NRr0g0G0X6zb0=.4a106aa2-8e76-4b5a-9206-cebc6f17472e@github.com>
 <HVuUWfsnr8fqATnVU2b4S7VdSOwuKg1xxEZW-islB2g=.56d118c4-745d-4371-91a9-3bb250c9b7a3@github.com>
Message-ID: <AZT2E7ZueFv02oR3VekvtEzPUeXZ9gYvzBo-9ImCMqg=.4e988c58-da72-4824-b86e-10c6b035b17a@github.com>

On Tue, 23 Mar 2021 16:33:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Marked as reviewed by luhenry (Author).
>
>> > > > [ Back-porting this patch to JDK 11] depends on the will of openjdk11 maintainers to accept this (and few other, like jep-388, as we depend on it) contribution.
>> > > 
>> > > 
>> > > To the extent that 11u has fixed policies :) we definitely have a policy of accepting patches to keep 11u working on current hardware. So yes.
>> > 
>> > 
>> > @lewurm That sounds like a green flag for you and jep-388 (with its R18_RESERVED functionality) ;)
>> 
>> Thanks, @theRealAph, and @VladimirKempik . We are on it!
> 
> It's going to be tricky to do in a really clean way, given some of the weirdnesses of the ABI. However, I think there's probably a need for it

The JEP was targeted to JDK17. So I propose to integrate this. 

Thank you all for the reviews, suggestions, discussions, and support!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2200

From darcy at openjdk.java.net  Thu Mar 25 19:36:32 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 25 Mar 2021 19:36:32 GMT
Subject: RFR: 8264161: BigDecimal#stripTrailingZeros can throw undocumented
 ArithmeticException
Message-ID: <u_9qYkeBPdMkiKzN2VXk3PpcuUCqVGxjY1EuQH2RFMs=.ea483c56-056f-402b-826f-aa5e70030508@github.com>

While some of the existing text in BigDecimal could be read as implying exponent overflow/underflow will throw an ArithmeticException, it is reasonable to simply state that explicitly.

The next text is meant to cover the usage of the checkScale family of methods.

I'll reflow the existing paragraph once the text is agreed to.

-------------

Commit messages:
 - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException

Changes: https://git.openjdk.java.net/jdk/pull/3204/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3204&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264161
  Stats: 7 lines in 1 file changed: 5 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3204.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3204/head:pull/3204

PR: https://git.openjdk.java.net/jdk/pull/3204

From bpb at openjdk.java.net  Thu Mar 25 19:42:26 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 25 Mar 2021 19:42:26 GMT
Subject: RFR: 8264161: BigDecimal#stripTrailingZeros can throw
 undocumented ArithmeticException
In-Reply-To: <u_9qYkeBPdMkiKzN2VXk3PpcuUCqVGxjY1EuQH2RFMs=.ea483c56-056f-402b-826f-aa5e70030508@github.com>
References: <u_9qYkeBPdMkiKzN2VXk3PpcuUCqVGxjY1EuQH2RFMs=.ea483c56-056f-402b-826f-aa5e70030508@github.com>
Message-ID: <-HYtmGQ1ehQ4HYdSBD7Lvsltc8ZrvoXMXl9Ri2Tut9g=.4f70b4d3-899b-4ede-a48d-0abbd2498233@github.com>

On Thu, 25 Mar 2021 19:30:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> While some of the existing text in BigDecimal could be read as implying exponent overflow/underflow will throw an ArithmeticException, it is reasonable to simply state that explicitly.
> 
> The next text is meant to cover the usage of the checkScale family of methods.
> 
> I'll reflow the existing paragraph once the text is agreed to.

src/java.base/share/classes/java/math/BigDecimal.java line 200:

> 198:  * but bounded. If the scale of a result would exceed the range of a
> 199:  * 32-bit integer, either by overflow or underflow, the operation may
> 200:  * throw {@code ArithmeticException}.

Do we need an indefinite article here, e.g., `throw an`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3204

From darcy at openjdk.java.net  Thu Mar 25 19:55:44 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 25 Mar 2021 19:55:44 GMT
Subject: RFR: 8264161: BigDecimal#stripTrailingZeros can throw
 undocumented ArithmeticException [v2]
In-Reply-To: <u_9qYkeBPdMkiKzN2VXk3PpcuUCqVGxjY1EuQH2RFMs=.ea483c56-056f-402b-826f-aa5e70030508@github.com>
References: <u_9qYkeBPdMkiKzN2VXk3PpcuUCqVGxjY1EuQH2RFMs=.ea483c56-056f-402b-826f-aa5e70030508@github.com>
Message-ID: <ytmBfPL-Hl1taLjxs2vuvu34eeuZqG6hXqoAJE4nVko=.7011408e-9a16-4c4c-bc13-a9bd11b32d73@github.com>

> While some of the existing text in BigDecimal could be read as implying exponent overflow/underflow will throw an ArithmeticException, it is reasonable to simply state that explicitly.
> 
> The next text is meant to cover the usage of the checkScale family of methods.
> 
> I'll reflow the existing paragraph once the text is agreed to.

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.java.net/jdk/pull/3204/files
  - new: https://git.openjdk.java.net/jdk/pull/3204/files/05ed1753..f427ba56

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3204&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3204&range=00-01

  Stats: 12 lines in 1 file changed: 0 ins; 1 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3204.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3204/head:pull/3204

PR: https://git.openjdk.java.net/jdk/pull/3204

From rriggs at openjdk.java.net  Thu Mar 25 20:15:35 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 25 Mar 2021 20:15:35 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static
Message-ID: <vgld966LDtRNI2RDlfmRq5CSrS5T5-MOSAr7vCTf_hE=.3de9cbb9-c1b5-49a6-a8c0-38d78a3ee6e2@github.com>

A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.

These  APIs were added early in JDK 17 and are being updated before GA.
This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.

   public boolean isHexDigit(int);
   public int fromHexDigit(int);
   public int fromHexDigits(java.lang.CharSequence);
   public int fromHexDigits(java.lang.CharSequence, int, int);
   public long fromHexDigitsToLong(java.lang.CharSequence);
   public long fromHexDigitsToLong(java.lang.CharSequence, int, int);

-------------

Commit messages:
 - 8263754: HexFormat 'fromHex' methods should be static

Changes: https://git.openjdk.java.net/jdk/pull/3205/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3205&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8263754
  Stats: 47 lines in 5 files changed: 0 ins; 8 del; 39 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3205.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3205/head:pull/3205

PR: https://git.openjdk.java.net/jdk/pull/3205

From kcr at openjdk.java.net  Thu Mar 25 20:19:27 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 25 Mar 2021 20:19:27 GMT
Subject: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <8Vo0sYp5M4FNk6DKP2URAChl60rTHV-MpMsSUQi0-Nk=.c1f6ac22-cc67-4072-8d75-80032979db2f@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

src/java.desktop/share/classes/java/applet/package-info.java line 39:

> 37:  * applet development environment.
> 38:  * <p>
> 39:  * @deprecated.  This package has been deprecated and may be removed in

Package declarations cannot have `@deprecated` tags, so `make docs` fails with this change. Also, since there is a tag here, the previous `<p>` is now empty and causes a warning. Both problems will be fixed by removing the `@deprecated` tag, while leaving the added text.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2920

From bpb at openjdk.java.net  Thu Mar 25 20:47:28 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 25 Mar 2021 20:47:28 GMT
Subject: RFR: 8264161: BigDecimal#stripTrailingZeros can throw
 undocumented ArithmeticException [v2]
In-Reply-To: <ytmBfPL-Hl1taLjxs2vuvu34eeuZqG6hXqoAJE4nVko=.7011408e-9a16-4c4c-bc13-a9bd11b32d73@github.com>
References: <u_9qYkeBPdMkiKzN2VXk3PpcuUCqVGxjY1EuQH2RFMs=.ea483c56-056f-402b-826f-aa5e70030508@github.com>
 <ytmBfPL-Hl1taLjxs2vuvu34eeuZqG6hXqoAJE4nVko=.7011408e-9a16-4c4c-bc13-a9bd11b32d73@github.com>
Message-ID: <howC2VmVHBgznhdPA3b-qzvpwjvXUHBYtm5apB355cQ=.c245544b-54e7-4a2f-b3a3-a164c8ae2535@github.com>

On Thu, 25 Mar 2021 19:55:44 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> While some of the existing text in BigDecimal could be read as implying exponent overflow/underflow will throw an ArithmeticException, it is reasonable to simply state that explicitly.
>> 
>> The next text is meant to cover the usage of the checkScale family of methods.
>> 
>> I'll reflow the existing paragraph once the text is agreed to.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3204

From darcy at openjdk.java.net  Thu Mar 25 20:47:29 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 25 Mar 2021 20:47:29 GMT
Subject: Integrated: 8264161: BigDecimal#stripTrailingZeros can throw
 undocumented ArithmeticException
In-Reply-To: <u_9qYkeBPdMkiKzN2VXk3PpcuUCqVGxjY1EuQH2RFMs=.ea483c56-056f-402b-826f-aa5e70030508@github.com>
References: <u_9qYkeBPdMkiKzN2VXk3PpcuUCqVGxjY1EuQH2RFMs=.ea483c56-056f-402b-826f-aa5e70030508@github.com>
Message-ID: <72L4_HOJjB85M4rNoPRSXjHlRvaF7wcwWENKxVcOY8Y=.2325b073-39f7-4526-a197-aee3ec9ff0d5@github.com>

On Thu, 25 Mar 2021 19:30:01 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> While some of the existing text in BigDecimal could be read as implying exponent overflow/underflow will throw an ArithmeticException, it is reasonable to simply state that explicitly.
> 
> The next text is meant to cover the usage of the checkScale family of methods.
> 
> I'll reflow the existing paragraph once the text is agreed to.

This pull request has now been integrated.

Changeset: 25931966
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/25931966
Stats:     17 lines in 1 file changed: 5 ins; 2 del; 10 mod

8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException

Reviewed-by: bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/3204

From redestad at openjdk.java.net  Thu Mar 25 21:18:31 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 25 Mar 2021 21:18:31 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static
In-Reply-To: <vgld966LDtRNI2RDlfmRq5CSrS5T5-MOSAr7vCTf_hE=.3de9cbb9-c1b5-49a6-a8c0-38d78a3ee6e2@github.com>
References: <vgld966LDtRNI2RDlfmRq5CSrS5T5-MOSAr7vCTf_hE=.3de9cbb9-c1b5-49a6-a8c0-38d78a3ee6e2@github.com>
Message-ID: <VHtWIM-ySrPwUPOG08vyaKrjIiiY8RiAMQhPJI81VzI=.8b1763e7-ebf0-411a-98f4-050439960c26@github.com>

On Thu, 25 Mar 2021 20:08:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.
> 
> These  APIs were added early in JDK 17 and are being updated before GA.
> This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.
> 
>    public boolean isHexDigit(int);
>    public int fromHexDigit(int);
>    public int fromHexDigits(java.lang.CharSequence);
>    public int fromHexDigits(java.lang.CharSequence, int, int);
>    public long fromHexDigitsToLong(java.lang.CharSequence);
>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);

I like the direction. There are a number of orphaned HexFormat instances that can be cleaned up. I might have missed a few. 

Do you intend to do the same thing with the toHexDigit methods?

src/java.base/share/classes/sun/security/provider/certpath/RevocationChecker.java line 822:

> 820:         StringBuilder hexNumber = new StringBuilder();
> 821:         for (int i = 0; i < chars.length; i++) {
> 822:             if (HexFormat.isHexDigit(chars[i])) {

`hex` left unused.

src/java.base/share/classes/sun/security/tools/keytool/Main.java line 4582:

> 4580:                             int pos = 0;
> 4581:                             for (char c: value.toCharArray()) {
> 4582:                                 if (!HexFormat.isHexDigit(c)) {

`hexFmt` created on line 4576 appears to be unused after this.

src/java.base/share/classes/sun/security/x509/AVA.java line 504:

> 502:         throws IOException {
> 503: 
> 504:         HexFormat hex = HexFormat.of();

`hex` left unused.

-------------

Changes requested by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3205

From naoto at openjdk.java.net  Thu Mar 25 21:49:26 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 25 Mar 2021 21:49:26 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static
In-Reply-To: <vgld966LDtRNI2RDlfmRq5CSrS5T5-MOSAr7vCTf_hE=.3de9cbb9-c1b5-49a6-a8c0-38d78a3ee6e2@github.com>
References: <vgld966LDtRNI2RDlfmRq5CSrS5T5-MOSAr7vCTf_hE=.3de9cbb9-c1b5-49a6-a8c0-38d78a3ee6e2@github.com>
Message-ID: <XphWJO-lERsNcYPscxfUjM1e-4xt0i0HPbabasqJqJQ=.2279ecaa-2390-4aad-92f2-e25896916ee8@github.com>

On Thu, 25 Mar 2021 20:08:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.
> 
> These  APIs were added early in JDK 17 and are being updated before GA.
> This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.
> 
>    public boolean isHexDigit(int);
>    public int fromHexDigit(int);
>    public int fromHexDigits(java.lang.CharSequence);
>    public int fromHexDigits(java.lang.CharSequence, int, int);
>    public long fromHexDigitsToLong(java.lang.CharSequence);
>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);

Looks good (with the suggestions by Claes).

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3205

From rriggs at openjdk.java.net  Thu Mar 25 21:53:28 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 25 Mar 2021 21:53:28 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static
In-Reply-To: <VHtWIM-ySrPwUPOG08vyaKrjIiiY8RiAMQhPJI81VzI=.8b1763e7-ebf0-411a-98f4-050439960c26@github.com>
References: <vgld966LDtRNI2RDlfmRq5CSrS5T5-MOSAr7vCTf_hE=.3de9cbb9-c1b5-49a6-a8c0-38d78a3ee6e2@github.com>
 <VHtWIM-ySrPwUPOG08vyaKrjIiiY8RiAMQhPJI81VzI=.8b1763e7-ebf0-411a-98f4-050439960c26@github.com>
Message-ID: <BU8VU46rUlqfSGDy-t2tQABY8L9u8ivDyfpKq9__f7s=.59ac1ece-507d-48e4-8e7f-3b83184e3d5a@github.com>

On Thu, 25 Mar 2021 21:05:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.
>> 
>> These  APIs were added early in JDK 17 and are being updated before GA.
>> This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.
>> 
>>    public boolean isHexDigit(int);
>>    public int fromHexDigit(int);
>>    public int fromHexDigits(java.lang.CharSequence);
>>    public int fromHexDigits(java.lang.CharSequence, int, int);
>>    public long fromHexDigitsToLong(java.lang.CharSequence);
>>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);
>
> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 4582:
> 
>> 4580:                             int pos = 0;
>> 4581:                             for (char c: value.toCharArray()) {
>> 4582:                                 if (!HexFormat.isHexDigit(c)) {
> 
> `hexFmt` created on line 4576 appears to be unused after this.

The toHexDigit methods need access to the uppercase/lowercase distinction.
So there is no plan to change them.
I'll amend to include the above and re-check for uncaught uses.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3205

From redestad at openjdk.java.net  Thu Mar 25 22:49:26 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 25 Mar 2021 22:49:26 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static
In-Reply-To: <BU8VU46rUlqfSGDy-t2tQABY8L9u8ivDyfpKq9__f7s=.59ac1ece-507d-48e4-8e7f-3b83184e3d5a@github.com>
References: <vgld966LDtRNI2RDlfmRq5CSrS5T5-MOSAr7vCTf_hE=.3de9cbb9-c1b5-49a6-a8c0-38d78a3ee6e2@github.com>
 <VHtWIM-ySrPwUPOG08vyaKrjIiiY8RiAMQhPJI81VzI=.8b1763e7-ebf0-411a-98f4-050439960c26@github.com>
 <BU8VU46rUlqfSGDy-t2tQABY8L9u8ivDyfpKq9__f7s=.59ac1ece-507d-48e4-8e7f-3b83184e3d5a@github.com>
Message-ID: <9uIY69WYeuDY3CNtYqlCYe_axVevoxXNiCsEgTu0vBk=.68cb70dc-6ee8-4acc-a63e-f7e0a3486b26@github.com>

On Thu, 25 Mar 2021 21:50:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/tools/keytool/Main.java line 4582:
>> 
>>> 4580:                             int pos = 0;
>>> 4581:                             for (char c: value.toCharArray()) {
>>> 4582:                                 if (!HexFormat.isHexDigit(c)) {
>> 
>> `hexFmt` created on line 4576 appears to be unused after this.
>
> The toHexDigit methods need access to the uppercase/lowercase distinction.
> So there is no plan to change them.
> I'll amend to include the above and re-check for uncaught uses.

Hmm, I missed that unfortunate detail. It looks mis-matched to have `fromHex*` be static while `toHex*` variants aren't.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3205

From herrick at openjdk.java.net  Thu Mar 25 22:58:53 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 25 Mar 2021 22:58:53 GMT
Subject: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations
 [v2]
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 301 additional commits since the last revision:

 - 8189198: Add "forRemoval = true" to Applet API deprecations
 - Merge branch 'master' into 8189198
 - 8260862: JFR: New configure command for the jfr tool
   
   Reviewed-by: mgronlun
 - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
   
   Reviewed-by: bpb
 - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
   
   Reviewed-by: cjplummer, lmesnik, sspitsyn
 - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
   
   Reviewed-by: jnimeh
 - 8253795: Implementation of JEP 391: macOS/AArch64 Port
   8253816: Support macOS W^X
   8253817: Support macOS Aarch64 ABI in Interpreter
   8253818: Support macOS Aarch64 ABI for compiled wrappers
   8253819: Implement os/cpu for macOS/AArch64
   8253839: Update tests and JDK code for macOS/Aarch64
   8254941: Implement Serviceability Agent for macOS/AArch64
   8255776: Change build system for macOS/AArch64
   8262903: [macos_aarch64] Thread::current() called on detached thread
   
   Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
   Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
   Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
   Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
   Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
 - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
   
   Reviewed-by: adinn
 - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
   
   Reviewed-by: herrick, dcubed
 - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
   
   Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
 - ... and 291 more: https://git.openjdk.java.net/jdk/compare/ddfe8ec5...026f09c8

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2920/files
  - new: https://git.openjdk.java.net/jdk/pull/2920/files/1148f208..026f09c8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2920&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2920&range=00-01

  Stats: 64315 lines in 2948 files changed: 41333 ins; 13022 del; 9960 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2920.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2920/head:pull/2920

PR: https://git.openjdk.java.net/jdk/pull/2920

From herrick at openjdk.java.net  Thu Mar 25 22:58:53 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 25 Mar 2021 22:58:53 GMT
Subject: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations
 [v2]
In-Reply-To: <qiZi_Vbv_HUnvOdDXWkOYXX34-TZXgn5RfVZ10RKPbA=.2a14f73b-832e-4dbb-92c9-bee2ff7b62ec@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <Poh3115G7WmCJJa8gd0hy8ZEbFgWwOPD9RnNwHZkMME=.bfdc5752-dc35-416f-abb7-7a836b1a3607@github.com>
 <MJh1FiEuibiQtlniWggPXMakxTjQb00gKhZNrfEO92s=.1f736e09-c355-401d-aee0-de9c0e534cc5@github.com>
 <dAq_shzF02U7z3JlgBjqYs2l9DokroFkIVbulC18WQk=.ade138dc-9719-4fba-bc5f-bc6a2d744360@github.com>
 <fDHwQZqPpR9I3bBnnq67JsK1C55ItjUaig2dmaT3PAs=.1121b4e3-7c5b-4b50-8bdc-b0f4631510d9@github.com>
 <qiZi_Vbv_HUnvOdDXWkOYXX34-TZXgn5RfVZ10RKPbA=.2a14f73b-832e-4dbb-92c9-bee2ff7b62ec@github.com>
Message-ID: <tArFXdLPW8vkB0tQ-hZLGWSCFii-IBVY2md9t8TNSD8=.fcac7aad-39cc-4449-a046-6140be9cfbde@github.com>

On Wed, 17 Mar 2021 20:33:09 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>>> I cannot find any instances where the scope can be narrowed
>> 
>> Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?
>
>> 
>> 
>> > I cannot find any instances where the scope can be narrowed
>> 
>> Are you about AquaInternalFrameUI.mouseRelased, BasicPopupMenuUI. stateChanged, and other non-trivial methods?
> 
> These have the code pattern such as: 
> } else if (c instanceof JApplet) {
> putting '@SuppressWarnings("removal")' before the declaration of 'c' does not help, because the code is not an assignment to 'c'

pushed minor change to src/java.desktop/share/classes/java/applet/package-info.java as well as merge with master.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2920

From kcr at openjdk.java.net  Thu Mar 25 23:27:37 2021
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Thu, 25 Mar 2021 23:27:37 GMT
Subject: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations
 [v2]
In-Reply-To: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
Message-ID: <LC2l3Zo5eUjQhM6QcVCXZJ7PFh4op_NJSj15xFWPblg=.c02e5303-8b79-4ad8-bc4c-eab62698228f@github.com>

On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 301 additional commits since the last revision:
> 
>  - 8189198: Add "forRemoval = true" to Applet API deprecations
>  - Merge branch 'master' into 8189198
>  - 8260862: JFR: New configure command for the jfr tool
>    
>    Reviewed-by: mgronlun
>  - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
>    
>    Reviewed-by: bpb
>  - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
>    
>    Reviewed-by: cjplummer, lmesnik, sspitsyn
>  - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
>    
>    Reviewed-by: jnimeh
>  - 8253795: Implementation of JEP 391: macOS/AArch64 Port
>    8253816: Support macOS W^X
>    8253817: Support macOS Aarch64 ABI in Interpreter
>    8253818: Support macOS Aarch64 ABI for compiled wrappers
>    8253819: Implement os/cpu for macOS/AArch64
>    8253839: Update tests and JDK code for macOS/Aarch64
>    8254941: Implement Serviceability Agent for macOS/AArch64
>    8255776: Change build system for macOS/AArch64
>    8262903: [macos_aarch64] Thread::current() called on detached thread
>    
>    Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
>    Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
>    Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
>    Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
>    Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
>  - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
>    
>    Reviewed-by: adinn
>  - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
>    
>    Reviewed-by: herrick, dcubed
>  - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
>    
>    Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
>  - ... and 291 more: https://git.openjdk.java.net/jdk/compare/e2285595...026f09c8

Looks good.

-------------

Marked as reviewed by kcr (Author).

PR: https://git.openjdk.java.net/jdk/pull/2920

From egahlin at openjdk.java.net  Thu Mar 25 23:31:26 2021
From: egahlin at openjdk.java.net (Erik Gahlin)
Date: Thu, 25 Mar 2021 23:31:26 GMT
Subject: RFR: 8203359: Container level resources events
In-Reply-To: <32-BO7tExbAStlYsma_g-oc8kw-kj3HSyhJOP-qAjLk=.6c4d8c45-1a64-4b5a-8767-7307c297b3d8@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <32-BO7tExbAStlYsma_g-oc8kw-kj3HSyhJOP-qAjLk=.6c4d8c45-1a64-4b5a-8767-7307c297b3d8@github.com>
Message-ID: <guLUz-SeGYnE6_eRBBNQgyWIoC7XoemXN5iyGVHFlMU=.9e1ee611-1e1d-477d-bf7f-df29a93f7149@github.com>

On Wed, 24 Mar 2021 18:39:06 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> With this change it becomes possible to surface various cgroup level metrics (available via `jdk.internal.platform.Metrics`) as JFR events.
>> 
>> Only a subset of the metrics exposed by `jdk.internal.platform.Metrics` is turned into JFR events to start with.
>> * CPU related metrics
>> * Memory related metrics
>> * I/O related metrics
>> 
>> For each of those subsystems a configuration data will be emitted as well. The initial proposal is to emit the configuration data events at least once per chunk and the metrics values at 30 seconds interval. 
>> By using these values the emitted events seem to contain useful information without increasing overhead (the metrics values are read from `/proc` filesystem so that should not be done too frequently).
>
> @jbachorik Would it make sense for `ContainerConfigurationEvent` to include the underlying cgroup version info (v1 or legacy vs. v2 or unified)? `Metrics.getProvider()` should give that info.

Does each getter call result in parsing /proc, or do things aggregated over several calls or hooks?

Do you have any data how expensive the invocations are? 

You could for example try to measure it by temporary making the events durational, and fetch the values between begin() and end(), and perhaps show a 'jfr print --events Container* recording.jfr' printout. 

If possible, it would be interesting to get some idea about the startup cost as well

If not too much overhead, I think it would be nice to skip the "flag" in the .jfcs, and always record the events in a container environment.

I know there is a way to test JFR using Docker, maybe @mseledts could provide information? Some sanity tests would be good to have.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From iris at openjdk.java.net  Thu Mar 25 23:38:33 2021
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 25 Mar 2021 23:38:33 GMT
Subject: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations
 [v2]
In-Reply-To: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
Message-ID: <Ge5orwjsQQS4sJiLXFYz2nVh9v4HCBf1tz3WlVpSGlU=.f6a8deb3-c66a-4eea-b35e-76a82c2fbf73@github.com>

On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 301 additional commits since the last revision:
> 
>  - 8189198: Add "forRemoval = true" to Applet API deprecations
>  - Merge branch 'master' into 8189198
>  - 8260862: JFR: New configure command for the jfr tool
>    
>    Reviewed-by: mgronlun
>  - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
>    
>    Reviewed-by: bpb
>  - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
>    
>    Reviewed-by: cjplummer, lmesnik, sspitsyn
>  - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
>    
>    Reviewed-by: jnimeh
>  - 8253795: Implementation of JEP 391: macOS/AArch64 Port
>    8253816: Support macOS W^X
>    8253817: Support macOS Aarch64 ABI in Interpreter
>    8253818: Support macOS Aarch64 ABI for compiled wrappers
>    8253819: Implement os/cpu for macOS/AArch64
>    8253839: Update tests and JDK code for macOS/Aarch64
>    8254941: Implement Serviceability Agent for macOS/AArch64
>    8255776: Change build system for macOS/AArch64
>    8262903: [macos_aarch64] Thread::current() called on detached thread
>    
>    Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
>    Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
>    Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
>    Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
>    Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
>  - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
>    
>    Reviewed-by: adinn
>  - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
>    
>    Reviewed-by: herrick, dcubed
>  - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
>    
>    Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
>  - ... and 291 more: https://git.openjdk.java.net/jdk/compare/8fcfe0bd...026f09c8

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2920

From prr at openjdk.java.net  Thu Mar 25 23:51:33 2021
From: prr at openjdk.java.net (Phil Race)
Date: Thu, 25 Mar 2021 23:51:33 GMT
Subject: RFR: 8189198: Add "forRemoval = true" to Applet API deprecations
 [v2]
In-Reply-To: <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
 <-CtgNrXO36S532ldbcltqkgdva_l7Oaam8rBgC7yBQY=.b56cd831-56f3-4573-8a67-e4b835c677c9@github.com>
Message-ID: <rX_M7QysdLlKt6uprI4OE3kPj_x721_7gNHPw8Q52aQ=.952d1e25-d194-408d-a50d-b92cc8c5c7c4@github.com>

On Thu, 25 Mar 2021 22:58:53 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> implementation of
>> JDK-8256145: JEP 398: Deprecate the Applet API for Removal
>
> Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 301 additional commits since the last revision:
> 
>  - 8189198: Add "forRemoval = true" to Applet API deprecations
>  - Merge branch 'master' into 8189198
>  - 8260862: JFR: New configure command for the jfr tool
>    
>    Reviewed-by: mgronlun
>  - 8264161: BigDecimal#stripTrailingZeros can throw undocumented ArithmeticException
>    
>    Reviewed-by: bpb
>  - 8262081: vmTestbase/nsk/jdi/ThreadDeathRequest/addThreadFilter/addthreadfilter001/TestDescription.java failed with "ERROR: eventSet1.size() != 3 :: 2"
>    
>    Reviewed-by: cjplummer, lmesnik, sspitsyn
>  - 8261502: ECDHKeyAgreement: Allows alternate ECPrivateKey impl and revised exception handling
>    
>    Reviewed-by: jnimeh
>  - 8253795: Implementation of JEP 391: macOS/AArch64 Port
>    8253816: Support macOS W^X
>    8253817: Support macOS Aarch64 ABI in Interpreter
>    8253818: Support macOS Aarch64 ABI for compiled wrappers
>    8253819: Implement os/cpu for macOS/AArch64
>    8253839: Update tests and JDK code for macOS/Aarch64
>    8254941: Implement Serviceability Agent for macOS/AArch64
>    8255776: Change build system for macOS/AArch64
>    8262903: [macos_aarch64] Thread::current() called on detached thread
>    
>    Co-authored-by: Vladimir Kempik <vkempik at openjdk.org>
>    Co-authored-by: Bernhard Urban-Forster <burban at openjdk.org>
>    Co-authored-by: Ludovic Henry <luhenry at openjdk.org>
>    Co-authored-by: Monica Beckwith <mbeckwit at openjdk.org>
>    Reviewed-by: erikj, ihse, prr, cjplummer, stefank, gziemski, aph, mbeckwit, luhenry
>  - 4833719: (bf) Views of MappedByteBuffers are not MappedByteBuffers, and cannot be forced
>    
>    Reviewed-by: adinn
>  - 8264165: jpackage BasicTest fails after JDK-8220266: Check help text contains plaform specific parameters
>    
>    Reviewed-by: herrick, dcubed
>  - 8263454: com.apple.laf.AquaFileChooserUI ignores the result of String.trim()
>    
>    Reviewed-by: serb, pbansal, kizune, trebari, psadhukhan
>  - ... and 291 more: https://git.openjdk.java.net/jdk/compare/00b7b36f...026f09c8

Marked as reviewed by prr (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/2920

From lzang at openjdk.java.net  Fri Mar 26 02:17:26 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 26 Mar 2021 02:17:26 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts,
 use of optional GZIP fields [v3]
In-Reply-To: <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
 <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>
 <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
Message-ID: <TI04aLV2v1LDIZB33Kx-PgoCKoVQpXwvEah02OUrj_Q=.0bbc94a7-a0a5-492f-8081-52653a8bdd56@github.com>

On Wed, 24 Mar 2021 10:25:44 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi Lance?
>> Thanks a lot for your review. I will update the PR ASAP. 
>> May I ask your help to also review the CSR? Thanks!
>> 
>> BRs,
>> Lin
>
> Hi Lin,
> 
> On Mar 24, 2021, at 2:51 AM, Lin Zang ***@***.******@***.***>> wrote:
> 
> 
> 
> Hi Lance?
> Thanks a lot for your review. I will update the PR ASAP.
> May I ask your help to also review the CSR?
> 
> I believe we need to flush out some of the issues I raised that were not test related as they will result in updates to the javadoc which will require an update to the CSR.
> 
> 
> 
> Thanks!
> 
> BRs,
> Lin
> 
> ?
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub<https://github.com/openjdk/jdk/pull/3072#issuecomment-805549600>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABQPFO5R4INTAUFZ3QS6WL3TFGDXHANCNFSM4ZMLU6SA>.
> 
> ***@***.***
> 
> 
> 
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> ***@***.******@***.***>

Dear Lance?

Sorry that I reply so late, I got stuck at some work recently.

> * We should have tests that include some , but not all of the additional fields as I believe they are all optional according to the RFC.

I see Joe's comments in the CSR about the encode of the byte array of String-alike field such file name, I checked that the RFC has description it is "ISO8859-1". So do you think it is ok to change the argument type to String and add the encoding decription in the documented comments?

And Joe also suggested to make all optional header field as a class (I propose to name it "gzipHeaderMetaRecord" ). And then the constructor could accept it and process related flag and fields.  Moreover it seems this class cloud also be used in GzipInputStream?Do you think it is ok to also change it here?  Thanks!


BRs,
Lin

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

From lzang at openjdk.java.net  Fri Mar 26 02:40:28 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 26 Mar 2021 02:40:28 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts,
 use of optional GZIP fields [v3]
In-Reply-To: <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
Message-ID: <aO0OoafozlwJ2FWaLnpk_FByrDW22ICb0OCN9A7GFH4=.2613b267-7f24-48b4-8f39-6c4feb3eb89e@github.com>

On Mon, 22 Mar 2021 20:06:33 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update copyright
>>  - reuse arguments constructor for non-argument one.
>
> src/java.base/share/classes/java/util/zip/GZIPOutputStream.java line 320:
> 
>> 318:              *     +---+---+=================================+
>> 319:              */
>> 320:             int xlen = extraFieldBytes.length;
> 
> On a quick look at the RFC,  I noticed the following:
> 
> ------------------------
> 2.3.1.1. Extra field
> 
>          If the FLG.FEXTRA bit is set, an "extra field" is present in
>          the header, with total length XLEN bytes.  It consists of a
>          series of subfields, each of the form:
> 
>             +---+---+---+---+==================================+
>             |SI1|SI2|  LEN  |... LEN bytes of subfield data ...|
>             +---+---+---+---+==================================+
> 
>          SI1 and SI2 provide a subfield ID, typically two ASCII letters
>          with some mnemonic value.  Jean-Loup Gailly
>          <gzip at prep.ai.mit.edu> is maintaining a registry of subfield
>          IDs; please send him any subfield ID you wish to use.  Subfield
>          IDs with SI2 = 0 are reserved for future use.  The following
>          IDs are currently defined:
> 
> 
> ---------------
> 
> This does not seem to be accounted for or is it?

Yes, This should be considered, I will add logic in the code. 
However, I did some search and found that there is only one subfield defined, which is mentioned in RFC:
SI1         SI2         Data
----------  ----------  ----
0x41 ('A')  0x70 ('P')  Apollo file type information

or SI2 = 0  is reserved.

It seems this subfield definition is no longe maintained. (FYI, https://stackoverflow.com/questions/65188890/what-gzip-extra-field-subfields-exist) 

So is it ok if make it only accept these two cases for FLG.FEXTRA and reject others?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

From lzang at openjdk.java.net  Fri Mar 26 02:46:25 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 26 Mar 2021 02:46:25 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts,
 use of optional GZIP fields [v3]
In-Reply-To: <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
Message-ID: <9F9tRwRWWG5GFMfYoVP7TH-Rsq4a1Jr80450YhvarqQ=.bdc57670-71fc-482e-ae07-3d549250695f@github.com>

On Mon, 22 Mar 2021 20:15:38 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> on operating systems using
>         EBCDIC or any other character set for file names, the name
>         must be translated to the ISO LATIN-1 character set.  This
>         is the original name of the file being compressed, with any
>         directory components removed, and, if the file being
>         compressed is on a file system with case insensitive names,
>         forced to lower case. There is no original file name if the
>         data was compressed from a source other than a named file;
>         for example, if the source was stdin on a Unix system, there
>         is no file name.

IMHO, this looks much like the rule that user should take care of,  I think here we only need to accept a String and decode it with "ISO-8859-1" to byte array then write to the header.  Is this reasonable?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

From lzang at openjdk.java.net  Fri Mar 26 02:54:28 2021
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 26 Mar 2021 02:54:28 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts,
 use of optional GZIP fields [v3]
In-Reply-To: <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
Message-ID: <nGmttD1jfTzWNRBSHNcs0cA7T_MxYRZZf8uq1enqT6E=.4f2aa0f5-3bdd-4b6d-803e-fe49165bd58f@github.com>

On Mon, 22 Mar 2021 20:18:37 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Lin Zang has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update copyright
>>  - reuse arguments constructor for non-argument one.
>
> src/java.base/share/classes/java/util/zip/GZIPOutputStream.java line 357:
> 
>> 355:              */
>> 356:             out.write(fileComment);
>> 357:             out.write(0);
> 
> The RFC states:
> 
>             If FCOMMENT is set, a zero-terminated file comment is
>             present.  This comment is not interpreted; it is only
>             intended for human consumption.  The comment must consist of
>             ISO 8859-1 (LATIN-1) characters.  Line breaks should be
>             denoted by a single line feed character (10 decimal).
> 
> 
> So should the characters be validates as well as line breaks?

Same as file name , I think it is the users responsibility to pass the right encoded String as an argument. if constructor is designed to accept a String here, I think it can decode to byte array with ISO 8859-1, and then write to the header.

Moreover?I can't figure out a way to testing the encoding information of the String, do you have any clue about validate it?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

From sgehwolf at openjdk.java.net  Fri Mar 26 11:08:25 2021
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 26 Mar 2021 11:08:25 GMT
Subject: RFR: 8203359: Container level resources events
In-Reply-To: <guLUz-SeGYnE6_eRBBNQgyWIoC7XoemXN5iyGVHFlMU=.9e1ee611-1e1d-477d-bf7f-df29a93f7149@github.com>
References: <cH-j0-G1pyU3kuPKTblCrlSYkss_l3inKPcoVZXZOvc=.a3dc8e7b-f09d-4a31-a0f8-acf3875deb96@github.com>
 <32-BO7tExbAStlYsma_g-oc8kw-kj3HSyhJOP-qAjLk=.6c4d8c45-1a64-4b5a-8767-7307c297b3d8@github.com>
 <guLUz-SeGYnE6_eRBBNQgyWIoC7XoemXN5iyGVHFlMU=.9e1ee611-1e1d-477d-bf7f-df29a93f7149@github.com>
Message-ID: <kfY9mi-n8TsPGlK_QctCmtzxsgr0bs5VrGxepAtI4xc=.549f72df-9639-4d3c-a9d6-40d2aab1509f@github.com>

On Thu, 25 Mar 2021 23:28:18 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Does each getter call result in parsing /proc, or do things aggregated over several calls or hooks?

>From the looks of it the event emitting code uses `Metrics.java` interface for retrieving the info. Each call to a method exposed by Metrics result in file IO on some cgroup (v1 or v2) interface file(s) in `/sys/fs/...`. I don't see any aggregation being done.

On the hotspot side, we implemented some caching for frequent calls (JDK-8232207, JDK-8227006), but we didn't do that yet for the Java side since there wasn't any need (so far). If calls are becoming frequent with this it should be reconsidered.

So +1 on getting some data on what the perf penalty of this is.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3126

From alexsch at openjdk.java.net  Fri Mar 26 11:21:29 2021
From: alexsch at openjdk.java.net (Alexander Scherbatiy)
Date: Fri, 26 Mar 2021 11:21:29 GMT
Subject: RFR: 8263968: CDS: java/lang/ModuleLayer.EMPTY_LAYER should be
 singleton [v2]
In-Reply-To: <5ddGQm8sn2u7O1sUIRV89eoBMVHjmIyrGHhrDXUJwNY=.df28dbeb-65e1-4c9d-8383-64557d028487@github.com>
References: <l5rkIui2BaK2eXu8uem2mQcbzi2Lyo6HdTR5kLno44U=.260f6472-70e5-41a3-a2fe-dd6d5943954f@github.com>
 <C6roaR7ZxyPk0pJIPt2arP5KpOsVzIO8KF0uXfrv9Lw=.a4b75f9a-3da1-4df9-a0a5-1ad7880d209c@github.com>
 <5ddGQm8sn2u7O1sUIRV89eoBMVHjmIyrGHhrDXUJwNY=.df28dbeb-65e1-4c9d-8383-64557d028487@github.com>
Message-ID: <WWsKW9ABiCetWgOlnMJPRtcluavEyiwDXJLFb4HfQ90=.138ff26a-ec36-45ca-9454-113204b4ada4@github.com>

On Wed, 24 Mar 2021 16:31:20 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Aleksei Voitylov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix style
>
> Looks good. The need to retain singleton/identity semantics of constants like this when archiving in CDS has bitten us in the past.

> Unknown command `backport` - for a list of valid commands use `/help`.

There is the description on the SKARA/Backports page: https://wiki.openjdk.java.net/display/SKARA/Backports
Backport Commit Command

The /backport commit command can be used to quickly create a backport pull request for a given commit.
Just navigate to the comment in source code hosting provider's web UI and add a comment 
consisting of "/backport <repo>". 
If the commit does not apply clean on the target repository then a message
will be shown for the files with conflicts.

The `The /backport commit command ` link points to: https://wiki.openjdk.java.net/display/SKARA/Commit+Commands#CommitCommands-/backport
Commit Commands

Syntax

Description

Applies the commit onto the given branch in the given repository and then shows to a link to create a pull request with
the changes. The branch is optional and defaults to the master branch. If the commit does not apply 
then an message is shown describing the files containing conflicts.

Examples



What is the right way to create a backport to jdk16u?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3131

From jlaskey at openjdk.java.net  Fri Mar 26 12:25:43 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 26 Mar 2021 12:25:43 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v37]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <b3NvYC-c_euRkQGixw9-EhAuGxh7VJgagcZNvXsRqi0=.3586e6c4-fae0-4b5d-b310-4cde2b0cef7f@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  CSR review revisions

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/be9536ce..84cc93fa

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=36
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=35-36

  Stats: 15 lines in 2 files changed: 4 ins; 6 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

PR: https://git.openjdk.java.net/jdk/pull/1292

From chegar at openjdk.java.net  Fri Mar 26 12:42:25 2021
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 26 Mar 2021 12:42:25 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static
In-Reply-To: <vgld966LDtRNI2RDlfmRq5CSrS5T5-MOSAr7vCTf_hE=.3de9cbb9-c1b5-49a6-a8c0-38d78a3ee6e2@github.com>
References: <vgld966LDtRNI2RDlfmRq5CSrS5T5-MOSAr7vCTf_hE=.3de9cbb9-c1b5-49a6-a8c0-38d78a3ee6e2@github.com>
Message-ID: <jL-Uot-hQR0R6dWncd3z8k-F5WO8PnR-ZEnNGLxShrA=.427bfd53-e058-435e-8c2b-ae2aac1d6078@github.com>

On Thu, 25 Mar 2021 20:08:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.
> 
> These  APIs were added early in JDK 17 and are being updated before GA.
> This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.
> 
>    public boolean isHexDigit(int);
>    public int fromHexDigit(int);
>    public int fromHexDigits(java.lang.CharSequence);
>    public int fromHexDigits(java.lang.CharSequence, int, int);
>    public long fromHexDigitsToLong(java.lang.CharSequence);
>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3205

From rriggs at openjdk.java.net  Fri Mar 26 14:33:24 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 26 Mar 2021 14:33:24 GMT
Subject: RFR: 8262110: DST starts from incorrect time in 2038
In-Reply-To: <EMl1RAfjTfftzQCREsPNQlurue7qly6B_k1mHJCdO94=.e10e693d-dcc9-46e3-839a-554eadd55757@github.com>
References: <EMl1RAfjTfftzQCREsPNQlurue7qly6B_k1mHJCdO94=.e10e693d-dcc9-46e3-839a-554eadd55757@github.com>
Message-ID: <ngZVQ-jS9H66wG-LA06_h3upo8gCqLUQ73Erc6mzkJE=.94b8a01f-545c-49e4-862d-3218d68c31e0@github.com>

On Tue, 23 Mar 2021 23:38:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the DST transition bug after the year 2037. The logic had the side effect that it adjusted the dst offset every time the method `getOffsets()` is issued. Only adjust the offset when issued with wall time.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3165

From rriggs at openjdk.java.net  Fri Mar 26 14:39:47 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 26 Mar 2021 14:39:47 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static [v2]
In-Reply-To: <vgld966LDtRNI2RDlfmRq5CSrS5T5-MOSAr7vCTf_hE=.3de9cbb9-c1b5-49a6-a8c0-38d78a3ee6e2@github.com>
References: <vgld966LDtRNI2RDlfmRq5CSrS5T5-MOSAr7vCTf_hE=.3de9cbb9-c1b5-49a6-a8c0-38d78a3ee6e2@github.com>
Message-ID: <saNdmxzKWiX9Dvm0jMrjmCRPHrFBoqCjfOoMKLzDKuo=.95c789fc-d7db-4e22-9148-65f8f0373236@github.com>

> A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.
> 
> These  APIs were added early in JDK 17 and are being updated before GA.
> This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.
> 
>    public boolean isHexDigit(int);
>    public int fromHexDigit(int);
>    public int fromHexDigits(java.lang.CharSequence);
>    public int fromHexDigits(java.lang.CharSequence, int, int);
>    public long fromHexDigitsToLong(java.lang.CharSequence);
>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused HexFormat instances

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3205/files
  - new: https://git.openjdk.java.net/jdk/pull/3205/files/050495a9..042dc18b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3205&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3205&range=00-01

  Stats: 7 lines in 4 files changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3205.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3205/head:pull/3205

PR: https://git.openjdk.java.net/jdk/pull/3205

From herrick at openjdk.java.net  Fri Mar 26 14:51:28 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 26 Mar 2021 14:51:28 GMT
Subject: Integrated: 8189198: Add "forRemoval = true" to Applet API
 deprecations
In-Reply-To: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
References: <s_5wQSXJ0Nau-WH44l8tCaGim67yNWQZrUHsMdw1tis=.380a8827-6125-443a-bda8-9cbf06202be6@github.com>
Message-ID: <4WWT8Ziy2C8n3V8-SQqJ_SNHpYlyB1uO26I-Szzm29c=.d2041dca-362a-4285-a961-7f71635df559@github.com>

On Wed, 10 Mar 2021 18:33:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> implementation of
> JDK-8256145: JEP 398: Deprecate the Applet API for Removal

This pull request has now been integrated.

Changeset: 57115fa2
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/57115fa2
Stats:     73 lines in 22 files changed: 14 ins; 0 del; 59 mod

8189198: Add "forRemoval = true" to Applet API deprecations

Reviewed-by: iris, almatvee, kcr, prr

-------------

PR: https://git.openjdk.java.net/jdk/pull/2920

From redestad at openjdk.java.net  Fri Mar 26 15:00:31 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 26 Mar 2021 15:00:31 GMT
Subject: RFR: 8263754: HexFormat 'fromHex' methods should be static [v2]
In-Reply-To: <saNdmxzKWiX9Dvm0jMrjmCRPHrFBoqCjfOoMKLzDKuo=.95c789fc-d7db-4e22-9148-65f8f0373236@github.com>
References: <vgld966LDtRNI2RDlfmRq5CSrS5T5-MOSAr7vCTf_hE=.3de9cbb9-c1b5-49a6-a8c0-38d78a3ee6e2@github.com>
 <saNdmxzKWiX9Dvm0jMrjmCRPHrFBoqCjfOoMKLzDKuo=.95c789fc-d7db-4e22-9148-65f8f0373236@github.com>
Message-ID: <wX6Wt2nP04sXbfueXTavhyKjKfDGAtEtbY6XSs50iQY=.83eb4233-ac07-4247-b422-08fd8d24eeab@github.com>

On Fri, 26 Mar 2021 14:39:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.
>> 
>> These  APIs were added early in JDK 17 and are being updated before GA.
>> This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.
>> 
>>    public boolean isHexDigit(int);
>>    public int fromHexDigit(int);
>>    public int fromHexDigits(java.lang.CharSequence);
>>    public int fromHexDigits(java.lang.CharSequence, int, int);
>>    public long fromHexDigitsToLong(java.lang.CharSequence);
>>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused HexFormat instances

Marked as reviewed by redestad (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3205

From roger.riggs at oracle.com  Fri Mar 26 15:04:23 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 26 Mar 2021 11:04:23 -0400
Subject: Dynamic Deserialization Filters - a JEP draft
Message-ID: <54b2133e-0cdb-c0dd-a36b-87102d897e1b@oracle.com>

Please review a JEP to extend deserialization filtering (JEP 290) to 
enable deserialization filters to be selected by the application based 
on the runtime context.

JDK-8263381 <https://bugs.openjdk.java.net/browse/JDK-8263381> Dynamic 
Deserialization Filters

Comments appreciated,? Roger

From roger.riggs at oracle.com  Fri Mar 26 15:08:23 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 26 Mar 2021 11:08:23 -0400
Subject: Comment on CSR 8251991: Hex formatting and parsing utility
In-Reply-To: <cff8a2aa-df5e-278f-1f5f-00a60c4a7298@gmail.com>
References: <cff8a2aa-df5e-278f-1f5f-00a60c4a7298@gmail.com>
Message-ID: <cdd01acc-a5bc-df27-c02a-34c690b1ee9d@oracle.com>

fyi,? a PR to make the methods static.

https://git.openjdk.java.net/jdk/pull/3205

On 3/15/21 4:26 PM, Raffaello Giulietti wrote:
> Hello,
>
> I understand your points expressed in 
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.html
>
> On the other hand, it kind of hurts when the javadoc spec implies that 
> the fromXXX() methods do not logically depend on the state and yet one 
> has to invoke them on some instance anyway.
>
>
> As for HexFormat.of() to always return the same instance, you are of 
> course right in observing that this is out of place for value-based 
> classes. The intent was to describe a static-like idiom that would 
> deter programmers to rewrite their own static version of these methods.
>
>
> Greetings
> Raffaello
>
>
>> Hi,
>>
>> The question about static vs instance methods was raised during the 
>> review.
>> At the time, my rationale for the current API is summarized in this 
>> email.
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.html 
>>
>>
>> It comes down to choosing one kind of consistency vs another.
>>
>> I was/am looking for additional comments to weigh one or the other 
>> alternative.
>> I did receive one offline comment in support of static methods on the 
>> rationale of
>> convenience.
>>
>> Regards, Roger
>>
>>
>> On 3/15/21 12:06 PM, Raffaello Giulietti wrote:
>>> Hi,
>>>
>>> the javadoc of most of the methods listed in my previous post below 
>>> reads:
>>> ??? "The delimiter, prefix, suffix, and uppercase parameters are not 
>>> used."
>>>
>>> As these eventually constitute the whole state of an instance of 
>>> this final class and as the state is not involved, it is possible to 
>>> declare the methods as static.
>>>
>>>
>>> If, for some reason, declaring the methods as static is not a 
>>> choice, the next best thing is to clarify that
>>> * HexFormat.of() always returns the same instance and thus
>>> * absent any other instance, the recommended idiom for invoking any 
>>> of the methods below is, for example,
>>> ??? HexFormat.of().isHexDigit('F')
>>> (because there are almost no additional costs wrt static methods.)
>> Note that HexFormat is specified as a value based class and
>> any statement related to identity is out of place.
>>
>> Incidentally, its generally discouraged and can cause a warning when 
>> a static method is invoked using a reference.
>>
>>>
>>> But I don't see a reason why they should be non-static. Just oversight?
>>>
>>>
>>> Greetings
>>> Raffaello
>>>
>>>
>>> On 2021-03-08 11:52, Raffaello Giulietti wrote:
>>>> Hello,
>>>>
>>>> it appears that all of the following API methods in [1] can be 
>>>> declared *static*, which makes them more useful in contexts where 
>>>> there's no instance of HexFormat available or none is desired.
>>>>
>>>> As 17 has not yet entered any formal phase, the change should be 
>>>> harmless.
>>>>
>>>> ?? public boolean isHexDigit(int);
>>>> ?? public int fromHexDigit(int);
>>>> ?? public int fromHexDigits(java.lang.CharSequence);
>>>> ?? public int fromHexDigits(java.lang.CharSequence, int, int);
>>>> ?? public long fromHexDigitsToLong(java.lang.CharSequence);
>>>> ?? public long fromHexDigitsToLong(java.lang.CharSequence, int, int);
>>>>
>>>> Greetings
>>>> Raffaello
>>>>
>>>> ----
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8251991


From naoto at openjdk.java.net  Fri Mar 26 17:18:30 2021
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 26 Mar 2021 17:18:30 GMT
Subject: Integrated: 8262110: DST starts from incorrect time in 2038
In-Reply-To: <EMl1RAfjTfftzQCREsPNQlurue7qly6B_k1mHJCdO94=.e10e693d-dcc9-46e3-839a-554eadd55757@github.com>
References: <EMl1RAfjTfftzQCREsPNQlurue7qly6B_k1mHJCdO94=.e10e693d-dcc9-46e3-839a-554eadd55757@github.com>
Message-ID: <Qjoy4uJyCKL32lgHW_lSxqqmwwekiA_6v18NlihQmqI=.1794a471-6316-4d21-bf8c-a9c55c2272eb@github.com>

On Tue, 23 Mar 2021 23:38:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the DST transition bug after the year 2037. The logic had the side effect that it adjusted the dst offset every time the method `getOffsets()` is issued. Only adjust the offset when issued with wall time.

This pull request has now been integrated.

Changeset: 7284f013
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7284f013
Stats:     75 lines in 2 files changed: 73 ins; 0 del; 2 mod

8262110: DST starts from incorrect time in 2038
8073446: TimeZone getOffset API does not  return a dst offset between years 2038-2137

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.java.net/jdk/pull/3165

From mark.reinhold at oracle.com  Fri Mar 26 19:44:11 2021
From: mark.reinhold at oracle.com (mark.reinhold at oracle.com)
Date: Fri, 26 Mar 2021 12:44:11 -0700
Subject: Dynamic Deserialization Filters - a JEP draft
In-Reply-To: <54b2133e-0cdb-c0dd-a36b-87102d897e1b@oracle.com>
References: <54b2133e-0cdb-c0dd-a36b-87102d897e1b@oracle.com>
Message-ID: <20210326124411.853417986@eggemoggin.niobe.net>

2021/3/26 8:04:23 -0700, roger.riggs at oracle.com:
> Please review a JEP to extend deserialization filtering (JEP 290) to 
> enable deserialization filters to be selected by the application based 
> on the runtime context.
> 
> JDK-8263381 <https://bugs.openjdk.java.net/browse/JDK-8263381> Dynamic 
> Deserialization Filters

More readably: https://openjdk.java.net/jeps/8263381

- Mark

From darcy at openjdk.java.net  Fri Mar 26 20:03:30 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Fri, 26 Mar 2021 20:03:30 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v37]
In-Reply-To: <b3NvYC-c_euRkQGixw9-EhAuGxh7VJgagcZNvXsRqi0=.3586e6c4-fae0-4b5d-b310-4cde2b0cef7f@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <b3NvYC-c_euRkQGixw9-EhAuGxh7VJgagcZNvXsRqi0=.3586e6c4-fae0-4b5d-b310-4cde2b0cef7f@github.com>
Message-ID: <NTFNUx1pBBo85boNJR0rGK3J6ftq2zW3_HlLD_rN7cY=.2b6bc204-5cb2-42c4-a525-9701a3244388@github.com>

On Fri, 26 Mar 2021 12:25:43 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
>> 
>> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
>> 
>> old PR:  https://github.com/openjdk/jdk/pull/1273
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR review revisions

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From dongbo at openjdk.java.net  Sat Mar 27 09:05:45 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Sat, 27 Mar 2021 09:05:45 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
Message-ID: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>

In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.

Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.

There can be illegal characters at the start of the input if the data is MIME encoded.
It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.

A JMH micro, Base64Decode.java, is added for performance test.
With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.

The Base64Decode.java JMH micro-benchmark results:

# Kunpeng916, intrinsic
Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op

# Kunpeng916, default
Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

-------------

Commit messages:
 - 8256245: AArch64: Implement Base64 decoding intrinsic

Changes: https://git.openjdk.java.net/jdk/pull/3228/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3228&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256245
  Stats: 410 lines in 3 files changed: 410 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3228.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3228/head:pull/3228

PR: https://git.openjdk.java.net/jdk/pull/3228

From aph at openjdk.java.net  Sat Mar 27 09:56:27 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Sat, 27 Mar 2021 09:56:27 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>

On Sat, 27 Mar 2021 08:58:03 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

Firstly, I wonder how important this is for most applications. I don't actually know, but let's put that to one side. 

There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3228

From aph at openjdk.java.net  Sat Mar 27 10:00:27 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Sat, 27 Mar 2021 10:00:27 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <nfte202QapWYJ9-w79xivSexwVEqGg78VtMdD8EE-WY=.7a9c5287-1f66-499d-88f4-a7d7f6d987e5@github.com>

On Sat, 27 Mar 2021 08:58:03 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5578:

> 5576:   void generate_base64_decode_nosimdround(Register src, Register dst,
> 5577:         Register nosimd_codec, Label &Exit)
> 5578:   {

We'd want enter/leave here so profiling tools can walk the stack.

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5728:

> 5726: 
> 5727:     static const uint8_t fromBase64ForNoSIMD[256] = {
> 5728:       255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u,

There seems to be no documentation of these magic tables of constants.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3228

From aph at openjdk.java.net  Sat Mar 27 10:07:24 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Sat, 27 Mar 2021 10:07:24 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
Message-ID: <eBiHcByhkHGE7uY6TOd9UmlOBHNi-zHYiQAfdl0scgY=.99dda61c-1d76-4125-bebd-94e26fca9b88@github.com>

On Sat, 27 Mar 2021 09:53:37 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> Firstly, I wonder how important this is for most applications. I don't actually know, but let's put that to one side. 
> 
> There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution. It's very tempting to unroll everything to make a benchmark run quickly, but we have to take a balanced approach.

Please consider losing the non-SIMD case. It doesn't result in any significant gain.

> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5728:
> 
>> 5726: 
>> 5727:     static const uint8_t fromBase64ForNoSIMD[256] = {
>> 5728:       255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u, 255u,
> 
> There seems to be no documentation of these magic tables of constants.

We're either going to need a proper description of the algorithm here or a permalink to one.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3228

From attila at openjdk.java.net  Sat Mar 27 15:34:32 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sat, 27 Mar 2021 15:34:32 GMT
Subject: RFR: 8264326: Modernize javax.script.ScriptEngineManager and related
 classes' implementation
Message-ID: <ZLqKPN5QGdkNhY5b4CswU76jOLCYBCrAG6W_i84gXxs=.baae1d66-f3a9-45e9-8761-f7871b5bf0d1@github.com>

I noticed that `javax.script.ScriptEngineManager` `getEngineByXxx` methods had a lot of code duplication among themselves, and even within each method. I refactored them into a modern unified implementation. While there I also took the opportunity to introduce `Objects.requireNonNull` in place of null checks followed by NPE throws, mark private fields final where possible, use lambdas for `doPrivileged` block, use `List.of` and `List.copyOf` where possible, and generally sanitize/deduplicate.

-------------

Commit messages:
 - Tidy
 - require non null in SimpleBindings
 - Simplify SimpleScriptContext.scopes
 - Mark fields final where possible
 - Deduplicate registerEngineXxx methods
 - Misc tidying
 - Deduplicate exception reporting
 - Lambdify
 - Mark fields as final; eliminate now unnecessary init() method.
 - Deduplicate engine creation and setup code
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/a209ed01...f378f350

Changes: https://git.openjdk.java.net/jdk/pull/3229/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3229&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264326
  Stats: 225 lines in 5 files changed: 38 ins; 142 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3229.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3229/head:pull/3229

PR: https://git.openjdk.java.net/jdk/pull/3229

From attila at openjdk.java.net  Sat Mar 27 15:34:32 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sat, 27 Mar 2021 15:34:32 GMT
Subject: RFR: 8264326: Modernize javax.script.ScriptEngineManager and
 related classes' implementation
In-Reply-To: <ZLqKPN5QGdkNhY5b4CswU76jOLCYBCrAG6W_i84gXxs=.baae1d66-f3a9-45e9-8761-f7871b5bf0d1@github.com>
References: <ZLqKPN5QGdkNhY5b4CswU76jOLCYBCrAG6W_i84gXxs=.baae1d66-f3a9-45e9-8761-f7871b5bf0d1@github.com>
Message-ID: <t0Bph5Z7jBtOwJo90yjwG6vLqWIRTIOkCpVczQJcq0I=.1125dce5-aa05-4aa1-b93e-13a2fe51b8ad@github.com>

On Sat, 27 Mar 2021 15:19:37 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> I noticed that `javax.script.ScriptEngineManager` `getEngineByXxx` methods had a lot of code duplication among themselves, and even within each method. I refactored them into a modern unified implementation. While there I also took the opportunity to introduce `Objects.requireNonNull` in place of null checks followed by NPE throws, mark private fields final where possible, use lambdas for `doPrivileged` block, use `List.of` and `List.copyOf` where possible, and generally sanitize/deduplicate.

src/java.scripting/share/classes/javax/script/ScriptEngineManager.java line 224:

> 222:                 try {
> 223:                     List<String> matches = valuesFn.apply(spi);
> 224:                     return matches != null && matches.contains(selector);

Note this under anomalous conditions, calling `List.contains` here can result in somewhat different behavior than [what was here before](https://github.com/openjdk/jdk/blob/master/src/java.scripting/share/classes/javax/script/ScriptEngineManager.java#L238). Notably:
* if `spi` returns a list that contains the selector value _at least twice_, and
* it throws an exception while creating the engine for the first time, then
* the previous implementation will invoke `getScriptEngine` for the second time too.

My modified implementation will ignore multiple occurrences of the selector value in the returned list. I believe that behavior is correct, especially since the list of values for engine names, extensions, and mime types is expected to contain unique entries (too bad the interface didn't define these methods to return a `Set<String>`?)

-------------

PR: https://git.openjdk.java.net/jdk/pull/3229

From alanb at openjdk.java.net  Sat Mar 27 15:49:25 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 27 Mar 2021 15:49:25 GMT
Subject: RFR: 8264326: Modernize javax.script.ScriptEngineManager and
 related classes' implementation
In-Reply-To: <ZLqKPN5QGdkNhY5b4CswU76jOLCYBCrAG6W_i84gXxs=.baae1d66-f3a9-45e9-8761-f7871b5bf0d1@github.com>
References: <ZLqKPN5QGdkNhY5b4CswU76jOLCYBCrAG6W_i84gXxs=.baae1d66-f3a9-45e9-8761-f7871b5bf0d1@github.com>
Message-ID: <61wDd2S8QdaVpUj6XfXqkzpbsZHZCm2WE7iMWw1D5jY=.13ab3b92-fcb0-4f0c-a8b4-7920b9629921@github.com>

On Sat, 27 Mar 2021 15:19:37 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> I noticed that `javax.script.ScriptEngineManager` `getEngineByXxx` methods had a lot of code duplication among themselves, and even within each method. I refactored them into a modern unified implementation. While there I also took the opportunity to introduce `Objects.requireNonNull` in place of null checks followed by NPE throws, mark private fields final where possible, use lambdas for `doPrivileged` block, use `List.of` and `List.copyOf` where possible, and generally sanitize/deduplicate.

src/java.scripting/share/classes/javax/script/ScriptEngineManager.java line 215:

> 213:     }
> 214: 
> 215:     private ScriptEngine getEngineBy(String selector, Map<String, ScriptEngineFactory> associations, Function<ScriptEngineFactory, List<String>> valuesFn) {

No objection to do some modernization of this code but probably best to avoid introducing overly long lines as it is impossible to see the changes with side-by-side diffs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3229

From alanb at openjdk.java.net  Sat Mar 27 16:05:26 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 27 Mar 2021 16:05:26 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <p-_HnI7N66Tgv3ksgxXBfa7uSaj9VBe-3eQYSIpNep8=.10b43b7a-6a14-488a-9b98-95afa10846a7@github.com>

On Fri, 26 Feb 2021 17:03:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

I think the summary is that we've converged on -C/--dir. We might have to tweak the usage message for -C so that it starts with the existing "Change to the specified directory ..." rather than changing it to start with the extract case.
Are you, or Lance, going to create the CSR for this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2752

From alanb at openjdk.java.net  Sat Mar 27 16:44:32 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sat, 27 Mar 2021 16:44:32 GMT
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts,
 use of optional GZIP fields [v3]
In-Reply-To: <TI04aLV2v1LDIZB33Kx-PgoCKoVQpXwvEah02OUrj_Q=.0bbc94a7-a0a5-492f-8081-52653a8bdd56@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
 <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>
 <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
 <TI04aLV2v1LDIZB33Kx-PgoCKoVQpXwvEah02OUrj_Q=.0bbc94a7-a0a5-492f-8081-52653a8bdd56@github.com>
Message-ID: <3VZEYZr8-M7o776i5W7Tyus-_fbUnQ8Wlrbx43Mzt6o=.c26626fe-9a1b-4dc4-9a25-37534da3b45a@github.com>

On Fri, 26 Mar 2021 02:14:54 GMT, Lin Zang <lzang at openjdk.org> wrote:

>> Hi Lin,
>> 
>> On Mar 24, 2021, at 2:51 AM, Lin Zang ***@***.******@***.***>> wrote:
>> 
>> 
>> 
>> Hi Lance?
>> Thanks a lot for your review. I will update the PR ASAP.
>> May I ask your help to also review the CSR?
>> 
>> I believe we need to flush out some of the issues I raised that were not test related as they will result in updates to the javadoc which will require an update to the CSR.
>> 
>> 
>> 
>> Thanks!
>> 
>> BRs,
>> Lin
>> 
>> ?
>> You are receiving this because you commented.
>> Reply to this email directly, view it on GitHub<https://github.com/openjdk/jdk/pull/3072#issuecomment-805549600>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ABQPFO5R4INTAUFZ3QS6WL3TFGDXHANCNFSM4ZMLU6SA>.
>> 
>> ***@***.***
>> 
>> 
>> 
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> ***@***.******@***.***>
>
> Dear Lance?
> 
> Sorry that I reply so late, I got stuck at some work recently.
> 
>> * We should have tests that include some , but not all of the additional fields as I believe they are all optional according to the RFC.
> 
> I see Joe's comments in the CSR about the encode of the byte array of String-alike field such file name, I checked that the RFC has description it is "ISO8859-1". So do you think it is ok to change the argument type to String and add the encoding decription in the documented comments?
> 
> And Joe also suggested to make all optional header field as a class (I propose to name it "gzipHeaderMetaRecord" ). And then the constructor could accept it and process related flag and fields.  Moreover it seems this class cloud also be used in GzipInputStream?Do you think it is ok to also change it here?  Thanks!
> 
> 
> BRs,
> Lin

GZIPInputStream/GZIPOutputStream are JDK 1.1 era classes that aren't well specified and I think we'll have to do some improvements as part of extending the support. For example, the GZIPOutputStream constructors (existing and proposed) do not specify that they write the member header. 

As regards the new constructors then I think new parameters will need to be clearly specified and/or linked to their description in the RFC. The types of some of the parameters may need to be re-examined, maybe the file name and comment should be provided as Strings (that will help with the discussion about the encoding to 8859_1). I think the javadoc will need to make it clear on what flags/values are allowed and the behavior when other values are used. It might be that the class will need enums and other classes to provide a better API.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

From lance.andersen at oracle.com  Sat Mar 27 17:19:17 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sat, 27 Mar 2021 17:19:17 +0000
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <p-_HnI7N66Tgv3ksgxXBfa7uSaj9VBe-3eQYSIpNep8=.10b43b7a-6a14-488a-9b98-95afa10846a7@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <p-_HnI7N66Tgv3ksgxXBfa7uSaj9VBe-3eQYSIpNep8=.10b43b7a-6a14-488a-9b98-95afa10846a7@github.com>
Message-ID: <1C26247B-1293-424F-AED8-4EDB4B957349@oracle.com>



On Mar 27, 2021, at 12:05 PM, Alan Bateman <alanb at openjdk.java.net<mailto:alanb at openjdk.java.net>> wrote:

On Fri, 26 Feb 2021 17:03:11 GMT, Jaikiran Pai <jpai at openjdk.org<mailto:jpai at openjdk.org>> wrote:

Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?

The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.

As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.

The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).

The commit also includes a jtreg testcase which verifies the usage of this new option.

I think the summary is that we've converged on -C/--dir. We might have to tweak the usage message for -C so that it starts with the existing "Change to the specified directory ..." rather than changing it to start with the extract case.
Are you, or Lance, going to create the CSR for this?

I have not had a chance to go through the latest update from Jaikiran or his revised PR yet.

Yes, once we flush everything out, I will work with Jaikiran on the CSR and determine which of us will create the CSR.  On the todo list for next week.

Best
Lance

-------------

PR: https://git.openjdk.java.net/jdk/pull/2752

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>




From jai.forums2013 at gmail.com  Sun Mar 28 13:24:48 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Sun, 28 Mar 2021 18:54:48 +0530
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <b10be763-cf85-a144-87bb-0653f3a0a1ec@gmail.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
 <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
 <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>
 <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com>
 <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com>
 <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com>
 <237e6c14-8593-69df-5866-4a238e020fce@oracle.com>
 <b10be763-cf85-a144-87bb-0653f3a0a1ec@gmail.com>
Message-ID: <e24c6f02-2672-4dfa-e699-c8a34cb617f9@gmail.com>

Lance ran some tests against the proposed patch and that has exposed an 
area which we haven't yet taken into account for this feature.

The jar tool has a (hidden) option "-P" which can be used with the "c" 
(create), "u" (update) and "x" (extract) main operations. When this -P 
option is used, the jar tool will preserve/won't strip leading slash and 
".." component from file name. So imagine a jar created with the -P 
option as follows:

jar -cfP foo.jar /tmp/blah.txt

This will add /tmp/blah.txt with the the leading / preserved, so the 
contents of the jar will be:

jar -tf foo.jar
META-INF/
META-INF/MANIFEST.MF
/tmp/blah.txt

Consider being in /home/me/ directory and running the jar -xfP command 
against this jar. When you do that, the /tmp/blah.txt will get extracted 
to the /tmp/blah.txt absolute path and the META-INF and the other 
entries get extracted inside the /home/me/ directory. This is how the 
jar tool currently behaves when the leading slashes (and ..) are 
involved with the -P option.

Now coming to this new feature we are talking about, IMO, we cannot 
break this existing behaviour. So when the user continues to use:

jar -xfP foo.jar

without any explicit -C or --dir option, then IMO, the extract should 
continue to work just like it does now and continue to extract the 
/tmp/blah.txt to that absolute location. Now when the user explicitly 
specifies the new -C or --dir option with the -P option for extract, 
something like:

jar -xfP foo.jar -C /tmp/hello/

I think we should continue to extract the /tmp/blah.txt to that absolute 
location instead of making it relative to the /tmp/hello/ directory. 
Given that -P is a hidden option, I am not sure if this should be 
documented in some manner (other than maybe code comments), but I wanted 
to bring this up so that we can come to a decision and have the proposed 
implementation work in that manner.

-Jaikiran

On 24/03/21 4:10 pm, Jaikiran Pai wrote:
> Based on the inputs so far, I've updated the PR to include the 
> provided feedback. Since the PR code review hadn't yet started, I 
> decided to do a force push to the PR so that we can start it afresh.
>
> Command option:
>
> In this current discussion, we seem to have an agreement for using -C 
> and --dir as the short and long options for this feature. The 
> implementation in this PR now uses these options. There was also a 
> suggestion to additionally allow --directory as an option too. I 
> haven't added that yet, since I wasn't sure if we really want that. It 
> was suggested that if we do use --directory, we should "hide" --dir. 
> If we do need the --directory option, I can add that in, in subsequent 
> updates to this PR.
>
>
> Directories creation:
>
> There was an agreement in our discussion that if the destination 
> directory hierarchy isn't present, then we should create that whole 
> hierarchy and extract the jar into it. The implementation in this PR 
> matches this decision.
>
>
> Verbose logging:
>
> During the discussion, there was a question whether this feature 
> should introduce any new verbose logs during extraction. IMO, it's a 
> good idea to log the target directory to which the jar is being 
> extracted. So, in the implementation, I have introduced a new 
> (resource bundle backed) verbose log message which prints the absolute 
> path to which the jar will be extracted. Do note that this verbose log 
> message will be printed even if you don't explicitly specify any 
> target directory. i.e. even when the default current directory is 
> used, this verbose log message will be printed if the "-v" option is 
> used.
>
> Repeatability of the newly introduce options:
>
> Unlike in the other main operations of the jar command, the -C option 
> that we use during the extract main operation, IMO, shouldn't be 
> allowed to be used more than once. More specifically the destination 
> directory to which the jar needs to be extracted must only be 
> specified once, irrespective of whether it's through the use of -C or 
> --dir. The code in the PR, explicitly throws an error when such 
> repeatition is encountered.
>
> An alternate approach would have been to allow the -C and/or --dir 
> option to be repeated, but use the last specified value of these 
> options. However, I decided not to pursue that approach, to keep it 
> simple as well as to avoid any confusion on the command usage.
>
>
> Overwriting of contents in existing target directory:
>
> No specific change has been done when it comes to dealing with the 
> extraction logic itself. Specifically, when the explicitly specified 
> or the default current directory already has directories/files that 
> belong to the jar being extracted, those files/dirs will continue to 
> be overwritten.
>
> Compatibility mode:
>
> The code in this PR also supports the compatibility mode for this 
> option. Specifically, a command like:
>
> jar -xvf somejar.jar -C /tmp/foo/
>
> will work fine and the jar will be extracted into /tmp/foo directory.
>
>
> Message/error internationalization:
>
> I have only updated the jar.properties for the English version of the 
> new output and error messages. I don't know what the process is for 
> adding this to other languages, if at all that needs to be done in 
> this PR.
>
>
> jar --help output:
>
> Currently the jar --help output only talks about creation and updation 
> of the jar. There's no mention of using the tool for extracting the 
> jar content:
>
> "jar creates an archive for classes and resources, and can manipulate or
> restore individual classes or resources from an archive."
>
> It does mention "manipulate" but doesn't specifically say extraction. 
> The examples in the help command output don't have any examples for 
> extraction. Should we add an example for extracting the jar file, in 
> this help output?
>
>
> Testing:
>
> A new jtreg test has been introduced which tests various aspects of 
> this feature. It runs most of those tests against both absolute and 
> relative paths.
>
> A couple of tests in the new introduced test case, check for the 
> output/error messages. The jar tool uses resource bundles to print out 
> these messages. I need input on whether I should enforce a specific 
> locale to run these tests so that I can compare the error/output 
> messages for expected strings? See testExtractFailWithMultipleDir() or 
> testHelpOutput() for what I mean.
>
>
> Man page:
>
> This one I need input on. I have tried to see how these man pages are 
> generated and from what I can understand it looks like these man pages 
> are autogenerated during the build process using pandoc. Is that 
> right? The hints that I see in the Docs.gmk seems to suggest that 
> there are some markdown source files from which these man pages get 
> generated. However, I can't seem to locate any such markdown files for 
> this or other tools, from which the man pages get generated. Any help 
> on how I should go about editing/updating the man page for the jar tool?
>
>
> Example usage:
>
> Here are some example usages:
>
> jar -x -f somejar.jar -C /tmp/foo/bar/
>
> This command extracts the somejar.jar file to the /tmp/foo/bar/ 
> directory, creating it if necessary.
>
>
> jar -x -f somejar.jar --dir /tmp/foo/bar/
>
> Same as above, except uses the long form --dir option
>
>
> jar -x -f somejar.jar -C /tmp/foo/bar/ f1.txt d1/f2.txt
>
> Assuming somejar.jar contains "f1.txt" (at root), "d1/f2.txt" and 
> other files, then the above command extracts only "f1.txt" and 
> "d1/f2.txt" into the /tmp/foo/bar/ directory.
>
>
> -Jaikiran
>
> On 14/03/21 6:21 pm, Alan Bateman wrote:
>> On 12/03/2021 12:18, Lance Andersen wrote:
>>>
>>> :
>>>
>>> I don?t have a strong preference but lean slightly towards 
>>> ?-directory? as it is more descriptive, similar to the other 
>>> GNU-style commands jar currently supports . ?Tar supports ??cd?, 
>>> ??directory? in addition to ?-C? which is why I suggested supporting 
>>> ?both GNU-style long options.
>>>
>>> Perhaps jpackage should also support ?dir/directory in addition to 
>>> ??dest' if we are looking at consistency between java tools.
>>>
>>> I do agree that it would be nice to be consistent across the java 
>>> tools for options so if we go the ?-directory?, we should follow 
>>> your suggestion and make it the primary and remove ??dir? from the 
>>> usage output.
>> My comment on consistency was limited to the long option to specify 
>> the directory when extracting, didn't mean to suggest doing anything 
>> with the other tools that specify an output/destination directory. In 
>> any case, I think we have enough to make progress on this issue now.
>>
>> -Alan
>>

From attila at openjdk.java.net  Sun Mar 28 13:38:51 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sun, 28 Mar 2021 13:38:51 GMT
Subject: RFR: 8264326: Modernize javax.script.ScriptEngineManager and
 related classes' implementation [v2]
In-Reply-To: <ZLqKPN5QGdkNhY5b4CswU76jOLCYBCrAG6W_i84gXxs=.baae1d66-f3a9-45e9-8761-f7871b5bf0d1@github.com>
References: <ZLqKPN5QGdkNhY5b4CswU76jOLCYBCrAG6W_i84gXxs=.baae1d66-f3a9-45e9-8761-f7871b5bf0d1@github.com>
Message-ID: <bnYgrO5cxB6AH9ekGM0j2gBPo6DQlEFoHGefCk9GZ4Q=.ab39c81c-e55d-476f-a1cf-562f00c98a76@github.com>

> I noticed that `javax.script.ScriptEngineManager` `getEngineByXxx` methods had a lot of code duplication among themselves, and even within each method. I refactored them into a modern unified implementation. While there I also took the opportunity to introduce `Objects.requireNonNull` in place of null checks followed by NPE throws, mark private fields final where possible, use lambdas for `doPrivileged` block, use `List.of` and `List.copyOf` where possible, and generally sanitize/deduplicate.

Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 13 new commits since the last revision:

 - Tidy
 - require non null in SimpleBindings
 - Simplify SimpleScriptContext.scopes
 - Mark fields final where possible
 - Deduplicate registerEngineXxx methods
 - Misc tidying
 - Deduplicate exception reporting
 - Lambdify
 - Mark fields as final; eliminate now unnecessary init() method.
 - Deduplicate engine creation and setup code
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/f378f350...56d89eb2

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3229/files
  - new: https://git.openjdk.java.net/jdk/pull/3229/files/f378f350..56d89eb2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3229&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3229&range=00-01

  Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3229.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3229/head:pull/3229

PR: https://git.openjdk.java.net/jdk/pull/3229

From attila at openjdk.java.net  Sun Mar 28 13:38:52 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Sun, 28 Mar 2021 13:38:52 GMT
Subject: RFR: 8264326: Modernize javax.script.ScriptEngineManager and
 related classes' implementation [v2]
In-Reply-To: <61wDd2S8QdaVpUj6XfXqkzpbsZHZCm2WE7iMWw1D5jY=.13ab3b92-fcb0-4f0c-a8b4-7920b9629921@github.com>
References: <ZLqKPN5QGdkNhY5b4CswU76jOLCYBCrAG6W_i84gXxs=.baae1d66-f3a9-45e9-8761-f7871b5bf0d1@github.com>
 <61wDd2S8QdaVpUj6XfXqkzpbsZHZCm2WE7iMWw1D5jY=.13ab3b92-fcb0-4f0c-a8b4-7920b9629921@github.com>
Message-ID: <3qyeH9vA_t0JZ21v90l8ooeKrLOe7W-oYqsWgHurf5A=.7b4ee159-0304-435c-bc6c-f8a733ded74b@github.com>

On Sat, 27 Mar 2021 15:46:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 13 new commits since the last revision:
>> 
>>  - Tidy
>>  - require non null in SimpleBindings
>>  - Simplify SimpleScriptContext.scopes
>>  - Mark fields final where possible
>>  - Deduplicate registerEngineXxx methods
>>  - Misc tidying
>>  - Deduplicate exception reporting
>>  - Lambdify
>>  - Mark fields as final; eliminate now unnecessary init() method.
>>  - Deduplicate engine creation and setup code
>>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/f378f350...56d89eb2
>
> src/java.scripting/share/classes/javax/script/ScriptEngineManager.java line 215:
> 
>> 213:     }
>> 214: 
>> 215:     private ScriptEngine getEngineBy(String selector, Map<String, ScriptEngineFactory> associations, Function<ScriptEngineFactory, List<String>> valuesFn) {
> 
> No objection to do some modernization of this code but probably best to avoid introducing overly long lines as it is impossible to see the changes with side-by-side diffs.

Fair enough, I reformatted lines longer than 120 characters.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3229

From github.com+76791+alblue at openjdk.java.net  Sun Mar 28 13:58:43 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Sun, 28 Mar 2021 13:58:43 GMT
Subject: RFR: 8264334: Use the blessed modifier order in jdk.jpackage
Message-ID: <b4X3NH4t3rSR-8OKSv-5AR8qV2AbdRECNv88ZxT8FY0=.b1997b75-a37f-4a9a-b383-88b696e17938@github.com>

8264334: Use the blessed modifier order in jdk.jpackage

-------------

Commit messages:
 - 8264334: Use the blessed modifier order in jdk.jpackage

Changes: https://git.openjdk.java.net/jdk/pull/3234/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3234&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264334
  Stats: 58 lines in 19 files changed: 0 ins; 0 del; 58 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3234.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3234/head:pull/3234

PR: https://git.openjdk.java.net/jdk/pull/3234

From herrick at openjdk.java.net  Sun Mar 28 15:55:33 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Sun, 28 Mar 2021 15:55:33 GMT
Subject: RFR: 8264334: Use the blessed modifier order in jdk.jpackage
In-Reply-To: <b4X3NH4t3rSR-8OKSv-5AR8qV2AbdRECNv88ZxT8FY0=.b1997b75-a37f-4a9a-b383-88b696e17938@github.com>
References: <b4X3NH4t3rSR-8OKSv-5AR8qV2AbdRECNv88ZxT8FY0=.b1997b75-a37f-4a9a-b383-88b696e17938@github.com>
Message-ID: <EgzjjE5uDq_4oodCxfzvAYah_jgNA0CSyB7yNjtA8YQ=.952adccd-1120-40a5-a727-017fcbd65999@github.com>

On Sun, 28 Mar 2021 13:53:27 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264334: Use the blessed modifier order in jdk.jpackage

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3234

From lance.andersen at oracle.com  Sun Mar 28 16:22:03 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sun, 28 Mar 2021 16:22:03 +0000
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <e24c6f02-2672-4dfa-e699-c8a34cb617f9@gmail.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
 <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
 <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>
 <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com>
 <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com>
 <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com>
 <237e6c14-8593-69df-5866-4a238e020fce@oracle.com>
 <b10be763-cf85-a144-87bb-0653f3a0a1ec@gmail.com>
 <e24c6f02-2672-4dfa-e699-c8a34cb617f9@gmail.com>
Message-ID: <BAA7024A-3C04-4F8C-A5A5-B9CD1B361C41@oracle.com>



On Mar 28, 2021, at 9:24 AM, Jaikiran Pai <jai.forums2013 at gmail.com<mailto:jai.forums2013 at gmail.com>> wrote:

Lance ran some tests against the proposed patch and that has exposed an area which we haven't yet taken into account for this feature.

The jar tool has a (hidden) option "-P" which can be used with the "c" (create), "u" (update) and "x" (extract) main operations. When this -P option is used, the jar tool will preserve/won't strip leading slash and ".." component from file name. So imagine a jar created with the -P option as follows:

jar -cfP foo.jar /tmp/blah.txt

This will add /tmp/blah.txt with the the leading / preserved, so the contents of the jar will be:

jar -tf foo.jar
META-INF/
META-INF/MANIFEST.MF
/tmp/blah.txt

Consider being in /home/me/ directory and running the jar -xfP command against this jar. When you do that, the /tmp/blah.txt will get extracted to the /tmp/blah.txt absolute path and the META-INF and the other entries get extracted inside the /home/me/ directory. This is how the jar tool currently behaves when the leading slashes (and ..) are involved with the -P option.

Now coming to this new feature we are talking about, IMO, we cannot break this existing behaviour. So when the user continues to use:

jar -xfP foo.jar

without any explicit -C or --dir option, then IMO, the extract should continue to work just like it does now and continue to extract the /tmp/blah.txt to that absolute location.


Agree

Now when the user explicitly specifies the new -C or --dir option with the -P option for extract, something like:

jar -xfP foo.jar -C /tmp/hello/

Given the support of -C/-dir is new and -P is there for backwards compatibility then I see the choices are:


  *   Issue an error when -P and -C/-dir are specified together with -x
  *   Silently ignore the -P option
  *   Ignore -C/-dir and the behavior is if -xfP was specified.

I am leaning towards an error given this is a new feature when -P and -C/-dir are specified with -x

Best
Lance

I think we should continue to extract the /tmp/blah.txt to that absolute location instead of making it relative to the /tmp/hello/ directory. Given that -P is a hidden option, I am not sure if this should be documented in some manner (other than maybe code comments), but I wanted to bring this up so that we can come to a decision and have the proposed implementation work in that manner.

-Jaikiran

On 24/03/21 4:10 pm, Jaikiran Pai wrote:
Based on the inputs so far, I've updated the PR to include the provided feedback. Since the PR code review hadn't yet started, I decided to do a force push to the PR so that we can start it afresh.

Command option:

In this current discussion, we seem to have an agreement for using -C and --dir as the short and long options for this feature. The implementation in this PR now uses these options. There was also a suggestion to additionally allow --directory as an option too. I haven't added that yet, since I wasn't sure if we really want that. It was suggested that if we do use --directory, we should "hide" --dir. If we do need the --directory option, I can add that in, in subsequent updates to this PR.


Directories creation:

There was an agreement in our discussion that if the destination directory hierarchy isn't present, then we should create that whole hierarchy and extract the jar into it. The implementation in this PR matches this decision.


Verbose logging:

During the discussion, there was a question whether this feature should introduce any new verbose logs during extraction. IMO, it's a good idea to log the target directory to which the jar is being extracted. So, in the implementation, I have introduced a new (resource bundle backed) verbose log message which prints the absolute path to which the jar will be extracted. Do note that this verbose log message will be printed even if you don't explicitly specify any target directory. i.e. even when the default current directory is used, this verbose log message will be printed if the "-v" option is used.

Repeatability of the newly introduce options:

Unlike in the other main operations of the jar command, the -C option that we use during the extract main operation, IMO, shouldn't be allowed to be used more than once. More specifically the destination directory to which the jar needs to be extracted must only be specified once, irrespective of whether it's through the use of -C or --dir. The code in the PR, explicitly throws an error when such repeatition is encountered.

An alternate approach would have been to allow the -C and/or --dir option to be repeated, but use the last specified value of these options. However, I decided not to pursue that approach, to keep it simple as well as to avoid any confusion on the command usage.


Overwriting of contents in existing target directory:

No specific change has been done when it comes to dealing with the extraction logic itself. Specifically, when the explicitly specified or the default current directory already has directories/files that belong to the jar being extracted, those files/dirs will continue to be overwritten.

Compatibility mode:

The code in this PR also supports the compatibility mode for this option. Specifically, a command like:

jar -xvf somejar.jar -C /tmp/foo/

will work fine and the jar will be extracted into /tmp/foo directory.


Message/error internationalization:

I have only updated the jar.properties for the English version of the new output and error messages. I don't know what the process is for adding this to other languages, if at all that needs to be done in this PR.


jar --help output:

Currently the jar --help output only talks about creation and updation of the jar. There's no mention of using the tool for extracting the jar content:

"jar creates an archive for classes and resources, and can manipulate or
restore individual classes or resources from an archive."

It does mention "manipulate" but doesn't specifically say extraction. The examples in the help command output don't have any examples for extraction. Should we add an example for extracting the jar file, in this help output?


Testing:

A new jtreg test has been introduced which tests various aspects of this feature. It runs most of those tests against both absolute and relative paths.

A couple of tests in the new introduced test case, check for the output/error messages. The jar tool uses resource bundles to print out these messages. I need input on whether I should enforce a specific locale to run these tests so that I can compare the error/output messages for expected strings? See testExtractFailWithMultipleDir() or testHelpOutput() for what I mean.


Man page:

This one I need input on. I have tried to see how these man pages are generated and from what I can understand it looks like these man pages are autogenerated during the build process using pandoc. Is that right? The hints that I see in the Docs.gmk seems to suggest that there are some markdown source files from which these man pages get generated. However, I can't seem to locate any such markdown files for this or other tools, from which the man pages get generated. Any help on how I should go about editing/updating the man page for the jar tool?


Example usage:

Here are some example usages:

jar -x -f somejar.jar -C /tmp/foo/bar/

This command extracts the somejar.jar file to the /tmp/foo/bar/ directory, creating it if necessary.


jar -x -f somejar.jar --dir /tmp/foo/bar/

Same as above, except uses the long form --dir option


jar -x -f somejar.jar -C /tmp/foo/bar/ f1.txt d1/f2.txt

Assuming somejar.jar contains "f1.txt" (at root), "d1/f2.txt" and other files, then the above command extracts only "f1.txt" and "d1/f2.txt" into the /tmp/foo/bar/ directory.


-Jaikiran

On 14/03/21 6:21 pm, Alan Bateman wrote:
On 12/03/2021 12:18, Lance Andersen wrote:

:

I don?t have a strong preference but lean slightly towards ?-directory? as it is more descriptive, similar to the other GNU-style commands jar currently supports .  Tar supports ??cd?, ??directory? in addition to ?-C? which is why I suggested supporting  both GNU-style long options.

Perhaps jpackage should also support ?dir/directory in addition to ??dest' if we are looking at consistency between java tools.

I do agree that it would be nice to be consistent across the java tools for options so if we go the ?-directory?, we should follow your suggestion and make it the primary and remove ??dir? from the usage output.
My comment on consistency was limited to the long option to specify the directory when extracting, didn't mean to suggest doing anything with the other tools that specify an output/destination directory. In any case, I think we have enough to make progress on this issue now.

-Alan


[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>




From lance.andersen at oracle.com  Sun Mar 28 16:49:34 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Sun, 28 Mar 2021 16:49:34 +0000
Subject: RFR: 4890732: GZIPOutputStream doesn't support, in fact thwarts, 
 use of optional GZIP fields [v3]
In-Reply-To: <3VZEYZr8-M7o776i5W7Tyus-_fbUnQ8Wlrbx43Mzt6o=.c26626fe-9a1b-4dc4-9a25-37534da3b45a@github.com>
References: <DKXYUELjj1BRxIwULHr8Ocm0DY4I6ngRFJ7eog1Miew=.c080fccf-a2b0-46cc-9e4a-306c226cce3c@github.com>
 <TC8qFd23YTgC7ZF7LXBIHhVMvbwwyP-xlUEHxdwZjS8=.fc6faa66-8dff-4c4f-bd3b-0c925afc7c91@github.com>
 <wglX4v3H6Newag-71ZN3FDVNTLg7Un5Bg2IQGmWaot8=.7b668fe5-78f2-4f3e-b659-0d744a0786bf@github.com>
 <O04th1o8bQKVS0gLKyCyaMr_-ypO-7nQDPcaz4XI8Fg=.390d5117-faa3-43a0-81ae-06f25623a026@github.com>
 <CzrmnEOeZtKxy0r0Ykd3FdULdV6eXHY7IWhIms1vCRs=.32d40098-49d8-414f-875c-8e296eb9b7d5@github.com>
 <TI04aLV2v1LDIZB33Kx-PgoCKoVQpXwvEah02OUrj_Q=.0bbc94a7-a0a5-492f-8081-52653a8bdd56@github.com>
 <3VZEYZr8-M7o776i5W7Tyus-_fbUnQ8Wlrbx43Mzt6o=.c26626fe-9a1b-4dc4-9a25-37534da3b45a@github.com>
Message-ID: <6284E7C5-C311-41FF-9EE5-8071EBE7C7A4@oracle.com>



On Mar 27, 2021, at 12:44 PM, Alan Bateman <alanb at openjdk.java.net<mailto:alanb at openjdk.java.net>> wrote:


Dear Lance?

Sorry that I reply so late, I got stuck at some work recently.

* We should have tests that include some , but not all of the additional fields as I believe they are all optional according to the RFC.

I see Joe's comments in the CSR about the encode of the byte array of String-alike field such file name, I checked that the RFC has description it is "ISO8859-1". So do you think it is ok to change the argument type to String and add the encoding decription in the documented comments?

And Joe also suggested to make all optional header field as a class (I propose to name it "gzipHeaderMetaRecord" ). And then the constructor could accept it and process related flag and fields.  Moreover it seems this class cloud also be used in GzipInputStream?Do you think it is ok to also change it here?  Thanks!


BRs,
Lin

GZIPInputStream/GZIPOutputStream are JDK 1.1 era classes that aren't well specified and I think we'll have to do some improvements as part of extending the support. For example, the GZIPOutputStream constructors (existing and proposed) do not specify that they write the member header.

That is a reasonable suggestion to indicate what is and is not done.

As regards the new constructors then I think new parameters will need to be clearly specified and/or linked to their description in the RFC. The types of some of the parameters may need to be re-examined, maybe the file name and comment should be provided as Strings (that will help with the discussion about the encoding to 8859_1).

Agree and that will also align it with ZipEntry(String), Zipentry::setComment

I think the javadoc will need to make it clear on what flags/values are allowed and the behavior when other values are used.

The Gzip spec is kind of vague in this area for example with the SI1 and SI2 for the Extra Field only one value set is specified but I can imagine additional values being somewhere.

It might be that the class will need enums and other classes to provide a better API.

I am not sure how much if at all these extra header fields are used.  Certainly if the API now sets them, we should probably provide a way to access them as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3072

[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>




From ngasson at openjdk.java.net  Mon Mar 29 03:15:26 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 29 Mar 2021 03:15:26 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <nfte202QapWYJ9-w79xivSexwVEqGg78VtMdD8EE-WY=.7a9c5287-1f66-499d-88f4-a7d7f6d987e5@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <nfte202QapWYJ9-w79xivSexwVEqGg78VtMdD8EE-WY=.7a9c5287-1f66-499d-88f4-a7d7f6d987e5@github.com>
Message-ID: <KXgKQrPeN_k9kNFIlmhMbgUPwmlu-QNwNP11PgLkzNw=.b5ab63f7-a555-44b3-bc7f-b1df8a453147@github.com>

On Sat, 27 Mar 2021 09:54:57 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
>> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
>> 
>> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
>> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
>> 
>> There can be illegal characters at the start of the input if the data is MIME encoded.
>> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
>> 
>> A JMH micro, Base64Decode.java, is added for performance test.
>> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
>> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
>> 
>> The Base64Decode.java JMH micro-benchmark results:
>> 
>> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
>> 
>> # Kunpeng916, intrinsic
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
>> 
>> # Kunpeng916, default
>> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
>> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
>> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
>> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
>> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
>> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
>> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
>> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
>> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
>> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
>> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
>> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
>> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
>> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
>> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
>> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
>> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
>> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
>> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
>> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
>> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
>> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
>> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op
>
> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5578:
> 
>> 5576:   void generate_base64_decode_nosimdround(Register src, Register dst,
>> 5577:         Register nosimd_codec, Label &Exit)
>> 5578:   {
> 
> We'd want enter/leave here so profiling tools can walk the stack.

That probably ought to go around the whole routine in generate_base64_decodeBlock rather than here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3228

From ngasson at openjdk.java.net  Mon Mar 29 03:15:28 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 29 Mar 2021 03:15:28 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <4q0UZGolKaHArH3ZQS7G_-EBspOa_zWomuGzWfYGNK0=.7b2a9668-a123-435a-822d-5ab2dc01a8c7@github.com>

On Sat, 27 Mar 2021 08:58:03 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5624:

> 5622:     __ ld4(in0, in1, in2, in3, arrangement, __ post(src, 4 * size));
> 5623: 
> 5624:     // we need unsigned saturationg substract, to make sure all input values

"saturating subtract"

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5649:

> 5647:     __ orr(decL3, arrangement, decL3, decH3);
> 5648: 
> 5649:     // check iilegal inputs, value larger than 63 (maximum of 6 bits)

"illegal inputs". Are there existing jtreg tests that cover these cases?

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5772:

> 5770:     // The value of index 64 is set to 0, so that we know that we already get the
> 5771:     // decoded data with the 1st lookup.
> 5772:     static const uint8_t fromBase64ForSIMD[128] = {

This table and the one below seem to be identical to first half of the NoSIMD tables. Can't you just use one set of 256-entry tables for both SIMD and non-SIMD algorithms?

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5803:

> 5801:     Register dst   = c_rarg3;  // dest array
> 5802:     Register doff  = c_rarg4;  // position for writing to dest array
> 5803:     Register isURL = c_rarg5;  // Base64 or URL chracter set

"character set"

src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 5830:

> 5828: 
> 5829:     // The 1st character of the input can be illegal if the data is MIME encoded.
> 5830:     // We can not benefits from SIMD for this case. The max line size of MIME

"cannot benefit"

-------------

PR: https://git.openjdk.java.net/jdk/pull/3228

From ngasson at openjdk.java.net  Mon Mar 29 03:18:27 2021
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 29 Mar 2021 03:18:27 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
Message-ID: <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>

On Sat, 27 Mar 2021 09:53:37 GMT, Andrew Haley <aph at openjdk.org> wrote:

> 
> There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution. It's very tempting to unroll everything to make a benchmark run quickly, but we have to take a balanced approach.

But there's only ever one of these generated at startup, right? It's not like the string intrinsics that are expanded at every call site.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3228

From dongbo at openjdk.java.net  Mon Mar 29 03:33:34 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Mon, 29 Mar 2021 03:33:34 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
 <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
Message-ID: <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com>

On Mon, 29 Mar 2021 03:15:57 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> Firstly, I wonder how important this is for most applications. I don't actually know, but let's put that to one side. 
>> 
>> There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution. It's very tempting to unroll everything to make a benchmark run quickly, but we have to take a balanced approach.
>
>> 
>> There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution. It's very tempting to unroll everything to make a benchmark run quickly, but we have to take a balanced approach.
> 
> But there's only ever one of these generated at startup, right? It's not like the string intrinsics that are expanded at every call site.

Thanks for the comments.

> Firstly, I wonder how important this is for most applications. I don't actually know, but let's put that to one side.
>

As claimed in JEP 135, Base64 is frequently used to encode binary/octet sequences that are transmitted as textual data.
It is commonly used by applications using Multipurpose Internal Mail Extensions (MIME), encoding passwords for HTTP headers, message digests, etc.
 
> There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution. It's very tempting to unroll everything to make a benchmark run quickly, but we have to take a balanced approach.
>

There is no code unrolling in the non-SIMD case. The instructions are just loading, processing, storing data within loops.
About half of the code size is the error handling in SIMD case:
    // handle illegal input
    if (size == 16) {
      Label ErrorInLowerHalf;
      __ umov(rscratch1, in2, __ D, 0);
      __ cbnz(rscratch1, ErrorInLowerHalf);

      // illegal input is in higher half, store the lower half now.
      __ st3(out0, out1, out2, __ T8B, __ post(dst, 24));

      for (int i = 8; i < 15; i++) {
        __ umov(rscratch2, in2, __ B, (u1) i);
        __ cbnz(rscratch2, Exit);
        __ umov(r10, out0, __ B, (u1) i);
        __ umov(r11, out1, __ B, (u1) i);
        __ umov(r12, out2, __ B, (u1) i);
        __ strb(r10, __ post(dst, 1));
        __ strb(r11, __ post(dst, 1));
        __ strb(r12, __ post(dst, 1));
      }
      __ b(Exit);
I think I can rewrite this part as loops.
With an intial implemention, we can have almost half of the code size reduced (1312B -> 748B). Sounds OK to you?

> Please consider losing the non-SIMD case. It doesn't result in any significant gain.
>

The non-SIMD case is useful for MIME decoding performance.
The MIME base64 encoded data is arranged in lines (line size can be set by user with maximum 76B).
Newline characters, e.g. `\r\n`, are illegal but can be ignored by MIME decoding.
While the SIMD case works as `load data -> two vector table lookups -> combining -> error detection -> store data`.
When using SIMD for MIME decoding, the 1st byte of the input are possibly a newline character.
The SIMD case will execute too much wasty code before it can detect the error and exit, with non-simd case, there are only few ldrs, orrs, strs for error detecting.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3228

From dongbo at openjdk.java.net  Mon Mar 29 03:54:26 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Mon, 29 Mar 2021 03:54:26 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
 <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
Message-ID: <Yefd5pSSUCC2NFjpByR4v-RiO3WjqLGe74xhhcsjUZo=.c0b94f0b-2081-4384-9453-542a5673c038@github.com>

On Mon, 29 Mar 2021 03:15:57 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> Firstly, I wonder how important this is for most applications. I don't actually know, but let's put that to one side. 
>> 
>> There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution. It's very tempting to unroll everything to make a benchmark run quickly, but we have to take a balanced approach.
>
>> 
>> There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution. It's very tempting to unroll everything to make a benchmark run quickly, but we have to take a balanced approach.
> 
> But there's only ever one of these generated at startup, right? It's not like the string intrinsics that are expanded at every call site.

@nick-arm Thank you for watching this.

> That probably ought to go around the whole routine in generate_base64_decodeBlock rather than here?
>

There are two non-simd blocks in this intrinsic.
The 1st is at the begining, mainly to roll MIME decoding to non-simd processing due to the performance issue as I claimed before.
The 2nd is at the end to handle trailing inputs. So I guess we need generate_base64_decode_nosimdround here.

>  "illegal inputs". Are there existing jtreg tests that cover these cases?
>

Yes, they are covered by `test/hotspot/jtreg/compiler/intrinsics/base64/TestBase64.java`.

> This table and the one below seem to be identical to first half of the NoSIMD tables. Can't you just use one set of 256-entry tables for both SIMD and non-SIMD algorithms?
>
They are not identical, `*ForSIMD[64]==0`, `*forNoSIMD[64]=255`.
In SIMD case, `*ForSIMD[64]` acts as a pivot to tell us that we already get the decoded data with the 1st lookup when performing the 2nd lookup.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3228

From github.com+76791+alblue at openjdk.java.net  Mon Mar 29 08:04:28 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Mon, 29 Mar 2021 08:04:28 GMT
Subject: Integrated: 8264334: Use the blessed modifier order in jdk.jpackage
In-Reply-To: <b4X3NH4t3rSR-8OKSv-5AR8qV2AbdRECNv88ZxT8FY0=.b1997b75-a37f-4a9a-b383-88b696e17938@github.com>
References: <b4X3NH4t3rSR-8OKSv-5AR8qV2AbdRECNv88ZxT8FY0=.b1997b75-a37f-4a9a-b383-88b696e17938@github.com>
Message-ID: <MsaBwe5R_SjH8Nz6oCtLqPcrWWX-G18ihoLj6H5Zufs=.739ce5f4-e621-4147-8ccf-2fe2f71a9d42@github.com>

On Sun, 28 Mar 2021 13:53:27 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264334: Use the blessed modifier order in jdk.jpackage

This pull request has now been integrated.

Changeset: 30b4b17c
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/30b4b17c
Stats:     58 lines in 19 files changed: 0 ins; 0 del; 58 mod

8264334: Use the blessed modifier order in jdk.jpackage

Reviewed-by: herrick, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/3234

From shade at openjdk.java.net  Mon Mar 29 08:04:28 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 29 Mar 2021 08:04:28 GMT
Subject: RFR: 8264334: Use the blessed modifier order in jdk.jpackage
In-Reply-To: <b4X3NH4t3rSR-8OKSv-5AR8qV2AbdRECNv88ZxT8FY0=.b1997b75-a37f-4a9a-b383-88b696e17938@github.com>
References: <b4X3NH4t3rSR-8OKSv-5AR8qV2AbdRECNv88ZxT8FY0=.b1997b75-a37f-4a9a-b383-88b696e17938@github.com>
Message-ID: <vAgKaNQ-v1ZlYVklRI_bQANqYFqf0GfJox-5Xy3SDdg=.e0ede5a8-ffd7-435e-8a24-38812408b967@github.com>

On Sun, 28 Mar 2021 13:53:27 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264334: Use the blessed modifier order in jdk.jpackage

Marked as reviewed by shade (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3234

From aph at openjdk.java.net  Mon Mar 29 08:34:45 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 29 Mar 2021 08:34:45 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
 <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
Message-ID: <i9-JQswdn8i2ssfDUL-cll1F3wyNJWk1oYLbWiTgiBA=.cebb4a33-db5c-4b9a-92d1-45ab1e3d75d8@github.com>

On Mon, 29 Mar 2021 03:15:57 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> > There's a lot of unrolling, particularly in the non-SIMD case. Please consider taking out some of the unrolling; I suspect it'd not increase time by very much but would greatly reduce the code cache pollution. It's very tempting to unroll everything to make a benchmark run quickly, but we have to take a balanced approach.
> 
> But there's only ever one of these generated at startup, right? It's not like the string intrinsics that are expanded at every call site.

I'm talking about icache pollution. This stuff could be quite small.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3228

From aph at openjdk.java.net  Mon Mar 29 08:41:27 2021
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 29 Mar 2021 08:41:27 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
 <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
 <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com>
Message-ID: <vxrUJagEcM97odeOocaFBJjZC_lNQwiuGmJwD0s-7wc=.d75d3029-2513-405c-afa3-f1ed8e7af5a1@github.com>

On Mon, 29 Mar 2021 03:28:54 GMT, Dong Bo <dongbo at openjdk.org> wrote:

> I think I can rewrite this part as loops.
> With an intial implemention, we can have almost half of the code size reduced (1312B -> 748B). Sounds OK to you?

Sounds great, but I'm still somewhat concerned that the non-SIMD case only offers 3-12% performance gain. Make it just 748 bytes, and therefore not icache-hostile, then perhaps the balance of risk and reward is justified.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3228

From alanb at openjdk.java.net  Mon Mar 29 10:31:28 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 29 Mar 2021 10:31:28 GMT
Subject: RFR: 8264332: Use the blessed modifier order in jdk.charsets
In-Reply-To: <4yzvftI_KCA5YbxJml9vHzj_gh3oo1f7mCpAxQssvFA=.f5e52134-ea47-442d-b787-1d787cf9ad92@github.com>
References: <4yzvftI_KCA5YbxJml9vHzj_gh3oo1f7mCpAxQssvFA=.f5e52134-ea47-442d-b787-1d787cf9ad92@github.com>
Message-ID: <mLxrAOoLzAwtbsMdnfchANuopPYnLb5eaxQgCSVzIV8=.94665e0c-7ec8-4aad-9f26-5832e38c32b6@github.com>

On Sun, 28 Mar 2021 13:56:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264332: Use the blessed modifier order in jdk.charsets

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3236

From jai.forums2013 at gmail.com  Mon Mar 29 10:46:37 2021
From: jai.forums2013 at gmail.com (Jaikiran Pai)
Date: Mon, 29 Mar 2021 16:16:37 +0530
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <BAA7024A-3C04-4F8C-A5A5-B9CD1B361C41@oracle.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <1BB8805F-174A-4EB9-B26A-060B2251A40C@oracle.com>
 <e88d6a73-f126-6848-45a2-3960d9726de8@oracle.com>
 <6242cfe8-cef7-0603-33fc-b3428209a1ac@gmail.com>
 <C1A35D8F-B1D3-4233-AE2F-1D699BF74B65@oracle.com>
 <ab9bcc11-1f1b-b82e-2dfe-ae17ea630d7f@gmail.com>
 <F7E99E98-2000-4ACD-B3A9-CEBE4903D26D@oracle.com>
 <1e14f8e1-c4d2-1e11-df88-8af083bac8f9@gmail.com>
 <9B159F65-A7CC-4FEA-BAB8-77D66D7AD5AB@oracle.com>
 <73dcce4d-0b53-23bd-b706-bf4fdbcbe256@oracle.com>
 <9030C4FE-9D94-496B-9E06-C8B9B7664651@oracle.com>
 <2a54cca7-1132-37e6-d8cc-9f9db7b3f6b5@oracle.com>
 <69369159-FB85-4812-976B-53019FCD5FC6@oracle.com>
 <237e6c14-8593-69df-5866-4a238e020fce@oracle.com>
 <b10be763-cf85-a144-87bb-0653f3a0a1ec@gmail.com>
 <e24c6f02-2672-4dfa-e699-c8a34cb617f9@gmail.com>
 <BAA7024A-3C04-4F8C-A5A5-B9CD1B361C41@oracle.com>
Message-ID: <495db34e-48a8-489d-8a86-36ba74870d60@gmail.com>


On 28/03/21 9:52 pm, Lance Andersen wrote:
>
>
>> On Mar 28, 2021, at 9:24 AM, Jaikiran Pai <jai.forums2013 at gmail.com 
>> <mailto:jai.forums2013 at gmail.com>> wrote:
>>
>>
>> Now when the user explicitly specifies the new -C or --dir option 
>> with the -P option for extract, something like:
>>
>> jar -xfP foo.jar -C /tmp/hello/
>
> Given the support of -C/-dir is new and -P is there for backwards 
> compatibility then I see the choices are:
>
>   * Issue an error when -P and -C/-dir are specified together with -x
>   * Silently ignore the -P option
>   * Ignore -C/-dir and the behavior is if -xfP was specified.
>
>
> I am leaning towards an error given this is a new feature when -P and 
> -C/-dir are specified with -x

That sounds reasonable to me. I'll update the PR accordingly to take 
this into account.

-Jaikiran



From github.com+741251+turbanoff at openjdk.java.net  Mon Mar 29 13:34:27 2021
From: github.com+741251+turbanoff at openjdk.java.net (Andrey Turbanov)
Date: Mon, 29 Mar 2021 13:34:27 GMT
Subject: Integrated: 8264029: Replace uses of StringBuffer with StringBuilder
 in java.base
In-Reply-To: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com>
References: <2VOSu01Jk4NxUMyb7yhxh9hY0KMMjjmMCfq_TSFNvNE=.8d809c0c-5664-46e8-ab9e-0ec78a8ead67@github.com>
Message-ID: <rHP4ESf1h0WvcUvWdBWHQCj5bIYYZaHa8OLJnXrzjZQ=.696dd190-ff1d-448e-ba3d-f77baec9f813@github.com>

On Wed, 10 Mar 2021 19:47:00 GMT, Andrey Turbanov <github.com+741251+turbanoff at openjdk.org> wrote:

> Found by IntelliJ IDEA inspection `Java | Java language level migration aids | Java 5 | 'StringBuffer' may be 'StringBuilder'`
> As suggested in https://github.com/openjdk/jdk/pull/1507#issuecomment-757369003 I've created separate PR for module `java.base`
> Similar cleanup in the past - https://bugs.openjdk.java.net/browse/JDK-8041679

This pull request has now been integrated.

Changeset: fbbd98ba
Author:    Andrey Turbanov <turbanoff at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/fbbd98ba
Stats:     12 lines in 3 files changed: 0 ins; 3 del; 9 mod

8264029: Replace uses of StringBuffer with StringBuilder in java.base

Reviewed-by: shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/2922

From shade at openjdk.java.net  Mon Mar 29 13:36:25 2021
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 29 Mar 2021 13:36:25 GMT
Subject: RFR: 8264332: Use the blessed modifier order in jdk.charsets
In-Reply-To: <4yzvftI_KCA5YbxJml9vHzj_gh3oo1f7mCpAxQssvFA=.f5e52134-ea47-442d-b787-1d787cf9ad92@github.com>
References: <4yzvftI_KCA5YbxJml9vHzj_gh3oo1f7mCpAxQssvFA=.f5e52134-ea47-442d-b787-1d787cf9ad92@github.com>
Message-ID: <QzacK00OM0pdqCCzbILYAWzbVWzFlx3lo0eGoowFo7U=.a5a2f37a-6471-4f2b-b2c7-e217bd0a0dbd@github.com>

On Sun, 28 Mar 2021 13:56:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264332: Use the blessed modifier order in jdk.charsets

Marked as reviewed by shade (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3236

From github.com+76791+alblue at openjdk.java.net  Mon Mar 29 13:36:26 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Mon, 29 Mar 2021 13:36:26 GMT
Subject: Integrated: 8264332: Use the blessed modifier order in jdk.charsets
In-Reply-To: <4yzvftI_KCA5YbxJml9vHzj_gh3oo1f7mCpAxQssvFA=.f5e52134-ea47-442d-b787-1d787cf9ad92@github.com>
References: <4yzvftI_KCA5YbxJml9vHzj_gh3oo1f7mCpAxQssvFA=.f5e52134-ea47-442d-b787-1d787cf9ad92@github.com>
Message-ID: <iSwvVwyzTpxHb9YS2Q3dNe3qGGFy-faARpaiF3VyZk8=.7f1d7170-d0f9-403e-8450-6fe10d38a8d8@github.com>

On Sun, 28 Mar 2021 13:56:00 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264332: Use the blessed modifier order in jdk.charsets

This pull request has now been integrated.

Changeset: 364cce14
Author:    Alex Blewitt <alex.blewitt at gmail.com>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/364cce14
Stats:     56 lines in 6 files changed: 0 ins; 0 del; 56 mod

8264332: Use the blessed modifier order in jdk.charsets

Reviewed-by: alanb, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/3236

From jpai at openjdk.java.net  Mon Mar 29 14:04:10 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 29 Mar 2021 14:04:10 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a
 directory [v3]
In-Reply-To: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
Message-ID: <wJWTT4pJBi4VAIR8MpsVhzm_9iy42ehwzec9JxHXHsc=.5b981f07-a864-4f53-baa4-00df1116c73a@github.com>

> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
> 
> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
> 
> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
> 
> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
> 
> The commit also includes a jtreg testcase which verifies the usage of this new option.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - Alan's review feedback for -C help text
 - Keep -xfP backward compatible but don't allow -C/--dir with -xfP

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/2752/files
  - new: https://git.openjdk.java.net/jdk/pull/2752/files/a9954240..3df602d2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=2752&range=01-02

  Stats: 88 lines in 3 files changed: 78 ins; 3 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/2752.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/2752/head:pull/2752

PR: https://git.openjdk.java.net/jdk/pull/2752

From asemenyuk at openjdk.java.net  Mon Mar 29 18:18:41 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 29 Mar 2021 18:18:41 GMT
Subject: RFR: 8248418: jpackage fails to extract main class and version from
 app module linked in external runtime
Message-ID: <X2DlcuPOop0-B0Ema5OxeWPYFipcygxczWyS6HqOKqc=.d7d836eb-d78e-4cc0-a581-4df066ae80dc@github.com>

Remove the test for failing jpackage use case scenario that we don't intent to fix

-------------

Commit messages:
 - 8248418: jpackage fails to extract main class and version from app module linked in external runtime

Changes: https://git.openjdk.java.net/jdk/pull/3249/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3249&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8248418
  Stats: 23 lines in 2 files changed: 0 ins; 23 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3249.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3249/head:pull/3249

PR: https://git.openjdk.java.net/jdk/pull/3249

From herrick at openjdk.java.net  Mon Mar 29 18:56:40 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 29 Mar 2021 18:56:40 GMT
Subject: RFR: 8248418: jpackage fails to extract main class and version
 from app module linked in external runtime
In-Reply-To: <X2DlcuPOop0-B0Ema5OxeWPYFipcygxczWyS6HqOKqc=.d7d836eb-d78e-4cc0-a581-4df066ae80dc@github.com>
References: <X2DlcuPOop0-B0Ema5OxeWPYFipcygxczWyS6HqOKqc=.d7d836eb-d78e-4cc0-a581-4df066ae80dc@github.com>
Message-ID: <KFKi3GbvEu36Y8okSoF6ZLW7Qgkn8ij0JdF9WjGx8TE=.fb3247af-b653-4bae-9bee-57a7188c0408@github.com>

On Mon, 29 Mar 2021 18:11:26 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Remove the test for failing jpackage use case scenario that we don't intent to fix

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3249

From almatvee at openjdk.java.net  Mon Mar 29 19:29:44 2021
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Mon, 29 Mar 2021 19:29:44 GMT
Subject: RFR: 8248418: jpackage fails to extract main class and version
 from app module linked in external runtime
In-Reply-To: <X2DlcuPOop0-B0Ema5OxeWPYFipcygxczWyS6HqOKqc=.d7d836eb-d78e-4cc0-a581-4df066ae80dc@github.com>
References: <X2DlcuPOop0-B0Ema5OxeWPYFipcygxczWyS6HqOKqc=.d7d836eb-d78e-4cc0-a581-4df066ae80dc@github.com>
Message-ID: <xqyyPm5UPqGbT2AC3HwrzItk_vGthSiSp6U_MY5HN7Y=.4f50d4f6-cc52-4e88-b5a3-8cb76e43a070@github.com>

On Mon, 29 Mar 2021 18:11:26 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Remove the test for failing jpackage use case scenario that we don't intent to fix

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3249

From asemenyuk at openjdk.java.net  Mon Mar 29 19:55:44 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 29 Mar 2021 19:55:44 GMT
Subject: Integrated: 8248418: jpackage fails to extract main class and version
 from app module linked in external runtime
In-Reply-To: <X2DlcuPOop0-B0Ema5OxeWPYFipcygxczWyS6HqOKqc=.d7d836eb-d78e-4cc0-a581-4df066ae80dc@github.com>
References: <X2DlcuPOop0-B0Ema5OxeWPYFipcygxczWyS6HqOKqc=.d7d836eb-d78e-4cc0-a581-4df066ae80dc@github.com>
Message-ID: <7Apt98wa9YesTDdU4mMq5vxJwFsMg8fRCSi-ptM6Te8=.c657b8e7-a844-477b-adf4-a09e6414c825@github.com>

On Mon, 29 Mar 2021 18:11:26 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Remove the test for failing jpackage use case scenario that we don't intent to fix

This pull request has now been integrated.

Changeset: 128c0c97
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/128c0c97
Stats:     23 lines in 2 files changed: 0 ins; 23 del; 0 mod

8248418: jpackage fails to extract main class and version from app module linked in external runtime

Reviewed-by: herrick, almatvee

-------------

PR: https://git.openjdk.java.net/jdk/pull/3249

From raffaello.giulietti at gmail.com  Mon Mar 29 20:14:53 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Mon, 29 Mar 2021 22:14:53 +0200
Subject: Proposal for Decimal64 and Decimal128 value-based classes
Message-ID: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>

Hello,

I'm experimenting with an implementation of Decimal64 and Decimal128, 
two standard IEEE 754-2019 formats supporting, well, decimal floating 
point numbers of up to 16 resp 34 decimal digits.

While BigDecimal can simulate most finite number computations on these 
formats by passing MathContext.DECIMAL64 and MathContext.DECIMAL128, 
resp., to the arithmetic operations, this approach has some shortcomings 
wrt to the standard:
* Like the binary formats (float and double in Java), the standard 
mandates signed zeroes, signed infinities and NaNs for the decimal 
formats as well, while BigDecimal has neither.
* BigDecimal is not a final class, so is not (and can never be) value-based.
* BigDecimal needs support from BigInteger (another non final, non 
value-based class).

On the other hand, classes Decimal64 and Decimal128:
* Are value-based and can be declared to be primitive in a future 
version of OpenJDK, once Valhalla is completed.
* Require 12 and 20 bytes, resp, of storage in the Valhalla model of 
primitive objects and have no references to other identity or primitive 
objects.
* Support the signed zeroes, the infinities and the NaNs.
* Currently support the 4 fundamental operations (+ - * /) according to 
the standard and will support remainder, square root, comparisons, etc. 
and the conversions listed in the standard.
* Could be extended to support the (rather cumbersome) exceptions 
handling of the standard.
* There's no plan to support transcendental functions, as the aim is to 
have numerical classes for business applications, not scientific or 
engineering purposes.
* Are faster than the (incomplete) simulation with BigDecimal, 1x-5x in 
the current incarnations.


I would be glad to contribute the code to the OpenJDK provided there is 
a genuine interest from the community and a reviewer willing to sponsor 
my effort. (I guess the best candidate for this role would be Joe Darcy 
from what I can read in this mailing list.)


Greetings
Raffaello

From rriggs at openjdk.java.net  Mon Mar 29 20:41:35 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 29 Mar 2021 20:41:35 GMT
Subject: Integrated: 8263754: HexFormat 'fromHex' methods should be static
In-Reply-To: <vgld966LDtRNI2RDlfmRq5CSrS5T5-MOSAr7vCTf_hE=.3de9cbb9-c1b5-49a6-a8c0-38d78a3ee6e2@github.com>
References: <vgld966LDtRNI2RDlfmRq5CSrS5T5-MOSAr7vCTf_hE=.3de9cbb9-c1b5-49a6-a8c0-38d78a3ee6e2@github.com>
Message-ID: <XB6k4A31uO-sjyTr_hL7HZafGOv77-WddzerU4ZLkoU=.fe4c5e91-624a-4929-83c3-bb5f555a4e72@github.com>

On Thu, 25 Mar 2021 20:08:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A number of HexFormat methods converting from strings to numbers do not use delimiter, prefix, suffix, and uppercase parameters and would be more convenient if the methods were static.
> 
> These  APIs were added early in JDK 17 and are being updated before GA.
> This PR updates existing uses in the JDK but there may be compiler warnings in non-JDK source files.
> 
>    public boolean isHexDigit(int);
>    public int fromHexDigit(int);
>    public int fromHexDigits(java.lang.CharSequence);
>    public int fromHexDigits(java.lang.CharSequence, int, int);
>    public long fromHexDigitsToLong(java.lang.CharSequence);
>    public long fromHexDigitsToLong(java.lang.CharSequence, int, int);

This pull request has now been integrated.

Changeset: 8cf1c62c
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8cf1c62c
Stats:     54 lines in 5 files changed: 0 ins; 15 del; 39 mod

8263754: HexFormat 'fromHex' methods should be static

Reviewed-by: redestad, naoto, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/3205

From raffaello.giulietti at gmail.com  Mon Mar 29 21:07:26 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Mon, 29 Mar 2021 23:07:26 +0200
Subject: Comment on CSR 8251991: Hex formatting and parsing utility
In-Reply-To: <cdd01acc-a5bc-df27-c02a-34c690b1ee9d@oracle.com>
References: <cff8a2aa-df5e-278f-1f5f-00a60c4a7298@gmail.com>
 <cdd01acc-a5bc-df27-c02a-34c690b1ee9d@oracle.com>
Message-ID: <95e8bd7f-2d4a-4dee-a9b8-7ce49109810f@gmail.com>

Thanks, I noticed.

There are a couple of other methods that can be simplified, require a 
couple of minutes to review and which don't have any impact on the API.

If you agree, I'll prepare a PR with all the changes and the bug 
narrative for you to add to bugs.openjdk.org (I only have read access).


Greetings
Raffaello



On 2021-03-26 16:08, Roger Riggs wrote:
> fyi,? a PR to make the methods static.
> 
> https://git.openjdk.java.net/jdk/pull/3205
> 
> On 3/15/21 4:26 PM, Raffaello Giulietti wrote:
>> Hello,
>>
>> I understand your points expressed in 
>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.html 
>>
>>
>> On the other hand, it kind of hurts when the javadoc spec implies that 
>> the fromXXX() methods do not logically depend on the state and yet one 
>> has to invoke them on some instance anyway.
>>
>>
>> As for HexFormat.of() to always return the same instance, you are of 
>> course right in observing that this is out of place for value-based 
>> classes. The intent was to describe a static-like idiom that would 
>> deter programmers to rewrite their own static version of these methods.
>>
>>
>> Greetings
>> Raffaello
>>
>>
>>> Hi,
>>>
>>> The question about static vs instance methods was raised during the 
>>> review.
>>> At the time, my rationale for the current API is summarized in this 
>>> email.
>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.html 
>>>
>>>
>>> It comes down to choosing one kind of consistency vs another.
>>>
>>> I was/am looking for additional comments to weigh one or the other 
>>> alternative.
>>> I did receive one offline comment in support of static methods on the 
>>> rationale of
>>> convenience.
>>>
>>> Regards, Roger
>>>
>>>
>>> On 3/15/21 12:06 PM, Raffaello Giulietti wrote:
>>>> Hi,
>>>>
>>>> the javadoc of most of the methods listed in my previous post below 
>>>> reads:
>>>> ??? "The delimiter, prefix, suffix, and uppercase parameters are not 
>>>> used."
>>>>
>>>> As these eventually constitute the whole state of an instance of 
>>>> this final class and as the state is not involved, it is possible to 
>>>> declare the methods as static.
>>>>
>>>>
>>>> If, for some reason, declaring the methods as static is not a 
>>>> choice, the next best thing is to clarify that
>>>> * HexFormat.of() always returns the same instance and thus
>>>> * absent any other instance, the recommended idiom for invoking any 
>>>> of the methods below is, for example,
>>>> ??? HexFormat.of().isHexDigit('F')
>>>> (because there are almost no additional costs wrt static methods.)
>>> Note that HexFormat is specified as a value based class and
>>> any statement related to identity is out of place.
>>>
>>> Incidentally, its generally discouraged and can cause a warning when 
>>> a static method is invoked using a reference.
>>>
>>>>
>>>> But I don't see a reason why they should be non-static. Just oversight?
>>>>
>>>>
>>>> Greetings
>>>> Raffaello
>>>>
>>>>
>>>> On 2021-03-08 11:52, Raffaello Giulietti wrote:
>>>>> Hello,
>>>>>
>>>>> it appears that all of the following API methods in [1] can be 
>>>>> declared *static*, which makes them more useful in contexts where 
>>>>> there's no instance of HexFormat available or none is desired.
>>>>>
>>>>> As 17 has not yet entered any formal phase, the change should be 
>>>>> harmless.
>>>>>
>>>>> ?? public boolean isHexDigit(int);
>>>>> ?? public int fromHexDigit(int);
>>>>> ?? public int fromHexDigits(java.lang.CharSequence);
>>>>> ?? public int fromHexDigits(java.lang.CharSequence, int, int);
>>>>> ?? public long fromHexDigitsToLong(java.lang.CharSequence);
>>>>> ?? public long fromHexDigitsToLong(java.lang.CharSequence, int, int);
>>>>>
>>>>> Greetings
>>>>> Raffaello
>>>>>
>>>>> ----
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8251991
> 

From github.com+76791+alblue at openjdk.java.net  Mon Mar 29 21:17:06 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Mon, 29 Mar 2021 21:17:06 GMT
Subject: RFR: 8264397: Use the blessed modifier order in jdk.incubator.foreign
Message-ID: <S8y1iC02mJVfaCzrbFMxNe1fcbZAqsS6xDo_6kKZwBY=.283524b1-104f-47f7-9996-b2b8977a09ac@github.com>

8264397: Use the blessed modifier order in jdk.incubator.foreign

-------------

Commit messages:
 - 8264397: Use the blessed modifier order in jdk.incubator.foreign

Changes: https://git.openjdk.java.net/jdk/pull/3253/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3253&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264397
  Stats: 16 lines in 8 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3253.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3253/head:pull/3253

PR: https://git.openjdk.java.net/jdk/pull/3253

From smarks at openjdk.java.net  Mon Mar 29 21:21:02 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 29 Mar 2021 21:21:02 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

The removal of the obsolescent "As of release 1.4, this exception has been retrofitted..." is good. Changing the calls from the other exception-getting methods to `getCause()` is also good. I'm less sure of the utility of deprecating these older methods. The deprecation will issue warning messages; is there any benefit to the calling code to migrating from the older methods to `getCause()`? If they're exactly equivalent, then I think the benefits are small, compared to the cost of dealing with warnings. Thus for most of these cases I think that not deprecating the older methods is reasonable, and perhaps the explanation should be converted to an `@apiNote`.

(The considerations for the JDK itself are different, though, which is why I support changing the call sites.)

One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3182

From darcy at openjdk.java.net  Mon Mar 29 21:21:02 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 29 Mar 2021 21:21:02 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for exception
 chaining
Message-ID: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>

8264148: Update spec for exceptions retrofitted for exception chaining

-------------

Commit messages:
 - Respond to review feedback.
 - Respond to review feedback.
 - Merge branch 'master' into 8264148
 - Merge branch 'master' into 8264148
 - 8264148: Update spec for exceptions retrofitted for exception chaining

Changes: https://git.openjdk.java.net/jdk/pull/3182/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3182&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264148
  Stats: 84 lines in 22 files changed: 8 ins; 44 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3182.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3182/head:pull/3182

PR: https://git.openjdk.java.net/jdk/pull/3182

From darcy at openjdk.java.net  Mon Mar 29 21:21:03 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Mon, 29 Mar 2021 21:21:03 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
Message-ID: <YGY3e5JZUid7DXjezumgNg-peG8xsYydHM1F_ZVbZ7o=.f2c5de76-0340-43aa-9698-dec84018dc6a@github.com>

On Thu, 25 Mar 2021 18:52:54 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> 8264148: Update spec for exceptions retrofitted for exception chaining
>
> The removal of the obsolescent "As of release 1.4, this exception has been retrofitted..." is good. Changing the calls from the other exception-getting methods to `getCause()` is also good. I'm less sure of the utility of deprecating these older methods. The deprecation will issue warning messages; is there any benefit to the calling code to migrating from the older methods to `getCause()`? If they're exactly equivalent, then I think the benefits are small, compared to the cost of dealing with warnings. Thus for most of these cases I think that not deprecating the older methods is reasonable, and perhaps the explanation should be converted to an `@apiNote`.
> 
> (The considerations for the JDK itself are different, though, which is why I support changing the call sites.)
> 
> One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong.

Some discussion of the proposed changes here. While the history with respect to the introduction of the chained exception mechanism may have been relevant in times past, those comments have little utility today. Per guidance from Dr. Deprecator, I've removed deprecation of the redundant methods and only kept deprecation of the mutable field in WriteAbortedException.

The legacy wrapped exception accessing methods in ClassNotFoundException, ExceptionInInitializerError, and UndeclaredThrowableException are equivalent to getCause. The legacy method in PrivilegedActionException returns the same value, but narrowed to Exception rather than Throwable.

Once the rest of the change is agree to, I'll update copyrights and do a CSR for the deprecation and other spec changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3182

From roger.riggs at oracle.com  Mon Mar 29 22:24:53 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Mon, 29 Mar 2021 18:24:53 -0400
Subject: Comment on CSR 8251991: Hex formatting and parsing utility
In-Reply-To: <95e8bd7f-2d4a-4dee-a9b8-7ce49109810f@gmail.com>
References: <cff8a2aa-df5e-278f-1f5f-00a60c4a7298@gmail.com>
 <cdd01acc-a5bc-df27-c02a-34c690b1ee9d@oracle.com>
 <95e8bd7f-2d4a-4dee-a9b8-7ce49109810f@gmail.com>
Message-ID: <dda39b30-bcee-091d-46b0-69b64fede153@oracle.com>

HI Raffaello,

Which methods and what did you have in mind?
(There may be good reasons for them as they are.)

Thanks, Roger


On 3/29/21 5:07 PM, Raffaello Giulietti wrote:
> Thanks, I noticed.
>
> There are a couple of other methods that can be simplified, require a 
> couple of minutes to review and which don't have any impact on the API.
>
> If you agree, I'll prepare a PR with all the changes and the bug 
> narrative for you to add to bugs.openjdk.org (I only have read access).
>
>
> Greetings
> Raffaello
>
>
>
> On 2021-03-26 16:08, Roger Riggs wrote:
>> fyi,? a PR to make the methods static.
>>
>> https://git.openjdk.java.net/jdk/pull/3205
>>
>> On 3/15/21 4:26 PM, Raffaello Giulietti wrote:
>>> Hello,
>>>
>>> I understand your points expressed in 
>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.html 
>>>
>>>
>>> On the other hand, it kind of hurts when the javadoc spec implies 
>>> that the fromXXX() methods do not logically depend on the state and 
>>> yet one has to invoke them on some instance anyway.
>>>
>>>
>>> As for HexFormat.of() to always return the same instance, you are of 
>>> course right in observing that this is out of place for value-based 
>>> classes. The intent was to describe a static-like idiom that would 
>>> deter programmers to rewrite their own static version of these methods.
>>>
>>>
>>> Greetings
>>> Raffaello
>>>
>>>
>>>> Hi,
>>>>
>>>> The question about static vs instance methods was raised during the 
>>>> review.
>>>> At the time, my rationale for the current API is summarized in this 
>>>> email.
>>>> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-October/070317.html 
>>>>
>>>>
>>>> It comes down to choosing one kind of consistency vs another.
>>>>
>>>> I was/am looking for additional comments to weigh one or the other 
>>>> alternative.
>>>> I did receive one offline comment in support of static methods on 
>>>> the rationale of
>>>> convenience.
>>>>
>>>> Regards, Roger
>>>>
>>>>
>>>> On 3/15/21 12:06 PM, Raffaello Giulietti wrote:
>>>>> Hi,
>>>>>
>>>>> the javadoc of most of the methods listed in my previous post 
>>>>> below reads:
>>>>> ??? "The delimiter, prefix, suffix, and uppercase parameters are 
>>>>> not used."
>>>>>
>>>>> As these eventually constitute the whole state of an instance of 
>>>>> this final class and as the state is not involved, it is possible 
>>>>> to declare the methods as static.
>>>>>
>>>>>
>>>>> If, for some reason, declaring the methods as static is not a 
>>>>> choice, the next best thing is to clarify that
>>>>> * HexFormat.of() always returns the same instance and thus
>>>>> * absent any other instance, the recommended idiom for invoking 
>>>>> any of the methods below is, for example,
>>>>> ??? HexFormat.of().isHexDigit('F')
>>>>> (because there are almost no additional costs wrt static methods.)
>>>> Note that HexFormat is specified as a value based class and
>>>> any statement related to identity is out of place.
>>>>
>>>> Incidentally, its generally discouraged and can cause a warning 
>>>> when a static method is invoked using a reference.
>>>>
>>>>>
>>>>> But I don't see a reason why they should be non-static. Just 
>>>>> oversight?
>>>>>
>>>>>
>>>>> Greetings
>>>>> Raffaello
>>>>>
>>>>>
>>>>> On 2021-03-08 11:52, Raffaello Giulietti wrote:
>>>>>> Hello,
>>>>>>
>>>>>> it appears that all of the following API methods in [1] can be 
>>>>>> declared *static*, which makes them more useful in contexts where 
>>>>>> there's no instance of HexFormat available or none is desired.
>>>>>>
>>>>>> As 17 has not yet entered any formal phase, the change should be 
>>>>>> harmless.
>>>>>>
>>>>>> ?? public boolean isHexDigit(int);
>>>>>> ?? public int fromHexDigit(int);
>>>>>> ?? public int fromHexDigits(java.lang.CharSequence);
>>>>>> ?? public int fromHexDigits(java.lang.CharSequence, int, int);
>>>>>> ?? public long fromHexDigitsToLong(java.lang.CharSequence);
>>>>>> ?? public long fromHexDigitsToLong(java.lang.CharSequence, int, 
>>>>>> int);
>>>>>>
>>>>>> Greetings
>>>>>> Raffaello
>>>>>>
>>>>>> ----
>>>>>>
>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8251991
>>


From redestad at openjdk.java.net  Mon Mar 29 23:57:44 2021
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 29 Mar 2021 23:57:44 GMT
Subject: RFR: 8264397: Use the blessed modifier order in
 jdk.incubator.foreign
In-Reply-To: <S8y1iC02mJVfaCzrbFMxNe1fcbZAqsS6xDo_6kKZwBY=.283524b1-104f-47f7-9996-b2b8977a09ac@github.com>
References: <S8y1iC02mJVfaCzrbFMxNe1fcbZAqsS6xDo_6kKZwBY=.283524b1-104f-47f7-9996-b2b8977a09ac@github.com>
Message-ID: <DghGx59T4CxKsAK-0GNtn8_UhLjcybiCYbvg9QSbye4=.d1fa3ec9-1c82-49ca-9d1f-2fdb071a6fff@github.com>

On Mon, 29 Mar 2021 21:09:56 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264397: Use the blessed modifier order in jdk.incubator.foreign

This one should probably be fixed in the upstream repo over at https://github.com/openjdk/panama-foreign (I believe). /ping @JornVernee @mcimadamore

-------------

PR: https://git.openjdk.java.net/jdk/pull/3253

From sirinath1978m at gmail.com  Tue Mar 30 01:13:54 2021
From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena)
Date: Tue, 30 Mar 2021 06:43:54 +0530
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
References: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
Message-ID: <CAAfFNYFwKoEj1hgx6YEebOi8N4A_XKDTegH8oaTM7uWfOfS=VA@mail.gmail.com>

This would be interesting to have.

It would be better if the full set of numbers b16-256 and d32-128 are
implemented so there is full coverage of all IEEE 754 numbers.


On Tue, 30 Mar 2021 at 01:45, Raffaello Giulietti <
raffaello.giulietti at gmail.com> wrote:

> Hello,
>
> I'm experimenting with an implementation of Decimal64 and Decimal128,
> two standard IEEE 754-2019 formats supporting, well, decimal floating
> point numbers of up to 16 resp 34 decimal digits.
>
> While BigDecimal can simulate most finite number computations on these
> formats by passing MathContext.DECIMAL64 and MathContext.DECIMAL128,
> resp., to the arithmetic operations, this approach has some shortcomings
> wrt to the standard:
> * Like the binary formats (float and double in Java), the standard
> mandates signed zeroes, signed infinities and NaNs for the decimal
> formats as well, while BigDecimal has neither.
> * BigDecimal is not a final class, so is not (and can never be)
> value-based.
> * BigDecimal needs support from BigInteger (another non final, non
> value-based class).
>
> On the other hand, classes Decimal64 and Decimal128:
> * Are value-based and can be declared to be primitive in a future
> version of OpenJDK, once Valhalla is completed.
> * Require 12 and 20 bytes, resp, of storage in the Valhalla model of
> primitive objects and have no references to other identity or primitive
> objects.
> * Support the signed zeroes, the infinities and the NaNs.
> * Currently support the 4 fundamental operations (+ - * /) according to
> the standard and will support remainder, square root, comparisons, etc.
> and the conversions listed in the standard.
> * Could be extended to support the (rather cumbersome) exceptions
> handling of the standard.
> * There's no plan to support transcendental functions, as the aim is to
> have numerical classes for business applications, not scientific or
> engineering purposes.
> * Are faster than the (incomplete) simulation with BigDecimal, 1x-5x in
> the current incarnations.
>
>
> I would be glad to contribute the code to the OpenJDK provided there is
> a genuine interest from the community and a reviewer willing to sponsor
> my effort. (I guess the best candidate for this role would be Joe Darcy
> from what I can read in this mailing list.)
>
>
> Greetings
> Raffaello
>

From dongbo at openjdk.java.net  Tue Mar 30 03:22:12 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 30 Mar 2021 03:22:12 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic [v2]
In-Reply-To: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
Message-ID: <wW3-lR4nav-LQec833kPoA4EsNrZFyHIj5FABSyhrwE=.1394d82c-789e-4bb4-b921-fbc40e382042@github.com>

> In JDK-8248188, IntrinsicCandidate and API is added for Base64 decoding.
> Base64 decoding can be improved on aarch64 with ld4/tbl/tbx/st3, a basic idea can be found at http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.
> 
> Patch passed jtreg tier1-3 tests with linux-aarch64-server-fastdebug build.
> Tests in `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java` runned specially for the correctness of the implementation.
> 
> There can be illegal characters at the start of the input if the data is MIME encoded.
> It would be no benefits to use SIMD for this case, so the stub use no-simd instructions for MIME encoded data now.
> 
> A JMH micro, Base64Decode.java, is added for performance test.
> With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
> we witness ~2.5x improvements with long inputs and no regression with short inputs for raw base64 decodeing, minor improvements (~10.95%) for MIME on Kunpeng916.
> 
> The Base64Decode.java JMH micro-benchmark results:
> 
> Benchmark                          (lineSize)  (maxNumBytes)  Mode  Cnt       Score       Error  Units
> 
> # Kunpeng916, intrinsic
> Base64Decode.testBase64Decode               4              1  avgt    5      48.614 ?     0.609  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      58.199 ?     1.650  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      69.400 ?     0.931  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5      96.818 ?     1.687  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     122.856 ?     9.217  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     130.935 ?     1.667  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     143.627 ?     1.751  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     152.311 ?     1.178  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     342.631 ?     0.584  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5     573.635 ?     1.050  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5    9534.136 ?    45.172  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   22718.726 ?   192.070  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      63.558 ?    0.336  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.504 ?    0.848  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     120.591 ?    0.608  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     324.314 ?    6.236  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     532.678 ?    4.670  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     678.126 ?    4.324  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     771.603 ?    6.393  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     889.608 ?   0.759  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    3663.557 ?    3.422  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7017.784 ?    9.128  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  128670.660 ? 7951.521  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  317113.667 ?  161.758  ns/op
> 
> # Kunpeng916, default
> Base64Decode.testBase64Decode               4              1  avgt    5      48.455 ?   0.571  ns/op
> Base64Decode.testBase64Decode               4              3  avgt    5      57.937 ?   0.505  ns/op
> Base64Decode.testBase64Decode               4              7  avgt    5      73.823 ?   1.452  ns/op
> Base64Decode.testBase64Decode               4             32  avgt    5     106.484 ?   1.243  ns/op
> Base64Decode.testBase64Decode               4             64  avgt    5     141.004 ?   1.188  ns/op
> Base64Decode.testBase64Decode               4             80  avgt    5     156.284 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4             96  avgt    5     174.137 ?   0.177  ns/op
> Base64Decode.testBase64Decode               4            112  avgt    5     188.445 ?   0.572  ns/op
> Base64Decode.testBase64Decode               4            512  avgt    5     610.847 ?   1.559  ns/op
> Base64Decode.testBase64Decode               4           1000  avgt    5    1155.368 ?   0.813  ns/op
> Base64Decode.testBase64Decode               4          20000  avgt    5   19751.477 ?  24.669  ns/op
> Base64Decode.testBase64Decode               4          50000  avgt    5   50046.586 ? 523.155  ns/op
> Base64Decode.testBase64MIMEDecode           4              1  avgt   10      64.130 ?   0.238  ns/op
> Base64Decode.testBase64MIMEDecode           4              3  avgt   10      82.096 ?   0.205  ns/op
> Base64Decode.testBase64MIMEDecode           4              7  avgt   10     118.849 ?   0.610  ns/op
> Base64Decode.testBase64MIMEDecode           4             32  avgt   10     331.177 ?   4.732  ns/op
> Base64Decode.testBase64MIMEDecode           4             64  avgt   10     549.117 ?   0.177  ns/op
> Base64Decode.testBase64MIMEDecode           4             80  avgt   10     702.951 ?   4.572  ns/op
> Base64Decode.testBase64MIMEDecode           4             96  avgt   10     799.566 ?   0.301  ns/op
> Base64Decode.testBase64MIMEDecode           4            112  avgt   10     923.749 ?   0.389  ns/op
> Base64Decode.testBase64MIMEDecode           4            512  avgt   10    4000.725 ?   2.519  ns/op
> Base64Decode.testBase64MIMEDecode           4           1000  avgt   10    7674.994 ?   9.281  ns/op
> Base64Decode.testBase64MIMEDecode           4          20000  avgt   10  142059.001 ? 157.920  ns/op
> Base64Decode.testBase64MIMEDecode           4          50000  avgt   10  355698.369 ? 216.542  ns/op

Dong Bo has updated the pull request with a new target base 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:

 - trivial fixes
 - Handling error in SIMD case with loops, combining two non-SIMD cases into one code blob, addressing other comments
 - Merge branch 'master' into aarch64.base64.decode
 - 8256245: AArch64: Implement Base64 decoding intrinsic

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3228/files
  - new: https://git.openjdk.java.net/jdk/pull/3228/files/8a898aec..e658ebf4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3228&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3228&range=00-01

  Stats: 9524 lines in 363 files changed: 7727 ins; 450 del; 1347 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3228.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3228/head:pull/3228

PR: https://git.openjdk.java.net/jdk/pull/3228

From dongbo at openjdk.java.net  Tue Mar 30 03:27:40 2021
From: dongbo at openjdk.java.net (Dong Bo)
Date: Tue, 30 Mar 2021 03:27:40 GMT
Subject: RFR: 8256245: AArch64: Implement Base64 decoding intrinsic
In-Reply-To: <vxrUJagEcM97odeOocaFBJjZC_lNQwiuGmJwD0s-7wc=.d75d3029-2513-405c-afa3-f1ed8e7af5a1@github.com>
References: <NmciaFsgNvy3-wo6VlRxLGevC1QRz9ufY0FSewcwgYI=.0c80245c-9a8a-44b1-9764-78e31cdeaa0c@github.com>
 <LNx0HU4HK5QDeGDJSrtylpV-L9vFYseHmMjQaK6Irxc=.b7707afc-9b72-4c84-a958-339686e24d79@github.com>
 <Mmpv2GPk-CHhcg1Lc_ZwR8717iDI0iQDUACdv_HKdMg=.cd2989be-9099-467e-9310-889c658efe60@github.com>
 <_ZrhnM9OyXLckhtT27laLzWPZbCFZTPjm6ePbZdbyOs=.fcc6aaba-1578-443a-aa57-8141a99231f6@github.com>
 <vxrUJagEcM97odeOocaFBJjZC_lNQwiuGmJwD0s-7wc=.d75d3029-2513-405c-afa3-f1ed8e7af5a1@github.com>
Message-ID: <Nn9jqfMe-xnqho_oiJKjJwTMc7rRUy3cjrB0E0RpsqY=.34512df4-3587-4b8c-96e2-af4d82851c8f@github.com>

On Mon, 29 Mar 2021 08:38:59 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > With an intial implemention, we can have almost half of the code size reduced (1312B -> 748B). Sounds OK to you?
> 
> Sounds great, but I'm still somewhat concerned that the non-SIMD case only offers 3-12% performance gain. Make it just 748 bytes, and therefore not icache-hostile, then perhaps the balance of risk and reward is justified.

Hi, @theRealAph @nick-arm 

The code is updated. The error handling in SIMD case was rewriten as loops.

Also combined the two non-SIMD code blocks into one.
Due to we have only one non-SIMD loop now, it is moved into `generate_base64_decodeBlock`.
The size of the stub is 692 bytes, the non-SIMD loop takes about 92 bytes if my calculation is right.

Verified with tests `test/jdk/java/util/Base64/` and `compiler/intrinsics/base64/TestBase64.java`.
Compared with previous implementation, the performance changes are negligible.

Other comments are addressed too. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3228

From github.com+28367473+jmehrens at openjdk.java.net  Tue Mar 30 04:01:57 2021
From: github.com+28367473+jmehrens at openjdk.java.net (jmehrens)
Date: Tue, 30 Mar 2021 04:01:57 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <6OMPZyYBcENA0hYJp2fEMiwyhvAIT7cXwPoMVQ0TIUc=.65348cfa-1afe-4a3d-8d18-002f2be28d7d@github.com>
Message-ID: <dGNio-0tGjN8jEVGIMK8y212esY7r1g9L8CjyJYbcDE=.a43a1fd2-9dba-4971-96c1-d84a716f746a@github.com>

On Thu, 25 Mar 2021 18:52:54 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> One special case is the **public field** in `WriteAbortedException`. This is really bad and something ought to be done about this, including deprecation, and maybe more. This implies that the exception is mutable, right? Hrrmph. Isn't there a general rule that once the cause has been set (either via a constructor or via initCause) the exception is immutable? Maybe the field should be deprecated, and `getCause()` should return the cause from the superclass. That's a behavior change of course, and I don't know how to assess the compatibility impact. But the current situation just seems wrong.


Agreed. WriteAbortedException should get similar treatment as the others like it:

- http://cr.openjdk.java.net/~dmeetry/8009581/webrev.5/
- http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016908.html
- http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017594.html
- https://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051341.html

The only twist is that we would have to keep the public field as deprecated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3182

From github.com+10835776+stsypanov at openjdk.java.net  Tue Mar 30 06:52:43 2021
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Tue, 30 Mar 2021 06:52:43 GMT
Subject: Integrated: 8263560: Remove needless wrapping with BufferedInputStream
In-Reply-To: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
References: <kgcVc2QXO1a9Yq9wyZH_TFTtI2NM3NEk0TOXLekVhng=.31e105e7-ceda-4211-a9d0-68d201529d74@github.com>
Message-ID: <c6tIF-4jWFv4iLkJPlKq7ABPqw2f_gCnrflDqE6AxwQ=.6187aee6-098b-4ab3-83d8-e7fcb289b015@github.com>

On Sat, 13 Mar 2021 22:29:23 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> In some cases wrapping of `InputStream` with `BufferedInputStream` is redundant, e.g. in case the wrapped one is `ByteArrayOutputStream` which does not require any buffer having one within.
> 
> Other cases are related to reading either a byte or short `byte[]`: in both cases `BufferedInputStream.fill()` will be called resulting in load of much bigger amount of data (8192 by default) than required.

This pull request has now been integrated.

Changeset: 1a681fa7
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1a681fa7
Stats:     12 lines in 2 files changed: 2 ins; 5 del; 5 mod

8263560: Remove needless wrapping with BufferedInputStream

Reviewed-by: prr, alanb, dfuchs, serb

-------------

PR: https://git.openjdk.java.net/jdk/pull/2992

From github.com+76791+alblue at openjdk.java.net  Tue Mar 30 08:17:46 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Tue, 30 Mar 2021 08:17:46 GMT
Subject: RFR: 8264397: Use the blessed modifier order in
 jdk.incubator.foreign
In-Reply-To: <DghGx59T4CxKsAK-0GNtn8_UhLjcybiCYbvg9QSbye4=.d1fa3ec9-1c82-49ca-9d1f-2fdb071a6fff@github.com>
References: <S8y1iC02mJVfaCzrbFMxNe1fcbZAqsS6xDo_6kKZwBY=.283524b1-104f-47f7-9996-b2b8977a09ac@github.com>
 <DghGx59T4CxKsAK-0GNtn8_UhLjcybiCYbvg9QSbye4=.d1fa3ec9-1c82-49ca-9d1f-2fdb071a6fff@github.com>
Message-ID: <h1-4oxvZOZ0Ftv0NLoABjU3NdkBLLm-2qOuLGHpOrwo=.5b8f4c16-1544-41e1-bd6d-4845e0b73eca@github.com>

On Mon, 29 Mar 2021 23:54:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> 8264397: Use the blessed modifier order in jdk.incubator.foreign
>
> This one should probably be fixed in the upstream repo over at https://github.com/openjdk/panama-foreign (I believe). /ping @JornVernee @mcimadamore

Happy to submit a fix elsewhere if that's the right thing to do?

-------------

PR: https://git.openjdk.java.net/jdk/pull/3253

From raffaello.giulietti at gmail.com  Tue Mar 30 10:30:09 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Tue, 30 Mar 2021 12:30:09 +0200
Subject: Proposal for Decimal64 and Decimal128 value-based classes
Message-ID: <ce8429b1-293e-cfdd-2292-686a47873d18@gmail.com>

Hi,

the intent of this proposal is to have numerical classes for *business 
and financial applications*, not to implement the IEEE 754-2019 spec for 
the sake of full coverage.

The goal is to have numerical classes that are lighter-weight and more 
efficient in terms of storage space and computation time wrt BigDecimal 
*and* to adhere to a widespread standard whose model is familiar to many 
programmers.

Perhaps some extended precision decimal format could be handy. On the 
other hand, I don't see why binary floating point numbers would be a 
useful option in this area.


Greetings
Raffaello



> This would be interesting to have.
> 
> It would be better if the full set of numbers b16-256 and d32-128 are
> implemented so there is full coverage of all IEEE 754 numbers.
> 
> 
> On Tue, 30 Mar 2021 at 01:45, Raffaello Giulietti <
> raffaello.giulietti at gmail.com> wrote:
> 
>> Hello,
>>
>> I'm experimenting with an implementation of Decimal64 and Decimal128,
>> two standard IEEE 754-2019 formats supporting, well, decimal floating
>> point numbers of up to 16 resp 34 decimal digits.
>>
>> While BigDecimal can simulate most finite number computations on these
>> formats by passing MathContext.DECIMAL64 and MathContext.DECIMAL128,
>> resp., to the arithmetic operations, this approach has some shortcomings
>> wrt to the standard:
>> * Like the binary formats (float and double in Java), the standard
>> mandates signed zeroes, signed infinities and NaNs for the decimal
>> formats as well, while BigDecimal has neither.
>> * BigDecimal is not a final class, so is not (and can never be)
>> value-based.
>> * BigDecimal needs support from BigInteger (another non final, non
>> value-based class).
>>
>> On the other hand, classes Decimal64 and Decimal128:
>> * Are value-based and can be declared to be primitive in a future
>> version of OpenJDK, once Valhalla is completed.
>> * Require 12 and 20 bytes, resp, of storage in the Valhalla model of
>> primitive objects and have no references to other identity or primitive
>> objects.
>> * Support the signed zeroes, the infinities and the NaNs.
>> * Currently support the 4 fundamental operations (+ - * /) according to
>> the standard and will support remainder, square root, comparisons, etc.
>> and the conversions listed in the standard.
>> * Could be extended to support the (rather cumbersome) exceptions
>> handling of the standard.
>> * There's no plan to support transcendental functions, as the aim is to
>> have numerical classes for business applications, not scientific or
>> engineering purposes.
>> * Are faster than the (incomplete) simulation with BigDecimal, 1x-5x in
>> the current incarnations.
>>
>>
>> I would be glad to contribute the code to the OpenJDK provided there is
>> a genuine interest from the community and a reviewer willing to sponsor
>> my effort. (I guess the best candidate for this role would be Joe Darcy
>> from what I can read in this mailing list.)
>>
>>
>> Greetings
>> Raffaello
>>


From jlaskey at openjdk.java.net  Tue Mar 30 11:07:47 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 30 Mar 2021 11:07:47 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v31]
In-Reply-To: <7yvwMppH8E53dxxutLQCRKg6UpiXwjzobRmjz9hOOHM=.d4b62b25-849e-4539-a207-f136a6e96b52@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <VKucCe2YRlRl3S6HDMxN5_q9xx6450oLSs2eHsfEFIA=.3dc00672-45c9-4f1e-b5bd-1968aa0bf63b@github.com>
 <qd5H4ke7UsQlKhgmxSa9ssITkjopLucGg3bVmP1SKNs=.9b49cd22-25a0-44de-984c-3b3ca5a0f0c2@github.com>
 <7yvwMppH8E53dxxutLQCRKg6UpiXwjzobRmjz9hOOHM=.d4b62b25-849e-4539-a207-f136a6e96b52@github.com>
Message-ID: <9Es77RTptBxFcVenc1vGjX4aDX0ebTKV75rzZJxR0uo=.35dad54d-1d18-438c-8050-306c6fe66982@github.com>

On Thu, 18 Mar 2021 12:57:16 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 62:
>> 
>>> 60:     @Retention(RetentionPolicy.RUNTIME)
>>> 61:     @Target(ElementType.TYPE)
>>> 62:     public @interface RandomGeneratorProperties {
>> 
>> Should the is-deprecated information be stored here?
>
> I don't think so. That would require the deprecation state be stored in two places. I think it's sufficient to rely on the presence of @Deprecated.

isDeprecated was added

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From jlaskey at openjdk.java.net  Tue Mar 30 11:12:07 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 30 Mar 2021 11:12:07 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v38]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <pMFasySD2h2x87OA5reBbEukJA0x-gH0BCFchF0t20I=.c2261902-c66a-48db-a92f-4622bb01e62e@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 74 commits:

 - Merge branch 'master' into 8248862
 - CSR review revisions
 - CSR review updates
 - Removed @since from nextDouble ThreadLocalRandom
 - RandomGeneratorFactory::all(Class<T> category) @implNote was out of date
 - Clarify all()
 - Cleaned up ints(), longs(), doubles()
 - Merge branch 'master' into 8248862
 - Review revisions
 - Missing @since
 - ... and 64 more: https://git.openjdk.java.net/jdk/compare/f3726a87...3de42645

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=37
  Stats: 12965 lines in 26 files changed: 11199 ins; 1588 del; 178 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

PR: https://git.openjdk.java.net/jdk/pull/1292

From aefimov at openjdk.java.net  Tue Mar 30 11:38:55 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Tue, 30 Mar 2021 11:38:55 GMT
Subject: RFR: 8264048: Fix caching in Jar URL connections when an entry is
 missing
Message-ID: <1n33RkwMvQZNEeyHOmPjK9UUNp9hc5esxRwL00sT_IM=.45c6aa6e-39c1-4048-b05e-9a6aa765469e@github.com>

Current fix tries to tackle an issue with URL connection referencing non-existing Jar file entries:
If an entry that doesn't exist is specified in an URL connection the underlying Jar file is still cached even if an exception is thrown after that. Such behavior prevents the caller, for instance, a `URLClassLoader`, from closing a Jar file.

The proposed fix checks if entry exists before caching a Jar file (only for cases with enabled caching):
- If entry exists - jar file is cached if it wasn't cached before
- If entry doesn't exist and jar file wasn't cached before - jar file is closed and exception is thrown
- If entry doesn't exist and jar file was cached before - jar file is kept cached and exception is thrown


The following tests have been used to verify the fix:
- New regression tests
- ``:jdk_core:`` tests
- `api/java_util`,`api/java_net` JCK tests

-------------

Commit messages:
 - Merge remote-tracking branch 'origin' into JDK-8264048
 - 8264048: Fix caching in Jar URL connections when an entry is missing

Changes: https://git.openjdk.java.net/jdk/pull/3263/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3263&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264048
  Stats: 551 lines in 7 files changed: 525 ins; 2 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3263/head:pull/3263

PR: https://git.openjdk.java.net/jdk/pull/3263

From mcimadamore at openjdk.java.net  Tue Mar 30 11:51:40 2021
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 30 Mar 2021 11:51:40 GMT
Subject: RFR: 8264397: Use the blessed modifier order in
 jdk.incubator.foreign
In-Reply-To: <h1-4oxvZOZ0Ftv0NLoABjU3NdkBLLm-2qOuLGHpOrwo=.5b8f4c16-1544-41e1-bd6d-4845e0b73eca@github.com>
References: <S8y1iC02mJVfaCzrbFMxNe1fcbZAqsS6xDo_6kKZwBY=.283524b1-104f-47f7-9996-b2b8977a09ac@github.com>
 <DghGx59T4CxKsAK-0GNtn8_UhLjcybiCYbvg9QSbye4=.d1fa3ec9-1c82-49ca-9d1f-2fdb071a6fff@github.com>
 <h1-4oxvZOZ0Ftv0NLoABjU3NdkBLLm-2qOuLGHpOrwo=.5b8f4c16-1544-41e1-bd6d-4845e0b73eca@github.com>
Message-ID: <mQyEUYhJLFLQIES7JzR1RDnvh4cak4tHxuCG4GNQwpY=.c1a2de68-3533-4cb6-96ee-588d7afb62ea@github.com>

On Tue, 30 Mar 2021 08:14:58 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> This one should probably be fixed in the upstream repo over at https://github.com/openjdk/panama-foreign (I believe). /ping @JornVernee @mcimadamore
>
> Happy to submit a fix elsewhere if that's the right thing to do?

Hi @alblue, thanks for the contribution. We will make sure to integrate this at some point, but I don't think now is the right moment to do this kind of stylistic changes to the API/implementation. If you want to integrate the fix now, I'd suggest to file a PR against https://github.com/openjdk/panama-foreign, and we'll be happy to sponsor the change. That way you'd be guaranteed the change would be included in the next incubation round.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3253

From sundar at openjdk.java.net  Tue Mar 30 12:41:10 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Tue, 30 Mar 2021 12:41:10 GMT
Subject: RFR: 8262503: Support records in Dynalink
In-Reply-To: <yO1O4eJNyQhMbkx-h1gbgcvRbkrknAox4oMjkrGUi6U=.8ee56a7f-39b8-4a9b-a497-c2576767d090@github.com>
References: <yO1O4eJNyQhMbkx-h1gbgcvRbkrknAox4oMjkrGUi6U=.8ee56a7f-39b8-4a9b-a497-c2576767d090@github.com>
Message-ID: <v7tQzdZLojPapGAQ9zBmrfZavuyilf-XF6bsCsQIa-0=.be87fbbc-8629-45b6-9f96-689c49edfd17@github.com>

On Sun, 28 Feb 2021 16:46:31 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> 8262503: Support records in Dynalink

Looks good

-------------

Marked as reviewed by sundar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/2767

From sundar at openjdk.java.net  Tue Mar 30 12:46:15 2021
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Tue, 30 Mar 2021 12:46:15 GMT
Subject: RFR: 8264326: Modernize javax.script.ScriptEngineManager and
 related classes' implementation [v2]
In-Reply-To: <bnYgrO5cxB6AH9ekGM0j2gBPo6DQlEFoHGefCk9GZ4Q=.ab39c81c-e55d-476f-a1cf-562f00c98a76@github.com>
References: <ZLqKPN5QGdkNhY5b4CswU76jOLCYBCrAG6W_i84gXxs=.baae1d66-f3a9-45e9-8761-f7871b5bf0d1@github.com>
 <bnYgrO5cxB6AH9ekGM0j2gBPo6DQlEFoHGefCk9GZ4Q=.ab39c81c-e55d-476f-a1cf-562f00c98a76@github.com>
Message-ID: <bAEtctHv96JOCkx6qxECZaYdjLSzNZrLP0AGpQUbZKk=.26c10187-c7dc-4b83-89d2-436f2526a54c@github.com>

On Sun, 28 Mar 2021 13:38:51 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> I noticed that `javax.script.ScriptEngineManager` `getEngineByXxx` methods had a lot of code duplication among themselves, and even within each method. I refactored them into a modern unified implementation. While there I also took the opportunity to introduce `Objects.requireNonNull` in place of null checks followed by NPE throws, mark private fields final where possible, use lambdas for `doPrivileged` block, use `List.of` and `List.copyOf` where possible, and generally sanitize/deduplicate.
>
> Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 13 new commits since the last revision:
> 
>  - Tidy
>  - require non null in SimpleBindings
>  - Simplify SimpleScriptContext.scopes
>  - Mark fields final where possible
>  - Deduplicate registerEngineXxx methods
>  - Misc tidying
>  - Deduplicate exception reporting
>  - Lambdify
>  - Mark fields as final; eliminate now unnecessary init() method.
>  - Deduplicate engine creation and setup code
>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/f378f350...56d89eb2

Marked as reviewed by sundar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3229

From jlaskey at openjdk.java.net  Tue Mar 30 13:03:49 2021
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 30 Mar 2021 13:03:49 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v39]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <THmgQkGR9oNvPV-8HL7VIXCJ92XfJzJ_Cz7DptBqK04=.a3a959ba-cf14-4d8c-925b-bb2c11c4ac08@github.com>

> This PR is to introduce a new random number API for the JDK. The primary API is found in RandomGenerator and RandomGeneratorFactory. Further description can be found in the JEP https://openjdk.java.net/jeps/356 .
> 
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html
> 
> old PR:  https://github.com/openjdk/jdk/pull/1273

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Correct return type of RandomGeneratorFactory.of

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/3de42645..0aa49eda

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=38
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=37-38

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1292.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1292/head:pull/1292

PR: https://git.openjdk.java.net/jdk/pull/1292

From weijun at openjdk.java.net  Tue Mar 30 13:10:26 2021
From: weijun at openjdk.java.net (Weijun Wang)
Date: Tue, 30 Mar 2021 13:10:26 GMT
Subject: RFR: 8264277: java.xml.crypto module should be granted FilePermission
 and SocketPermission
Message-ID: <k0vdgcDXj_NlZvpiaiOQ0aPAAMv9-r5TG-sMZFygjsY=.1b307811-5306-45db-a674-d098ad9f5463@github.com>

These permissions are needed so that the URIDereferencer is able to read data from a file system or a network. As the test shows, you still have to grant the same type of permission to your application.

-------------

Depends on: https://git.openjdk.java.net/jdk/pull/3181

Commit messages:
 - 8264277: java.xml.crypto module should be granted FilePermission and SocketPermission

Changes: https://git.openjdk.java.net/jdk/pull/3266/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3266&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264277
  Stats: 139 lines in 2 files changed: 139 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3266.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3266/head:pull/3266

PR: https://git.openjdk.java.net/jdk/pull/3266

From rriggs at openjdk.java.net  Tue Mar 30 13:29:23 2021
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 30 Mar 2021 13:29:23 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

I agree that the public field in WriteAbortedException could be remediated.
But it is also mostly harmless.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMObjectFactory.java line 62:

> 60:     catch (java.lang.reflect.InvocationTargetException ite) {
> 61:         if (ite.getCause() instanceof RuntimeException) {
> 62:             throw (RuntimeException)ite.getCause();

This might be a place to use the new instanceof pattern form:
`if (ite.getCause() instanceof RuntimeException rex)
        throw rex.getCause();
`

src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/Utils.java line 293:

> 291:             Throwable t = e.getCause();
> 292:             if (t instanceof Exception) {
> 293:                 throw (Exception) t;

Ditto:
 ` if (t instanceof Exception ex) throw ex`

-------------

Marked as reviewed by rriggs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3182

From github.com+28367473+jmehrens at openjdk.java.net  Tue Mar 30 13:43:22 2021
From: github.com+28367473+jmehrens at openjdk.java.net (jmehrens)
Date: Tue, 30 Mar 2021 13:43:22 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <k1pS0P2Zl6vFFpNo2Fq30IZYZjel2QSHPDAqPZFlFik=.c94d3533-7b16-42ec-b803-d4725851de35@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

src/java.base/share/classes/java/io/WriteAbortedException.java line 86:

> 84:     @Override
> 85:     public Throwable getCause() {
> 86:         return detail;

Use SuppressWarnings??

-------------

PR: https://git.openjdk.java.net/jdk/pull/3182

From github.com+34924738+mahendrachhipa at openjdk.java.net  Tue Mar 30 15:47:27 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Tue, 30 Mar 2021 15:47:27 GMT
Subject: RFR: JDK-8064681 : Jaxp unit test need to be improved
In-Reply-To: <VnWbnpfehcz0m0yTfpUKJqyFdliX6akY-TC6e900OWo=.f93cc5b7-34bf-4338-abc5-8c7b6398a70a@github.com>
References: <V9kOzORMX8sH7Goli5bUISPnubjBkl1Ej_ZAc5WJLeU=.3ed5bbf0-f840-4f63-8105-5f09e0bfbed8@github.com>
 <VnWbnpfehcz0m0yTfpUKJqyFdliX6akY-TC6e900OWo=.f93cc5b7-34bf-4338-abc5-8c7b6398a70a@github.com>
Message-ID: <FiY-eYesliD1QTHca_NiKEP0t2nhvMshcLWHAZwQQVA=.9e144909-cfdc-46f3-acc5-5925d3bd8036@github.com>

On Wed, 24 Mar 2021 14:47:56 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> https://bugs.openjdk.java.net/browse/JDK-8064681
>
> the tests set a system property and then clear that system property at the end of the test.  Is it always the case that the property being set in the test does not have a value prior to be being set? Or is it more appropriate to save the current value of the property, set the new value and then restore the original value, rather than clearing the property?

Won't fix

-------------

PR: https://git.openjdk.java.net/jdk/pull/3115

From github.com+34924738+mahendrachhipa at openjdk.java.net  Tue Mar 30 15:47:27 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Tue, 30 Mar 2021 15:47:27 GMT
Subject: Withdrawn: JDK-8064681 : Jaxp unit test need to be improved
In-Reply-To: <V9kOzORMX8sH7Goli5bUISPnubjBkl1Ej_ZAc5WJLeU=.3ed5bbf0-f840-4f63-8105-5f09e0bfbed8@github.com>
References: <V9kOzORMX8sH7Goli5bUISPnubjBkl1Ej_ZAc5WJLeU=.3ed5bbf0-f840-4f63-8105-5f09e0bfbed8@github.com>
Message-ID: <Vs3a2FXdqGVV8NbYvRuIUxGCh5NZD7P7rxEJSzF_jeo=.0fbcc7ba-01eb-483a-a825-ac0a151a1170@github.com>

On Mon, 22 Mar 2021 10:35:03 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

> https://bugs.openjdk.java.net/browse/JDK-8064681

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3115

From joe.darcy at oracle.com  Tue Mar 30 15:55:20 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 30 Mar 2021 08:55:20 -0700
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <k1pS0P2Zl6vFFpNo2Fq30IZYZjel2QSHPDAqPZFlFik=.c94d3533-7b16-42ec-b803-d4725851de35@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <k1pS0P2Zl6vFFpNo2Fq30IZYZjel2QSHPDAqPZFlFik=.c94d3533-7b16-42ec-b803-d4725851de35@github.com>
Message-ID: <76cee601-67a3-adbd-ea45-ded1f2dc592e@oracle.com>


On 3/30/2021 6:43 AM, jmehrens wrote:
> On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>> 8264148: Update spec for exceptions retrofitted for exception chaining
> src/java.base/share/classes/java/io/WriteAbortedException.java line 86:
>
>> 84:     @Override
>> 85:     public Throwable getCause() {
>> 86:         return detail;
> Use SuppressWarnings??


There is no warning to suppress since the detail field is defined in the 
same class.

-Joe


From joe.darcy at oracle.com  Tue Mar 30 16:00:50 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 30 Mar 2021 09:00:50 -0700
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
 <-rMQxHXFk7yEM-DmoZOmE9eePkkvaklW5YyWhsJEek4=.8456ad76-b965-4098-a66b-1e80f396cf7c@github.com>
Message-ID: <0627b7e4-6db3-50bc-fba5-35877647d038@oracle.com>


On 3/30/2021 6:29 AM, Roger Riggs wrote:
> On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:
>
>> 8264148: Update spec for exceptions retrofitted for exception chaining
> I agree that the public field in WriteAbortedException could be remediated.
> But it is also mostly harmless.
>
> src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/VMObjectFactory.java line 62:
>
>> 60:     catch (java.lang.reflect.InvocationTargetException ite) {
>> 61:         if (ite.getCause() instanceof RuntimeException) {
>> 62:             throw (RuntimeException)ite.getCause();
> This might be a place to use the new instanceof pattern form:
> `if (ite.getCause() instanceof RuntimeException rex)
>          throw rex.getCause();
> `
>
> src/jdk.jconsole/share/classes/sun/tools/jconsole/inspector/Utils.java line 293:
>
>> 291:             Throwable t = e.getCause();
>> 292:             if (t instanceof Exception) {
>> 293:                 throw (Exception) t;
> Ditto:
>   ` if (t instanceof Exception ex) throw ex`
>

I think the use of the new instanceof form would be better left for a 
follow-up refactoring.

Thanks,

-Joe


From dev at anthonyv.be  Tue Mar 30 17:03:21 2021
From: dev at anthonyv.be (Anthony Vanelverdinghe)
Date: Tue, 30 Mar 2021 19:03:21 +0200
Subject: =?utf-8?q?Re=3A?= Insufficiencies in
 =?utf-8?q?JEP=3A?==?utf-8?q?_400=3A?= UTF-8 by Default
In-Reply-To: <633eb370-6252-475c-167b-1d4cb5873dc6@oracle.com>
Message-ID: <68f7-60635a00-175-6401b300@35209972>

Hi Alan

As Marco mentioned, another use case is sub-process stdin/stdout/stderr. In my particular instance, I'm starting a Process which has its output redirected to a file. It uses the platform's default encoding for writing to stdout. So when I want to read its output from the file at some later point, I need to supply that encoding to the Files API.
One way to accommodate this use case, is a method which allows to retrieve the platform's default encoding, for example a method `platformEncoding` in Charset or Process, or the `Console::charset` method you mentioned. Another option would be to enhance the Process API, by adding methods to Process which return appropriate Readers/Writers & adding methods of the form `redirectX(File file, Charset encoding)` to ProcessBuilder. But this seems like a lot of additional API surface, just to avoid surfacing the platform's default encoding itself.
So I think the JEP should specify how it'll address use cases w.r.t. the Process API, shouldn't it?

Kind regards,
Anthony
 
On Sunday, March 14, 2021 13:01 CET, Alan Bateman <Alan.Bateman at oracle.com> wrote: 
 
> On 14/03/2021 11:00, Marco wrote:
> > :
> >
> > IMO Charset should provide standardized getters for the OS charset and the
> > console charset. The latter being different has been a long standing issue on
> > Windows where the codepage differs between its CLI and regular environments.
> > OpenJDK has the necessary data already available in its custom system
> > properties.
> >
> > The console charset is currently hidden behind PrintStream not exposing the
> > underlying OSWriter and not offering getEncoding() itself. The OS charset
> > would be hidden in the future by Charset.getDefaultCharset()'s specification
> > change in JEP 400.
> The intention that there will be little or no impact to the console 
> streams. This means that java.io.Console reader/writer methods should 
> continue to return a Reader/PrintWriter that uses the platform encoding 
> (or code page is on Windows). Same thing for the System.out/System.err 
> print streams. We need to make this clearer in the JEP.
> 
> There has been discussion on this mailing list about adding a 
> Console::charset method but it didn't come to a consensus. Naoto Sato 
> and I have been chatting about it again recently as there may be a need 
> to add an API in advance of proposing to target the JEP.
> 
> One case that we are still mulling over is code that creates an 
> InputStreamReader on System.in without specifying the charset. This 
> might be older code that pre-dates java.io.Console or maybe code that 
> wasn't tested on a wide range or platforms. Options range from a spec 
> change to doing nothing (the latter meaning running with "COMPACT" or 
> migrating the code to use the 2-arg constructor as the default charset 
> is not the right choice).
> 
> -Alan
> 
> 
>


From github.com+34924738+mahendrachhipa at openjdk.java.net  Tue Mar 30 17:04:33 2021
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Tue, 30 Mar 2021 17:04:33 GMT
Subject: RFR: JDK-8264454 : Jaxp unit test from open jdk needs to be improved
Message-ID: <9m0pNx9y4V-QfxrJpbXLjtg10Oao9N-67fGdmZyNbTU=.e446d95d-763a-4cec-86b0-2219f0e20d34@github.com>

JDK-8264454 : Jaxp unit test from open jdk needs to be improved

-------------

Commit messages:
 - JDK-8264454 : Jaxp unit test from open jdk needs to be improved
 - JDK-8064681 : Jaxp unit test need to be improved

Changes: https://git.openjdk.java.net/jdk/pull/3274/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3274&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264454
  Stats: 743 lines in 8 files changed: 71 ins; 596 del; 76 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3274.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3274/head:pull/3274

PR: https://git.openjdk.java.net/jdk/pull/3274

From smarks at openjdk.java.net  Tue Mar 30 17:06:32 2021
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 30 Mar 2021 17:06:32 GMT
Subject: RFR: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <XaOfh6DMc2x_a0qsP15eZNL4BNIlr5sZdA5in2dfBVo=.ae0724db-ccc6-4f84-ab43-d698b3042113@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

Marked as reviewed by smarks (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3182

From attila at openjdk.java.net  Tue Mar 30 18:10:24 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Tue, 30 Mar 2021 18:10:24 GMT
Subject: RFR: 8262503: Support records in Dynalink
In-Reply-To: <v7tQzdZLojPapGAQ9zBmrfZavuyilf-XF6bsCsQIa-0=.be87fbbc-8629-45b6-9f96-689c49edfd17@github.com>
References: <yO1O4eJNyQhMbkx-h1gbgcvRbkrknAox4oMjkrGUi6U=.8ee56a7f-39b8-4a9b-a497-c2576767d090@github.com>
 <v7tQzdZLojPapGAQ9zBmrfZavuyilf-XF6bsCsQIa-0=.be87fbbc-8629-45b6-9f96-689c49edfd17@github.com>
Message-ID: <8QjdE3MXeZv1DaSaq4KDmUvCw-KizA0YxhdMbbiq8uk=.04b3e4fb-6c61-4433-9c18-3a97f7ff4dea@github.com>

On Tue, 30 Mar 2021 12:38:41 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> 8262503: Support records in Dynalink
>
> Looks good

Thank you for the review, @sundararajana!

-------------

PR: https://git.openjdk.java.net/jdk/pull/2767

From attila at openjdk.java.net  Tue Mar 30 18:10:27 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Tue, 30 Mar 2021 18:10:27 GMT
Subject: Integrated: 8262503: Support records in Dynalink
In-Reply-To: <yO1O4eJNyQhMbkx-h1gbgcvRbkrknAox4oMjkrGUi6U=.8ee56a7f-39b8-4a9b-a497-c2576767d090@github.com>
References: <yO1O4eJNyQhMbkx-h1gbgcvRbkrknAox4oMjkrGUi6U=.8ee56a7f-39b8-4a9b-a497-c2576767d090@github.com>
Message-ID: <s55ki_tNAiuD41awuBPMu_Tr5i7FSV4VNyi7ky8DfnA=.7e098519-8b82-478f-96bd-ac2d5650a822@github.com>

On Sun, 28 Feb 2021 16:46:31 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> 8262503: Support records in Dynalink

This pull request has now been integrated.

Changeset: b08d6383
Author:    Attila Szegedi <attila at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b08d6383
Stats:     165 lines in 8 files changed: 153 ins; 6 del; 6 mod

8262503: Support records in Dynalink

Reviewed-by: sundar

-------------

PR: https://git.openjdk.java.net/jdk/pull/2767

From attila at openjdk.java.net  Tue Mar 30 18:16:19 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Tue, 30 Mar 2021 18:16:19 GMT
Subject: RFR: 8264326: Modernize javax.script.ScriptEngineManager and
 related classes' implementation [v2]
In-Reply-To: <bAEtctHv96JOCkx6qxECZaYdjLSzNZrLP0AGpQUbZKk=.26c10187-c7dc-4b83-89d2-436f2526a54c@github.com>
References: <ZLqKPN5QGdkNhY5b4CswU76jOLCYBCrAG6W_i84gXxs=.baae1d66-f3a9-45e9-8761-f7871b5bf0d1@github.com>
 <bnYgrO5cxB6AH9ekGM0j2gBPo6DQlEFoHGefCk9GZ4Q=.ab39c81c-e55d-476f-a1cf-562f00c98a76@github.com>
 <bAEtctHv96JOCkx6qxECZaYdjLSzNZrLP0AGpQUbZKk=.26c10187-c7dc-4b83-89d2-436f2526a54c@github.com>
Message-ID: <JGLZSaZ2XBoeX8D3NqmKXZ2PbnJb71OC7O1USckxQKg=.6d9d5dc4-5029-4b27-aad9-dcc90bf4f696@github.com>

On Tue, 30 Mar 2021 12:43:18 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

>> Attila Szegedi has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains 13 new commits since the last revision:
>> 
>>  - Tidy
>>  - require non null in SimpleBindings
>>  - Simplify SimpleScriptContext.scopes
>>  - Mark fields final where possible
>>  - Deduplicate registerEngineXxx methods
>>  - Misc tidying
>>  - Deduplicate exception reporting
>>  - Lambdify
>>  - Mark fields as final; eliminate now unnecessary init() method.
>>  - Deduplicate engine creation and setup code
>>  - ... and 3 more: https://git.openjdk.java.net/jdk/compare/f378f350...56d89eb2
>
> Marked as reviewed by sundar (Reviewer).

Thank you for the review @sundararajana! Much appreciated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3229

From attila at openjdk.java.net  Tue Mar 30 18:16:20 2021
From: attila at openjdk.java.net (Attila Szegedi)
Date: Tue, 30 Mar 2021 18:16:20 GMT
Subject: Integrated: 8264326: Modernize javax.script.ScriptEngineManager and
 related classes' implementation
In-Reply-To: <ZLqKPN5QGdkNhY5b4CswU76jOLCYBCrAG6W_i84gXxs=.baae1d66-f3a9-45e9-8761-f7871b5bf0d1@github.com>
References: <ZLqKPN5QGdkNhY5b4CswU76jOLCYBCrAG6W_i84gXxs=.baae1d66-f3a9-45e9-8761-f7871b5bf0d1@github.com>
Message-ID: <D6MvKWC-7rkzAcve6rU6-gnzkqUir2H17p54iAgpFVs=.af1690be-457d-40a2-85bb-701d27eeaeea@github.com>

On Sat, 27 Mar 2021 15:19:37 GMT, Attila Szegedi <attila at openjdk.org> wrote:

> I noticed that `javax.script.ScriptEngineManager` `getEngineByXxx` methods had a lot of code duplication among themselves, and even within each method. I refactored them into a modern unified implementation. While there I also took the opportunity to introduce `Objects.requireNonNull` in place of null checks followed by NPE throws, mark private fields final where possible, use lambdas for `doPrivileged` block, use `List.of` and `List.copyOf` where possible, and generally sanitize/deduplicate.

This pull request has now been integrated.

Changeset: 2bd80f94
Author:    Attila Szegedi <attila at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2bd80f94
Stats:     227 lines in 5 files changed: 40 ins; 140 del; 47 mod

8264326: Modernize javax.script.ScriptEngineManager and related classes' implementation

Reviewed-by: sundar

-------------

PR: https://git.openjdk.java.net/jdk/pull/3229

From joe.darcy at oracle.com  Tue Mar 30 19:56:33 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 30 Mar 2021 12:56:33 -0700
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
References: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
Message-ID: <1cdd2c5b-9d54-a37e-8a9c-17f4d048b8e5@oracle.com>

Hi Raffaello,

On 3/29/2021 1:14 PM, Raffaello Giulietti wrote:
> Hello,
>
> I'm experimenting with an implementation of Decimal64 and Decimal128, 
> two standard IEEE 754-2019 formats supporting, well, decimal floating 
> point numbers of up to 16 resp 34 decimal digits.

Fun project!

>
> While BigDecimal can simulate most finite number computations on these 
> formats by passing MathContext.DECIMAL64 and MathContext.DECIMAL128, 
> resp., to the arithmetic operations, this approach has some 
> shortcomings wrt to the standard:
> * Like the binary formats (float and double in Java), the standard 
> mandates signed zeroes, signed infinities and NaNs for the decimal 
> formats as well, while BigDecimal has neither.

Quite right; those differences were recently (if belatedly) documented 
in JDK 17 (8261366: Add discussion of IEEE 754 to BigDecimal).

> * BigDecimal is not a final class, so is not (and can never be) 
> value-based.

Yep; as discussed in "Effective Java" the non-final-ness of the class 
was recognized as a mistake after it was in the platform, but it is not 
something we are likely to change now. As an aside, a happy accident of 
the ability of BigDecimal to be subclassed was allowing easier 
adaptation to changes in toString output that had an unexpectedly large 
behavioral compatibility impact in JDK 5.0.


> * BigDecimal needs support from BigInteger (another non final, non 
> value-based class).
>
> On the other hand, classes Decimal64 and Decimal128:
> * Are value-based and can be declared to be primitive in a future 
> version of OpenJDK, once Valhalla is completed.
> * Require 12 and 20 bytes, resp, of storage in the Valhalla model of 
> primitive objects and have no references to other identity or 
> primitive objects.
> * Support the signed zeroes, the infinities and the NaNs.
> * Currently support the 4 fundamental operations (+ - * /) according 
> to the standard and will support remainder, square root, comparisons, 
> etc. and the conversions listed in the standard.

Assuming you have DecimalN <-> BigDecimal conversions, the BigDecimal 
type should be usable for testing at least. For in-range values not near 
the exponent range, the scale (exponent) and significand for finite and 
nonzero values should be the same for the basic arithmetic operations 
and square root in DecimalN and BigDecimal.

(Around the limits of the exponent range, there are subnormal and 
"supernormal" results where the rounding of the significand interacts 
with the exponent computation. This would make it a bit tricky to 
offload BigDecimal computations in range of, say, a Decimal128 to a 
hardware implementation where one was available.)

Fixed-size decimal computations have an interesting design space to 
explore in terms of trading off memory compactness and computational 
cost. For example, the IEEE 754 spec details two different encodings of 
three decimal digits in 10 bits. However, it is not strictly necessary 
for each operation to produce results whose internal storage maps to an 
"interchange format," in the terminology of 754. It would be possible to 
keep the significand encoded as normal integers and only produce an 
interchange representation on something akin to a serialization event.

I understand hardware implementations of FPUs will use these sort of 
techniques and also have architectural-invisible bits indicating what 
kind of value a floating-point number is. For example, the beginning of 
many math library functions starts with "Handle NaN cases," ... "Handle 
infinity case" ... "Handle zero case" ... Sometimes the handling falls 
out naturally and doesn't require explicit testing, but in the cases 
that does not occur, it can be cheaper to have the "isFoo" bit already 
computed.


> * Could be extended to support the (rather cumbersome) exceptions 
> handling of the standard.
> * There's no plan to support transcendental functions, as the aim is 
> to have numerical classes for business applications, not scientific or 
> engineering purposes.
> * Are faster than the (incomplete) simulation with BigDecimal, 1x-5x 
> in the current incarnations.
>
>
> I would be glad to contribute the code to the OpenJDK provided there 
> is a genuine interest from the community and a reviewer willing to 
> sponsor my effort. (I guess the best candidate for this role would be 
> Joe Darcy from what I can read in this mailing list.)
>
At least for the time being, I don't think the OpenJDK (at least the 
main project) would be the best home for such code. As you're noted, 
post Valhalla having such a type in the JDK becomes more interesting 
from a performance perspective.

Thanks,

-Joe


From joe.darcy at oracle.com  Tue Mar 30 20:00:54 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Tue, 30 Mar 2021 13:00:54 -0700
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <CAAfFNYFwKoEj1hgx6YEebOi8N4A_XKDTegH8oaTM7uWfOfS=VA@mail.gmail.com>
References: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
 <CAAfFNYFwKoEj1hgx6YEebOi8N4A_XKDTegH8oaTM7uWfOfS=VA@mail.gmail.com>
Message-ID: <c7177a3f-fe6a-c9c3-31de-fd62027d2078@oracle.com>

On 3/29/2021 6:13 PM, Suminda Sirinath Salpitikorala Dharmasena wrote:
> This would be interesting to have.
>
> It would be better if the full set of numbers b16-256 and d32-128 are
> implemented so there is full coverage of all IEEE 754 numbers.

FYI, if one is need of such code in C today, you can look at the 
SoftFloat library (http://www.jhauser.us/arithmetic/SoftFloat.html):

> Berkeley SoftFloat is a free, high-quality software implementation of 
> binary floating-point that conforms to the IEEE Standard for 
> Floating-Point Arithmetic. SoftFloat is completely faithful to the 
> IEEE Standard, while at the same time being relatively fast. All 
> functions dictated by the original 1985 version of the standard are 
> supported except for conversions to and from decimal. The latest 
> release of SoftFloat implements five floating-point formats: 
> half-precision, single-precision, double-precision, 
> double-extended-precision, and quadruple-precision. All required 
> rounding modes, exception flags, and special values are supported. 
> Fused multiply-add is also implemented for all formats except 
> double-extended-precision.

HTH,

-Joe


From darcy at openjdk.java.net  Tue Mar 30 20:03:18 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Tue, 30 Mar 2021 20:03:18 GMT
Subject: Integrated: 8264148: Update spec for exceptions retrofitted for
 exception chaining
In-Reply-To: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
References: <SDZpx2KGw9fZcD5wSksgQ0A4EGJsyXdtUAiWUqRvN44=.6dd1e8d3-1c84-40e0-b873-ffb3e5d326af@github.com>
Message-ID: <DLYKwabnY95L4xZ2RniMmrgFe7bbxZx5oq6uzIP-wvE=.8605c32a-3628-444e-bc16-8546bfaa87c1@github.com>

On Wed, 24 Mar 2021 23:17:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 8264148: Update spec for exceptions retrofitted for exception chaining

This pull request has now been integrated.

Changeset: 815248ab
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/815248ab
Stats:     84 lines in 22 files changed: 8 ins; 44 del; 32 mod

8264148: Update spec for exceptions retrofitted for exception chaining

Reviewed-by: rriggs, smarks

-------------

PR: https://git.openjdk.java.net/jdk/pull/3182

From brian.goetz at oracle.com  Tue Mar 30 20:03:47 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 30 Mar 2021 16:03:47 -0400
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
References: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
Message-ID: <00975763-89a9-4b4b-8dd2-b2df4551edbf@oracle.com>

Overall, I'd be happy to see Decimal types that are aimed at "reasonable 
precision" in addition to the infinite precision that BD offers.? (After 
Valhalla, of course.)



On 3/29/2021 4:14 PM, Raffaello Giulietti wrote:
> Hello,
>
> I'm experimenting with an implementation of Decimal64 and Decimal128, 
> two standard IEEE 754-2019 formats supporting, well, decimal floating 
> point numbers of up to 16 resp 34 decimal digits.
>
> While BigDecimal can simulate most finite number computations on these 
> formats by passing MathContext.DECIMAL64 and MathContext.DECIMAL128, 
> resp., to the arithmetic operations, this approach has some 
> shortcomings wrt to the standard:
> * Like the binary formats (float and double in Java), the standard 
> mandates signed zeroes, signed infinities and NaNs for the decimal 
> formats as well, while BigDecimal has neither.
> * BigDecimal is not a final class, so is not (and can never be) 
> value-based.
> * BigDecimal needs support from BigInteger (another non final, non 
> value-based class).
>
> On the other hand, classes Decimal64 and Decimal128:
> * Are value-based and can be declared to be primitive in a future 
> version of OpenJDK, once Valhalla is completed.
> * Require 12 and 20 bytes, resp, of storage in the Valhalla model of 
> primitive objects and have no references to other identity or 
> primitive objects.
> * Support the signed zeroes, the infinities and the NaNs.
> * Currently support the 4 fundamental operations (+ - * /) according 
> to the standard and will support remainder, square root, comparisons, 
> etc. and the conversions listed in the standard.
> * Could be extended to support the (rather cumbersome) exceptions 
> handling of the standard.
> * There's no plan to support transcendental functions, as the aim is 
> to have numerical classes for business applications, not scientific or 
> engineering purposes.
> * Are faster than the (incomplete) simulation with BigDecimal, 1x-5x 
> in the current incarnations.
>
>
> I would be glad to contribute the code to the OpenJDK provided there 
> is a genuine interest from the community and a reviewer willing to 
> sponsor my effort. (I guess the best candidate for this role would be 
> Joe Darcy from what I can read in this mailing list.)
>
>
> Greetings
> Raffaello


From paul.sandoz at oracle.com  Tue Mar 30 20:54:23 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 Mar 2021 20:54:23 +0000
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <00975763-89a9-4b4b-8dd2-b2df4551edbf@oracle.com>
References: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
 <00975763-89a9-4b4b-8dd2-b2df4551edbf@oracle.com>
Message-ID: <3621EAD0-FB9A-41B5-960B-4045F09A9C7C@oracle.com>



> On Mar 30, 2021, at 1:03 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
> 
> Overall, I'd be happy to see Decimal types that are aimed at "reasonable precision" in addition to the infinite precision that BD offers.  (After Valhalla, of course.)
> 

Yes, me too.

Raffaello, as an experiment you could develop such classes as primitive classes compiled against recent builds of Valhalla.

I would caution against unduly biasing towards "business applications?, as I think with primitive classes and other possible features Java can become a better platform for scientific or engineering purposes.

As an example we are making progress with the Vector API and in the panama-vector repo we have integrated with code of Intel?s Short Vector Math Library, which may open the possibility for it to be used by the auto-vectorizer too.

Paul.

From maurizio.cimadamore at oracle.com  Tue Mar 30 21:01:02 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Tue, 30 Mar 2021 22:01:02 +0100
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <3621EAD0-FB9A-41B5-960B-4045F09A9C7C@oracle.com>
References: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
 <00975763-89a9-4b4b-8dd2-b2df4551edbf@oracle.com>
 <3621EAD0-FB9A-41B5-960B-4045F09A9C7C@oracle.com>
Message-ID: <3bd78fc2-8ce9-b49e-f92d-c1ed93b0a2c6@oracle.com>

Add me to the list of interested folks.

Such types are useful when interacting with System ABIs, and the Foreign 
Linker API needs "well-known" carrier which model these types in Java. 
There are also other interesting types to be explored in that domain, 
such as Long128, LongDouble (extended precision float) and HalfFloats.

Maurizio

On 30/03/2021 21:54, Paul Sandoz wrote:
>
>> On Mar 30, 2021, at 1:03 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>> Overall, I'd be happy to see Decimal types that are aimed at "reasonable precision" in addition to the infinite precision that BD offers.  (After Valhalla, of course.)
>>
> Yes, me too.
>
> Raffaello, as an experiment you could develop such classes as primitive classes compiled against recent builds of Valhalla.
>
> I would caution against unduly biasing towards "business applications?, as I think with primitive classes and other possible features Java can become a better platform for scientific or engineering purposes.
>
> As an example we are making progress with the Vector API and in the panama-vector repo we have integrated with code of Intel?s Short Vector Math Library, which may open the possibility for it to be used by the auto-vectorizer too.
>
> Paul.

From github.com+76791+alblue at openjdk.java.net  Tue Mar 30 21:29:23 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Tue, 30 Mar 2021 21:29:23 GMT
Subject: RFR: 8264397: Use the blessed modifier order in
 jdk.incubator.foreign
In-Reply-To: <mQyEUYhJLFLQIES7JzR1RDnvh4cak4tHxuCG4GNQwpY=.c1a2de68-3533-4cb6-96ee-588d7afb62ea@github.com>
References: <S8y1iC02mJVfaCzrbFMxNe1fcbZAqsS6xDo_6kKZwBY=.283524b1-104f-47f7-9996-b2b8977a09ac@github.com>
 <DghGx59T4CxKsAK-0GNtn8_UhLjcybiCYbvg9QSbye4=.d1fa3ec9-1c82-49ca-9d1f-2fdb071a6fff@github.com>
 <h1-4oxvZOZ0Ftv0NLoABjU3NdkBLLm-2qOuLGHpOrwo=.5b8f4c16-1544-41e1-bd6d-4845e0b73eca@github.com>
 <mQyEUYhJLFLQIES7JzR1RDnvh4cak4tHxuCG4GNQwpY=.c1a2de68-3533-4cb6-96ee-588d7afb62ea@github.com>
Message-ID: <1SRsrDQ6ehLr6rA9c-fQSxPBF6TSZVDpWWoUj_eqGk0=.d446fc38-a4c8-4254-9f52-8541d9680f6a@github.com>

On Tue, 30 Mar 2021 11:48:36 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Happy to submit a fix elsewhere if that's the right thing to do?
>
> Hi @alblue, thanks for the contribution. We will make sure to integrate this at some point, but I don't think now is the right moment to do this kind of stylistic changes to the API/implementation. If you want to integrate the fix now, I'd suggest to file a PR against https://github.com/openjdk/panama-foreign, and we'll be happy to sponsor the change. That way you'd be guaranteed the change would be included in the next incubation round.

Have submitted change to the panama-foreign branch; let me know if that's the appropriate place and I can abandon this PR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3253

From raffaello.giulietti at gmail.com  Tue Mar 30 22:48:58 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 31 Mar 2021 00:48:58 +0200
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <1cdd2c5b-9d54-a37e-8a9c-17f4d048b8e5@oracle.com>
References: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
 <1cdd2c5b-9d54-a37e-8a9c-17f4d048b8e5@oracle.com>
Message-ID: <51b488db-bde2-f947-4d77-7545ceb20068@gmail.com>

Hi Joe,

On 2021-03-30 21:56, Joe Darcy wrote:
> Hi Raffaello,
> 
> On 3/29/2021 1:14 PM, Raffaello Giulietti wrote:
>> Hello,
>>
> 
> Assuming you have DecimalN <-> BigDecimal conversions, the BigDecimal 
> type should be usable for testing at least. For in-range values not near 
> the exponent range, the scale (exponent) and significand for finite and 
> nonzero values should be the same for the basic arithmetic operations 
> and square root in DecimalN and BigDecimal.
> 
> (Around the limits of the exponent range, there are subnormal and 
> "supernormal" results where the rounding of the significand interacts 
> with the exponent computation. This would make it a bit tricky to 
> offload BigDecimal computations in range of, say, a Decimal128 to a 
> hardware implementation where one was available.)
> 

Yes, some of my current tests exploit BigDecimal for crosschecks in the 
normal range.


> Fixed-size decimal computations have an interesting design space to 
> explore in terms of trading off memory compactness and computational 
> cost. For example, the IEEE 754 spec details two different encodings of 
> three decimal digits in 10 bits. However, it is not strictly necessary 
> for each operation to produce results whose internal storage maps to an 
> "interchange format," in the terminology of 754. It would be possible to 
> keep the significand encoded as normal integers and only produce an 
> interchange representation on something akin to a serialization event.
> 

The internal representation is none of the interchange formats. 
Similarly to the interchange format's 1'000-based declets, it holds 
1'000'000'000-based (30 bits) "declets"/int, in addition to the unbiased 
exponent, the sign, the precision and the kind, as you mention below.


> I understand hardware implementations of FPUs will use these sort of 
> techniques and also have architectural-invisible bits indicating what 
> kind of value a floating-point number is. For example, the beginning of 
> many math library functions starts with "Handle NaN cases," ... "Handle 
> infinity case" ... "Handle zero case" ... Sometimes the handling falls 
> out naturally and doesn't require explicit testing, but in the cases 
> that does not occur, it can be cheaper to have the "isFoo" bit already 
> computed.
> 
> 
>> I would be glad to contribute the code to the OpenJDK provided there 
>> is a genuine interest from the community and a reviewer willing to 
>> sponsor my effort. (I guess the best candidate for this role would be 
>> Joe Darcy from what I can read in this mailing list.)
>>
> At least for the time being, I don't think the OpenJDK (at least the 
> main project) would be the best home for such code. As you're noted, 
> post Valhalla having such a type in the JDK becomes more interesting 
> from a performance perspective.
> 

They are already more compact and faster than BigDecimal even on the 
current, pre-Valhalla release, so they would make sense even today, were 
they ready for review.

(I'm spending my free time on this, so I just wanted to make sure I'm 
not wasting energy for something that will sit on my computer only.)


Greetings
Raffaello

From raffaello.giulietti at gmail.com  Tue Mar 30 22:52:23 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 31 Mar 2021 00:52:23 +0200
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <00975763-89a9-4b4b-8dd2-b2df4551edbf@oracle.com>
References: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
 <00975763-89a9-4b4b-8dd2-b2df4551edbf@oracle.com>
Message-ID: <159b33b5-1c06-4b1c-b87e-a65eaf1e057e@gmail.com>

There's no strict need for Valhalla, as they are more compact and faster 
than BigDecimal even today.


On 2021-03-30 22:03, Brian Goetz wrote:
> Overall, I'd be happy to see Decimal types that are aimed at "reasonable 
> precision" in addition to the infinite precision that BD offers.? (After 
> Valhalla, of course.)
> 
> 
> 
> On 3/29/2021 4:14 PM, Raffaello Giulietti wrote:
>> Hello,
>>
>> I'm experimenting with an implementation of Decimal64 and Decimal128, 
>> two standard IEEE 754-2019 formats supporting, well, decimal floating 
>> point numbers of up to 16 resp 34 decimal digits.
>>

From raffaello.giulietti at gmail.com  Tue Mar 30 23:05:47 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 31 Mar 2021 01:05:47 +0200
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <3621EAD0-FB9A-41B5-960B-4045F09A9C7C@oracle.com>
References: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
 <00975763-89a9-4b4b-8dd2-b2df4551edbf@oracle.com>
 <3621EAD0-FB9A-41B5-960B-4045F09A9C7C@oracle.com>
Message-ID: <162ac99e-a2fa-8254-01ca-05c68e40e9d0@gmail.com>

Hi Paul,


On 2021-03-30 22:54, Paul Sandoz wrote:
> 
> 
>> On Mar 30, 2021, at 1:03 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>
>> Overall, I'd be happy to see Decimal types that are aimed at "reasonable precision" in addition to the infinite precision that BD offers.  (After Valhalla, of course.)
>>
> 
> Yes, me too.
> 
> Raffaello, as an experiment you could develop such classes as primitive classes compiled against recent builds of Valhalla.
> 

I guess the most recent builds of Valhalla are those resulting from 
building from the source code in the git repo. Or are you recommending 
the official ea releases instead?

I ask because I plan to use the latest release from the git repo and 
keeping it current, not the ea release.


> I would caution against unduly biasing towards "business applications?, as I think with primitive classes and other possible features Java can become a better platform for scientific or engineering purposes.
> 
> As an example we are making progress with the Vector API and in the panama-vector repo we have integrated with code of Intel?s Short Vector Math Library, which may open the possibility for it to be used by the auto-vectorizer too.
> 
> Paul.
> 

As far as I can tell, scientific computation will make use of binary 
floating point numbers for a long time. Decimal floating point numbers 
are still limited to biz and fin applications.

Does Intel's lib operates on decimal formats as well?


Greetings
Raffaello

From raffaello.giulietti at gmail.com  Tue Mar 30 23:21:17 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 31 Mar 2021 01:21:17 +0200
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <3bd78fc2-8ce9-b49e-f92d-c1ed93b0a2c6@oracle.com>
References: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
 <00975763-89a9-4b4b-8dd2-b2df4551edbf@oracle.com>
 <3621EAD0-FB9A-41B5-960B-4045F09A9C7C@oracle.com>
 <3bd78fc2-8ce9-b49e-f92d-c1ed93b0a2c6@oracle.com>
Message-ID: <f3c73ead-f1ae-3fca-6b71-450acf5955ba@gmail.com>

Ciao Maurizio,

thanks for your interest.


On 2021-03-30 23:01, Maurizio Cimadamore wrote:
> Add me to the list of interested folks.
> 

Will do.


> Such types are useful when interacting with System ABIs, and the Foreign 
> Linker API needs "well-known" carrier which model these types in Java. 
> There are also other interesting types to be explored in that domain, 
> such as Long128, LongDouble (extended precision float) and HalfFloats.
>  > Maurizio
> 
> On 30/03/2021 21:54, Paul Sandoz wrote:
>>
>>> On Mar 30, 2021, at 1:03 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>>
>>> Overall, I'd be happy to see Decimal types that are aimed at 
>>> "reasonable precision" in addition to the infinite precision that BD 
>>> offers.? (After Valhalla, of course.)
>>>
>> Yes, me too.
>>
>> Raffaello, as an experiment you could develop such classes as 
>> primitive classes compiled against recent builds of Valhalla.
>>
>> I would caution against unduly biasing towards "business 
>> applications?, as I think with primitive classes and other possible 
>> features Java can become a better platform for scientific or 
>> engineering purposes.
>>
>> As an example we are making progress with the Vector API and in the 
>> panama-vector repo we have integrated with code of Intel?s Short 
>> Vector Math Library, which may open the possibility for it to be used 
>> by the auto-vectorizer too.
>>
>> Paul.

From paul.sandoz at oracle.com  Tue Mar 30 23:25:31 2021
From: paul.sandoz at oracle.com (Paul Sandoz)
Date: Tue, 30 Mar 2021 23:25:31 +0000
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <162ac99e-a2fa-8254-01ca-05c68e40e9d0@gmail.com>
References: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
 <00975763-89a9-4b4b-8dd2-b2df4551edbf@oracle.com>
 <3621EAD0-FB9A-41B5-960B-4045F09A9C7C@oracle.com>
 <162ac99e-a2fa-8254-01ca-05c68e40e9d0@gmail.com>
Message-ID: <1B541C16-94FF-4628-9E54-8B577CB18A38@oracle.com>



> On Mar 30, 2021, at 4:05 PM, Raffaello Giulietti <raffaello.giulietti at gmail.com> wrote:
> 
> Hi Paul,
> 
> 
> On 2021-03-30 22:54, Paul Sandoz wrote:
>>> On Mar 30, 2021, at 1:03 PM, Brian Goetz <brian.goetz at oracle.com> wrote:
>>> 
>>> Overall, I'd be happy to see Decimal types that are aimed at "reasonable precision" in addition to the infinite precision that BD offers.  (After Valhalla, of course.)
>>> 
>> Yes, me too.
>> Raffaello, as an experiment you could develop such classes as primitive classes compiled against recent builds of Valhalla.
> 
> I guess the most recent builds of Valhalla are those resulting from building from the source code in the git repo. Or are you recommending the official ea releases instead?
> 

I would recommend building from the git repo if you can, since that will allow for the most relevant feedback.


> I ask because I plan to use the latest release from the git repo and keeping it current, not the ea release.
> 
> 
>> I would caution against unduly biasing towards "business applications?, as I think with primitive classes and other possible features Java can become a better platform for scientific or engineering purposes.
>> As an example we are making progress with the Vector API and in the panama-vector repo we have integrated with code of Intel?s Short Vector Math Library, which may open the possibility for it to be used by the auto-vectorizer too.
>> Paul.
> 
> As far as I can tell, scientific computation will make use of binary floating point numbers for a long time. Decimal floating point numbers are still limited to biz and fin applications.
> 

Ok.


> Does Intel's lib operates on decimal formats as well?
> 

No.

Paul.


From chriswjohnson.jdk at gmail.com  Tue Mar 30 23:44:16 2021
From: chriswjohnson.jdk at gmail.com (Chris Johnson)
Date: Tue, 30 Mar 2021 18:44:16 -0500
Subject: Proposed: StringUTF16 bug fix with optimization - Part 1 of 2,
 StringUTF16 Patch
Message-ID: <CAPcpk_vDOjZU+VuFF75MT6i6uNxD0HZRcj0bJeG_QPhRVKTcKQ@mail.gmail.com>

Historically, the methods currently known as "compareToCI" and
"regionMatchesCI", and located in "java.lang.StringUTF16", have lacked
support for Supplementary Multilingual Plane code-points. (I've seen no
associated bug.)

On July 23, 2020 the first fix for the bug was committed. However, it
includes two simple bugs of its own. They're not much more than typos,
but they break some things nonetheless, as demonstrated by the unit
tests comprising part 2 of this contribution.

(Those two bugs: In "StringUTF16.compareToCIImpl", change statements
"cp1 -= cp1;" and "cp2 -= cp2;" to, respectively, "cp1 = -cp1;" and
"cp2 = -cp2;", and those bugs are history.)

The fixed "compareToCI" and "regionMatchesCI" methods in this patch are
different, however.[1] Notably:

  1. Case-insensitive UTF-16 string comparison and equality-testing is
     2.2 to 2.9 times faster than the current methods, depending on data
     set composition. (So, meaningfully faster, but the degree varies
     with the strings compared.)

  2. 100% TestNG unit test coverage.

  3. A utility method, "compareCodePointsIgnoringCase", created for these
     methods increased their performance by 24%, and could, in the future,
     be applied easily to "StringLatin1" methods "compareToCI*", and
     "regionMatchesCI*". (My guess is the performance gain there will be
     smaller, but still useful.)

This patch to "StringUTF16" may appear quite large. For better or worse
(your call, gentle reader), the vast majority of it is comments. The code
itself is minimal by comparison.

Thanks in advance for your consideration,

----Chris

Chris W. Johnson
chriswjohnson.jdk at gmail.com
http://www.panojohnson.com/


Footnote:

1. Work on this code began around 4 years ago, when I failed to find a
   bug report link on the OpenJDK page, and supposed the message to devs
   might be something like "contribute or go away". Since then, life,
   death, work, learning to build & test OpenJDK, registering as a
   contributor, social anxiety, unit test development, benchmarking,
   experimentation, and being unable to look at my own code without
   seeing *something* to improve (especially considering it might end-up
   in the JDK), are among the reasons for the long delay in attempting
   this contribution.






Index: src/java.base/share/classes/java/lang/StringUTF16.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>US-ASCII
===================================================================
diff --git a/src/java.base/share/classes/java/lang/StringUTF16.java
b/src/java.base/share/classes/java/lang/StringUTF16.java
--- a/src/java.base/share/classes/java/lang/StringUTF16.java    (revision
60819:ee1d592a9f5389725a0338a4b5dfcf4fc3fcf20c)
+++ b/src/java.base/share/classes/java/lang/StringUTF16.java    (revision
60819+:ee1d592a9f53+)
@@ -41,7 +41,32 @@
 import static java.lang.String.LATIN1;

 final class StringUTF16 {
-
+
+    /**
+     * Number of low-order bits storing the payload of Unicode surrogate
code-units.
+     * (The number of surrogate header bits is {@link Character#SIZE}
minus this value.)
+     */
+    private static final int    SURROGATE_PAYLOAD_BIT_COUNT = 10;
+
+    /**
+     * The high six bits common to all high-surrogate code-units (bits
15-10) right-shifted into bits
+     * 5-0 of an "{@code int}" primitive. ({@code 0b1101_10**_****_****
>>> 10 == 0b11_0110 == 0x36})
+     */
+    private static final int    SURROGATE_HI_HEADER_RIGHT_SHIFTED_10 =
Character.MIN_HIGH_SURROGATE >>> SURROGATE_PAYLOAD_BIT_COUNT;  // == 0x36
+
+    /**
+     * Produces a Supplementary Multilingual Plane code-point when added
to a valid surrogate-pair
+     * combined as follows: {@code (highSurrogate <<
SURROGATE_PAYLOAD_BIT_COUNT) + lowSurrogate}.
+     * The result is undefined if either would-be surrogate is invalid
(not a surrogate code-unit,
+     * or the wrong surrogate type [low instead of high, or vice versa]).
+     *
+     * @see Character#toCodePoint(char, char)
+     */
+    private static final int    SURROGATE_COMBO_TO_CODE_POINT_DELTA =
 Character.MIN_SUPPLEMENTARY_CODE_POINT
+                                                                    -
(Character.MIN_HIGH_SURROGATE << SURROGATE_PAYLOAD_BIT_COUNT)
+                                                                    -
 Character.MIN_LOW_SURROGATE;  // -56_613_888
+
+
     public static byte[] newBytesFor(int len) {
         if (len < 0) {
             throw new NegativeArraySizeException();
@@ -318,93 +343,429 @@
         return -StringLatin1.compareToUTF16(other, value, len2, len1);
     }

-    public static int compareToCI(byte[] value, byte[] other) {
-        return compareToCIImpl(value, 0, length(value), other, 0,
length(other));
+    /**
+     * Compares case-insensitively UTF-16 sequences in {@code byte}
arrays. Performs
+     * {@linkplain #compareCodePointsIgnoringCase case conversions
equivalent to
+     *
<code>Character.toLowerCase(Character.toUpperCase(codePoint))</code>} before
+     * comparing unequal code-points.
+     *
+     * @param charsA array of byte pairs representing 16-bit ({@code
char}) quantities,
+     *               with byte order mandated by {@code
StringUTF16.isBigEndian()}
+     * @param charsB array of byte pairs representing 16-bit ({@code
char}) quantities,
+     *               with byte order mandated by {@code
StringUTF16.isBigEndian()}
+     *
+     * @return negative if {@code charsA} is lexicographically less than
{@code charsB},
+     * positive if it is greater, or zero if they are equal
+     */
+    static int compareToCI
+    (
+        final byte[]            charsA,
+        final byte[]            charsB
+    ){
+    //  Consider: If the G1 garbage collector's string-deduplication mode
is enabled, performance may
+    //            be improved by first testing "charsA" and "charsB" for
reference equality, and
+    //            returning zero in that case. However, the same is
equally true for all invocations
+    //            of "String.compareToIgnoreCase" (not just those
operating on two UTF-16 strings),
+    //            so the test belongs in that method (ideally with magic
causing the array reference
+    //            equality test to occur only when G1 and its
string-deduplication mode are active).
+    //                Similarly modifying methods
"String.equalsIgnoreCase" and "String.equals" may be
+    //            even more beneficial, because they already include
"String" object reference equality
+    //            fast-paths, unlike "String.compareToIgnoreCase".
+    //                Indeed, string-deduplication makes reference
equality more likely between backing-
+    //            store arrays than "String" objects, and therefore the
more important fast-path test,
+    //            provided real-world use of those methods frequently
involves "String" objects whose
+    //            tenure (number of garbage-collections survived) is >=
the deduplication threshold (3
+    //            by default, as of JDK 15, or the
"-XX:StringDeduplicationAgeThreshold" value).
+
+        final int               lengthSignum = charsA.length -
charsB.length;
+
+    //  If the array lengths are identical, return the "compareToCI"
result; no additional
+    //  considerations apply.
+
+        if (lengthSignum == 0)
+            return compareToCI(charsA, 0, charsB, 0, length(charsA));
+
+    //  The array lengths differ. Compare the elements present in both
"charsA" and "charsB".
+    //  If the comparison result is inequality, return the comparison
result. If the result
+    //  is equality, the shorter array is considered less than the longer
array.
+
+        final int               compareSignum = compareToCI(charsA, 0,
charsB, 0, length(lengthSignum <= 0 ? charsA : charsB));
+
+    //  The right-shift (division by two) applied to "lengthSignum" below
is necessary only
+    //  if compatibility is required with code expecting specific return
values (instead of
+    //  any negative or positive value) from known comparisons.
+
+        return compareSignum != 0 ? compareSignum : lengthSignum >> 1;
     }
-
-    private static int compareToCIImpl(byte[] value, int toffset, int tlen,
-                                      byte[] other, int ooffset, int olen)
{
-        int tlast = toffset + tlen;
-        int olast = ooffset + olen;
-        assert toffset >= 0 && ooffset >= 0;
-        assert tlast <= length(value);
-        assert olast <= length(other);
-
-        for (int k1 = toffset, k2 = ooffset; k1 < tlast && k2 < olast;
k1++, k2++) {
-            int cp1 = (int)getChar(value, k1);
-            int cp2 = (int)getChar(other, k2);
-
-            if (cp1 == cp2 || compareCodePointCI(cp1, cp2) == 0) {
+
+    /**
+     * Compares case-insensitively UTF-16 sequences in {@code byte} array
subsections.
+     * Performs {@linkplain #compareCodePointsIgnoringCase case
conversions equivalent
+     * to
<code>Character.toLowerCase(Character.toUpperCase(codePoint))</code>} before
+     * comparing unequal code-points.
+     *
+     * @param charsA      array of byte pairs representing 16-bit ({@code
char}) quantities,
+     *                    with byte order mandated by {@code
StringUTF16.isBigEndian()}
+     * @param charsAIndex index, in 16-bit quantities, at which comparison
of "{@code charsA}"
+     *                    begins. Caller must enforce constraints "{@code
0 <= charsAIndex}"
+     *                    and "{@code 0 <= charsAIndex + totalChars <=
charsA.length / 2}".
+     * @param charsB      array of byte pairs representing 16-bit ({@code
char}) quantities,
+     *                    with byte order mandated by {@code
StringUTF16.isBigEndian()}
+     * @param charsBIndex index, in 16-bit quantities, at which comparison
of "{@code charsB}"
+     *                    begins. Caller must enforce constraints "{@code
0 <= charsBIndex}"
+     *                    and "{@code 0 <= charsBIndex + totalChars <=
charsB.length / 2}".
+     * @param totalChars  maximum number of {@code char}s to compare.
Caller must enforce
+     *                    constraint "{@code 0 <= totalChars}".
+     *
+     * @return negative if the compared portion of {@code charsA} is
lexicographically less
+     * than that of {@code charsB}, positive if it is greater, or zero if
they are equal
+     *
+     * @implNote <p>This method relies on the following "<b>Unicode
Empirical Properties</b>":</p>
+     * <ol>
+     *     <li>
+     *         <p>Only code-points encoded using the same UTF-16
high-surrogate may be case-insensitively equal.</p>
+     *         <p>Several facts suggest sufficient proximity of code-point
case-variants within the Supplementary
+     *         Multilingual Plane (SMP):</p>
+     *         <ul>
+     *             <li>Related code-points are grouped into a Unicode
"block".</li>
+     *             <li>Blocks start at multiples of 256.</li>
+     *             <li>High-surrogates encode 1,024 code-points starting
with multiples of 1,024.</li>
+     *             <li>Few SMP code-points are case-sensitive (450, as of
Unicode 13.0.0).</li>
+     *         </ul>
+     *         <p>Thus, it is not surprising this property has held for 25
years, as of February, 2021.</p>
+     *     <li><p>For all SMP code-points, both {@code
Character.toLowerCase(Character.toUpperCase(int))} and
+     *         {@code Character.toUpperCase(int)} return a SMP code-point,
never a Basic Multilingual Plane (BMP)
+     *         code-point.</p>
+     *         <p>Supporting points:</p>
+     *         <ul>
+     *             <li>This is expected due to related code-point
grouping.</li>
+     *             <li>If this property were ever invalidated, every
Unicode case-insensitive equality test
+     *             which requires equal-length input sequences (measured
in {@code byte}s or {@code char}s)
+     *             would break. In other words, this property is already
utilized more-or-less universally by
+     *             Unicode case-insensitive equality tests, whether or not
their authors realize it. The
+     *             Unicode Consortium has likely been aware of, and
sensitive to, this issue for years.
+     *             </li>
+     *         </ul>
+     *     </li>
+     *     <li><p>For all BMP code-points, both {@code
Character.toLowerCase(Character.toUpperCase(int))} and
+     *         {@code Character.toUpperCase(int)} return a BMP code-point,
never a SMP code-point.</p>
+     *         <p>Supporting points:</p>
+     *         <ul>
+     *             <li>This is expected due to related code-point
grouping.</li>
+     *             <li>Most scripts affected by letter case were added
early in Unicode's history, and therefore
+     *             placed in the BMP. (As of Unicode 13.0.0, there are
2,349 case-sensitive code-points in the
+     *             BMP, but only 450 in the SMP.)
+     *             </li>
+     *             <li>If this property were ever invalidated, every
Unicode case-insensitive equality test
+     *             which requires equal-length input sequences (measured
in {@code byte}s or {@code char}s)
+     *             would break. In other words, this property is already
utilized more-or-less universally by
+     *             Unicode case-insensitive equality tests, whether or not
their authors realize it. The
+     *             Unicode Consortium has likely been aware of, and
sensitive to, this issue for years.
+     *             </li>
+     *         </ul>
+     *     </li>
+     * </ol>
+     * <p>Validation of each property is performed automatically by unit
tests in {@code CompareIC}
+     * ("test/jdk/java/lang/String/CompareIC.java") during normal,
post-build JDK testing. Those unit tests
+     * methods are, respectively:
+     * </p>
+     * <ol>
+     *     <li>{@code
validatePremise_AllSMPCodePointCaseVariantsUseTheSameHighSurrogate}</li>
+     *     <li>{@code
validatePremise_AllSMPCodePointCaseVariantsAreSMPCodePoints}</li>
+     *     <li>{@code
validatePremise_AllBMPCodePointCaseVariantsAreBMPCodePoints}</li>
+     * </ol>
+     * <p>Those tests' Javadocs include discussion of the consequences
should they ever fail.
+     * </p>
+     */
+    private static int compareToCI
+    (
+        final byte[] charsA, int charsAIndex,
+        final byte[] charsB, int charsBIndex, int totalChars
+    ){
+    //  Assertions carried-over from the previous "regionMatchesCI"
implementation, with additional
+    //  negative value testing. (Are these assertions still necessary or
desirable?)
+
+        assert (charsAIndex | charsBIndex | totalChars) >= 0;  // Ensure
these parameters are non-negative.
+        assert  charsAIndex + totalChars <= length(charsA);
+        assert  charsBIndex + totalChars <= length(charsB);
+
+    //  Variable "priorExactlyEqualChar" (PEEC) is used by the following
loop to store the "char" value read
+    //  by its prior iteration, if the same "char" value was read from
both inputs ("charsA" and "charsB").
+    //  Otherwise, it is set to zero. PEEC's value is used only during the
UTF-16 decoding attempt triggered
+    //  by reading a pair of unequal low-surrogates (see Unicode empirical
property no. 1). It removes from
+    //  this algorithm all read-behind/-ahead operations, along with their
extra tests & branches, and
+    //  redundant array accesses.
+    //      Note: PEEC can be zero for three reasons: (1) the loop is in
its first iteration, (2) the prior
+    //  iteration read code-point zero from both inputs, or (3) the prior
iteration read different, but case-
+    //  insensitively equal, Basic Multilingual Plane code-points. In all
three cases, zero signifies absence
+    //  of preceding, identical high-surrogates (as does any
non-high-surrogate value). Thus, a zero value's
+    //  cause is ambiguous, but its meaning is clear.
+
+        int                     priorExactlyEqualChar = 0;  // AKA "PEEC".
+
+        while (--totalChars >= 0) {
+            int                     cA = getChar(charsA, charsAIndex++);
+            int                     cB = getChar(charsB, charsBIndex++);
+
+            if (cA == cB) {
+
+            //  If the next iteration's "cA" and "cB" are different
low-surrogate code-units, it will need this
+            //  iteration's value of "cA"/"cB" (their presumed
high-surrogate code-unit), so it is stored in
+            //  "priorExactlyEqualChar" (PEEC). In all other cases, this
caching of "cA"/"cB" in PEEC is a small
+            //  waste of time. However, the time saved by eliminating the
tests, branches and reads necessary to
+            //  reacquire pairs of high-surrogates should compensate for
many unnecessary writes to PEEC.
+
+                priorExactlyEqualChar = cA;
                 continue;
             }
-
-            // Check for supplementary characters case
-            cp1 = codePointIncluding(value, cp1, k1, toffset, tlast);
-            if (cp1 < 0) {
-                k1++;
-                cp1 -= cp1;
-            }
-            cp2 = codePointIncluding(other, cp2, k2, ooffset, olast);
-            if (cp2 < 0) {
-                k2++;
-                cp2 -= cp2;
-            }
-
-            int diff = compareCodePointCI(cp1, cp2);
-            if (diff != 0) {
-                return diff;
-            }
-        }
-        return tlen - olen;
-    }
-
-    // Case insensitive comparison of two code points
-    private static int compareCodePointCI(int cp1, int cp2) {
-        // try converting both characters to uppercase.
-        // If the results match, then the comparison scan should
-        // continue.
-        cp1 = Character.toUpperCase(cp1);
-        cp2 = Character.toUpperCase(cp2);
-        if (cp1 != cp2) {
-            // Unfortunately, conversion to uppercase does not work
properly
-            // for the Georgian alphabet, which has strange rules about
case
-            // conversion.  So we need to make one last check before
-            // exiting.
-            cp1 = Character.toLowerCase(cp1);
-            cp2 = Character.toLowerCase(cp2);
-            if (cp1 != cp2) {
-                return cp1 - cp2;
+
+        //  KNOWN: "cA" and "cB" are not precisely equal.
+
+        //  When "priorExactlyEqualChar" is a high-surrogate, and both
"cA" and "cB" are low-surrogates, the
+        //  following "if" block performs UTF-16 decoding, replacing the
code-units in "cA" and "cB" with
+        //  code-points. The "if" block then falls-through to the
code-point case-insensitive comparison.
+        //
+        //  If any UTF-16 decoding precondition is unmet, "cA" and "cB"
will contain Basic Multilingual Plane
+        //  (BMP) code-points suitable for case-insensitive comparison,
unless UTF-16 encoding is corrupt in
+        //  "charsA" and/or "charsB". The following cases are possible:
+        //      * "priorExactlyEqualChar" is not a high-surrogate, so the
"if" block is not entered.
+        //         Possible states of "cA" and "cB":
+        //          * "cA" and "cB" are unequal BMP code-points,
potentially case-insensitively equal.
+        //          * "cA" and "cB" are unequal high-surrogates.
Case-insensitive equality testing inevitably
+        //            fails for those code-units, terminating this method.
Low-surrogate retrieval and UTF-16
+        //            decoding are unnecessary due to Unicode empirical
property no. 1.
+        //          * "cA" and "cB" are unequal low-surrogates. UTF-16
encoding is corrupt in both "charsA"
+        //            and "charsB" (low-surrogates not preceded by
high-surrogates). Case-insensitive equality
+        //            testing inevitably fails for those code-units,
terminating this method.
+        //          * Either "cA" or "cB" is a low-surrogate, while the
other is a high-surrogate or BMP code-
+        //            point. UTF-16 encoding is corrupt in the array
supplying the low-surrogate (no preceding
+        //            high-surrogate). Case-insensitive equality testing
inevitably fails, terminating this
+        //            method.
+        //      * "priorExactlyEqualChar" is a high-surrogate present in
both "charsA" and "charsB".
+        //        Possible states of "cA" and "cB":
+        //          * "cA" and "cB" are unequal low-surrogates. The "if"
block is entered, converting "cA"
+        //            and "cB" into Supplementary Multilingual Plane (SMP)
code-points, potentially case-
+        //            insensitively equal.
+        //          * "cA" and "cB" are unequal high-surrogates. UTF-16
encoding is corrupt in both "charsA"
+        //            and "charsB" (high-surrogates following
high-surrogates). Even if the next loop
+        //            iteration would retrieve low-surrogates, Unicode
empirical property no. 1 rules-out
+        //            case-insensitive equality based on the unequal
high-surrogates alone.
+        //          * "cA" and "cB" are unequal BMP code-points,
potentially case-insensitively equal. UTF-16
+        //            encoding is corrupt in both "charsA" and "charsB"
(high-surrogates not followed by low-
+        //            surrogates), but the corruption is ignored because
the high-surrogates were identical
+        //            (equality exists thus far, corrupt encoding
notwithstanding).
+        //          * Either "cA" or "cB" is a low-surrogate, while the
other is a high-surrogate or BMP code-
+        //            point. UTF-16 encoding is corrupt in the array
supplying the non-low-surrogate (high-
+        //            surrogate not followed by low-surrogate). UTF-16
decoding using the lone low-surrogate
+        //            is unnecessary, because either:
+        //              1. The non-low-surrogate is a high-surrogate,
ruling-out case-insensitive equality.
+        //                 (Two independent rationales: [1] A
high-surrogate is not a low-surrogate, by
+        //                 definition. Also by definition, [2] an SMP
code-point--decoded from high-surrogate
+        //                 "priorExactlyEqualChar" and the lone
low-surrogate--is not a high-surrogate code-
+        //                 unit.)
+        //              2. The non-low-surrogate is a BMP code-point.
Unicode empirical properties 2 and 3
+        //                 rule-out case-insensitive equality between SMP
and BMP code-points.
+        //                     (Alternately, if those properties did not
exist, deciding equality exists based
+        //                 on code-points at different positions within
the compared string sections--whose
+        //                 comparison requires overlooking an inconvenient
preceding code-unit in one string--
+        //                 would be logically dubious on multiple grounds.
For instance, if one preceding
+        //                 orphan surrogate can be ignored to prove
equality, is the same true for two or more
+        //                 orphans consecutively and/or separately? If so,
existing code breaks. Notably, most
+        //                 string equality tests would break due to
invalidation of their equal-length strings
+        //                 precondition. [A precondition also invalidated
if the Unicode Consortium ever
+        //                 asserts case-insensitive equality between a BMP
and SMP code-point. Thus, Unicode
+        //                 empirical properties 2 and 3 will likely
persist.])
+        //
+        //  (Aside: Of the following three tests, only the test of
"priorExactlyEqualChar" would be necessary
+        //  if Unicode [non-compact] "String" objects guaranteed valid
UTF-16 encoding. It seems certain
+        //  enforcing that guarantee during creation of every "String" [or
string-like object] is infeasible
+        //  due to runtime cost, and backwards-incompatibility.
Nonetheless, this writer [CWJ] is tantalized
+        //  by the many code simplifications guaranteed-correct "String"
objects would permit, as well as the
+        //  clues they could confer on some developers [including this
writer, once upon a time].)
+
+        //  Branch Reduction
+        //
+        //  The "if" statement used below has two tests/branches, instead
of three, due to combining two
+        //  low-surrogate tests into one. Multiple comparative benchmarks
(each using 300 random data sets
+        //  of 200,000 comparisons, repeated 800 times [160 million
comparisons per data set; 48 billion
+        //  total comparisons]), run on two different OS & hardware
combinations, yielded respective best-
+        //  case improvements of 1.24% and 0.98%, and mean improvements of
1.79% and 0.62%, relative to
+        //  three-branch "if" statement:
+        //
+        //      if (priorExactlyEqualChar >>> SURROGATE_PAYLOAD_BIT_COUNT
== SURROGATE_HI_HEADER_RIGHT_SHIFTED_10
+        //      &&  cA                    >>> SURROGATE_PAYLOAD_BIT_COUNT
== SURROGATE_LO_HEADER_RIGHT_SHIFTED_10
+        //      &&  cB                    >>> SURROGATE_PAYLOAD_BIT_COUNT
== SURROGATE_LO_HEADER_RIGHT_SHIFTED_10)
+        //
+        //  Conversely, combining all three tests into one yields worse
performance than the three-test
+        //  "if" shown above, because high-surrogate testing of
"priorExactlyEqualChar" fails frequently
+        //  (50% minimum failure rate for well-formed UTF-16), and, when
it fails, low-surrogate testing
+        //  of "cA" and "cB" wastes time.
+
+            if (priorExactlyEqualChar >>> SURROGATE_PAYLOAD_BIT_COUNT ==
SURROGATE_HI_HEADER_RIGHT_SHIFTED_10
+            && (cA ^ Character.MIN_LOW_SURROGATE | cB ^
Character.MIN_LOW_SURROGATE) >>> SURROGATE_PAYLOAD_BIT_COUNT == 0
+            ){
+            //  KNOWN: "cA" and "cB" are not precisely equal.
+            //  KNOWN: "priorExactlyEqualChar" is a high-surrogate
code-unit.
+            //  KNOWN: "cA" and "cB" are low-surrogate code-units. (Bits
15 to 10 of both are 110111.)
+
+            //  Perform UTF-16 decoding, accelerated by repurposing
"priorExactlyEqualChar" (PEEC) to store
+            //  the result of decoding operations common to both "cA" and
"cB" (because they share the high-
+            //  surrogate in PEEC). Near-total commonality of operations
enables decoding two code-points
+            //  using only one more addition operation than decoding a
single code-point. (PEEC's repurposing
+            //  is brief; it is always set to zero immediately after this
"if" block.)
+
+                priorExactlyEqualChar = (priorExactlyEqualChar <<
SURROGATE_PAYLOAD_BIT_COUNT) + SURROGATE_COMBO_TO_CODE_POINT_DELTA;
+
+                cA += priorExactlyEqualChar;
+                cB += priorExactlyEqualChar;
             }
+
+        //  "cA" and "cB" are not precisely equal, therefore set
"priorExactlyEqualChar" (PEEC) to zero for
+        //  the next iteration's potential benefit. ("Potential benefit,"
because the next iteration, if any,
+        //  uses PEEC's value only when its "cA" and "cB" are different
low-surrogate code-units.)
+
+            priorExactlyEqualChar = 0;
+
+        //  Having performed UTF-16 decoding (if necessary and possible),
compare case-insensitively code-
+        //  points "cA" and "cB".
+        //
+        //  Note: Code-units are also possible. Normal terminating
conditions include unequal high-surrogates
+        //        (see Unicode empirical property no. 1), and a
high-surrogate/code-point combination. An
+        //        abnormal terminating condition is a low-surrogate and a
code-point, meaning at least one
+        //        input string's UTF-16 encoding is corrupt (a
low-surrogate not preceded by a high-surrogate,
+        //        or matching high-surrogates not followed--in one
string--by a low-surrogate). None of those
+        //        conditions undermines the code below, because
"compareCodePointsIgnoringCase" evaluates
+        //        "caseless" inputs unchanged, including code-units.
+
+            cA = compareCodePointsIgnoringCase(cA, cB);
+            if (cA != 0)
+                return cA;
         }
+
         return 0;
     }
-
-    // Returns a code point from the code unit pointed by "index". If it is
-    // not a surrogate or an unpaired surrogate, then the code unit is
-    // returned as is. Otherwise, it is combined with the code unit before
-    // or after, depending on the type of the surrogate at index, to make a
-    // supplementary code point. The return value will be negated if the
code
-    // unit pointed by index is a high surrogate, and index + 1 is a low
surrogate.
-    private static int codePointIncluding(byte[] ba, int cp, int index,
int start, int end) {
-        // fast check
-        if (!Character.isSurrogate((char)cp)) {
-            return cp;
-        }
-        if (Character.isLowSurrogate((char)cp)) {
-            if (index > start) {
-                char c = getChar(ba, index - 1);
-                if (Character.isHighSurrogate(c)) {
-                    return Character.toCodePoint(c, (char)cp);
-                }
-            }
-        } else if (index + 1 < end) { // cp == high surrogate
-            char c = getChar(ba, index + 1);
-            if (Character.isLowSurrogate(c)) {
-                // negate the code point
-                return - Character.toCodePoint((char)cp, c);
-            }
-        }
-        return cp;
+
+    /**
+     * Gets the case-insensitive, lexicographical relationship between
code-points.
+     * Though not required, passing this method only unequal code-points
("{@code
+     * codePointA != codePointB}") is most efficient.
+     *
+     * @param codePointA first code-point
+     * @param codePointB second code-point
+     *
+     * @return "{@code codePointA - codePointB}" after both undergo
case-conversion equivalent
+     * to, but faster than, {@code
Character.toLowerCase(Character.toUpperCase(codePoint))}
+     *
+     * @implNote This method uses two, duplicate {@code switch}
expressions, because
+     * benchmarking showed a noticeable performance improvement over a
single {@code
+     * switch} wrapped in the most minimal of two-iteration loops. The
duplication
+     * should create no maintenance problems, because, as detailed by a
comment within
+     * the method, the {@code switch} source code is programmatically
generated when a
+     * "CompareIC" unit test detects a mishandled "triple-case"
code-point. Otherwise,
+     * modifying these expressions is unnecessary. (The unit test does not
alter this,
+     * or any, file; it merely includes updated {@code switch} source in
its error
+     * message, leaving a human responsible for pasting it here, twice.)
+     */
+    static int compareCodePointsIgnoringCase
+    (
+        final int               codePointA,
+        final int               codePointB
+    ){
+    /*  A code-point is here dubbed "triple-case" if "codePoint !=
Character.toUpperCase(codePoint) &&
+        codePoint !=
Character.toLowerCase(Character.toUpperCase(codePoint))". Such code-points
are rare
+        (see "switch" expressions below), but force most code-point
comparisons to invoke both "toUpperCase"
+        and "toLowerCase". If "triple-case" code-points did not exist,
invoking only "toLowerCase" would
+        suffice.
+
+        This method comes close to realizing the "no triple-case
code-points" scenario by directly converting
+        "triple-case" code-points to their final, lowercase forms using
"switch" expressions, and invoking
+        only "toLowerCase" on all other code-points. The effect is a
benchmark performance gain of 24.3%.
+
+        Note: The Georgian alphabet includes no "triple-case" code-points,
as shown below by the "progression"
+              columns of the "switch" expressions' comments. (As of
Unicode 13.0.0, there are three Georgian
+              blocks: "Georgian" 10A0-10FF, "Georgian Extended" 1C90-1CBF,
and "Georgian Supplement" 2D00-2D2F.)
+
+
+        TESTING AND CODE GENERATION
+
+        A unit test in "CompareIC"
("test/jdk/java/lang/String/CompareIC.java") searches all 1,114,112 Unicode
+        code-points/-units for triple-case code-points, then validates
their handling by "String.equalsIgnoreCase"
+        and "String.compareToIgnoreCase". If errors are detected, those
tests fail with a message detailing each
+        error and supplying freshly generated source code for the "switch"
expression used twice below. (If the
+        new and existing set of "case" clauses differ, pasting the former
over the latter will fix the problem.
+        If "case" clauses are identical, the problem lies elsewhere.)
+    */
+                                          //  Triple-Case Code-Points, as
of Java 15.0.2. (Written by
"java.lang.CompareIC.generateTripleCaseCodePointsSwitchExpression".)
+                                          //
+                                          //  Code-Point Progression
   Code-Point Progression by Name
+        return switch (codePointA) {      //  --------------------------

 -------------------------------------------------------------------------------------------------------------------------------------
+            case '\u00B5' -> '\u03BC';    //  U+00B5 -> U+039C -> U+03BC
   MICRO SIGN                                            -> GREEK CAPITAL
LETTER MU               -> GREEK SMALL LETTER MU
+            case '\u0131' -> '\u0069';    //  U+0131 -> U+0049 -> U+0069
   LATIN SMALL LETTER DOTLESS I                          -> LATIN CAPITAL
LETTER I                -> LATIN SMALL LETTER I
+            case '\u017F' -> '\u0073';    //  U+017F -> U+0053 -> U+0073
   LATIN SMALL LETTER LONG S                             -> LATIN CAPITAL
LETTER S                -> LATIN SMALL LETTER S
+            case '\u01C5' -> '\u01C6';    //  U+01C5 -> U+01C4 -> U+01C6
   LATIN CAPITAL LETTER D WITH SMALL LETTER Z WITH CARON -> LATIN CAPITAL
LETTER DZ WITH CARON    -> LATIN SMALL LETTER DZ WITH CARON
+            case '\u01C8' -> '\u01C9';    //  U+01C8 -> U+01C7 -> U+01C9
   LATIN CAPITAL LETTER L WITH SMALL LETTER J            -> LATIN CAPITAL
LETTER LJ               -> LATIN SMALL LETTER LJ
+            case '\u01CB' -> '\u01CC';    //  U+01CB -> U+01CA -> U+01CC
   LATIN CAPITAL LETTER N WITH SMALL LETTER J            -> LATIN CAPITAL
LETTER NJ               -> LATIN SMALL LETTER NJ
+            case '\u01F2' -> '\u01F3';    //  U+01F2 -> U+01F1 -> U+01F3
   LATIN CAPITAL LETTER D WITH SMALL LETTER Z            -> LATIN CAPITAL
LETTER DZ               -> LATIN SMALL LETTER DZ
+            case '\u0345' -> '\u03B9';    //  U+0345 -> U+0399 -> U+03B9
   COMBINING GREEK YPOGEGRAMMENI                         -> GREEK CAPITAL
LETTER IOTA             -> GREEK SMALL LETTER IOTA
+            case '\u03C2' -> '\u03C3';    //  U+03C2 -> U+03A3 -> U+03C3
   GREEK SMALL LETTER FINAL SIGMA                        -> GREEK CAPITAL
LETTER SIGMA            -> GREEK SMALL LETTER SIGMA
+            case '\u03D0' -> '\u03B2';    //  U+03D0 -> U+0392 -> U+03B2
   GREEK BETA SYMBOL                                     -> GREEK CAPITAL
LETTER BETA             -> GREEK SMALL LETTER BETA
+            case '\u03D1' -> '\u03B8';    //  U+03D1 -> U+0398 -> U+03B8
   GREEK THETA SYMBOL                                    -> GREEK CAPITAL
LETTER THETA            -> GREEK SMALL LETTER THETA
+            case '\u03D5' -> '\u03C6';    //  U+03D5 -> U+03A6 -> U+03C6
   GREEK PHI SYMBOL                                      -> GREEK CAPITAL
LETTER PHI              -> GREEK SMALL LETTER PHI
+            case '\u03D6' -> '\u03C0';    //  U+03D6 -> U+03A0 -> U+03C0
   GREEK PI SYMBOL                                       -> GREEK CAPITAL
LETTER PI               -> GREEK SMALL LETTER PI
+            case '\u03F0' -> '\u03BA';    //  U+03F0 -> U+039A -> U+03BA
   GREEK KAPPA SYMBOL                                    -> GREEK CAPITAL
LETTER KAPPA            -> GREEK SMALL LETTER KAPPA
+            case '\u03F1' -> '\u03C1';    //  U+03F1 -> U+03A1 -> U+03C1
   GREEK RHO SYMBOL                                      -> GREEK CAPITAL
LETTER RHO              -> GREEK SMALL LETTER RHO
+            case '\u03F5' -> '\u03B5';    //  U+03F5 -> U+0395 -> U+03B5
   GREEK LUNATE EPSILON SYMBOL                           -> GREEK CAPITAL
LETTER EPSILON          -> GREEK SMALL LETTER EPSILON
+            case '\u1C80' -> '\u0432';    //  U+1C80 -> U+0412 -> U+0432
   CYRILLIC SMALL LETTER ROUNDED VE                      -> CYRILLIC
CAPITAL LETTER VE            -> CYRILLIC SMALL LETTER VE
+            case '\u1C81' -> '\u0434';    //  U+1C81 -> U+0414 -> U+0434
   CYRILLIC SMALL LETTER LONG-LEGGED DE                  -> CYRILLIC
CAPITAL LETTER DE            -> CYRILLIC SMALL LETTER DE
+            case '\u1C82' -> '\u043E';    //  U+1C82 -> U+041E -> U+043E
   CYRILLIC SMALL LETTER NARROW O                        -> CYRILLIC
CAPITAL LETTER O             -> CYRILLIC SMALL LETTER O
+            case '\u1C83' -> '\u0441';    //  U+1C83 -> U+0421 -> U+0441
   CYRILLIC SMALL LETTER WIDE ES                         -> CYRILLIC
CAPITAL LETTER ES            -> CYRILLIC SMALL LETTER ES
+            case '\u1C84' -> '\u0442';    //  U+1C84 -> U+0422 -> U+0442
   CYRILLIC SMALL LETTER TALL TE                         -> CYRILLIC
CAPITAL LETTER TE            -> CYRILLIC SMALL LETTER TE
+            case '\u1C85' -> '\u0442';    //  U+1C85 -> U+0422 -> U+0442
   CYRILLIC SMALL LETTER THREE-LEGGED TE                 -> CYRILLIC
CAPITAL LETTER TE            -> CYRILLIC SMALL LETTER TE
+            case '\u1C86' -> '\u044A';    //  U+1C86 -> U+042A -> U+044A
   CYRILLIC SMALL LETTER TALL HARD SIGN                  -> CYRILLIC
CAPITAL LETTER HARD SIGN     -> CYRILLIC SMALL LETTER HARD SIGN
+            case '\u1C87' -> '\u0463';    //  U+1C87 -> U+0462 -> U+0463
   CYRILLIC SMALL LETTER TALL YAT                        -> CYRILLIC
CAPITAL LETTER YAT           -> CYRILLIC SMALL LETTER YAT
+            case '\u1C88' -> '\uA64B';    //  U+1C88 -> U+A64A -> U+A64B
   CYRILLIC SMALL LETTER UNBLENDED UK                    -> CYRILLIC
CAPITAL LETTER MONOGRAPH UK  -> CYRILLIC SMALL LETTER MONOGRAPH UK
+            case '\u1E9B' -> '\u1E61';    //  U+1E9B -> U+1E60 -> U+1E61
   LATIN SMALL LETTER LONG S WITH DOT ABOVE              -> LATIN CAPITAL
LETTER S WITH DOT ABOVE -> LATIN SMALL LETTER S WITH DOT ABOVE
+            case '\u1FBE' -> '\u03B9';    //  U+1FBE -> U+0399 -> U+03B9
   GREEK PROSGEGRAMMENI                                  -> GREEK CAPITAL
LETTER IOTA             -> GREEK SMALL LETTER IOTA
+                                          //  --------------------------

 -------------------------------------------------------------------------------------------------------------------------------------
+        //  All other case-sensitive code-points are either uppercase (in
which case they are changed
+        //  below), or lowercase already (in which case they are not).
Therefore, only "toLowerCase"
+        //  is necessary. Code-units and case-insensitive code-points are
unchanged by "toLowerCase".
+            default -> Character.toLowerCase(codePointA);
+
+        } - switch (codePointB) {         //  --------------------------

 -------------------------------------------------------------------------------------------------------------------------------------
+            case '\u00B5' -> '\u03BC';    //  U+00B5 -> U+039C -> U+03BC
   MICRO SIGN                                            -> GREEK CAPITAL
LETTER MU               -> GREEK SMALL LETTER MU
+            case '\u0131' -> '\u0069';    //  U+0131 -> U+0049 -> U+0069
   LATIN SMALL LETTER DOTLESS I                          -> LATIN CAPITAL
LETTER I                -> LATIN SMALL LETTER I
+            case '\u017F' -> '\u0073';    //  U+017F -> U+0053 -> U+0073
   LATIN SMALL LETTER LONG S                             -> LATIN CAPITAL
LETTER S                -> LATIN SMALL LETTER S
+            case '\u01C5' -> '\u01C6';    //  U+01C5 -> U+01C4 -> U+01C6
   LATIN CAPITAL LETTER D WITH SMALL LETTER Z WITH CARON -> LATIN CAPITAL
LETTER DZ WITH CARON    -> LATIN SMALL LETTER DZ WITH CARON
+            case '\u01C8' -> '\u01C9';    //  U+01C8 -> U+01C7 -> U+01C9
   LATIN CAPITAL LETTER L WITH SMALL LETTER J            -> LATIN CAPITAL
LETTER LJ               -> LATIN SMALL LETTER LJ
+            case '\u01CB' -> '\u01CC';    //  U+01CB -> U+01CA -> U+01CC
   LATIN CAPITAL LETTER N WITH SMALL LETTER J            -> LATIN CAPITAL
LETTER NJ               -> LATIN SMALL LETTER NJ
+            case '\u01F2' -> '\u01F3';    //  U+01F2 -> U+01F1 -> U+01F3
   LATIN CAPITAL LETTER D WITH SMALL LETTER Z            -> LATIN CAPITAL
LETTER DZ               -> LATIN SMALL LETTER DZ
+            case '\u0345' -> '\u03B9';    //  U+0345 -> U+0399 -> U+03B9
   COMBINING GREEK YPOGEGRAMMENI                         -> GREEK CAPITAL
LETTER IOTA             -> GREEK SMALL LETTER IOTA
+            case '\u03C2' -> '\u03C3';    //  U+03C2 -> U+03A3 -> U+03C3
   GREEK SMALL LETTER FINAL SIGMA                        -> GREEK CAPITAL
LETTER SIGMA            -> GREEK SMALL LETTER SIGMA
+            case '\u03D0' -> '\u03B2';    //  U+03D0 -> U+0392 -> U+03B2
   GREEK BETA SYMBOL                                     -> GREEK CAPITAL
LETTER BETA             -> GREEK SMALL LETTER BETA
+            case '\u03D1' -> '\u03B8';    //  U+03D1 -> U+0398 -> U+03B8
   GREEK THETA SYMBOL                                    -> GREEK CAPITAL
LETTER THETA            -> GREEK SMALL LETTER THETA
+            case '\u03D5' -> '\u03C6';    //  U+03D5 -> U+03A6 -> U+03C6
   GREEK PHI SYMBOL                                      -> GREEK CAPITAL
LETTER PHI              -> GREEK SMALL LETTER PHI
+            case '\u03D6' -> '\u03C0';    //  U+03D6 -> U+03A0 -> U+03C0
   GREEK PI SYMBOL                                       -> GREEK CAPITAL
LETTER PI               -> GREEK SMALL LETTER PI
+            case '\u03F0' -> '\u03BA';    //  U+03F0 -> U+039A -> U+03BA
   GREEK KAPPA SYMBOL                                    -> GREEK CAPITAL
LETTER KAPPA            -> GREEK SMALL LETTER KAPPA
+            case '\u03F1' -> '\u03C1';    //  U+03F1 -> U+03A1 -> U+03C1
   GREEK RHO SYMBOL                                      -> GREEK CAPITAL
LETTER RHO              -> GREEK SMALL LETTER RHO
+            case '\u03F5' -> '\u03B5';    //  U+03F5 -> U+0395 -> U+03B5
   GREEK LUNATE EPSILON SYMBOL                           -> GREEK CAPITAL
LETTER EPSILON          -> GREEK SMALL LETTER EPSILON
+            case '\u1C80' -> '\u0432';    //  U+1C80 -> U+0412 -> U+0432
   CYRILLIC SMALL LETTER ROUNDED VE                      -> CYRILLIC
CAPITAL LETTER VE            -> CYRILLIC SMALL LETTER VE
+            case '\u1C81' -> '\u0434';    //  U+1C81 -> U+0414 -> U+0434
   CYRILLIC SMALL LETTER LONG-LEGGED DE                  -> CYRILLIC
CAPITAL LETTER DE            -> CYRILLIC SMALL LETTER DE
+            case '\u1C82' -> '\u043E';    //  U+1C82 -> U+041E -> U+043E
   CYRILLIC SMALL LETTER NARROW O                        -> CYRILLIC
CAPITAL LETTER O             -> CYRILLIC SMALL LETTER O
+            case '\u1C83' -> '\u0441';    //  U+1C83 -> U+0421 -> U+0441
   CYRILLIC SMALL LETTER WIDE ES                         -> CYRILLIC
CAPITAL LETTER ES            -> CYRILLIC SMALL LETTER ES
+            case '\u1C84' -> '\u0442';    //  U+1C84 -> U+0422 -> U+0442
   CYRILLIC SMALL LETTER TALL TE                         -> CYRILLIC
CAPITAL LETTER TE            -> CYRILLIC SMALL LETTER TE
+            case '\u1C85' -> '\u0442';    //  U+1C85 -> U+0422 -> U+0442
   CYRILLIC SMALL LETTER THREE-LEGGED TE                 -> CYRILLIC
CAPITAL LETTER TE            -> CYRILLIC SMALL LETTER TE
+            case '\u1C86' -> '\u044A';    //  U+1C86 -> U+042A -> U+044A
   CYRILLIC SMALL LETTER TALL HARD SIGN                  -> CYRILLIC
CAPITAL LETTER HARD SIGN     -> CYRILLIC SMALL LETTER HARD SIGN
+            case '\u1C87' -> '\u0463';    //  U+1C87 -> U+0462 -> U+0463
   CYRILLIC SMALL LETTER TALL YAT                        -> CYRILLIC
CAPITAL LETTER YAT           -> CYRILLIC SMALL LETTER YAT
+            case '\u1C88' -> '\uA64B';    //  U+1C88 -> U+A64A -> U+A64B
   CYRILLIC SMALL LETTER UNBLENDED UK                    -> CYRILLIC
CAPITAL LETTER MONOGRAPH UK  -> CYRILLIC SMALL LETTER MONOGRAPH UK
+            case '\u1E9B' -> '\u1E61';    //  U+1E9B -> U+1E60 -> U+1E61
   LATIN SMALL LETTER LONG S WITH DOT ABOVE              -> LATIN CAPITAL
LETTER S WITH DOT ABOVE -> LATIN SMALL LETTER S WITH DOT ABOVE
+            case '\u1FBE' -> '\u03B9';    //  U+1FBE -> U+0399 -> U+03B9
   GREEK PROSGEGRAMMENI                                  -> GREEK CAPITAL
LETTER IOTA             -> GREEK SMALL LETTER IOTA
+                                          //  --------------------------

 -------------------------------------------------------------------------------------------------------------------------------------
+        //  All other case-sensitive code-points are either uppercase (in
which case they are changed
+        //  below), or lowercase already (in which case they are not).
Therefore, only "toLowerCase"
+        //  is necessary. Code-units and case-insensitive code-points are
unchanged by "toLowerCase".
+            default -> Character.toLowerCase(codePointB);
+        };
     }

     public static int compareToCI_Latin1(byte[] value, byte[] other) {
@@ -780,10 +1141,35 @@
         }
         return new String(result, UTF16);
     }
-
-    public static boolean regionMatchesCI(byte[] value, int toffset,
-                                          byte[] other, int ooffset, int
len) {
-        return compareToCIImpl(value, toffset, len, other, ooffset, len)
== 0;
+
+    /**
+     * Tests case-insensitive equality of UTF-16 sequences in {@code byte}
array subsections.
+     * Performs {@linkplain #compareCodePointsIgnoringCase case
conversions equivalent to
+     *
<code>Character.toLowerCase(Character.toUpperCase(codePoint))</code>}
before comparing
+     * unequal code-points.
+     *
+     * @param charsA      array of byte pairs representing 16-bit ({@code
char}) quantities,
+     *                    with byte order mandated by {@code
StringUTF16.isBigEndian()}
+     * @param charsAIndex index, in 16-bit quantities, at which comparison
of "{@code charsA}"
+     *                    begins. Caller must enforce constraints "{@code
0 <= charsAIndex}"
+     *                    and "{@code 0 <= charsAIndex + totalChars <=
charsA.length / 2}".
+     * @param charsB      array of byte pairs representing 16-bit ({@code
char}) quantities,
+     *                    with byte order mandated by {@code
StringUTF16.isBigEndian()}
+     * @param charsBIndex index, in 16-bit quantities, at which comparison
of "{@code charsB}"
+     *                    begins. Caller must enforce constraints "{@code
0 <= charsBIndex}"
+     *                    and "{@code 0 <= charsBIndex + totalChars <=
charsB.length / 2}".
+     * @param totalChars  maximum number of {@code char}s to compare.
Caller must enforce
+     *                    constraint "{@code 0 <= totalChars}".
+     *
+     * @return {@code true} if the tested portions of {@code charsA} and
{@code charsB} are
+     * case-insensitively equal, otherwise {@code false}
+     */
+    static boolean regionMatchesCI
+    (
+        final byte[] charsA, final int charsAIndex,
+        final byte[] charsB, final int charsBIndex, final int totalChars
+    ){
+        return compareToCI(charsA, charsAIndex, charsB, charsBIndex,
totalChars) == 0;
     }

     public static boolean regionMatchesCI_Latin1(byte[] value, int toffset,

From chriswjohnson.jdk at gmail.com  Tue Mar 30 23:45:11 2021
From: chriswjohnson.jdk at gmail.com (Chris Johnson)
Date: Tue, 30 Mar 2021 18:45:11 -0500
Subject: Proposed: StringUTF16 bug fix with optimization - Part 2 of 2,
 Unit Tests
Message-ID: <CAPcpk_syCgR4KxSOGhR9NMUuEoov=vte1Xdx-_AEqydQLo519w@mail.gmail.com>

This is a patch for test class "CompareIC", providing 100% unit test
coverage of the fixed "java.lang.StringUTF16" methods "compareToCI" and
"regionMatchesCI" in part 1 of this proposed contribution.

The tests also provide 100% coverage of the current implementations of
those methods, and, if run against them, will reveal the pair of small
bugs detailed in part 1.

These tests fill a JDK test coverage gap that allowed the lack of
support for case-insensitive comparison and equality testing of strings
containing case-sensitive Supplementary Multilingual Plane code-points
to (apparently) go unnoticed officially until last year.

As such, these tests are of value to the JDK even if my proposed
revisions of "compareToCI" and "regionMatchesCI" are unacceptable.

Thanks again for your consideration,

----Chris

Chris W. Johnson
chriswjohnson.jdk at gmail.com
http://www.panojohnson.com/






Index: test/jdk/java/lang/String/CompareIC.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>US-ASCII
===================================================================
diff --git a/test/jdk/java/lang/String/CompareIC.java
b/test/jdk/java/lang/String/CompareIC.java
--- a/test/jdk/java/lang/String/CompareIC.java (revision
60819:ee1d592a9f5389725a0338a4b5dfcf4fc3fcf20c)
+++ b/test/jdk/java/lang/String/CompareIC.java (revision
60819+:ee1d592a9f53+)
@@ -24,41 +24,1544 @@
 /*
  * @test
  * @bug 4124769 8160312
- * @summary Test ignore-case comparison
- *
+ * @summary Test case-insensitive comparison and equality
+ * @run testng/othervm -XX:+CompactStrings CompareIC
+ * @run testng/othervm -XX:-CompactStrings CompareIC
  */

-import java.net.*;
-import java.io.InputStream;
+
+import static org.testng.Assert.assertEquals;
+import static org.testng.Assert.fail;
+
+import org.testng.annotations.Test;
+
 import java.io.IOException;
+import java.io.UncheckedIOException;
+import java.util.Arrays;
+import java.util.Formatter;
+import java.util.function.BiFunction;
+import java.util.function.IntFunction;
+import java.util.function.Predicate;

+
+/**
+ * <p>{@code CompareIC} provides generalized unit tests of {@link String}
methods {@link String#equalsIgnoreCase
+ * equalsIgnoreCase} and {@link String#compareToIgnoreCase
compareToIgnoreCase} with an emphasis on exercising
+ * underlying methods {@code java.lang.StringUTF16#compareToCI} and {@code
java.lang.StringUTF16#regionMatchesCI}.
+ * It also:
+ * </p>
+ * <ul>
+ *     <li>Tests every case-sensitive Unicode code-point for equality to
each of its case variants, using
+ *     both {@link #equalsIgnoreCase} and {@link #compareToIgnoreCase}.
+ *     </li>
+ *     <li>Provides 100% test coverage of the CWJ implementations of
{@code StringUTF16} methods {@code
+ *     compareToCI}, {@code regionMatchesCI} and {@code
compareCodePointsIgnoringCase}.
+ *     </li>
+ *     <li>Tests all premises underlying the CWJ implementations of {@code
StringUTF16} methods {@code
+ *     compareToCI}, {@code regionMatchesCI} and {@code
compareCodePointsIgnoringCase}.
+ *     </li>
+ *     <li>Converts to separate TestNG unit tests the legacy test code
from the 2016-06-27 commit. (Those
+ *     tests provide no additional coverage, so they are preserved only
for completeness.)
+ *     </li>
+ * </ul>
+ * <p>All tests operate by invoking local instance methods {@link
#equalsIgnoreCase} and {@link #compareToIgnoreCase},
+ * which may be overridden to apply these tests to any class supplying
equivalent functionality. This has been
+ * useful, for example, while developing and benchmarking optimized
implementations of {@code StringUTF16} methods
+ * {@code regionMatchesCI} and {@code compareToCI} outside the JDK code
base. If doing so, be aware of other
+ * methods intended to be overridden:
+ * </p>
+ * <p><b>General</b></p>
+ * <ul>
+ *     <li>{@link #getTestedClassFQN()}</li>
+ * </ul>
+ * <p><b>EqualsIgnoreCase</b></p>
+ * <ul>
+ *     <li>{@link #getEqualsIgnoreCaseMethodName()}</li>
+ *     <li>{@link #getEqualsIgnoreCaseFormatterString()}</li>
+ * </ul>
+ * <p><b>CompareToIgnoreCase</b></p>
+ * <ul>
+ *     <li>{@link #getCompareToIgnoreCaseMethodName()}</li>
+ *     <li>{@link #getCompareToIgnoreCaseFormatterString()}</li>
+ * </ul>
+ * <p>The tests will function whether or not those methods are overridden,
+ * but overriding them improves error message readability.
+ * </p>
+ */
+ at SuppressWarnings({ "UseOfSystemOutOrSystemErr",
"DuplicateStringLiteralInspection" })
 public class CompareIC {
-
-    public static void main(String[] args) throws Exception {
-        String test1 = "Tess";
-        String test2 = "Test";
-        String test3 = "Tesu";
-        CompareIC comparer = new CompareIC();
-
-        comparer.testTriplet(test1, test2, test3);
+
+    /**
+     * <p>Gets tested class's fully qualified name (FQN) for use in
messages generated by these tests.
+     * </p>
+     * <p>By default, returns "java.lang.String". Intended to be
overridden when this class is used
+     * outside the JDK-proper while, for example, developing and
benchmarking optimized implementations
+     * of methods "{@code regionMatchesCI}" and "{@code compareToCI}" from
"java.lang.StringUTF16".
+     * </p>
+     *
+     * @return fully qualified name of tested class
+     *
+     * @see #getEqualsIgnoreCaseMethodName()
+     * @see #getCompareToIgnoreCaseMethodName()
+     */
+    public String getTestedClassFQN() {
+        return String.class.getName();
+    }
+
+    /**
+     * Gets name of case-insensitive equality method being tested.
+     *
+     * @return case-insensitive equality method's name, for example {@code
"equalsIgnoreCase"}
+     *
+     * @see #getEqualsIgnoreCaseFormatterString()
+     */
+    public String getEqualsIgnoreCaseMethodName() {
+        return "equalsIgnoreCase";
+    }
+
+    /**
+     * <p>Gets format string suitable for use by {@link
Formatter#format(String, Object...)} to create a text
+     * representation of an "equalsIgnoreCase" (or equivalent) invocation.
When this format is used, the {@code
+     * format} method is passed the following parameters:
+     * </p>
+     * <ol>
+     *     <li>{@code String} - First compared {@code String}, converted
to string literal format.</li>
+     *     <li>{@code int} - {@code char} offset, into first compared
{@code String}, at which comparison was to begin.</li>
+     *     <li>{@code int} - Number of {@code char}s used, starting at
offset above, from first compared {@code String}.</li>
+     *     <li>{@code String} - Second compared {@code String}, converted
to string literal format.</li>
+     *     <li>{@code int} - {@code char} offset, into second compared
{@code String}, at which comparison was to begin.</li>
+     *     <li>{@code int} - Number of {@code char}s used, starting at
offset above, from second compared {@code String}.</li>
+     * </ol>
+     * <p>For an invocation of {@link String#equalsIgnoreCase(String)},
the format string would be {@code "%s.equalsIgnoreCase(%4$)"}.
+     * Most of the {@code format} parameters are irrelevant in most cases
(and parameter 3 makes redundant parameter 6 in almost
+     * any case), but these parameters should allow representation of
almost any method invocation.
+     * </p>
+     *
+     * @return {@link Formatter} format string used to create a text
representation of an "equalsIgnoreCase" (or equivalent)
+     * invocation, including all of its parameters
+     *
+     * @see #getEqualsIgnoreCaseMethodName()
+     */
+    public String getEqualsIgnoreCaseFormatterString() {
+        return "%1$s." + getEqualsIgnoreCaseMethodName() + "(%4$s)";
+    }
+
+    /**
+     * Gets name of case-insensitive comparison method being tested.
+     *
+     * @return case-insensitive comparison method's name, for example
{@code "compareToIgnoreCase"}
+     *
+     * @see #getCompareToIgnoreCaseFormatterString()
+     */
+    public String getCompareToIgnoreCaseMethodName() {
+        return "compareToIgnoreCase";
+    }
+
+    /**
+     * <p>Gets format string suitable for use by {@link
Formatter#format(String, Object...)} to create a text
+     * representation of a "compareToIgnoreCase" (or equivalent)
invocation. When this format is used, the {@code
+     * format} method is passed the following parameters:
+     * </p>
+     * <ol>
+     *     <li>{@code String} - First compared {@code String}, converted
to string literal format.</li>
+     *     <li>{@code int} - {@code char} offset, into first compared
{@code String}, at which comparison was to begin.</li>
+     *     <li>{@code int} - Number of {@code char}s used, starting at
offset above, from first compared {@code String}.</li>
+     *     <li>{@code String} - Second compared {@code String}, converted
to string literal format.</li>
+     *     <li>{@code int} - {@code char} offset, into second compared
{@code String}, at which comparison was to begin.</li>
+     *     <li>{@code int} - Number of {@code char}s used, starting at
offset above, from second compared {@code String}.</li>
+     * </ol>
+     * <p>For an invocation of {@link String#compareToIgnoreCase(String)},
the format string would be {@code "%s.compareToIgnoreCase(%4$)"}.
+     * Most of the {@code format} parameters are irrelevant in most cases
(and parameter 3 makes redundant parameter 6 in almost
+     * any case), but these parameters should allow representation of
almost any method invocation.
+     * </p>
+     *
+     * @return {@link Formatter} format string used to create a text
representation of a "compareToIgnoreCase" (or equivalent)
+     * invocation, including all of its parameters
+     *
+     * @see #getCompareToIgnoreCaseMethodName()
+     */
+    public String getCompareToIgnoreCaseFormatterString() {
+        return "%1$s." + getCompareToIgnoreCaseMethodName() + "(%4$s)";
+    }
+
+    /**
+     * <p>Evaluates case-insensitive equality of two strings.
+     * </p>
+     * <p>By default, uses parameters "{@code a}" and "{@code b}" in
invocation "{@code a.equalsIgnoreCase(b)}".
+     * Intended to be overridden when this class is used outside the
JDK-proper while, for example, developing
+     * and benchmarking optimized implementations of "{@code
java.lang.StringUTF16.regionMatchesCI}".
+     * </p>
+     *
+     * @param a one string to test
+     * @param b the other string to test
+     *
+     * @return {@code true} if the strings were equal (exactly or
case-insensitively), {@code false} otherwise
+     *
+     * @see #getEqualsIgnoreCaseMethodName()
+     * @see #getTestedClassFQN()
+     */
+    public boolean equalsIgnoreCase
+    (
+        final String            a,
+        final String            b
+    ){
+        return a.equalsIgnoreCase(b);
+    }
+
+    /**
+     * <p>Compares two strings case-insensitively.
+     * </p>
+     * <p>By default, uses parameters "{@code a}" and "{@code b}" in
invocation "{@code a.compareToIgnoreCase(b)}".
+     * Intended to be overridden when this class is used outside the
JDK-proper while, for example, developing and
+     * benchmarking optimized implementations of "{@code
java.lang.StringUTF16.compareToCI}".
+     * </p>
+     *
+     * @param a basis of the comparison, as if invoking {@code
a.compareToIgnoreCase(b)}
+     * @param b {@code String} to which {@code a} is compared
+     *
+     * @return negative value when {@code a < b}, zero when {@code a}
equals {@code b},
+     * or positive value when {@code a > b}
+     *
+     * @see #getCompareToIgnoreCaseMethodName()
+     * @see #getTestedClassFQN()
+     */
+    public int compareToIgnoreCase
+    (
+        final String            a,
+        final String            b
+    ){
+        return a.compareToIgnoreCase(b);
+    }
+
+    /**
+     * Legacy test for <a href="
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8160312">bug
8160312</a>.
+     */
+    @Test
+    public void compareToIgnoreCase_MicroSignGreaterThanX() {
+
+    //  Code-point U+00B5 is the "MICRO SIGN" character from Unicode's
ISO-8859-1 range.
+    //  Code-point U+0058 is the "LATIN CAPITAL LETTER X" character from
Unicode's US-ASCII range.
+
+        if (compareToIgnoreCase("\u00b5", "X") <= 0)
+            fail("Comparison failure 1 for bug 8160312.");
+    }
+
+    /**
+     * Legacy test for <a href="
https://bugs.java.com/bugdatabase/view_bug.do?bug_id=4124769">bug
4124769</a>.
+     */
+    @SuppressWarnings("StringToUpperCaseOrToLowerCaseWithoutLocale")
+    @Test
+    public void compareToIgnoreCase_Triplets() {
+        final String test1 = "Tess";
+              String test2 = "Test";
+        final String test3 = "Tesu";
+
+        testTriplet(test1, test2, test3);
         test2 = test2.toUpperCase();
-        comparer.testTriplet(test1, test2, test3);
+        testTriplet(test1, test2, test3);
         test2 = test2.toLowerCase();
-        comparer.testTriplet(test1, test2, test3);
-
-        // toLowerCase -> non-latin1
-        if ("\u00b5".compareToIgnoreCase("X") < 0)
-            throw new RuntimeException("Comparison failure1");
-    }
-
-    private void testTriplet(String one, String two, String three)
-        throws Exception {
-            if (one.compareToIgnoreCase(two) > 0)
-                throw new RuntimeException("Comparison failure1");
-            if (two.compareToIgnoreCase(three) > 0)
-                throw new RuntimeException("Comparison failure2");
-            if (three.compareToIgnoreCase(one) < 0)
-                throw new RuntimeException("Comparison failure3");
+        testTriplet(test1, test2, test3);
+    }
+
+    /**
+     * Compares a trio of strings for legacy test {@link
#compareToIgnoreCase_Triplets}.
+     *
+     * @param one   string used by test comparisons
+     * @param two   string used by test comparisons
+     * @param three string used by test comparisons
+     */
+    @SuppressWarnings("SameParameterValue")
+    private void testTriplet(final String one, final String two, final
String three) {
+
+        if (compareToIgnoreCase(one, two) > 0)
+            fail("Comparison failure 1 for bug 4124769.");
+        if (compareToIgnoreCase(two, three) > 0)
+            fail("Comparison failure 2 for bug 4124769.");
+        if (compareToIgnoreCase(three, one) < 0)
+            fail("Comparison failure 3 for bug 4124769.");
+    }
+
+    @Test
+    public void testStringsOfEqualLength() {
+
+    //  Note: Full-width latin letters (uppercase U+FF21 to U+FF3A, and
lowercase
+    //        U+FF41 to U+FF5A) are case-insensitively equal to each
other, but
+    //        not to their ASCII counterparts.
+
+    //  Test equal-length strings exhibiting case-insensitive equality.
+
+        testEqualStringsIC("\uFF21",                   "\uFF41"
       );  // "A" vs. "a".
+        testEqualStringsIC("\uFF21\uFF22",             "\uFF41\uFF42"
       );  // "AB" vs. "ab".
+        testEqualStringsIC("\uFF21\uFF22\uFF23",
"\uFF41\uFF42\uFF43"      );  // "ABC" vs. "abc".
+        testEqualStringsIC("\uFF21\uFF22\uFF23\uFF24",
"\uFF41\uFF42\uFF43\uFF44");  // "ABCD" vs. "abcd".
+        testEqualStringsIC("\uFF21\uFF22\uFF23\uFF24", new
String("\uFF21\uFF22\uFF23\uFF24".toCharArray()));  // Test identical
strings ("ABCD") without "String" object reference equality interfering.
+
+    //  Test equal-length strings exhibiting case-insensitive inequality.
+
+        testUnequalStringsIC("\uFF21\uFF22cd",
"\uFF41\uFF42\uFF43\uFF44");  // "ABcd" vs. "abcd".
+    }
+
+    @Test
+    public void testStringsOfUnequalLength() {
+
+    //  Note: Full-width latin letters (uppercase U+FF21 to U+FF3A, and
lowercase
+    //        U+FF41 to U+FF5A) are case-insensitively equal to each
other, but
+    //        not to their ASCII counterparts.
+
+    //  Test strings whose overlapping portions are equal, so
+    //  inequality emerges only from their length difference.
+
+        testUnequalStringsIC("\uFF21\uFF22\uFF23\uFF24",
"\uFF41\uFF42\uFF43\uFF44\uFF45");  // "ABCD" vs. "abcde".
+        testUnequalStringsIC("\uFF41\uFF42\uFF43\uFF44",
"\uFF21\uFF22\uFF23\uFF24\uFF25");  // "abcd" vs. "ABCDE".
+
+
+    //  Test strings whose overlapping portions are unequal, so
+    //  inequality originates in the comparison of their overlap,
+    //  rather than their length difference.
+
+        testUnequalStringsIC("\uFF41\uFF42\uFF43\uFF44\uFF45",
"\uFF21\uFF22\uFF23\uFF38");  // "abcde" vs. "ABCX".
+
+        testUnequalStringsIC("\uFF21\uFF22\uFF23\uFF24",
"\uFF41\uFF42\uFF43\uFF58\uFF59\uFF5A");  // "ABCD" vs. "abcxyz".
+        testUnequalStringsIC("\uFF41\uFF42\uFF43\uFF44",
"\uFF21\uFF22\uFF23\uFF38\uFF39\uFF3A");  // "abcd" vs. "ABCXYZ".
+    }
+
+    @Test
+    public void testUnpairedSurrogates_HighVsHigh() {
+        testUnpairedSurrogates("\uD800", "\uDBFF");
+    }
+
+    @Test
+    public void testUnpairedSurrogates_LowVsLow() {
+        testUnpairedSurrogates("\uDC00", "\uDFFF");
+    }
+
+    @Test
+    public void testUnpairedSurrogates_HighVsLow() {
+        testUnpairedSurrogates("\uD800", "\uDC00");
+    }
+
+    private void testUnpairedSurrogates
+    (
+        final String            unpairedSurrogateLesser,
+        final String            unpairedSurrogateGreater
+    ){
+        testUnequalStringsIC(      unpairedSurrogateLesser      ,
unpairedSurrogateGreater      );
+        testUnequalStringsIC("0" + unpairedSurrogateLesser      , "0" +
unpairedSurrogateGreater      );
+        testUnequalStringsIC(      unpairedSurrogateLesser + "1",
unpairedSurrogateGreater + "1");
+        testUnequalStringsIC("0" + unpairedSurrogateLesser + "2", "0" +
unpairedSurrogateGreater + "2");
+
+    //  Compare unpaired surrogate with greater and lesser 16-bit BMP
code-points.
+
+        testUnequalStringsIC("0" + unpairedSurrogateLesser + "2",
"0\uFF112");
+        testUnequalStringsIC("0\u20812", "0" + unpairedSurrogateLesser +
"2");
+    }
+
+    @Test
+    public void testSurrogatePairs_UnequalHighVsEqualLow() {
+        testUnequalStringsIC("\uD800\uDC00", "\uD801\uDC00");
+    }
+
+    @Test
+    public void testSurrogatePairs_EqualHighVsUnequalLow() {
+        testUnequalStringsIC("\uD800\uDC00", "\uD800\uDC01");
+    }
+
+    @Test
+    public void testSurrogatePairs_EqualHighVsInvalidLow() {
+
+    //  One invalid low-surrogate.
+
+        testUnequalStringsIC("\uD800\uBAD1", "\uD800\uDC00");
+
+    //  Two invalid low-surrogates.
+
+        testUnequalStringsIC("\uD800\uBAD1", "\uD800\uBAD2");
+    }
+
+    private void testEqualStringsIC
+    (
+        @SuppressWarnings("SameParameterValue")
+        final String            stringA,  // String case-insensitively
equal to "stringB".
+        final String            stringB   // String case-insensitively
equal to "stringA".
+    ){
+        try (
+            final Formatter         error = new Formatter(new
StringBuilder(0))  // If the test succeeds, this "StringBuilder" remains
zero-length.
+        ){
+
+        //  Test comparison, as used in sorting.
+        //
+        //  These tests fail if "stringA" is not identified by
+        //  "compareToIgnoreCase" as equal to "stringB".
+
+            {
+                int                     signum;
+
+                signum = compareToIgnoreCase(stringA, stringB);
+                if (signum != 0) {
+
+                    error.format(
+                        "%n    * Method %s.",
+                        getTestedClassFQN()
+                    ).format(
+                        getCompareToIgnoreCaseFormatterString(),
+                        /* 1 */ StringLiteral.from(stringA),
+                        /* 2 */ 0,
+                        /* 3 */ stringA.length(),
+                        /* 4 */ StringLiteral.from(stringB),
+                        /* 5 */ 0,
+                        /* 6 */ stringB.length()
+                    ).format(
+                        " returned %d instead of zero.",
+                        signum
+                    );
+                }
+
+                signum = compareToIgnoreCase(stringB, stringA);
+                if (signum != 0) {
+
+                    error.format(
+                        "%n    * Method %s.",
+                        getTestedClassFQN()
+                    ).format(
+                        getCompareToIgnoreCaseFormatterString(),
+                        /* 1 */ StringLiteral.from(stringB),
+                        /* 2 */ 0,
+                        /* 3 */ stringB.length(),
+                        /* 4 */ StringLiteral.from(stringA),
+                        /* 5 */ 0,
+                        /* 6 */ stringA.length()
+                    ).format(
+                        " returned %d instead of zero.",
+                        signum
+                    );
+                }
+            }
+
+        //  Test equality testing.
+        //
+        //  These tests fail if "equalsIgnoreCase" returns "false".
+
+            if (!equalsIgnoreCase(stringA, stringB)) {
+
+                error.format(
+                    "%n    * Method %s.",
+                    getTestedClassFQN()
+                ).format(
+                    getEqualsIgnoreCaseFormatterString(),
+                    /* 1 */ StringLiteral.from(stringA),
+                    /* 2 */ 0,
+                    /* 3 */ stringA.length(),
+                    /* 4 */ StringLiteral.from(stringB),
+                    /* 5 */ 0,
+                    /* 6 */ stringB.length()
+                ).format(
+                    " returned \"false\" instead of \"true\"."
+                );
+            }
+
+            if (!equalsIgnoreCase(stringB, stringA)) {
+
+                error.format(
+                    "%n    * Method %s.",
+                    getTestedClassFQN()
+                ).format(
+                    getEqualsIgnoreCaseFormatterString(),
+                    /* 1 */ StringLiteral.from(stringB),
+                    /* 2 */ 0,
+                    /* 3 */ stringB.length(),
+                    /* 4 */ StringLiteral.from(stringA),
+                    /* 5 */ 0,
+                    /* 6 */ stringA.length()
+                ).format(
+                    " returned \"false\" instead of \"true\"."
+                );
+            }
+
+        //  If the "StringBuilder" used by "error" is not empty, one or
more tests failed, so invoke "fail".
+
+            error.flush();
+
+            if (!((CharSequence) error.out()).isEmpty()) {
+
+                fail(
+                    "testEqualStringsIC(" + StringLiteral.from(stringA) +
+                    ", " + StringLiteral.from(stringB) + ") found test
failure(s):" +
+                    error
+                );
+            }
+        }
+    }
+
+    private void testUnequalStringsIC
+    (
+        @SuppressWarnings("SameParameterValue")
+        final String            stringLesser,  // String
case-insensitively less than "stringGreater".
+        final String            stringGreater  // String
case-insensitively greater than "stringLesser".
+    ){
+        try (
+            final Formatter         error = new Formatter(new
StringBuilder(0))  // If the test succeeds, this "StringBuilder" remains
zero-length.
+        ){
+
+        //  Test comparison, as used in sorting.
+        //
+        //  These tests fail if "stringLesser" is not identified by
+        //  "compareToIgnoreCase" as less than "stringGreater".
+
+            {
+                int                     signum;
+
+                signum = compareToIgnoreCase(stringLesser, stringGreater);
+                if (signum >= 0) {
+
+                    error.format(
+                        "%n    * Method %s.",
+                        getTestedClassFQN()
+                    ).format(
+                        getCompareToIgnoreCaseFormatterString(),
+                        /* 1 */ StringLiteral.from(stringLesser),
+                        /* 2 */ 0,
+                        /* 3 */ stringLesser.length(),
+                        /* 4 */ StringLiteral.from(stringGreater),
+                        /* 5 */ 0,
+                        /* 6 */ stringGreater.length()
+                    ).format(
+                        " returned %d instead of a negative value.",
+                        signum
+                    );
+                }
+
+                signum = compareToIgnoreCase(stringGreater, stringLesser);
+                if (signum <= 0) {
+
+                    error.format(
+                        "%n    * Method %s.",
+                        getTestedClassFQN()
+                    ).format(
+                        getCompareToIgnoreCaseFormatterString(),
+                        /* 1 */ StringLiteral.from(stringGreater),
+                        /* 2 */ 0,
+                        /* 3 */ stringGreater.length(),
+                        /* 4 */ StringLiteral.from(stringLesser),
+                        /* 5 */ 0,
+                        /* 6 */ stringLesser.length()
+                    ).format(
+                        " returned %d instead of a positive value.",
+                        signum
+                    );
+                }
+            }
+
+        //  Test equality testing.
+        //
+        //  (As this method's name makes clear, its inputs must be
case-insensitively *unequal*,
+        //  so these tests fail if "equalsIgnoreCase" returns "true".)
+
+            if (equalsIgnoreCase(stringLesser, stringGreater)) {
+
+                error.format(
+                    "%n    * Method %s.",
+                    getTestedClassFQN()
+                ).format(
+                    getEqualsIgnoreCaseFormatterString(),
+                    /* 1 */ StringLiteral.from(stringLesser),
+                    /* 2 */ 0,
+                    /* 3 */ stringLesser.length(),
+                    /* 4 */ StringLiteral.from(stringGreater),
+                    /* 5 */ 0,
+                    /* 6 */ stringGreater.length()
+                ).format(
+                    " returned \"true\" instead of \"false\"."
+                );
+            }
+
+            if (equalsIgnoreCase(stringGreater, stringLesser)) {
+
+                error.format(
+                    "%n    * Method %s.",
+                    getTestedClassFQN()
+                ).format(
+                    getEqualsIgnoreCaseFormatterString(),
+                    /* 1 */ StringLiteral.from(stringGreater),
+                    /* 2 */ 0,
+                    /* 3 */ stringGreater.length(),
+                    /* 4 */ StringLiteral.from(stringLesser),
+                    /* 5 */ 0,
+                    /* 6 */ stringLesser.length()
+                ).format(
+                    " returned \"true\" instead of \"false\"."
+                );
+            }
+
+        //  If the "StringBuilder" used by "error" is not empty, one or
more tests failed, so invoke "fail".
+
+            error.flush();
+
+            if (!((CharSequence) error.out()).isEmpty()) {
+
+                fail(
+                    "testUnequalStringsIC(" +
StringLiteral.from(stringLesser) +
+                    ", " + StringLiteral.from(stringGreater) + ") found
test failure(s):" +
+                    error
+                );
+            }
+        }
+    }
+
+    @Test
+    public void
allCodePointsDifferingOnlyInCaseAreEqual_equalsIgnoreCase() {
+
+    //  If the test
"validatePremise_AllSMPCodePointCaseVariantsAreSMPCodePoints",
+    //  or
"validatePremise_AllSMPCodePointCaseVariantsUseTheSameHighSurrogate",
+    //  reports, for example:
+    //
+    //      "Of 1,048,576 SMP code-points, 450 are assigned, public and
affected
+    //      by case-conversion."
+    //
+    //  ...then expect a total failure of this test to report 225 errors
(450/2),
+    //  because errors unaffected by parameter order are reported only on
their
+    //  first occurrence (assuming the test's code-point loop operates in
ascending
+    //  order).
+    //
+    //  That expectation would not apply if a case conversion error
occurred among
+    //  the Basic Multilingual Plane code-points, but that has not been an
issue,
+    //  historically.
+
+        testAllAssignedPublicCodePointsForCaseInsensitiveEquality(
+            getTestedClassFQN(),
+            getEqualsIgnoreCaseMethodName(),
+            getEqualsIgnoreCaseFormatterString() + " returned \"%10$s\",
not \"true\"",
+            this::equalsIgnoreCase,
+        //  No result conversion needed. If "equalsIgnoreCase" works as
expected,
+        //  "true" is returned. If "false" is returned, something went
wrong.
+            r -> r
+        );
+    }
+
+    @Test
+    public void
allCodePointsDifferingOnlyInCaseAreEqual_compareToIgnoreCase() {
+
+    //  If the test
"validatePremise_AllSMPCodePointCaseVariantsAreSMPCodePoints",
+    //  or
"validatePremise_AllSMPCodePointCaseVariantsUseTheSameHighSurrogate",
+    //  reports, for example:
+    //
+    //      "Of 1,048,576 SMP code-points, 450 are assigned, public and
affected
+    //      by case-conversion."
+    //
+    //  ...then expect a total failure of this test to report 225 errors
(450/2),
+    //  because errors unaffected by parameter order are reported only on
their
+    //  first occurrence (assuming the test's code-point loop operates in
ascending
+    //  order).
+    //
+    //  That expectation would not apply if a case conversion error
occurred among
+    //  the Basic Multilingual Plane code-points, but that has not been an
issue,
+    //  historically.
+
+        testAllAssignedPublicCodePointsForCaseInsensitiveEquality(
+            getTestedClassFQN(),
+            getCompareToIgnoreCaseMethodName(),
+            getCompareToIgnoreCaseFormatterString() + " returned %10$s,
not 0",
+            this::compareToIgnoreCase,
+        //  Convert the result to a boolean. If "compareToIgnoreCase"
works as expected,
+        //  zero is returned, and this function converts it to "true". If
a non-zero value
+        //  is returned, something went wrong, and this function converts
it to "false".
+            r -> r == 0
+        );
+    }
+
+    private static <R> void
testAllAssignedPublicCodePointsForCaseInsensitiveEquality
+    (
+        final String                        testedClassName,
+        final String                        testedMethodName,
+        final String
 testMethodInvocationFailureFormat,
+        final BiFunction<String,String,R>   testFunction,
+        final Predicate<R>                  testResultValidator
+    ){
+        final String            toUcFormat     = "%n    U+%7$04X -
Character.toUpperCase(0x%8$04X) returned code-point U+%9$04X, but " +
testMethodInvocationFailureFormat + '.';
+        final String            toLcFormat     = "%n    U+%7$04X -
Character.toLowerCase(0x%8$04X) returned code-point U+%9$04X, but " +
testMethodInvocationFailureFormat + '.';
+        final String            toLcToUcFormat = "%n    U+%7$04X -
Character.toLowerCase(Character.toUpperCase(0x%8$04X)) returned code-point
U+%9$04X, but " + testMethodInvocationFailureFormat + '.';
+
+        try (
+            final Formatter         error    = new Formatter(new
StringBuilder(0))  // If the test succeeds, this "StringBuilder" remains
zero-length.
+        ){
+            int                     failures = 0;
+
+        //  Examine *every* Unicode code-point.
+
+            for (int codePoint = Character.MIN_CODE_POINT; codePoint <=
Character.MAX_CODE_POINT; codePoint++) {
+                final int               codePointType =
Character.getType(codePoint);
+
+            //  Skip this code-point/-unit, if case is irrelevant to its
type (Unicode category).
+
+                if (codePointType == Character.UNASSIGNED || codePointType
== Character.PRIVATE_USE || codePointType == Character.SURROGATE)
+                    continue;
+
+            //  Replicate both conversions potentially performed by
case-insensitive comparison:
+            //      1. Convert the code-point to uppercase.
+            //      2. Convert the uppercase code-point to lowercase.
+
+                final int               codePointUc =
Character.toUpperCase(codePoint  );
+                final int               codePointLc =
Character.toLowerCase(codePointUc);
+
+            //  Skip this code-point, if neither case-conversion affected
it.
+
+                if (codePoint == codePointUc && codePointUc == codePointLc)
+                    continue;
+
+            //  KNOWN: "codePoint" is not equal to one or both of
"codePointUc" and "codePointLc".
+            //         Therefore, "codePoint" has upper- and/or lower-case
counterparts, and is
+            //         suitable for the following case-insensitive
"String" equality validation tests.
+
+                if (codePoint != codePointUc) {
+
+                //  KNOWN: "codePoint" is lowercase, because
"toUpperCase(codePoint)" returned a different code-point.
+                //         Therefore test "codePoint" vs. "codePointUc".
+
+                    if
(!testMutualEqualityWithoutRedundantErrors(codePoint, testFunction,
testResultValidator, codePoint, codePointUc, error, toUcFormat))
+                        failures++;
+
+                    if (codePoint != codePointLc) {
+
+                    //  Triple-case code-point: There must be three
distinct forms of "codePoint" (including itself).
+                    //  This is very rare, and all examples are Basic
Multilingual Plane code-points, as of JDK 15.0.2
+                    //  and Unicode 13.0.0.
+
+                        if
(!testMutualEqualityWithoutRedundantErrors(codePoint, testFunction,
testResultValidator, codePointUc, codePointLc, error, toLcToUcFormat))
+                            failures++;
+                    }
+
+                } else {  // codePoint == codePointUc && codePointUc !=
codePointLc
+
+                //  KNOWN: "codePoint" is uppercase, because
"toUpperCase(codePoint)" returned it.
+                //         Therefore, test "codePoint" vs. "codePointLc".
+
+                    if
(!testMutualEqualityWithoutRedundantErrors(codePoint, testFunction,
testResultValidator, codePoint, codePointLc, error, toLcFormat))
+                        failures++;
+                }
+            }
+
+            if (failures != 0) {
+
+                error.format("%nTotal erroneous case-insensitive
code-point comparisons: %,d.", failures).flush();
+                fail("Method \"" + testedClassName + '.' +
testedMethodName + "\" erroneously reported differences between
case-insensitively equal code-points:" + error.out());
+            }
+        }
+    }
+
+    private static <R> boolean testMutualEqualityWithoutRedundantErrors
+    (
+        final int                           testCodePoint,       //
Code-point currently being tested by the caller's code-point loop, which
must operate in ascending order.
+        final BiFunction<String,String,R>   comparisonFunction,  //
Case-insensitive comparison function invoked with "String" representations
of "codePointA" and "codePointB" as its parameters (in that order, and
reversed).
+        final Predicate<R>                  resultIsEquality,    //
Function to examine "comparisonFunction" result, returning "true" if it
indicates equality, or "false" otherwise.
+        final int                           codePointA,          //
Code-point for equality test.
+        final int                           codePointB,          //
Code-point for equality test.
+        final Formatter                     out,                 //
"Formatter" to which an error report, if any, will be written.
+        final String                        failureFormat        //
"Formatter" format "String". Parameters: (1) "testCodePoint" or
"codePointA" in String literal format, (2) offset into "String" of
parameter 1 code-point [always 0],
+                                                                 // (3)
length of "String" of parameter 1 code-point [1 or 2], (4) "codePointB" in
String literal format, (5) offset into "String" of "codePointB" [always 0],
+    ){                                                           // (6)
length of "String" of "codePointB" [1 or 2], (7) "testCodePoint", (8)
parameter 1 code-point as "int", (9) "codePointB", and (10)
"comparisonFunction" return value.
+        if (codePointA != codePointB) {
+            final String            codePointAStr =
Character.toString(codePointA);
+            final String            codePointBStr =
Character.toString(codePointB);
+            final R                 compareResult =
comparisonFunction.apply(codePointAStr, codePointBStr);
+
+            if (!resultIsEquality.test(compareResult)) {  // If
"resultIsEquality" judged that "compareResult" indicates inequality...
+
+            //  Failure. However, report the failure only if (1) this
appears to be its first occurrence
+            //  (assuming the caller is testing code-points in ascending
order), or (2) "testCodePoint" is
+            //  a rare triple-case code-point, or (3) performing the same
test with parameters reversed
+            //  produces an inconsistent result.
+
+                if (testCodePoint <= codePointA && testCodePoint <=
codePointB                     // This is the first occurrence of this
particular failure, because the caller's ascending code-point loop has
reached neither "codePointA" nor "codePointB".
+                ||  testCodePoint != codePointA && testCodePoint !=
codePointB                     // "testCodePoint" must be one of the very
rare triple-case code-points. Always report errors associated with it.
+                ||
 resultIsEquality.test(comparisonFunction.apply(codePointBStr,
codePointAStr))  // Reversing the "comparisonFunction" parameters produced
a different result. Report the lack of mutual equality. (This could be
redundant.)
+                ){
+                //  Either this is the failure's first occurrence, or
"testCodePoint" is a triple-case code-
+                //  point, or the parameter-reversed test returned a
result different from the first test.
+
+                    if (testCodePoint == codePointA || testCodePoint ==
codePointB) {
+                        out.format(
+                            failureFormat,  // This is usually the
caller's "toLc" or "toUc" format. For example, respectively,
"Character.toLowerCase(0x%8$04X) == U+%9$04X" or
"Character.toUpperCase(0x%8$04X) == U+%9$04X".
+                            /*  1 */ StringLiteral.from(codePointA),
+                            /*  2 */ 0,
+                            /*  3 */ codePointLength(codePointA),
+                            /*  4 */ StringLiteral.from(codePointB),
+                            /*  5 */ 0,
+                            /*  6 */ codePointLength(codePointB),
+                            /*  7 */ testCodePoint,
+                            /*  8 */ codePointA,
+                            /*  9 */ codePointB,
+                            /* 10 */ compareResult
+                        );
+                    } else {  // if (testCodePoint != codePointA &&
testCodePoint != codePointB)...
+                        out.format(
+                            failureFormat,  // This should be the caller's
"toLcToUc" format. For example,
"Character.toLowerCase(Character.toUpperCase(0x%8$04X)) == U+%9$04X".
+                            /*  1 */ StringLiteral.from(testCodePoint),
+                            /*  2 */ 0,
+                            /*  3 */ codePointLength(testCodePoint),
+                            /*  4 */ StringLiteral.from(codePointB),
+                            /*  5 */ 0,
+                            /*  6 */ codePointLength(codePointB),
+                            /*  7 */ testCodePoint,
+                            /*  8 */ testCodePoint,
+                            /*  9 */ codePointB,
+                            /* 10 */ compareResult
+                        );
+                    }
+
+                    return false;  // The test failed, and this should be
the error's first occurrence.
+                }
+            }
+        }
+
+    //  The test was either unnecessary ("codePointA == codePointB"), or
successful, or deemed
+    //  a redundant failure to be ignored.
+
+        return true;
+    }
+
+    @Test
+    public void allTripleCaseCodePointsAreEqual_equalsIgnoreCase() {
+
+        testTripleCaseCodePointEquality(
+            getTestedClassFQN(),
+            "equalsIgnoreCase",
+            getEqualsIgnoreCaseFormatterString() + " returned \"%10$s\",
not \"true\"",
+            this::equalsIgnoreCase,
+            r -> r  // "true" (equality) is the correct answer, so return
"true" when "r" is "true", and "false" when "r" is "false".
+        );
+    }
+
+    @Test
+    public void allTripleCaseCodePointsAreEqual_compareToIgnoreCase() {
+
+        testTripleCaseCodePointEquality(
+            getTestedClassFQN(),
+            "compareToIgnoreCase",
+            getCompareToIgnoreCaseFormatterString() + " returned %10$s,
not 0",
+            this::compareToIgnoreCase,
+            r -> r == 0  // Zero (equality) is the correct answer. Return
"true" when "r" is zero.
+        );
+    }
+
+    private static <R> void testTripleCaseCodePointEquality
+    (
+        final String                        testedClassName,
+        final String                        testedMethodName,
+        final String                        testedMethodFormatterString,
+        final BiFunction<String,String,R>   testFunction,
+        final Predicate<R>                  testResultValidator
+    ){
+        try (
+            final Formatter         error = new Formatter(new
StringBuilder(0))  // If the test succeeds, this "StringBuilder" remains
zero-length.
+        ){
+        //  Test each of the triple-case code-points. (Other test methods
in this class test
+        //  these code-points, but they do not single-out these
code-points, or supply a bug's
+        //  probable fix.)
+
+            final String            toUcFormat           = "    U+%7$04X -
Character.toUpperCase(0x%8$04X) returned code-point U+%9$04X, but " +
testedMethodFormatterString + ".%n";
+            final String            toLcFormat           = "    U+%7$04X -
Character.toLowerCase(0x%8$04X) returned code-point U+%9$04X, but " +
testedMethodFormatterString + ".%n";
+            final String            toLcToUcFormatCpLc   = "    U+%7$04X -
Character.toLowerCase(Character.toUpperCase(0x%<04X)) returned code-point
U+%9$04X, but " + testedMethodFormatterString + ".%n";
+            final String            toLcToUcFormatLcCp   = "    U+%7$04X -
Character.toLowerCase(Character.toUpperCase(0x%<04X)) returned code-point
U+%8$04X, but " + testedMethodFormatterString + ".%n";
+            final int[]             tripleCaseCodePoints =
getTripleCaseCodePoints();
+            int                     failures             = 0;
+
+            for (final int codePoint : tripleCaseCodePoints) {
+                final int               codePointUc =
Character.toUpperCase(codePoint  );
+                final int               codePointLc =
Character.toLowerCase(codePointUc);
+
+                if (!testMutualEqualityWithoutRedundantErrors(codePoint,
testFunction, testResultValidator, codePoint,   codePointUc, error,
toUcFormat))
+                    failures++;
+                if (!testMutualEqualityWithoutRedundantErrors(codePoint,
testFunction, testResultValidator, codePointUc, codePointLc, error,
toLcFormat))
+                    failures++;
+                if (!testMutualEqualityWithoutRedundantErrors(codePoint,
testFunction, testResultValidator, codePoint,   codePointLc, error,
toLcToUcFormatCpLc))
+                    failures++;
+
+            //  Repeat the preceding test with the code-points reversed.
The repetition is necessary to
+            //  achieve full coverage of any implementation with a
"compareCodePointsIgnoringCase" method
+            //  using a pair of "switch" expressions (which should contain
identical "case" clauses).
+
+                if (!testMutualEqualityWithoutRedundantErrors(codePoint,
testFunction, testResultValidator, codePointLc, codePoint,   error,
toLcToUcFormatLcCp))
+                    failures++;
+            }
+
+            if (failures != 0) {
+
+                error.format("%nReplacement for \"switch\" expression in
\"StringUTF16.getCIComparisonCodePoint\":%n%n");
+                generateTripleCaseCodePointsSwitchExpression(error,
"Code-Point Progression by Name", Character::getName, tripleCaseCodePoints);
+            //  generateTripleCaseCodePointsSwitchExpression(error,
"Unicode Block Progression", Character.UnicodeBlock::of,
tripleCaseCodePoints);
+
+                error.flush();
+                fail(
+                    """
+                    Triple-case code-point case-insensitive equality test
failed by "%s.%s".%n\
+                    TRY: Replace each "switch" expression in
"%1$s.getCIComparisonCodePoint"%n\
+                         with the new expression at this message's end.%n\
+                    %n\
+                    Individual Failures:%n\
+                    %s\
+                    """.formatted(
+                        testedClassName,
+                        testedMethodName,
+                        error.out()
+                    )
+                );
+            }
+        }
+    }
+
+    private static int[] getTripleCaseCodePoints() {
+        @SuppressWarnings("MagicNumber")
+        int[]                   tripleCaseCodePoints    = new int[27];  //
27 was the correct number of triple-case code-points as of JDK 15.0.2 and
Unicode 13.0, but this array will grow, if necessary.
+        int                     tripleCaseCodePointsIdx = 0;
+
+        for (int codePoint = Character.MIN_CODE_POINT; codePoint <=
Character.MAX_CODE_POINT; codePoint++) {
+            final int               codePointUc =
Character.toUpperCase(codePoint);
+
+            if (codePoint == codePointUc)
+                continue;
+
+            final int               codePointLc =
Character.toLowerCase(codePointUc);
+
+            if (codePointUc == codePointLc || codePoint == codePointLc)
+                continue;
+
+        //  "codePoint" has, in effect, three cases (instead of just
uppercase and lowercase).
+
+        //  Increase size of array "tripleCaseCodePoints", if necessary.
+
+            if (tripleCaseCodePoints.length == tripleCaseCodePointsIdx) {
+                //noinspection ObjectAllocationInLoop
+                tripleCaseCodePoints = Arrays.copyOf(tripleCaseCodePoints,
tripleCaseCodePoints.length << 1);
+            }
+
+        //  Add "codePoint" to array "tripleCaseCodePoints".
+
+            tripleCaseCodePoints[tripleCaseCodePointsIdx++] = codePoint;
+        }
+
+        return tripleCaseCodePoints.length == tripleCaseCodePointsIdx ?
tripleCaseCodePoints : Arrays.copyOf(tripleCaseCodePoints,
tripleCaseCodePointsIdx);
     }
-
+
+    /**
+     * Generates the triple-case code-point "switch" expression used in
method "{@code
+     * java.lang.StringUTF16.getCIComparisonCodePoint}", allowing
expression generation
+     * independent of the these tests or their outcomes.
+     *
+     * @return source code for "switch" expression in {@code
StringUTF16.getCIComparisonCodePoint}"},
+     *         generated based on the operative JDK's Unicode data
+     */
+    public static String generateTripleCaseCodePointsSwitchExpression() {
+
+        try (
+            final Formatter         out = new Formatter(new
StringBuilder(5 * 1_024))
+        ){
+            generateTripleCaseCodePointsSwitchExpression(out, "Code-Point
Progression by Name", Character::getName, getTripleCaseCodePoints());
+        //  generateTripleCaseCodePointsSwitchExpression(out, "Unicode
Block Progression", Character.UnicodeBlock::of, getTripleCaseCodePoints());
+
+            out.flush();
+            return out.out().toString();
+        }
+    }
+
+    /**
+     * Generates the triple-case code-point "switch" expression used in
method "{@code
+     * java.lang.StringUTF16.getCIComparisonCodePoint}", writing it to the
supplied {@link Formatter}.
+     *
+     * @param out                      {@code Formatter} to which the
"switch" expression is written
+     * @param symbolicProgressionTitle title of column representing
code-point progression using names
+     *                                 (instead of code-point numbers)
+     * @param symbolicNameAccessor     function accepting a code-point and
returning an object whose
+     *                                 {@code toString} method provides a
name relevant to the code-point
+     * @param tripleCaseCodePoints     array containing every triple-case
code-point, sorted in ascending
+     *                                 order. Normally supplied by {@link
#getTripleCaseCodePoints()}.
+     */
+    private static void generateTripleCaseCodePointsSwitchExpression
+    (
+        final Formatter             out,
+        @SuppressWarnings("SameParameterValue")
+        final String                symbolicProgressionTitle,
+        final IntFunction<Object>   symbolicNameAccessor,
+        final int[]                 tripleCaseCodePoints  // Sorted in
ascending order.
+    ){
+        final boolean               bmpOnly                         =
tripleCaseCodePoints[tripleCaseCodePoints.length - 1] >>> Character.SIZE ==
0;  // Is the greatest code-point within the Basic Multilingual Plane?
+        final String                switchExpressionLine            =
"switch (codePoint) {";
+        final String                columnCPPTitle                  =
"Code-Point Progression";
+        final int                   columnCPPCodePoints;
      // Width of "Code-Point Progression" column in code-points.
+        final String                columnCPPLine;
      // Column header/footer line, a sequence of HYPHEN-MINUS (U+002D)
characters.
+        final String                columnGap                       = "
   ";  // Six spaces.
+        final int                   caseCodePoints                  = 30;
       // Width of "case" clauses in code-points. There are two formats: "
   case '\u0000' -> '\u0000';" and "    case 0x000000 -> 0x000000;". Both
happen to be the same length.
+        final int                   commentAbsoluteIndentCodePoints =
Math.max(codePointCount(switchExpressionLine), caseCodePoints) + 4;  //
Indent, from left margin, of the comments documenting code-point and
Unicode block progressions.
+        final String                commentAbsoluteIndent           = "
".repeat(commentAbsoluteIndentCodePoints);
+        final String                caseCommentGap                  = "
".repeat(commentAbsoluteIndentCodePoints - caseCodePoints);  // Gap between
"case" semicolon and line-comment start.
+        final String                caseFormat;
+        final TripleCaseCodePoints  tccpInfo                        = new
TripleCaseCodePoints(tripleCaseCodePoints, symbolicNameAccessor);
+        final int                   columnSNPCodePoints             =
tccpInfo.name3cCodePointsMax + 4 + tccpInfo.nameUcCodePointsMax + 4 +
tccpInfo.nameLcCodePointsMax;  // Width of symbolic name progression (SNP)
column in code-points.
+        final String                columnSNPLine                   =
"-".repeat(columnSNPCodePoints);  // Column header/footer line, a sequence
of HYPHEN-MINUS (U+002D) characters.
+
+        if (bmpOnly) {  // Code-points from Basic Multilingual Plane (BMP)
only.
+
+            //noinspection StringConcatenationMissingWhitespace
+            caseFormat          = "    case '\\u%1$04X' ->
'\\u%3$04X';%4$s//  U+%1$04X -> U+%2$04X -> U+%3$04X%5$s%6$-" +
tccpInfo.name3cCodePointsMax + "s -> %7$-" + tccpInfo.nameUcCodePointsMax +
"s -> %8$s%n";
+            columnCPPCodePoints = 2 + 4 + 4 + 2 + 4 + 4 + 2 + 4;  // For
example, "U+00B5 -> U+039C -> U+03BC".
+
+        } else {        // Code-points from both BMP and Supplementary
Multilingual Plane.
+
+            //noinspection StringConcatenationMissingWhitespace
+            caseFormat          = "    case 0x%1$06X -> 0x%3$06X;%4$s//
 U+%1$06X -> U+%2$06X -> U+%3$06X%5$s%6$-" + tccpInfo.name3cCodePointsMax +
"s -> %7$-" + tccpInfo.nameUcCodePointsMax + "s -> %8$s%n";
+            columnCPPCodePoints = 2 + 6 + 4 + 2 + 6 + 4 + 2 + 6;  // For
example, "U+0000B5 -> U+00039C -> U+0003BC".
+        }
+
+        columnCPPLine = "-".repeat(columnCPPCodePoints);
+
+        out.format(  // Comment line: title.
+            "%s//  Triple-Case Code-Points, as of Java %s. (Written by
\"%s.generateTripleCaseCodePointsSwitchExpression\".)%n",
+            commentAbsoluteIndent,
+            System.getProperty("java.version"),
+            CompareIC.class.getName()
+        );
+        out.format("%s//  %n", commentAbsoluteIndent);
+        out.format(  // Comment line: column titles.
+            "%s//  %s%s%s%s%n",
+            commentAbsoluteIndent,
+            columnCPPTitle,
+            " ".repeat(columnCPPCodePoints -
codePointCount(columnCPPTitle)),
+            columnGap,
+            symbolicProgressionTitle
+        );
+        out.format(  // Comment line: column horizontal lines.
+            "%s%s//  %s%s%s%n",
+            switchExpressionLine,
+            " ".repeat(commentAbsoluteIndentCodePoints -
codePointCount(switchExpressionLine)),
+            columnCPPLine,
+            columnGap,
+            columnSNPLine
+        );
+
+        for (final TripleCaseCodePoint tccpDatum : tccpInfo.tccpData) {
+
+            out.format(
+                caseFormat,
+                /* 1 */ tccpDatum.codePoint3c,
+                /* 2 */ tccpDatum.codePointUc,
+                /* 3 */ tccpDatum.codePointLc,
+                /* 4 */ caseCommentGap,
+                /* 5 */ columnGap,
+                /* 6 */ tccpDatum.codePoint3cName,
+                /* 7 */ tccpDatum.codePointUcName,
+                /* 8 */ tccpDatum.codePointLcName
+            );
+        }
+
+        out.format("%s//  %s%s%s%n", commentAbsoluteIndent, columnCPPLine,
columnGap, columnSNPLine);  // Comment line: column horizontal lines.
+        out.format(
+            """
+            //  All other case-sensitive code-points are either uppercase
(in which case they are changed%n\
+            //  below), or lowercase already (in which case they are not).
Therefore, only "toLowerCase"%n\
+            //  is necessary. Code-units and case-insensitive code-points
are unchanged by "toLowerCase".%n\
+                default -> Character.toLowerCase(codePoint);%n\
+            };%n\
+            """
+        );
+    }
+
+    /**
+     * <p>Test premise: "Case-insensitive equality exists only among
Supplementary Multilingual Plane (SMP)
+     * code-points UTF-16 encoded using the same high-surrogate
code-unit." This premise, known as "Unicode Empirical
+     * Property no. 1" in {@link java.lang.StringUTF16} (see {@link
java.lang.StringUTF16#regionMatchesCI
+     * regionMatchesCI} implementation notes), is valid for Unicode
versions up to (at least) 13.0.0. It allows an
+     * optimization of UTF-16 case-insensitive comparison: Surrogate pairs
using different high-surrogates prove
+     * inequality, therefore the comparison may terminate without
performing either UTF-16 decoding, or
+     * case-insensitive code-point comparison. (In the case of {@link
java.lang.StringUTF16#compareToCI}, returning
+     * the difference between the high-surrogates is correct.)
+     * </p>
+     * <p>If this premise ceases to be valid (in other words, if this test
fails), methods {@code java.lang.StringUTF16#regionMatchesCI}
+     * and {@link java.lang.StringUTF16#compareToCI}) will require
de-optimization: They must test for case-insensitive
+     * equality between all SMP code-points.
+     * </p>
+     * <p>That optimization cannot be guaranteed safe for Java code in
general, because the code could, someday, run in
+     * the JVM of a Java version whose {@link Character} class represents
a Unicode version with a case-sensitive SMP
+     * code-point arrangement invalidating this premise. Conversely, the
optimization is guaranteed safe for the code of
+     * each Java version passing this test, because that code can
encounter only the Unicode version built into its
+     * {@code Character} class. While this premise holds true, this
optimization allows code outside the JDK to benefit
+     * from the JDK's unique certainty about the operative Unicode version.
+     * </p>
+     *
+     * @see #validatePremise_AllSMPCodePointCaseVariantsAreSMPCodePoints()
+     * @see #validatePremise_AllBMPCodePointCaseVariantsAreBMPCodePoints()
+     */
+    @SuppressWarnings("JavadocReference")
+    @Test
+    public void
validatePremise_AllSMPCodePointCaseVariantsUseTheSameHighSurrogate() {
+
+        System.out.println();
+        System.out.printf(
+            "PREMISE: Case-insensitive equality exists only among
Supplementary Multilingual Plane (SMP) code-points UTF-16%n" +
+            "encoded using the same high-surrogate code-unit.%n"
+        );
+
+        int                     invalidatingCases       = 0;
+        int                     caseSensitiveCodePoints = 0;
+
+        for (int codePoint = Character.MIN_SUPPLEMENTARY_CODE_POINT;
codePoint <= Character.MAX_CODE_POINT; codePoint++) {
+            final int               codePointType =
Character.getType(codePoint);
+
+            if (codePointType == Character.UNASSIGNED || codePointType ==
Character.PRIVATE_USE)
+                continue;
+
+            final int               codePointUc =
Character.toUpperCase(codePoint  );
+            final int               codePointLc =
Character.toLowerCase(codePointUc);
+
+            if (codePoint == codePointUc && codePointUc == codePointLc)
+                continue;
+
+            caseSensitiveCodePoints++;
+
+            if (codePoint >>> 10 != codePointUc >>> 10) {
+
+                System.out.printf(
+                    "    > INVALIDATION: toUpperCase(U+%06X) == U+%06X.
Their high-surrogates differ: U+%04X != U+%04X.%n",
+                    codePoint,
+                    codePointUc,
+                    Character.MIN_HIGH_SURROGATE | (codePoint   -
Character.MIN_SUPPLEMENTARY_CODE_POINT >>> 10),
+                    Character.MIN_HIGH_SURROGATE | (codePointUc -
Character.MIN_SUPPLEMENTARY_CODE_POINT >>> 10)
+                );
+
+                invalidatingCases++;
+            }
+
+            if (codePointUc >>> 10 != codePointLc >>> 10) {
+
+                System.out.printf(
+                    "    > INVALIDATION: toLowerCase(U+%06X) == U+%06X.
Their high-surrogates differ: U+%04X != U+%04X.%n",
+                    codePointUc,
+                    codePointLc,
+                    Character.MIN_HIGH_SURROGATE | (codePointUc -
Character.MIN_SUPPLEMENTARY_CODE_POINT >>> 10),
+                    Character.MIN_HIGH_SURROGATE | (codePointLc -
Character.MIN_SUPPLEMENTARY_CODE_POINT >>> 10)
+                );
+
+                invalidatingCases++;
+            }
+        }
+
+        System.out.printf(
+            "    * Of %,d SMP code-points, %,d are assigned, public and
affected by case-conversion.%n" +
+            "    * Tested case variants of those %<,d SMP code-points for
unequal high-surrogates.%n" +
+            "        * Found %s.%n",
+            Character.MAX_CODE_POINT -
Character.MIN_SUPPLEMENTARY_CODE_POINT + 1,
+            caseSensitiveCodePoints,
+            invalidatingCases == 0 ? "none" :
"%,d".formatted(invalidatingCases)
+        );
+
+        if (invalidatingCases != 0)
+            fail(String.format("TEST RESULT: Premise is false, because %,d
case variants use different high-surrogates.", invalidatingCases));
+
+        System.out.printf(
+            "TEST RESULT: Premise is valid for operative Unicode version,
because all SMP code-point case variants used%n" +
+            "             common high-surrogates.%n%n"
+        );
+    }
+
+    /**
+     * <p>Test premise: "For each Supplementary Multilingual Plane (SMP)
code-point, {@link Character#toUpperCase(int)}
+     * and {@code Character.toLowerCase(Character.toUpperCase(int))}
return a SMP code-point." In {@code
+     * java.lang.StringUTF16}, this premise is referred to as "Unicode
empirical property no. 2".
+     * </p>
+     * <p>Someday, {@link Character} might provide a version of Unicode
(greater than 13.0) invalidating that premise.
+     * If so, it will break all case-insensitive Unicode equality
comparisons requiring equal-length inputs (measured in
+     * "{@code char}" primitives, instead of code-points). For example,
{@link String#equalsIgnoreCase} will break.
+     * </p>
+     * <p>However, even after resolving all aspects of the length issue
everywhere it hides, methods {@code
+     * java.lang.StringUTF16#compareToCI} and {@code
java.lang.StringUTF16#regionMatchesCI} would still be broken,
+     * because this premise, and {@linkplain
#validatePremise_AllBMPCodePointCaseVariantsAreBMPCodePoints() another},
+     * are the bases of an optimization: unequal code-points are tested
for case-insensitive equality only when both
+     * belong to either the Basic Multilingual Plane, or the SMP. (In the
SMP case, a further optimization relies on
+     * a {@linkplain
#validatePremise_AllSMPCodePointCaseVariantsUseTheSameHighSurrogate()
further premise} tested by
+     * this class.)
+     * </p>
+     *
+     * @see #validatePremise_AllBMPCodePointCaseVariantsAreBMPCodePoints
+     * @see
#validatePremise_AllSMPCodePointCaseVariantsUseTheSameHighSurrogate
+     */
+    @Test
+    public void
validatePremise_AllSMPCodePointCaseVariantsAreSMPCodePoints() {
+
+        System.out.println();
+        System.out.println("PREMISE: All Supplementary Multilingual Plane
(SMP) code-points are case-converted to SMP code-points.");
+
+        int                     invalidatingCases       = 0;
+        int                     caseSensitiveCodePoints = 0;
+
+        for (int codePoint = Character.MIN_SUPPLEMENTARY_CODE_POINT;
codePoint <= Character.MAX_CODE_POINT; codePoint++) {
+            final int               codePointType =
Character.getType(codePoint);
+
+            if (codePointType == Character.UNASSIGNED || codePointType ==
Character.PRIVATE_USE)
+                continue;
+
+            final int               codePointUc =
Character.toUpperCase(codePoint  );
+            final int               codePointLc =
Character.toLowerCase(codePointUc);
+
+            if (codePoint == codePointUc && codePointUc == codePointLc)
+                continue;
+
+            caseSensitiveCodePoints++;
+
+            if (codePointUc < Character.MIN_SUPPLEMENTARY_CODE_POINT) {
+
+                System.out.printf("    > INVALIDATION: toUpperCase(0x%06X)
== 0x%04X.%n", codePoint, codePointUc);
+                invalidatingCases++;
+
+            } else if (codePointLc <
Character.MIN_SUPPLEMENTARY_CODE_POINT) {
+
+                System.out.printf("    > INVALIDATION:
toLowerCase(toUpperCase(0x%06X)) == 0x%04X.%n", codePoint, codePointLc);
+                invalidatingCases++;
+            }
+        }
+
+        System.out.printf(
+            "    * Of %,d SMP code-points, %,d are assigned, public and
affected by case-conversion.%n" +
+            "    * Tested case variants of those %<,d SMP code-points for
Basic Multilingual Plane (BMP) code-points.%n" +
+            "        * Found %s.%n",
+            Character.MAX_CODE_POINT -
Character.MIN_SUPPLEMENTARY_CODE_POINT + 1,
+            caseSensitiveCodePoints,
+            invalidatingCases == 0 ? "none" :
"%,d".formatted(invalidatingCases)
+        );
+
+        if (invalidatingCases != 0)
+            fail(String.format("TEST RESULT: Premise is false, because %,d
SMP code-points were case-converted to BMP code-points.",
invalidatingCases));
+
+        System.out.printf("TEST RESULT: Premise is valid for operative
Unicode version, because all case variants were also SMP code-points.%n%n");
+    }
+
+    /**
+     * <p>Test premise: "For each Basic Multilingual Plane (BMP)
code-point, {@link Character#toUpperCase(int)}
+     * and {@code Character.toLowerCase(Character.toUpperCase(int))}
return a BMP code-point." In {@code
+     * java.lang.StringUTF16}, this premise is referred to as "Unicode
empirical property no. 3".
+     * </p>
+     * <p>Someday, {@link Character} might provide a version of Unicode
(greater than 13.0) invalidating that premise.
+     * If so, it will break all case-insensitive Unicode equality
comparisons requiring equal-length inputs (measured in
+     * "{@code char}" primitives, instead of code-points). For example,
{@link String#equalsIgnoreCase} will break.
+     * </p>
+     * <p>However, even after resolving all aspects of the length issue
everywhere it hides, methods {@code
+     * java.lang.StringUTF16#compareToCI} and {@code
java.lang.StringUTF16#regionMatchesCI} would still be broken,
+     * because this premise, and {@linkplain
#validatePremise_AllSMPCodePointCaseVariantsAreSMPCodePoints() another},
+     * are the bases of an optimization: unequal code-points are tested
for case-insensitive equality only when both
+     * belong to either the BMP, or the Supplementary Multilingual Plane
(SMP). (In the SMP case, a further optimization
+     * relies on a {@linkplain
#validatePremise_AllSMPCodePointCaseVariantsUseTheSameHighSurrogate()
further premise}
+     * tested by this class.)
+     * </p>
+     *
+     * @see #validatePremise_AllSMPCodePointCaseVariantsAreSMPCodePoints()
+     * @see
#validatePremise_AllSMPCodePointCaseVariantsUseTheSameHighSurrogate()
+     */
+    @Test
+    public void
validatePremise_AllBMPCodePointCaseVariantsAreBMPCodePoints() {
+
+        System.out.println();
+        System.out.println("PREMISE: All Basic Multilingual Plane (BMP)
code-points are case-converted to BMP code-points.");
+
+        int                     invalidatingCases       = 0;
+        int                     caseSensitiveCodePoints = 0;
+
+        for (int codePoint = Character.MIN_CODE_POINT; codePoint <
Character.MIN_SUPPLEMENTARY_CODE_POINT; codePoint++) {
+            final int               codePointType =
Character.getType(codePoint);
+
+            if (codePointType == Character.UNASSIGNED || codePointType ==
Character.PRIVATE_USE || codePointType == Character.SURROGATE)
+                continue;
+
+            final int               codePointUc =
Character.toUpperCase(codePoint  );
+            final int               codePointLc =
Character.toLowerCase(codePointUc);
+
+            if (codePoint == codePointUc && codePointUc == codePointLc)
+                continue;
+
+            caseSensitiveCodePoints++;
+
+            if (codePointUc >= Character.MIN_SUPPLEMENTARY_CODE_POINT) {
+
+                System.out.printf("    > INVALIDATION: toUpperCase(U+%04X)
== U+%06X.%n", codePoint, codePointUc);
+                invalidatingCases++;
+
+            } else if (codePointLc >=
Character.MIN_SUPPLEMENTARY_CODE_POINT) {
+
+                System.out.printf("    > INVALIDATION:
toLowerCase(toUpperCase(0x%04X)) == 0x%06X.%n", codePoint, codePointLc);
+                invalidatingCases++;
+            }
+        }
+
+        System.out.printf(
+            "    * Of %,d BMP code-points, %,d are assigned, public and
affected by case-conversion.%n" +
+            "    * Tested case variants of those %<,d BMP code-points for
Supplementary Multilingual Plane (SMP) code-points.%n" +
+            "        * Found %s.%n",
+            Character.MIN_SUPPLEMENTARY_CODE_POINT -
(Character.MAX_SURROGATE - Character.MIN_SURROGATE + 1),
+            caseSensitiveCodePoints,
+            invalidatingCases == 0 ? "none" :
"%,d".formatted(invalidatingCases)
+        );
+
+        if (invalidatingCases != 0)
+            fail(String.format("TEST RESULT: Premise is false, because %,d
BMP code-points were case-converted to SMP code-points.",
invalidatingCases));
+
+        System.out.printf("TEST RESULT: Premise is valid for operative
Unicode version, because all case variants were also BMP code-points.%n%n");
+    }
+
+    @Test
+    public void validatePremise_SurrogatesAreUnchangedByCaseConversion() {
+
+        for (char surrogate = Character.MIN_SURROGATE; surrogate <=
Character.MAX_SURROGATE; surrogate++) {
+
+            assertEquals(surrogate, Character.toUpperCase(surrogate));
+            assertEquals(surrogate, Character.toLowerCase(surrogate));
+        }
+    }
+
+    private static int codePointLength
+    (
+        final int               codePoint
+    ){
+        return codePoint >>> Character.SIZE == 0 ? 1 : 2;
+    }
+
+    private static int codePointCount
+    (
+        final String            chars
+    ){
+        return chars.codePointCount(0, chars.length());
+    }
+
+
+    private static class TripleCaseCodePoints {
+
+        final TripleCaseCodePoint[]     tccpData;
+        final int                       name3cCodePointsMax;
+        final int                       nameUcCodePointsMax;
+        final int                       nameLcCodePointsMax;
+
+
+        @SuppressWarnings({ "ObjectAllocationInLoop",
"LocalVariableHidesMemberVariable" })
+        TripleCaseCodePoints
+        (
+            final int[]                 codePoint3cArray,
+            final IntFunction<Object>   codePointNameAccessor
+        ){
+            final TripleCaseCodePoint[] tccpData            = new
TripleCaseCodePoint[codePoint3cArray.length];
+            int                         name3cCodePointsMax = 0;
+            int                         nameUcCodePointsMax = 0;
+            int                         nameLcCodePointsMax = 0;
+
+            for (int tccpIdx = 0; tccpIdx < tccpData.length; tccpIdx++) {
+                final TripleCaseCodePoint   tccpDatum        = new
TripleCaseCodePoint(codePoint3cArray[tccpIdx], codePointNameAccessor);
+                final int                   cpNameCodePoints =
codePointCount(tccpDatum.codePoint3cName);
+                final int                   ucNameCodePoints =
codePointCount(tccpDatum.codePointUcName);
+                final int                   lcNameCodePoints =
codePointCount(tccpDatum.codePointLcName);
+
+                tccpData[tccpIdx] = tccpDatum;
+
+                if (name3cCodePointsMax < cpNameCodePoints)
+                    name3cCodePointsMax = cpNameCodePoints;
+                if (nameUcCodePointsMax < ucNameCodePoints)
+                    nameUcCodePointsMax = ucNameCodePoints;
+                if (nameLcCodePointsMax < lcNameCodePoints)
+                    nameLcCodePointsMax = lcNameCodePoints;
+            }
+
+            this.tccpData            = tccpData;
+            this.name3cCodePointsMax = name3cCodePointsMax;
+            this.nameUcCodePointsMax = nameUcCodePointsMax;
+            this.nameLcCodePointsMax = nameLcCodePointsMax;
+        }
+    }
+
+
+    private static class TripleCaseCodePoint {
+
+        final int                   codePoint3c;
+        final String                codePoint3cName;
+        final int                   codePointUc;
+        final String                codePointUcName;
+        final int                   codePointLc;
+        final String                codePointLcName;
+
+
+        TripleCaseCodePoint
+        (
+            final int                   codePoint3c,
+            final IntFunction<Object>   codePointNameAccessor
+        ){
+            this.codePoint3c     = codePoint3c;
+            this.codePoint3cName =
codePointNameAccessor.apply(codePoint3c).toString();
+            this.codePointUc     = Character.toUpperCase(codePoint3c);
+            this.codePointUcName =
codePointNameAccessor.apply(codePointUc).toString();
+            this.codePointLc     = Character.toLowerCase(codePointUc);
+            this.codePointLcName =
codePointNameAccessor.apply(codePointLc).toString();
+        }
+    }
+
+
+    private static final class StringLiteral {
+
+        private static final char[]     NIBBLES =
"0123456789ABCDEF".toCharArray();
+        private static final String[]   ESCAPES = new String[128];
+
+        static {
+            ESCAPES['\b'] = "\\b";
+            ESCAPES['\t'] = "\\t";
+            ESCAPES['\n'] = "\\n";
+            ESCAPES['\f'] = "\\f";
+            ESCAPES['\r'] = "\\r";
+            ESCAPES['"' ] = "\\\"";
+            ESCAPES['\\'] = "\\\\";
+            ESCAPES[' ' ] = " ";  // Avoids an extra conditional test.
+        }
+
+
+        static String from
+        (
+            final int               codePoint
+        ){
+            try {
+                return append(new StringBuilder(14), codePoint).toString();
+            } catch (final IOException e) {
+                throw new UncheckedIOException(e);  // Operating on a
"StringBuilder", this case cannot arise.
+            }
+        }
+
+        static String from
+        (
+            final String            chars
+        ){
+            try {
+                final StringBuilder     output = append(new
StringBuilder(chars.length()), chars);
+
+                return chars.length() == output.length() ? chars :
output.toString();
+
+            } catch (final IOException e) {
+                throw new UncheckedIOException(e);  // Operating on a
"StringBuilder", this case cannot arise.
+            }
+        }
+
+        static CharSequence from
+        (
+            final CharSequence      chars
+        ){
+            try {
+                final StringBuilder     output = append(new
StringBuilder(chars.length()), chars);
+
+                return chars.length() == output.length() ? chars :
output.toString();
+
+            } catch (final IOException e) {
+                throw new UncheckedIOException(e);  // Operating on a
"StringBuilder", this case cannot arise.
+            }
+        }
+
+        static <T extends Appendable> T append
+        (
+            final T                 out,
+            final int               codePoint
+        )
+        throws IOException
+        {
+            out.append("\"\\u");
+
+            if (codePoint >>> Character.SIZE == 0) {
+
+                appendHex(out, 4, 4, codePoint).append('"');
+
+            } else {
+
+                appendHex(out, 4, 4,
Character.highSurrogate(codePoint)).append("\\u");
+                appendHex(out, 4, 4, Character.lowSurrogate
(codePoint)).append('"'  );
+            }
+
+            return out;
+        }
+
+        static <T extends Appendable> T append
+        (
+            final T                 out,
+            final CharSequence      chars
+        )
+        throws IOException
+        {
+            out.append('"');
+
+            for (int charIdx = 0, charsRemaining = chars.length();
--charsRemaining >= 0; charIdx++) {
+                final char              c = chars.charAt(charIdx);
+
+                if (c < ESCAPES.length) {
+                    final String            escape = ESCAPES[c];
+
+                    if (escape != null) {
+                        out.append(escape);
+                        continue;
+                    }
+                }
+
+                final int               codePointCategory =
Character.getType(c);
+
+                if (codePointCategory == Character.UNASSIGNED  // Also
includes "permanently reserved" code-points.
+                ||  codePointCategory >= Character.SPACE_SEPARATOR
+                &&  codePointCategory <= Character.SURROGATE
+                ){
+                //  Represent whitespace, invisibles, Supplementary
Multilingual Plane code-points, and so
+                //  forth, using 16-bit Unicode escapes. "Character" class
identifiers for those Unicode
+                //  categories are:
+                //       0 - UNASSIGNED
+                //      12 - SPACE_SEPARATOR (the escape logic prevents
encoding of code-point "SPACE", U+0020)
+                //      13 - LINE_SEPARATOR
+                //      14 - PARAGRAPH_SEPARATOR
+                //      15 - CONTROL
+                //      16 - FORMAT
+                //      17 - (unused)
+                //      18 - PRIVATE_USE
+                //      19 - SURROGATE
+
+                    appendHex(out.append("\\u"), 4, 4, c);
+
+                } else
+                    out.append(c);
+            }
+
+            out.append('"');
+
+            return out;
+        }
+
+        @SuppressWarnings("MagicNumber")
+        private static <T extends Appendable> T appendHex
+        (
+            final T                 out,
+            @SuppressWarnings("SameParameterValue")
+            final int               hexDigitsMin,
+            @SuppressWarnings("SameParameterValue")
+            final int               hexDigitsMax,
+            final int               value
+        )
+        throws IOException
+        {
+        //  NOTE: If necessary, this method can be made to support 64-bit
values by changing "value"
+        //        from "int" to "long", and replacing "Integer" class
references with "Long".
+
+            if (0 > hexDigitsMin || hexDigitsMin > hexDigitsMax ||
hexDigitsMax > Integer.SIZE >>> 2)
+                throw new IllegalArgumentException("Violation of parameter
value constraints: 0 < \"hexDigitsMin\" (" + hexDigitsMin + ") <
\"hexDigitsMax\" (" + hexDigitsMax + ") <= " + (Integer.SIZE >>> 2) + '.');
+
+            int                     shift  = hexDigitsMax - 1 << 2;
+            int                     nibble = value >>> shift & 0xF;
+
+            if (nibble == 0 && hexDigitsMin < hexDigitsMax) {
+                int                     optionalLeadingZeros =
hexDigitsMax - hexDigitsMin;
+
+                do {
+
+                    shift -= 4;                      // Ignore the current
zero nibble.
+                    nibble = value >>> shift & 0xF;  // Read the next
nibble.
+
+                } while (nibble == 0 && --optionalLeadingZeros > 0);
+            }
+
+            out.append(NIBBLES[nibble]);
+
+            for (shift -= 4; shift >= 0; shift -= 4)
+                out.append(NIBBLES[value >>> shift & 0xF]);
+
+            return out;
+        }
+    }
 }

From raffaello.giulietti at gmail.com  Wed Mar 31 00:19:49 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 31 Mar 2021 02:19:49 +0200
Subject: Further review of java.util.HexFormat
Message-ID: <86f36fac-1de3-1191-7895-0f2bed87515b@gmail.com>

Hello Roger,


these are the changes I'm proposing after reviewing the code of 
j.u.HexFormat. The modified code available here
https://github.com/rgiulietti/jdk/commit/6759a25eb952ab19a045a83349d41b82cc1b07cb

In addition to other smaller, hopefully self-explanatory enhancements, 
here are the rationales for the changes.


Static field DIGITS should preferably be formatted with 16 values/line 
to ease a visual positional crosscheck with published ASCII/IsoLatin1 
tables.


Field digits is initialized with either UPPERCASE_DIGITS, 
LOWERCASE_DIGITS or digits from another instance, so it always ends up 
being either UPPERCASE_DIGITS or LOWERCASE_DIGITS.
Consequently:
* There's no need for requireNonNull() check in the (sole) private 
constructor.
* It's preferable to move the last comparison in method equals() as the 
first factor in the return statement, so it can return faster in case of 
a lower/upper mismatch. (Arrays.equals() first checks for ==, so it 
always returns fast as used in this class. It could even be replaced by 
a simple == )


Method fromHexDigits(CharSequence, int) either returns a value in the 
range [0x00..0xff] or throws.
Therefore, there's no need for the checks leading to the throwing of 
IllegalArgumentException in methods
* parseHex(CharSequence, int, int)
* parseNoDelimiter(CharSequence)
which can be simplified as a consequence.


The test for IllegalArgumentException in method parseHex(CharSequence, 
int, int), namely
string.length() < valueChars || (string.length() - valueChars) % stride != 0
can be simplified as
(string.length() - valueChars) % stride != 0

Indeed, at this point in the control flow we have
string.length() > 0  and  stride >= valueChars
Assuming string.length() < valueChars as in the left operand of || we 
then have
-stride <= -valueChars < string.length() - valueChars < 0
so
string.length() - valueChars) % stride != 0
which is the right operand of ||.
In other words, the left operand always implies the right one, adding 
nothing to it.


There's no need to check again for non-nullness in private method 
fromHexDigits(CharSequence, int). It is invoked from two places where 
the check is already performed.


Both fromHexDigits(CharSequence) and fromHexDigitsToLong(CharSequence) 
can simply invoke their 3 args counterparts.


If you prefer, I can prepare a PR once there's an issue in the bug 
system to associate the PR with.


Greetings
Raffaello

From brian.goetz at oracle.com  Wed Mar 31 02:12:32 2021
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 30 Mar 2021 22:12:32 -0400
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <162ac99e-a2fa-8254-01ca-05c68e40e9d0@gmail.com>
References: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
 <00975763-89a9-4b4b-8dd2-b2df4551edbf@oracle.com>
 <3621EAD0-FB9A-41B5-960B-4045F09A9C7C@oracle.com>
 <162ac99e-a2fa-8254-01ca-05c68e40e9d0@gmail.com>
Message-ID: <64334a24-0e4c-57b8-b666-447ca3508ce5@oracle.com>

They'll find a natural home in JDBC, since SQL has a native decimal type.

On 3/30/2021 7:05 PM, Raffaello Giulietti wrote:
>
> As far as I can tell, scientific computation will make use of binary 
> floating point numbers for a long time. Decimal floating point numbers 
> are still limited to biz and fin applications. 


From xgong at openjdk.java.net  Wed Mar 31 02:53:13 2021
From: xgong at openjdk.java.net (Xiaohong Gong)
Date: Wed, 31 Mar 2021 02:53:13 GMT
Subject: RFR: 8264109: Add vectorized implementation for
 VectorMask.andNot()
In-Reply-To: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
Message-ID: <n_ZlRg0lP98U8fWWF63kmW-GQiGjLtmvKvjzqBGNeZI=.b6a8b249-a66a-4359-b04d-5b0604bdffd0@github.com>

On Fri, 26 Mar 2021 01:50:33 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently "VectorMask.andNot()" is not vectorized:
>     public VectorMask<E> andNot(VectorMask<E> m) {
>         // FIXME: Generate good code here.
>         return bOp(m, (i, a, b) -> a && !b);
>     }
> This can be implemented with` "and(m.not())" `directly. Since `"VectorMask.and()/not()" `have been vectorized in hotspot, `"andNot"`
> can be vectorized as well by calling them.
> 
> The performance gain is >100% for such a simple JMH:
>   @Benchmark
>   public Object andNot(Blackhole bh) {
>     boolean[] mask = fm.apply(SPECIES.length());
>     boolean[] r = fmt.apply(SPECIES.length());
>     VectorMask<Byte> rm = VectorMask.fromArray(SPECIES, r, 0);
> 
>     for (int ic = 0; ic < INVOC_COUNT; ic++) {
>       for (int i = 0; i < mask.length; i += SPECIES.length()) {
>         VectorMask<Byte> vmask = VectorMask.fromArray(SPECIES, mask, i);
>           rm = rm.andNot(vmask);
>         }
>     }
>     return rm;
>   }

Hi there, could anyone please take a look at this PR? Thanks so much!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3211

From joehw at openjdk.java.net  Wed Mar 31 05:10:30 2021
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 31 Mar 2021 05:10:30 GMT
Subject: RFR: JDK-8264454 : Jaxp unit test from open jdk needs to be
 improved
In-Reply-To: <9m0pNx9y4V-QfxrJpbXLjtg10Oao9N-67fGdmZyNbTU=.e446d95d-763a-4cec-86b0-2219f0e20d34@github.com>
References: <9m0pNx9y4V-QfxrJpbXLjtg10Oao9N-67fGdmZyNbTU=.e446d95d-763a-4cec-86b0-2219f0e20d34@github.com>
Message-ID: <hjYWCsb8W14zg-jXGR9J1N6WTh1yJ6HtrfmjqhR_Ogs=.4772f9aa-b5ba-400d-9df8-e484666fea58@github.com>

On Tue, 30 Mar 2021 16:56:57 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

> JDK-8264454 : Jaxp unit test from open jdk needs to be improved

test/jaxp/javax/xml/jaxp/unittest/common/Bug6350682.java line 47:

> 45:     @Test
> 46:     public void testSAXParserFactory() {
> 47:         runWithAllPerm(() -> Thread.currentThread().setContextClassLoader(null));

To address item 4 (the environment is changed), a note, something like "this test runs in othervm" can be added here or to the summary.

test/jaxp/javax/xml/jaxp/unittest/common/Bug6723276Test.java line 45:

> 43: @Listeners({jaxp.library.BasePolicy.class})
> 44: public class Bug6723276Test {
> 45:     private static final String ERR_MSG = "org.apache.xerces.jaxp.SAXParserFactoryImpl not found";

This test currently doesn't verify anything since there's no org.apache.xerces.jaxp.SAXParserFactoryImpl on the classpath. Post JDK 9, such test would require creating a dummy module.

test/jaxp/javax/xml/jaxp/unittest/common/Bug6723276Test.java line 48:

> 46: 
> 47:     @Test
> 48:     public void testSAXParserFactoryCreationWithDefaultContextClassLoader() {

A shorter name such as testWithDefaultClassLoader would be fine.

test/jaxp/javax/xml/jaxp/unittest/common/Bug6723276Test.java line 59:

> 57: 
> 58:     @Test
> 59:     public void testSAXParserFactoryCreationWithGivenURLContextClassLoader() {

A shorter name would be testWithURLClassLoader

test/jaxp/javax/xml/jaxp/unittest/datatype/Bug6320118.java line 59:

> 57:         Assert.assertEquals(calendar.getMonth(), 1);
> 58:         Assert.assertEquals(calendar.getDay(), 2);
> 59:         Assert.assertEquals(calendar.getHour(), 0, "hour 24 needs to be treated as hour 0 of next day");

This change has added assertions, but it seems ok.

test/jaxp/javax/xml/jaxp/unittest/datatype/Bug6937964Test.java line 57:

> 55:      * Constant to indicate expected lexical test failure.
> 56:      */
> 57:     private static final String TEST_VALUE_FAIL = "*FAIL*";

I don't see this in the expected values. It, along with the related assertions, may be removed.

test/jaxp/javax/xml/jaxp/unittest/datatype/Bug6937964Test.java line 194:

> 192:             try {
> 193:                 QName xmlSchemaType = duration.getXMLSchemaType();
> 194:                 if (!xmlSchemaType.equals(DatatypeConstants.DURATION_YEARMONTH)) {

Can be changed to assertEquals

test/jaxp/javax/xml/jaxp/unittest/datatype/Bug6937964Test.java line 200:

> 198:                 } catch (IllegalStateException illegalStateException) {
> 199:                     // TODO; this test really should pass
> 200:                     System.err.println("Please fix this bug that is being ignored, for now: " + illegalStateException.getMessage());

Do we still have such a bug?

test/jaxp/javax/xml/jaxp/unittest/datatype/Bug6937964Test.java line 204:

> 202: 
> 203:                 // does it have the right value?
> 204:                 if (!expectedLex.equals(duration.toString())) {

Can be changed to assertEquals

-------------

PR: https://git.openjdk.java.net/jdk/pull/3274

From stefank at openjdk.java.net  Wed Mar 31 07:02:42 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 31 Mar 2021 07:02:42 GMT
Subject: RFR: 8264489: Add more logging to LargeCopyWithMark.java
Message-ID: <cI2Haf-RY2Hhea8pOevcFdWSj4fqoeCMfMPLRb203IA=.d0f2f187-e1a3-4172-afd5-360723544cbb@github.com>

Add more logging to the LargeCopyWithMark.java test, to gather more information when this test fails with OOME. 

The intention is to gather more info for JDK-8239089.

I consider this patch trivial, and expect to push it after I've gotten on Review.

-------------

Commit messages:
 - 8264489: Add more logging to LargeCopyWithMark.java

Changes: https://git.openjdk.java.net/jdk/pull/3282/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3282&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264489
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3282.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3282/head:pull/3282

PR: https://git.openjdk.java.net/jdk/pull/3282

From kbarrett at openjdk.java.net  Wed Mar 31 08:42:30 2021
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 31 Mar 2021 08:42:30 GMT
Subject: RFR: 8264489: Add more logging to LargeCopyWithMark.java
In-Reply-To: <cI2Haf-RY2Hhea8pOevcFdWSj4fqoeCMfMPLRb203IA=.d0f2f187-e1a3-4172-afd5-360723544cbb@github.com>
References: <cI2Haf-RY2Hhea8pOevcFdWSj4fqoeCMfMPLRb203IA=.d0f2f187-e1a3-4172-afd5-360723544cbb@github.com>
Message-ID: <1UaIiA_vTdseSbwUFIVMle0lkkifUDPslodOBmMqnBI=.7e3cd01d-f7dd-4c7b-b2c3-0cde379e826c@github.com>

On Wed, 31 Mar 2021 06:56:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Add more logging to the LargeCopyWithMark.java test, to gather more information when this test fails with OOME. 
> 
> The intention is to gather more info for JDK-8239089.
> 
> I consider this patch trivial, and expect to push it after I've gotten one Review.

Looks good, and trivial.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3282

From stefank at openjdk.java.net  Wed Mar 31 08:47:25 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 31 Mar 2021 08:47:25 GMT
Subject: RFR: 8264489: Add more logging to LargeCopyWithMark.java
In-Reply-To: <1UaIiA_vTdseSbwUFIVMle0lkkifUDPslodOBmMqnBI=.7e3cd01d-f7dd-4c7b-b2c3-0cde379e826c@github.com>
References: <cI2Haf-RY2Hhea8pOevcFdWSj4fqoeCMfMPLRb203IA=.d0f2f187-e1a3-4172-afd5-360723544cbb@github.com>
 <1UaIiA_vTdseSbwUFIVMle0lkkifUDPslodOBmMqnBI=.7e3cd01d-f7dd-4c7b-b2c3-0cde379e826c@github.com>
Message-ID: <-9Fj-aJgYyg-1hThUJwi7TbNo-1GReBVuofF686aDho=.441292e8-52da-4228-9bd4-772a8a3f8391@github.com>

On Wed, 31 Mar 2021 08:39:02 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Add more logging to the LargeCopyWithMark.java test, to gather more information when this test fails with OOME. 
>> 
>> The intention is to gather more info for JDK-8239089.
>> 
>> I consider this patch trivial, and expect to push it after I've gotten one Review.
>
> Looks good, and trivial.

Thanks Kim!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3282

From scolebourne at joda.org  Wed Mar 31 08:51:29 2021
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 31 Mar 2021 09:51:29 +0100
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <3bd78fc2-8ce9-b49e-f92d-c1ed93b0a2c6@oracle.com>
References: <ac59a3d8-c193-56fc-1833-191a407c7490@gmail.com>
 <00975763-89a9-4b4b-8dd2-b2df4551edbf@oracle.com>
 <3621EAD0-FB9A-41B5-960B-4045F09A9C7C@oracle.com>
 <3bd78fc2-8ce9-b49e-f92d-c1ed93b0a2c6@oracle.com>
Message-ID: <CACzrW9BrsmduUr7LYVcXOGKWBst=2BcuXBnL9cN9VoD6teLZWA@mail.gmail.com>

On Tue, 30 Mar 2021 at 22:02, Maurizio Cimadamore
<maurizio.cimadamore at oracle.com> wrote:
> There are also other interesting types to be explored in that domain,
> such as Long128, LongDouble (extended precision float) and HalfFloats.

Perhaps it would be beneficial to have a GitHub repo where designs for
these could be fleshed out. Kind of like a JSR would do. (For example,
Valhalla and OopenJDK will need to agree on naming conventions for the
various methods - for example I prefer plus() but others prefer add().
Stephen

From alanb at openjdk.java.net  Wed Mar 31 09:32:07 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 31 Mar 2021 09:32:07 GMT
Subject: RFR: 8264489: Add more logging to LargeCopyWithMark.java
In-Reply-To: <cI2Haf-RY2Hhea8pOevcFdWSj4fqoeCMfMPLRb203IA=.d0f2f187-e1a3-4172-afd5-360723544cbb@github.com>
References: <cI2Haf-RY2Hhea8pOevcFdWSj4fqoeCMfMPLRb203IA=.d0f2f187-e1a3-4172-afd5-360723544cbb@github.com>
Message-ID: <SVSvGKzOySERjzA4Arq511KlB-9aJOnKN0GZtB6-tfc=.c75d1515-d210-4275-b1ad-750ec3759dcd@github.com>

On Wed, 31 Mar 2021 06:56:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Add more logging to the LargeCopyWithMark.java test, to gather more information when this test fails with OOME. 
> 
> The intention is to gather more info for JDK-8239089.
> 
> I consider this patch trivial, and expect to push it after I've gotten one Review.

test/jdk/java/io/BufferedInputStream/LargeCopyWithMark.java line 29:

> 27:  * @summary BufferedInputStream calculates negative array size with large
> 28:  *          streams and mark
> 29:  * @run main/othervm -Xmx4G -Xlog:gc,gc+heap,gc+ergo+heap -XX:+CrashOnOutOfMemoryError -XX:+IgnoreUnrecognizedVMOptions -XX:+G1ExitOnExpansionFailure LargeCopyWithMark

Looks okay but I assume you can split this line to avoid having a 170+ line in this file, this helps with future side-by-side review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3282

From github.com+76791+alblue at openjdk.java.net  Wed Mar 31 09:35:19 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Wed, 31 Mar 2021 09:35:19 GMT
Subject: RFR: 8264397: Use the blessed modifier order in
 jdk.incubator.foreign
In-Reply-To: <1SRsrDQ6ehLr6rA9c-fQSxPBF6TSZVDpWWoUj_eqGk0=.d446fc38-a4c8-4254-9f52-8541d9680f6a@github.com>
References: <S8y1iC02mJVfaCzrbFMxNe1fcbZAqsS6xDo_6kKZwBY=.283524b1-104f-47f7-9996-b2b8977a09ac@github.com>
 <DghGx59T4CxKsAK-0GNtn8_UhLjcybiCYbvg9QSbye4=.d1fa3ec9-1c82-49ca-9d1f-2fdb071a6fff@github.com>
 <h1-4oxvZOZ0Ftv0NLoABjU3NdkBLLm-2qOuLGHpOrwo=.5b8f4c16-1544-41e1-bd6d-4845e0b73eca@github.com>
 <mQyEUYhJLFLQIES7JzR1RDnvh4cak4tHxuCG4GNQwpY=.c1a2de68-3533-4cb6-96ee-588d7afb62ea@github.com>
 <1SRsrDQ6ehLr6rA9c-fQSxPBF6TSZVDpWWoUj_eqGk0=.d446fc38-a4c8-4254-9f52-8541d9680f6a@github.com>
Message-ID: <oaWNYduHt1jeh82w0nFl6-6V7cRehvbPdFaFfVJCl6A=.bf5faa06-2d52-45a3-a1c9-80580259f892@github.com>

On Tue, 30 Mar 2021 21:26:34 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

>> Hi @alblue, thanks for the contribution. We will make sure to integrate this at some point, but I don't think now is the right moment to do this kind of stylistic changes to the API/implementation. If you want to integrate the fix now, I'd suggest to file a PR against https://github.com/openjdk/panama-foreign, and we'll be happy to sponsor the change. That way you'd be guaranteed the change would be included in the next incubation round.
>
> Have submitted change to the panama-foreign branch; let me know if that's the appropriate place and I can abandon this PR.

Going to upstream this patch into opendjk/panama-foreign

-------------

PR: https://git.openjdk.java.net/jdk/pull/3253

From github.com+76791+alblue at openjdk.java.net  Wed Mar 31 09:35:19 2021
From: github.com+76791+alblue at openjdk.java.net (Alex Blewitt)
Date: Wed, 31 Mar 2021 09:35:19 GMT
Subject: Withdrawn: 8264397: Use the blessed modifier order in
 jdk.incubator.foreign
In-Reply-To: <S8y1iC02mJVfaCzrbFMxNe1fcbZAqsS6xDo_6kKZwBY=.283524b1-104f-47f7-9996-b2b8977a09ac@github.com>
References: <S8y1iC02mJVfaCzrbFMxNe1fcbZAqsS6xDo_6kKZwBY=.283524b1-104f-47f7-9996-b2b8977a09ac@github.com>
Message-ID: <lTPFf7CiBfVyo5Zxshzqa3wbT_H5U3ken9pmVLS-d4w=.0eb785c8-0530-4486-8be4-4c2169cb3778@github.com>

On Mon, 29 Mar 2021 21:09:56 GMT, Alex Blewitt <github.com+76791+alblue at openjdk.org> wrote:

> 8264397: Use the blessed modifier order in jdk.incubator.foreign

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3253

From stefank at openjdk.java.net  Wed Mar 31 11:15:43 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 31 Mar 2021 11:15:43 GMT
Subject: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]
In-Reply-To: <cI2Haf-RY2Hhea8pOevcFdWSj4fqoeCMfMPLRb203IA=.d0f2f187-e1a3-4172-afd5-360723544cbb@github.com>
References: <cI2Haf-RY2Hhea8pOevcFdWSj4fqoeCMfMPLRb203IA=.d0f2f187-e1a3-4172-afd5-360723544cbb@github.com>
Message-ID: <FRumAE8XsRLP6iTloWT_T1HlAxsSMZNRyAXm75VxBl4=.ec5dbbbe-d25e-426e-bf72-14572729be5d@github.com>

> Add more logging to the LargeCopyWithMark.java test, to gather more information when this test fails with OOME. 
> 
> The intention is to gather more info for JDK-8239089.
> 
> I consider this patch trivial, and expect to push it after I've gotten one Review.

Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:

  Review Alan

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3282/files
  - new: https://git.openjdk.java.net/jdk/pull/3282/files/a7260c86..1828df10

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3282&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3282&range=00-01

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3282.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3282/head:pull/3282

PR: https://git.openjdk.java.net/jdk/pull/3282

From stefank at openjdk.java.net  Wed Mar 31 11:19:08 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 31 Mar 2021 11:19:08 GMT
Subject: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]
In-Reply-To: <SVSvGKzOySERjzA4Arq511KlB-9aJOnKN0GZtB6-tfc=.c75d1515-d210-4275-b1ad-750ec3759dcd@github.com>
References: <cI2Haf-RY2Hhea8pOevcFdWSj4fqoeCMfMPLRb203IA=.d0f2f187-e1a3-4172-afd5-360723544cbb@github.com>
 <SVSvGKzOySERjzA4Arq511KlB-9aJOnKN0GZtB6-tfc=.c75d1515-d210-4275-b1ad-750ec3759dcd@github.com>
Message-ID: <yqhGv3OyfxMpuJPhP5LZacQAR4pBbMgIbknYLduq6ck=.1d68b75e-341d-4b8b-867d-6f1dfb582d8b@github.com>

On Wed, 31 Mar 2021 09:29:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Alan
>
> test/jdk/java/io/BufferedInputStream/LargeCopyWithMark.java line 29:
> 
>> 27:  * @summary BufferedInputStream calculates negative array size with large
>> 28:  *          streams and mark
>> 29:  * @run main/othervm -Xmx4G -Xlog:gc,gc+heap,gc+ergo+heap -XX:+CrashOnOutOfMemoryError -XX:+IgnoreUnrecognizedVMOptions -XX:+G1ExitOnExpansionFailure LargeCopyWithMark
> 
> Looks okay but I assume you can split this line to avoid having a 170+ line in this file, this helps with future side-by-side review.

Thanks. I've added line breaks to make it easier to read.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3282

From alanb at openjdk.java.net  Wed Mar 31 11:24:19 2021
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 31 Mar 2021 11:24:19 GMT
Subject: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]
In-Reply-To: <FRumAE8XsRLP6iTloWT_T1HlAxsSMZNRyAXm75VxBl4=.ec5dbbbe-d25e-426e-bf72-14572729be5d@github.com>
References: <cI2Haf-RY2Hhea8pOevcFdWSj4fqoeCMfMPLRb203IA=.d0f2f187-e1a3-4172-afd5-360723544cbb@github.com>
 <FRumAE8XsRLP6iTloWT_T1HlAxsSMZNRyAXm75VxBl4=.ec5dbbbe-d25e-426e-bf72-14572729be5d@github.com>
Message-ID: <OD3yyQZg0DbsLr0ECJEkY65rx4-Fdu5UxEYqfiY7_NM=.314e8af3-a9c0-4d6a-b9b5-399e20ed9b90@github.com>

On Wed, 31 Mar 2021 11:15:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Add more logging to the LargeCopyWithMark.java test, to gather more information when this test fails with OOME. 
>> 
>> The intention is to gather more info for JDK-8239089.
>> 
>> I consider this patch trivial, and expect to push it after I've gotten one Review.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Alan

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3282

From dfuchs at openjdk.java.net  Wed Mar 31 11:27:12 2021
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 31 Mar 2021 11:27:12 GMT
Subject: RFR: 8264048: Fix caching in Jar URL connections when an entry is
 missing
In-Reply-To: <1n33RkwMvQZNEeyHOmPjK9UUNp9hc5esxRwL00sT_IM=.45c6aa6e-39c1-4048-b05e-9a6aa765469e@github.com>
References: <1n33RkwMvQZNEeyHOmPjK9UUNp9hc5esxRwL00sT_IM=.45c6aa6e-39c1-4048-b05e-9a6aa765469e@github.com>
Message-ID: <3rVqQ1ucYqe31hOSaRB6bsLOwU2GznjSofMJOWzE2Uk=.90e87186-538d-4e94-9ddf-236d03a9bc1f@github.com>

On Tue, 30 Mar 2021 11:30:48 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> Current fix tries to tackle an issue with URL connection referencing non-existing Jar file entries:
> If an entry that doesn't exist is specified in an URL connection the underlying Jar file is still cached even if an exception is thrown after that. Such behavior prevents the caller, for instance, a `URLClassLoader`, from closing a Jar file.
> 
> The proposed fix checks if entry exists before caching a Jar file (only for cases with enabled caching):
> - If entry exists - jar file is cached if it wasn't cached before
> - If entry doesn't exist and jar file wasn't cached before - jar file is closed and exception is thrown
> - If entry doesn't exist and jar file was cached before - jar file is kept cached and exception is thrown
> 
> 
> The following tests have been used to verify the fix:
> - New regression tests
> - ``:jdk_core:`` tests
> - `api/java_util`,`api/java_net` JCK tests

Hi Aleksei, thanks for putting this together.

`test/jdk/sun/misc/URLClassPath/RemoveJar.java` seems to be an older version of `test/jdk/java/net/URLClassLoader/RemoveJar.java`. The two tests are almost identical - so `test/jdk/sun/misc/URLClassPath/RemoveJar.java` can probably be removed from the PR.

Otherwise the proposed changes look good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3263

From aefimov at openjdk.java.net  Wed Mar 31 12:47:52 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 31 Mar 2021 12:47:52 GMT
Subject: RFR: 8264048: Fix caching in Jar URL connections when an entry is
 missing
In-Reply-To: <3rVqQ1ucYqe31hOSaRB6bsLOwU2GznjSofMJOWzE2Uk=.90e87186-538d-4e94-9ddf-236d03a9bc1f@github.com>
References: <1n33RkwMvQZNEeyHOmPjK9UUNp9hc5esxRwL00sT_IM=.45c6aa6e-39c1-4048-b05e-9a6aa765469e@github.com>
 <3rVqQ1ucYqe31hOSaRB6bsLOwU2GznjSofMJOWzE2Uk=.90e87186-538d-4e94-9ddf-236d03a9bc1f@github.com>
Message-ID: <sKqwYvg9YKQgiCjXGBkFVWxB5Syb7R4LIDjaLwpdyyw=.4e3dc039-7e3b-4411-a6b8-87332e648837@github.com>

On Wed, 31 Mar 2021 11:24:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Current fix tries to tackle an issue with URL connection referencing non-existing Jar file entries:
>> If an entry that doesn't exist is specified in an URL connection the underlying Jar file is still cached even if an exception is thrown after that. Such behavior prevents the caller, for instance, a `URLClassLoader`, from closing a Jar file.
>> 
>> The proposed fix checks if entry exists before caching a Jar file (only for cases with enabled caching):
>> - If entry exists - jar file is cached if it wasn't cached before
>> - If entry doesn't exist and jar file wasn't cached before - jar file is closed and exception is thrown
>> - If entry doesn't exist and jar file was cached before - jar file is kept cached and exception is thrown
>> 
>> 
>> The following tests have been used to verify the fix:
>> - New regression tests
>> - ``:jdk_core:`` tests
>> - `api/java_util`,`api/java_net` JCK tests
>
> Hi Aleksei, thanks for putting this together.
> 
> `test/jdk/sun/misc/URLClassPath/RemoveJar.java` seems to be an older version of `test/jdk/java/net/URLClassLoader/RemoveJar.java`. The two tests are almost identical - so `test/jdk/sun/misc/URLClassPath/RemoveJar.java` can probably be removed from the PR.
> 
> Otherwise the proposed changes look good to me.

Thanks for the review, Daniel. It is correct that `test/jdk/sun/misc/URLClassPath/RemoveJar.java` is an old version. It is removed now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3263

From aefimov at openjdk.java.net  Wed Mar 31 12:47:50 2021
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Wed, 31 Mar 2021 12:47:50 GMT
Subject: RFR: 8264048: Fix caching in Jar URL connections when an entry is
 missing [v2]
In-Reply-To: <1n33RkwMvQZNEeyHOmPjK9UUNp9hc5esxRwL00sT_IM=.45c6aa6e-39c1-4048-b05e-9a6aa765469e@github.com>
References: <1n33RkwMvQZNEeyHOmPjK9UUNp9hc5esxRwL00sT_IM=.45c6aa6e-39c1-4048-b05e-9a6aa765469e@github.com>
Message-ID: <D8au5a1Xx4NlUqMVWmU3XZJ8W03xN3oVJxgfajzfpS4=.f2db26da-357b-4591-9cd6-1e3ffaf91154@github.com>

> Current fix tries to tackle an issue with URL connection referencing non-existing Jar file entries:
> If an entry that doesn't exist is specified in an URL connection the underlying Jar file is still cached even if an exception is thrown after that. Such behavior prevents the caller, for instance, a `URLClassLoader`, from closing a Jar file.
> 
> The proposed fix checks if entry exists before caching a Jar file (only for cases with enabled caching):
> - If entry exists - jar file is cached if it wasn't cached before
> - If entry doesn't exist and jar file wasn't cached before - jar file is closed and exception is thrown
> - If entry doesn't exist and jar file was cached before - jar file is kept cached and exception is thrown
> 
> 
> The following tests have been used to verify the fix:
> - New regression tests
> - ``:jdk_core:`` tests
> - `api/java_util`,`api/java_net` JCK tests

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8264048: Remove old version of RemoveJar test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/3263/files
  - new: https://git.openjdk.java.net/jdk/pull/3263/files/6aeb3333..2f0fa527

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=3263&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=3263&range=00-01

  Stats: 179 lines in 1 file changed: 0 ins; 179 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3263.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3263/head:pull/3263

PR: https://git.openjdk.java.net/jdk/pull/3263

From jpai at openjdk.java.net  Wed Mar 31 13:40:09 2021
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 31 Mar 2021 13:40:09 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a directory
In-Reply-To: <p-_HnI7N66Tgv3ksgxXBfa7uSaj9VBe-3eQYSIpNep8=.10b43b7a-6a14-488a-9b98-95afa10846a7@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <p-_HnI7N66Tgv3ksgxXBfa7uSaj9VBe-3eQYSIpNep8=.10b43b7a-6a14-488a-9b98-95afa10846a7@github.com>
Message-ID: <Lnpf7HVinfNW1KkmTzDhO4CsYIhmYjHeU-oX5RRS5Bc=.48ac3f40-0359-4d56-9252-f5460687e5c9@github.com>

On Sat, 27 Mar 2021 16:02:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
>> 
>> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
>> 
>> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> I think the summary is that we've converged on -C/--dir. We might have to tweak the usage message for -C so that it starts with the existing "Change to the specified directory ..." rather than changing it to start with the extract case.
> Are you, or Lance, going to create the CSR for this?

A CSR for this enhancement has now been created https://bugs.openjdk.java.net/browse/JDK-8264510

-------------

PR: https://git.openjdk.java.net/jdk/pull/2752

From roger.riggs at oracle.com  Wed Mar 31 13:53:54 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 31 Mar 2021 09:53:54 -0400
Subject: Further review of java.util.HexFormat
In-Reply-To: <86f36fac-1de3-1191-7895-0f2bed87515b@gmail.com>
References: <86f36fac-1de3-1191-7895-0f2bed87515b@gmail.com>
Message-ID: <8d85fecc-9752-0780-253f-82829ad747c4@oracle.com>

Hi Raffaello,

None of these are substantive but useful none the less.
I would have rather seen them during the review and not be revisiting them.

Issue created: 8264514 
<https://bugs.openjdk.java.net/browse/JDK-8264514> HexFormat 
implementation tweaks

On 3/30/21 8:19 PM, Raffaello Giulietti wrote:
> Hello Roger,
>
>
> these are the changes I'm proposing after reviewing the code of 
> j.u.HexFormat. The modified code available here
> https://urldefense.com/v3/__https://github.com/rgiulietti/jdk/commit/6759a25eb952ab19a045a83349d41b82cc1b07cb__;!!GqivPVa7Brio!JLXpQq2CQ_x4RuLDCYWukMvEBq8yc6hUH8q7U0stTiQjEgvx6yn_h_2gwUMfmMgI$ 
>
> In addition to other smaller, hopefully self-explanatory enhancements, 
> here are the rationales for the changes.
>
>
> Static field DIGITS should preferably be formatted with 16 values/line 
> to ease a visual positional crosscheck with published ASCII/IsoLatin1 
> tables.
yes, but as is are easier to index using decimal values.? (20 per line 
and more compact).
>
>
> Field digits is initialized with either UPPERCASE_DIGITS, 
> LOWERCASE_DIGITS or digits from another instance, so it always ends up 
> being either UPPERCASE_DIGITS or LOWERCASE_DIGITS.
> Consequently:
> * There's no need for requireNonNull() check in the (sole) private 
> constructor.
> * It's preferable to move the last comparison in method equals() as 
> the first factor in the return statement, so it can return faster in 
> case of a lower/upper mismatch. (Arrays.equals() first checks for ==, 
> so it always returns fast as used in this class. It could even be 
> replaced by a simple == )
Though perhaps less intuitive and not performance sensitive.
>
>
> Method fromHexDigits(CharSequence, int) either returns a value in the 
> range [0x00..0xff] or throws.
> Therefore, there's no need for the checks leading to the throwing of 
> IllegalArgumentException in methods
> * parseHex(CharSequence, int, int)
> * parseNoDelimiter(CharSequence)
> which can be simplified as a consequence.
The private fromHexDigits method did not originally throw.
An @throws ILE should be added
>
>
> The test for IllegalArgumentException in method parseHex(CharSequence, 
> int, int), namely
> string.length() < valueChars || (string.length() - valueChars) % 
> stride != 0
> can be simplified as
> (string.length() - valueChars) % stride != 0
>
> Indeed, at this point in the control flow we have
> string.length() > 0? and? stride >= valueChars
> Assuming string.length() < valueChars as in the left operand of || we 
> then have
> -stride <= -valueChars < string.length() - valueChars < 0
> so
> string.length() - valueChars) % stride != 0
> which is the right operand of ||.
> In other words, the left operand always implies the right one, adding 
> nothing to it.
>
>
> There's no need to check again for non-nullness in private method 
> fromHexDigits(CharSequence, int). It is invoked from two places where 
> the check is already performed.
Though the checking seems redundant it documents the requirement.
The hotspot compiler squashes out any redundancy, so there is no 
performance impact.
>
>
> Both fromHexDigits(CharSequence) and fromHexDigitsToLong(CharSequence) 
> can simply invoke their 3 args counterparts.
At a slightly higher overhead to add the offset.
>
>
> If you prefer, I can prepare a PR once there's an issue in the bug 
> system to associate the PR with.
>

Thanks, Roger

>
> Greetings
> Raffaello


From douglas.surber at oracle.com  Wed Mar 31 14:23:43 2021
From: douglas.surber at oracle.com (Douglas Surber)
Date: Wed, 31 Mar 2021 14:23:43 +0000
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <mailman.10128.1617167439.17574.core-libs-dev@openjdk.java.net>
References: <mailman.10128.1617167439.17574.core-libs-dev@openjdk.java.net>
Message-ID: <B9390F44-C669-4E1C-9E19-63E7BAA65284@oracle.com>

+1

JDBC would support this immediately. All it would take is the addition of a couple of lines in some appendices to require that conforming implementations of getObject(int, Class), setObject(int, Object, SQLType), etc support Decimal64 and Decimal128. No change to the API required. Driver vendors could add this support the instant the types are available, no need to wait for a change in the JDBC spec.

This would be a huge win for many Java apps. A large fraction of Java apps deal with money in some form. Binary floats are inappropriate for money and BigDecimal is too big and too slow.

Rather than waiting on Valhala I would prefer that this project be fast tracked and added to OpenJDK ASAP.

Thanks for doing this.

Douglas

On Mar 30, 2021, at 10:10 PM, core-libs-dev-request at openjdk.java.net<mailto:core-libs-dev-request at openjdk.java.net> wrote:

Date: Tue, 30 Mar 2021 22:12:32 -0400
From: Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com>>
To: Raffaello Giulietti <raffaello.giulietti at gmail.com<mailto:raffaello.giulietti at gmail.com>>, Paul Sandoz
<paul.sandoz at oracle.com<mailto:paul.sandoz at oracle.com>>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net>>
Subject: Re: Proposal for Decimal64 and Decimal128 value-based classes
Message-ID: <64334a24-0e4c-57b8-b666-447ca3508ce5 at oracle.com<mailto:64334a24-0e4c-57b8-b666-447ca3508ce5 at oracle.com>>
Content-Type: text/plain; charset=utf-8; format=flowed

They'll find a natural home in JDBC, since SQL has a native decimal type.

On 3/30/2021 7:05 PM, Raffaello Giulietti wrote:

As far as I can tell, scientific computation will make use of binary
floating point numbers for a long time. Decimal floating point numbers
are still limited to biz and fin applications.



From lance.andersen at oracle.com  Wed Mar 31 14:39:00 2021
From: lance.andersen at oracle.com (Lance Andersen)
Date: Wed, 31 Mar 2021 14:39:00 +0000
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <B9390F44-C669-4E1C-9E19-63E7BAA65284@oracle.com>
References: <mailman.10128.1617167439.17574.core-libs-dev@openjdk.java.net>
 <B9390F44-C669-4E1C-9E19-63E7BAA65284@oracle.com>
Message-ID: <6DD1C81C-CF18-4A35-8F15-EF18DDF46911@oracle.com>

Agree this could be beneficial to JDBC users.  To officially support this in JDBC would require an MR but as Douglas indicates  the work required to the JDBC spec would be minimal

Best
Lance

On Mar 31, 2021, at 10:23 AM, Douglas Surber <douglas.surber at oracle.com<mailto:douglas.surber at oracle.com>> wrote:

+1

JDBC would support this immediately. All it would take is the addition of a couple of lines in some appendices to require that conforming implementations of getObject(int, Class), setObject(int, Object, SQLType), etc support Decimal64 and Decimal128. No change to the API required. Driver vendors could add this support the instant the types are available, no need to wait for a change in the JDBC spec.

This would be a huge win for many Java apps. A large fraction of Java apps deal with money in some form. Binary floats are inappropriate for money and BigDecimal is too big and too slow.

Rather than waiting on Valhala I would prefer that this project be fast tracked and added to OpenJDK ASAP.

Thanks for doing this.

Douglas

On Mar 30, 2021, at 10:10 PM, core-libs-dev-request at openjdk.java.net<mailto:core-libs-dev-request at openjdk.java.net><mailto:core-libs-dev-request at openjdk.java.net> wrote:

Date: Tue, 30 Mar 2021 22:12:32 -0400
From: Brian Goetz <brian.goetz at oracle.com<mailto:brian.goetz at oracle.com><mailto:brian.goetz at oracle.com>>
To: Raffaello Giulietti <raffaello.giulietti at gmail.com<mailto:raffaello.giulietti at gmail.com><mailto:raffaello.giulietti at gmail.com>>, Paul Sandoz
<paul.sandoz at oracle.com<mailto:paul.sandoz at oracle.com><mailto:paul.sandoz at oracle.com>>
Cc: core-libs-dev <core-libs-dev at openjdk.java.net<mailto:core-libs-dev at openjdk.java.net><mailto:core-libs-dev at openjdk.java.net>>
Subject: Re: Proposal for Decimal64 and Decimal128 value-based classes
Message-ID: <64334a24-0e4c-57b8-b666-447ca3508ce5 at oracle.com<mailto:64334a24-0e4c-57b8-b666-447ca3508ce5 at oracle.com><mailto:64334a24-0e4c-57b8-b666-447ca3508ce5 at oracle.com>>
Content-Type: text/plain; charset=utf-8; format=flowed

They'll find a natural home in JDBC, since SQL has a native decimal type.

On 3/30/2021 7:05 PM, Raffaello Giulietti wrote:

As far as I can tell, scientific computation will make use of binary
floating point numbers for a long time. Decimal floating point numbers
are still limited to biz and fin applications.



[cid:E1C4E2F0-ECD0-4C9D-ADB4-B16CA7BCB7FC at home]



Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering
1 Network Drive
Burlington, MA 01803
Lance.Andersen at oracle.com<mailto:Lance.Andersen at oracle.com>




From maurizio.cimadamore at oracle.com  Wed Mar 31 15:01:31 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 31 Mar 2021 16:01:31 +0100
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <B9390F44-C669-4E1C-9E19-63E7BAA65284@oracle.com>
References: <mailman.10128.1617167439.17574.core-libs-dev@openjdk.java.net>
 <B9390F44-C669-4E1C-9E19-63E7BAA65284@oracle.com>
Message-ID: <2cdb04af-ba29-2792-4b35-573288fffe9b@oracle.com>


On 31/03/2021 15:23, Douglas Surber wrote:
> Rather than waiting on Valhala I would prefer that this project be fast tracked and added to OpenJDK ASAP.

There is a catch here.

While in principle, we can add these as value-based classes, and migrate 
to Valhalla later, there is a biggie difference between doing it 
before/after.

When it comes to "migrated" primitive classes, there is a choice in how 
to interpret the "old" utterances of the class name. Let's say that 
class Foo is migrated to be a primitive class; does that mean that all 
uses of Foo in existing program will automatically get flattening? Or 
will references to Foo be interpreted in a conservative fashion, so? as 
to allow the same operations as before? One important difference in 
semantics is assignment to `null` which is prohibited under flattened 
semantics, but allowed under "indirect" (or by reference, if you will) 
semantics.

In other words, under the current plan, if Decimal128 is added now and 
migrated later, utterances of Decimal128 will behave like they used to 
pre-Valhalla, and, to take advantage of flattening you would need to 
opt-in with some keyword (e.g. Decimal128.val).

To me this is kind of a strong argument against going with these classes 
now (as much as I understand how useful they'd be even w/o Valhalla) - 
and preserving the "good" name (Decimal128) for the flattened case seems 
worth, IMHO, waiting few more cycles.

Maurizio


From bpb at openjdk.java.net  Wed Mar 31 15:45:27 2021
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 31 Mar 2021 15:45:27 GMT
Subject: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]
In-Reply-To: <FRumAE8XsRLP6iTloWT_T1HlAxsSMZNRyAXm75VxBl4=.ec5dbbbe-d25e-426e-bf72-14572729be5d@github.com>
References: <cI2Haf-RY2Hhea8pOevcFdWSj4fqoeCMfMPLRb203IA=.d0f2f187-e1a3-4172-afd5-360723544cbb@github.com>
 <FRumAE8XsRLP6iTloWT_T1HlAxsSMZNRyAXm75VxBl4=.ec5dbbbe-d25e-426e-bf72-14572729be5d@github.com>
Message-ID: <zd89zKUnTBrIJM2XnK_eLA2LVKKgudlvsSHIB78RLXA=.f03d85bf-77f7-4648-b466-df1f7ef5a5b5@github.com>

On Wed, 31 Mar 2021 11:15:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Add more logging to the LargeCopyWithMark.java test, to gather more information when this test fails with OOME. 
>> 
>> The intention is to gather more info for JDK-8239089.
>> 
>> I consider this patch trivial, and expect to push it after I've gotten one Review.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review Alan

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/3282

From lancea at openjdk.java.net  Wed Mar 31 15:57:13 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 31 Mar 2021 15:57:13 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a
 directory [v3]
In-Reply-To: <wJWTT4pJBi4VAIR8MpsVhzm_9iy42ehwzec9JxHXHsc=.5b981f07-a864-4f53-baa4-00df1116c73a@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <wJWTT4pJBi4VAIR8MpsVhzm_9iy42ehwzec9JxHXHsc=.5b981f07-a864-4f53-baa4-00df1116c73a@github.com>
Message-ID: <dMjYy1GsCRKWd1GE9BIIkE7OJDU0Cazk3q8bld_oXCw=.9e1e85e0-7753-4fab-8c32-4f9e8665a0c4@github.com>

On Mon, 29 Mar 2021 14:04:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
>> 
>> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
>> 
>> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Alan's review feedback for -C help text
>  - Keep -xfP backward compatible but don't allow -C/--dir with -xfP

Hi Jaikiran

Overall this looks good.  I have a few comments below and will look at the CSR shortly.

src/jdk.jartool/share/classes/sun/tools/jar/Main.java line 1427:

> 1425:             return rc;    // leading '/' or 'dot-dot' only path
> 1426:         }
> 1427:         File f = new File(xdestDir, name.replace('/', File.separatorChar));

Could you please add a comment regarding xdestDir and also correct the typo on line 1418 'requres' -> 'requires'

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 62:

> 60:         Could not create a temporary file
> 61: error.extract.multiple.dest.dir=\
> 62:         You may not specify more than one directory for extracting the jar

Perhaps something similar to:

You may not specify  the  '-C' or '--dir' option more than once with the '-x' option

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 64:

> 62:         You may not specify more than one directory for extracting the jar
> 63: error.extract.pflag.not.allowed=\
> 64:         -P option cannot be used when extracting a jar to a specific location

Perhaps something similar to

You may not specify '-Px'  with the '-C' or '--dir' options

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 167:

> 165:         (in = {0}) (out= {1})
> 166: out.extract.dir=\
> 167:         extracting to {0}

Perhaps 'Extracting to directory: {0}'

src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 249:

> 247: \  -C DIR                     Change to the specified directory and include the\n\
> 248: \                             following file. When used in extract mode, extracts\n\
> 249: \                             the jar to the specified directory

Should this be updated on line 187 as well in the compatibility mode section?

test/jdk/tools/jar/JarExtractTest.java line 152:

> 150:         return abs;
> 151:     }
> 152: 

Please add a comment to each test giving a high level overview of what it does as it will help future maintainers

test/jdk/tools/jar/JarExtractTest.java line 307:

> 305:         // make sure only the specific files were extracted
> 306:         final Stream<Path> paths = Files.walk(Path.of(tmpDir));
> 307:         Assert.assertEquals(paths.count(), 6, "Unexpected number of files/dirs in " + tmpDir);

Should '6' be in a local variable to make it clearer or at a minimum a comment

test/jdk/tools/jar/JarExtractTest.java line 367:

> 365:     }
> 366: 
> 367:     private static Path createJarWithPFlagSemantics() throws IOException {

Perhaps add a comment as to what the method does

-------------

PR: https://git.openjdk.java.net/jdk/pull/2752

From psandoz at openjdk.java.net  Wed Mar 31 16:45:26 2021
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 31 Mar 2021 16:45:26 GMT
Subject: RFR: 8264109: Add vectorized implementation for
 VectorMask.andNot()
In-Reply-To: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
References: <gd_UPiCd0TIukDJGuJ1nBQtHSNRKXRa5c9e6GPBEOps=.3338faaf-5835-4335-aa3a-822962ed6888@github.com>
Message-ID: <4nYUWzXPdlo6tL9f4j7pTj8ArbRtFSZEHRae7P17UBE=.0d1f8bd8-ff98-49a5-b6d7-d5a4856bcaf0@github.com>

On Fri, 26 Mar 2021 01:50:33 GMT, Xiaohong Gong <xgong at openjdk.org> wrote:

> Currently "VectorMask.andNot()" is not vectorized:
>     public VectorMask<E> andNot(VectorMask<E> m) {
>         // FIXME: Generate good code here.
>         return bOp(m, (i, a, b) -> a && !b);
>     }
> This can be implemented with` "and(m.not())" `directly. Since `"VectorMask.and()/not()" `have been vectorized in hotspot, `"andNot"`
> can be vectorized as well by calling them.
> 
> The performance gain is >100% for such a simple JMH:
>   @Benchmark
>   public Object andNot(Blackhole bh) {
>     boolean[] mask = fm.apply(SPECIES.length());
>     boolean[] r = fmt.apply(SPECIES.length());
>     VectorMask<Byte> rm = VectorMask.fromArray(SPECIES, r, 0);
> 
>     for (int ic = 0; ic < INVOC_COUNT; ic++) {
>       for (int i = 0; i < mask.length; i += SPECIES.length()) {
>         VectorMask<Byte> vmask = VectorMask.fromArray(SPECIES, mask, i);
>           rm = rm.andNot(vmask);
>         }
>     }
>     return rm;
>   }

Would you mind updating the existing `AbstractMask.andNot` implementation? rather than changing `VectorMask.andNot`. That fits in with the current implementation pattern.

-------------

PR: https://git.openjdk.java.net/jdk/pull/3211

From douglas.surber at oracle.com  Wed Mar 31 16:46:01 2021
From: douglas.surber at oracle.com (Douglas Surber)
Date: Wed, 31 Mar 2021 16:46:01 +0000
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <2cdb04af-ba29-2792-4b35-573288fffe9b@oracle.com>
References: <mailman.10128.1617167439.17574.core-libs-dev@openjdk.java.net>
 <B9390F44-C669-4E1C-9E19-63E7BAA65284@oracle.com>
 <2cdb04af-ba29-2792-4b35-573288fffe9b@oracle.com>
Message-ID: <CE4E78D6-E694-4CE6-A628-6068891C8264@oracle.com>

I'm sure this would be a huge disruption, but I'll throw it out anyway. I'd be perfectly happy if assigning null to a Decimal64/128 container was not allowed, whether it is a reference or a value.

I haven't followed the progress of Valhalla closely. It would be reasonable to delay Decimal64/128 until Valhalla so long as that isn't more than a very few cycles. My concern is that Valhalla is a challenging project. I would not want Decimal64/128 to get hung up because Valhalla is delayed or even worse canceled.

Douglas

> On Mar 31, 2021, at 8:01 AM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> 
> On 31/03/2021 15:23, Douglas Surber wrote:
>> Rather than waiting on Valhala I would prefer that this project be fast tracked and added to OpenJDK ASAP.
> 
> There is a catch here.
> 
> While in principle, we can add these as value-based classes, and migrate to Valhalla later, there is a biggie difference between doing it before/after.
> 
> When it comes to "migrated" primitive classes, there is a choice in how to interpret the "old" utterances of the class name. Let's say that class Foo is migrated to be a primitive class; does that mean that all uses of Foo in existing program will automatically get flattening? Or will references to Foo be interpreted in a conservative fashion, so  as to allow the same operations as before? One important difference in semantics is assignment to `null` which is prohibited under flattened semantics, but allowed under "indirect" (or by reference, if you will) semantics.
> 
> In other words, under the current plan, if Decimal128 is added now and migrated later, utterances of Decimal128 will behave like they used to pre-Valhalla, and, to take advantage of flattening you would need to opt-in with some keyword (e.g. Decimal128.val).
> 
> To me this is kind of a strong argument against going with these classes now (as much as I understand how useful they'd be even w/o Valhalla) - and preserving the "good" name (Decimal128) for the flattened case seems worth, IMHO, waiting few more cycles.
> 
> Maurizio
> 


From stefank at openjdk.java.net  Wed Mar 31 16:46:18 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 31 Mar 2021 16:46:18 GMT
Subject: Integrated: 8264489: Add more logging to LargeCopyWithMark.java
In-Reply-To: <cI2Haf-RY2Hhea8pOevcFdWSj4fqoeCMfMPLRb203IA=.d0f2f187-e1a3-4172-afd5-360723544cbb@github.com>
References: <cI2Haf-RY2Hhea8pOevcFdWSj4fqoeCMfMPLRb203IA=.d0f2f187-e1a3-4172-afd5-360723544cbb@github.com>
Message-ID: <s2MKdFqFlE3-M2y8Yz41-S1M0J5SMMddxbOcHped5Pg=.2b5403cc-c42f-47d1-a9c9-5946c797c5b6@github.com>

On Wed, 31 Mar 2021 06:56:23 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> Add more logging to the LargeCopyWithMark.java test, to gather more information when this test fails with OOME. 
> 
> The intention is to gather more info for JDK-8239089.
> 
> I consider this patch trivial, and expect to push it after I've gotten one Review.

This pull request has now been integrated.

Changeset: 0fa35728
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0fa35728
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8264489: Add more logging to LargeCopyWithMark.java

Reviewed-by: kbarrett, alanb, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/3282

From stefank at openjdk.java.net  Wed Mar 31 16:46:17 2021
From: stefank at openjdk.java.net (Stefan Karlsson)
Date: Wed, 31 Mar 2021 16:46:17 GMT
Subject: RFR: 8264489: Add more logging to LargeCopyWithMark.java [v2]
In-Reply-To: <zd89zKUnTBrIJM2XnK_eLA2LVKKgudlvsSHIB78RLXA=.f03d85bf-77f7-4648-b466-df1f7ef5a5b5@github.com>
References: <cI2Haf-RY2Hhea8pOevcFdWSj4fqoeCMfMPLRb203IA=.d0f2f187-e1a3-4172-afd5-360723544cbb@github.com>
 <FRumAE8XsRLP6iTloWT_T1HlAxsSMZNRyAXm75VxBl4=.ec5dbbbe-d25e-426e-bf72-14572729be5d@github.com>
 <zd89zKUnTBrIJM2XnK_eLA2LVKKgudlvsSHIB78RLXA=.f03d85bf-77f7-4648-b466-df1f7ef5a5b5@github.com>
Message-ID: <70AzSrvNILDjmfO1UT6FPLio6PBCAdavBT0ZSHExf6I=.61a45778-bd87-4fe3-b2ef-4b7e2e93539d@github.com>

On Wed, 31 Mar 2021 15:42:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review Alan
>
> Marked as reviewed by bpb (Reviewer).

Thanks for reviewing!

-------------

PR: https://git.openjdk.java.net/jdk/pull/3282

From roger.riggs at oracle.com  Wed Mar 31 17:03:54 2021
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 31 Mar 2021 13:03:54 -0400
Subject: Insufficiencies in JEP: 400: UTF-8 by Default
In-Reply-To: <68f7-60635a00-175-6401b300@35209972>
References: <68f7-60635a00-175-6401b300@35209972>
Message-ID: <15dd248e-c0a6-f04a-c573-33548f23397c@oracle.com>

Hi Anthony,

A draft of updates to the Process API is in the works and covers improving
the ease of use and providing Readers and Writers.? Note that if process 
output
is redirected to a file, it does not interpose on the byte streams and 
is not in
a position to affect the character set used by the child process.

Regards, Roger


On 3/30/21 1:03 PM, Anthony Vanelverdinghe wrote:
> Hi Alan
>
> As Marco mentioned, another use case is sub-process stdin/stdout/stderr. In my particular instance, I'm starting a Process which has its output redirected to a file. It uses the platform's default encoding for writing to stdout. So when I want to read its output from the file at some later point, I need to supply that encoding to the Files API.
> One way to accommodate this use case, is a method which allows to retrieve the platform's default encoding, for example a method `platformEncoding` in Charset or Process, or the `Console::charset` method you mentioned. Another option would be to enhance the Process API, by adding methods to Process which return appropriate Readers/Writers & adding methods of the form `redirectX(File file, Charset encoding)` to ProcessBuilder. But this seems like a lot of additional API surface, just to avoid surfacing the platform's default encoding itself.
> So I think the JEP should specify how it'll address use cases w.r.t. the Process API, shouldn't it?
>
> Kind regards,
> Anthony
>   
> On Sunday, March 14, 2021 13:01 CET, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>   
>> On 14/03/2021 11:00, Marco wrote:
>>> :
>>>
>>> IMO Charset should provide standardized getters for the OS charset and the
>>> console charset. The latter being different has been a long standing issue on
>>> Windows where the codepage differs between its CLI and regular environments.
>>> OpenJDK has the necessary data already available in its custom system
>>> properties.
>>>
>>> The console charset is currently hidden behind PrintStream not exposing the
>>> underlying OSWriter and not offering getEncoding() itself. The OS charset
>>> would be hidden in the future by Charset.getDefaultCharset()'s specification
>>> change in JEP 400.
>> The intention that there will be little or no impact to the console
>> streams. This means that java.io.Console reader/writer methods should
>> continue to return a Reader/PrintWriter that uses the platform encoding
>> (or code page is on Windows). Same thing for the System.out/System.err
>> print streams. We need to make this clearer in the JEP.
>>
>> There has been discussion on this mailing list about adding a
>> Console::charset method but it didn't come to a consensus. Naoto Sato
>> and I have been chatting about it again recently as there may be a need
>> to add an API in advance of proposing to target the JEP.
>>
>> One case that we are still mulling over is code that creates an
>> InputStreamReader on System.in without specifying the charset. This
>> might be older code that pre-dates java.io.Console or maybe code that
>> wasn't tested on a wide range or platforms. Options range from a spec
>> change to doing nothing (the latter meaning running with "COMPACT" or
>> migrating the code to use the 2-arg constructor as the default charset
>> is not the right choice).
>>
>> -Alan
>>
>>
>>


From lancea at openjdk.java.net  Wed Mar 31 17:26:19 2021
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 31 Mar 2021 17:26:19 GMT
Subject: RFR: 8173970: jar tool should have a way to extract to a
 directory [v3]
In-Reply-To: <wJWTT4pJBi4VAIR8MpsVhzm_9iy42ehwzec9JxHXHsc=.5b981f07-a864-4f53-baa4-00df1116c73a@github.com>
References: <MRlQpBJcCaZSMcnssPw88TaYd2cAwiJOkfI4k8hXM0E=.76718687-c714-4d12-a03b-fa0fdb51a9ff@github.com>
 <wJWTT4pJBi4VAIR8MpsVhzm_9iy42ehwzec9JxHXHsc=.5b981f07-a864-4f53-baa4-00df1116c73a@github.com>
Message-ID: <UX_PIU0pgWPZnI_jsSBiE6w-D5KD0PQGSOORZKtRzQY=.d126b8fc-0658-4adc-b6cc-bb57e9d054ca@github.com>

On Mon, 29 Mar 2021 14:04:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review for this patch which proposes to implement the enhancement request noted in https://bugs.openjdk.java.net/browse/JDK-8173970?
>> 
>> The commit in this PR introduces the `-o` and `--output-dir` option to the `jar` command. The option takes a path to a destination directory as a value and extracts the contents of the jar into that directory. This is an optional option and the changes in the commit continue to maintain backward compatibility where the jar is extracted into current directory, if no `-o` or `--output-dir` option has been specified.
>> 
>> As far as I know, there hasn't been any discussion on what the name of this new option should be. I was initially thinking of using `-d` but that is currently used by the `jar` command for a different purpose. So I decided to use `-o` and `--output-dir`. This is of course open for change depending on any suggestions in this PR.
>> 
>> The commit in this PR also updates the `jar.properties` file which contains the English version of the jar command's `--help` output. However, no changes have been done to the internationalization files corresponding to this one (for example: `jar_de.properties`), because I don't know what process needs to be followed to have those files updated (if at all they need to be updated).
>> 
>> The commit also includes a jtreg testcase which verifies the usage of this new option.
>
> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Alan's review feedback for -C help text
>  - Keep -xfP backward compatible but don't allow -C/--dir with -xfP

Some additional comments basically suggesting that we test --extract in addition to -x

test/jdk/tools/jar/JarExtractTest.java line 175:

> 173:         final String dest = "foo-bar";
> 174:         System.out.println("Extracting " + testJarPath + " to " + dest);
> 175:         final int exitCode = JAR_TOOL.run(System.out, System.err, "-x", "-f", testJarPath.toString(),

Perhaps add a DataProvider so you can test --extract as well?

test/jdk/tools/jar/JarExtractTest.java line 216:

> 214:         final Path jarPath = createJarWithPFlagSemantics();
> 215:         // extract with -P flag without any explicit destination directory (expect the extraction to work fine)
> 216:         final String[] args = new String[]{"-xvfP", jarPath.toString()};

Perhaps add a DataProvider so you can test --extract as well?

test/jdk/tools/jar/JarExtractTest.java line 239:

> 237:      */
> 238:     @Test
> 239:     public void testExtractWithDirPFlagNotAllowed() throws Exception {

I would include --extract in your testing options

test/jdk/tools/jar/JarExtractTest.java line 240:

> 238:     @Test
> 239:     public void testExtractWithDirPFlagNotAllowed() throws Exception {
> 240:         final String expectedErrMsg = "-P option cannot be used when extracting a jar to a specific location";

Probably need to add a comment that this must match the entry in jar.properties

test/jdk/tools/jar/JarExtractTest.java line 247:

> 245:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "-P", "-C", "."});
> 246:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "-P", "--dir", "."});
> 247:         cmdArgs.add(new String[]{"-xvfP", testJarPath.toString(), "-C", tmpDir});

Perhaps add a DataProvider so you can test --extract as well?

test/jdk/tools/jar/JarExtractTest.java line 262:

> 260:      */
> 261:     @Test
> 262:     public void testLegacyCompatibilityMode() throws Exception {

Perhaps add a DataProvider so you can test --extract as well?

test/jdk/tools/jar/JarExtractTest.java line 282:

> 280:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "-C", tmpDir, "-C", tmpDir});
> 281:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "--dir", tmpDir, "--dir", tmpDir});
> 282:         cmdArgs.add(new String[]{"-x", "-f", testJarPath.toString(), "--dir", tmpDir, "-C", tmpDir});

Perhaps use a DataProvider so you can test --extract as well?

test/jdk/tools/jar/JarExtractTest.java line 300:

> 298:     public void testExtractPartialContent() throws Exception {
> 299:         final String tmpDir = Files.createTempDirectory(Path.of("."), "8173970-").toString();
> 300:         final String[] cmdArgs = new String[]{"-x", "-f", testJarPath.toString(), "--dir", tmpDir,

Perhaps add a DataProvider so you can test --extract as well?

test/jdk/tools/jar/JarExtractTest.java line 332:

> 330:      */
> 331:     private void testExtract(final String dest) throws Exception {
> 332:         final String[] args = new String[]{"-x", "-f", testJarPath.toString(), "-C", dest};

Perhaps add a DataProvider so you can test --extract as well?

-------------

PR: https://git.openjdk.java.net/jdk/pull/2752

From bchristi at openjdk.java.net  Wed Mar 31 17:34:18 2021
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 31 Mar 2021 17:34:18 GMT
Subject: RFR: 8264048: Fix caching in Jar URL connections when an entry is
 missing [v2]
In-Reply-To: <D8au5a1Xx4NlUqMVWmU3XZJ8W03xN3oVJxgfajzfpS4=.f2db26da-357b-4591-9cd6-1e3ffaf91154@github.com>
References: <1n33RkwMvQZNEeyHOmPjK9UUNp9hc5esxRwL00sT_IM=.45c6aa6e-39c1-4048-b05e-9a6aa765469e@github.com>
 <D8au5a1Xx4NlUqMVWmU3XZJ8W03xN3oVJxgfajzfpS4=.f2db26da-357b-4591-9cd6-1e3ffaf91154@github.com>
Message-ID: <zpy5blScTPGJeNKdM4LhuBOgyw8qzlwuq78xFMzs22M=.d66c47db-150f-402e-ac8a-30aedc5a9777@github.com>

On Wed, 31 Mar 2021 12:47:50 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Current fix tries to tackle an issue with URL connection referencing non-existing Jar file entries:
>> If an entry that doesn't exist is specified in an URL connection the underlying Jar file is still cached even if an exception is thrown after that. Such behavior prevents the caller, for instance, a `URLClassLoader`, from closing a Jar file.
>> 
>> The proposed fix checks if entry exists before caching a Jar file (only for cases with enabled caching):
>> - If entry exists - jar file is cached if it wasn't cached before
>> - If entry doesn't exist and jar file wasn't cached before - jar file is closed and exception is thrown
>> - If entry doesn't exist and jar file was cached before - jar file is kept cached and exception is thrown
>> 
>> 
>> The following tests have been used to verify the fix:
>> - New regression tests
>> - ``:jdk_core:`` tests
>> - `api/java_util`,`api/java_net` JCK tests
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8264048: Remove old version of RemoveJar test

Hi, Aleksei.  The change looks good.

-------------

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/3263

From raffaello.giulietti at gmail.com  Wed Mar 31 20:13:55 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 31 Mar 2021 22:13:55 +0200
Subject: Proposal for Decimal64 and Decimal128 value-based classes
Message-ID: <da11a680-3ba3-6081-cdfb-57f1825d9281@gmail.com>

Hi,

I think there's a misunderstanding about the nature of IEEE 754 
Decimal<n> (e.g., Decimal64), the subject of this thread, and the nature 
of SQL DECIMAL(p, s).

SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an 
overall maximum precision p and a scale s, the number of digits to the 
right of the decimal point (both parameters can be selected freely 
inside some ranges). For example, DECIMAL(2, 1) can represent only the 
values
     -9.9, -9.8, ..., 9.8, 9.9
and that's it.
Thus, the sum 6.6 + 7.7 overflows, as well as the product 2.9 * 4.

IEEE decimals are *floating* point decimal numbers. A hypothetical 
decimal of precision 2 can represent values of the form c*10^q, where 
integer c meets |c| < 100 (that is, max two digits) and integer q is 
limited in some range. It covers the values above and much more, for 
example, 0.012 (=12*10^(-3)) and -3.4E2 (=-34*10^1).
The sum 6.6 + 7.7 produces 14 because the mathematical result 14.3 is 
rounded to the closest number of precision 2 (assuming 
RoundingMode.HALF_EVEN). By the same token, the product 2.9 * 4 produces 
12, which is 11.6 rounded to 2 digits.
But really, the position of the decimal point is floating.

IEEE decimals and SQL decimals are fundamentally different and ave 
different arithmetic, so I wouldn't recommend using the proposed classes 
for JDBC.

On the positive side, SQL decimals, are easier to implement if the 
maximum allowed p in DECIMAL(p, s) is reasonable, say 38. But that's 
another topic.


Greetings
Raffaello

From herrick at openjdk.java.net  Wed Mar 31 20:22:30 2021
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 31 Mar 2021 20:22:30 GMT
Subject: RFR: JDK-8264403: [macos]: App names containing '.' characters
 results in an error message when launching
Message-ID: <PRvADLA7cdiYRji-WMZxuTYtaL0dIh2EWpybtFIrIXk=.db04951c-7eaf-469f-ae15-cb00f06d6678@github.com>

Deriving the cfg file name is broken on mac and linux when the application name has a "." in it.

-------------

Commit messages:
 - Merge branch 'master' into JDK-8264403
 - JDK-8264403: [macos]: App names containing '.' characters results in an error message when launching
 - 8264466: Cut-paste error in InterfaceCalls JMH
 - 8264149: BreakpointInfo::set allocates metaspace object in VM thread
 - 8264417: ParallelCompactData::region_offset should not accept pointers outside the current region
 - 8264112: (fs) Reorder methods/constructor/fields in UnixUserDefinedFileAttributeView.java
 - 8261957: [PPC64] Support for Concurrent Thread-Stack Processing
 - 8262894: [macos_aarch64] SIGBUS in Assembler::ld_st2
 - 8263582: WB_IsMethodCompilable ignores compiler directives
 - 8244540: Print more information with -XX:+PrintSharedArchiveAndExit
 - ... and 65 more: https://git.openjdk.java.net/jdk/compare/6225ae63...1fe2699e

Changes: https://git.openjdk.java.net/jdk/pull/3288/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3288&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264403
  Stats: 82 lines in 5 files changed: 80 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3288.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3288/head:pull/3288

PR: https://git.openjdk.java.net/jdk/pull/3288

From raffaello.giulietti at gmail.com  Wed Mar 31 20:43:25 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 31 Mar 2021 22:43:25 +0200
Subject: Proposal for Decimal64 and Decimal128 value-based classes
Message-ID: <10e8c9d1-fd93-5f34-d4cf-0d6e044b8501@gmail.com>

Ciao Maurizio,

admittedly, yours is a fairly convincing argument to wait for the 
completion of Valhalla, or at least JEP 401.

Personally, I wouldn't mind having to denote the primitive class as 
Decimal128.val in some future (2022? 2023? who knows?) if I could use 
Decimal128 tomorrow, but I understand your concerns in defending the 
interests of the community at large (which includes myself).


Greetings
Raffaello


> On 31/03/2021 15:23, Douglas Surber wrote:
>> Rather than waiting on Valhala I would prefer that this project be fast tracked and added to OpenJDK ASAP.
> 
> There is a catch here.
> 
> While in principle, we can add these as value-based classes, and migrate 
> to Valhalla later, there is a biggie difference between doing it 
> before/after.
> 
> When it comes to "migrated" primitive classes, there is a choice in how 
> to interpret the "old" utterances of the class name. Let's say that 
> class Foo is migrated to be a primitive class; does that mean that all 
> uses of Foo in existing program will automatically get flattening? Or 
> will references to Foo be interpreted in a conservative fashion, so  as 
> to allow the same operations as before? One important difference in 
> semantics is assignment to `null` which is prohibited under flattened 
> semantics, but allowed under "indirect" (or by reference, if you will) 
> semantics.
> 
> In other words, under the current plan, if Decimal128 is added now and 
> migrated later, utterances of Decimal128 will behave like they used to 
> pre-Valhalla, and, to take advantage of flattening you would need to 
> opt-in with some keyword (e.g. Decimal128.val).
> 
> To me this is kind of a strong argument against going with these classes 
> now (as much as I understand how useful they'd be even w/o Valhalla) - 
> and preserving the "good" name (Decimal128) for the flattened case seems 
> worth, IMHO, waiting few more cycles.
> 
> Maurizio


From igraves at openjdk.java.net  Wed Mar 31 20:45:32 2021
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 31 Mar 2021 20:45:32 GMT
Subject: RFR: 8037397: Lost nested character class after intersection &&
Message-ID: <egL7LpLIAIKszVGyTyewrG0bhyQROotDgcEo4U8kEHE=.f7c19955-98da-48e6-a976-d5bbb71339ce@github.com>

Bug fix with the intersection `&&` operator in regex patterns. In JDK-8037397, some character classes on the right hand side of the operator are dropped in cases where nested `[..]` classes are used with non "nested" ones.

-------------

Commit messages:
 - Fixing a regex intersection bug that drops expressions on the right hand side

Changes: https://git.openjdk.java.net/jdk/pull/3291/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3291&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8037397
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3291.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3291/head:pull/3291

PR: https://git.openjdk.java.net/jdk/pull/3291

From douglas.surber at oracle.com  Wed Mar 31 20:53:09 2021
From: douglas.surber at oracle.com (Douglas Surber)
Date: Wed, 31 Mar 2021 20:53:09 +0000
Subject: [External] : Re: Proposal for Decimal64 and Decimal128
 value-based classes
In-Reply-To: <da11a680-3ba3-6081-cdfb-57f1825d9281@gmail.com>
References: <da11a680-3ba3-6081-cdfb-57f1825d9281@gmail.com>
Message-ID: <6ADB5D12-E66D-4797-B09B-DF3CB4BE1D10@oracle.com>

Understood. The problem is that right now the only appropriate type for non-integer SQL numbers is BigDecimal. It's too big and too slow and lots of users avoid it. 

Decimal128 supports 34 significant digits. The max precision of SQL numeric types varies from vendor to vendor. In SQL Server it is 38. In MySQL it is 65. So there are a huge range of values representable in SQL that are not representable in Decimal128. BUT, for the vast majority of applications that might be tempted to use Decimal128, those non-representable numbers don't occur. Currency amounts exceeding 34 decimal digits of precision are an almost non-existent minority.

Very few apps will pay the price of using BigDecimal even though it would support huge numbers exactly. Instead they find workarounds that are more efficient. Decimal128 would be a substantial improvement for those apps.

Douglas

> On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti <raffaello.giulietti at gmail.com> wrote:
> 
> Hi,
> 
> I think there's a misunderstanding about the nature of IEEE 754 Decimal<n> (e.g., Decimal64), the subject of this thread, and the nature of SQL DECIMAL(p, s).
> 
> SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an overall maximum precision p and a scale s, the number of digits to the right of the decimal point (both parameters can be selected freely inside some ranges). For example, DECIMAL(2, 1) can represent only the values
>    -9.9, -9.8, ..., 9.8, 9.9
> and that's it.
> Thus, the sum 6.6 + 7.7 overflows, as well as the product 2.9 * 4.
> 
> IEEE decimals are *floating* point decimal numbers. A hypothetical decimal of precision 2 can represent values of the form c*10^q, where integer c meets |c| < 100 (that is, max two digits) and integer q is limited in some range. It covers the values above and much more, for example, 0.012 (=12*10^(-3)) and -3.4E2 (=-34*10^1).
> The sum 6.6 + 7.7 produces 14 because the mathematical result 14.3 is rounded to the closest number of precision 2 (assuming RoundingMode.HALF_EVEN). By the same token, the product 2.9 * 4 produces 12, which is 11.6 rounded to 2 digits.
> But really, the position of the decimal point is floating.
> 
> IEEE decimals and SQL decimals are fundamentally different and ave different arithmetic, so I wouldn't recommend using the proposed classes for JDBC.
> 
> On the positive side, SQL decimals, are easier to implement if the maximum allowed p in DECIMAL(p, s) is reasonable, say 38. But that's another topic.
> 
> 
> Greetings
> Raffaello


From raffaello.giulietti at gmail.com  Wed Mar 31 21:17:48 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Wed, 31 Mar 2021 23:17:48 +0200
Subject: [External] : Re: Proposal for Decimal64 and Decimal128
 value-based classes
In-Reply-To: <6ADB5D12-E66D-4797-B09B-DF3CB4BE1D10@oracle.com>
References: <da11a680-3ba3-6081-cdfb-57f1825d9281@gmail.com>
 <6ADB5D12-E66D-4797-B09B-DF3CB4BE1D10@oracle.com>
Message-ID: <64aa0072-9c06-ae1d-4791-94f4e92b218e@gmail.com>

Hi Douglas,

yes, different vendors have different limits on the precision, the most 
extreme probably being PostgreSQL.

But apart from that, the arithmetic is different.

A better option is to implement some optimized fixed precision classes 
like SQLDecimal38 and SQLDecimal65 + a more general variable precision 
SQLDecimal. But, as I mentioned, this is something different than 
Decimal<N>.


Greetings
Raffaello



On 2021-03-31 22:53, Douglas Surber wrote:
> Understood. The problem is that right now the only appropriate type for non-integer SQL numbers is BigDecimal. It's too big and too slow and lots of users avoid it.
> 
> Decimal128 supports 34 significant digits. The max precision of SQL numeric types varies from vendor to vendor. In SQL Server it is 38. In MySQL it is 65. So there are a huge range of values representable in SQL that are not representable in Decimal128. BUT, for the vast majority of applications that might be tempted to use Decimal128, those non-representable numbers don't occur. Currency amounts exceeding 34 decimal digits of precision are an almost non-existent minority.
> 
> Very few apps will pay the price of using BigDecimal even though it would support huge numbers exactly. Instead they find workarounds that are more efficient. Decimal128 would be a substantial improvement for those apps.
> 
> Douglas
> 
>> On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti <raffaello.giulietti at gmail.com> wrote:
>>
>> Hi,
>>
>> I think there's a misunderstanding about the nature of IEEE 754 Decimal<n> (e.g., Decimal64), the subject of this thread, and the nature of SQL DECIMAL(p, s).
>>
>> SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an overall maximum precision p and a scale s, the number of digits to the right of the decimal point (both parameters can be selected freely inside some ranges). For example, DECIMAL(2, 1) can represent only the values
>>     -9.9, -9.8, ..., 9.8, 9.9
>> and that's it.
>> Thus, the sum 6.6 + 7.7 overflows, as well as the product 2.9 * 4.
>>
>> IEEE decimals are *floating* point decimal numbers. A hypothetical decimal of precision 2 can represent values of the form c*10^q, where integer c meets |c| < 100 (that is, max two digits) and integer q is limited in some range. It covers the values above and much more, for example, 0.012 (=12*10^(-3)) and -3.4E2 (=-34*10^1).
>> The sum 6.6 + 7.7 produces 14 because the mathematical result 14.3 is rounded to the closest number of precision 2 (assuming RoundingMode.HALF_EVEN). By the same token, the product 2.9 * 4 produces 12, which is 11.6 rounded to 2 digits.
>> But really, the position of the decimal point is floating.
>>
>> IEEE decimals and SQL decimals are fundamentally different and ave different arithmetic, so I wouldn't recommend using the proposed classes for JDBC.
>>
>> On the positive side, SQL decimals, are easier to implement if the maximum allowed p in DECIMAL(p, s) is reasonable, say 38. But that's another topic.
>>
>>
>> Greetings
>> Raffaello
> 

From naoto.sato at oracle.com  Wed Mar 31 21:20:55 2021
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 31 Mar 2021 14:20:55 -0700
Subject: Proposed: StringUTF16 bug fix with optimization - Part 1 of 2,
 StringUTF16 Patch
In-Reply-To: <CAPcpk_vDOjZU+VuFF75MT6i6uNxD0HZRcj0bJeG_QPhRVKTcKQ@mail.gmail.com>
References: <CAPcpk_vDOjZU+VuFF75MT6i6uNxD0HZRcj0bJeG_QPhRVKTcKQ@mail.gmail.com>
Message-ID: <836d4eed-32f1-62c2-63c5-03ad28f911a3@oracle.com>

Hi Chris,

Thank you for your contribution. I believe this can be divided into two 
parts, one is the bug in the current implementation, and the other is 
the enhancement to refactor the whole implementation for performance. I 
have created two JIRA issues for each:

https://bugs.openjdk.java.net/browse/JDK-8264544
https://bugs.openjdk.java.net/browse/JDK-8264545

The former one is really an embarassing one that I would want to fix 
right away. I think the latter one need more eyes. Comments from others 
are welcome.

Naoto

On 3/30/21 4:44 PM, Chris Johnson wrote:
> Historically, the methods currently known as "compareToCI" and
> "regionMatchesCI", and located in "java.lang.StringUTF16", have lacked
> support for Supplementary Multilingual Plane code-points. (I've seen no
> associated bug.)
> 
> On July 23, 2020 the first fix for the bug was committed. However, it
> includes two simple bugs of its own. They're not much more than typos,
> but they break some things nonetheless, as demonstrated by the unit
> tests comprising part 2 of this contribution.
> 
> (Those two bugs: In "StringUTF16.compareToCIImpl", change statements
> "cp1 -= cp1;" and "cp2 -= cp2;" to, respectively, "cp1 = -cp1;" and
> "cp2 = -cp2;", and those bugs are history.)
> 
> The fixed "compareToCI" and "regionMatchesCI" methods in this patch are
> different, however.[1] Notably:
> 
>    1. Case-insensitive UTF-16 string comparison and equality-testing is
>       2.2 to 2.9 times faster than the current methods, depending on data
>       set composition. (So, meaningfully faster, but the degree varies
>       with the strings compared.)
> 
>    2. 100% TestNG unit test coverage.
> 
>    3. A utility method, "compareCodePointsIgnoringCase", created for these
>       methods increased their performance by 24%, and could, in the future,
>       be applied easily to "StringLatin1" methods "compareToCI*", and
>       "regionMatchesCI*". (My guess is the performance gain there will be
>       smaller, but still useful.)
> 
> This patch to "StringUTF16" may appear quite large. For better or worse
> (your call, gentle reader), the vast majority of it is comments. The code
> itself is minimal by comparison.
> 
> Thanks in advance for your consideration,
> 
> ----Chris
> 
> Chris W. Johnson
> chriswjohnson.jdk at gmail.com
> http://www.panojohnson.com/
> 
> 
> Footnote:
> 
> 1. Work on this code began around 4 years ago, when I failed to find a
>     bug report link on the OpenJDK page, and supposed the message to devs
>     might be something like "contribute or go away". Since then, life,
>     death, work, learning to build & test OpenJDK, registering as a
>     contributor, social anxiety, unit test development, benchmarking,
>     experimentation, and being unable to look at my own code without
>     seeing *something* to improve (especially considering it might end-up
>     in the JDK), are among the reasons for the long delay in attempting
>     this contribution.
> 
> 
> 
> 
> 
> 
> Index: src/java.base/share/classes/java/lang/StringUTF16.java
> IDEA additional info:
> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> <+>US-ASCII
> ===================================================================
> diff --git a/src/java.base/share/classes/java/lang/StringUTF16.java
> b/src/java.base/share/classes/java/lang/StringUTF16.java
> --- a/src/java.base/share/classes/java/lang/StringUTF16.java    (revision
> 60819:ee1d592a9f5389725a0338a4b5dfcf4fc3fcf20c)
> +++ b/src/java.base/share/classes/java/lang/StringUTF16.java    (revision
> 60819+:ee1d592a9f53+)
> @@ -41,7 +41,32 @@
>   import static java.lang.String.LATIN1;
> 
>   final class StringUTF16 {
> -
> +
> +    /**
> +     * Number of low-order bits storing the payload of Unicode surrogate
> code-units.
> +     * (The number of surrogate header bits is {@link Character#SIZE}
> minus this value.)
> +     */
> +    private static final int    SURROGATE_PAYLOAD_BIT_COUNT = 10;
> +
> +    /**
> +     * The high six bits common to all high-surrogate code-units (bits
> 15-10) right-shifted into bits
> +     * 5-0 of an "{@code int}" primitive. ({@code 0b1101_10**_****_****
>>>> 10 == 0b11_0110 == 0x36})
> +     */
> +    private static final int    SURROGATE_HI_HEADER_RIGHT_SHIFTED_10 =
> Character.MIN_HIGH_SURROGATE >>> SURROGATE_PAYLOAD_BIT_COUNT;  // == 0x36
> +
> +    /**
> +     * Produces a Supplementary Multilingual Plane code-point when added
> to a valid surrogate-pair
> +     * combined as follows: {@code (highSurrogate <<
> SURROGATE_PAYLOAD_BIT_COUNT) + lowSurrogate}.
> +     * The result is undefined if either would-be surrogate is invalid
> (not a surrogate code-unit,
> +     * or the wrong surrogate type [low instead of high, or vice versa]).
> +     *
> +     * @see Character#toCodePoint(char, char)
> +     */
> +    private static final int    SURROGATE_COMBO_TO_CODE_POINT_DELTA =
>   Character.MIN_SUPPLEMENTARY_CODE_POINT
> +                                                                    -
> (Character.MIN_HIGH_SURROGATE << SURROGATE_PAYLOAD_BIT_COUNT)
> +                                                                    -
>   Character.MIN_LOW_SURROGATE;  // -56_613_888
> +
> +
>       public static byte[] newBytesFor(int len) {
>           if (len < 0) {
>               throw new NegativeArraySizeException();
> @@ -318,93 +343,429 @@
>           return -StringLatin1.compareToUTF16(other, value, len2, len1);
>       }
> 
> -    public static int compareToCI(byte[] value, byte[] other) {
> -        return compareToCIImpl(value, 0, length(value), other, 0,
> length(other));
> +    /**
> +     * Compares case-insensitively UTF-16 sequences in {@code byte}
> arrays. Performs
> +     * {@linkplain #compareCodePointsIgnoringCase case conversions
> equivalent to
> +     *
> <code>Character.toLowerCase(Character.toUpperCase(codePoint))</code>} before
> +     * comparing unequal code-points.
> +     *
> +     * @param charsA array of byte pairs representing 16-bit ({@code
> char}) quantities,
> +     *               with byte order mandated by {@code
> StringUTF16.isBigEndian()}
> +     * @param charsB array of byte pairs representing 16-bit ({@code
> char}) quantities,
> +     *               with byte order mandated by {@code
> StringUTF16.isBigEndian()}
> +     *
> +     * @return negative if {@code charsA} is lexicographically less than
> {@code charsB},
> +     * positive if it is greater, or zero if they are equal
> +     */
> +    static int compareToCI
> +    (
> +        final byte[]            charsA,
> +        final byte[]            charsB
> +    ){
> +    //  Consider: If the G1 garbage collector's string-deduplication mode
> is enabled, performance may
> +    //            be improved by first testing "charsA" and "charsB" for
> reference equality, and
> +    //            returning zero in that case. However, the same is
> equally true for all invocations
> +    //            of "String.compareToIgnoreCase" (not just those
> operating on two UTF-16 strings),
> +    //            so the test belongs in that method (ideally with magic
> causing the array reference
> +    //            equality test to occur only when G1 and its
> string-deduplication mode are active).
> +    //                Similarly modifying methods
> "String.equalsIgnoreCase" and "String.equals" may be
> +    //            even more beneficial, because they already include
> "String" object reference equality
> +    //            fast-paths, unlike "String.compareToIgnoreCase".
> +    //                Indeed, string-deduplication makes reference
> equality more likely between backing-
> +    //            store arrays than "String" objects, and therefore the
> more important fast-path test,
> +    //            provided real-world use of those methods frequently
> involves "String" objects whose
> +    //            tenure (number of garbage-collections survived) is >=
> the deduplication threshold (3
> +    //            by default, as of JDK 15, or the
> "-XX:StringDeduplicationAgeThreshold" value).
> +
> +        final int               lengthSignum = charsA.length -
> charsB.length;
> +
> +    //  If the array lengths are identical, return the "compareToCI"
> result; no additional
> +    //  considerations apply.
> +
> +        if (lengthSignum == 0)
> +            return compareToCI(charsA, 0, charsB, 0, length(charsA));
> +
> +    //  The array lengths differ. Compare the elements present in both
> "charsA" and "charsB".
> +    //  If the comparison result is inequality, return the comparison
> result. If the result
> +    //  is equality, the shorter array is considered less than the longer
> array.
> +
> +        final int               compareSignum = compareToCI(charsA, 0,
> charsB, 0, length(lengthSignum <= 0 ? charsA : charsB));
> +
> +    //  The right-shift (division by two) applied to "lengthSignum" below
> is necessary only
> +    //  if compatibility is required with code expecting specific return
> values (instead of
> +    //  any negative or positive value) from known comparisons.
> +
> +        return compareSignum != 0 ? compareSignum : lengthSignum >> 1;
>       }
> -
> -    private static int compareToCIImpl(byte[] value, int toffset, int tlen,
> -                                      byte[] other, int ooffset, int olen)
> {
> -        int tlast = toffset + tlen;
> -        int olast = ooffset + olen;
> -        assert toffset >= 0 && ooffset >= 0;
> -        assert tlast <= length(value);
> -        assert olast <= length(other);
> -
> -        for (int k1 = toffset, k2 = ooffset; k1 < tlast && k2 < olast;
> k1++, k2++) {
> -            int cp1 = (int)getChar(value, k1);
> -            int cp2 = (int)getChar(other, k2);
> -
> -            if (cp1 == cp2 || compareCodePointCI(cp1, cp2) == 0) {
> +
> +    /**
> +     * Compares case-insensitively UTF-16 sequences in {@code byte} array
> subsections.
> +     * Performs {@linkplain #compareCodePointsIgnoringCase case
> conversions equivalent
> +     * to
> <code>Character.toLowerCase(Character.toUpperCase(codePoint))</code>} before
> +     * comparing unequal code-points.
> +     *
> +     * @param charsA      array of byte pairs representing 16-bit ({@code
> char}) quantities,
> +     *                    with byte order mandated by {@code
> StringUTF16.isBigEndian()}
> +     * @param charsAIndex index, in 16-bit quantities, at which comparison
> of "{@code charsA}"
> +     *                    begins. Caller must enforce constraints "{@code
> 0 <= charsAIndex}"
> +     *                    and "{@code 0 <= charsAIndex + totalChars <=
> charsA.length / 2}".
> +     * @param charsB      array of byte pairs representing 16-bit ({@code
> char}) quantities,
> +     *                    with byte order mandated by {@code
> StringUTF16.isBigEndian()}
> +     * @param charsBIndex index, in 16-bit quantities, at which comparison
> of "{@code charsB}"
> +     *                    begins. Caller must enforce constraints "{@code
> 0 <= charsBIndex}"
> +     *                    and "{@code 0 <= charsBIndex + totalChars <=
> charsB.length / 2}".
> +     * @param totalChars  maximum number of {@code char}s to compare.
> Caller must enforce
> +     *                    constraint "{@code 0 <= totalChars}".
> +     *
> +     * @return negative if the compared portion of {@code charsA} is
> lexicographically less
> +     * than that of {@code charsB}, positive if it is greater, or zero if
> they are equal
> +     *
> +     * @implNote <p>This method relies on the following "<b>Unicode
> Empirical Properties</b>":</p>
> +     * <ol>
> +     *     <li>
> +     *         <p>Only code-points encoded using the same UTF-16
> high-surrogate may be case-insensitively equal.</p>
> +     *         <p>Several facts suggest sufficient proximity of code-point
> case-variants within the Supplementary
> +     *         Multilingual Plane (SMP):</p>
> +     *         <ul>
> +     *             <li>Related code-points are grouped into a Unicode
> "block".</li>
> +     *             <li>Blocks start at multiples of 256.</li>
> +     *             <li>High-surrogates encode 1,024 code-points starting
> with multiples of 1,024.</li>
> +     *             <li>Few SMP code-points are case-sensitive (450, as of
> Unicode 13.0.0).</li>
> +     *         </ul>
> +     *         <p>Thus, it is not surprising this property has held for 25
> years, as of February, 2021.</p>
> +     *     <li><p>For all SMP code-points, both {@code
> Character.toLowerCase(Character.toUpperCase(int))} and
> +     *         {@code Character.toUpperCase(int)} return a SMP code-point,
> never a Basic Multilingual Plane (BMP)
> +     *         code-point.</p>
> +     *         <p>Supporting points:</p>
> +     *         <ul>
> +     *             <li>This is expected due to related code-point
> grouping.</li>
> +     *             <li>If this property were ever invalidated, every
> Unicode case-insensitive equality test
> +     *             which requires equal-length input sequences (measured
> in {@code byte}s or {@code char}s)
> +     *             would break. In other words, this property is already
> utilized more-or-less universally by
> +     *             Unicode case-insensitive equality tests, whether or not
> their authors realize it. The
> +     *             Unicode Consortium has likely been aware of, and
> sensitive to, this issue for years.
> +     *             </li>
> +     *         </ul>
> +     *     </li>
> +     *     <li><p>For all BMP code-points, both {@code
> Character.toLowerCase(Character.toUpperCase(int))} and
> +     *         {@code Character.toUpperCase(int)} return a BMP code-point,
> never a SMP code-point.</p>
> +     *         <p>Supporting points:</p>
> +     *         <ul>
> +     *             <li>This is expected due to related code-point
> grouping.</li>
> +     *             <li>Most scripts affected by letter case were added
> early in Unicode's history, and therefore
> +     *             placed in the BMP. (As of Unicode 13.0.0, there are
> 2,349 case-sensitive code-points in the
> +     *             BMP, but only 450 in the SMP.)
> +     *             </li>
> +     *             <li>If this property were ever invalidated, every
> Unicode case-insensitive equality test
> +     *             which requires equal-length input sequences (measured
> in {@code byte}s or {@code char}s)
> +     *             would break. In other words, this property is already
> utilized more-or-less universally by
> +     *             Unicode case-insensitive equality tests, whether or not
> their authors realize it. The
> +     *             Unicode Consortium has likely been aware of, and
> sensitive to, this issue for years.
> +     *             </li>
> +     *         </ul>
> +     *     </li>
> +     * </ol>
> +     * <p>Validation of each property is performed automatically by unit
> tests in {@code CompareIC}
> +     * ("test/jdk/java/lang/String/CompareIC.java") during normal,
> post-build JDK testing. Those unit tests
> +     * methods are, respectively:
> +     * </p>
> +     * <ol>
> +     *     <li>{@code
> validatePremise_AllSMPCodePointCaseVariantsUseTheSameHighSurrogate}</li>
> +     *     <li>{@code
> validatePremise_AllSMPCodePointCaseVariantsAreSMPCodePoints}</li>
> +     *     <li>{@code
> validatePremise_AllBMPCodePointCaseVariantsAreBMPCodePoints}</li>
> +     * </ol>
> +     * <p>Those tests' Javadocs include discussion of the consequences
> should they ever fail.
> +     * </p>
> +     */
> +    private static int compareToCI
> +    (
> +        final byte[] charsA, int charsAIndex,
> +        final byte[] charsB, int charsBIndex, int totalChars
> +    ){
> +    //  Assertions carried-over from the previous "regionMatchesCI"
> implementation, with additional
> +    //  negative value testing. (Are these assertions still necessary or
> desirable?)
> +
> +        assert (charsAIndex | charsBIndex | totalChars) >= 0;  // Ensure
> these parameters are non-negative.
> +        assert  charsAIndex + totalChars <= length(charsA);
> +        assert  charsBIndex + totalChars <= length(charsB);
> +
> +    //  Variable "priorExactlyEqualChar" (PEEC) is used by the following
> loop to store the "char" value read
> +    //  by its prior iteration, if the same "char" value was read from
> both inputs ("charsA" and "charsB").
> +    //  Otherwise, it is set to zero. PEEC's value is used only during the
> UTF-16 decoding attempt triggered
> +    //  by reading a pair of unequal low-surrogates (see Unicode empirical
> property no. 1). It removes from
> +    //  this algorithm all read-behind/-ahead operations, along with their
> extra tests & branches, and
> +    //  redundant array accesses.
> +    //      Note: PEEC can be zero for three reasons: (1) the loop is in
> its first iteration, (2) the prior
> +    //  iteration read code-point zero from both inputs, or (3) the prior
> iteration read different, but case-
> +    //  insensitively equal, Basic Multilingual Plane code-points. In all
> three cases, zero signifies absence
> +    //  of preceding, identical high-surrogates (as does any
> non-high-surrogate value). Thus, a zero value's
> +    //  cause is ambiguous, but its meaning is clear.
> +
> +        int                     priorExactlyEqualChar = 0;  // AKA "PEEC".
> +
> +        while (--totalChars >= 0) {
> +            int                     cA = getChar(charsA, charsAIndex++);
> +            int                     cB = getChar(charsB, charsBIndex++);
> +
> +            if (cA == cB) {
> +
> +            //  If the next iteration's "cA" and "cB" are different
> low-surrogate code-units, it will need this
> +            //  iteration's value of "cA"/"cB" (their presumed
> high-surrogate code-unit), so it is stored in
> +            //  "priorExactlyEqualChar" (PEEC). In all other cases, this
> caching of "cA"/"cB" in PEEC is a small
> +            //  waste of time. However, the time saved by eliminating the
> tests, branches and reads necessary to
> +            //  reacquire pairs of high-surrogates should compensate for
> many unnecessary writes to PEEC.
> +
> +                priorExactlyEqualChar = cA;
>                   continue;
>               }
> -
> -            // Check for supplementary characters case
> -            cp1 = codePointIncluding(value, cp1, k1, toffset, tlast);
> -            if (cp1 < 0) {
> -                k1++;
> -                cp1 -= cp1;
> -            }
> -            cp2 = codePointIncluding(other, cp2, k2, ooffset, olast);
> -            if (cp2 < 0) {
> -                k2++;
> -                cp2 -= cp2;
> -            }
> -
> -            int diff = compareCodePointCI(cp1, cp2);
> -            if (diff != 0) {
> -                return diff;
> -            }
> -        }
> -        return tlen - olen;
> -    }
> -
> -    // Case insensitive comparison of two code points
> -    private static int compareCodePointCI(int cp1, int cp2) {
> -        // try converting both characters to uppercase.
> -        // If the results match, then the comparison scan should
> -        // continue.
> -        cp1 = Character.toUpperCase(cp1);
> -        cp2 = Character.toUpperCase(cp2);
> -        if (cp1 != cp2) {
> -            // Unfortunately, conversion to uppercase does not work
> properly
> -            // for the Georgian alphabet, which has strange rules about
> case
> -            // conversion.  So we need to make one last check before
> -            // exiting.
> -            cp1 = Character.toLowerCase(cp1);
> -            cp2 = Character.toLowerCase(cp2);
> -            if (cp1 != cp2) {
> -                return cp1 - cp2;
> +
> +        //  KNOWN: "cA" and "cB" are not precisely equal.
> +
> +        //  When "priorExactlyEqualChar" is a high-surrogate, and both
> "cA" and "cB" are low-surrogates, the
> +        //  following "if" block performs UTF-16 decoding, replacing the
> code-units in "cA" and "cB" with
> +        //  code-points. The "if" block then falls-through to the
> code-point case-insensitive comparison.
> +        //
> +        //  If any UTF-16 decoding precondition is unmet, "cA" and "cB"
> will contain Basic Multilingual Plane
> +        //  (BMP) code-points suitable for case-insensitive comparison,
> unless UTF-16 encoding is corrupt in
> +        //  "charsA" and/or "charsB". The following cases are possible:
> +        //      * "priorExactlyEqualChar" is not a high-surrogate, so the
> "if" block is not entered.
> +        //         Possible states of "cA" and "cB":
> +        //          * "cA" and "cB" are unequal BMP code-points,
> potentially case-insensitively equal.
> +        //          * "cA" and "cB" are unequal high-surrogates.
> Case-insensitive equality testing inevitably
> +        //            fails for those code-units, terminating this method.
> Low-surrogate retrieval and UTF-16
> +        //            decoding are unnecessary due to Unicode empirical
> property no. 1.
> +        //          * "cA" and "cB" are unequal low-surrogates. UTF-16
> encoding is corrupt in both "charsA"
> +        //            and "charsB" (low-surrogates not preceded by
> high-surrogates). Case-insensitive equality
> +        //            testing inevitably fails for those code-units,
> terminating this method.
> +        //          * Either "cA" or "cB" is a low-surrogate, while the
> other is a high-surrogate or BMP code-
> +        //            point. UTF-16 encoding is corrupt in the array
> supplying the low-surrogate (no preceding
> +        //            high-surrogate). Case-insensitive equality testing
> inevitably fails, terminating this
> +        //            method.
> +        //      * "priorExactlyEqualChar" is a high-surrogate present in
> both "charsA" and "charsB".
> +        //        Possible states of "cA" and "cB":
> +        //          * "cA" and "cB" are unequal low-surrogates. The "if"
> block is entered, converting "cA"
> +        //            and "cB" into Supplementary Multilingual Plane (SMP)
> code-points, potentially case-
> +        //            insensitively equal.
> +        //          * "cA" and "cB" are unequal high-surrogates. UTF-16
> encoding is corrupt in both "charsA"
> +        //            and "charsB" (high-surrogates following
> high-surrogates). Even if the next loop
> +        //            iteration would retrieve low-surrogates, Unicode
> empirical property no. 1 rules-out
> +        //            case-insensitive equality based on the unequal
> high-surrogates alone.
> +        //          * "cA" and "cB" are unequal BMP code-points,
> potentially case-insensitively equal. UTF-16
> +        //            encoding is corrupt in both "charsA" and "charsB"
> (high-surrogates not followed by low-
> +        //            surrogates), but the corruption is ignored because
> the high-surrogates were identical
> +        //            (equality exists thus far, corrupt encoding
> notwithstanding).
> +        //          * Either "cA" or "cB" is a low-surrogate, while the
> other is a high-surrogate or BMP code-
> +        //            point. UTF-16 encoding is corrupt in the array
> supplying the non-low-surrogate (high-
> +        //            surrogate not followed by low-surrogate). UTF-16
> decoding using the lone low-surrogate
> +        //            is unnecessary, because either:
> +        //              1. The non-low-surrogate is a high-surrogate,
> ruling-out case-insensitive equality.
> +        //                 (Two independent rationales: [1] A
> high-surrogate is not a low-surrogate, by
> +        //                 definition. Also by definition, [2] an SMP
> code-point--decoded from high-surrogate
> +        //                 "priorExactlyEqualChar" and the lone
> low-surrogate--is not a high-surrogate code-
> +        //                 unit.)
> +        //              2. The non-low-surrogate is a BMP code-point.
> Unicode empirical properties 2 and 3
> +        //                 rule-out case-insensitive equality between SMP
> and BMP code-points.
> +        //                     (Alternately, if those properties did not
> exist, deciding equality exists based
> +        //                 on code-points at different positions within
> the compared string sections--whose
> +        //                 comparison requires overlooking an inconvenient
> preceding code-unit in one string--
> +        //                 would be logically dubious on multiple grounds.
> For instance, if one preceding
> +        //                 orphan surrogate can be ignored to prove
> equality, is the same true for two or more
> +        //                 orphans consecutively and/or separately? If so,
> existing code breaks. Notably, most
> +        //                 string equality tests would break due to
> invalidation of their equal-length strings
> +        //                 precondition. [A precondition also invalidated
> if the Unicode Consortium ever
> +        //                 asserts case-insensitive equality between a BMP
> and SMP code-point. Thus, Unicode
> +        //                 empirical properties 2 and 3 will likely
> persist.])
> +        //
> +        //  (Aside: Of the following three tests, only the test of
> "priorExactlyEqualChar" would be necessary
> +        //  if Unicode [non-compact] "String" objects guaranteed valid
> UTF-16 encoding. It seems certain
> +        //  enforcing that guarantee during creation of every "String" [or
> string-like object] is infeasible
> +        //  due to runtime cost, and backwards-incompatibility.
> Nonetheless, this writer [CWJ] is tantalized
> +        //  by the many code simplifications guaranteed-correct "String"
> objects would permit, as well as the
> +        //  clues they could confer on some developers [including this
> writer, once upon a time].)
> +
> +        //  Branch Reduction
> +        //
> +        //  The "if" statement used below has two tests/branches, instead
> of three, due to combining two
> +        //  low-surrogate tests into one. Multiple comparative benchmarks
> (each using 300 random data sets
> +        //  of 200,000 comparisons, repeated 800 times [160 million
> comparisons per data set; 48 billion
> +        //  total comparisons]), run on two different OS & hardware
> combinations, yielded respective best-
> +        //  case improvements of 1.24% and 0.98%, and mean improvements of
> 1.79% and 0.62%, relative to
> +        //  three-branch "if" statement:
> +        //
> +        //      if (priorExactlyEqualChar >>> SURROGATE_PAYLOAD_BIT_COUNT
> == SURROGATE_HI_HEADER_RIGHT_SHIFTED_10
> +        //      &&  cA                    >>> SURROGATE_PAYLOAD_BIT_COUNT
> == SURROGATE_LO_HEADER_RIGHT_SHIFTED_10
> +        //      &&  cB                    >>> SURROGATE_PAYLOAD_BIT_COUNT
> == SURROGATE_LO_HEADER_RIGHT_SHIFTED_10)
> +        //
> +        //  Conversely, combining all three tests into one yields worse
> performance than the three-test
> +        //  "if" shown above, because high-surrogate testing of
> "priorExactlyEqualChar" fails frequently
> +        //  (50% minimum failure rate for well-formed UTF-16), and, when
> it fails, low-surrogate testing
> +        //  of "cA" and "cB" wastes time.
> +
> +            if (priorExactlyEqualChar >>> SURROGATE_PAYLOAD_BIT_COUNT ==
> SURROGATE_HI_HEADER_RIGHT_SHIFTED_10
> +            && (cA ^ Character.MIN_LOW_SURROGATE | cB ^
> Character.MIN_LOW_SURROGATE) >>> SURROGATE_PAYLOAD_BIT_COUNT == 0
> +            ){
> +            //  KNOWN: "cA" and "cB" are not precisely equal.
> +            //  KNOWN: "priorExactlyEqualChar" is a high-surrogate
> code-unit.
> +            //  KNOWN: "cA" and "cB" are low-surrogate code-units. (Bits
> 15 to 10 of both are 110111.)
> +
> +            //  Perform UTF-16 decoding, accelerated by repurposing
> "priorExactlyEqualChar" (PEEC) to store
> +            //  the result of decoding operations common to both "cA" and
> "cB" (because they share the high-
> +            //  surrogate in PEEC). Near-total commonality of operations
> enables decoding two code-points
> +            //  using only one more addition operation than decoding a
> single code-point. (PEEC's repurposing
> +            //  is brief; it is always set to zero immediately after this
> "if" block.)
> +
> +                priorExactlyEqualChar = (priorExactlyEqualChar <<
> SURROGATE_PAYLOAD_BIT_COUNT) + SURROGATE_COMBO_TO_CODE_POINT_DELTA;
> +
> +                cA += priorExactlyEqualChar;
> +                cB += priorExactlyEqualChar;
>               }
> +
> +        //  "cA" and "cB" are not precisely equal, therefore set
> "priorExactlyEqualChar" (PEEC) to zero for
> +        //  the next iteration's potential benefit. ("Potential benefit,"
> because the next iteration, if any,
> +        //  uses PEEC's value only when its "cA" and "cB" are different
> low-surrogate code-units.)
> +
> +            priorExactlyEqualChar = 0;
> +
> +        //  Having performed UTF-16 decoding (if necessary and possible),
> compare case-insensitively code-
> +        //  points "cA" and "cB".
> +        //
> +        //  Note: Code-units are also possible. Normal terminating
> conditions include unequal high-surrogates
> +        //        (see Unicode empirical property no. 1), and a
> high-surrogate/code-point combination. An
> +        //        abnormal terminating condition is a low-surrogate and a
> code-point, meaning at least one
> +        //        input string's UTF-16 encoding is corrupt (a
> low-surrogate not preceded by a high-surrogate,
> +        //        or matching high-surrogates not followed--in one
> string--by a low-surrogate). None of those
> +        //        conditions undermines the code below, because
> "compareCodePointsIgnoringCase" evaluates
> +        //        "caseless" inputs unchanged, including code-units.
> +
> +            cA = compareCodePointsIgnoringCase(cA, cB);
> +            if (cA != 0)
> +                return cA;
>           }
> +
>           return 0;
>       }
> -
> -    // Returns a code point from the code unit pointed by "index". If it is
> -    // not a surrogate or an unpaired surrogate, then the code unit is
> -    // returned as is. Otherwise, it is combined with the code unit before
> -    // or after, depending on the type of the surrogate at index, to make a
> -    // supplementary code point. The return value will be negated if the
> code
> -    // unit pointed by index is a high surrogate, and index + 1 is a low
> surrogate.
> -    private static int codePointIncluding(byte[] ba, int cp, int index,
> int start, int end) {
> -        // fast check
> -        if (!Character.isSurrogate((char)cp)) {
> -            return cp;
> -        }
> -        if (Character.isLowSurrogate((char)cp)) {
> -            if (index > start) {
> -                char c = getChar(ba, index - 1);
> -                if (Character.isHighSurrogate(c)) {
> -                    return Character.toCodePoint(c, (char)cp);
> -                }
> -            }
> -        } else if (index + 1 < end) { // cp == high surrogate
> -            char c = getChar(ba, index + 1);
> -            if (Character.isLowSurrogate(c)) {
> -                // negate the code point
> -                return - Character.toCodePoint((char)cp, c);
> -            }
> -        }
> -        return cp;
> +
> +    /**
> +     * Gets the case-insensitive, lexicographical relationship between
> code-points.
> +     * Though not required, passing this method only unequal code-points
> ("{@code
> +     * codePointA != codePointB}") is most efficient.
> +     *
> +     * @param codePointA first code-point
> +     * @param codePointB second code-point
> +     *
> +     * @return "{@code codePointA - codePointB}" after both undergo
> case-conversion equivalent
> +     * to, but faster than, {@code
> Character.toLowerCase(Character.toUpperCase(codePoint))}
> +     *
> +     * @implNote This method uses two, duplicate {@code switch}
> expressions, because
> +     * benchmarking showed a noticeable performance improvement over a
> single {@code
> +     * switch} wrapped in the most minimal of two-iteration loops. The
> duplication
> +     * should create no maintenance problems, because, as detailed by a
> comment within
> +     * the method, the {@code switch} source code is programmatically
> generated when a
> +     * "CompareIC" unit test detects a mishandled "triple-case"
> code-point. Otherwise,
> +     * modifying these expressions is unnecessary. (The unit test does not
> alter this,
> +     * or any, file; it merely includes updated {@code switch} source in
> its error
> +     * message, leaving a human responsible for pasting it here, twice.)
> +     */
> +    static int compareCodePointsIgnoringCase
> +    (
> +        final int               codePointA,
> +        final int               codePointB
> +    ){
> +    /*  A code-point is here dubbed "triple-case" if "codePoint !=
> Character.toUpperCase(codePoint) &&
> +        codePoint !=
> Character.toLowerCase(Character.toUpperCase(codePoint))". Such code-points
> are rare
> +        (see "switch" expressions below), but force most code-point
> comparisons to invoke both "toUpperCase"
> +        and "toLowerCase". If "triple-case" code-points did not exist,
> invoking only "toLowerCase" would
> +        suffice.
> +
> +        This method comes close to realizing the "no triple-case
> code-points" scenario by directly converting
> +        "triple-case" code-points to their final, lowercase forms using
> "switch" expressions, and invoking
> +        only "toLowerCase" on all other code-points. The effect is a
> benchmark performance gain of 24.3%.
> +
> +        Note: The Georgian alphabet includes no "triple-case" code-points,
> as shown below by the "progression"
> +              columns of the "switch" expressions' comments. (As of
> Unicode 13.0.0, there are three Georgian
> +              blocks: "Georgian" 10A0-10FF, "Georgian Extended" 1C90-1CBF,
> and "Georgian Supplement" 2D00-2D2F.)
> +
> +
> +        TESTING AND CODE GENERATION
> +
> +        A unit test in "CompareIC"
> ("test/jdk/java/lang/String/CompareIC.java") searches all 1,114,112 Unicode
> +        code-points/-units for triple-case code-points, then validates
> their handling by "String.equalsIgnoreCase"
> +        and "String.compareToIgnoreCase". If errors are detected, those
> tests fail with a message detailing each
> +        error and supplying freshly generated source code for the "switch"
> expression used twice below. (If the
> +        new and existing set of "case" clauses differ, pasting the former
> over the latter will fix the problem.
> +        If "case" clauses are identical, the problem lies elsewhere.)
> +    */
> +                                          //  Triple-Case Code-Points, as
> of Java 15.0.2. (Written by
> "java.lang.CompareIC.generateTripleCaseCodePointsSwitchExpression".)
> +                                          //
> +                                          //  Code-Point Progression
>     Code-Point Progression by Name
> +        return switch (codePointA) {      //  --------------------------
> 
>   -------------------------------------------------------------------------------------------------------------------------------------
> +            case '\u00B5' -> '\u03BC';    //  U+00B5 -> U+039C -> U+03BC
>     MICRO SIGN                                            -> GREEK CAPITAL
> LETTER MU               -> GREEK SMALL LETTER MU
> +            case '\u0131' -> '\u0069';    //  U+0131 -> U+0049 -> U+0069
>     LATIN SMALL LETTER DOTLESS I                          -> LATIN CAPITAL
> LETTER I                -> LATIN SMALL LETTER I
> +            case '\u017F' -> '\u0073';    //  U+017F -> U+0053 -> U+0073
>     LATIN SMALL LETTER LONG S                             -> LATIN CAPITAL
> LETTER S                -> LATIN SMALL LETTER S
> +            case '\u01C5' -> '\u01C6';    //  U+01C5 -> U+01C4 -> U+01C6
>     LATIN CAPITAL LETTER D WITH SMALL LETTER Z WITH CARON -> LATIN CAPITAL
> LETTER DZ WITH CARON    -> LATIN SMALL LETTER DZ WITH CARON
> +            case '\u01C8' -> '\u01C9';    //  U+01C8 -> U+01C7 -> U+01C9
>     LATIN CAPITAL LETTER L WITH SMALL LETTER J            -> LATIN CAPITAL
> LETTER LJ               -> LATIN SMALL LETTER LJ
> +            case '\u01CB' -> '\u01CC';    //  U+01CB -> U+01CA -> U+01CC
>     LATIN CAPITAL LETTER N WITH SMALL LETTER J            -> LATIN CAPITAL
> LETTER NJ               -> LATIN SMALL LETTER NJ
> +            case '\u01F2' -> '\u01F3';    //  U+01F2 -> U+01F1 -> U+01F3
>     LATIN CAPITAL LETTER D WITH SMALL LETTER Z            -> LATIN CAPITAL
> LETTER DZ               -> LATIN SMALL LETTER DZ
> +            case '\u0345' -> '\u03B9';    //  U+0345 -> U+0399 -> U+03B9
>     COMBINING GREEK YPOGEGRAMMENI                         -> GREEK CAPITAL
> LETTER IOTA             -> GREEK SMALL LETTER IOTA
> +            case '\u03C2' -> '\u03C3';    //  U+03C2 -> U+03A3 -> U+03C3
>     GREEK SMALL LETTER FINAL SIGMA                        -> GREEK CAPITAL
> LETTER SIGMA            -> GREEK SMALL LETTER SIGMA
> +            case '\u03D0' -> '\u03B2';    //  U+03D0 -> U+0392 -> U+03B2
>     GREEK BETA SYMBOL                                     -> GREEK CAPITAL
> LETTER BETA             -> GREEK SMALL LETTER BETA
> +            case '\u03D1' -> '\u03B8';    //  U+03D1 -> U+0398 -> U+03B8
>     GREEK THETA SYMBOL                                    -> GREEK CAPITAL
> LETTER THETA            -> GREEK SMALL LETTER THETA
> +            case '\u03D5' -> '\u03C6';    //  U+03D5 -> U+03A6 -> U+03C6
>     GREEK PHI SYMBOL                                      -> GREEK CAPITAL
> LETTER PHI              -> GREEK SMALL LETTER PHI
> +            case '\u03D6' -> '\u03C0';    //  U+03D6 -> U+03A0 -> U+03C0
>     GREEK PI SYMBOL                                       -> GREEK CAPITAL
> LETTER PI               -> GREEK SMALL LETTER PI
> +            case '\u03F0' -> '\u03BA';    //  U+03F0 -> U+039A -> U+03BA
>     GREEK KAPPA SYMBOL                                    -> GREEK CAPITAL
> LETTER KAPPA            -> GREEK SMALL LETTER KAPPA
> +            case '\u03F1' -> '\u03C1';    //  U+03F1 -> U+03A1 -> U+03C1
>     GREEK RHO SYMBOL                                      -> GREEK CAPITAL
> LETTER RHO              -> GREEK SMALL LETTER RHO
> +            case '\u03F5' -> '\u03B5';    //  U+03F5 -> U+0395 -> U+03B5
>     GREEK LUNATE EPSILON SYMBOL                           -> GREEK CAPITAL
> LETTER EPSILON          -> GREEK SMALL LETTER EPSILON
> +            case '\u1C80' -> '\u0432';    //  U+1C80 -> U+0412 -> U+0432
>     CYRILLIC SMALL LETTER ROUNDED VE                      -> CYRILLIC
> CAPITAL LETTER VE            -> CYRILLIC SMALL LETTER VE
> +            case '\u1C81' -> '\u0434';    //  U+1C81 -> U+0414 -> U+0434
>     CYRILLIC SMALL LETTER LONG-LEGGED DE                  -> CYRILLIC
> CAPITAL LETTER DE            -> CYRILLIC SMALL LETTER DE
> +            case '\u1C82' -> '\u043E';    //  U+1C82 -> U+041E -> U+043E
>     CYRILLIC SMALL LETTER NARROW O                        -> CYRILLIC
> CAPITAL LETTER O             -> CYRILLIC SMALL LETTER O
> +            case '\u1C83' -> '\u0441';    //  U+1C83 -> U+0421 -> U+0441
>     CYRILLIC SMALL LETTER WIDE ES                         -> CYRILLIC
> CAPITAL LETTER ES            -> CYRILLIC SMALL LETTER ES
> +            case '\u1C84' -> '\u0442';    //  U+1C84 -> U+0422 -> U+0442
>     CYRILLIC SMALL LETTER TALL TE                         -> CYRILLIC
> CAPITAL LETTER TE            -> CYRILLIC SMALL LETTER TE
> +            case '\u1C85' -> '\u0442';    //  U+1C85 -> U+0422 -> U+0442
>     CYRILLIC SMALL LETTER THREE-LEGGED TE                 -> CYRILLIC
> CAPITAL LETTER TE            -> CYRILLIC SMALL LETTER TE
> +            case '\u1C86' -> '\u044A';    //  U+1C86 -> U+042A -> U+044A
>     CYRILLIC SMALL LETTER TALL HARD SIGN                  -> CYRILLIC
> CAPITAL LETTER HARD SIGN     -> CYRILLIC SMALL LETTER HARD SIGN
> +            case '\u1C87' -> '\u0463';    //  U+1C87 -> U+0462 -> U+0463
>     CYRILLIC SMALL LETTER TALL YAT                        -> CYRILLIC
> CAPITAL LETTER YAT           -> CYRILLIC SMALL LETTER YAT
> +            case '\u1C88' -> '\uA64B';    //  U+1C88 -> U+A64A -> U+A64B
>     CYRILLIC SMALL LETTER UNBLENDED UK                    -> CYRILLIC
> CAPITAL LETTER MONOGRAPH UK  -> CYRILLIC SMALL LETTER MONOGRAPH UK
> +            case '\u1E9B' -> '\u1E61';    //  U+1E9B -> U+1E60 -> U+1E61
>     LATIN SMALL LETTER LONG S WITH DOT ABOVE              -> LATIN CAPITAL
> LETTER S WITH DOT ABOVE -> LATIN SMALL LETTER S WITH DOT ABOVE
> +            case '\u1FBE' -> '\u03B9';    //  U+1FBE -> U+0399 -> U+03B9
>     GREEK PROSGEGRAMMENI                                  -> GREEK CAPITAL
> LETTER IOTA             -> GREEK SMALL LETTER IOTA
> +                                          //  --------------------------
> 
>   -------------------------------------------------------------------------------------------------------------------------------------
> +        //  All other case-sensitive code-points are either uppercase (in
> which case they are changed
> +        //  below), or lowercase already (in which case they are not).
> Therefore, only "toLowerCase"
> +        //  is necessary. Code-units and case-insensitive code-points are
> unchanged by "toLowerCase".
> +            default -> Character.toLowerCase(codePointA);
> +
> +        } - switch (codePointB) {         //  --------------------------
> 
>   -------------------------------------------------------------------------------------------------------------------------------------
> +            case '\u00B5' -> '\u03BC';    //  U+00B5 -> U+039C -> U+03BC
>     MICRO SIGN                                            -> GREEK CAPITAL
> LETTER MU               -> GREEK SMALL LETTER MU
> +            case '\u0131' -> '\u0069';    //  U+0131 -> U+0049 -> U+0069
>     LATIN SMALL LETTER DOTLESS I                          -> LATIN CAPITAL
> LETTER I                -> LATIN SMALL LETTER I
> +            case '\u017F' -> '\u0073';    //  U+017F -> U+0053 -> U+0073
>     LATIN SMALL LETTER LONG S                             -> LATIN CAPITAL
> LETTER S                -> LATIN SMALL LETTER S
> +            case '\u01C5' -> '\u01C6';    //  U+01C5 -> U+01C4 -> U+01C6
>     LATIN CAPITAL LETTER D WITH SMALL LETTER Z WITH CARON -> LATIN CAPITAL
> LETTER DZ WITH CARON    -> LATIN SMALL LETTER DZ WITH CARON
> +            case '\u01C8' -> '\u01C9';    //  U+01C8 -> U+01C7 -> U+01C9
>     LATIN CAPITAL LETTER L WITH SMALL LETTER J            -> LATIN CAPITAL
> LETTER LJ               -> LATIN SMALL LETTER LJ
> +            case '\u01CB' -> '\u01CC';    //  U+01CB -> U+01CA -> U+01CC
>     LATIN CAPITAL LETTER N WITH SMALL LETTER J            -> LATIN CAPITAL
> LETTER NJ               -> LATIN SMALL LETTER NJ
> +            case '\u01F2' -> '\u01F3';    //  U+01F2 -> U+01F1 -> U+01F3
>     LATIN CAPITAL LETTER D WITH SMALL LETTER Z            -> LATIN CAPITAL
> LETTER DZ               -> LATIN SMALL LETTER DZ
> +            case '\u0345' -> '\u03B9';    //  U+0345 -> U+0399 -> U+03B9
>     COMBINING GREEK YPOGEGRAMMENI                         -> GREEK CAPITAL
> LETTER IOTA             -> GREEK SMALL LETTER IOTA
> +            case '\u03C2' -> '\u03C3';    //  U+03C2 -> U+03A3 -> U+03C3
>     GREEK SMALL LETTER FINAL SIGMA                        -> GREEK CAPITAL
> LETTER SIGMA            -> GREEK SMALL LETTER SIGMA
> +            case '\u03D0' -> '\u03B2';    //  U+03D0 -> U+0392 -> U+03B2
>     GREEK BETA SYMBOL                                     -> GREEK CAPITAL
> LETTER BETA             -> GREEK SMALL LETTER BETA
> +            case '\u03D1' -> '\u03B8';    //  U+03D1 -> U+0398 -> U+03B8
>     GREEK THETA SYMBOL                                    -> GREEK CAPITAL
> LETTER THETA            -> GREEK SMALL LETTER THETA
> +            case '\u03D5' -> '\u03C6';    //  U+03D5 -> U+03A6 -> U+03C6
>     GREEK PHI SYMBOL                                      -> GREEK CAPITAL
> LETTER PHI              -> GREEK SMALL LETTER PHI
> +            case '\u03D6' -> '\u03C0';    //  U+03D6 -> U+03A0 -> U+03C0
>     GREEK PI SYMBOL                                       -> GREEK CAPITAL
> LETTER PI               -> GREEK SMALL LETTER PI
> +            case '\u03F0' -> '\u03BA';    //  U+03F0 -> U+039A -> U+03BA
>     GREEK KAPPA SYMBOL                                    -> GREEK CAPITAL
> LETTER KAPPA            -> GREEK SMALL LETTER KAPPA
> +            case '\u03F1' -> '\u03C1';    //  U+03F1 -> U+03A1 -> U+03C1
>     GREEK RHO SYMBOL                                      -> GREEK CAPITAL
> LETTER RHO              -> GREEK SMALL LETTER RHO
> +            case '\u03F5' -> '\u03B5';    //  U+03F5 -> U+0395 -> U+03B5
>     GREEK LUNATE EPSILON SYMBOL                           -> GREEK CAPITAL
> LETTER EPSILON          -> GREEK SMALL LETTER EPSILON
> +            case '\u1C80' -> '\u0432';    //  U+1C80 -> U+0412 -> U+0432
>     CYRILLIC SMALL LETTER ROUNDED VE                      -> CYRILLIC
> CAPITAL LETTER VE            -> CYRILLIC SMALL LETTER VE
> +            case '\u1C81' -> '\u0434';    //  U+1C81 -> U+0414 -> U+0434
>     CYRILLIC SMALL LETTER LONG-LEGGED DE                  -> CYRILLIC
> CAPITAL LETTER DE            -> CYRILLIC SMALL LETTER DE
> +            case '\u1C82' -> '\u043E';    //  U+1C82 -> U+041E -> U+043E
>     CYRILLIC SMALL LETTER NARROW O                        -> CYRILLIC
> CAPITAL LETTER O             -> CYRILLIC SMALL LETTER O
> +            case '\u1C83' -> '\u0441';    //  U+1C83 -> U+0421 -> U+0441
>     CYRILLIC SMALL LETTER WIDE ES                         -> CYRILLIC
> CAPITAL LETTER ES            -> CYRILLIC SMALL LETTER ES
> +            case '\u1C84' -> '\u0442';    //  U+1C84 -> U+0422 -> U+0442
>     CYRILLIC SMALL LETTER TALL TE                         -> CYRILLIC
> CAPITAL LETTER TE            -> CYRILLIC SMALL LETTER TE
> +            case '\u1C85' -> '\u0442';    //  U+1C85 -> U+0422 -> U+0442
>     CYRILLIC SMALL LETTER THREE-LEGGED TE                 -> CYRILLIC
> CAPITAL LETTER TE            -> CYRILLIC SMALL LETTER TE
> +            case '\u1C86' -> '\u044A';    //  U+1C86 -> U+042A -> U+044A
>     CYRILLIC SMALL LETTER TALL HARD SIGN                  -> CYRILLIC
> CAPITAL LETTER HARD SIGN     -> CYRILLIC SMALL LETTER HARD SIGN
> +            case '\u1C87' -> '\u0463';    //  U+1C87 -> U+0462 -> U+0463
>     CYRILLIC SMALL LETTER TALL YAT                        -> CYRILLIC
> CAPITAL LETTER YAT           -> CYRILLIC SMALL LETTER YAT
> +            case '\u1C88' -> '\uA64B';    //  U+1C88 -> U+A64A -> U+A64B
>     CYRILLIC SMALL LETTER UNBLENDED UK                    -> CYRILLIC
> CAPITAL LETTER MONOGRAPH UK  -> CYRILLIC SMALL LETTER MONOGRAPH UK
> +            case '\u1E9B' -> '\u1E61';    //  U+1E9B -> U+1E60 -> U+1E61
>     LATIN SMALL LETTER LONG S WITH DOT ABOVE              -> LATIN CAPITAL
> LETTER S WITH DOT ABOVE -> LATIN SMALL LETTER S WITH DOT ABOVE
> +            case '\u1FBE' -> '\u03B9';    //  U+1FBE -> U+0399 -> U+03B9
>     GREEK PROSGEGRAMMENI                                  -> GREEK CAPITAL
> LETTER IOTA             -> GREEK SMALL LETTER IOTA
> +                                          //  --------------------------
> 
>   -------------------------------------------------------------------------------------------------------------------------------------
> +        //  All other case-sensitive code-points are either uppercase (in
> which case they are changed
> +        //  below), or lowercase already (in which case they are not).
> Therefore, only "toLowerCase"
> +        //  is necessary. Code-units and case-insensitive code-points are
> unchanged by "toLowerCase".
> +            default -> Character.toLowerCase(codePointB);
> +        };
>       }
> 
>       public static int compareToCI_Latin1(byte[] value, byte[] other) {
> @@ -780,10 +1141,35 @@
>           }
>           return new String(result, UTF16);
>       }
> -
> -    public static boolean regionMatchesCI(byte[] value, int toffset,
> -                                          byte[] other, int ooffset, int
> len) {
> -        return compareToCIImpl(value, toffset, len, other, ooffset, len)
> == 0;
> +
> +    /**
> +     * Tests case-insensitive equality of UTF-16 sequences in {@code byte}
> array subsections.
> +     * Performs {@linkplain #compareCodePointsIgnoringCase case
> conversions equivalent to
> +     *
> <code>Character.toLowerCase(Character.toUpperCase(codePoint))</code>}
> before comparing
> +     * unequal code-points.
> +     *
> +     * @param charsA      array of byte pairs representing 16-bit ({@code
> char}) quantities,
> +     *                    with byte order mandated by {@code
> StringUTF16.isBigEndian()}
> +     * @param charsAIndex index, in 16-bit quantities, at which comparison
> of "{@code charsA}"
> +     *                    begins. Caller must enforce constraints "{@code
> 0 <= charsAIndex}"
> +     *                    and "{@code 0 <= charsAIndex + totalChars <=
> charsA.length / 2}".
> +     * @param charsB      array of byte pairs representing 16-bit ({@code
> char}) quantities,
> +     *                    with byte order mandated by {@code
> StringUTF16.isBigEndian()}
> +     * @param charsBIndex index, in 16-bit quantities, at which comparison
> of "{@code charsB}"
> +     *                    begins. Caller must enforce constraints "{@code
> 0 <= charsBIndex}"
> +     *                    and "{@code 0 <= charsBIndex + totalChars <=
> charsB.length / 2}".
> +     * @param totalChars  maximum number of {@code char}s to compare.
> Caller must enforce
> +     *                    constraint "{@code 0 <= totalChars}".
> +     *
> +     * @return {@code true} if the tested portions of {@code charsA} and
> {@code charsB} are
> +     * case-insensitively equal, otherwise {@code false}
> +     */
> +    static boolean regionMatchesCI
> +    (
> +        final byte[] charsA, final int charsAIndex,
> +        final byte[] charsB, final int charsBIndex, final int totalChars
> +    ){
> +        return compareToCI(charsA, charsAIndex, charsB, charsBIndex,
> totalChars) == 0;
>       }
> 
>       public static boolean regionMatchesCI_Latin1(byte[] value, int toffset,
> 

From douglas.surber at oracle.com  Wed Mar 31 21:24:22 2021
From: douglas.surber at oracle.com (Douglas Surber)
Date: Wed, 31 Mar 2021 21:24:22 +0000
Subject: [External] : Re: Proposal for Decimal64 and Decimal128
 value-based classes
In-Reply-To: <64aa0072-9c06-ae1d-4791-94f4e92b218e@gmail.com>
References: <da11a680-3ba3-6081-cdfb-57f1825d9281@gmail.com>
 <6ADB5D12-E66D-4797-B09B-DF3CB4BE1D10@oracle.com>
 <64aa0072-9c06-ae1d-4791-94f4e92b218e@gmail.com>
Message-ID: <0E2BDE4A-F206-4D5D-B5B3-FD9E2A0E6CE9@oracle.com>

My understanding is that IEEE decimal floating point is intended for currency. A large fraction of numeric values stored in databases are currency. It's not obvious to me why an e-commerce web site would not want to use Decimal128 to represent prices, extensions, taxes, discounts, totals, etc.

> On Mar 31, 2021, at 2:17 PM, Raffaello Giulietti <raffaello.giulietti at gmail.com> wrote:
> 
> Hi Douglas,
> 
> yes, different vendors have different limits on the precision, the most extreme probably being PostgreSQL.
> 
> But apart from that, the arithmetic is different.
> 
> A better option is to implement some optimized fixed precision classes like SQLDecimal38 and SQLDecimal65 + a more general variable precision SQLDecimal. But, as I mentioned, this is something different than Decimal<N>.
> 
> 
> Greetings
> Raffaello
> 
> 
> 
> On 2021-03-31 22:53, Douglas Surber wrote:
>> Understood. The problem is that right now the only appropriate type for non-integer SQL numbers is BigDecimal. It's too big and too slow and lots of users avoid it.
>> Decimal128 supports 34 significant digits. The max precision of SQL numeric types varies from vendor to vendor. In SQL Server it is 38. In MySQL it is 65. So there are a huge range of values representable in SQL that are not representable in Decimal128. BUT, for the vast majority of applications that might be tempted to use Decimal128, those non-representable numbers don't occur. Currency amounts exceeding 34 decimal digits of precision are an almost non-existent minority.
>> Very few apps will pay the price of using BigDecimal even though it would support huge numbers exactly. Instead they find workarounds that are more efficient. Decimal128 would be a substantial improvement for those apps.
>> Douglas
>>> On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti <raffaello.giulietti at gmail.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I think there's a misunderstanding about the nature of IEEE 754 Decimal<n> (e.g., Decimal64), the subject of this thread, and the nature of SQL DECIMAL(p, s).
>>> 
>>> SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an overall maximum precision p and a scale s, the number of digits to the right of the decimal point (both parameters can be selected freely inside some ranges). For example, DECIMAL(2, 1) can represent only the values
>>>    -9.9, -9.8, ..., 9.8, 9.9
>>> and that's it.
>>> Thus, the sum 6.6 + 7.7 overflows, as well as the product 2.9 * 4.
>>> 
>>> IEEE decimals are *floating* point decimal numbers. A hypothetical decimal of precision 2 can represent values of the form c*10^q, where integer c meets |c| < 100 (that is, max two digits) and integer q is limited in some range. It covers the values above and much more, for example, 0.012 (=12*10^(-3)) and -3.4E2 (=-34*10^1).
>>> The sum 6.6 + 7.7 produces 14 because the mathematical result 14.3 is rounded to the closest number of precision 2 (assuming RoundingMode.HALF_EVEN). By the same token, the product 2.9 * 4 produces 12, which is 11.6 rounded to 2 digits.
>>> But really, the position of the decimal point is floating.
>>> 
>>> IEEE decimals and SQL decimals are fundamentally different and ave different arithmetic, so I wouldn't recommend using the proposed classes for JDBC.
>>> 
>>> On the positive side, SQL decimals, are easier to implement if the maximum allowed p in DECIMAL(p, s) is reasonable, say 38. But that's another topic.
>>> 
>>> 
>>> Greetings
>>> Raffaello


From maurizio.cimadamore at oracle.com  Wed Mar 31 21:27:21 2021
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Wed, 31 Mar 2021 22:27:21 +0100
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <10e8c9d1-fd93-5f34-d4cf-0d6e044b8501@gmail.com>
References: <10e8c9d1-fd93-5f34-d4cf-0d6e044b8501@gmail.com>
Message-ID: <84b24edc-a822-a91c-f9dd-759cb1de70f7@oracle.com>


On 31/03/2021 21:43, Raffaello Giulietti wrote:
> Ciao Maurizio,
>
> admittedly, yours is a fairly convincing argument to wait for the 
> completion of Valhalla, or at least JEP 401.
>
> Personally, I wouldn't mind having to denote the primitive class as 
> Decimal128.val in some future (2022? 2023? who knows?) if I could use 
> Decimal128 tomorrow, but I understand your concerns in defending the 
> interests of the community at large (which includes myself).

Well, I think the problem with a lot of these things is consistency. 
Decimal128.val is not horrible, although it is the wrong default (think 
of Decimal128[] which you would probably want flattened?).

The worse aspect is if _some_ of these types are added before, and some 
after, so you have to remember to use Decimal128.val, but HalfFloat is 
ok (as it has been added after Valhalla).

Considering that these things can happen, I'd be reluctant to go ahead 
and add these types now.

What I'd be curious though, is if the @ValueBased annotation could be 
enhanced to say _which_ primitive class default you want (and then javac 
could enforce extra checks if you pick the "val" default). If something 
like this was feasible (cc'ing Dan), maybe some of the friction here 
could be removed?

Maurizio

>
>
> Greetings
> Raffaello
>
>
>> On 31/03/2021 15:23, Douglas Surber wrote:
>>> Rather than waiting on Valhala I would prefer that this project be 
>>> fast tracked and added to OpenJDK ASAP.
>>
>> There is a catch here.
>>
>> While in principle, we can add these as value-based classes, and 
>> migrate to Valhalla later, there is a biggie difference between doing 
>> it before/after.
>>
>> When it comes to "migrated" primitive classes, there is a choice in 
>> how to interpret the "old" utterances of the class name. Let's say 
>> that class Foo is migrated to be a primitive class; does that mean 
>> that all uses of Foo in existing program will automatically get 
>> flattening? Or will references to Foo be interpreted in a 
>> conservative fashion, so? as to allow the same operations as before? 
>> One important difference in semantics is assignment to `null` which 
>> is prohibited under flattened semantics, but allowed under "indirect" 
>> (or by reference, if you will) semantics.
>>
>> In other words, under the current plan, if Decimal128 is added now 
>> and migrated later, utterances of Decimal128 will behave like they 
>> used to pre-Valhalla, and, to take advantage of flattening you would 
>> need to opt-in with some keyword (e.g. Decimal128.val).
>>
>> To me this is kind of a strong argument against going with these 
>> classes now (as much as I understand how useful they'd be even w/o 
>> Valhalla) - and preserving the "good" name (Decimal128) for the 
>> flattened case seems worth, IMHO, waiting few more cycles.
>>
>> Maurizio
>

From darcy at openjdk.java.net  Wed Mar 31 21:38:35 2021
From: darcy at openjdk.java.net (Joe Darcy)
Date: Wed, 31 Mar 2021 21:38:35 GMT
Subject: RFR: 8169629: Annotations with lambda expressions cause
 AnnotationFormatErrorr
Message-ID: <gD7qFYsjwU-W7Z84CPc5aZbc2gBFaTM8RvyxeP41nBQ=.049861b7-0717-471f-bbb7-8b14c01a2ede@github.com>

The stricter checks added by
    8035781: Improve equality for annotations
in creating the proxy objects used to implement annotations has an unintended by-catch of rejecting annotation's whose type has, say, a field initialized with a lambda expression. While uncommon, it is legal code to have a field in an annotation type.

The updated checks skip over the sort of synthetic method used for the initialization.

Some different compilation tactics were used before and after nest mates, so the test includes compilation and testing under both situations.

-------------

Commit messages:
 - 8169629: Annotations with lambda expressions cause AnnotationFormatErro

Changes: https://git.openjdk.java.net/jdk/pull/3294/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3294&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8169629
  Stats: 29 lines in 2 files changed: 25 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3294.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3294/head:pull/3294

PR: https://git.openjdk.java.net/jdk/pull/3294

From github.com+70726043+rgiulietti at openjdk.java.net  Wed Mar 31 21:45:30 2021
From: github.com+70726043+rgiulietti at openjdk.java.net (Raffaello Giulietti)
Date: Wed, 31 Mar 2021 21:45:30 GMT
Subject: RFR: 8264514: HexFormat implementation tweaks
Message-ID: <CmAtdEv07AR4bJ9zJ5aAlkHL4zsmyN58_TFDvnqCNwQ=.89102181-0ae7-4294-82b0-4b87b92c4b68@github.com>

Please review these small tweaks.

For background information see [1](https://mail.openjdk.java.net/pipermail/core-libs-dev/2021-March/075822.html)

Greetings
Raffaello

-------------

Commit messages:
 - 8264514: HexFormat implementation tweaks

Changes: https://git.openjdk.java.net/jdk/pull/3295/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=3295&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8264514
  Stats: 67 lines in 1 file changed: 10 ins; 26 del; 31 mod
  Patch: https://git.openjdk.java.net/jdk/pull/3295.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/3295/head:pull/3295

PR: https://git.openjdk.java.net/jdk/pull/3295

From asemenyuk at openjdk.java.net  Wed Mar 31 22:03:32 2021
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 31 Mar 2021 22:03:32 GMT
Subject: RFR: JDK-8264403: [macos]: App names containing '.' characters
 results in an error message when launching
In-Reply-To: <PRvADLA7cdiYRji-WMZxuTYtaL0dIh2EWpybtFIrIXk=.db04951c-7eaf-469f-ae15-cb00f06d6678@github.com>
References: <PRvADLA7cdiYRji-WMZxuTYtaL0dIh2EWpybtFIrIXk=.db04951c-7eaf-469f-ae15-cb00f06d6678@github.com>
Message-ID: <zdbfxDkZszM9KvTiwN0cI2XbGyQzGmzzGebiiTfuYJE=.0d42edaf-2cde-4421-bc44-2f2e1a4cd76d@github.com>

On Wed, 31 Mar 2021 19:30:10 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> Deriving the cfg file name is broken on mac and linux when the application name has a "." in it.

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/share/native/common/FileUtils.h line 76:

> 74: 
> 75:     // extract the name from the launcher path
> 76:     tstring extractName(const tstring& path);

Function name seems to be misleading. 
If it specifically designed to be applied to executables, I'd name it `stripExecutableSuffix()`. On Unix implementation would return passed in string as is without calling `basename()` and on Windows would just strip ".exe" suffix not calling `basename()` either.
The use would be: `FileUtils::mkpath() << appDirPath << (FileUtils::stripExecutableSuffix(FileUtils::basename(launcherPath)) + _T(".cfg"));`

-------------

PR: https://git.openjdk.java.net/jdk/pull/3288

From raffaello.giulietti at gmail.com  Wed Mar 31 22:38:12 2021
From: raffaello.giulietti at gmail.com (Raffaello Giulietti)
Date: Thu, 1 Apr 2021 00:38:12 +0200
Subject: [External] : Re: Proposal for Decimal64 and Decimal128
 value-based classes
In-Reply-To: <0E2BDE4A-F206-4D5D-B5B3-FD9E2A0E6CE9@oracle.com>
References: <da11a680-3ba3-6081-cdfb-57f1825d9281@gmail.com>
 <6ADB5D12-E66D-4797-B09B-DF3CB4BE1D10@oracle.com>
 <64aa0072-9c06-ae1d-4791-94f4e92b218e@gmail.com>
 <0E2BDE4A-F206-4D5D-B5B3-FD9E2A0E6CE9@oracle.com>
Message-ID: <4db15e9b-b9ae-0982-8cb4-ebdf5d497183@gmail.com>

The issue is to simulate SQL DECIMAL arithmetic using IEEE Decimal<N>

Consider the division 20 / 3. Using Decimal64:
     20 / 3 -> 6.666666666666666666666666666666667
Using DECIMAL(38, 6), or many other reasonable combinations:
     20 / 3 -> 6.666667

We could expose a richer API in Decimal<N>, similar to BigDecimal's. It 
is doable, but beyond IEEE and my current plan.

In addition, I find that the point issued by Maurizio about the best 
name for the Valhalla primitive class is important enough for the 
community at large to warrant a rumination pause.

Let me ponder about how to enrich the API to support SQL for a couple of 
days or so. In the meantime, the Valhalla guys may come up with a good 
solution to better assist migration of @ValueBased classes to truly 
primitive classes without disrupting existing code that depends on them, 
as described by Maurizio in his previous post.



On 2021-03-31 23:24, Douglas Surber wrote:
> My understanding is that IEEE decimal floating point is intended for currency. A large fraction of numeric values stored in databases are currency. It's not obvious to me why an e-commerce web site would not want to use Decimal128 to represent prices, extensions, taxes, discounts, totals, etc.
> 
>> On Mar 31, 2021, at 2:17 PM, Raffaello Giulietti <raffaello.giulietti at gmail.com> wrote:
>>
>> Hi Douglas,
>>
>> yes, different vendors have different limits on the precision, the most extreme probably being PostgreSQL.
>>
>> But apart from that, the arithmetic is different.
>>
>> A better option is to implement some optimized fixed precision classes like SQLDecimal38 and SQLDecimal65 + a more general variable precision SQLDecimal. But, as I mentioned, this is something different than Decimal<N>.
>>
>>
>> Greetings
>> Raffaello
>>
>>
>>
>> On 2021-03-31 22:53, Douglas Surber wrote:
>>> Understood. The problem is that right now the only appropriate type for non-integer SQL numbers is BigDecimal. It's too big and too slow and lots of users avoid it.
>>> Decimal128 supports 34 significant digits. The max precision of SQL numeric types varies from vendor to vendor. In SQL Server it is 38. In MySQL it is 65. So there are a huge range of values representable in SQL that are not representable in Decimal128. BUT, for the vast majority of applications that might be tempted to use Decimal128, those non-representable numbers don't occur. Currency amounts exceeding 34 decimal digits of precision are an almost non-existent minority.
>>> Very few apps will pay the price of using BigDecimal even though it would support huge numbers exactly. Instead they find workarounds that are more efficient. Decimal128 would be a substantial improvement for those apps.
>>> Douglas
>>>> On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti <raffaello.giulietti at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I think there's a misunderstanding about the nature of IEEE 754 Decimal<n> (e.g., Decimal64), the subject of this thread, and the nature of SQL DECIMAL(p, s).
>>>>
>>>> SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an overall maximum precision p and a scale s, the number of digits to the right of the decimal point (both parameters can be selected freely inside some ranges). For example, DECIMAL(2, 1) can represent only the values
>>>>     -9.9, -9.8, ..., 9.8, 9.9
>>>> and that's it.
>>>> Thus, the sum 6.6 + 7.7 overflows, as well as the product 2.9 * 4.
>>>>
>>>> IEEE decimals are *floating* point decimal numbers. A hypothetical decimal of precision 2 can represent values of the form c*10^q, where integer c meets |c| < 100 (that is, max two digits) and integer q is limited in some range. It covers the values above and much more, for example, 0.012 (=12*10^(-3)) and -3.4E2 (=-34*10^1).
>>>> The sum 6.6 + 7.7 produces 14 because the mathematical result 14.3 is rounded to the closest number of precision 2 (assuming RoundingMode.HALF_EVEN). By the same token, the product 2.9 * 4 produces 12, which is 11.6 rounded to 2 digits.
>>>> But really, the position of the decimal point is floating.
>>>>
>>>> IEEE decimals and SQL decimals are fundamentally different and ave different arithmetic, so I wouldn't recommend using the proposed classes for JDBC.
>>>>
>>>> On the positive side, SQL decimals, are easier to implement if the maximum allowed p in DECIMAL(p, s) is reasonable, say 38. But that's another topic.
>>>>
>>>>
>>>> Greetings
>>>> Raffaello
> 

From joe.darcy at oracle.com  Wed Mar 31 22:41:43 2021
From: joe.darcy at oracle.com (Joe Darcy)
Date: Wed, 31 Mar 2021 15:41:43 -0700
Subject: [External] : Re: Proposal for Decimal64 and Decimal128
 value-based classes
In-Reply-To: <0E2BDE4A-F206-4D5D-B5B3-FD9E2A0E6CE9@oracle.com>
References: <da11a680-3ba3-6081-cdfb-57f1825d9281@gmail.com>
 <6ADB5D12-E66D-4797-B09B-DF3CB4BE1D10@oracle.com>
 <64aa0072-9c06-ae1d-4791-94f4e92b218e@gmail.com>
 <0E2BDE4A-F206-4D5D-B5B3-FD9E2A0E6CE9@oracle.com>
Message-ID: <2e372ae6-241b-2ef9-85be-217057a0a270@oracle.com>

The IEEE decimal floating-point is usable for currency calculations, but 
it is not intended to be limited to such calculations. A type targeted 
at currency calculations would focus more on fixed-point rounding, 
rounding to a given digit position (scale in BigDecimal terminology), as 
opposed to floating-point rounding which is primarily rounding to a 
fixed precision. In a currency setting, rounding to a given scale would 
mean rounding to whole dollars (pounds, euros, etc.), cents, mills, or 
other particular fractional quantity.

-Joe

On 3/31/2021 2:24 PM, Douglas Surber wrote:
> My understanding is that IEEE decimal floating point is intended for currency. A large fraction of numeric values stored in databases are currency. It's not obvious to me why an e-commerce web site would not want to use Decimal128 to represent prices, extensions, taxes, discounts, totals, etc.
>
>> On Mar 31, 2021, at 2:17 PM, Raffaello Giulietti <raffaello.giulietti at gmail.com> wrote:
>>
>> Hi Douglas,
>>
>> yes, different vendors have different limits on the precision, the most extreme probably being PostgreSQL.
>>
>> But apart from that, the arithmetic is different.
>>
>> A better option is to implement some optimized fixed precision classes like SQLDecimal38 and SQLDecimal65 + a more general variable precision SQLDecimal. But, as I mentioned, this is something different than Decimal<N>.
>>
>>
>> Greetings
>> Raffaello
>>
>>
>>
>> On 2021-03-31 22:53, Douglas Surber wrote:
>>> Understood. The problem is that right now the only appropriate type for non-integer SQL numbers is BigDecimal. It's too big and too slow and lots of users avoid it.
>>> Decimal128 supports 34 significant digits. The max precision of SQL numeric types varies from vendor to vendor. In SQL Server it is 38. In MySQL it is 65. So there are a huge range of values representable in SQL that are not representable in Decimal128. BUT, for the vast majority of applications that might be tempted to use Decimal128, those non-representable numbers don't occur. Currency amounts exceeding 34 decimal digits of precision are an almost non-existent minority.
>>> Very few apps will pay the price of using BigDecimal even though it would support huge numbers exactly. Instead they find workarounds that are more efficient. Decimal128 would be a substantial improvement for those apps.
>>> Douglas
>>>> On Mar 31, 2021, at 1:13 PM, Raffaello Giulietti <raffaello.giulietti at gmail.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> I think there's a misunderstanding about the nature of IEEE 754 Decimal<n> (e.g., Decimal64), the subject of this thread, and the nature of SQL DECIMAL(p, s).
>>>>
>>>> SQL DECIMAL(p, s) represent *fixed* point decimal numbers, with an overall maximum precision p and a scale s, the number of digits to the right of the decimal point (both parameters can be selected freely inside some ranges). For example, DECIMAL(2, 1) can represent only the values
>>>>     -9.9, -9.8, ..., 9.8, 9.9
>>>> and that's it.
>>>> Thus, the sum 6.6 + 7.7 overflows, as well as the product 2.9 * 4.
>>>>
>>>> IEEE decimals are *floating* point decimal numbers. A hypothetical decimal of precision 2 can represent values of the form c*10^q, where integer c meets |c| < 100 (that is, max two digits) and integer q is limited in some range. It covers the values above and much more, for example, 0.012 (=12*10^(-3)) and -3.4E2 (=-34*10^1).
>>>> The sum 6.6 + 7.7 produces 14 because the mathematical result 14.3 is rounded to the closest number of precision 2 (assuming RoundingMode.HALF_EVEN). By the same token, the product 2.9 * 4 produces 12, which is 11.6 rounded to 2 digits.
>>>> But really, the position of the decimal point is floating.
>>>>
>>>> IEEE decimals and SQL decimals are fundamentally different and ave different arithmetic, so I wouldn't recommend using the proposed classes for JDBC.
>>>>
>>>> On the positive side, SQL decimals, are easier to implement if the maximum allowed p in DECIMAL(p, s) is reasonable, say 38. But that's another topic.
>>>>
>>>>
>>>> Greetings
>>>> Raffaello

From daniel.smith at oracle.com  Wed Mar 31 22:54:02 2021
From: daniel.smith at oracle.com (Dan Smith)
Date: Wed, 31 Mar 2021 22:54:02 +0000
Subject: Proposal for Decimal64 and Decimal128 value-based classes
In-Reply-To: <84b24edc-a822-a91c-f9dd-759cb1de70f7@oracle.com>
References: <10e8c9d1-fd93-5f34-d4cf-0d6e044b8501@gmail.com>
 <84b24edc-a822-a91c-f9dd-759cb1de70f7@oracle.com>
Message-ID: <5985B06A-7F50-43E4-80B8-CB653B135FFD@oracle.com>

> On Mar 31, 2021, at 3:27 PM, Maurizio Cimadamore <maurizio.cimadamore at oracle.com> wrote:
> 
> What I'd be curious though, is if the @ValueBased annotation could be enhanced to say _which_ primitive class default you want (and then javac could enforce extra checks if you pick the "val" default). If something like this was feasible (cc'ing Dan), maybe some of the friction here could be removed?

You mean annotate a class with "pretend this class's name represents a value type" and then implement the associated null checks in javac, even though we don't actually have value types yet?

I'd expect that to run into a number of problems related to the fact that the language model hasn't actually been updated to include primitive classes or value types yet. Plus the lack of features like reference types (Foo.ref) would be limiting for programmers who need them. Plus binary incompatibility?value types need special encoding in class files, and those class files aren't legal yet; when they are, you risk mismatches.

In this case I think the straightforward approach of just completing and delivering the Valhalla features is better than trying to spin off a small taste of them early.