From winterhalter at openjdk.java.net  Sun Nov  1 01:09:53 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Sun, 1 Nov 2020 01:09:53 GMT
Subject: RFR: 8202471: Make type annotations on owner type parameters
 available
In-Reply-To: <nruqzzWvKlH2vzXaYez9l7ol30GFHrP3cU4JbwLHwO8=.8af75fe4-2cca-473d-a7aa-772da4791b0c@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
 <nruqzzWvKlH2vzXaYez9l7ol30GFHrP3cU4JbwLHwO8=.8af75fe4-2cca-473d-a7aa-772da4791b0c@github.com>
Message-ID: <n5vX_74Im1lr2xoX4yY2pgcXPgW2dICbExlk4NggcJw=.bb833ae5-715d-4787-ae0f-f2be59d17e6e@github.com>

On Tue, 27 Oct 2020 19:09:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.
>
> Hint: if you merge from master, you would get the updated test workflows, which would include the artifact with *.jtr (jtreg output) files in "testsupport". You can then use them to diagnose the testing failures you are getting.

Thanks, I had those working on Mercurial and kind of winged the transfer Should work now!

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Sun Nov  1 13:22:54 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Sun, 1 Nov 2020 13:22:54 GMT
Subject: RFR: 8186085: (opt) add filter(), flatMap(),
 and map() methods to OptionalDouble/Int/Long
In-Reply-To: <-3VzAZKRIBxGn1ompqha9OBTeYP9mGBK8yzq3bZP4to=.ee9dfff4-b66f-42c3-b69d-ce60b52732bc@github.com>
References: <b7KzeBxklrPQqohcMHsNfDtIKbYaZ_9qa5td3dV_Oe4=.542e7568-bf8b-47b9-979a-6864fcf7eece@github.com>
 <-3VzAZKRIBxGn1ompqha9OBTeYP9mGBK8yzq3bZP4to=.ee9dfff4-b66f-42c3-b69d-ce60b52732bc@github.com>
Message-ID: <TaroBjqcibqQ8y7nF1FhWFQ63yH9_caohN7y5NPOaUM=.fa54a95f-e577-4244-8386-a808a204ea5c@github.com>

On Sat, 31 Oct 2020 16:45:06 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> Hi all,
>> This PR intends to add filter, map and flatMap methods to the Optional classes for primitives. The rationale is consistency with the Optional class for objects and user convenience.
>> Thanks.
>> Regards,
>> Kartik
>
> Kindly review the patch. Thanks in advance!

Thank you for the suggestions. I'll try fixing some bugs first. Should I close this PR as well or leave it open ?

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

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

From github.com+828220+forax at openjdk.java.net  Sun Nov  1 13:44:54 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sun, 1 Nov 2020 13:44:54 GMT
Subject: RFR: 8186085: (opt) add filter(), flatMap(),
 and map() methods to OptionalDouble/Int/Long
In-Reply-To: <-3VzAZKRIBxGn1ompqha9OBTeYP9mGBK8yzq3bZP4to=.ee9dfff4-b66f-42c3-b69d-ce60b52732bc@github.com>
References: <b7KzeBxklrPQqohcMHsNfDtIKbYaZ_9qa5td3dV_Oe4=.542e7568-bf8b-47b9-979a-6864fcf7eece@github.com>
 <-3VzAZKRIBxGn1ompqha9OBTeYP9mGBK8yzq3bZP4to=.ee9dfff4-b66f-42c3-b69d-ce60b52732bc@github.com>
Message-ID: <vNIb12gh8dHNnbfVq68en3pw6NBQBz5RnLautKnE0Ck=.8843d602-b8ff-48ec-80c5-d1d5b49c11f1@github.com>

On Sat, 31 Oct 2020 16:45:06 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> Hi all,
>> This PR intends to add filter, map and flatMap methods to the Optional classes for primitives. The rationale is consistency with the Optional class for objects and user convenience.
>> Thanks.
>> Regards,
>> Kartik
>
> Kindly review the patch. Thanks in advance!

Hi !
thanks for taking the time to craft that pull request but this is typically the kind of patch that should be discussed on the mailing list first before creating a pull request.

There are several issues, one is that we want to retrofit OptionalInt, OptionalLong, etc to be Optional<int>, Optional<long> as part of project Valhalla so we don't want to add more methods in the primitive variants of Optional and Stream to avoid to be blocked later while trying retrofitting those classes due to these methods.
So we know that some methods are missing but we want to know first how the specialization of generics over primitive types works before adding those methods.

The second issue is that when you want to change the public API of the JDK, you have to create a CSR to ask to the CSR guys/girls leaded by Joe Darcy if the signature and the semantics of the methods you want to add are coherent with the rest of the API.

I recommend you to start by fixing bugs because those can be fixed by a simple pull request.

regards,
R?mi

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

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

From github.com+828220+forax at openjdk.java.net  Sun Nov  1 14:30:53 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sun, 1 Nov 2020 14:30:53 GMT
Subject: RFR: 8186085: (opt) add filter(), flatMap(),
 and map() methods to OptionalDouble/Int/Long
In-Reply-To: <TaroBjqcibqQ8y7nF1FhWFQ63yH9_caohN7y5NPOaUM=.fa54a95f-e577-4244-8386-a808a204ea5c@github.com>
References: <b7KzeBxklrPQqohcMHsNfDtIKbYaZ_9qa5td3dV_Oe4=.542e7568-bf8b-47b9-979a-6864fcf7eece@github.com>
 <-3VzAZKRIBxGn1ompqha9OBTeYP9mGBK8yzq3bZP4to=.ee9dfff4-b66f-42c3-b69d-ce60b52732bc@github.com>
 <TaroBjqcibqQ8y7nF1FhWFQ63yH9_caohN7y5NPOaUM=.fa54a95f-e577-4244-8386-a808a204ea5c@github.com>
Message-ID: <xzNpb8zMVZms0-yDWA6D_CjCapvz1IvFe2pOS054C3I=.2fe687be-86b5-444a-8021-bdad438ce8cd@github.com>

On Sun, 1 Nov 2020 13:20:20 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

>> Hi !
>> thanks for taking the time to craft that pull request but this is typically the kind of patch that should be discussed on the mailing list first before creating a pull request.
>> 
>> There are several issues, one is that we want to retrofit OptionalInt, OptionalLong, etc to be Optional<int>, Optional<long> as part of project Valhalla so we don't want to add more methods in the primitive variants of Optional and Stream to avoid to be blocked later while trying retrofitting those classes due to these methods.
>> So we know that some methods are missing but we want to know first how the specialization of generics over primitive types works before adding those methods.
>> 
>> The second issue is that when you want to change the public API of the JDK, you have to create a CSR to ask to the CSR guys/girls leaded by Joe Darcy if the signature and the semantics of the methods you want to add are coherent with the rest of the API.
>> 
>> I recommend you to start by fixing bugs because those can be fixed by a simple pull request.
>> 
>> regards,
>> R?mi
>
> Thank you for the suggestions. I'll try fixing some bugs first. Should I close this PR as well or leave it open ?

If it doesn't break your hart too much, yes please.

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Sun Nov  1 14:52:57 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Sun, 1 Nov 2020 14:52:57 GMT
Subject: RFR: 8186085: (opt) add filter(), flatMap(),
 and map() methods to OptionalDouble/Int/Long
In-Reply-To: <xzNpb8zMVZms0-yDWA6D_CjCapvz1IvFe2pOS054C3I=.2fe687be-86b5-444a-8021-bdad438ce8cd@github.com>
References: <b7KzeBxklrPQqohcMHsNfDtIKbYaZ_9qa5td3dV_Oe4=.542e7568-bf8b-47b9-979a-6864fcf7eece@github.com>
 <-3VzAZKRIBxGn1ompqha9OBTeYP9mGBK8yzq3bZP4to=.ee9dfff4-b66f-42c3-b69d-ce60b52732bc@github.com>
 <TaroBjqcibqQ8y7nF1FhWFQ63yH9_caohN7y5NPOaUM=.fa54a95f-e577-4244-8386-a808a204ea5c@github.com>
 <xzNpb8zMVZms0-yDWA6D_CjCapvz1IvFe2pOS054C3I=.2fe687be-86b5-444a-8021-bdad438ce8cd@github.com>
Message-ID: <X77qS4TQxQ8X9gWkoVYpN9B_FfNrdDgq9QZ4A4Gpx18=.4d8d31e1-fe8f-4a6f-84b4-d881161b6001@github.com>

On Sun, 1 Nov 2020 14:27:41 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Thank you for the suggestions. I'll try fixing some bugs first. Should I close this PR as well or leave it open ?
>
> If it doesn't break your hart too much, yes please.

Sure, no worries. I am new to the project and understand that it'll take some time to understand how the project works and make some valuable contributions. In the future, I'll take care of first discussing on the appropriate mailing list before proposing patches. Thanks again.

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

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

From github.com+27751938+amcap1712 at openjdk.java.net  Sun Nov  1 14:52:58 2020
From: github.com+27751938+amcap1712 at openjdk.java.net (Kartik Ohri)
Date: Sun, 1 Nov 2020 14:52:58 GMT
Subject: Withdrawn: 8186085: (opt) add filter(), flatMap(),
 and map() methods to OptionalDouble/Int/Long
In-Reply-To: <b7KzeBxklrPQqohcMHsNfDtIKbYaZ_9qa5td3dV_Oe4=.542e7568-bf8b-47b9-979a-6864fcf7eece@github.com>
References: <b7KzeBxklrPQqohcMHsNfDtIKbYaZ_9qa5td3dV_Oe4=.542e7568-bf8b-47b9-979a-6864fcf7eece@github.com>
Message-ID: <h1XO9hGXgy9b9jUqwdtWznMmonVrlSRkEoNI5Aw-ZFQ=.68862bd1-9ae6-416f-8392-b51b3eeb7649@github.com>

On Sun, 25 Oct 2020 10:49:01 GMT, Kartik Ohri <github.com+27751938+amCap1712 at openjdk.org> wrote:

> Hi all,
> This PR intends to add filter, map and flatMap methods to the Optional classes for primitives. The rationale is consistency with the Optional class for objects and user convenience.
> Thanks.
> Regards,
> Kartik

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.java.net  Sun Nov  1 16:08:54 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 1 Nov 2020 16:08:54 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator)
In-Reply-To: <gKyi3UsqpyQ6bWnRX3JIEsc5-4SEMZmHLFdz0gRgRoY=.2b655f9f-551c-4454-9f21-1c9dbf2dcc24@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <pS93Tkclki7y3uzfofkeCRZiZV8Wbb0fpPTI4aOHZXA=.b467ed27-1874-4302-833d-e022ef913dbb@github.com>
 <gKyi3UsqpyQ6bWnRX3JIEsc5-4SEMZmHLFdz0gRgRoY=.2b655f9f-551c-4454-9f21-1c9dbf2dcc24@github.com>
Message-ID: <wW7_WrOpEbYNHP12tT3x2ujcGAl2O35RyZud9SY_43w=.7848a0e3-0015-408e-9dd0-44ab545c7465@github.com>

On Thu, 29 Oct 2020 14:13:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>>> @mcimadamore, if you pull from current master, you would get the Linux x86_32 tier1 run "for free".
>> 
>> Just did that - I also removed TestMismatch from the problem list in the latest iteration, and fixed the alignment for long/double layouts, after chatting with the team (https://bugs.openjdk.java.net/browse/JDK-8255350)
>
> I've just uploaded another iteration which addresses some comments from @AlanBateman. Basically, there are some operations on Channel and Socket which take ByteBuffer as arguments, and then, if such buffers are *direct*, they get the address and pass it down to some native function. This idiom is problematic because there's no way to guarantee that the buffer won't be closed (if obtained from a memory segment) after the address has been obtained. As a stop gap solution, I've introduced checks in `DirectBuffer::address` method, which is used in around 30 places in the JDK. This method will now throw if (a) the buffer has a shared scope, or (b) if the scope is confined, but already closed. With this extra check, I believe there's no way to misuse the buffer obtained from a segment. We have discussed plans to remove this limitations (which we think will be possible) - but for the time being, it's better to play the conservative card.

I looked through the changes in this update.

The shared memory segment support looks sound and the mechanism to close a shared memory segment is clever (albeit a bit surprising at first that it does global handshake to look for a frame in a scoped region. Also surprising that close can cause failure at both ends - it took me a while to see that this is pragmatic approach).

The share method specifies NPE if thread == null but there is no thread parameter, is this a cut 'n paste error? Another one in registerCleaner where it should be NPE if the cleaner is null.

I think the javadoc for the close method needs to be a bit clearer on the state of the memory segment when IllegalStateException is thrown. Will it be marked "not alive" when it fails? Does this mean there is a resource leak? I think an apiNote to explain the rational for why close is not idempotent is also needed, or maybe it should be re-visited so that close is a no-op when the memory segment is not alive.

Now that MemorySegment is AutoCloseable then maybe the term "alive" should be replaced with "open" or  "closed" and isAlive replaced with isOpen is isClosed.

FileDescriptor can be attraction nuisance and forced reference counting everywhere that it is used. Is it needed? Could an isMapped method work instead?

mapFromPath was in the second preview but I think the method name should be re-examined as it maps a file, the path just locates the file.  Naming is subjectives but in this case using "map" or "mapFile" would fit beside the allocateNative methods.

MappedMemorySegments. The force method specifies a write back guarantee but at the same time, the implNote in the class description suggests that the methods might be a no-op. You might want to adjust the wording to avoid any suggestion that force might be a no-op.

The javadoc for copyFrom isn't changed in this update but I notice it specifies IndexOutOfBoundException when the source segment is larger than the receiver, have other exceptions been examined?

I don't have any any comments on MemoryAccess except that it's not immediately clear why there are "Byte" methods that take a ByteOrder. Make sense for the multi-byte types of course.

The updates the java/nio sources look okay but it would be helpful if the really long lines could be chopped down as it's just too hard to do side-by-side reviews when the lines are so long. A minor nit but the changes X-Buffer.java.template mess up the alignment of the parameters to copyMemory/copySwapMemory methods.

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

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

From lancea at openjdk.java.net  Sun Nov  1 20:20:04 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sun, 1 Nov 2020 20:20:04 GMT
Subject: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if
 zipinfo-time is not set to false
Message-ID: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>

Hi,

Please review the fix for JDK-8255380 which addresses an issue when the Zip file is > 4GB.  Zip FS when processing the CEN extra data does not take into account the fact that there is no specific order to how the extra data fields are written.  Info-ZIP writes the fields in a different order than Zip FS which presents a problem when evaluating the Info-ZIP extended timestamp and the LOC offset is 0XFFFFFFFF therefore the LOC offset needs to be read from the EXTID_ZIP64 extra data prior to attempting to read the LOC extra data field.

The fix will defer reading of the LOC extra data field, if needed until all of the CEN extra data has been processed.

Using jdk.nio.zipfs.ZipInfo, you can see the ordering difference of the CEND extra data fields when using Zip FS and info-zip.

Info-zip is included with Mac OS so the test uses ProcessBuilder to execute zip on Mac OS and Linux.  

Mach5 tests jdk-tier1, jdk-tier2, and jdk-tier3 run cleanly.

Best,
Lance

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

Commit messages:
 - (zipfs) ZipFileSystem::readExtra can fail if zipinfo-time is not set to false

Changes: https://git.openjdk.java.net/jdk/pull/987/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=987&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255380
  Stats: 311 lines in 2 files changed: 272 ins; 29 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/987.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/987/head:pull/987

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

From redestad at openjdk.java.net  Sun Nov  1 22:23:56 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 1 Nov 2020 22:23:56 GMT
Subject: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if
 zipinfo-time is not set to false
In-Reply-To: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>
References: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>
Message-ID: <-nbhvVlcWVm1c8ZOXDHij7eG-LPTMLHYIzcNqT8MWpE=.f40672cc-4544-47ec-a3c6-f05f5dcda0c7@github.com>

On Sun, 1 Nov 2020 20:09:32 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review the fix for JDK-8255380 which addresses an issue when the Zip file is > 4GB.  Zip FS when processing the CEN extra data does not take into account the fact that there is no specific order to how the extra data fields are written.  Info-ZIP writes the fields in a different order than Zip FS which presents a problem when evaluating the Info-ZIP extended timestamp and the LOC offset is 0XFFFFFFFF therefore the LOC offset needs to be read from the EXTID_ZIP64 extra data prior to attempting to read the LOC extra data field.
> 
> The fix will defer reading of the LOC extra data field, if needed until all of the CEN extra data has been processed.
> 
> Using jdk.nio.zipfs.ZipInfo, you can see the ordering difference of the CEND extra data fields when using Zip FS and info-zip.
> 
> Info-zip is included with Mac OS so the test uses ProcessBuilder to execute zip on Mac OS and Linux.  
> 
> Mach5 tests jdk-tier1, jdk-tier2, and jdk-tier3 run cleanly.
> 
> Best,
> Lance

LGTM. Some nits inline.

I guess the test can be cause for issues in some test systems since it needs to write out the 4Gb+ file. Is this why you've only enabled it on linux and mac? Perhaps someone might have ideas on how to improve this.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2993:

> 2991:             // We need to read the LOC extra data and the LOC offset was obtained
> 2992:             // from the EXTID_ZIP64 field.
> 2993:             if(hasZip64LocOffset) {

Suggestion:

            if (hasZip64LocOffset) {

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2978:

> 2976:                     // prior to reading the LOC extra data field in order to obtain
> 2977:                     // the Info-ZIP Extended Timestamp.
> 2978:                     if(locoff != ZIP64_MINVAL) {

Suggestion:

                    if (locoff != ZIP64_MINVAL) {

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

Marked as reviewed by redestad (Reviewer).

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

From lancea at openjdk.java.net  Sun Nov  1 22:59:08 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sun, 1 Nov 2020 22:59:08 GMT
Subject: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if
 zipinfo-time is not set to false [v2]
In-Reply-To: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>
References: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>
Message-ID: <D3MOVNhlrnhW6ghVh_7woxw_W4pgURUk6EsWyXYewJw=.1e43f78f-2eeb-498b-8153-93382d3af0b7@github.com>

> Hi,
> 
> Please review the fix for JDK-8255380 which addresses an issue when the Zip file is > 4GB.  Zip FS when processing the CEN extra data does not take into account the fact that there is no specific order to how the extra data fields are written.  Info-ZIP writes the fields in a different order than Zip FS which presents a problem when evaluating the Info-ZIP extended timestamp and the LOC offset is 0XFFFFFFFF therefore the LOC offset needs to be read from the EXTID_ZIP64 extra data prior to attempting to read the LOC extra data field.
> 
> The fix will defer reading of the LOC extra data field, if needed until all of the CEN extra data has been processed.
> 
> Using jdk.nio.zipfs.ZipInfo, you can see the ordering difference of the CEND extra data fields when using Zip FS and info-zip.
> 
> Info-zip is included with Mac OS so the test uses ProcessBuilder to execute zip on Mac OS and Linux.  
> 
> Mach5 tests jdk-tier1, jdk-tier2, and jdk-tier3 run cleanly.
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Addressed feedback from Claes

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/987/files
  - new: https://git.openjdk.java.net/jdk/pull/987/files/7bb9a906..efa7b750

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

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

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

From lancea at openjdk.java.net  Sun Nov  1 22:59:09 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sun, 1 Nov 2020 22:59:09 GMT
Subject: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if
 zipinfo-time is not set to false [v2]
In-Reply-To: <-nbhvVlcWVm1c8ZOXDHij7eG-LPTMLHYIzcNqT8MWpE=.f40672cc-4544-47ec-a3c6-f05f5dcda0c7@github.com>
References: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>
 <-nbhvVlcWVm1c8ZOXDHij7eG-LPTMLHYIzcNqT8MWpE=.f40672cc-4544-47ec-a3c6-f05f5dcda0c7@github.com>
Message-ID: <l6MR-avalWs2sojerP_WKtZx61r_H0xfEZ3la2jdIuU=.359f5ee1-8b00-4f1e-a258-f98133d86578@github.com>

On Sun, 1 Nov 2020 22:21:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> LGTM. Some nits inline.
> 
> I guess the test can be cause for issues in some test systems since it needs to write out the 4Gb+ file. Is this why you've only enabled it on linux and mac? Perhaps someone might have ideas on how to improve this.

To validate the test, requires info-zip which comes on Mac and linux.  It is not included with windows.  There are no issues if the Zip is created via java.util.zip or Zip FS

> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2993:
> 
>> 2991:             // We need to read the LOC extra data and the LOC offset was obtained
>> 2992:             // from the EXTID_ZIP64 field.
>> 2993:             if(hasZip64LocOffset) {
> 
> Suggestion:
> 
>             if (hasZip64LocOffset) {

Resolved

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

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

From redestad at openjdk.java.net  Sun Nov  1 23:07:54 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 1 Nov 2020 23:07:54 GMT
Subject: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if
 zipinfo-time is not set to false [v2]
In-Reply-To: <l6MR-avalWs2sojerP_WKtZx61r_H0xfEZ3la2jdIuU=.359f5ee1-8b00-4f1e-a258-f98133d86578@github.com>
References: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>
 <-nbhvVlcWVm1c8ZOXDHij7eG-LPTMLHYIzcNqT8MWpE=.f40672cc-4544-47ec-a3c6-f05f5dcda0c7@github.com>
 <l6MR-avalWs2sojerP_WKtZx61r_H0xfEZ3la2jdIuU=.359f5ee1-8b00-4f1e-a258-f98133d86578@github.com>
Message-ID: <zTBdnQBbMRSGiGLxsdXC1sXgA7pZdjVUFy40cH1GCyQ=.d4684e4b-fb3a-4c25-8a35-9dd392ca55f4@github.com>

On Sun, 1 Nov 2020 22:55:48 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> To validate the test, requires info-zip which comes on Mac and linux. It is not included with windows. There are no issues if the Zip is created via java.util.zip or Zip FS

Ah, gotcha. I see and understand the use of the external zip now. This seem a bit fragile - maybe needs to be more graceful in case the system zip doesn't exist or doesn't do what you expect?

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

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

From lancea at openjdk.java.net  Sun Nov  1 23:44:55 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sun, 1 Nov 2020 23:44:55 GMT
Subject: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if
 zipinfo-time is not set to false [v2]
In-Reply-To: <zTBdnQBbMRSGiGLxsdXC1sXgA7pZdjVUFy40cH1GCyQ=.d4684e4b-fb3a-4c25-8a35-9dd392ca55f4@github.com>
References: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>
 <-nbhvVlcWVm1c8ZOXDHij7eG-LPTMLHYIzcNqT8MWpE=.f40672cc-4544-47ec-a3c6-f05f5dcda0c7@github.com>
 <l6MR-avalWs2sojerP_WKtZx61r_H0xfEZ3la2jdIuU=.359f5ee1-8b00-4f1e-a258-f98133d86578@github.com>
 <zTBdnQBbMRSGiGLxsdXC1sXgA7pZdjVUFy40cH1GCyQ=.d4684e4b-fb3a-4c25-8a35-9dd392ca55f4@github.com>
Message-ID: <FzULM71cSepnUpEuNUOIXA78OJxwVckgQM460eeqTAc=.2422c5a4-d26c-4847-a402-7c056f7fdae4@github.com>

On Sun, 1 Nov 2020 23:04:47 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> > To validate the test, requires info-zip which comes on Mac and linux. It is not included with windows. There are no issues if the Zip is created via java.util.zip or Zip FS
> 
> Ah, gotcha. I see and understand the use of the external zip now. This seem a bit fragile - maybe needs to be more graceful in case the system zip doesn't exist or doesn't do what you expect?

Zip is provided on Mac and Linux so unless the system is mis-configured, zip should be available on the path.  Are you suggesting to execute "zip -h" or "which zip" and  skip if zip is not there?  I could make it a manual test but thought given zip should be on linux and Mac that should be OK.  As long as the zip file is created, we are good to go.   I chose not to fall back to Zip FS (or java.util.zip)  to create the zip file as I know this will always pass.

Given the size of the file needed, it would be too large to check a file into the workspace.

Please let me know if you had another idea (Or prefer this to be a manual test)

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

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

From redestad at openjdk.java.net  Sun Nov  1 23:47:56 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 1 Nov 2020 23:47:56 GMT
Subject: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if
 zipinfo-time is not set to false [v2]
In-Reply-To: <FzULM71cSepnUpEuNUOIXA78OJxwVckgQM460eeqTAc=.2422c5a4-d26c-4847-a402-7c056f7fdae4@github.com>
References: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>
 <-nbhvVlcWVm1c8ZOXDHij7eG-LPTMLHYIzcNqT8MWpE=.f40672cc-4544-47ec-a3c6-f05f5dcda0c7@github.com>
 <l6MR-avalWs2sojerP_WKtZx61r_H0xfEZ3la2jdIuU=.359f5ee1-8b00-4f1e-a258-f98133d86578@github.com>
 <zTBdnQBbMRSGiGLxsdXC1sXgA7pZdjVUFy40cH1GCyQ=.d4684e4b-fb3a-4c25-8a35-9dd392ca55f4@github.com>
 <FzULM71cSepnUpEuNUOIXA78OJxwVckgQM460eeqTAc=.2422c5a4-d26c-4847-a402-7c056f7fdae4@github.com>
Message-ID: <r4L1GZQHVVGbgEZT8qo44l4PeybMIPKcid2X-xVe6Iw=.f025f52c-81b5-4b4b-9b50-14e990077537@github.com>

On Sun, 1 Nov 2020 23:41:43 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>>> To validate the test, requires info-zip which comes on Mac and linux. It is not included with windows. There are no issues if the Zip is created via java.util.zip or Zip FS
>> 
>> Ah, gotcha. I see and understand the use of the external zip now. This seem a bit fragile - maybe needs to be more graceful in case the system zip doesn't exist or doesn't do what you expect?
>
>> > To validate the test, requires info-zip which comes on Mac and linux. It is not included with windows. There are no issues if the Zip is created via java.util.zip or Zip FS
>> 
>> Ah, gotcha. I see and understand the use of the external zip now. This seem a bit fragile - maybe needs to be more graceful in case the system zip doesn't exist or doesn't do what you expect?
> 
> Zip is provided on Mac and Linux so unless the system is mis-configured, zip should be available on the path.  Are you suggesting to execute "zip -h" or "which zip" and  skip if zip is not there?  I could make it a manual test but thought given zip should be on linux and Mac that should be OK.  As long as the zip file is created, we are good to go.   I chose not to fall back to Zip FS (or java.util.zip)  to create the zip file as I know this will always pass.
> 
> Given the size of the file needed, it would be too large to check a file into the workspace.
> 
> Please let me know if you had another idea (Or prefer this to be a manual test)

Given the need to generate a 4Gb file on the fly I do feel this maybe ought to be a manual test, or maybe there's some annotation to ensure it's not run on systems with too little disk space (and no compatible zip).

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

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

From lancea at openjdk.java.net  Sun Nov  1 23:51:54 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Sun, 1 Nov 2020 23:51:54 GMT
Subject: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if
 zipinfo-time is not set to false [v2]
In-Reply-To: <r4L1GZQHVVGbgEZT8qo44l4PeybMIPKcid2X-xVe6Iw=.f025f52c-81b5-4b4b-9b50-14e990077537@github.com>
References: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>
 <-nbhvVlcWVm1c8ZOXDHij7eG-LPTMLHYIzcNqT8MWpE=.f40672cc-4544-47ec-a3c6-f05f5dcda0c7@github.com>
 <l6MR-avalWs2sojerP_WKtZx61r_H0xfEZ3la2jdIuU=.359f5ee1-8b00-4f1e-a258-f98133d86578@github.com>
 <zTBdnQBbMRSGiGLxsdXC1sXgA7pZdjVUFy40cH1GCyQ=.d4684e4b-fb3a-4c25-8a35-9dd392ca55f4@github.com>
 <FzULM71cSepnUpEuNUOIXA78OJxwVckgQM460eeqTAc=.2422c5a4-d26c-4847-a402-7c056f7fdae4@github.com>
 <r4L1GZQHVVGbgEZT8qo44l4PeybMIPKcid2X-xVe6Iw=.f025f52c-81b5-4b4b-9b50-14e990077537@github.com>
Message-ID: <ouF7LJAl4tvXVfHEbH8PhqNg1X6kLreMAsPlL9HLuBw=.17ee3c82-ed6b-46c3-9909-4d8116babd4d@github.com>

On Sun, 1 Nov 2020 23:44:53 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Given the need to generate a 4Gb file on the fly I do feel this maybe ought to be a manual test, or maybe there's some annotation to ensure it's not run on systems with too little disk space (and no compatible zip).

OK,  I can make it a manual test, thank you for the feedback Claes!

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

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

From lancea at openjdk.java.net  Mon Nov  2 00:28:08 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 2 Nov 2020 00:28:08 GMT
Subject: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if
 zipinfo-time is not set to false [v3]
In-Reply-To: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>
References: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>
Message-ID: <pDkkWFyFOmTS5xKo3dYLHDeTc22r62KEkfAfzkoQs0s=.847bb570-b722-4626-8ac1-dd379060e23d@github.com>

> Hi,
> 
> Please review the fix for JDK-8255380 which addresses an issue when the Zip file is > 4GB.  Zip FS when processing the CEN extra data does not take into account the fact that there is no specific order to how the extra data fields are written.  Info-ZIP writes the fields in a different order than Zip FS which presents a problem when evaluating the Info-ZIP extended timestamp and the LOC offset is 0XFFFFFFFF therefore the LOC offset needs to be read from the EXTID_ZIP64 extra data prior to attempting to read the LOC extra data field.
> 
> The fix will defer reading of the LOC extra data field, if needed until all of the CEN extra data has been processed.
> 
> Using jdk.nio.zipfs.ZipInfo, you can see the ordering difference of the CEND extra data fields when using Zip FS and info-zip.
> 
> Info-zip is included with Mac OS so the test uses ProcessBuilder to execute zip on Mac OS and Linux.  
> 
> Mach5 tests jdk-tier1, jdk-tier2, and jdk-tier3 run cleanly.
> 
> Best,
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Convert test to being a manual test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/987/files
  - new: https://git.openjdk.java.net/jdk/pull/987/files/efa7b750..bcf73949

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

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

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

From dongbo at openjdk.java.net  Mon Nov  2 03:12:01 2020
From: dongbo at openjdk.java.net (Dong Bo)
Date: Mon, 2 Nov 2020 03:12:01 GMT
Subject: RFR: 8255625: AArch64: Implement Base64.encodeBlock
 accelerator/intrinsic
Message-ID: <Nae3tL5ftv-WnQRfTyvvoJUSOmVXQ9b1SMOGmk15XUU=.d371ec0b-fdf7-4f04-bc7e-81d1e2b9dac5@github.com>

Base64.encodeBlock stub is implemented for x86_64. 
We can also do the same thing for aarch64 with SIMD LD3/ST4/TBL.
A basic idea can be found here: http://0x80.pl/articles/base64-simd-neon.html#encoding-quadwords.

Patch passed jtreg tier1-3 tests with linux-aarch64-server-release build.
Tests in test/jdk/java/util/Base64/* runned specially for the correctness of the implementation and passed.

A JMH micro, Base64Encode.java, is added for performance test.
With different input length (upper-bounded by parameter `maxNumBytes` in the JMH micro),
we witness ~4x improvement with long input and no regression with short input on Kunpeng916 and Kunpeng920.

The Base64Encode.java JMH micro-benchmark results:
Benchmark                      (maxNumBytes)  Mode  Cnt      Score   Error  Units
# kunpeng 916, intrinsic
Base64Encode.testBase64Encode              1  avgt   10    31.564 ? 0.034  ns/op
Base64Encode.testBase64Encode              2  avgt   10    33.921 ? 0.362  ns/op
Base64Encode.testBase64Encode              3  avgt   10    38.015 ? 0.220  ns/op
Base64Encode.testBase64Encode              6  avgt   10    41.115 ? 0.281  ns/op
Base64Encode.testBase64Encode              7  avgt   10    42.161 ? 0.630  ns/op
Base64Encode.testBase64Encode              9  avgt   10    44.797 ? 0.849  ns/op
Base64Encode.testBase64Encode             10  avgt   10    46.013 ? 0.917  ns/op
Base64Encode.testBase64Encode             48  avgt   10    67.984 ? 0.777  ns/op
Base64Encode.testBase64Encode            512  avgt   10   174.494 ? 1.614  ns/op
Base64Encode.testBase64Encode           1000  avgt   10   277.103 ? 0.306  ns/op
Base64Encode.testBase64Encode          20000  avgt   10  4261.018 ? 1.883  ns/op

# kunpeng 916, default
Base64Encode.testBase64Encode              1  avgt   10     31.710 ? 0.234  ns/op
Base64Encode.testBase64Encode              2  avgt   10     33.978 ? 0.305  ns/op
Base64Encode.testBase64Encode              3  avgt   10     40.059 ? 0.444  ns/op
Base64Encode.testBase64Encode              6  avgt   10     47.958 ? 0.328  ns/op
Base64Encode.testBase64Encode              7  avgt   10     49.017 ? 1.305  ns/op
Base64Encode.testBase64Encode              9  avgt   10     53.150 ? 0.769  ns/op
Base64Encode.testBase64Encode             10  avgt   10     55.418 ? 0.316  ns/op
Base64Encode.testBase64Encode             48  avgt   10     93.517 ? 0.391  ns/op
Base64Encode.testBase64Encode            512  avgt   10    494.809 ? 0.413  ns/op
Base64Encode.testBase64Encode           1000  avgt   10    898.581 ? 0.944  ns/op
Base64Encode.testBase64Encode          20000  avgt   10  16464.411 ? 7.582  ns/op

# kunpeng 920, intrinsic
Base64Encode.testBase64Encode              1  avgt   10    17.494 ? 0.012  ns/op
Base64Encode.testBase64Encode              2  avgt   10    21.023 ? 0.169  ns/op
Base64Encode.testBase64Encode              3  avgt   10    25.772 ? 0.138  ns/op
Base64Encode.testBase64Encode              6  avgt   10    30.121 ? 0.347  ns/op
Base64Encode.testBase64Encode              7  avgt   10    31.591 ? 0.238  ns/op
Base64Encode.testBase64Encode              9  avgt   10    32.728 ? 0.395  ns/op
Base64Encode.testBase64Encode             10  avgt   10    35.110 ? 0.215  ns/op
Base64Encode.testBase64Encode             48  avgt   10    48.621 ? 0.314  ns/op
Base64Encode.testBase64Encode            512  avgt   10   113.391 ? 0.554  ns/op
Base64Encode.testBase64Encode           1000  avgt   10   180.749 ? 0.193  ns/op
Base64Encode.testBase64Encode          20000  avgt   10  3273.961 ? 5.706  ns/op

# kunpeng 920, default
Base64Encode.testBase64Encode              1  avgt   10     17.428 ? 0.037  ns/op
Base64Encode.testBase64Encode              2  avgt   10     20.926 ? 0.155  ns/op
Base64Encode.testBase64Encode              3  avgt   10     25.466 ? 0.140  ns/op
Base64Encode.testBase64Encode              6  avgt   10     32.526 ? 0.190  ns/op
Base64Encode.testBase64Encode              7  avgt   10     34.132 ? 0.387  ns/op
Base64Encode.testBase64Encode              9  avgt   10     36.685 ? 0.212  ns/op
Base64Encode.testBase64Encode             10  avgt   10     38.117 ? 0.246  ns/op
Base64Encode.testBase64Encode             48  avgt   10     62.447 ? 0.900  ns/op
Base64Encode.testBase64Encode            512  avgt   10    377.275 ? 0.162  ns/op
Base64Encode.testBase64Encode           1000  avgt   10    700.628 ? 0.509  ns/op
Base64Encode.testBase64Encode          20000  avgt   10  13626.764 ? 3.448  ns/op

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

Commit messages:
 - Merge branch 'master' into aarch64-base64-encoding
 - 8255625: AArch64: Implement Base64.encodeBlock accelerator/intrinsic

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

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

From jlahoda at openjdk.java.net  Mon Nov  2 08:15:21 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 2 Nov 2020 08:15:21 GMT
Subject: RFR: 8236842: Surprising 'multiple elements' behaviour from
 getTypeElement when cross-compiling with --release [v4]
In-Reply-To: <iWe2lgOsak5uDaFjLkz5quSVAL8i_cfVG8TCGh2U55A=.87f0e5cc-54e6-4234-a6bb-2ac9a9f876ab@github.com>
References: <iWe2lgOsak5uDaFjLkz5quSVAL8i_cfVG8TCGh2U55A=.87f0e5cc-54e6-4234-a6bb-2ac9a9f876ab@github.com>
Message-ID: <1dxDS8NcRcAH9S9p038xQo7zA3RVkKrfn6XHqzkXmzg=.76d60e31-96fb-4cee-b6d4-956d76de64e1@github.com>

> Unqualified Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) search for elements across all modules in the module graph, and only return a value when they find exactly one element. This is troublesome, as an element (uniquely) visible from a root module may be "hidden" by an element that is not visible from any root module (i.e. is internal to some module that is not in the root module set). The idea proposed here is that these unqualified methods would first look for elements visible from the root modules, and would search the internals of other modules only if nothing would be found in the first round.
> 
> The draft of the corresponding CSR is here: https://bugs.openjdk.java.net/browse/JDK-8253168.

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

 - Merge branch 'master' into JDK-8236842
 - Linking to root and all modules definition.
 - Merge branch 'master' into JDK-8236842
 - Reflecting review comments - improving javadoc, avoid repeated search of modules that have already been searched.
 - 8253168: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/200/files
  - new: https://git.openjdk.java.net/jdk/pull/200/files/33ca56ed..fa0e316a

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

  Stats: 462759 lines in 4438 files changed: 385829 ins; 55838 del; 21092 mod
  Patch: https://git.openjdk.java.net/jdk/pull/200.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/200/head:pull/200

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

From jlahoda at openjdk.java.net  Mon Nov  2 10:22:02 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 2 Nov 2020 10:22:02 GMT
Subject: Integrated: 8236842: Surprising 'multiple elements' behaviour from
 getTypeElement when cross-compiling with --release
In-Reply-To: <iWe2lgOsak5uDaFjLkz5quSVAL8i_cfVG8TCGh2U55A=.87f0e5cc-54e6-4234-a6bb-2ac9a9f876ab@github.com>
References: <iWe2lgOsak5uDaFjLkz5quSVAL8i_cfVG8TCGh2U55A=.87f0e5cc-54e6-4234-a6bb-2ac9a9f876ab@github.com>
Message-ID: <on9ttvHk0x0erzBu9p1OV9cQdLi7yTBQLNoHJWyhEK0=.1bfeb816-c1e9-4835-a3a2-e4a93280bb02@github.com>

On Wed, 16 Sep 2020 07:57:30 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Unqualified Elements.getTypeElement(CharSequence) and Elements.getPackageElement(CharSequence) search for elements across all modules in the module graph, and only return a value when they find exactly one element. This is troublesome, as an element (uniquely) visible from a root module may be "hidden" by an element that is not visible from any root module (i.e. is internal to some module that is not in the root module set). The idea proposed here is that these unqualified methods would first look for elements visible from the root modules, and would search the internals of other modules only if nothing would be found in the first round.
> 
> The draft of the corresponding CSR is here: https://bugs.openjdk.java.net/browse/JDK-8253168.

This pull request has now been integrated.

Changeset: d05df7c1
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d05df7c1
Stats:     551 lines in 4 files changed: 490 ins; 29 del; 32 mod

8236842: Surprising 'multiple elements' behaviour from getTypeElement when cross-compiling with --release

Reviewed-by: vromero

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

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

From redestad at openjdk.java.net  Mon Nov  2 10:50:56 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 2 Nov 2020 10:50:56 GMT
Subject: RFR: 8255380: (zipfs) ZipFileSystem::readExtra can fail if
 zipinfo-time is not set to false [v3]
In-Reply-To: <pDkkWFyFOmTS5xKo3dYLHDeTc22r62KEkfAfzkoQs0s=.847bb570-b722-4626-8ac1-dd379060e23d@github.com>
References: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>
 <pDkkWFyFOmTS5xKo3dYLHDeTc22r62KEkfAfzkoQs0s=.847bb570-b722-4626-8ac1-dd379060e23d@github.com>
Message-ID: <vrj5fsQoKY_xxjLGi2ng15amemh_89EdP2J0TpUf57w=.cb969360-5ebf-47ef-9034-4679bdee3b88@github.com>

On Mon, 2 Nov 2020 00:28:08 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the fix for JDK-8255380 which addresses an issue when the Zip file is > 4GB.  Zip FS when processing the CEN extra data does not take into account the fact that there is no specific order to how the extra data fields are written.  Info-ZIP writes the fields in a different order than Zip FS which presents a problem when evaluating the Info-ZIP extended timestamp and the LOC offset is 0XFFFFFFFF therefore the LOC offset needs to be read from the EXTID_ZIP64 extra data prior to attempting to read the LOC extra data field.
>> 
>> The fix will defer reading of the LOC extra data field, if needed until all of the CEN extra data has been processed.
>> 
>> Using jdk.nio.zipfs.ZipInfo, you can see the ordering difference of the CEND extra data fields when using Zip FS and info-zip.
>> 
>> Info-zip is included with Mac OS so the test uses ProcessBuilder to execute zip on Mac OS and Linux.  
>> 
>> Mach5 tests jdk-tier1, jdk-tier2, and jdk-tier3 run cleanly.
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Convert test to being a manual test

Marked as reviewed by redestad (Reviewer).

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

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

From mcimadamore at openjdk.java.net  Mon Nov  2 11:11:56 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 2 Nov 2020 11:11:56 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator)
In-Reply-To: <wW7_WrOpEbYNHP12tT3x2ujcGAl2O35RyZud9SY_43w=.7848a0e3-0015-408e-9dd0-44ab545c7465@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <pS93Tkclki7y3uzfofkeCRZiZV8Wbb0fpPTI4aOHZXA=.b467ed27-1874-4302-833d-e022ef913dbb@github.com>
 <gKyi3UsqpyQ6bWnRX3JIEsc5-4SEMZmHLFdz0gRgRoY=.2b655f9f-551c-4454-9f21-1c9dbf2dcc24@github.com>
 <wW7_WrOpEbYNHP12tT3x2ujcGAl2O35RyZud9SY_43w=.7848a0e3-0015-408e-9dd0-44ab545c7465@github.com>
Message-ID: <pb2UdDdnfCqIg68FQimNJiWEJed1N6XEQpnQlFn7W64=.fac4bef1-0c41-4ed1-ab24-caf9aee09aa0@github.com>

On Sun, 1 Nov 2020 16:06:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Now that MemorySegment is AutoCloseable then maybe the term "alive" should be replaced with "open" or "closed" and isAlive replaced with isOpen is isClosed.

While the reason for the method being called "isAlive" are mostly historical (the old Panama pointer API had such a method), I think I still stand behind the current naming scheme. For temporal bounds, I think "isAlive" works better than "isOpened".

> MappedMemorySegments. The force method specifies a write back guarantee but at the same time, the implNote in the class description suggests that the methods might be a no-op. You might want to adjust the wording to avoid any suggestion that force might be a no-op.

The comment that this operation could be no-op was borrowed from the `MappedByteBuffer` API; looking at the impl, it seems that you are right that, under no circumstances (unless the segment has length zero) this should be a no-op. How do you suggest I proceed?

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

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

From jvernee at openjdk.java.net  Mon Nov  2 11:22:07 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 2 Nov 2020 11:22:07 GMT
Subject: RFR: 8254354: Add a withInvokeExactBehavior() VarHandle
 combinator [v12]
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <th7IW9wqkBXxmedkRXzI7BH5TGmOVJDiPs_b9Fc2Okc=.66796688-a2c7-40d3-92ff-54093f40b2c6@github.com>

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn
> 
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375

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

  s/an arity/and arity

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/843/files
  - new: https://git.openjdk.java.net/jdk/pull/843/files/d49e3f30..e92bd30f

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

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

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

From mcimadamore at openjdk.java.net  Mon Nov  2 11:29:54 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 2 Nov 2020 11:29:54 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator)
In-Reply-To: <wW7_WrOpEbYNHP12tT3x2ujcGAl2O35RyZud9SY_43w=.7848a0e3-0015-408e-9dd0-44ab545c7465@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <pS93Tkclki7y3uzfofkeCRZiZV8Wbb0fpPTI4aOHZXA=.b467ed27-1874-4302-833d-e022ef913dbb@github.com>
 <gKyi3UsqpyQ6bWnRX3JIEsc5-4SEMZmHLFdz0gRgRoY=.2b655f9f-551c-4454-9f21-1c9dbf2dcc24@github.com>
 <wW7_WrOpEbYNHP12tT3x2ujcGAl2O35RyZud9SY_43w=.7848a0e3-0015-408e-9dd0-44ab545c7465@github.com>
Message-ID: <x0QEmnZ93qnHvRh3E1Vnudm-RseXooykHXD4X3FeNkA=.9c63d73e-c20e-4219-a1a4-1126aa55085f@github.com>

On Sun, 1 Nov 2020 16:06:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The javadoc for copyFrom isn't changed in this update but I notice it specifies IndexOutOfBoundException when the source segment is larger than the receiver, have other exceptions been examined?

This exception is consistent with other uses of this exception throughout this API (e.g. when writing a segment out of bounds).

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

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

From mcimadamore at openjdk.java.net  Mon Nov  2 11:59:09 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 2 Nov 2020 11:59:09 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v20]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <bkQboBlDzB9wnFtO7R7xv6uzNkuz5MSOffBcR04DpJw=.51fa000b-27f9-4450-b691-ae80d777060f@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

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

  Address comments from @AlanBateman

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/bd400615..8225bf2e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=18-19

  Stats: 121 lines in 9 files changed: 14 ins; 53 del; 54 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

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

From serb at openjdk.java.net  Mon Nov  2 12:15:02 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Mon, 2 Nov 2020 12:15:02 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v20]
In-Reply-To: <bkQboBlDzB9wnFtO7R7xv6uzNkuz5MSOffBcR04DpJw=.51fa000b-27f9-4450-b691-ae80d777060f@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <bkQboBlDzB9wnFtO7R7xv6uzNkuz5MSOffBcR04DpJw=.51fa000b-27f9-4450-b691-ae80d777060f@github.com>
Message-ID: <Tqx-7fGOXO3xOD1hzZGsY322kCRmRT5aqdWr1dU33Cc=.b08c6275-a8f9-4f79-9e5f-36a0d28cac95@github.com>

On Mon, 2 Nov 2020 11:59:09 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
>> 
>> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
>> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
>> 
>> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
>> 
>> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
>> 
>> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
>> 
>> Thanks 
>> Maurizio 
>> 
>> Javadoc: 
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff: 
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR: 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
>> * `MemoryHandles`
>>   * drop `withOffset` combinator
>>   * drop `withStride` combinator
>>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
>> * `Addressable`
>>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
>> * `MemoryLayouts`
>>   * A new layout, for machine addresses, has been added to the mix.
>> 
>> 
>> 
>> ### Implementation changes
>> 
>> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
>> 
>> #### Shared segments
>> 
>> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
>> 
>> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
>> 
>> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
>> 
>> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
>> 
>> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
>> 
>> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
>> 
>> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
>> 
>> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
>> 
>> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
>> 
>> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
>> 
>> #### Memory access var handles overhaul
>> 
>> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
>> 
>> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
>> 
>> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
>> 
>> #### Test changes
>> 
>> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
>> 
>> [1] - https://openjdk.java.net/jeps/393
>> [2] - https://openjdk.java.net/jeps/389
>> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
>> [4] - https://openjdk.java.net/jeps/312
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address comments from @AlanBateman

test/jdk/java/foreign/TestCleaner.java line 8:

> 6:  * under the terms of the GNU General Public License version 2 only, as
> 7:  * published by the Free Software Foundation.  Oracle designates this
> 8:  * particular file as subject to the "Classpath" exception as provided

"Classpath exception" could be dropped?

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

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

From mcimadamore at openjdk.java.net  Mon Nov  2 14:18:14 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 2 Nov 2020 14:18:14 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v21]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <m_p5iGDcdZXleg1tH5Ys7jnCdPRdOvPb54OQ7S8vKOg=.5a15d1b2-7fe0-40a5-9e0a-e27d40933c16@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

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

  Addess remaining feedback from @AlanBateman and @mrserb

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/8225bf2e..e2f69ec0

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

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

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

From roland at openjdk.java.net  Mon Nov  2 16:22:12 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 2 Nov 2020 16:22:12 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and ranges
Message-ID: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>

This change add 3 new methods in Objects:

public static long checkIndex(long index, long length)
public static long checkFromToIndex(long fromIndex, long toIndex, long length)
public static long checkFromIndexSize(long fromIndex, long size, long length)

This mirrors the int utility methods that were added by JDK-8135248
with the same motivations.

As is the case with the int checkIndex(), the long checkIndex() method
is JIT compiled as an intrinsic. It allows the JIT to compile
checkIndex to an unsigned comparison and properly recognize it as
a range check that then becomes a candidate for the existing range check
optimizations. This has proven to be important for panama's
MemorySegment API and a prototype of this change (with some extra c2
improvements) showed that panama micro benchmark results improve
significantly.

This change includes:

- the API change
- the C2 intrinsic
- tests for the API and the C2 intrinsic

This is a joint work with Paul who reviewed and reworked the API change
and filled the CSR.

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

Commit messages:
 - Update headers and add intrinsic to Graal test ignore list
 - move compiler test and add bug to test
 - non x86_64 arch support
 - c2 test case
 - intrinsic
 - Use overloads of method names.
 - Vladimir's comments
 - checkLongIndex

Changes: https://git.openjdk.java.net/jdk/pull/1003/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1003&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255150
  Stats: 895 lines in 30 files changed: 848 ins; 1 del; 46 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1003.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1003/head:pull/1003

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

From kravikumar at openjdk.java.net  Mon Nov  2 16:38:00 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Mon, 2 Nov 2020 16:38:00 GMT
Subject: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d
Message-ID: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>

Hi Guys,

Please review the integration of tzdata2020d to JDK.

Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html
Bug: https://bugs.openjdk.java.net/browse/JDK-8255226

TestZoneInfo310.java test failure is addressed along with it. The last rule affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.

Regression Tests pass along with JCK.

Please let me know if the changes are good to push.

Thanks,
Kiran

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

Commit messages:
 - 8255226: (tz) Upgrade time-zone data to tzdata2020d

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

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

From naoto at openjdk.java.net  Mon Nov  2 16:53:54 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 16:53:54 GMT
Subject: Integrated: 8255671: Bidi.reorderVisually has misleading exception
 messages
In-Reply-To: <irFBtIXgezDQi9atpQK8wSsmX2xHxLmzCh9oRK4E7KM=.e12f1d21-76cf-402f-a2e7-fbc59853acf5@github.com>
References: <irFBtIXgezDQi9atpQK8wSsmX2xHxLmzCh9oRK4E7KM=.e12f1d21-76cf-402f-a2e7-fbc59853acf5@github.com>
Message-ID: <URkwSJmYy0wJlQT8LMwJRk9les68gEjUDfiYBbXFMwk=.e0a6e4d3-b930-46d9-9fbf-c86a4a6038a3@github.com>

On Fri, 30 Oct 2020 22:23:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple message fix that follows JDK-8255242.
> 
> Naoto

This pull request has now been integrated.

Changeset: 6dac8d27
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6dac8d27
Stats:     35 lines in 2 files changed: 32 ins; 0 del; 3 mod

8255671: Bidi.reorderVisually has misleading exception messages

Reviewed-by: joehw

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

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

From naoto at openjdk.java.net  Mon Nov  2 17:18:02 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 17:18:02 GMT
Subject: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d
In-Reply-To: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
Message-ID: <W3jxMBMG3Cs9-ppnD9uj_WS-GDDUqr56ZbnRh7g91Y0=.88a99cdf-ce3b-4538-a055-b87069949ab3@github.com>

On Mon, 2 Nov 2020 16:29:07 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the integration of tzdata2020d to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
> 
> TestZoneInfo310.java test failure is addressed along with it. The last rule affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

The test case needs copyright year change to 2020.

test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 201:

> 199:                 zid.equals("Iran") || // last rule mismatch
> 200:                 zid.equals("Asia/Gaza") || // last rule mismatch
> 201:                 zid.equals("Asia/Hebron")) { // last rule mismatch

Can you explain why these zones are failing? The criteria for excluding failing tests here is that the zone has negative dst and last rules beyond 2037, and I don't think those newly excluded zones suffice those.

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

Changes requested by naoto (Reviewer).

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

From lancea at openjdk.java.net  Mon Nov  2 17:43:03 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 2 Nov 2020 17:43:03 GMT
Subject: RFR: 8255529:  Remove unused methods from java.util.zip.ZipFile
Message-ID: <ZarHa1XPXipzw_oNGAZHIDxoxKurvzUP5W6zROk0sDk=.b11b8a52-c1c1-4c0e-9893-011cac4e3920@github.com>

Please review this fix for JDK-8255529 which removes methods that were unused and were added back merge in July

Mach5 jdk-tier1, jdk-tier2, jdk-tier3 ran clean.

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

Commit messages:
 - Remove unused methods

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

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

From scolebourne at openjdk.java.net  Mon Nov  2 17:44:00 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Mon, 2 Nov 2020 17:44:00 GMT
Subject: RFR: 8247781: Day periods support [v3]
In-Reply-To: <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
Message-ID: <96h7JM1OhKA5v5Bx9qj9n08oRHav8V13E6Uor0m8SVw=.6960968e-0e3a-4ceb-95d0-a293838225ba@github.com>

On Fri, 30 Oct 2020 11:06:59 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed exception messages.
>
> src/java.base/share/classes/java/time/format/Parsed.java line 497:
> 
>> 495:                         AMPM_OF_DAY.checkValidValue(ap);
>> 496:                     }
>> 497:                     updateCheckDayPeriodConflict(AMPM_OF_DAY, midpoint / 720);
> 
> No need to put `AMPM_OF_DAY` back in here because you've already resolved it to `HOUR_OF_DAY` and `MINUTE_OF_HOUR`. There probably does need to be validation to check that the day period agrees with the AM/PM value.

Line can still be removed AFAICT

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

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

From scolebourne at openjdk.java.net  Mon Nov  2 17:44:02 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Mon, 2 Nov 2020 17:44:02 GMT
Subject: RFR: 8247781: Day periods support [v3]
In-Reply-To: <GLJiZaszK-Ut5Ylcw7XH5fZlSdthxIsntMr6HenWf6c=.d16b1861-d000-4338-adef-80d5cd82b29f@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <GLJiZaszK-Ut5Ylcw7XH5fZlSdthxIsntMr6HenWf6c=.d16b1861-d000-4338-adef-80d5cd82b29f@github.com>
Message-ID: <v6pthmUP-A2POQbI-tGr0Vm-RzG1rZp9A6sp2oyw4z8=.6f4bb8c3-2aef-420a-9a82-796eebb352e3@github.com>

On Fri, 30 Oct 2020 22:03:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed exception messages.

test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 656:

> 654:             {"h B", "11 at night", 23},
> 655:             {"h B", "3 at night", 3},
> 656:             {"h B", "11 in the morning", 11},

Need tests for "51 in the morning" (which should parse in LENIENT as "3 in the morning" plus 2 days, see how HOUR_OF_DAY=51 works in general.

Similar issue with HOUR_OF_AMPM=3 and AMPM_OF_DAY=4.

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

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

From scolebourne at openjdk.java.net  Mon Nov  2 17:43:59 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Mon, 2 Nov 2020 17:43:59 GMT
Subject: RFR: 8247781: Day periods support [v3]
In-Reply-To: <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>
Message-ID: <Tu7yq15XUzC2-z2v40tNUGHkTkYW37q7RUiop9pB4xU=.d61a3059-6929-4b45-8a16-df33469ab56b@github.com>

On Fri, 30 Oct 2020 21:30:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/Parsed.java line 472:
>> 
>>> 470:         }
>>> 471:         if (dayPeriod != null) {
>>> 472:             if (fieldValues.containsKey(HOUR_OF_DAY)) {
>> 
>> Are we certain that the CLDR data does not contain day periods based on minutes as well as hours? This logic does not check against MINUTE_OF_HOUR for example. The logic also conflicts with the spec Javadoc that says MINUTE_OF_HOUR is validated.
>
> MINUTE_OF_HOUR without HOUR_OF_DAY/HOUR_OF_AMPM may not make any sense, so it is only validated in updateCheckDayPeriodConflict.

But can you get a CLDR rule that says "at night" before 05:30 and "In the morning" from 05:30 onwards? If you can then I don't think it is handled, because HOUR_OF_DAY and MINUTE_OF_HOUR are not used together when checking against DayPeriod.

>> src/java.base/share/classes/java/time/format/Parsed.java line 500:
>> 
>>> 498:                 }
>>> 499:             }
>>> 500:         }
>> 
>> Looking at the existing logic, the `AMPM_OF_DAY` field is completely ignored if there is no `HOUR_OF_AMPM` field. Thus, there is no validation to check `AMPM_OF_DAY` against `HOUR_OF_DAY`. This seems odd. (AMPM_OF_DAY = 0 and HOUR_OF_DAY=18 does not look like it throws an exception, when it probably should).
>> 
>> On solution would be for `AMPM_OF_DAY` to be resolved to a day period at line 427, checking for conflicts with any parsed day period. (a small bug fix behavioural change)
>
> There are cases where a period crosses midnight, e.g., 23:00-04:00 so it cannot validate am/pm, so I decided to just override ampm with dayperiod without validating.

Pulling on this a little more.

As the PR stands, it seems that if the user passes in text with just a day-period of "AM" they get a `LocalTime` of 06:00 but if they pass in `AMPM_OF_DAY` of "AM" the get no `LocalTime` in the result. Is that right? If so, I don't think this is sustainable.

Thats why I think `AMPM_OF_DAY` will have to be resolved to a dayPeriod of "am" or "pm". If dayPeriod is more precise than `AMPM_OF_DAY`, then dayPeriod can silently take precedence

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

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

From jjg at openjdk.java.net  Mon Nov  2 17:52:56 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 Nov 2020 17:52:56 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v4]
In-Reply-To: <DrJrH40To0Fq7TDeDV6ni9sik4WVsH-5pk6zcBUkR3A=.4f2bdac5-7269-40d5-9ad2-e997e281f21a@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
 <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
 <281-fNSKFfd-qngLAcLkMFdmKe-XHD-0qKCEh4OGvog=.82b534a0-e57a-41bf-ba94-e487601b2773@github.com>
 <DrJrH40To0Fq7TDeDV6ni9sik4WVsH-5pk6zcBUkR3A=.4f2bdac5-7269-40d5-9ad2-e997e281f21a@github.com>
Message-ID: <0nw1ywk_bFqAUlU9DuC_79QXVgx63FEsf3Jwt_Y187M=.1164173f-b6d5-4f20-bc66-f722ebb0be08@github.com>

On Thu, 29 Oct 2020 09:43:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> I don't think there should be much interaction with -source <older-version>. We don't support preview features from previous version or preview class files from previous versions, so I think it should be enough to handle the currently present preview features.
>
> We don't support preview features from previous releases, AFAIK. So javadoc for JDK 16 should not accept e.g. record class when running with  -source 15.

Yeah, my recollection is that I was wondering whether preview-related code needs to be "guarded" to only work in the current release. But, I guess we may get the right effect (of forbidding preview features in older code) from the javac front end, so that in javadoc we can be assured that there are no instances of what may still be preview features in older code (i.e with older --source/--rlease options)

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

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

From jjg at openjdk.java.net  Mon Nov  2 17:52:56 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 Nov 2020 17:52:56 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v4]
In-Reply-To: <R2KYb4nzD1FZrz1hP4dXxn6a16GAAHCjlglZ6V6U45I=.b421488e-2f19-4511-8a71-c52f18dfe740@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
 <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
 <R2KYb4nzD1FZrz1hP4dXxn6a16GAAHCjlglZ6V6U45I=.b421488e-2f19-4511-8a71-c52f18dfe740@github.com>
Message-ID: <bnNujCWoLYgdYrY_DE7HbPU31mxMVErp49NoXt-aRp8=.dd9add9c-ee0b-40a4-975b-65f8b39d1ba2@github.com>

On Thu, 29 Oct 2020 09:26:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/tool/ElementsTable.java line 1288:
>> 
>>> 1286:                 case FIELD: case INSTANCE_INIT: case LOCAL_VARIABLE: case PARAMETER:
>>> 1287:                 case RESOURCE_VARIABLE: case STATIC_INIT: case TYPE_PARAMETER:
>>> 1288:                 case RECORD_COMPONENT:
>> 
>> I'm not saying this is wrong, but I'd like to understand why it is necessary.
>
> HtmlDocletWriter.getPreviewNotes analyzes classes and their members, to see if some are using aspects that are under preview. When looking at the members, it uses utils.isIncluded on the member, and that eventually gets here. And if the member is a RECORD_COMPONENT, it would fail here. But we can avoid asking for RECORD_COMPONENTS, if needed.

ok

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

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

From naoto at openjdk.java.net  Mon Nov  2 17:58:00 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 17:58:00 GMT
Subject: RFR: 8255529:  Remove unused methods from java.util.zip.ZipFile
In-Reply-To: <ZarHa1XPXipzw_oNGAZHIDxoxKurvzUP5W6zROk0sDk=.b11b8a52-c1c1-4c0e-9893-011cac4e3920@github.com>
References: <ZarHa1XPXipzw_oNGAZHIDxoxKurvzUP5W6zROk0sDk=.b11b8a52-c1c1-4c0e-9893-011cac4e3920@github.com>
Message-ID: <uAyFSMeT6MIGwHubgLrhQ4zVXI74oSGgYpt29VNsJaU=.764edc18-4017-4a94-9b1a-cc7a07478f29@github.com>

On Mon, 2 Nov 2020 17:33:57 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this fix for JDK-8255529 which removes methods that were unused and were added back merge in July
> 
> Mach5 jdk-tier1, jdk-tier2, jdk-tier3 ran clean.

Looks good to me.

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

Marked as reviewed by naoto (Reviewer).

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

From kravikumar at openjdk.java.net  Mon Nov  2 18:09:03 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Mon, 2 Nov 2020 18:09:03 GMT
Subject: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d
In-Reply-To: <W3jxMBMG3Cs9-ppnD9uj_WS-GDDUqr56ZbnRh7g91Y0=.88a99cdf-ce3b-4538-a055-b87069949ab3@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
 <W3jxMBMG3Cs9-ppnD9uj_WS-GDDUqr56ZbnRh7g91Y0=.88a99cdf-ce3b-4538-a055-b87069949ab3@github.com>
Message-ID: <_-CfMNeat8oHCidIqA-s6I6ZQPcHAa-z8NRg1h9mm4c=.c4846ff2-a653-4a50-b66a-8fd455e2d729@github.com>

On Mon, 2 Nov 2020 17:10:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi Guys,
>> 
>> Please review the integration of tzdata2020d to JDK.
>> 
>> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
>> 
>> TestZoneInfo310.java test failure is addressed along with it. The last rule affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
>> 
>> Regression Tests pass along with JCK.
>> 
>> Please let me know if the changes are good to push.
>> 
>> Thanks,
>> Kiran
>
> test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 201:
> 
>> 199:                 zid.equals("Iran") || // last rule mismatch
>> 200:                 zid.equals("Asia/Gaza") || // last rule mismatch
>> 201:                 zid.equals("Asia/Hebron")) { // last rule mismatch
> 
> Can you explain why these zones are failing? The criteria for excluding failing tests here is that the zone has negative dst and last rules beyond 2037, and I don't think those newly excluded zones suffice those.

It's probably these last rule what is causing the issue

Rule Palestine	2020	max	-	Mar	Sat>=24	0:00	1:00	S
Rule Palestine	2020	max	-	Oct	Sat>=24	1:00	0	-

The failure seen is 

******************************
Asia/Gaza : Asia/Gaza
    -------------
    SimpleTimeZone (NG)
       stz=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=7,startTime=0,startTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=7,endTime=3600000,endTimeMode=0]
      stz0=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=24,startDayOfWeek=7,startTime=0,startTimeMode=0,endMode=3,endMonth=9,endDay=24,endDayOfWeek=7,endTime=3600000,endTimeMode=0]

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

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

From cjashfor at linux.ibm.com  Mon Nov  2 18:09:36 2020
From: cjashfor at linux.ibm.com (Corey Ashford)
Date: Mon, 2 Nov 2020 10:09:36 -0800
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v8]
In-Reply-To: <-7PHVafzbyMukuWngsX5bdLvJPubN2KzjMWM2lrQnCs=.a278b608-3e1c-4126-9791-efe18a5d8d5e@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
 <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
 <_JR-e3ZsRFwvZCR7ws34z5jLjp2kJQ1bu4gyl0RG1XU=.ec3040cf-8147-4dcd-b87d-4fd9be4eb59e@github.com>
 <-7PHVafzbyMukuWngsX5bdLvJPubN2KzjMWM2lrQnCs=.a278b608-3e1c-4126-9791-efe18a5d8d5e@github.com>
Message-ID: <8c320241-a64f-380a-6e02-6fdf5878cd10@linux.ibm.com>

On 10/26/20 12:47 PM, Paul Murphy wrote:
> On Thu, 22 Oct 2020 22:06:11 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:
> 
>>> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3878:
>>>
>>>> 3876:             // |    Element    |             |                      |                      |             |             |                      |                      |             |
>>>> 3877:             // +===============+=============+======================+======================+=============+=============+======================+======================+=============+
>>>> 3878:             // | after vaddubm | 00||b0:0..5 | 00||b0:6..7||b1:0..3 | 00||b1:4..7||b2:0..1 | 00||b2:2..7 | 00||b3:0..5 | 00||b3:6..7||b4:0..3 | 00||b4:4..7||b5:0..1 | 00||b5:2..7 |
>>>
>>> An extra line here showing how the 8 6-bit values above get mapping into 6 bytes greatly help my brain out. (likewise for the <P10 case below too)
>>
>> Just to make sure I understand, you're not asking for a change here, is that right?
> 
> I think the first line should also express the initial layout of the 6 bit values similar to the linked algo.  I think changing this comment add an extra line which describes the bits as they leave `vaddubm` would be helpful to understand the demangling here. (e.g the `00aaaaaa 00bbbbbb 00ccccc 00dddddd` comments in the linked paper)

Ok, got it.  I will change it as you suggest to create a better mental 
link between the terminology used in the paper and the bit numbering I 
chose to use in the code comments.

> 
>>> src/hotspot/cpu/ppc/stubGenerator_ppc.cpp line 3884:
>>>
>>>> 3882:             // |   vec_0x3fs   |  00111111   |       00111111       |       00111111       |  00111111   |  00111111   |       00111111       |       00111111       |  00111111   |
>>>> 3883:             // +---------------+-------------+----------------------+----------------------+-------------+-------------+----------------------+----------------------+-------------+
>>>> 3884:             // | after vpextd  |   b5:0..7   |       b4:0..7        |       b3:0..7        |   b2:0..7   |   b1:0..7   |       b0:0..7        |       00000000       |  00000000   |
>>>
>>> Are theses comments correct or am I misunderstanding this? I read the final result as something starting as `b5:2..7 || b4:4..7|| b5:0..1` from vpextd.
>>
>> Because the bytes are displayed e15..e8, instead of the other way around, it's hard to follow.  As an example, consider just the last four bytes of the table, but displayed in the reverse order:
>>
>> 00||b0:0..5    00||b0:6..7||b1:0..3    00||b1:4..7||b2:0..1    00||b2:2..7
>>
>> After vpextd with bit select pattern 00111111 for all bytes:
>>
>> b0:0..5||b0:6..7    b1:0..3||1:4..7    b2:0..1||b2:2..7
>> =
>> b0:0..7    b1:0..7    b2:0..7
>>
>> Should I reverse the order of this table with a comment at the top, to explain the reason for the reversal?  It seems like a good idea.
> 
> Since you are operating on doublewords here, expressing this as operations on a doubleword instead of bytes would be more intuitive here.  I think the lane mappings for little endian are what throw me off.
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/293
> 

Got it.  I will try that out and see how it looks compared to the 
byte-swapped version.  Also I will add a comment about vpextd operating 
on doublewords.

As a side note, on github, it's waiting for you to check a box: "I agree 
to the OpenJDK Terms of use for all comments I make in a project in the 
OpenJDK GitHub organization.".  Until you tick that box, your comment 
can't be seen there.

https://github.com/openjdk/jdk/pull/293#discussion_r512214354

Thanks,

- Corey


From redestad at openjdk.java.net  Mon Nov  2 18:13:55 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Mon, 2 Nov 2020 18:13:55 GMT
Subject: RFR: 8255529:  Remove unused methods from java.util.zip.ZipFile
In-Reply-To: <ZarHa1XPXipzw_oNGAZHIDxoxKurvzUP5W6zROk0sDk=.b11b8a52-c1c1-4c0e-9893-011cac4e3920@github.com>
References: <ZarHa1XPXipzw_oNGAZHIDxoxKurvzUP5W6zROk0sDk=.b11b8a52-c1c1-4c0e-9893-011cac4e3920@github.com>
Message-ID: <h-nKh6PmkXOOrsYV4xCr1jPyd7-72JU7Sfe3YREvhNQ=.b229d0bc-79a2-444e-9017-970c68f5ad9e@github.com>

On Mon, 2 Nov 2020 17:33:57 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this fix for JDK-8255529 which removes methods that were unused and were added back merge in July
> 
> Mach5 jdk-tier1, jdk-tier2, jdk-tier3 ran clean.

Marked as reviewed by redestad (Reviewer).

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

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

From jlahoda at openjdk.java.net  Mon Nov  2 18:15:09 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 2 Nov 2020 18:15:09 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

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

 - Removing trailing whitespace.
 - Merging master into JDK-8250768.
 - Updating tests after records are a final feature.
 - Fixing tests.
 - Finalizing removal of record preview hooks.
 - Merging master into JDK-8250768
 - Reflecting review comments.
 - Merge branch 'master' into JDK-8250768
 - Removing unnecessary cast.
 - Using a more correct way to get URLs.
 - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900

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

Changes: https://git.openjdk.java.net/jdk/pull/703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=05
  Stats: 3012 lines in 142 files changed: 2521 ins; 260 del; 231 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

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

From naoto at openjdk.java.net  Mon Nov  2 18:18:00 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 18:18:00 GMT
Subject: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d
In-Reply-To: <_-CfMNeat8oHCidIqA-s6I6ZQPcHAa-z8NRg1h9mm4c=.c4846ff2-a653-4a50-b66a-8fd455e2d729@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
 <W3jxMBMG3Cs9-ppnD9uj_WS-GDDUqr56ZbnRh7g91Y0=.88a99cdf-ce3b-4538-a055-b87069949ab3@github.com>
 <_-CfMNeat8oHCidIqA-s6I6ZQPcHAa-z8NRg1h9mm4c=.c4846ff2-a653-4a50-b66a-8fd455e2d729@github.com>
Message-ID: <3BuHmUaG3MrBs7zQdpb8uiAxEQGUGO8YhdADRKBGaqw=.7276ab51-8823-4f20-be80-6c003212f317@github.com>

On Mon, 2 Nov 2020 18:06:28 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

>> test/jdk/sun/util/calendar/zi/TestZoneInfo310.java line 201:
>> 
>>> 199:                 zid.equals("Iran") || // last rule mismatch
>>> 200:                 zid.equals("Asia/Gaza") || // last rule mismatch
>>> 201:                 zid.equals("Asia/Hebron")) { // last rule mismatch
>> 
>> Can you explain why these zones are failing? The criteria for excluding failing tests here is that the zone has negative dst and last rules beyond 2037, and I don't think those newly excluded zones suffice those.
>
> It's probably these last rule what is causing the issue
> 
> Rule Palestine	2020	max	-	Mar	Sat>=24	0:00	1:00	S
> Rule Palestine	2020	max	-	Oct	Sat>=24	1:00	0	-
> 
> The failure seen is 
> 
> ******************************
> Asia/Gaza : Asia/Gaza
>     -------------
>     SimpleTimeZone (NG)
>        stz=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=7,startTime=0,startTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=7,endTime=3600000,endTimeMode=0]
>       stz0=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=24,startDayOfWeek=7,startTime=0,startTimeMode=0,endMode=3,endMonth=9,endDay=24,endDayOfWeek=7,endTime=3600000,endTimeMode=0]

My question is why it is failing. Have you figured it? The existing exceptions are either negative DST or last rule beyond 2037, which javazic cannot handle. The changes introduced with 2020d does not meet either of them. Unless we know why it is failing, we cannot be sure we can exclude it.

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

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

From lancea at openjdk.java.net  Mon Nov  2 18:29:58 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 2 Nov 2020 18:29:58 GMT
Subject: Integrated: 8255529: Remove unused methods from java.util.zip.ZipFile
In-Reply-To: <ZarHa1XPXipzw_oNGAZHIDxoxKurvzUP5W6zROk0sDk=.b11b8a52-c1c1-4c0e-9893-011cac4e3920@github.com>
References: <ZarHa1XPXipzw_oNGAZHIDxoxKurvzUP5W6zROk0sDk=.b11b8a52-c1c1-4c0e-9893-011cac4e3920@github.com>
Message-ID: <coNvzSNuTSUNcfVQ4jOMpbzk1hYZ0zVrOVe1rsvapC8=.ceeb9159-b4e7-40c8-9178-f077d177aaa8@github.com>

On Mon, 2 Nov 2020 17:33:57 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Please review this fix for JDK-8255529 which removes methods that were unused and were added back merge in July
> 
> Mach5 jdk-tier1, jdk-tier2, jdk-tier3 ran clean.

This pull request has now been integrated.

Changeset: 05bcd67e
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/05bcd67e
Stats:     12 lines in 1 file changed: 0 ins; 12 del; 0 mod

8255529: Remove unused methods from java.util.zip.ZipFile

Reviewed-by: naoto, redestad

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

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

From jjg at openjdk.java.net  Mon Nov  2 20:25:10 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 Nov 2020 20:25:10 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
Message-ID: <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>

On Mon, 2 Nov 2020 18:15:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
>> 
>> The notable changes are:
>> 
>>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>>  
>>  Please also see the CSR [6] for more information.
>>  
>>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
> 
>  - Removing trailing whitespace.
>  - Merging master into JDK-8250768.
>  - Updating tests after records are a final feature.
>  - Fixing tests.
>  - Finalizing removal of record preview hooks.
>  - Merging master into JDK-8250768
>  - Reflecting review comments.
>  - Merge branch 'master' into JDK-8250768
>  - Removing unnecessary cast.
>  - Using a more correct way to get URLs.
>  - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900

I have read all the files. 

I have added a n umber of various minor non-blocking comments (no need for re-review( to fix these.  But I have a couple of comments/questions before finally giving approval.
There's a comment in `PreviewListWriter` about annotation members that needs too be addressed, and I wonder is RECORD and RECORD_COMPONENT need to be added into PreviewElementKind.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 75:

> 73:          * A key for testing.
> 74:          */
> 75:         TEST,

Slightly weird

src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskPool.java line 257:

> 255:             //when patching modules (esp. java.base), it may be impossible to
> 256:             //clear the symbols read from the patch path:
> 257:             polluted |= get(JavaFileManager.class).hasLocation(StandardLocation.PATCH_MODULE_PATH);

OK, but looks unrelated to primary work

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 218:

> 216:         return Errors.PreviewFeatureDisabledClassfile(classfile, majorVersionToSource.get(majorVersion).name);
> 217:     }
> 218: 

Up above in isPreview, lines 185-188, I'm supervised it's not a `switch` statement.  (Can't annotate those lines directly)

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 89:

> 87:     @Override
> 88:     protected Content getDeprecatedOrPreviewLink(Element member) {
> 89:         Content content = new ContentBuilder();

Yeah the shorter name is good here and more in keeping with the code style

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 93:

> 91:         if (!utils.isConstructor(member)) {
> 92:             content.add(".");
> 93:             content.add(member.getSimpleName());

this is OK, but generally FYI, `Content` is now set up to allow chained method calls.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassUseWriter.java line 436:

> 434:                 configuration, LinkInfoImpl.Kind.CLASS_USE_HEADER, typeElement)
> 435:                 .label(resources.getText("doclet.Class"))
> 436:                 .skipPreview(true));

@hns General comment, not directly related to this review: is it worth a cleanup to fold the sequence `getLink(new LinkInfoImpl(...))` into a hypothetical new `LinkBuilder` ?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java line 221:

> 219:         if (modifiers.endsWith(" ")) {
> 220:             pre.add(" ");
> 221:         }

Obligatory ugh that `modifiers` is a string and that it might end with a space. This is a possibility for future cleanup.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ClassWriterImpl.java line 283:

> 281:                 if (isFirst) {
> 282:                     pre.add(DocletConstants.NL);
> 283:                     pre.add("permits");

Note for javadoc-dev folk: we should have a better  more consistent way of handling keywords

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HelpWriter.java line 254:

> 252:             contentTree.add(section);
> 253:         }
> 254: 

??

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/HtmlConfiguration.java line 145:

> 143:     // which performs a somewhat similar role
> 144:     public enum ConditionalPage {
> 145:         CONSTANT_VALUES, DEPRECATED, PREVIEW, SERIALIZED_FORM, SYSTEM_PROPERTIES

??

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/LinkFactoryImpl.java line 120:

> 118:                                 title,
> 119:                                 classLinkInfo.target));
> 120:                         if (flags.contains(ElementFlag.PREVIEW)) {

I see a lot of `new HtmlTree(TagName.SUP).add(...)` ... enough to warrant a new factory method ``HtmlTree.SUP(Content)` or similar.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/ModuleIndexWriter.java line 39:

> 37: import jdk.javadoc.internal.doclets.formats.html.markup.HtmlStyle;
> 38: import jdk.javadoc.internal.doclets.formats.html.markup.HtmlTree;
> 39: import jdk.javadoc.internal.doclets.formats.html.markup.RawHtml;

Are these imports still required?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PreviewListWriter.java line 40:

> 38: 
> 39: import com.sun.source.doctree.DocTree;
> 40: import javax.lang.model.element.ElementKind;

unordered imports

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PreviewListWriter.java line 223:

> 221:                 case CONSTRUCTOR -> new ConstructorWriterImpl(this);
> 222:                 case ENUM_CONSTANT -> new EnumConstantWriterImpl(this);
> 223:                 case ANNOTATION_TYPE_MEMBER -> new AnnotationTypeOptionalMemberWriterImpl(this, null);

Hmmm. Not sure about this one. For better or worse, javadoc current handles optional and required members differently (i.e. with different classes). That's arguably something that should be cleaned up at some point, but in the meantime, I'm surprised to not see the distinction here.  I guess if we're not likely to see an interaction between preview-ness and annotation-members, this will not likely show up in practice.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/PreviewListWriter.java line 67:

> 65: public class PreviewListWriter extends SubWriterHolderWriter {
> 66: 
> 67:     private String getAnchorName(PreviewElementKind kind) {

1. I'm mildly surprised to not see anything record-related here. 
2. I'm mildly surprised you haven't used the new switch-expression syntax.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/PreviewAPIListBuilder.java line 67:

> 65:         ENUM_CONSTANT,
> 66:         ANNOTATION_TYPE_MEMBER // no ElementKind mapping
> 67:     };

Should there be RECORD and RECORD_COMPONENT in this list?

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/markup/HtmlTree.java line 932:

> 930:         switch (tagName) {
> 931:             case A: case BUTTON: case BR: case CODE: case EM: case I: case IMG:
> 932:             case LABEL: case SMALL: case SPAN: case STRONG: case SUB: case SUP:

See comment elsewhere about possibly adding a factory method for `SUP` trees.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/resources/standard.properties line 290:

> 288: doclet.Declared_Using_Preview.SEALED_PERMITS=Sealed Classes
> 289: doclet.PreviewPlatformLeadingNote={0} is a preview API of the Java platform.
> 290: doclet.ReflectivePreviewPlatformLeadingNote={0} is a reflective preview API of the Java platform.

Question: is the following "inconsistency" deliberate:
1. Java platform
2. Java language
3. Java SE (in javac diagnostics)

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/FieldWriter.java line 75:

> 73: 
> 74:     /**
> 75:      * Add the preview output for the given member.

(minor) Should be "Adds"

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/MethodWriter.java line 75:

> 73: 
> 74:     /**
> 75:      * Add the preview output for the given member.

(minor) should be "Adds"

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java line 156:

> 154:         buildSignature(annotationDocTree);
> 155:         buildDeprecationInfo(annotationDocTree);
> 156:         buildPreviewInfo(annotationDocTree);

(Just checking) I presume this behavior is inherited into `AnnotationTypeOptionalMemberBuilder` so no changes required there.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/EnumConstantBuilder.java line 166:

> 164:         writer.addPreview(currentElement, enumConstantsTree);
> 165:     }
> 166: 

Note to self: I regret that this duplication of adding this method everywhere seems to be necessary. This would be good to clean up at some point.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 213:

> 211: doclet.Preview=Preview.
> 212: doclet.Properties=Properties
> 213: doclet.constructors=constructors

Is the period after `Preview` intentional? It seems inconsistent.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Comparators.java line 131:

> 129:     /**
> 130:      * Returns a Comparator for deprecated items listed on deprecated list page, by comparing the
> 131:      * fully qualified names, and if those are equal the names of the enclosing modules.

Comment does not match method name

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 132:

> 130: import static com.sun.source.doctree.DocTree.Kind.*;
> 131: import javax.lang.model.AnnotatedConstruct;
> 132: import javax.lang.model.util.SimpleAnnotationValueVisitor14;

unordered imports

test/langtools/jdk/javadoc/doclet/testPreview/TestPreview.java line 75:

> 73:                                       </div>""";
> 74:             String expected = MessageFormat.format(expectedTemplate, zero, one, two, three);
> 75:             checkOutput("m/pkg/TestPreviewDeclaration.html", true, expected);

Interesting technique...

Future: it might be interesting to consider folding the bundle access on line 59 into a utility call in JavadocTester

test/langtools/jdk/javadoc/doclet/testPreview/api/preview/Core.java line 28:

> 26: import jdk.internal.javac.PreviewFeature.Feature;
> 27: 
> 28: @PreviewFeature(feature=Feature.TEST)

Yeah, I remember `Feature.TEST` from earlier.  I guess it's OK for now, as a workaround for a testing a feature which is inherently, by design, a moving target across releases. 

These days, javadoc tests are trending towards generating small sample test programs, instead of having small static side-files dominated  by a legal header. I wonder if there is a possibility of  having a "generator class" in the `javadoc.tester` package that can generate sample code using one or more of the current set of preview features, as a way of reducing the need for the TEST feature.

test/langtools/tools/javac/patterns/BindingsTest2.out line 54:

> 52: - compiler.note.preview.filename: BindingsTest2.java, DEFAULT
> 53: - compiler.note.preview.recompile
> 54: 51 errors

(issue unrelated to review)  it seems wrong that we encourage/allow the use of files that do not end in newline.

test/langtools/tools/javac/preview/PreviewAutoSuppress.java line 25:

> 23: 
> 24: /*
> 25:  * @test

no `@bug`?

test/langtools/tools/javac/preview/PreviewErrors.java line 38:

> 36:  * @build toolbox.ToolBox toolbox.JavacTask
> 37:  * @build combo.ComboTestHelper
> 38:  * @compile PreviewErrors.java

do you need `@compile` here: is `@build` not good enough?

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

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

From jjg at openjdk.java.net  Mon Nov  2 20:25:12 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 Nov 2020 20:25:12 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <5xE8fziHH9n04bSHhODnOB9On3t_zGz-JY0gJhVhP74=.0c79430f-fac0-44f9-82be-40ef2f94a0d9@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <5xE8fziHH9n04bSHhODnOB9On3t_zGz-JY0gJhVhP74=.0c79430f-fac0-44f9-82be-40ef2f94a0d9@github.com>
Message-ID: <8FF_CARupWr7LcKZm5Th7wpIZ-QhNVOM_KytRUOPppE=.bf38fc0c-5c70-4bff-aa50-fe23c772fe2b@github.com>

On Fri, 16 Oct 2020 16:07:41 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - Removing trailing whitespace.
>>  - Merging master into JDK-8250768.
>>  - Updating tests after records are a final feature.
>>  - Fixing tests.
>>  - Finalizing removal of record preview hooks.
>>  - Merging master into JDK-8250768
>>  - Reflecting review comments.
>>  - Merge branch 'master' into JDK-8250768
>>  - Removing unnecessary cast.
>>  - Using a more correct way to get URLs.
>>  - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java line 166:
> 
>> 164:             s = "compiler.misc.tree.tag." + StringUtils.toLowerCase(((Tag) arg).name());
>> 165:         } else if (arg instanceof Source && arg == Source.DEFAULT &&
>> 166:                 CODES_NEEDING_SOURCE_NORMALIZATION.contains(diag.getCode())) {
> 
> Nice trick to keep raw output constant across versions :-)

??

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

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

From jjg at openjdk.java.net  Mon Nov  2 20:25:12 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Mon, 2 Nov 2020 20:25:12 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v4]
In-Reply-To: <281-fNSKFfd-qngLAcLkMFdmKe-XHD-0qKCEh4OGvog=.82b534a0-e57a-41bf-ba94-e487601b2773@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <DvuPT_pYUFWOCkxQnkIKxUpLqyBQYSzSDVwrqR7iz4c=.221543e2-f4ee-4e28-b7ee-80aa21a9e3a0@github.com>
 <P6CERo1De3tix7TduT-Eh184-uAfYegth-i3neTAV1Y=.46960ac4-d027-4d59-a0b6-664819d1635f@github.com>
 <281-fNSKFfd-qngLAcLkMFdmKe-XHD-0qKCEh4OGvog=.82b534a0-e57a-41bf-ba94-e487601b2773@github.com>
Message-ID: <qwHKfUsdnZ8nr_K3-KSb_JXg9odmcou78exxImP7bOE=.25ca0b72-cfb1-4e79-a8f2-c62151b5edbf@github.com>

On Tue, 27 Oct 2020 16:09:45 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/formats/html/AbstractExecutableMemberWriter.java line 88:
>> 
>>> 86: 
>>> 87:     @Override
>>> 88:     protected Content getDeprecatedOrPreviewLink(Element member) {
>> 
>> This name is a side-effect of the `ElementFlag` question.  We should either use explicit field and method names, or we should use `ElementFlag` more consistently.   This method name works OK for now, but if if ever gets to have another `orFoo` component in the name, the signature should be parameterized with something like `ElementFlag` or its equivalent.
>
> Note this method returns the same link for deprecate or preview - it just was named "getDeprecatedLink", and when using it work preview, I renamed it "getDeprecatedOrPreviewLink". We may need to think of a better name.

This name is OK for now. Maybe we'll have m ore insight into a better name if/when we add a third variant ;-)

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

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

From naoto at openjdk.java.net  Mon Nov  2 23:17:10 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 23:17:10 GMT
Subject: RFR: 8247781: Day periods support [v4]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <qgF4cC9s4vjo_MdB1ix4zsR_9i3y_78pVxzhIkRh9Yc=.119a02c0-5c7b-4584-b05f-28ff3349a2ce@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

Naoto Sato has updated the pull request incrementally with three additional commits since the last revision:

 - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516147298
 - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516123190
 - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516138455

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/29c47afc..297acc94

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

  Stats: 66 lines in 2 files changed: 53 ins; 3 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

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

From naoto at openjdk.java.net  Mon Nov  2 23:17:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 23:17:11 GMT
Subject: RFR: 8247781: Day periods support [v3]
In-Reply-To: <v6pthmUP-A2POQbI-tGr0Vm-RzG1rZp9A6sp2oyw4z8=.6f4bb8c3-2aef-420a-9a82-796eebb352e3@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <GLJiZaszK-Ut5Ylcw7XH5fZlSdthxIsntMr6HenWf6c=.d16b1861-d000-4338-adef-80d5cd82b29f@github.com>
 <v6pthmUP-A2POQbI-tGr0Vm-RzG1rZp9A6sp2oyw4z8=.6f4bb8c3-2aef-420a-9a82-796eebb352e3@github.com>
Message-ID: <kw7i8DY3Sg5tPgZP5mWX9N2auu5m_2ZX4EbdXN0wudY=.c6a1e155-d877-43bf-83a5-d48d8f0f6c4c@github.com>

On Mon, 2 Nov 2020 17:27:35 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed exception messages.
>
> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 656:
> 
>> 654:             {"h B", "11 at night", 23},
>> 655:             {"h B", "3 at night", 3},
>> 656:             {"h B", "11 in the morning", 11},
> 
> Need tests for "51 in the morning" (which should parse in LENIENT as "3 in the morning" plus 2 days, see how HOUR_OF_DAY=51 works in general.
> 
> Similar issue with HOUR_OF_AMPM=3 and AMPM_OF_DAY=4.

Fixed.

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

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

From naoto at openjdk.java.net  Mon Nov  2 23:23:57 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 23:23:57 GMT
Subject: RFR: 8247781: Day periods support [v4]
In-Reply-To: <96h7JM1OhKA5v5Bx9qj9n08oRHav8V13E6Uor0m8SVw=.6960968e-0e3a-4ceb-95d0-a293838225ba@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <96h7JM1OhKA5v5Bx9qj9n08oRHav8V13E6Uor0m8SVw=.6960968e-0e3a-4ceb-95d0-a293838225ba@github.com>
Message-ID: <Et-GMOCvrHk8WobIWs3kBsi-GDF7mOL9wI2MUjO2cgU=.fe7fc32d-adb5-47b0-98bf-462b74496dae@github.com>

On Mon, 2 Nov 2020 17:08:10 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> src/java.base/share/classes/java/time/format/Parsed.java line 497:
>> 
>>> 495:                         AMPM_OF_DAY.checkValidValue(ap);
>>> 496:                     }
>>> 497:                     updateCheckDayPeriodConflict(AMPM_OF_DAY, midpoint / 720);
>> 
>> No need to put `AMPM_OF_DAY` back in here because you've already resolved it to `HOUR_OF_DAY` and `MINUTE_OF_HOUR`. There probably does need to be validation to check that the day period agrees with the AM/PM value.
>
> Line can still be removed AFAICT

Fixed.

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

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

From naoto at openjdk.java.net  Mon Nov  2 23:23:56 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 2 Nov 2020 23:23:56 GMT
Subject: RFR: 8247781: Day periods support [v4]
In-Reply-To: <Tu7yq15XUzC2-z2v40tNUGHkTkYW37q7RUiop9pB4xU=.d61a3059-6929-4b45-8a16-df33469ab56b@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>
 <Tu7yq15XUzC2-z2v40tNUGHkTkYW37q7RUiop9pB4xU=.d61a3059-6929-4b45-8a16-df33469ab56b@github.com>
Message-ID: <_KS-70pqQG8VavYGtbXCrOlvwfwGl6Nm-lk8SjkEDQI=.1775f0e1-4847-401a-a576-dbb93e080c90@github.com>

On Mon, 2 Nov 2020 17:05:40 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> MINUTE_OF_HOUR without HOUR_OF_DAY/HOUR_OF_AMPM may not make any sense, so it is only validated in updateCheckDayPeriodConflict.
>
> But can you get a CLDR rule that says "at night" before 05:30 and "In the morning" from 05:30 onwards? If you can then I don't think it is handled, because HOUR_OF_DAY and MINUTE_OF_HOUR are not used together when checking against DayPeriod.

CLDR allows rules that involve MINUTE_OF_HOUR. The validation I meant was within the `updateCheckDayPeriodConflict`:
            long hod = fieldValues.get(HOUR_OF_DAY);
            long moh = fieldValues.containsKey(MINUTE_OF_HOUR) ? fieldValues.get(MINUTE_OF_HOUR) : 0;
            long mod =  hod * 60 + moh;
            if (!dayPeriod.includes(mod)) {
                throw new DateTimeException("Conflict found: Resolved time %02d:%02d".formatted(hod, moh) +
                        " conflicts with " + dayPeriod);
            }
which checks both hod/moh. moh is assumed zero if `MINUTE_OF_HOUR` does not exist. Are you suggesting `HOUR_OF_DAY` should also be assumed zero if it does not exist?

>> There are cases where a period crosses midnight, e.g., 23:00-04:00 so it cannot validate am/pm, so I decided to just override ampm with dayperiod without validating.
>
> Pulling on this a little more.
> 
> As the PR stands, it seems that if the user passes in text with just a day-period of "AM" they get a `LocalTime` of 06:00 but if they pass in `AMPM_OF_DAY` of "AM" the get no `LocalTime` in the result. Is that right? If so, I don't think this is sustainable.
> 
> Thats why I think `AMPM_OF_DAY` will have to be resolved to a dayPeriod of "am" or "pm". If dayPeriod is more precise than `AMPM_OF_DAY`, then dayPeriod can silently take precedence

I implemented what you suggested here in the latest PR, but that would be a behavioral change which requires a CSR, as "AM" would be resolved to 06:00 which was not before. Do you think it would be acceptable? If so, I will reopen the CSR and describe the change. (In fact some TCK failed with this impl)

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

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

From kravikumar at openjdk.java.net  Tue Nov  3 00:02:57 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 3 Nov 2020 00:02:57 GMT
Subject: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d
In-Reply-To: <3BuHmUaG3MrBs7zQdpb8uiAxEQGUGO8YhdADRKBGaqw=.7276ab51-8823-4f20-be80-6c003212f317@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
 <W3jxMBMG3Cs9-ppnD9uj_WS-GDDUqr56ZbnRh7g91Y0=.88a99cdf-ce3b-4538-a055-b87069949ab3@github.com>
 <_-CfMNeat8oHCidIqA-s6I6ZQPcHAa-z8NRg1h9mm4c=.c4846ff2-a653-4a50-b66a-8fd455e2d729@github.com>
 <3BuHmUaG3MrBs7zQdpb8uiAxEQGUGO8YhdADRKBGaqw=.7276ab51-8823-4f20-be80-6c003212f317@github.com>
Message-ID: <ZivMlyICX9cQptzCvYLLpWaP2Qc-DYMRWy7XV_7AZmU=.a54a44f2-67d5-4fe5-8b6a-af7af5897651@github.com>

On Mon, 2 Nov 2020 18:14:47 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> It's probably these last rule what is causing the issue
>> 
>> Rule Palestine	2020	max	-	Mar	Sat>=24	0:00	1:00	S
>> Rule Palestine	2020	max	-	Oct	Sat>=24	1:00	0	-
>> 
>> The failure seen is 
>> 
>> ******************************
>> Asia/Gaza : Asia/Gaza
>>     -------------
>>     SimpleTimeZone (NG)
>>        stz=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=2,startMonth=2,startDay=-1,startDayOfWeek=7,startTime=0,startTimeMode=0,endMode=2,endMonth=9,endDay=-1,endDayOfWeek=7,endTime=3600000,endTimeMode=0]
>>       stz0=java.util.SimpleTimeZone[id=Asia/Gaza,offset=7200000,dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2,startDay=24,startDayOfWeek=7,startTime=0,startTimeMode=0,endMode=3,endMonth=9,endDay=24,endDayOfWeek=7,endTime=3600000,endTimeMode=0]
>
> My question is why it is failing. Have you figured it? The existing exceptions are either negative DST or last rule beyond 2037, which javazic cannot handle. The changes introduced with 2020d does not meet either of them. Unless we know why it is failing, we cannot be sure we can exclude it.

Thanks for getting back Naoto, I believe this is a long-standing issue - https://bugs.openjdk.java.net/browse/JDK-8227293.

Looking back at the integration of tzdata2019a/tzdata2019b, the same issue was addressed by updating the source code - https://hg.openjdk.java.net/jdk/jdk/rev/79036e5e744b#l13.1. 

Here is some history to the issue - https://mail.openjdk.java.net/pipermail/i18n-dev/2019-July/002887.html

Please let me know your thoughts

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

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

From bpb at openjdk.java.net  Tue Nov  3 00:14:03 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 3 Nov 2020 00:14:03 GMT
Subject: RFR: 8254742: InputStream::readNBytes(int) result may contain zeros
 not in input
Message-ID: <98TbkcfuPy2a9vBmt6jvxytDwfOocw0T9aw0r7BN6FI=.c55069f6-b801-4ce9-bfd4-1f1f48e7dc5d@github.com>

InputStream::readNBytes() invokes read(byte[],int,int) repeatedly to load bytes into a sequence of intermediate arrays. If an intermediate array is not completely filled before being added to the list of arrays the contents of which are eventually concatenated to produce the result, then the unfilled part of the intermediate array will contribute zeros to the result which are not actually in the input. This can occur for example if n < 8192 bytes are read into an intermediate array without filling it, and the next read() returns zero. It is proposed to detect when an intermediate array is only partially full, and to copy the valid range of the array into a new array which is instead appended to the list of component arrays.

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

Commit messages:
 - 8254742: InputStream::readNBytes(int) result may contain zeros not in input

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

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

From naoto at openjdk.java.net  Tue Nov  3 00:24:00 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 3 Nov 2020 00:24:00 GMT
Subject: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d
In-Reply-To: <ZivMlyICX9cQptzCvYLLpWaP2Qc-DYMRWy7XV_7AZmU=.a54a44f2-67d5-4fe5-8b6a-af7af5897651@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
 <W3jxMBMG3Cs9-ppnD9uj_WS-GDDUqr56ZbnRh7g91Y0=.88a99cdf-ce3b-4538-a055-b87069949ab3@github.com>
 <_-CfMNeat8oHCidIqA-s6I6ZQPcHAa-z8NRg1h9mm4c=.c4846ff2-a653-4a50-b66a-8fd455e2d729@github.com>
 <3BuHmUaG3MrBs7zQdpb8uiAxEQGUGO8YhdADRKBGaqw=.7276ab51-8823-4f20-be80-6c003212f317@github.com>
 <ZivMlyICX9cQptzCvYLLpWaP2Qc-DYMRWy7XV_7AZmU=.a54a44f2-67d5-4fe5-8b6a-af7af5897651@github.com>
Message-ID: <CWOOoaUdoW42sKioocwW4jZ85zL5EfjZd-vRe1gnuxI=.f5ee6eae-c5cd-44b2-a683-89c0795ab16f@github.com>

On Tue, 3 Nov 2020 00:00:26 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

>> My question is why it is failing. Have you figured it? The existing exceptions are either negative DST or last rule beyond 2037, which javazic cannot handle. The changes introduced with 2020d does not meet either of them. Unless we know why it is failing, we cannot be sure we can exclude it.
>
> Thanks for getting back Naoto, I believe this is a long-standing issue - https://bugs.openjdk.java.net/browse/JDK-8227293.
> 
> Looking back at the integration of tzdata2019a/tzdata2019b, the same issue was addressed by updating the source code - https://hg.openjdk.java.net/jdk/jdk/rev/79036e5e744b#l13.1. 
> 
> Here is some history to the issue - https://mail.openjdk.java.net/pipermail/i18n-dev/2019-July/002887.html
> 
> Please let me know your thoughts

Should we then remove the hack in the ZoneInfoFile.java that excludes Gaza/Hebron instead?

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Tue Nov  3 02:24:58 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Tue, 3 Nov 2020 02:24:58 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v8]
In-Reply-To: <LBKU_Ov5ZdR3WADmgLKeXahpXnxFBxUjxQ6frLwny38=.841fba45-c53a-4225-b77f-c5d2c24d93c0@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
 <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
 <iD4pt7fK5AExXfPuONZnrjoFTNmHO7T96s_9KCiBYTM=.64012cef-fd79-4692-a029-2b75391bd193@github.com>
 <IXZnO1Rv6RMimJLR5zL5MYSQZrBltEe_0I13tbN92XE=.24c72b06-28b8-413b-8b27-c97176125780@github.com>
 <LBKU_Ov5ZdR3WADmgLKeXahpXnxFBxUjxQ6frLwny38=.841fba45-c53a-4225-b77f-c5d2c24d93c0@github.com>
Message-ID: <OuyVbKSeAxwnCi4kWVjOC-fUh39nxEfVXLQee2aSaBY=.3a25c029-1a61-4977-bdb3-906057e0f4b2@github.com>

On Sat, 24 Oct 2020 21:38:55 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> Yes, it assumes uniformly random data, but also recall that the unencoded data bytes get shifted by 2, 4, 6 bits into the encoded bytes, which I'm guessing would tend to make the data somewhat more uniform, even if the source data has low entropy.
>> 
>> That said, I didn't actually benchmark it.  I will do that to make sure there is a gain, and if there isn't I will remove the conditional branch.
>
>> I took a look at the VSX algo. I haven't looked much beyond it. I had a few questions I've inlined. It does look like a faithful VSX implementation of the linked algo.
> 
> I neglected to thank you for reviewing this code!  I realize there's quite a time commitment required to review this properly, and because of that I was having difficulty finding a second reviewer for the PPC64 portion.
> 
> Just to set expectations, I will be on vacation next week, so further commits won't be posted until the following week, but I will address all of your great feedback.  Thanks again!

I just got done running a benchmark without the branch around the xxsel, and your hunch was right.  There's about a 9% performance gain in the benchmark with that branch dropped.  I also changed the previous instruction not to set the condition code, but I doubt that affected performance.  Both regression tests for Base64 encoding/decoding still pass.

The next set of commits will contain this change.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Tue Nov  3 02:53:09 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Tue, 3 Nov 2020 02:53:09 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v9]
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <PIawBmZQe4PJutGa5jI3fM_b5pirapj9G5F2rq6WG6M=.1924a4b0-5c3b-4c88-978b-0ea6c42e31c9@github.com>

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

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

 - stubGenerator_ppc.cpp: Remove the predicted branch around the xxsel instruction to improves performance by about 9%
   
   This conditional branch around the xxsel seemed like a good idea at the
   time, because I thought the branch would be less costly than the xxsel
   instruction, but it turns out not to be the case; executing the xxsel every
   time without a conditional branch increases performance by about 9%.
   Removing that branch also removed the need for the declaration and usage of
   an array of Label's for the branch destinations inside the unrolled code.
 - stubGenerator_ppc.cpp: address issues with understanding the pack algorithm
   
    * Change the order of the bytes as listed in the tables, which makes the
      use of vpextd easier to understand.
   
    * Because the byte order of the constants used in the tables is reversed from
      the original documentation, change the constant declarations to match the order
      in the table, by using the ARRAY_TO_LXV_ORDER macro.  This makes the constant
      declarations more consistent as well.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/293/files
  - new: https://git.openjdk.java.net/jdk/pull/293/files/8e15d971..0e291be4

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

  Stats: 106 lines in 1 file changed: 25 ins; 12 del; 69 mod
  Patch: https://git.openjdk.java.net/jdk/pull/293.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/293/head:pull/293

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

From github.com+51754783+coreyashford at openjdk.java.net  Tue Nov  3 02:55:58 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Tue, 3 Nov 2020 02:55:58 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v9]
In-Reply-To: <-7PHVafzbyMukuWngsX5bdLvJPubN2KzjMWM2lrQnCs=.a278b608-3e1c-4126-9791-efe18a5d8d5e@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
 <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
 <_JR-e3ZsRFwvZCR7ws34z5jLjp2kJQ1bu4gyl0RG1XU=.ec3040cf-8147-4dcd-b87d-4fd9be4eb59e@github.com>
 <-7PHVafzbyMukuWngsX5bdLvJPubN2KzjMWM2lrQnCs=.a278b608-3e1c-4126-9791-efe18a5d8d5e@github.com>
Message-ID: <NvWpdob94gnBRHSSyzjDk7oPyIH4p9q6qEzpx270214=.e6cc6b6c-bd40-4590-8825-905af8c542d6@github.com>

On Mon, 26 Oct 2020 19:22:23 GMT, Paul Murphy <github.com+12972156+pmur at openjdk.org> wrote:

>> Just to make sure I understand, you're not asking for a change here, is that right?
>
> I think the first line should also express the initial layout of the 6 bit values similar to the linked algo.  I think changing this comment add an extra line which describes the bits as they leave `vaddubm` would be helpful to understand the demangling here. (e.g the `00aaaaaa 00bbbbbb 00ccccc 00dddddd` comments in the linked paper)

I think I have addressed the issues in this comment with the latest commits.  Reversing the order of the bytes in the tables seems to make the tables easier to understand, and also make the vector constant declarations consistent: all use the ARRAY_TO_LXV_ORDER macro now.

The 00aaaaa (etc.) bit fields are added to the tables..  I'm not 100% sure they help much, but at least the comments follow the original paper in a clearer way.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Tue Nov  3 03:01:09 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Tue, 3 Nov 2020 03:01:09 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v10]
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <Q4-5D8lEOZhG4McAEvkgeZBGNl-oealNHxKfFAfFy0U=.57aa82a4-0d6e-4a04-b343-ec7f9092be8a@github.com>

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

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

  stubGenerator_ppc.cpp: fix trailing whitespace errors

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/293/files
  - new: https://git.openjdk.java.net/jdk/pull/293/files/0e291be4..8292527e

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

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

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

From smarks at openjdk.java.net  Tue Nov  3 03:18:08 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 3 Nov 2020 03:18:08 GMT
Subject: RFR: 8180352: Add Stream.toList() method
Message-ID: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>

This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.

In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:

https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065

This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.

Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.

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

Commit messages:
 - 8180352: Add Stream.toList() method

Changes: https://git.openjdk.java.net/jdk/pull/1026/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1026&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8180352
  Stats: 405 lines in 6 files changed: 358 ins; 23 del; 24 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1026/head:pull/1026

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

From ihse at openjdk.java.net  Tue Nov  3 08:29:01 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 3 Nov 2020 08:29:01 GMT
Subject: RFR: 8255798: Remove dead headless code in CompileJavaModules.gmk
Message-ID: <5Gi8FSVPAw7OmK6bq4YjYDWyCGr23IgedicITWsO0CE=.bfa58da7-69c2-472c-9a5f-1b6fa9dd2d36@github.com>

The variable BUILD_HEADLESS_ONLY is no longer set. And sun/applet does not exist anymore.

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

Commit messages:
 - 8255798: Remove dead headless code in CompileJavaModules.gmk

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

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

From shade at openjdk.java.net  Tue Nov  3 08:58:57 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 3 Nov 2020 08:58:57 GMT
Subject: RFR: 8254742: InputStream::readNBytes(int) result may contain
 zeros not in input
In-Reply-To: <98TbkcfuPy2a9vBmt6jvxytDwfOocw0T9aw0r7BN6FI=.c55069f6-b801-4ce9-bfd4-1f1f48e7dc5d@github.com>
References: <98TbkcfuPy2a9vBmt6jvxytDwfOocw0T9aw0r7BN6FI=.c55069f6-b801-4ce9-bfd4-1f1f48e7dc5d@github.com>
Message-ID: <bdDAYFWhLBg8lKY35a5cb5mwv3SwYDYN8dDgxKG7YyQ=.e5c3ed5a-632a-4eb3-a170-02ad14fbcb1e@github.com>

On Tue, 3 Nov 2020 00:04:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> InputStream::readNBytes() invokes read(byte[],int,int) repeatedly to load bytes into a sequence of intermediate arrays. If an intermediate array is not completely filled before being added to the list of arrays the contents of which are eventually concatenated to produce the result, then the unfilled part of the intermediate array will contribute zeros to the result which are not actually in the input. This can occur for example if n < 8192 bytes are read into an intermediate array without filling it, and the next read() returns zero. It is proposed to detect when an intermediate array is only partially full, and to copy the valid range of the array into a new array which is instead appended to the list of component arrays.

This makes sense to me.

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

Marked as reviewed by shade (Reviewer).

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

From dfuchs at openjdk.java.net  Tue Nov  3 10:09:00 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Tue, 3 Nov 2020 10:09:00 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
Message-ID: <0zwE2OhqyHVBDkcWL42fXImwwIth508MtuiR2M2HmKg=.a8929d75-fd9a-4056-ab1f-f09b40c01504@github.com>

On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
> 
> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
> 
> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
> 
> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.

Should there be a test that tests the default implementation in `j.u.s.Stream`? Or maybe there is and I missed that?

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

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

From scolebourne at openjdk.java.net  Tue Nov  3 11:10:00 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Tue, 3 Nov 2020 11:10:00 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
Message-ID: <ApRvKdQ0A6oWVUJI1QJB5GZ2lazceqT7GBLj4S8ds7k=.270bfefc-cebc-47d6-9067-048c5bbb46fc@github.com>

On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
> 
> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
> 
> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
> 
> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.

src/java.base/share/classes/java/util/ImmutableCollections.java line 211:

> 209:         }
> 210: 
> 211:         switch (input.length) { // implicit null check of elements

Was a variable renamed? Should "elements" be "input"?

src/java.base/share/classes/java/util/stream/Stream.java line 1168:

> 1166:      * Accumulates the elements of this stream into a {@code List}. The elements in
> 1167:      * the list will be in this stream's encounter order, if one exists. There are no
> 1168:      * guarantees on the implementation type, mutability, serializability, or

It would be useful for callers to feel more confident that they will get an immutable instance. In java.time.* we have wording like "This interface places no restrictions on the mutability of implementations, however immutability is strongly recommended." Could something like that work here, emphasising that everyone implementing this method should seek to return an immutable list?

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

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

From github.com+2729073+fweimer at openjdk.java.net  Tue Nov  3 11:10:01 2020
From: github.com+2729073+fweimer at openjdk.java.net (Florian Weimer)
Date: Tue, 3 Nov 2020 11:10:01 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
Message-ID: <vqSvtBfEwiOEe7DgHNV0WrUgE60idFop1163gpzj_7o=.7ef2df29-9019-412f-b9ba-4902072edada@github.com>

On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
> 
> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
> 
> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
> 
> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.

test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/ToListOpTest.java line 47:

> 45:     }
> 46: 
> 47:     private void checkUnmodifiable(List<Integer> list) {

I'd expect a test here that if the list contains a null element, `List::copyOf` throws `NullPointerException`.

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

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

From jvernee at openjdk.java.net  Tue Nov  3 12:16:02 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 3 Nov 2020 12:16:02 GMT
Subject: Integrated: 8255374: Add a dropReturn MethodHandle combinator
In-Reply-To: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
References: <zYoRWf3w-WVtBQZCV97D4sPBDGLFNQ8-JCrq4NXCQ4Q=.f5c6fb56-bc8b-44f4-987b-725dd70e6ace@github.com>
Message-ID: <py_TmAcE8KcVBwZLHhf-6GYXFekovnOR491GGdXF66c=.1a66654f-7b1e-43fb-adbc-c9de0480f526@github.com>

On Mon, 26 Oct 2020 15:18:08 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This patch adds a `dropReturn` combinator to `MethodHandles` that can be used to create a new method handle that drops the return value, from a given method handle. Similar to the following code:
> 
> MethodHandle target = ...;
> Class<?> targetReturnType = target.type().returnType();
> if (targetReturnType != void.class)
>     target = filterReturnValue(target, empty(methodType(void.class, targetReturnType))); 
> // use target
> 
> But as a short-hand.
> 
> Thanks,
> Jorn
> 
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255398

This pull request has now been integrated.

Changeset: b8d4e02c
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b8d4e02c
Stats:     91 lines in 2 files changed: 91 ins; 0 del; 0 mod

8255374: Add a dropReturn MethodHandle combinator

Reviewed-by: redestad

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

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

From forax at univ-mlv.fr  Tue Nov  3 14:53:01 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 3 Nov 2020 15:53:01 +0100 (CET)
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
Message-ID: <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stuart Marks" <smarks at openjdk.java.net>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 3 Novembre 2020 04:18:08
> Objet: RFR: 8180352: Add Stream.toList() method

> This change introduces a new terminal operation on Stream. This looks like a
> convenience method for Stream.collect(Collectors.toList()) or
> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
> method directly on Stream enables it to do what can't easily by done by a
> Collector. In particular, it allows the stream to deposit results directly into
> a destination array (even in parallel) and have this array be wrapped in an
> unmodifiable List without copying.
> 
> In the past we've kept most things from the Collections Framework as
> implementations of Collector, not directly on Stream, whereas only fundamental
> things (like toArray) appear directly on Stream. This is true of most
> Collections, but it does seem that List is special. It can be a thin wrapper
> around an array; it can handle generics better than arrays; and unlike an
> array, it can be made unmodifiable (shallowly immutable); and it can be
> value-based. See John Rose's comments in the bug report:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
> 
> This operation is null-tolerant, which matches the rest of Streams. This isn't
> specified, though; a general statement about null handling in Streams is
> probably warranted at some point.
> 
> Finally, this method is indeed quite convenient (if the caller can deal with
> what this operation returns), as collecting into a List is the most common
> stream terminal operation.

Hi Stuart,
I'm Okay with the idea of having a method toList() on Stream but really dislike the proposed semantics because tit is neither stream.collect(toList()) nor stream.collect(toUnmodifiableList()) but something in between.

It's true that a Stream support nulls, we want people to be able map() with a method that returns null and then filter out the nulls (even if using flatMap for this case is usually a better idea),
but it doesn't mean that all methods of the Stream interface has to support nulls, the original idea was more to allow nulls to flow in the stream because at some point they will be removed before being stored in a collection.

For me allowing in 2020 to store null in a collection is very backward, all collections since 1.6 doesn't support nulls.

Also, adding a third immutable list creates a problem, it means that now when we get an immutable list it can be 3 different implementations but the VM only uses bimorphic inlining cache,
so more callsites will fail to inline because of that. I think we have already reduced the number of implementation of immutable map from 3 to 2 for the very same reasons.

I believe that instead of inventing a third semantics that allows to store null in a collection, we should use the semantics of stream.collect(Collectors.toUnmodifiableList()) even if it means that toList() will throw a NPE if one element is null.

R?mi

From kravikumar at openjdk.java.net  Tue Nov  3 15:40:12 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 3 Nov 2020 15:40:12 GMT
Subject: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d [v2]
In-Reply-To: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
Message-ID: <tZ1Aw6hQ_9mTBptxjK6-uySsW_sSeKpJrQrIgja6NX4=.338713e8-ad91-43b3-a3a9-b3c306293f7a@github.com>

> Hi Guys,
> 
> Please review the integration of tzdata2020d to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
> 
> TestZoneInfo310.java test failure is addressed along with it. The last rule affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

Kiran Sidhartha Ravikumar has updated the pull request with a new target base 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-8255226
 - 8255226: Updating ZoneInfoFile.java logic to avoid certain zones
 - 8255226: (tz) Upgrade time-zone data to tzdata2020d

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1012/files
  - new: https://git.openjdk.java.net/jdk/pull/1012/files/e859af83..8782181c

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

  Stats: 2120 lines in 83 files changed: 1178 ins; 580 del; 362 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1012.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1012/head:pull/1012

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

From kravikumar at openjdk.java.net  Tue Nov  3 15:42:55 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 3 Nov 2020 15:42:55 GMT
Subject: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d [v2]
In-Reply-To: <CWOOoaUdoW42sKioocwW4jZ85zL5EfjZd-vRe1gnuxI=.f5ee6eae-c5cd-44b2-a683-89c0795ab16f@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
 <W3jxMBMG3Cs9-ppnD9uj_WS-GDDUqr56ZbnRh7g91Y0=.88a99cdf-ce3b-4538-a055-b87069949ab3@github.com>
 <_-CfMNeat8oHCidIqA-s6I6ZQPcHAa-z8NRg1h9mm4c=.c4846ff2-a653-4a50-b66a-8fd455e2d729@github.com>
 <3BuHmUaG3MrBs7zQdpb8uiAxEQGUGO8YhdADRKBGaqw=.7276ab51-8823-4f20-be80-6c003212f317@github.com>
 <ZivMlyICX9cQptzCvYLLpWaP2Qc-DYMRWy7XV_7AZmU=.a54a44f2-67d5-4fe5-8b6a-af7af5897651@github.com>
 <CWOOoaUdoW42sKioocwW4jZ85zL5EfjZd-vRe1gnuxI=.f5ee6eae-c5cd-44b2-a683-89c0795ab16f@github.com>
Message-ID: <y6Y0SwdznkaNjTg9KHy-Txp8ZPeTFhCNHsk9A1303Xs=.ee9e6481-6fc4-4f13-a588-a90b91230103@github.com>

On Tue, 3 Nov 2020 00:21:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Thanks for getting back Naoto, I believe this is a long-standing issue - https://bugs.openjdk.java.net/browse/JDK-8227293.
>> 
>> Looking back at the integration of tzdata2019a/tzdata2019b, the same issue was addressed by updating the source code - https://hg.openjdk.java.net/jdk/jdk/rev/79036e5e744b#l13.1. 
>> 
>> Here is some history to the issue - https://mail.openjdk.java.net/pipermail/i18n-dev/2019-July/002887.html
>> 
>> Please let me know your thoughts
>
> Should we then remove the hack in the ZoneInfoFile.java that excludes Gaza/Hebron instead?

I had made changes to the ZoneInfoFile.java to avoid applying the logic present to Gaza/Hebron. Regression tests executed successfully.

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

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

From kravikumar at openjdk.java.net  Tue Nov  3 15:49:09 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Tue, 3 Nov 2020 15:49:09 GMT
Subject: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d [v3]
In-Reply-To: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
Message-ID: <VhA15wejTNIaiPen4iI73YmCSTNabvINmiyC1zr8Oqs=.3f14784b-acc7-461f-95bd-397fbc0b8071@github.com>

> Hi Guys,
> 
> Please review the integration of tzdata2020d to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
> 
> TestZoneInfo310.java test failure is addressed along with it. The last rule affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

Kiran Sidhartha Ravikumar has updated the pull request incrementally with one additional commit since the last revision:

  8255226: Fixing whitespaces

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1012/files
  - new: https://git.openjdk.java.net/jdk/pull/1012/files/8782181c..e4a565e2

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

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

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

From brian.goetz at oracle.com  Tue Nov  3 18:02:37 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 3 Nov 2020 13:02:37 -0500
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
Message-ID: <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>


>> This change introduces a new terminal operation on Stream. This looks like a
>> convenience method for Stream.collect(Collectors.toList()) or
>> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
>> method directly on Stream enables it to do what can't easily by done by a
>> Collector. In particular, it allows the stream to deposit results directly into
>> a destination array (even in parallel) and have this array be wrapped in an
>> unmodifiable List without copying.
>>
>> Hi Stuart,
>> I'm Okay with the idea of having a method toList() on Stream but really dislike the proposed semantics because tit is neither stream.collect(toList()) nor stream.collect(toUnmodifiableList()) but something in between.
>>
>> It's true that a Stream support nulls, we want people to be able map() with a method that returns null and then filter out the nulls (even if using flatMap for this case is usually a better idea),
>> but it doesn't mean that all methods of the Stream interface has to support nulls, the original idea was more to allow nulls to flow in the stream because at some point they will be removed before being stored in a collection.

Uhm ... no and no.

It does mean that all methods of the stream interface have to support 
nulls.? Streams are null tolerant.? Because ...

The original idea was not "the nulls can be removed later."? The 
original idea was "Streams are plumbing, they pass values through 
pipelines, to user-specified lambdas, into arrays, etc, and the stream 
plumbing should not have an opinion on the values that are flowing 
through."?? And this was the right choice.

There is no value in making users remember which stream methods are 
null-hostile and which are null-tolerant; this is just more accidental 
complexity.? And the root cause of that accidental complexity is the 
misguided belief that we can (and should) contain the consequences of 
nullity by making ad-hoc restrictions about nullity.?? That doesn't 
work, and all it does is add more complexity and more ways for X to not 
interact with Y.

I understand the hatred for nulls, but it's a fantasy to think we can 
contain them with ad-hoc restrictions.?? And the aggregate cost in 
complexity of all the ad-hoc decisions is pretty significant. Stuart 
made the right choice here.



From naoto at openjdk.java.net  Tue Nov  3 18:12:03 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 3 Nov 2020 18:12:03 GMT
Subject: RFR: 8255226: (tz) Upgrade time-zone data to tzdata2020d [v3]
In-Reply-To: <VhA15wejTNIaiPen4iI73YmCSTNabvINmiyC1zr8Oqs=.3f14784b-acc7-461f-95bd-397fbc0b8071@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
 <VhA15wejTNIaiPen4iI73YmCSTNabvINmiyC1zr8Oqs=.3f14784b-acc7-461f-95bd-397fbc0b8071@github.com>
Message-ID: <CWPb2P5FXmatgTGcoSfrZxGGtw0Fujeb6fd37hKt8Zk=.f10e89ba-1b7d-4da2-96d9-2967cd74f4a8@github.com>

On Tue, 3 Nov 2020 15:49:09 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

>> Hi Guys,
>> 
>> Please review the integration of tzdata2020d to JDK.
>> 
>> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
>> 
>> TestZoneInfo310.java test failure is addressed along with it. The last rule affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
>> 
>> Regression Tests pass along with JCK.
>> 
>> Please let me know if the changes are good to push.
>> 
>> Thanks,
>> Kiran
>
> Kiran Sidhartha Ravikumar has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255226: Fixing whitespaces

Looks good.

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

Marked as reviewed by naoto (Reviewer).

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

From naoto at openjdk.java.net  Tue Nov  3 18:23:12 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 3 Nov 2020 18:23:12 GMT
Subject: RFR: 8247781: Day periods support [v5]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <Dj2Tt8VtHoEUpSmMCj5e-EURs66D9SlFDqlLDZu88WI=.329fb314-1c72-4cca-8806-dc49943d86d5@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Fixed TCK test failures, added the new pattern char description in DateTimeFormatter

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/297acc94..e52fe51f

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

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

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

From smarks at openjdk.java.net  Tue Nov  3 18:42:56 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 3 Nov 2020 18:42:56 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <ApRvKdQ0A6oWVUJI1QJB5GZ2lazceqT7GBLj4S8ds7k=.270bfefc-cebc-47d6-9067-048c5bbb46fc@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <ApRvKdQ0A6oWVUJI1QJB5GZ2lazceqT7GBLj4S8ds7k=.270bfefc-cebc-47d6-9067-048c5bbb46fc@github.com>
Message-ID: <O9fZjN8c315o55E1RmmV0twEEkeEAcQjZOycqjrMmjk=.2ed55679-a1a1-40f9-8119-8ea233e3413e@github.com>

On Tue, 3 Nov 2020 10:58:25 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
>> 
>> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
>> 
>> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
>> 
>> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 211:
> 
>> 209:         }
>> 210: 
>> 211:         switch (input.length) { // implicit null check of elements
> 
> Was a variable renamed? Should "elements" be "input"?

Yes, actually that comment belongs up above. I'll fix it, thanks.

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

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

From smarks at openjdk.java.net  Tue Nov  3 18:49:00 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 3 Nov 2020 18:49:00 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <ApRvKdQ0A6oWVUJI1QJB5GZ2lazceqT7GBLj4S8ds7k=.270bfefc-cebc-47d6-9067-048c5bbb46fc@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <ApRvKdQ0A6oWVUJI1QJB5GZ2lazceqT7GBLj4S8ds7k=.270bfefc-cebc-47d6-9067-048c5bbb46fc@github.com>
Message-ID: <shZ-q59OfZQsHQyVSSYmOHPZhy1WNvLeI-9FK2X51uQ=.e2e19d59-a14b-4e43-b97f-562c0304ee38@github.com>

On Tue, 3 Nov 2020 11:05:21 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
>> 
>> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
>> 
>> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
>> 
>> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.
>
> src/java.base/share/classes/java/util/stream/Stream.java line 1168:
> 
>> 1166:      * Accumulates the elements of this stream into a {@code List}. The elements in
>> 1167:      * the list will be in this stream's encounter order, if one exists. There are no
>> 1168:      * guarantees on the implementation type, mutability, serializability, or
> 
> It would be useful for callers to feel more confident that they will get an immutable instance. In java.time.* we have wording like "This interface places no restrictions on the mutability of implementations, however immutability is strongly recommended." Could something like that work here, emphasising that everyone implementing this method should seek to return an immutable list?

Yes, good point, the "no guarantee of mutability" clashes with the later statement about the possibility of the returned instance being value-based, which strongly implies immutability. I'll work on tuning this up to be a stronger statement on immutability, while retaining "no-guarantee" for implementation type, serializability, etc. I think we do want to preserve future implementation flexibility in those areas.

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

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

From smarks at openjdk.java.net  Tue Nov  3 18:55:55 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 3 Nov 2020 18:55:55 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <0zwE2OhqyHVBDkcWL42fXImwwIth508MtuiR2M2HmKg=.a8929d75-fd9a-4056-ab1f-f09b40c01504@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <0zwE2OhqyHVBDkcWL42fXImwwIth508MtuiR2M2HmKg=.a8929d75-fd9a-4056-ab1f-f09b40c01504@github.com>
Message-ID: <aEf9SHIToPBuecCg0o-ZKeNj1a28si75KfKKCuaJq5c=.95ad6de6-2d7e-4b69-ab31-cf4c650393a1@github.com>

On Tue, 3 Nov 2020 10:06:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
>> 
>> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
>> 
>> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
>> 
>> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.
>
> Should there be a test that tests the default implementation in `j.u.s.Stream`? Or maybe there is and I missed that?

@dfuch wrote:
> Should there be a test that tests the default implementation in `j.u.s.Stream`? Or maybe there is and I missed that?

The test method `testDefaultOps` does that. The stream test framework has a thing called `DefaultMethodStreams` that delegates everything except default methods to another Stream instance, so this should test the default implementation.

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

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

From john.r.rose at oracle.com  Tue Nov  3 19:12:35 2020
From: john.r.rose at oracle.com (John Rose)
Date: Tue, 3 Nov 2020 11:12:35 -0800
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
Message-ID: <A43D85B0-5547-49CD-8396-322F3E464024@oracle.com>

I agree with Stuart and Brian that streams should be null-tolerant,
including in this case.  And of course I?m delighted to see an
immutable container as the output to the utility method; I?m
a fan of reduced-copy, race-free, bug-resistant algorithms you
get from immutability.

On Nov 3, 2020, at 6:53 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Also, adding a third immutable list creates a problem, it means that now when we get an immutable list it can be 3 different implementations but the VM only uses bimorphic inlining cache,
> so more callsites will fail to inline because of that. I think we have already reduced the number of implementation of immutable map from 3 to 2 for the very same reasons.

Yes, this part concerns me, with my JIT hat on.

It seems to me that the problem can be removed simply by allowing
the existing ListN object to contain nulls.  That?s not the same
thing as allowing List.of(1,2,3, null):  That factory method can
reject nulls, while the privileged factory method that makes
an array-backed ListN can simply sidestep the null check.

And if a call to Stream::toList call returns 0, 1, or 2 items,
it?s a straightforward matter to test if either is null, and then
choose to use either ListN or List12.  No new implementation
classes, at all!

From forax at univ-mlv.fr  Tue Nov  3 19:24:36 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 3 Nov 2020 20:24:36 +0100 (CET)
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
Message-ID: <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>, "Stuart Marks" <smarks at openjdk.java.net>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 3 Novembre 2020 19:02:37
> Objet: Re: RFR: 8180352: Add Stream.toList() method

>>> This change introduces a new terminal operation on Stream. This looks like a
>>> convenience method for Stream.collect(Collectors.toList()) or
>>> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
>>> method directly on Stream enables it to do what can't easily by done by a
>>> Collector. In particular, it allows the stream to deposit results directly into
>>> a destination array (even in parallel) and have this array be wrapped in an
>>> unmodifiable List without copying.
>>>
>>> Hi Stuart,
>>> I'm Okay with the idea of having a method toList() on Stream but really dislike
>>> the proposed semantics because tit is neither stream.collect(toList()) nor
>>> stream.collect(toUnmodifiableList()) but something in between.
>>>
>>> It's true that a Stream support nulls, we want people to be able map() with a
>>> method that returns null and then filter out the nulls (even if using flatMap
>>> for this case is usually a better idea),
>>> but it doesn't mean that all methods of the Stream interface has to support
>>> nulls, the original idea was more to allow nulls to flow in the stream because
>>> at some point they will be removed before being stored in a collection.
> 
> Uhm ... no and no.
> 
> It does mean that all methods of the stream interface have to support
> nulls.? Streams are null tolerant.? Because ...
> 
> The original idea was not "the nulls can be removed later."? The
> original idea was "Streams are plumbing, they pass values through
> pipelines, to user-specified lambdas, into arrays, etc, and the stream
> plumbing should not have an opinion on the values that are flowing
> through."?? And this was the right choice.

A stream is computation, so i agree that letting nulls to flow is the right call.
So i stand corrected on that point.

> 
> There is no value in making users remember which stream methods are
> null-hostile and which are null-tolerant; this is just more accidental
> complexity.?

I think that ship has sailed a long ago.
Some collectors are null hostile, some are not.
You can make a point that a Collector is technically not the Stream API per se.

[...]

Let's take a step back,
if we introduce a method toList() on Stream it will be used a lot, i mean really a lot, to the point where people will change the code from stream.collect(Collectors.toList()) to use stream.toList() instead.

Because of that, i don't think we even have the choice of the semantics for Stream.toList(), it has to be the same as stream.collect(Collectors.toList()).

So you are right that toList() can not be null hostile because Collectors.toList() is not null hostile.

But it can not be immutable too, for the same reason.

> Stuart made the right choice here.

I would say half of the right choices, null hostile: right, immutable: wrong :)

And if we at some point introduce a method toImmutableList() on Stream, it will have to be null hostile.

R?mi

From lancea at openjdk.java.net  Tue Nov  3 19:24:57 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 3 Nov 2020 19:24:57 GMT
Subject: Integrated: 8255380: (zipfs) ZipFileSystem::readExtra can fail if
 zipinfo-time is not set to false
In-Reply-To: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>
References: <zRLEdLmV0F5GPtsc7CGjHYnZCfuOZSaaPc1Sc7xuy-4=.7b1b7159-f0d1-4583-b4de-1f2dd91d5ef4@github.com>
Message-ID: <g4mFGVp61HknsD6Xy-6_2NXKKc4A0C9oP0rhdW999Tg=.89c951fb-a84f-4225-ac2a-96f1fefce48c@github.com>

On Sun, 1 Nov 2020 20:09:32 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review the fix for JDK-8255380 which addresses an issue when the Zip file is > 4GB.  Zip FS when processing the CEN extra data does not take into account the fact that there is no specific order to how the extra data fields are written.  Info-ZIP writes the fields in a different order than Zip FS which presents a problem when evaluating the Info-ZIP extended timestamp and the LOC offset is 0XFFFFFFFF therefore the LOC offset needs to be read from the EXTID_ZIP64 extra data prior to attempting to read the LOC extra data field.
> 
> The fix will defer reading of the LOC extra data field, if needed until all of the CEN extra data has been processed.
> 
> Using jdk.nio.zipfs.ZipInfo, you can see the ordering difference of the CEND extra data fields when using Zip FS and info-zip.
> 
> Info-zip is included with Mac OS so the test uses ProcessBuilder to execute zip on Mac OS and Linux.  
> 
> Mach5 tests jdk-tier1, jdk-tier2, and jdk-tier3 run cleanly.
> 
> Best,
> Lance

This pull request has now been integrated.

Changeset: 6606e090
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6606e090
Stats:     311 lines in 2 files changed: 272 ins; 29 del; 10 mod

8255380: (zipfs) ZipFileSystem::readExtra can fail if zipinfo-time is not set to false

Reviewed-by: redestad

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

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

From brian.goetz at oracle.com  Tue Nov  3 19:54:57 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 3 Nov 2020 14:54:57 -0500
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
 <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
Message-ID: <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>


>> There is no value in making users remember which stream methods are
>> null-hostile and which are null-tolerant; this is just more accidental
>> complexity.
> I think that ship has sailed a long ago.
> Some collectors are null hostile, some are not.
> You can make a point that a Collector is technically not the Stream API per se.

Yes, and this is no mere "technical argument".? A Collector is a 
collection of behaviors, governed by its own spec.? The behaviors passed 
to stream operations, whether they be lambdas passed by the user 
(`.map(x -> x.hopeXIsntNull())`) or collector objects or comparators, 
are under the control of the user, and it is the user's responsibility 
to pass behaviors which are compatible with the data domain -- which the 
user knows and the streams implementation cannot know.

> Because of that, i don't think we even have the choice of the semantics for Stream.toList(), it has to be the same as stream.collect(Collectors.toList()).

This doesn't remotely follow.? (And, if it did, I would likely not even 
support this RFE.)? The spec of Collectors::toList was crafted to 
disavow pretty much anything other than List-hood, in part in 
anticipation of this addition.


> But it can not be immutable too, for the same reason.

Nope.? The spec of toList() very clearly says: no guarantees as to the 
type, mutability, serializability, etc etc of the returned list.? That 
doesn't mean that every method returning a List added to the JDK after 
Collectors::toList must similarly disavow all such guarantees.

(In fact, we would be entirely justified to change the behavior of 
Collectors::toList tomorrow, to match the proposed Stream::toList; the 
spec was crafted to preserve this option.? We probably won't, because 
there are too many programmers who refuse to read the specification, and 
have baked in the assumption that it returns an ArrayList, and this 
would likely just be picking a fight for little good reason, regardless 
of who is right.)

Please, can we stop having this same tired "I hate nulls, let's find a 
new way to punish people who like them" discussion for every single 
feature?


From forax at univ-mlv.fr  Tue Nov  3 20:30:01 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 3 Nov 2020 21:30:01 +0100 (CET)
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
 <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
 <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
Message-ID: <475927212.1685842.1604435401142.JavaMail.zimbra@u-pem.fr>

> De: "Brian Goetz" <brian.goetz at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Stuart Marks" <smarks at openjdk.java.net>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 3 Novembre 2020 20:54:57
> Objet: Re: RFR: 8180352: Add Stream.toList() method

>>> There is no value in making users remember which stream methods are
>>> null-hostile and which are null-tolerant; this is just more accidental
>>> complexity.

>> I think that ship has sailed a long ago.
>> Some collectors are null hostile, some are not.
>> You can make a point that a Collector is technically not the Stream API per se.

> Yes, and this is no mere "technical argument". A Collector is a collection of
> behaviors, governed by its own spec. The behaviors passed to stream operations,
> whether they be lambdas passed by the user (`.map(x -> x.hopeXIsntNull())`) or
> collector objects or comparators, are under the control of the user, and it is
> the user's responsibility to pass behaviors which are compatible with the data
> domain -- which the user knows and the streams implementation cannot know.

>> Because of that, i don't think we even have the choice of the semantics for
>> Stream.toList(), it has to be the same as stream.collect(Collectors.toList()).

> This doesn't remotely follow. (And, if it did, I would likely not even support
> this RFE.)
It seems you had an issue when replying to my mail, there is a paragraph before "Because" 

> Let's take a step back, 
> if we introduce a method toList() on Stream it will be used a lot, i mean really 
> a lot, to the point where people will change the code from 
> stream.collect(Collectors.toList()) to use stream.toList() instead. 

> The spec of Collectors::toList was crafted to disavow pretty much anything other
> than List-hood, in part in anticipation of this addition.

>> But it can not be immutable too, for the same reason.

> Nope. The spec of toList() very clearly says: no guarantees as to the type,
> mutability, serializability, etc etc of the returned list. That doesn't mean
> that every method returning a List added to the JDK after Collectors::toList
> must similarly disavow all such guarantees.

> (In fact, we would be entirely justified to change the behavior of
> Collectors::toList tomorrow, to match the proposed Stream::toList; the spec was
> crafted to preserve this option. We probably won't, because there are too many
> programmers who refuse to read the specification, and have baked in the
> assumption that it returns an ArrayList, and this would likely just be picking
> a fight for little good reason, regardless of who is right.)
I don't understand your argument. 
You know that you can not change the implementation of Collectors.toList(), and you also know that if there is a method Stream.toList(), people will replace the calls to .collect(Collectors.toList()) by a call to Stream.toList() for the very same reason but you want the semantics of Stream.toList() to be different from the semantics of Collectors.toList(). 

R?mi 

From talden at gmail.com  Tue Nov  3 20:59:37 2020
From: talden at gmail.com (Aaron Scott-Boddendijk)
Date: Wed, 4 Nov 2020 09:59:37 +1300
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <475927212.1685842.1604435401142.JavaMail.zimbra@u-pem.fr>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
 <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
 <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
 <475927212.1685842.1604435401142.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAE=ECuRSmRdOVpgnn1mq-DQsdfGY4L4gJzbCKKJYn7PecHsvgA@mail.gmail.com>

 >>> But it can not be immutable too, for the same reason.

>> Nope. The spec of toList() very clearly says: no guarantees as to the
type,
>> mutability, serializability, etc etc of the returned list. That doesn't
mean
>> that every method returning a List added to the JDK after
Collectors::toList
>> must similarly disavow all such guarantees.

>> (In fact, we would be entirely justified to change the behavior of
>> Collectors::toList tomorrow, to match the proposed Stream::toList; the
spec was
>> crafted to preserve this option. We probably won't, because there are
too many
>> programmers who refuse to read the specification, and have baked in the
>> assumption that it returns an ArrayList, and this would likely just be
picking
>> a fight for little good reason, regardless of who is right.)

>I don't understand your argument.
>You know that you can not change the implementation of
Collectors.toList(), and you also know that if there is a method
Stream.toList(), people will replace the calls to
>.collect(Collectors.toList()) by a call to Stream.toList() for the very
same reason but you want the semantics of Stream.toList() to be different
from the semantics of Collectors.toList().

Surely, taking that position, List.of(...) should not have produced an
unmodifiable list since many combinations of creating Lists would not have
produced unmodifiable lists.

In all of the teams I've worked with, through many Java version transitions
(and 3rdparty library version transitions), dealing with the selective
adoption of new APIs is nothing new.

This case is no different, developers will need to identify the cases in
which they can accept the list as unmodifiable and replace those uses of
Collectors.toList() and Collectors.toUnmodifiableList().

And static-analysis will be able to propose some of those replacements for
us.

Does this mean it's more complex than a text-replace, sure. Will there be
mistakes, sure. But are there benefits to the immutability of the API
result? I suggest that's pretty hard to debate against given the risk of a
mistake is an exception rather than bad data outcomes.

Please don't blunt the tool to make it safer for children.

--
Aaron Scott-Boddendijk


On Wed, Nov 4, 2020 at 9:30 AM <forax at univ-mlv.fr> wrote:

> > De: "Brian Goetz" <brian.goetz at oracle.com>
> > ?: "Remi Forax" <forax at univ-mlv.fr>
> > Cc: "Stuart Marks" <smarks at openjdk.java.net>, "core-libs-dev"
> > <core-libs-dev at openjdk.java.net>
> > Envoy?: Mardi 3 Novembre 2020 20:54:57
> > Objet: Re: RFR: 8180352: Add Stream.toList() method
>
> >>> There is no value in making users remember which stream methods are
> >>> null-hostile and which are null-tolerant; this is just more accidental
> >>> complexity.
>
> >> I think that ship has sailed a long ago.
> >> Some collectors are null hostile, some are not.
> >> You can make a point that a Collector is technically not the Stream API
> per se.
>
> > Yes, and this is no mere "technical argument". A Collector is a
> collection of
> > behaviors, governed by its own spec. The behaviors passed to stream
> operations,
> > whether they be lambdas passed by the user (`.map(x ->
> x.hopeXIsntNull())`) or
> > collector objects or comparators, are under the control of the user, and
> it is
> > the user's responsibility to pass behaviors which are compatible with
> the data
> > domain -- which the user knows and the streams implementation cannot
> know.
>
> >> Because of that, i don't think we even have the choice of the semantics
> for
> >> Stream.toList(), it has to be the same as
> stream.collect(Collectors.toList()).
>
> > This doesn't remotely follow. (And, if it did, I would likely not even
> support
> > this RFE.)
> It seems you had an issue when replying to my mail, there is a paragraph
> before "Because"
>
> > Let's take a step back,
> > if we introduce a method toList() on Stream it will be used a lot, i
> mean really
> > a lot, to the point where people will change the code from
> > stream.collect(Collectors.toList()) to use stream.toList() instead.
>
> > The spec of Collectors::toList was crafted to disavow pretty much
> anything other
> > than List-hood, in part in anticipation of this addition.
>
> >> But it can not be immutable too, for the same reason.
>
> > Nope. The spec of toList() very clearly says: no guarantees as to the
> type,
> > mutability, serializability, etc etc of the returned list. That doesn't
> mean
> > that every method returning a List added to the JDK after
> Collectors::toList
> > must similarly disavow all such guarantees.
>
> > (In fact, we would be entirely justified to change the behavior of
> > Collectors::toList tomorrow, to match the proposed Stream::toList; the
> spec was
> > crafted to preserve this option. We probably won't, because there are
> too many
> > programmers who refuse to read the specification, and have baked in the
> > assumption that it returns an ArrayList, and this would likely just be
> picking
> > a fight for little good reason, regardless of who is right.)
> I don't understand your argument.
> You know that you can not change the implementation of
> Collectors.toList(), and you also know that if there is a method
> Stream.toList(), people will replace the calls to
> .collect(Collectors.toList()) by a call to Stream.toList() for the very
> same reason but you want the semantics of Stream.toList() to be different
> from the semantics of Collectors.toList().
>
> R?mi
>

From martin.desruisseaux at geomatys.com  Tue Nov  3 22:16:49 2020
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Tue, 3 Nov 2020 23:16:49 +0100
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <475927212.1685842.1604435401142.JavaMail.zimbra@u-pem.fr>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
 <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
 <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
 <475927212.1685842.1604435401142.JavaMail.zimbra@u-pem.fr>
Message-ID: <b86cbe48-6e24-0202-9da7-7b02cfc4fe1a@geomatys.com>

Hello

Le 03/11/2020 ? 21:30, forax at univ-mlv.fr a ?crit?:

> You know that you can not change the implementation of 
> Collectors.toList(), and you also know that if there is a method 
> Stream.toList(), people will replace the calls to 
> .collect(Collectors.toList()) by a call to Stream.toList() for the 
> very same reason (?snip?)
>
Would they would be so numerous to do this change without verifying if 
the specifications match? (on my side I do read the method javadoc). But 
even if we worry about developers not reading javadoc, the argument 
could go both ways: they could assume that all Stream methods accepts 
null and not read that Stream.toList() specifies otherwise.

 ??? Martin



From ihse at openjdk.java.net  Tue Nov  3 22:34:03 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 3 Nov 2020 22:34:03 GMT
Subject: RFR: 8253892: Disable misleading-indentation on clang as well as gcc
Message-ID: <o4c8NPdtSYy3Q9ahv1RTaaMzJM1uLVP0N5w4DRSKZmA=.0bc3d50a-4651-447d-9ccf-0291671132cc@github.com>

With clang 10.0, the compiler now detects a new class of warnings. The `misleading-indentation` warning has previously been disabled on gcc for hotspot and libfdlibm.  Now we need to disable it for clang as well.

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

Commit messages:
 - 8253892: Disable misleading-indentation on clang as well as gcc

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

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

From glaubitz at openjdk.java.net  Tue Nov  3 22:38:56 2020
From: glaubitz at openjdk.java.net (John Paul Adrian Glaubitz)
Date: Tue, 3 Nov 2020 22:38:56 GMT
Subject: RFR: 8253892: Disable misleading-indentation on clang as well as
 gcc
In-Reply-To: <o4c8NPdtSYy3Q9ahv1RTaaMzJM1uLVP0N5w4DRSKZmA=.0bc3d50a-4651-447d-9ccf-0291671132cc@github.com>
References: <o4c8NPdtSYy3Q9ahv1RTaaMzJM1uLVP0N5w4DRSKZmA=.0bc3d50a-4651-447d-9ccf-0291671132cc@github.com>
Message-ID: <4ndvIuL0hY08UQkoaye7QsI2UxVSTJs6yD66R7Re9dY=.1b18ff9f-108b-4132-9d8c-a9716efb8be8@github.com>

On Tue, 3 Nov 2020 22:25:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> With clang 10.0, the compiler now detects a new class of warnings. The `misleading-indentation` warning has previously been disabled on gcc for hotspot and libfdlibm.  Now we need to disable it for clang as well.

Why do we disable the warning instead of fixing the incorrect indentations?

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

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

From forax at univ-mlv.fr  Tue Nov  3 22:44:56 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 3 Nov 2020 23:44:56 +0100 (CET)
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <CAE=ECuRSmRdOVpgnn1mq-DQsdfGY4L4gJzbCKKJYn7PecHsvgA@mail.gmail.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
 <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
 <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
 <475927212.1685842.1604435401142.JavaMail.zimbra@u-pem.fr>
 <CAE=ECuRSmRdOVpgnn1mq-DQsdfGY4L4gJzbCKKJYn7PecHsvgA@mail.gmail.com>
Message-ID: <286493187.1707899.1604443496808.JavaMail.zimbra@u-pem.fr>

Hi Aaron, 

> De: "Aaron Scott-Boddendijk" <talden at gmail.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Brian Goetz" <brian.goetz at oracle.com>, "Stuart Marks"
> <smarks at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 3 Novembre 2020 21:59:37
> Objet: Re: RFR: 8180352: Add Stream.toList() method

> >>> But it can not be immutable too, for the same reason.

> >> Nope. The spec of toList() very clearly says: no guarantees as to the type,
> >> mutability, serializability, etc etc of the returned list. That doesn't mean
> >> that every method returning a List added to the JDK after Collectors::toList
> >> must similarly disavow all such guarantees.

> >> (In fact, we would be entirely justified to change the behavior of
> >> Collectors::toList tomorrow, to match the proposed Stream::toList; the spec was
> >> crafted to preserve this option. We probably won't, because there are too many
> >> programmers who refuse to read the specification, and have baked in the
> >> assumption that it returns an ArrayList, and this would likely just be picking
> >> a fight for little good reason, regardless of who is right.)

> >I don't understand your argument.
>>You know that you can not change the implementation of Collectors.toList(), and
>>you also know that if there is a method Stream.toList(), people will replace
> >the calls to
>>.collect(Collectors.toList()) by a call to Stream.toList() for the very same
>>reason but you want the semantics of Stream.toList() to be different from the
> >semantics of Collectors.toList().

> Surely, taking that position, List.of(...) should not have produced an
> unmodifiable list since many combinations of creating Lists would not have
> produced unmodifiable lists.

The problem is that people will see stream.toList() as a shorcut for stream.collect(Collectors.toList()), 
i've not seen my student thinking that List.of() is a shortcut for creating an ArrayList with some elements, but maybe it's because we introduce ArrayList later compared to List.of(...). 

> In all of the teams I've worked with, through many Java version transitions (and
> 3rdparty library version transitions), dealing with the selective adoption of
> new APIs is nothing new.

> This case is no different, developers will need to identify the cases in which
> they can accept the list as unmodifiable and replace those uses of
> Collectors.toList() and Collectors.toUnmodifiableList().

We have Collectors.toList() and Collectors.toUnmodifiableList(), would it make more sense to have stream.toList() and stream.toUnmodifiableList() instead of having stream.toList() that behave half way in betwen the semantics of Collectors.toList() and Collectors.toUnmodifiableList(). 

> And static-analysis will be able to propose some of those replacements for us.

I believe that a tool able to suggest to use Collectors.toUnmodifiableList() instead of Collectors.toList() will rely one a global interprocedural static analysis, so such analysis will be invalid once you will update one of your dependency. 

> Does this mean it's more complex than a text-replace, sure. Will there be
> mistakes, sure. But are there benefits to the immutability of the API result? I
> suggest that's pretty hard to debate against given the risk of a mistake is an
> exception rather than bad data outcomes.

You want immutability/unmodifiability over the cost of people miss mis-using the API. I think it's a sin as bad as me want stream.toList() to return a null hostile List :) 
As Brain implies, Java is a blue collar language, we should not forget it, whatever we think about null or immutability. 

And I said above perhaps we should not discussed about adding a method Stream.toList() but a method Stream.toUnmodifiableList(). 

> Please don't blunt the tool to make it safer for children.

> --
> Aaron Scott-Boddendijk

R?mi 

> On Wed, Nov 4, 2020 at 9:30 AM < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr
> ] > wrote:

>> > De: "Brian Goetz" < [ mailto:brian.goetz at oracle.com | brian.goetz at oracle.com ] >
>> > ?: "Remi Forax" < [ mailto:forax at univ-mlv.fr | forax at univ-mlv.fr ] >
>>> Cc: "Stuart Marks" < [ mailto:smarks at openjdk.java.net | smarks at openjdk.java.net
>> > ] >, "core-libs-dev"
>> > < [ mailto:core-libs-dev at openjdk.java.net | core-libs-dev at openjdk.java.net ] >
>> > Envoy?: Mardi 3 Novembre 2020 20:54:57
>> > Objet: Re: RFR: 8180352: Add Stream.toList() method

>> >>> There is no value in making users remember which stream methods are
>> >>> null-hostile and which are null-tolerant; this is just more accidental
>> >>> complexity.

>> >> I think that ship has sailed a long ago.
>> >> Some collectors are null hostile, some are not.
>> >> You can make a point that a Collector is technically not the Stream API per se.

>> > Yes, and this is no mere "technical argument". A Collector is a collection of
>> > behaviors, governed by its own spec. The behaviors passed to stream operations,
>> > whether they be lambdas passed by the user (`.map(x -> x.hopeXIsntNull())`) or
>> > collector objects or comparators, are under the control of the user, and it is
>> > the user's responsibility to pass behaviors which are compatible with the data
>> > domain -- which the user knows and the streams implementation cannot know.

>> >> Because of that, i don't think we even have the choice of the semantics for
>> >> Stream.toList(), it has to be the same as stream.collect(Collectors.toList()).

>> > This doesn't remotely follow. (And, if it did, I would likely not even support
>> > this RFE.)
>> It seems you had an issue when replying to my mail, there is a paragraph before
>> "Because"

>> > Let's take a step back,
>> > if we introduce a method toList() on Stream it will be used a lot, i mean really
>> > a lot, to the point where people will change the code from
>> > stream.collect(Collectors.toList()) to use stream.toList() instead.

>> > The spec of Collectors::toList was crafted to disavow pretty much anything other
>> > than List-hood, in part in anticipation of this addition.

>> >> But it can not be immutable too, for the same reason.

>> > Nope. The spec of toList() very clearly says: no guarantees as to the type,
>> > mutability, serializability, etc etc of the returned list. That doesn't mean
>> > that every method returning a List added to the JDK after Collectors::toList
>> > must similarly disavow all such guarantees.

>> > (In fact, we would be entirely justified to change the behavior of
>> > Collectors::toList tomorrow, to match the proposed Stream::toList; the spec was
>> > crafted to preserve this option. We probably won't, because there are too many
>> > programmers who refuse to read the specification, and have baked in the
>> > assumption that it returns an ArrayList, and this would likely just be picking
>> > a fight for little good reason, regardless of who is right.)
>> I don't understand your argument.
>> You know that you can not change the implementation of Collectors.toList(), and
>> you also know that if there is a method Stream.toList(), people will replace
>> the calls to .collect(Collectors.toList()) by a call to Stream.toList() for the
>> very same reason but you want the semantics of Stream.toList() to be different
>> from the semantics of Collectors.toList().

>> R?mi

From forax at univ-mlv.fr  Tue Nov  3 22:47:22 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 3 Nov 2020 23:47:22 +0100 (CET)
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <b86cbe48-6e24-0202-9da7-7b02cfc4fe1a@geomatys.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
 <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
 <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
 <475927212.1685842.1604435401142.JavaMail.zimbra@u-pem.fr>
 <b86cbe48-6e24-0202-9da7-7b02cfc4fe1a@geomatys.com>
Message-ID: <1342277376.1708027.1604443642799.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Martin Desruisseaux" <martin.desruisseaux at geomatys.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 3 Novembre 2020 23:16:49
> Objet: Re: RFR: 8180352: Add Stream.toList() method

> Hello
> 
> Le 03/11/2020 ? 21:30, forax at univ-mlv.fr a ?crit?:
> 
>> You know that you can not change the implementation of
>> Collectors.toList(), and you also know that if there is a method
>> Stream.toList(), people will replace the calls to
>> .collect(Collectors.toList()) by a call to Stream.toList() for the
>> very same reason (?snip?)
>>
> Would they would be so numerous to do this change without verifying if
> the specifications match? (on my side I do read the method javadoc). But
> even if we worry about developers not reading javadoc, the argument
> could go both ways: they could assume that all Stream methods accepts
> null and not read that Stream.toList() specifies otherwise.

yes, that why i said to Brian that he is right that stream.toList() should return a List that accept null.

> 
>  ??? Martin

R?mi

From ihse at openjdk.java.net  Tue Nov  3 22:57:54 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 3 Nov 2020 22:57:54 GMT
Subject: RFR: 8253892: Disable misleading-indentation on clang as well as
 gcc
In-Reply-To: <4ndvIuL0hY08UQkoaye7QsI2UxVSTJs6yD66R7Re9dY=.1b18ff9f-108b-4132-9d8c-a9716efb8be8@github.com>
References: <o4c8NPdtSYy3Q9ahv1RTaaMzJM1uLVP0N5w4DRSKZmA=.0bc3d50a-4651-447d-9ccf-0291671132cc@github.com>
 <4ndvIuL0hY08UQkoaye7QsI2UxVSTJs6yD66R7Re9dY=.1b18ff9f-108b-4132-9d8c-a9716efb8be8@github.com>
Message-ID: <II9oaa8-fLwCA-GZgBm--m3rbc_5NQ8huf85CqyCg3U=.a4db9b9d-2d6d-463c-9ca2-61e591eeccc7@github.com>

On Tue, 3 Nov 2020 22:36:34 GMT, John Paul Adrian Glaubitz <glaubitz at openjdk.org> wrote:

>> With clang 10.0, the compiler now detects a new class of warnings. The `misleading-indentation` warning has previously been disabled on gcc for hotspot and libfdlibm.  Now we need to disable it for clang as well.
>
> Why do we disable the warning instead of fixing the incorrect indentations?

@glaubitz Good question. :) If you want to start fixing code to get rid of disabled warnings, I will not stand in your way!

For example, in hotspot and gcc, we have `parentheses comment unknown-pragmas address delete-non-virtual-dtor char-subscripts array-bounds int-in-bool-context ignored-qualifiers missing-field-initializers implicit-fallthrough empty-body strict-overflow sequence-point maybe-uninitialized misleading-indentation cast-function-type shift-negative-value`. I believe many of these should be fixed and removed from the list of disabled warnings.

But this bug is about disabling a warning in one compiler that we have already decided to disable in another.

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

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

From stuart.marks at oracle.com  Tue Nov  3 23:41:46 2020
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 3 Nov 2020 15:41:46 -0800
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <vqSvtBfEwiOEe7DgHNV0WrUgE60idFop1163gpzj_7o=.7ef2df29-9019-412f-b9ba-4902072edada@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <vqSvtBfEwiOEe7DgHNV0WrUgE60idFop1163gpzj_7o=.7ef2df29-9019-412f-b9ba-4902072edada@github.com>
Message-ID: <5894f7c9-98a4-f083-3173-2d1bdfe0f234@oracle.com>



On 11/3/20 3:10 AM, Florian Weimer wrote:
> I'd expect a test here that if the list contains a null element, `List::copyOf` throws `NullPointerException`.

The new Stream.toList() actually permits null elements (by design) so it goes 
through a different path than List::copyOf. The new tests' data provider does 
include nulls in the input, and these should be accepted.

Rejection of nulls for List::copyOf is be handled by tests in

test/jdk/java/util/List/ListFactories.java

s'marks

From mchung at openjdk.java.net  Wed Nov  4 00:05:03 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 4 Nov 2020 00:05:03 GMT
Subject: RFR: 8255863: Clean up
 test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java
Message-ID: <VPsEqCHwcOkWVbGmJEGi_ahoEHCTUCEVZZS_8xPTlHc=.d8461338-a499-44cd-bd5f-65c1700c8c61@github.com>

test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java tests a record class.
This test no longer needs to be run with --enable-preview.

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

Commit messages:
 - 8255863: Clean up test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java

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

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

From mchung at openjdk.java.net  Wed Nov  4 00:06:02 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 4 Nov 2020 00:06:02 GMT
Subject: RFR: 8255862: Remove @SuppressWarnings from sun.misc.Unsafe
Message-ID: <PBmgtaHHOqvNu6cMZtv-R4JCNMXfFj3LMS5vRbqHQvM=.45158ac3-2ffb-43b3-9ad9-d5f9c5b2b317@github.com>

Record classes are now a standard feature in 16. @SuppressWarnings can be
removed from sun.misc.Unsafe.

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

Commit messages:
 - 8255862: Remove @SuppressWarnings from sun.misc.Unsafe

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

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

From smarks at openjdk.java.net  Wed Nov  4 00:14:54 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 4 Nov 2020 00:14:54 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <aEf9SHIToPBuecCg0o-ZKeNj1a28si75KfKKCuaJq5c=.95ad6de6-2d7e-4b69-ab31-cf4c650393a1@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <0zwE2OhqyHVBDkcWL42fXImwwIth508MtuiR2M2HmKg=.a8929d75-fd9a-4056-ab1f-f09b40c01504@github.com>
 <aEf9SHIToPBuecCg0o-ZKeNj1a28si75KfKKCuaJq5c=.95ad6de6-2d7e-4b69-ab31-cf4c650393a1@github.com>
Message-ID: <wSdUECk4APupZvNKUUx7YymkzFXMFmx4dFJ7MGJkwcM=.fc462cf4-8d5f-4a14-b448-64722660fc37@github.com>

On Tue, 3 Nov 2020 18:53:23 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Should there be a test that tests the default implementation in `j.u.s.Stream`? Or maybe there is and I missed that?
>
> @dfuch wrote:
>> Should there be a test that tests the default implementation in `j.u.s.Stream`? Or maybe there is and I missed that?
> 
> The test method `testDefaultOps` does that. The stream test framework has a thing called `DefaultMethodStreams` that delegates everything except default methods to another Stream instance, so this should test the default implementation.

OK, there are rather too many forking threads here for me to try to reply to any particular message, so I'll try to summarize things and say what I intend to do.

Null tolerance. While part of me wants to prohibit nulls, the fact is that Streams pass through nulls, and toList() would be much less useful if it were to reject nulls. The affinity here is closer to Stream.toArray(), which allows nulls, rather than Collectors.to[Unmodifiable]List.

Unmodifiability. Unlike with nulls, this is where we've been taking a strong stand recently, where new constructs are unmodifiable ("shallowly immutable"). Consider the Java 9 unmodifiable collections, records, primitive classes, etc. -- they're all unmodifiable. They're data-race-free and are resistant to a whole class of bugs that arise from mutability.

Unfortunately, the combination of the above means that the returned List is neither like an ArrayList nor like an unmodifiable list produced by List.of() or by Collectors.toUnmodifiableList(). [Heavy sigh.] While I've been somewhat reluctant to introduce this new thing, the alternatives of trying to reuse one of the existing things are worse.

John and R?mi pointed out that the way I implemented this, using a subclass, reintroduces the possibility of problems with megamorphic dispatch which we had so carefully avoided by reducing the number of implementation classes in this area. I agree this is a problem.

I also had an off-line discussion with John where we discussed the serialization format, which unfortunately is somewhat coupled with this issue. (Fortunately I think it can mostly be decoupled.) Given that we're introducing a new thing, which is an unmodifiable-list-that-allows-nulls, this needs to be manifested in the serialized form of these new objects. (This corresponds to the new tag value of IMM_LIST_NULLS in the CollSer class.) The alternative is to reuse the existing serialized form, IMM_LIST, for both of these cases, relaxing it to allow nulls. This would be a serialization immutability problem. Suppose I had an application that created a data structure that used lists from List.of(), and I had a global assertion over that structure that it contained no nulls. Further suppose that I serialized and deserizalized this structure. I'd want that assertion to be preserved after deserialization. If another app (or a future version of this app) created the structure using Stream.to
 List(), this would allow nulls to leak into that structure and violate that assertion. Therefore, the result of Stream.toList() should not be serialization-compatible with List.of() et. al. That's why there's the new IMM_LIST_NULLS tag in the serial format.

However, the new representation in the serial format does NOT necessarily require the implementation to be a different class. I'm going to investigate collapsing ListN and ListNNullsAllowed back into a single class, while preserving the separate serialized forms. This should mitigate the concerns about megamorphic dispatch.

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

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

From bchristi at openjdk.java.net  Wed Nov  4 00:54:57 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 4 Nov 2020 00:54:57 GMT
Subject: RFR: 8254742: InputStream::readNBytes(int) result may contain
 zeros not in input
In-Reply-To: <98TbkcfuPy2a9vBmt6jvxytDwfOocw0T9aw0r7BN6FI=.c55069f6-b801-4ce9-bfd4-1f1f48e7dc5d@github.com>
References: <98TbkcfuPy2a9vBmt6jvxytDwfOocw0T9aw0r7BN6FI=.c55069f6-b801-4ce9-bfd4-1f1f48e7dc5d@github.com>
Message-ID: <HU5AB-8GNsFoJ_XXSYVF4p8R5Bgm1NPzUOZ0l6sauvI=.88391f74-41c0-4af1-8b0b-d827e48d2a8d@github.com>

On Tue, 3 Nov 2020 00:04:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> InputStream::readNBytes() invokes read(byte[],int,int) repeatedly to load bytes into a sequence of intermediate arrays. If an intermediate array is not completely filled before being added to the list of arrays the contents of which are eventually concatenated to produce the result, then the unfilled part of the intermediate array will contribute zeros to the result which are not actually in the input. This can occur for example if n < 8192 bytes are read into an intermediate array without filling it, and the next read() returns zero. It is proposed to detect when an intermediate array is only partially full, and to copy the valid range of the array into a new array which is instead appended to the list of component arrays.

Marked as reviewed by bchristi (Reviewer).

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

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

From bchristi at openjdk.java.net  Wed Nov  4 00:54:58 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 4 Nov 2020 00:54:58 GMT
Subject: RFR: 8254742: InputStream::readNBytes(int) result may contain
 zeros not in input
In-Reply-To: <bdDAYFWhLBg8lKY35a5cb5mwv3SwYDYN8dDgxKG7YyQ=.e5c3ed5a-632a-4eb3-a170-02ad14fbcb1e@github.com>
References: <98TbkcfuPy2a9vBmt6jvxytDwfOocw0T9aw0r7BN6FI=.c55069f6-b801-4ce9-bfd4-1f1f48e7dc5d@github.com>
 <bdDAYFWhLBg8lKY35a5cb5mwv3SwYDYN8dDgxKG7YyQ=.e5c3ed5a-632a-4eb3-a170-02ad14fbcb1e@github.com>
Message-ID: <cMpDV803PC3zFoOcESSghkAEQ3v5f_yC3Ef4xWMCgJE=.d986c21c-888c-4a28-9b0a-f057040275e7@github.com>

On Tue, 3 Nov 2020 08:56:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> InputStream::readNBytes() invokes read(byte[],int,int) repeatedly to load bytes into a sequence of intermediate arrays. If an intermediate array is not completely filled before being added to the list of arrays the contents of which are eventually concatenated to produce the result, then the unfilled part of the intermediate array will contribute zeros to the result which are not actually in the input. This can occur for example if n < 8192 bytes are read into an intermediate array without filling it, and the next read() returns zero. It is proposed to detect when an intermediate array is only partially full, and to copy the valid range of the array into a new array which is instead appended to the list of component arrays.
>
> This makes sense to me.

Looks good to me.

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

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

From vsharma at openjdk.java.net  Wed Nov  4 01:34:13 2020
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Wed, 4 Nov 2020 01:34:13 GMT
Subject: RFR: JDK-8253936 Replace <code>...</code> with {@code ...} for
 java.sql [v2]
In-Reply-To: <zr8HOhlJbmboYIC-rVP0S3Mj5FeXOI4lzlUXvL2XMoc=.f173b3a1-f879-458c-9450-c432cecb6d6f@github.com>
References: <zr8HOhlJbmboYIC-rVP0S3Mj5FeXOI4lzlUXvL2XMoc=.f173b3a1-f879-458c-9450-c432cecb6d6f@github.com>
Message-ID: <oHk3etlLv_g3kGgBAhDDxKEtnxdkc7OI-GYr80DT7bg=.8b95b585-5e91-4c7d-84f1-173f70eab910@github.com>

> <code>...</code> is replaced with {@code ...} in java.sql classes.
> Please review and sponsor this change.

Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision:

  Updated copyright year and other issues reporrted in review

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/707/files
  - new: https://git.openjdk.java.net/jdk/pull/707/files/89245f36..0823d56f

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

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

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

From alanb at openjdk.java.net  Wed Nov  4 07:47:55 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 4 Nov 2020 07:47:55 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator)
In-Reply-To: <x0QEmnZ93qnHvRh3E1Vnudm-RseXooykHXD4X3FeNkA=.9c63d73e-c20e-4219-a1a4-1126aa55085f@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <pS93Tkclki7y3uzfofkeCRZiZV8Wbb0fpPTI4aOHZXA=.b467ed27-1874-4302-833d-e022ef913dbb@github.com>
 <gKyi3UsqpyQ6bWnRX3JIEsc5-4SEMZmHLFdz0gRgRoY=.2b655f9f-551c-4454-9f21-1c9dbf2dcc24@github.com>
 <wW7_WrOpEbYNHP12tT3x2ujcGAl2O35RyZud9SY_43w=.7848a0e3-0015-408e-9dd0-44ab545c7465@github.com>
 <x0QEmnZ93qnHvRh3E1Vnudm-RseXooykHXD4X3FeNkA=.9c63d73e-c20e-4219-a1a4-1126aa55085f@github.com>
Message-ID: <-u4eSM47o_e_KlfTRYBNGyLNhjqAeG-84u_uEd3ppH0=.c49b4269-1001-49d1-96fd-ecacbf2417e9@github.com>

On Mon, 2 Nov 2020 11:26:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I looked through the changes in this update.
>> 
>> The shared memory segment support looks sound and the mechanism to close a shared memory segment is clever (albeit a bit surprising at first that it does global handshake to look for a frame in a scoped region. Also surprising that close can cause failure at both ends - it took me a while to see that this is pragmatic approach).
>> 
>> The share method specifies NPE if thread == null but there is no thread parameter, is this a cut 'n paste error? Another one in registerCleaner where it should be NPE if the cleaner is null.
>> 
>> I think the javadoc for the close method needs to be a bit clearer on the state of the memory segment when IllegalStateException is thrown. Will it be marked "not alive" when it fails? Does this mean there is a resource leak? I think an apiNote to explain the rational for why close is not idempotent is also needed, or maybe it should be re-visited so that close is a no-op when the memory segment is not alive.
>> 
>> Now that MemorySegment is AutoCloseable then maybe the term "alive" should be replaced with "open" or  "closed" and isAlive replaced with isOpen is isClosed.
>> 
>> FileDescriptor can be attraction nuisance and forced reference counting everywhere that it is used. Is it needed? Could an isMapped method work instead?
>> 
>> mapFromPath was in the second preview but I think the method name should be re-examined as it maps a file, the path just locates the file.  Naming is subjectives but in this case using "map" or "mapFile" would fit beside the allocateNative methods.
>> 
>> MappedMemorySegments. The force method specifies a write back guarantee but at the same time, the implNote in the class description suggests that the methods might be a no-op. You might want to adjust the wording to avoid any suggestion that force might be a no-op.
>> 
>> The javadoc for copyFrom isn't changed in this update but I notice it specifies IndexOutOfBoundException when the source segment is larger than the receiver, have other exceptions been examined?
>> 
>> I don't have any any comments on MemoryAccess except that it's not immediately clear why there are "Byte" methods that take a ByteOrder. Make sense for the multi-byte types of course.
>> 
>> The updates the java/nio sources look okay but it would be helpful if the really long lines could be chopped down as it's just too hard to do side-by-side reviews when the lines are so long. A minor nit but the changes X-Buffer.java.template mess up the alignment of the parameters to copyMemory/copySwapMemory methods.
>
>> The javadoc for copyFrom isn't changed in this update but I notice it specifies IndexOutOfBoundException when the source segment is larger than the receiver, have other exceptions been examined?
> 
> This exception is consistent with other uses of this exception throughout this API (e.g. when writing a segment out of bounds).

I assume the CSR needs to be updated so that it's in sync with the API changes in the latest round.

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

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

From github.com+761899+orionll at openjdk.java.net  Wed Nov  4 08:55:56 2020
From: github.com+761899+orionll at openjdk.java.net (Zheka Kozlov)
Date: Wed, 4 Nov 2020 08:55:56 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
Message-ID: <aBcWsV_NhVd3jaVqcC-TKl38hWXUmEIrSUmsYPPF88g=.2b4b7d94-a3cc-4fc0-a9e7-defa360ee3a0@github.com>

On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
> 
> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
> 
> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
> 
> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.

Changes requested by orionll at github.com (no known OpenJDK username).

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

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

From amaembo at gmail.com  Wed Nov  4 08:58:36 2020
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 4 Nov 2020 15:58:36 +0700
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
 <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
 <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
Message-ID: <CAE+3fjaRn2QQJjvV+tukMJDYWVPWJrg9uztwKoN4X7x9Axi1JA@mail.gmail.com>

Hello!

On Wed, Nov 4, 2020 at 2:55 AM Brian Goetz <brian.goetz at oracle.com> wrote:
> (In fact, we would be entirely justified to change the behavior of
> Collectors::toList tomorrow, to match the proposed Stream::toList; the
> spec was crafted to preserve this option.  We probably won't, because
> there are too many programmers who refuse to read the specification, and
> have baked in the assumption that it returns an ArrayList, and this
> would likely just be picking a fight for little good reason, regardless
> of who is right.)

My experience based on writing Stream code as well as reading Stream
code written by other developers suggest that one of the most popular
reasons to modify the resulting list is caused by the need to add a
special value (or a few of them) to the resulting list. We have
several options:
1. List<String> result =
Stream.concat(xyz.stream().filter(...).map(...),
Stream.of("special")).collect(toList());
Canonical, recommended way, no mutability. However concat is really
ugly, it breaks the fluent style of stream API calls, it's hard to
read and people just hate it.

2. List<String> result =
xyz.stream().filter(...).map(...).collect(toCollection(ArrayList::new));
result.add("special");
Mutable result, but much more readable. Also, according to spec. But
this ArrayList::new is hard to type and makes the code longer.

3. List<String> result = xyz.stream().filter(...).map(...).collect(toList());
result.add("special");
Shorter and readable! Well, violates the spec but works!

What people really need is an easy and readable way to concatenate
lists and streams, appending new elements, etc. The JDK doesn't offer
really great options here, so people often end up with external
utility methods or libraries.

Something like this would be very welcomed (and would reduce the need
for mutable lists):
List<String> result =
xyz.stream().filter(...).map(...).append("special").collect(toList());

As for nullity topic, I really welcome that the proposed toList() is
null-tolerant but it worth mentioning that existing terminal
operations like findFirst(), findAny(), min() and max() are already
null-hostile.

With best regards,
Tagir Valeev.

From github.com+761899+orionll at openjdk.java.net  Wed Nov  4 09:04:54 2020
From: github.com+761899+orionll at openjdk.java.net (Zheka Kozlov)
Date: Wed, 4 Nov 2020 09:04:54 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
Message-ID: <3N2Oa4dVVDShlyR-w1G8jWG7mNPL5utzKFdm0QWkM3Y=.0cee9962-8dfb-40f3-b9ae-e50ea8377ed3@github.com>

On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
> 
> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
> 
> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
> 
> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.

src/java.base/share/classes/java/util/stream/Stream.java line 1192:

> 1190:     @SuppressWarnings("unchecked")
> 1191:     default List<T> toList() {
> 1192:         return (List<T>) Collections.unmodifiableList(new ArrayList<>(Arrays.asList(this.toArray())));

Why can't we return `listFromTrustedArrayNullsAllowed` here as in `ReferencePipeline`?
Or at least, we should avoid unnecessary copying of arrays. See [how this is done](https://github.com/amaembo/streamex/blob/master/src/main/java/one/util/streamex/AbstractStreamEx.java#L1313) in StreamEx.

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

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

From kbarrett at openjdk.java.net  Wed Nov  4 09:10:27 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 4 Nov 2020 09:10:27 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v7]
In-Reply-To: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
Message-ID: <IP5CzadacjyTZ5DD3nZ6KaXCufoOj-uRl9764c1vMFc=.477de10c-3a8c-4c72-95a8-a35afa5a8e80@github.com>

> Finally returning to this review that was started in April 2020.  I've
> recast it as a github PR.  I think the security concern raised by Gil
> has been adequately answered.
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
> 
> Please review a new function: java.lang.ref.Reference.refersTo.
> 
> This function is needed to test the referent of a Reference object without
> artificially extending the lifetime of the referent object, as may happen
> when calling Reference.get.  Some garbage collectors require extending the
> lifetime of a weak referent when accessed, in order to maintain collector
> invariants.  Lifetime extension may occur with any collector when the
> Reference is a SoftReference, as calling get indicates recent access.  This
> new function also allows testing the referent of a PhantomReference, which
> can't be accessed by calling get.
> 
> The new function uses native methods whose implementations are in the VM so
> they can use the Access API.  It is the intent that these methods will be
> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
> implemented yet.  Bear that in mind before rushing off to change existing
> uses of Reference.get.
> 
> There are two native methods involved, one in Reference and an override in
> PhantomReference, both package private in java.lang.ref. The reason for this
> split is to simplify the intrinsification. This is a change from the version
> from April 2020; that version had a single native method in Reference,
> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
> However, adding support for that category in the compilers adds significant
> implementation effort and complexity. Splitting avoids that complexity.
> 
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage collectors.

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 13 additional commits since the last revision:

 - Merge branch 'master' into refersto
 - improve wording in refersTo javadoc
 - Merge branch 'master' into refersto
 - More explicit refersTo0 comment.
 - simplify test
 - cleanup nits from Mandy
 - use Object instead of TestObject
 - improve refersTo0 descriptions
 - basic functional test
 - change referent access
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/f06d7348...79277ff3

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/498/files
  - new: https://git.openjdk.java.net/jdk/pull/498/files/3a15b6a9..79277ff3

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

  Stats: 90837 lines in 1555 files changed: 63919 ins; 19502 del; 7416 mod
  Patch: https://git.openjdk.java.net/jdk/pull/498.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/498/head:pull/498

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

From justin.dekeyser at gmail.com  Wed Nov  4 09:19:23 2020
From: justin.dekeyser at gmail.com (Justin Dekeyser)
Date: Wed, 4 Nov 2020 10:19:23 +0100
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <CAE+3fjaRn2QQJjvV+tukMJDYWVPWJrg9uztwKoN4X7x9Axi1JA@mail.gmail.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
 <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
 <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
 <CAE+3fjaRn2QQJjvV+tukMJDYWVPWJrg9uztwKoN4X7x9Axi1JA@mail.gmail.com>
Message-ID: <CAO5-QM1Nb_0nOAisTqFRPH=d_dDsQtY-m5uprXiFeratD9VoLA@mail.gmail.com>

Hello,

I think the `collect(toList())` is interesting, as the developer
really knows that the internal operation is collect-like.
I say this because there would be another, much more functional
approach, that would be of the form
`stream.map(List::of).reduce(List.empty, List::concat)`,
(if ever the List has been made with monads in minds... (concat does
not exist, and there is no unit for the empty list monad).)
The toList() obfuscates both the list implementation (as the current
utils actually) but also obfuscates the philosophy of the conversion.

As suggested by the previous mail, collect version looks much more
explicit, because it really suggests an aggregate operation and allows
one to use the exact constructor.

What about trying to make the Stream interface *flexible* to users,
instead of adding new functionalities that we could regret later?
Then, as the language usages and the trends evolve, we could really
see which of the "utils" functions are relevant to add.

For example, we could maybe invent a method of the form (just a
sketch, not an actual well thought proposal)
`
default <S extends Stream<T>> S wrap(Function<Stream<T>, S> wrapper) {
   return wrapper.apply(this);
}
`
on Stream<T> interface, in such a way one could use the "natural flow"
of writing while binding its own implementation and, therefore, use
its own shortcuts.

Best regards,

Justin Dekeyser

On Wed, Nov 4, 2020 at 9:59 AM Tagir Valeev <amaembo at gmail.com> wrote:
>
> Hello!
>
> On Wed, Nov 4, 2020 at 2:55 AM Brian Goetz <brian.goetz at oracle.com> wrote:
> > (In fact, we would be entirely justified to change the behavior of
> > Collectors::toList tomorrow, to match the proposed Stream::toList; the
> > spec was crafted to preserve this option.  We probably won't, because
> > there are too many programmers who refuse to read the specification, and
> > have baked in the assumption that it returns an ArrayList, and this
> > would likely just be picking a fight for little good reason, regardless
> > of who is right.)
>
> My experience based on writing Stream code as well as reading Stream
> code written by other developers suggest that one of the most popular
> reasons to modify the resulting list is caused by the need to add a
> special value (or a few of them) to the resulting list. We have
> several options:
> 1. List<String> result =
> Stream.concat(xyz.stream().filter(...).map(...),
> Stream.of("special")).collect(toList());
> Canonical, recommended way, no mutability. However concat is really
> ugly, it breaks the fluent style of stream API calls, it's hard to
> read and people just hate it.
>
> 2. List<String> result =
> xyz.stream().filter(...).map(...).collect(toCollection(ArrayList::new));
> result.add("special");
> Mutable result, but much more readable. Also, according to spec. But
> this ArrayList::new is hard to type and makes the code longer.
>
> 3. List<String> result = xyz.stream().filter(...).map(...).collect(toList());
> result.add("special");
> Shorter and readable! Well, violates the spec but works!
>
> What people really need is an easy and readable way to concatenate
> lists and streams, appending new elements, etc. The JDK doesn't offer
> really great options here, so people often end up with external
> utility methods or libraries.
>
> Something like this would be very welcomed (and would reduce the need
> for mutable lists):
> List<String> result =
> xyz.stream().filter(...).map(...).append("special").collect(toList());
>
> As for nullity topic, I really welcome that the proposed toList() is
> null-tolerant but it worth mentioning that existing terminal
> operations like findFirst(), findAny(), min() and max() are already
> null-hostile.
>
> With best regards,
> Tagir Valeev.

From shade at openjdk.java.net  Wed Nov  4 09:21:56 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 4 Nov 2020 09:21:56 GMT
Subject: RFR: 8255862: Remove @SuppressWarnings from sun.misc.Unsafe
In-Reply-To: <PBmgtaHHOqvNu6cMZtv-R4JCNMXfFj3LMS5vRbqHQvM=.45158ac3-2ffb-43b3-9ad9-d5f9c5b2b317@github.com>
References: <PBmgtaHHOqvNu6cMZtv-R4JCNMXfFj3LMS5vRbqHQvM=.45158ac3-2ffb-43b3-9ad9-d5f9c5b2b317@github.com>
Message-ID: <aERZ7Mu5I8OZm3PG_03mwKVzAtQlKUCp1WW8zZNAbY4=.f5f31bbb-5b1f-4ac8-b833-6834b8451e6b@github.com>

On Tue, 3 Nov 2020 23:56:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Record classes are now a standard feature in 16. @SuppressWarnings can be
> removed from sun.misc.Unsafe.

Looks fine to me. I see there are Shenandoah-related failures in testing, that's not the fault of this patch.

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

Marked as reviewed by shade (Reviewer).

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

From kbarrett at openjdk.java.net  Wed Nov  4 09:23:00 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 4 Nov 2020 09:23:00 GMT
Subject: Integrated: 8188055: (ref) Add Reference::refersTo predicate
In-Reply-To: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
Message-ID: <NVs0Y6Jbt11rrNZVekWZdKvdn0D9jJZQMFYbDsKSsp8=.0f935bfb-ebaa-4710-8a70-46ad74884e76@github.com>

On Sun, 4 Oct 2020 03:59:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Finally returning to this review that was started in April 2020.  I've
> recast it as a github PR.  I think the security concern raised by Gil
> has been adequately answered.
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-April/029203.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-July/030401.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-August/030677.html
> https://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2020-September/030793.html
> 
> Please review a new function: java.lang.ref.Reference.refersTo.
> 
> This function is needed to test the referent of a Reference object without
> artificially extending the lifetime of the referent object, as may happen
> when calling Reference.get.  Some garbage collectors require extending the
> lifetime of a weak referent when accessed, in order to maintain collector
> invariants.  Lifetime extension may occur with any collector when the
> Reference is a SoftReference, as calling get indicates recent access.  This
> new function also allows testing the referent of a PhantomReference, which
> can't be accessed by calling get.
> 
> The new function uses native methods whose implementations are in the VM so
> they can use the Access API.  It is the intent that these methods will be
> intrinsified by optimizing compilers like C2 or graal, but that hasn't been
> implemented yet.  Bear that in mind before rushing off to change existing
> uses of Reference.get.
> 
> There are two native methods involved, one in Reference and an override in
> PhantomReference, both package private in java.lang.ref. The reason for this
> split is to simplify the intrinsification. This is a change from the version
> from April 2020; that version had a single native method in Reference,
> implemented using the ON_UNKNOWN_OOP_REF Access reference strength category.
> However, adding support for that category in the compilers adds significant
> implementation effort and complexity. Splitting avoids that complexity.
> 
> Testing:
> mach5 tier1
> Locally (linux-x64) verified the new test passes with various garbage collectors.

This pull request has now been integrated.

Changeset: 6023f6b1
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6023f6b1
Stats:     501 lines in 13 files changed: 488 ins; 0 del; 13 mod

8188055: (ref) Add Reference::refersTo predicate

Reviewed-by: mchung, pliden, rriggs, dholmes, ihse, smarks, alanb

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

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

From tvaleev at openjdk.java.net  Wed Nov  4 09:23:58 2020
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Wed, 4 Nov 2020 09:23:58 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <3N2Oa4dVVDShlyR-w1G8jWG7mNPL5utzKFdm0QWkM3Y=.0cee9962-8dfb-40f3-b9ae-e50ea8377ed3@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <3N2Oa4dVVDShlyR-w1G8jWG7mNPL5utzKFdm0QWkM3Y=.0cee9962-8dfb-40f3-b9ae-e50ea8377ed3@github.com>
Message-ID: <zUyJi1Y8IGbR3Hv50ZWy1OS0oqFycWzHLP7iVECLTec=.2b79a385-c78d-46b3-9b4b-2d5d7bc2d071@github.com>

On Wed, 4 Nov 2020 08:50:49 GMT, Zheka Kozlov <github.com+761899+orionll at openjdk.org> wrote:

>> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
>> 
>> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
>> 
>> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
>> 
>> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.
>
> src/java.base/share/classes/java/util/stream/Stream.java line 1192:
> 
>> 1190:     @SuppressWarnings("unchecked")
>> 1191:     default List<T> toList() {
>> 1192:         return (List<T>) Collections.unmodifiableList(new ArrayList<>(Arrays.asList(this.toArray())));
> 
> Why can't we return `listFromTrustedArrayNullsAllowed` here as in `ReferencePipeline`?
> Or at least, we should avoid unnecessary copying of arrays. See [how this is done](https://github.com/amaembo/streamex/blob/master/src/main/java/one/util/streamex/AbstractStreamEx.java#L1313) in StreamEx.

`listFromTrustedArrayNullsAllowed` is clearly not an option, as it will produce shared-secret leaking (see [JDK-8254090](https://bugs.openjdk.java.net/browse/JDK-8254090) for a similar case). StreamEx solution is dirty as it relies on the implementation detail. I believe, OpenJDK team is not very interested in providing optimal implementations for third-party stream implementations, as third-party implementations will likely update by themselves when necessary. At least, my suggestion to make the default `mapMulti` implementation better was declined.

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

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

From amaembo at gmail.com  Wed Nov  4 09:24:04 2020
From: amaembo at gmail.com (Tagir Valeev)
Date: Wed, 4 Nov 2020 16:24:04 +0700
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <CAO5-QM1Nb_0nOAisTqFRPH=d_dDsQtY-m5uprXiFeratD9VoLA@mail.gmail.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
 <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
 <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
 <CAE+3fjaRn2QQJjvV+tukMJDYWVPWJrg9uztwKoN4X7x9Axi1JA@mail.gmail.com>
 <CAO5-QM1Nb_0nOAisTqFRPH=d_dDsQtY-m5uprXiFeratD9VoLA@mail.gmail.com>
Message-ID: <CAE+3fjZPP1wThvd3MT15oe+ih7of7MYj2PiLjjwxuifNdvjvKQ@mail.gmail.com>

Hello!

On Wed, Nov 4, 2020 at 4:16 PM Justin Dekeyser
<justin.dekeyser at gmail.com> wrote:
> What about trying to make the Stream interface *flexible* to users,
> instead of adding new functionalities that we could regret later?
> Then, as the language usages and the trends evolve, we could really
> see which of the "utils" functions are relevant to add.
>
> For example, we could maybe invent a method of the form (just a
> sketch, not an actual well thought proposal)
> `
> default <S extends Stream<T>> S wrap(Function<Stream<T>, S> wrapper) {
>    return wrapper.apply(this);
> }
> `
> on Stream<T> interface, in such a way one could use the "natural flow"
> of writing while binding its own implementation and, therefore, use
> its own shortcuts.

See https://bugs.openjdk.java.net/browse/JDK-8210372
(also, String::transform)

With best regards,
Tagir Valeev

From tvaleev at openjdk.java.net  Wed Nov  4 09:34:11 2020
From: tvaleev at openjdk.java.net (Tagir F.Valeev)
Date: Wed, 4 Nov 2020 09:34:11 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <JQqMtimYvcfwvNPp7O6OP6F7Jib8794qnGbWpfps4Qo=.d9694144-b5c2-467a-8afd-e31a65aec7a0@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <0dhF_xxcp1VoUowwdZenB2qWa9ILcZjTMe3lsaRrg7k=.3c633db8-f745-4353-ad34-a64fbc96d4e0@github.com>
 <JQqMtimYvcfwvNPp7O6OP6F7Jib8794qnGbWpfps4Qo=.d9694144-b5c2-467a-8afd-e31a65aec7a0@github.com>
Message-ID: <cHFf7xRBwVmj2Uz3frknnQoh4jRQluc9xVBcwDAE0d8=.34d8eb59-b7c3-478a-bf92-a9a1200b0094@github.com>

On Wed, 28 Oct 2020 15:56:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   improve wording in refersTo javadoc
>
> The API looks good, thanks for getting this in.

Hello!

As an IDE developer, I'm thinking about IDE inspection that may suggest the new method. My idea is to suggest replacing every `ref.get() == obj` with `ref.refersTo(obj)`. Is this a good idea or there are cases when `ref.get() == obj` could be preferred? What do you think?

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

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

From kbarrett at openjdk.java.net  Wed Nov  4 09:38:00 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 4 Nov 2020 09:38:00 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <cHFf7xRBwVmj2Uz3frknnQoh4jRQluc9xVBcwDAE0d8=.34d8eb59-b7c3-478a-bf92-a9a1200b0094@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <0dhF_xxcp1VoUowwdZenB2qWa9ILcZjTMe3lsaRrg7k=.3c633db8-f745-4353-ad34-a64fbc96d4e0@github.com>
 <JQqMtimYvcfwvNPp7O6OP6F7Jib8794qnGbWpfps4Qo=.d9694144-b5c2-467a-8afd-e31a65aec7a0@github.com>
 <cHFf7xRBwVmj2Uz3frknnQoh4jRQluc9xVBcwDAE0d8=.34d8eb59-b7c3-478a-bf92-a9a1200b0094@github.com>
Message-ID: <xa0WK4N18s1cmap7LkHfNNKht1nfpuJX3EK8u78-EIY=.d1f7b5a3-9ed5-44c1-8909-fa3dc69fce0e@github.com>

On Wed, 4 Nov 2020 09:31:13 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> The API looks good, thanks for getting this in.
>
> Hello!
> 
> As an IDE developer, I'm thinking about IDE inspection that may suggest the new method. My idea is to suggest replacing every `ref.get() == obj` with `ref.refersTo(obj)`. Is this a good idea or there are cases when `ref.get() == obj` could be preferred? What do you think?

Thanks to a whole host of folks for reviews and comments.

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

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

From github.com+761899+orionll at openjdk.java.net  Wed Nov  4 09:49:00 2020
From: github.com+761899+orionll at openjdk.java.net (Zheka Kozlov)
Date: Wed, 4 Nov 2020 09:49:00 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
Message-ID: <YwAlhIiyxluEDXPN2kR0L--dq5Bej4YyiT5DSrnMhXA=.819a3617-42d1-42c1-94b2-bd780f51cb72@github.com>

On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
> 
> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
> 
> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
> 
> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.

src/java.base/share/classes/java/util/ImmutableCollections.java line 240:

> 238:     static <E> List<E> listFromTrustedArrayNullsAllowed(Object... input) {
> 239:         if (input.length == 0) {
> 240:             return (List<E>) EMPTY_LIST;

If we return a `ListN` here, does this mean that `Stream.of().toList().contains(null)` will throw an NPE? But this is incorrect because `toList()` returns a null-tolerant List.

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

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

From justin.dekeyser at gmail.com  Wed Nov  4 10:00:33 2020
From: justin.dekeyser at gmail.com (Justin Dekeyser)
Date: Wed, 4 Nov 2020 11:00:33 +0100
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <CAE+3fjZPP1wThvd3MT15oe+ih7of7MYj2PiLjjwxuifNdvjvKQ@mail.gmail.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
 <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
 <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
 <CAE+3fjaRn2QQJjvV+tukMJDYWVPWJrg9uztwKoN4X7x9Axi1JA@mail.gmail.com>
 <CAO5-QM1Nb_0nOAisTqFRPH=d_dDsQtY-m5uprXiFeratD9VoLA@mail.gmail.com>
 <CAE+3fjZPP1wThvd3MT15oe+ih7of7MYj2PiLjjwxuifNdvjvKQ@mail.gmail.com>
Message-ID: <CAO5-QM1c3s7+TLSotf0x+tjacfscDBZ-do3=T66ndw1ya_mbhw@mail.gmail.com>

Hello,

Ah that's a super good news, thanks a lot for sharing !
I dream of this since 2 years <3

Best regards,

Justin Dekeyser


On Wed, Nov 4, 2020 at 10:24 AM Tagir Valeev <amaembo at gmail.com> wrote:
>
> Hello!
>
> On Wed, Nov 4, 2020 at 4:16 PM Justin Dekeyser
> <justin.dekeyser at gmail.com> wrote:
> > What about trying to make the Stream interface *flexible* to users,
> > instead of adding new functionalities that we could regret later?
> > Then, as the language usages and the trends evolve, we could really
> > see which of the "utils" functions are relevant to add.
> >
> > For example, we could maybe invent a method of the form (just a
> > sketch, not an actual well thought proposal)
> > `
> > default <S extends Stream<T>> S wrap(Function<Stream<T>, S> wrapper) {
> >    return wrapper.apply(this);
> > }
> > `
> > on Stream<T> interface, in such a way one could use the "natural flow"
> > of writing while binding its own implementation and, therefore, use
> > its own shortcuts.
>
> See https://bugs.openjdk.java.net/browse/JDK-8210372
> (also, String::transform)
>
> With best regards,
> Tagir Valeev

From kbarrett at openjdk.java.net  Wed Nov  4 10:16:59 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 4 Nov 2020 10:16:59 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <cHFf7xRBwVmj2Uz3frknnQoh4jRQluc9xVBcwDAE0d8=.34d8eb59-b7c3-478a-bf92-a9a1200b0094@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <0dhF_xxcp1VoUowwdZenB2qWa9ILcZjTMe3lsaRrg7k=.3c633db8-f745-4353-ad34-a64fbc96d4e0@github.com>
 <JQqMtimYvcfwvNPp7O6OP6F7Jib8794qnGbWpfps4Qo=.d9694144-b5c2-467a-8afd-e31a65aec7a0@github.com>
 <cHFf7xRBwVmj2Uz3frknnQoh4jRQluc9xVBcwDAE0d8=.34d8eb59-b7c3-478a-bf92-a9a1200b0094@github.com>
Message-ID: <BysqfS_1yD8KoFuxW_NNTRBt-PY5VY4Kdzd-Dmi-47w=.bd9c97fd-4bab-48c4-8b83-5979ff9968c4@github.com>

On Wed, 4 Nov 2020 09:31:13 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

> Hello!
> 
> As an IDE developer, I'm thinking about IDE inspection that may suggest the new method. My idea is to suggest replacing every `ref.get() == obj` with `ref.refersTo(obj)`. Is this a good idea or there are cases when `ref.get() == obj` could be preferred? What do you think?

Those have different behaviors when ref's class overrides get.  Sometimes that might be intentional (PhantomReference, where get blocks access to the referent, and SoftReference, where get may update heuristics for recent accesses delaying GC clearing).  But if some further subclass overrides get for some reason, such a change might not be appropriate.

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

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

From jlahoda at openjdk.java.net  Wed Nov  4 10:35:02 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 10:35:02 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
Message-ID: <IijcUDOf-xzQhzimXQT8c7pe7AfuWn2Stirsv-KzC3Y=.c6050a44-bb8b-4ced-8f2d-1c1938c4a100@github.com>

On Mon, 2 Nov 2020 18:39:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - Removing trailing whitespace.
>>  - Merging master into JDK-8250768.
>>  - Updating tests after records are a final feature.
>>  - Fixing tests.
>>  - Finalizing removal of record preview hooks.
>>  - Merging master into JDK-8250768
>>  - Reflecting review comments.
>>  - Merge branch 'master' into JDK-8250768
>>  - Removing unnecessary cast.
>>  - Using a more correct way to get URLs.
>>  - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/api/JavacTaskPool.java line 257:
> 
>> 255:             //when patching modules (esp. java.base), it may be impossible to
>> 256:             //clear the symbols read from the patch path:
>> 257:             polluted |= get(JavaFileManager.class).hasLocation(StandardLocation.PATCH_MODULE_PATH);
> 
> OK, but looks unrelated to primary work

The tests need to inject preview APIs into compilation, and without this tweak, the incorrect values are re-used for tests that use the javac pool. So it is related in the sense it is needed for the tests to pass.

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

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

From jlahoda at openjdk.java.net  Wed Nov  4 10:42:59 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 10:42:59 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
Message-ID: <MkZSP-dnn9axp0s9fBfgTNKxR5Tpqo4IThFsFK4Pfqo=.f8962940-e5a9-40bf-a31a-608104ecae58@github.com>

On Mon, 2 Nov 2020 19:37:39 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - Removing trailing whitespace.
>>  - Merging master into JDK-8250768.
>>  - Updating tests after records are a final feature.
>>  - Fixing tests.
>>  - Finalizing removal of record preview hooks.
>>  - Merging master into JDK-8250768
>>  - Reflecting review comments.
>>  - Merge branch 'master' into JDK-8250768
>>  - Removing unnecessary cast.
>>  - Using a more correct way to get URLs.
>>  - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/builders/AnnotationTypeRequiredMemberBuilder.java line 156:
> 
>> 154:         buildSignature(annotationDocTree);
>> 155:         buildDeprecationInfo(annotationDocTree);
>> 156:         buildPreviewInfo(annotationDocTree);
> 
> (Just checking) I presume this behavior is inherited into `AnnotationTypeOptionalMemberBuilder` so no changes required there.

Right, I think so.

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

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

From forax at univ-mlv.fr  Wed Nov  4 10:45:35 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 4 Nov 2020 11:45:35 +0100 (CET)
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <wSdUECk4APupZvNKUUx7YymkzFXMFmx4dFJ7MGJkwcM=.fc462cf4-8d5f-4a14-b448-64722660fc37@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <0zwE2OhqyHVBDkcWL42fXImwwIth508MtuiR2M2HmKg=.a8929d75-fd9a-4056-ab1f-f09b40c01504@github.com>
 <aEf9SHIToPBuecCg0o-ZKeNj1a28si75KfKKCuaJq5c=.95ad6de6-2d7e-4b69-ab31-cf4c650393a1@github.com>
 <wSdUECk4APupZvNKUUx7YymkzFXMFmx4dFJ7MGJkwcM=.fc462cf4-8d5f-4a14-b448-64722660fc37@github.com>
Message-ID: <642166503.1959043.1604486735140.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stuart Marks" <smarks at openjdk.java.net>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mercredi 4 Novembre 2020 01:14:54
> Objet: Re: RFR: 8180352: Add Stream.toList() method

> On Tue, 3 Nov 2020 18:53:23 GMT, Stuart Marks <smarks at openjdk.org> wrote:
> 
>>> Should there be a test that tests the default implementation in `j.u.s.Stream`?
>>> Or maybe there is and I missed that?
>>
>> @dfuch wrote:
>>> Should there be a test that tests the default implementation in `j.u.s.Stream`?
>>> Or maybe there is and I missed that?
>> 
>> The test method `testDefaultOps` does that. The stream test framework has a
>> thing called `DefaultMethodStreams` that delegates everything except default
>> methods to another Stream instance, so this should test the default
>> implementation.
> 
> OK, there are rather too many forking threads here for me to try to reply to any
> particular message, so I'll try to summarize things and say what I intend to
> do.
> 
> Null tolerance. While part of me wants to prohibit nulls, the fact is that
> Streams pass through nulls, and toList() would be much less useful if it were
> to reject nulls. The affinity here is closer to Stream.toArray(), which allows
> nulls, rather than Collectors.to[Unmodifiable]List.
> 
> Unmodifiability. Unlike with nulls, this is where we've been taking a strong
> stand recently, where new constructs are unmodifiable ("shallowly immutable").
> Consider the Java 9 unmodifiable collections, records, primitive classes, etc.
> -- they're all unmodifiable. They're data-race-free and are resistant to a
> whole class of bugs that arise from mutability.

again, the strong stance about null in collections was taken earlier that the one about unmodifiable collection,
all collections introduced since java 1.6 are null hostile.

I think we are bound to rediscover why :(

<teacher>
And BTW, an unmodifiable list is not data-race free, it depends if the content is immutable or not.
</teacher>

> 
> Unfortunately, the combination of the above means that the returned List is
> neither like an ArrayList nor like an unmodifiable list produced by List.of()
> or by Collectors.toUnmodifiableList(). [Heavy sigh.] While I've been somewhat
> reluctant to introduce this new thing, the alternatives of trying to reuse one
> of the existing things are worse.

This is the smell test here.
You want to introduce a 4th semantics, we already have ArrayList, Arrays.asList() and List.of().
Add a new semantics has not a linear cost, the cost is bigger than linear because of the all the interactions with iterators, streams, etc.
(BTW this remember me that List.of().stream() is not optimize well compared to ArrayList.stream())

This is a real danger, Java is already complex, if it becomes more and more, it will be irrelevant, because it becomes harder and harder to internalize all the semantics inside of your head.
There is already a C++, let us not become another one.

So i really like the fact that you have decided to go bold here and choose to return an unmodifiable list but we should go to full monty and be null hostile too, like toUnmodifiableList().

> 
> John and R?mi pointed out that the way I implemented this, using a subclass,
> reintroduces the possibility of problems with megamorphic dispatch which we had
> so carefully avoided by reducing the number of implementation classes in this
> area. I agree this is a problem.
> 
> I also had an off-line discussion with John where we discussed the serialization
> format, which unfortunately is somewhat coupled with this issue. (Fortunately I
> think it can mostly be decoupled.) Given that we're introducing a new thing,
> which is an unmodifiable-list-that-allows-nulls, this needs to be manifested in
> the serialized form of these new objects. (This corresponds to the new tag
> value of IMM_LIST_NULLS in the CollSer class.) The alternative is to reuse the
> existing serialized form, IMM_LIST, for both of these cases, relaxing it to
> allow nulls. This would be a serialization immutability problem. Suppose I had
> an application that created a data structure that used lists from List.of(),
> and I had a global assertion over that structure that it contained no nulls.
> Further suppose that I serialized and deserizalized this structure. I'd want
> that assertion to be preserved after deserialization. If another app (or a
> future version of this app) created the structure using Stream.to
> List(), this would allow nulls to leak into that structure and violate that
> assertion. Therefore, the result of Stream.toList() should not be
> serialization-compatible with List.of() et. al. That's why there's the new
> IMM_LIST_NULLS tag in the serial format.
> 
> However, the new representation in the serial format does NOT necessarily
> require the implementation to be a different class. I'm going to investigate
> collapsing ListN and ListNNullsAllowed back into a single class, while
> preserving the separate serialized forms. This should mitigate the concerns
> about megamorphic dispatch.

There are 3 reasons to not do that,
- merging ListN and ListNNullsAllowed means we will have trouble when we will want to generify that List as part of Valhalla,
  a list of primitive object (ex inline type) doesn't allow null.

- the current implementation uses @Stable and the transient state for @Stable is null, so you are creating a performance pot hole,
    private static final List<Integer> CONST = Stream.of(2, null).toList();
    ...
    CONST.get(0);  // it's a constant
    CONST.get(1);  // it's not a constant

- you have to sprinkle some if(element == null) at some places, the VM will likely to optimize them away (or at least to consider the follow up code as a dead branch) until the List really store null
  at that point, a deopt storm will likely follow creating a weird latency peak.

R?mi

From alanb at openjdk.java.net  Wed Nov  4 10:51:57 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 4 Nov 2020 10:51:57 GMT
Subject: RFR: 8255862: Remove @SuppressWarnings from sun.misc.Unsafe
In-Reply-To: <PBmgtaHHOqvNu6cMZtv-R4JCNMXfFj3LMS5vRbqHQvM=.45158ac3-2ffb-43b3-9ad9-d5f9c5b2b317@github.com>
References: <PBmgtaHHOqvNu6cMZtv-R4JCNMXfFj3LMS5vRbqHQvM=.45158ac3-2ffb-43b3-9ad9-d5f9c5b2b317@github.com>
Message-ID: <Db10l7vOtzZk5QP1rxtdXHNq7pbBwDFzlq6QN7fhlXw=.0c1e9bc7-7cbb-4b28-90a0-615ffba0a89c@github.com>

On Tue, 3 Nov 2020 23:56:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Record classes are now a standard feature in 16. @SuppressWarnings can be
> removed from sun.misc.Unsafe.

Looks okay. Given some of the changes in the pipeline then we might be want to think about deprecating these methods soon too.

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

Marked as reviewed by alanb (Reviewer).

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

From jlahoda at openjdk.java.net  Wed Nov  4 10:59:02 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 10:59:02 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
Message-ID: <mzKNqA7xgHu-19kTap5m6RMUdXP85yPcERtjXSklSac=.11faf90c-5b79-4ce5-9ec7-673f3e335a9e@github.com>

On Mon, 2 Nov 2020 19:41:08 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - Removing trailing whitespace.
>>  - Merging master into JDK-8250768.
>>  - Updating tests after records are a final feature.
>>  - Fixing tests.
>>  - Finalizing removal of record preview hooks.
>>  - Merging master into JDK-8250768
>>  - Reflecting review comments.
>>  - Merge branch 'master' into JDK-8250768
>>  - Removing unnecessary cast.
>>  - Using a more correct way to get URLs.
>>  - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900
>
> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets.properties line 213:
> 
>> 211: doclet.Preview=Preview.
>> 212: doclet.Properties=Properties
>> 213: doclet.constructors=constructors
> 
> Is the period after `Preview` intentional? It seems inconsistent.

This is consistent with doclet.Deprecated key a few lines up. In the javadoc it then says something along these lines:
Preview.
A binding pattern tree

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

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

From jlahoda at openjdk.java.net  Wed Nov  4 11:04:04 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 11:04:04 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
Message-ID: <BeSJxg7MFuEnGoXMsNJ6K6jpbPZZkQ-17xETBtCA42o=.21065724-decf-46a6-9463-2f61cccaf30c@github.com>

On Mon, 2 Nov 2020 19:59:10 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - Removing trailing whitespace.
>>  - Merging master into JDK-8250768.
>>  - Updating tests after records are a final feature.
>>  - Fixing tests.
>>  - Finalizing removal of record preview hooks.
>>  - Merging master into JDK-8250768
>>  - Reflecting review comments.
>>  - Merge branch 'master' into JDK-8250768
>>  - Removing unnecessary cast.
>>  - Using a more correct way to get URLs.
>>  - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900
>
> test/langtools/jdk/javadoc/doclet/testPreview/api/preview/Core.java line 28:
> 
>> 26: import jdk.internal.javac.PreviewFeature.Feature;
>> 27: 
>> 28: @PreviewFeature(feature=Feature.TEST)
> 
> Yeah, I remember `Feature.TEST` from earlier.  I guess it's OK for now, as a workaround for a testing a feature which is inherently, by design, a moving target across releases. 
> 
> These days, javadoc tests are trending towards generating small sample test programs, instead of having small static side-files dominated  by a legal header. I wonder if there is a possibility of  having a "generator class" in the `javadoc.tester` package that can generate sample code using one or more of the current set of preview features, as a way of reducing the need for the TEST feature.

I have intentionally added Feature.TEST to improve testability. Before, tests were using one of the constants (typically whatever was the first constant), but that seems somewhat problematic - what if (at some point, transiently) we have no preview features?

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

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

From justin.dekeyser at gmail.com  Wed Nov  4 13:18:44 2020
From: justin.dekeyser at gmail.com (Justin Dekeyser)
Date: Wed, 4 Nov 2020 14:18:44 +0100
Subject: Asking to contribute(?)
Message-ID: <CAO5-QM2X1rbTa2pGrqB5zXxA=TdDbsezOiHnsq0xD16A1bbDxw@mail.gmail.com>

Hello everyone,

I have been following this mailing list for several months, and
earlier today my attention was drawn to
https://bugs.openjdk.java.net/browse/JDK-8140283. Actually I've been
dreaming of such a feature for a long time now.

I would really be interested in solving it, but I do not know its
current state nor if someone would agree to sponsor my work on that.

It would be my very first intervention in the Java code base.
(Still have to make sure the Oracle agreement paper does not conflict
with my current job contract, so nothing's ready for now.)

Thank you for your time,

Best regards,

Justin Dekeyser

From jlahoda at openjdk.java.net  Wed Nov  4 13:29:10 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 13:29:10 GMT
Subject: RFR: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final) [v6]
In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
Message-ID: <tHakK_zRnsUlnZscY1TJuS_ZrzuHs15ver2nRZD9tRY=.c137a9eb-d0e4-4586-8c69-88773a28e2a7@github.com>

> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
> 
> A summary of changes:
> -making the feature permanent (non-preview)
> -making the binding variables non-final (as per current specification proposal)
> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal)
> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc.
> 
> This change will not be integrated until JEP 394 is targetted.

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

 - Merge branch 'master' into patterns-instanceof3
 - Merging master into patterns-instanceof3
 - Removing the preview deprecated methods from BindingPatternTree.
 - Merge branch 'master' into patterns-instanceof3
 - Fixing review comments.
 - Cleanup: using a null instead of List.of() as a parameter to JavaCompiler.getTask
 - Merge branch 'master' into patterns-instanceof3
 - Fixing more tests.
 - Correcting positions.
 - Improve the AST model.
 - ... and 10 more: https://git.openjdk.java.net/jdk/compare/7f4d873d...325f96ad

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

Changes: https://git.openjdk.java.net/jdk/pull/559/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=559&range=05
  Stats: 651 lines in 90 files changed: 228 ins; 310 del; 113 mod
  Patch: https://git.openjdk.java.net/jdk/pull/559.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/559/head:pull/559

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

From erikj at openjdk.java.net  Wed Nov  4 13:32:58 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 4 Nov 2020 13:32:58 GMT
Subject: RFR: 8253892: Disable misleading-indentation on clang as well as
 gcc
In-Reply-To: <o4c8NPdtSYy3Q9ahv1RTaaMzJM1uLVP0N5w4DRSKZmA=.0bc3d50a-4651-447d-9ccf-0291671132cc@github.com>
References: <o4c8NPdtSYy3Q9ahv1RTaaMzJM1uLVP0N5w4DRSKZmA=.0bc3d50a-4651-447d-9ccf-0291671132cc@github.com>
Message-ID: <LPXcnKVOOop73hl5HhM6DuhFFH7I_HFKc0JTTtsUvg0=.9103067c-22ae-4b6c-a611-0dcf6fcbbacd@github.com>

On Tue, 3 Nov 2020 22:25:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> With clang 10.0, the compiler now detects a new class of warnings. The `misleading-indentation` warning has previously been disabled on gcc for hotspot and libfdlibm.  Now we need to disable it for clang as well.

Marked as reviewed by erikj (Reviewer).

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

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

From rriggs at openjdk.java.net  Wed Nov  4 14:30:55 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 4 Nov 2020 14:30:55 GMT
Subject: RFR: 8255863: Clean up
 test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java
In-Reply-To: <VPsEqCHwcOkWVbGmJEGi_ahoEHCTUCEVZZS_8xPTlHc=.d8461338-a499-44cd-bd5f-65c1700c8c61@github.com>
References: <VPsEqCHwcOkWVbGmJEGi_ahoEHCTUCEVZZS_8xPTlHc=.d8461338-a499-44cd-bd5f-65c1700c8c61@github.com>
Message-ID: <sAH92oHWeSuSVMEUE_KKbUZQ89KwkrTMt5Lpk5fkRe0=.2cedac4e-9ad8-4caa-a2d7-0545275f6bf6@github.com>

On Tue, 3 Nov 2020 23:55:24 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java tests a record class.
> This test no longer needs to be run with --enable-preview.

Marked as reviewed by rriggs (Reviewer).

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

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

From mdoerr at openjdk.java.net  Wed Nov  4 14:54:07 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Wed, 4 Nov 2020 14:54:07 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v10]
In-Reply-To: <Q4-5D8lEOZhG4McAEvkgeZBGNl-oealNHxKfFAfFy0U=.57aa82a4-0d6e-4a04-b343-ec7f9092be8a@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <Q4-5D8lEOZhG4McAEvkgeZBGNl-oealNHxKfFAfFy0U=.57aa82a4-0d6e-4a04-b343-ec7f9092be8a@github.com>
Message-ID: <Hnb7dm4geiyDJZs1rlLphVhBYuZteBpBGTFXAlAFh_s=.f749fb97-6a83-4341-98c4-36345fee88aa@github.com>

On Tue, 3 Nov 2020 03:01:09 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stubGenerator_ppc.cpp: fix trailing whitespace errors

Thanks for removing the branch from the loop. (Maybe this affects unrolling decision.) Looks good.

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

Marked as reviewed by mdoerr (Reviewer).

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

From rriggs at openjdk.java.net  Wed Nov  4 15:05:58 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 4 Nov 2020 15:05:58 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v10]
In-Reply-To: <Q4-5D8lEOZhG4McAEvkgeZBGNl-oealNHxKfFAfFy0U=.57aa82a4-0d6e-4a04-b343-ec7f9092be8a@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <Q4-5D8lEOZhG4McAEvkgeZBGNl-oealNHxKfFAfFy0U=.57aa82a4-0d6e-4a04-b343-ec7f9092be8a@github.com>
Message-ID: <87_YermU8Z_HS5_a1cJDOjVKsPrjQZkdrPFlNoLcqwI=.a70cdec0-6ea0-468f-853b-a7a9079a9c7c@github.com>

On Tue, 3 Nov 2020 03:01:09 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stubGenerator_ppc.cpp: fix trailing whitespace errors

Marked as reviewed by rriggs (Reviewer).

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

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

From chegar at openjdk.java.net  Wed Nov  4 15:31:58 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 4 Nov 2020 15:31:58 GMT
Subject: RFR: 8255862: Remove @SuppressWarnings from sun.misc.Unsafe
In-Reply-To: <PBmgtaHHOqvNu6cMZtv-R4JCNMXfFj3LMS5vRbqHQvM=.45158ac3-2ffb-43b3-9ad9-d5f9c5b2b317@github.com>
References: <PBmgtaHHOqvNu6cMZtv-R4JCNMXfFj3LMS5vRbqHQvM=.45158ac3-2ffb-43b3-9ad9-d5f9c5b2b317@github.com>
Message-ID: <xkKEq6tz7EYWIeOQNFSDvg6ksK1NXC-mj9Y6asC3XBM=.40bc4bbe-4202-460d-9235-28f79d471b12@github.com>

On Tue, 3 Nov 2020 23:56:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Record classes are now a standard feature in 16. @SuppressWarnings can be
> removed from sun.misc.Unsafe.

Marked as reviewed by chegar (Reviewer).

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

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

From chegar at openjdk.java.net  Wed Nov  4 15:32:00 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 4 Nov 2020 15:32:00 GMT
Subject: RFR: 8255863: Clean up
 test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java
In-Reply-To: <VPsEqCHwcOkWVbGmJEGi_ahoEHCTUCEVZZS_8xPTlHc=.d8461338-a499-44cd-bd5f-65c1700c8c61@github.com>
References: <VPsEqCHwcOkWVbGmJEGi_ahoEHCTUCEVZZS_8xPTlHc=.d8461338-a499-44cd-bd5f-65c1700c8c61@github.com>
Message-ID: <Y8En4txkAXd7IQEk-qvHiBsx1-01XqOjNUWZR-05KqM=.d522ecab-7dbb-47ac-a5cc-53ddef3d9908@github.com>

On Tue, 3 Nov 2020 23:55:24 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java tests a record class.
> This test no longer needs to be run with --enable-preview.

Marked as reviewed by chegar (Reviewer).

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

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

From ihse at openjdk.java.net  Wed Nov  4 16:20:54 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Wed, 4 Nov 2020 16:20:54 GMT
Subject: Integrated: 8253892: Disable misleading-indentation on clang as well
 as gcc
In-Reply-To: <o4c8NPdtSYy3Q9ahv1RTaaMzJM1uLVP0N5w4DRSKZmA=.0bc3d50a-4651-447d-9ccf-0291671132cc@github.com>
References: <o4c8NPdtSYy3Q9ahv1RTaaMzJM1uLVP0N5w4DRSKZmA=.0bc3d50a-4651-447d-9ccf-0291671132cc@github.com>
Message-ID: <mfGJaT0Kr3s8UTLWg8gfZALIp7STPm6He75rYa5YEtE=.a51775f9-a623-4c5c-9b0d-5ffe7382ad6c@github.com>

On Tue, 3 Nov 2020 22:25:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> With clang 10.0, the compiler now detects a new class of warnings. The `misleading-indentation` warning has previously been disabled on gcc for hotspot and libfdlibm.  Now we need to disable it for clang as well.

This pull request has now been integrated.

Changeset: 7dcaba63
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7dcaba63
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8253892: Disable misleading-indentation on clang as well as gcc

Reviewed-by: erikj

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

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

From bpb at openjdk.java.net  Wed Nov  4 16:52:56 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 4 Nov 2020 16:52:56 GMT
Subject: Integrated: 8254742: InputStream::readNBytes(int) result may contain
 zeros not in input
In-Reply-To: <98TbkcfuPy2a9vBmt6jvxytDwfOocw0T9aw0r7BN6FI=.c55069f6-b801-4ce9-bfd4-1f1f48e7dc5d@github.com>
References: <98TbkcfuPy2a9vBmt6jvxytDwfOocw0T9aw0r7BN6FI=.c55069f6-b801-4ce9-bfd4-1f1f48e7dc5d@github.com>
Message-ID: <dV4M3HI88InjZbKoK4zYJRA6_1AjOi6KCXZtywOyXoM=.e5e6cf65-2a3a-4cd6-b938-186f00f5baba@github.com>

On Tue, 3 Nov 2020 00:04:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> InputStream::readNBytes() invokes read(byte[],int,int) repeatedly to load bytes into a sequence of intermediate arrays. If an intermediate array is not completely filled before being added to the list of arrays the contents of which are eventually concatenated to produce the result, then the unfilled part of the intermediate array will contribute zeros to the result which are not actually in the input. This can occur for example if n < 8192 bytes are read into an intermediate array without filling it, and the next read() returns zero. It is proposed to detect when an intermediate array is only partially full, and to copy the valid range of the array into a new array which is instead appended to the list of component arrays.

This pull request has now been integrated.

Changeset: c287170c
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c287170c
Stats:     43 lines in 2 files changed: 39 ins; 1 del; 3 mod

8254742: InputStream::readNBytes(int) result may contain zeros not in input

Reviewed-by: shade, bchristi

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

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

From mchung at openjdk.java.net  Wed Nov  4 17:40:00 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 4 Nov 2020 17:40:00 GMT
Subject: RFR: 8188055: (ref) Add Reference::refersTo predicate [v6]
In-Reply-To: <BysqfS_1yD8KoFuxW_NNTRBt-PY5VY4Kdzd-Dmi-47w=.bd9c97fd-4bab-48c4-8b83-5979ff9968c4@github.com>
References: <D4HSg8FT20Eaxk5KJkkw0GgETSxRkBn1ipS3Dt0kPto=.e4bab078-2e04-4413-90cb-9bfafb2a6831@github.com>
 <0dhF_xxcp1VoUowwdZenB2qWa9ILcZjTMe3lsaRrg7k=.3c633db8-f745-4353-ad34-a64fbc96d4e0@github.com>
 <JQqMtimYvcfwvNPp7O6OP6F7Jib8794qnGbWpfps4Qo=.d9694144-b5c2-467a-8afd-e31a65aec7a0@github.com>
 <cHFf7xRBwVmj2Uz3frknnQoh4jRQluc9xVBcwDAE0d8=.34d8eb59-b7c3-478a-bf92-a9a1200b0094@github.com>
 <BysqfS_1yD8KoFuxW_NNTRBt-PY5VY4Kdzd-Dmi-47w=.bd9c97fd-4bab-48c4-8b83-5979ff9968c4@github.com>
Message-ID: <95NVU6qFbtLLeI2DfNZBHdpbkrXlc0jWTbHpebLpHj0=.31a36bc2-e770-453c-940f-ca21ff79e4c2@github.com>

On Wed, 4 Nov 2020 10:13:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Hello!
>> 
>> As an IDE developer, I'm thinking about IDE inspection that may suggest the new method. My idea is to suggest replacing every `ref.get() == obj` with `ref.refersTo(obj)`. Is this a good idea or there are cases when `ref.get() == obj` could be preferred? What do you think?
>
>> Hello!
>> 
>> As an IDE developer, I'm thinking about IDE inspection that may suggest the new method. My idea is to suggest replacing every `ref.get() == obj` with `ref.refersTo(obj)`. Is this a good idea or there are cases when `ref.get() == obj` could be preferred? What do you think?
> 
> Those have different behaviors when ref's class overrides get.  Sometimes that might be intentional (PhantomReference, where get blocks access to the referent, and SoftReference, where get may update heuristics for recent accesses delaying GC clearing).  But if some further subclass overrides get for some reason, such a change might not be appropriate.

Checking if a reference has been cleared i.e. `ref.get() == null` or `ref.get() != null` may benefit with IDE giving a hint.

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

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

From mchung at openjdk.java.net  Wed Nov  4 17:42:59 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 4 Nov 2020 17:42:59 GMT
Subject: Integrated: 8255862: Remove @SuppressWarnings from sun.misc.Unsafe
In-Reply-To: <PBmgtaHHOqvNu6cMZtv-R4JCNMXfFj3LMS5vRbqHQvM=.45158ac3-2ffb-43b3-9ad9-d5f9c5b2b317@github.com>
References: <PBmgtaHHOqvNu6cMZtv-R4JCNMXfFj3LMS5vRbqHQvM=.45158ac3-2ffb-43b3-9ad9-d5f9c5b2b317@github.com>
Message-ID: <bfQN8akht_xqsOxbwY2Roj-uK_2q_pfpL1965nj_kCo=.92b3146d-dbb2-4818-8845-da9492b34f5c@github.com>

On Tue, 3 Nov 2020 23:56:34 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Record classes are now a standard feature in 16. @SuppressWarnings can be
> removed from sun.misc.Unsafe.

This pull request has now been integrated.

Changeset: 2da9981e
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2da9981e
Stats:     6 lines in 1 file changed: 0 ins; 3 del; 3 mod

8255862: Remove @SuppressWarnings from sun.misc.Unsafe

Reviewed-by: shade, alanb, chegar

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

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

From mchung at openjdk.java.net  Wed Nov  4 17:46:54 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 4 Nov 2020 17:46:54 GMT
Subject: Integrated: 8255863: Clean up
 test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java
In-Reply-To: <VPsEqCHwcOkWVbGmJEGi_ahoEHCTUCEVZZS_8xPTlHc=.d8461338-a499-44cd-bd5f-65c1700c8c61@github.com>
References: <VPsEqCHwcOkWVbGmJEGi_ahoEHCTUCEVZZS_8xPTlHc=.d8461338-a499-44cd-bd5f-65c1700c8c61@github.com>
Message-ID: <bnLhi08hHEO7-dtNNNlRnod7yZ1n58Xs_fdZJM3cSNQ=.97bfc45d-0bf3-41c6-a6fa-df11a2524d5d@github.com>

On Tue, 3 Nov 2020 23:55:24 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java tests a record class.
> This test no longer needs to be run with --enable-preview.

This pull request has now been integrated.

Changeset: 94ace035
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/94ace035
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8255863: Clean up test/jdk/java/lang/invoke/defineHiddenClass/BasicTest.java

Reviewed-by: rriggs, chegar

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

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

From brian.goetz at oracle.com  Wed Nov  4 17:58:59 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 4 Nov 2020 12:58:59 -0500
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <CAE+3fjaRn2QQJjvV+tukMJDYWVPWJrg9uztwKoN4X7x9Axi1JA@mail.gmail.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
 <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
 <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
 <CAE+3fjaRn2QQJjvV+tukMJDYWVPWJrg9uztwKoN4X7x9Axi1JA@mail.gmail.com>
Message-ID: <212b4d2b-f1f5-7332-8e98-860eebb82558@oracle.com>


> As for nullity topic, I really welcome that the proposed toList() is
> null-tolerant but it worth mentioning that existing terminal
> operations like findFirst(), findAny(), min() and max() are already
> null-hostile.
The min() and max() methods are not null hostile.? If you pass a 
null-friendly comparator (such as returned by the `nullsFirst()` and 
`nullsLast()` comparator combinators), nulls are not a problem.? The 
null hostility comes not from streams, but from the behaviors that 
clients pass to stream methods, whether they be min() or max() or 
map().? If the behaviors passed to _any_ stream method are null-hostile, 
then (usually) so will be that stream pipeline.? But this is something 
entirely under the control of the user; users should ensure that their 
domain and the behaviors that operate on that domain are consistent.

What we're talking about is what _streams_ should do.? Streams should 
not gratutiously narrow the domain.? Since `toList()` will be built into 
streams, we have to define this clearly, and there's no justification 
for making this method null-hostile.? The arguments made so far that 
toList() should somehow be null-hostile appear to be nothing more than 
weak wrappers around "I hate nulls, so let's make new methods 
null-hostile."

Remi say:

> You know that you can not change the implementation of 
> Collectors.toList(), and you also know that if there is a method 
> Stream.toList(), people will replace the calls to 
> .collect(Collectors.toList()) by a call to Stream.toList() for the 
> very same reason but you want the semantics of Stream.toList() to be 
> different from the semantics of Collectors.toList().

This is what I call a "for consistency" argument.? Now, we all know that 
consistency is a good starting point, but almost invariably, when 
someone says "you should do X because for consistency with Y", that "for 
consistency" argument turns out to be little more than a thin wrapper 
around "I prefer Y, and I found a precedent for it." Yes, people will be 
tempted to make this assumption -- at first. (And most of the time, that 
will be fine -- the most common thing people do after collecting to a 
list is iterate the list.)?? But it is a complete inversion to say that 
the built-in method must be consistent with any given existing 
Collector, even if that collector has a similar name.? The built-in 
method should provide sensible default to-list behavior, and if you want 
_any other_ to-list behavior -- a mutable list, a different type of 
list, a null-hostile list, a list that drops prime-numbered elements, 
whatever -- you use the more general tool, which is collect(), which 
lets you do whatever you want, and comes with a variety of 
pre-configured options.? And this is the most sensible default behavior 
for a built-in to-list operation.

firstFirst/findAny are indeed sad corner cases, because we didn't have a 
good way of representing "maybe absent nullable value."? (If that case 
were more important, we might have done more work to support it.)? But I 
think it would be a poor move to try and extrapolate from this behavior; 
this behavior is merely a hostage to circumstance.



From yano-masanori at fujitsu.com  Wed Nov  4 09:03:21 2020
From: yano-masanori at fujitsu.com (yano-masanori at fujitsu.com)
Date: Wed, 4 Nov 2020 09:03:21 +0000
Subject: 8250678: ModuleDescriptor.Version parsing treats empty segments
 inconsistently
Message-ID: <OSBPR01MB16719EE75330CEBBE79366ECE7EF0@OSBPR01MB1671.jpnprd01.prod.outlook.com>

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/java/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.java	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 joehw at openjdk.java.net  Wed Nov  4 18:46:57 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Wed, 4 Nov 2020 18:46:57 GMT
Subject: RFR: 8247781: Day periods support [v5]
In-Reply-To: <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
Message-ID: <jEjrbvC0UWHqg_4JKqtrqQewqNwkqxE3HViqOBalA_g=.3cb53665-b5d6-457f-816f-cb8bcdddbc5d@github.com>

On Fri, 30 Oct 2020 11:42:49 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed TCK test failures, added the new pattern char description in DateTimeFormatter
>
> Changes requested by scolebourne (Author).

Since 24:00 is not represented in for example LocalTime and H (hour-of-day) 0-23, it seems obvious midnight in the JDK would be 00:00, and the new DayPeriod tests proves that. The CLDR rule for midnight is also obvious, but the LDML spec does state that it "strongly recommend" that implementations provide for the ability to specify whether midnight is supported or not (and for either 00:00 or 24:00 or both). 

Just wonder whether there is a need to explicitly state the fact about midnight? DateTimeFormatterBuilder::appendInstant() for example, stated clearly how 24:00 is processed, e.g. "The end-of-day time of '24:00' is handled as midnight at the start of the following day."

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

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

From herrick at openjdk.java.net  Wed Nov  4 19:17:11 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 4 Nov 2020 19:17:11 GMT
Subject: RFR: JDK-8252870: Finalize (remove "incubator" from) jpackage [v6]
In-Reply-To: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
Message-ID: <OaeOPTtjUyr9khu_C405JW7d2-n0U6TTSIwU9dnKAUY=.0eda7c31-1c60-4820-9508-9b96ecdd1438@github.com>

> JDK-8252870: Finalize (remove "incubator" from) jpackage

Andy Herrick has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch 'master' into JDK-8252870
 - Merge branch 'master' into JDK-8252870
 - Merge branch master into JDK-8252870
 - Merge branch 'master' into JDK-8252870
 - JDK-8252870: Finalize (remove "incubator" from) jpackage
     - reverting two auto-generated files, and changing module-info to "@since 16"
 - JDK-8252870: Finalize (remove "incubator" from) jpackage
   Merge branch 'finalize' into JDK-8252870
 - 8252869 Finalize (remove incubator from) jpackage (implementation)

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

Changes: https://git.openjdk.java.net/jdk/pull/633/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=633&range=05
  Stats: 1733 lines in 259 files changed: 692 ins; 701 del; 340 mod
  Patch: https://git.openjdk.java.net/jdk/pull/633.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/633/head:pull/633

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

From lancea at openjdk.java.net  Wed Nov  4 19:32:03 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 4 Nov 2020 19:32:03 GMT
Subject: RFR: JDK-8253936 Replace <code>...</code> with {@code ...} for
 java.sql [v2]
In-Reply-To: <oHk3etlLv_g3kGgBAhDDxKEtnxdkc7OI-GYr80DT7bg=.8b95b585-5e91-4c7d-84f1-173f70eab910@github.com>
References: <zr8HOhlJbmboYIC-rVP0S3Mj5FeXOI4lzlUXvL2XMoc=.f173b3a1-f879-458c-9450-c432cecb6d6f@github.com>
 <oHk3etlLv_g3kGgBAhDDxKEtnxdkc7OI-GYr80DT7bg=.8b95b585-5e91-4c7d-84f1-173f70eab910@github.com>
Message-ID: <MBfAaQ9Kxqy4D1Il0qH7198245SVKLLZJuvkim5_Yhs=.1e8ae75b-7ba4-4144-ae14-3a40fcde9d38@github.com>

On Wed, 4 Nov 2020 01:34:13 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

>> <code>...</code> is replaced with {@code ...} in java.sql classes.
>> Please review and sponsor this change.
>
> Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updated copyright year and other issues reporrted in review

Marked as reviewed by lancea (Reviewer).

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

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

From jlahoda at openjdk.java.net  Wed Nov  4 19:36:11 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 19:36:11 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v7]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <wp_qEKajc8aWtWvHtSmytYLeBsrxKzcpHLXE72rP1Q0=.f320f566-3c9c-4a80-9be3-95bbd9d6a29f@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

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

 - Cleanup - removing unnecessary code.
 - Merging master into JDK-8250768-dev4
 - Reflecting review comments.
 - Removing trailing whitespace.
 - Merging master into JDK-8250768.
 - Updating tests after records are a final feature.
 - Fixing tests.
 - Finalizing removal of record preview hooks.
 - Merging master into JDK-8250768
 - Reflecting review comments.
 - ... and 39 more: https://git.openjdk.java.net/jdk/compare/7f4d873d...e4b02827

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

Changes: https://git.openjdk.java.net/jdk/pull/703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=06
  Stats: 3719 lines in 148 files changed: 2701 ins; 730 del; 288 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

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

From openjdk at icemanx.nl  Wed Nov  4 19:36:17 2020
From: openjdk at icemanx.nl (Rob Spoor)
Date: Wed, 4 Nov 2020 20:36:17 +0100
Subject: Asking to contribute(?)
In-Reply-To: <CAO5-QM2X1rbTa2pGrqB5zXxA=TdDbsezOiHnsq0xD16A1bbDxw@mail.gmail.com>
References: <CAO5-QM2X1rbTa2pGrqB5zXxA=TdDbsezOiHnsq0xD16A1bbDxw@mail.gmail.com>
Message-ID: <ba4a2ebf-79b5-ad09-81a5-8865f3cfead7@icemanx.nl>

On 04/11/2020 14:18, Justin Dekeyser wrote:
> Hello everyone,
> 
> I have been following this mailing list for several months, and
> earlier today my attention was drawn to
> https://bugs.openjdk.java.net/browse/JDK-8140283. Actually I've been
> dreaming of such a feature for a long time now.
> 
> I would really be interested in solving it, but I do not know its
> current state nor if someone would agree to sponsor my work on that.
> 
> It would be my very first intervention in the Java code base.
> (Still have to make sure the Oracle agreement paper does not conflict
> with my current job contract, so nothing's ready for now.)
> 
> Thank you for your time,
> 
> Best regards,
> 
> Justin Dekeyser
> 

I'd like this feature as well, but why stop at Stream? String already 
has the transform method, but StringBuilder (and StringBuffer) could 
also use it.

And that's where you're likely to start copy pasting. I've done so for 
several builder classes I've written for myself. So here's a thought: 
why add this method to classes, when you can create a trait using an 
interface with a default method?

     public interface Transformable<T> {

         default <R> R transform(Function<? super T, ? extends R> f) {
             // note: this would need documentation that a class X is
             // only allowed to implement Transformable<X>
             return f.apply((T) this);
         }
     }

So you could get the following, and each would automatically get the 
transform method:
* public class String implements Transformable<String>
* public class StringBuilder implements Transformable<StringBuilder>
* public class StringBuffer implements Transformable<StringBuffer>
* public interface Stream<T> implements Transformable<Stream<T>>

From jlahoda at openjdk.java.net  Wed Nov  4 19:43:06 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 4 Nov 2020 19:43:06 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
Message-ID: <KtWlgWOHrf9MbXbBd_hUeQaDVmIB5BJMAiCJ2DDKKtM=.cb31d17f-07a1-4cca-b5e4-0aa4007c5a44@github.com>

On Mon, 2 Nov 2020 20:21:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 46 commits:
>> 
>>  - Removing trailing whitespace.
>>  - Merging master into JDK-8250768.
>>  - Updating tests after records are a final feature.
>>  - Fixing tests.
>>  - Finalizing removal of record preview hooks.
>>  - Merging master into JDK-8250768
>>  - Reflecting review comments.
>>  - Merge branch 'master' into JDK-8250768
>>  - Removing unnecessary cast.
>>  - Using a more correct way to get URLs.
>>  - ... and 36 more: https://git.openjdk.java.net/jdk/compare/d93e3a7d...2e403900
>
> I have read all the files. 
> 
> I have added a n umber of various minor non-blocking comments (no need for re-review( to fix these.  But I have a couple of comments/questions before finally giving approval.
> There's a comment in `PreviewListWriter` about annotation members that needs too be addressed, and I wonder is RECORD and RECORD_COMPONENT need to be added into PreviewElementKind.

Thanks @jonathan-gibbons for your comments! I've tried to update the code based on them, mostly in https://github.com/lahodaj/jdk/commit/743f516c660b577035cdda4510a0bb97937fd9b2 and https://github.com/lahodaj/jdk/commit/e4b02827998fc2e8f19f983aabfb3d720b03d111

A big chunk of the update is generalization of the deprecated and preview list builders and writers into a "summary" list builder and writer. These should also now handle records. For record components, those are a little tricky, as (AFAIK) can't currently have deprecation/preview-ness for them (and hence there is no good way to test any support for record components in these). But the summary build and writer are looking for record components and will fail in case a record component is sent into them.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Wed Nov  4 20:25:58 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 4 Nov 2020 20:25:58 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v10]
In-Reply-To: <Hnb7dm4geiyDJZs1rlLphVhBYuZteBpBGTFXAlAFh_s=.f749fb97-6a83-4341-98c4-36345fee88aa@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <Q4-5D8lEOZhG4McAEvkgeZBGNl-oealNHxKfFAfFy0U=.57aa82a4-0d6e-4a04-b343-ec7f9092be8a@github.com>
 <Hnb7dm4geiyDJZs1rlLphVhBYuZteBpBGTFXAlAFh_s=.f749fb97-6a83-4341-98c4-36345fee88aa@github.com>
Message-ID: <Eo8DSqoYf45afEOwzrjmMY2FLyRy3r9zXfP8vvHuP6U=.63ba6c7f-1446-4899-af90-5ae6f8236ac7@github.com>

On Wed, 4 Nov 2020 14:51:06 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Thanks for removing the branch from the loop. (Maybe this affects unrolling decision.) Looks good.

Yeah, it does, and oddly enough the best loop unroll value is now 1.   I will re-run the benchmarks again to confirm, but that's what it's looking like now.

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

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

From herrick at openjdk.java.net  Wed Nov  4 20:30:58 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 4 Nov 2020 20:30:58 GMT
Subject: Integrated: JDK-8252870: Finalize (remove "incubator" from) jpackage
In-Reply-To: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
References: <HlksY2mFyKG_kkZA6n6JHHIWBGJT3bjmoLG28c9q1EU=.2b9faa66-08b9-4694-a5db-9d9918039642@github.com>
Message-ID: <7UWYWJYiZj1QKeFBjKC1fPxOdQENTEeBp0QwFxhOcuY=.b202c984-622a-4651-98e0-907a671e7ccc@github.com>

On Tue, 13 Oct 2020 12:51:54 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8252870: Finalize (remove "incubator" from) jpackage

This pull request has now been integrated.

Changeset: 26e7ef78
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/26e7ef78
Stats:     1733 lines in 259 files changed: 692 ins; 701 del; 340 mod

8252870: Finalize (remove "incubator" from) jpackage

Reviewed-by: kcr, erikj, almatvee, asemenyuk, prr, ihse

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

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

From naoto at openjdk.java.net  Wed Nov  4 20:49:57 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 4 Nov 2020 20:49:57 GMT
Subject: RFR: 8247781: Day periods support [v5]
In-Reply-To: <jEjrbvC0UWHqg_4JKqtrqQewqNwkqxE3HViqOBalA_g=.3cb53665-b5d6-457f-816f-cb8bcdddbc5d@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <jEjrbvC0UWHqg_4JKqtrqQewqNwkqxE3HViqOBalA_g=.3cb53665-b5d6-457f-816f-cb8bcdddbc5d@github.com>
Message-ID: <VthlErjstCa3ltZilgl2Xk8OnXqbwZ52LAxtTrhWy2w=.e720dac2-9361-4035-a53d-207d9218fdc8@github.com>

On Wed, 4 Nov 2020 18:44:33 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Changes requested by scolebourne (Author).
>
> Since 24:00 is not represented in for example LocalTime and H (hour-of-day) 0-23, it seems obvious midnight in the JDK would be 00:00, and the new DayPeriod tests proves that. The CLDR rule for midnight is also obvious, but the LDML spec does state that it "strongly recommend" that implementations provide for the ability to specify whether midnight is supported or not (and for either 00:00 or 24:00 or both). 
> 
> Just wonder whether there is a need to explicitly state the fact about midnight? DateTimeFormatterBuilder::appendInstant() for example, stated clearly how 24:00 is processed, e.g. "The end-of-day time of '24:00' is handled as midnight at the start of the following day."

Thanks, Joe. I will incorporate some description about "midnight" in the next update.

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

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

From forax at univ-mlv.fr  Wed Nov  4 20:56:50 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Wed, 4 Nov 2020 21:56:50 +0100 (CET)
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <212b4d2b-f1f5-7332-8e98-860eebb82558@oracle.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
 <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
 <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
 <CAE+3fjaRn2QQJjvV+tukMJDYWVPWJrg9uztwKoN4X7x9Axi1JA@mail.gmail.com>
 <212b4d2b-f1f5-7332-8e98-860eebb82558@oracle.com>
Message-ID: <1403080618.2358182.1604523410681.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> ?: "Tagir Valeev" <amaembo at gmail.com>
> Cc: "Remi Forax" <forax at univ-mlv.fr>, "Stuart Marks" <smarks at openjdk.java.net>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoy?: Mercredi 4 Novembre 2020 18:58:59
> Objet: Re: RFR: 8180352: Add Stream.toList() method

>> As for nullity topic, I really welcome that the proposed toList() is
>> null-tolerant but it worth mentioning that existing terminal
>> operations like findFirst(), findAny(), min() and max() are already
>> null-hostile.
> The min() and max() methods are not null hostile.? If you pass a
> null-friendly comparator (such as returned by the `nullsFirst()` and
> `nullsLast()` comparator combinators), nulls are not a problem.? The
> null hostility comes not from streams, but from the behaviors that
> clients pass to stream methods, whether they be min() or max() or
> map().? If the behaviors passed to _any_ stream method are null-hostile,
> then (usually) so will be that stream pipeline.? But this is something
> entirely under the control of the user; users should ensure that their
> domain and the behaviors that operate on that domain are consistent.
> 
> What we're talking about is what _streams_ should do.? Streams should
> not gratutiously narrow the domain.? Since `toList()` will be built into
> streams, we have to define this clearly, and there's no justification
> for making this method null-hostile.? The arguments made so far that
> toList() should somehow be null-hostile appear to be nothing more than
> weak wrappers around "I hate nulls, so let's make new methods
> null-hostile."
> 
> Remi say:
> 
>> You know that you can not change the implementation of
>> Collectors.toList(), and you also know that if there is a method
>> Stream.toList(), people will replace the calls to
>> .collect(Collectors.toList()) by a call to Stream.toList() for the
>> very same reason but you want the semantics of Stream.toList() to be
>> different from the semantics of Collectors.toList().
> 
> This is what I call a "for consistency" argument.? Now, we all know that
> consistency is a good starting point, but almost invariably, when
> someone says "you should do X because for consistency with Y", that "for
> consistency" argument turns out to be little more than a thin wrapper
> around "I prefer Y, and I found a precedent for it." Yes, people will be
> tempted to make this assumption -- at first. (And most of the time, that
> will be fine -- the most common thing people do after collecting to a
> list is iterate the list.)?? But it is a complete inversion to say that
> the built-in method must be consistent with any given existing
> Collector, even if that collector has a similar name.? The built-in
> method should provide sensible default to-list behavior, and if you want
> _any other_ to-list behavior -- a mutable list, a different type of
> list, a null-hostile list, a list that drops prime-numbered elements,
> whatever -- you use the more general tool, which is collect(), which
> lets you do whatever you want, and comes with a variety of
> pre-configured options.? And this is the most sensible default behavior
> for a built-in to-list operation.

As i said since, i can live with only one method toList() instead of two (toList() and toUnmodifiableList()), as you said this requires to provide a good default.
Obviously i still disagree with you about what the good default is.

This morning i was thinking about the symmetry between stream.toList() and stream.toArray(), there are two variants of toarray, toArray() and toArray(IntFunction<A[]>),
the second variant let you choose as a user which implementation of array you want.

I wonder if we should not do the same with toList(), having toList() to be equivalent to collect(Collectors.toUnmodifiableList()) and toList(IntFunction<List<E>>) allowing to use a null friendly List implementation like ArrayList. 

> 
> firstFirst/findAny are indeed sad corner cases, because we didn't have a
> good way of representing "maybe absent nullable value."? (If that case
> were more important, we might have done more work to support it.)? But I
> think it would be a poor move to try and extrapolate from this behavior;
> this behavior is merely a hostage to circumstance.

R?mi

From ryadav at openjdk.java.net  Wed Nov  4 21:59:02 2020
From: ryadav at openjdk.java.net (Rahul Yadav)
Date: Wed, 4 Nov 2020 21:59:02 GMT
Subject: RFR: 8255214 : Unsupported 'valign' attribute for 'th' tag used in
 j.u.l.LogManager
Message-ID: <7m69nfdp-uy1A4Xtn1rNZsG21IbKzRuPCsW_2d-MUbU=.3d922f24-528c-4499-a420-1b5e5a8c0c8e@github.com>

Hello,

Request to review this small change, as HTML4 support has been dropped from javadoc.
Have replaced valign="top" with style="vertical-align:top".

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

Commit messages:
 - JDK-8255214 : Unsupported 'valign' attribute for 'th' tag used in j.u.l.LogManager

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

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

From naoto at openjdk.java.net  Wed Nov  4 22:13:25 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 4 Nov 2020 22:13:25 GMT
Subject: RFR: 8247781: Day periods support [v6]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <TvkjldizPHi6iF1jymT2C9MPbcUzV-UvQfOO0gxPVTw=.0f874012-aaf0-43c9-922b-a1f18206d591@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

 - Merge branch 'master' into dayperiod
 - Change based on CSR change.
 - Fixed TCK test failures, added the new pattern char description in DateTimeFormatter
 - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516147298
 - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516123190
 - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516138455
 - Fixed exception messages.
 - Addressed the following comments:
   - https://github.com/openjdk/jdk/pull/938#discussion_r515003422
   - https://github.com/openjdk/jdk/pull/938#discussion_r515005296
   - https://github.com/openjdk/jdk/pull/938#discussion_r515008862
   - https://github.com/openjdk/jdk/pull/938#discussion_r515030268
   - https://github.com/openjdk/jdk/pull/938#discussion_r515030880
   - https://github.com/openjdk/jdk/pull/938#discussion_r515032002
   - https://github.com/openjdk/jdk/pull/938#discussion_r515036803
   - https://github.com/openjdk/jdk/pull/938#discussion_r515037626
   - https://github.com/openjdk/jdk/pull/938#discussion_r515038069
   - https://github.com/openjdk/jdk/pull/938#discussion_r515039056
 - 8247781: Day periods support

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/e52fe51f..4aa5b197

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

  Stats: 12803 lines in 661 files changed: 7123 ins; 3276 del; 2404 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

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

From github.com+51754783+coreyashford at openjdk.java.net  Wed Nov  4 22:54:13 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Wed, 4 Nov 2020 22:54:13 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v11]
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <mKjB8xy1sDO9HsOmSMlQLvPsspjwYtmNBLVFNHQ5DKY=.309cbddb-a18c-4c10-af32-c1112d0355c7@github.com>

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

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

  stubGenerator_ppc.cpp: reduce loop_unrolls to 1 to match new benchmark results.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/293/files
  - new: https://git.openjdk.java.net/jdk/pull/293/files/8292527e..c4d22da3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=293&range=09-10

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

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

From brian.goetz at oracle.com  Wed Nov  4 23:02:28 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Wed, 4 Nov 2020 18:02:28 -0500
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <1403080618.2358182.1604523410681.JavaMail.zimbra@u-pem.fr>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
 <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
 <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
 <CAE+3fjaRn2QQJjvV+tukMJDYWVPWJrg9uztwKoN4X7x9Axi1JA@mail.gmail.com>
 <212b4d2b-f1f5-7332-8e98-860eebb82558@oracle.com>
 <1403080618.2358182.1604523410681.JavaMail.zimbra@u-pem.fr>
Message-ID: <aa201697-b481-4400-d793-10091dcaac02@oracle.com>


> I wonder if we should not do the same with toList(), having toList() to be equivalent to collect(Collectors.toUnmodifiableList()) and toList(IntFunction<List<E>>) allowing to use a null friendly List implementation like ArrayList.

If you pull on this string all the way, we end up with "let's just not 
do anything."

Adding conveniences only begets demands for more conveniences, and the 
endpoint there is a class with hundreds of trivial methods. This is why 
we held the line for so long.? Over that time, it emerged that the _one_ 
convenience method we could justify was toList(), since 
collect(toList()) is single most commonly used terminal op -- but only 
if we could justify stopping there.? Which I think we can, so we're 
stopping there.? (Maybe in five years we'll add another one.)



From github.com+645859+epaul at openjdk.java.net  Wed Nov  4 23:10:57 2020
From: github.com+645859+epaul at openjdk.java.net (=?UTF-8?B?UGHFrWxv?= Ebermann)
Date: Wed, 4 Nov 2020 23:10:57 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
Message-ID: <bUKuBU0ScUvhnCa-rUjJDUCPUfcPmS-OqMXyTSBsUeU=.2430a5a0-076e-4f16-9d1d-0dfa49faa99d@github.com>

On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
> 
> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
> 
> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
> 
> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.

src/java.base/share/classes/java/util/ImmutableCollections.java line 199:

> 197:      * safely reused as the List's internal storage, avoiding a defensive copy. Declared
> 198:      * with Object... instead of E... as the parameter type so that varargs calls don't
> 199:      * accidentally create an array of type other than Object[].

Why would that be a problem? If the resulting list is immutable, then the actual array type doesn't really matter, right?

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

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

From mchung at openjdk.java.net  Wed Nov  4 23:18:56 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 4 Nov 2020 23:18:56 GMT
Subject: RFR: 8255214 : Unsupported 'valign' attribute for 'th' tag used
 in j.u.l.LogManager
In-Reply-To: <7m69nfdp-uy1A4Xtn1rNZsG21IbKzRuPCsW_2d-MUbU=.3d922f24-528c-4499-a420-1b5e5a8c0c8e@github.com>
References: <7m69nfdp-uy1A4Xtn1rNZsG21IbKzRuPCsW_2d-MUbU=.3d922f24-528c-4499-a420-1b5e5a8c0c8e@github.com>
Message-ID: <YEz84zKc4G34GRWXV3jOc1S3PhBTp-wU0D_suT9_BSs=.1d1a662d-67f5-493a-b5ae-d91057399df4@github.com>

On Wed, 4 Nov 2020 21:52:56 GMT, Rahul Yadav <ryadav at openjdk.org> wrote:

> Hello,
> 
> Request to review this small change, as HTML4 support has been dropped from javadoc.
> Have replaced valign="top" with style="vertical-align:top".

Marked as reviewed by mchung (Reviewer).

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

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

From github.com+645859+epaul at openjdk.java.net  Wed Nov  4 23:20:57 2020
From: github.com+645859+epaul at openjdk.java.net (=?UTF-8?B?UGHFrWxv?= Ebermann)
Date: Wed, 4 Nov 2020 23:20:57 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <aBcWsV_NhVd3jaVqcC-TKl38hWXUmEIrSUmsYPPF88g=.2b4b7d94-a3cc-4fc0-a9e7-defa360ee3a0@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <aBcWsV_NhVd3jaVqcC-TKl38hWXUmEIrSUmsYPPF88g=.2b4b7d94-a3cc-4fc0-a9e7-defa360ee3a0@github.com>
Message-ID: <zNl6puL1sy_S1JWp3tLiQQf2YrhHvHY3GtGIBjtfz7E=.5eb94743-bfbb-4908-a2af-e9aceb22c9d3@github.com>

On Wed, 4 Nov 2020 08:53:23 GMT, Zheka Kozlov <github.com+761899+orionll at openjdk.org> wrote:

>> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
>> 
>> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
>> 
>> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
>> 
>> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.
>
> Changes requested by orionll at github.com (no known OpenJDK username).

Looking at the linked issue, I see [this comment from R?mi Forax](https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14171626&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14171626):

> Please talk with Brian about this change because it nulls a property of the Stream API we (the lambda-util group) have take time to keep.
The whole Stream API doesn't depends on the Collection API, [...] so the Stream API can be easily integrated with other collection API if in the future we want by example add a persistent collection API with no link with java.util.List.

That's an argument I can understand ? as is, the Stream API works just as well with collections from e.g. Scala's or Kotlin's (or Ceylon's) collection libraries instead of the java.util ones, just using different collectors. Adding a method which directly returns a java.util.List somewhat couples it to the Java Collection API.

Now this was mentioned two and a half year ago. Did something change which made this consideration irrelevant? I would expect at least some mention of it in the discussion here.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Thu Nov  5 01:20:08 2020
From: github.com+51754783+coreyashford at openjdk.java.net (CoreyAshford)
Date: Thu, 5 Nov 2020 01:20:08 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v12]
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <HTGhchKnqvptVzMrGvV6bxpoOtAUXt1vOYB3Es9RBz8=.d8d84bbc-0aa4-46e4-a7d1-fa4b2a004eee@github.com>

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

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

  stubGenerator_ppc.cpp: fix typo (omitted 'the')

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/293/files
  - new: https://git.openjdk.java.net/jdk/pull/293/files/c4d22da3..9e303dad

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

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

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

From amaembo at gmail.com  Thu Nov  5 02:37:50 2020
From: amaembo at gmail.com (Tagir Valeev)
Date: Thu, 5 Nov 2020 09:37:50 +0700
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <212b4d2b-f1f5-7332-8e98-860eebb82558@oracle.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <368586170.1475743.1604415181648.JavaMail.zimbra@u-pem.fr>
 <5bf7aaff-8c8e-a6f3-3b0f-03d6889209e4@oracle.com>
 <1272431905.1666883.1604431476806.JavaMail.zimbra@u-pem.fr>
 <76ad3e20-0a63-8ed0-bb03-a38c6892a2a8@oracle.com>
 <CAE+3fjaRn2QQJjvV+tukMJDYWVPWJrg9uztwKoN4X7x9Axi1JA@mail.gmail.com>
 <212b4d2b-f1f5-7332-8e98-860eebb82558@oracle.com>
Message-ID: <CAE+3fjZJUCG6r=gCc0_jkCvnrXaQH1UNTzHEbpEinoSzhd3aPQ@mail.gmail.com>

Hello!

> The min() and max() methods are not null hostile.  If you pass a
> null-friendly comparator (such as returned by the `nullsFirst()` and
> `nullsLast()` comparator combinators), nulls are not a problem.

No, it is the problem, the same as with findFirst(). Try it:

Comparator<String> nullFriendly =
Comparator.nullsFirst(Comparator.naturalOrder());
List<String> data = Arrays.asList("hello", null, "world");
System.out.println(Collections.min(data, nullFriendly)); // null -- correct
System.out.println(data.stream().min(nullFriendly)); // NPE!

With best regards,
Tagir Valeev.

From hshi at openjdk.java.net  Thu Nov  5 03:03:03 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Thu, 5 Nov 2020 03:03:03 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?=
Message-ID: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>

?AccessorImpl object

We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883

Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.

In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.

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

Commit messages:
 - 8255883: Avoid multiple GeneratedMethodAccessor for same NativeMethodAccessorImpl object

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

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

From justin.dekeyser at gmail.com  Thu Nov  5 05:23:10 2020
From: justin.dekeyser at gmail.com (Justin Dekeyser)
Date: Thu, 5 Nov 2020 06:23:10 +0100
Subject: Asking to contribute(?)
In-Reply-To: <ba4a2ebf-79b5-ad09-81a5-8865f3cfead7@icemanx.nl>
References: <CAO5-QM2X1rbTa2pGrqB5zXxA=TdDbsezOiHnsq0xD16A1bbDxw@mail.gmail.com>
 <ba4a2ebf-79b5-ad09-81a5-8865f3cfead7@icemanx.nl>
Message-ID: <CAO5-QM3OFAkE_CSk+eUuegu2n-ru0usjdCQjJ_vZyASE6tmZog@mail.gmail.com>

Hello,

Thank you for your answer, I appreciate!

Indeed, it is clear to me that if the feature should be a concern of both
String and Stream (or more?), a common contract can be designed.

The impl. you sketch is the more natural one I think. (it's also the one I
gave in the other mailing grap about that toList stuff, so I guess it's ok!)

I am just a bit cold about the idea that the spec will make the compiler's
job, but I guess in Java there is no work around.

I don't know what the community thinks about it.

Regards,

Justin Dekeyser

On Wednesday, November 4, 2020, Rob Spoor <openjdk at icemanx.nl> wrote:

> On 04/11/2020 14:18, Justin Dekeyser wrote:
>
>> Hello everyone,
>>
>> I have been following this mailing list for several months, and
>> earlier today my attention was drawn to
>> https://bugs.openjdk.java.net/browse/JDK-8140283. Actually I've been
>> dreaming of such a feature for a long time now.
>>
>> I would really be interested in solving it, but I do not know its
>> current state nor if someone would agree to sponsor my work on that.
>>
>> It would be my very first intervention in the Java code base.
>> (Still have to make sure the Oracle agreement paper does not conflict
>> with my current job contract, so nothing's ready for now.)
>>
>> Thank you for your time,
>>
>> Best regards,
>>
>> Justin Dekeyser
>>
>>
> I'd like this feature as well, but why stop at Stream? String already has
> the transform method, but StringBuilder (and StringBuffer) could also use
> it.
>
> And that's where you're likely to start copy pasting. I've done so for
> several builder classes I've written for myself. So here's a thought: why
> add this method to classes, when you can create a trait using an interface
> with a default method?
>
>     public interface Transformable<T> {
>
>         default <R> R transform(Function<? super T, ? extends R> f) {
>             // note: this would need documentation that a class X is
>             // only allowed to implement Transformable<X>
>             return f.apply((T) this);
>         }
>     }
>
> So you could get the following, and each would automatically get the
> transform method:
> * public class String implements Transformable<String>
> * public class StringBuilder implements Transformable<StringBuilder>
> * public class StringBuffer implements Transformable<StringBuffer>
> * public interface Stream<T> implements Transformable<Stream<T>>
>

From jlahoda at openjdk.java.net  Thu Nov  5 08:04:55 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 5 Nov 2020 08:04:55 GMT
Subject: Integrated: 8250625: Compiler implementation of Pattern Matching for
 instanceof (Final)
In-Reply-To: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
References: <0uEby0-y3KVBLA1VxxdD5hCMlLhPCKB3w0mpihs9dsY=.181f22cd-7cf7-4941-b2d1-2ba4228d11d5@github.com>
Message-ID: <nUkL9iXeuEGYEAKGy577xnEBf2E5G4nWx0RYA4j2m2s=.6a49113e-86ed-44d9-b115-fd47689abc71@github.com>

On Thu, 8 Oct 2020 11:49:17 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is the current proposed patch for the upcoming JEP 394, for pattern matching for instanceof.
> 
> A summary of changes:
> -making the feature permanent (non-preview)
> -making the binding variables non-final (as per current specification proposal)
> -producing a compile-time error for the case where the expression's type is a subtype of the type test pattern's type (as per current specification proposal)
> -changing the AST structure so that the binding variable has a VariableTree in the AST. BindingPatternTree is preserved and encloses the VariableTree. The reason is better consistency in the API, with nodes like CatchTree, EnhancedForLoop Tree, etc.
> 
> This change will not be integrated until JEP 394 is targetted.

This pull request has now been integrated.

Changeset: 18bc95ba
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/18bc95ba
Stats:     651 lines in 90 files changed: 228 ins; 310 del; 113 mod

8250625: Compiler implementation of Pattern Matching for instanceof (Final)

Reviewed-by: vromero

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

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

From shade at openjdk.java.net  Thu Nov  5 09:09:57 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 5 Nov 2020 09:09:57 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?=
In-Reply-To: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
Message-ID: <6914QI9MySYQ4-Lpt_OIzMBbyFGRTYnPTLGJpIfBdQI=.57041221-95ea-44eb-90a6-57789597f741@github.com>

On Thu, 5 Nov 2020 02:52:05 GMT, Hui Shi <hshi at openjdk.org> wrote:

> ?AccessorImpl object
> 
> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
> 
> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
> 
> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.

I do wonder if it makes sense to handle triple-state `int` here: "not yet generated", "generated", "in error"? So that we don't try to generate the accessor over and over again when it is in error?

src/java.base/share/classes/jdk/internal/reflect/NativeMethodAccessorImpl.java line 80:

> 78:                 succ = true;
> 79:             } finally {
> 80:                 if (succ == false) {

Why `succ` variable, if you can just `catch (Throwable e)` and restore the `accessorGenerated`?

src/java.base/share/classes/jdk/internal/reflect/NativeMethodAccessorImpl.java line 66:

> 64:                 && !method.getDeclaringClass().isHidden()
> 65:                 && !ReflectUtil.isVMAnonymousClass(method.getDeclaringClass())
> 66:                 && ACCESSOR_GENERATED.compareAndSet(this, false, true)) {

As the micro-optimization, checking that `accessor_generated` is `false` before attempting a (potentially contended) CAS might fit better. (See https://en.wikipedia.org/wiki/Test_and_test-and-set).

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

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

From jlahoda at openjdk.java.net  Thu Nov  5 09:31:20 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 5 Nov 2020 09:31:20 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v8]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <y-trIOfLEVK-lQ45vC5TzEQAaZiBAHhcQ0oPzNox4kY=.47a73ac3-67a7-4024-a2fa-2bff9bbccb75@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

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

 - Merging master into JDK-8250768
 - Removing unnecessary property keys.
 - Cleanup - removing unnecessary code.
 - Merging master into JDK-8250768-dev4
 - Reflecting review comments.
 - Removing trailing whitespace.
 - Merging master into JDK-8250768.
 - Updating tests after records are a final feature.
 - Fixing tests.
 - Finalizing removal of record preview hooks.
 - ... and 41 more: https://git.openjdk.java.net/jdk/compare/700447f7...3d55f909

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

Changes: https://git.openjdk.java.net/jdk/pull/703/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=07
  Stats: 3665 lines in 136 files changed: 2701 ins; 692 del; 272 mod
  Patch: https://git.openjdk.java.net/jdk/pull/703.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/703/head:pull/703

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

From jlahoda at openjdk.java.net  Thu Nov  5 09:51:13 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 5 Nov 2020 09:51:13 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v9]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <hLYgh37_nCbIVUDXUIl1LsiyNyD1Z9nmsLWguYFdtWA=.ff11a8ad-9271-4750-b47d-b1ae3fd3a379@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Removing obsolette @PreviewFeature.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/703/files
  - new: https://git.openjdk.java.net/jdk/pull/703/files/3d55f909..370031f0

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

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

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

From mdoerr at openjdk.java.net  Thu Nov  5 10:13:59 2020
From: mdoerr at openjdk.java.net (Martin Doerr)
Date: Thu, 5 Nov 2020 10:13:59 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v12]
In-Reply-To: <HTGhchKnqvptVzMrGvV6bxpoOtAUXt1vOYB3Es9RBz8=.d8d84bbc-0aa4-46e4-a7d1-fa4b2a004eee@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <HTGhchKnqvptVzMrGvV6bxpoOtAUXt1vOYB3Es9RBz8=.d8d84bbc-0aa4-46e4-a7d1-fa4b2a004eee@github.com>
Message-ID: <OWFWSEAqLsrjfaGumYs3D492GXaPe_7p4GfEbZh30xo=.5e0f6bcc-b2e4-4fa4-97cf-62bd993a22fa@github.com>

On Thu, 5 Nov 2020 01:20:08 GMT, CoreyAshford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

>> This patch set encompasses the following commits:
>> 
>> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
>> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation
>> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
>> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
>> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.
>
> CoreyAshford has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stubGenerator_ppc.cpp: fix typo (omitted 'the')

I already had the feeling that unrolling the large loop was not beneficial. Thanks and thumps up from my side!

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

Marked as reviewed by mdoerr (Reviewer).

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

From jlahoda at openjdk.java.net  Thu Nov  5 11:08:18 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 5 Nov 2020 11:08:18 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v10]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <0RHAqKvLjL4Y2yvmClOLoPrcEfdYyWid4BR-ntTWQ78=.e91baacb-444b-4cd1-89d1-8cb26f3de56f@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing typo.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/703/files
  - new: https://git.openjdk.java.net/jdk/pull/703/files/370031f0..097ae3c1

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

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

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

From kravikumar at openjdk.java.net  Thu Nov  5 11:31:57 2020
From: kravikumar at openjdk.java.net (Kiran Sidhartha Ravikumar)
Date: Thu, 5 Nov 2020 11:31:57 GMT
Subject: Integrated: 8255226: (tz) Upgrade time-zone data to tzdata2020d
In-Reply-To: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
References: <K6LRjgx7LdkjcwuXmCVzlEbK-PqdMTFutjmDhtLWZ6A=.23ec0878-8518-4f28-9778-3323c96333b4@github.com>
Message-ID: <4rYwfKPXXlBxc5V7Ij0-lLBvxPDl7qYtyFtJnPTbL5A=.a3d49bd2-db07-4048-bdce-6bbf378ad9c3@github.com>

On Mon, 2 Nov 2020 16:29:07 GMT, Kiran Sidhartha Ravikumar <kravikumar at openjdk.org> wrote:

> Hi Guys,
> 
> Please review the integration of tzdata2020d to JDK.
> 
> Details regarding the change can be viewed at - https://mm.icann.org/pipermail/tz-announce/2020-October/000062.html
> Bug: https://bugs.openjdk.java.net/browse/JDK-8255226
> 
> TestZoneInfo310.java test failure is addressed along with it. The last rule affects "Asia/Gaza" and "Asia/Hebron" and therefore excluded from the test.
> 
> Regression Tests pass along with JCK.
> 
> Please let me know if the changes are good to push.
> 
> Thanks,
> Kiran

This pull request has now been integrated.

Changeset: b65ff60a
Author:    Kiran Sidhartha Ravikumar <kravikumar at openjdk.org>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b65ff60a
Stats:     61 lines in 4 files changed: 38 ins; 2 del; 21 mod

8255226: (tz) Upgrade time-zone data to tzdata2020d

Reviewed-by: naoto

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

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

From jvernee at openjdk.java.net  Thu Nov  5 12:01:57 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 5 Nov 2020 12:01:57 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and ranges
In-Reply-To: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
Message-ID: <qzpN0G6np5h6PjFv9rqj9-_Bp7zzHAstypf81kQyNT0=.2a16fbb5-533c-4045-9a07-f70a6a26d617@github.com>

On Mon, 2 Nov 2020 10:47:18 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> This change add 3 new methods in Objects:
> 
> public static long checkIndex(long index, long length)
> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
> public static long checkFromIndexSize(long fromIndex, long size, long length)
> 
> This mirrors the int utility methods that were added by JDK-8135248
> with the same motivations.
> 
> As is the case with the int checkIndex(), the long checkIndex() method
> is JIT compiled as an intrinsic. It allows the JIT to compile
> checkIndex to an unsigned comparison and properly recognize it as
> a range check that then becomes a candidate for the existing range check
> optimizations. This has proven to be important for panama's
> MemorySegment API and a prototype of this change (with some extra c2
> improvements) showed that panama micro benchmark results improve
> significantly.
> 
> This change includes:
> 
> - the API change
> - the C2 intrinsic
> - tests for the API and the C2 intrinsic
> 
> This is a joint work with Paul who reviewed and reworked the API change
> and filled the CSR.

Hi Roland, Paul. Thank you for tackling this! We have to jump through quite a few hoops in the implementation of the foreign memory access API in order to leverage the intrinsification of int-based index checks, and even then we are not covering the cases where the numbers are larger than ints. Looking forward to being able to remove those hacks!

Although I'm not a 'Reviewer', I've done a pass over the code and left some inline comments that I hope you find useful.

src/hotspot/share/opto/graphKit.hpp line 109:

> 107:     if (bt == T_INT) {
> 108:       assert((jlong)(jint)con == con, "not an int");
> 109:       return intcon((jint) con);

Could also use `checked_cast` here (from globalDefinitions.hpp), which does a similar check.
Suggestion:

      return intcon(checked_cast<jint>(con));

src/hotspot/share/opto/graphKit.hpp line 111:

> 109:       return intcon((jint) con);
> 110:     }
> 111:     return longcon(con);

This ends up defaulting to longcon for any basic type that is not T_INT. Maybe it's nice to have an assert here?
Suggestion:

    assert(bt == T_LONG, "basic type not an int or long");
    return longcon(con);

src/hotspot/share/opto/type.cpp line 1353:

> 1351:     jint int_hi = (jint)hi;
> 1352:     assert(((jlong)int_lo) == lo && ((jlong)int_hi) == hi, "bounds are not ints");
> 1353:     return TypeInt::make(int_lo, int_hi, w);

checked_cast could also be used here.
Suggestion:

    return TypeInt::make(checked_cast<jint>(lo), checked_cast<jint>(hi), w);

src/java.base/share/classes/java/lang/IndexOutOfBoundsException.java line 83:

> 81:      */
> 82:     public IndexOutOfBoundsException(long index) {
> 83:         super("Index out of range: " + index);

For consistency with the class name:
Suggestion:

        super("Index out of bounds: " + index);

test/jdk/java/util/Objects/CheckLongIndex.java line 94:

> 92:         long apply(long a, long b, long c);
> 93:     }
> 94: 

Seems unused?
Suggestion:

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

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

From dfuchs at openjdk.java.net  Thu Nov  5 12:38:57 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 5 Nov 2020 12:38:57 GMT
Subject: RFR: 8255214 : Unsupported 'valign' attribute for 'th' tag used
 in j.u.l.LogManager
In-Reply-To: <7m69nfdp-uy1A4Xtn1rNZsG21IbKzRuPCsW_2d-MUbU=.3d922f24-528c-4499-a420-1b5e5a8c0c8e@github.com>
References: <7m69nfdp-uy1A4Xtn1rNZsG21IbKzRuPCsW_2d-MUbU=.3d922f24-528c-4499-a420-1b5e5a8c0c8e@github.com>
Message-ID: <kF_ojK4PClh8GGFIcVgu3YRUYOPFBVmrx1wUVLAa9y0=.de946011-cd90-4acf-b84b-a963c01a8aff@github.com>

On Wed, 4 Nov 2020 21:52:56 GMT, Rahul Yadav <ryadav at openjdk.org> wrote:

> Hello,
> 
> Request to review this small change, as HTML4 support has been dropped from javadoc.
> Have replaced valign="top" with style="vertical-align:top".

LGTM Rahul. The generated javadoc looks OK too.

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

Marked as reviewed by dfuchs (Reviewer).

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

From jlahoda at openjdk.java.net  Thu Nov  5 12:45:56 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Thu, 5 Nov 2020 12:45:56 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <KtWlgWOHrf9MbXbBd_hUeQaDVmIB5BJMAiCJ2DDKKtM=.cb31d17f-07a1-4cca-b5e4-0aa4007c5a44@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
 <KtWlgWOHrf9MbXbBd_hUeQaDVmIB5BJMAiCJ2DDKKtM=.cb31d17f-07a1-4cca-b5e4-0aa4007c5a44@github.com>
Message-ID: <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com>

On Wed, 4 Nov 2020 19:40:33 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> I have read all the files. 
>> 
>> I have added a n umber of various minor non-blocking comments (no need for re-review( to fix these.  But I have a couple of comments/questions before finally giving approval.
>> There's a comment in `PreviewListWriter` about annotation members that needs too be addressed, and I wonder is RECORD and RECORD_COMPONENT need to be added into PreviewElementKind.
>
> Thanks @jonathan-gibbons for your comments! I've tried to update the code based on them, mostly in https://github.com/lahodaj/jdk/commit/743f516c660b577035cdda4510a0bb97937fd9b2 and https://github.com/lahodaj/jdk/commit/e4b02827998fc2e8f19f983aabfb3d720b03d111
> 
> A big chunk of the update is generalization of the deprecated and preview list builders and writers into a "summary" list builder and writer. These should also now handle records. For record components, those are a little tricky, as (AFAIK) can't currently have deprecation/preview-ness for them (and hence there is no good way to test any support for record components in these). But the summary build and writer are looking for record components and will fail in case a record component is sent into them.

FWIW, a javadoc generated with the current version of the patch:
http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html

And a specdiff comparing it to the javadoc built from the corresponding master:
http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.specdiff.01/overview-summary.html

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

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

From james.laskey at oracle.com  Thu Nov  5 13:02:24 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 5 Nov 2020 09:02:24 -0400
Subject: RFR: JDK-8255395 Implement Enhanced Pseudo-Random Number Generators
 (CSR)
Message-ID: <A7677943-0906-48FD-9CBC-FEF2FAC71E22@oracle.com>

Please review the CSR for JEP-356 Enhanced Pseudo-Random Number Generators.

Thank you.

-- Jim

CSR: https://bugs.openjdk.java.net/browse/JDK-8255395 <https://bugs.openjdk.java.net/browse/JDK-8255395>
JBS: https://bugs.openjdk.java.net/browse/JDK-8248862 <https://bugs.openjdk.java.net/browse/JDK-8248862>
JEP: http://openjdk.java.net/jeps/356 <http://openjdk.java.net/jeps/356>


From chegar at openjdk.java.net  Thu Nov  5 13:55:56 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 5 Nov 2020 13:55:56 GMT
Subject: RFR: 8254354: Add a withInvokeExactBehavior() VarHandle
 combinator [v12]
In-Reply-To: <th7IW9wqkBXxmedkRXzI7BH5TGmOVJDiPs_b9Fc2Okc=.66796688-a2c7-40d3-92ff-54093f40b2c6@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <th7IW9wqkBXxmedkRXzI7BH5TGmOVJDiPs_b9Fc2Okc=.66796688-a2c7-40d3-92ff-54093f40b2c6@github.com>
Message-ID: <5HSMNj9VfLJfxuLBY1WzdCdwxeW6naCfHYM18ZkX0sE=.4fc0aa57-df77-421f-a6c9-3025b9368b43@github.com>

On Mon, 2 Nov 2020 11:22:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
>> 
>> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
>> 
>> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
>> 
>> Thanks,
>> Jorn
>> 
>> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   s/an arity/and arity

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 1600:

> 1598:      * If this VarHandle already has invoke-exact behavior this VarHandle is returned.
> 1599:      * @apiNote
> 1600:      * Invoke-exact behavior guarantees that that upon invocation of an access mode method

minor typo "that that"

src/java.base/share/classes/java/lang/invoke/VarHandle.java line 1603:

> 1601:      * the types and arity of the arguments must match the {@link #accessModeType(AccessMode) access mode type},
> 1602:      * otherwise a {@link WrongMethodTypeException} is thrown.
> 1603:      *

While not strictly necessary, the pedantic part to me likes to see assertions like this in the spec:

"Invoking `hasInvokeExactBehavior` on the returned VarHandle is guaranteed to return true."  And conversely, for withInvokeBehavior.

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

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

From hshi at openjdk.java.net  Thu Nov  5 14:03:57 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Thu, 5 Nov 2020 14:03:57 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?=
In-Reply-To: <6914QI9MySYQ4-Lpt_OIzMBbyFGRTYnPTLGJpIfBdQI=.57041221-95ea-44eb-90a6-57789597f741@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <6914QI9MySYQ4-Lpt_OIzMBbyFGRTYnPTLGJpIfBdQI=.57041221-95ea-44eb-90a6-57789597f741@github.com>
Message-ID: <gvuR6l9OtyIHc64XBnlOv004yDphJERj5nFQRqQYYAQ=.27a8baad-b297-46cb-9f11-ed4d90d34297@github.com>

On Thu, 5 Nov 2020 09:02:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> ?AccessorImpl object
>> 
>> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
>> 
>> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
>> 
>> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.
>
> src/java.base/share/classes/jdk/internal/reflect/NativeMethodAccessorImpl.java line 80:
> 
>> 78:                 succ = true;
>> 79:             } finally {
>> 80:                 if (succ == false) {
> 
> Why `succ` variable, if you can just `catch (Throwable e)` and restore the `accessorGenerated`?

Good suggest! Will update.

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

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

From hshi at openjdk.java.net  Thu Nov  5 14:26:57 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Thu, 5 Nov 2020 14:26:57 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?=
In-Reply-To: <6914QI9MySYQ4-Lpt_OIzMBbyFGRTYnPTLGJpIfBdQI=.57041221-95ea-44eb-90a6-57789597f741@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <6914QI9MySYQ4-Lpt_OIzMBbyFGRTYnPTLGJpIfBdQI=.57041221-95ea-44eb-90a6-57789597f741@github.com>
Message-ID: <3vz_p8-E5f6x5NmxZ8eh0PT6oT2bw7fhWG1PeXemECE=.8833f45d-f835-4e54-bf82-126cf57f1565@github.com>

On Thu, 5 Nov 2020 09:05:55 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> ?AccessorImpl object
>> 
>> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
>> 
>> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
>> 
>> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.
>
> src/java.base/share/classes/jdk/internal/reflect/NativeMethodAccessorImpl.java line 66:
> 
>> 64:                 && !method.getDeclaringClass().isHidden()
>> 65:                 && !ReflectUtil.isVMAnonymousClass(method.getDeclaringClass())
>> 66:                 && ACCESSOR_GENERATED.compareAndSet(this, false, true)) {
> 
> As the micro-optimization, checking that `accessor_generated` is `false` before attempting a (potentially contended) CAS might fit better. (See https://en.wikipedia.org/wiki/Test_and_test-and-set).

Agree this could benefit performance. Grep jdk codes (grep -R  compareAndSet *), not found codes with test and test-and-set pattern.

compareAndSet is intrinsic and maybe it's better let runtime/compiler generate Test_and_test-and-set code sequence to solve all compareAndSet operations.

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

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

From ryadav at openjdk.java.net  Thu Nov  5 14:38:55 2020
From: ryadav at openjdk.java.net (Rahul Yadav)
Date: Thu, 5 Nov 2020 14:38:55 GMT
Subject: Integrated: 8255214: Unsupported 'valign' attribute for 'th' tag used
 in j.u.l.LogManager
In-Reply-To: <7m69nfdp-uy1A4Xtn1rNZsG21IbKzRuPCsW_2d-MUbU=.3d922f24-528c-4499-a420-1b5e5a8c0c8e@github.com>
References: <7m69nfdp-uy1A4Xtn1rNZsG21IbKzRuPCsW_2d-MUbU=.3d922f24-528c-4499-a420-1b5e5a8c0c8e@github.com>
Message-ID: <VMUiQUt71AHT-x9aBbHyJhP38WBjblaglc4b2BS4HJI=.587f7f71-4036-48ab-ad8e-3469e624dc76@github.com>

On Wed, 4 Nov 2020 21:52:56 GMT, Rahul Yadav <ryadav at openjdk.org> wrote:

> Hello,
> 
> Request to review this small change, as HTML4 support has been dropped from javadoc.
> Have replaced valign="top" with style="vertical-align:top".

This pull request has now been integrated.

Changeset: 867a484d
Author:    Rahul Yadav <ryadav at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/867a484d
Stats:     5 lines in 1 file changed: 0 ins; 0 del; 5 mod

8255214: Unsupported 'valign' attribute for 'th' tag used in j.u.l.LogManager

Reviewed-by: mchung, dfuchs

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

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

From alanb at openjdk.java.net  Thu Nov  5 15:02:57 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 5 Nov 2020 15:02:57 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?=
In-Reply-To: <6914QI9MySYQ4-Lpt_OIzMBbyFGRTYnPTLGJpIfBdQI=.57041221-95ea-44eb-90a6-57789597f741@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <6914QI9MySYQ4-Lpt_OIzMBbyFGRTYnPTLGJpIfBdQI=.57041221-95ea-44eb-90a6-57789597f741@github.com>
Message-ID: <wllRvEUkKyTEFAmShdMQsLf5yMaL7TUIiS_SEDPptE0=.2042cc3b-8bde-4229-b198-76485f0647f6@github.com>

On Thu, 5 Nov 2020 09:07:13 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> ?AccessorImpl object
>> 
>> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
>> 
>> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
>> 
>> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.
>
> I do wonder if it makes sense to handle triple-state `int` here: "not yet generated", "generated", "in error"? So that we don't try to generate the accessor over and over again when it is in error?

If we are changing NativeMethodAccessorImpl.invoke then we should probably do NativeConstructorAccessorImpl.newInstance at the same time. Also wondering if we should, while in the area, add "return acc.invoke(obj, args)" after setting the delegate so that it invokes the newly generated accessor.

Are there resource or other cases that you have observed where generateMethod fails and then succeeds in a subsequent call?

@cl4es Do you know of any startup tests that might be sensitive to the eager creating of a VarHandle?

I agree with @shipilev to test before the CAS.

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

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

From roland at openjdk.java.net  Thu Nov  5 15:47:31 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 5 Nov 2020 15:47:31 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v2]
In-Reply-To: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
Message-ID: <nzsF9Y2uu_CnCMbvedurT-g6us-65wC-n1VDDHr_KhY=.632433d8-8db2-4ac7-872d-095f6b63cc63@github.com>

> This change add 3 new methods in Objects:
> 
> public static long checkIndex(long index, long length)
> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
> public static long checkFromIndexSize(long fromIndex, long size, long length)
> 
> This mirrors the int utility methods that were added by JDK-8135248
> with the same motivations.
> 
> As is the case with the int checkIndex(), the long checkIndex() method
> is JIT compiled as an intrinsic. It allows the JIT to compile
> checkIndex to an unsigned comparison and properly recognize it as
> a range check that then becomes a candidate for the existing range check
> optimizations. This has proven to be important for panama's
> MemorySegment API and a prototype of this change (with some extra c2
> improvements) showed that panama micro benchmark results improve
> significantly.
> 
> This change includes:
> 
> - the API change
> - the C2 intrinsic
> - tests for the API and the C2 intrinsic
> 
> This is a joint work with Paul who reviewed and reworked the API change
> and filled the CSR.

Roland Westrelin has updated the pull request with a new target base 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:

 - Jorn's comments
 - Update headers and add intrinsic to Graal test ignore list
 - move compiler test and add bug to test
 - non x86_64 arch support
 - c2 test case
 - intrinsic
 - Use overloads of method names.
   
   Simplify internally to avoid overload resolution
   issues, leverging List<Number> for the exception
   mapper.
 - Vladimir's comments
 - checkLongIndex

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1003/files
  - new: https://git.openjdk.java.net/jdk/pull/1003/files/74df12d3..b47184ac

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

  Stats: 11784 lines in 698 files changed: 6370 ins; 3584 del; 1830 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1003.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1003/head:pull/1003

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

From roland at openjdk.java.net  Thu Nov  5 15:47:32 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Thu, 5 Nov 2020 15:47:32 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v2]
In-Reply-To: <qzpN0G6np5h6PjFv9rqj9-_Bp7zzHAstypf81kQyNT0=.2a16fbb5-533c-4045-9a07-f70a6a26d617@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
 <qzpN0G6np5h6PjFv9rqj9-_Bp7zzHAstypf81kQyNT0=.2a16fbb5-533c-4045-9a07-f70a6a26d617@github.com>
Message-ID: <VO-4I5OBKL2rNREZRiOntdegczhOnsyKHCfEUQfCw90=.f2f04328-1b4f-4275-8bbc-dbb63f93f297@github.com>

On Thu, 5 Nov 2020 11:58:43 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Although I'm not a 'Reviewer', I've done a pass over the code and left some inline comments that I hope you find useful.

Thanks for the review! All suggestions (except the exception message one that I commented on) look good to me. I applied them.

> src/java.base/share/classes/java/lang/IndexOutOfBoundsException.java line 83:
> 
>> 81:      */
>> 82:     public IndexOutOfBoundsException(long index) {
>> 83:         super("Index out of range: " + index);
> 
> For consistency with the class name:
> Suggestion:
> 
>         super("Index out of bounds: " + index);

Not sure about that one as it's a copy of the message from IndexOutOfBoundsException(int index). Both would need to be changed for consistency.

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

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

From redestad at openjdk.java.net  Thu Nov  5 16:00:59 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 5 Nov 2020 16:00:59 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?=
In-Reply-To: <wllRvEUkKyTEFAmShdMQsLf5yMaL7TUIiS_SEDPptE0=.2042cc3b-8bde-4229-b198-76485f0647f6@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <6914QI9MySYQ4-Lpt_OIzMBbyFGRTYnPTLGJpIfBdQI=.57041221-95ea-44eb-90a6-57789597f741@github.com>
 <wllRvEUkKyTEFAmShdMQsLf5yMaL7TUIiS_SEDPptE0=.2042cc3b-8bde-4229-b198-76485f0647f6@github.com>
Message-ID: <DJyBxF4_XzxNJruviNuVRMFJaW_estPmZ8s4Ws1kSVk=.a3e15928-b60d-43a9-99ea-bca5aa633062@github.com>

On Thu, 5 Nov 2020 14:59:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I do wonder if it makes sense to handle triple-state `int` here: "not yet generated", "generated", "in error"? So that we don't try to generate the accessor over and over again when it is in error?
>
> If we are changing NativeMethodAccessorImpl.invoke then we should probably do NativeConstructorAccessorImpl.newInstance at the same time. Also wondering if we should, while in the area, add "return acc.invoke(obj, args)" after setting the delegate so that it invokes the newly generated accessor.
> 
> Are there resource or other cases that you have observed where generateMethod fails and then succeeds in a subsequent call?
> 
> @cl4es Do you know of any startup tests that might be sensitive to the eager creating of a VarHandle?
> 
> I agree with @shipilev to test before the CAS.

@AlanBateman I had a look and it seems unlikely the eager creation in this `<clinit>` will matter. I can find `NativeMethodAccessorImpl` in the startup profiles only for netty and larger apps, which often already initialize some `VarHandle` or are large enough that the initialization overhead will be lost in the noise.

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

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

From rriggs at openjdk.java.net  Thu Nov  5 16:11:55 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 Nov 2020 16:11:55 GMT
Subject: RFR: 8247781: Day periods support [v3]
In-Reply-To: <GLJiZaszK-Ut5Ylcw7XH5fZlSdthxIsntMr6HenWf6c=.d16b1861-d000-4338-adef-80d5cd82b29f@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <GLJiZaszK-Ut5Ylcw7XH5fZlSdthxIsntMr6HenWf6c=.d16b1861-d000-4338-adef-80d5cd82b29f@github.com>
Message-ID: <7vZA6TYuo_b7Z4_4OUqCSxYAKLRBUB3F3NGqa6osA8E=.e73908ae-349c-42e1-88e5-6e30cf809bef@github.com>

On Fri, 30 Oct 2020 22:03:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed exception messages.

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/java/time/format/Parsed.java line 180:

> 178:         cloned.chrono = this.chrono;
> 179:         cloned.leapSecond = this.leapSecond;
> 180:         cloned.dayPeriod= this.dayPeriod;

Add space before "=".

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

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

From rriggs at openjdk.java.net  Thu Nov  5 16:12:03 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 5 Nov 2020 16:12:03 GMT
Subject: RFR: 8247781: Day periods support [v6]
In-Reply-To: <TvkjldizPHi6iF1jymT2C9MPbcUzV-UvQfOO0gxPVTw=.0f874012-aaf0-43c9-922b-a1f18206d591@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <TvkjldizPHi6iF1jymT2C9MPbcUzV-UvQfOO0gxPVTw=.0f874012-aaf0-43c9-922b-a1f18206d591@github.com>
Message-ID: <g0GUXhc7FlezDMeKtmuRgCVljwN6_wrb0CjWv7Xc1Dc=.d6fab1c5-4755-420e-9abf-018c3b4ab0bb@github.com>

On Wed, 4 Nov 2020 22:13:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'master' into dayperiod
>  - Change based on CSR change.
>  - Fixed TCK test failures, added the new pattern char description in DateTimeFormatter
>  - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516147298
>  - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516123190
>  - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r516138455
>  - Fixed exception messages.
>  - Addressed the following comments:
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515003422
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515005296
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515008862
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515030268
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515030880
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515032002
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515036803
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515037626
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515038069
>    - https://github.com/openjdk/jdk/pull/938#discussion_r515039056
>  - 8247781: Day periods support

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1479:

> 1477:      * for it in the formatter locale is from 21:00 to 06:00, then {@code HOUR_OF_DAY}
> 1478:      * is set to '1' and {@code MINUTE_OF_HOUR} set to '30'. If {@code AMPM_OF_DAY} exists
> 1479:      * and no {@code HOUR_OF_DAY} is resolved, the parsed day period takes the precedence.

"the precedence" -> "precedence"

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

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

From jvernee at openjdk.java.net  Thu Nov  5 16:47:56 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 5 Nov 2020 16:47:56 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v2]
In-Reply-To: <VO-4I5OBKL2rNREZRiOntdegczhOnsyKHCfEUQfCw90=.f2f04328-1b4f-4275-8bbc-dbb63f93f297@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
 <qzpN0G6np5h6PjFv9rqj9-_Bp7zzHAstypf81kQyNT0=.2a16fbb5-533c-4045-9a07-f70a6a26d617@github.com>
 <VO-4I5OBKL2rNREZRiOntdegczhOnsyKHCfEUQfCw90=.f2f04328-1b4f-4275-8bbc-dbb63f93f297@github.com>
Message-ID: <x9yYvCb2PnhwLCZfml95KGPBR6UdBasQXJl7hHV0bxk=.90ca46d7-1699-4fab-904b-eb557e6ae100@github.com>

On Thu, 5 Nov 2020 15:42:54 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/IndexOutOfBoundsException.java line 83:
>> 
>>> 81:      */
>>> 82:     public IndexOutOfBoundsException(long index) {
>>> 83:         super("Index out of range: " + index);
>> 
>> For consistency with the class name:
>> Suggestion:
>> 
>>         super("Index out of bounds: " + index);
>
> Not sure about that one as it's a copy of the message from IndexOutOfBoundsException(int index). Both would need to be changed for consistency.

Ok, I didn't notice that it was taken from elsewhere. Never mind then.

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

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

From naoto at openjdk.java.net  Thu Nov  5 17:12:12 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Nov 2020 17:12:12 GMT
Subject: RFR: 8247781: Day periods support [v3]
In-Reply-To: <7vZA6TYuo_b7Z4_4OUqCSxYAKLRBUB3F3NGqa6osA8E=.e73908ae-349c-42e1-88e5-6e30cf809bef@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <GLJiZaszK-Ut5Ylcw7XH5fZlSdthxIsntMr6HenWf6c=.d16b1861-d000-4338-adef-80d5cd82b29f@github.com>
 <7vZA6TYuo_b7Z4_4OUqCSxYAKLRBUB3F3NGqa6osA8E=.e73908ae-349c-42e1-88e5-6e30cf809bef@github.com>
Message-ID: <OW3Gc6P5KEakWSysjH8u0KF_0O5Q9Hp3aeatm4CmPBY=.897d0daf-1a1c-440c-9031-8e2b343a5621@github.com>

On Mon, 2 Nov 2020 19:20:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed exception messages.
>
> src/java.base/share/classes/java/time/format/Parsed.java line 180:
> 
>> 178:         cloned.chrono = this.chrono;
>> 179:         cloned.leapSecond = this.leapSecond;
>> 180:         cloned.dayPeriod= this.dayPeriod;
> 
> Add space before "=".

Fixed.

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

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

From naoto at openjdk.java.net  Thu Nov  5 17:12:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Nov 2020 17:12:11 GMT
Subject: RFR: 8247781: Day periods support [v7]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Fixed typo/grammatical error.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/4aa5b197..b0649899

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

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

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

From naoto at openjdk.java.net  Thu Nov  5 17:12:14 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Nov 2020 17:12:14 GMT
Subject: RFR: 8247781: Day periods support [v7]
In-Reply-To: <g0GUXhc7FlezDMeKtmuRgCVljwN6_wrb0CjWv7Xc1Dc=.d6fab1c5-4755-420e-9abf-018c3b4ab0bb@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <TvkjldizPHi6iF1jymT2C9MPbcUzV-UvQfOO0gxPVTw=.0f874012-aaf0-43c9-922b-a1f18206d591@github.com>
 <g0GUXhc7FlezDMeKtmuRgCVljwN6_wrb0CjWv7Xc1Dc=.d6fab1c5-4755-420e-9abf-018c3b4ab0bb@github.com>
Message-ID: <LPjtLYCQS_oOrfZxxbSdtfVgSJ9UBatJUnQ8izpW40I=.fcf315dc-f66b-4f33-bc6d-66e2222915b3@github.com>

On Thu, 5 Nov 2020 16:07:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed typo/grammatical error.
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1479:
> 
>> 1477:      * for it in the formatter locale is from 21:00 to 06:00, then {@code HOUR_OF_DAY}
>> 1478:      * is set to '1' and {@code MINUTE_OF_HOUR} set to '30'. If {@code AMPM_OF_DAY} exists
>> 1479:      * and no {@code HOUR_OF_DAY} is resolved, the parsed day period takes the precedence.
> 
> "the precedence" -> "precedence"

Fixed.

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

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

From mcimadamore at openjdk.java.net  Thu Nov  5 17:14:16 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 5 Nov 2020 17:14:16 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v22]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <ZWF7DHS6AGr90BoY-ASpDvze6Zivwv51UpyP_jf1kvA=.16432297-ea9b-47e5-b295-e71ac807d7d8@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:

 - Fix post-merge issues caused by 8219014
 - Merge branch 'master' into 8254162
 - Addess remaining feedback from @AlanBateman and @mrserb
 - Address comments from @AlanBateman
 - Merge branch 'master' into 8254162
 - Fix issues with derived buffers and IO operations
 - More 32-bit fixes for TestLayouts
 - * Add final to MappedByteBuffer::SCOPED_MEMORY_ACCESS field
   * Tweak TestLayouts to make it 32-bit friendly after recent MemoryLayouts tweaks
 - Remove TestMismatch from 32-bit problem list
 - Merge branch 'master' into 8254162
 - ... and 19 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...02f9e251

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

Changes: https://git.openjdk.java.net/jdk/pull/548/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=21
  Stats: 7608 lines in 80 files changed: 4859 ins; 1545 del; 1204 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

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

From joehw at openjdk.java.net  Thu Nov  5 17:21:01 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 5 Nov 2020 17:21:01 GMT
Subject: RFR: 8247781: Day periods support [v7]
In-Reply-To: <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
Message-ID: <kvy8Rd-azX7Uaso_x_A5dAl1CZw_NDe3UxrZ_UXlmoA=.5d329b35-4684-4264-bb29-46822fd0d482@github.com>

On Thu, 5 Nov 2020 17:12:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo/grammatical error.

Marked as reviewed by joehw (Reviewer).

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

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

From smarks at openjdk.java.net  Thu Nov  5 17:26:02 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 5 Nov 2020 17:26:02 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <YwAlhIiyxluEDXPN2kR0L--dq5Bej4YyiT5DSrnMhXA=.819a3617-42d1-42c1-94b2-bd780f51cb72@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <YwAlhIiyxluEDXPN2kR0L--dq5Bej4YyiT5DSrnMhXA=.819a3617-42d1-42c1-94b2-bd780f51cb72@github.com>
Message-ID: <W7dMAjt2P20DEq_BvlwdKFsS-vr0p4Q-_tM3KjdSSio=.6f774b01-1066-48cc-9366-39e06baae32e@github.com>

On Wed, 4 Nov 2020 09:46:32 GMT, Zheka Kozlov <github.com+761899+orionll at openjdk.org> wrote:

>> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
>> 
>> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
>> 
>> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
>> 
>> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 240:
> 
>> 238:     static <E> List<E> listFromTrustedArrayNullsAllowed(Object... input) {
>> 239:         if (input.length == 0) {
>> 240:             return (List<E>) EMPTY_LIST;
> 
> If we return a `ListN` here, does this mean that `Stream.of().toList().contains(null)` will throw an NPE? But this is incorrect because `toList()` returns a null-tolerant List.

Yes, good point, we might need to have a null-tolerant empty list.

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

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

From neliasso at openjdk.java.net  Thu Nov  5 17:28:06 2020
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Thu, 5 Nov 2020 17:28:06 GMT
Subject: RFR: 8255964: Add jcmd Thread.print to jtreg timeout handler
Message-ID: <DsUVGVtRjQYJjXik8iSra_siW4L2QXZrwjMG9zhBAJY=.2d637062-34c5-4c5e-b7ed-2d4708f16221@github.com>

This patch adds jcmd Thread.print to the jtreg timeout handler.

Please review.

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

Commit messages:
 - Add jcmd thread.print to timeout handler

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

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

From smarks at openjdk.java.net  Thu Nov  5 17:30:00 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 5 Nov 2020 17:30:00 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <bUKuBU0ScUvhnCa-rUjJDUCPUfcPmS-OqMXyTSBsUeU=.2430a5a0-076e-4f16-9d1d-0dfa49faa99d@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <bUKuBU0ScUvhnCa-rUjJDUCPUfcPmS-OqMXyTSBsUeU=.2430a5a0-076e-4f16-9d1d-0dfa49faa99d@github.com>
Message-ID: <4CY9WKRujRFgx526Z2joGTNdI4OGIJUI9omHgMnhReg=.8bf6e1d5-8ba9-4f7c-80bf-8adde581a9f6@github.com>

On Wed, 4 Nov 2020 23:03:02 GMT, Pa?lo Ebermann <github.com+645859+ePaul at openjdk.org> wrote:

>> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
>> 
>> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
>> 
>> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
>> 
>> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 199:
> 
>> 197:      * safely reused as the List's internal storage, avoiding a defensive copy. Declared
>> 198:      * with Object... instead of E... as the parameter type so that varargs calls don't
>> 199:      * accidentally create an array of type other than Object[].
> 
> Why would that be a problem? If the resulting list is immutable, then the actual array type doesn't really matter, right?

It's an implementation invariant that the internal array be Object[]. Having it be something other than Object[] can lead to subtle bugs. See [JDK-6260652](https://bugs.openjdk.java.net/browse/JDK-6260652) for example.

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

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

From simon at dancingcloudservices.com  Thu Nov  5 17:40:44 2020
From: simon at dancingcloudservices.com (Simon Roberts)
Date: Thu, 5 Nov 2020 10:40:44 -0700
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <4CY9WKRujRFgx526Z2joGTNdI4OGIJUI9omHgMnhReg=.8bf6e1d5-8ba9-4f7c-80bf-8adde581a9f6@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <bUKuBU0ScUvhnCa-rUjJDUCPUfcPmS-OqMXyTSBsUeU=.2430a5a0-076e-4f16-9d1d-0dfa49faa99d@github.com>
 <4CY9WKRujRFgx526Z2joGTNdI4OGIJUI9omHgMnhReg=.8bf6e1d5-8ba9-4f7c-80bf-8adde581a9f6@github.com>
Message-ID: <CADsQA7hbZZdcDsVX1csqYJwi8Nnv-vxLbcN2gc+W+of0+-dAKA@mail.gmail.com>

At the risk of a can of worms, or at least of raising something that has
long since been discussed and rejected...

This discussion of unmodifiable lists brings me back to the thought that
there would be good client-side reasons for inserting an UnmodifiableList
interface as a parent of LIst, not least because all our unmodifiable
variants from the Collections.unmodifiableList proxy onward fail the Liskov
substitution test for actually "being contract-fulfilling Lists".

Is this something that has been considered and rejected? (If so, is it easy
to point me at the discussion, as I expect I'd find it fascinating). Is it
worth considering, might it have some merit, or merely horrible
unforeseen-by-me consequences to the implementation?

Cheers,
Simon



On Thu, Nov 5, 2020 at 10:30 AM Stuart Marks <smarks at openjdk.java.net>
wrote:

> On Wed, 4 Nov 2020 23:03:02 GMT, Pa?lo Ebermann <github.com+
> 645859+ePaul at openjdk.org> wrote:
>
> >> This change introduces a new terminal operation on Stream. This looks
> like a convenience method for Stream.collect(Collectors.toList()) or
> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
> method directly on Stream enables it to do what can't easily by done by a
> Collector. In particular, it allows the stream to deposit results directly
> into a destination array (even in parallel) and have this array be wrapped
> in an unmodifiable List without copying.
> >>
> >> In the past we've kept most things from the Collections Framework as
> implementations of Collector, not directly on Stream, whereas only
> fundamental things (like toArray) appear directly on Stream. This is true
> of most Collections, but it does seem that List is special. It can be a
> thin wrapper around an array; it can handle generics better than arrays;
> and unlike an array, it can be made unmodifiable (shallowly immutable); and
> it can be value-based. See John Rose's comments in the bug report:
> >>
> >>
> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
> >>
> >> This operation is null-tolerant, which matches the rest of Streams.
> This isn't specified, though; a general statement about null handling in
> Streams is probably warranted at some point.
> >>
> >> Finally, this method is indeed quite convenient (if the caller can deal
> with what this operation returns), as collecting into a List is the most
> common stream terminal operation.
> >
> > src/java.base/share/classes/java/util/ImmutableCollections.java line 199:
> >
> >> 197:      * safely reused as the List's internal storage, avoiding a
> defensive copy. Declared
> >> 198:      * with Object... instead of E... as the parameter type so
> that varargs calls don't
> >> 199:      * accidentally create an array of type other than Object[].
> >
> > Why would that be a problem? If the resulting list is immutable, then
> the actual array type doesn't really matter, right?
>
> It's an implementation invariant that the internal array be Object[].
> Having it be something other than Object[] can lead to subtle bugs. See
> [JDK-6260652](https://bugs.openjdk.java.net/browse/JDK-6260652) for
> example.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/1026
>


-- 
Simon Roberts
(303) 249 3613

From alex.buckley at oracle.com  Thu Nov  5 18:11:00 2020
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 5 Nov 2020 10:11:00 -0800
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
 <KtWlgWOHrf9MbXbBd_hUeQaDVmIB5BJMAiCJ2DDKKtM=.cb31d17f-07a1-4cca-b5e4-0aa4007c5a44@github.com>
 <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com>
Message-ID: <a3e944fd-0344-a1a0-3597-34e80ccf045a@oracle.com>

On 11/5/2020 4:45 AM, Jan Lahoda wrote:
> FWIW, a javadoc generated with the current version of the patch:
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html

Allow me to draw people's attention to the PREVIEW link in the banner of 
the generated javadoc. It shows all the preview APIs in the release on 
one page. This is very helpful for understanding the surface area of a 
preview feature.

For example, with Sealed Classes being the only preview feature likely 
to target JDK 16, the PREVIEW page shows that the feature's API is 
solely about reflection. It's clear that Sealed Classes do not 
introduce, say, a java.lang.Sealed class analogous to the 
java.lang.Record class introduced by Records in JDK 14/15 (and which 
would have appeared on the PREVIEW page had it existed then).

Alex

From herrick at openjdk.java.net  Thu Nov  5 18:18:16 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 5 Nov 2020 18:18:16 GMT
Subject: RFR: JDK-8254920: Application launched with jpackage produced
 .exe crashes JVM [v3]
In-Reply-To: <Tcn6BwsjMBJ4KTFov7i4VN7kVJasVeTEXGyguR4RVUw=.1f8c589f-0ade-447b-be0d-b5178e15752b@github.com>
References: <Tcn6BwsjMBJ4KTFov7i4VN7kVJasVeTEXGyguR4RVUw=.1f8c589f-0ade-447b-be0d-b5178e15752b@github.com>
Message-ID: <vN9F3RdqDRCqi1gjJIlSYXwIdZ0sS938xXuYvVt02-4=.e415d5c2-5e26-4aa7-952b-5a8add8b6646@github.com>

> JVM

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 three additional commits since the last revision:

 - Merge branch 'master' into jdk-8254920
 - JDK-8254920: Application launched with jpackage produced .exe crashes JVM
 - JDK-8254920: Application launched with jpackage produced .exe crashes
   JVM

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/940/files
  - new: https://git.openjdk.java.net/jdk/pull/940/files/3d83b99b..247bc2c0

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

  Stats: 14531 lines in 808 files changed: 7882 ins; 4035 del; 2614 mod
  Patch: https://git.openjdk.java.net/jdk/pull/940.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/940/head:pull/940

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

From ecki at zusammenkunft.net  Thu Nov  5 19:11:31 2020
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Thu, 5 Nov 2020 19:11:31 +0000
Subject: RFR: JDK-8255395 Implement Enhanced Pseudo-Random Number
 Generators (CSR)
In-Reply-To: <A7677943-0906-48FD-9CBC-FEF2FAC71E22@oracle.com>
References: <A7677943-0906-48FD-9CBC-FEF2FAC71E22@oracle.com>
Message-ID: <AM6PR03MB4389B82DA7E0B28DEA891F99FFEE0@AM6PR03MB4389.eurprd03.prod.outlook.com>

Hello,

Not sure if it is needed to implement a new RandumGenerator interface instead of extending SecureRandom, but the extensions and the discovery mechanism looks good.

One thing I am wondering about is if reseed() and reseed(Param) should be part of the new RandomGenerator interface as well.

BTW a lot of the random number Discovery and configuration could have been avoided when the actual implementation just would have been stronger and less blocking. The focus should be on the two old factory methods to make them return top quality, it?s hard enough to make everyone use them for the correct use case.

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: core-libs-dev <core-libs-dev-retn at openjdk.java.net> im Auftrag von Jim Laskey <james.laskey at oracle.com>
Gesendet: Thursday, November 5, 2020 2:02:24 PM
An: core-libs-dev <core-libs-dev at openjdk.java.net>
Betreff: RFR: JDK-8255395 Implement Enhanced Pseudo-Random Number Generators (CSR)

Please review the CSR for JEP-356 Enhanced Pseudo-Random Number Generators.

Thank you.

-- Jim

CSR: https://bugs.openjdk.java.net/browse/JDK-8255395 <https://bugs.openjdk.java.net/browse/JDK-8255395>
JBS: https://bugs.openjdk.java.net/browse/JDK-8248862 <https://bugs.openjdk.java.net/browse/JDK-8248862>
JEP: http://openjdk.java.net/jeps/356 <http://openjdk.java.net/jeps/356>


From psandoz at openjdk.java.net  Thu Nov  5 19:50:59 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 5 Nov 2020 19:50:59 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
Message-ID: <DRlwT77aGPTE0hAf251c2adIT-iQ8JVDLrYxLU5jYV0=.550ddb2a-9710-432b-9777-4f493fe8f7b7@github.com>

On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
> 
> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
> 
> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
> 
> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.

test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/ToListOpTest.java line 73:

> 71:     }
> 72: 
> 73:     @Test(dataProvider = "withNull:StreamTestData<Integer>", dataProviderClass = StreamTestDataProvider.class)

Given the non-default `toList()` implementation defers to the `toArray()` terminal op there is no need for this and the following tests, which are really designed to shake out the optimizations when producing and operating on arrays.

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

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

From bpb at openjdk.java.net  Thu Nov  5 19:56:03 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 5 Nov 2020 19:56:03 GMT
Subject: RFR: 8255969: Improve
 java/io/BufferedInputStream/LargeCopyWithMark.java using jtreg tags
Message-ID: <-P8McZTovaFNg3tR_2x6eXGKneuzWiclxVduu_wABKQ=.e9a970d8-3088-43fc-a7e5-af94aa73cf51@github.com>

Please review this change which would replace the use of a system property and a child process with updated jtreg tags.

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

Commit messages:
 - 8255969: Improve java/io/BufferedInputStream/LargeCopyWithMark.java using jtreg tags

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

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

From mcimadamore at openjdk.java.net  Thu Nov  5 21:26:16 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 5 Nov 2020 21:26:16 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:

 - Merge branch '8254162' into 8254231_linker
 - Fix post-merge issues caused by 8219014
 - Merge branch 'master' into 8254162
 - Addess remaining feedback from @AlanBateman and @mrserb
 - Address comments from @AlanBateman
 - Fix typo in upcall helper for aarch64
 - Merge branch '8254162' into 8254231_linker
 - Merge branch 'master' into 8254162
 - Fix issues with derived buffers and IO operations
 - More 32-bit fixes for TestLayouts
 - ... and 54 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...b38afb3f

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

Changes: https://git.openjdk.java.net/jdk/pull/634/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=14
  Stats: 75292 lines in 271 files changed: 72365 ins; 1626 del; 1301 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

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

From michael.edgar at gmail.com  Thu Nov  5 21:35:15 2020
From: michael.edgar at gmail.com (Michael Edgar)
Date: Thu, 5 Nov 2020 16:35:15 -0500
Subject: Filtered XMLStreamReader Exceptions (java.xml)
In-Reply-To: <1bef2d11-0e3f-944a-4fd7-7b1a8524f9a1@oracle.com>
References: <CAJ9fJk4dF8H1M23xv6L2cacB8epxg1WOsPsX7sRZ=MrAS23aXw@mail.gmail.com>
 <1bef2d11-0e3f-944a-4fd7-7b1a8524f9a1@oracle.com>
Message-ID: <CAJ9fJk7DbWjAtDJj6-pyny1+o87SA2QNUjCKS55-Wv+k8LtNGw@mail.gmail.com>

The bug for this issue was accepted: JDK-8255918. I have made the change
that I suggested in my original email and tested, but have not yet opened a
pull request. Please let me know what (if anything) needs to occur for the
CSR process due to the method signature change (added `throws`).

Thank you,
Mike


On Wed, Oct 28, 2020 at 12:52 PM Joe Wang <huizhe.wang at oracle.com> wrote:

> Hi Mike,
>
> As you said, creating a bug report would be a good start. If it involves
> a signature change, it'd need to go through a proper review (CSR) process.
>
> When you are ready to submit a bug report, please make sure to add a
> test case to illustrate the use case scenario.
>
> Thanks,
> Joe
>
> On 10/28/20 5:14 AM, Michael Edgar wrote:
> > Hi everyone,
> > I'm working on a project that makes use of the StAX API and an issue I
> have
> > encountered is that when wrapping an `XMLStreamReader` with a
> > `StreamFilter`, errors encountered in the setup are not thrown to the
> > caller. The source of the error could be any stream error that is
> triggered
> > as the `XMLStreamFilterImpl` advances to the next acceptable event.
> > Ultimately, when attempting to utilize the filtered reader, some
> secondary
> > exception will occur, but the original `Exception` is lost.
> >
> > I have not seen any other issues related specifically to this problem,
> so I
> > would like to propose removal of the try/catch in the constructor of
> > `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl` and the
> > method signature changed to declare that `XMLStreamException` is thrown.
> > The constructor is used by
> >
> `com.sun.xml.internal.stream.XMLInputFactoryImpl.createFilteredReader(XMLStreamReader,
> > StreamFilter)` which itself already declares the same exception and is an
> > implementation of the public `XMLInputFactory` interface.
> >
> > Further, the `nextTag` method of the same class has a bug where it checks
> > for `START_ELEMENT` events twice.
> >
> > I have an OCA in place and I am happy to submit a PR, but I believe that
> a
> > bug record needs to be opened in order to proceed.
> >
> > Thank you,
> > Mike
>
>

From naoto at openjdk.java.net  Thu Nov  5 21:59:57 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Nov 2020 21:59:57 GMT
Subject: RFR: 8255969: Improve
 java/io/BufferedInputStream/LargeCopyWithMark.java using jtreg tags
In-Reply-To: <-P8McZTovaFNg3tR_2x6eXGKneuzWiclxVduu_wABKQ=.e9a970d8-3088-43fc-a7e5-af94aa73cf51@github.com>
References: <-P8McZTovaFNg3tR_2x6eXGKneuzWiclxVduu_wABKQ=.e9a970d8-3088-43fc-a7e5-af94aa73cf51@github.com>
Message-ID: <_2NW3mG4yzP0BBAGZCn8agmE1PsotB470FsC7qOqrss=.7e0b4a95-a66a-4561-8d4f-967ef8c1c7b6@github.com>

On Thu, 5 Nov 2020 19:50:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this change which would replace the use of a system property and a child process with updated jtreg tags.

test/jdk/java/io/BufferedInputStream/LargeCopyWithMark.java line 29:

> 27:  * @summary BufferedInputStream calculates negative array size with large
> 28:  *          streams and mark
> 29:  * @library /test/lib

Looks like this (@library /test/lib) can be removed. Otherwise looks good.

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

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

From bpb at openjdk.java.net  Thu Nov  5 22:10:07 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 5 Nov 2020 22:10:07 GMT
Subject: RFR: 8255969: Improve
 java/io/BufferedInputStream/LargeCopyWithMark.java using jtreg tags [v2]
In-Reply-To: <-P8McZTovaFNg3tR_2x6eXGKneuzWiclxVduu_wABKQ=.e9a970d8-3088-43fc-a7e5-af94aa73cf51@github.com>
References: <-P8McZTovaFNg3tR_2x6eXGKneuzWiclxVduu_wABKQ=.e9a970d8-3088-43fc-a7e5-af94aa73cf51@github.com>
Message-ID: <8luAraZaekQG8VTQO_Mw9mwuGIc5GSAANPzSMX1wsl8=.1ed6da2f-33fb-4360-8968-d796dc8ef27a@github.com>

> Please review this change which would replace the use of a system property and a child process with updated jtreg tags.

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

  8255969: Improve java/io/BufferedInputStream/LargeCopyWithMark.java using jtreg tags

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1083/files
  - new: https://git.openjdk.java.net/jdk/pull/1083/files/bf6249eb..a3346ff9

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

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

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

From bpb at openjdk.java.net  Thu Nov  5 22:10:08 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 5 Nov 2020 22:10:08 GMT
Subject: RFR: 8255969: Improve
 java/io/BufferedInputStream/LargeCopyWithMark.java using jtreg tags [v2]
In-Reply-To: <_2NW3mG4yzP0BBAGZCn8agmE1PsotB470FsC7qOqrss=.7e0b4a95-a66a-4561-8d4f-967ef8c1c7b6@github.com>
References: <-P8McZTovaFNg3tR_2x6eXGKneuzWiclxVduu_wABKQ=.e9a970d8-3088-43fc-a7e5-af94aa73cf51@github.com>
 <_2NW3mG4yzP0BBAGZCn8agmE1PsotB470FsC7qOqrss=.7e0b4a95-a66a-4561-8d4f-967ef8c1c7b6@github.com>
Message-ID: <7t-MMXS29G4gSNfj5hd-BHXxluEvK7i5c8FCUBSf6Zw=.50dea9fb-0f4a-4fec-819b-95385c7df5df@github.com>

On Thu, 5 Nov 2020 21:53:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8255969: Improve java/io/BufferedInputStream/LargeCopyWithMark.java using jtreg tags
>
> test/jdk/java/io/BufferedInputStream/LargeCopyWithMark.java line 29:
> 
>> 27:  * @summary BufferedInputStream calculates negative array size with large
>> 28:  *          streams and mark
>> 29:  * @library /test/lib
> 
> Looks like this (@library /test/lib) can be removed. Otherwise looks good.

Yes, you are correct: fixed. Thanks.

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

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

From naoto at openjdk.java.net  Thu Nov  5 22:15:01 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 5 Nov 2020 22:15:01 GMT
Subject: RFR: 8255969: Improve
 java/io/BufferedInputStream/LargeCopyWithMark.java using jtreg tags [v2]
In-Reply-To: <8luAraZaekQG8VTQO_Mw9mwuGIc5GSAANPzSMX1wsl8=.1ed6da2f-33fb-4360-8968-d796dc8ef27a@github.com>
References: <-P8McZTovaFNg3tR_2x6eXGKneuzWiclxVduu_wABKQ=.e9a970d8-3088-43fc-a7e5-af94aa73cf51@github.com>
 <8luAraZaekQG8VTQO_Mw9mwuGIc5GSAANPzSMX1wsl8=.1ed6da2f-33fb-4360-8968-d796dc8ef27a@github.com>
Message-ID: <gfRzFLCgb6T3DzXpA_GN0vTQdX6J5suFo2a-VXv5ZRs=.9ae4a065-e55d-49cc-b4a9-3d22ac13a9ad@github.com>

On Thu, 5 Nov 2020 22:10:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this change which would replace the use of a system property and a child process with updated jtreg tags.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255969: Improve java/io/BufferedInputStream/LargeCopyWithMark.java using jtreg tags

Looks good. Thanks for fixing.

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

Marked as reviewed by naoto (Reviewer).

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

From david.holmes at oracle.com  Thu Nov  5 22:29:34 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 6 Nov 2020 08:29:34 +1000
Subject: =?UTF-8?Q?Re=3a_RFR=3a_8255883=3a_Avoid_multiple_GeneratedMethodAcc?=
 =?UTF-8?Q?essor_for_same_NativeMethod=e2=80=a6?=
In-Reply-To: <6914QI9MySYQ4-Lpt_OIzMBbyFGRTYnPTLGJpIfBdQI=.57041221-95ea-44eb-90a6-57789597f741@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <6914QI9MySYQ4-Lpt_OIzMBbyFGRTYnPTLGJpIfBdQI=.57041221-95ea-44eb-90a6-57789597f741@github.com>
Message-ID: <4fd724ae-6b3c-3a88-4df2-b415e1aabd11@oracle.com>

On 5/11/2020 7:09 pm, Aleksey Shipilev wrote:
> On Thu, 5 Nov 2020 02:52:05 GMT, Hui Shi <hshi at openjdk.org> wrote:
> 
>> ?AccessorImpl object
>>
>> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
>>
>> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
>>
>> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.
> 
> I do wonder if it makes sense to handle triple-state `int` here: "not yet generated", "generated", "in error"? So that we don't try to generate the accessor over and over again when it is in error?

You have no idea why generation failed so don't know whether a retry 
will succeed or not. Current code will retry so it would be a change in 
behaviour to declare it permanently "in error".

Cheers,
David

> src/java.base/share/classes/jdk/internal/reflect/NativeMethodAccessorImpl.java line 80:
> 
>> 78:                 succ = true;
>> 79:             } finally {
>> 80:                 if (succ == false) {
> 
> Why `succ` variable, if you can just `catch (Throwable e)` and restore the `accessorGenerated`?
> 
> src/java.base/share/classes/jdk/internal/reflect/NativeMethodAccessorImpl.java line 66:
> 
>> 64:                 && !method.getDeclaringClass().isHidden()
>> 65:                 && !ReflectUtil.isVMAnonymousClass(method.getDeclaringClass())
>> 66:                 && ACCESSOR_GENERATED.compareAndSet(this, false, true)) {
> 
> As the micro-optimization, checking that `accessor_generated` is `false` before attempting a (potentially contended) CAS might fit better. (See https://en.wikipedia.org/wiki/Test_and_test-and-set).
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1070
> 

From kizune at openjdk.java.net  Thu Nov  5 22:34:02 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Thu, 5 Nov 2020 22:34:02 GMT
Subject: RFR: JDK-8254920: Application launched with jpackage produced
 .exe crashes JVM [v3]
In-Reply-To: <vN9F3RdqDRCqi1gjJIlSYXwIdZ0sS938xXuYvVt02-4=.e415d5c2-5e26-4aa7-952b-5a8add8b6646@github.com>
References: <Tcn6BwsjMBJ4KTFov7i4VN7kVJasVeTEXGyguR4RVUw=.1f8c589f-0ade-447b-be0d-b5178e15752b@github.com>
 <vN9F3RdqDRCqi1gjJIlSYXwIdZ0sS938xXuYvVt02-4=.e415d5c2-5e26-4aa7-952b-5a8add8b6646@github.com>
Message-ID: <0bx-6bLPCqaxRTwShGE50KQuieHco-5pQVE7MsTCrto=.64f48b00-c646-4dca-b9a3-e44580a6c908@github.com>

On Thu, 5 Nov 2020 18:18:16 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JVM
>
> 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 three additional commits since the last revision:
> 
>  - Merge branch 'master' into jdk-8254920
>  - JDK-8254920: Application launched with jpackage produced .exe crashes JVM
>  - JDK-8254920: Application launched with jpackage produced .exe crashes
>    JVM

Looks good.

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

Marked as reviewed by kizune (Reviewer).

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

From scolebourne at openjdk.java.net  Thu Nov  5 23:52:02 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Thu, 5 Nov 2020 23:52:02 GMT
Subject: RFR: 8247781: Day periods support [v7]
In-Reply-To: <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
Message-ID: <JinAuJMdAgSg6_n0vPK9NpaLSGbVSuhKBUBun2-5H4Q=.9251b24d-61f5-4f3f-b489-49279c4602fb@github.com>

On Thu, 5 Nov 2020 17:12:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed typo/grammatical error.

test/jdk/java/time/tck/java/time/format/TCKDateTimeParseResolver.java line 858:

> 856:         return new Object[][]{
> 857:                 {STRICT, 0, LocalTime.of(6, 0), 0},
> 858:                 {STRICT, 1, LocalTime.of(18, 0), 1},

As mentioned in my other comment, this seems odd in STRICT mode.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5055:

> 5053:         @Override
> 5054:         public boolean format(DateTimePrintContext context, StringBuilder buf) {
> 5055:             Long value = context.getValue(MINUTE_OF_DAY);

This does not match the spec: " During formatting, the day period is obtained from {@code HOUR_OF_DAY}, and optionally {@code MINUTE_OF_HOUR} if exist"

It is possible and legal to create a Temporal that returns `HOUR_OF_DAY` and `MINUTE_OF_HOUR` but not `MINUTE_OF_DAY`. As such, this method must be changed to follow the spec.

-----

In addition, it is possible for `HOUR_OF_DAY` and `MINUTE_OF_HOUR` to be outside their normal bounds. The right behaviour would be to combine the two fields within this method, and then use mod to get the value into the range 0 to 1440 before calling `dayPeriod.include`. (While the fall back behaviour below does cover this, it would be better to do what I propose here.)

An example of this is a `TransportTime` class where the day runs from 03:00 to 27:00 each day (because trains run after midnight for no extra cost to the passenger, and it is more convenient for the operator to treat the date that way). A `TransportTime` of 26:30 should still resolve to "night1" rather than fall back to "am".

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

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

From scolebourne at openjdk.java.net  Thu Nov  5 23:51:59 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Thu, 5 Nov 2020 23:51:59 GMT
Subject: RFR: 8247781: Day periods support [v7]
In-Reply-To: <_KS-70pqQG8VavYGtbXCrOlvwfwGl6Nm-lk8SjkEDQI=.1775f0e1-4847-401a-a576-dbb93e080c90@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>
 <Tu7yq15XUzC2-z2v40tNUGHkTkYW37q7RUiop9pB4xU=.d61a3059-6929-4b45-8a16-df33469ab56b@github.com>
 <_KS-70pqQG8VavYGtbXCrOlvwfwGl6Nm-lk8SjkEDQI=.1775f0e1-4847-401a-a576-dbb93e080c90@github.com>
Message-ID: <BVGHbYN8Sp6W49GTct6d5edTJvgx9uVn688oy3VXe1U=.a1393d13-538c-4b3c-82db-e8abd30e297f@github.com>

On Mon, 2 Nov 2020 23:21:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Pulling on this a little more.
>> 
>> As the PR stands, it seems that if the user passes in text with just a day-period of "AM" they get a `LocalTime` of 06:00 but if they pass in `AMPM_OF_DAY` of "AM" the get no `LocalTime` in the result. Is that right? If so, I don't think this is sustainable.
>> 
>> Thats why I think `AMPM_OF_DAY` will have to be resolved to a dayPeriod of "am" or "pm". If dayPeriod is more precise than `AMPM_OF_DAY`, then dayPeriod can silently take precedence
>
> I implemented what you suggested here in the latest PR, but that would be a behavioral change which requires a CSR, as "AM" would be resolved to 06:00 which was not before. Do you think it would be acceptable? If so, I will reopen the CSR and describe the change. (In fact some TCK failed with this impl)

I find the whole "half way between the start and end" behaviour of day periods odd anyway, but if it is to be supported then it should be consistent as you've implemented. 

Another option I should have thought of earlier would be to simply not support the "half way between the start and end" behaviour of LDML in either dayPeriod or AM/PM. But since LDML defines it, you've implemented it, and it isn't overly harmful I think its OK to leave it in.

Would it be possible for STRICT mode to not have the "half way between the start and end" behaviour?

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

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

From dlong at openjdk.java.net  Fri Nov  6 00:02:58 2020
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 6 Nov 2020 00:02:58 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v2]
In-Reply-To: <nzsF9Y2uu_CnCMbvedurT-g6us-65wC-n1VDDHr_KhY=.632433d8-8db2-4ac7-872d-095f6b63cc63@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
 <nzsF9Y2uu_CnCMbvedurT-g6us-65wC-n1VDDHr_KhY=.632433d8-8db2-4ac7-872d-095f6b63cc63@github.com>
Message-ID: <KydsKzLVnAXutzj2ZpstlIeZsPFiK945J8PsnE0txGA=.f9645a2e-674c-46a4-8e2c-c0f416f55b1c@github.com>

On Thu, 5 Nov 2020 15:47:31 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This change add 3 new methods in Objects:
>> 
>> public static long checkIndex(long index, long length)
>> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
>> public static long checkFromIndexSize(long fromIndex, long size, long length)
>> 
>> This mirrors the int utility methods that were added by JDK-8135248
>> with the same motivations.
>> 
>> As is the case with the int checkIndex(), the long checkIndex() method
>> is JIT compiled as an intrinsic. It allows the JIT to compile
>> checkIndex to an unsigned comparison and properly recognize it as
>> a range check that then becomes a candidate for the existing range check
>> optimizations. This has proven to be important for panama's
>> MemorySegment API and a prototype of this change (with some extra c2
>> improvements) showed that panama micro benchmark results improve
>> significantly.
>> 
>> This change includes:
>> 
>> - the API change
>> - the C2 intrinsic
>> - tests for the API and the C2 intrinsic
>> 
>> This is a joint work with Paul who reviewed and reworked the API change
>> and filled the CSR.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Jorn's comments
>  - Update headers and add intrinsic to Graal test ignore list
>  - move compiler test and add bug to test
>  - non x86_64 arch support
>  - c2 test case
>  - intrinsic
>  - Use overloads of method names.
>    
>    Simplify internally to avoid overload resolution
>    issues, leverging List<Number> for the exception
>    mapper.
>  - Vladimir's comments
>  - checkLongIndex

C2 changes look good, except for new code block in inline_preconditions_checkIndex could use a comment.

src/hotspot/share/opto/library_call.cpp line 1015:

> 1013:                   Deoptimization::Action_make_not_entrant);
> 1014:   }
> 1015: 

A comment here explaining what the code below is doing would be helpful.

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

Changes requested by dlong (Reviewer).

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

From hshi at openjdk.java.net  Fri Nov  6 00:26:53 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Fri, 6 Nov 2020 00:26:53 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?=
In-Reply-To: <wllRvEUkKyTEFAmShdMQsLf5yMaL7TUIiS_SEDPptE0=.2042cc3b-8bde-4229-b198-76485f0647f6@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <6914QI9MySYQ4-Lpt_OIzMBbyFGRTYnPTLGJpIfBdQI=.57041221-95ea-44eb-90a6-57789597f741@github.com>
 <wllRvEUkKyTEFAmShdMQsLf5yMaL7TUIiS_SEDPptE0=.2042cc3b-8bde-4229-b198-76485f0647f6@github.com>
Message-ID: <1IPqXcDKyV2gwO1ro01A5-zCJB4_1A9P-GLsdaFY8GI=.750c0542-31ef-4281-bcb2-6da7a66c958b@github.com>

On Thu, 5 Nov 2020 14:59:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If we are changing NativeMethodAccessorImpl.invoke then we should probably do NativeConstructorAccessorImpl.newInstance at the same time. 

Yes, NativeConstructorAccessorImpl should also apply this change.

> Also wondering if we should, while in the area, add "return acc.invoke(obj, args)" after setting the delegate so that it invokes the newly generated accessor.
> 

Agree,  I see no harm to invoke generated method when it is aviable. 
Should leave this to another patch?

> Are there resource or other cases that you have observed where generateMethod fails and then succeeds in a subsequent call?
> 
I have not seen exception/error happen in generate method yet.  But in case it fails in some ways, try - catch - reset is added to make sure behavior is same before/after with this change.

> @cl4es Do you know of any startup tests that might be sensitive to the eager creating of a VarHandle?
> 
> I agree with @shipilev to test before the CAS.

@AlanBateman 
Thanks for you comments!

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

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

From huizhe.wang at oracle.com  Fri Nov  6 01:22:46 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 5 Nov 2020 17:22:46 -0800
Subject: Filtered XMLStreamReader Exceptions (java.xml)
In-Reply-To: <CAJ9fJk7DbWjAtDJj6-pyny1+o87SA2QNUjCKS55-Wv+k8LtNGw@mail.gmail.com>
References: <CAJ9fJk4dF8H1M23xv6L2cacB8epxg1WOsPsX7sRZ=MrAS23aXw@mail.gmail.com>
 <1bef2d11-0e3f-944a-4fd7-7b1a8524f9a1@oracle.com>
 <CAJ9fJk7DbWjAtDJj6-pyny1+o87SA2QNUjCKS55-Wv+k8LtNGw@mail.gmail.com>
Message-ID: <880cf7c4-878a-9068-646f-4dbc026f355f@oracle.com>

Hi Mike,

I saw that you are on the OCA list but not census 
<https://openjdk.java.net/census>, I therefore assumed you'd need a 
sponsor, or would you?? Let me know if I'm mistaken. If you're an 
openjdk author/committer and have a JBS account, please go ahead take 
over the bug and create a CSR. Creating a CSR is straight-forward: from 
the JBS bug, click more -> create CSR and follow the template.

You mentioned you're going to submit a PR. Are you familiar with the 
Skara process or have you already done it?

Thanks,
Joe

On 11/5/20 1:35 PM, Michael Edgar wrote:
> The bug for this issue was accepted: JDK-8255918. I have made the 
> change that I suggested in my original email and tested, but have not 
> yet opened a pull request. Please let me know what (if anything) needs 
> to occur for the CSR process due to the method signature change (added 
> `throws`).
>
> Thank you,
> Mike
>
>
> On Wed, Oct 28, 2020 at 12:52 PM Joe Wang <huizhe.wang at oracle.com 
> <mailto:huizhe.wang at oracle.com>> wrote:
>
>     Hi Mike,
>
>     As you said, creating a bug report would be a good start. If it
>     involves
>     a signature change, it'd need to go through a proper review (CSR)
>     process.
>
>     When you are ready to submit a bug report, please make sure to add a
>     test case to illustrate the use case scenario.
>
>     Thanks,
>     Joe
>
>     On 10/28/20 5:14 AM, Michael Edgar wrote:
>     > Hi everyone,
>     > I'm working on a project that makes use of the StAX API and an
>     issue I have
>     > encountered is that when wrapping an `XMLStreamReader` with a
>     > `StreamFilter`, errors encountered in the setup are not thrown
>     to the
>     > caller. The source of the error could be any stream error that
>     is triggered
>     > as the `XMLStreamFilterImpl` advances to the next acceptable event.
>     > Ultimately, when attempting to utilize the filtered reader, some
>     secondary
>     > exception will occur, but the original `Exception` is lost.
>     >
>     > I have not seen any other issues related specifically to this
>     problem, so I
>     > would like to propose removal of the try/catch in the constructor of
>     > `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl`
>     and the
>     > method signature changed to declare that `XMLStreamException` is
>     thrown.
>     > The constructor is used by
>     >
>     `com.sun.xml.internal.stream.XMLInputFactoryImpl.createFilteredReader(XMLStreamReader,
>     > StreamFilter)` which itself already declares the same exception
>     and is an
>     > implementation of the public `XMLInputFactory` interface.
>     >
>     > Further, the `nextTag` method of the same class has a bug where
>     it checks
>     > for `START_ELEMENT` events twice.
>     >
>     > I have an OCA in place and I am happy to submit a PR, but I
>     believe that a
>     > bug record needs to be opened in order to proceed.
>     >
>     > Thank you,
>     > Mike
>


From smarks at openjdk.java.net  Fri Nov  6 02:52:56 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 6 Nov 2020 02:52:56 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <DRlwT77aGPTE0hAf251c2adIT-iQ8JVDLrYxLU5jYV0=.550ddb2a-9710-432b-9777-4f493fe8f7b7@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <DRlwT77aGPTE0hAf251c2adIT-iQ8JVDLrYxLU5jYV0=.550ddb2a-9710-432b-9777-4f493fe8f7b7@github.com>
Message-ID: <hPOcNhjKwQsNYsReZ8HprLYOUhhs2KbOjMft_TQr-qI=.fc980a25-29c6-42e9-980c-529f4e009fc3@github.com>

On Thu, 5 Nov 2020 19:47:43 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
>> 
>> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
>> 
>> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
>> 
>> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.
>
> test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/ToListOpTest.java line 73:
> 
>> 71:     }
>> 72: 
>> 73:     @Test(dataProvider = "withNull:StreamTestData<Integer>", dataProviderClass = StreamTestDataProvider.class)
> 
> Given the non-default `toList()` implementation defers to the `toArray()` terminal op there is no need for this and the following tests, which are really designed to shake out the optimizations when producing and operating on arrays.

OK, I'll remove all the tests starting from here to the end of the file. I'm assuming that's the set of tests you're referring to.

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

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

From psandoz at openjdk.java.net  Fri Nov  6 02:57:56 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Fri, 6 Nov 2020 02:57:56 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <hPOcNhjKwQsNYsReZ8HprLYOUhhs2KbOjMft_TQr-qI=.fc980a25-29c6-42e9-980c-529f4e009fc3@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <DRlwT77aGPTE0hAf251c2adIT-iQ8JVDLrYxLU5jYV0=.550ddb2a-9710-432b-9777-4f493fe8f7b7@github.com>
 <hPOcNhjKwQsNYsReZ8HprLYOUhhs2KbOjMft_TQr-qI=.fc980a25-29c6-42e9-980c-529f4e009fc3@github.com>
Message-ID: <bZ0SwNu7d-FP-O9XNc3KolE5dx0Tw8YA9vRhQUh_XHg=.11069348-9be9-4c27-93de-71a9bf5301d4@github.com>

On Fri, 6 Nov 2020 02:50:29 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> test/jdk/java/util/stream/test/org/openjdk/tests/java/util/stream/ToListOpTest.java line 73:
>> 
>>> 71:     }
>>> 72: 
>>> 73:     @Test(dataProvider = "withNull:StreamTestData<Integer>", dataProviderClass = StreamTestDataProvider.class)
>> 
>> Given the non-default `toList()` implementation defers to the `toArray()` terminal op there is no need for this and the following tests, which are really designed to shake out the optimizations when producing and operating on arrays.
>
> OK, I'll remove all the tests starting from here to the end of the file. I'm assuming that's the set of tests you're referring to.

Yes from line 73 to <SHIFT>G (the end).

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

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

From naoto at openjdk.java.net  Fri Nov  6 03:03:59 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 6 Nov 2020 03:03:59 GMT
Subject: RFR: 8247781: Day periods support [v7]
In-Reply-To: <JinAuJMdAgSg6_n0vPK9NpaLSGbVSuhKBUBun2-5H4Q=.9251b24d-61f5-4f3f-b489-49279c4602fb@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
 <JinAuJMdAgSg6_n0vPK9NpaLSGbVSuhKBUBun2-5H4Q=.9251b24d-61f5-4f3f-b489-49279c4602fb@github.com>
Message-ID: <9g42DltbGQ0tCN99vN_SL3DU2KUlAf6btO749uqifkQ=.d10e88e1-5fb7-4d5f-aa61-07cb4fdacabf@github.com>

On Thu, 5 Nov 2020 23:25:38 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed typo/grammatical error.
>
> test/jdk/java/time/tck/java/time/format/TCKDateTimeParseResolver.java line 858:
> 
>> 856:         return new Object[][]{
>> 857:                 {STRICT, 0, LocalTime.of(6, 0), 0},
>> 858:                 {STRICT, 1, LocalTime.of(18, 0), 1},
> 
> As mentioned in my other comment, this seems odd in STRICT mode.

Did you mean in STRICT mode, HOUR_OF_AMPM should default to 0, and to 6 in SMART/LENIENT modes?

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

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

From smarks at openjdk.java.net  Fri Nov  6 03:04:56 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 6 Nov 2020 03:04:56 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <zNl6puL1sy_S1JWp3tLiQQf2YrhHvHY3GtGIBjtfz7E=.5eb94743-bfbb-4908-a2af-e9aceb22c9d3@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <aBcWsV_NhVd3jaVqcC-TKl38hWXUmEIrSUmsYPPF88g=.2b4b7d94-a3cc-4fc0-a9e7-defa360ee3a0@github.com>
 <zNl6puL1sy_S1JWp3tLiQQf2YrhHvHY3GtGIBjtfz7E=.5eb94743-bfbb-4908-a2af-e9aceb22c9d3@github.com>
Message-ID: <VeEg7hCJwqiJ8eqvlPLb9Oi6eNx-pgOqTzwshgb01jk=.5169c749-c176-438b-adc2-9e94921aa7c2@github.com>

On Wed, 4 Nov 2020 23:18:29 GMT, Pa?lo Ebermann <github.com+645859+ePaul at openjdk.org> wrote:

>> Changes requested by orionll at github.com (no known OpenJDK username).
>
> Looking at the linked issue, I see [this comment from R?mi Forax](https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14171626&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14171626):
> 
>> Please talk with Brian about this change because it nulls a property of the Stream API we (the lambda-util group) have take time to keep.
> The whole Stream API doesn't depends on the Collection API, [...] so the Stream API can be easily integrated with other collection API if in the future we want by example add a persistent collection API with no link with java.util.List.
> 
> That's an argument I can understand ? as is, the Stream API works just as well with collections from e.g. Scala's or Kotlin's (or Ceylon's) collection libraries instead of the java.util ones, just using different collectors. Adding a method which directly returns a java.util.List somewhat couples it to the Java Collection API.
> 
> Now this was mentioned two and a half year ago. Did something change which made this consideration irrelevant? I would expect at least some mention of it in the discussion here.

@ePaul wrote:

> The Stream API works just as well with [third party] collection libraries instead of the java.util ones, just using different collectors. Adding a method which directly returns a java.util.List somewhat couples it to the Java Collection API.
> 
> Now this was mentioned two and a half year ago. Did something change which made this consideration irrelevant? I would expect at least some mention of it in the discussion here.

The separation between streams and the java.util Collections Framework is a good design principle, but it isn't an ironclad rule. It's still easy to have streams create instances of other collections libraries using the Collector interface. What's different here is that the Collections Framework has "leaked into" streams a little bit more, so that they're now more interdependent. This doesn't seem to have any disadvantages; it seems unlikely that the Collections Framework will ever be unplugged from the JDK. However, the benefits are that a List is the closest thing we have to an unmodifiable array that also plays well with generics and that can be value-based; these benefits are considerable.

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

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

From smarks at openjdk.java.net  Fri Nov  6 03:08:55 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 6 Nov 2020 03:08:55 GMT
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <VeEg7hCJwqiJ8eqvlPLb9Oi6eNx-pgOqTzwshgb01jk=.5169c749-c176-438b-adc2-9e94921aa7c2@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <aBcWsV_NhVd3jaVqcC-TKl38hWXUmEIrSUmsYPPF88g=.2b4b7d94-a3cc-4fc0-a9e7-defa360ee3a0@github.com>
 <zNl6puL1sy_S1JWp3tLiQQf2YrhHvHY3GtGIBjtfz7E=.5eb94743-bfbb-4908-a2af-e9aceb22c9d3@github.com>
 <VeEg7hCJwqiJ8eqvlPLb9Oi6eNx-pgOqTzwshgb01jk=.5169c749-c176-438b-adc2-9e94921aa7c2@github.com>
Message-ID: <hhibYsPaakZXBiorfc_4a2T6Y0fwkHATDT49wamF5QU=.4b4549f7-863d-4902-a34c-7648d806d4fd@github.com>

On Fri, 6 Nov 2020 03:01:42 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Looking at the linked issue, I see [this comment from R?mi Forax](https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14171626&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14171626):
>> 
>>> Please talk with Brian about this change because it nulls a property of the Stream API we (the lambda-util group) have take time to keep.
>> The whole Stream API doesn't depends on the Collection API, [...] so the Stream API can be easily integrated with other collection API if in the future we want by example add a persistent collection API with no link with java.util.List.
>> 
>> That's an argument I can understand ? as is, the Stream API works just as well with collections from e.g. Scala's or Kotlin's (or Ceylon's) collection libraries instead of the java.util ones, just using different collectors. Adding a method which directly returns a java.util.List somewhat couples it to the Java Collection API.
>> 
>> Now this was mentioned two and a half year ago. Did something change which made this consideration irrelevant? I would expect at least some mention of it in the discussion here.
>
> @ePaul wrote:
> 
>> The Stream API works just as well with [third party] collection libraries instead of the java.util ones, just using different collectors. Adding a method which directly returns a java.util.List somewhat couples it to the Java Collection API.
>> 
>> Now this was mentioned two and a half year ago. Did something change which made this consideration irrelevant? I would expect at least some mention of it in the discussion here.
> 
> The separation between streams and the java.util Collections Framework is a good design principle, but it isn't an ironclad rule. It's still easy to have streams create instances of other collections libraries using the Collector interface. What's different here is that the Collections Framework has "leaked into" streams a little bit more, so that they're now more interdependent. This doesn't seem to have any disadvantages; it seems unlikely that the Collections Framework will ever be unplugged from the JDK. However, the benefits are that a List is the closest thing we have to an unmodifiable array that also plays well with generics and that can be value-based; these benefits are considerable.

> Simon Roberts wrote:

> This discussion of unmodifiable lists brings me back to the thought that
> there would be good client-side reasons for inserting an UnmodifiableList
> interface as a parent of LIst, not least because all our unmodifiable
> variants from the Collections.unmodifiableList proxy onward fail the Liskov
> substitution test for actually "being contract-fulfilling Lists".

At some point there probably will need to be a long article explaining all the issues here, but at the moment the best writeup I have is this one:

https://stackoverflow.com/a/57926310/1441122

TL;DR there are a few different ways to approach retrofitting something like this, but they all have enough compromises that the net benefits are unclear.

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

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

From dlong at openjdk.java.net  Fri Nov  6 04:27:57 2020
From: dlong at openjdk.java.net (Dean Long)
Date: Fri, 6 Nov 2020 04:27:57 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v2]
In-Reply-To: <KydsKzLVnAXutzj2ZpstlIeZsPFiK945J8PsnE0txGA=.f9645a2e-674c-46a4-8e2c-c0f416f55b1c@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
 <nzsF9Y2uu_CnCMbvedurT-g6us-65wC-n1VDDHr_KhY=.632433d8-8db2-4ac7-872d-095f6b63cc63@github.com>
 <KydsKzLVnAXutzj2ZpstlIeZsPFiK945J8PsnE0txGA=.f9645a2e-674c-46a4-8e2c-c0f416f55b1c@github.com>
Message-ID: <yqDCzs57zTfvf0pR3s455EbLxq5Y0DZndFBTB5Qedxc=.88fec390-840f-4dde-9495-42f09f65386b@github.com>

On Thu, 5 Nov 2020 23:58:21 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
>> 
>>  - Jorn's comments
>>  - Update headers and add intrinsic to Graal test ignore list
>>  - move compiler test and add bug to test
>>  - non x86_64 arch support
>>  - c2 test case
>>  - intrinsic
>>  - Use overloads of method names.
>>    
>>    Simplify internally to avoid overload resolution
>>    issues, leverging List<Number> for the exception
>>    mapper.
>>  - Vladimir's comments
>>  - checkLongIndex
>
> src/hotspot/share/opto/library_call.cpp line 1015:
> 
>> 1013:                   Deoptimization::Action_make_not_entrant);
>> 1014:   }
>> 1015: 
> 
> A comment here explaining what the code below is doing would be helpful.

This code wasn't here before, so I'm guessing it's needed for T_LONG.  For T_INT is it just wasted work?

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

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

From roland at openjdk.java.net  Fri Nov  6 08:27:59 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 6 Nov 2020 08:27:59 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v2]
In-Reply-To: <yqDCzs57zTfvf0pR3s455EbLxq5Y0DZndFBTB5Qedxc=.88fec390-840f-4dde-9495-42f09f65386b@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
 <nzsF9Y2uu_CnCMbvedurT-g6us-65wC-n1VDDHr_KhY=.632433d8-8db2-4ac7-872d-095f6b63cc63@github.com>
 <KydsKzLVnAXutzj2ZpstlIeZsPFiK945J8PsnE0txGA=.f9645a2e-674c-46a4-8e2c-c0f416f55b1c@github.com>
 <yqDCzs57zTfvf0pR3s455EbLxq5Y0DZndFBTB5Qedxc=.88fec390-840f-4dde-9495-42f09f65386b@github.com>
Message-ID: <BdtT-vmuno4Joyk-Gfuey2gOmCDHb9_viZb34FSwFPw=.c59dcd97-e842-4545-bcfa-2d530c7ae202@github.com>

On Fri, 6 Nov 2020 04:25:40 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/share/opto/library_call.cpp line 1015:
>> 
>>> 1013:                   Deoptimization::Action_make_not_entrant);
>>> 1014:   }
>>> 1015: 
>> 
>> A comment here explaining what the code below is doing would be helpful.
>
> This code wasn't here before, so I'm guessing it's needed for T_LONG.  For T_INT is it just wasted work?

Code in IdealLoopTree::is_range_check_if() uses this check:
  if (range->Opcode() != Op_LoadRange && !iff->is_RangeCheck()) {
    const TypeInt* tint = phase->_igvn.type(range)->isa_int();
    if (tint == NULL || tint->empty() || tint->_lo < 0) {
      // Allow predication on positive values that aren't LoadRanges.
      // This allows optimization of loops where the length of the
      // array is a known value and doesn't need to be loaded back
      // from the array.
      return false;
that is it assumes that everything that's on the right hand size of the a RangeCheck test is positive. I think it's cleaner and less dangerous to explicitly cast the length to >= 0 when the intrinsic is built. In a subsequent patch I intend to drop the && !iff->is_RangeCheck() check above.

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

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

From roland at openjdk.java.net  Fri Nov  6 08:35:17 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 6 Nov 2020 08:35:17 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v2]
In-Reply-To: <KydsKzLVnAXutzj2ZpstlIeZsPFiK945J8PsnE0txGA=.f9645a2e-674c-46a4-8e2c-c0f416f55b1c@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
 <nzsF9Y2uu_CnCMbvedurT-g6us-65wC-n1VDDHr_KhY=.632433d8-8db2-4ac7-872d-095f6b63cc63@github.com>
 <KydsKzLVnAXutzj2ZpstlIeZsPFiK945J8PsnE0txGA=.f9645a2e-674c-46a4-8e2c-c0f416f55b1c@github.com>
Message-ID: <HmylZIdktuSBTiDkK1pj-ezkHjvoW-p7WVcaErR5nQ0=.bec1cbf0-0026-4209-8058-8d1f50bfea15@github.com>

On Thu, 5 Nov 2020 23:59:43 GMT, Dean Long <dlong at openjdk.org> wrote:

> C2 changes look good, except for new code block in inline_preconditions_checkIndex could use a comment.

Thanks for the review. I added a comment for this block and some other comments for the rest of this method.

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

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

From roland at openjdk.java.net  Fri Nov  6 08:35:17 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 6 Nov 2020 08:35:17 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v3]
In-Reply-To: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
Message-ID: <R_wj8HyVj3TBppCLzwfdHTqEJOB4mxFdTmwx4yftKQc=.555c0dff-9826-4772-8421-2228c7a7aa7d@github.com>

> This change add 3 new methods in Objects:
> 
> public static long checkIndex(long index, long length)
> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
> public static long checkFromIndexSize(long fromIndex, long size, long length)
> 
> This mirrors the int utility methods that were added by JDK-8135248
> with the same motivations.
> 
> As is the case with the int checkIndex(), the long checkIndex() method
> is JIT compiled as an intrinsic. It allows the JIT to compile
> checkIndex to an unsigned comparison and properly recognize it as
> a range check that then becomes a candidate for the existing range check
> optimizations. This has proven to be important for panama's
> MemorySegment API and a prototype of this change (with some extra c2
> improvements) showed that panama micro benchmark results improve
> significantly.
> 
> This change includes:
> 
> - the API change
> - the C2 intrinsic
> - tests for the API and the C2 intrinsic
> 
> This is a joint work with Paul who reviewed and reworked the API change
> and filled the CSR.

Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:

  intrinsic comments

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1003/files
  - new: https://git.openjdk.java.net/jdk/pull/1003/files/b47184ac..aaacd328

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

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

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

From jfranck at openjdk.java.net  Fri Nov  6 09:01:59 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Fri, 6 Nov 2020 09:01:59 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?=
In-Reply-To: <1IPqXcDKyV2gwO1ro01A5-zCJB4_1A9P-GLsdaFY8GI=.750c0542-31ef-4281-bcb2-6da7a66c958b@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <6914QI9MySYQ4-Lpt_OIzMBbyFGRTYnPTLGJpIfBdQI=.57041221-95ea-44eb-90a6-57789597f741@github.com>
 <wllRvEUkKyTEFAmShdMQsLf5yMaL7TUIiS_SEDPptE0=.2042cc3b-8bde-4229-b198-76485f0647f6@github.com>
 <1IPqXcDKyV2gwO1ro01A5-zCJB4_1A9P-GLsdaFY8GI=.750c0542-31ef-4281-bcb2-6da7a66c958b@github.com>
Message-ID: <tJKI-gR0XTRiOp7w_gAgKvGI46sAOafuohtX_EZ5tk0=.8c11e1b6-d7dc-496f-901d-39b738a53b0a@github.com>

On Fri, 6 Nov 2020 00:24:14 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> If we are changing NativeMethodAccessorImpl.invoke then we should probably do NativeConstructorAccessorImpl.newInstance at the same time. Also wondering if we should, while in the area, add "return acc.invoke(obj, args)" after setting the delegate so that it invokes the newly generated accessor.
>> 
>> Are there resource or other cases that you have observed where generateMethod fails and then succeeds in a subsequent call?
>> 
>> @cl4es Do you know of any startup tests that might be sensitive to the eager creating of a VarHandle?
>> 
>> I agree with @shipilev to test before the CAS.
>
>> If we are changing NativeMethodAccessorImpl.invoke then we should probably do NativeConstructorAccessorImpl.newInstance at the same time. 
> 
> Yes, NativeConstructorAccessorImpl should also apply this change.
> 
>> Also wondering if we should, while in the area, add "return acc.invoke(obj, args)" after setting the delegate so that it invokes the newly generated accessor.
>> 
> 
> Agree,  I see no harm to invoke generated method when it is aviable. 
> Should leave this to another patch?
> 
>> Are there resource or other cases that you have observed where generateMethod fails and then succeeds in a subsequent call?
>> 
> I have not seen exception/error happen in generate method yet.  But in case it fails in some ways, try - catch - reset is added to make sure behavior is same before/after with this change.
> 
>> @cl4es Do you know of any startup tests that might be sensitive to the eager creating of a VarHandle?
>> 
>> I agree with @shipilev to test before the CAS.
> 
> @AlanBateman 
> Thanks for you comments!

Are there any benchmarks to compare this accessor with the previous version in the presumably common case where there is no or very little contention? Edit to clarify: it is stated as "trivial" is this also measured somewhere?

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

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

From forax at univ-mlv.fr  Fri Nov  6 09:14:22 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Fri, 6 Nov 2020 10:14:22 +0100 (CET)
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <CADsQA7hbZZdcDsVX1csqYJwi8Nnv-vxLbcN2gc+W+of0+-dAKA@mail.gmail.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <bUKuBU0ScUvhnCa-rUjJDUCPUfcPmS-OqMXyTSBsUeU=.2430a5a0-076e-4f16-9d1d-0dfa49faa99d@github.com>
 <4CY9WKRujRFgx526Z2joGTNdI4OGIJUI9omHgMnhReg=.8bf6e1d5-8ba9-4f7c-80bf-8adde581a9f6@github.com>
 <CADsQA7hbZZdcDsVX1csqYJwi8Nnv-vxLbcN2gc+W+of0+-dAKA@mail.gmail.com>
Message-ID: <1681654584.871831.1604654062322.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Simon Roberts" <simon at dancingcloudservices.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Jeudi 5 Novembre 2020 18:40:44
> Objet: Re: RFR: 8180352: Add Stream.toList() method

> At the risk of a can of worms, or at least of raising something that has
> long since been discussed and rejected...
> 
> This discussion of unmodifiable lists brings me back to the thought that
> there would be good client-side reasons for inserting an UnmodifiableList
> interface as a parent of LIst, not least because all our unmodifiable
> variants from the Collections.unmodifiableList proxy onward fail the Liskov
> substitution test for actually "being contract-fulfilling Lists".
> 
> Is this something that has been considered and rejected? (If so, is it easy
> to point me at the discussion, as I expect I'd find it fascinating). Is it
> worth considering, might it have some merit, or merely horrible
> unforeseen-by-me consequences to the implementation?

This question is asked at least every six months since 1998
https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html#a1

> 
> Cheers,
> Simon

regards,
R?mi Forax

> 
> 
> 
> On Thu, Nov 5, 2020 at 10:30 AM Stuart Marks <smarks at openjdk.java.net>
> wrote:
> 
>> On Wed, 4 Nov 2020 23:03:02 GMT, Pa?lo Ebermann <github.com+
>> 645859+ePaul at openjdk.org> wrote:
>>
>> >> This change introduces a new terminal operation on Stream. This looks
>> like a convenience method for Stream.collect(Collectors.toList()) or
>> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
>> method directly on Stream enables it to do what can't easily by done by a
>> Collector. In particular, it allows the stream to deposit results directly
>> into a destination array (even in parallel) and have this array be wrapped
>> in an unmodifiable List without copying.
>> >>
>> >> In the past we've kept most things from the Collections Framework as
>> implementations of Collector, not directly on Stream, whereas only
>> fundamental things (like toArray) appear directly on Stream. This is true
>> of most Collections, but it does seem that List is special. It can be a
>> thin wrapper around an array; it can handle generics better than arrays;
>> and unlike an array, it can be made unmodifiable (shallowly immutable); and
>> it can be value-based. See John Rose's comments in the bug report:
>> >>
>> >>
>> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
>> >>
>> >> This operation is null-tolerant, which matches the rest of Streams.
>> This isn't specified, though; a general statement about null handling in
>> Streams is probably warranted at some point.
>> >>
>> >> Finally, this method is indeed quite convenient (if the caller can deal
>> with what this operation returns), as collecting into a List is the most
>> common stream terminal operation.
>> >
>> > src/java.base/share/classes/java/util/ImmutableCollections.java line 199:
>> >
>> >> 197:      * safely reused as the List's internal storage, avoiding a
>> defensive copy. Declared
>> >> 198:      * with Object... instead of E... as the parameter type so
>> that varargs calls don't
>> >> 199:      * accidentally create an array of type other than Object[].
>> >
>> > Why would that be a problem? If the resulting list is immutable, then
>> the actual array type doesn't really matter, right?
>>
>> It's an implementation invariant that the internal array be Object[].
>> Having it be something other than Object[] can lead to subtle bugs. See
>> [JDK-6260652](https://bugs.openjdk.java.net/browse/JDK-6260652) for
>> example.
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/1026
>>
> 
> 
> --
> Simon Roberts
> (303) 249 3613

From scolebourne at openjdk.java.net  Fri Nov  6 09:14:58 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Fri, 6 Nov 2020 09:14:58 GMT
Subject: RFR: 8247781: Day periods support [v7]
In-Reply-To: <9g42DltbGQ0tCN99vN_SL3DU2KUlAf6btO749uqifkQ=.d10e88e1-5fb7-4d5f-aa61-07cb4fdacabf@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
 <JinAuJMdAgSg6_n0vPK9NpaLSGbVSuhKBUBun2-5H4Q=.9251b24d-61f5-4f3f-b489-49279c4602fb@github.com>
 <9g42DltbGQ0tCN99vN_SL3DU2KUlAf6btO749uqifkQ=.d10e88e1-5fb7-4d5f-aa61-07cb4fdacabf@github.com>
Message-ID: <D0R1WkNIFGKaEtcT66x4msdO0pMMVpKHoAAiG1xmd7E=.213b20a1-0695-4890-b220-a5ff2208d68f@github.com>

On Fri, 6 Nov 2020 03:00:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/time/tck/java/time/format/TCKDateTimeParseResolver.java line 858:
>> 
>>> 856:         return new Object[][]{
>>> 857:                 {STRICT, 0, LocalTime.of(6, 0), 0},
>>> 858:                 {STRICT, 1, LocalTime.of(18, 0), 1},
>> 
>> As mentioned in my other comment, this seems odd in STRICT mode.
>
> Did you mean in STRICT mode, HOUR_OF_AMPM should default to 0, and to 6 in SMART/LENIENT modes?

No. I mean that when resolving AMPM/dayPeriod in strict mode, and there is no HOUR_OF_DAY or HOUR_OF_AMPM, then do not resolve using "half way between"(ie. fail). This will produce a result where `LocalTime` cannot be obtained.

var f = DateTimeFormatter.ofPattern("B").withResolverStyle(ResolverStyle.STRICT);
var t = LocalTime.from("at night", f);
would throw an exception in STRICT mode (whereas SMART or LENIENT would return a `LocalTime`). Same with pattern "a".

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

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

From lzang at openjdk.java.net  Fri Nov  6 12:59:05 2020
From: lzang at openjdk.java.net (Lin Zang)
Date: Fri, 6 Nov 2020 12:59:05 GMT
Subject: RFR: 8255982: Extend BasicJMapTest to test with different GC Heap
Message-ID: <oMOl_RemTAQcjWRQ-1NSgzzFy9NPjLw-Bws6V_HgGk8=.29b31af6-519a-49ba-b799-af7e7586ceba@github.com>

The implementation of jmap tool depends on the implementation of object iteration by different GC heap.
This patch extend the BasicJMapTest to cover differet GC Heap.

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

Commit messages:
 - 8255982: Extend BasicJMapTest to test with different GC Heap

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

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

From chris.hegarty at oracle.com  Fri Nov  6 15:12:45 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 6 Nov 2020 15:12:45 +0000
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <a3e944fd-0344-a1a0-3597-34e80ccf045a@oracle.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
 <KtWlgWOHrf9MbXbBd_hUeQaDVmIB5BJMAiCJ2DDKKtM=.cb31d17f-07a1-4cca-b5e4-0aa4007c5a44@github.com>
 <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com>
 <a3e944fd-0344-a1a0-3597-34e80ccf045a@oracle.com>
Message-ID: <B9978080-4F14-47B9-AE8E-6D86C43DEBF8@oracle.com>


> On 5 Nov 2020, at 18:11, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> On 11/5/2020 4:45 AM, Jan Lahoda wrote:
>> FWIW, a javadoc generated with the current version of the patch:
>> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html
> 
> Allow me to draw people's attention to the PREVIEW link in the banner of the generated javadoc. It shows all the preview APIs in the release on one page. This is very helpful for understanding the surface area of a preview feature.
> 
> For example, with Sealed Classes being the only preview feature likely to target JDK 16, the PREVIEW page shows that the feature's API is solely about reflection. It's clear that Sealed Classes do not introduce, say, a java.lang.Sealed class analogous to the java.lang.Record class introduced by Records in JDK 14/15 (and which would have appeared on the PREVIEW page had it existed then).

Very cool! ( I didn?t notice this until you pointed it out ;-) )

http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/preview-list.html <http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/preview-list.html>

There appears to be a very minor bug; when I click on the PREVIEW link in the banner, the page that lists the preview API points loads, but the banner does not ?highlight? that PREVIEW is ?selected?, but rather it ?highlights? DEPRECATED.

-Chris.


From jjg at openjdk.java.net  Fri Nov  6 15:35:00 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Fri, 6 Nov 2020 15:35:00 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
 <KtWlgWOHrf9MbXbBd_hUeQaDVmIB5BJMAiCJ2DDKKtM=.cb31d17f-07a1-4cca-b5e4-0aa4007c5a44@github.com>
 <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com>
Message-ID: <T9pPB5b2ARzPDwukZiP4FJKUwx-ZUnqULpH6FFPoTR8=.545a81ab-b04a-4044-bd07-9fe6dec44dbe@github.com>

On Thu, 5 Nov 2020 12:43:03 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Thanks @jonathan-gibbons for your comments! I've tried to update the code based on them, mostly in https://github.com/lahodaj/jdk/commit/743f516c660b577035cdda4510a0bb97937fd9b2 and https://github.com/lahodaj/jdk/commit/e4b02827998fc2e8f19f983aabfb3d720b03d111
>> 
>> A big chunk of the update is generalization of the deprecated and preview list builders and writers into a "summary" list builder and writer. These should also now handle records. For record components, those are a little tricky, as (AFAIK) can't currently have deprecation/preview-ness for them (and hence there is no good way to test any support for record components in these). But the summary build and writer are looking for record components and will fail in case a record component is sent into them.
>
> FWIW, a javadoc generated with the current version of the patch:
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html
> 
> And a specdiff comparing it to the javadoc built from the corresponding master:
> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.specdiff.01/overview-summary.html

The page and comments are generally good, but there is a bug that needs 
to be fixed.

After clicking on the PREVIEW link in the top bar to go to the Preview 
page, the word DEPRECATED is highlighted in the top navbar instead of 
PREVIEW.

-- Jon


On 11/5/20 10:13 AM, mlbridge[bot] wrote:
>
> /Mailing list message from Alex Buckley 
> <mailto:alex.buckley at oracle.com> on kulla-dev 
> <mailto:kulla-dev at openjdk.java.net>:/
>
> On 11/5/2020 4:45 AM, Jan Lahoda wrote:
>
>     FWIW, a javadoc generated with the current version of the patch:
>     http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html
>
> Allow me to draw people's attention to the PREVIEW link in the banner of
> the generated javadoc. It shows all the preview APIs in the release on
> one page. This is very helpful for understanding the surface area of a
> preview feature.
>
> For example, with Sealed Classes being the only preview feature likely
> to target JDK 16, the PREVIEW page shows that the feature's API is
> solely about reflection. It's clear that Sealed Classes do not
> introduce, say, a java.lang.Sealed class analogous to the
> java.lang.Record class introduced by Records in JDK 14/15 (and which
> would have appeared on the PREVIEW page had it existed then).
>
> Alex
>
> ?
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/703*issuecomment-722549484__;Iw!!GqivPVa7Brio!ONrE9EESNKSCZJPGXBa8TTa4Ey9OqEVTynHLfgVOrBRIkb1Cr2iqLALb01M_DlGDeQEPpw$>, 
> or unsubscribe 
> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRRTA7I6T2AUM3QT7QTSOLTLXANCNFSM4STPEYJQ__;!!GqivPVa7Brio!ONrE9EESNKSCZJPGXBa8TTa4Ey9OqEVTynHLfgVOrBRIkb1Cr2iqLALb01M_DlE4QxPnyw$>.
>

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

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

From iignatyev at openjdk.java.net  Fri Nov  6 15:55:58 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Fri, 6 Nov 2020 15:55:58 GMT
Subject: RFR: 8255964: Add jcmd Thread.print to jtreg timeout handler
In-Reply-To: <DsUVGVtRjQYJjXik8iSra_siW4L2QXZrwjMG9zhBAJY=.2d637062-34c5-4c5e-b7ed-2d4708f16221@github.com>
References: <DsUVGVtRjQYJjXik8iSra_siW4L2QXZrwjMG9zhBAJY=.2d637062-34c5-4c5e-b7ed-2d4708f16221@github.com>
Message-ID: <ZrJ7x_INx7cLUOesplcPg0Z-zw2q905aGoJPDT-EyDk=.327cdf15-0d1e-4810-b5d3-6f0ff7adb856@github.com>

On Thu, 5 Nov 2020 17:09:58 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> This patch adds jcmd Thread.print to the jtreg timeout handler.
> 
> Please review.

Hi Nils,

It looks alright, but could you please elaborate on why we need it when there is already `jstack` action?

? Igor

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

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

From herrick at openjdk.java.net  Fri Nov  6 16:17:58 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 6 Nov 2020 16:17:58 GMT
Subject: Integrated: JDK-8254920: Application launched with jpackage produced
 .exe crashes JVM
In-Reply-To: <Tcn6BwsjMBJ4KTFov7i4VN7kVJasVeTEXGyguR4RVUw=.1f8c589f-0ade-447b-be0d-b5178e15752b@github.com>
References: <Tcn6BwsjMBJ4KTFov7i4VN7kVJasVeTEXGyguR4RVUw=.1f8c589f-0ade-447b-be0d-b5178e15752b@github.com>
Message-ID: <iVntWHyPs0dmoyeGqqU0yBAMqyhQR13IKMtE-V5rMzo=.8244f1f0-3293-4658-a545-748b6c457a19@github.com>

On Thu, 29 Oct 2020 17:32:24 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JVM

This pull request has now been integrated.

Changeset: 952abea4
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/952abea4
Stats:     115 lines in 4 files changed: 110 ins; 0 del; 5 mod

8254920: Application launched with jpackage produced .exe crashes JVM

Reviewed-by: asemenyuk, almatvee, kizune

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

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

From bpb at openjdk.java.net  Fri Nov  6 16:18:58 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 6 Nov 2020 16:18:58 GMT
Subject: Integrated: 8255969: Improve
 java/io/BufferedInputStream/LargeCopyWithMark.java using jtreg tags
In-Reply-To: <-P8McZTovaFNg3tR_2x6eXGKneuzWiclxVduu_wABKQ=.e9a970d8-3088-43fc-a7e5-af94aa73cf51@github.com>
References: <-P8McZTovaFNg3tR_2x6eXGKneuzWiclxVduu_wABKQ=.e9a970d8-3088-43fc-a7e5-af94aa73cf51@github.com>
Message-ID: <-DOsa9RRgTbkos4YCUbDJ65HDE-GZYftEgQRXRNuKLk=.c62aa357-2e2a-45b4-9b0c-d40ab09a69ce@github.com>

On Thu, 5 Nov 2020 19:50:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this change which would replace the use of a system property and a child process with updated jtreg tags.

This pull request has now been integrated.

Changeset: 727a69f5
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/727a69f5
Stats:     45 lines in 1 file changed: 1 ins; 24 del; 20 mod

8255969: Improve java/io/BufferedInputStream/LargeCopyWithMark.java using jtreg tags

Reviewed-by: naoto

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

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

From neliasso at openjdk.java.net  Fri Nov  6 16:55:57 2020
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 6 Nov 2020 16:55:57 GMT
Subject: RFR: 8255964: Add jcmd Thread.print to jtreg timeout handler
In-Reply-To: <ZrJ7x_INx7cLUOesplcPg0Z-zw2q905aGoJPDT-EyDk=.327cdf15-0d1e-4810-b5d3-6f0ff7adb856@github.com>
References: <DsUVGVtRjQYJjXik8iSra_siW4L2QXZrwjMG9zhBAJY=.2d637062-34c5-4c5e-b7ed-2d4708f16221@github.com>
 <ZrJ7x_INx7cLUOesplcPg0Z-zw2q905aGoJPDT-EyDk=.327cdf15-0d1e-4810-b5d3-6f0ff7adb856@github.com>
Message-ID: <quyczTj9q2IQfEUmEP5uA5-BXIdjBRbsoqJCQ7fkGv4=.e885b70e-dfb5-493f-917f-27867b553bf4@github.com>

On Fri, 6 Nov 2020 15:53:35 GMT, Igor Ignatyev <iignatyev at openjdk.org> wrote:

>> This patch adds jcmd Thread.print to the jtreg timeout handler.
>> 
>> Please review.
>
> Hi Nils,
> 
> It looks alright, but could you please elaborate on why we need it when there is already `jstack` action?
> 
> ? Igor

They have the same output - I didn't realize that. But it would be nice to add the extended output - so I am updating the PR.

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

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

From jvernee at openjdk.java.net  Fri Nov  6 17:01:30 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 6 Nov 2020 17:01:30 GMT
Subject: RFR: 8254354: Add a withInvokeExactBehavior() VarHandle
 combinator [v13]
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <Ps806PNYCNrIhFLAEwqqAvx2uwpm2yOu2Ejzx7Bhhrs=.9b5e0114-0ab5-426b-b7fa-69f99f71481a@github.com>

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn
> 
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375

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

 - Merge branch 'master' into Exact_VarHandle
 - Address review comments:
   - Fix typo
   - add specification about return value of hasInvokeExactBehaviour
 - s/an arity/and arity
 - behaviour -> behavior in javadoc as well
 - - behaviour -> behaviour
   - Return same VarHandle instance when instance is already exact/non-exact
 - Update Javadoc, and rename asExact and asGeneric to withInvokeExactBehaviour and withInvokeBehaviour
 - Merge branch 'master' into Exact_VarHandle
 - Use AccessType ordinal in guard checks instead of the AccessMode ordinal
 - Update accessModeType to use the AccessType ordinal directly.
 - Add benchmarks
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/b6a085d4...ea7c920c

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/843/files
  - new: https://git.openjdk.java.net/jdk/pull/843/files/e92bd30f..ea7c920c

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

  Stats: 15154 lines in 825 files changed: 8417 ins; 4076 del; 2661 mod
  Patch: https://git.openjdk.java.net/jdk/pull/843.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/843/head:pull/843

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

From jvernee at openjdk.java.net  Fri Nov  6 17:01:34 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 6 Nov 2020 17:01:34 GMT
Subject: RFR: 8254354: Add a withInvokeExactBehavior() VarHandle
 combinator [v9]
In-Reply-To: <lgz1VUKPSgaoURH9_ducL4gAAP498ncimLq4NCMfhAo=.2fa5aebf-ff0f-47df-af05-5e19f54b504e@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <uTje1Aig7YoVD5weI_IyD0yZdCFlNsIiSJjyzUQIXHM=.fcd5a9fa-e186-4776-a968-b07f4552b4e9@github.com>
 <lgz1VUKPSgaoURH9_ducL4gAAP498ncimLq4NCMfhAo=.2fa5aebf-ff0f-47df-af05-5e19f54b504e@github.com>
Message-ID: <WNXbnpKwILBJubTYFxHNWEfK_xF-RB09HpdE0J4p3wE=.d7c1468d-a252-4ac4-aeb7-b14fa8351177@github.com>

On Fri, 30 Oct 2020 15:23:28 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
>> 
>>  - Update Javadoc, and rename asExact and asGeneric to withInvokeExactBehaviour and withInvokeBehaviour
>>  - Merge branch 'master' into Exact_VarHandle
>>  - Use AccessType ordinal in guard checks instead of the AccessMode ordinal
>>  - Update accessModeType to use the AccessType ordinal directly.
>>  - Add benchmarks
>>  - - Update javadoc
>>    - Make isExact() public
>>  - Fixes failing tests, and enable verifier on Exact test
>>  - Fix whitespace
>>  - Comment out VarHandleGuards generator code
>>  - Makes exactness a property of a VarHandle, not a VarForm, since the latter are shared. Use handle.accessModeType to get the exact type of the VarHandle.
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/84ce7081...3c707bc7
>
> Looks good. There is just one difference between the spec and implementation. The spec states: 
>> If this VarHandle already has invoke{-exact} behaviour this VarHandle is returned.
> 
> I prefer this behaviour, but feel free to update the spec if you like e.g. If ... already has XXX then a new VH with exactly the same behaviour as this VH is returned.
> 
> I just realized i used "behaviour", the english spelling. We should use the US spelling, "behavior", which is more commonly used throughout the JDK documentation.

@ChrisHegarty Thanks for the comments. I've implemented them.

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

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

From smarks at openjdk.java.net  Fri Nov  6 17:54:10 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 6 Nov 2020 17:54:10 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v2]
In-Reply-To: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
Message-ID: <5OcYlSgfeNz0fZ0WndJOIW3Wn59rAP5HgmAcdnWr44o=.6cefa19c-25eb-4f2e-a010-fafd1a6cf0ca@github.com>

> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
> 
> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
> 
> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
> 
> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.

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

  Merge ListNNullsAllowed into ListN. Update spec for Stream.toList.
  Add nulls-allowed empty list. Simplify indexOf/lastIndexOf.
  Reduce tests, add contains(null) tests.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1026/files
  - new: https://git.openjdk.java.net/jdk/pull/1026/files/3e05564d..cf849755

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

  Stats: 181 lines in 3 files changed: 16 ins; 117 del; 48 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1026/head:pull/1026

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

From javalists at cbfiddle.com  Fri Nov  6 18:00:22 2020
From: javalists at cbfiddle.com (Alan Snyder)
Date: Fri, 6 Nov 2020 10:00:22 -0800
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <1681654584.871831.1604654062322.JavaMail.zimbra@u-pem.fr>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <bUKuBU0ScUvhnCa-rUjJDUCPUfcPmS-OqMXyTSBsUeU=.2430a5a0-076e-4f16-9d1d-0dfa49faa99d@github.com>
 <4CY9WKRujRFgx526Z2joGTNdI4OGIJUI9omHgMnhReg=.8bf6e1d5-8ba9-4f7c-80bf-8adde581a9f6@github.com>
 <CADsQA7hbZZdcDsVX1csqYJwi8Nnv-vxLbcN2gc+W+of0+-dAKA@mail.gmail.com>
 <1681654584.871831.1604654062322.JavaMail.zimbra@u-pem.fr>
Message-ID: <D2E3083B-A827-4A6C-A31C-DAE771AF30E8@cbfiddle.com>

>> This discussion of unmodifiable lists brings me back to the thought that
>> there would be good client-side reasons for inserting an UnmodifiableList
>> interface as a parent of LIst

> On Nov 6, 2020, at 1:14 AM, Remi Forax <forax at univ-mlv.fr <mailto:forax at univ-mlv.fr>> wrote:
> 
> 
> This question is asked at least every six months since 1998
> https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html#a1 <https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html#a1>

The question that Simon asked is not exactly the question that is answered in this link.

The question of whether List should be a subtype of (some kind of) ImmutableList is answered in
Stuart?s stack overflow answer (https://stackoverflow.com/a/57926310/1441122 <https://stackoverflow.com/a/57926310/1441122>). The answer
is that it should not.

The question answered in the link is basically a straw man: why not capture every conceivable
semantic distinction in the collections type system. And the answer is, not surprisingly, that
there would be way too many types.

But a question that deserves ongoing review is whether Java should support immutable collections
using a separate type hierarchy. In other words, Immutable List would not be a subtype of List
and List would not be a subtype of Immutable List. The linked answer says:
"Adding this support to the type hierarchy requires four more interfaces.? Four additional
interfaces sounds like a small cost for a significant benefit. As Java evolves to better support
functional programming styles, immutable collections seems like an obvious next step.

Much could be written, and probably has been, about the disadvantages of basing the
collections framework on mutable collections. Let me just remark that in addition to the
already mentioned UnsupportedOperationException, there is also the more subtle
ConcurrentModificationException, both of which would be absent in fully immutable collections.

The lack of subtyping between List and ImmutableList is not terrible. Arrays coexist with
Lists with no subtyping relationship. java.io.File coexists with java.nio.filePath with no
subtyping relationship. It means that explicit conversions are required between List and
ImmutableList. Extra copying may be needed, but there are tricks for reducing copying, and the
need for defensive copying is removed.

  Alan


From jlahoda at openjdk.java.net  Fri Nov  6 18:41:15 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 Nov 2020 18:41:15 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v11]
In-Reply-To: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
Message-ID: <fDWoj48-Ewh1-5pZKBQFI_UYuXFGPgjnXwmJuRlvKfY=.bb7279d8-008c-4254-8145-654579ef639f@github.com>

> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
> 
> The notable changes are:
> 
>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>  
>  Please also see the CSR [6] for more information.
>  
>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing navigator for the PREVIEW page.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/703/files
  - new: https://git.openjdk.java.net/jdk/pull/703/files/097ae3c1..61264fe4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=703&range=09-10

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

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

From jlahoda at openjdk.java.net  Fri Nov  6 18:41:15 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 6 Nov 2020 18:41:15 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v6]
In-Reply-To: <T9pPB5b2ARzPDwukZiP4FJKUwx-ZUnqULpH6FFPoTR8=.545a81ab-b04a-4044-bd07-9fe6dec44dbe@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <0_WQkFp21--3oBLlFpJ-CN3ACeLwKEB21ByfD_LUl7Q=.831ed155-e36f-4bb9-8289-98e30042b65b@github.com>
 <3jLIRMTBm23tqzjxY8zwTvMCL7zaZkLgjEKAUiCFc78=.279fb6fb-2f7f-4602-8ed5-5df354276a3e@github.com>
 <KtWlgWOHrf9MbXbBd_hUeQaDVmIB5BJMAiCJ2DDKKtM=.cb31d17f-07a1-4cca-b5e4-0aa4007c5a44@github.com>
 <9oQ_AyidieKnLIkJrx6koIR3TUJIqmxVmlzp82TX_64=.c44f863b-7873-498c-ae87-a922e0086fb9@github.com>
 <T9pPB5b2ARzPDwukZiP4FJKUwx-ZUnqULpH6FFPoTR8=.545a81ab-b04a-4044-bd07-9fe6dec44dbe@github.com>
Message-ID: <bEQCaxy0VNHdMsS8Yhv_PqRo71oH0TMnHYSe4LIt5R4=.939875b7-57b7-4bfb-a0c7-e70d3b81e983@github.com>

On Fri, 6 Nov 2020 15:32:16 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> FWIW, a javadoc generated with the current version of the patch:
>> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html
>> 
>> And a specdiff comparing it to the javadoc built from the corresponding master:
>> http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.specdiff.01/overview-summary.html
>
> The page and comments are generally good, but there is a bug that needs 
> to be fixed.
> 
> After clicking on the PREVIEW link in the top bar to go to the Preview 
> page, the word DEPRECATED is highlighted in the top navbar instead of 
> PREVIEW.
> 
> -- Jon
> 
> 
> On 11/5/20 10:13 AM, mlbridge[bot] wrote:
>>
>> /Mailing list message from Alex Buckley 
>> <mailto:alex.buckley at oracle.com> on kulla-dev 
>> <mailto:kulla-dev at openjdk.java.net>:/
>>
>> On 11/5/2020 4:45 AM, Jan Lahoda wrote:
>>
>>     FWIW, a javadoc generated with the current version of the patch:
>>     http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.01/api/index.html
>>
>> Allow me to draw people's attention to the PREVIEW link in the banner of
>> the generated javadoc. It shows all the preview APIs in the release on
>> one page. This is very helpful for understanding the surface area of a
>> preview feature.
>>
>> For example, with Sealed Classes being the only preview feature likely
>> to target JDK 16, the PREVIEW page shows that the feature's API is
>> solely about reflection. It's clear that Sealed Classes do not
>> introduce, say, a java.lang.Sealed class analogous to the
>> java.lang.Record class introduced by Records in JDK 14/15 (and which
>> would have appeared on the PREVIEW page had it existed then).
>>
>> Alex
>>
>> ?
>> You are receiving this because you were mentioned.
>> Reply to this email directly, view it on GitHub 
>> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/703*issuecomment-722549484__;Iw!!GqivPVa7Brio!ONrE9EESNKSCZJPGXBa8TTa4Ey9OqEVTynHLfgVOrBRIkb1Cr2iqLALb01M_DlGDeQEPpw$>, 
>> or unsubscribe 
>> <https://urldefense.com/v3/__https://github.com/notifications/unsubscribe-auth/AOUXBRRTA7I6T2AUM3QT7QTSOLTLXANCNFSM4STPEYJQ__;!!GqivPVa7Brio!ONrE9EESNKSCZJPGXBa8TTa4Ey9OqEVTynHLfgVOrBRIkb1Cr2iqLALb01M_DlE4QxPnyw$>.
>>

Thanks for noticing Chris and @jonathan-gibbons. Fixed in 61264fe, updated javadoc:
http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.02/api/preview-list.html

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

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

From martin.desruisseaux at geomatys.com  Fri Nov  6 19:54:56 2020
From: martin.desruisseaux at geomatys.com (Martin Desruisseaux)
Date: Fri, 6 Nov 2020 20:54:56 +0100
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <D2E3083B-A827-4A6C-A31C-DAE771AF30E8@cbfiddle.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <bUKuBU0ScUvhnCa-rUjJDUCPUfcPmS-OqMXyTSBsUeU=.2430a5a0-076e-4f16-9d1d-0dfa49faa99d@github.com>
 <4CY9WKRujRFgx526Z2joGTNdI4OGIJUI9omHgMnhReg=.8bf6e1d5-8ba9-4f7c-80bf-8adde581a9f6@github.com>
 <CADsQA7hbZZdcDsVX1csqYJwi8Nnv-vxLbcN2gc+W+of0+-dAKA@mail.gmail.com>
 <1681654584.871831.1604654062322.JavaMail.zimbra@u-pem.fr>
 <D2E3083B-A827-4A6C-A31C-DAE771AF30E8@cbfiddle.com>
Message-ID: <4d4a7f46-275e-3062-9063-5c3c8e84cdab@geomatys.com>

Le 06/11/2020 ? 19:00, Alan Snyder a ?crit?:
> (?snip?) But a question that deserves ongoing review is whether Java 
> should support immutable collections using a separate type hierarchy 
> (?snip?).

Maybe an alternative way (admittedly more difficult) to have immutable 
collections without introducing new interfaces could be to take 
inspiration from the C++ "const" keyword? Especially since in Java, 
"const" is already a reserved keyword, just not used yet.

I realize that it would be a difficult task: how to handle private 
fields that are just caches in a const object; where to add the "const" 
keyword in existing JDK API; how to make such change in a backward 
compatible way (e.g. when a legacy code overrides a "const" method). I 
do not have any expectation. But given the inconvenient of alternatives, 
I wonder if there is some research about the long-term feasibility of a 
"const" semantic in Java? If it was the case, then maybe it would be 
better to not add immutable collection interfaces in Java for now.

 ??? Regards

 ??? ??? Martin



From prappo at openjdk.java.net  Fri Nov  6 20:17:04 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Fri, 6 Nov 2020 20:17:04 GMT
Subject: RFR: 8255989: Remove explicitly unascribed authorship from Java
 source files
Message-ID: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>

This PR proposes to remove
1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.java.net/jdk/pull/1100/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1100&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255989
  Stats: 140 lines in 77 files changed: 0 ins; 80 del; 60 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1100.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1100/head:pull/1100

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

From neliasso at openjdk.java.net  Fri Nov  6 20:25:13 2020
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 6 Nov 2020 20:25:13 GMT
Subject: RFR: 8255964: Add jcmd Thread.print to jtreg timeout handler [v2]
In-Reply-To: <DsUVGVtRjQYJjXik8iSra_siW4L2QXZrwjMG9zhBAJY=.2d637062-34c5-4c5e-b7ed-2d4708f16221@github.com>
References: <DsUVGVtRjQYJjXik8iSra_siW4L2QXZrwjMG9zhBAJY=.2d637062-34c5-4c5e-b7ed-2d4708f16221@github.com>
Message-ID: <UVfJeztUBd6Vigce9KfOz8F4B6CiBzdPoRmzAZrK4AA=.92c7e754-35cb-4ef9-91d8-8d03890243c2@github.com>

> This patch adds jcmd Thread.print to the jtreg timeout handler.
> 
> Please review.

Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision:

  add extended printing to jstack

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1080/files
  - new: https://git.openjdk.java.net/jdk/pull/1080/files/2451660c..2ca47884

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

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

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

From redestad at openjdk.java.net  Fri Nov  6 20:28:57 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 6 Nov 2020 20:28:57 GMT
Subject: RFR: 8255989: Remove explicitly unascribed authorship from Java
 source files
In-Reply-To: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
Message-ID: <NXj1QERdKDWAI_eCPFIqxfcpSvgIsMaZj-D098av1Bs=.a8ad7c00-e037-449e-93c0-0ba7c3fb455b@github.com>

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

A removed @author tag is a good @author tag

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

Marked as reviewed by redestad (Reviewer).

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

From naoto at openjdk.java.net  Fri Nov  6 21:12:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 6 Nov 2020 21:12:11 GMT
Subject: RFR: 8247781: Day periods support [v8]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <mhZ-mRv8p80kHFCQkQvF92FUkWoByYUXm8zFgkH3vR0=.b66ab4e9-d924-4800-83fe-7624111352f2@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Addressed the following comments:
  - https://github.com/openjdk/jdk/pull/938#discussion_r518431077
  - https://github.com/openjdk/jdk/pull/938#discussion_r518616570
  - https://github.com/openjdk/jdk/pull/938#discussion_r518439782

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/b0649899..8054ce6b

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

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

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

From naoto at openjdk.java.net  Fri Nov  6 21:12:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 6 Nov 2020 21:12:11 GMT
Subject: RFR: 8247781: Day periods support [v7]
In-Reply-To: <D0R1WkNIFGKaEtcT66x4msdO0pMMVpKHoAAiG1xmd7E=.213b20a1-0695-4890-b220-a5ff2208d68f@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
 <JinAuJMdAgSg6_n0vPK9NpaLSGbVSuhKBUBun2-5H4Q=.9251b24d-61f5-4f3f-b489-49279c4602fb@github.com>
 <9g42DltbGQ0tCN99vN_SL3DU2KUlAf6btO749uqifkQ=.d10e88e1-5fb7-4d5f-aa61-07cb4fdacabf@github.com>
 <D0R1WkNIFGKaEtcT66x4msdO0pMMVpKHoAAiG1xmd7E=.213b20a1-0695-4890-b220-a5ff2208d68f@github.com>
Message-ID: <i7Zo3zBe3iAab5D5KEOuVulO7MpC6x8QlL2ope_WX6Q=.dfd7168c-0134-47b7-bb44-e7ff996bfa9f@github.com>

On Fri, 6 Nov 2020 09:12:38 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Did you mean in STRICT mode, HOUR_OF_AMPM should default to 0, and to 6 in SMART/LENIENT modes?
>
> No. I mean that when resolving AMPM/dayPeriod in strict mode, and there is no HOUR_OF_DAY or HOUR_OF_AMPM, then do not resolve using "half way between"(ie. fail). This will produce a result where `LocalTime` cannot be obtained.
> 
> var f = DateTimeFormatter.ofPattern("B").withResolverStyle(ResolverStyle.STRICT);
> var t = LocalTime.from("at night", f);
> would throw an exception in STRICT mode (whereas SMART or LENIENT would return a `LocalTime`). Same with pattern "a".

Changed to throw an exception in STRICT mode.

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

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

From naoto at openjdk.java.net  Fri Nov  6 21:12:12 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 6 Nov 2020 21:12:12 GMT
Subject: RFR: 8247781: Day periods support [v7]
In-Reply-To: <JinAuJMdAgSg6_n0vPK9NpaLSGbVSuhKBUBun2-5H4Q=.9251b24d-61f5-4f3f-b489-49279c4602fb@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <QPpC2RpJBfXOsQ1h8mtksrDQcdFvHOwMfby_zklW-zc=.1174c74e-047d-4a84-a5a7-bcb5f544630c@github.com>
 <JinAuJMdAgSg6_n0vPK9NpaLSGbVSuhKBUBun2-5H4Q=.9251b24d-61f5-4f3f-b489-49279c4602fb@github.com>
Message-ID: <5fowCEUB6fq9jJPqJ-vc3dHPjBFSBLm8PweNV6ISwZE=.683ddc9d-536f-483c-be69-079a3728a12c@github.com>

On Thu, 5 Nov 2020 23:49:25 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed typo/grammatical error.
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5055:
> 
>> 5053:         @Override
>> 5054:         public boolean format(DateTimePrintContext context, StringBuilder buf) {
>> 5055:             Long value = context.getValue(MINUTE_OF_DAY);
> 
> This does not match the spec: " During formatting, the day period is obtained from {@code HOUR_OF_DAY}, and optionally {@code MINUTE_OF_HOUR} if exist"
> 
> It is possible and legal to create a Temporal that returns `HOUR_OF_DAY` and `MINUTE_OF_HOUR` but not `MINUTE_OF_DAY`. As such, this method must be changed to follow the spec.
> 
> -----
> 
> In addition, it is possible for `HOUR_OF_DAY` and `MINUTE_OF_HOUR` to be outside their normal bounds. The right behaviour would be to combine the two fields within this method, and then use mod to get the value into the range 0 to 1440 before calling `dayPeriod.include`. (While the fall back behaviour below does cover this, it would be better to do what I propose here.)
> 
> An example of this is a `TransportTime` class where the day runs from 03:00 to 27:00 each day (because trains run after midnight for no extra cost to the passenger, and it is more convenient for the operator to treat the date that way). A `TransportTime` of 26:30 should still resolve to "night1" rather than fall back to "am".

Fixed.

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

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

From mr at openjdk.java.net  Fri Nov  6 21:17:59 2020
From: mr at openjdk.java.net (Mark Reinhold)
Date: Fri, 6 Nov 2020 21:17:59 GMT
Subject: RFR: 8255989: Remove explicitly unascribed authorship from Java
 source files
In-Reply-To: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
Message-ID: <BXofM2LBxP-1vS0_CarSp2TRDMe6_jUI56Dw8QuBsCw=.6dd59831-78f0-4730-8e9f-c97fa6ee03b2@github.com>

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

Marked as reviewed by mr (Lead).

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

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

From mchung at openjdk.java.net  Fri Nov  6 21:25:56 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 6 Nov 2020 21:25:56 GMT
Subject: RFR: 8255989: Remove explicitly unascribed authorship from Java
 source files
In-Reply-To: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
Message-ID: <4lqSkD7QVCiQkecfe_9HY1XLD7-l0OqNLmjTfJ9AgQw=.f11bfd8f-ff3e-454c-a560-6f34637eeb2c@github.com>

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

Marked as reviewed by mchung (Reviewer).

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

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

From iris at openjdk.java.net  Fri Nov  6 21:40:57 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 6 Nov 2020 21:40:57 GMT
Subject: RFR: 8255989: Remove explicitly unascribed authorship from Java
 source files
In-Reply-To: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
Message-ID: <s-NIWpKZrEAHSFtUU4Ebb8O9-eplKij8yJJn5d6PPus=.c3adad62-7973-4f84-af13-eee58210d609@github.com>

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

Marked as reviewed by iris (Reviewer).

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

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

From asemenyuk at openjdk.java.net  Fri Nov  6 22:07:03 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 6 Nov 2020 22:07:03 GMT
Subject: RFR: 8233332: Need to create exploded tests covering all forms of
 modules
Message-ID: <x3sGxQki-zqnyuH2AbS-L55BB31wPNP0iqnytFD1ogo=.2bdd5824-435f-4194-8389-50182593d0f0@github.com>

8233332: Need to create exploded tests covering all forms of modules

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

Commit messages:
 - 8233332: Need to create exploded tests covering all forms of modules
 - 8233332: Need to create exploded tests covering all forms of modules

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

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

From naoto at openjdk.java.net  Fri Nov  6 22:10:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 6 Nov 2020 22:10:11 GMT
Subject: RFR: 8247781: Day periods support [v9]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <W7s-TdlHxXcmpop480lS0hkhJP7JO7aRA2Jkq4Vnxjc=.b4f47eb8-63e3-4055-9ca5-d1f83cd0f34d@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Fixed a comment.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/8054ce6b..3a9ea64a

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

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

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

From coleenp at openjdk.java.net  Fri Nov  6 22:41:06 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 6 Nov 2020 22:41:06 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <cpNCcue6y1OO8obK4QmhiNrdw85BAdAXFLqVbh1RmYc=.ee32d53d-1296-4bd5-8bdd-6632e7ff6af6@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <cpNCcue6y1OO8obK4QmhiNrdw85BAdAXFLqVbh1RmYc=.ee32d53d-1296-4bd5-8bdd-6632e7ff6af6@github.com>
Message-ID: <zQoUYQIxv-d9YTEFZ3oi1CPlJDFWrze3fBQ3LTUX8Ns=.54812730-35b1-4a9e-9e19-29a8f49c45a4@github.com>

On Fri, 6 Nov 2020 21:47:42 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
>> 
>>  - Merge branch '8254162' into 8254231_linker
>>  - Fix post-merge issues caused by 8219014
>>  - Merge branch 'master' into 8254162
>>  - Addess remaining feedback from @AlanBateman and @mrserb
>>  - Address comments from @AlanBateman
>>  - Fix typo in upcall helper for aarch64
>>  - Merge branch '8254162' into 8254231_linker
>>  - Merge branch 'master' into 8254162
>>  - Fix issues with derived buffers and IO operations
>>  - More 32-bit fixes for TestLayouts
>>  - ... and 54 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...b38afb3f
>
> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 81:
> 
>> 79: #endif
>> 80: 
>> 81:   Method* method = k->lookup_method(mname_sym, mdesc_sym);
> 
> This "method" appears unused.

This should be moved into javaClasses or common code.  resolve_or_null only resolves the class, it doesn't also call the initializer for the class so you shouldn't be able to call a static method on the class.

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

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

From coleenp at openjdk.java.net  Fri Nov  6 22:41:05 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Fri, 6 Nov 2020 22:41:05 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
Message-ID: <cpNCcue6y1OO8obK4QmhiNrdw85BAdAXFLqVbh1RmYc=.ee32d53d-1296-4bd5-8bdd-6632e7ff6af6@github.com>

On Thu, 5 Nov 2020 21:26:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
> 
>  - Merge branch '8254162' into 8254231_linker
>  - Fix post-merge issues caused by 8219014
>  - Merge branch 'master' into 8254162
>  - Addess remaining feedback from @AlanBateman and @mrserb
>  - Address comments from @AlanBateman
>  - Fix typo in upcall helper for aarch64
>  - Merge branch '8254162' into 8254231_linker
>  - Merge branch 'master' into 8254162
>  - Fix issues with derived buffers and IO operations
>  - More 32-bit fixes for TestLayouts
>  - ... and 54 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...b38afb3f

src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 58:

> 56: #if 0
> 57:   fprintf(stderr, "upcall_init()\n");
> 58: #endif

There shouldn't be #if 0 debugging code in the final version.

src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 55:

> 53: 
> 54: // FIXME: This should be initialized explicitly instead of lazily/racily
> 55: static void upcall_init() {

The FIXME is right this should be initialized as a well known class and referred to here as SystemDictionary::ProgrammableUpcallHandler_klass().  This really doesn't belong here.

src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 81:

> 79: #endif
> 80: 
> 81:   Method* method = k->lookup_method(mname_sym, mdesc_sym);

This "method" appears unused.

src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 76:

> 74: #endif
> 75: 
> 76:   Klass* k = SystemDictionary::resolve_or_null(cname_sym, THREAD);

pass CATCH if you expect this to never throw an ClassNotFoundException.

src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 68:

> 66:   Symbol* cname_sym = SymbolTable::new_symbol(cname, (int)strlen(cname));
> 67:   Symbol* mname_sym = SymbolTable::new_symbol(mname, (int)strlen(mname));
> 68:   Symbol* mdesc_sym = SymbolTable::new_symbol(mdesc, (int)strlen(mdesc));

You don't need the strlen() argument.

src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 121:

> 119:                          upcall_info.upcall_method.name, upcall_info.upcall_method.sig,
> 120:                          &args, thread);
> 121: }

This code shouldn't be in the cpu directory.  This should be in SharedRuntime or in jni.cpp.  It should have a JNI_ENTRY and not transition directly.  I don't know what AttachCurrentThreadAsDaemon does.

src/hotspot/share/prims/universalNativeInvoker.hpp line 28:

> 26: 
> 27: #include "classfile/javaClasses.hpp"
> 28: #include "classfile/vmSymbols.hpp"

This file doesn't seem to need all of these #include files.

src/hotspot/share/prims/universalNativeInvoker.hpp line 37:

> 35: #ifdef ZERO
> 36: # include "entry_zero.hpp"
> 37: #endif

needed?  Or does the header file that declares ProgrammableStub need this?

src/hotspot/share/prims/universalUpcallHandler.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2018, 2020, Oracle and/or its affiliates. All rights reserved.

New files should only have 2020 even though this might have been checked into a branch before.  There are a bunch of new files that have old copyrights I noticed.

src/hotspot/share/prims/universalUpcallHandler.cpp line 52:

> 50:   guarantee(status == JNI_OK && !env->ExceptionOccurred(),
> 51:             "register jdk.internal.foreign.abi.ProgrammableUpcallHandler natives");
> 52: JNI_END

Why isn't that other function here?

src/hotspot/share/prims/universalUpcallHandler.hpp line 30:

> 28: #include "classfile/vmSymbols.hpp"
> 29: #include "include/jvm.h"
> 30: #include "runtime/frame.inline.hpp"

None of these header files seem to be needed here.

src/hotspot/share/runtime/init.cpp line 40:

> 38: #include "prims/methodHandles.hpp"
> 39: #include "prims/universalNativeInvoker.hpp"
> 40: #include "runtime/globals.hpp"

This looks like the only change so why do you need the #includes?

src/hotspot/share/runtime/thread.hpp line 1574:

> 1572:     return byte_offset_of(JavaThread, _anchor);
> 1573:   }
> 1574: 

blank line, revert this if this is the only change here to avoid conflicts.

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

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

From iignatyev at openjdk.java.net  Sat Nov  7 00:00:56 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Sat, 7 Nov 2020 00:00:56 GMT
Subject: RFR: 8255964: Add all details to jstack log in jtreg timeout
 handler [v2]
In-Reply-To: <UVfJeztUBd6Vigce9KfOz8F4B6CiBzdPoRmzAZrK4AA=.92c7e754-35cb-4ef9-91d8-8d03890243c2@github.com>
References: <DsUVGVtRjQYJjXik8iSra_siW4L2QXZrwjMG9zhBAJY=.2d637062-34c5-4c5e-b7ed-2d4708f16221@github.com>
 <UVfJeztUBd6Vigce9KfOz8F4B6CiBzdPoRmzAZrK4AA=.92c7e754-35cb-4ef9-91d8-8d03890243c2@github.com>
Message-ID: <mCrMj0Axr7eSyXQu3d3nkUL8w0GefT5gLQ42vv-KIaA=.3d7c8cf7-aeb3-47c1-ab37-7cc7774604f3@github.com>

On Fri, 6 Nov 2020 20:25:13 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

>> This patch adds jcmd Thread.print to the jtreg timeout handler.
>> 
>> Please review.
>
> Nils Eliasson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add extended printing to jstack

Marked as reviewed by iignatyev (Reviewer).

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

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

From scolebourne at openjdk.java.net  Sat Nov  7 00:01:58 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Sat, 7 Nov 2020 00:01:58 GMT
Subject: RFR: 8247781: Day periods support [v9]
In-Reply-To: <BVGHbYN8Sp6W49GTct6d5edTJvgx9uVn688oy3VXe1U=.a1393d13-538c-4b3c-82db-e8abd30e297f@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>
 <Tu7yq15XUzC2-z2v40tNUGHkTkYW37q7RUiop9pB4xU=.d61a3059-6929-4b45-8a16-df33469ab56b@github.com>
 <_KS-70pqQG8VavYGtbXCrOlvwfwGl6Nm-lk8SjkEDQI=.1775f0e1-4847-401a-a576-dbb93e080c90@github.com>
 <BVGHbYN8Sp6W49GTct6d5edTJvgx9uVn688oy3VXe1U=.a1393d13-538c-4b3c-82db-e8abd30e297f@github.com>
Message-ID: <_p9FOFl7DOCxiwGk3Ks2OHs-5wbIcPEcFQXBMs0tJfQ=.43913af9-8a74-49ad-9764-89595ecc63fd@github.com>

On Thu, 5 Nov 2020 23:24:19 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> I implemented what you suggested here in the latest PR, but that would be a behavioral change which requires a CSR, as "AM" would be resolved to 06:00 which was not before. Do you think it would be acceptable? If so, I will reopen the CSR and describe the change. (In fact some TCK failed with this impl)
>
> I find the whole "half way between the start and end" behaviour of day periods odd anyway, but if it is to be supported then it should be consistent as you've implemented. 
> 
> Another option I should have thought of earlier would be to simply not support the "half way between the start and end" behaviour of LDML in either dayPeriod or AM/PM. But since LDML defines it, you've implemented it, and it isn't overly harmful I think its OK to leave it in.
> 
> Would it be possible for STRICT mode to not have the "half way between the start and end" behaviour?

I've had a look tonight, but found two more problems!

The comments at the start of `resolveTimeLenient()` indicate that setting the midpoint in `resolveTimeFields()` is a bad idea - it needs to be done inside `resolveTimeLenient()`. (This ensures user-defined fields can resolve to ChronoFields IIRC). Thus, the day period resolving would have to be split between the two methods. How important is the midpoint logic? Could it just be dropped?

Secondly, we need to ensure that "24:00 midnight" (using HOUR_OF_DAY only) correctly parses to the end of day midnight, not the start of day or an exception. This is related to the problem above. 

I _think_ (but haven't confirmed everything yet) that the only thing that should be in `resolveTimeFields()` is the resolution of HOUR_OF_AMPM + dayPeriod to HOUR_OF_DAY (with `dayPeriod` then being set to `null`). Everything else should go in `resolveTimeLenient()` - the midpoint logic in the first if block (where time fields are defaulted), and the validation logic at the end of the method.

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

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

From serb at openjdk.java.net  Sat Nov  7 09:07:54 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Sat, 7 Nov 2020 09:07:54 GMT
Subject: RFR: 8255989: Remove explicitly unascribed authorship from Java
 source files
In-Reply-To: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
Message-ID: <g14KL4Fyv5qtYlqDWXMXBXs9N89kvx2cXl7cUKzwxrE=.0cb3a58a-6e38-4bff-814c-f9a9dbf0b0c5@github.com>

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

Marked as reviewed by serb (Reviewer).

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

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

From github.com+654217+bastie at openjdk.java.net  Sat Nov  7 10:50:00 2020
From: github.com+654217+bastie at openjdk.java.net (Sebastian Ritter)
Date: Sat, 7 Nov 2020 10:50:00 GMT
Subject: RFR: 8066622 8066637: remove deprecated using java.io.File.toURL() in
 internal classes
Message-ID: <EbSZJq5R0_NZWXVivUsn-nJoOwHQCtYwUrUrPOeKa0c=.5877af1b-0db2-4064-bc35-638151ecc774@github.com>

In result of Javadoc to do not use java.io.File.toURL()
Change use  java.io.File.toURL().toURI() instead.

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

Commit messages:
 - in result of Javadoc to java.io.File.toURL do use internal java.io.File.toURL().toURI instead

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

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

From github.com+654217+bastie at openjdk.java.net  Sat Nov  7 10:50:00 2020
From: github.com+654217+bastie at openjdk.java.net (Sebastian Ritter)
Date: Sat, 7 Nov 2020 10:50:00 GMT
Subject: RFR: 8066622 8066637: remove deprecated using
 java.io.File.toURL() in internal classes
In-Reply-To: <EbSZJq5R0_NZWXVivUsn-nJoOwHQCtYwUrUrPOeKa0c=.5877af1b-0db2-4064-bc35-638151ecc774@github.com>
References: <EbSZJq5R0_NZWXVivUsn-nJoOwHQCtYwUrUrPOeKa0c=.5877af1b-0db2-4064-bc35-638151ecc774@github.com>
Message-ID: <imS0Kd5rFXVv5L3eOf2S-1e2MGrtAWGIc_U7Y7s-UZo=.6c74ca73-f6b5-4b3d-a6a2-3c710db25bfd@github.com>

On Sat, 7 Nov 2020 07:55:03 GMT, Sebastian Ritter <github.com+654217+bastie at openjdk.org> wrote:

> In result of Javadoc to do not use java.io.File.toURL()
> Change use  java.io.File.toURL().toURI() instead.

8066622 8066637: only for java.io.File.toURL

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

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

From vlivanov at openjdk.java.net  Sat Nov  7 11:41:58 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Sat, 7 Nov 2020 11:41:58 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v3]
In-Reply-To: <R_wj8HyVj3TBppCLzwfdHTqEJOB4mxFdTmwx4yftKQc=.555c0dff-9826-4772-8421-2228c7a7aa7d@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
 <R_wj8HyVj3TBppCLzwfdHTqEJOB4mxFdTmwx4yftKQc=.555c0dff-9826-4772-8421-2228c7a7aa7d@github.com>
Message-ID: <0P2H9rV2KCehYBo_hE-uYriC_S0YAs_1QOePRcRtQjI=.614ae3b3-316b-4bd9-a547-680acb193d3d@github.com>

On Fri, 6 Nov 2020 08:35:17 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This change add 3 new methods in Objects:
>> 
>> public static long checkIndex(long index, long length)
>> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
>> public static long checkFromIndexSize(long fromIndex, long size, long length)
>> 
>> This mirrors the int utility methods that were added by JDK-8135248
>> with the same motivations.
>> 
>> As is the case with the int checkIndex(), the long checkIndex() method
>> is JIT compiled as an intrinsic. It allows the JIT to compile
>> checkIndex to an unsigned comparison and properly recognize it as
>> a range check that then becomes a candidate for the existing range check
>> optimizations. This has proven to be important for panama's
>> MemorySegment API and a prototype of this change (with some extra c2
>> improvements) showed that panama micro benchmark results improve
>> significantly.
>> 
>> This change includes:
>> 
>> - the API change
>> - the C2 intrinsic
>> - tests for the API and the C2 intrinsic
>> 
>> This is a joint work with Paul who reviewed and reworked the API change
>> and filled the CSR.
>
> Roland Westrelin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   intrinsic comments

Marked as reviewed by vlivanov (Reviewer).

src/hotspot/share/opto/castnode.cpp line 100:

> 98:   }
> 99:   case Op_CastLL: {
> 100:     assert(!carry_dependency, "carry dependency not supported");

Any particular reason to reject control dependency (except it is not used right now)?

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

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

From prappo at openjdk.java.net  Sat Nov  7 11:52:08 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Sat, 7 Nov 2020 11:52:08 GMT
Subject: RFR: 8255989: Remove explicitly unascribed authorship from Java
 source files [v2]
In-Reply-To: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
Message-ID: <TDJhHLH1pPKaWtmDP2vjWa5Fq7SiikXPslLW_F09-HM=.f706d3b9-4053-46d1-9d9f-d156cf2cceff@github.com>

> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

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

 - Merge branch 'master' into 8255989
 - Initial commit

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1100/files
  - new: https://git.openjdk.java.net/jdk/pull/1100/files/9f9b0a85..830ffafb

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

  Stats: 192 lines in 9 files changed: 28 ins; 64 del; 100 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1100.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1100/head:pull/1100

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

From prappo at openjdk.java.net  Sat Nov  7 12:09:55 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Sat, 7 Nov 2020 12:09:55 GMT
Subject: RFR: 8255989: Remove explicitly unascribed authorship from Java
 source files [v2]
In-Reply-To: <g14KL4Fyv5qtYlqDWXMXBXs9N89kvx2cXl7cUKzwxrE=.0cb3a58a-6e38-4bff-814c-f9a9dbf0b0c5@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
 <g14KL4Fyv5qtYlqDWXMXBXs9N89kvx2cXl7cUKzwxrE=.0cb3a58a-6e38-4bff-814c-f9a9dbf0b0c5@github.com>
Message-ID: <yIaBasqWPzIV7U0vBcoO6n0PXATYFnvHcSQaKn9PNTg=.af66d989-b606-4fbc-b298-e74867c518e0@github.com>

On Sat, 7 Nov 2020 09:05:29 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into 8255989
>>  - Initial commit
>
> Marked as reviewed by serb (Reviewer).

Thanks to all the reviewers, this may be now integrated.

For extra confidence, I went to https://openjdk.java.net/census and checked that there are no authors whose name is one of "unascribed", "unattributed", or "unknown". I did this because some words might not be what they seem: for example, see https://stackoverflow.com/questions/4456438/how-to-pass-null-a-real-surname-to-a-soap-web-service-in-actionscript-3

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

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

From prappo at openjdk.java.net  Sat Nov  7 12:14:56 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Sat, 7 Nov 2020 12:14:56 GMT
Subject: Integrated: 8255989: Remove explicitly unascribed authorship from
 Java source files
In-Reply-To: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
References: <RA3aaIhpReG9FDbcJG9rgA5h20UYmW1Fah4-tkkPN4A=.48c47879-685c-4192-9b12-bb6dce702aa9@github.com>
Message-ID: <kRuRluhvztusqU-jT53kBjdKy9hzaK4WAFrcaFjMak4=.d2d77e82-ada8-4c97-99d6-7987c7746d2b@github.com>

On Fri, 6 Nov 2020 20:11:24 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This PR proposes to remove
> 1. JavaDoc `@author` tags with unclear semantics: `@author unascribed|unattributed|unknown`
> 2. A couple of astray Form Feed (a.k.a. FF, `\f`,  `0xC`, or `^L`) characters

This pull request has now been integrated.

Changeset: c5462bb9
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c5462bb9
Stats:     140 lines in 77 files changed: 0 ins; 80 del; 60 mod

8255989: Remove explicitly unascribed authorship from Java source files

Reviewed-by: redestad, mr, mchung, iris, serb

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

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

From Marius at volkhart.com  Sat Nov  7 19:11:39 2020
From: Marius at volkhart.com (Marius Volkhart)
Date: Sat, 7 Nov 2020 20:11:39 +0100
Subject: Fix: javax.xml.XMLEventReader produces incorrect START_DOCUMENT event
Message-ID: <CAEi2yB_hd9ieug7WadpwrSgzyKz+ZsdwqD2OdQ6Fnw-8aG6p5Q@mail.gmail.com>

Hello,

I've submitted a PR https://github.com/openjdk/jdk/pull/1056 for what I
believe to be a bug I found in the javax.xml module. An issue for this
behavior does not exist in the bug tracker.

The default implementation of javax.xml.stream.XMLEventReader produces a
StartDocument event that always indicates that the "standalone" attribute
was set in the original document.

The root cause of this is that the
com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the
"standalone" attribute, rather than asking streamReader.standaloneSet()
before setting the property of the StartDocumentEvent being created.

--
Cheers,
Marius Volkhart

From hshi at openjdk.java.net  Sun Nov  8 05:07:07 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Sun, 8 Nov 2020 05:07:07 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v2]
In-Reply-To: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
Message-ID: <pLjfXREv5ofhOmaYMK_9UZ7uqCgGOlgM9SRdaSfXD2w=.6e6503d8-e782-44ce-9fc1-32e716823b78@github.com>

> ?AccessorImpl object
> 
> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
> 
> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
> 
> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.

Hui Shi 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:

  8255883: Avoid multiple GeneratedAccessor for same NativeMethod/ConstructorAccessorImpl object

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1070/files
  - new: https://git.openjdk.java.net/jdk/pull/1070/files/94390613..8f65047e

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

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

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

From hshi at openjdk.java.net  Sun Nov  8 05:24:59 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Sun, 8 Nov 2020 05:24:59 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v2]
In-Reply-To: <wllRvEUkKyTEFAmShdMQsLf5yMaL7TUIiS_SEDPptE0=.2042cc3b-8bde-4229-b198-76485f0647f6@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <6914QI9MySYQ4-Lpt_OIzMBbyFGRTYnPTLGJpIfBdQI=.57041221-95ea-44eb-90a6-57789597f741@github.com>
 <wllRvEUkKyTEFAmShdMQsLf5yMaL7TUIiS_SEDPptE0=.2042cc3b-8bde-4229-b198-76485f0647f6@github.com>
Message-ID: <82Ivxe4SYYss0V1jS1oKXP2ahCft43uCw8Fi-XB_ITc=.640f63f4-aacc-460a-9e3d-cf8aa5ad0ad6@github.com>

On Thu, 5 Nov 2020 14:59:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I do wonder if it makes sense to handle triple-state `int` here: "not yet generated", "generated", "in error"? So that we don't try to generate the accessor over and over again when it is in error?
>
> If we are changing NativeMethodAccessorImpl.invoke then we should probably do NativeConstructorAccessorImpl.newInstance at the same time. Also wondering if we should, while in the area, add "return acc.invoke(obj, args)" after setting the delegate so that it invokes the newly generated accessor.
> 
> Are there resource or other cases that you have observed where generateMethod fails and then succeeds in a subsequent call?
> 
> @cl4es Do you know of any startup tests that might be sensitive to the eager creating of a VarHandle?
> 
> I agree with @shipilev to test before the CAS.

@AlanBateman @shipilev  commit is updated, please help reivew it again

1.  add same change in NativeConstructorAccessorImpl
2.  eager creating of a VarHandle in both NativeConstructorAccessorImpl and NativeMethodAccessorImpl will cause error. [http://cr.openjdk.java.net/~hshi/8255883/cyclic_clinit_dependency.txt](url).  Use unsafe API here. 
3.  add test before compareAndSet and remove "succ" variable.

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

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

From alanb at openjdk.java.net  Sun Nov  8 08:12:56 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 8 Nov 2020 08:12:56 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator)
In-Reply-To: <-u4eSM47o_e_KlfTRYBNGyLNhjqAeG-84u_uEd3ppH0=.c49b4269-1001-49d1-96fd-ecacbf2417e9@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <pS93Tkclki7y3uzfofkeCRZiZV8Wbb0fpPTI4aOHZXA=.b467ed27-1874-4302-833d-e022ef913dbb@github.com>
 <gKyi3UsqpyQ6bWnRX3JIEsc5-4SEMZmHLFdz0gRgRoY=.2b655f9f-551c-4454-9f21-1c9dbf2dcc24@github.com>
 <wW7_WrOpEbYNHP12tT3x2ujcGAl2O35RyZud9SY_43w=.7848a0e3-0015-408e-9dd0-44ab545c7465@github.com>
 <x0QEmnZ93qnHvRh3E1Vnudm-RseXooykHXD4X3FeNkA=.9c63d73e-c20e-4219-a1a4-1126aa55085f@github.com>
 <-u4eSM47o_e_KlfTRYBNGyLNhjqAeG-84u_uEd3ppH0=.c49b4269-1001-49d1-96fd-ecacbf2417e9@github.com>
Message-ID: <Mtctoo2gT4Tgsja1L7yvBmyyhRLUTkWQ187CUkCYLnc=.388c82a9-ea24-465f-bde8-d2cfa949e46d@github.com>

On Wed, 4 Nov 2020 07:45:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> The javadoc for copyFrom isn't changed in this update but I notice it specifies IndexOutOfBoundException when the source segment is larger than the receiver, have other exceptions been examined?
>> 
>> This exception is consistent with other uses of this exception throughout this API (e.g. when writing a segment out of bounds).
>
> I assume the CSR needs to be updated so that it's in sync with the API changes in the latest round.

I see the xxxByteAtIndex methods that took a ByteOrder have been removed from MemoryAccess. Should the xxxByte and xxxByteAtOffset that take a ByteOrder be removed too?

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

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

From mayankbansal933 at gmail.com  Sun Nov  8 10:22:01 2020
From: mayankbansal933 at gmail.com (mayank bansal)
Date: Sun, 8 Nov 2020 15:52:01 +0530
Subject: Class TreeMap<K,V> | Lower and Upper Count Support
Message-ID: <CAPHdF1n1vbCWT=cOQD8X0DSKYAvFg=ZbrXg5Uju7+kxhOEhEeA@mail.gmail.com>

Hi Everyone,

I would like to propose and work on a feature request of supporting the
lower and higher count in java class TreeMap.
"lower count" is the number of elements that are strictly less than the
given value.
"upper count" is the number of elements that are strictly greater than the
given value.

*Method definitions-*
int getLowerCount(K key);
int getHigherCount(K key);

*Follow-up feature -*
Class TreeSet<E> constructor initializes the TreeMap<K,V> in the TreeSet
constructor.
It puts the dummy value as *new Object()* whenever we add the entry in
TreeSet.
I would like to work on the feature to provide the *Duplicate count* in
case of the same Key and the same Value.

I will be happy to work on both and raise a PR. I need some guidance if the
proposed feature looks good and I can start working on it and also would
like to know about the process whether I can directly raise the PR.

Thanks
-- 
Regards,
Mayank Bansal

From forax at univ-mlv.fr  Sun Nov  8 10:39:30 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 8 Nov 2020 11:39:30 +0100 (CET)
Subject: Class TreeMap<K,V> | Lower and Upper Count Support
In-Reply-To: <CAPHdF1n1vbCWT=cOQD8X0DSKYAvFg=ZbrXg5Uju7+kxhOEhEeA@mail.gmail.com>
References: <CAPHdF1n1vbCWT=cOQD8X0DSKYAvFg=ZbrXg5Uju7+kxhOEhEeA@mail.gmail.com>
Message-ID: <1632913677.1674462.1604831970061.JavaMail.zimbra@u-pem.fr>

Is it different from
 headMap(key, true).size() / tailMap(key, true).size() ?

https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#headMap(K,boolean)
https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#tailMap(K,boolean)

cheers,
R?mi

----- Mail original -----
> De: "mayank bansal" <mayankbansal933 at gmail.com>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Dimanche 8 Novembre 2020 11:22:01
> Objet: Class TreeMap<K,V> | Lower and Upper Count Support

> Hi Everyone,
> 
> I would like to propose and work on a feature request of supporting the
> lower and higher count in java class TreeMap.
> "lower count" is the number of elements that are strictly less than the
> given value.
> "upper count" is the number of elements that are strictly greater than the
> given value.
> 
> *Method definitions-*
> int getLowerCount(K key);
> int getHigherCount(K key);
> 
> *Follow-up feature -*
> Class TreeSet<E> constructor initializes the TreeMap<K,V> in the TreeSet
> constructor.
> It puts the dummy value as *new Object()* whenever we add the entry in
> TreeSet.
> I would like to work on the feature to provide the *Duplicate count* in
> case of the same Key and the same Value.
> 
> I will be happy to work on both and raise a PR. I need some guidance if the
> proposed feature looks good and I can start working on it and also would
> like to know about the process whether I can directly raise the PR.
> 
> Thanks
> --
> Regards,
> Mayank Bansal

From plevart at openjdk.java.net  Sun Nov  8 10:50:57 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 8 Nov 2020 10:50:57 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v2]
In-Reply-To: <hhibYsPaakZXBiorfc_4a2T6Y0fwkHATDT49wamF5QU=.4b4549f7-863d-4902-a34c-7648d806d4fd@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <aBcWsV_NhVd3jaVqcC-TKl38hWXUmEIrSUmsYPPF88g=.2b4b7d94-a3cc-4fc0-a9e7-defa360ee3a0@github.com>
 <zNl6puL1sy_S1JWp3tLiQQf2YrhHvHY3GtGIBjtfz7E=.5eb94743-bfbb-4908-a2af-e9aceb22c9d3@github.com>
 <VeEg7hCJwqiJ8eqvlPLb9Oi6eNx-pgOqTzwshgb01jk=.5169c749-c176-438b-adc2-9e94921aa7c2@github.com>
 <hhibYsPaakZXBiorfc_4a2T6Y0fwkHATDT49wamF5QU=.4b4549f7-863d-4902-a34c-7648d806d4fd@github.com>
Message-ID: <ItQDJF_yBhjEKceLh1skwy3tYtIY5T_TxOQX0h6nYBI=.0503f471-5876-4448-80b3-968a16f38293@github.com>

On Fri, 6 Nov 2020 03:05:45 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> @ePaul wrote:
>> 
>>> The Stream API works just as well with [third party] collection libraries instead of the java.util ones, just using different collectors. Adding a method which directly returns a java.util.List somewhat couples it to the Java Collection API.
>>> 
>>> Now this was mentioned two and a half year ago. Did something change which made this consideration irrelevant? I would expect at least some mention of it in the discussion here.
>> 
>> The separation between streams and the java.util Collections Framework is a good design principle, but it isn't an ironclad rule. It's still easy to have streams create instances of other collections libraries using the Collector interface. What's different here is that the Collections Framework has "leaked into" streams a little bit more, so that they're now more interdependent. This doesn't seem to have any disadvantages; it seems unlikely that the Collections Framework will ever be unplugged from the JDK. However, the benefits are that a List is the closest thing we have to an unmodifiable array that also plays well with generics and that can be value-based; these benefits are considerable.
>
>> Simon Roberts wrote:
> 
>> This discussion of unmodifiable lists brings me back to the thought that
>> there would be good client-side reasons for inserting an UnmodifiableList
>> interface as a parent of LIst, not least because all our unmodifiable
>> variants from the Collections.unmodifiableList proxy onward fail the Liskov
>> substitution test for actually "being contract-fulfilling Lists".
> 
> At some point there probably will need to be a long article explaining all the issues here, but at the moment the best writeup I have is this one:
> 
> https://stackoverflow.com/a/57926310/1441122
> 
> TL;DR there are a few different ways to approach retrofitting something like this, but they all have enough compromises that the net benefits are unclear.

Hi Stuart,

I would like to discuss the serialization. You introduce new CollSer.IMM_LIST_NULLS type of immutable collection. This means that if this change goes into JDK16 for example, JDK15 and before will not be able to deserialize such list as they know nothing about IMM_LIST_NULLS even if such lists don't contain nulls. The reason you say to chose new type of serialization format is the following:

> "Suppose I had an application that created a data structure that used lists from List.of(), and I had a global assertion over that structure that it contained no nulls. Further suppose that I serialized and deserizalized this structure. I'd want that assertion to be preserved after deserialization. If another app (or a future version of this app) created the structure using Stream.to
>  List(), this would allow nulls to leak into that structure and violate that assertion. Therefore, the result of Stream.toList() should not be serialization-compatible with List.of() et. al. That's why there's the new IMM_LIST_NULLS tag in the serial format"

I don't quite get this reasoning. Let's try to decompose the reasoning giving an example. Suppose we had the following data structure:

public class Names implements Serializable {
  private final List<String> names;
  Names(List<String> names) {
    this.names = names;
  }
  public List<String> names() { return names; }
}

App v1 creates such structures using new Names(List.of(...)) and serializes/deserializes them. They keep the invariant that no nulls are present. Now comes App v2 that starts using new Names(stream.toList()) which allows nulls to be present. When such Names instance from app v2 is serialized and then deserialized in app v1, nulls "leak" into data structure of app v1 that does not expect them.

But the question is how does having a separate CollSer.IMM_LIST_NULLS type prevent that from happening?

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

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

From forax at univ-mlv.fr  Sun Nov  8 11:32:41 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 8 Nov 2020 12:32:41 +0100 (CET)
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <901940D3-DA82-4C1F-A24A-7799A0D14884@cbfiddle.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <bUKuBU0ScUvhnCa-rUjJDUCPUfcPmS-OqMXyTSBsUeU=.2430a5a0-076e-4f16-9d1d-0dfa49faa99d@github.com>
 <4CY9WKRujRFgx526Z2joGTNdI4OGIJUI9omHgMnhReg=.8bf6e1d5-8ba9-4f7c-80bf-8adde581a9f6@github.com>
 <CADsQA7hbZZdcDsVX1csqYJwi8Nnv-vxLbcN2gc+W+of0+-dAKA@mail.gmail.com>
 <1681654584.871831.1604654062322.JavaMail.zimbra@u-pem.fr>
 <901940D3-DA82-4C1F-A24A-7799A0D14884@cbfiddle.com>
Message-ID: <2098168537.1695995.1604835161502.JavaMail.zimbra@u-pem.fr>

> De: "Alan Snyder" <fishgarage at cbfiddle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Simon Roberts" <simon at dancingcloudservices.com>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoy?: Vendredi 6 Novembre 2020 18:55:40
> Objet: Re: RFR: 8180352: Add Stream.toList() method
Hi Alan, 

>>> This discussion of unmodifiable lists brings me back to the thought that
>>> there would be good client-side reasons for inserting an UnmodifiableList
>>> interface as a parent of LIst
>> On Nov 6, 2020, at 1:14 AM, Remi Forax < [ mailto:forax at univ-mlv.fr |
>> forax at univ-mlv.fr ] > wrote:

>> This question is asked at least every six months since 1998
>> [
>> https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html#a1
>> |
>> https://docs.oracle.com/javase/8/docs/technotes/guides/collections/designfaq.html#a1
>> ]

> The question that Simon asked is not exactly the question that is answered in
> this link.

> The question of whether List should be a subtype of (some kind of) ImmutableList
> is answered in
> Stuart?s stack overflow answer ( [ https://stackoverflow.com/a/57926310/1441122
> | https://stackoverflow.com/a/57926310/1441122 ] ). The answer
> is that it should not.

> The question answered in the link is basically a straw man: why not capture
> every conceivable
> semantic distinction in the collections type system. And the answer is, not
> surprisingly, that
> there would be way too many types.

It's a strawman but the effect is real, the more interfaces you have the less you can reuse code because the code is written with the wrong interface for your use case. 

> But a question that deserves ongoing review is whether Java should support
> immutable collections
> using a separate type hierarchy. In other words, Immutable List would not be a
> subtype of List
> and List would not be a subtype of Immutable List. The linked answer says:
> " Adding this support to the type hierarchy requires four more interfaces.? Four
> additional
> interfaces sounds like a small cost for a significant benefit. As Java evolves
> to better support
> functional programming styles, immutable collections seems like an obvious next
> step.

> Much could be written, and probably has been, about the disadvantages of basing
> the
> collections framework on mutable collections. Let me just remark that in
> addition to the
> already mentioned UnsupportedOperationException, there is also the more subtle
> ConcurrentModificationException, both of which would be absent in fully
> immutable collections.

Following the same reasoning, you can say that having interfaces saying that collections are null hostile is even more important because it alleviate the issue with NullPointerException. 

> The lack of subtyping between List and ImmutableList is not terrible. Arrays
> coexist with
> Lists with no subtyping relationship. java.io.File coexists with
> java.nio.filePath with no
> subtyping relationship. It means that explicit conversions are required between
> List and
> ImmutableList. Extra copying may be needed, but there are tricks for reducing
> copying, and the
> need for defensive copying is removed.

Array vs List is not something we can be very proud of, by example in java.lang.invoke, we have several methods that are duplicated only because of this dichotomy. 
File vs Path is less an issue because it's between implementation classes, not interfaces, anyway, you still have a number of methods inside java.io/java.nio that are duplicated. 

Anyway, I don't think we can *all* agree about how a collection API should be implemented because it is equivalent to answering to the question what you want to be part of the type system and what you want to be runtime exceptions. 
With that in minde, Java is in the middle between Clojure and Scala. 

> Alan

R?mi 

From michael.edgar at gmail.com  Sun Nov  8 11:45:56 2020
From: michael.edgar at gmail.com (Michael Edgar)
Date: Sun, 8 Nov 2020 06:45:56 -0500
Subject: Filtered XMLStreamReader Exceptions (java.xml)
In-Reply-To: <880cf7c4-878a-9068-646f-4dbc026f355f@oracle.com>
References: <CAJ9fJk4dF8H1M23xv6L2cacB8epxg1WOsPsX7sRZ=MrAS23aXw@mail.gmail.com>
 <1bef2d11-0e3f-944a-4fd7-7b1a8524f9a1@oracle.com>
 <CAJ9fJk7DbWjAtDJj6-pyny1+o87SA2QNUjCKS55-Wv+k8LtNGw@mail.gmail.com>
 <880cf7c4-878a-9068-646f-4dbc026f355f@oracle.com>
Message-ID: <CAJ9fJk6o2s_uiO6hrHF6XbnDs9PUEA4-SSag2SdCZ85b0ZKEow@mail.gmail.com>

Hi Joe,

This is the first issue I have worked on with openjdk so I assume I will
need a sponsor (I do not have a JBS account). Regarding the PR, I am not
familiar with the Skara process. Is there anything I need to know beyond
the typical GitHub PR process?

Thanks,
Mike


On Thu, Nov 5, 2020 at 8:22 PM Joe Wang <huizhe.wang at oracle.com> wrote:

> Hi Mike,
>
> I saw that you are on the OCA list but not census
> <https://openjdk.java.net/census>, I therefore assumed you'd need a
> sponsor, or would you?  Let me know if I'm mistaken. If you're an openjdk
> author/committer and have a JBS account, please go ahead take over the bug
> and create a CSR. Creating a CSR is straight-forward: from the JBS bug,
> click more -> create CSR and follow the template.
>
> You mentioned you're going to submit a PR. Are you familiar with the Skara
> process or have you already done it?
>
> Thanks,
> Joe
>
> On 11/5/20 1:35 PM, Michael Edgar wrote:
>
> The bug for this issue was accepted: JDK-8255918. I have made the change
> that I suggested in my original email and tested, but have not yet opened a
> pull request. Please let me know what (if anything) needs to occur for the
> CSR process due to the method signature change (added `throws`).
>
> Thank you,
> Mike
>
>
> On Wed, Oct 28, 2020 at 12:52 PM Joe Wang <huizhe.wang at oracle.com> wrote:
>
>> Hi Mike,
>>
>> As you said, creating a bug report would be a good start. If it involves
>> a signature change, it'd need to go through a proper review (CSR) process.
>>
>> When you are ready to submit a bug report, please make sure to add a
>> test case to illustrate the use case scenario.
>>
>> Thanks,
>> Joe
>>
>> On 10/28/20 5:14 AM, Michael Edgar wrote:
>> > Hi everyone,
>> > I'm working on a project that makes use of the StAX API and an issue I
>> have
>> > encountered is that when wrapping an `XMLStreamReader` with a
>> > `StreamFilter`, errors encountered in the setup are not thrown to the
>> > caller. The source of the error could be any stream error that is
>> triggered
>> > as the `XMLStreamFilterImpl` advances to the next acceptable event.
>> > Ultimately, when attempting to utilize the filtered reader, some
>> secondary
>> > exception will occur, but the original `Exception` is lost.
>> >
>> > I have not seen any other issues related specifically to this problem,
>> so I
>> > would like to propose removal of the try/catch in the constructor of
>> > `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl` and the
>> > method signature changed to declare that `XMLStreamException` is thrown.
>> > The constructor is used by
>> >
>> `com.sun.xml.internal.stream.XMLInputFactoryImpl.createFilteredReader(XMLStreamReader,
>> > StreamFilter)` which itself already declares the same exception and is
>> an
>> > implementation of the public `XMLInputFactory` interface.
>> >
>> > Further, the `nextTag` method of the same class has a bug where it
>> checks
>> > for `START_ELEMENT` events twice.
>> >
>> > I have an OCA in place and I am happy to submit a PR, but I believe
>> that a
>> > bug record needs to be opened in order to proceed.
>> >
>> > Thank you,
>> > Mike
>>
>>
>

From mayankbansal933 at gmail.com  Sun Nov  8 11:55:09 2020
From: mayankbansal933 at gmail.com (mayank bansal)
Date: Sun, 8 Nov 2020 17:25:09 +0530
Subject: Class TreeMap<K,V> | Lower and Upper Count Support
In-Reply-To: <1632913677.1674462.1604831970061.JavaMail.zimbra@u-pem.fr>
References: <CAPHdF1n1vbCWT=cOQD8X0DSKYAvFg=ZbrXg5Uju7+kxhOEhEeA@mail.gmail.com>
 <1632913677.1674462.1604831970061.JavaMail.zimbra@u-pem.fr>
Message-ID: <CAPHdF1kCofUhjuDiyfnkwGYy3TuQgX2k5-7wiFPveKNvF-Mwyw@mail.gmail.com>

Hi Remi,

Thank you for pointing that out. This is providing the same feature but it
is not the optimal approach for calculating the size.

AscendingSubMap().size() is actually iterating each and every element using
Iterator to calculate the size resulting in the O(N) time complexity which
can be reduced to O(logN) and this will be a huge improvement. Code snippet
for the reference -
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/TreeMap.java#L1937-L1950

I am coming from the fact that I was trying to solve one coding problem, I
tried using own Balanced BST
<https://leetcode.com/submissions/detail/418028305/> (AVL tree) and it
executed in ~180ms and when I tried using TreeSet headSet().size()
<https://leetcode.com/submissions/detail/418070375/>, it resulted in a TLE
- Time Limit Exceeded.



On Sun, Nov 8, 2020 at 4:09 PM Remi Forax <forax at univ-mlv.fr> wrote:

> Is it different from
>  headMap(key, true).size() / tailMap(key, true).size() ?
>
>
> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#headMap(K,boolean)
>
> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#tailMap(K,boolean)
>
> cheers,
> R?mi
>
> ----- Mail original -----
> > De: "mayank bansal" <mayankbansal933 at gmail.com>
> > ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > Envoy?: Dimanche 8 Novembre 2020 11:22:01
> > Objet: Class TreeMap<K,V> | Lower and Upper Count Support
>
> > Hi Everyone,
> >
> > I would like to propose and work on a feature request of supporting the
> > lower and higher count in java class TreeMap.
> > "lower count" is the number of elements that are strictly less than the
> > given value.
> > "upper count" is the number of elements that are strictly greater than
> the
> > given value.
> >
> > *Method definitions-*
> > int getLowerCount(K key);
> > int getHigherCount(K key);
> >
> > *Follow-up feature -*
> > Class TreeSet<E> constructor initializes the TreeMap<K,V> in the TreeSet
> > constructor.
> > It puts the dummy value as *new Object()* whenever we add the entry in
> > TreeSet.
> > I would like to work on the feature to provide the *Duplicate count* in
> > case of the same Key and the same Value.
> >
> > I will be happy to work on both and raise a PR. I need some guidance if
> the
> > proposed feature looks good and I can start working on it and also would
> > like to know about the process whether I can directly raise the PR.
> >
> > Thanks
> > --
> > Regards,
> > Mayank Bansal
>


-- 
Regards,
Mayank Bansal

From forax at univ-mlv.fr  Sun Nov  8 12:08:34 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Sun, 8 Nov 2020 13:08:34 +0100 (CET)
Subject: Class TreeMap<K,V> | Lower and Upper Count Support
In-Reply-To: <CAPHdF1kCofUhjuDiyfnkwGYy3TuQgX2k5-7wiFPveKNvF-Mwyw@mail.gmail.com>
References: <CAPHdF1n1vbCWT=cOQD8X0DSKYAvFg=ZbrXg5Uju7+kxhOEhEeA@mail.gmail.com>
 <1632913677.1674462.1604831970061.JavaMail.zimbra@u-pem.fr>
 <CAPHdF1kCofUhjuDiyfnkwGYy3TuQgX2k5-7wiFPveKNvF-Mwyw@mail.gmail.com>
Message-ID: <1952229439.1712458.1604837314184.JavaMail.zimbra@u-pem.fr>

> De: "mayank bansal" <mayankbansal933 at gmail.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Dimanche 8 Novembre 2020 12:55:09
> Objet: Re: Class TreeMap<K,V> | Lower and Upper Count Support

> Hi Remi,
> Thank you for pointing that out. This is providing the same feature but it is
> not the optimal approach for calculating the size.

> AscendingSubMap().size() is actually iterating each and every element using
> Iterator to calculate the size resulting in the O(N) time complexity which can
> be reduced to O(logN) and this will be a huge improvement. Code snippet for the
> reference - [
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/TreeMap.java#L1937-L1950
> |
> https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/TreeMap.java#L1937-L1950
> ]

> I am coming from the fact that I was trying to solve one coding problem, I tried
> using own [ https://leetcode.com/submissions/detail/418028305/ | Balanced BST ]
> (AVL tree) and it executed in ~180ms and when I tried using [
> https://leetcode.com/submissions/detail/418070375/ | TreeSet headSet().size() ]
> , it resulted in a TLE - Time Limit Exceeded.

Interesting, I've always though that all collections of java.util had a size() implementation in O(1). 
It may be worth fixing this if there is a simple fix. 

One issue with TreeMap is that unlike most of the other implementations, TreeMap is not used a lot so we are still discovering issues. 

R?mi 

> On Sun, Nov 8, 2020 at 4:09 PM Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>> Is it different from
>> headMap(key, true).size() / tailMap(key, true).size() ?

>> [
>> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#headMap(K,boolean)
>> |
>> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#headMap(K,boolean)
>> ]
>> [
>> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#tailMap(K,boolean)
>> |
>> https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/util/NavigableMap.html#tailMap(K,boolean)
>> ]

>> cheers,
>> R?mi

>> ----- Mail original -----
>>> De: "mayank bansal" < [ mailto:mayankbansal933 at gmail.com |
>> > mayankbansal933 at gmail.com ] >
>>> ?: "core-libs-dev" < [ mailto:core-libs-dev at openjdk.java.net |
>> > core-libs-dev at openjdk.java.net ] >
>> > Envoy?: Dimanche 8 Novembre 2020 11:22:01
>> > Objet: Class TreeMap<K,V> | Lower and Upper Count Support

>> > Hi Everyone,

>> > I would like to propose and work on a feature request of supporting the
>> > lower and higher count in java class TreeMap.
>> > "lower count" is the number of elements that are strictly less than the
>> > given value.
>> > "upper count" is the number of elements that are strictly greater than the
>> > given value.

>> > *Method definitions-*
>> > int getLowerCount(K key);
>> > int getHigherCount(K key);

>> > *Follow-up feature -*
>> > Class TreeSet<E> constructor initializes the TreeMap<K,V> in the TreeSet
>> > constructor.
>> > It puts the dummy value as *new Object()* whenever we add the entry in
>> > TreeSet.
>> > I would like to work on the feature to provide the *Duplicate count* in
>> > case of the same Key and the same Value.

>> > I will be happy to work on both and raise a PR. I need some guidance if the
>> > proposed feature looks good and I can start working on it and also would
>> > like to know about the process whether I can directly raise the PR.

>> > Thanks
>> > --
>> > Regards,
>> > Mayank Bansal

> --
> Regards,
> Mayank Bansal

From plevart at openjdk.java.net  Sun Nov  8 16:00:56 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Sun, 8 Nov 2020 16:00:56 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v2]
In-Reply-To: <ItQDJF_yBhjEKceLh1skwy3tYtIY5T_TxOQX0h6nYBI=.0503f471-5876-4448-80b3-968a16f38293@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <aBcWsV_NhVd3jaVqcC-TKl38hWXUmEIrSUmsYPPF88g=.2b4b7d94-a3cc-4fc0-a9e7-defa360ee3a0@github.com>
 <zNl6puL1sy_S1JWp3tLiQQf2YrhHvHY3GtGIBjtfz7E=.5eb94743-bfbb-4908-a2af-e9aceb22c9d3@github.com>
 <VeEg7hCJwqiJ8eqvlPLb9Oi6eNx-pgOqTzwshgb01jk=.5169c749-c176-438b-adc2-9e94921aa7c2@github.com>
 <hhibYsPaakZXBiorfc_4a2T6Y0fwkHATDT49wamF5QU=.4b4549f7-863d-4902-a34c-7648d806d4fd@github.com>
 <ItQDJF_yBhjEKceLh1skwy3tYtIY5T_TxOQX0h6nYBI=.0503f471-5876-4448-80b3-968a16f38293@github.com>
Message-ID: <Y71HRQPKV6Uc-_6PkgZWl97d3bHhu4BmQjE_pL8MEmA=.f6ab9972-7ed4-41fc-8dcf-c5286b0062fb@github.com>

On Sun, 8 Nov 2020 10:47:08 GMT, Peter Levart <plevart at openjdk.org> wrote:

>>> Simon Roberts wrote:
>> 
>>> This discussion of unmodifiable lists brings me back to the thought that
>>> there would be good client-side reasons for inserting an UnmodifiableList
>>> interface as a parent of LIst, not least because all our unmodifiable
>>> variants from the Collections.unmodifiableList proxy onward fail the Liskov
>>> substitution test for actually "being contract-fulfilling Lists".
>> 
>> At some point there probably will need to be a long article explaining all the issues here, but at the moment the best writeup I have is this one:
>> 
>> https://stackoverflow.com/a/57926310/1441122
>> 
>> TL;DR there are a few different ways to approach retrofitting something like this, but they all have enough compromises that the net benefits are unclear.
>
> Hi Stuart,
> 
> I would like to discuss the serialization. You introduce new CollSer.IMM_LIST_NULLS type of immutable collection. This means that if this change goes into JDK16 for example, JDK15 and before will not be able to deserialize such list as they know nothing about IMM_LIST_NULLS even if such lists don't contain nulls. The reason you say to chose new type of serialization format is the following:
> 
>> "Suppose I had an application that created a data structure that used lists from List.of(), and I had a global assertion over that structure that it contained no nulls. Further suppose that I serialized and deserizalized this structure. I'd want that assertion to be preserved after deserialization. If another app (or a future version of this app) created the structure using Stream.to
>>  List(), this would allow nulls to leak into that structure and violate that assertion. Therefore, the result of Stream.toList() should not be serialization-compatible with List.of() et. al. That's why there's the new IMM_LIST_NULLS tag in the serial format"
> 
> I don't quite get this reasoning. Let's try to decompose the reasoning giving an example. Suppose we had the following data structure:
> 
> public class Names implements Serializable {
>   private final List<String> names;
>   Names(List<String> names) {
>     this.names = names;
>   }
>   public List<String> names() { return names; }
> }
> 
> App v1 creates such structures using new Names(List.of(...)) and serializes/deserializes them. They keep the invariant that no nulls are present. Now comes App v2 that starts using new Names(stream.toList()) which allows nulls to be present. When such Names instance from app v2 is serialized and then deserialized in app v1, nulls "leak" into data structure of app v1 that does not expect them.
> 
> But the question is how does having a separate CollSer.IMM_LIST_NULLS type prevent that from happening?

I can see that having a separate IMM_LIST_NULLS type might be necessary to preserve the allows-null/disallows-null behaviour of indexOf and lastIndexOf methods...

NOTE ALSO that while ListN.equals(o) method is using Objects.equals(o1, o2) to compare elements, hashCode is inherited from AbstractImmutableList:

        public int hashCode() {
            int hash = 1;
            for (int i = 0, s = size(); i < s; i++) {
                hash = 31 * hash + get(i).hashCode();
            }
            return hash;
        }

...which means it will throw NPE when the list contains null. The same goes for SubList.

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

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

From alanb at openjdk.java.net  Sun Nov  8 16:31:58 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 8 Nov 2020 16:31:58 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v22]
In-Reply-To: <ZWF7DHS6AGr90BoY-ASpDvze6Zivwv51UpyP_jf1kvA=.16432297-ea9b-47e5-b295-e71ac807d7d8@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <ZWF7DHS6AGr90BoY-ASpDvze6Zivwv51UpyP_jf1kvA=.16432297-ea9b-47e5-b295-e71ac807d7d8@github.com>
Message-ID: <xzyq8znZUemq70i9sC0sz5KGOqD5GMrwdguA5MxuQm0=.c51a1a5e-f1f4-4844-8a8e-8738997604c8@github.com>

On Thu, 5 Nov 2020 17:14:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
>> 
>> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
>> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
>> 
>> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
>> 
>> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
>> 
>> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
>> 
>> Thanks 
>> Maurizio 
>> 
>> Javadoc: 
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff: 
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR: 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
>> * `MemoryHandles`
>>   * drop `withOffset` combinator
>>   * drop `withStride` combinator
>>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
>> * `Addressable`
>>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
>> * `MemoryLayouts`
>>   * A new layout, for machine addresses, has been added to the mix.
>> 
>> 
>> 
>> ### Implementation changes
>> 
>> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
>> 
>> #### Shared segments
>> 
>> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
>> 
>> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
>> 
>> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
>> 
>> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
>> 
>> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
>> 
>> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
>> 
>> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
>> 
>> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
>> 
>> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
>> 
>> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
>> 
>> #### Memory access var handles overhaul
>> 
>> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
>> 
>> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
>> 
>> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
>> 
>> #### Test changes
>> 
>> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
>> 
>> [1] - https://openjdk.java.net/jeps/393
>> [2] - https://openjdk.java.net/jeps/389
>> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
>> [4] - https://openjdk.java.net/jeps/312
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
> 
>  - Fix post-merge issues caused by 8219014
>  - Merge branch 'master' into 8254162
>  - Addess remaining feedback from @AlanBateman and @mrserb
>  - Address comments from @AlanBateman
>  - Merge branch 'master' into 8254162
>  - Fix issues with derived buffers and IO operations
>  - More 32-bit fixes for TestLayouts
>  - * Add final to MappedByteBuffer::SCOPED_MEMORY_ACCESS field
>    * Tweak TestLayouts to make it 32-bit friendly after recent MemoryLayouts tweaks
>  - Remove TestMismatch from 32-bit problem list
>  - Merge branch 'master' into 8254162
>  - ... and 19 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...02f9e251

Marked as reviewed by alanb (Reviewer).

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

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

From prr at openjdk.java.net  Sun Nov  8 17:00:55 2020
From: prr at openjdk.java.net (Phil Race)
Date: Sun, 8 Nov 2020 17:00:55 GMT
Subject: RFR: 8066622 8066637: remove deprecated using
 java.io.File.toURL() in internal classes
In-Reply-To: <EbSZJq5R0_NZWXVivUsn-nJoOwHQCtYwUrUrPOeKa0c=.5877af1b-0db2-4064-bc35-638151ecc774@github.com>
References: <EbSZJq5R0_NZWXVivUsn-nJoOwHQCtYwUrUrPOeKa0c=.5877af1b-0db2-4064-bc35-638151ecc774@github.com>
Message-ID: <JyzlXMPWtFSGD9k-MTyqrK4EOw_ju8VVXO3niuy66ag=.d8d9124d-c831-4879-a44d-13412ce4da64@github.com>

On Sat, 7 Nov 2020 07:55:03 GMT, Sebastian Ritter <github.com+654217+bastie at openjdk.org> wrote:

> In result of Javadoc to do not use java.io.File.toURL()
> Change use  java.io.File.toURL().toURI() instead.

You reference a desktop bug that discusses many, many deprecations
and skara has identified https://bugs.openjdk.java.net/browse/JDK-8066622
as the issue being fixed.
Yet you propose to fix precisely one of these.
But when this is integrated that bug will be closed out as resolved.
I think you need a new bug about JUST the changes you are making.
So I don't think you should use that bug id any where in this PR.
And I'd like to hear whether you actually *tested* splashscreen with your change ? I see no sign that you did.

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

Changes requested by prr (Reviewer).

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

From javalists at cbfiddle.com  Sun Nov  8 18:04:13 2020
From: javalists at cbfiddle.com (Alan Snyder)
Date: Sun, 8 Nov 2020 10:04:13 -0800
Subject: RFR: 8180352: Add Stream.toList() method
In-Reply-To: <2098168537.1695995.1604835161502.JavaMail.zimbra@u-pem.fr>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <bUKuBU0ScUvhnCa-rUjJDUCPUfcPmS-OqMXyTSBsUeU=.2430a5a0-076e-4f16-9d1d-0dfa49faa99d@github.com>
 <4CY9WKRujRFgx526Z2joGTNdI4OGIJUI9omHgMnhReg=.8bf6e1d5-8ba9-4f7c-80bf-8adde581a9f6@github.com>
 <CADsQA7hbZZdcDsVX1csqYJwi8Nnv-vxLbcN2gc+W+of0+-dAKA@mail.gmail.com>
 <1681654584.871831.1604654062322.JavaMail.zimbra@u-pem.fr>
 <901940D3-DA82-4C1F-A24A-7799A0D14884@cbfiddle.com>
 <2098168537.1695995.1604835161502.JavaMail.zimbra@u-pem.fr>
Message-ID: <E7080C82-52CE-4B93-9874-67A371B83DC5@cbfiddle.com>



> On Nov 8, 2020, at 3:32 AM, forax at univ-mlv.fr wrote:
> 
> It's a strawman but the effect is real, the more interfaces you have the less you can reuse code because the code is written with the wrong interface for your use case. 

There are points of compromise. If someone can accept misbehavior, they can use interfaces that are pure access interfaces, such as Iterator and Stream.

> Following the same reasoning, you can say that having interfaces saying that collections are null hostile is even more important because it alleviate the issue with NullPointerException. 

My own immutable collection classes are also null-intolerant. No explosion there. Use Optional instead.

> Array vs List is not something we can be very proud of, by example in java.lang.invoke, we have several methods that are duplicated only because of this dichotomy. 
> File vs Path is less an issue because it's between implementation classes, not interfaces, anyway, you still have a number of methods inside java.io/java.nio <http://java.io/java.nio> that are duplicated.

Progress with backwards compatibility requires some duplication. It is nothing to be ashamed about.

I?m more ashamed that Type<> notation cannot be used with arrays and [] notation cannot be used with Lists.

  Alan


From naoto at openjdk.java.net  Mon Nov  9 01:40:12 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 9 Nov 2020 01:40:12 GMT
Subject: RFR: 8247781: Day periods support [v10]
In-Reply-To: <_p9FOFl7DOCxiwGk3Ks2OHs-5wbIcPEcFQXBMs0tJfQ=.43913af9-8a74-49ad-9764-89595ecc63fd@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>
 <Tu7yq15XUzC2-z2v40tNUGHkTkYW37q7RUiop9pB4xU=.d61a3059-6929-4b45-8a16-df33469ab56b@github.com>
 <_KS-70pqQG8VavYGtbXCrOlvwfwGl6Nm-lk8SjkEDQI=.1775f0e1-4847-401a-a576-dbb93e080c90@github.com>
 <BVGHbYN8Sp6W49GTct6d5edTJvgx9uVn688oy3VXe1U=.a1393d13-538c-4b3c-82db-e8abd30e297f@github.com>
 <_p9FOFl7DOCxiwGk3Ks2OHs-5wbIcPEcFQXBMs0tJfQ=.43913af9-8a74-49ad-9764-89595ecc63fd@github.com>
Message-ID: <X1JBy-5Svma-t50EpOmlCYMMrckOUylULK5YdcTWLMI=.d9ebf78e-a648-470e-9e53-2cc102160882@github.com>

On Fri, 6 Nov 2020 23:59:36 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> I find the whole "half way between the start and end" behaviour of day periods odd anyway, but if it is to be supported then it should be consistent as you've implemented. 
>> 
>> Another option I should have thought of earlier would be to simply not support the "half way between the start and end" behaviour of LDML in either dayPeriod or AM/PM. But since LDML defines it, you've implemented it, and it isn't overly harmful I think its OK to leave it in.
>> 
>> Would it be possible for STRICT mode to not have the "half way between the start and end" behaviour?
>
> I've had a look tonight, but found two more problems!
> 
> The comments at the start of `resolveTimeLenient()` indicate that setting the midpoint in `resolveTimeFields()` is a bad idea - it needs to be done inside `resolveTimeLenient()`. (This ensures user-defined fields can resolve to ChronoFields IIRC). Thus, the day period resolving would have to be split between the two methods. How important is the midpoint logic? Could it just be dropped?
> 
> Secondly, we need to ensure that "24:00 midnight" (using HOUR_OF_DAY only) correctly parses to the end of day midnight, not the start of day or an exception. This is related to the problem above. 
> 
> I _think_ (but haven't confirmed everything yet) that the only thing that should be in `resolveTimeFields()` is the resolution of HOUR_OF_AMPM + dayPeriod to HOUR_OF_DAY (with `dayPeriod` then being set to `null`). Everything else should go in `resolveTimeLenient()` - the midpoint logic in the first if block (where time fields are defaulted), and the validation logic at the end of the method.

Thanks for the insights. I believe I fixed both of the issues with the new commit.

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

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

From naoto at openjdk.java.net  Mon Nov  9 01:40:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 9 Nov 2020 01:40:11 GMT
Subject: RFR: 8247781: Day periods support [v10]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <Z_y8oHtX5z7xiMv47vPMIJm0YGw097bemeR2G9c6rTA=.90f6c639-d908-4f1b-a3a0-9ee97a97b0ac@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Addressing https://github.com/openjdk/jdk/pull/938#discussion_r519061476

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/3a9ea64a..7140ae27

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

  Stats: 90 lines in 3 files changed: 56 ins; 34 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

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

From hshi at openjdk.java.net  Mon Nov  9 03:01:58 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Mon, 9 Nov 2020 03:01:58 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v2]
In-Reply-To: <tJKI-gR0XTRiOp7w_gAgKvGI46sAOafuohtX_EZ5tk0=.8c11e1b6-d7dc-496f-901d-39b738a53b0a@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <6914QI9MySYQ4-Lpt_OIzMBbyFGRTYnPTLGJpIfBdQI=.57041221-95ea-44eb-90a6-57789597f741@github.com>
 <wllRvEUkKyTEFAmShdMQsLf5yMaL7TUIiS_SEDPptE0=.2042cc3b-8bde-4229-b198-76485f0647f6@github.com>
 <1IPqXcDKyV2gwO1ro01A5-zCJB4_1A9P-GLsdaFY8GI=.750c0542-31ef-4281-bcb2-6da7a66c958b@github.com>
 <tJKI-gR0XTRiOp7w_gAgKvGI46sAOafuohtX_EZ5tk0=.8c11e1b6-d7dc-496f-901d-39b738a53b0a@github.com>
Message-ID: <bAznO9DcJxwL-47s3SLsG7dKJ3VYjgnZBEC0rllyA6M=.d804bf0e-f66d-4907-887a-b5a3e39c7b14@github.com>

On Fri, 6 Nov 2020 08:58:13 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

> Are there any benchmarks to compare this accessor with the previous version in the presumably common case where there is no or very little contention? Edit to clarify: it is stated as "trivial" is this also measured somewhere?

@jbf  in presumably common case,  one extra CAS is added when invocation reach threshold.
MethodInvoke in jdk repo micro benchmark test shows no regression with this patch.

**Before patch**
Benchmark                                  Mode  Cnt   Score   Error  Units
MethodInvoke.invokeWithSixObjectParams     avgt   25   5.443 ? 0.008  ns/op
MethodInvoke.invokeWithSixPrimitiveParams  avgt   25  10.195 ? 0.020  ns/op
MethodInvoke.invokeWithoutParams           avgt   25   3.919 ? 0.011  ns/op

Benchmark                                  Mode  Cnt   Score   Error  Units
MethodInvoke.invokeWithSixObjectParams     avgt   25   5.440 ? 0.012  ns/op
MethodInvoke.invokeWithSixPrimitiveParams  avgt   25  10.197 ? 0.028  ns/op
MethodInvoke.invokeWithoutParams           avgt   25   3.923 ? 0.010  ns/op

**After patch**
Benchmark                                  Mode  Cnt   Score   Error  Units
MethodInvoke.invokeWithSixObjectParams     avgt   25   5.438 ? 0.005  ns/op
MethodInvoke.invokeWithSixPrimitiveParams  avgt   25  10.190 ? 0.038  ns/op
MethodInvoke.invokeWithoutParams           avgt   25   3.930 ? 0.010  ns/op
Finished running test 'micro:java.lang.reflect.MethodInvoke'

Benchmark                                  Mode  Cnt   Score   Error  Units
MethodInvoke.invokeWithSixObjectParams     avgt   25   5.442 ? 0.009  ns/op
MethodInvoke.invokeWithSixPrimitiveParams  avgt   25  10.205 ? 0.034  ns/op
MethodInvoke.invokeWithoutParams           avgt   25   3.916 ? 0.005  ns/op

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

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

From dholmes at openjdk.java.net  Mon Nov  9 03:26:01 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 9 Nov 2020 03:26:01 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
Message-ID: <8bF0fXpoTGxGwg_Ea__S4LApLPhAJ9ejrOP4P_IvaiM=.14114594-11fa-415f-9008-d3be3dfaf0c3@github.com>

On Thu, 5 Nov 2020 21:26:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
> 
>  - Merge branch '8254162' into 8254231_linker
>  - Fix post-merge issues caused by 8219014
>  - Merge branch 'master' into 8254162
>  - Addess remaining feedback from @AlanBateman and @mrserb
>  - Address comments from @AlanBateman
>  - Fix typo in upcall helper for aarch64
>  - Merge branch '8254162' into 8254231_linker
>  - Merge branch 'master' into 8254162
>  - Fix issues with derived buffers and IO operations
>  - More 32-bit fixes for TestLayouts
>  - ... and 54 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...b38afb3f

src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 60:

> 58: #endif
> 59: 
> 60:   TRAPS = Thread::current();

Don't use TRAPS this way - it exists for use in signatures. Just declare:
`Thread* THREAD = Thread::current();`

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

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

From dholmes at openjdk.java.net  Mon Nov  9 04:13:07 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 9 Nov 2020 04:13:07 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
Message-ID: <lIajZsJ7LXE6I7upbj-IV39aHVHILgTG52OYWJrndHI=.b4565d6b-d6c6-455f-8aa0-ece5c443a011@github.com>

On Thu, 5 Nov 2020 21:26:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
> 
>  - Merge branch '8254162' into 8254231_linker
>  - Fix post-merge issues caused by 8219014
>  - Merge branch 'master' into 8254162
>  - Addess remaining feedback from @AlanBateman and @mrserb
>  - Address comments from @AlanBateman
>  - Fix typo in upcall helper for aarch64
>  - Merge branch '8254162' into 8254231_linker
>  - Merge branch 'master' into 8254162
>  - Fix issues with derived buffers and IO operations
>  - More 32-bit fixes for TestLayouts
>  - ... and 54 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...b38afb3f

A high-level scan through - mostly VM files.

src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 99:

> 97:   if (thread == NULL) {
> 98:     JavaVM_ *vm = (JavaVM *)(&main_vm);
> 99:     vm -> functions -> AttachCurrentThreadAsDaemon(vm, &p_env, NULL);

Style nit: don't put spaces around `->` operator.

What is the context for this being called? It looks highly suspicious to just attach the current thread to the VM this way.

src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 105:

> 103:   assert(thread->is_Java_thread(), "really?");
> 104: 
> 105:   ThreadInVMfromNative __tiv((JavaThread *)thread);

Please use `thread->as_Java_thread()` instead of the cast.

src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 111:

> 109:   }
> 110: 
> 111:   ResourceMark rm;

Pass `thread` to the RM constructor.

src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 3521:

> 3519:   __ movl(Address(r15_thread, JavaThread::thread_state_offset()), _thread_in_native_trans);
> 3520: 
> 3521:   if (os::is_MP()) {

The assumption these days is that we are always MP and we don't litter the code with `os::is_MP()` checks any more.

src/hotspot/cpu/x86/universalUpcallHandler_x86.cpp line 53:

> 51:     Symbol* sig;
> 52:   } upcall_method;  // jdk.internal.foreign.abi.UniversalUpcallHandler::invoke
> 53: } upcall_info;

Why is this being duplicated in platform specific code when it appears to be common/shared?

src/hotspot/cpu/x86/universalUpcallHandler_x86.cpp line 56:

> 54: 
> 55: // FIXME: This should be initialized explicitly instead of lazily/racily
> 56: static void upcall_init() {

Obviously see all comments on the Aarch64 files. This appears it should be common/shared code.

src/hotspot/share/prims/scopedMemoryAccess.cpp line 86:

> 84:   void do_thread(Thread* thread) {
> 85: 
> 86:     JavaThread* jt = (JavaThread*)thread;

Please use `thread->as_Java_thread()` instead of the cast.

src/hotspot/share/prims/universalNativeInvoker.cpp line 40:

> 38:     assert(thread->thread_state() == _thread_in_native, "thread state is: %d", thread->thread_state());
> 39:   }
> 40:   assert(thread->thread_state() == _thread_in_vm, "thread state is: %d", thread->thread_state());

Is there some reason you don't trust the thread-state transition code and are asserting it updates the state correctly all the time? :) There are already a number of assertions of this kind within the ThreadToNativeFromVM code.

src/java.base/share/classes/jdk/internal/invoke/NativeEntryPoint.java line 63:

> 61:     }
> 62: 
> 63:     public static NativeEntryPoint make(long addr, String name, ABIDescriptorProxy abi, VMStorageProxy[] argMoves, VMStorageProxy[] returnMoves,

Where is name validation performed, to ensure the named native method is in fact legal and not trying to provide backdoor access to native code that should be encapsulated and protected?

src/java.base/windows/native/libjava/jni_util_md.c line 51:

> 49: 
> 50:     // first come, first served
> 51:     if(EnumProcessModules(hProcess, hMods, sizeof(hMods), &cbNeeded)) {

Style check: space after `if`

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

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

From dholmes at openjdk.java.net  Mon Nov  9 04:13:10 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 9 Nov 2020 04:13:10 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v14]
In-Reply-To: <P8t0K2fKjwwudHg7xDwbiyVM8plG0ADy34fzxBgROps=.b07a6d4a-660f-4642-9f6c-67027d21f348@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <P8t0K2fKjwwudHg7xDwbiyVM8plG0ADy34fzxBgROps=.b07a6d4a-660f-4642-9f6c-67027d21f348@github.com>
Message-ID: <037JOlF9tavFXVI6H6AnLiI3GSpcJLiAOANXz_KTWUg=.16b28fcd-302a-42b2-b493-cd2e4e59b9b2@github.com>

On Fri, 30 Oct 2020 12:16:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in upcall helper for aarch64

src/java.base/share/classes/java/lang/System.java line 2086:

> 2084:                     break;
> 2085:                 case "allow":
> 2086:                     allowSecurityManager = MAYBE;

Why is this removed? I don't see the connection.

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

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

From dholmes at openjdk.java.net  Mon Nov  9 04:13:09 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Mon, 9 Nov 2020 04:13:09 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <cpNCcue6y1OO8obK4QmhiNrdw85BAdAXFLqVbh1RmYc=.ee32d53d-1296-4bd5-8bdd-6632e7ff6af6@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <cpNCcue6y1OO8obK4QmhiNrdw85BAdAXFLqVbh1RmYc=.ee32d53d-1296-4bd5-8bdd-6632e7ff6af6@github.com>
Message-ID: <nLzZg6qxGVHcXPTOh8dSEnLIAP0ER7lwbTjDBn8dtsk=.eb183041-9dd5-4472-8430-16623e015598@github.com>

On Fri, 6 Nov 2020 21:42:41 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
>> 
>>  - Merge branch '8254162' into 8254231_linker
>>  - Fix post-merge issues caused by 8219014
>>  - Merge branch 'master' into 8254162
>>  - Addess remaining feedback from @AlanBateman and @mrserb
>>  - Address comments from @AlanBateman
>>  - Fix typo in upcall helper for aarch64
>>  - Merge branch '8254162' into 8254231_linker
>>  - Merge branch 'master' into 8254162
>>  - Fix issues with derived buffers and IO operations
>>  - More 32-bit fixes for TestLayouts
>>  - ... and 54 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...b38afb3f
>
> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 55:
> 
>> 53: 
>> 54: // FIXME: This should be initialized explicitly instead of lazily/racily
>> 55: static void upcall_init() {
> 
> The FIXME is right this should be initialized as a well known class and referred to here as SystemDictionary::ProgrammableUpcallHandler_klass().  This really doesn't belong here.

I agree with Coleen.

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

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

From ngasson at openjdk.java.net  Mon Nov  9 06:10:03 2020
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Mon, 9 Nov 2020 06:10:03 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
Message-ID: <4bUSiuyN2A59lbK4owjFzfRXLm4G49lJo4ObxopBTrs=.bc8c90c7-f831-4814-b5e4-c1f1fcc4e98f@github.com>

On Thu, 5 Nov 2020 21:26:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
> 
>  - Merge branch '8254162' into 8254231_linker
>  - Fix post-merge issues caused by 8219014
>  - Merge branch 'master' into 8254162
>  - Addess remaining feedback from @AlanBateman and @mrserb
>  - Address comments from @AlanBateman
>  - Fix typo in upcall helper for aarch64
>  - Merge branch '8254162' into 8254231_linker
>  - Merge branch 'master' into 8254162
>  - Fix issues with derived buffers and IO operations
>  - More 32-bit fixes for TestLayouts
>  - ... and 54 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...b38afb3f

src/hotspot/share/opto/output.cpp line 1697:

> 1695:       current_offset = cb->insts_size();
> 1696: 
> 1697:       assert(!is_mcall || (call_returns[block->_pre_order] == (uint) current_offset), "ret_addr_offset() did not match size of emitted code");

This assertion is too strong: on AArch64 we generate additional instructions after the BLR (call) instruction for certain types of call. For example

  
  0x0000ffff790f00dc:   adr     x9, 0x0000ffff790f00f4
  0x0000ffff790f00e0:   mov     x8, #0x5714                     // #22292
  0x0000ffff790f00e4:   movk    x8, #0x8d3d, lsl #16
  0x0000ffff790f00e8:   movk    x8, #0xffff, lsl #32
  0x0000ffff790f00ec:   stp     xzr, x9, [sp, #-16]!
  0x0000ffff790f00f0:   blr     x8
  0x0000ffff790f00f4:   add     sp, sp, #0x10                          <== ret_addr_offset() is here
  0x0000ffff790f00f8:   Address 0x0000ffff790f00f8 is out of bounds.   <== current_offset is here

I think the `==` should be `<=`. (Although this still fails sometimes on AArch64, but I believe it exposes a real bug. I've opened JDK-8256025 and will fix this shortly.)

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

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

From roland at openjdk.java.net  Mon Nov  9 09:09:25 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 9 Nov 2020 09:09:25 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v4]
In-Reply-To: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
Message-ID: <G1QhRCEuD-K0ytHSyflrjmQIH1QDRth1bYtrL1-CxBE=.aa99a221-be67-4c18-8f6c-8a407305bfbf@github.com>

> This change add 3 new methods in Objects:
> 
> public static long checkIndex(long index, long length)
> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
> public static long checkFromIndexSize(long fromIndex, long size, long length)
> 
> This mirrors the int utility methods that were added by JDK-8135248
> with the same motivations.
> 
> As is the case with the int checkIndex(), the long checkIndex() method
> is JIT compiled as an intrinsic. It allows the JIT to compile
> checkIndex to an unsigned comparison and properly recognize it as
> a range check that then becomes a candidate for the existing range check
> optimizations. This has proven to be important for panama's
> MemorySegment API and a prototype of this change (with some extra c2
> improvements) showed that panama micro benchmark results improve
> significantly.
> 
> This change includes:
> 
> - the API change
> - the C2 intrinsic
> - tests for the API and the C2 intrinsic
> 
> This is a joint work with Paul who reviewed and reworked the API change
> and filled the CSR.

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

 - CastLL should define carry_depency
 - intrinsic comments
 - Jorn's comments
 - Update headers and add intrinsic to Graal test ignore list
 - move compiler test and add bug to test
 - non x86_64 arch support
 - c2 test case
 - intrinsic
 - Use overloads of method names.
   
   Simplify internally to avoid overload resolution
   issues, leverging List<Number> for the exception
   mapper.
 - Vladimir's comments
 - ... and 1 more: https://git.openjdk.java.net/jdk/compare/976fa4c6...692b4298

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1003/files
  - new: https://git.openjdk.java.net/jdk/pull/1003/files/aaacd328..692b4298

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

  Stats: 515 lines in 41 files changed: 400 ins; 66 del; 49 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1003.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1003/head:pull/1003

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

From roland at openjdk.java.net  Mon Nov  9 09:12:58 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Mon, 9 Nov 2020 09:12:58 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v3]
In-Reply-To: <0P2H9rV2KCehYBo_hE-uYriC_S0YAs_1QOePRcRtQjI=.614ae3b3-316b-4bd9-a547-680acb193d3d@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
 <R_wj8HyVj3TBppCLzwfdHTqEJOB4mxFdTmwx4yftKQc=.555c0dff-9826-4772-8421-2228c7a7aa7d@github.com>
 <0P2H9rV2KCehYBo_hE-uYriC_S0YAs_1QOePRcRtQjI=.614ae3b3-316b-4bd9-a547-680acb193d3d@github.com>
Message-ID: <t4zffKnAssIWbUCTa2g7EvlVsPd7c0Hk6l51FqgGHrg=.9dadb767-0e1a-4c93-96fd-0e326e82505f@github.com>

On Sat, 7 Nov 2020 11:38:37 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Roland Westrelin 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.
>
> src/hotspot/share/opto/castnode.cpp line 100:
> 
>> 98:   }
>> 99:   case Op_CastLL: {
>> 100:     assert(!carry_dependency, "carry dependency not supported");
> 
> Any particular reason to reject control dependency (except it is not used right now)?

Because it's not used. But actually now that I think more about it, I realize it's required. I updated the change with support for carry_dependency for CastLL.
Thanks for the review!

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

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

From jiefu at openjdk.java.net  Mon Nov  9 09:25:03 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 9 Nov 2020 09:25:03 GMT
Subject: RFR: 8256037: [TESTBUG]
 com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails due to the hard coded
 threshold is small
Message-ID: <QuPW3Afb2RpucHhJT9NQDsmHo977-Y378EuBgcg_-B0=.07b9b5f2-8faf-434b-9e98-72a80734976f@github.com>

Hi all,

May I get reviews for this change?

com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails occasionally on some of our testing platforms.
The reason is that the hard coded Threshold (1000 ms) [1] is a little smaller than that (e.g., 1026 ms) on our platforms.

The fix just increases the threshold from 1000 ms to 3000 ms.
Any comments?

Thanks.
Best regards,
Jie

[1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java#L49

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

Commit messages:
 - 8256037: [TESTBUG] com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails due to the hard coded threshold is small

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

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

From jvernee at openjdk.java.net  Mon Nov  9 11:12:05 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 9 Nov 2020 11:12:05 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <4bUSiuyN2A59lbK4owjFzfRXLm4G49lJo4ObxopBTrs=.bc8c90c7-f831-4814-b5e4-c1f1fcc4e98f@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <4bUSiuyN2A59lbK4owjFzfRXLm4G49lJo4ObxopBTrs=.bc8c90c7-f831-4814-b5e4-c1f1fcc4e98f@github.com>
Message-ID: <3Rq38lsrqgc6urjbkdsLYLCMljA519ITzLs6cLnOEfk=.24bc9068-30f4-4a8d-91d9-20bcd61696c1@github.com>

On Mon, 9 Nov 2020 06:07:32 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
>> 
>>  - Merge branch '8254162' into 8254231_linker
>>  - Fix post-merge issues caused by 8219014
>>  - Merge branch 'master' into 8254162
>>  - Addess remaining feedback from @AlanBateman and @mrserb
>>  - Address comments from @AlanBateman
>>  - Fix typo in upcall helper for aarch64
>>  - Merge branch '8254162' into 8254231_linker
>>  - Merge branch 'master' into 8254162
>>  - Fix issues with derived buffers and IO operations
>>  - More 32-bit fixes for TestLayouts
>>  - ... and 54 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...b38afb3f
>
> src/hotspot/share/opto/output.cpp line 1697:
> 
>> 1695:       current_offset = cb->insts_size();
>> 1696: 
>> 1697:       assert(!is_mcall || (call_returns[block->_pre_order] == (uint) current_offset), "ret_addr_offset() did not match size of emitted code");
> 
> This assertion is too strong: on AArch64 we generate additional instructions after the BLR (call) instruction for certain types of call. For example
> 
>   
>   0x0000ffff790f00dc:   adr     x9, 0x0000ffff790f00f4
>   0x0000ffff790f00e0:   mov     x8, #0x5714                     // #22292
>   0x0000ffff790f00e4:   movk    x8, #0x8d3d, lsl #16
>   0x0000ffff790f00e8:   movk    x8, #0xffff, lsl #32
>   0x0000ffff790f00ec:   stp     xzr, x9, [sp, #-16]!
>   0x0000ffff790f00f0:   blr     x8
>   0x0000ffff790f00f4:   add     sp, sp, #0x10                          <== ret_addr_offset() is here
>   0x0000ffff790f00f8:   Address 0x0000ffff790f00f8 is out of bounds.   <== current_offset is here
> 
> I think the `==` should be `<=`. (Although this still fails sometimes on AArch64, but I believe it exposes a real bug. I've opened JDK-8256025 and will fix this shortly.)

Ok, that seems fine to me. IIRC the problem this was trying to catch is a ret_addr_offset that is too large, which might cause a later call's oop map to be overridden. So, using `<=` should still work. At least if the code between ret_addr_offset and current_offset is guaranteed not to contain any calls or other safepoints.

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

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

From jvernee at openjdk.java.net  Mon Nov  9 11:57:07 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 9 Nov 2020 11:57:07 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <lIajZsJ7LXE6I7upbj-IV39aHVHILgTG52OYWJrndHI=.b4565d6b-d6c6-455f-8aa0-ece5c443a011@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <lIajZsJ7LXE6I7upbj-IV39aHVHILgTG52OYWJrndHI=.b4565d6b-d6c6-455f-8aa0-ece5c443a011@github.com>
Message-ID: <xkIvCl3CZLV3QXNpVQKVUJeUcNdMZ1DvMdji0iTS0L0=.4ea8f950-13f6-43bb-b7c8-c7a1cf0873b5@github.com>

On Mon, 9 Nov 2020 03:29:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
>> 
>>  - Merge branch '8254162' into 8254231_linker
>>  - Fix post-merge issues caused by 8219014
>>  - Merge branch 'master' into 8254162
>>  - Addess remaining feedback from @AlanBateman and @mrserb
>>  - Address comments from @AlanBateman
>>  - Fix typo in upcall helper for aarch64
>>  - Merge branch '8254162' into 8254231_linker
>>  - Merge branch 'master' into 8254162
>>  - Fix issues with derived buffers and IO operations
>>  - More 32-bit fixes for TestLayouts
>>  - ... and 54 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...b38afb3f
>
> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 99:
> 
>> 97:   if (thread == NULL) {
>> 98:     JavaVM_ *vm = (JavaVM *)(&main_vm);
>> 99:     vm -> functions -> AttachCurrentThreadAsDaemon(vm, &p_env, NULL);
> 
> Style nit: don't put spaces around `->` operator.
> 
> What is the context for this being called? It looks highly suspicious to just attach the current thread to the VM this way.

The context is a thread that is spawned by native code doing an upcall. We need to attach the thread to the VM first in that case. Normally this would be handled by the calling code, but in our case the calling code doesn't know it's calling into Java.

> src/java.base/share/classes/jdk/internal/invoke/NativeEntryPoint.java line 63:
> 
>> 61:     }
>> 62: 
>> 63:     public static NativeEntryPoint make(long addr, String name, ABIDescriptorProxy abi, VMStorageProxy[] argMoves, VMStorageProxy[] returnMoves,
> 
> Where is name validation performed, to ensure the named native method is in fact legal and not trying to provide backdoor access to native code that should be encapsulated and protected?

The name is just used as debugging information (in e.g. CallNativeNode::dump_spec), we are not looking it up. The address that is passed there is the actual function target.

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

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

From jvernee at openjdk.java.net  Mon Nov  9 12:15:01 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 9 Nov 2020 12:15:01 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <nLzZg6qxGVHcXPTOh8dSEnLIAP0ER7lwbTjDBn8dtsk=.eb183041-9dd5-4472-8430-16623e015598@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <cpNCcue6y1OO8obK4QmhiNrdw85BAdAXFLqVbh1RmYc=.ee32d53d-1296-4bd5-8bdd-6632e7ff6af6@github.com>
 <nLzZg6qxGVHcXPTOh8dSEnLIAP0ER7lwbTjDBn8dtsk=.eb183041-9dd5-4472-8430-16623e015598@github.com>
Message-ID: <tMZM86a9J0tRJcNgirnPN2grov9rB4L2yE-pA6LvVys=.3be44d8d-af7f-4cd7-b515-00cbd9b89e3a@github.com>

On Mon, 9 Nov 2020 03:31:15 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 55:
>> 
>>> 53: 
>>> 54: // FIXME: This should be initialized explicitly instead of lazily/racily
>>> 55: static void upcall_init() {
>> 
>> The FIXME is right this should be initialized as a well known class and referred to here as SystemDictionary::ProgrammableUpcallHandler_klass().  This really doesn't belong here.
>
> I agree with Coleen.

I'll give this another try, but I think last time I tried this resolution of the class failed when trying to build the JDK, seemingly since it exists in an incubator module, which is not always added to the module graph.

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

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

From mcimadamore at openjdk.java.net  Mon Nov  9 12:28:13 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 9 Nov 2020 12:28:13 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v23]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <flI3usQ4hSmH0W2nQBcFI2IZF-lQZzurodC_WU9qHCU=.95877421-aabd-4dcf-b0f1-120b693a62fe@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

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

  Remove endianness-aware byte getter/setter in MemoryAccess
  Remove index-based version of byte getter/setter in MemoryAccess

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/02f9e251..6940f0ac

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

  Stats: 110 lines in 3 files changed: 0 ins; 98 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

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

From mcimadamore at openjdk.java.net  Mon Nov  9 12:28:16 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 9 Nov 2020 12:28:16 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v22]
In-Reply-To: <xzyq8znZUemq70i9sC0sz5KGOqD5GMrwdguA5MxuQm0=.c51a1a5e-f1f4-4844-8a8e-8738997604c8@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <ZWF7DHS6AGr90BoY-ASpDvze6Zivwv51UpyP_jf1kvA=.16432297-ea9b-47e5-b295-e71ac807d7d8@github.com>
 <xzyq8znZUemq70i9sC0sz5KGOqD5GMrwdguA5MxuQm0=.c51a1a5e-f1f4-4844-8a8e-8738997604c8@github.com>
Message-ID: <DKbjPKiPvxDvPhFyTbBW_5aP8Y5lwHgLY_ytewCKZDQ=.7db9fc02-8279-4347-bd40-f62e33b38d29@github.com>

On Sun, 8 Nov 2020 16:28:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits:
>> 
>>  - Fix post-merge issues caused by 8219014
>>  - Merge branch 'master' into 8254162
>>  - Addess remaining feedback from @AlanBateman and @mrserb
>>  - Address comments from @AlanBateman
>>  - Merge branch 'master' into 8254162
>>  - Fix issues with derived buffers and IO operations
>>  - More 32-bit fixes for TestLayouts
>>  - * Add final to MappedByteBuffer::SCOPED_MEMORY_ACCESS field
>>    * Tweak TestLayouts to make it 32-bit friendly after recent MemoryLayouts tweaks
>>  - Remove TestMismatch from 32-bit problem list
>>  - Merge branch 'master' into 8254162
>>  - ... and 19 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...02f9e251
>
> Marked as reviewed by alanb (Reviewer).

> I see the xxxByteAtIndex methods that took a ByteOrder have been removed from MemoryAccess. Should the xxxByte and xxxByteAtOffset that take a ByteOrder be removed too?

I've addresses this in the latest iteration. Since I was there I also removed `getByteAtIndex` and `getByteAtIndex`, since their behavior is identical to that of `getByteAtOffset` and `setByteAtOffset`, respectively (in other words, the indexed variants are not really helpful until carrier size > 1 byte).

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

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

From mcimadamore at openjdk.java.net  Mon Nov  9 13:22:14 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 9 Nov 2020 13:22:14 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v24]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <Ix7054TzJ3bH_ke5nRpKWYxxtuXXrHfy7FLexuQNEHA=.7f79b67a-c605-408a-92b5-59d44a2ae622@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

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

  Improve debugging output of TestHandhsake

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/6940f0ac..f5d339a7

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

  Stats: 37 lines in 1 file changed: 11 ins; 1 del; 25 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

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

From david.holmes at oracle.com  Mon Nov  9 13:51:03 2020
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 9 Nov 2020 23:51:03 +1000
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <xkIvCl3CZLV3QXNpVQKVUJeUcNdMZ1DvMdji0iTS0L0=.4ea8f950-13f6-43bb-b7c8-c7a1cf0873b5@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <lIajZsJ7LXE6I7upbj-IV39aHVHILgTG52OYWJrndHI=.b4565d6b-d6c6-455f-8aa0-ece5c443a011@github.com>
 <xkIvCl3CZLV3QXNpVQKVUJeUcNdMZ1DvMdji0iTS0L0=.4ea8f950-13f6-43bb-b7c8-c7a1cf0873b5@github.com>
Message-ID: <8c4cbff8-32b5-c90b-20da-dccfa49e970c@oracle.com>

Hi Jorn,

On 9/11/2020 9:57 pm, Jorn Vernee wrote:
> On Mon, 9 Nov 2020 03:29:05 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 99:
>>
>>> 97:   if (thread == NULL) {
>>> 98:     JavaVM_ *vm = (JavaVM *)(&main_vm);
>>> 99:     vm -> functions -> AttachCurrentThreadAsDaemon(vm, &p_env, NULL);
>>
>> Style nit: don't put spaces around `->` operator.
>>
>> What is the context for this being called? It looks highly suspicious to just attach the current thread to the VM this way.
> 
> The context is a thread that is spawned by native code doing an upcall. We need to attach the thread to the VM first in that case. Normally this would be handled by the calling code, but in our case the calling code doesn't know it's calling into Java.

Apologies that I don't have enough knowledge of this feature to 
understand the context. Shouldn't you then detach it again afterwards? 
Otherwise when will it detach? If you don't detach you will get a memory 
leak.

>> src/java.base/share/classes/jdk/internal/invoke/NativeEntryPoint.java line 63:
>>
>>> 61:     }
>>> 62:
>>> 63:     public static NativeEntryPoint make(long addr, String name, ABIDescriptorProxy abi, VMStorageProxy[] argMoves, VMStorageProxy[] returnMoves,
>>
>> Where is name validation performed, to ensure the named native method is in fact legal and not trying to provide backdoor access to native code that should be encapsulated and protected?
> 
> The name is just used as debugging information (in e.g. CallNativeNode::dump_spec), we are not looking it up. The address that is passed there is the actual function target.

Okay.

Thanks,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/634
> 

From jorn.vernee at oracle.com  Mon Nov  9 15:07:48 2020
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Mon, 9 Nov 2020 16:07:48 +0100
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <8c4cbff8-32b5-c90b-20da-dccfa49e970c@oracle.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <lIajZsJ7LXE6I7upbj-IV39aHVHILgTG52OYWJrndHI=.b4565d6b-d6c6-455f-8aa0-ece5c443a011@github.com>
 <xkIvCl3CZLV3QXNpVQKVUJeUcNdMZ1DvMdji0iTS0L0=.4ea8f950-13f6-43bb-b7c8-c7a1cf0873b5@github.com>
 <8c4cbff8-32b5-c90b-20da-dccfa49e970c@oracle.com>
Message-ID: <56e42c7c-4abf-3948-cb63-1f102acedd85@oracle.com>

Hi David,

On 09/11/2020 14:51, David Holmes wrote:
> Hi Jorn,
>
> On 9/11/2020 9:57 pm, Jorn Vernee wrote:
>> On Mon, 9 Nov 2020 03:29:05 GMT, David Holmes <dholmes at openjdk.org> 
>> wrote:
>>
>>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 99:
>>>
>>>> 97:?? if (thread == NULL) {
>>>> 98:???? JavaVM_ *vm = (JavaVM *)(&main_vm);
>>>> 99:???? vm -> functions -> AttachCurrentThreadAsDaemon(vm, &p_env, 
>>>> NULL);
>>>
>>> Style nit: don't put spaces around `->` operator.
>>>
>>> What is the context for this being called? It looks highly 
>>> suspicious to just attach the current thread to the VM this way.
>>
>> The context is a thread that is spawned by native code doing an 
>> upcall. We need to attach the thread to the VM first in that case. 
>> Normally this would be handled by the calling code, but in our case 
>> the calling code doesn't know it's calling into Java.
>
> Apologies that I don't have enough knowledge of this feature to 
> understand the context. Shouldn't you then detach it again afterwards? 
> Otherwise when will it detach? If you don't detach you will get a 
> memory leak.
I went back to look at the original thread that added this code [1]. At 
that point the decision was made to go with the memory leak to avoid 
additional complexity in assembly stub generation and performance loss 
from having to repeatedly attach and detach threads.

At least the complexity argument is no longer valid. As for the 
performance argument. This implementation of upcalls is not expected to 
perform stellar, so I think calling detach again in case we did an 
attach is the right call. (Though we'll have to solve the same problem 
again down the line for the optimized version).

Thanks for catching,
Jorn

[1] : 
https://mail.openjdk.java.net/pipermail/panama-dev/2019-June/005761.html
>>> src/java.base/share/classes/jdk/internal/invoke/NativeEntryPoint.java 
>>> line 63:
>>>
>>>> 61:???? }
>>>> 62:
>>>> 63:???? public static NativeEntryPoint make(long addr, String name, 
>>>> ABIDescriptorProxy abi, VMStorageProxy[] argMoves, VMStorageProxy[] 
>>>> returnMoves,
>>>
>>> Where is name validation performed, to ensure the named native 
>>> method is in fact legal and not trying to provide backdoor access to 
>>> native code that should be encapsulated and protected?
>>
>> The name is just used as debugging information (in e.g. 
>> CallNativeNode::dump_spec), we are not looking it up. The address 
>> that is passed there is the actual function target.
>
> Okay.
>
> Thanks,
> David
> -----
>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/634
>>

From mcimadamore at openjdk.java.net  Mon Nov  9 15:26:13 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 9 Nov 2020 15:26:13 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v25]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <gnKnWkA-37ut74uFNQVeQNjRqa66q_HaFFjN2MzsXKQ=.34d98a76-5ad6-4fdf-8c9b-e1226dc43eda@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

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

  Further improve output of TestHandshake

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/f5d339a7..27677a13

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

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

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

From aph at openjdk.java.net  Mon Nov  9 16:06:00 2020
From: aph at openjdk.java.net (Andrew Haley)
Date: Mon, 9 Nov 2020 16:06:00 GMT
Subject: Integrated: 8254078: DataOutputStream is very slow post-disabling of
 Biased Locking
In-Reply-To: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
References: <lLg_yNI_6LvUZTlM4PyN5ra6AaUZZeT35QzYzV_0CpI=.f2d3cb9e-be30-40dc-922c-dad5bef7feea@github.com>
Message-ID: <lX_dGMgUN_eW8kJyqUqqLhvj-8rSn-Z4xaxqgYM9Dao=.37566ceb-a98f-4e6d-80a4-475cb2512232@github.com>

On Wed, 7 Oct 2020 13:30:14 GMT, Andrew Haley <aph at openjdk.org> wrote:

> DataOutputStream is very slow post-disabling of Biased Locking. This
> was discovered when benchmarking a transaction library, which showed
> significant performance loss when moving to JDK 15. WIth some small
> changes to DataOutputStream we can get the performance back. There's a
> JMH benchmark at
> http://cr.openjdk.java.net/~aph/JDK-8254078/jmh-tests.tar
> 
> Some Stream classes use very fine-grained locking.
> 
> In particular, writeInt is defined like this:
> 
>         out.write((v >>> 24) & 0xFF);
>         out.write((v >>> 16) & 0xFF);
>         out.write((v >>> 8) & 0xFF);
>         out.write((v >>> 0) & 0xFF);
>         incCount(4);
> 
> Unfortunately, ByteArrayOutputStream.write(byte) is defined like this:
> 
>     public synchronized void write(int b) {
>         ensureCapacity(count + 1);
>         buf[count] = (byte) b;
>         count += 1;
>     }
> 
> so we acquire and release a lock for every byte that is output. 
> 
>  For example, writing 4kb of ints goes from 17.3 us/op to 53.9 us/op when biased locking is disabled: 
> 
> 
> +UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 53.895 ? 5.126 us/op
> -UseBiasedLocking DataOutputStreamTest.dataOutputStreamOverByteArray avgt 6 17.291 ? 4.430 us/op
> 
> There are refactorings of DataOutputStream we can do to mitigate this.

This pull request has now been integrated.

Changeset: 17f04fc9
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/17f04fc9
Stats:     143 lines in 3 files changed: 132 ins; 0 del; 11 mod

8254078: DataOutputStream is very slow post-disabling of Biased Locking

Reviewed-by: rriggs, shade, alanb

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

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

From mcimadamore at openjdk.java.net  Mon Nov  9 16:07:13 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 9 Nov 2020 16:07:13 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v26]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <NCctjv7i5o9hX26cfcXS7Xc5Kcb0sMFdD3Nmd7BtKC0=.c4dc7496-ac84-4c5f-8753-274138deca85@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

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

  Add more output in TestHandhsake.java

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/27677a13..a22b6b5b

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

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

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

From jvernee at openjdk.java.net  Mon Nov  9 16:34:00 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 9 Nov 2020 16:34:00 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <tMZM86a9J0tRJcNgirnPN2grov9rB4L2yE-pA6LvVys=.3be44d8d-af7f-4cd7-b515-00cbd9b89e3a@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <cpNCcue6y1OO8obK4QmhiNrdw85BAdAXFLqVbh1RmYc=.ee32d53d-1296-4bd5-8bdd-6632e7ff6af6@github.com>
 <nLzZg6qxGVHcXPTOh8dSEnLIAP0ER7lwbTjDBn8dtsk=.eb183041-9dd5-4472-8430-16623e015598@github.com>
 <tMZM86a9J0tRJcNgirnPN2grov9rB4L2yE-pA6LvVys=.3be44d8d-af7f-4cd7-b515-00cbd9b89e3a@github.com>
Message-ID: <_Nl5ypHkLlY3aqitzjfT_Rot6lDm6TX3VS3KbTE_gBg=.4a0f5742-bad8-4ceb-805d-2e7e0c51ebf4@github.com>

On Mon, 9 Nov 2020 12:11:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I agree with Coleen.
>
> I'll give this another try, but I think last time I tried this resolution of the class failed when trying to build the JDK, seemingly since it exists in an incubator module, which is not always added to the module graph.

Ok, I can confirm that moving this to be a well-known class will result in a `java/lang/NoClassDefFoundError: jdk/internal/foreign/abi/ProgrammableUpcallHandler` error while trying to build the JDK. I think this is because the particular class is in an incubator module, which is not always present.

I think we'll have to stick with the lazy resolution instead.

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

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

From jvernee at openjdk.java.net  Mon Nov  9 16:34:01 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 9 Nov 2020 16:34:01 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <zQoUYQIxv-d9YTEFZ3oi1CPlJDFWrze3fBQ3LTUX8Ns=.54812730-35b1-4a9e-9e19-29a8f49c45a4@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <cpNCcue6y1OO8obK4QmhiNrdw85BAdAXFLqVbh1RmYc=.ee32d53d-1296-4bd5-8bdd-6632e7ff6af6@github.com>
 <zQoUYQIxv-d9YTEFZ3oi1CPlJDFWrze3fBQ3LTUX8Ns=.54812730-35b1-4a9e-9e19-29a8f49c45a4@github.com>
Message-ID: <UHktcVkQrNrSwiWLLOvg8rdC28g-oLh4t57bctIL04k=.df55a9c4-a4dd-4b9a-9f88-d75575296bea@github.com>

On Fri, 6 Nov 2020 22:02:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 81:
>> 
>>> 79: #endif
>>> 80: 
>>> 81:   Method* method = k->lookup_method(mname_sym, mdesc_sym);
>> 
>> This "method" appears unused.
>
> This should be moved into javaClasses or common code.  resolve_or_null only resolves the class, it doesn't also call the initializer for the class so you shouldn't be able to call a static method on the class.

I'll move this to common code and add a call to `Klass::initialize`

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

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

From jvernee at openjdk.java.net  Mon Nov  9 16:34:05 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 9 Nov 2020 16:34:05 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <cpNCcue6y1OO8obK4QmhiNrdw85BAdAXFLqVbh1RmYc=.ee32d53d-1296-4bd5-8bdd-6632e7ff6af6@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <cpNCcue6y1OO8obK4QmhiNrdw85BAdAXFLqVbh1RmYc=.ee32d53d-1296-4bd5-8bdd-6632e7ff6af6@github.com>
Message-ID: <fCjfFUcswrkqB-pHnb-nyRJNUpuKmNPzTZBwfXaZvnw=.6f65227d-6707-439c-92e7-66de4d910d64@github.com>

On Fri, 6 Nov 2020 22:07:39 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
>> 
>>  - Merge branch '8254162' into 8254231_linker
>>  - Fix post-merge issues caused by 8219014
>>  - Merge branch 'master' into 8254162
>>  - Addess remaining feedback from @AlanBateman and @mrserb
>>  - Address comments from @AlanBateman
>>  - Fix typo in upcall helper for aarch64
>>  - Merge branch '8254162' into 8254231_linker
>>  - Merge branch 'master' into 8254162
>>  - Fix issues with derived buffers and IO operations
>>  - More 32-bit fixes for TestLayouts
>>  - ... and 54 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...b38afb3f
>
> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 68:
> 
>> 66:   Symbol* cname_sym = SymbolTable::new_symbol(cname, (int)strlen(cname));
>> 67:   Symbol* mname_sym = SymbolTable::new_symbol(mname, (int)strlen(mname));
>> 68:   Symbol* mdesc_sym = SymbolTable::new_symbol(mdesc, (int)strlen(mdesc));
> 
> You don't need the strlen() argument.

Ok, I see it has an overload that does that in the header file (and I only looked at the .cpp file. :( )

> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 121:
> 
>> 119:                          upcall_info.upcall_method.name, upcall_info.upcall_method.sig,
>> 120:                          &args, thread);
>> 121: }
> 
> This code shouldn't be in the cpu directory.  This should be in SharedRuntime or in jni.cpp.  It should have a JNI_ENTRY and not transition directly.  I don't know what AttachCurrentThreadAsDaemon does.

Roger that.

We need the thread state transition though in case we get a random native thread calling us.

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

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

From jvernee at openjdk.java.net  Mon Nov  9 16:37:07 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 9 Nov 2020 16:37:07 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <lIajZsJ7LXE6I7upbj-IV39aHVHILgTG52OYWJrndHI=.b4565d6b-d6c6-455f-8aa0-ece5c443a011@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <lIajZsJ7LXE6I7upbj-IV39aHVHILgTG52OYWJrndHI=.b4565d6b-d6c6-455f-8aa0-ece5c443a011@github.com>
Message-ID: <N6U3JGJgeZs6qhgfFr3uO4ss-_fSJ-ACv-odXn9uta8=.48377049-f8aa-4df0-ba47-4d573adc37a4@github.com>

On Mon, 9 Nov 2020 03:52:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
>> 
>>  - Merge branch '8254162' into 8254231_linker
>>  - Fix post-merge issues caused by 8219014
>>  - Merge branch 'master' into 8254162
>>  - Addess remaining feedback from @AlanBateman and @mrserb
>>  - Address comments from @AlanBateman
>>  - Fix typo in upcall helper for aarch64
>>  - Merge branch '8254162' into 8254231_linker
>>  - Merge branch 'master' into 8254162
>>  - Fix issues with derived buffers and IO operations
>>  - More 32-bit fixes for TestLayouts
>>  - ... and 54 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...b38afb3f
>
> src/hotspot/share/prims/universalNativeInvoker.cpp line 40:
> 
>> 38:     assert(thread->thread_state() == _thread_in_native, "thread state is: %d", thread->thread_state());
>> 39:   }
>> 40:   assert(thread->thread_state() == _thread_in_vm, "thread state is: %d", thread->thread_state());
> 
> Is there some reason you don't trust the thread-state transition code and are asserting it updates the state correctly all the time? :) There are already a number of assertions of this kind within the ThreadToNativeFromVM code.

Pre-existing code (to me at least). I agree it seems unnecessary, I'll remove the asserts.

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

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

From jvernee at openjdk.java.net  Mon Nov  9 16:37:09 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 9 Nov 2020 16:37:09 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v14]
In-Reply-To: <037JOlF9tavFXVI6H6AnLiI3GSpcJLiAOANXz_KTWUg=.16b28fcd-302a-42b2-b493-cd2e4e59b9b2@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <P8t0K2fKjwwudHg7xDwbiyVM8plG0ADy34fzxBgROps=.b07a6d4a-660f-4642-9f6c-67027d21f348@github.com>
 <037JOlF9tavFXVI6H6AnLiI3GSpcJLiAOANXz_KTWUg=.16b28fcd-302a-42b2-b493-cd2e4e59b9b2@github.com>
Message-ID: <PGrjeLqm0ONHcAYX8BiQj50L7xF08KjkYCeAls7B350=.3bc18ea9-94cd-437d-b5b5-6b21a0574c41@github.com>

On Mon, 9 Nov 2020 03:56:38 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in upcall helper for aarch64
>
> src/java.base/share/classes/java/lang/System.java line 2086:
> 
>> 2084:                     break;
>> 2085:                 case "allow":
>> 2086:                     allowSecurityManager = MAYBE;
> 
> Why is this removed? I don't see the connection.

Seems to be a problem from a merge gone wrong. Not related as you say. Will remove

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Mon Nov  9 17:32:00 2020
From: github.com+51754783+coreyashford at openjdk.java.net (Corey Ashford)
Date: Mon, 9 Nov 2020 17:32:00 GMT
Subject: RFR: 8248188: Add IntrinsicCandidate and API for Base64 decoding
 [v12]
In-Reply-To: <-7PHVafzbyMukuWngsX5bdLvJPubN2KzjMWM2lrQnCs=.a278b608-3e1c-4126-9791-efe18a5d8d5e@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
 <nU4nZ9oCthDEi7olxerj_bkmWuITInbbNzJKkb1shkY=.28b4ed81-9733-4981-b6fb-c8e4e3bd335e@github.com>
 <r_UoYsBul9SV88OG2z5qfeCfKQFCF23_DDfdB1LKlzY=.2df9f9a4-d0b6-4ac6-b75b-1cd59022eca6@github.com>
 <_JR-e3ZsRFwvZCR7ws34z5jLjp2kJQ1bu4gyl0RG1XU=.ec3040cf-8147-4dcd-b87d-4fd9be4eb59e@github.com>
 <-7PHVafzbyMukuWngsX5bdLvJPubN2KzjMWM2lrQnCs=.a278b608-3e1c-4126-9791-efe18a5d8d5e@github.com>
Message-ID: <W8yVseLKRYUQgq2L6aIoxoDH6PFdk2gp-Q2mo_m-UJo=.585bf9e8-1f27-4fbf-b9b8-2a63a2be798a@github.com>

On Mon, 26 Oct 2020 19:27:59 GMT, Paul Murphy <github.com+12972156+pmur at openjdk.org> wrote:

>> Because the bytes are displayed e15..e8, instead of the other way around, it's hard to follow.  As an example, consider just the last four bytes of the table, but displayed in the reverse order:
>> 
>> 00||b0:0..5    00||b0:6..7||b1:0..3    00||b1:4..7||b2:0..1    00||b2:2..7
>> 
>> After vpextd with bit select pattern 00111111 for all bytes:
>> 
>> b0:0..5||b0:6..7    b1:0..3||1:4..7    b2:0..1||b2:2..7
>> =
>> b0:0..7    b1:0..7    b2:0..7
>> 
>> Should I reverse the order of this table with a comment at the top, to explain the reason for the reversal?  It seems like a good idea.
>
> Since you are operating on doublewords here, expressing this as operations on a doubleword instead of bytes would be more intuitive here.  I think the lane mappings for little endian are what throw me off.

Are you satisfied with the recent changes to the comments?

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

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

From mcimadamore at openjdk.java.net  Mon Nov  9 18:25:27 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 9 Nov 2020 18:25:27 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v16]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <D7MSlNT-UyDFzWtuM-jNTUvX5U24UeegDOOpmtSslOg=.24c9abce-277c-4b42-98c0-3a91e088ed22@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #6 from JornVernee/MoveUpcallInfo
   
   Address review comments
 - - Use lazy constant for upcall_info
   - Reduce copied code between platforms
   - Clean up includes
   - Split thread attach from upcall_helper

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/b38afb3f..e9606edb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=15
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=14-15

  Stats: 463 lines in 8 files changed: 100 ins; 296 del; 67 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

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

From naoto at openjdk.java.net  Tue Nov 10 00:07:16 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 Nov 2020 00:07:16 GMT
Subject: RFR: 8247781: Day periods support [v11]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <lqmBJURhzGemQV8SxRqPuJMjtiR0BJjJmzJeqDLFE3Q=.b3ce354a-c663-490a-8ea6-daf5eefc16d7@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Clarified 24:00 for "midnight" type in the spec. Some clean up.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/7140ae27..ccefe70c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=09-10

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

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

From dholmes at openjdk.java.net  Tue Nov 10 01:51:02 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 10 Nov 2020 01:51:02 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v16]
In-Reply-To: <D7MSlNT-UyDFzWtuM-jNTUvX5U24UeegDOOpmtSslOg=.24c9abce-277c-4b42-98c0-3a91e088ed22@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <D7MSlNT-UyDFzWtuM-jNTUvX5U24UeegDOOpmtSslOg=.24c9abce-277c-4b42-98c0-3a91e088ed22@github.com>
Message-ID: <hH06Qp5hlXJf8Tn--t3KJO86ynJzw9SfAr8LitaLKLI=.73f30472-42aa-40a7-aa42-fcbedfc89ff5@github.com>

On Mon, 9 Nov 2020 18:25:27 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge pull request #6 from JornVernee/MoveUpcallInfo
>    
>    Address review comments
>  - - Use lazy constant for upcall_info
>    - Reduce copied code between platforms
>    - Clean up includes
>    - Split thread attach from upcall_helper

src/hotspot/cpu/aarch64/universalNativeInvoker_aarch64.cpp line 29:

> 27: #include "prims/universalNativeInvoker.hpp"
> 28: #include "memory/resourceArea.hpp"
> 29: #include "code/codeBlob.hpp"

Nit: includes should be in alphabetical order

src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp line 28:

> 26: #include "prims/universalNativeInvoker.hpp"
> 27: #include "memory/resourceArea.hpp"
> 28: #include "code/codeBlob.hpp"

Nit: includes should be in alphabetical order

src/hotspot/share/prims/universalUpcallHandler.cpp line 54:

> 52:   if (thread == nullptr) {
> 53:     JavaVM_ *vm = (JavaVM *)(&main_vm);
> 54:     vm->functions->AttachCurrentThread(vm, (void**) &p_env, nullptr);

The return value should be checked in case of errors.
Making this non-daemon now is probably somewhat safer.

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

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

From david.holmes at oracle.com  Tue Nov 10 02:13:24 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 10 Nov 2020 12:13:24 +1000
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <_Nl5ypHkLlY3aqitzjfT_Rot6lDm6TX3VS3KbTE_gBg=.4a0f5742-bad8-4ceb-805d-2e7e0c51ebf4@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <cpNCcue6y1OO8obK4QmhiNrdw85BAdAXFLqVbh1RmYc=.ee32d53d-1296-4bd5-8bdd-6632e7ff6af6@github.com>
 <nLzZg6qxGVHcXPTOh8dSEnLIAP0ER7lwbTjDBn8dtsk=.eb183041-9dd5-4472-8430-16623e015598@github.com>
 <tMZM86a9J0tRJcNgirnPN2grov9rB4L2yE-pA6LvVys=.3be44d8d-af7f-4cd7-b515-00cbd9b89e3a@github.com>
 <_Nl5ypHkLlY3aqitzjfT_Rot6lDm6TX3VS3KbTE_gBg=.4a0f5742-bad8-4ceb-805d-2e7e0c51ebf4@github.com>
Message-ID: <cb311531-e5a2-f478-672f-3f93f4b95326@oracle.com>

On 10/11/2020 2:34 am, Jorn Vernee wrote:
> On Mon, 9 Nov 2020 12:11:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:
> 
>>> I agree with Coleen.
>>
>> I'll give this another try, but I think last time I tried this resolution of the class failed when trying to build the JDK, seemingly since it exists in an incubator module, which is not always added to the module graph.
> 
> Ok, I can confirm that moving this to be a well-known class will result in a `java/lang/NoClassDefFoundError: jdk/internal/foreign/abi/ProgrammableUpcallHandler` error while trying to build the JDK. I think this is because the particular class is in an incubator module, which is not always present.

Right ... well-known classes appear to be limited to being in java.base 
module.

> I think we'll have to stick with the lazy resolution instead.

I think this could still be done non-racily during VM startup, after 
module system initialization i.e. between:

  call_initPhase2()
  ...
  call_initPhase3()

in Threads::create_vm. And it could still use the mechanisms in 
systemDictionary to define a global accessor I think, even if not 
initialized with the other "well known" classes. I don't have a good 
mental picture of how all the pieces of this connect in terms of Java 
APIs and VM entry points so these structuring suggestions may, or may 
not make sense. Potentially this could be a future cleanup anyway.

Thanks,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/634
> 

From smarks at openjdk.java.net  Tue Nov 10 05:40:02 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 10 Nov 2020 05:40:02 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v2]
In-Reply-To: <Y71HRQPKV6Uc-_6PkgZWl97d3bHhu4BmQjE_pL8MEmA=.f6ab9972-7ed4-41fc-8dcf-c5286b0062fb@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <aBcWsV_NhVd3jaVqcC-TKl38hWXUmEIrSUmsYPPF88g=.2b4b7d94-a3cc-4fc0-a9e7-defa360ee3a0@github.com>
 <zNl6puL1sy_S1JWp3tLiQQf2YrhHvHY3GtGIBjtfz7E=.5eb94743-bfbb-4908-a2af-e9aceb22c9d3@github.com>
 <VeEg7hCJwqiJ8eqvlPLb9Oi6eNx-pgOqTzwshgb01jk=.5169c749-c176-438b-adc2-9e94921aa7c2@github.com>
 <hhibYsPaakZXBiorfc_4a2T6Y0fwkHATDT49wamF5QU=.4b4549f7-863d-4902-a34c-7648d806d4fd@github.com>
 <ItQDJF_yBhjEKceLh1skwy3tYtIY5T_TxOQX0h6nYBI=.0503f471-5876-4448-80b3-968a16f38293@github.com>
 <Y71HRQPKV6Uc-_6PkgZWl97d3bHhu4BmQjE_pL8MEmA=.f6ab9972-7ed4-41fc-8dcf-c5286b0062fb@github.com>
Message-ID: <yn1aWOyMO0wVvLseEu7_r9omiOyWmo1GtXUWmwpUDEg=.2202c00b-1e0a-4054-acea-5196c9552f40@github.com>

On Sun, 8 Nov 2020 15:55:58 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Hi Stuart,
>> 
>> I would like to discuss the serialization. You introduce new CollSer.IMM_LIST_NULLS type of immutable collection. This means that if this change goes into JDK16 for example, JDK15 and before will not be able to deserialize such list as they know nothing about IMM_LIST_NULLS even if such lists don't contain nulls. The reason you say to chose new type of serialization format is the following:
>> 
>>> "Suppose I had an application that created a data structure that used lists from List.of(), and I had a global assertion over that structure that it contained no nulls. Further suppose that I serialized and deserizalized this structure. I'd want that assertion to be preserved after deserialization. If another app (or a future version of this app) created the structure using Stream.to
>>>  List(), this would allow nulls to leak into that structure and violate that assertion. Therefore, the result of Stream.toList() should not be serialization-compatible with List.of() et. al. That's why there's the new IMM_LIST_NULLS tag in the serial format"
>> 
>> I don't quite get this reasoning. Let's try to decompose the reasoning giving an example. Suppose we had the following data structure:
>> 
>> public class Names implements Serializable {
>>   private final List<String> names;
>>   Names(List<String> names) {
>>     this.names = names;
>>   }
>>   public List<String> names() { return names; }
>> }
>> 
>> App v1 creates such structures using new Names(List.of(...)) and serializes/deserializes them. They keep the invariant that no nulls are present. Now comes App v2 that starts using new Names(stream.toList()) which allows nulls to be present. When such Names instance from app v2 is serialized and then deserialized in app v1, nulls "leak" into data structure of app v1 that does not expect them.
>> 
>> But the question is how does having a separate CollSer.IMM_LIST_NULLS type prevent that from happening?
>
> I can see that having a separate IMM_LIST_NULLS type might be necessary to preserve the allows-null/disallows-null behaviour of indexOf and lastIndexOf methods...
> 
> NOTE ALSO that ListN.equals(o) and ListN.hashCode() are inherited from AbstractImmutableList:
> 
>         @Override
>         public boolean equals(Object o) {
>             if (o == this) {
>                 return true;
>             }
> 
>             if (!(o instanceof List)) {
>                 return false;
>             }
> 
>             Iterator<?> oit = ((List<?>) o).iterator();
>             for (int i = 0, s = size(); i < s; i++) {
>                 if (!oit.hasNext() || !get(i).equals(oit.next())) {
>                     return false;
>                 }
>             }
>             return !oit.hasNext();
>         }
> and
>         public int hashCode() {
>             int hash = 1;
>             for (int i = 0, s = size(); i < s; i++) {
>                 hash = 31 * hash + get(i).hashCode();
>             }
>             return hash;
>         }
> 
> ...which means they will throw NPE when the list contains null. The same goes for SubList.

@plevart wrote:
> But the question is how does having a separate CollSer.IMM_LIST_NULLS type prevent that from happening?

When a serialized list with IMM_LIST_NULLS is deserialized on an older JDK, it'll throw InvalidObjectException since that tag isn't valid on older JDKs. Obviously this is still an error, but it's a fail-fast approach that avoids letting nulls leak into a data structure where they might cause a problem some arbitrary time later.

> NOTE ALSO that ListN.equals(o) and ListN.hashCode() are inherited from AbstractImmutableList [...] which means they will throw NPE when the list contains null. The same goes for SubList.

Good catch! Yes, this is a problem. I'll do some rearranging here and add more test cases. Thanks for spotting this.

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

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

From plevart at openjdk.java.net  Tue Nov 10 09:37:58 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Tue, 10 Nov 2020 09:37:58 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v2]
In-Reply-To: <Y71HRQPKV6Uc-_6PkgZWl97d3bHhu4BmQjE_pL8MEmA=.f6ab9972-7ed4-41fc-8dcf-c5286b0062fb@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <aBcWsV_NhVd3jaVqcC-TKl38hWXUmEIrSUmsYPPF88g=.2b4b7d94-a3cc-4fc0-a9e7-defa360ee3a0@github.com>
 <zNl6puL1sy_S1JWp3tLiQQf2YrhHvHY3GtGIBjtfz7E=.5eb94743-bfbb-4908-a2af-e9aceb22c9d3@github.com>
 <VeEg7hCJwqiJ8eqvlPLb9Oi6eNx-pgOqTzwshgb01jk=.5169c749-c176-438b-adc2-9e94921aa7c2@github.com>
 <hhibYsPaakZXBiorfc_4a2T6Y0fwkHATDT49wamF5QU=.4b4549f7-863d-4902-a34c-7648d806d4fd@github.com>
 <ItQDJF_yBhjEKceLh1skwy3tYtIY5T_TxOQX0h6nYBI=.0503f471-5876-4448-80b3-968a16f38293@github.com>
 <Y71HRQPKV6Uc-_6PkgZWl97d3bHhu4BmQjE_pL8MEmA=.f6ab9972-7ed4-41fc-8dcf-c5286b0062fb@github.com>
Message-ID: <EKK54iv-Ok1SZ1XEeUTm-Yjofp-lSOaRFpyKixb-xKI=.f6489482-9026-46aa-8a1f-afa8dd9d4d58@github.com>

On Sun, 8 Nov 2020 15:55:58 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Hi Stuart,
>> 
>> I would like to discuss the serialization. You introduce new CollSer.IMM_LIST_NULLS type of immutable collection. This means that if this change goes into JDK16 for example, JDK15 and before will not be able to deserialize such list as they know nothing about IMM_LIST_NULLS even if such lists don't contain nulls. The reason you say to chose new type of serialization format is the following:
>> 
>>> "Suppose I had an application that created a data structure that used lists from List.of(), and I had a global assertion over that structure that it contained no nulls. Further suppose that I serialized and deserizalized this structure. I'd want that assertion to be preserved after deserialization. If another app (or a future version of this app) created the structure using Stream.to
>>>  List(), this would allow nulls to leak into that structure and violate that assertion. Therefore, the result of Stream.toList() should not be serialization-compatible with List.of() et. al. That's why there's the new IMM_LIST_NULLS tag in the serial format"
>> 
>> I don't quite get this reasoning. Let's try to decompose the reasoning giving an example. Suppose we had the following data structure:
>> 
>> public class Names implements Serializable {
>>   private final List<String> names;
>>   Names(List<String> names) {
>>     this.names = names;
>>   }
>>   public List<String> names() { return names; }
>> }
>> 
>> App v1 creates such structures using new Names(List.of(...)) and serializes/deserializes them. They keep the invariant that no nulls are present. Now comes App v2 that starts using new Names(stream.toList()) which allows nulls to be present. When such Names instance from app v2 is serialized and then deserialized in app v1, nulls "leak" into data structure of app v1 that does not expect them.
>> 
>> But the question is how does having a separate CollSer.IMM_LIST_NULLS type prevent that from happening?
>
> I can see that having a separate IMM_LIST_NULLS type might be necessary to preserve the allows-null/disallows-null behaviour of indexOf and lastIndexOf methods...
> 
> NOTE ALSO that ListN.equals(o) and ListN.hashCode() are inherited from AbstractImmutableList:
> 
>         @Override
>         public boolean equals(Object o) {
>             if (o == this) {
>                 return true;
>             }
> 
>             if (!(o instanceof List)) {
>                 return false;
>             }
> 
>             Iterator<?> oit = ((List<?>) o).iterator();
>             for (int i = 0, s = size(); i < s; i++) {
>                 if (!oit.hasNext() || !get(i).equals(oit.next())) {
>                     return false;
>                 }
>             }
>             return !oit.hasNext();
>         }
> and
>         public int hashCode() {
>             int hash = 1;
>             for (int i = 0, s = size(); i < s; i++) {
>                 hash = 31 * hash + get(i).hashCode();
>             }
>             return hash;
>         }
> 
> ...which means they will throw NPE when the list contains null. The same goes for SubList.

> @plevart wrote:
> 
> > But the question is how does having a separate CollSer.IMM_LIST_NULLS type prevent that from happening?
> 
> When a serialized list with IMM_LIST_NULLS is deserialized on an older JDK, it'll throw InvalidObjectException since that tag isn't valid on older JDKs. Obviously this is still an error, but it's a fail-fast approach that avoids letting nulls leak into a data structure where they might cause a problem some arbitrary time later.
> 

Yes, but that is JDK16+ vs. JDK15- and not App V1 vs. App V2 thing. If both apps run on JDK16+, there will be no exception.

What I'm trying to say is that the same problem of injecting unexpected nulls via serialization/deserialization can happen also if App V2 starts using ArrayList to construct the data structure and serialize it while App V1 deserializes it and expects non-null values only. App V1 would already have to guard against null values during deserialization in that case, because possibility of null values in deserialized data structure is nothing new for App V1.

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

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

From rkennke at openjdk.java.net  Tue Nov 10 09:43:02 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 10 Nov 2020 09:43:02 GMT
Subject: RFR: 8256106: Bypass intrinsic/barrier when calling Reference.get()
 from Finalizer
Message-ID: <CFzWfHREh0P7xzdn5-X5I0gqV5YG4Xs70Oo2Zd6ZCfY=.f4af9a11-e99c-4bb7-a254-b2cf05ef2ba0@github.com>

Finalizer calls Reference.get() from the Finalizer to acquire the finalizee. Concurrent reference processing GCs like Shenandoah and ZGC would return NULL for unreachable referents, and thus would not call finalize() on them.

ZGC works around this by fixing the referent before enqueuing, so that the barrier would take the fast-path, but Shenandoah cannot do this.

It is ok to bypass the barrier altogether in this place, because the FinalReference is inactive and marking and reference-discovery treat inactive FinalReferences like strong references.

Testing:
 - [x] hotspot_gc_shenandoah
 - [x] tier1 +UseShenandoahGC +ShenandoahVerify
 - [x] tier2 +UseShenandoahGC +ShenandoahVerify
 - [ ] tier1
 - [ ] tier2

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

Commit messages:
 - 8256106: Bypass intrinsic/barrier when calling Reference.get() from Finalizer

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

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

From alanb at openjdk.java.net  Tue Nov 10 11:03:55 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 10 Nov 2020 11:03:55 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v26]
In-Reply-To: <NCctjv7i5o9hX26cfcXS7Xc5Kcb0sMFdD3Nmd7BtKC0=.c4dc7496-ac84-4c5f-8753-274138deca85@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
 <NCctjv7i5o9hX26cfcXS7Xc5Kcb0sMFdD3Nmd7BtKC0=.c4dc7496-ac84-4c5f-8753-274138deca85@github.com>
Message-ID: <BbD1GrXSR4IFF6U-IkAzbpzwBAMhcR584AvTKYG495w=.59b311a0-e531-4fe3-8fd6-948767c8fc7b@github.com>

On Mon, 9 Nov 2020 16:07:13 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
>> 
>> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
>> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
>> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
>> 
>> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
>> 
>> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
>> 
>> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
>> 
>> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
>> 
>> Thanks 
>> Maurizio 
>> 
>> Javadoc: 
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff: 
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
>> 
>> CSR: 
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254163
>> 
>> 
>> 
>> ### API Changes
>> 
>> * `MemorySegment`
>>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>>   * added a no-arg factory for a native restricted segment representing entire native heap
>>   * rename `withOwnerThread` to `handoff`
>>   * add new `share` method, to create shared segments
>>   * add new `registerCleaner` method, to register a segment against a cleaner
>>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
>> * `MemoryAddress`
>>   * drop `segment` accessor
>>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
>> * `MemoryAccess`
>>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
>> * `MemoryHandles`
>>   * drop `withOffset` combinator
>>   * drop `withStride` combinator
>>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
>> * `Addressable`
>>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
>> * `MemoryLayouts`
>>   * A new layout, for machine addresses, has been added to the mix.
>> 
>> 
>> 
>> ### Implementation changes
>> 
>> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
>> 
>> #### Shared segments
>> 
>> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
>> 
>> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
>> 
>> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
>> 
>> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
>> 
>> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
>> 
>> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
>> 
>> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
>> 
>> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
>> 
>> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
>> 
>> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
>> 
>> #### Memory access var handles overhaul
>> 
>> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
>> 
>> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
>> 
>> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
>> 
>> #### Test changes
>> 
>> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
>> 
>> [1] - https://openjdk.java.net/jeps/393
>> [2] - https://openjdk.java.net/jeps/389
>> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
>> [4] - https://openjdk.java.net/jeps/312
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more output in TestHandhsake.java

Marked as reviewed by alanb (Reviewer).

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

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

From github.com+654217+bastie at openjdk.java.net  Tue Nov 10 11:47:55 2020
From: github.com+654217+bastie at openjdk.java.net (Sebastian Ritter)
Date: Tue, 10 Nov 2020 11:47:55 GMT
Subject: RFR: 8066622 8066637: remove deprecated using
 java.io.File.toURL() in internal classes
In-Reply-To: <JyzlXMPWtFSGD9k-MTyqrK4EOw_ju8VVXO3niuy66ag=.d8d9124d-c831-4879-a44d-13412ce4da64@github.com>
References: <EbSZJq5R0_NZWXVivUsn-nJoOwHQCtYwUrUrPOeKa0c=.5877af1b-0db2-4064-bc35-638151ecc774@github.com>
 <JyzlXMPWtFSGD9k-MTyqrK4EOw_ju8VVXO3niuy66ag=.d8d9124d-c831-4879-a44d-13412ce4da64@github.com>
Message-ID: <kbeKe8e0KYLcdTALuu35QXQQALktrXXoQ05kilJo8qQ=.b430e927-3454-4a39-8b67-b7926a3be016@github.com>

On Sun, 8 Nov 2020 16:58:24 GMT, Phil Race <prr at openjdk.org> wrote:

> You reference a desktop bug that discusses many, many deprecations ...
Yep. In my opinion this is a bot problem here and need other place to discuss. 

> Yet you propose to fix precisely one of these.
@prrace:  Not really. 
The way to work with problems differ. Both bugs - maybe these are more quality change requests than bugs - are bullet lists and are created on build process. The different is, I work on single quality tests and remove deprecated code from source base. So in my clean Java build the method java.io.File.toUrl() does not(!) exist. 
Because java.io.File.toURL() doesn't exist, also two patches are needed for JDK build process (internal I use diff-patch).

> And I'd like to hear whether you actually _tested_ splashscreen with your change ? I see no sign that you did.
I'm not sure, what you want to listen. I work with a clean Java build with patch to remove java.io.File.toURL() and change the collateral damages.

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

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

From mcimadamore at openjdk.java.net  Tue Nov 10 12:10:26 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 10 Nov 2020 12:10:26 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v17]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <KH7tOt-NLmeK4onkahGLePE7vylhMWmxtDTMwbm8DSs=.52105df3-f69f-4c29-90c9-b30f153a701f@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

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

  Address more CSR feedback

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/e9606edb..9960b3d7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=16
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=15-16

  Stats: 50 lines in 6 files changed: 0 ins; 30 del; 20 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

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

From mcimadamore at openjdk.java.net  Tue Nov 10 14:16:22 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 10 Nov 2020 14:16:22 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v18]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <AK-p2u_9FlJzupbJzCMvC55iWN_5j5lNwy8q1SXGObI=.615fee87-b80b-4bcf-8b6e-33c758eb4da4@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision:

 - Merge pull request #7 from JornVernee/Additional_Review_Comments
   
   Additional review comments
 - Revert System.java changes
 - Set copyright year for added files to 2020
 - Check result of AttachCurrentThread
 - Sort includes alphabetically
 - Relax ret_addr_offset() assert
 - Extra space after if
 - remove excessive asserts in ProgrammableInvoker::invoke_native
 - Remove os::is_MP() check
 - remove blank line in thread.hpp

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/9960b3d7..efc969dc

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=16-17

  Stats: 90 lines in 56 files changed: 14 ins; 13 del; 63 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

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

From jvernee at openjdk.java.net  Tue Nov 10 14:28:06 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 10 Nov 2020 14:28:06 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <lIajZsJ7LXE6I7upbj-IV39aHVHILgTG52OYWJrndHI=.b4565d6b-d6c6-455f-8aa0-ece5c443a011@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <lIajZsJ7LXE6I7upbj-IV39aHVHILgTG52OYWJrndHI=.b4565d6b-d6c6-455f-8aa0-ece5c443a011@github.com>
Message-ID: <HQ6ik2TWYeDxbwdroLcvNssU0uoIM8_ZxmShtGoDiAE=.61b0558c-9684-4c11-b284-42c45f1ec4bc@github.com>

On Mon, 9 Nov 2020 04:10:30 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 64 commits:
>> 
>>  - Merge branch '8254162' into 8254231_linker
>>  - Fix post-merge issues caused by 8219014
>>  - Merge branch 'master' into 8254162
>>  - Addess remaining feedback from @AlanBateman and @mrserb
>>  - Address comments from @AlanBateman
>>  - Fix typo in upcall helper for aarch64
>>  - Merge branch '8254162' into 8254231_linker
>>  - Merge branch 'master' into 8254162
>>  - Fix issues with derived buffers and IO operations
>>  - More 32-bit fixes for TestLayouts
>>  - ... and 54 more: https://git.openjdk.java.net/jdk/compare/a50fdd54...b38afb3f
>
> A high-level scan through - mostly VM files.

I've addressed the open review comments. One of the commits is a bigger change that removes the code duplication in the upcall handler code. The initialization code is moved to the ProgrammableUpcallHandler class' constructor instead. That class is then lazily instantiated using a local `static` variable (see ProgrammableUpcallHandler::instance), which since C++11 guarantees thread-safe initialize-once behaviour.

Along with those  changes I've also removed some other duplicated code in the native invoker code (ProgrammableInvokerGenerator), cleaned up the includes most files, as well as using a JNI_ENTRY function when doing upcalls (as requested), by splitting the current functionality of the upcall_helper function in 2; one function that does the thread attach, and then other that does the actual upcall (which is the one using JNI_ENTRY). (see: https://github.com/openjdk/jdk/pull/634/commits/719224ca9dc70fce6d28885acfb362fee715ebbd). As discussed, changing ProgrammableUpcallHandler to be a well-known class didn't work, since it is not in java.base.

Changes: 

- Merge both versions of upcall_init and move the code to (the constructor of) ProgrammableUpcallHandler. Using the same lazy singleton pattern as for ForeignGlobals to make initialization thread-safe.
 - Merge both PorgrammableInvokeGenerator classes into a shared ProgrammableInvoke::Generator class.
 - Also move ProgrammableStub to ProgrammableInvoke::Stub for better name-spacing
 - Also move native_invoker_size constant to ProgrammableInvoker (we now have 1 instead of 2)
 - Merge ProgrammableInvoker::Generator::generate and top-level generate_invoke_native functions (avoiding the need to forward fields)
 - Split upcall_helper method into ProgrammableUpcallHandler::attach_thread_and_do_upcall and upcall_helper. The former does the thread attach/detach, the latter does the actual upcall.
 - Add a few comments to ProgrammableUpcallHandler::generate_upcall_stub
 - Remove unused imports

The rest of the review comments were addressed in a set of smaller commits (see timeline on GitHub). The changes therein are:

- remove blank line in thread.hpp
- Remove os::is_MP() check
- remove excessive asserts in ProgrammableInvoker::invoke_native
- Extra space after if in jni_util_md (Windows)
- Relax ret_addr_offset() assert
- Sort includes alphabetically in upcallHandler CPU files
- Check result of AttachCurrentThread call
- Set copyright year for added files to 2020 (I didn't touch the ARM copyright headers)

That should address all open review comments (but please let me know if I've missed something).

Thanks for the reviews so far.

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

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

From jvernee at openjdk.java.net  Tue Nov 10 15:02:08 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 10 Nov 2020 15:02:08 GMT
Subject: RFR: 8254354: Add a withInvokeExactBehavior() VarHandle
 combinator [v14]
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <5wtCS4QJyQ6mPJlqrcywN5j-pViezdNeE9L9CgxppoQ=.04154754-3453-4c94-a40b-fd35de56628a@github.com>

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn
> 
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375

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

  Re-order javadoc

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/843/files
  - new: https://git.openjdk.java.net/jdk/pull/843/files/ea7c920c..3097f080

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

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

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

From chegar at openjdk.java.net  Tue Nov 10 16:30:56 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 10 Nov 2020 16:30:56 GMT
Subject: RFR: 8254354: Add a withInvokeExactBehavior() VarHandle
 combinator [v14]
In-Reply-To: <5wtCS4QJyQ6mPJlqrcywN5j-pViezdNeE9L9CgxppoQ=.04154754-3453-4c94-a40b-fd35de56628a@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <5wtCS4QJyQ6mPJlqrcywN5j-pViezdNeE9L9CgxppoQ=.04154754-3453-4c94-a40b-fd35de56628a@github.com>
Message-ID: <_s4YCnGkPtElh5bRQ9b70NsCtRexsAwNNXw6QJT6LWA=.6bd837d5-47a9-44ac-a891-7476bfbe393d@github.com>

On Tue, 10 Nov 2020 15:02:08 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Hi,
>> 
>> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
>> 
>> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
>> 
>> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
>> 
>> Thanks,
>> Jorn
>> 
>> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Re-order javadoc

LGTM.

The test could be sprinkled with a number of assertions related to the invocation behaviour, a.k.a `hasInvokeExactBehavior`; either the newly specified default behaviour assertFalse(vh. hasInvokeExactBehavior()), or post switching to exact: assertTrue(vh. hasInvokeExactBehavior())

test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java line 82:

> 80:             throws NoSuchFieldException, IllegalAccessException {
> 81:         if (ro) throw new SkipException("Can not test setter with read only field");
> 82:         VarHandle vh = MethodHandles.lookup().findVarHandle(Widget.class, fieldBaseName + "_RW", fieldType);

Quite trivially we can assertFalse(vh. hasInvokeExactBehavior())

test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java line 92:

> 90:         }
> 91: 
> 92:         vh = vh.withInvokeExactBehavior();

Quite trivially we can assertTrue(vh. hasInvokeExactBehavior())

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

Marked as reviewed by chegar (Reviewer).

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

From mchung at openjdk.java.net  Tue Nov 10 17:55:04 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 10 Nov 2020 17:55:04 GMT
Subject: Integrated: 8256066: Tests use deprecated TestNG API that is no
 longer available in new versions
Message-ID: <53FItwfbemM2Ij99amqBaMlvVi95Sl5AlYyJkUUSjsQ=.2aedf368-d84e-4696-aad1-6a447b9dcdc4@github.com>

@ExpectedExceptions is no longer available in TestNG 7.*.  Update the tests
to use @Test(expectedExceptions = "...") instead.

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

Commit messages:
 - 8256066: Tests use deprecated TestNG API that is no longer available in new versions

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

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

From jjg at openjdk.java.net  Tue Nov 10 17:55:04 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Tue, 10 Nov 2020 17:55:04 GMT
Subject: Integrated: 8256066: Tests use deprecated TestNG API that is no
 longer available in new versions
In-Reply-To: <53FItwfbemM2Ij99amqBaMlvVi95Sl5AlYyJkUUSjsQ=.2aedf368-d84e-4696-aad1-6a447b9dcdc4@github.com>
References: <53FItwfbemM2Ij99amqBaMlvVi95Sl5AlYyJkUUSjsQ=.2aedf368-d84e-4696-aad1-6a447b9dcdc4@github.com>
Message-ID: <2CmUvmTmaKIS2nl28zk6f55qH__Hz3RApx9kdXxWkbk=.1d667157-79b1-4f37-b0d1-239a6e65ebb3@github.com>

On Tue, 10 Nov 2020 17:41:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> @ExpectedExceptions is no longer available in TestNG 7.*.  Update the tests
> to use @Test(expectedExceptions = "...") instead.

Marked as reviewed by jjg (Reviewer).

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

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

From mchung at openjdk.java.net  Tue Nov 10 17:55:05 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 10 Nov 2020 17:55:05 GMT
Subject: Integrated: 8256066: Tests use deprecated TestNG API that is no
 longer available in new versions
In-Reply-To: <53FItwfbemM2Ij99amqBaMlvVi95Sl5AlYyJkUUSjsQ=.2aedf368-d84e-4696-aad1-6a447b9dcdc4@github.com>
References: <53FItwfbemM2Ij99amqBaMlvVi95Sl5AlYyJkUUSjsQ=.2aedf368-d84e-4696-aad1-6a447b9dcdc4@github.com>
Message-ID: <IGMvV9ONftrmrX6KbDjO7odFssdAmlbwfvpd-Y0zsms=.7801c2f1-c2b6-4a97-a571-f413af8de3d2@github.com>

On Tue, 10 Nov 2020 17:41:28 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> @ExpectedExceptions is no longer available in TestNG 7.*.  Update the tests
> to use @Test(expectedExceptions = "...") instead.

This pull request has now been integrated.

Changeset: 6d8acd26
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6d8acd26
Stats:     12 lines in 3 files changed: 0 ins; 6 del; 6 mod

8256066: Tests use deprecated TestNG API that is no longer available in new versions

Reviewed-by: jjg

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

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

From nlisker at gmail.com  Tue Nov 10 17:58:46 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 10 Nov 2020 19:58:46 +0200
Subject: 'Find' method for Iterable
In-Reply-To: <CA+0ynh-54KbmQrshE4cJdJ8Q=MCBEUbN3cnW7=J=6Xbr1g5HmQ@mail.gmail.com>
References: <CA+0ynh9wguU9b4ZQnOz=ySeSa9sovYzeeQ=rAa8fPJCpo=gXag@mail.gmail.com>
 <219103610.2532126.1600289966746.JavaMail.zimbra@u-pem.fr>
 <e4abaa1c-2d82-4ceb-a046-f914cb6056af@oracle.com>
 <CA+0ynh-54KbmQrshE4cJdJ8Q=MCBEUbN3cnW7=J=6Xbr1g5HmQ@mail.gmail.com>
Message-ID: <CA+0ynh9n9+_4+AQkLoiD8vvKCgdCV3YCuC0QsA=eHtN+-e9hZQ@mail.gmail.com>

Did this discussion get lost?

On Sun, Sep 20, 2020 at 1:27 AM Nir Lisker <nlisker at gmail.com> wrote:

> While it might not be difficult to add a find() method to Iterable, why
>> limit it to
>> the find operation, and what about all the other operations available on
>> Stream?
>
>
> Good question. I would say it's a matter of how much it is used and what
> it takes to implement it. The find operation is a lot more common than
> reduce from what I observe, for example, so I wouldn't suggest reduce to be
> added..A map(Function<T,R>) operation would require creating a new
> collection/iterable internally, and that can be messy (you could
> preemptively create and pass your own, but then I doubt the worthiness of
> it). forEach already exists. I just don't see anything enticing.
>
> Maybe what's necessary is a way to convert an Iterable to a Stream.
>
>
> Most Iterables are Collections and arrays, and these are easy to convert,
> so I'm not sure if that really helps. Besides,the idea is to avoid Stream,
> as I've mentioned, due to the cumbersomeness and the overhead of creating a
> stream. If I need to do
>
> iterable.stream().filter(person -> person.id == 123456).findAny/First()
>
> then I didn't really solve my problem.
>
> On the other hand, your examples use a list. The List interface already
>> has methods
>> indexOf/lastIndexOf which search the list for a particular object that's
>> compared
>> using equals(). It seems reasonable to consider similar methods that take
>> a
>> predicate instead of an object.
>
>
> I could have used a Set just as well. As for indexOf(Predicate<T>), I
> would say that it is useful (but personally, I hardly ever need the index
> of an object, I need the object itself). Interestingly,
> removeIf(Predicate<T>) exists, but remove(Predicate<T>) doesn't. I would
> think twice before suggesting to add it though.
>
> Ultimately, you have access to a lot of analytics and codebase scans. If
> you know which patterns are used a lot more than others it would be a good
> guide. If there are a lot of iterations in order to find an object, its
> index, or to remove it (or something else), perhaps it's worth supplying
> these methods. After all, forEach(Consumer<T>) exists and it iterates while
> calling accept(t) - not that different from iterating with test(t).
>
> P.S. lastIndexOf I find odd in the sense that it's the only method I found
> that iterates backwards, We don't have, removeLast, removeIfBackwards,
> forEachBackwards, a backwards for-each loop, or addLast (the latter is
> add(list.size()-1, e); ).
>
> - Nir
>
> On Thu, Sep 17, 2020 at 1:32 AM Stuart Marks <stuart.marks at oracle.com>
> wrote:
>
>>
>>
>> On 9/16/20 1:59 PM, Remi Forax wrote:
>> > ----- Mail original -----
>> >> De: "Nir Lisker" <nlisker at gmail.com>
>> >> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> >> Envoy?: Lundi 14 Septembre 2020 20:56:27
>> >> Objet: 'Find' method for Iterable
>> >
>> >> Hi,
>> >>
>> >> This has probably been brought up at some point. When we need to find
>> an
>> >> item in a collection based on its properties, we can either do it in a
>> >> loop, testing each item, or in a stream with filter and findFirst/Any.
>> >>
>> >> I would think that a method in Iterable<T> be useful, along the lines
>> of:
>> >>
>> >> public <T> Optional<T> find(Predicate<T> condition) {
>> >>     Objects.requireNonNull(condition);
>> >>     for (T t : this) {
>> >>          if (condition.test(t)) {
>> >>              return Optional.of(t);
>> >>         }
>> >>     }
>> >>     return Optional.empty();
>> >> }
>> >>
>> >> With usage:
>> >>
>> >> list.find(person -> person.id == 123456);
>> >>
>> >> There are a few issues with the method here such as t being null in
>> >> null-friendly collections and the lack of bound generic types, but this
>> >> example is just used to explain the intention.
>> >>
>> >> It will be an alternative to
>> >>
>> >> list.stream().filter(person -> person.id == 123456).findAny/First()
>> >> (depending on if the collection is ordered or not)
>> >>
>> >> which doesn't create a stream, similar to Iterable#forEach vs
>> >> Stream#forEach.
>> >>
>> >> Maybe with pattern matching this would become more appetizing.
>> >
>> > During the development of Java 8, we first tried to use
>> Iterator/Iterable instead of using a novel interface Stream.
>> > But a Stream cleanly separate the lazy side effect free API from the
>> mutable one (Collection) and can be optimized better by the VM (it's a push
>> API instead of being a pull API).
>> >
>> > The other question is why there is no method find() on Collection, i
>> believe it's because while find() is ok for any DB API, find() is dangerous
>> on a Collection because the execution time is linear, so people may use it
>> instead of using a Map.
>>
>>
>> Hi Nir,
>>
>> R?mi is correct to point out this distinction between the lazy operations
>> (which
>> appear on Stream) and the eager (and possibly mutating) operations on
>> Collections. I
>> think we want to preserve this distinction.
>>
>> While it might not be difficult to add a find() method to Iterable, why
>> limit it to
>> the find operation, and what about all the other operations available on
>> Stream?
>> Maybe what's necessary is a way to convert an Iterable to a Stream. In
>> fact, this is
>> already possible:
>>
>>      StreamSupport.stream(iterable.spliterator(), false)
>>
>> Well, this is mouthful, so maybe there ought to be an easier way to
>> convert an
>> Iterable to a Stream.
>>
>> On the other hand, your examples use a list. The List interface already
>> has methods
>> indexOf/lastIndexOf which search the list for a particular object that's
>> compared
>> using equals(). It seems reasonable to consider similar methods that take
>> a
>> predicate instead of an object.
>>
>> Does either of these sound promising?
>>
>> s'marks
>>
>

From jvernee at openjdk.java.net  Tue Nov 10 18:01:09 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 10 Nov 2020 18:01:09 GMT
Subject: RFR: 8254354: Add a withInvokeExactBehavior() VarHandle
 combinator [v15]
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <YlzU053AE4rGi9Rk6lPBEcI3nZ3IiU0ZO5P5A74DU18=.a2f02d1a-3275-44a9-9bd3-5b025044f518@github.com>

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn
> 
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375

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

  Add additional asserts to tests checking result of hasInvokeExactBehavior

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/843/files
  - new: https://git.openjdk.java.net/jdk/pull/843/files/3097f080..4248f7ee

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

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

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

From jvernee at openjdk.java.net  Tue Nov 10 18:01:10 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 10 Nov 2020 18:01:10 GMT
Subject: RFR: 8254354: Add a withInvokeExactBehavior() VarHandle
 combinator [v14]
In-Reply-To: <_s4YCnGkPtElh5bRQ9b70NsCtRexsAwNNXw6QJT6LWA=.6bd837d5-47a9-44ac-a891-7476bfbe393d@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
 <5wtCS4QJyQ6mPJlqrcywN5j-pViezdNeE9L9CgxppoQ=.04154754-3453-4c94-a40b-fd35de56628a@github.com>
 <_s4YCnGkPtElh5bRQ9b70NsCtRexsAwNNXw6QJT6LWA=.6bd837d5-47a9-44ac-a891-7476bfbe393d@github.com>
Message-ID: <wQdn2TgKCUNXcRI7qO7-QX3rUfUbZYckbmUyyMdrTho=.537fec1c-865d-4858-8001-a5aff181f2d9@github.com>

On Tue, 10 Nov 2020 16:27:48 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Re-order javadoc
>
> LGTM.
> 
> The test could be sprinkled with a number of assertions related to the invocation behaviour, a.k.a `hasInvokeExactBehavior`; either the newly specified default behaviour assertFalse(vh. hasInvokeExactBehavior()), or post switching to exact: assertTrue(vh. hasInvokeExactBehavior())

@ChrisHegarty Good suggestion! Added.

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

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

From herrick at openjdk.java.net  Tue Nov 10 18:17:56 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 10 Nov 2020 18:17:56 GMT
Subject: RFR: 8233332: Need to create exploded tests covering all forms of
 modules
In-Reply-To: <x3sGxQki-zqnyuH2AbS-L55BB31wPNP0iqnytFD1ogo=.2bdd5824-435f-4194-8389-50182593d0f0@github.com>
References: <x3sGxQki-zqnyuH2AbS-L55BB31wPNP0iqnytFD1ogo=.2bdd5824-435f-4194-8389-50182593d0f0@github.com>
Message-ID: <VbEYICrf3i59YO7ur8UoiGujXDrTaHge0Ak36MtTM5Q=.5470e2b8-70f7-433a-b91d-6fa4dd28f44c@github.com>

On Fri, 6 Nov 2020 21:59:51 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8233332: Need to create exploded tests covering all forms of modules

looks good.

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

Marked as reviewed by herrick (Reviewer).

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

From shade at openjdk.java.net  Tue Nov 10 18:39:00 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 10 Nov 2020 18:39:00 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v2]
In-Reply-To: <pLjfXREv5ofhOmaYMK_9UZ7uqCgGOlgM9SRdaSfXD2w=.6e6503d8-e782-44ce-9fc1-32e716823b78@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <pLjfXREv5ofhOmaYMK_9UZ7uqCgGOlgM9SRdaSfXD2w=.6e6503d8-e782-44ce-9fc1-32e716823b78@github.com>
Message-ID: <pnJkCrvIkTmD7TDNr_gtN9a0ugbHOtd-_DxOoHpkEVw=.b1e11a05-f0d8-4cb2-9d3c-eae6f0d69234@github.com>

On Sun, 8 Nov 2020 05:07:07 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> ?AccessorImpl object
>> 
>> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
>> 
>> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
>> 
>> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.
>
> Hui Shi 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:
> 
>   8255883: Avoid multiple GeneratedAccessor for same NativeMethod/ConstructorAccessorImpl object

Minor nits here.

src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java line 37:

> 35: 
> 36: class NativeConstructorAccessorImpl extends ConstructorAccessorImpl {
> 37:     private static final Unsafe unsafe = Unsafe.getUnsafe();

`static final` field identifiers should be capitalized. Suggestion: `private static final Unsafe U = Unsafe.getUnsafe()`.

src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java line 38:

> 36: class NativeConstructorAccessorImpl extends ConstructorAccessorImpl {
> 37:     private static final Unsafe unsafe = Unsafe.getUnsafe();
> 38:     private static final long accessorGeneratedaOffset

Typo "Generated*a*Offset". But also this is `static final`, so it should be e.g. `GENERATED_OFFSET`. The field can be just `generated` to match the name of this offset.

src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java line 61:

> 59:                 && !c.getDeclaringClass().isHidden()
> 60:                 && !ReflectUtil.isVMAnonymousClass(c.getDeclaringClass())
> 61:                 && accessorGenerated == false

Should be `!accessorGenerated`.

src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java line 62:

> 60:                 && !ReflectUtil.isVMAnonymousClass(c.getDeclaringClass())
> 61:                 && accessorGenerated == false
> 62:                 && unsafe.compareAndSetBoolean(this, accessorGeneratedaOffset, false, true)) {

`compareAndSetBoolean` gets us into the awkward territory of sub-word CASes. (Click through to `Unsafe.compareAndExchangeByte` to see what I am talking about). It is probably not relevant here, though. Still, might be as good to use `int` field for generated flag.

src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java line 72:

> 70:                 parent.setDelegate(acc);
> 71:             } catch (Throwable t) {
> 72:                 // in case Thowable happens in generateMethod

Typo: `Thowable`.

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

Changes requested by shade (Reviewer).

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

From naoto at openjdk.java.net  Tue Nov 10 19:52:14 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 Nov 2020 19:52:14 GMT
Subject: RFR: 8247781: Day periods support [v12]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

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

  Added a test case for user defined temporal field resolution with day period.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/ccefe70c..a960804f

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

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

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

From naoto at openjdk.java.net  Tue Nov 10 19:58:58 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 Nov 2020 19:58:58 GMT
Subject: RFR: 8247781: Day periods support [v12]
In-Reply-To: <X1JBy-5Svma-t50EpOmlCYMMrckOUylULK5YdcTWLMI=.d9ebf78e-a648-470e-9e53-2cc102160882@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <LzBaAtUIc3RzanmZDGnDcbgwEAc1j194SuSGamn_--o=.0a3c2199-ee99-4e4d-95c6-e9295b84ba2a@github.com>
 <DnMwydDzsyXWpVxNeFK2hfasKlwH8-JWH2S5INzdBBY=.4bc6f1f9-eff0-4aa5-bc39-ac6652686544@github.com>
 <Tu7yq15XUzC2-z2v40tNUGHkTkYW37q7RUiop9pB4xU=.d61a3059-6929-4b45-8a16-df33469ab56b@github.com>
 <_KS-70pqQG8VavYGtbXCrOlvwfwGl6Nm-lk8SjkEDQI=.1775f0e1-4847-401a-a576-dbb93e080c90@github.com>
 <BVGHbYN8Sp6W49GTct6d5edTJvgx9uVn688oy3VXe1U=.a1393d13-538c-4b3c-82db-e8abd30e297f@github.com>
 <_p9FOFl7DOCxiwGk3Ks2OHs-5wbIcPEcFQXBMs0tJfQ=.43913af9-8a74-49ad-9764-89595ecc63fd@github.com>
 <X1JBy-5Svma-t50EpOmlCYMMrckOUylULK5YdcTWLMI=.d9ebf78e-a648-470e-9e53-2cc102160882@github.com>
Message-ID: <dGOjTGi3zRqT0NFo3Xqugst4_CQrMuTnexFMAQY6A_A=.9865e7b4-2a14-4b24-85a2-09555f42ac15@github.com>

On Mon, 9 Nov 2020 01:37:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I've had a look tonight, but found two more problems!
>> 
>> The comments at the start of `resolveTimeLenient()` indicate that setting the midpoint in `resolveTimeFields()` is a bad idea - it needs to be done inside `resolveTimeLenient()`. (This ensures user-defined fields can resolve to ChronoFields IIRC). Thus, the day period resolving would have to be split between the two methods. How important is the midpoint logic? Could it just be dropped?
>> 
>> Secondly, we need to ensure that "24:00 midnight" (using HOUR_OF_DAY only) correctly parses to the end of day midnight, not the start of day or an exception. This is related to the problem above. 
>> 
>> I _think_ (but haven't confirmed everything yet) that the only thing that should be in `resolveTimeFields()` is the resolution of HOUR_OF_AMPM + dayPeriod to HOUR_OF_DAY (with `dayPeriod` then being set to `null`). Everything else should go in `resolveTimeLenient()` - the midpoint logic in the first if block (where time fields are defaulted), and the validation logic at the end of the method.
>
> Thanks for the insights. I believe I fixed both of the issues with the new commit.

Added a test case with the latest commit: https://github.com/openjdk/jdk/commit/a960804ff4d3f7df18e51fe59dcdcaf04542e10a

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

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

From almatvee at openjdk.java.net  Tue Nov 10 20:23:55 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 10 Nov 2020 20:23:55 GMT
Subject: RFR: 8233332: Need to create exploded tests covering all forms of
 modules
In-Reply-To: <x3sGxQki-zqnyuH2AbS-L55BB31wPNP0iqnytFD1ogo=.2bdd5824-435f-4194-8389-50182593d0f0@github.com>
References: <x3sGxQki-zqnyuH2AbS-L55BB31wPNP0iqnytFD1ogo=.2bdd5824-435f-4194-8389-50182593d0f0@github.com>
Message-ID: <ZV8YF-T6u3y5JOErsR4OemAid86Q2MX_WrB-Pqk-s7A=.2c570521-d1e5-4783-9ce8-b11ed02f5449@github.com>

On Fri, 6 Nov 2020 21:59:51 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8233332: Need to create exploded tests covering all forms of modules

Marked as reviewed by almatvee (Committer).

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

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

From coleenp at openjdk.java.net  Tue Nov 10 21:25:06 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 10 Nov 2020 21:25:06 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <fCjfFUcswrkqB-pHnb-nyRJNUpuKmNPzTZBwfXaZvnw=.6f65227d-6707-439c-92e7-66de4d910d64@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <cpNCcue6y1OO8obK4QmhiNrdw85BAdAXFLqVbh1RmYc=.ee32d53d-1296-4bd5-8bdd-6632e7ff6af6@github.com>
 <fCjfFUcswrkqB-pHnb-nyRJNUpuKmNPzTZBwfXaZvnw=.6f65227d-6707-439c-92e7-66de4d910d64@github.com>
Message-ID: <ey91_BZ_osjp9pbnn9rfBj1__Qoqs6H9mSWHDhp0hUg=.9622acd2-b1c2-4ab6-a597-66d8ef53b4d6@github.com>

On Mon, 9 Nov 2020 16:31:23 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 121:
>> 
>>> 119:                          upcall_info.upcall_method.name, upcall_info.upcall_method.sig,
>>> 120:                          &args, thread);
>>> 121: }
>> 
>> This code shouldn't be in the cpu directory.  This should be in SharedRuntime or in jni.cpp.  It should have a JNI_ENTRY and not transition directly.  I don't know what AttachCurrentThreadAsDaemon does.
>
> Roger that.
> 
> We need the thread state transition though in case we get a random native thread calling us.

yikes.  Does that work?

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

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

From hseigel at openjdk.java.net  Tue Nov 10 21:30:04 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Tue, 10 Nov 2020 21:30:04 GMT
Subject: RFR: 8255787: Tag container tests that use cGroups with cgroups
 keyword
Message-ID: <KZXHhMlBA_blkP7RL4Rwsd_zo3HEYH7wBVBIQIF7Sp0=.3a9b1171-b985-46d6-b3bd-2d2dcb9259e8@github.com>

Please review this small change to add a cgroups keyword to tests that use cgroups.  The fix was tested by running Mach5 container tests.

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

Commit messages:
 - 8255787: Tag container tests that use cGroups with cgroups keyword

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

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

From lancea at openjdk.java.net  Tue Nov 10 21:32:04 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Tue, 10 Nov 2020 21:32:04 GMT
Subject: RFR: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence
Message-ID: <vRlZhcESYttdSpeB0IuIOAd77U4iUbjE51cnhiatTnw=.1e8cb2ac-aa59-484e-976c-3d0715aec51b@github.com>

Hi, 

Please review the fix for JDK-8256018 which addresses the issue that  the update(ByteBuffer)  methods of Adler32, CRC32, and CRC32C should use Reference.reachabilityFence to ensure that direct byte buffer are kept kept alive when they are accessed directly.

The Mach5 jdk-tier1, jdk-tier2, jdk-tier3 as well as the  jck:api/java_util/zip,jck:api/java_util/jar continue to run clean.

Best
Lance

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

Commit messages:
 - Adler32/CRC32/CRC32C missing reachabilityFence

Changes: https://git.openjdk.java.net/jdk/pull/1149/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1149&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256018
  Stats: 23 lines in 3 files changed: 16 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1149.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1149/head:pull/1149

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

From coleenp at openjdk.java.net  Tue Nov 10 21:37:06 2020
From: coleenp at openjdk.java.net (Coleen Phillimore)
Date: Tue, 10 Nov 2020 21:37:06 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v18]
In-Reply-To: <AK-p2u_9FlJzupbJzCMvC55iWN_5j5lNwy8q1SXGObI=.615fee87-b80b-4bcf-8b6e-33c758eb4da4@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <AK-p2u_9FlJzupbJzCMvC55iWN_5j5lNwy8q1SXGObI=.615fee87-b80b-4bcf-8b6e-33c758eb4da4@github.com>
Message-ID: <Kbbgn0A0CBimPAKf1D99Y3zu3JZoNb8Jiupq1-HYZeE=.a3b963c0-c5c8-4c26-926c-ad14186a28ea@github.com>

On Tue, 10 Nov 2020 14:16:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision:
> 
>  - Merge pull request #7 from JornVernee/Additional_Review_Comments
>    
>    Additional review comments
>  - Revert System.java changes
>  - Set copyright year for added files to 2020
>  - Check result of AttachCurrentThread
>  - Sort includes alphabetically
>  - Relax ret_addr_offset() assert
>  - Extra space after if
>  - remove excessive asserts in ProgrammableInvoker::invoke_native
>  - Remove os::is_MP() check
>  - remove blank line in thread.hpp

The Hotspot prims and runtime changes look good to me.

src/hotspot/share/prims/universalUpcallHandler.cpp line 68:

> 66:     vm->functions->DetachCurrentThread(vm);
> 67:   }
> 68: }

Yes, this looks good. Thanks for moving this.

src/hotspot/share/prims/universalUpcallHandler.cpp line 85:

> 83:   upcall_method.sig = SymbolTable::new_symbol("(L" FOREIGN_ABI "ProgrammableUpcallHandler;J)V");
> 84: 
> 85:   assert(upcall_method.klass->lookup_method(upcall_method.name, upcall_method.sig) != nullptr,

I think you need a ResourceMark here.

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

Marked as reviewed by coleenp (Reviewer).

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

From naoto at openjdk.java.net  Tue Nov 10 22:34:59 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 10 Nov 2020 22:34:59 GMT
Subject: RFR: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence
In-Reply-To: <vRlZhcESYttdSpeB0IuIOAd77U4iUbjE51cnhiatTnw=.1e8cb2ac-aa59-484e-976c-3d0715aec51b@github.com>
References: <vRlZhcESYttdSpeB0IuIOAd77U4iUbjE51cnhiatTnw=.1e8cb2ac-aa59-484e-976c-3d0715aec51b@github.com>
Message-ID: <RJpIM9nn1KeP-FV18pb_l3ZiIFlKPqfLAFbHu2FJH30=.52268b7c-48ce-4968-b76b-a0ebe1f90868@github.com>

On Tue, 10 Nov 2020 21:26:59 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi, 
> 
> Please review the fix for JDK-8256018 which addresses the issue that  the update(ByteBuffer)  methods of Adler32, CRC32, and CRC32C should use Reference.reachabilityFence to ensure that direct byte buffer are kept kept alive when they are accessed directly.
> 
> The Mach5 jdk-tier1, jdk-tier2, jdk-tier3 as well as the  jck:api/java_util/zip,jck:api/java_util/jar continue to run clean.
> 
> Best
> Lance

Looks good, Lance.

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

Marked as reviewed by naoto (Reviewer).

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

From asemenyuk at openjdk.java.net  Tue Nov 10 22:39:56 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 10 Nov 2020 22:39:56 GMT
Subject: Integrated: 8233332: Need to create exploded tests covering all forms
 of modules
In-Reply-To: <x3sGxQki-zqnyuH2AbS-L55BB31wPNP0iqnytFD1ogo=.2bdd5824-435f-4194-8389-50182593d0f0@github.com>
References: <x3sGxQki-zqnyuH2AbS-L55BB31wPNP0iqnytFD1ogo=.2bdd5824-435f-4194-8389-50182593d0f0@github.com>
Message-ID: <QPwGMr5yEK7K9jo1WmzxfWNOnl8XtJgL8uejzG-e9FY=.55656b42-04b7-4a0c-a8d5-15992d6ba39a@github.com>

On Fri, 6 Nov 2020 21:59:51 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8233332: Need to create exploded tests covering all forms of modules

This pull request has now been integrated.

Changeset: d6f1463c
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d6f1463c
Stats:     65 lines in 3 files changed: 59 ins; 1 del; 5 mod

8233332: Need to create exploded tests covering all forms of modules

Reviewed-by: herrick, almatvee

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

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

From jvernee at openjdk.java.net  Tue Nov 10 23:28:57 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 10 Nov 2020 23:28:57 GMT
Subject: Integrated: 8254354: Add a withInvokeExactBehavior() VarHandle
 combinator
In-Reply-To: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
References: <gJ1pTeZZC7tbtwiRsrHcZ1ydfTQhr1MPndGrnGolf14=.dd935929-4f22-4e41-9e0d-99a592ac46b7@github.com>
Message-ID: <QWzGNscpB4QhIKeXDdff7tVINd9XkW0wURFgLv1dwNk=.7fd04bcc-9e20-4d81-b793-5fcbc40e3b7b@github.com>

On Fri, 23 Oct 2020 17:47:36 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Hi,
> 
> This patch adds an asExact() combinator to VarHandle, that will return a new VarHandle that performs exact type checks, similar to MethodHandle::invokeExact, to help developers catch inexact VarHandle usage, which can lead to performance degradation.
> 
> This is implemented using a boolean flag in VarForm. If the flag is set, the exact type of the invocation is checked against the exact type in the VarForm. If there is a mismatch, a WrongMethodTypeException is thrown.
> 
> Other than that, there is also an asGeneric() combinator added that does the inverse operation (thanks to R?mi for the suggestion). I've also added The `@Hidden` annotation to the VarHandleGuards methods, as well as a type-checking helper method called from the generic invocation lambda form, so that the stack trace we get points at the location where the VarHandle is being used.
> 
> Thanks,
> Jorn
> 
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8255375

This pull request has now been integrated.

Changeset: 0a41ca6b
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0a41ca6b
Stats:     1668 lines in 12 files changed: 1263 ins; 62 del; 343 mod

8254354: Add a withInvokeExactBehavior() VarHandle combinator

Reviewed-by: psandoz, chegar

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

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

From sspitsyn at openjdk.java.net  Wed Nov 11 00:30:54 2020
From: sspitsyn at openjdk.java.net (Serguei Spitsyn)
Date: Wed, 11 Nov 2020 00:30:54 GMT
Subject: RFR: 8255787: Tag container tests that use cGroups with cgroups
 keyword
In-Reply-To: <KZXHhMlBA_blkP7RL4Rwsd_zo3HEYH7wBVBIQIF7Sp0=.3a9b1171-b985-46d6-b3bd-2d2dcb9259e8@github.com>
References: <KZXHhMlBA_blkP7RL4Rwsd_zo3HEYH7wBVBIQIF7Sp0=.3a9b1171-b985-46d6-b3bd-2d2dcb9259e8@github.com>
Message-ID: <ohQTnzM9m1AQ8JhLsLBD4zhow69sBnV6d3R_lqY3GU4=.d216bd3b-784f-4cab-a080-3d3298fac48a@github.com>

On Tue, 10 Nov 2020 21:24:25 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small change to add a cgroups keyword to tests that use cgroups.  The fix was tested by running Mach5 container tests.

Hi Harold,

The fix looks good.

Thanks,
Serguei

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

Marked as reviewed by sspitsyn (Reviewer).

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

From jjg at openjdk.java.net  Wed Nov 11 02:25:04 2020
From: jjg at openjdk.java.net (Jonathan Gibbons)
Date: Wed, 11 Nov 2020 02:25:04 GMT
Subject: RFR: JDK-8250768: javac should be adapted to changes in JEP 12
 [v11]
In-Reply-To: <fDWoj48-Ewh1-5pZKBQFI_UYuXFGPgjnXwmJuRlvKfY=.bb7279d8-008c-4254-8145-654579ef639f@github.com>
References: <RRMAPzh6xcVcxOj2S_VW_r50YvZz-3Imaj46bDi8e9U=.9347534e-d482-468a-8668-132d5516bb76@github.com>
 <fDWoj48-Ewh1-5pZKBQFI_UYuXFGPgjnXwmJuRlvKfY=.bb7279d8-008c-4254-8145-654579ef639f@github.com>
Message-ID: <PvyAuDl9KUxhsTfT6gj82FHyDQsivb_OFBrsZ1Tsaqc=.eebe3873-97a9-4353-8df2-d49485193560@github.com>

On Fri, 6 Nov 2020 18:41:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is an update to javac and javadoc, to introduce support for Preview APIs, and generally improve javac and javadoc behavior to more closely adhere to JEP 12.
>> 
>> The notable changes are:
>> 
>>  * adding support for Preview APIs (javac until now supported primarily only preview language features, and APIs associated with preview language features). This includes:
>>      * the @PreviewFeature annotation has boolean attribute "reflective", which should be true for reflective Preview APIs, false otherwise. This replaces the existing "essentialAPI" attribute with roughly inverted meaning.
>>      * the preview warnings for preview APIs are auto-suppressed as described in the JEP 12. E.g. the module that declares the preview API is free to use it without warnings
>>  * improving error/warning messages. Please see [1] for a list of cases/examples.
>>  * class files are only marked as preview if they are using a preview feature. [1] also shows if a class file is marked as preview or not.
>>  * the PreviewFeature annotation has been moved to jdk.internal.javac package (originally was in the jdk.internal package).
>>  * Preview API in JDK's javadoc no longer needs to specify @preview tag in the source files. javadoc will auto-generate a note for @PreviewFeature elements, see e.g. [2] and [3] (non-reflective and reflective API, respectively). A summary of preview elements is also provided [4]. Existing uses of @preview have been updated/removed.
>>  * non-JDK javadoc is also enhanced to auto-generate preview notes for uses of Preview elements, and for declaring elements using preview language features [5].
>>  
>>  Please also see the CSR [6] for more information.
>>  
>>  [1] http://cr.openjdk.java.net/~jlahoda/8250768/JEP12-errors-warnings-v6.html
>>  [2] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.base/java/lang/Record.html
>>  [3] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/java.compiler/javax/lang/model/element/RecordComponentElement.html
>>  [4] http://cr.openjdk.java.net/~jlahoda/8250768/jdk.javadoc.00/api/preview-list.html
>>  [5] http://cr.openjdk.java.net/~jlahoda/8250768/test.javadoc.00/
>>  [6] https://bugs.openjdk.java.net/browse/JDK-8250769
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing navigator for the PREVIEW page.

I have a mild queasiness about this new overloaded use of the word "Summary", since "summary tables" are normally the summary of the contents of a declaration, like fields and methods of a class.

That being said, the usage is primarily internal, and I have no overwhelmingly wonderful alternative, and (overloading aside) the term is accurate. 

So, OK for now. We can change it later if  we want to.

src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/util/Utils.java line 2949:

> 2947: 
> 2948:     /**
> 2949:      * Return the set of preview language features used to declare the given element.

"Returns"

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

Marked as reviewed by jjg (Reviewer).

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

From hshi at openjdk.java.net  Wed Nov 11 03:41:13 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Wed, 11 Nov 2020 03:41:13 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v3]
In-Reply-To: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
Message-ID: <Mkpb4wtsWhye5CV1v2IyqYgzuQ_KcYE_5VeZxOpSZoA=.0a8fad8f-b262-46f8-a430-03a2f63aaa13@github.com>

> ?AccessorImpl object
> 
> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
> 
> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
> 
> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.

Hui Shi 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:

  8255883: Avoid multiple GeneratedAccessor for same NativeMethod/ConstructorAccessorImpl object

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1070/files
  - new: https://git.openjdk.java.net/jdk/pull/1070/files/8f65047e..7a1b274a

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

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

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

From almatvee at openjdk.java.net  Wed Nov 11 04:33:08 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Wed, 11 Nov 2020 04:33:08 GMT
Subject: RFR: 8255947: [macos] Signed macOS jpackage app doesn't filter
 spurious '-psn' argument
Message-ID: <gA_HFoOHfdrbfrRXQG6Jvn7M_tfns2G7WvzUIS_afg0=.ea64b8e8-1afd-4884-99b4-cb84333dbbf3@github.com>

This is regression from JDK-8242302 and for some reason removing -psn argument code was removed during refactoring. Fixed be adding removing -psn argument back. Also, test was added to test this functionality.

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

Commit messages:
 - 8255947: [macos] Signed macOS jpackage app doesn't filter spurious '-psn' argument

Changes: https://git.openjdk.java.net/jdk/pull/1154/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1154&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255947
  Stats: 113 lines in 5 files changed: 100 ins; 10 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1154.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1154/head:pull/1154

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

From hshi at openjdk.java.net  Wed Nov 11 05:13:12 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Wed, 11 Nov 2020 05:13:12 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v4]
In-Reply-To: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
Message-ID: <oxRHcra7Yus3Fb4Yv8cYRR4-o3IqisgvXpiN-le16TE=.0e06fdef-99b5-4ab9-b6ff-6673ca7b8e69@github.com>

> ?AccessorImpl object
> 
> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
> 
> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
> 
> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.

Hui Shi 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:

  8255883: Avoid multiple GeneratedAccessor for same NativeMethod/ConstructorAccessorImpl object

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1070/files
  - new: https://git.openjdk.java.net/jdk/pull/1070/files/7a1b274a..abf34872

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

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

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

From hshi at openjdk.java.net  Wed Nov 11 05:38:08 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Wed, 11 Nov 2020 05:38:08 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v5]
In-Reply-To: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
Message-ID: <eLNP96JheIN15HOCR6-Bh5qgd-hTDKdi_KQClLBBPuY=.fad46a90-a5a4-4292-9082-78d3ac91e00a@github.com>

> ?AccessorImpl object
> 
> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
> 
> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
> 
> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.

Hui Shi 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:

  8255883: Avoid multiple GeneratedAccessor for same NativeMethod/ConstructorAccessorImpl object

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1070/files
  - new: https://git.openjdk.java.net/jdk/pull/1070/files/abf34872..ec1531b2

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

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

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

From hshi at openjdk.java.net  Wed Nov 11 06:10:58 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Wed, 11 Nov 2020 06:10:58 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v2]
In-Reply-To: <pnJkCrvIkTmD7TDNr_gtN9a0ugbHOtd-_DxOoHpkEVw=.b1e11a05-f0d8-4cb2-9d3c-eae6f0d69234@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <pLjfXREv5ofhOmaYMK_9UZ7uqCgGOlgM9SRdaSfXD2w=.6e6503d8-e782-44ce-9fc1-32e716823b78@github.com>
 <pnJkCrvIkTmD7TDNr_gtN9a0ugbHOtd-_DxOoHpkEVw=.b1e11a05-f0d8-4cb2-9d3c-eae6f0d69234@github.com>
Message-ID: <xlS_4gyJIqzH334jG9N1_Bul0vmApJeKDmGCR-QRdx0=.b7162024-c0b7-4927-90f5-778c33a9ccd1@github.com>

On Tue, 10 Nov 2020 18:28:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hui Shi 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:
>> 
>>   8255883: Avoid multiple GeneratedAccessor for same NativeMethod/ConstructorAccessorImpl object
>
> src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java line 37:
> 
>> 35: 
>> 36: class NativeConstructorAccessorImpl extends ConstructorAccessorImpl {
>> 37:     private static final Unsafe unsafe = Unsafe.getUnsafe();
> 
> `static final` field identifiers should be capitalized. Suggestion: `private static final Unsafe U = Unsafe.getUnsafe()`.

fixed

> src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java line 38:
> 
>> 36: class NativeConstructorAccessorImpl extends ConstructorAccessorImpl {
>> 37:     private static final Unsafe unsafe = Unsafe.getUnsafe();
>> 38:     private static final long accessorGeneratedaOffset
> 
> Typo "Generated*a*Offset". But also this is `static final`, so it should be e.g. `GENERATED_OFFSET`. The field can be just `generated` to match the name of this offset.

field name udpated

> src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java line 61:
> 
>> 59:                 && !c.getDeclaringClass().isHidden()
>> 60:                 && !ReflectUtil.isVMAnonymousClass(c.getDeclaringClass())
>> 61:                 && accessorGenerated == false
> 
> Should be `!accessorGenerated`.

change to "generated == 0", as generated is int type now

> src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java line 62:
> 
>> 60:                 && !ReflectUtil.isVMAnonymousClass(c.getDeclaringClass())
>> 61:                 && accessorGenerated == false
>> 62:                 && unsafe.compareAndSetBoolean(this, accessorGeneratedaOffset, false, true)) {
> 
> `compareAndSetBoolean` gets us into the awkward territory of sub-word CASes. (Click through to `Unsafe.compareAndExchangeByte` to see what I am talking about). It is probably not relevant here, though. Still, might be as good to use `int` field for generated flag.

use int type now

> src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java line 72:
> 
>> 70:                 parent.setDelegate(acc);
>> 71:             } catch (Throwable t) {
>> 72:                 // in case Thowable happens in generateMethod
> 
> Typo: `Thowable`.

updated

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

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

From hshi at openjdk.java.net  Wed Nov 11 06:31:55 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Wed, 11 Nov 2020 06:31:55 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v2]
In-Reply-To: <pnJkCrvIkTmD7TDNr_gtN9a0ugbHOtd-_DxOoHpkEVw=.b1e11a05-f0d8-4cb2-9d3c-eae6f0d69234@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <pLjfXREv5ofhOmaYMK_9UZ7uqCgGOlgM9SRdaSfXD2w=.6e6503d8-e782-44ce-9fc1-32e716823b78@github.com>
 <pnJkCrvIkTmD7TDNr_gtN9a0ugbHOtd-_DxOoHpkEVw=.b1e11a05-f0d8-4cb2-9d3c-eae6f0d69234@github.com>
Message-ID: <rgqWW-4nhTJ2BLrawa93rIJmUZIFlkk6KRsl2uNumpU=.39b05762-0c86-4c0f-90e3-a35e8c3e252b@github.com>

On Tue, 10 Nov 2020 18:36:22 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hui Shi 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:
>> 
>>   8255883: Avoid multiple GeneratedAccessor for same NativeMethod/ConstructorAccessorImpl object
>
> Minor nits here.

@shipilev all comments are updated, please help review again!

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

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

From dholmes at openjdk.java.net  Wed Nov 11 07:24:07 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 11 Nov 2020 07:24:07 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v18]
In-Reply-To: <AK-p2u_9FlJzupbJzCMvC55iWN_5j5lNwy8q1SXGObI=.615fee87-b80b-4bcf-8b6e-33c758eb4da4@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <AK-p2u_9FlJzupbJzCMvC55iWN_5j5lNwy8q1SXGObI=.615fee87-b80b-4bcf-8b6e-33c758eb4da4@github.com>
Message-ID: <yrsF1ii1HxVNPHKO1ffHzWq2Ap7WxcVh0y21obwYndA=.0f609c85-da94-4de6-9cbc-e21811594bbf@github.com>

On Tue, 10 Nov 2020 14:16:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision:
> 
>  - Merge pull request #7 from JornVernee/Additional_Review_Comments
>    
>    Additional review comments
>  - Revert System.java changes
>  - Set copyright year for added files to 2020
>  - Check result of AttachCurrentThread
>  - Sort includes alphabetically
>  - Relax ret_addr_offset() assert
>  - Extra space after if
>  - remove excessive asserts in ProgrammableInvoker::invoke_native
>  - Remove os::is_MP() check
>  - remove blank line in thread.hpp

Updates seem fine to me. Thanks.

Adding approval for hotspot parts.

src/hotspot/share/prims/universalUpcallHandler.cpp line 55:

> 53:     JavaVM_ *vm = (JavaVM *)(&main_vm);
> 54:     jint result = vm->functions->AttachCurrentThread(vm, (void**) &p_env, nullptr);
> 55:     guarantee(result == JNI_OK, "Could not attach thread for upcall. JNI error code: %d", result);

I'm assuming you don't have a mechanism for conveying an error back to the original entry point used by the native thread? Attaching an existing thread should only fail if we run out of C-Heap, so we're on the brink of aborting anyway, but still the guarantee here is not ideal.

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

Marked as reviewed by dholmes (Reviewer).

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

From alanb at openjdk.java.net  Wed Nov 11 07:32:56 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 Nov 2020 07:32:56 GMT
Subject: RFR: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence
In-Reply-To: <vRlZhcESYttdSpeB0IuIOAd77U4iUbjE51cnhiatTnw=.1e8cb2ac-aa59-484e-976c-3d0715aec51b@github.com>
References: <vRlZhcESYttdSpeB0IuIOAd77U4iUbjE51cnhiatTnw=.1e8cb2ac-aa59-484e-976c-3d0715aec51b@github.com>
Message-ID: <5NH_G4-u_8BAWR_KncUfsW5kqXkRcy5fyZOphrC6YdU=.29dcc286-45b7-40d6-94e2-9e3202105b4f@github.com>

On Tue, 10 Nov 2020 21:26:59 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi, 
> 
> Please review the fix for JDK-8256018 which addresses the issue that  the update(ByteBuffer)  methods of Adler32, CRC32, and CRC32C should use Reference.reachabilityFence to ensure that direct byte buffer are kept kept alive when they are accessed directly.
> 
> The Mach5 jdk-tier1, jdk-tier2, jdk-tier3 as well as the  jck:api/java_util/zip,jck:api/java_util/jar continue to run clean.
> 
> Best
> Lance

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/util/zip/Adler32.java line 103:

> 101:             try {
> 102:                 adler = updateByteBuffer(adler, ((DirectBuffer)buffer).address(), pos, rem);
> 103: 

spurious blank line here but otherwise looks good.

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

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

From jiefu at openjdk.java.net  Wed Nov 11 09:30:57 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Wed, 11 Nov 2020 09:30:57 GMT
Subject: RFR: 8256037: [TESTBUG]
 com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails due to the hard coded
 threshold is small
In-Reply-To: <QuPW3Afb2RpucHhJT9NQDsmHo977-Y378EuBgcg_-B0=.07b9b5f2-8faf-434b-9e98-72a80734976f@github.com>
References: <QuPW3Afb2RpucHhJT9NQDsmHo977-Y378EuBgcg_-B0=.07b9b5f2-8faf-434b-9e98-72a80734976f@github.com>
Message-ID: <0EfKq3POH_J9gLOClCXZPsOmIrpDJiNd_C-9DOgYhiY=.2176de96-cfaf-4c28-a092-8096968bc881@github.com>

On Mon, 9 Nov 2020 09:19:44 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> May I get reviews for this change?
> 
> com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails occasionally on some of our testing platforms.
> The reason is that the hard coded Threshold (1000 ms) [1] is a little smaller than that (e.g., 1026 ms) on our platforms.
> 
> The fix just increases the threshold from 1000 ms to 3000 ms.
> Any comments?
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java#L49

The failure happens with fastdebug VMs, especially on our newly added non-x86 platforms.

Could someone help to review it?
Thanks.

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

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

From shade at openjdk.java.net  Wed Nov 11 09:30:59 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 11 Nov 2020 09:30:59 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v5]
In-Reply-To: <eLNP96JheIN15HOCR6-Bh5qgd-hTDKdi_KQClLBBPuY=.fad46a90-a5a4-4292-9082-78d3ac91e00a@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <eLNP96JheIN15HOCR6-Bh5qgd-hTDKdi_KQClLBBPuY=.fad46a90-a5a4-4292-9082-78d3ac91e00a@github.com>
Message-ID: <zNWxOUS1MCggXuCZ5BWtLH2CMszJax9-UyGR9szH-4g=.fe7b10b8-6727-4dc9-ba60-1c66d3d14dbe@github.com>

On Wed, 11 Nov 2020 05:38:08 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> ?AccessorImpl object
>> 
>> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
>> 
>> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
>> 
>> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.
>
> Hui Shi 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.

Looks okay (as far as low-level code goes) to me. Others need to ack too.

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

Marked as reviewed by shade (Reviewer).

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

From jvernee at openjdk.java.net  Wed Nov 11 11:19:04 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 Nov 2020 11:19:04 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v18]
In-Reply-To: <yrsF1ii1HxVNPHKO1ffHzWq2Ap7WxcVh0y21obwYndA=.0f609c85-da94-4de6-9cbc-e21811594bbf@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <AK-p2u_9FlJzupbJzCMvC55iWN_5j5lNwy8q1SXGObI=.615fee87-b80b-4bcf-8b6e-33c758eb4da4@github.com>
 <yrsF1ii1HxVNPHKO1ffHzWq2Ap7WxcVh0y21obwYndA=.0f609c85-da94-4de6-9cbc-e21811594bbf@github.com>
Message-ID: <PlQHyVh02PHNlNQJirTyQdUSLhHLEzpjg_kSoLtaWl4=.57fa2628-6e4c-45be-8dc9-8e58493d0553@github.com>

On Wed, 11 Nov 2020 07:18:33 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision:
>> 
>>  - Merge pull request #7 from JornVernee/Additional_Review_Comments
>>    
>>    Additional review comments
>>  - Revert System.java changes
>>  - Set copyright year for added files to 2020
>>  - Check result of AttachCurrentThread
>>  - Sort includes alphabetically
>>  - Relax ret_addr_offset() assert
>>  - Extra space after if
>>  - remove excessive asserts in ProgrammableInvoker::invoke_native
>>  - Remove os::is_MP() check
>>  - remove blank line in thread.hpp
>
> src/hotspot/share/prims/universalUpcallHandler.cpp line 55:
> 
>> 53:     JavaVM_ *vm = (JavaVM *)(&main_vm);
>> 54:     jint result = vm->functions->AttachCurrentThread(vm, (void**) &p_env, nullptr);
>> 55:     guarantee(result == JNI_OK, "Could not attach thread for upcall. JNI error code: %d", result);
> 
> I'm assuming you don't have a mechanism for conveying an error back to the original entry point used by the native thread? Attaching an existing thread should only fail if we run out of C-Heap, so we're on the brink of aborting anyway, but still the guarantee here is not ideal.

Yeah, we have no idea where/how to report such and error. The native code might just call a function through a function pointer like `void(*)(void)` i.e. no place to return an error code. Also, since it's a previously non-attached thread, there is no JavaFrameAnchor that gives us a last Java frame we could jump back to and throw an exception.

Is there's a more explicit way to exit with an error, other than a `guarantee` that you would prefer here?

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

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

From david.holmes at oracle.com  Wed Nov 11 11:36:43 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 11 Nov 2020 21:36:43 +1000
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v18]
In-Reply-To: <PlQHyVh02PHNlNQJirTyQdUSLhHLEzpjg_kSoLtaWl4=.57fa2628-6e4c-45be-8dc9-8e58493d0553@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <AK-p2u_9FlJzupbJzCMvC55iWN_5j5lNwy8q1SXGObI=.615fee87-b80b-4bcf-8b6e-33c758eb4da4@github.com>
 <yrsF1ii1HxVNPHKO1ffHzWq2Ap7WxcVh0y21obwYndA=.0f609c85-da94-4de6-9cbc-e21811594bbf@github.com>
 <PlQHyVh02PHNlNQJirTyQdUSLhHLEzpjg_kSoLtaWl4=.57fa2628-6e4c-45be-8dc9-8e58493d0553@github.com>
Message-ID: <718dab9a-2939-68a6-9c79-2414a7296ffe@oracle.com>

On 11/11/2020 9:19 pm, Jorn Vernee wrote:
> On Wed, 11 Nov 2020 07:18:33 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision:
>>>
>>>   - Merge pull request #7 from JornVernee/Additional_Review_Comments
>>>     
>>>     Additional review comments
>>>   - Revert System.java changes
>>>   - Set copyright year for added files to 2020
>>>   - Check result of AttachCurrentThread
>>>   - Sort includes alphabetically
>>>   - Relax ret_addr_offset() assert
>>>   - Extra space after if
>>>   - remove excessive asserts in ProgrammableInvoker::invoke_native
>>>   - Remove os::is_MP() check
>>>   - remove blank line in thread.hpp
>>
>> src/hotspot/share/prims/universalUpcallHandler.cpp line 55:
>>
>>> 53:     JavaVM_ *vm = (JavaVM *)(&main_vm);
>>> 54:     jint result = vm->functions->AttachCurrentThread(vm, (void**) &p_env, nullptr);
>>> 55:     guarantee(result == JNI_OK, "Could not attach thread for upcall. JNI error code: %d", result);
>>
>> I'm assuming you don't have a mechanism for conveying an error back to the original entry point used by the native thread? Attaching an existing thread should only fail if we run out of C-Heap, so we're on the brink of aborting anyway, but still the guarantee here is not ideal.
> 
> Yeah, we have no idea where/how to report such and error. The native code might just call a function through a function pointer like `void(*)(void)` i.e. no place to return an error code. Also, since it's a previously non-attached thread, there is no JavaFrameAnchor that gives us a last Java frame we could jump back to and throw an exception.

Yeah not a solvable problem when you can transparently attach to the VM.

> Is there's a more explicit way to exit with an error, other than a `guarantee` that you would prefer here?

Perhaps vm_exit_out_if_memory under the assumption that is the only 
reason attach could fail. But really I don't think it makes much 
practical difference.

Thanks,
David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/634
> 

From mcimadamore at openjdk.java.net  Wed Nov 11 11:40:12 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 11 Nov 2020 11:40:12 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v27]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <pZper4cZnHoH4u8bquMP8UVKNLYthj1uzDrB5Pd7PVg=.9b2ff831-e59d-49c8-93ba-6cdaf5ad3e94@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits:

 - Merge branch 'master' into 8254162
 - Add more output in TestHandhsake.java
 - Further improve output of TestHandshake
 - Improve debugging output of TestHandhsake
 - Remove endianness-aware byte getter/setter in MemoryAccess
   Remove index-based version of byte getter/setter in MemoryAccess
 - Fix post-merge issues caused by 8219014
 - Merge branch 'master' into 8254162
 - Addess remaining feedback from @AlanBateman and @mrserb
 - Address comments from @AlanBateman
 - Merge branch 'master' into 8254162
 - ... and 24 more: https://git.openjdk.java.net/jdk/compare/432c387e...8444c633

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

Changes: https://git.openjdk.java.net/jdk/pull/548/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=26
  Stats: 7600 lines in 82 files changed: 4791 ins; 1590 del; 1219 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

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

From mcimadamore at openjdk.java.net  Wed Nov 11 11:50:14 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 11 Nov 2020 11:50:14 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v28]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <StOJze6rBlThtdnlhnYt2W4FAWjKEaTUuCu84C1TrDw=.4de05d3d-819e-4fe1-847b-6f57e340b2d6@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

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

  Invert condition in memory access var handle `withInvokeBehavior'

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/548/files
  - new: https://git.openjdk.java.net/jdk/pull/548/files/8444c633..eae57b4d

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

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

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

From lancea at openjdk.java.net  Wed Nov 11 11:58:08 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 11 Nov 2020 11:58:08 GMT
Subject: RFR: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence [v2]
In-Reply-To: <vRlZhcESYttdSpeB0IuIOAd77U4iUbjE51cnhiatTnw=.1e8cb2ac-aa59-484e-976c-3d0715aec51b@github.com>
References: <vRlZhcESYttdSpeB0IuIOAd77U4iUbjE51cnhiatTnw=.1e8cb2ac-aa59-484e-976c-3d0715aec51b@github.com>
Message-ID: <1D4M66CbBg1O5uHteS_kY0pKEos7Olhwlj_1RLBvoCs=.1cf2a416-ba80-421c-95a8-edca93cc55a5@github.com>

> Hi, 
> 
> Please review the fix for JDK-8256018 which addresses the issue that  the update(ByteBuffer)  methods of Adler32, CRC32, and CRC32C should use Reference.reachabilityFence to ensure that direct byte buffer are kept kept alive when they are accessed directly.
> 
> The Mach5 jdk-tier1, jdk-tier2, jdk-tier3 as well as the  jck:api/java_util/zip,jck:api/java_util/jar continue to run clean.
> 
> Best
> Lance

Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:

  Remove extra blank line

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1149/files
  - new: https://git.openjdk.java.net/jdk/pull/1149/files/267f2375..251f8a09

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

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

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

From dnsimon at openjdk.java.net  Wed Nov 11 13:28:03 2020
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Wed, 11 Nov 2020 13:28:03 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <xkIvCl3CZLV3QXNpVQKVUJeUcNdMZ1DvMdji0iTS0L0=.4ea8f950-13f6-43bb-b7c8-c7a1cf0873b5@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <lIajZsJ7LXE6I7upbj-IV39aHVHILgTG52OYWJrndHI=.b4565d6b-d6c6-455f-8aa0-ece5c443a011@github.com>
 <xkIvCl3CZLV3QXNpVQKVUJeUcNdMZ1DvMdji0iTS0L0=.4ea8f950-13f6-43bb-b7c8-c7a1cf0873b5@github.com>
Message-ID: <b6YF-JnTMxoWVfkVKNZXyxreUap-Ljq1O3sj6UjsjlM=.a2be4ffe-cf28-49ed-897f-9a5fd3fd90e7@github.com>

On Mon, 9 Nov 2020 11:50:54 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/universalUpcallHandler_aarch64.cpp line 99:
>> 
>>> 97:   if (thread == NULL) {
>>> 98:     JavaVM_ *vm = (JavaVM *)(&main_vm);
>>> 99:     vm -> functions -> AttachCurrentThreadAsDaemon(vm, &p_env, NULL);
>> 
>> Style nit: don't put spaces around `->` operator.
>> 
>> What is the context for this being called? It looks highly suspicious to just attach the current thread to the VM this way.
>
> The context is a thread that is spawned by native code doing an upcall. We need to attach the thread to the VM first in that case. Normally this would be handled by the calling code, but in our case the calling code doesn't know it's calling into Java.

Where's the logic for the native thread to detach? We have a similar problem in libgraal. We have a [utility class](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java#L27-L32) for libgraal created threads (as opposed to VM created threads that call into libgraal) that call into the VM. The utility class takes care of [attaching](https://github.com/oracle/graal/blob/a913944a06425c25ccd6e4a90379938fcf7ea2cf/substratevm/src/com.oracle.svm.graal.hotspot.libgraal/src/com/oracle/svm/graal/hotspot/libgraal/LibGraalFeature.java#L749) and [detaching](https://github.com/oracle/graal/blob/a913944a06425c25ccd6e4a90379938fcf7ea2cf/substratevm/src/com.oracle.svm.graal.hotspot.libgraal/src/com/oracle/svm/graal/hotspot/libgraal/LibGraalFeature.java#L757) to/from the VM.

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

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

From jvernee at openjdk.java.net  Wed Nov 11 13:34:02 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 Nov 2020 13:34:02 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <b6YF-JnTMxoWVfkVKNZXyxreUap-Ljq1O3sj6UjsjlM=.a2be4ffe-cf28-49ed-897f-9a5fd3fd90e7@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <lIajZsJ7LXE6I7upbj-IV39aHVHILgTG52OYWJrndHI=.b4565d6b-d6c6-455f-8aa0-ece5c443a011@github.com>
 <xkIvCl3CZLV3QXNpVQKVUJeUcNdMZ1DvMdji0iTS0L0=.4ea8f950-13f6-43bb-b7c8-c7a1cf0873b5@github.com>
 <b6YF-JnTMxoWVfkVKNZXyxreUap-Ljq1O3sj6UjsjlM=.a2be4ffe-cf28-49ed-897f-9a5fd3fd90e7@github.com>
Message-ID: <q8K2t7459QSU_TwCcooqu5494FWM950RzcT1SDJgk3g=.7b687458-a85e-4e8e-8e91-fa3358866feb@github.com>

On Wed, 11 Nov 2020 13:25:32 GMT, Doug Simon <dnsimon at openjdk.org> wrote:

>> The context is a thread that is spawned by native code doing an upcall. We need to attach the thread to the VM first in that case. Normally this would be handled by the calling code, but in our case the calling code doesn't know it's calling into Java.
>
> Where's the logic for the native thread to detach? We have a similar problem in libgraal. We have a [utility class](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java#L27-L32) for libgraal created threads (as opposed to VM created threads that call into libgraal) that call into the VM. The utility class takes care of [attaching](https://github.com/oracle/graal/blob/a913944a06425c25ccd6e4a90379938fcf7ea2cf/substratevm/src/com.oracle.svm.graal.hotspot.libgraal/src/com/oracle/svm/graal/hotspot/libgraal/LibGraalFeature.java#L749) and [detaching](https://github.com/oracle/graal/blob/a913944a06425c25ccd6e4a90379938fcf7ea2cf/substratevm/src/com.oracle.svm.graal.hotspot.libgraal/src/com/oracle/svm/graal/hotspot/libgraal/LibGraalFeature.java#L757) to/from the VM.

I added a call to DetachCurrentThread here: https://github.com/openjdk/jdk/pull/634/commits/719224ca9dc70fce6d28885acfb362fee715ebbd#diff-c084afc373a6ce95010a480ddc5ab79d3cb759b80e46102c212c2cbc948e2303R65

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

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

From dnsimon at openjdk.java.net  Wed Nov 11 14:00:14 2020
From: dnsimon at openjdk.java.net (Doug Simon)
Date: Wed, 11 Nov 2020 14:00:14 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v15]
In-Reply-To: <q8K2t7459QSU_TwCcooqu5494FWM950RzcT1SDJgk3g=.7b687458-a85e-4e8e-8e91-fa3358866feb@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <Ftqd411w84FVXNHP3vWBqx1v5YGB9eXmmMe6zvXAcc8=.6ddac525-a72b-4638-bede-3b4558e6a67b@github.com>
 <lIajZsJ7LXE6I7upbj-IV39aHVHILgTG52OYWJrndHI=.b4565d6b-d6c6-455f-8aa0-ece5c443a011@github.com>
 <xkIvCl3CZLV3QXNpVQKVUJeUcNdMZ1DvMdji0iTS0L0=.4ea8f950-13f6-43bb-b7c8-c7a1cf0873b5@github.com>
 <b6YF-JnTMxoWVfkVKNZXyxreUap-Ljq1O3sj6UjsjlM=.a2be4ffe-cf28-49ed-897f-9a5fd3fd90e7@github.com>
 <q8K2t7459QSU_TwCcooqu5494FWM950RzcT1SDJgk3g=.7b687458-a85e-4e8e-8e91-fa3358866feb@github.com>
Message-ID: <qtm1r1TfN28hF0O-qapZR2LcRuyu1CPPOtkODQWPkDU=.eb6b3baf-69f8-4286-b9d2-d8688e1c3ae1@github.com>

On Wed, 11 Nov 2020 13:31:11 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Where's the logic for the native thread to detach? We have a similar problem in libgraal. We have a [utility class](https://github.com/oracle/graal/blob/e4b9ab931940e1946f96f2015b937ba100384573/compiler/src/org.graalvm.compiler.core/src/org/graalvm/compiler/core/GraalServiceThread.java#L27-L32) for libgraal created threads (as opposed to VM created threads that call into libgraal) that call into the VM. The utility class takes care of [attaching](https://github.com/oracle/graal/blob/a913944a06425c25ccd6e4a90379938fcf7ea2cf/substratevm/src/com.oracle.svm.graal.hotspot.libgraal/src/com/oracle/svm/graal/hotspot/libgraal/LibGraalFeature.java#L749) and [detaching](https://github.com/oracle/graal/blob/a913944a06425c25ccd6e4a90379938fcf7ea2cf/substratevm/src/com.oracle.svm.graal.hotspot.libgraal/src/com/oracle/svm/graal/hotspot/libgraal/LibGraalFeature.java#L757) to/from the VM.
>
> I added a call to DetachCurrentThread here: https://github.com/openjdk/jdk/pull/634/commits/719224ca9dc70fce6d28885acfb362fee715ebbd#diff-c084afc373a6ce95010a480ddc5ab79d3cb759b80e46102c212c2cbc948e2303R65

Ok. That makes for high overhead for each upcall on a non-attached native thread. I assume that's an edge case not worth optimizing?

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

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

From vlivanov at openjdk.java.net  Wed Nov 11 14:21:14 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 11 Nov 2020 14:21:14 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v18]
In-Reply-To: <AK-p2u_9FlJzupbJzCMvC55iWN_5j5lNwy8q1SXGObI=.615fee87-b80b-4bcf-8b6e-33c758eb4da4@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <AK-p2u_9FlJzupbJzCMvC55iWN_5j5lNwy8q1SXGObI=.615fee87-b80b-4bcf-8b6e-33c758eb4da4@github.com>
Message-ID: <JJ6qdIZFLnnE1yqOVCPu5xEDWEKNiaVPQXgh4DH8Fhk=.7daf2599-efa9-4a47-aa7d-e52c58e2b6cf@github.com>

On Tue, 10 Nov 2020 14:16:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision:
> 
>  - Merge pull request #7 from JornVernee/Additional_Review_Comments
>    
>    Additional review comments
>  - Revert System.java changes
>  - Set copyright year for added files to 2020
>  - Check result of AttachCurrentThread
>  - Sort includes alphabetically
>  - Relax ret_addr_offset() assert
>  - Extra space after if
>  - remove excessive asserts in ProgrammableInvoker::invoke_native
>  - Remove os::is_MP() check
>  - remove blank line in thread.hpp

I made a pass over hotspot code. Overall, it looks good. Some comments follow.

src/hotspot/cpu/aarch64/vmreg_aarch64.cpp line 57:

> 55: #define INTEGER_TYPE 0
> 56: #define VECTOR_TYPE 1
> 57: #define X87_TYPE 2

Unused.

src/hotspot/cpu/aarch64/foreign_globals_aarch64.hpp line 31:

> 29: #include "utilities/growableArray.hpp"
> 30: 
> 31: #define __ _masm->

Should be declared in cpp file instead.

src/hotspot/cpu/x86/foreign_globals_x86.hpp line 30:

> 28: #include "utilities/growableArray.hpp"
> 29: 
> 30: #define __ _masm->

Same here (move to cpp file).

src/hotspot/share/opto/lcm.cpp line 867:

> 865:     case Op_CallNative:
> 866:       // FIXME compute actual save policy based on nep->abi
> 867:       save_policy = _matcher._c_reg_save_policy;

Please, elaborate here why it's OK for now to use ` _c_reg_save_policy`. And then turn `FIXME` into `TODO`. 
If possible, would be nice to introduce some asserts to back the claim.

src/hotspot/share/opto/machnode.cpp line 831:

> 829:   st->print("%s ",_name);
> 830:   st->print("_arg_regs: ");
> 831:   _arg_regs.print_on(st);

It doesn't print any useful info: `_arg_regs: AllocatedObj(0x000000011cf5cbe8)`. Please, improve it.

src/hotspot/share/opto/output.cpp line 3394:

> 3392:     }
> 3393: 
> 3394:     address* native_stubs = NULL;

IMO it's worth considering inlining `native_stubs` array into `nmethod` itself. That's the way how per-nmethod information is handled now (e.g., dependencies, debug info, exception handler table, implicit exception table).

src/hotspot/share/opto/callnode.cpp line 1184:

> 1182: void CallNativeNode::calling_convention( BasicType* sig_bt, VMRegPair *parm_regs, uint argcnt ) const {
> 1183:   assert((tf()->domain()->cnt() - TypeFunc::Parms) == argcnt, "arg counts must match!");
> 1184: #ifndef PRODUCT

Should be `#ifdef ASSERT` instead.

src/hotspot/share/opto/callnode.cpp line 1143:

> 1141:     case TypeFunc::Parms:
> 1142:     default: {
> 1143:       if(tf()->range()->field_at(proj->_con) == Type::HALF) {

That's `TypeFunc::Parms+1` case in `CallNode::match`. Why did you decide to move it to `default` case? 

Overall, it looks very similar to `CallNode::match`. Why not just customize `OptoRegPair regs` computation for `CallNative` there?

src/hotspot/share/opto/graphKit.cpp line 2665:

> 2663:     for (uint vm_ret_pos = 0; vm_ret_pos < n_returns; vm_ret_pos++) {
> 2664:       if (new_call_type->range()->field_at(TypeFunc::Parms + vm_ret_pos)  == Type::HALF) {
> 2665:         // FIXME is this needed?

Why do you need the projection at all? Please, clarify and remove `FIXME` comment.

src/hotspot/share/opto/graphKit.cpp line 2675:

> 2673:     // Unpack native results if needed
> 2674:     // Need this method type since it's unerased
> 2675:     switch (nep->method_type()->rtype()->basic_type()) {

Are calls returning multiple values supported right now? (From what I'm seeing in other places, they are not supported.) If not, then you don't need a loop over return values and there are other places where it can simplify code.

src/hotspot/share/opto/type.hpp line 678:

> 676:   static const TypeTuple *make_range(ciSignature *sig);
> 677:   static const TypeTuple *make_domain(ciInstanceKlass* recv, ciSignature *sig);
> 678:   static const TypeTuple *make_func(uint arg_cnt, const Type **arg_fields);

I find `make_func` name misleading: it makes an impression you get `TypeFunc` out of it, but in reailty it just composes type array with `TypeTyple::make`+`TypeTyple::fields`.  I'd prefer to see it as `TypeTuple::fields` overload.

Or rewrite `GraphKit::make_native_call` to operate directly on `TypeTyple::fields` and get rid fo intermediate arrays.

src/hotspot/share/opto/output.cpp line 1144:

> 1142:     methodHandle null_mh;
> 1143:     bool rethrow_exception = false;
> 1144:     bool is_opt_native = mach->is_MachCallNative();

Please, move it to `MachCall`-related logic (where `is_method_handle_invoke` is set).

src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp line 77:

> 75:     XMMRegister reg = _abi->_vector_argument_registers.at(i);
> 76:     size_t offs = _layout->arguments_vector + i * sizeof(VectorRegister);
> 77:     if (UseAVX >= 3) {

Assuming worst-case scenario (w.r.t. value size) is sub-optimal. Considering FP values are handled as vectors you end up operating on 32-bit/64-bit values as if they were 512-bit in size. And, in addition to wasted memory bandwidth, EVEX-encoded instructions may trigger CPU frequency scaling which will penalize cases when AVX512 is not used. So, it is worth considering annotating vector values with their actual sizes and taking the size into account when operating on vectors.

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

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

From jvernee at openjdk.java.net  Wed Nov 11 14:42:12 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 Nov 2020 14:42:12 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v18]
In-Reply-To: <JJ6qdIZFLnnE1yqOVCPu5xEDWEKNiaVPQXgh4DH8Fhk=.7daf2599-efa9-4a47-aa7d-e52c58e2b6cf@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <AK-p2u_9FlJzupbJzCMvC55iWN_5j5lNwy8q1SXGObI=.615fee87-b80b-4bcf-8b6e-33c758eb4da4@github.com>
 <JJ6qdIZFLnnE1yqOVCPu5xEDWEKNiaVPQXgh4DH8Fhk=.7daf2599-efa9-4a47-aa7d-e52c58e2b6cf@github.com>
Message-ID: <Xtd7iX0fmncQVgGmkcCKSlMuC5ZBIicnWyxdw_DzlUg=.540f329e-ddea-4ec2-9a6a-8b891ac43810@github.com>

On Wed, 11 Nov 2020 12:44:56 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision:
>> 
>>  - Merge pull request #7 from JornVernee/Additional_Review_Comments
>>    
>>    Additional review comments
>>  - Revert System.java changes
>>  - Set copyright year for added files to 2020
>>  - Check result of AttachCurrentThread
>>  - Sort includes alphabetically
>>  - Relax ret_addr_offset() assert
>>  - Extra space after if
>>  - remove excessive asserts in ProgrammableInvoker::invoke_native
>>  - Remove os::is_MP() check
>>  - remove blank line in thread.hpp
>
> src/hotspot/share/opto/callnode.cpp line 1143:
> 
>> 1141:     case TypeFunc::Parms:
>> 1142:     default: {
>> 1143:       if(tf()->range()->field_at(proj->_con) == Type::HALF) {
> 
> That's `TypeFunc::Parms+1` case in `CallNode::match`. Why did you decide to move it to `default` case? 
> 
> Overall, it looks very similar to `CallNode::match`. Why not just customize `OptoRegPair regs` computation for `CallNative` there?

For native calls we can have multiple return values, at least in theory. Currently this is not the case though.

Will take another look.

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

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

From jvernee at openjdk.java.net  Wed Nov 11 14:48:04 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 Nov 2020 14:48:04 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v18]
In-Reply-To: <JJ6qdIZFLnnE1yqOVCPu5xEDWEKNiaVPQXgh4DH8Fhk=.7daf2599-efa9-4a47-aa7d-e52c58e2b6cf@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <AK-p2u_9FlJzupbJzCMvC55iWN_5j5lNwy8q1SXGObI=.615fee87-b80b-4bcf-8b6e-33c758eb4da4@github.com>
 <JJ6qdIZFLnnE1yqOVCPu5xEDWEKNiaVPQXgh4DH8Fhk=.7daf2599-efa9-4a47-aa7d-e52c58e2b6cf@github.com>
Message-ID: <AntY5CoOfgZEPcJCWHOs6SoHEPTIhZO9qpsAqa9gtnQ=.51338daa-6484-4c16-9d32-3b421a59d47f@github.com>

On Wed, 11 Nov 2020 14:17:20 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision:
>> 
>>  - Merge pull request #7 from JornVernee/Additional_Review_Comments
>>    
>>    Additional review comments
>>  - Revert System.java changes
>>  - Set copyright year for added files to 2020
>>  - Check result of AttachCurrentThread
>>  - Sort includes alphabetically
>>  - Relax ret_addr_offset() assert
>>  - Extra space after if
>>  - remove excessive asserts in ProgrammableInvoker::invoke_native
>>  - Remove os::is_MP() check
>>  - remove blank line in thread.hpp
>
> src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp line 77:
> 
>> 75:     XMMRegister reg = _abi->_vector_argument_registers.at(i);
>> 76:     size_t offs = _layout->arguments_vector + i * sizeof(VectorRegister);
>> 77:     if (UseAVX >= 3) {
> 
> Assuming worst-case scenario (w.r.t. value size) is sub-optimal. Considering FP values are handled as vectors you end up operating on 32-bit/64-bit values as if they were 512-bit in size. And, in addition to wasted memory bandwidth, EVEX-encoded instructions may trigger CPU frequency scaling which will penalize cases when AVX512 is not used. So, it is worth considering annotating vector values with their actual sizes and taking the size into account when operating on vectors.

Yes, more cleanup is needed here. We don't support vectors at all right now, so I'd rather remove this code and only operate on XMM registers instead.

In the future this could be handled using separate VMStorage types for different vector sizes.

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

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

From rkennke at openjdk.java.net  Wed Nov 11 15:23:12 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 11 Nov 2020 15:23:12 GMT
Subject: RFR: 8256106: Bypass intrinsic/barrier when calling
 Reference.get() from Finalizer [v2]
In-Reply-To: <CFzWfHREh0P7xzdn5-X5I0gqV5YG4Xs70Oo2Zd6ZCfY=.f4af9a11-e99c-4bb7-a254-b2cf05ef2ba0@github.com>
References: <CFzWfHREh0P7xzdn5-X5I0gqV5YG4Xs70Oo2Zd6ZCfY=.f4af9a11-e99c-4bb7-a254-b2cf05ef2ba0@github.com>
Message-ID: <onY1b2atpGqVFdnfCxGcm9NAld2tv3LsF0SyqJHCXBE=.23672376-e8dc-4fd4-b90f-df1b7d451600@github.com>

> Finalizer calls Reference.get() from the Finalizer to acquire the finalizee. Concurrent reference processing GCs like Shenandoah and ZGC would return NULL for unreachable referents, and thus would not call finalize() on them.
> 
> ZGC works around this by fixing the referent before enqueuing, so that the barrier would take the fast-path, but Shenandoah cannot do this.
> 
> It is ok to bypass the barrier altogether in this place, because the FinalReference is inactive and marking and reference-discovery treat inactive FinalReferences like strong references.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1 +UseShenandoahGC +ShenandoahVerify
>  - [x] tier2 +UseShenandoahGC +ShenandoahVerify
>  - [x] tier1
>  - [x] tier2

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

 - Merge branch 'master' into JDK-8256106
 - 8256106: Bypass intrinsic/barrier when calling Reference.get() from Finalizer

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1140/files
  - new: https://git.openjdk.java.net/jdk/pull/1140/files/52820f98..61878147

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

  Stats: 5646 lines in 150 files changed: 3822 ins; 862 del; 962 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1140.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1140/head:pull/1140

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

From naoto at openjdk.java.net  Wed Nov 11 15:33:59 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 11 Nov 2020 15:33:59 GMT
Subject: RFR: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence [v2]
In-Reply-To: <1D4M66CbBg1O5uHteS_kY0pKEos7Olhwlj_1RLBvoCs=.1cf2a416-ba80-421c-95a8-edca93cc55a5@github.com>
References: <vRlZhcESYttdSpeB0IuIOAd77U4iUbjE51cnhiatTnw=.1e8cb2ac-aa59-484e-976c-3d0715aec51b@github.com>
 <1D4M66CbBg1O5uHteS_kY0pKEos7Olhwlj_1RLBvoCs=.1cf2a416-ba80-421c-95a8-edca93cc55a5@github.com>
Message-ID: <lxYje_Ncu4bUbPmJlMC9Z6NoXu2NNOWTfyd6ltsFWq8=.5b6e7b9d-2e7a-471d-a348-621387c2e579@github.com>

On Wed, 11 Nov 2020 11:58:08 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi, 
>> 
>> Please review the fix for JDK-8256018 which addresses the issue that  the update(ByteBuffer)  methods of Adler32, CRC32, and CRC32C should use Reference.reachabilityFence to ensure that direct byte buffer are kept kept alive when they are accessed directly.
>> 
>> The Mach5 jdk-tier1, jdk-tier2, jdk-tier3 as well as the  jck:api/java_util/zip,jck:api/java_util/jar continue to run clean.
>> 
>> Best
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove extra blank line

Still looks good.

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

Marked as reviewed by naoto (Reviewer).

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

From jvernee at openjdk.java.net  Wed Nov 11 15:36:11 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 11 Nov 2020 15:36:11 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v18]
In-Reply-To: <JJ6qdIZFLnnE1yqOVCPu5xEDWEKNiaVPQXgh4DH8Fhk=.7daf2599-efa9-4a47-aa7d-e52c58e2b6cf@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <AK-p2u_9FlJzupbJzCMvC55iWN_5j5lNwy8q1SXGObI=.615fee87-b80b-4bcf-8b6e-33c758eb4da4@github.com>
 <JJ6qdIZFLnnE1yqOVCPu5xEDWEKNiaVPQXgh4DH8Fhk=.7daf2599-efa9-4a47-aa7d-e52c58e2b6cf@github.com>
Message-ID: <nBxoAcVFfZHc5JY79lagvAJJY8hseGr5SMhu66WX4vI=.532a7f2b-14e8-4033-8813-7aed2057405e@github.com>

On Wed, 11 Nov 2020 11:05:47 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision:
>> 
>>  - Merge pull request #7 from JornVernee/Additional_Review_Comments
>>    
>>    Additional review comments
>>  - Revert System.java changes
>>  - Set copyright year for added files to 2020
>>  - Check result of AttachCurrentThread
>>  - Sort includes alphabetically
>>  - Relax ret_addr_offset() assert
>>  - Extra space after if
>>  - remove excessive asserts in ProgrammableInvoker::invoke_native
>>  - Remove os::is_MP() check
>>  - remove blank line in thread.hpp
>
> src/hotspot/share/opto/machnode.cpp line 831:
> 
>> 829:   st->print("%s ",_name);
>> 830:   st->print("_arg_regs: ");
>> 831:   _arg_regs.print_on(st);
> 
> It doesn't print any useful info: `_arg_regs: AllocatedObj(0x000000011cf5cbe8)`. Please, improve it.

Ok, I added printing to GrowableArray at some point, but seems that this was removed in a merge maybe.

> src/hotspot/share/opto/graphKit.cpp line 2665:
> 
>> 2663:     for (uint vm_ret_pos = 0; vm_ret_pos < n_returns; vm_ret_pos++) {
>> 2664:       if (new_call_type->range()->field_at(TypeFunc::Parms + vm_ret_pos)  == Type::HALF) {
>> 2665:         // FIXME is this needed?
> 
> Why do you need the projection at all? Please, clarify and remove `FIXME` comment.

Was a leftover. Will remove

> src/hotspot/share/opto/graphKit.cpp line 2675:
> 
>> 2673:     // Unpack native results if needed
>> 2674:     // Need this method type since it's unerased
>> 2675:     switch (nep->method_type()->rtype()->basic_type()) {
> 
> Are calls returning multiple values supported right now? (From what I'm seeing in other places, they are not supported.) If not, then you don't need a loop over return values and there are other places where it can simplify code.

Yes, multiple returns are not supported currently. Will simplify this.

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

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

From lancea at openjdk.java.net  Wed Nov 11 15:36:55 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 11 Nov 2020 15:36:55 GMT
Subject: Integrated: 8256018: Adler32/CRC32/CRC32C missing reachabilityFence
In-Reply-To: <vRlZhcESYttdSpeB0IuIOAd77U4iUbjE51cnhiatTnw=.1e8cb2ac-aa59-484e-976c-3d0715aec51b@github.com>
References: <vRlZhcESYttdSpeB0IuIOAd77U4iUbjE51cnhiatTnw=.1e8cb2ac-aa59-484e-976c-3d0715aec51b@github.com>
Message-ID: <7BH2T89dSp1IFuXVxvg7WAQHuU_ld_lcBlltiFP7eoE=.6f0ba94f-973a-4636-8091-41357fb14f01@github.com>

On Tue, 10 Nov 2020 21:26:59 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi, 
> 
> Please review the fix for JDK-8256018 which addresses the issue that  the update(ByteBuffer)  methods of Adler32, CRC32, and CRC32C should use Reference.reachabilityFence to ensure that direct byte buffer are kept kept alive when they are accessed directly.
> 
> The Mach5 jdk-tier1, jdk-tier2, jdk-tier3 as well as the  jck:api/java_util/zip,jck:api/java_util/jar continue to run clean.
> 
> Best
> Lance

This pull request has now been integrated.

Changeset: 6247736f
Author:    Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6247736f
Stats:     22 lines in 3 files changed: 15 ins; 0 del; 7 mod

8256018: Adler32/CRC32/CRC32C missing reachabilityFence

Reviewed-by: naoto, alanb

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

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

From eosterlund at openjdk.java.net  Wed Nov 11 17:20:59 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 11 Nov 2020 17:20:59 GMT
Subject: RFR: 8256106: Bypass intrinsic/barrier when calling
 Reference.get() from Finalizer [v2]
In-Reply-To: <onY1b2atpGqVFdnfCxGcm9NAld2tv3LsF0SyqJHCXBE=.23672376-e8dc-4fd4-b90f-df1b7d451600@github.com>
References: <CFzWfHREh0P7xzdn5-X5I0gqV5YG4Xs70Oo2Zd6ZCfY=.f4af9a11-e99c-4bb7-a254-b2cf05ef2ba0@github.com>
 <onY1b2atpGqVFdnfCxGcm9NAld2tv3LsF0SyqJHCXBE=.23672376-e8dc-4fd4-b90f-df1b7d451600@github.com>
Message-ID: <UIv-UhR0z00hXy-0k5-jljfehEoiW10q1153BR1NFuo=.e995affa-afef-4d3a-8e06-7f380d123f02@github.com>

On Wed, 11 Nov 2020 15:23:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Finalizer calls Reference.get() from the Finalizer to acquire the finalizee. Concurrent reference processing GCs like Shenandoah and ZGC would return NULL for unreachable referents, and thus would not call finalize() on them.
>> 
>> ZGC works around this by fixing the referent before enqueuing, so that the barrier would take the fast-path, but Shenandoah cannot do this.
>> 
>> It is ok to bypass the barrier altogether in this place, because the FinalReference is inactive and marking and reference-discovery treat inactive FinalReferences like strong references.
>> 
>> Testing:
>>  - [x] hotspot_gc_shenandoah
>>  - [x] tier1 +UseShenandoahGC +ShenandoahVerify
>>  - [x] tier2 +UseShenandoahGC +ShenandoahVerify
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8256106
>  - 8256106: Bypass intrinsic/barrier when calling Reference.get() from Finalizer

I would prefer if we could make this look like less of a hack. We use the "raw" postfix usually to describe an access that will not have GC barriers applied. This is not true here. What it does, is rather to apply strong load barriers, which is not a raw access. So I think the name should suggest that this is treated like a strong access. Strong loads are semantically okay when the Reference is inactive, because then the referent switches over to strong semantics instead. So perhaps we could call it something that better captures this. Either something like getAsStrong() or getInactive(). I think I might prefer the latter. And new comments to describe what I just said. Oh and the comments should maybe be in java doc format like all the other comments in this file.

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

Changes requested by eosterlund (Reviewer).

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

From justin.dekeyser at gmail.com  Wed Nov 11 17:22:10 2020
From: justin.dekeyser at gmail.com (Justin Dekeyser)
Date: Wed, 11 Nov 2020 18:22:10 +0100
Subject: 'Find' method for Iterable
In-Reply-To: <CA+0ynh9n9+_4+AQkLoiD8vvKCgdCV3YCuC0QsA=eHtN+-e9hZQ@mail.gmail.com>
References: <CA+0ynh9wguU9b4ZQnOz=ySeSa9sovYzeeQ=rAa8fPJCpo=gXag@mail.gmail.com>
 <219103610.2532126.1600289966746.JavaMail.zimbra@u-pem.fr>
 <e4abaa1c-2d82-4ceb-a046-f914cb6056af@oracle.com>
 <CA+0ynh-54KbmQrshE4cJdJ8Q=MCBEUbN3cnW7=J=6Xbr1g5HmQ@mail.gmail.com>
 <CA+0ynh9n9+_4+AQkLoiD8vvKCgdCV3YCuC0QsA=eHtN+-e9hZQ@mail.gmail.com>
Message-ID: <CAO5-QM0XE9bXf3j=qOPwfNgE=yZEQrXiXYJGUs_NNvce00HYQA@mail.gmail.com>

Hello all,

Were those downsides seriously considered and strongly argued against? :

(1) Iterable belongs to java.lang so, at least from how it is usually
approached, it's a feature at the very level of the language, not a
util feature like Collection. Adding a find on it, is it really
relevant, or should it be concerned with the simple idea of unlocking
the enhanced-for loop syntax?

(2) For the find() method to stop on any Iterable, the Iterable should
have finite size. This mean the size() method can be implemented too,
by this move:
```java
default int size() {
   int[] dummy = { 0 };
   Predicate<T> falsy = $ -> { dummy[0] += 1; return false; }
   find(falsy);
   return dummy[0];
}
```
At the very moment an Iterable<T> also has a size(), a Collection<T>
implementation can be provided (since the altering methods add/remove
are optional in this spec). So , long story short:

Adding a find() method on Iterable<T> with a contract that it stops
(stops, and not just linear search time), makes it a Collection. It
really looks like a nonsense. Or maybe you're going to relax the "this
method is guaranteed to stop" from the spec? Is it then still
relevant?

Note: This (2) problem is not a problem for now, because all the utils
that turns Iterable<T> to a collection like stuff, or a Stream, are
actually features *on those latter* classes. Hence it's not a concern
of Iterable<T> itself.
The problem with (1) is really a communication problem: nothing is
made in the Java documentation to clearly indicate whether or not
Iterable should be used businesswise, or is it only for
syntax-enhancement. (The same problem goes for AutoCloseable: you'll
really find two schools out of there.)

(3) To my opinion, most people are using Iterable either from a
collection (where the .stream().filter(p).findAny() makes the job.
It's not perfect but it's quite clear and flexible) or with a
ResultSet, where the SQL procedure could/should be used anyway. The
other cases look so exotic (but I might be wrong) that I really wonder
how a find method on a Iterable (and not Collection) stuff can be felt
so useful and language fundamental, that it should be in the java.lang
package.

Best regards,

Justin Dekeyser

On Tue, Nov 10, 2020 at 7:02 PM Nir Lisker <nlisker at gmail.com> wrote:
>
> Did this discussion get lost?
>
> On Sun, Sep 20, 2020 at 1:27 AM Nir Lisker <nlisker at gmail.com> wrote:
>
> > While it might not be difficult to add a find() method to Iterable, why
> >> limit it to
> >> the find operation, and what about all the other operations available on
> >> Stream?
> >
> >
> > Good question. I would say it's a matter of how much it is used and what
> > it takes to implement it. The find operation is a lot more common than
> > reduce from what I observe, for example, so I wouldn't suggest reduce to be
> > added..A map(Function<T,R>) operation would require creating a new
> > collection/iterable internally, and that can be messy (you could
> > preemptively create and pass your own, but then I doubt the worthiness of
> > it). forEach already exists. I just don't see anything enticing.
> >
> > Maybe what's necessary is a way to convert an Iterable to a Stream.
> >
> >
> > Most Iterables are Collections and arrays, and these are easy to convert,
> > so I'm not sure if that really helps. Besides,the idea is to avoid Stream,
> > as I've mentioned, due to the cumbersomeness and the overhead of creating a
> > stream. If I need to do
> >
> > iterable.stream().filter(person -> person.id == 123456).findAny/First()
> >
> > then I didn't really solve my problem.
> >
> > On the other hand, your examples use a list. The List interface already
> >> has methods
> >> indexOf/lastIndexOf which search the list for a particular object that's
> >> compared
> >> using equals(). It seems reasonable to consider similar methods that take
> >> a
> >> predicate instead of an object.
> >
> >
> > I could have used a Set just as well. As for indexOf(Predicate<T>), I
> > would say that it is useful (but personally, I hardly ever need the index
> > of an object, I need the object itself). Interestingly,
> > removeIf(Predicate<T>) exists, but remove(Predicate<T>) doesn't. I would
> > think twice before suggesting to add it though.
> >
> > Ultimately, you have access to a lot of analytics and codebase scans. If
> > you know which patterns are used a lot more than others it would be a good
> > guide. If there are a lot of iterations in order to find an object, its
> > index, or to remove it (or something else), perhaps it's worth supplying
> > these methods. After all, forEach(Consumer<T>) exists and it iterates while
> > calling accept(t) - not that different from iterating with test(t).
> >
> > P.S. lastIndexOf I find odd in the sense that it's the only method I found
> > that iterates backwards, We don't have, removeLast, removeIfBackwards,
> > forEachBackwards, a backwards for-each loop, or addLast (the latter is
> > add(list.size()-1, e); ).
> >
> > - Nir
> >
> > On Thu, Sep 17, 2020 at 1:32 AM Stuart Marks <stuart.marks at oracle.com>
> > wrote:
> >
> >>
> >>
> >> On 9/16/20 1:59 PM, Remi Forax wrote:
> >> > ----- Mail original -----
> >> >> De: "Nir Lisker" <nlisker at gmail.com>
> >> >> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> >> >> Envoy?: Lundi 14 Septembre 2020 20:56:27
> >> >> Objet: 'Find' method for Iterable
> >> >
> >> >> Hi,
> >> >>
> >> >> This has probably been brought up at some point. When we need to find
> >> an
> >> >> item in a collection based on its properties, we can either do it in a
> >> >> loop, testing each item, or in a stream with filter and findFirst/Any.
> >> >>
> >> >> I would think that a method in Iterable<T> be useful, along the lines
> >> of:
> >> >>
> >> >> public <T> Optional<T> find(Predicate<T> condition) {
> >> >>     Objects.requireNonNull(condition);
> >> >>     for (T t : this) {
> >> >>          if (condition.test(t)) {
> >> >>              return Optional.of(t);
> >> >>         }
> >> >>     }
> >> >>     return Optional.empty();
> >> >> }
> >> >>
> >> >> With usage:
> >> >>
> >> >> list.find(person -> person.id == 123456);
> >> >>
> >> >> There are a few issues with the method here such as t being null in
> >> >> null-friendly collections and the lack of bound generic types, but this
> >> >> example is just used to explain the intention.
> >> >>
> >> >> It will be an alternative to
> >> >>
> >> >> list.stream().filter(person -> person.id == 123456).findAny/First()
> >> >> (depending on if the collection is ordered or not)
> >> >>
> >> >> which doesn't create a stream, similar to Iterable#forEach vs
> >> >> Stream#forEach.
> >> >>
> >> >> Maybe with pattern matching this would become more appetizing.
> >> >
> >> > During the development of Java 8, we first tried to use
> >> Iterator/Iterable instead of using a novel interface Stream.
> >> > But a Stream cleanly separate the lazy side effect free API from the
> >> mutable one (Collection) and can be optimized better by the VM (it's a push
> >> API instead of being a pull API).
> >> >
> >> > The other question is why there is no method find() on Collection, i
> >> believe it's because while find() is ok for any DB API, find() is dangerous
> >> on a Collection because the execution time is linear, so people may use it
> >> instead of using a Map.
> >>
> >>
> >> Hi Nir,
> >>
> >> R?mi is correct to point out this distinction between the lazy operations
> >> (which
> >> appear on Stream) and the eager (and possibly mutating) operations on
> >> Collections. I
> >> think we want to preserve this distinction.
> >>
> >> While it might not be difficult to add a find() method to Iterable, why
> >> limit it to
> >> the find operation, and what about all the other operations available on
> >> Stream?
> >> Maybe what's necessary is a way to convert an Iterable to a Stream. In
> >> fact, this is
> >> already possible:
> >>
> >>      StreamSupport.stream(iterable.spliterator(), false)
> >>
> >> Well, this is mouthful, so maybe there ought to be an easier way to
> >> convert an
> >> Iterable to a Stream.
> >>
> >> On the other hand, your examples use a list. The List interface already
> >> has methods
> >> indexOf/lastIndexOf which search the list for a particular object that's
> >> compared
> >> using equals(). It seems reasonable to consider similar methods that take
> >> a
> >> predicate instead of an object.
> >>
> >> Does either of these sound promising?
> >>
> >> s'marks
> >>
> >

From rkennke at openjdk.java.net  Wed Nov 11 17:48:12 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 11 Nov 2020 17:48:12 GMT
Subject: RFR: 8256106: Bypass intrinsic/barrier when calling
 Reference.get() from Finalizer [v3]
In-Reply-To: <CFzWfHREh0P7xzdn5-X5I0gqV5YG4Xs70Oo2Zd6ZCfY=.f4af9a11-e99c-4bb7-a254-b2cf05ef2ba0@github.com>
References: <CFzWfHREh0P7xzdn5-X5I0gqV5YG4Xs70Oo2Zd6ZCfY=.f4af9a11-e99c-4bb7-a254-b2cf05ef2ba0@github.com>
Message-ID: <iRmUSs1VRLBsKD_fMQwcVGTkGQYRc77U76TN0qh4-ns=.741276bd-c16b-4c59-94a8-35bed65ead46@github.com>

> Finalizer calls Reference.get() from the Finalizer to acquire the finalizee. Concurrent reference processing GCs like Shenandoah and ZGC would return NULL for unreachable referents, and thus would not call finalize() on them.
> 
> ZGC works around this by fixing the referent before enqueuing, so that the barrier would take the fast-path, but Shenandoah cannot do this.
> 
> It is ok to bypass the barrier altogether in this place, because the FinalReference is inactive and marking and reference-discovery treat inactive FinalReferences like strong references.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1 +UseShenandoahGC +ShenandoahVerify
>  - [x] tier2 +UseShenandoahGC +ShenandoahVerify
>  - [x] tier1
>  - [x] tier2

Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:

  Rename inactive-getter and improve javadocs

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1140/files
  - new: https://git.openjdk.java.net/jdk/pull/1140/files/61878147..45e35e78

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

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

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

From eosterlund at openjdk.java.net  Wed Nov 11 18:07:02 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 11 Nov 2020 18:07:02 GMT
Subject: RFR: 8256106: Bypass intrinsic/barrier when calling
 Reference.get() from Finalizer [v3]
In-Reply-To: <iRmUSs1VRLBsKD_fMQwcVGTkGQYRc77U76TN0qh4-ns=.741276bd-c16b-4c59-94a8-35bed65ead46@github.com>
References: <CFzWfHREh0P7xzdn5-X5I0gqV5YG4Xs70Oo2Zd6ZCfY=.f4af9a11-e99c-4bb7-a254-b2cf05ef2ba0@github.com>
 <iRmUSs1VRLBsKD_fMQwcVGTkGQYRc77U76TN0qh4-ns=.741276bd-c16b-4c59-94a8-35bed65ead46@github.com>
Message-ID: <TfUpUcfj__F8Gor6mHYNclPZMuFmle1x666bYWlkYbk=.de8d25eb-d629-459b-bfe9-b69bac94c7a0@github.com>

On Wed, 11 Nov 2020 17:48:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Finalizer calls Reference.get() from the Finalizer to acquire the finalizee. Concurrent reference processing GCs like Shenandoah and ZGC would return NULL for unreachable referents, and thus would not call finalize() on them.
>> 
>> ZGC works around this by fixing the referent before enqueuing, so that the barrier would take the fast-path, but Shenandoah cannot do this.
>> 
>> It is ok to bypass the barrier altogether in this place, because the FinalReference is inactive and marking and reference-discovery treat inactive FinalReferences like strong references.
>> 
>> Testing:
>>  - [x] hotspot_gc_shenandoah
>>  - [x] tier1 +UseShenandoahGC +ShenandoahVerify
>>  - [x] tier2 +UseShenandoahGC +ShenandoahVerify
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename inactive-getter and improve javadocs

Looks good.

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

Marked as reviewed by eosterlund (Reviewer).

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

From rkennke at openjdk.java.net  Wed Nov 11 18:09:55 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 11 Nov 2020 18:09:55 GMT
Subject: Integrated: 8256106: Bypass intrinsic/barrier when calling
 Reference.get() from Finalizer
In-Reply-To: <CFzWfHREh0P7xzdn5-X5I0gqV5YG4Xs70Oo2Zd6ZCfY=.f4af9a11-e99c-4bb7-a254-b2cf05ef2ba0@github.com>
References: <CFzWfHREh0P7xzdn5-X5I0gqV5YG4Xs70Oo2Zd6ZCfY=.f4af9a11-e99c-4bb7-a254-b2cf05ef2ba0@github.com>
Message-ID: <Fsv48ZFjezrc10r2ovysBwwV2Bwd-E5S6arevYIjVsU=.aa2365bf-39a3-447f-8707-29f7980ab05b@github.com>

On Tue, 10 Nov 2020 09:37:29 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> Finalizer calls Reference.get() from the Finalizer to acquire the finalizee. Concurrent reference processing GCs like Shenandoah and ZGC would return NULL for unreachable referents, and thus would not call finalize() on them.
> 
> ZGC works around this by fixing the referent before enqueuing, so that the barrier would take the fast-path, but Shenandoah cannot do this.
> 
> It is ok to bypass the barrier altogether in this place, because the FinalReference is inactive and marking and reference-discovery treat inactive FinalReferences like strong references.
> 
> Testing:
>  - [x] hotspot_gc_shenandoah
>  - [x] tier1 +UseShenandoahGC +ShenandoahVerify
>  - [x] tier2 +UseShenandoahGC +ShenandoahVerify
>  - [x] tier1
>  - [x] tier2

This pull request has now been integrated.

Changeset: 96e02610
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/96e02610
Stats:     15 lines in 2 files changed: 14 ins; 0 del; 1 mod

8256106: Bypass intrinsic/barrier when calling Reference.get() from Finalizer

Reviewed-by: eosterlund

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

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

From ayang at openjdk.java.net  Wed Nov 11 18:15:54 2020
From: ayang at openjdk.java.net (Albert Mingkun Yang)
Date: Wed, 11 Nov 2020 18:15:54 GMT
Subject: RFR: 8256106: Bypass intrinsic/barrier when calling
 Reference.get() from Finalizer [v3]
In-Reply-To: <TfUpUcfj__F8Gor6mHYNclPZMuFmle1x666bYWlkYbk=.de8d25eb-d629-459b-bfe9-b69bac94c7a0@github.com>
References: <CFzWfHREh0P7xzdn5-X5I0gqV5YG4Xs70Oo2Zd6ZCfY=.f4af9a11-e99c-4bb7-a254-b2cf05ef2ba0@github.com>
 <iRmUSs1VRLBsKD_fMQwcVGTkGQYRc77U76TN0qh4-ns=.741276bd-c16b-4c59-94a8-35bed65ead46@github.com>
 <TfUpUcfj__F8Gor6mHYNclPZMuFmle1x666bYWlkYbk=.de8d25eb-d629-459b-bfe9-b69bac94c7a0@github.com>
Message-ID: <C1TDWKlR-HAhXoCdZWcGSu7hJA5ylJ4lCUscr5BIwVY=.c8599b05-596a-4308-b323-6b61b66257f8@github.com>

On Wed, 11 Nov 2020 18:04:12 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename inactive-getter and improve javadocs
>
> Looks good.

With `getInactive`, is the null check, `if (finalizee != null` still needed?

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

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

From mchung at openjdk.java.net  Wed Nov 11 18:28:02 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 11 Nov 2020 18:28:02 GMT
Subject: RFR: 8256106: Bypass intrinsic/barrier when calling
 Reference.get() from Finalizer [v3]
In-Reply-To: <iRmUSs1VRLBsKD_fMQwcVGTkGQYRc77U76TN0qh4-ns=.741276bd-c16b-4c59-94a8-35bed65ead46@github.com>
References: <CFzWfHREh0P7xzdn5-X5I0gqV5YG4Xs70Oo2Zd6ZCfY=.f4af9a11-e99c-4bb7-a254-b2cf05ef2ba0@github.com>
 <iRmUSs1VRLBsKD_fMQwcVGTkGQYRc77U76TN0qh4-ns=.741276bd-c16b-4c59-94a8-35bed65ead46@github.com>
Message-ID: <XnjFGMzsoS4MiBYuwUea9RtztVe9eqoeBUU5L2yy2LI=.0c86139c-1e32-4116-a7c4-2453038480b9@github.com>

On Wed, 11 Nov 2020 17:48:12 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Finalizer calls Reference.get() from the Finalizer to acquire the finalizee. Concurrent reference processing GCs like Shenandoah and ZGC would return NULL for unreachable referents, and thus would not call finalize() on them.
>> 
>> ZGC works around this by fixing the referent before enqueuing, so that the barrier would take the fast-path, but Shenandoah cannot do this.
>> 
>> It is ok to bypass the barrier altogether in this place, because the FinalReference is inactive and marking and reference-discovery treat inactive FinalReferences like strong references.
>> 
>> Testing:
>>  - [x] hotspot_gc_shenandoah
>>  - [x] tier1 +UseShenandoahGC +ShenandoahVerify
>>  - [x] tier2 +UseShenandoahGC +ShenandoahVerify
>>  - [x] tier1
>>  - [x] tier2
>
> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename inactive-getter and improve javadocs

src/java.base/share/classes/java/lang/ref/Reference.java line 356:

> 354:      */
> 355:     T getInactive() {
> 356:         return this.referent;

It would be good to add `assert this instanceof FinalReference` to make this assertion clear.

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

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

From rkennke at openjdk.java.net  Wed Nov 11 18:27:59 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 11 Nov 2020 18:27:59 GMT
Subject: RFR: 8256106: Bypass intrinsic/barrier when calling
 Reference.get() from Finalizer [v3]
In-Reply-To: <C1TDWKlR-HAhXoCdZWcGSu7hJA5ylJ4lCUscr5BIwVY=.c8599b05-596a-4308-b323-6b61b66257f8@github.com>
References: <CFzWfHREh0P7xzdn5-X5I0gqV5YG4Xs70Oo2Zd6ZCfY=.f4af9a11-e99c-4bb7-a254-b2cf05ef2ba0@github.com>
 <iRmUSs1VRLBsKD_fMQwcVGTkGQYRc77U76TN0qh4-ns=.741276bd-c16b-4c59-94a8-35bed65ead46@github.com>
 <TfUpUcfj__F8Gor6mHYNclPZMuFmle1x666bYWlkYbk=.de8d25eb-d629-459b-bfe9-b69bac94c7a0@github.com>
 <C1TDWKlR-HAhXoCdZWcGSu7hJA5ylJ4lCUscr5BIwVY=.c8599b05-596a-4308-b323-6b61b66257f8@github.com>
Message-ID: <0wWrYRCZyu-8qEzQCtCNft6bzpk6fnz9rKvp6gJeTkc=.5e61b95f-f915-4060-b95b-8bb86d79d537@github.com>

On Wed, 11 Nov 2020 18:13:30 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

> With `getInactive`, is the null check, `if (finalizee != null` still needed?

Good point! I don't think it is. The GC should not clean the referent before we finalized it (or not at all), and no other code is clearing it either. Unfortunately, I just integrated this PR, do you think it'd be worth to open a follow-up issue?

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

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

From rkennke at openjdk.java.net  Wed Nov 11 18:28:03 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Wed, 11 Nov 2020 18:28:03 GMT
Subject: RFR: 8256106: Bypass intrinsic/barrier when calling
 Reference.get() from Finalizer [v3]
In-Reply-To: <XnjFGMzsoS4MiBYuwUea9RtztVe9eqoeBUU5L2yy2LI=.0c86139c-1e32-4116-a7c4-2453038480b9@github.com>
References: <CFzWfHREh0P7xzdn5-X5I0gqV5YG4Xs70Oo2Zd6ZCfY=.f4af9a11-e99c-4bb7-a254-b2cf05ef2ba0@github.com>
 <iRmUSs1VRLBsKD_fMQwcVGTkGQYRc77U76TN0qh4-ns=.741276bd-c16b-4c59-94a8-35bed65ead46@github.com>
 <XnjFGMzsoS4MiBYuwUea9RtztVe9eqoeBUU5L2yy2LI=.0c86139c-1e32-4116-a7c4-2453038480b9@github.com>
Message-ID: <sIRHDcnQ3o-MmZIutDfaUn0BHbLt89-g_XQoqHJiiIE=.5f2204b2-7f60-41b0-9583-f7be8a7e3cd9@github.com>

On Wed, 11 Nov 2020 18:19:01 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Roman Kennke has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename inactive-getter and improve javadocs
>
> src/java.base/share/classes/java/lang/ref/Reference.java line 356:
> 
>> 354:      */
>> 355:     T getInactive() {
>> 356:         return this.referent;
> 
> It would be good to add `assert this instanceof FinalReference` to make this assertion clear.

Right. And maybe also assert that the Reference is indeed inactive. I'll open a new issue for that (I already integrated this one, sorry I kinda jumped the gun a little.)

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

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

From mchung at openjdk.java.net  Wed Nov 11 18:57:04 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 11 Nov 2020 18:57:04 GMT
Subject: RFR: 8230501: Class data support for hidden classes
Message-ID: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>

Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects
be shared between a hidden class and other classes.  A hidden class can load
these live objects as dynamically-computed constants via this API.

Specdiff
http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html

With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass`
will be deprecated for removal.  Existing libraries should replace their
calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass`
or `Lookup::defineHiddenClassWithClassData`.

This patch also updates the implementation of lambda meta factory and
`MemoryAccessVarHandleGenerator` to use class data.   No performance difference
observed in the jdk.incubator.foreign microbenchmarks.   A side note: 
`MemoryAccessVarHandleGenerator` is removed in the upcoming integration of 
JDK-8254162 but it helps validating the class data support.

Background
----------

This is an enhancement following up JEP 371: Hidden Classes w.r.t.
"Constant-pool patching" in the "Risks and Assumption" section.

A VM-anonymous class can be defined with its constant-pool entries already
resolved to concrete values. This allows critical constants to be shared
between a VM-anonymous class and the language runtime that defines it, and
between multiple VM-anonymous classes. For example, a language runtime will
often have `MethodHandle` objects in its address space that would be useful
to newly-defined VM-anonymous classes. Instead of the runtime serializing
the objects to constant-pool entries in VM-anonymous classes and then
generating bytecode in those classes to laboriously `ldc` the entries,
the runtime can simply supply `Unsafe::defineAnonymousClass` with references
to its live objects. The relevant constant-pool entries in the newly-defined
VM-anonymous class are pre-linked to those objects, improving performance
and reducing footprint. In addition, this allows VM-anonymous classes to
refer to each other: Constant-pool entries in a class file are based on names.
They thus cannot refer to nameless VM-anonymous classes. A language runtime can,
however, easily track the live Class objects for its VM-anonymous classes and
supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's
constant pool entries to other VM-anonymous classes.

This extends the hidden classes to allow live objects to be injected
in a hidden class and loaded them via condy.

Details
-------

A new `Lookup::defineHiddenClassWithClassData` API takes additional
`classData` argument compared to `Lookup::defineHiddenClass`.
Class data can be method handles, lookup objects, arbitrary user objects
or collections of all of the above.

This method behaves as if calling `Lookup::defineHiddenClass` to define
a hidden class with a private static unnamed field that is initialized
with `classData` at the first instruction of the class initializer.

`MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
is a bootstrap method to load the class data of the given lookup's lookup class.
The hidden class will be initialized when `classData` method is called if
the hidden class has not been initialized.

For a class data containing more than one single element, libraries can
create their convenience method to load a single live object via condy.
We can reconsider if such a convenience method is needed in the future.

Frameworks sometimes want to dynamically create a hidden class (HC) and add it
it the lookup class nest and have HC to carry secrets hidden from that nest.
In this case, frameworks should not to use private static finals (in the HCs
they spin) to hold secrets because a nestmate of HC may obtain access to
such a private static final and observe the framework's secret.  It should use
condy.  In addition, we need to differentiate if a lookup object is created from
the original lookup class or created from teleporting e.g. `Lookup::in`
and `MethodHandles::privateLookupIn`.

This proposes to add a new `ORIGINAL` bit that is only set if the lookup
object is created by `MethodHandles::lookup` or by bootstrap method invocation.
The operations only apply to a Lookup object with original access are:
   - create method handles for caller-sensitve methods
   - obtain class data associated with the lookup class

No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which
ignores the ORIGINAL bit.


Compatibility Risks
-------------------

`Lookup::lookupModes` includes a new `ORIGINAL` bit.  Most lookup operations
ignore this original bit except creating method handles for caller-sensitive methods
that expects the lookup from the original lookup class.  Existing code  compares
the return value of `lookupModes` to be a fixed value may be impacted.   However
existing client has no need to expect a fixed value of lookup modes.
The incompatibility risk of this spec change is low.

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

Commit messages:
 - fix incorrect merge
 - more clean up
 - merge
 - Keep classDataAt package-private
 - Merge branch 'master' of https://github.com/openjdk/jdk into class-data
 - MethodHandles::hasFullPrivilegeAccess and Lookup::toString ignores ORIGINAL bit
 - revert some test changes
 - Merge branch 'master' of https://github.com/openjdk/jdk into class-data
 - Add ORIGINAL access
 - Merge branch 'master' of https://github.com/openjdk/jdk into class-data
 - ... and 5 more: https://git.openjdk.java.net/jdk/compare/2e19026d...5a3e29ba

Changes: https://git.openjdk.java.net/jdk/pull/1171/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1171&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8230501
  Stats: 970 lines in 16 files changed: 778 ins; 80 del; 112 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1171.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1171/head:pull/1171

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

From forax at univ-mlv.fr  Wed Nov 11 19:01:41 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 11 Nov 2020 20:01:41 +0100 (CET)
Subject: RFR: 8230501: Class data support for hidden classes
In-Reply-To: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
Message-ID: <1180961384.2348941.1605121301491.JavaMail.zimbra@u-pem.fr>

Hi Mandy,
maybe a stupid question but why this mechanism is limited to hidden classes ?

regards,
R?mi

----- Mail original -----
> De: "Mandy Chung" <mchung at openjdk.java.net>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot compiler" <hotspot-compiler-dev at openjdk.java.net>
> Envoy?: Mercredi 11 Novembre 2020 19:57:04
> Objet: RFR: 8230501: Class data support for hidden classes

> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live
> objects
> be shared between a hidden class and other classes.  A hidden class can load
> these live objects as dynamically-computed constants via this API.
> 
> Specdiff
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
> 
> With this class data support and hidden classes,
> `sun.misc.Unsafe::defineAnonymousClass`
> will be deprecated for removal.  Existing libraries should replace their
> calls to `sun.misc.Unsafe::defineAnonymousClass` with
> `Lookup::defineHiddenClass`
> or `Lookup::defineHiddenClassWithClassData`.
> 
> This patch also updates the implementation of lambda meta factory and
> `MemoryAccessVarHandleGenerator` to use class data.   No performance difference
> observed in the jdk.incubator.foreign microbenchmarks.   A side note:
> `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of
> JDK-8254162 but it helps validating the class data support.
> 
> Background
> ----------
> 
> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
> "Constant-pool patching" in the "Risks and Assumption" section.
> 
> A VM-anonymous class can be defined with its constant-pool entries already
> resolved to concrete values. This allows critical constants to be shared
> between a VM-anonymous class and the language runtime that defines it, and
> between multiple VM-anonymous classes. For example, a language runtime will
> often have `MethodHandle` objects in its address space that would be useful
> to newly-defined VM-anonymous classes. Instead of the runtime serializing
> the objects to constant-pool entries in VM-anonymous classes and then
> generating bytecode in those classes to laboriously `ldc` the entries,
> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
> to its live objects. The relevant constant-pool entries in the newly-defined
> VM-anonymous class are pre-linked to those objects, improving performance
> and reducing footprint. In addition, this allows VM-anonymous classes to
> refer to each other: Constant-pool entries in a class file are based on names.
> They thus cannot refer to nameless VM-anonymous classes. A language runtime can,
> however, easily track the live Class objects for its VM-anonymous classes and
> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's
> constant pool entries to other VM-anonymous classes.
> 
> This extends the hidden classes to allow live objects to be injected
> in a hidden class and loaded them via condy.
> 
> Details
> -------
> 
> A new `Lookup::defineHiddenClassWithClassData` API takes additional
> `classData` argument compared to `Lookup::defineHiddenClass`.
> Class data can be method handles, lookup objects, arbitrary user objects
> or collections of all of the above.
> 
> This method behaves as if calling `Lookup::defineHiddenClass` to define
> a hidden class with a private static unnamed field that is initialized
> with `classData` at the first instruction of the class initializer.
> 
> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
> is a bootstrap method to load the class data of the given lookup's lookup class.
> The hidden class will be initialized when `classData` method is called if
> the hidden class has not been initialized.
> 
> For a class data containing more than one single element, libraries can
> create their convenience method to load a single live object via condy.
> We can reconsider if such a convenience method is needed in the future.
> 
> Frameworks sometimes want to dynamically create a hidden class (HC) and add it
> it the lookup class nest and have HC to carry secrets hidden from that nest.
> In this case, frameworks should not to use private static finals (in the HCs
> they spin) to hold secrets because a nestmate of HC may obtain access to
> such a private static final and observe the framework's secret.  It should use
> condy.  In addition, we need to differentiate if a lookup object is created from
> the original lookup class or created from teleporting e.g. `Lookup::in`
> and `MethodHandles::privateLookupIn`.
> 
> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
> object is created by `MethodHandles::lookup` or by bootstrap method invocation.
> The operations only apply to a Lookup object with original access are:
>   - create method handles for caller-sensitve methods
>   - obtain class data associated with the lookup class
> 
> No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which
> ignores the ORIGINAL bit.
> 
> 
> Compatibility Risks
> -------------------
> 
> `Lookup::lookupModes` includes a new `ORIGINAL` bit.  Most lookup operations
> ignore this original bit except creating method handles for caller-sensitive
> methods
> that expects the lookup from the original lookup class.  Existing code  compares
> the return value of `lookupModes` to be a fixed value may be impacted.   However
> existing client has no need to expect a fixed value of lookup modes.
> The incompatibility risk of this spec change is low.
> 
> -------------
> 
> Commit messages:
> - fix incorrect merge
> - more clean up
> - merge
> - Keep classDataAt package-private
> - Merge branch 'master' of https://github.com/openjdk/jdk into class-data
> - MethodHandles::hasFullPrivilegeAccess and Lookup::toString ignores ORIGINAL
> bit
> - revert some test changes
> - Merge branch 'master' of https://github.com/openjdk/jdk into class-data
> - Add ORIGINAL access
> - Merge branch 'master' of https://github.com/openjdk/jdk into class-data
> - ... and 5 more: https://git.openjdk.java.net/jdk/compare/2e19026d...5a3e29ba
> 
> Changes: https://git.openjdk.java.net/jdk/pull/1171/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1171&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8230501
>  Stats: 970 lines in 16 files changed: 778 ins; 80 del; 112 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/1171.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1171/head:pull/1171
> 
> PR: https://git.openjdk.java.net/jdk/pull/1171

From alanb at openjdk.java.net  Wed Nov 11 19:14:58 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 11 Nov 2020 19:14:58 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v5]
In-Reply-To: <eLNP96JheIN15HOCR6-Bh5qgd-hTDKdi_KQClLBBPuY=.fad46a90-a5a4-4292-9082-78d3ac91e00a@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <eLNP96JheIN15HOCR6-Bh5qgd-hTDKdi_KQClLBBPuY=.fad46a90-a5a4-4292-9082-78d3ac91e00a@github.com>
Message-ID: <MBg_DrZt6xaxukQCru1IDGIBTBWESE9dWpY1cYyFxPw=.ed2adb68-519f-4508-b086-705a693a73e6@github.com>

On Wed, 11 Nov 2020 05:38:08 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> ?AccessorImpl object
>> 
>> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
>> 
>> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
>> 
>> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.
>
> Hui Shi 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.

src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java line 44:

> 42:     private DelegatingConstructorAccessorImpl parent;
> 43:     private int numInvocations;
> 44:     private int generated;

What is the reason for using an int? I remember there was a suggestion for three states but two states seems okay so curious why it was changed from boolean to int.
The restoring to 0 in the event of failure should probably be a volatile-write. Might be clearer to declare it as a volatile.

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

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

From mchung at openjdk.java.net  Wed Nov 11 19:24:54 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 11 Nov 2020 19:24:54 GMT
Subject: RFR: 8230501: Class data support for hidden classes
In-Reply-To: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
Message-ID: <JhV6c6pVUBaip5okFydxicMWjH-dfuCkTBJvh9t8kG8=.cfad11b8-c8a0-47fb-b83c-dcd5eef610e1@github.com>

On Wed, 11 Nov 2020 18:52:10 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects
> be shared between a hidden class and other classes.  A hidden class can load
> these live objects as dynamically-computed constants via this API.
> 
> Specdiff
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
> 
> With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass`
> will be deprecated for removal.  Existing libraries should replace their
> calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass`
> or `Lookup::defineHiddenClassWithClassData`.
> 
> This patch also updates the implementation of lambda meta factory and
> `MemoryAccessVarHandleGenerator` to use class data.   No performance difference
> observed in the jdk.incubator.foreign microbenchmarks.   A side note: 
> `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of 
> JDK-8254162 but it helps validating the class data support.
> 
> Background
> ----------
> 
> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
> "Constant-pool patching" in the "Risks and Assumption" section.
> 
> A VM-anonymous class can be defined with its constant-pool entries already
> resolved to concrete values. This allows critical constants to be shared
> between a VM-anonymous class and the language runtime that defines it, and
> between multiple VM-anonymous classes. For example, a language runtime will
> often have `MethodHandle` objects in its address space that would be useful
> to newly-defined VM-anonymous classes. Instead of the runtime serializing
> the objects to constant-pool entries in VM-anonymous classes and then
> generating bytecode in those classes to laboriously `ldc` the entries,
> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
> to its live objects. The relevant constant-pool entries in the newly-defined
> VM-anonymous class are pre-linked to those objects, improving performance
> and reducing footprint. In addition, this allows VM-anonymous classes to
> refer to each other: Constant-pool entries in a class file are based on names.
> They thus cannot refer to nameless VM-anonymous classes. A language runtime can,
> however, easily track the live Class objects for its VM-anonymous classes and
> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's
> constant pool entries to other VM-anonymous classes.
> 
> This extends the hidden classes to allow live objects to be injected
> in a hidden class and loaded them via condy.
> 
> Details
> -------
> 
> A new `Lookup::defineHiddenClassWithClassData` API takes additional
> `classData` argument compared to `Lookup::defineHiddenClass`.
> Class data can be method handles, lookup objects, arbitrary user objects
> or collections of all of the above.
> 
> This method behaves as if calling `Lookup::defineHiddenClass` to define
> a hidden class with a private static unnamed field that is initialized
> with `classData` at the first instruction of the class initializer.
> 
> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
> is a bootstrap method to load the class data of the given lookup's lookup class.
> The hidden class will be initialized when `classData` method is called if
> the hidden class has not been initialized.
> 
> For a class data containing more than one single element, libraries can
> create their convenience method to load a single live object via condy.
> We can reconsider if such a convenience method is needed in the future.
> 
> Frameworks sometimes want to dynamically create a hidden class (HC) and add it
> it the lookup class nest and have HC to carry secrets hidden from that nest.
> In this case, frameworks should not to use private static finals (in the HCs
> they spin) to hold secrets because a nestmate of HC may obtain access to
> such a private static final and observe the framework's secret.  It should use
> condy.  In addition, we need to differentiate if a lookup object is created from
> the original lookup class or created from teleporting e.g. `Lookup::in`
> and `MethodHandles::privateLookupIn`.
> 
> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
> object is created by `MethodHandles::lookup` or by bootstrap method invocation.
> The operations only apply to a Lookup object with original access are:
>    - create method handles for caller-sensitve methods
>    - obtain class data associated with the lookup class
> 
> No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which
> ignores the ORIGINAL bit.
> 
> 
> Compatibility Risks
> -------------------
> 
> `Lookup::lookupModes` includes a new `ORIGINAL` bit.  Most lookup operations
> ignore this original bit except creating method handles for caller-sensitive methods
> that expects the lookup from the original lookup class.  Existing code  compares
> the return value of `lookupModes` to be a fixed value may be impacted.   However
> existing client has no need to expect a fixed value of lookup modes.
> The incompatibility risk of this spec change is low.

Hi Remi,

One primary motivation of the class data support is to allow hidden classes to refer each other as they are nameless and cannot be referenced in the constant-pool entries.    I see the benefit of extending class data support to normal classes that can simplify the bytecode generated with fewer CP entries.   I want to keep the scope just as a follow up to JEP 371 Hidden Classes so that we can deprecate `Unsafe::defineAnonymousClass` for removal.   Soon we can remove the VM anonymous and constant pool patching code from HotSpot VM.

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

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

From github.com+51754783+coreyashford at openjdk.java.net  Wed Nov 11 21:33:58 2020
From: github.com+51754783+coreyashford at openjdk.java.net (Corey Ashford)
Date: Wed, 11 Nov 2020 21:33:58 GMT
Subject: Integrated: 8248188: Add IntrinsicCandidate and API for Base64
 decoding
In-Reply-To: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
References: <CiQAOE10qD_mpmXlg8vYvf-w0nbq0_JqEfJ_O76iWNA=.01c0d142-c101-4ed6-8d94-b536d2a736be@github.com>
Message-ID: <KutiSfsSrsHPYA2yHUZfsuWV-gSnRDeU5lQqCgl5skg=.be043335-9625-44a0-bc0f-ec730acf3a59@github.com>

On Tue, 22 Sep 2020 02:45:36 GMT, Corey Ashford <github.com+51754783+CoreyAshford at openjdk.org> wrote:

> This patch set encompasses the following commits:
> 
> - Adds a new HotSpot intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic.  The API is similar to the existing encodeBlock intrinsic.
> - Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation
> - Adds a Power64LE-specific implementation of the decodeBlock intrinsic.
> - Adds a JMH microbenchmark for both Base64 encoding and encoding.
> - Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

This pull request has now been integrated.

Changeset: ccb48b72
Author:    Corey Ashford <cjashfor at linux.vnet.ibm.com>
Committer: Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ccb48b72
Stats:     1905 lines in 25 files changed: 1878 ins; 4 del; 23 mod

8248188: Add IntrinsicCandidate and API for Base64 decoding

8248188: Add IntrinsicCandidate and API for Base64 decoding, add Power64LE intrinsic implementation.

This patch set encompasses the following commits:

Adds a new intrinsic candidate to the java.lang.Base64 class - decodeBlock(), and provides a flexible API for the intrinsic. The API is similar to the existing encodeBlock intrinsic.

Adds the code in HotSpot to check and martial the new intrinsic's arguments to the arch-specific intrinsic implementation.

Adds a Power64LE-specific implementation of the decodeBlock intrinsic.

Adds a JMH microbenchmark for both Base64 encoding and encoding.

Enhances the JTReg hotspot intrinsic "TestBase64.java" regression test to more fully test both decoding and encoding.

Reviewed-by: rriggs, mdoerr, kvn

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

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

From mchung at openjdk.java.net  Wed Nov 11 23:08:08 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 11 Nov 2020 23:08:08 GMT
Subject: RFR: 8256063: Module::getPackages on an unnamed module may return
 packages that are in a named module
Message-ID: <XPWHk4GD1jYRKb3uGzwyhgTVsHA6vjOoniCml4PyGgs=.1cf08390-ec9a-4c6e-9cbb-a6fb21b8a298@github.com>

If `Module::getPackages` is invoked on the unnamed module of a class loader
then the set of packages returned will include the packages of any named modules
that are defined to that class loader.  This is a spec and implementation bug.

`Module::getPackages` is changed to return the packages that are defined in
the unnamed module. 

CSR: https://bugs.openjdk.java.net/browse/JDK-8256242

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

Commit messages:
 - add new regression test
 - 8256063: Module::getPackages on an unnamed module may return packages that are in a named module

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

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

From hshi at openjdk.java.net  Thu Nov 12 04:25:57 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Thu, 12 Nov 2020 04:25:57 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v5]
In-Reply-To: <MBg_DrZt6xaxukQCru1IDGIBTBWESE9dWpY1cYyFxPw=.ed2adb68-519f-4508-b086-705a693a73e6@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <eLNP96JheIN15HOCR6-Bh5qgd-hTDKdi_KQClLBBPuY=.fad46a90-a5a4-4292-9082-78d3ac91e00a@github.com>
 <MBg_DrZt6xaxukQCru1IDGIBTBWESE9dWpY1cYyFxPw=.ed2adb68-519f-4508-b086-705a693a73e6@github.com>
Message-ID: <KQl2UYnDgp-cWGLQg5s03CUcXeB9glsD8LeW4ysVBtU=.f3cb68ba-fc70-4ae0-a493-66bd81806a86@github.com>

On Wed, 11 Nov 2020 19:12:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hui Shi 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.
>
> src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java line 44:
> 
>> 42:     private DelegatingConstructorAccessorImpl parent;
>> 43:     private int numInvocations;
>> 44:     private int generated;
> 
> What is the reason for using an int? I remember there was a suggestion for three states but two states seems okay so curious why it was changed from boolean to int.
> The restoring to 0 in the event of failure should probably be a volatile-write. Might be clearer to declare it as a volatile.

@AlanBateman 

> What is the reason for using an int? I remember there was a suggestion for three states but two states seems okay so curious why it was changed from boolean to int.

shipilev suggested not to use sub-word CAS, so change compareAndSetBoolean to compareAndSetInt. Change field "generated" from boolean to int doesn't increase object size (no extra byte/boolean to fold into same word).

> The restoring to 0 in the event of failure should probably be a volatile-write. Might be clearer to declare it as a volatile.
"generated" field  is read once and CAS once in this method. It doesn't likely cached and no visibiliy order required.

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

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

From alanb at openjdk.java.net  Thu Nov 12 07:35:55 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 12 Nov 2020 07:35:55 GMT
Subject: RFR: 8256063: Module::getPackages on an unnamed module may return
 packages that are in a named module
In-Reply-To: <XPWHk4GD1jYRKb3uGzwyhgTVsHA6vjOoniCml4PyGgs=.1cf08390-ec9a-4c6e-9cbb-a6fb21b8a298@github.com>
References: <XPWHk4GD1jYRKb3uGzwyhgTVsHA6vjOoniCml4PyGgs=.1cf08390-ec9a-4c6e-9cbb-a6fb21b8a298@github.com>
Message-ID: <lgG9QXvjEVjvL33a1CyhVydQUGythKEQ7Gal03j1QDI=.9608f830-57c2-4ed1-afb9-f598524d8ce7@github.com>

On Wed, 11 Nov 2020 23:02:49 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> If `Module::getPackages` is invoked on the unnamed module of a class loader
> then the set of packages returned will include the packages of any named modules
> that are defined to that class loader.  This is a spec and implementation bug.
> 
> `Module::getPackages` is changed to return the packages that are defined in
> the unnamed module. 
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8256242

Marked as reviewed by alanb (Reviewer).

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

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

From chegar at openjdk.java.net  Thu Nov 12 09:02:59 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 12 Nov 2020 09:02:59 GMT
Subject: RFR: 8256063: Module::getPackages on an unnamed module may return
 packages that are in a named module
In-Reply-To: <XPWHk4GD1jYRKb3uGzwyhgTVsHA6vjOoniCml4PyGgs=.1cf08390-ec9a-4c6e-9cbb-a6fb21b8a298@github.com>
References: <XPWHk4GD1jYRKb3uGzwyhgTVsHA6vjOoniCml4PyGgs=.1cf08390-ec9a-4c6e-9cbb-a6fb21b8a298@github.com>
Message-ID: <pBUz29mnJ_kKmFsqyn5xnHmsGUbqnZTAPnCzbzy6_LY=.de655c0b-4f0d-497c-a3eb-3ddb625a84c0@github.com>

On Wed, 11 Nov 2020 23:02:49 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> If `Module::getPackages` is invoked on the unnamed module of a class loader
> then the set of packages returned will include the packages of any named modules
> that are defined to that class loader.  This is a spec and implementation bug.
> 
> `Module::getPackages` is changed to return the packages that are defined in
> the unnamed module. 
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8256242

Marked as reviewed by chegar (Reviewer).

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

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

From mcimadamore at openjdk.java.net  Thu Nov 12 12:18:09 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 12 Nov 2020 12:18:09 GMT
Subject: RFR: 8254162: Implementation of Foreign-Memory Access API (Third
 Incubator) [v29]
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <BalYuM1UEfeBPfUBeI_jv6Bzmi6QeRhZsx7Aaj_k2RA=.11ddf880-19ce-471c-891d-f56c68654a8b@github.com>

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 36 commits:

 - Merge branch 'master' into 8254162
 - Invert condition in memory access var handle `withInvokeBehavior'
 - Merge branch 'master' into 8254162
 - Add more output in TestHandhsake.java
 - Further improve output of TestHandshake
 - Improve debugging output of TestHandhsake
 - Remove endianness-aware byte getter/setter in MemoryAccess
   Remove index-based version of byte getter/setter in MemoryAccess
 - Fix post-merge issues caused by 8219014
 - Merge branch 'master' into 8254162
 - Addess remaining feedback from @AlanBateman and @mrserb
 - ... and 26 more: https://git.openjdk.java.net/jdk/compare/ec08b3f2...0b81a39e

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

Changes: https://git.openjdk.java.net/jdk/pull/548/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=548&range=28
  Stats: 7600 lines in 82 files changed: 4791 ins; 1590 del; 1219 mod
  Patch: https://git.openjdk.java.net/jdk/pull/548.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/548/head:pull/548

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

From alanb at openjdk.java.net  Thu Nov 12 12:25:57 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 12 Nov 2020 12:25:57 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v5]
In-Reply-To: <KQl2UYnDgp-cWGLQg5s03CUcXeB9glsD8LeW4ysVBtU=.f3cb68ba-fc70-4ae0-a493-66bd81806a86@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <eLNP96JheIN15HOCR6-Bh5qgd-hTDKdi_KQClLBBPuY=.fad46a90-a5a4-4292-9082-78d3ac91e00a@github.com>
 <MBg_DrZt6xaxukQCru1IDGIBTBWESE9dWpY1cYyFxPw=.ed2adb68-519f-4508-b086-705a693a73e6@github.com>
 <KQl2UYnDgp-cWGLQg5s03CUcXeB9glsD8LeW4ysVBtU=.f3cb68ba-fc70-4ae0-a493-66bd81806a86@github.com>
Message-ID: <h9AcY1VriU3YGXGhXw7Z6I0cMeO90HMKY2K4JD2lYVI=.92c669d4-64fe-43b6-9949-c8aa89e0d47d@github.com>

On Thu, 12 Nov 2020 04:23:37 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/reflect/NativeConstructorAccessorImpl.java line 44:
>> 
>>> 42:     private DelegatingConstructorAccessorImpl parent;
>>> 43:     private int numInvocations;
>>> 44:     private int generated;
>> 
>> What is the reason for using an int? I remember there was a suggestion for three states but two states seems okay so curious why it was changed from boolean to int.
>> The restoring to 0 in the event of failure should probably be a volatile-write. Might be clearer to declare it as a volatile.
>
> @AlanBateman 
> 
>> What is the reason for using an int? I remember there was a suggestion for three states but two states seems okay so curious why it was changed from boolean to int.
> 
> shipilev suggested not to use sub-word CAS, so change compareAndSetBoolean to compareAndSetInt. Change field "generated" from boolean to int doesn't increase object size (no extra byte/boolean to fold into same word).
> 
>> The restoring to 0 in the event of failure should probably be a volatile-write. Might be clearer to declare it as a volatile.
> 
> "generated" field  is read once and CAS once in this method. It doesn't likely cached and no visibiliy order required.

okay, although I think it would be clearer for maintainers to declare it as volatile because it is set with CAS.

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

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

From hseigel at openjdk.java.net  Thu Nov 12 13:26:54 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 12 Nov 2020 13:26:54 GMT
Subject: Integrated: 8255787: Tag container tests that use cGroups with
 cgroups keyword
In-Reply-To: <KZXHhMlBA_blkP7RL4Rwsd_zo3HEYH7wBVBIQIF7Sp0=.3a9b1171-b985-46d6-b3bd-2d2dcb9259e8@github.com>
References: <KZXHhMlBA_blkP7RL4Rwsd_zo3HEYH7wBVBIQIF7Sp0=.3a9b1171-b985-46d6-b3bd-2d2dcb9259e8@github.com>
Message-ID: <HaZeU-cpIK3oM12Rms-TTRWN0hdbhiZOUuiaEBvOG4A=.a24752c2-ffab-45a1-8f89-ee6eee2308ef@github.com>

On Tue, 10 Nov 2020 21:24:25 GMT, Harold Seigel <hseigel at openjdk.org> wrote:

> Please review this small change to add a cgroups keyword to tests that use cgroups.  The fix was tested by running Mach5 container tests.

This pull request has now been integrated.

Changeset: 4df8abc2
Author:    Harold Seigel <hseigel at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/4df8abc2
Stats:     20 lines in 15 files changed: 15 ins; 0 del; 5 mod

8255787: Tag container tests that use cGroups with cgroups keyword

Reviewed-by: sspitsyn

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

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

From hseigel at openjdk.java.net  Thu Nov 12 13:30:57 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Thu, 12 Nov 2020 13:30:57 GMT
Subject: RFR: 8255787: Tag container tests that use cGroups with cgroups
 keyword
In-Reply-To: <ohQTnzM9m1AQ8JhLsLBD4zhow69sBnV6d3R_lqY3GU4=.d216bd3b-784f-4cab-a080-3d3298fac48a@github.com>
References: <KZXHhMlBA_blkP7RL4Rwsd_zo3HEYH7wBVBIQIF7Sp0=.3a9b1171-b985-46d6-b3bd-2d2dcb9259e8@github.com>
 <ohQTnzM9m1AQ8JhLsLBD4zhow69sBnV6d3R_lqY3GU4=.d216bd3b-784f-4cab-a080-3d3298fac48a@github.com>
Message-ID: <MwfG1v-bjvFShTC4_CEaL7zfHlBBD4BwQ4d3knK_-9A=.c50fa520-237b-4a1b-9c87-02817a4170dd@github.com>

On Wed, 11 Nov 2020 00:27:59 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Please review this small change to add a cgroups keyword to tests that use cgroups.  The fix was tested by running Mach5 container tests.
>
> Hi Harold,
> 
> The fix looks good.
> 
> Thanks,
> Serguei

Thanks Serguei!
Harold

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

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

From jvernee at openjdk.java.net  Thu Nov 12 15:13:58 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 Nov 2020 15:13:58 GMT
Subject: RFR: 8230501: Class data support for hidden classes
In-Reply-To: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
Message-ID: <RK2kaCseu0XFFWcOj_p2MdE8CmamFNXJu-629wq4mDo=.b430f397-d7c4-46f7-a385-0cf14621c5a9@github.com>

On Wed, 11 Nov 2020 18:52:10 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects
> be shared between a hidden class and other classes.  A hidden class can load
> these live objects as dynamically-computed constants via this API.
> 
> Specdiff
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
> 
> With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass`
> will be deprecated for removal.  Existing libraries should replace their
> calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass`
> or `Lookup::defineHiddenClassWithClassData`.
> 
> This patch also updates the implementation of lambda meta factory and
> `MemoryAccessVarHandleGenerator` to use class data.   No performance difference
> observed in the jdk.incubator.foreign microbenchmarks.   A side note: 
> `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of 
> JDK-8254162 but it helps validating the class data support.
> 
> Background
> ----------
> 
> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
> "Constant-pool patching" in the "Risks and Assumption" section.
> 
> A VM-anonymous class can be defined with its constant-pool entries already
> resolved to concrete values. This allows critical constants to be shared
> between a VM-anonymous class and the language runtime that defines it, and
> between multiple VM-anonymous classes. For example, a language runtime will
> often have `MethodHandle` objects in its address space that would be useful
> to newly-defined VM-anonymous classes. Instead of the runtime serializing
> the objects to constant-pool entries in VM-anonymous classes and then
> generating bytecode in those classes to laboriously `ldc` the entries,
> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
> to its live objects. The relevant constant-pool entries in the newly-defined
> VM-anonymous class are pre-linked to those objects, improving performance
> and reducing footprint. In addition, this allows VM-anonymous classes to
> refer to each other: Constant-pool entries in a class file are based on names.
> They thus cannot refer to nameless VM-anonymous classes. A language runtime can,
> however, easily track the live Class objects for its VM-anonymous classes and
> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's
> constant pool entries to other VM-anonymous classes.
> 
> This extends the hidden classes to allow live objects to be injected
> in a hidden class and loaded them via condy.
> 
> Details
> -------
> 
> A new `Lookup::defineHiddenClassWithClassData` API takes additional
> `classData` argument compared to `Lookup::defineHiddenClass`.
> Class data can be method handles, lookup objects, arbitrary user objects
> or collections of all of the above.
> 
> This method behaves as if calling `Lookup::defineHiddenClass` to define
> a hidden class with a private static unnamed field that is initialized
> with `classData` at the first instruction of the class initializer.
> 
> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
> is a bootstrap method to load the class data of the given lookup's lookup class.
> The hidden class will be initialized when `classData` method is called if
> the hidden class has not been initialized.
> 
> For a class data containing more than one single element, libraries can
> create their convenience method to load a single live object via condy.
> We can reconsider if such a convenience method is needed in the future.
> 
> Frameworks sometimes want to dynamically create a hidden class (HC) and add it
> it the lookup class nest and have HC to carry secrets hidden from that nest.
> In this case, frameworks should not to use private static finals (in the HCs
> they spin) to hold secrets because a nestmate of HC may obtain access to
> such a private static final and observe the framework's secret.  It should use
> condy.  In addition, we need to differentiate if a lookup object is created from
> the original lookup class or created from teleporting e.g. `Lookup::in`
> and `MethodHandles::privateLookupIn`.
> 
> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
> object is created by `MethodHandles::lookup` or by bootstrap method invocation.
> The operations only apply to a Lookup object with original access are:
>    - create method handles for caller-sensitve methods
>    - obtain class data associated with the lookup class
> 
> No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which
> ignores the ORIGINAL bit.
> 
> 
> Compatibility Risks
> -------------------
> 
> `Lookup::lookupModes` includes a new `ORIGINAL` bit.  Most lookup operations
> ignore this original bit except creating method handles for caller-sensitive methods
> that expects the lookup from the original lookup class.  Existing code  compares
> the return value of `lookupModes` to be a fixed value may be impacted.   However
> existing client has no need to expect a fixed value of lookup modes.
> The incompatibility risk of this spec change is low.

I took a look, since I'm interested in this API. Though, I can't really give a meaningful review for the access checking & ORIGINAL code changes.

src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 552:

> 550:                 Handle classDataBsm = new Handle(H_INVOKESTATIC, Type.getInternalName(MethodHandles.class), "classData",
> 551:                                                  classDataMType.descriptorString(), false);
> 552:                 ConstantDynamic implMethodCondy = new ConstantDynamic("implMethod", MethodHandle.class.descriptorString(), classDataBsm);

Could be moved to clinit?

test/jdk/java/lang/invoke/AccessControlTest.java line 183:

> 181:          * then no members, not even public members, will be accessible
> 182:          * i.e. all access modes are lost.
> 183:          * [A8] If the new lookup class, the old lookup class and the previous lookup class

Seems like a typo? There are 2 A8s now, and no A7, it seems.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 319:

> 317:      */
> 318:      public static <T> T classData(Lookup caller, String name, Class<T> type) throws IllegalAccessException {
> 319:          Objects.requireNonNull(name);

`name` is unused, but it can not be `null`. I think it would be good to add something about that to the javadoc. e.g.
     * @param name ignored (must not be {@code null})

FWIW, `classDataAt` doesn't check this. Should `caller` be checked as well?

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 403:

> 401: 
> 402:         @SuppressWarnings("unchecked")
> 403:         List<T> classData = List.class.cast(classdata);

Couldn't this call `classData` ?
Suggestion:

        @SuppressWarnings("unchecked")
        List<T> classData = classData(caller, name, List.class);
        if (classData == null) return null;

test/jdk/java/lang/invoke/MethodHandles/classData/ClassDataTest.java line 78:

> 76:     @Test
> 77:     public void noClassData() throws Throwable {
> 78:         assertTrue(MethodHandles.classData(LOOKUP, "dummy", Object.class) == null);

Could be:
Suggestion:

        assertNull(MethodHandles.classData(LOOKUP, "dummy", Object.class));

FWIW

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

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

From jvernee at openjdk.java.net  Thu Nov 12 15:21:59 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 12 Nov 2020 15:21:59 GMT
Subject: RFR: 8230501: Class data support for hidden classes
In-Reply-To: <RK2kaCseu0XFFWcOj_p2MdE8CmamFNXJu-629wq4mDo=.b430f397-d7c4-46f7-a385-0cf14621c5a9@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <RK2kaCseu0XFFWcOj_p2MdE8CmamFNXJu-629wq4mDo=.b430f397-d7c4-46f7-a385-0cf14621c5a9@github.com>
Message-ID: <wxZyd-divfwFv3aeqh2mtvKhPi6UCBFkhiUxIAP7roc=.e1d5fcf0-fadc-4802-b0a7-b0c6cf1ab523@github.com>

On Thu, 12 Nov 2020 15:11:03 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects
>> be shared between a hidden class and other classes.  A hidden class can load
>> these live objects as dynamically-computed constants via this API.
>> 
>> Specdiff
>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
>> 
>> With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass`
>> will be deprecated for removal.  Existing libraries should replace their
>> calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass`
>> or `Lookup::defineHiddenClassWithClassData`.
>> 
>> This patch also updates the implementation of lambda meta factory and
>> `MemoryAccessVarHandleGenerator` to use class data.   No performance difference
>> observed in the jdk.incubator.foreign microbenchmarks.   A side note: 
>> `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of 
>> JDK-8254162 but it helps validating the class data support.
>> 
>> Background
>> ----------
>> 
>> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
>> "Constant-pool patching" in the "Risks and Assumption" section.
>> 
>> A VM-anonymous class can be defined with its constant-pool entries already
>> resolved to concrete values. This allows critical constants to be shared
>> between a VM-anonymous class and the language runtime that defines it, and
>> between multiple VM-anonymous classes. For example, a language runtime will
>> often have `MethodHandle` objects in its address space that would be useful
>> to newly-defined VM-anonymous classes. Instead of the runtime serializing
>> the objects to constant-pool entries in VM-anonymous classes and then
>> generating bytecode in those classes to laboriously `ldc` the entries,
>> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
>> to its live objects. The relevant constant-pool entries in the newly-defined
>> VM-anonymous class are pre-linked to those objects, improving performance
>> and reducing footprint. In addition, this allows VM-anonymous classes to
>> refer to each other: Constant-pool entries in a class file are based on names.
>> They thus cannot refer to nameless VM-anonymous classes. A language runtime can,
>> however, easily track the live Class objects for its VM-anonymous classes and
>> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's
>> constant pool entries to other VM-anonymous classes.
>> 
>> This extends the hidden classes to allow live objects to be injected
>> in a hidden class and loaded them via condy.
>> 
>> Details
>> -------
>> 
>> A new `Lookup::defineHiddenClassWithClassData` API takes additional
>> `classData` argument compared to `Lookup::defineHiddenClass`.
>> Class data can be method handles, lookup objects, arbitrary user objects
>> or collections of all of the above.
>> 
>> This method behaves as if calling `Lookup::defineHiddenClass` to define
>> a hidden class with a private static unnamed field that is initialized
>> with `classData` at the first instruction of the class initializer.
>> 
>> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
>> is a bootstrap method to load the class data of the given lookup's lookup class.
>> The hidden class will be initialized when `classData` method is called if
>> the hidden class has not been initialized.
>> 
>> For a class data containing more than one single element, libraries can
>> create their convenience method to load a single live object via condy.
>> We can reconsider if such a convenience method is needed in the future.
>> 
>> Frameworks sometimes want to dynamically create a hidden class (HC) and add it
>> it the lookup class nest and have HC to carry secrets hidden from that nest.
>> In this case, frameworks should not to use private static finals (in the HCs
>> they spin) to hold secrets because a nestmate of HC may obtain access to
>> such a private static final and observe the framework's secret.  It should use
>> condy.  In addition, we need to differentiate if a lookup object is created from
>> the original lookup class or created from teleporting e.g. `Lookup::in`
>> and `MethodHandles::privateLookupIn`.
>> 
>> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
>> object is created by `MethodHandles::lookup` or by bootstrap method invocation.
>> The operations only apply to a Lookup object with original access are:
>>    - create method handles for caller-sensitve methods
>>    - obtain class data associated with the lookup class
>> 
>> No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which
>> ignores the ORIGINAL bit.
>> 
>> 
>> Compatibility Risks
>> -------------------
>> 
>> `Lookup::lookupModes` includes a new `ORIGINAL` bit.  Most lookup operations
>> ignore this original bit except creating method handles for caller-sensitive methods
>> that expects the lookup from the original lookup class.  Existing code  compares
>> the return value of `lookupModes` to be a fixed value may be impacted.   However
>> existing client has no need to expect a fixed value of lookup modes.
>> The incompatibility risk of this spec change is low.
>
> I took a look, since I'm interested in this API. Though, I can't really give a meaningful review for the access checking & ORIGINAL code changes.

Also (as mentioned offline), while it's possible with the current API to provide an `Object[]` as class data, and then load elements of that array into CP entries using downstream condys (e.g. by creating an array access var handle and then using that), I think it would be good to add a `getArrayElement` BSM for doing that to `ConstantBootstraps` to make this (seemingly) common case easier (maybe also a `getField` for loading instance fields).

I can file some RFEs, and would be happy to work on that.

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

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

From rriggs at openjdk.java.net  Thu Nov 12 15:25:01 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 12 Nov 2020 15:25:01 GMT
Subject: RFR: 8247781: Day periods support [v12]
In-Reply-To: <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
Message-ID: <yVqa9HYTETWD3jT8iB_le0HwuMeMnkNkT8Hln7Zmo9I=.0b1ccc6e-bfa5-4077-bfd2-659632158441@github.com>

On Tue, 10 Nov 2020 19:52:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a test case for user defined temporal field resolution with day period.

test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 877:

> 875:         try {
> 876:             dtf.parse("0 at night");
> 877:             throw new RuntimeException("DateTimeParseException should be thrown");

Testng has `Assert.fail(message)` for this case.

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

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

From rriggs at openjdk.java.net  Thu Nov 12 15:25:00 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 12 Nov 2020 15:25:00 GMT
Subject: RFR: 8247781: Day periods support [v11]
In-Reply-To: <lqmBJURhzGemQV8SxRqPuJMjtiR0BJjJmzJeqDLFE3Q=.b3ce354a-c663-490a-8ea6-daf5eefc16d7@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <lqmBJURhzGemQV8SxRqPuJMjtiR0BJjJmzJeqDLFE3Q=.b3ce354a-c663-490a-8ea6-daf5eefc16d7@github.com>
Message-ID: <Z1cjTmu9oi3nWjDDPp6IxJZz93dDmR6jsSSiroE-bJc=.053d3352-a793-43e2-8365-4421aee4ce4c@github.com>

On Tue, 10 Nov 2020 00:07:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarified 24:00 for "midnight" type in the spec. Some clean up.

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1483:

> 1481:      * exception is thrown and the day period is ignored.
> 1482:      * <p>
> 1483:      * "midnight" type allows both "00:00" as the start-of-day and "24:00" as the

Editorial:  Add "The " at the beginning of the sentence.

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

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

From rriggs at openjdk.java.net  Thu Nov 12 15:45:05 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 12 Nov 2020 15:45:05 GMT
Subject: RFR: 8247781: Day periods support [v12]
In-Reply-To: <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
Message-ID: <XFs7_BF2vg0EP9x0Bt6KYlmmTJsqRkPwwJYqyDz60yI=.b786b60e-55af-492f-85d7-96788096a337@github.com>

On Tue, 10 Nov 2020 19:52:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a test case for user defined temporal field resolution with day period.

Marked as reviewed by rriggs (Reviewer).

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

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

From rriggs at openjdk.java.net  Thu Nov 12 15:54:03 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 12 Nov 2020 15:54:03 GMT
Subject: RFR: 8256244: java/lang/ProcessHandle/PermissionTest.java fails with
 TestNG 7.1
Message-ID: <6afL9WKPLwWJ8RxWRi37UMpq0SPmf41zBUW-24zwiVM=.0f0fa9a9-7d13-47e9-b0f2-d17bbd6f2196@github.com>

TestNG 7.1 changed/corrected the way that @BeforeGroups are selected at runtime.
The test was depending on @BeforeGroups to initialize common security policy for a number of tests.
The tests are modified to individually setup the needed security manager and policy.

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

Commit messages:
 - 8256244: java/lang/ProcessHandle/PermissionTest.java fails with TestNG 7.1

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

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

From lancea at openjdk.java.net  Thu Nov 12 16:24:56 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 12 Nov 2020 16:24:56 GMT
Subject: RFR: 8256244: java/lang/ProcessHandle/PermissionTest.java fails
 with TestNG 7.1
In-Reply-To: <6afL9WKPLwWJ8RxWRi37UMpq0SPmf41zBUW-24zwiVM=.0f0fa9a9-7d13-47e9-b0f2-d17bbd6f2196@github.com>
References: <6afL9WKPLwWJ8RxWRi37UMpq0SPmf41zBUW-24zwiVM=.0f0fa9a9-7d13-47e9-b0f2-d17bbd6f2196@github.com>
Message-ID: <0jjaOtMVNJAf4mjL-P_ytje7jQgoajm6gbBjugqcEwc=.63c352a5-3b80-4dc0-b425-2934fbbb98b3@github.com>

On Thu, 12 Nov 2020 15:48:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> TestNG 7.1 changed/corrected the way that @BeforeGroups are selected at runtime.
> The test was depending on @BeforeGroups to initialize common security policy for a number of tests.
> The tests are modified to individually setup the needed security manager and policy.

Marked as reviewed by lancea (Reviewer).

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

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

From kartikohri13 at gmail.com  Thu Nov 12 16:37:28 2020
From: kartikohri13 at gmail.com (Kartik Ohri)
Date: Thu, 12 Nov 2020 22:07:28 +0530
Subject: Working on JDK-8072719
Message-ID: <CAASLQ4OMKrNLOzW=iqhGho3thPLtYGKsb7V3HwVaxepHYuGGsA@mail.gmail.com>

Hi!
I think that JDK-8072719
<https://bugs.openjdk.java.net/browse/JDK-8072719>, enhancing
checked collections to accept a Predicate, can be a valuable addition to
the JDK. I would like to start a discussion on whether this is a good fit
for the Collections framework and the JDK. If it is decided to include this
feature, I would be interested in contributing a patch for the same.
Thanks.
Regards,
Kartik

From mcimadamore at openjdk.java.net  Thu Nov 12 16:41:01 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 12 Nov 2020 16:41:01 GMT
Subject: Integrated: 8254162: Implementation of Foreign-Memory Access API
 (Third Incubator)
In-Reply-To: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
References: <IngRk57F78UN3yySfo6IABbdwnMogGNdYrykh_3em-c=.b81f7478-015c-45ed-9788-58d7519a2770@github.com>
Message-ID: <ygtX5fK5Lgdyv6EfS5WmCvsFUh6WiFNuhmHOfhATMcw=.d88ef00b-d1c2-4936-919e-c5605d552015@github.com>

On Wed, 7 Oct 2020 17:13:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch contains the changes associated with the third incubation round of the foreign memory access API incubation  (see JEP 393 [1]). This iteration focus on improving the usability of the API in 3 main ways:
> 
> * first, by providing a way to obtain truly *shared* segments, which can be accessed and closed concurrently from multiple threads
> * second, by providing a way to register a memory segment against a `Cleaner`, so as to have some (optional) guarantee that the memory will be deallocated, eventually
> * third, by not requiring users to dive deep into var handles when they first pick up the API; a new `MemoryAccess` class has been added, which defines several useful dereference routines; these are really just thin wrappers around memory access var handles, but they make the barrier of entry for using this API somewhat lower.
> 
> A big conceptual shift that comes with this API refresh is that the role of `MemorySegment` and `MemoryAddress` is not the same as it used to be; it used to be the case that a memory address could (sometimes, not always) have a back link to the memory segment which originated it; additionally, memory access var handles used `MemoryAddress` as a basic unit of dereference.
> 
> This has all changed as per this API refresh;  now a `MemoryAddress` is just a dumb carrier which wraps a pair of object/long addressing coordinates; `MemorySegment` has become the star of the show, as far as dereferencing memory is concerned. You cannot dereference memory if you don't have a segment. This improves usability in a number of ways - first, it is a lot easier to wrap native addresses (`long`, essentially) into a `MemoryAddress`; secondly, it is crystal clear what a client has to do in order to dereference memory: if a client has a segment, it can use that; otherwise, if the client only has an address, it will have to create a segment *unsafely* (this can be done by calling `MemoryAddress::asSegmentRestricted`).
> 
> A list of the API, implementation and test changes is provided below. If  you have any questions, or need more detailed explanations, I (and the  rest of the Panama team) will be happy to point at existing discussions,  and/or to provide the feedback required. 
> 
> A big thank to Erik Osterlund, Vladimir Ivanov and David Holmes, without whom the work on shared memory segment would not have been possible; also I'd like to thank Paul Sandoz, whose insights on API design have been very helpful in this journey.
> 
> Thanks 
> Maurizio 
> 
> Javadoc: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff: 
> 
> http://cr.openjdk.java.net/~mcimadamore/8254162_v1/specdiff/jdk/incubator/foreign/package-summary.html
> 
> CSR: 
> 
> https://bugs.openjdk.java.net/browse/JDK-8254163
> 
> 
> 
> ### API Changes
> 
> * `MemorySegment`
>   * drop factory for restricted segment (this has been moved to `MemoryAddress`, see below)
>   * added a no-arg factory for a native restricted segment representing entire native heap
>   * rename `withOwnerThread` to `handoff`
>   * add new `share` method, to create shared segments
>   * add new `registerCleaner` method, to register a segment against a cleaner
>   * add more helpers to create arrays from a segment e.g. `toIntArray`
>   * add some `asSlice` overloads (to make up for the fact that now segments are more frequently used as cursors)
>   * rename `baseAddress` to `address` (so that `MemorySegment` can implement `Addressable`)
> * `MemoryAddress`
>   * drop `segment` accessor
>   * drop `rebase` method and replace it with `segmentOffset` which returns the offset (a `long`) of this address relative to a given segment
> * `MemoryAccess`
>   * New class supporting several static dereference helpers; the helpers are organized by carrier and access mode, where a carrier is one of the usual suspect (a Java primitive, minus `boolean`); the access mode can be simple (e.g. access base address of given segment), or indexed, in which case the accessor takes a segment and either a low-level byte offset,or a high level logical index. The classification is reflected in the naming scheme (e.g. `getByte` vs. `getByteAtOffset` vs `getByteAtIndex`).
> * `MemoryHandles`
>   * drop `withOffset` combinator
>   * drop `withStride` combinator
>   * the basic memory access handle factory now returns a var handle which takes a `MemorySegment` and a `long` - from which it is easy to derive all the other handles using plain var handle combinators.
> * `Addressable`
>   * This is a new interface which is attached to entities which can be projected to a `MemoryAddress`. For now, both `MemoryAddress` and `MemorySegment` implement it; we have plans, with JEP 389 [2] to add more implementations. Clients can largely ignore this interface, which comes in really handy when defining native bindings with tools like `jextract`.
> * `MemoryLayouts`
>   * A new layout, for machine addresses, has been added to the mix.
> 
> 
> 
> ### Implementation changes
> 
> There are two main things to discuss here: support for shared segments, and the general simplification of the memory access var handle support.
> 
> #### Shared segments
> 
> The support for shared segments cuts in pretty deep in the VM. Support for shared segments is notoriously hard to achieve, at least in a way that guarantees optimal access performances. This is caused by the fact that, if a segment is shared, it would be possible for a thread to close it while another is accessing it.
> 
> After considering several options (see [3]), we zeroed onto an approach which is inspired by an happy idea that Andrew Haley had (and that he reminded me of at this year OpenJDK committer workshop - thanks!). The idea is that if we could *freeze* the world (e.g. with a GC pause), while a segment is closed, we could then prevent segments from being accessed concurrently to a close operation. For this to work, it  is crucial that no GC safepoints can occur between a segment liveness check and the access itself (otherwise it would be possible for the accessing thread to stop just right before an unsafe call). It also relies on the fact that hotspot/C2 should not be able to propagate loads across safepoints.
> 
> Sadly, none of these conditions seems to be valid in the current implementation, so we needed to resort to a bit of creativity. First, we noted that, if we could mark so called *scoped* method with an annotation, it would be very simply to check as to whether a thread was in the middle of a scoped method when we stopped the world for a close operation (btw, instead of stopping the world, we do a much more efficient, thread-local polling, thanks to JEP 312 [4]).
> 
> The question is, then, once we detect that a thread is accessing the very segment we're about to close, what should happen? We first experimented with a solution which would install an *asynchronous* exception on the accessing thread, thus making it fail. This solution has some desirable properties, in that a `close` operation always succeeds. Unfortunately the machinery for async exceptions is a bit fragile (e.g. not all the code in hotspot checks for async exceptions); to minimize risks, we decided to revert to a simpler strategy, where `close` might fail when it finds that another thread is accessing the segment being closed.
> 
> As written in the javadoc, this doesn't mean that clients should just catch and try again; an exception on `close` is a bug in the user code, likely arising from lack of synchronization, and should be treated as such.
> 
> In terms of gritty implementation, we needed to centralize memory access routines in a single place, so that we could have a set of routines closely mimicking the primitives exposed by `Unsafe` but which, in addition, also provided a liveness check. This way we could mark all these routines with the special `@Scoped` annotation, which tells the VM that something important is going on.
> 
> To achieve this, we created a new (autogenerated) class, called `ScopedMemoryAccess`. This class contains all the main memory access primitives (including bulk access, like `copyMemory`, or `setMemory`), and accepts, in addition to the access coordinates, also a scope object, which is tested before access. A reachability fence is also thrown in the mix to make sure that the scope is kept alive during access (which is important when registering segments against cleaners).
> 
> Of course, to make memory access safe, memory access var handles, byte buffer var handles, and byte buffer API should use the new `ScopedMemoryAccess` class instead of unsafe, so that a liveness check can be triggered (in case a scope is present).
> 
> `ScopedMemoryAccess` has a `closeScope` method, which initiates the thread-local handshakes, and returns `true` if the handshake completed successfully.
> 
> The implementation of `MemoryScope` (now significantly simplified from what we had before), has two implementations, one for confined segments and one for shared segments; the main difference between the two is what happens when the scope is closed; a confined segment sets a boolean flag to false, and returns, whereas a shared segment goes into a `CLOSING` state, then starts the handshake, and then updates the state again, to either `CLOSED` or `ALIVE` depending on whether the handshake was successful or not. Note that when a shared segment is in the `CLOSING` state, `MemorySegment::isAlive` will still return `true`, while the liveness check upon memory access will fail.
> 
> #### Memory access var handles overhaul
> 
> The key realization here was that if all memory access var handles took a coordinate pair of `MemorySegment` and `long`, all other access types could be derived from this basic var handle form.
> 
> This allowed us to remove the on-the-fly var handle generation, and to simply derive structural access var handles (such as those obtained by calling `MemoryLayout::varHandle`) using *plain* var handle combinators, so that e.g. additional offset is injected into a base memory access var handle.
> 
> This also helped in simplifying the implementation by removing the special `withStride` and `withOffset` combinators, which previously needed low-level access on the innards of the memory access var handle. All that code is now gone.
> 
> #### Test changes
> 
> Not much to see here - most of the tests needed to be updated because of the API changes. Some were beefed up (like the array test, since now segments can be projected into many different kinds of arrays). A test has been added to test the `Cleaner` functionality, and another stress test has been added for shared segments (`TestHandshake`). Some of the microbenchmarks also needed some tweaks - and some of them were also updated to also test performance in the shared segment case.
> 
> [1] - https://openjdk.java.net/jeps/393
> [2] - https://openjdk.java.net/jeps/389
> [3] - https://mail.openjdk.java.net/pipermail/panama-dev/2020-May/009004.html
> [4] - https://openjdk.java.net/jeps/312

This pull request has now been integrated.

Changeset: 3e70aac5
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3e70aac5
Stats:     7600 lines in 82 files changed: 4791 ins; 1590 del; 1219 mod

8254162: Implementation of Foreign-Memory Access API (Third Incubator)

Reviewed-by: erikj, psandoz, alanb

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

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

From iignatyev at openjdk.java.net  Thu Nov 12 16:50:59 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Thu, 12 Nov 2020 16:50:59 GMT
Subject: RFR: 8256244: java/lang/ProcessHandle/PermissionTest.java fails
 with TestNG 7.1
In-Reply-To: <6afL9WKPLwWJ8RxWRi37UMpq0SPmf41zBUW-24zwiVM=.0f0fa9a9-7d13-47e9-b0f2-d17bbd6f2196@github.com>
References: <6afL9WKPLwWJ8RxWRi37UMpq0SPmf41zBUW-24zwiVM=.0f0fa9a9-7d13-47e9-b0f2-d17bbd6f2196@github.com>
Message-ID: <BARoKYgusKjjfZFhEXXi1hHZbv69tS0c8REon_zIbxI=.02673a0e-fc21-4dd5-88d9-670357ee1d76@github.com>

On Thu, 12 Nov 2020 15:48:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> TestNG 7.1 changed/corrected the way that @BeforeGroups are selected at runtime.
> The test was depending on @BeforeGroups to initialize common security policy for a number of tests.
> The tests are modified to individually setup the needed security manager and policy.

Marked as reviewed by iignatyev (Reviewer).

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

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

From scolebourne at openjdk.java.net  Thu Nov 12 17:07:05 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Thu, 12 Nov 2020 17:07:05 GMT
Subject: RFR: 8247781: Day periods support [v12]
In-Reply-To: <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
Message-ID: <QmM8ovyIghPebG9hVAeHvTSBfeRPt-noT9AF6tvv6Rs=.3d4f6cdd-af86-4342-abf1-9672b752e6bf@github.com>

On Tue, 10 Nov 2020 19:52:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a test case for user defined temporal field resolution with day period.

src/java.base/share/classes/java/time/format/Parsed.java line 550:

> 548:                     long midpoint = dayPeriod.mid();
> 549:                     fieldValues.put(HOUR_OF_DAY, midpoint / 60);
> 550:                     fieldValues.put(MINUTE_OF_HOUR, midpoint % 60);

Set `dayPeriod = null` here, as it has been successfully used.

src/java.base/share/classes/java/time/format/Parsed.java line 502:

> 500:                 HOUR_OF_AMPM.checkValidValue(hoap);
> 501:             }
> 502:             if (dayPeriod.includes((hoap % 24 + 12) * 60)) {

Pretty sure the 24 should be 12.

Also, it should use `Math.floorMod()` to handle `HOUR_OF_AMPM = -1` (which is 11 o'clock).

Also, this doesn't take into account minutes. So if the day period rule is afternoon1 to 18:30 and evening1 after 18:30, and the input is `HOUR_OF_AMPM = 6, MINUTE_OF_HOUR = 45`, this will fail to resolve,

Something like this should work (no need for `updateCheckDayPeriodConflict`):

    long hoap = fieldValues.remove(HOUR_OF_AMPM);
    if (resolverStyle == ResolverStyle.LENIENT) {
      HOUR_OF_AMPM.checkValidValue(hoap);
    }
    Long mohObj = fieldValues.get(MINUTE_OF_HOUR);
    long moh = mohObj != null ? Math.floorMod(mohObj, 60) : 0;
    long excessHours = dayPeriod.includes(Math.floorMod(hoap, 12) + 12 * 60 + moh ? 12 : 0;
    long hod = Math.addExact(hoap, excessHours);
    updateCheckConflict(HOUR_OF_AMPM, HOUR_OF_DAY, hod);
    dayPeriod = null;

src/java.base/share/classes/java/time/format/Parsed.java line 546:

> 544: 
> 545:             // Set the hour-of-day, if not exist and not in STRICT, to the mid point of the day period or am/pm.
> 546:             if (!fieldValues.containsKey(HOUR_OF_DAY) && resolverStyle != ResolverStyle.STRICT) {

Since this logic replaces both `HOUR_OF_DAY` and `MINUTE_OF_HOUR` I think it should only be invoked if both do not exist. Beyond that, it doesn't really make sense to do this logic if second/sub-second are present. Thus, it needs to check all four fields and can then directly set the time.

    if (!fieldValues.containsKey(HOUR_OF_DAY) && 
        !fieldValues.containsKey(MINUTE_OF_HOUR) && 
        !fieldValues.containsKey(SECOND_OF_MINUTE) && 
        !fieldValues.containsKey(NANO_OF_SECOND) && 
        resolverStyle != ResolverStyle.STRICT) {

      if (dayPeriod != null) {
        long midpoint = dayPeriod.mid();
        resolveTime(midpoint / 60, midpoint % 60, 0, 0);
        dayPeriod = null;
      } else if (fieldValues.containsKey(AMPM_OF_DAY)) {
        long ap = fieldValues.remove(AMPM_OF_DAY);
        if (resolverStyle == ResolverStyle.LENIENT) {
          resolveTime(Math.addExact(Math.multiplyExact(ap, 12), 6), 0, 0, 0);
        } else {  // SMART
          AMPM_OF_DAY.checkValidValue(ap);
          resolveTime(ap * 12 + 6, 0, 0, 0);
    }

src/java.base/share/classes/java/time/format/Parsed.java line 568:

> 566:                 if (dayPeriod != null) {
> 567:                     // Check whether the hod is within the day period
> 568:                     updateCheckDayPeriodConflict(HOUR_OF_DAY, hod);

With the other changes, this is the only use of this method and it can therefore be simplified (no need to check for conflicts, just whether it matches the day period).

test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 778:

> 776:                 {"h B", ResolverStyle.SMART, "59 in the morning", 11},
> 777: 
> 778:                 {"H B", ResolverStyle.LENIENT, "47 at night", 23},

This test should be split in two - smart (fails) and lenient (succeeds). The lenient tests should ensure that `p.query(DateTimeFormatter.parsedExcessDays())` returns the expected number of excess days. 

I'd also add a test for a negative value such as "-2 at night"

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

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

From rriggs at openjdk.java.net  Thu Nov 12 17:08:56 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 12 Nov 2020 17:08:56 GMT
Subject: Integrated: 8256244: java/lang/ProcessHandle/PermissionTest.java
 fails with TestNG 7.1
In-Reply-To: <6afL9WKPLwWJ8RxWRi37UMpq0SPmf41zBUW-24zwiVM=.0f0fa9a9-7d13-47e9-b0f2-d17bbd6f2196@github.com>
References: <6afL9WKPLwWJ8RxWRi37UMpq0SPmf41zBUW-24zwiVM=.0f0fa9a9-7d13-47e9-b0f2-d17bbd6f2196@github.com>
Message-ID: <FGJkfYJAcSeXJ0W8qFBAdPP9EJvxjPIsDl_wwz-oikc=.0d9fdd34-a9cb-4710-9d50-470a5e8653e7@github.com>

On Thu, 12 Nov 2020 15:48:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> TestNG 7.1 changed/corrected the way that @BeforeGroups are selected at runtime.
> The test was depending on @BeforeGroups to initialize common security policy for a number of tests.
> The tests are modified to individually setup the needed security manager and policy.

This pull request has now been integrated.

Changeset: b5a9c92b
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b5a9c92b
Stats:     19 lines in 1 file changed: 9 ins; 1 del; 9 mod

8256244: java/lang/ProcessHandle/PermissionTest.java fails with TestNG 7.1

Reviewed-by: lancea, iignatyev

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

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

From asemenyuk at openjdk.java.net  Thu Nov 12 17:23:57 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 12 Nov 2020 17:23:57 GMT
Subject: RFR: 8255947: [macos] Signed macOS jpackage app doesn't filter
 spurious '-psn' argument
In-Reply-To: <gA_HFoOHfdrbfrRXQG6Jvn7M_tfns2G7WvzUIS_afg0=.ea64b8e8-1afd-4884-99b4-cb84333dbbf3@github.com>
References: <gA_HFoOHfdrbfrRXQG6Jvn7M_tfns2G7WvzUIS_afg0=.ea64b8e8-1afd-4884-99b4-cb84333dbbf3@github.com>
Message-ID: <gUCULstfPgK4Tniba6342NguungJ-WlCIoHHYzQ3ZGM=.f5de5051-4afe-4f40-b794-4958b4bafbb7@github.com>

On Wed, 11 Nov 2020 04:28:02 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This is regression from JDK-8242302 and for some reason removing -psn argument code was removed during refactoring. Fixed be adding removing -psn argument back. Also, test was added to test this functionality.

src/jdk.jpackage/macosx/native/common/MacSysInfo.cpp line 90:

> 88:         }
> 89:         result.push_back(argv[i]);
> 90:     }

I'd suggest to use C++ here:
Suggestion:

    const tstring psnArgPrefix = "-psn_";
    for (int i = progNameMode == ExcludeProgramName ? 1 : 0; i < argc; i++) {
        const tstring arg = argv[i];
        if (!tstrings::startsWith(arg, psnArgPrefix)) {
            result.push_back(arg);
        }
    }

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

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

From mcimadamore at openjdk.java.net  Thu Nov 12 17:58:21 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 12 Nov 2020 17:58:21 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v19]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <pa1u0FeI8fgINopky26awFeSmNP_cFvGWvEkgwZJqjU=.b9c2eda2-6467-41e0-a37a-ec09e564d089@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 78 commits:

 - Merge branch 'master' into 8254231_linker
 - Merge pull request #7 from JornVernee/Additional_Review_Comments
   
   Additional review comments
 - Revert System.java changes
 - Set copyright year for added files to 2020
 - Check result of AttachCurrentThread
 - Sort includes alphabetically
 - Relax ret_addr_offset() assert
 - Extra space after if
 - remove excessive asserts in ProgrammableInvoker::invoke_native
 - Remove os::is_MP() check
 - ... and 68 more: https://git.openjdk.java.net/jdk/compare/3e70aac5...56099dac

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

Changes: https://git.openjdk.java.net/jdk/pull/634/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=18
  Stats: 67452 lines in 213 files changed: 67277 ins; 79 del; 96 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

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

From mcimadamore at openjdk.java.net  Thu Nov 12 18:07:23 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 12 Nov 2020 18:07:23 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v20]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <JCyebuMBOCLdt3wgh-mYq-90nQQriCgwg6VwR4G6ItY=.5ef5e87b-a5d7-4622-8a9c-cb4eaa1bdeb2@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

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

  Fix whitespaces

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/56099dac..e3d62ee7

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=19
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=18-19

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From mcimadamore at openjdk.java.net  Thu Nov 12 18:07:23 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 12 Nov 2020 18:07:23 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v18]
In-Reply-To: <JJ6qdIZFLnnE1yqOVCPu5xEDWEKNiaVPQXgh4DH8Fhk=.7daf2599-efa9-4a47-aa7d-e52c58e2b6cf@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <AK-p2u_9FlJzupbJzCMvC55iWN_5j5lNwy8q1SXGObI=.615fee87-b80b-4bcf-8b6e-33c758eb4da4@github.com>
 <JJ6qdIZFLnnE1yqOVCPu5xEDWEKNiaVPQXgh4DH8Fhk=.7daf2599-efa9-4a47-aa7d-e52c58e2b6cf@github.com>
Message-ID: <0NZr5QkMAOUHtmbqSuJA8ZUHPZR6D3sO5pQvBneCbf0=.70e86f1c-0217-47b0-bd53-bdb4fa488800@github.com>

On Wed, 11 Nov 2020 14:18:33 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with 10 additional commits since the last revision:
>> 
>>  - Merge pull request #7 from JornVernee/Additional_Review_Comments
>>    
>>    Additional review comments
>>  - Revert System.java changes
>>  - Set copyright year for added files to 2020
>>  - Check result of AttachCurrentThread
>>  - Sort includes alphabetically
>>  - Relax ret_addr_offset() assert
>>  - Extra space after if
>>  - remove excessive asserts in ProgrammableInvoker::invoke_native
>>  - Remove os::is_MP() check
>>  - remove blank line in thread.hpp
>
> I made a pass over hotspot code. Overall, it looks good. Some comments follow.

I've just merged against master - which now contains the foreign memory API changes that this JEP depends on. I believe reviewing the changes should now be easier, as only the relevant changes should be presented in the "File Changed" tab.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From mchung at openjdk.java.net  Thu Nov 12 19:22:03 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 12 Nov 2020 19:22:03 GMT
Subject: RFR: 8230501: Class data support for hidden classes
In-Reply-To: <RK2kaCseu0XFFWcOj_p2MdE8CmamFNXJu-629wq4mDo=.b430f397-d7c4-46f7-a385-0cf14621c5a9@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <RK2kaCseu0XFFWcOj_p2MdE8CmamFNXJu-629wq4mDo=.b430f397-d7c4-46f7-a385-0cf14621c5a9@github.com>
Message-ID: <I8xRQ69a6QwUoHwHTeOV7ciO3GhB9EtQmI6FsaAo3yQ=.e4e7e47d-eecc-45c5-ae8b-325fa53df215@github.com>

On Thu, 12 Nov 2020 14:18:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects
>> be shared between a hidden class and other classes.  A hidden class can load
>> these live objects as dynamically-computed constants via this API.
>> 
>> Specdiff
>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
>> 
>> With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass`
>> will be deprecated for removal.  Existing libraries should replace their
>> calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass`
>> or `Lookup::defineHiddenClassWithClassData`.
>> 
>> This patch also updates the implementation of lambda meta factory and
>> `MemoryAccessVarHandleGenerator` to use class data.   No performance difference
>> observed in the jdk.incubator.foreign microbenchmarks.   A side note: 
>> `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of 
>> JDK-8254162 but it helps validating the class data support.
>> 
>> Background
>> ----------
>> 
>> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
>> "Constant-pool patching" in the "Risks and Assumption" section.
>> 
>> A VM-anonymous class can be defined with its constant-pool entries already
>> resolved to concrete values. This allows critical constants to be shared
>> between a VM-anonymous class and the language runtime that defines it, and
>> between multiple VM-anonymous classes. For example, a language runtime will
>> often have `MethodHandle` objects in its address space that would be useful
>> to newly-defined VM-anonymous classes. Instead of the runtime serializing
>> the objects to constant-pool entries in VM-anonymous classes and then
>> generating bytecode in those classes to laboriously `ldc` the entries,
>> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
>> to its live objects. The relevant constant-pool entries in the newly-defined
>> VM-anonymous class are pre-linked to those objects, improving performance
>> and reducing footprint. In addition, this allows VM-anonymous classes to
>> refer to each other: Constant-pool entries in a class file are based on names.
>> They thus cannot refer to nameless VM-anonymous classes. A language runtime can,
>> however, easily track the live Class objects for its VM-anonymous classes and
>> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's
>> constant pool entries to other VM-anonymous classes.
>> 
>> This extends the hidden classes to allow live objects to be injected
>> in a hidden class and loaded them via condy.
>> 
>> Details
>> -------
>> 
>> A new `Lookup::defineHiddenClassWithClassData` API takes additional
>> `classData` argument compared to `Lookup::defineHiddenClass`.
>> Class data can be method handles, lookup objects, arbitrary user objects
>> or collections of all of the above.
>> 
>> This method behaves as if calling `Lookup::defineHiddenClass` to define
>> a hidden class with a private static unnamed field that is initialized
>> with `classData` at the first instruction of the class initializer.
>> 
>> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
>> is a bootstrap method to load the class data of the given lookup's lookup class.
>> The hidden class will be initialized when `classData` method is called if
>> the hidden class has not been initialized.
>> 
>> For a class data containing more than one single element, libraries can
>> create their convenience method to load a single live object via condy.
>> We can reconsider if such a convenience method is needed in the future.
>> 
>> Frameworks sometimes want to dynamically create a hidden class (HC) and add it
>> it the lookup class nest and have HC to carry secrets hidden from that nest.
>> In this case, frameworks should not to use private static finals (in the HCs
>> they spin) to hold secrets because a nestmate of HC may obtain access to
>> such a private static final and observe the framework's secret.  It should use
>> condy.  In addition, we need to differentiate if a lookup object is created from
>> the original lookup class or created from teleporting e.g. `Lookup::in`
>> and `MethodHandles::privateLookupIn`.
>> 
>> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
>> object is created by `MethodHandles::lookup` or by bootstrap method invocation.
>> The operations only apply to a Lookup object with original access are:
>>    - create method handles for caller-sensitve methods
>>    - obtain class data associated with the lookup class
>> 
>> No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which
>> ignores the ORIGINAL bit.
>> 
>> 
>> Compatibility Risks
>> -------------------
>> 
>> `Lookup::lookupModes` includes a new `ORIGINAL` bit.  Most lookup operations
>> ignore this original bit except creating method handles for caller-sensitive methods
>> that expects the lookup from the original lookup class.  Existing code  compares
>> the return value of `lookupModes` to be a fixed value may be impacted.   However
>> existing client has no need to expect a fixed value of lookup modes.
>> The incompatibility risk of this spec change is low.
>
> src/java.base/share/classes/java/lang/invoke/InnerClassLambdaMetafactory.java line 552:
> 
>> 550:                 Handle classDataBsm = new Handle(H_INVOKESTATIC, Type.getInternalName(MethodHandles.class), "classData",
>> 551:                                                  classDataMType.descriptorString(), false);
>> 552:                 ConstantDynamic implMethodCondy = new ConstantDynamic("implMethod", MethodHandle.class.descriptorString(), classDataBsm);
> 
> Could be moved to clinit?

Good suggestion.  Thanks.

> test/jdk/java/lang/invoke/AccessControlTest.java line 183:
> 
>> 181:          * then no members, not even public members, will be accessible
>> 182:          * i.e. all access modes are lost.
>> 183:          * [A8] If the new lookup class, the old lookup class and the previous lookup class
> 
> Seems like a typo? There are 2 A8s now, and no A7, it seems.

Yes, it's a typo.  Fixed.

> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 319:
> 
>> 317:      */
>> 318:      public static <T> T classData(Lookup caller, String name, Class<T> type) throws IllegalAccessException {
>> 319:          Objects.requireNonNull(name);
> 
> `name` is unused, but it can not be `null`. I think it would be good to add something about that to the javadoc. e.g.
>      * @param name ignored (must not be {@code null})
> 
> FWIW, `classDataAt` doesn't check this. Should `caller` be checked as well?

Good catch.  `name` argument is unused and should not be checked.  I added `@throws NullPointerException if {@code caller} or {@code type} argument is {@code null}`. 

`caller.lookupModes()` will throw NPE if it's null.

> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 403:
> 
>> 401: 
>> 402:         @SuppressWarnings("unchecked")
>> 403:         List<T> classData = List.class.cast(classdata);
> 
> Couldn't this call `classData` ?
> Suggestion:
> 
>         @SuppressWarnings("unchecked")
>         List<T> classData = classData(caller, name, List.class);
>         if (classData == null) return null;

Fixed.

> test/jdk/java/lang/invoke/MethodHandles/classData/ClassDataTest.java line 78:
> 
>> 76:     @Test
>> 77:     public void noClassData() throws Throwable {
>> 78:         assertTrue(MethodHandles.classData(LOOKUP, "dummy", Object.class) == null);
> 
> Could be:
> Suggestion:
> 
>         assertNull(MethodHandles.classData(LOOKUP, "dummy", Object.class));
> 
> FWIW

OK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1171

From naoto at openjdk.java.net  Thu Nov 12 20:03:14 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 12 Nov 2020 20:03:14 GMT
Subject: RFR: 8247781: Day periods support [v13]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <tm8uVtpgEhGiOg5qKP86M_OUEgW8hkq2zvQr9EALtY8=.2aed5272-0d52-43e4-a2e0-e534f0e22a20@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Addressed the following comments:
  - https://github.com/openjdk/jdk/pull/938#discussion_r522185469
  - https://github.com/openjdk/jdk/pull/938#discussion_r522187931
  - https://github.com/openjdk/jdk/pull/938#discussion_r522203757
  - https://github.com/openjdk/jdk/pull/938#discussion_r522211444
  - https://github.com/openjdk/jdk/pull/938#discussion_r522244221
  - https://github.com/openjdk/jdk/pull/938#discussion_r522262379
  - https://github.com/openjdk/jdk/pull/938#discussion_r522266836

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/a960804f..570b4582

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=11-12

  Stats: 75 lines in 3 files changed: 23 ins; 23 del; 29 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

PR: https://git.openjdk.java.net/jdk/pull/938

From naoto at openjdk.java.net  Thu Nov 12 20:09:08 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 12 Nov 2020 20:09:08 GMT
Subject: RFR: 8247781: Day periods support [v12]
In-Reply-To: <QmM8ovyIghPebG9hVAeHvTSBfeRPt-noT9AF6tvv6Rs=.3d4f6cdd-af86-4342-abf1-9672b752e6bf@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
 <QmM8ovyIghPebG9hVAeHvTSBfeRPt-noT9AF6tvv6Rs=.3d4f6cdd-af86-4342-abf1-9672b752e6bf@github.com>
Message-ID: <YxXizzeh3_HVnp09-Efvf9JcvD4is2-UF1sUjH-jK_c=.0f601ede-9ef5-4146-8fe5-5d4afbda88ad@github.com>

On Thu, 12 Nov 2020 15:41:56 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a test case for user defined temporal field resolution with day period.
>
> src/java.base/share/classes/java/time/format/Parsed.java line 550:
> 
>> 548:                     long midpoint = dayPeriod.mid();
>> 549:                     fieldValues.put(HOUR_OF_DAY, midpoint / 60);
>> 550:                     fieldValues.put(MINUTE_OF_HOUR, midpoint % 60);
> 
> Set `dayPeriod = null` here, as it has been successfully used.

Fixed.

> src/java.base/share/classes/java/time/format/Parsed.java line 502:
> 
>> 500:                 HOUR_OF_AMPM.checkValidValue(hoap);
>> 501:             }
>> 502:             if (dayPeriod.includes((hoap % 24 + 12) * 60)) {
> 
> Pretty sure the 24 should be 12.
> 
> Also, it should use `Math.floorMod()` to handle `HOUR_OF_AMPM = -1` (which is 11 o'clock).
> 
> Also, this doesn't take into account minutes. So if the day period rule is afternoon1 to 18:30 and evening1 after 18:30, and the input is `HOUR_OF_AMPM = 6, MINUTE_OF_HOUR = 45`, this will fail to resolve,
> 
> Something like this should work (no need for `updateCheckDayPeriodConflict`):
> 
>     long hoap = fieldValues.remove(HOUR_OF_AMPM);
>     if (resolverStyle == ResolverStyle.LENIENT) {
>       HOUR_OF_AMPM.checkValidValue(hoap);
>     }
>     Long mohObj = fieldValues.get(MINUTE_OF_HOUR);
>     long moh = mohObj != null ? Math.floorMod(mohObj, 60) : 0;
>     long excessHours = dayPeriod.includes(Math.floorMod(hoap, 12) + 12 * 60 + moh ? 12 : 0;
>     long hod = Math.addExact(hoap, excessHours);
>     updateCheckConflict(HOUR_OF_AMPM, HOUR_OF_DAY, hod);
>     dayPeriod = null;

Fixed.

> src/java.base/share/classes/java/time/format/Parsed.java line 546:
> 
>> 544: 
>> 545:             // Set the hour-of-day, if not exist and not in STRICT, to the mid point of the day period or am/pm.
>> 546:             if (!fieldValues.containsKey(HOUR_OF_DAY) && resolverStyle != ResolverStyle.STRICT) {
> 
> Since this logic replaces both `HOUR_OF_DAY` and `MINUTE_OF_HOUR` I think it should only be invoked if both do not exist. Beyond that, it doesn't really make sense to do this logic if second/sub-second are present. Thus, it needs to check all four fields and can then directly set the time.
> 
>     if (!fieldValues.containsKey(HOUR_OF_DAY) && 
>         !fieldValues.containsKey(MINUTE_OF_HOUR) && 
>         !fieldValues.containsKey(SECOND_OF_MINUTE) && 
>         !fieldValues.containsKey(NANO_OF_SECOND) && 
>         resolverStyle != ResolverStyle.STRICT) {
> 
>       if (dayPeriod != null) {
>         long midpoint = dayPeriod.mid();
>         resolveTime(midpoint / 60, midpoint % 60, 0, 0);
>         dayPeriod = null;
>       } else if (fieldValues.containsKey(AMPM_OF_DAY)) {
>         long ap = fieldValues.remove(AMPM_OF_DAY);
>         if (resolverStyle == ResolverStyle.LENIENT) {
>           resolveTime(Math.addExact(Math.multiplyExact(ap, 12), 6), 0, 0, 0);
>         } else {  // SMART
>           AMPM_OF_DAY.checkValidValue(ap);
>           resolveTime(ap * 12 + 6, 0, 0, 0);
>     }

Fixed.

> src/java.base/share/classes/java/time/format/Parsed.java line 568:
> 
>> 566:                 if (dayPeriod != null) {
>> 567:                     // Check whether the hod is within the day period
>> 568:                     updateCheckDayPeriodConflict(HOUR_OF_DAY, hod);
> 
> With the other changes, this is the only use of this method and it can therefore be simplified (no need to check for conflicts, just whether it matches the day period).

Fixed.

> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 778:
> 
>> 776:                 {"h B", ResolverStyle.SMART, "59 in the morning", 11},
>> 777: 
>> 778:                 {"H B", ResolverStyle.LENIENT, "47 at night", 23},
> 
> This test should be split in two - smart (fails) and lenient (succeeds). The lenient tests should ensure that `p.query(DateTimeFormatter.parsedExcessDays())` returns the expected number of excess days. 
> 
> I'd also add a test for a negative value such as "-2 at night"

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/938

From naoto at openjdk.java.net  Thu Nov 12 20:09:05 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 12 Nov 2020 20:09:05 GMT
Subject: RFR: 8247781: Day periods support [v12]
In-Reply-To: <yVqa9HYTETWD3jT8iB_le0HwuMeMnkNkT8Hln7Zmo9I=.0b1ccc6e-bfa5-4077-bfd2-659632158441@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <qSUn3WI4wfn0LwvAS4cbQ62shB5zAJ7r9MgrOSSoEi8=.34665319-c9d7-4421-83d4-9b22a1097f8b@github.com>
 <yVqa9HYTETWD3jT8iB_le0HwuMeMnkNkT8Hln7Zmo9I=.0b1ccc6e-bfa5-4077-bfd2-659632158441@github.com>
Message-ID: <UFcLrQMiiUoq04bIvT3Nv1FP8-ZL4FuTwto1pF5ViCw=.f766ffdb-cad8-41b1-b860-1965dc3c92f8@github.com>

On Thu, 12 Nov 2020 15:21:52 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a test case for user defined temporal field resolution with day period.
>
> test/jdk/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java line 877:
> 
>> 875:         try {
>> 876:             dtf.parse("0 at night");
>> 877:             throw new RuntimeException("DateTimeParseException should be thrown");
> 
> Testng has `Assert.fail(message)` for this case.

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/938

From naoto at openjdk.java.net  Thu Nov 12 20:09:04 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 12 Nov 2020 20:09:04 GMT
Subject: RFR: 8247781: Day periods support [v11]
In-Reply-To: <Z1cjTmu9oi3nWjDDPp6IxJZz93dDmR6jsSSiroE-bJc=.053d3352-a793-43e2-8365-4421aee4ce4c@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <lqmBJURhzGemQV8SxRqPuJMjtiR0BJjJmzJeqDLFE3Q=.b3ce354a-c663-490a-8ea6-daf5eefc16d7@github.com>
 <Z1cjTmu9oi3nWjDDPp6IxJZz93dDmR6jsSSiroE-bJc=.053d3352-a793-43e2-8365-4421aee4ce4c@github.com>
Message-ID: <l8H--FnpRHlCx9Kt2HSNPMha0czgRZWHBYeH_LA3q30=.5b1aa0e4-79ac-43d9-ada9-e58e0b2700bc@github.com>

On Thu, 12 Nov 2020 15:18:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Clarified 24:00 for "midnight" type in the spec. Some clean up.
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 1483:
> 
>> 1481:      * exception is thrown and the day period is ignored.
>> 1482:      * <p>
>> 1483:      * "midnight" type allows both "00:00" as the start-of-day and "24:00" as the
> 
> Editorial:  Add "The " at the beginning of the sentence.

Fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/938

From herrick at openjdk.java.net  Thu Nov 12 20:48:13 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 12 Nov 2020 20:48:13 GMT
Subject: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2]
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>

> JDK-8189198: Add "forRemoval = true" to Applet APIs

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 six additional commits since the last revision:

 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - Merge branch 'master' into JDK-8189198
 - Merge branch 'master' into JDK-8189198
 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - JDK-8189198: Add "forRemoval = true" to Applet APIs
 - JDK-8189198: Add "forRemoval = true" to Applet APIs

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1127/files
  - new: https://git.openjdk.java.net/jdk/pull/1127/files/a74deeee..d9850cd8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=00-01

  Stats: 7753 lines in 89 files changed: 4891 ins; 1603 del; 1259 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127

PR: https://git.openjdk.java.net/jdk/pull/1127

From scolebourne at openjdk.java.net  Thu Nov 12 22:01:01 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Thu, 12 Nov 2020 22:01:01 GMT
Subject: RFR: 8247781: Day periods support [v13]
In-Reply-To: <tm8uVtpgEhGiOg5qKP86M_OUEgW8hkq2zvQr9EALtY8=.2aed5272-0d52-43e4-a2e0-e534f0e22a20@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <tm8uVtpgEhGiOg5qKP86M_OUEgW8hkq2zvQr9EALtY8=.2aed5272-0d52-43e4-a2e0-e534f0e22a20@github.com>
Message-ID: <aCQlAaZ5H4ZFpGmesZNHQzWiLgXARGwEeRhTWKm0hMg=.dc7244d4-151e-4cdc-af92-4e6fc4d39d9a@github.com>

On Thu, 12 Nov 2020 20:03:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254629
>> 
>> Naoto
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addressed the following comments:
>   - https://github.com/openjdk/jdk/pull/938#discussion_r522185469
>   - https://github.com/openjdk/jdk/pull/938#discussion_r522187931
>   - https://github.com/openjdk/jdk/pull/938#discussion_r522203757
>   - https://github.com/openjdk/jdk/pull/938#discussion_r522211444
>   - https://github.com/openjdk/jdk/pull/938#discussion_r522244221
>   - https://github.com/openjdk/jdk/pull/938#discussion_r522262379
>   - https://github.com/openjdk/jdk/pull/938#discussion_r522266836

Approved with one overflow to fix.

The spec could do with some rewording too. It might be better to explicitly mention the "resolving phase" with the three parts:

> The day period is combined with other fields to make a `LocalTime` in the resolving phase. If the `HOUR_OF_AMPM` field is present, it is combined with the day period to make `HOUR_OF_DAY` taking into account any `MINUTE_OF_HOUR` value. If `HOUR_OF_DAY` is present, it is validated against the day period taking into account any `MINUTE_OF_HOUR` value. If a day period is present without `HOUR_OF_DAY`, `MINUTE_OF_HOUR`, `SECOND_OF_MINUTE` and `NANO_OF_SECOND` then the midpoint of the day period is set as the time.

Note that the above is incomplete, and it doesn't describe STRICT/LENIENT, so the actual words will be more complex,

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5063:

> 5061:             }
> 5062:             Long moh = context.getValue(MINUTE_OF_HOUR);
> 5063:             long value = (hod * 60 + (moh != null ? moh : 0)) % 1_440;

`long value = Math.floorMod(hod, 24) * 60 + (moh != null ? Math.floorMod(moh, 60) : 0);`

and remove the next three lines

-------------

Marked as reviewed by scolebourne (Author).

PR: https://git.openjdk.java.net/jdk/pull/938

From mchung at openjdk.java.net  Thu Nov 12 22:56:09 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 12 Nov 2020 22:56:09 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v2]
In-Reply-To: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
Message-ID: <k34rexdX1i4Hyw2DQzftIjf0AyEwP_saBsl1u5XFXCs=.f204de36-d0be-4c2c-bf85-f23a1a8892dc@github.com>

> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects
> be shared between a hidden class and other classes.  A hidden class can load
> these live objects as dynamically-computed constants via this API.
> 
> Specdiff
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
> 
> With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass`
> will be deprecated for removal.  Existing libraries should replace their
> calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass`
> or `Lookup::defineHiddenClassWithClassData`.
> 
> This patch also updates the implementation of lambda meta factory and
> `MemoryAccessVarHandleGenerator` to use class data.   No performance difference
> observed in the jdk.incubator.foreign microbenchmarks.   A side note: 
> `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of 
> JDK-8254162 but it helps validating the class data support.
> 
> Background
> ----------
> 
> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
> "Constant-pool patching" in the "Risks and Assumption" section.
> 
> A VM-anonymous class can be defined with its constant-pool entries already
> resolved to concrete values. This allows critical constants to be shared
> between a VM-anonymous class and the language runtime that defines it, and
> between multiple VM-anonymous classes. For example, a language runtime will
> often have `MethodHandle` objects in its address space that would be useful
> to newly-defined VM-anonymous classes. Instead of the runtime serializing
> the objects to constant-pool entries in VM-anonymous classes and then
> generating bytecode in those classes to laboriously `ldc` the entries,
> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
> to its live objects. The relevant constant-pool entries in the newly-defined
> VM-anonymous class are pre-linked to those objects, improving performance
> and reducing footprint. In addition, this allows VM-anonymous classes to
> refer to each other: Constant-pool entries in a class file are based on names.
> They thus cannot refer to nameless VM-anonymous classes. A language runtime can,
> however, easily track the live Class objects for its VM-anonymous classes and
> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's
> constant pool entries to other VM-anonymous classes.
> 
> This extends the hidden classes to allow live objects to be injected
> in a hidden class and loaded them via condy.
> 
> Details
> -------
> 
> A new `Lookup::defineHiddenClassWithClassData` API takes additional
> `classData` argument compared to `Lookup::defineHiddenClass`.
> Class data can be method handles, lookup objects, arbitrary user objects
> or collections of all of the above.
> 
> This method behaves as if calling `Lookup::defineHiddenClass` to define
> a hidden class with a private static unnamed field that is initialized
> with `classData` at the first instruction of the class initializer.
> 
> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
> is a bootstrap method to load the class data of the given lookup's lookup class.
> The hidden class will be initialized when `classData` method is called if
> the hidden class has not been initialized.
> 
> For a class data containing more than one single element, libraries can
> create their convenience method to load a single live object via condy.
> We can reconsider if such a convenience method is needed in the future.
> 
> Frameworks sometimes want to dynamically create a hidden class (HC) and add it
> it the lookup class nest and have HC to carry secrets hidden from that nest.
> In this case, frameworks should not to use private static finals (in the HCs
> they spin) to hold secrets because a nestmate of HC may obtain access to
> such a private static final and observe the framework's secret.  It should use
> condy.  In addition, we need to differentiate if a lookup object is created from
> the original lookup class or created from teleporting e.g. `Lookup::in`
> and `MethodHandles::privateLookupIn`.
> 
> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
> object is created by `MethodHandles::lookup` or by bootstrap method invocation.
> The operations only apply to a Lookup object with original access are:
>    - create method handles for caller-sensitve methods
>    - obtain class data associated with the lookup class
> 
> No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which
> ignores the ORIGINAL bit.
> 
> 
> Compatibility Risks
> -------------------
> 
> `Lookup::lookupModes` includes a new `ORIGINAL` bit.  Most lookup operations
> ignore this original bit except creating method handles for caller-sensitive methods
> that expects the lookup from the original lookup class.  Existing code  compares
> the return value of `lookupModes` to be a fixed value may be impacted.   However
> existing client has no need to expect a fixed value of lookup modes.
> The incompatibility risk of this spec change is low.

Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 17 commits:

 - per Jorn's feedback
 - Merge
 - fix incorrect merge
 - more clean up
 - merge
 - Keep classDataAt package-private
 - Merge branch 'master' of https://github.com/openjdk/jdk into class-data
 - MethodHandles::hasFullPrivilegeAccess and Lookup::toString ignores ORIGINAL bit
 - revert some test changes
 - Merge branch 'master' of https://github.com/openjdk/jdk into class-data
 - ... and 7 more: https://git.openjdk.java.net/jdk/compare/b5a9c92b...68576fec

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1171/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1171&range=01
  Stats: 893 lines in 15 files changed: 763 ins; 29 del; 101 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1171.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1171/head:pull/1171

PR: https://git.openjdk.java.net/jdk/pull/1171

From naoto at openjdk.java.net  Thu Nov 12 23:11:15 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 12 Nov 2020 23:11:15 GMT
Subject: RFR: 8247781: Day periods support [v13]
In-Reply-To: <aCQlAaZ5H4ZFpGmesZNHQzWiLgXARGwEeRhTWKm0hMg=.dc7244d4-151e-4cdc-af92-4e6fc4d39d9a@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
 <tm8uVtpgEhGiOg5qKP86M_OUEgW8hkq2zvQr9EALtY8=.2aed5272-0d52-43e4-a2e0-e534f0e22a20@github.com>
 <aCQlAaZ5H4ZFpGmesZNHQzWiLgXARGwEeRhTWKm0hMg=.dc7244d4-151e-4cdc-af92-4e6fc4d39d9a@github.com>
Message-ID: <Mq0wVmNZDvzm8zC9fBGPN0_vePntMqjF2OFbOPUNHdI=.e59b133c-a678-44d6-b07a-abddd88fafd3@github.com>

On Thu, 12 Nov 2020 21:49:16 GMT, Stephen Colebourne <scolebourne at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addressed the following comments:
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r522185469
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r522187931
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r522203757
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r522211444
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r522244221
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r522262379
>>   - https://github.com/openjdk/jdk/pull/938#discussion_r522266836
>
> src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 5063:
> 
>> 5061:             }
>> 5062:             Long moh = context.getValue(MINUTE_OF_HOUR);
>> 5063:             long value = (hod * 60 + (moh != null ? moh : 0)) % 1_440;
> 
> `long value = Math.floorMod(hod, 24) * 60 + (moh != null ? Math.floorMod(moh, 60) : 0);`
> 
> and remove the next three lines

Thanks, Stephen. I made the changes based on your comments.

-------------

PR: https://git.openjdk.java.net/jdk/pull/938

From naoto at openjdk.java.net  Thu Nov 12 23:11:14 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 12 Nov 2020 23:11:14 GMT
Subject: RFR: 8247781: Day periods support [v14]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <lyoWXiAsNIlmnVAYYdCL4_PcMxIz34pArDsner113_U=.d2416b09-c158-4b25-955b-ef1d09dd7b86@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Re-worded the spec of appendDayPeriodText, refactored calculation of minute-of-day.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/570b4582..1aa3134f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=13
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=12-13

  Stats: 18 lines in 1 file changed: 0 ins; 3 del; 15 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

PR: https://git.openjdk.java.net/jdk/pull/938

From almatvee at openjdk.java.net  Thu Nov 12 23:52:56 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 12 Nov 2020 23:52:56 GMT
Subject: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2]
In-Reply-To: <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
Message-ID: <JVMXf2S7V5H6rariy6z8YkOGlh3YAtu2O6TWup0KeyY=.729335e8-4acc-4146-be1f-f5329cd98caf@github.com>

On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> 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 six additional commits since the last revision:
> 
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - Merge branch 'master' into JDK-8189198
>  - Merge branch 'master' into JDK-8189198
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1127

From kcr at openjdk.java.net  Fri Nov 13 00:27:58 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Nov 2020 00:27:58 GMT
Subject: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <Ycx4b7aaw5u8aiSS2NkJhWpuXdQjIRVbEn4DZautriM=.bbab7054-a46f-49c7-b8b7-ee0174aaa8b8@github.com>

On Mon, 9 Nov 2020 13:56:33 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> JDK-8189198: Add "forRemoval = true" to Applet APIs

@andyherrick can you enter the `/csr needed` command? I would, but it needs to be done by either the author of the PR or a Reviewer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1127

From mchung at openjdk.java.net  Fri Nov 13 00:34:58 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 13 Nov 2020 00:34:58 GMT
Subject: Integrated: 8256063: Module::getPackages on an unnamed module may
 return packages that are in a named module
In-Reply-To: <XPWHk4GD1jYRKb3uGzwyhgTVsHA6vjOoniCml4PyGgs=.1cf08390-ec9a-4c6e-9cbb-a6fb21b8a298@github.com>
References: <XPWHk4GD1jYRKb3uGzwyhgTVsHA6vjOoniCml4PyGgs=.1cf08390-ec9a-4c6e-9cbb-a6fb21b8a298@github.com>
Message-ID: <E8Qkhd1oAoNRR4KlmmOeBrki6L0OHyBVWPR63NZoaEE=.9e0287e7-0c4f-45ac-94b0-f1164c7caf6d@github.com>

On Wed, 11 Nov 2020 23:02:49 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> If `Module::getPackages` is invoked on the unnamed module of a class loader
> then the set of packages returned will include the packages of any named modules
> that are defined to that class loader.  This is a spec and implementation bug.
> 
> `Module::getPackages` is changed to return the packages that are defined in
> the unnamed module. 
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8256242

This pull request has now been integrated.

Changeset: dff26a48
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dff26a48
Stats:     123 lines in 4 files changed: 118 ins; 1 del; 4 mod

8256063: Module::getPackages on an unnamed module may return packages that are in a named module

Reviewed-by: alanb, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/1178

From almatvee at openjdk.java.net  Fri Nov 13 00:47:19 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 13 Nov 2020 00:47:19 GMT
Subject: RFR: 8255947: [macos] Signed macOS jpackage app doesn't filter
 spurious '-psn' argument [v2]
In-Reply-To: <gA_HFoOHfdrbfrRXQG6Jvn7M_tfns2G7WvzUIS_afg0=.ea64b8e8-1afd-4884-99b4-cb84333dbbf3@github.com>
References: <gA_HFoOHfdrbfrRXQG6Jvn7M_tfns2G7WvzUIS_afg0=.ea64b8e8-1afd-4884-99b4-cb84333dbbf3@github.com>
Message-ID: <_hNfbthQHRe4rOSC-cHFZXCTBPGUaNHH5tcCPVOxt6U=.39f14c4a-3664-4ee6-947a-7e379b19c63e@github.com>

> This is regression from JDK-8242302 and for some reason removing -psn argument code was removed during refactoring. Fixed be adding removing -psn argument back. Also, test was added to test this functionality.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8255947: [macos] Signed macOS jpackage app doesn't filter spurious '-psn' argument [v2]

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1154/files
  - new: https://git.openjdk.java.net/jdk/pull/1154/files/e07fec6f..7df8d225

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1154&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1154&range=00-01

  Stats: 7 lines in 1 file changed: 2 ins; 3 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1154.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1154/head:pull/1154

PR: https://git.openjdk.java.net/jdk/pull/1154

From hshi at openjdk.java.net  Fri Nov 13 03:50:09 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Fri, 13 Nov 2020 03:50:09 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v6]
In-Reply-To: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
Message-ID: <L2o_e9o3XE1ORKMUk04eVNLHCbnUOdWCstK9jCWXzk4=.6524e841-b1dd-4b5c-ab40-ec7f033b9ece@github.com>

> ?AccessorImpl object
> 
> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
> 
> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
> 
> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.

Hui Shi 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:

  8255883: Avoid multiple GeneratedAccessor for same NativeMethod/ConstructorAccessorImpl object

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1070/files
  - new: https://git.openjdk.java.net/jdk/pull/1070/files/ec1531b2..85c8b96a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1070&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1070&range=04-05

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1070.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1070/head:pull/1070

PR: https://git.openjdk.java.net/jdk/pull/1070

From hshi at openjdk.java.net  Fri Nov 13 03:52:56 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Fri, 13 Nov 2020 03:52:56 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v5]
In-Reply-To: <h9AcY1VriU3YGXGhXw7Z6I0cMeO90HMKY2K4JD2lYVI=.92c669d4-64fe-43b6-9949-c8aa89e0d47d@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <eLNP96JheIN15HOCR6-Bh5qgd-hTDKdi_KQClLBBPuY=.fad46a90-a5a4-4292-9082-78d3ac91e00a@github.com>
 <MBg_DrZt6xaxukQCru1IDGIBTBWESE9dWpY1cYyFxPw=.ed2adb68-519f-4508-b086-705a693a73e6@github.com>
 <KQl2UYnDgp-cWGLQg5s03CUcXeB9glsD8LeW4ysVBtU=.f3cb68ba-fc70-4ae0-a493-66bd81806a86@github.com>
 <h9AcY1VriU3YGXGhXw7Z6I0cMeO90HMKY2K4JD2lYVI=.92c669d4-64fe-43b6-9949-c8aa89e0d47d@github.com>
Message-ID: <-Ir90gkBZdYip05DbOUBPMpAqEpYBncJIWFuMQzvy60=.d2d689b2-5762-458d-8277-65dac0d6dd88@github.com>

On Thu, 12 Nov 2020 12:23:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman 
>> 
>>> What is the reason for using an int? I remember there was a suggestion for three states but two states seems okay so curious why it was changed from boolean to int.
>> 
>> shipilev suggested not to use sub-word CAS, so change compareAndSetBoolean to compareAndSetInt. Change field "generated" from boolean to int doesn't increase object size (no extra byte/boolean to fold into same word).
>> 
>>> The restoring to 0 in the event of failure should probably be a volatile-write. Might be clearer to declare it as a volatile.
>> 
>> "generated" field  is read once and CAS once in this method. It doesn't likely cached and no visibiliy order required.
>
> okay, although I think it would be clearer for maintainers to declare it as volatile because it is set with CAS.

@AlanBateman 

volatile attribute is added. As in common case, it only read and CAS at most once. And I see no regression on my testcase.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1070

From alanb at openjdk.java.net  Fri Nov 13 08:36:00 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 13 Nov 2020 08:36:00 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v6]
In-Reply-To: <L2o_e9o3XE1ORKMUk04eVNLHCbnUOdWCstK9jCWXzk4=.6524e841-b1dd-4b5c-ab40-ec7f033b9ece@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <L2o_e9o3XE1ORKMUk04eVNLHCbnUOdWCstK9jCWXzk4=.6524e841-b1dd-4b5c-ab40-ec7f033b9ece@github.com>
Message-ID: <otOVI-HphtgB9WZIrX2dNU-1tmLb8I5tO29lEr7TVaY=.eddc79d4-e2b3-44cd-bb28-b7f021cdaff7@github.com>

On Fri, 13 Nov 2020 03:50:09 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> ?AccessorImpl object
>> 
>> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
>> 
>> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
>> 
>> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.
>
> Hui Shi 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:
> 
>   8255883: Avoid multiple GeneratedAccessor for same NativeMethod/ConstructorAccessorImpl object

Thanks for the update, latest version looks good.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1070

From roland at openjdk.java.net  Fri Nov 13 08:52:22 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 13 Nov 2020 08:52:22 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v5]
In-Reply-To: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
Message-ID: <ys8d2rDNLXiFJuYrxkuMbkQwoKVHtoOVbMxzm8g1maA=.a6701948-8e9f-458d-9f10-cc7cd3b92b47@github.com>

> This change add 3 new methods in Objects:
> 
> public static long checkIndex(long index, long length)
> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
> public static long checkFromIndexSize(long fromIndex, long size, long length)
> 
> This mirrors the int utility methods that were added by JDK-8135248
> with the same motivations.
> 
> As is the case with the int checkIndex(), the long checkIndex() method
> is JIT compiled as an intrinsic. It allows the JIT to compile
> checkIndex to an unsigned comparison and properly recognize it as
> a range check that then becomes a candidate for the existing range check
> optimizations. This has proven to be important for panama's
> MemorySegment API and a prototype of this change (with some extra c2
> improvements) showed that panama micro benchmark results improve
> significantly.
> 
> This change includes:
> 
> - the API change
> - the C2 intrinsic
> - tests for the API and the C2 intrinsic
> 
> This is a joint work with Paul who reviewed and reworked the API change
> and filled the CSR.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 23 additional commits since the last revision:

 - exclude compiler test when run with -Xcomp
 - CastLL should define carry_depency
 - intrinsic comments
 - Jorn's comments
 - Update headers and add intrinsic to Graal test ignore list
 - move compiler test and add bug to test
 - non x86_64 arch support
 - c2 test case
 - intrinsic
 - Use overloads of method names.
   
   Simplify internally to avoid overload resolution
   issues, leverging List<Number> for the exception
   mapper.
 - ... and 13 more: https://git.openjdk.java.net/jdk/compare/a9aed82d...e3887a79

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1003/files
  - new: https://git.openjdk.java.net/jdk/pull/1003/files/692b4298..e3887a79

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1003&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1003&range=03-04

  Stats: 48430 lines in 396 files changed: 26604 ins; 14405 del; 7421 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1003.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1003/head:pull/1003

PR: https://git.openjdk.java.net/jdk/pull/1003

From roland at openjdk.java.net  Fri Nov 13 08:52:22 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 13 Nov 2020 08:52:22 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v3]
In-Reply-To: <0P2H9rV2KCehYBo_hE-uYriC_S0YAs_1QOePRcRtQjI=.614ae3b3-316b-4bd9-a547-680acb193d3d@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
 <R_wj8HyVj3TBppCLzwfdHTqEJOB4mxFdTmwx4yftKQc=.555c0dff-9826-4772-8421-2228c7a7aa7d@github.com>
 <0P2H9rV2KCehYBo_hE-uYriC_S0YAs_1QOePRcRtQjI=.614ae3b3-316b-4bd9-a547-680acb193d3d@github.com>
Message-ID: <DaoSRcz6dJD4sq0XzSRIwMf7C_tEFD8mTo0L177QOog=.30f5be67-d2d9-4e68-9c8d-55f882a94238@github.com>

On Sat, 7 Nov 2020 11:38:50 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Roland Westrelin 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 vlivanov (Reviewer).

I noticed the compiler test would fail with -Xcomp. I pushed a fix for that

-------------

PR: https://git.openjdk.java.net/jdk/pull/1003

From roland at openjdk.java.net  Fri Nov 13 09:04:11 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Fri, 13 Nov 2020 09:04:11 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v6]
In-Reply-To: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
Message-ID: <q3rw6gzXqUz5II72lZb-m7BLwo7VZ0nRkDkVR6kqJM4=.9c0e10e3-4948-4e2d-a651-8e6010acc979@github.com>

> This change add 3 new methods in Objects:
> 
> public static long checkIndex(long index, long length)
> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
> public static long checkFromIndexSize(long fromIndex, long size, long length)
> 
> This mirrors the int utility methods that were added by JDK-8135248
> with the same motivations.
> 
> As is the case with the int checkIndex(), the long checkIndex() method
> is JIT compiled as an intrinsic. It allows the JIT to compile
> checkIndex to an unsigned comparison and properly recognize it as
> a range check that then becomes a candidate for the existing range check
> optimizations. This has proven to be important for panama's
> MemorySegment API and a prototype of this change (with some extra c2
> improvements) showed that panama micro benchmark results improve
> significantly.
> 
> This change includes:
> 
> - the API change
> - the C2 intrinsic
> - tests for the API and the C2 intrinsic
> 
> This is a joint work with Paul who reviewed and reworked the API change
> and filled the CSR.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits:

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8255150
 - exclude compiler test when run with -Xcomp
 - CastLL should define carry_depency
 - intrinsic comments
 - Jorn's comments
 - Update headers and add intrinsic to Graal test ignore list
 - move compiler test and add bug to test
 - non x86_64 arch support
 - c2 test case
 - intrinsic
 - ... and 14 more: https://git.openjdk.java.net/jdk/compare/b4d01867...90493e6e

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1003/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1003&range=05
  Stats: 897 lines in 30 files changed: 846 ins; 4 del; 47 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1003.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1003/head:pull/1003

PR: https://git.openjdk.java.net/jdk/pull/1003

From alanb at openjdk.java.net  Fri Nov 13 09:35:00 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 13 Nov 2020 09:35:00 GMT
Subject: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2]
In-Reply-To: <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
Message-ID: <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>

On Thu, 12 Nov 2020 20:48:13 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> 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 six additional commits since the last revision:
> 
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - Merge branch 'master' into JDK-8189198
>  - Merge branch 'master' into JDK-8189198
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>  - JDK-8189198: Add "forRemoval = true" to Applet APIs

src/java.naming/share/classes/javax/naming/Context.java line 1087:

> 1085:     @Deprecated(since="16", forRemoval=true)
> 1086:     String APPLET = "java.naming.applet";
> 1087: };

Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1127

From neliasso at openjdk.java.net  Fri Nov 13 09:42:57 2020
From: neliasso at openjdk.java.net (Nils Eliasson)
Date: Fri, 13 Nov 2020 09:42:57 GMT
Subject: Integrated: 8255964: Add all details to jstack log in jtreg timeout
 handler
In-Reply-To: <DsUVGVtRjQYJjXik8iSra_siW4L2QXZrwjMG9zhBAJY=.2d637062-34c5-4c5e-b7ed-2d4708f16221@github.com>
References: <DsUVGVtRjQYJjXik8iSra_siW4L2QXZrwjMG9zhBAJY=.2d637062-34c5-4c5e-b7ed-2d4708f16221@github.com>
Message-ID: <FZBu0GyIziZEXU85kxkiIBxvKAf4LnJJPT3CqGcfImQ=.4963d93e-ac02-4481-bed7-bfe5911ef7a3@github.com>

On Thu, 5 Nov 2020 17:09:58 GMT, Nils Eliasson <neliasso at openjdk.org> wrote:

> This patch adds jcmd Thread.print to the jtreg timeout handler.
> 
> Please review.

This pull request has now been integrated.

Changeset: 41139e31
Author:    Nils Eliasson <neliasso at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/41139e31
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8255964: Add all details to jstack log in jtreg timeout handler

Reviewed-by: iignatyev

-------------

PR: https://git.openjdk.java.net/jdk/pull/1080

From mcimadamore at openjdk.java.net  Fri Nov 13 11:38:24 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 Nov 2020 11:38:24 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v21]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <vTrc07jnWDzKwksUK3U3hKwDTuQVu_FCTG44QPYeCcU=.a5e1f8dd-877b-4c82-a68b-51e4de4436ea@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with three additional commits since the last revision:

 - Fix crashes on aarch64 due to lack of intrinsics support
 - Fix high arity test for aarch64
 - Fix build failure with disabled precompiled headers

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/e3d62ee7..15ab3647

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=20
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=19-20

  Stats: 57 lines in 7 files changed: 52 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From mcimadamore at openjdk.java.net  Fri Nov 13 11:44:17 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 Nov 2020 11:44:17 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v22]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <DQ-2MntEsoZy0zxSB-e5a6RM0FsKH38Gq-a1a4XbTts=.859631c6-aa53-48ee-9eb4-2eacb79d078e@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 83 commits:

 - Merge branch 'master' into 8254231_linker
 - Fix crashes on aarch64 due to lack of intrinsics support
 - Fix high arity test for aarch64
 - Fix build failure with disabled precompiled headers
 - Fix whitespaces
 - Merge branch 'master' into 8254231_linker
 - Merge pull request #7 from JornVernee/Additional_Review_Comments
   
   Additional review comments
 - Revert System.java changes
 - Set copyright year for added files to 2020
 - Check result of AttachCurrentThread
 - ... and 73 more: https://git.openjdk.java.net/jdk/compare/5973e91c...9b7cd259

-------------

Changes: https://git.openjdk.java.net/jdk/pull/634/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=21
  Stats: 67506 lines in 214 files changed: 67329 ins; 79 del; 98 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From herrick at openjdk.java.net  Fri Nov 13 13:50:01 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 13 Nov 2020 13:50:01 GMT
Subject: RFR: 8255947: [macos] Signed macOS jpackage app doesn't filter
 spurious '-psn' argument [v2]
In-Reply-To: <_hNfbthQHRe4rOSC-cHFZXCTBPGUaNHH5tcCPVOxt6U=.39f14c4a-3664-4ee6-947a-7e379b19c63e@github.com>
References: <gA_HFoOHfdrbfrRXQG6Jvn7M_tfns2G7WvzUIS_afg0=.ea64b8e8-1afd-4884-99b4-cb84333dbbf3@github.com>
 <_hNfbthQHRe4rOSC-cHFZXCTBPGUaNHH5tcCPVOxt6U=.39f14c4a-3664-4ee6-947a-7e379b19c63e@github.com>
Message-ID: <lza9OWL5JUWa_4YXqln5ImL8BSY1nTBv160u7rt1-Ng=.10c17f3d-1358-4a1c-a179-2764bdf0e4a9@github.com>

On Fri, 13 Nov 2020 00:47:19 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> This is regression from JDK-8242302 and for some reason removing -psn argument code was removed during refactoring. Fixed be adding removing -psn argument back. Also, test was added to test this functionality.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255947: [macos] Signed macOS jpackage app doesn't filter spurious '-psn' argument [v2]

Looks good

-------------

Marked as reviewed by herrick (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1154

From hshi at openjdk.java.net  Fri Nov 13 14:04:01 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Fri, 13 Nov 2020 14:04:01 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v6]
In-Reply-To: <otOVI-HphtgB9WZIrX2dNU-1tmLb8I5tO29lEr7TVaY=.eddc79d4-e2b3-44cd-bb28-b7f021cdaff7@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <L2o_e9o3XE1ORKMUk04eVNLHCbnUOdWCstK9jCWXzk4=.6524e841-b1dd-4b5c-ab40-ec7f033b9ece@github.com>
 <otOVI-HphtgB9WZIrX2dNU-1tmLb8I5tO29lEr7TVaY=.eddc79d4-e2b3-44cd-bb28-b7f021cdaff7@github.com>
Message-ID: <MHmeYQfZdMABlaTpg2Py1fwjjQwAmcaVk3C0_pvz8xk=.55bda839-16d1-41b8-8bd8-ddde90868b8c@github.com>

On Fri, 13 Nov 2020 08:33:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hui Shi 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:
>> 
>>   8255883: Avoid multiple GeneratedAccessor for same NativeMethod/ConstructorAccessorImpl object
>
> Thanks for the update, latest version looks good.

Thanks all! May this test-request get approved?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1070

From herrick at openjdk.java.net  Fri Nov 13 15:05:15 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 13 Nov 2020 15:05:15 GMT
Subject: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v3]
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>

> JDK-8189198: Add "forRemoval = true" to Applet APIs

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8189198: Add "forRemoval = true" to Applet APIs

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1127/files
  - new: https://git.openjdk.java.net/jdk/pull/1127/files/d9850cd8..c6ea7714

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=01-02

  Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127

PR: https://git.openjdk.java.net/jdk/pull/1127

From jvernee at openjdk.java.net  Fri Nov 13 16:05:57 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 13 Nov 2020 16:05:57 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v6]
In-Reply-To: <MHmeYQfZdMABlaTpg2Py1fwjjQwAmcaVk3C0_pvz8xk=.55bda839-16d1-41b8-8bd8-ddde90868b8c@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <L2o_e9o3XE1ORKMUk04eVNLHCbnUOdWCstK9jCWXzk4=.6524e841-b1dd-4b5c-ab40-ec7f033b9ece@github.com>
 <otOVI-HphtgB9WZIrX2dNU-1tmLb8I5tO29lEr7TVaY=.eddc79d4-e2b3-44cd-bb28-b7f021cdaff7@github.com>
 <MHmeYQfZdMABlaTpg2Py1fwjjQwAmcaVk3C0_pvz8xk=.55bda839-16d1-41b8-8bd8-ddde90868b8c@github.com>
Message-ID: <7ETw0-y1ErydqXnnZvK3WwcrQ3kgv7zqm70f7KqBsQQ=.b5c57015-2a9e-4ccf-ae8b-1b75bb2273f6@github.com>

On Fri, 13 Nov 2020 14:01:28 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> Thanks for the update, latest version looks good.
>
> Thanks all! May this test-request get approved?

Notice that the `/test` command is currently un-available (some implementation concerns are still under consideration). As an alternative, GitHub actions can be used to do basic automatic testing when pushes occur.

However, pushes to the master branch are ignored. The tests didn't run for this PR since it was created from the `master` branch instead of a feature branch (this is ill-advised https://github.com/openjdk/jdk/pull/1070#issuecomment-722108502).

@huishi-hs My advice for now would be to push the changes for this PR to a separate new branch in your fork, for which the GitHub actions workflow should run, and then simply include a link to the workflow here (if you want to share the results).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1070

From mcimadamore at openjdk.java.net  Fri Nov 13 17:06:41 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 13 Nov 2020 17:06:41 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v23]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <7igMkBiVz8heDwoSy6l7jyEr37zVgg6EIA7vNQrAFzA=.e7b3930b-e800-4426-a844-acffd744b64e@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with six additional commits since the last revision:

 - Merge pull request #8 from JornVernee/Vlad_Comments
   
   Address More Review comments
 - - Don't print anything in nmehtod debug output for native invoker if there are none.
   - Use memcpy to copy native stubs to nmethod data
 - Simplify print code
 - Merge branch '8254231_linker' into Vlad_Comments
 - Address Vlad's review comments
 - Add ResourceMark to ProgrammableUpcallHandler constructor

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/9b7cd259..739c7925

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=22
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=21-22

  Stats: 264 lines in 29 files changed: 72 ins; 112 del; 80 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From kcr at openjdk.java.net  Fri Nov 13 18:03:59 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Nov 2020 18:03:59 GMT
Subject: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2]
In-Reply-To: <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
 <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>
Message-ID: <mot16WfbcRFgGyIX69OOOuf0ci4YY6zH1DcHnNVwM9g=.39da06f9-1bf8-47cf-9d99-a7b29b999ffa@github.com>

On Fri, 13 Nov 2020 09:31:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> 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 six additional commits since the last revision:
>> 
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>>  - Merge branch 'master' into JDK-8189198
>>  - Merge branch 'master' into JDK-8189198
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>>  - JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> src/java.naming/share/classes/javax/naming/Context.java line 1087:
> 
>> 1085:     @Deprecated(since="16", forRemoval=true)
>> 1086:     String APPLET = "java.naming.applet";
>> 1087: };
> 
> Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work).

Good point, since it was in fact deprecated in 9.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1127

From kcr at openjdk.java.net  Fri Nov 13 18:23:02 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Fri, 13 Nov 2020 18:23:02 GMT
Subject: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v3]
In-Reply-To: <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>
Message-ID: <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com>

On Fri, 13 Nov 2020 15:05:15 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8189198: Add "forRemoval = true" to Applet APIs

src/java.desktop/share/classes/java/applet/package-info.java line 40:

> 38:  * <p>
> 39:  * Deprecated.
> 40:  * This package has been deprecated and may be removed in a future version of the Java Platform.

That should be `@deprecated This package ...`. See [java/rmi/activation/package-info.java#L41](https://github.com/openjdk/jdk/blob/master/src/java.rmi/share/classes/java/rmi/activation/package-info.java#L41).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1127

From herrick at openjdk.java.net  Fri Nov 13 18:22:59 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 13 Nov 2020 18:22:59 GMT
Subject: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v2]
In-Reply-To: <mot16WfbcRFgGyIX69OOOuf0ci4YY6zH1DcHnNVwM9g=.39da06f9-1bf8-47cf-9d99-a7b29b999ffa@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <DgI_isgoPnnYbPUOaS1oImUTNiG2TCCinTkAce-gOwg=.ed55ee2b-6bfc-4043-baca-abf5b3c58399@github.com>
 <3GqHzIv1CUYpxhZUBOoX5m2C2a-E9h_N77-MxvYKUQY=.3a9aa402-2e45-4d8c-a513-fb1e65157fbe@github.com>
 <mot16WfbcRFgGyIX69OOOuf0ci4YY6zH1DcHnNVwM9g=.39da06f9-1bf8-47cf-9d99-a7b29b999ffa@github.com>
Message-ID: <gYa0bATGPUhfwxiRzpSFAjvkqohOGexGE2wtQOhzU2A=.0686d174-96f9-48c3-8bce-2222bdf38e3b@github.com>

On Fri, 13 Nov 2020 18:01:18 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> src/java.naming/share/classes/javax/naming/Context.java line 1087:
>> 
>>> 1085:     @Deprecated(since="16", forRemoval=true)
>>> 1086:     String APPLET = "java.naming.applet";
>>> 1087: };
>> 
>> Probably should be since="9" (the deprecation in JDK-8051422 pre-dates the enhanced deprecation work).
>
> Good point, since it was in fact deprecated in 9.

yes - changed to since="9" this morning

-------------

PR: https://git.openjdk.java.net/jdk/pull/1127

From mchung at openjdk.java.net  Fri Nov 13 18:46:02 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 13 Nov 2020 18:46:02 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v2]
In-Reply-To: <wxZyd-divfwFv3aeqh2mtvKhPi6UCBFkhiUxIAP7roc=.e1d5fcf0-fadc-4802-b0a7-b0c6cf1ab523@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <RK2kaCseu0XFFWcOj_p2MdE8CmamFNXJu-629wq4mDo=.b430f397-d7c4-46f7-a385-0cf14621c5a9@github.com>
 <wxZyd-divfwFv3aeqh2mtvKhPi6UCBFkhiUxIAP7roc=.e1d5fcf0-fadc-4802-b0a7-b0c6cf1ab523@github.com>
Message-ID: <WlA-Zm7637l3htB-189QvbnZfAm1r4qInwj94mWJDg0=.1c6a3b2c-de7d-4e1a-a032-d470b2296a9e@github.com>

On Thu, 12 Nov 2020 15:19:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Also (as mentioned offline), while it's possible with the current API to provide an `Object[]` as class data, and then load elements of that array into CP entries using downstream condys (e.g. by creating an array access var handle and then using that), I think it would be good to add a `getArrayElement` BSM for doing that to `ConstantBootstraps` to make this (seemingly) common case easier (maybe also a `getField` for loading instance fields). This would help to address the case where multiple live constants need to be injected.

I am uncomfortable with adding `ConstantBootstraps::getArrayElement` because an array is modifiable and _not_ true constant.   A final instance field can be modified via reflection and therefore it's not trusted as a constant either.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1171

From jvernee at openjdk.java.net  Fri Nov 13 19:27:58 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 13 Nov 2020 19:27:58 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v2]
In-Reply-To: <WlA-Zm7637l3htB-189QvbnZfAm1r4qInwj94mWJDg0=.1c6a3b2c-de7d-4e1a-a032-d470b2296a9e@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <RK2kaCseu0XFFWcOj_p2MdE8CmamFNXJu-629wq4mDo=.b430f397-d7c4-46f7-a385-0cf14621c5a9@github.com>
 <wxZyd-divfwFv3aeqh2mtvKhPi6UCBFkhiUxIAP7roc=.e1d5fcf0-fadc-4802-b0a7-b0c6cf1ab523@github.com>
 <WlA-Zm7637l3htB-189QvbnZfAm1r4qInwj94mWJDg0=.1c6a3b2c-de7d-4e1a-a032-d470b2296a9e@github.com>
Message-ID: <uhWRYTdpJqMlo-mpvJ-lS216uJpdxW5BgWnA-oGro48=.a6c97077-41c2-487e-9d18-bd66fdc87bc8@github.com>

On Fri, 13 Nov 2020 18:42:53 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > Also (as mentioned offline), while it's possible with the current API to provide an `Object[]` as class data, and then load elements of that array into CP entries using downstream condys (e.g. by creating an array access var handle and then using that), I think it would be good to add a `getArrayElement` BSM for doing that to `ConstantBootstraps` to make this (seemingly) common case easier (maybe also a `getField` for loading instance fields). This would help to address the case where multiple live constants need to be injected.
> 
> I am uncomfortable with adding `ConstantBootstraps::getArrayElement` because an array is modifiable and _not_ true constant. A final instance field can be modified via reflection and therefore it's not trusted as a constant either.

I guess it would be similar to doing something like:

private static final Object[] arr = getArray();
private static final Object o = arr[0];

Setting `arr[0] = new Object();` would not affect `o` after it has been initialized. The difference being that a constant for the array element would be resolved (more) lazily, so it would be possible to resolve the array, then modify it, and then resolve the constant that loads the element, which would see the updated value as well.

However, we can already store an array in the constant pool today, and modify it if we want, even though, as you say, it is mutable. In that sense getArrayElement doesn't introduce anything new.

Mutating the array is probably a bad idea though, so maybe we want to push users away from using arrays? To prevent inadvertent modification, maybe an immutable `List` should be used in place of a plain array. In that case, would you feel differently about added a `getListElement` BSM, that gets an element from an (immutable) List instead?

Another idea is to rely on records, since they can not be mutated with reflection at all. i.e. we add a getRecordComponent BSM instead, so a class data Object can be a record, and then the BSM can be used to extract individual components.

WDYT?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1171

From jvernee at openjdk.java.net  Fri Nov 13 19:28:00 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 13 Nov 2020 19:28:00 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v2]
In-Reply-To: <uhWRYTdpJqMlo-mpvJ-lS216uJpdxW5BgWnA-oGro48=.a6c97077-41c2-487e-9d18-bd66fdc87bc8@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <RK2kaCseu0XFFWcOj_p2MdE8CmamFNXJu-629wq4mDo=.b430f397-d7c4-46f7-a385-0cf14621c5a9@github.com>
 <wxZyd-divfwFv3aeqh2mtvKhPi6UCBFkhiUxIAP7roc=.e1d5fcf0-fadc-4802-b0a7-b0c6cf1ab523@github.com>
 <WlA-Zm7637l3htB-189QvbnZfAm1r4qInwj94mWJDg0=.1c6a3b2c-de7d-4e1a-a032-d470b2296a9e@github.com>
 <uhWRYTdpJqMlo-mpvJ-lS216uJpdxW5BgWnA-oGro48=.a6c97077-41c2-487e-9d18-bd66fdc87bc8@github.com>
Message-ID: <Vd6vOPyFvi2qk6SALmrzFd7nj0yqZmFMginRP7AA40g=.4c9a033f-f339-4546-bb80-d87c1512ff64@github.com>

On Fri, 13 Nov 2020 19:23:54 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>>> Also (as mentioned offline), while it's possible with the current API to provide an `Object[]` as class data, and then load elements of that array into CP entries using downstream condys (e.g. by creating an array access var handle and then using that), I think it would be good to add a `getArrayElement` BSM for doing that to `ConstantBootstraps` to make this (seemingly) common case easier (maybe also a `getField` for loading instance fields). This would help to address the case where multiple live constants need to be injected.
>> 
>> I am uncomfortable with adding `ConstantBootstraps::getArrayElement` because an array is modifiable and _not_ true constant.   A final instance field can be modified via reflection and therefore it's not trusted as a constant either.
>
>> > Also (as mentioned offline), while it's possible with the current API to provide an `Object[]` as class data, and then load elements of that array into CP entries using downstream condys (e.g. by creating an array access var handle and then using that), I think it would be good to add a `getArrayElement` BSM for doing that to `ConstantBootstraps` to make this (seemingly) common case easier (maybe also a `getField` for loading instance fields). This would help to address the case where multiple live constants need to be injected.
>> 
>> I am uncomfortable with adding `ConstantBootstraps::getArrayElement` because an array is modifiable and _not_ true constant. A final instance field can be modified via reflection and therefore it's not trusted as a constant either.
> 
> I guess it would be similar to doing something like:
> 
> private static final Object[] arr = getArray();
> private static final Object o = arr[0];
> 
> Setting `arr[0] = new Object();` would not affect `o` after it has been initialized. The difference being that a constant for the array element would be resolved (more) lazily, so it would be possible to resolve the array, then modify it, and then resolve the constant that loads the element, which would see the updated value as well.
> 
> However, we can already store an array in the constant pool today, and modify it if we want, even though, as you say, it is mutable. In that sense getArrayElement doesn't introduce anything new.
> 
> Mutating the array is probably a bad idea though, so maybe we want to push users away from using arrays? To prevent inadvertent modification, maybe an immutable `List` should be used in place of a plain array. In that case, would you feel differently about added a `getListElement` BSM, that gets an element from an (immutable) List instead?
> 
> Another idea is to rely on records, since they can not be mutated with reflection at all. i.e. we add a getRecordComponent BSM instead, so a class data Object can be a record, and then the BSM can be used to extract individual components.
> 
> WDYT?

Sorry, this is unrelated to this RFR, I will start a separate discussion thread elsewhere.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1171

From jorn.vernee at oracle.com  Fri Nov 13 20:32:24 2020
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Fri, 13 Nov 2020 21:32:24 +0100
Subject: RFC: 8256341: Add bootstrap methods for getting array elements
Message-ID: <51783876-fec1-3ca9-5c43-a2f3028ab78a@oracle.com>

(Continuing this thread from relevant discussion on [1])

Discussing the following RFE: 
https://bugs.openjdk.java.net/browse/JDK-8256341

>> Also (as mentioned offline), while it's possible with the current API 
>> to provide an `Object[]` as class data, and then load elements of 
>> that array into CP entries using downstream condys (e.g. by creating 
>> an array access var handle and then using that), I think it would be 
>> good to add a `getArrayElement` BSM for doing that to 
>> `ConstantBootstraps` to make this (seemingly) common case easier 
>> (maybe also a `getField` for loading instance fields). This would 
>> help to address the case where multiple live constants need to be 
>> injected.
>>
> I am uncomfortable with adding `ConstantBootstraps::getArrayElement` 
> because an array is modifiable and _not_ true constant. A final 
> instance field can be modified via reflection and therefore it's not 
> trusted as a constant either.
>
I guess it would be similar to doing something like:

 ??? private static final Object[] arr = getArray();
 ??? private static final Object o = arr[0];

Setting `arr[0] = new Object();` would not affect `o` after it has been 
initialized. The difference being that a constant for the array element 
would be resolved (more) lazily, so it would be possible to resolve the 
array, then modify it, and then resolve the constant that loads the 
element, which would see the updated value as well.

However, we can already store an array in the constant pool today, and 
modify it if we want, even though, as you say, it is mutable. In that 
sense getArrayElement doesn't introduce anything new.

Mutating the array is probably a bad idea though, so maybe we want to 
push users away from using arrays? To prevent inadvertent modification, 
maybe an immutable `List` should be used in place of a plain array. In 
that case, would you feel differently about added a `getListElement` 
BSM, that gets an element from an (immutable) List instead?

Another idea is to rely on records, since they can not be mutated with 
reflection at all. i.e. we add a getRecordComponent BSM instead, so a 
class data Object can be a record, and then the BSM can be used to 
extract individual components. Though, the record class would probably 
have to be reflectively accessible from the point where the constant is 
resolved as well.

WDYT?

Jorn

[1] : https://github.com/openjdk/jdk/pull/1171


From openjdk at icemanx.nl  Fri Nov 13 21:30:57 2020
From: openjdk at icemanx.nl (Rob Spoor)
Date: Fri, 13 Nov 2020 22:30:57 +0100
Subject: Asking to contribute(?)
In-Reply-To: <CAO5-QM3OFAkE_CSk+eUuegu2n-ru0usjdCQjJ_vZyASE6tmZog@mail.gmail.com>
References: <CAO5-QM2X1rbTa2pGrqB5zXxA=TdDbsezOiHnsq0xD16A1bbDxw@mail.gmail.com>
 <ba4a2ebf-79b5-ad09-81a5-8865f3cfead7@icemanx.nl>
 <CAO5-QM3OFAkE_CSk+eUuegu2n-ru0usjdCQjJ_vZyASE6tmZog@mail.gmail.com>
Message-ID: <736f49df-3b34-39c3-1765-b85f1af9904f@icemanx.nl>

It appears this discussion has died out...

I really think it's a great addition to have a transform method added to 
not just Stream*, but also StringBuilder, StringBuffer and Optional. A 
search for classes containing "Builder" shows the following that could 
also be interesting:

* HttpClient.Builder, HttpRequest.Builder and WebSocket.Builder
* DateTimeFormatterBuilder
* ProcessBuilder


If we don't go for the Transformable interface (which I admit looks iffy 
due to the cast that can fail if a class decides to use a different 
generic type), I think we should at least add a transform method to 
Stream, StringBuilder, StringBuffer and Optional. The other classes I 
mentioned are probably not used as often as these 4, so let's omit them 
to keep the scope of the change limited.


* For the same reasons that OptionalInt, OptionalLong and OptionalDouble 
won't get (extra) map methods, let's skip IntStream, LongStream and 
DoubleStream as well.


On 05/11/2020 06:23, Justin Dekeyser wrote:
> Hello,
> 
> Thank you for your answer, I appreciate!
> 
> Indeed, it is clear to me that if the feature should be a concern of both
> String and Stream (or more?), a common contract can be designed.
> 
> The impl. you sketch is the more natural one I think. (it's also the one I
> gave in the other mailing grap about that toList stuff, so I guess it's ok!)
> 
> I am just a bit cold about the idea that the spec will make the compiler's
> job, but I guess in Java there is no work around.
> 
> I don't know what the community thinks about it.
> 
> Regards,
> 
> Justin Dekeyser
> 
> On Wednesday, November 4, 2020, Rob Spoor <openjdk at icemanx.nl> wrote:
> 
>> On 04/11/2020 14:18, Justin Dekeyser wrote:
>>
>>> Hello everyone,
>>>
>>> I have been following this mailing list for several months, and
>>> earlier today my attention was drawn to
>>> https://bugs.openjdk.java.net/browse/JDK-8140283. Actually I've been
>>> dreaming of such a feature for a long time now.
>>>
>>> I would really be interested in solving it, but I do not know its
>>> current state nor if someone would agree to sponsor my work on that.
>>>
>>> It would be my very first intervention in the Java code base.
>>> (Still have to make sure the Oracle agreement paper does not conflict
>>> with my current job contract, so nothing's ready for now.)
>>>
>>> Thank you for your time,
>>>
>>> Best regards,
>>>
>>> Justin Dekeyser
>>>
>>>
>> I'd like this feature as well, but why stop at Stream? String already has
>> the transform method, but StringBuilder (and StringBuffer) could also use
>> it.
>>
>> And that's where you're likely to start copy pasting. I've done so for
>> several builder classes I've written for myself. So here's a thought: why
>> add this method to classes, when you can create a trait using an interface
>> with a default method?
>>
>>      public interface Transformable<T> {
>>
>>          default <R> R transform(Function<? super T, ? extends R> f) {
>>              // note: this would need documentation that a class X is
>>              // only allowed to implement Transformable<X>
>>              return f.apply((T) this);
>>          }
>>      }
>>
>> So you could get the following, and each would automatically get the
>> transform method:
>> * public class String implements Transformable<String>
>> * public class StringBuilder implements Transformable<StringBuilder>
>> * public class StringBuffer implements Transformable<StringBuffer>
>> * public interface Stream<T> implements Transformable<Stream<T>>

From openjdk at icemanx.nl  Fri Nov 13 21:50:18 2020
From: openjdk at icemanx.nl (Rob Spoor)
Date: Fri, 13 Nov 2020 22:50:18 +0100
Subject: Feature Request: CharSequence.getChars
Message-ID: <a8ec1c7b-03b3-d01a-1e2b-6f293ea26c06@icemanx.nl>

Hi all,

In Java 9, compact strings were added. Ever since, I've been trying to 
use getChars instead of charAt for Strings. However, I prefer to also do 
the same for StringBuilder and StringBuffer. This can lead to some 
special cases. For instance, in Apache Commons I/O: 
https://github.com/apache/commons-io/blob/master/src/main/java/org/apache/commons/io/input/CharSequenceReader.java#L232

Is it perhaps not a good idea to add getChars as a default method to 
CharSequence? The implementation is simple enough:

     default void getChars(int srcBegin, int srcEnd, char[] dst, int 
dstBegin) {
         Objects.checkFromToIndex(srcBegin, srcEnd, length());
         int n = srcEnd - srcBegin;
         Objects.checkFromIndexSize(dstBegin, n, dst.length);
         for (int i = srcBegin; i < srcEnd; i++) {
             dst[dstBegin++] = charAt(i);
         }
     }

String, StringBuilder and StringBuffer automatically override it with 
their own methods, so these won't have to change at all.


I've already worked a bit on this, including more efficient overrides 
for CharBuffer and StringCharBuffer. The only other known 
implementation, Segment, won't profit much from a custom implementation, 
so I skipped it.

Should I continue with my work, or is it something that's considered not 
necessary? Adding it would allow a better implementation of 
Writer.append. For large CharSequences, that's currently hopelessly 
inefficient - first it converts the CharSequence to String, then to 
char[]. Instead, it could be implemented like write(String, int, int), 
with only one conversion (CharSequence to char[]).


Kind regards,

Rob

From igraves at openjdk.java.net  Fri Nov 13 22:32:17 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 13 Nov 2020 22:32:17 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v6]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <2mQzlvikTfBI9wGHRly2GopMAJ1YQwYvkmap-Kz4Ilc=.37dc7834-f1f3-49c8-8ff6-4bbb4b9b7b87@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision:

 - Merge branch 'format-string-numeric-bound' of github.com:igraves/jdk into format-string-numeric-bound
 - Additional specificity around width
 - Tweaking verbiage
 - Updating docs specifying exception for 0 indices
 - Throwing exceptions for zeroth indexes
 - Updating docs
 - Updating docs and throwing errors accordingly
 - Making IllegalFormatArgumentIndexException package private
 - Additional specificity around width
 - Tweaking verbiage
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/96b6dcaf...a84d3f2f

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/0526ef43..a84d3f2f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=04-05

  Stats: 302178 lines in 580 files changed: 296317 ins; 3588 del; 2273 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From igraves at openjdk.java.net  Fri Nov 13 23:10:08 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 13 Nov 2020 23:10:08 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v7]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <HMrF3ymlCBI25gzG8RR-8-pmf1L_T5VrxsFXx3MSrNE=.bbc51a3d-ae9c-4d98-9239-190baf3ebc05@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Making IllegalFormatArgumentIndexException package private
 - Additional specificity around width
 - Tweaking verbiage
 - Updating docs specifying exception for 0 indices
 - Throwing exceptions for zeroth indexes
 - Updating docs
 - Updating docs and throwing errors accordingly

-------------

Changes: https://git.openjdk.java.net/jdk/pull/516/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=06
  Stats: 94 lines in 4 files changed: 86 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From igraves at openjdk.java.net  Fri Nov 13 23:12:56 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 13 Nov 2020 23:12:56 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v7]
In-Reply-To: <rWfrZZY9p0Y97KCo6tSmK0vYrHrzqTWAAn4NzLtY8L8=.9ccce67d-a400-4fbc-b7d6-b2cb78f8d014@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <gg0s8jJxwD602qg5kVnZ2KUmJb84vaks1WKh7-zyA1I=.8614d28b-e1e4-4d81-82ad-eba620a4516c@github.com>
 <rWfrZZY9p0Y97KCo6tSmK0vYrHrzqTWAAn4NzLtY8L8=.9ccce67d-a400-4fbc-b7d6-b2cb78f8d014@github.com>
Message-ID: <PNbzBDrPGFq_Gb0XF9SpOHEKP9xgnSA2tceK5tJWduk=.857ea2b3-8ef2-4aad-854e-7234ff3f8b10@github.com>

On Tue, 6 Oct 2020 19:10:46 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> Is the new exception type useful?  yes, it matches the previous pattern.
>> But it does not (and none of the IllegalFormatException subclasses) produce a readable message with the offending value. So the developer will not see anything useful.
>> The fine grained exceptions provide little value.
>
> I've been on the fence about this, personally. The Formatter uses pretty fine-grained exception types for error conditions. I'd be okay discontinuing this practice here, but am not sure what to replace this with. Perhaps we enable `IllegalFormatException` to be, itself, public and instantiable ?

Updates (including cleaning up some git weirdness with rebasing) include adherence to the new CSR draft proposal. This makes the new exception type package-private.

-------------

PR: https://git.openjdk.java.net/jdk/pull/516

From serb at openjdk.java.net  Fri Nov 13 23:29:59 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 13 Nov 2020 23:29:59 GMT
Subject: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v3]
In-Reply-To: <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
 <dLkIa4mWpx0hhXams7FvPoHbI5grhVHbsVnX6W_DphM=.9977bce3-93fe-459a-84de-feee4eccfb93@github.com>
 <2YW5WLSFQN87oSb4c-t2jsiflm8TmSyLH_ByIc9lq2U=.647a0363-4fea-4550-bb90-91603e5b842c@github.com>
Message-ID: <duVZxCWBKhVJrPXH4TcaSygW8i99rc9pLXcJe1bXC_s=.5bc72434-59bb-44d8-a957-9c391237397e@github.com>

On Fri, 13 Nov 2020 18:20:37 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8189198: Add "forRemoval = true" to Applet APIs
>
> src/java.desktop/share/classes/java/applet/package-info.java line 40:
> 
>> 38:  * <p>
>> 39:  * Deprecated.
>> 40:  * This package has been deprecated and may be removed in a future version of the Java Platform.
> 
> That should be `@deprecated This package ...`. See [java/rmi/activation/package-info.java#L41](https://github.com/openjdk/jdk/blob/master/src/java.rmi/share/classes/java/rmi/activation/package-info.java#L41).

The deprecation description should point to the new API which might be used instead of the deprecated ones. So the text "deprecated without replacement" was intentionally added, it will be good to preserve it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1127

From igraves at openjdk.java.net  Fri Nov 13 23:31:12 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Fri, 13 Nov 2020 23:31:12 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v8]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <3S4BAXFZ25C4FF_O6igaXEQmYOiJ4-XtiPoQ5j1x38M=.56d9a12c-8b9a-474a-a198-e81d6f67d1ee@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Moving additional methods to package private

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/4bcb053e..5a0effe1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=06-07

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From hshi at openjdk.java.net  Fri Nov 13 23:42:00 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Fri, 13 Nov 2020 23:42:00 GMT
Subject: RFR: 8255883: Avoid duplicated GeneratedMethodAccessor when reflect
 method invoked from different threads
Message-ID: <XKc_CemY8Wb_BB7Z3GRpqTlmQfN19LmKTZRQISDUo94=.923ecbd8-6d99-480e-89b8-f5740402e815@github.com>

?ructorAccessorImpl object

duplicate with https://github.com/openjdk/jdk/pull/1070, try trigger test with new PR

-------------

Commit messages:
 - 8255883: Avoid multiple GeneratedAccessor for same NativeMethod/ConstructorAccessorImpl object

Changes: https://git.openjdk.java.net/jdk/pull/1213/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1213&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255883
  Stats: 46 lines in 2 files changed: 28 ins; 0 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1213.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1213/head:pull/1213

PR: https://git.openjdk.java.net/jdk/pull/1213

From hshi at openjdk.java.net  Fri Nov 13 23:58:54 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Fri, 13 Nov 2020 23:58:54 GMT
Subject: RFR: 8255883: Avoid duplicated GeneratedMethodAccessor when
 reflect method invoked from different threads
In-Reply-To: <XKc_CemY8Wb_BB7Z3GRpqTlmQfN19LmKTZRQISDUo94=.923ecbd8-6d99-480e-89b8-f5740402e815@github.com>
References: <XKc_CemY8Wb_BB7Z3GRpqTlmQfN19LmKTZRQISDUo94=.923ecbd8-6d99-480e-89b8-f5740402e815@github.com>
Message-ID: <uHlcxwddv3EUG-qDBDqCYZvYA6h2gNOgG6BjplvAkl8=.e7525996-ba1f-45ec-9d37-c39abd2d3fd3@github.com>

On Fri, 13 Nov 2020 23:37:46 GMT, Hui Shi <hshi at openjdk.org> wrote:

> ?ructorAccessorImpl object
> 
> duplicate with https://github.com/openjdk/jdk/pull/1070, try trigger test with new PR

@JornVernee 
Could you please help approve and start  tier1 test?
This is same PR with https://github.com/openjdk/jdk/pull/1070

-------------

PR: https://git.openjdk.java.net/jdk/pull/1213

From jvernee at openjdk.java.net  Sat Nov 14 00:31:57 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Sat, 14 Nov 2020 00:31:57 GMT
Subject: RFR: 8255883: Avoid duplicated GeneratedMethodAccessor when
 reflect method invoked from different threads
In-Reply-To: <uHlcxwddv3EUG-qDBDqCYZvYA6h2gNOgG6BjplvAkl8=.e7525996-ba1f-45ec-9d37-c39abd2d3fd3@github.com>
References: <XKc_CemY8Wb_BB7Z3GRpqTlmQfN19LmKTZRQISDUo94=.923ecbd8-6d99-480e-89b8-f5740402e815@github.com>
 <uHlcxwddv3EUG-qDBDqCYZvYA6h2gNOgG6BjplvAkl8=.e7525996-ba1f-45ec-9d37-c39abd2d3fd3@github.com>
Message-ID: <tQU04kuc8Z4hLo5fLvZ_nG6om2Bp9UKsDNMv2CuN55k=.eeaadaf6-93ec-475c-993c-6655d2cf3415@github.com>

On Fri, 13 Nov 2020 23:56:21 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> ?ructorAccessorImpl object
>> 
>> duplicate with https://github.com/openjdk/jdk/pull/1070, try trigger test with new PR
>
> @JornVernee 
> Could you please help approve and start  tier1 test?
> This is same PR with https://github.com/openjdk/jdk/pull/1070

@huishi-hs Testing should start automatically, and will appear here when you push to any branch in your fork that is not `master`: https://github.com/huishi-hs/jdk/actions (unless you disabled this in the repo settings).

As I said, the `/test` command does not work at this time.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1213

From asemenyuk at openjdk.java.net  Sat Nov 14 04:09:58 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Sat, 14 Nov 2020 04:09:58 GMT
Subject: RFR: 8255947: [macos] Signed macOS jpackage app doesn't filter
 spurious '-psn' argument [v2]
In-Reply-To: <_hNfbthQHRe4rOSC-cHFZXCTBPGUaNHH5tcCPVOxt6U=.39f14c4a-3664-4ee6-947a-7e379b19c63e@github.com>
References: <gA_HFoOHfdrbfrRXQG6Jvn7M_tfns2G7WvzUIS_afg0=.ea64b8e8-1afd-4884-99b4-cb84333dbbf3@github.com>
 <_hNfbthQHRe4rOSC-cHFZXCTBPGUaNHH5tcCPVOxt6U=.39f14c4a-3664-4ee6-947a-7e379b19c63e@github.com>
Message-ID: <DbY5j2cJpvJZPA570ZncSWmh9HRLjojK-Cq-_gkcOnM=.f2bda637-4d71-4518-b8df-26029fbda7e6@github.com>

On Fri, 13 Nov 2020 00:47:19 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> This is regression from JDK-8242302 and for some reason removing -psn argument code was removed during refactoring. Fixed be adding removing -psn argument back. Also, test was added to test this functionality.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255947: [macos] Signed macOS jpackage app doesn't filter spurious '-psn' argument [v2]

test/jdk/tools/jpackage/macosx/ArgumentsFilteringTest.java line 52:

> 50: public class ArgumentsFilteringTest {
> 51: 
> 52:     public static void main(String[] args) throws Exception {

Please don't use main() and TKit.run(). Use @Test annotation for methods with test cases.
Please put each case in separated class method.
You can use BasicTest class as a reference.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1154

From dongbo at openjdk.java.net  Sat Nov 14 06:28:05 2020
From: dongbo at openjdk.java.net (Dong Bo)
Date: Sat, 14 Nov 2020 06:28:05 GMT
Subject: RFR: 8256318: AArch64: Add support for floating-point absolute
 difference
Message-ID: <U-BXyTJIMmtZn6Ic1DINVD-fxoNrol9PuKxGQb1RWrk=.32cb0310-49ba-4131-8c14-12c8efe36d58@github.com>

This supports for floating-point absolute difference instructions, i.e. FABD scalar/vector.

Verified with linux-aarch64-server-release, tier1-3.

Added a JMH micro `test/micro/org/openjdk/bench/vm/compiler/FloatingScalarVectorAbsDiff.java` for performance test.

The FABD (scalar), the performance tests handle registers directly, the average latency reduces to almost half  (~57%) of the original.
For FABD (vector), we restrict the data size (~24KB) to be less than L1 data cache size (32KB),
so that the memory access can hit in L1, and witness 14.2% (float) and 21.2% (double) improvements.

The JMH results on Kunpeng916:

Benchmark                                            (count)  (seed)  Mode  Cnt     Score    Error  Units

# before, fsub+fabs
FloatingScalarVectorAbsDiff.testScalarAbsDiffDouble     1024  316731  avgt   10  6038.333 ? 3.889  ns/op
FloatingScalarVectorAbsDiff.testScalarAbsDiffFloat      1024  316731  avgt   10  6005.125 ? 3.025  ns/op
FloatingScalarVectorAbsDiff.testVectorAbsDiffDouble     1024  316731  avgt   10   950.340 ? 9.398  ns/op
FloatingScalarVectorAbsDiff.testVectorAbsDiffFloat      1024  316731  avgt   10   454.350 ? 1.798  ns/op

# after, fabd
FloatingScalarVectorAbsDiff.testScalarAbsDiffDouble     1024  316731  avgt   10  3483.801 ? 1.763  ns/op
FloatingScalarVectorAbsDiff.testScalarAbsDiffFloat      1024  316731  avgt   10  3442.412 ? 1.866  ns/op
FloatingScalarVectorAbsDiff.testVectorAbsDiffDouble     1024  316731  avgt   10   816.301 ? 4.454  ns/op
FloatingScalarVectorAbsDiff.testVectorAbsDiffFloat      1024  316731  avgt   10   354.710 ? 1.001  ns/op

-------------

Commit messages:
 - 8256318: AArch64: Add support for floating-point absolute difference

Changes: https://git.openjdk.java.net/jdk/pull/1215/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1215&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256318
  Stats: 209 lines in 20 files changed: 176 ins; 0 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1215.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1215/head:pull/1215

PR: https://git.openjdk.java.net/jdk/pull/1215

From hshi at openjdk.java.net  Sat Nov 14 07:42:58 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Sat, 14 Nov 2020 07:42:58 GMT
Subject: RFR: 8255883: Avoid duplicated GeneratedMethodAccessor when
 reflect method invoked from different threads
In-Reply-To: <tQU04kuc8Z4hLo5fLvZ_nG6om2Bp9UKsDNMv2CuN55k=.eeaadaf6-93ec-475c-993c-6655d2cf3415@github.com>
References: <XKc_CemY8Wb_BB7Z3GRpqTlmQfN19LmKTZRQISDUo94=.923ecbd8-6d99-480e-89b8-f5740402e815@github.com>
 <uHlcxwddv3EUG-qDBDqCYZvYA6h2gNOgG6BjplvAkl8=.e7525996-ba1f-45ec-9d37-c39abd2d3fd3@github.com>
 <tQU04kuc8Z4hLo5fLvZ_nG6om2Bp9UKsDNMv2CuN55k=.eeaadaf6-93ec-475c-993c-6655d2cf3415@github.com>
Message-ID: <a0i12pfzWWRm21OERbZMVHKUKXCFU7H75r7ygT-pGqA=.3279d1cc-e077-41e1-a13c-7a14f5a6c38d@github.com>

On Sat, 14 Nov 2020 00:28:58 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @JornVernee 
>> Could you please help approve and start  tier1 test?
>> This is same PR with https://github.com/openjdk/jdk/pull/1070
>
> @huishi-hs Testing should start automatically, and will appear here when you push to any branch in your fork that is not `master`: https://github.com/huishi-hs/jdk/actions (unless you disabled this in the repo settings).
> 
> As I said, the `/test` command does not work at this time.

@JornVernee  Thanks!  I didn't enable https://github.com/huishi-hs/jdk/actions. Now it works.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1213

From hshi at openjdk.java.net  Sat Nov 14 07:45:55 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Sat, 14 Nov 2020 07:45:55 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v6]
In-Reply-To: <7ETw0-y1ErydqXnnZvK3WwcrQ3kgv7zqm70f7KqBsQQ=.b5c57015-2a9e-4ccf-ae8b-1b75bb2273f6@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <L2o_e9o3XE1ORKMUk04eVNLHCbnUOdWCstK9jCWXzk4=.6524e841-b1dd-4b5c-ab40-ec7f033b9ece@github.com>
 <otOVI-HphtgB9WZIrX2dNU-1tmLb8I5tO29lEr7TVaY=.eddc79d4-e2b3-44cd-bb28-b7f021cdaff7@github.com>
 <MHmeYQfZdMABlaTpg2Py1fwjjQwAmcaVk3C0_pvz8xk=.55bda839-16d1-41b8-8bd8-ddde90868b8c@github.com>
 <7ETw0-y1ErydqXnnZvK3WwcrQ3kgv7zqm70f7KqBsQQ=.b5c57015-2a9e-4ccf-ae8b-1b75bb2273f6@github.com>
Message-ID: <K7L3SayNVHIFplJMxzxa4QkCkpAsNyG_npsXxE9mVmM=.265c6631-ff0a-49a4-9d44-88921f6ef82c@github.com>

On Fri, 13 Nov 2020 16:02:42 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Thanks all! May this test-request get approved?
>
> Notice that the `/test` command is currently un-available (some implementation concerns are still under consideration). As an alternative, GitHub actions can be used to do basic automatic testing when pushes occur.
> 
> However, pushes to the master branch are ignored. The tests didn't run for this PR since it was created from the `master` branch instead of a feature branch (this is ill-advised https://github.com/openjdk/jdk/pull/1070#issuecomment-722108502).
> 
> @huishi-hs My advice for now would be to push the changes for this PR to a separate new branch in your fork, for which the GitHub actions workflow should run, and then simply include a link to the workflow here (if you want to share the results).

according to instructions, test is performed with another PR and passed https://github.com/openjdk/jdk/pull/1213

-------------

PR: https://git.openjdk.java.net/jdk/pull/1070

From hshi at openjdk.java.net  Sat Nov 14 07:57:55 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Sat, 14 Nov 2020 07:57:55 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v6]
In-Reply-To: <7ETw0-y1ErydqXnnZvK3WwcrQ3kgv7zqm70f7KqBsQQ=.b5c57015-2a9e-4ccf-ae8b-1b75bb2273f6@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <L2o_e9o3XE1ORKMUk04eVNLHCbnUOdWCstK9jCWXzk4=.6524e841-b1dd-4b5c-ab40-ec7f033b9ece@github.com>
 <otOVI-HphtgB9WZIrX2dNU-1tmLb8I5tO29lEr7TVaY=.eddc79d4-e2b3-44cd-bb28-b7f021cdaff7@github.com>
 <MHmeYQfZdMABlaTpg2Py1fwjjQwAmcaVk3C0_pvz8xk=.55bda839-16d1-41b8-8bd8-ddde90868b8c@github.com>
 <7ETw0-y1ErydqXnnZvK3WwcrQ3kgv7zqm70f7KqBsQQ=.b5c57015-2a9e-4ccf-ae8b-1b75bb2273f6@github.com>
Message-ID: <N7i3aX9MhEhhdXazp8fVuJJLUwS5djrVwNvwpfWwfR0=.224a58f5-cddf-4910-bf1e-8fd5746f8fef@github.com>

On Fri, 13 Nov 2020 16:02:42 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Thanks all! May this test-request get approved?
>
> Notice that the `/test` command is currently un-available (some implementation concerns are still under consideration). As an alternative, GitHub actions can be used to do basic automatic testing when pushes occur.
> 
> However, pushes to the master branch are ignored. The tests didn't run for this PR since it was created from the `master` branch instead of a feature branch (this is ill-advised https://github.com/openjdk/jdk/pull/1070#issuecomment-722108502).
> 
> @huishi-hs My advice for now would be to push the changes for this PR to a separate new branch in your fork, for which the GitHub actions workflow should run, and then simply include a link to the workflow here (if you want to share the results).

@JornVernee How can "ready" label be added to this PR? This PR has been reviewed. Would you help on this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1070

From jvernee at openjdk.java.net  Sat Nov 14 12:14:55 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Sat, 14 Nov 2020 12:14:55 GMT
Subject: RFR: 8255883: Avoid multiple GeneratedMethodAccessor for same
 =?UTF-8?B?TmF0aXZlTWV0aG9k4oCm?= [v6]
In-Reply-To: <N7i3aX9MhEhhdXazp8fVuJJLUwS5djrVwNvwpfWwfR0=.224a58f5-cddf-4910-bf1e-8fd5746f8fef@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <L2o_e9o3XE1ORKMUk04eVNLHCbnUOdWCstK9jCWXzk4=.6524e841-b1dd-4b5c-ab40-ec7f033b9ece@github.com>
 <otOVI-HphtgB9WZIrX2dNU-1tmLb8I5tO29lEr7TVaY=.eddc79d4-e2b3-44cd-bb28-b7f021cdaff7@github.com>
 <MHmeYQfZdMABlaTpg2Py1fwjjQwAmcaVk3C0_pvz8xk=.55bda839-16d1-41b8-8bd8-ddde90868b8c@github.com>
 <7ETw0-y1ErydqXnnZvK3WwcrQ3kgv7zqm70f7KqBsQQ=.b5c57015-2a9e-4ccf-ae8b-1b75bb2273f6@github.com>
 <N7i3aX9MhEhhdXazp8fVuJJLUwS5djrVwNvwpfWwfR0=.224a58f5-cddf-4910-bf1e-8fd5746f8fef@github.com>
Message-ID: <nhTwMqhXKiLyoImrSRyGkjX-gdWEky6SwRVcaw2j9ls=.d1b12293-920e-482e-8c83-0dd01d8b105f@github.com>

On Sat, 14 Nov 2020 07:55:35 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> Notice that the `/test` command is currently un-available (some implementation concerns are still under consideration). As an alternative, GitHub actions can be used to do basic automatic testing when pushes occur.
>> 
>> However, pushes to the master branch are ignored. The tests didn't run for this PR since it was created from the `master` branch instead of a feature branch (this is ill-advised https://github.com/openjdk/jdk/pull/1070#issuecomment-722108502).
>> 
>> @huishi-hs My advice for now would be to push the changes for this PR to a separate new branch in your fork, for which the GitHub actions workflow should run, and then simply include a link to the workflow here (if you want to share the results).
>
> @JornVernee How can "ready" label be added to this PR? This PR has been reviewed. Would you help on this?

@huishi-hs See the "Integration blocker" section in the PR body; you have a JBS issue and PR title mismatch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1070

From hshi at openjdk.java.net  Sat Nov 14 12:56:10 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Sat, 14 Nov 2020 12:56:10 GMT
Subject: RFR: 8255883: Avoid duplicated GeneratedMethodAccessor when
 reflect method invoked from different threads [v7]
In-Reply-To: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
Message-ID: <owFuH1oNX-bEIChVOdoVFkbRu6r7ZdtuongbaBc_t9k=.3be5b678-4b4f-4108-9548-d91a2efdc55c@github.com>

> ?AccessorImpl object
> 
> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
> 
> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
> 
> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.

Hui Shi 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:

  8255883: Avoid duplicated GeneratedMethodAccessor when reflect method invoked from different threads

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1070/files
  - new: https://git.openjdk.java.net/jdk/pull/1070/files/85c8b96a..98278050

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1070&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1070&range=05-06

  Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1070.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1070/head:pull/1070

PR: https://git.openjdk.java.net/jdk/pull/1070

From hshi at openjdk.java.net  Sat Nov 14 12:56:10 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Sat, 14 Nov 2020 12:56:10 GMT
Subject: RFR: 8255883: Avoid duplicated GeneratedMethodAccessor when
 reflect method invoked from different threads [v6]
In-Reply-To: <nhTwMqhXKiLyoImrSRyGkjX-gdWEky6SwRVcaw2j9ls=.d1b12293-920e-482e-8c83-0dd01d8b105f@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <L2o_e9o3XE1ORKMUk04eVNLHCbnUOdWCstK9jCWXzk4=.6524e841-b1dd-4b5c-ab40-ec7f033b9ece@github.com>
 <otOVI-HphtgB9WZIrX2dNU-1tmLb8I5tO29lEr7TVaY=.eddc79d4-e2b3-44cd-bb28-b7f021cdaff7@github.com>
 <MHmeYQfZdMABlaTpg2Py1fwjjQwAmcaVk3C0_pvz8xk=.55bda839-16d1-41b8-8bd8-ddde90868b8c@github.com>
 <7ETw0-y1ErydqXnnZvK3WwcrQ3kgv7zqm70f7KqBsQQ=.b5c57015-2a9e-4ccf-ae8b-1b75bb2273f6@github.com>
 <N7i3aX9MhEhhdXazp8fVuJJLUwS5djrVwNvwpfWwfR0=.224a58f5-cddf-4910-bf1e-8fd5746f8fef@github.com>
 <nhTwMqhXKiLyoImrSRyGkjX-gdWEky6SwRVcaw2j9ls=.d1b12293-920e-482e-8c83-0dd01d8b105f@github.com>
Message-ID: <qRwlpYJBeTjxBNoRq8L9wdC_ntc63BVi5SPBPeIRCTw=.c3292105-76f8-4970-ac10-a56f96b736e4@github.com>

On Sat, 14 Nov 2020 12:11:52 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> @JornVernee How can "ready" label be added to this PR? This PR has been reviewed. Would you help on this?
>
> @huishi-hs See the "Integration blocker" section in the PR body; you have a JBS issue and PR title mismatch.

After review PR/commit title is changed to align with JBS title to add ready label

-------------

PR: https://git.openjdk.java.net/jdk/pull/1070

From hshi at openjdk.java.net  Sat Nov 14 12:57:55 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Sat, 14 Nov 2020 12:57:55 GMT
Subject: RFR: 8255883: Avoid duplicated GeneratedMethodAccessor when
 reflect method invoked from different threads
In-Reply-To: <a0i12pfzWWRm21OERbZMVHKUKXCFU7H75r7ygT-pGqA=.3279d1cc-e077-41e1-a13c-7a14f5a6c38d@github.com>
References: <XKc_CemY8Wb_BB7Z3GRpqTlmQfN19LmKTZRQISDUo94=.923ecbd8-6d99-480e-89b8-f5740402e815@github.com>
 <uHlcxwddv3EUG-qDBDqCYZvYA6h2gNOgG6BjplvAkl8=.e7525996-ba1f-45ec-9d37-c39abd2d3fd3@github.com>
 <tQU04kuc8Z4hLo5fLvZ_nG6om2Bp9UKsDNMv2CuN55k=.eeaadaf6-93ec-475c-993c-6655d2cf3415@github.com>
 <a0i12pfzWWRm21OERbZMVHKUKXCFU7H75r7ygT-pGqA=.3279d1cc-e077-41e1-a13c-7a14f5a6c38d@github.com>
Message-ID: <WxzJ_PkyUrBprbqj2j_OYsyP6q6xc11ZC-m71nSDPbU=.b41e753e-206c-48c0-beda-181886d15bdc@github.com>

On Sat, 14 Nov 2020 07:40:07 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> @huishi-hs Testing should start automatically, and will appear here when you push to any branch in your fork that is not `master`: https://github.com/huishi-hs/jdk/actions (unless you disabled this in the repo settings).
>> 
>> As I said, the `/test` command does not work at this time.
>
> @JornVernee  Thanks!  I didn't enable https://github.com/huishi-hs/jdk/actions. Now it works.

Close this. PR is only for presubmit testing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1213

From hshi at openjdk.java.net  Sat Nov 14 12:57:57 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Sat, 14 Nov 2020 12:57:57 GMT
Subject: Withdrawn: 8255883: Avoid duplicated GeneratedMethodAccessor when
 reflect method invoked from different threads
In-Reply-To: <XKc_CemY8Wb_BB7Z3GRpqTlmQfN19LmKTZRQISDUo94=.923ecbd8-6d99-480e-89b8-f5740402e815@github.com>
References: <XKc_CemY8Wb_BB7Z3GRpqTlmQfN19LmKTZRQISDUo94=.923ecbd8-6d99-480e-89b8-f5740402e815@github.com>
Message-ID: <1UgM5kbk4XDvzADbnWSp1vmEo0cE8H_71EyVJYEGRo4=.dc61dffc-4698-4dd9-8dc1-eaa5868fbebd@github.com>

On Fri, 13 Nov 2020 23:37:46 GMT, Hui Shi <hshi at openjdk.org> wrote:

> ?ructorAccessorImpl object
> 
> duplicate with https://github.com/openjdk/jdk/pull/1070, try trigger test with new PR

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1213

From github.com+1926185+robberphex at openjdk.java.net  Sat Nov 14 16:06:01 2020
From: github.com+1926185+robberphex at openjdk.java.net (Robert LU)
Date: Sat, 14 Nov 2020 16:06:01 GMT
Subject: RFR: 8253280: Use class name as class loading lock
Message-ID: <5DnzvOcYJwLegT48SxwqBUqvg8HnihAgaqUpdraS3CU=.516c26fb-e88f-4b7f-9090-26f770e54f05@github.com>

When many thread try to load same class, the thread will stuck on `ClassLoader.loadClass`.
At current jdk, the stacktrace by example program is:
"Thread-1" prio=5 Id=13 BLOCKED on java.lang.String at 724af044 owned by "Thread-0" Id=12
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:646)
        -  blocked on java.lang.String at 724af044 val="java.lang.String"
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:634)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:182)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
        at app//Main2.test(Main2.java:19)
        at app//Main2$$Lambda$37/0x00000001000c2a20.run(Unknown Source)
        at java.base/java.lang.Thread.run(Thread.java:831)
There is no way to get which class stuck the thread.

**After this patch, the stacktrace will be**:
"Thread-2" prio=5 Id=13 BLOCKED on java.lang.String at 724af044 owned by "Thread-3" Id=14
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:612)
	-  blocked on java.lang.String at 724af044 val="java.lang.String"
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:600)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
	at app//Main2.test(Main2.java:18)
	at app//Main2$$Lambda$38/0x0000000100097440.run(Unknown Source)
	at java.base/java.lang.Thread.run(Thread.java:832)
That is, user will know which class stuck the thread, in this example, the class is `java.lang.String`. It's helpful for troubleshooting.

The example program:
Before patch:
<details>
<summary>Main.java</summary>

// Main.java
import java.io.PrintStream;
import java.lang.management.*;

public final class Main {
    private synchronized static void test1() {
        while (true) {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

    private static void test() {
        while (true) {
            try {
                Main.class.getClassLoader().loadClass("java.lang.String");
            } catch (ClassNotFoundException e) {
            }
        }
    }

    public static void main(String[] args) throws InterruptedException, NoSuchFieldException, IllegalAccessException {
        new Thread(Main::test).start();
        new Thread(Main::test).start();
        new Thread(Main::test).start();
        new Thread(Main::test).start();
        new Thread(Main::test).start();

        while (true) {
            Thread.sleep(1000);
            ThreadMXBean bean = ManagementFactory.getThreadMXBean();
            ThreadInfo[] infos = bean.dumpAllThreads(true, true);
            for (ThreadInfo info : infos) {
                System.out.println(printThreadInfo(info));
            }
        }
    }

    private static String printThreadInfo(ThreadInfo threadInfo) {
        StringBuilder sb = new StringBuilder(""" + threadInfo.getThreadName() + """ +
                (threadInfo.isDaemon() ? " daemon" : "") +
                " prio=" + threadInfo.getPriority() +
                " Id=" + threadInfo.getThreadId() + " " +
                threadInfo.getThreadState());
        if (threadInfo.getLockName() != null) {
            sb.append(" on " + threadInfo.getLockName());
        }
        if (threadInfo.getLockOwnerName() != null) {
            sb.append(" owned by "" + threadInfo.getLockOwnerName() +
                    "" Id=" + threadInfo.getLockOwnerId());
        }
        if (threadInfo.isSuspended()) {
            sb.append(" (suspended)");
        }
        if (threadInfo.isInNative()) {
            sb.append(" (in native)");
        }
        sb.append('\n');
        int i = 0;
        StackTraceElement[] stackTrace = threadInfo.getStackTrace();
        for (; i < stackTrace.length; i++) {
            StackTraceElement ste = stackTrace[i];
            sb.append("\tat " + ste.toString());
            sb.append('\n');
            if (i == 0 && threadInfo.getLockInfo() != null) {
                Thread.State ts = threadInfo.getThreadState();
                switch (ts) {
                    case BLOCKED:
                        sb.append("\t-  blocked on " + printLockInfo(threadInfo.getLockInfo()));
                        sb.append('\n');
                        break;
                    case WAITING:
                        sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
                        sb.append('\n');
                        break;
                    case TIMED_WAITING:
                        sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
                        sb.append('\n');
                        break;
                    default:
                }
            }

            for (MonitorInfo mi : threadInfo.getLockedMonitors()) {
                if (mi.getLockedStackDepth() == i) {
                    sb.append("\t-  locked " + printLockInfo(mi));
                    sb.append('\n');
                }
            }
        }
        if (i < stackTrace.length) {
            sb.append("\t...");
            sb.append('\n');
        }

        LockInfo[] locks = threadInfo.getLockedSynchronizers();
        if (locks.length > 0) {
            sb.append("\n\tNumber of locked synchronizers = " + locks.length);
            sb.append('\n');
            for (LockInfo li : locks) {
                sb.append("\t- " + printLockInfo(li));
                sb.append('\n');
            }
        }
        sb.append('\n');
        return sb.toString();
    }

    private static String printLockInfo(LockInfo li) {
        String res = li.getClassName() + '@' + Integer.toHexString(li.getIdentityHashCode());
        return res;
    }
}
</details>
After patch:
<details>
<summary>Main2.java</summary>

// Main2.java
import java.io.PrintStream;
import java.lang.management.*;

public final class Main2 {
    private synchronized static void test1() {
        while (true) {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

    private static void test() {
        while (true) {
            try {
                Main2.class.getClassLoader().loadClass("java.lang.String");
            } catch (ClassNotFoundException e) {
            }
        }
    }

    public static void main(String[] args) throws InterruptedException, NoSuchFieldException, IllegalAccessException {
        new Thread(Main2::test).start();
        new Thread(Main2::test).start();
        new Thread(Main2::test).start();
        new Thread(Main2::test).start();
        new Thread(Main2::test).start();

        while (true) {
            Thread.sleep(1000);
            ThreadMXBean bean = ManagementFactory.getThreadMXBean();
            ThreadInfo[] infos = bean.dumpAllThreads(true, true);
            for (ThreadInfo info : infos) {
                System.out.println(printThreadInfo(info));
            }
        }
    }

    private static String printThreadInfo(ThreadInfo threadInfo) {
        StringBuilder sb = new StringBuilder(""" + threadInfo.getThreadName() + """ +
                (threadInfo.isDaemon() ? " daemon" : "") +
                " prio=" + threadInfo.getPriority() +
                " Id=" + threadInfo.getThreadId() + " " +
                threadInfo.getThreadState());
        if (threadInfo.getLockName() != null) {
            sb.append(" on " + threadInfo.getLockName());
        }
        if (threadInfo.getLockOwnerName() != null) {
            sb.append(" owned by "" + threadInfo.getLockOwnerName() +
                    "" Id=" + threadInfo.getLockOwnerId());
        }
        if (threadInfo.isSuspended()) {
            sb.append(" (suspended)");
        }
        if (threadInfo.isInNative()) {
            sb.append(" (in native)");
        }
        sb.append('\n');
        int i = 0;
        StackTraceElement[] stackTrace = threadInfo.getStackTrace();
        for (; i < stackTrace.length; i++) {
            StackTraceElement ste = stackTrace[i];
            sb.append("\tat " + ste.toString());
            sb.append('\n');
            if (i == 0 && threadInfo.getLockInfo() != null) {
                Thread.State ts = threadInfo.getThreadState();
                switch (ts) {
                    case BLOCKED:
                        sb.append("\t-  blocked on " + printLockInfo(threadInfo.getLockInfo()));
                        sb.append('\n');
                        break;
                    case WAITING:
                        sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
                        sb.append('\n');
                        break;
                    case TIMED_WAITING:
                        sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
                        sb.append('\n');
                        break;
                    default:
                }
            }

            for (MonitorInfo mi : threadInfo.getLockedMonitors()) {
                if (mi.getLockedStackDepth() == i) {
                    sb.append("\t-  locked " + printLockInfo(mi));
                    sb.append('\n');
                }
            }
        }
        if (i < stackTrace.length) {
            sb.append("\t...");
            sb.append('\n');
        }

        LockInfo[] locks = threadInfo.getLockedSynchronizers();
        if (locks.length > 0) {
            sb.append("\n\tNumber of locked synchronizers = " + locks.length);
            sb.append('\n');
            for (LockInfo li : locks) {
                sb.append("\t- " + printLockInfo(li));
                sb.append('\n');
            }
        }
        sb.append('\n');
        return sb.toString();
    }

    private static String printLockInfo(LockInfo li) {
        String res = li.getClassName() + '@' + Integer.toHexString(li.getIdentityHashCode());
        // There is no getLock method in current jdk
        if (li.getStringValue() != null) {
            return res + " val="" + li.getStringValue() + """;
        }
        return res;
    }
}
</details>

-------------

Commit messages:
 - 8253280: Use class name as class loading lock

Changes: https://git.openjdk.java.net/jdk/pull/104/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=104&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253280
  Stats: 73 lines in 5 files changed: 72 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/104.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/104/head:pull/104

PR: https://git.openjdk.java.net/jdk/pull/104

From mchung at openjdk.java.net  Sat Nov 14 16:06:02 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Sat, 14 Nov 2020 16:06:02 GMT
Subject: RFR: 8253280: Use class name as class loading lock
In-Reply-To: <5DnzvOcYJwLegT48SxwqBUqvg8HnihAgaqUpdraS3CU=.516c26fb-e88f-4b7f-9090-26f770e54f05@github.com>
References: <5DnzvOcYJwLegT48SxwqBUqvg8HnihAgaqUpdraS3CU=.516c26fb-e88f-4b7f-9090-26f770e54f05@github.com>
Message-ID: <KRijkIb6DQRiRoA62P9FPZjS6Fo-98i0G62qAHqIrbI=.cb25ba66-3ff3-4e07-a021-cc27286685c0@github.com>

On Thu, 10 Sep 2020 05:25:43 GMT, Robert LU <github.com+1926185+RobberPhex at openjdk.org> wrote:

> When many thread try to load same class, the thread will stuck on `ClassLoader.loadClass`.
> At current jdk, the stacktrace by example program is:
> "Thread-1" prio=5 Id=13 BLOCKED on java.lang.String at 724af044 owned by "Thread-0" Id=12
>         at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:646)
>         -  blocked on java.lang.String at 724af044 val="java.lang.String"
>         at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:634)
>         at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:182)
>         at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
>         at app//Main2.test(Main2.java:19)
>         at app//Main2$$Lambda$37/0x00000001000c2a20.run(Unknown Source)
>         at java.base/java.lang.Thread.run(Thread.java:831)
> There is no way to get which class stuck the thread.
> 
> **After this patch, the stacktrace will be**:
> "Thread-2" prio=5 Id=13 BLOCKED on java.lang.String at 724af044 owned by "Thread-3" Id=14
> 	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:612)
> 	-  blocked on java.lang.String at 724af044 val="java.lang.String"
> 	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:600)
> 	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> 	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> 	at app//Main2.test(Main2.java:18)
> 	at app//Main2$$Lambda$38/0x0000000100097440.run(Unknown Source)
> 	at java.base/java.lang.Thread.run(Thread.java:832)
> That is, user will know which class stuck the thread, in this example, the class is `java.lang.String`. It's helpful for troubleshooting.
> 
> The example program:
> Before patch:
> <details>
> <summary>Main.java</summary>
> 
> // Main.java
> import java.io.PrintStream;
> import java.lang.management.*;
> 
> public final class Main {
>     private synchronized static void test1() {
>         while (true) {
>             try {
>                 Thread.sleep(1000);
>             } catch (InterruptedException e) {
>                 e.printStackTrace();
>             }
>         }
>     }
> 
>     private static void test() {
>         while (true) {
>             try {
>                 Main.class.getClassLoader().loadClass("java.lang.String");
>             } catch (ClassNotFoundException e) {
>             }
>         }
>     }
> 
>     public static void main(String[] args) throws InterruptedException, NoSuchFieldException, IllegalAccessException {
>         new Thread(Main::test).start();
>         new Thread(Main::test).start();
>         new Thread(Main::test).start();
>         new Thread(Main::test).start();
>         new Thread(Main::test).start();
> 
>         while (true) {
>             Thread.sleep(1000);
>             ThreadMXBean bean = ManagementFactory.getThreadMXBean();
>             ThreadInfo[] infos = bean.dumpAllThreads(true, true);
>             for (ThreadInfo info : infos) {
>                 System.out.println(printThreadInfo(info));
>             }
>         }
>     }
> 
>     private static String printThreadInfo(ThreadInfo threadInfo) {
>         StringBuilder sb = new StringBuilder(""" + threadInfo.getThreadName() + """ +
>                 (threadInfo.isDaemon() ? " daemon" : "") +
>                 " prio=" + threadInfo.getPriority() +
>                 " Id=" + threadInfo.getThreadId() + " " +
>                 threadInfo.getThreadState());
>         if (threadInfo.getLockName() != null) {
>             sb.append(" on " + threadInfo.getLockName());
>         }
>         if (threadInfo.getLockOwnerName() != null) {
>             sb.append(" owned by "" + threadInfo.getLockOwnerName() +
>                     "" Id=" + threadInfo.getLockOwnerId());
>         }
>         if (threadInfo.isSuspended()) {
>             sb.append(" (suspended)");
>         }
>         if (threadInfo.isInNative()) {
>             sb.append(" (in native)");
>         }
>         sb.append('\n');
>         int i = 0;
>         StackTraceElement[] stackTrace = threadInfo.getStackTrace();
>         for (; i < stackTrace.length; i++) {
>             StackTraceElement ste = stackTrace[i];
>             sb.append("\tat " + ste.toString());
>             sb.append('\n');
>             if (i == 0 && threadInfo.getLockInfo() != null) {
>                 Thread.State ts = threadInfo.getThreadState();
>                 switch (ts) {
>                     case BLOCKED:
>                         sb.append("\t-  blocked on " + printLockInfo(threadInfo.getLockInfo()));
>                         sb.append('\n');
>                         break;
>                     case WAITING:
>                         sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
>                         sb.append('\n');
>                         break;
>                     case TIMED_WAITING:
>                         sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
>                         sb.append('\n');
>                         break;
>                     default:
>                 }
>             }
> 
>             for (MonitorInfo mi : threadInfo.getLockedMonitors()) {
>                 if (mi.getLockedStackDepth() == i) {
>                     sb.append("\t-  locked " + printLockInfo(mi));
>                     sb.append('\n');
>                 }
>             }
>         }
>         if (i < stackTrace.length) {
>             sb.append("\t...");
>             sb.append('\n');
>         }
> 
>         LockInfo[] locks = threadInfo.getLockedSynchronizers();
>         if (locks.length > 0) {
>             sb.append("\n\tNumber of locked synchronizers = " + locks.length);
>             sb.append('\n');
>             for (LockInfo li : locks) {
>                 sb.append("\t- " + printLockInfo(li));
>                 sb.append('\n');
>             }
>         }
>         sb.append('\n');
>         return sb.toString();
>     }
> 
>     private static String printLockInfo(LockInfo li) {
>         String res = li.getClassName() + '@' + Integer.toHexString(li.getIdentityHashCode());
>         return res;
>     }
> }
> </details>
> After patch:
> <details>
> <summary>Main2.java</summary>
> 
> // Main2.java
> import java.io.PrintStream;
> import java.lang.management.*;
> 
> public final class Main2 {
>     private synchronized static void test1() {
>         while (true) {
>             try {
>                 Thread.sleep(1000);
>             } catch (InterruptedException e) {
>                 e.printStackTrace();
>             }
>         }
>     }
> 
>     private static void test() {
>         while (true) {
>             try {
>                 Main2.class.getClassLoader().loadClass("java.lang.String");
>             } catch (ClassNotFoundException e) {
>             }
>         }
>     }
> 
>     public static void main(String[] args) throws InterruptedException, NoSuchFieldException, IllegalAccessException {
>         new Thread(Main2::test).start();
>         new Thread(Main2::test).start();
>         new Thread(Main2::test).start();
>         new Thread(Main2::test).start();
>         new Thread(Main2::test).start();
> 
>         while (true) {
>             Thread.sleep(1000);
>             ThreadMXBean bean = ManagementFactory.getThreadMXBean();
>             ThreadInfo[] infos = bean.dumpAllThreads(true, true);
>             for (ThreadInfo info : infos) {
>                 System.out.println(printThreadInfo(info));
>             }
>         }
>     }
> 
>     private static String printThreadInfo(ThreadInfo threadInfo) {
>         StringBuilder sb = new StringBuilder(""" + threadInfo.getThreadName() + """ +
>                 (threadInfo.isDaemon() ? " daemon" : "") +
>                 " prio=" + threadInfo.getPriority() +
>                 " Id=" + threadInfo.getThreadId() + " " +
>                 threadInfo.getThreadState());
>         if (threadInfo.getLockName() != null) {
>             sb.append(" on " + threadInfo.getLockName());
>         }
>         if (threadInfo.getLockOwnerName() != null) {
>             sb.append(" owned by "" + threadInfo.getLockOwnerName() +
>                     "" Id=" + threadInfo.getLockOwnerId());
>         }
>         if (threadInfo.isSuspended()) {
>             sb.append(" (suspended)");
>         }
>         if (threadInfo.isInNative()) {
>             sb.append(" (in native)");
>         }
>         sb.append('\n');
>         int i = 0;
>         StackTraceElement[] stackTrace = threadInfo.getStackTrace();
>         for (; i < stackTrace.length; i++) {
>             StackTraceElement ste = stackTrace[i];
>             sb.append("\tat " + ste.toString());
>             sb.append('\n');
>             if (i == 0 && threadInfo.getLockInfo() != null) {
>                 Thread.State ts = threadInfo.getThreadState();
>                 switch (ts) {
>                     case BLOCKED:
>                         sb.append("\t-  blocked on " + printLockInfo(threadInfo.getLockInfo()));
>                         sb.append('\n');
>                         break;
>                     case WAITING:
>                         sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
>                         sb.append('\n');
>                         break;
>                     case TIMED_WAITING:
>                         sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
>                         sb.append('\n');
>                         break;
>                     default:
>                 }
>             }
> 
>             for (MonitorInfo mi : threadInfo.getLockedMonitors()) {
>                 if (mi.getLockedStackDepth() == i) {
>                     sb.append("\t-  locked " + printLockInfo(mi));
>                     sb.append('\n');
>                 }
>             }
>         }
>         if (i < stackTrace.length) {
>             sb.append("\t...");
>             sb.append('\n');
>         }
> 
>         LockInfo[] locks = threadInfo.getLockedSynchronizers();
>         if (locks.length > 0) {
>             sb.append("\n\tNumber of locked synchronizers = " + locks.length);
>             sb.append('\n');
>             for (LockInfo li : locks) {
>                 sb.append("\t- " + printLockInfo(li));
>                 sb.append('\n');
>             }
>         }
>         sb.append('\n');
>         return sb.toString();
>     }
> 
>     private static String printLockInfo(LockInfo li) {
>         String res = li.getClassName() + '@' + Integer.toHexString(li.getIdentityHashCode());
>         // There is no getLock method in current jdk
>         if (li.getStringValue() != null) {
>             return res + " val="" + li.getStringValue() + """;
>         }
>         return res;
>     }
> }
> </details>

This patch proposes to add two public APIs `java.lang.management.LockInfo::getLock`
and the new `java.lang.management.MonitorInfo` constructor taking the lock object.
`java.lang.management.MonitorInfo` and `LockInfo` by design do not expose
the lock object for remote monitoring reason (may not be serializable) and
for security reason.   The API instead provides the class name and identity hash
code of the lock object serving. as an unique ID.

I read JDK-8253280 as improving the diagnosability of ClassLoader-specific lock
returned from `ClassLoader::getClassLoadingLock` for example improving
the VM thread dump by control-break to special case the lock object for class
loading operation.   `LockInfo` is not specific for ClassLoader and so it does 
not seem the appropriate place to embed this information.


For example
the class loading lock is a new ClassLoader$Lock class and VM will perhaps call Lock::toString
(or print a specific field) in the thread dump output.

The attached program uses `java.lang.management.ThreadMXBean` to get a thread dump
and prints the output.

-------------

PR: https://git.openjdk.java.net/jdk/pull/104

From github.com+1556567+grischard at openjdk.java.net  Sat Nov 14 17:26:55 2020
From: github.com+1556567+grischard at openjdk.java.net (Guillaume Rischard)
Date: Sat, 14 Nov 2020 17:26:55 GMT
Subject: RFR: 8255947: [macos] Signed macOS jpackage app doesn't filter
 spurious '-psn' argument
In-Reply-To: <gA_HFoOHfdrbfrRXQG6Jvn7M_tfns2G7WvzUIS_afg0=.ea64b8e8-1afd-4884-99b4-cb84333dbbf3@github.com>
References: <gA_HFoOHfdrbfrRXQG6Jvn7M_tfns2G7WvzUIS_afg0=.ea64b8e8-1afd-4884-99b4-cb84333dbbf3@github.com>
Message-ID: <o3Fi1555oAm-bfbpKNj3FMYIqLh07pcT-r2eOhehHdw=.91583c2e-7251-401f-b59e-61d67ecbdde2@github.com>

On Wed, 11 Nov 2020 04:28:02 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This is regression from JDK-8242302 and for some reason removing -psn argument code was removed during refactoring. Fixed be adding removing -psn argument back. Also, test was added to test this functionality.

For bug reproduction, note that the very latest version of macOS (Big Sur, 11.0.1), released just yesterday, doesn't pass the `-psn_x_yyyy` argument anymore

-------------

PR: https://git.openjdk.java.net/jdk/pull/1154

From robberphex at gmail.com  Sat Nov 14 16:26:01 2020
From: robberphex at gmail.com (Robert Lu)
Date: Sun, 15 Nov 2020 00:26:01 +0800
Subject: RFR: 8253280: Use class name as class loading lock
Message-ID: <CA+879repJkbq=zEpAarPyq1sWt09LmFbOP-HaCbZYxycyHA5VA@mail.gmail.com>

When many thread try to load same class, the thread will stuck on
ClassLoader.loadClass.

At current jdk, the stacktrace by example program is:

"Thread-1" prio=5 Id=12 BLOCKED on java.lang.Object at 2e817b38 owned by
"Thread-0" Id=11
        at java.base at 15/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:616)
        -  blocked on java.lang.Object at 2e817b38
        at java.base at 15/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:604)
        at java.base at 15/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:168)
        at java.base at 15/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
        at app//Main.test(Main.java:19)
        at app//Main$$Lambda$2/0x0000000800b8c468.run(Unknown Source)
        at java.base at 15/java.lang.Thread.run(Thread.java:832)

There is no way to get which class stuck the thread.

*After this patch, the stacktrace will be*:

"Thread-1" prio=5 Id=13 BLOCKED on java.lang.String at 724af044 owned by
"Thread-0" Id=12
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:646)
        -  blocked on java.lang.String at 724af044 val="java.lang.String"
        at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:634)
        at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:182)
        at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
        at app//Main2.test(Main2.java:19)
        at app//Main2$$Lambda$37/0x00000001000c2a20.run(Unknown Source)
        at java.base/java.lang.Thread.run(Thread.java:831)

That is, user will know which class stuck the thread, in this example, the
class is java.lang.String. It's helpful for troubleshooting.
The example program:

// Main2.javaimport java.io.PrintStream;import java.lang.management.*;
public final class Main2 {
    private synchronized static void test1() {
        while (true) {
            try {
                Thread.sleep(1000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }
        }
    }

    private static void test() {
        while (true) {
            try {
                Main2.class.getClassLoader().loadClass("java.lang.String");
            } catch (ClassNotFoundException e) {
            }
        }
    }

    public static void main(String[] args) throws
InterruptedException, NoSuchFieldException, IllegalAccessException {
        new Thread(Main2::test).start();
        new Thread(Main2::test).start();
        new Thread(Main2::test).start();
        new Thread(Main2::test).start();
        new Thread(Main2::test).start();

        while (true) {
            Thread.sleep(1000);
            ThreadMXBean bean = ManagementFactory.getThreadMXBean();
            ThreadInfo[] infos = bean.dumpAllThreads(true, true);
            for (ThreadInfo info : infos) {
                System.out.println(printThreadInfo(info));
            }
        }
    }

    private static String printThreadInfo(ThreadInfo threadInfo) {
        StringBuilder sb = new StringBuilder("\"" +
threadInfo.getThreadName() + "\"" +
                (threadInfo.isDaemon() ? " daemon" : "") +
                " prio=" + threadInfo.getPriority() +
                " Id=" + threadInfo.getThreadId() + " " +
                threadInfo.getThreadState());
        if (threadInfo.getLockName() != null) {
            sb.append(" on " + threadInfo.getLockName());
        }
        if (threadInfo.getLockOwnerName() != null) {
            sb.append(" owned by \"" + threadInfo.getLockOwnerName() +
                    "\" Id=" + threadInfo.getLockOwnerId());
        }
        if (threadInfo.isSuspended()) {
            sb.append(" (suspended)");
        }
        if (threadInfo.isInNative()) {
            sb.append(" (in native)");
        }
        sb.append('\n');
        int i = 0;
        StackTraceElement[] stackTrace = threadInfo.getStackTrace();
        for (; i < stackTrace.length; i++) {
            StackTraceElement ste = stackTrace[i];
            sb.append("\tat " + ste.toString());
            sb.append('\n');
            if (i == 0 && threadInfo.getLockInfo() != null) {
                Thread.State ts = threadInfo.getThreadState();
                switch (ts) {
                    case BLOCKED:
                        sb.append("\t-  blocked on " +
printLockInfo(threadInfo.getLockInfo()));
                        sb.append('\n');
                        break;
                    case WAITING:
                        sb.append("\t-  waiting on " +
printLockInfo(threadInfo.getLockInfo()));
                        sb.append('\n');
                        break;
                    case TIMED_WAITING:
                        sb.append("\t-  waiting on " +
printLockInfo(threadInfo.getLockInfo()));
                        sb.append('\n');
                        break;
                    default:
                }
            }

            for (MonitorInfo mi : threadInfo.getLockedMonitors()) {
                if (mi.getLockedStackDepth() == i) {
                    sb.append("\t-  locked " + printLockInfo(mi));
                    sb.append('\n');
                }
            }
        }
        if (i < stackTrace.length) {
            sb.append("\t...");
            sb.append('\n');
        }

        LockInfo[] locks = threadInfo.getLockedSynchronizers();
        if (locks.length > 0) {
            sb.append("\n\tNumber of locked synchronizers = " + locks.length);
            sb.append('\n');
            for (LockInfo li : locks) {
                sb.append("\t- " + printLockInfo(li));
                sb.append('\n');
            }
        }
        sb.append('\n');
        return sb.toString();
    }

    private static String printLockInfo(LockInfo li) {
        String res = li.getClassName() + '@' +
Integer.toHexString(li.getIdentityHashCode());
        // There is no getLock method in current jdk
        if (li.getStringValue() != null) {
            return res + " val=\"" + li.getStringValue() + "\"";
        }
        return res;
    }
}


----------

Commit messages:
 - 8253280: Use class name as class loading lock

Changes: https://github.com/openjdk/jdk/pull/104/files
 Webrev: https://openjdk.github.io/cr/?repo=jdk&pr=104&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253280
  Stats:  74 lines changed; 73 ins; 1 del
  Patch: https://git.openjdk.java.net/jdk/pull/104.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/104/head:pull/104

PR: https://git.openjdk.java.net/jdk/pull/104


-- 
Robert Lu <robberphex at gmail.com>

From alanb at openjdk.java.net  Sun Nov 15 07:27:57 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 15 Nov 2020 07:27:57 GMT
Subject: RFR: 8255883: Avoid duplicated GeneratedMethodAccessor when
 reflect method invoked from different threads [v6]
In-Reply-To: <qRwlpYJBeTjxBNoRq8L9wdC_ntc63BVi5SPBPeIRCTw=.c3292105-76f8-4970-ac10-a56f96b736e4@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <L2o_e9o3XE1ORKMUk04eVNLHCbnUOdWCstK9jCWXzk4=.6524e841-b1dd-4b5c-ab40-ec7f033b9ece@github.com>
 <otOVI-HphtgB9WZIrX2dNU-1tmLb8I5tO29lEr7TVaY=.eddc79d4-e2b3-44cd-bb28-b7f021cdaff7@github.com>
 <MHmeYQfZdMABlaTpg2Py1fwjjQwAmcaVk3C0_pvz8xk=.55bda839-16d1-41b8-8bd8-ddde90868b8c@github.com>
 <7ETw0-y1ErydqXnnZvK3WwcrQ3kgv7zqm70f7KqBsQQ=.b5c57015-2a9e-4ccf-ae8b-1b75bb2273f6@github.com>
 <N7i3aX9MhEhhdXazp8fVuJJLUwS5djrVwNvwpfWwfR0=.224a58f5-cddf-4910-bf1e-8fd5746f8fef@github.com>
 <nhTwMqhXKiLyoImrSRyGkjX-gdWEky6SwRVcaw2j9ls=.d1b12293-920e-482e-8c83-0dd01d8b105f@github.com>
 <qRwlpYJBeTjxBNoRq8L9wdC_ntc63BVi5SPBPeIRCTw=.c3292105-76f8-4970-ac10-a56f96b736e4@github.com>
Message-ID: <GqG44Z9jSYfTRGvBAmOfkiC63LnAXwVmhHkWElEeZ2k=.25e5dea2-8e97-44f7-8ae4-e04e0ae2d685@github.com>

On Sat, 14 Nov 2020 12:53:26 GMT, Hui Shi <hshi at openjdk.org> wrote:

>> @huishi-hs See the "Integration blocker" section in the PR body; you have a JBS issue and PR title mismatch.
>
> After review PR/commit title is changed to align with JBS title to add ready label

Can you sync up your branch (the bot is saying that it's 140 commits behind the main line)? I can sponsor once it has been tested with an up to date branch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1070

From Alan.Bateman at oracle.com  Sun Nov 15 07:45:59 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 15 Nov 2020 07:45:59 +0000
Subject: RFR: 8253280: Use class name as class loading lock
In-Reply-To: <CA+879repJkbq=zEpAarPyq1sWt09LmFbOP-HaCbZYxycyHA5VA@mail.gmail.com>
References: <CA+879repJkbq=zEpAarPyq1sWt09LmFbOP-HaCbZYxycyHA5VA@mail.gmail.com>
Message-ID: <e9f2d1e4-399f-660e-6fd5-2a5f6ae8841e@oracle.com>

Robert,

I think you need to start a discussion on serviceability-dev about the 
diagnostic challenges in this area before proposing API changes to 
java.lang.management that have wider implications and potential interop 
issues. It might be that your starting point is the thread dump instead.

-Alan

On 14/11/2020 16:26, Robert Lu wrote:
> When many thread try to load same class, the thread will stuck on
> ClassLoader.loadClass.
>
> At current jdk, the stacktrace by example program is:
>
> "Thread-1" prio=5 Id=12 BLOCKED on java.lang.Object at 2e817b38 owned by
> "Thread-0" Id=11
>          at java.base at 15/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:616)
>          -  blocked on java.lang.Object at 2e817b38
>          at java.base at 15/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:604)
>          at java.base at 15/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:168)
>          at java.base at 15/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
>          at app//Main.test(Main.java:19)
>          at app//Main$$Lambda$2/0x0000000800b8c468.run(Unknown Source)
>          at java.base at 15/java.lang.Thread.run(Thread.java:832)
>
> There is no way to get which class stuck the thread.
>
> *After this patch, the stacktrace will be*:
>
> "Thread-1" prio=5 Id=13 BLOCKED on java.lang.String at 724af044 owned by
> "Thread-0" Id=12
>          at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:646)
>          -  blocked on java.lang.String at 724af044 val="java.lang.String"
>          at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:634)
>          at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:182)
>          at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
>          at app//Main2.test(Main2.java:19)
>          at app//Main2$$Lambda$37/0x00000001000c2a20.run(Unknown Source)
>          at java.base/java.lang.Thread.run(Thread.java:831)
>
> That is, user will know which class stuck the thread, in this example, the
> class is java.lang.String. It's helpful for troubleshooting.
> The example program:
>
> // Main2.javaimport java.io.PrintStream;import java.lang.management.*;
> public final class Main2 {
>      private synchronized static void test1() {
>          while (true) {
>              try {
>                  Thread.sleep(1000);
>              } catch (InterruptedException e) {
>                  e.printStackTrace();
>              }
>          }
>      }
>
>      private static void test() {
>          while (true) {
>              try {
>                  Main2.class.getClassLoader().loadClass("java.lang.String");
>              } catch (ClassNotFoundException e) {
>              }
>          }
>      }
>
>      public static void main(String[] args) throws
> InterruptedException, NoSuchFieldException, IllegalAccessException {
>          new Thread(Main2::test).start();
>          new Thread(Main2::test).start();
>          new Thread(Main2::test).start();
>          new Thread(Main2::test).start();
>          new Thread(Main2::test).start();
>
>          while (true) {
>              Thread.sleep(1000);
>              ThreadMXBean bean = ManagementFactory.getThreadMXBean();
>              ThreadInfo[] infos = bean.dumpAllThreads(true, true);
>              for (ThreadInfo info : infos) {
>                  System.out.println(printThreadInfo(info));
>              }
>          }
>      }
>
>      private static String printThreadInfo(ThreadInfo threadInfo) {
>          StringBuilder sb = new StringBuilder("\"" +
> threadInfo.getThreadName() + "\"" +
>                  (threadInfo.isDaemon() ? " daemon" : "") +
>                  " prio=" + threadInfo.getPriority() +
>                  " Id=" + threadInfo.getThreadId() + " " +
>                  threadInfo.getThreadState());
>          if (threadInfo.getLockName() != null) {
>              sb.append(" on " + threadInfo.getLockName());
>          }
>          if (threadInfo.getLockOwnerName() != null) {
>              sb.append(" owned by \"" + threadInfo.getLockOwnerName() +
>                      "\" Id=" + threadInfo.getLockOwnerId());
>          }
>          if (threadInfo.isSuspended()) {
>              sb.append(" (suspended)");
>          }
>          if (threadInfo.isInNative()) {
>              sb.append(" (in native)");
>          }
>          sb.append('\n');
>          int i = 0;
>          StackTraceElement[] stackTrace = threadInfo.getStackTrace();
>          for (; i < stackTrace.length; i++) {
>              StackTraceElement ste = stackTrace[i];
>              sb.append("\tat " + ste.toString());
>              sb.append('\n');
>              if (i == 0 && threadInfo.getLockInfo() != null) {
>                  Thread.State ts = threadInfo.getThreadState();
>                  switch (ts) {
>                      case BLOCKED:
>                          sb.append("\t-  blocked on " +
> printLockInfo(threadInfo.getLockInfo()));
>                          sb.append('\n');
>                          break;
>                      case WAITING:
>                          sb.append("\t-  waiting on " +
> printLockInfo(threadInfo.getLockInfo()));
>                          sb.append('\n');
>                          break;
>                      case TIMED_WAITING:
>                          sb.append("\t-  waiting on " +
> printLockInfo(threadInfo.getLockInfo()));
>                          sb.append('\n');
>                          break;
>                      default:
>                  }
>              }
>
>              for (MonitorInfo mi : threadInfo.getLockedMonitors()) {
>                  if (mi.getLockedStackDepth() == i) {
>                      sb.append("\t-  locked " + printLockInfo(mi));
>                      sb.append('\n');
>                  }
>              }
>          }
>          if (i < stackTrace.length) {
>              sb.append("\t...");
>              sb.append('\n');
>          }
>
>          LockInfo[] locks = threadInfo.getLockedSynchronizers();
>          if (locks.length > 0) {
>              sb.append("\n\tNumber of locked synchronizers = " + locks.length);
>              sb.append('\n');
>              for (LockInfo li : locks) {
>                  sb.append("\t- " + printLockInfo(li));
>                  sb.append('\n');
>              }
>          }
>          sb.append('\n');
>          return sb.toString();
>      }
>
>      private static String printLockInfo(LockInfo li) {
>          String res = li.getClassName() + '@' +
> Integer.toHexString(li.getIdentityHashCode());
>          // There is no getLock method in current jdk
>          if (li.getStringValue() != null) {
>              return res + " val=\"" + li.getStringValue() + "\"";
>          }
>          return res;
>      }
> }
>
>
> ----------
>
> Commit messages:
>   - 8253280: Use class name as class loading lock
>
> Changes: https://github.com/openjdk/jdk/pull/104/files
>   Webrev: https://openjdk.github.io/cr/?repo=jdk&pr=104&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8253280
>    Stats:  74 lines changed; 73 ins; 1 del
>    Patch: https://git.openjdk.java.net/jdk/pull/104.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/104/head:pull/104
>
> PR: https://git.openjdk.java.net/jdk/pull/104
>
>


From herrick at openjdk.java.net  Sun Nov 15 19:09:07 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Sun, 15 Nov 2020 19:09:07 GMT
Subject: RFR: JDK-8189198: Add "forRemoval = true" to Applet APIs [v4]
In-Reply-To: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
References: <utCNZGBwBp_gbQabtwrNXFmZshdxtZyUXtky6CiTEfw=.91b0d9a6-f16d-482f-ba22-697b8a41ae16@github.com>
Message-ID: <n07B5X31Of1E-zQbdfwwtShOQ54zESY2s6oQQ8npBNU=.1beb38c9-1241-44cb-bf64-e64e0c9b3ea5@github.com>

> JDK-8189198: Add "forRemoval = true" to Applet APIs

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8189198: Add "forRemoval = true" to Applet APIs

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1127/files
  - new: https://git.openjdk.java.net/jdk/pull/1127/files/c6ea7714..bc781bea

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1127&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1127.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1127/head:pull/1127

PR: https://git.openjdk.java.net/jdk/pull/1127

From jfranck at openjdk.java.net  Sun Nov 15 19:55:58 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Sun, 15 Nov 2020 19:55:58 GMT
Subject: RFR: 8202471: Make type annotations on owner type parameters
 available [v4]
In-Reply-To: <kQyOv9xmyNPvRKuHMG9b6ev3HV7pt_GGAZe_ki12vgM=.8afc6c47-a01c-432e-9739-9c69bc121932@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
 <kQyOv9xmyNPvRKuHMG9b6ev3HV7pt_GGAZe_ki12vgM=.8afc6c47-a01c-432e-9739-9c69bc121932@github.com>
Message-ID: <C2tGe1trZxOHp7r30wi_6ll_QuCIOjwez5K7qrJUqKo=.9ff1a7a8-be4d-4e9b-bf57-c809372c88a0@github.com>

On Sat, 31 Oct 2020 21:11:15 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.
>
> 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.

Hi Rafael,

Thanks for your patience and  for the patch, I left a few comments.

src/java.base/share/classes/java/lang/reflect/Constructor.java line 664:

> 662:         Type t;
> 663:         if (o != null || v.length > 0) {
> 664:             t = ParameterizedTypeImpl.make(enclosingClass, v, o);

I think these should be instantiated by a GenericsFactory. Ideally you shouldn't have to import the reflective object directly.

src/java.base/share/classes/java/lang/reflect/Constructor.java line 660:

> 658:         }
> 659: 
> 660:         TypeVariable<?>[] v = enclosingClass.getTypeParameters();

Can you push down most or all of this to resolveOwner? It can then either return a Class instance or an appropriate Type instance.

src/java.base/share/classes/java/lang/reflect/Executable.java line 699:

> 697:         }
> 698:         Class<?> c = getDeclaringClass();
> 699:         TypeVariable<?>[] v = c.getTypeParameters();

Same here, can this be pushed down to a common method that either returns a Class or resolves the appropriate Type instance?

test/jdk/java/lang/annotation/typeAnnotations/TestReceiverTypeParameterizedConstructor.java line 52:

> 50:         Inner(TestReceiverTypeParameterizedConstructor<@TypeAnnotation T> TestReceiverTypeParameterizedConstructor.this) { }
> 51:     }
> 52: 

It might be good to add a case where the annotated type variable isn't on the immediate outer type like:

    class Inner2 {
        class  TwiceInner {
            TwiceInner(TestReceiverTypeParameterizedConstructor<@TypeAnnotation T>.Inner2 TestReceiverTypeParameterizedConstructor.Inner2.this) { }
        }
    }

Same for the method test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/851

From winterhalter at openjdk.java.net  Sun Nov 15 23:17:28 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Sun, 15 Nov 2020 23:17:28 GMT
Subject: RFR: 8202471: (ann) Cannot read type annotations on generic
 receiver type's type variables [v5]
In-Reply-To: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
Message-ID: <lh_yM9f7SE6XY51aR2eRrQ5CNi2DoNdSCLiyCJQJYH0=.6bd96b5f-e9d8-451f-95b2-36a2a266fd38@github.com>

> A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

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:

  8202471: A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/851/files
  - new: https://git.openjdk.java.net/jdk/pull/851/files/ac306162..9e4c2037

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=851&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=851&range=03-04

  Stats: 170 lines in 5 files changed: 136 ins; 28 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/851.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/851/head:pull/851

PR: https://git.openjdk.java.net/jdk/pull/851

From winterhalter at openjdk.java.net  Sun Nov 15 23:17:30 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Sun, 15 Nov 2020 23:17:30 GMT
Subject: RFR: 8202471: (ann) Cannot read type annotations on generic
 receiver type's type variables [v4]
In-Reply-To: <C2tGe1trZxOHp7r30wi_6ll_QuCIOjwez5K7qrJUqKo=.9ff1a7a8-be4d-4e9b-bf57-c809372c88a0@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
 <kQyOv9xmyNPvRKuHMG9b6ev3HV7pt_GGAZe_ki12vgM=.8afc6c47-a01c-432e-9739-9c69bc121932@github.com>
 <C2tGe1trZxOHp7r30wi_6ll_QuCIOjwez5K7qrJUqKo=.9ff1a7a8-be4d-4e9b-bf57-c809372c88a0@github.com>
Message-ID: <itbJ0zs0Moj9e7LCFcCf6wRKUQYrcszMfr-UhIvncGs=.409c5dc5-8692-408b-8b1a-d0969739fc56@github.com>

On Sun, 15 Nov 2020 19:49:57 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> 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:
>> 
>>   8202471: A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.
>
> test/jdk/java/lang/annotation/typeAnnotations/TestReceiverTypeParameterizedConstructor.java line 52:
> 
>> 50:         Inner(TestReceiverTypeParameterizedConstructor<@TypeAnnotation T> TestReceiverTypeParameterizedConstructor.this) { }
>> 51:     }
>> 52: 
> 
> It might be good to add a case where the annotated type variable isn't on the immediate outer type like:
> 
>     class Inner2 {
>         class  TwiceInner {
>             TwiceInner(TestReceiverTypeParameterizedConstructor<@TypeAnnotation T>.Inner2 TestReceiverTypeParameterizedConstructor.Inner2.this) { }
>         }
>     }
> 
> Same for the method test.

I added two tests for it.

> src/java.base/share/classes/java/lang/reflect/Executable.java line 699:
> 
>> 697:         }
>> 698:         Class<?> c = getDeclaringClass();
>> 699:         TypeVariable<?>[] v = c.getTypeParameters();
> 
> Same here, can this be pushed down to a common method that either returns a Class or resolves the appropriate Type instance?

I moved it to an annotation factory class and avoided the import.

> src/java.base/share/classes/java/lang/reflect/Constructor.java line 660:
> 
>> 658:         }
>> 659: 
>> 660:         TypeVariable<?>[] v = enclosingClass.getTypeParameters();
> 
> Can you push down most or all of this to resolveOwner? It can then either return a Class instance or an appropriate Type instance.

Pushed it down to the factory.

> src/java.base/share/classes/java/lang/reflect/Constructor.java line 664:
> 
>> 662:         Type t;
>> 663:         if (o != null || v.length > 0) {
>> 664:             t = ParameterizedTypeImpl.make(enclosingClass, v, o);
> 
> I think these should be instantiated by a GenericsFactory. Ideally you shouldn't have to import the reflective object directly.

I added it to the existing generics factory but as a static method since the instance values are not really required.

-------------

PR: https://git.openjdk.java.net/jdk/pull/851

From winterhalter at openjdk.java.net  Sun Nov 15 23:25:22 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Sun, 15 Nov 2020 23:25:22 GMT
Subject: RFR: 8202471: (ann) Cannot read type annotations on generic
 receiver type's type variables [v6]
In-Reply-To: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
Message-ID: <ytGIvACtcH3eCRNaqjTkYpzlzxcHXe2u2JnjoDHIlWk=.5fd669a6-f5b8-4a2e-91ee-ff0a8ab0f88e@github.com>

> A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

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:

  8202471: A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/851/files
  - new: https://git.openjdk.java.net/jdk/pull/851/files/9e4c2037..f043f685

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=851&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=851&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/851.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/851/head:pull/851

PR: https://git.openjdk.java.net/jdk/pull/851

From david.holmes at oracle.com  Mon Nov 16 05:55:59 2020
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 16 Nov 2020 15:55:59 +1000
Subject: RFR: 8253280: Use class name as class loading lock
In-Reply-To: <5DnzvOcYJwLegT48SxwqBUqvg8HnihAgaqUpdraS3CU=.516c26fb-e88f-4b7f-9090-26f770e54f05@github.com>
References: <5DnzvOcYJwLegT48SxwqBUqvg8HnihAgaqUpdraS3CU=.516c26fb-e88f-4b7f-9090-26f770e54f05@github.com>
Message-ID: <d682a617-f668-a0e9-e751-4041216740f7@oracle.com>

Hi Robert,

I have to agree with Mandy and Alan here. What you propose, in terms of 
getting more visibility into which class the classloader is trying to 
load, is quite reasonable. But the mechanism is quite problematic for a 
number of reasons as Mandy mentioned. In particular platform code needs 
to avoid calling toString() on user-defined objects as it can do anything.

Also note that java.lang.String is not a good example here as you should 
never be loading it (or any core class) explicitly via a user-defined 
classloader.

On 15/11/2020 2:06 am, Robert LU wrote:
> When many thread try to load same class, the thread will stuck on `ClassLoader.loadClass`.
> At current jdk, the stacktrace by example program is:
> "Thread-1" prio=5 Id=13 BLOCKED on java.lang.String at 724af044 owned by "Thread-0" Id=12
>          at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:646)
>          -  blocked on java.lang.String at 724af044 val="java.lang.String"

This seems to be the after case, not before.

Cheers,
David
-----


>          at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:634)
>          at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:182)
>          at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:519)
>          at app//Main2.test(Main2.java:19)
>          at app//Main2$$Lambda$37/0x00000001000c2a20.run(Unknown Source)
>          at java.base/java.lang.Thread.run(Thread.java:831)
> There is no way to get which class stuck the thread.
> 
> **After this patch, the stacktrace will be**:
> "Thread-2" prio=5 Id=13 BLOCKED on java.lang.String at 724af044 owned by "Thread-3" Id=14
> 	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:612)
> 	-  blocked on java.lang.String at 724af044 val="java.lang.String"
> 	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:600)
> 	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:178)
> 	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
> 	at app//Main2.test(Main2.java:18)
> 	at app//Main2$$Lambda$38/0x0000000100097440.run(Unknown Source)
> 	at java.base/java.lang.Thread.run(Thread.java:832)
> That is, user will know which class stuck the thread, in this example, the class is `java.lang.String`. It's helpful for troubleshooting.
> 
> The example program:
> Before patch:
> <details>
> <summary>Main.java</summary>
> 
> // Main.java
> import java.io.PrintStream;
> import java.lang.management.*;
> 
> public final class Main {
>      private synchronized static void test1() {
>          while (true) {
>              try {
>                  Thread.sleep(1000);
>              } catch (InterruptedException e) {
>                  e.printStackTrace();
>              }
>          }
>      }
> 
>      private static void test() {
>          while (true) {
>              try {
>                  Main.class.getClassLoader().loadClass("java.lang.String");
>              } catch (ClassNotFoundException e) {
>              }
>          }
>      }
> 
>      public static void main(String[] args) throws InterruptedException, NoSuchFieldException, IllegalAccessException {
>          new Thread(Main::test).start();
>          new Thread(Main::test).start();
>          new Thread(Main::test).start();
>          new Thread(Main::test).start();
>          new Thread(Main::test).start();
> 
>          while (true) {
>              Thread.sleep(1000);
>              ThreadMXBean bean = ManagementFactory.getThreadMXBean();
>              ThreadInfo[] infos = bean.dumpAllThreads(true, true);
>              for (ThreadInfo info : infos) {
>                  System.out.println(printThreadInfo(info));
>              }
>          }
>      }
> 
>      private static String printThreadInfo(ThreadInfo threadInfo) {
>          StringBuilder sb = new StringBuilder(""" + threadInfo.getThreadName() + """ +
>                  (threadInfo.isDaemon() ? " daemon" : "") +
>                  " prio=" + threadInfo.getPriority() +
>                  " Id=" + threadInfo.getThreadId() + " " +
>                  threadInfo.getThreadState());
>          if (threadInfo.getLockName() != null) {
>              sb.append(" on " + threadInfo.getLockName());
>          }
>          if (threadInfo.getLockOwnerName() != null) {
>              sb.append(" owned by "" + threadInfo.getLockOwnerName() +
>                      "" Id=" + threadInfo.getLockOwnerId());
>          }
>          if (threadInfo.isSuspended()) {
>              sb.append(" (suspended)");
>          }
>          if (threadInfo.isInNative()) {
>              sb.append(" (in native)");
>          }
>          sb.append('\n');
>          int i = 0;
>          StackTraceElement[] stackTrace = threadInfo.getStackTrace();
>          for (; i < stackTrace.length; i++) {
>              StackTraceElement ste = stackTrace[i];
>              sb.append("\tat " + ste.toString());
>              sb.append('\n');
>              if (i == 0 && threadInfo.getLockInfo() != null) {
>                  Thread.State ts = threadInfo.getThreadState();
>                  switch (ts) {
>                      case BLOCKED:
>                          sb.append("\t-  blocked on " + printLockInfo(threadInfo.getLockInfo()));
>                          sb.append('\n');
>                          break;
>                      case WAITING:
>                          sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
>                          sb.append('\n');
>                          break;
>                      case TIMED_WAITING:
>                          sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
>                          sb.append('\n');
>                          break;
>                      default:
>                  }
>              }
> 
>              for (MonitorInfo mi : threadInfo.getLockedMonitors()) {
>                  if (mi.getLockedStackDepth() == i) {
>                      sb.append("\t-  locked " + printLockInfo(mi));
>                      sb.append('\n');
>                  }
>              }
>          }
>          if (i < stackTrace.length) {
>              sb.append("\t...");
>              sb.append('\n');
>          }
> 
>          LockInfo[] locks = threadInfo.getLockedSynchronizers();
>          if (locks.length > 0) {
>              sb.append("\n\tNumber of locked synchronizers = " + locks.length);
>              sb.append('\n');
>              for (LockInfo li : locks) {
>                  sb.append("\t- " + printLockInfo(li));
>                  sb.append('\n');
>              }
>          }
>          sb.append('\n');
>          return sb.toString();
>      }
> 
>      private static String printLockInfo(LockInfo li) {
>          String res = li.getClassName() + '@' + Integer.toHexString(li.getIdentityHashCode());
>          return res;
>      }
> }
> </details>
> After patch:
> <details>
> <summary>Main2.java</summary>
> 
> // Main2.java
> import java.io.PrintStream;
> import java.lang.management.*;
> 
> public final class Main2 {
>      private synchronized static void test1() {
>          while (true) {
>              try {
>                  Thread.sleep(1000);
>              } catch (InterruptedException e) {
>                  e.printStackTrace();
>              }
>          }
>      }
> 
>      private static void test() {
>          while (true) {
>              try {
>                  Main2.class.getClassLoader().loadClass("java.lang.String");
>              } catch (ClassNotFoundException e) {
>              }
>          }
>      }
> 
>      public static void main(String[] args) throws InterruptedException, NoSuchFieldException, IllegalAccessException {
>          new Thread(Main2::test).start();
>          new Thread(Main2::test).start();
>          new Thread(Main2::test).start();
>          new Thread(Main2::test).start();
>          new Thread(Main2::test).start();
> 
>          while (true) {
>              Thread.sleep(1000);
>              ThreadMXBean bean = ManagementFactory.getThreadMXBean();
>              ThreadInfo[] infos = bean.dumpAllThreads(true, true);
>              for (ThreadInfo info : infos) {
>                  System.out.println(printThreadInfo(info));
>              }
>          }
>      }
> 
>      private static String printThreadInfo(ThreadInfo threadInfo) {
>          StringBuilder sb = new StringBuilder(""" + threadInfo.getThreadName() + """ +
>                  (threadInfo.isDaemon() ? " daemon" : "") +
>                  " prio=" + threadInfo.getPriority() +
>                  " Id=" + threadInfo.getThreadId() + " " +
>                  threadInfo.getThreadState());
>          if (threadInfo.getLockName() != null) {
>              sb.append(" on " + threadInfo.getLockName());
>          }
>          if (threadInfo.getLockOwnerName() != null) {
>              sb.append(" owned by "" + threadInfo.getLockOwnerName() +
>                      "" Id=" + threadInfo.getLockOwnerId());
>          }
>          if (threadInfo.isSuspended()) {
>              sb.append(" (suspended)");
>          }
>          if (threadInfo.isInNative()) {
>              sb.append(" (in native)");
>          }
>          sb.append('\n');
>          int i = 0;
>          StackTraceElement[] stackTrace = threadInfo.getStackTrace();
>          for (; i < stackTrace.length; i++) {
>              StackTraceElement ste = stackTrace[i];
>              sb.append("\tat " + ste.toString());
>              sb.append('\n');
>              if (i == 0 && threadInfo.getLockInfo() != null) {
>                  Thread.State ts = threadInfo.getThreadState();
>                  switch (ts) {
>                      case BLOCKED:
>                          sb.append("\t-  blocked on " + printLockInfo(threadInfo.getLockInfo()));
>                          sb.append('\n');
>                          break;
>                      case WAITING:
>                          sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
>                          sb.append('\n');
>                          break;
>                      case TIMED_WAITING:
>                          sb.append("\t-  waiting on " + printLockInfo(threadInfo.getLockInfo()));
>                          sb.append('\n');
>                          break;
>                      default:
>                  }
>              }
> 
>              for (MonitorInfo mi : threadInfo.getLockedMonitors()) {
>                  if (mi.getLockedStackDepth() == i) {
>                      sb.append("\t-  locked " + printLockInfo(mi));
>                      sb.append('\n');
>                  }
>              }
>          }
>          if (i < stackTrace.length) {
>              sb.append("\t...");
>              sb.append('\n');
>          }
> 
>          LockInfo[] locks = threadInfo.getLockedSynchronizers();
>          if (locks.length > 0) {
>              sb.append("\n\tNumber of locked synchronizers = " + locks.length);
>              sb.append('\n');
>              for (LockInfo li : locks) {
>                  sb.append("\t- " + printLockInfo(li));
>                  sb.append('\n');
>              }
>          }
>          sb.append('\n');
>          return sb.toString();
>      }
> 
>      private static String printLockInfo(LockInfo li) {
>          String res = li.getClassName() + '@' + Integer.toHexString(li.getIdentityHashCode());
>          // There is no getLock method in current jdk
>          if (li.getStringValue() != null) {
>              return res + " val="" + li.getStringValue() + """;
>          }
>          return res;
>      }
> }
> </details>
> 
> -------------
> 
> Commit messages:
>   - 8253280: Use class name as class loading lock
> 
> Changes: https://git.openjdk.java.net/jdk/pull/104/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=104&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8253280
>    Stats: 73 lines in 5 files changed: 72 ins; 0 del; 1 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/104.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/104/head:pull/104
> 
> PR: https://git.openjdk.java.net/jdk/pull/104
> 

From winterhalter at openjdk.java.net  Mon Nov 16 06:21:55 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Mon, 16 Nov 2020 06:21:55 GMT
Subject: RFR: 8228988: AnnotationParser throws NullPointerException on
 incompatible member type
In-Reply-To: <JE30SMjxGYOwl5toXuiKli58w9oeMb6n8wG2uA_4pl4=.0e965cac-2f8d-4d8d-b8ae-9146f9389578@github.com>
References: <JE30SMjxGYOwl5toXuiKli58w9oeMb6n8wG2uA_4pl4=.0e965cac-2f8d-4d8d-b8ae-9146f9389578@github.com>
Message-ID: <jr2OkMaiC8RkbPbuP_33zWuo2Gg91e6GubcSKqI2q84=.8f83e1ef-3ce7-4340-a0fe-7c1080c31435@github.com>

On Sun, 18 Oct 2020 22:21:37 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> If an annotation member type is changed in an incompatible manner, the `AnnotationParser` currently throws a `NullPointerException` if:
> 
> - An enumeration-typed member is changed to be an annotation type or a `Class` type.
> - An annotation type is changed to be a non-annotation type.
> 
> This patch creates `AnnotationTypeMismatchExceptionProxy` to give users a better error message and to delay the exception to the time where the annotation member is attempted to be accessed.

Commenting to avoid automatic closing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/725

From hshi at openjdk.java.net  Mon Nov 16 08:45:20 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Mon, 16 Nov 2020 08:45:20 GMT
Subject: RFR: 8255883: Avoid duplicated GeneratedMethodAccessor when
 reflect method invoked from different threads [v8]
In-Reply-To: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
Message-ID: <ipuGvbOAfupegFlyHkr3K0aIhkhXiqXYvOEeACiK0Fg=.3e182f48-10e0-4acb-af7e-b2f7e935bef3@github.com>

> ?AccessorImpl object
> 
> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
> 
> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
> 
> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.

Hui Shi has updated the pull request with a new target base 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:

  8255883: Avoid duplicated GeneratedMethodAccessor when reflect method invoked from different threads

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1070/files
  - new: https://git.openjdk.java.net/jdk/pull/1070/files/98278050..e7b6d88a

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1070&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1070&range=06-07

  Stats: 110505 lines in 1385 files changed: 59994 ins; 39577 del; 10934 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1070.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1070/head:pull/1070

PR: https://git.openjdk.java.net/jdk/pull/1070

From hshi at openjdk.java.net  Mon Nov 16 09:49:01 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Mon, 16 Nov 2020 09:49:01 GMT
Subject: RFR: 8255883: Avoid duplicated GeneratedMethodAccessor when
 reflect method invoked from different threads [v6]
In-Reply-To: <GqG44Z9jSYfTRGvBAmOfkiC63LnAXwVmhHkWElEeZ2k=.25e5dea2-8e97-44f7-8ae4-e04e0ae2d685@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
 <L2o_e9o3XE1ORKMUk04eVNLHCbnUOdWCstK9jCWXzk4=.6524e841-b1dd-4b5c-ab40-ec7f033b9ece@github.com>
 <otOVI-HphtgB9WZIrX2dNU-1tmLb8I5tO29lEr7TVaY=.eddc79d4-e2b3-44cd-bb28-b7f021cdaff7@github.com>
 <MHmeYQfZdMABlaTpg2Py1fwjjQwAmcaVk3C0_pvz8xk=.55bda839-16d1-41b8-8bd8-ddde90868b8c@github.com>
 <7ETw0-y1ErydqXnnZvK3WwcrQ3kgv7zqm70f7KqBsQQ=.b5c57015-2a9e-4ccf-ae8b-1b75bb2273f6@github.com>
 <N7i3aX9MhEhhdXazp8fVuJJLUwS5djrVwNvwpfWwfR0=.224a58f5-cddf-4910-bf1e-8fd5746f8fef@github.com>
 <nhTwMqhXKiLyoImrSRyGkjX-gdWEky6SwRVcaw2j9ls=.d1b12293-920e-482e-8c83-0dd01d8b105f@github.com>
 <qRwlpYJBeTjxBNoRq8L9wdC_ntc63BVi5SPBPeIRCTw=.c3292105-76f8-4970-ac10-a56f96b736e4@github.com>
 <GqG44Z9jSYfTRGvBAmOfkiC63LnAXwVmhHkWElEeZ2k=.25e5dea2-8e97-44f7-8ae4-e04e0ae2d685@github.com>
Message-ID: <gL915mO0GpU2Mtvez5_TDFlmf-c3JYRIzDE7RrJs9Lc=.bd0e14e8-8923-45f5-8b67-a91bebdec0ab@github.com>

On Sun, 15 Nov 2020 07:25:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> After review PR/commit title is changed to align with JBS title to add ready label
>
> Can you sync up your branch (the bot is saying that it's 140 commits behind the main line)? I can sponsor once it has been tested with an up to date branch.

@AlanBateman Thanks for your sponsoring! Commit is updated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1070

From shade at openjdk.java.net  Mon Nov 16 10:27:54 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 16 Nov 2020 10:27:54 GMT
Subject: RFR: 8256037: [TESTBUG]
 com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails due to the hard coded
 threshold is small
In-Reply-To: <QuPW3Afb2RpucHhJT9NQDsmHo977-Y378EuBgcg_-B0=.07b9b5f2-8faf-434b-9e98-72a80734976f@github.com>
References: <QuPW3Afb2RpucHhJT9NQDsmHo977-Y378EuBgcg_-B0=.07b9b5f2-8faf-434b-9e98-72a80734976f@github.com>
Message-ID: <XZbrhM6joLyMfsEllKggMoSC072Gj8pc0Dwu_UlT3gM=.09bd33a7-c7f1-493d-9163-2165257c1408@github.com>

On Mon, 9 Nov 2020 09:19:44 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> May I get reviews for this change?
> 
> com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails occasionally on some of our testing platforms.
> The reason is that the hard coded Threshold (1000 ms) [1] is a little smaller than that (e.g., 1026 ms) on our platforms.
> 
> The fix just increases the threshold from 1000 ms to 3000 ms.
> Any comments?
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java#L49

This looks fine to me.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1116

From jfranck at openjdk.java.net  Mon Nov 16 10:33:58 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Mon, 16 Nov 2020 10:33:58 GMT
Subject: RFR: 8202471: (ann) Cannot read type annotations on generic
 receiver type's type variables [v6]
In-Reply-To: <ytGIvACtcH3eCRNaqjTkYpzlzxcHXe2u2JnjoDHIlWk=.5fd669a6-f5b8-4a2e-91ee-ff0a8ab0f88e@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
 <ytGIvACtcH3eCRNaqjTkYpzlzxcHXe2u2JnjoDHIlWk=.5fd669a6-f5b8-4a2e-91ee-ff0a8ab0f88e@github.com>
Message-ID: <div6W7VFuwH-gPQHv6WdRJC8G1s2hHfx-SG1mfoZWpE=.b6f8daa7-7fa2-45bb-a650-9542a36d0a80@github.com>

On Sun, 15 Nov 2020 23:25:22 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.
>
> 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.

src/java.base/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java line 93:

> 91:     }
> 92: 
> 93:     public static Type ownerType(Class<?> c) {

This feels somewhat odd. How about, moving these back to Executable and rename `ownerType` to `resolveToType` ? I realise we can't get use getFactory() in executable but as you write, it isn't needed, it should be fine in this case to create it directly as in your v1. The reason is the semantics of this is somewhat unintuitive and is only used in the annotated receiver case.

test/jdk/java/lang/annotation/typeAnnotations/TestReceiverTypeParameterizedConstructorNested.java line 36:

> 34: import java.lang.reflect.Constructor;
> 35: 
> 36: public class TestReceiverTypeParameterizedConstructorNested {

Suggestion, what I would like to test is that we can walk up the chain and find type parameters on the outermost owner. Same for Method.

-------------

PR: https://git.openjdk.java.net/jdk/pull/851

From winterhalter at openjdk.java.net  Mon Nov 16 11:10:21 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Mon, 16 Nov 2020 11:10:21 GMT
Subject: RFR: 8202471: (ann) Cannot read type annotations on generic
 receiver type's type variables [v6]
In-Reply-To: <div6W7VFuwH-gPQHv6WdRJC8G1s2hHfx-SG1mfoZWpE=.b6f8daa7-7fa2-45bb-a650-9542a36d0a80@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
 <ytGIvACtcH3eCRNaqjTkYpzlzxcHXe2u2JnjoDHIlWk=.5fd669a6-f5b8-4a2e-91ee-ff0a8ab0f88e@github.com>
 <div6W7VFuwH-gPQHv6WdRJC8G1s2hHfx-SG1mfoZWpE=.b6f8daa7-7fa2-45bb-a650-9542a36d0a80@github.com>
Message-ID: <UxUl47r0dtt46KAt-rqJpRJ84vHBsuFT5WWzj1UhUfI=.9cbeae7f-9d62-4c7a-b383-0b36fca290ea@github.com>

On Mon, 16 Nov 2020 10:29:48 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> 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.
>
> test/jdk/java/lang/annotation/typeAnnotations/TestReceiverTypeParameterizedConstructorNested.java line 36:
> 
>> 34: import java.lang.reflect.Constructor;
>> 35: 
>> 36: public class TestReceiverTypeParameterizedConstructorNested {
> 
> Suggestion, what I would like to test is that we can walk up the chain and find type parameters on the outermost owner. Same for Method.

I adjusted the test to check for an inner and outer variable for both method and constructor.

> src/java.base/share/classes/sun/reflect/generics/factory/CoreReflectionFactory.java line 93:
> 
>> 91:     }
>> 92: 
>> 93:     public static Type ownerType(Class<?> c) {
> 
> This feels somewhat odd. How about, moving these back to Executable and rename `ownerType` to `resolveToType` ? I realise we can't get use getFactory() in executable but as you write, it isn't needed, it should be fine in this case to create it directly as in your v1. The reason is the semantics of this is somewhat unintuitive and is only used in the annotated receiver case.

I moved the code back and it's fairly compact now. I added "owner" to the method name since it does not make sense otherwise. Let me know what you think!

-------------

PR: https://git.openjdk.java.net/jdk/pull/851

From winterhalter at openjdk.java.net  Mon Nov 16 11:10:19 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Mon, 16 Nov 2020 11:10:19 GMT
Subject: RFR: 8202471: (ann) Cannot read type annotations on generic
 receiver type's type variables [v7]
In-Reply-To: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
Message-ID: <PiDCNijbUz7bmcEbfNDrcWIIE3R3qs9BzAfH-glf-Lg=.7081b9c8-73e0-49fc-9265-83258a63c97a@github.com>

> A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

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:

  8202471: A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/851/files
  - new: https://git.openjdk.java.net/jdk/pull/851/files/f043f685..811afcba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=851&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=851&range=05-06

  Stats: 211 lines in 7 files changed: 55 ins; 137 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/851.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/851/head:pull/851

PR: https://git.openjdk.java.net/jdk/pull/851

From jiefu at openjdk.java.net  Mon Nov 16 11:14:55 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Mon, 16 Nov 2020 11:14:55 GMT
Subject: RFR: 8256037: [TESTBUG]
 com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails due to the hard coded
 threshold is small
In-Reply-To: <XZbrhM6joLyMfsEllKggMoSC072Gj8pc0Dwu_UlT3gM=.09bd33a7-c7f1-493d-9163-2165257c1408@github.com>
References: <QuPW3Afb2RpucHhJT9NQDsmHo977-Y378EuBgcg_-B0=.07b9b5f2-8faf-434b-9e98-72a80734976f@github.com>
 <XZbrhM6joLyMfsEllKggMoSC072Gj8pc0Dwu_UlT3gM=.09bd33a7-c7f1-493d-9163-2165257c1408@github.com>
Message-ID: <trDic8Bkcn_cmWZtzepRZHf--WSgtaRKBWKkv-5NhWw=.95547f38-27c9-4b1b-93e4-fa85bb10968c@github.com>

On Mon, 16 Nov 2020 10:24:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> This looks fine to me.

Thanks @shipilev for your review.
Will push it tomorrow if there is no objection.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1116

From jfranck at openjdk.java.net  Mon Nov 16 11:27:01 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Mon, 16 Nov 2020 11:27:01 GMT
Subject: RFR: 8202471: (ann) Cannot read type annotations on generic
 receiver type's type variables [v7]
In-Reply-To: <PiDCNijbUz7bmcEbfNDrcWIIE3R3qs9BzAfH-glf-Lg=.7081b9c8-73e0-49fc-9265-83258a63c97a@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
 <PiDCNijbUz7bmcEbfNDrcWIIE3R3qs9BzAfH-glf-Lg=.7081b9c8-73e0-49fc-9265-83258a63c97a@github.com>
Message-ID: <61cSEEF8zzcgmd-BB4Hb5xHykupW5Zyw5u6iwC3tDlg=.45cf55d5-fd5d-445f-a589-26e7f8b0a1d6@github.com>

On Mon, 16 Nov 2020 11:10:19 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.
>
> 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:
> 
>   8202471: A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

Looks good. I'll run some additional testing on the patch.

-------------

Marked as reviewed by jfranck (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/851

From mcimadamore at openjdk.java.net  Mon Nov 16 11:30:22 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 16 Nov 2020 11:30:22 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v24]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <pTUgBvtLAwO4DejxD7i7MV7qaeJE4Pem1STxw7r2-Rc=.05aceea6-7f2b-424c-82a4-86f81eab65df@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with two additional commits since the last revision:

 - Merge pull request #9 from JornVernee/Windows_Warnings
   
   Fix warnings on MSVC
 - Fix warnings on MSVC

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/739c7925..000f75d5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=23
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=22-23

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From jfranck at openjdk.java.net  Mon Nov 16 11:31:54 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Mon, 16 Nov 2020 11:31:54 GMT
Subject: RFR: 8202471: (ann) Cannot read type annotations on generic
 receiver type's type variables [v7]
In-Reply-To: <61cSEEF8zzcgmd-BB4Hb5xHykupW5Zyw5u6iwC3tDlg=.45cf55d5-fd5d-445f-a589-26e7f8b0a1d6@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
 <PiDCNijbUz7bmcEbfNDrcWIIE3R3qs9BzAfH-glf-Lg=.7081b9c8-73e0-49fc-9265-83258a63c97a@github.com>
 <61cSEEF8zzcgmd-BB4Hb5xHykupW5Zyw5u6iwC3tDlg=.45cf55d5-fd5d-445f-a589-26e7f8b0a1d6@github.com>
Message-ID: <ArUjScpwlTZz5HBMZk8xmZLz-X28MZmLr7dT2UKBQlI=.80500db5-68c5-4d88-94db-3e7302529455@github.com>

On Mon, 16 Nov 2020 11:23:47 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> 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:
>> 
>>   8202471: A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.
>
> Looks good. I'll run some additional testing on the patch.

I think it would be good to rebase on top of a recent jdk upstream before merging.

-------------

PR: https://git.openjdk.java.net/jdk/pull/851

From hshi at openjdk.java.net  Mon Nov 16 11:37:57 2020
From: hshi at openjdk.java.net (Hui Shi)
Date: Mon, 16 Nov 2020 11:37:57 GMT
Subject: Integrated: 8255883: Avoid duplicated GeneratedMethodAccessor when
 reflect method invoked from different threads
In-Reply-To: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
References: <NS2FxBm993yy_jn18aBsVwXTzffEgDiURmC3H-8prQ4=.2955cdd7-8a31-481a-a6bc-4626b7a09f70@github.com>
Message-ID: <QEVXa7jElfdQjNF-cPdKM_ja2UZMwVIWwIZUPFrIkZw=.24b5ff11-fb64-47c8-a9e9-bd70c04456ba@github.com>

On Thu, 5 Nov 2020 02:52:05 GMT, Hui Shi <hshi at openjdk.org> wrote:

> ?AccessorImpl object
> 
> We met real problem when using protobuf with option optimized for code size, detail in JBS https://bugs.openjdk.java.net/browse/JDK-8255883
> 
> Optimize solution is adding a new boolean field to detect concurrent method accessor generation in same NativeMethodAccessorImpl object, only one thread is allowed to generate accessor, other threads still invoke in jni way until parent's delegator is updated from NativeMethodAccessorImpl  to generated accessor.
> 
> In common case, extra overhead is an atomic operation, compared with method accessor generate, this cost is trivial.

This pull request has now been integrated.

Changeset: 8eeb36f1
Author:    Hui Shi <hshi at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8eeb36f1
Stats:     46 lines in 2 files changed: 28 ins; 0 del; 18 mod

8255883: Avoid duplicated GeneratedMethodAccessor when reflect method invoked from different threads

Reviewed-by: shade, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1070

From winterhalter at openjdk.java.net  Mon Nov 16 11:54:14 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Mon, 16 Nov 2020 11:54:14 GMT
Subject: RFR: 8202471: (ann) Cannot read type annotations on generic
 receiver type's type variables [v7]
In-Reply-To: <ArUjScpwlTZz5HBMZk8xmZLz-X28MZmLr7dT2UKBQlI=.80500db5-68c5-4d88-94db-3e7302529455@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
 <PiDCNijbUz7bmcEbfNDrcWIIE3R3qs9BzAfH-glf-Lg=.7081b9c8-73e0-49fc-9265-83258a63c97a@github.com>
 <61cSEEF8zzcgmd-BB4Hb5xHykupW5Zyw5u6iwC3tDlg=.45cf55d5-fd5d-445f-a589-26e7f8b0a1d6@github.com>
 <ArUjScpwlTZz5HBMZk8xmZLz-X28MZmLr7dT2UKBQlI=.80500db5-68c5-4d88-94db-3e7302529455@github.com>
Message-ID: <xHKztYOh77LVM_GQ0CDFoGsPEWOB5q9eoxS00tgAaZ4=.93beeee6-b982-485d-afec-a6383d98608a@github.com>

On Mon, 16 Nov 2020 11:28:59 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> Looks good. I'll run some additional testing on the patch.
>
> I think it would be good to rebase on top of a recent jdk upstream before merging.

Rebased on HEAD/master.

-------------

PR: https://git.openjdk.java.net/jdk/pull/851

From winterhalter at openjdk.java.net  Mon Nov 16 11:54:14 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Mon, 16 Nov 2020 11:54:14 GMT
Subject: RFR: 8202471: (ann) Cannot read type annotations on generic
 receiver type's type variables [v8]
In-Reply-To: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
Message-ID: <XE9eDxv-s1T2lBfiXyQUvg8hfd8EKaHRLTTejhAeLCE=.7df0fdda-10c8-41be-ad24-111d459fbb66@github.com>

> A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

Rafael Winterhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8202471: A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

-------------

Changes: https://git.openjdk.java.net/jdk/pull/851/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=851&range=07
  Stats: 242 lines in 7 files changed: 235 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/851.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/851/head:pull/851

PR: https://git.openjdk.java.net/jdk/pull/851

From winterhalter at openjdk.java.net  Mon Nov 16 11:55:20 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Mon, 16 Nov 2020 11:55:20 GMT
Subject: RFR: 8228988: AnnotationParser throws NullPointerException on
 incompatible member type [v2]
In-Reply-To: <JE30SMjxGYOwl5toXuiKli58w9oeMb6n8wG2uA_4pl4=.0e965cac-2f8d-4d8d-b8ae-9146f9389578@github.com>
References: <JE30SMjxGYOwl5toXuiKli58w9oeMb6n8wG2uA_4pl4=.0e965cac-2f8d-4d8d-b8ae-9146f9389578@github.com>
Message-ID: <GT69hsxwVeop5OSVI99OeOmH4J318kKL6ozP4PEt5GM=.65a57bcc-a852-4b94-a629-53b88e4a20b4@github.com>

> If an annotation member type is changed in an incompatible manner, the `AnnotationParser` currently throws a `NullPointerException` if:
> 
> - An enumeration-typed member is changed to be an annotation type or a `Class` type.
> - An annotation type is changed to be a non-annotation type.
> 
> This patch creates `AnnotationTypeMismatchExceptionProxy` to give users a better error message and to delay the exception to the time where the annotation member is attempted to be accessed.

Rafael Winterhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  8228988: AnnotationParser throws NullPointerException on incompatible member type

-------------

Changes: https://git.openjdk.java.net/jdk/pull/725/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=725&range=01
  Stats: 174 lines in 3 files changed: 170 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/725.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/725/head:pull/725

PR: https://git.openjdk.java.net/jdk/pull/725

From mcimadamore at openjdk.java.net  Mon Nov 16 12:38:05 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 16 Nov 2020 12:38:05 GMT
Subject: RFR: JDK-8254162 broke 32bit windows build
Message-ID: <kzDAPqIblPvJGBBHTDnk05doKpkU7CvtjGSEGMyIzmI=.d57d57b8-456c-4ba7-8a23-acbd4abbc8ef@github.com>

This simple patch fixes a build issue on Windows x86 introduced by the new scoped memory access changes. The culprit is a signature mismatch between hpp and cpp function definition.

-------------

Commit messages:
 - Fix build issue on Windows x86

Changes: https://git.openjdk.java.net/jdk/pull/1224/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1224&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254162
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1224.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1224/head:pull/1224

PR: https://git.openjdk.java.net/jdk/pull/1224

From shade at openjdk.java.net  Mon Nov 16 12:42:53 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 16 Nov 2020 12:42:53 GMT
Subject: RFR: JDK-8254162 broke 32bit windows build
In-Reply-To: <kzDAPqIblPvJGBBHTDnk05doKpkU7CvtjGSEGMyIzmI=.d57d57b8-456c-4ba7-8a23-acbd4abbc8ef@github.com>
References: <kzDAPqIblPvJGBBHTDnk05doKpkU7CvtjGSEGMyIzmI=.d57d57b8-456c-4ba7-8a23-acbd4abbc8ef@github.com>
Message-ID: <-HVGSZJdS0-Te1Nb7_4BxyYCIRBqoAwatZLrM-pyjSE=.cc68d497-4407-4942-ad70-27b2142a9258@github.com>

On Mon, 16 Nov 2020 12:30:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This simple patch fixes a build issue on Windows x86 introduced by the new scoped memory access changes. The culprit is a signature mismatch between hpp and cpp function definition.

Already handled by #1222 ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1224

From mcimadamore at openjdk.java.net  Mon Nov 16 12:54:37 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 16 Nov 2020 12:54:37 GMT
Subject: Withdrawn: JDK-8254162 broke 32bit windows build
In-Reply-To: <kzDAPqIblPvJGBBHTDnk05doKpkU7CvtjGSEGMyIzmI=.d57d57b8-456c-4ba7-8a23-acbd4abbc8ef@github.com>
References: <kzDAPqIblPvJGBBHTDnk05doKpkU7CvtjGSEGMyIzmI=.d57d57b8-456c-4ba7-8a23-acbd4abbc8ef@github.com>
Message-ID: <_EPGcxFWatPfhohH-P4x4meQdoq_PKA1Fg5mEL12TK8=.28051173-e0ec-4e9b-857b-fbf013ead697@github.com>

On Mon, 16 Nov 2020 12:30:53 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This simple patch fixes a build issue on Windows x86 introduced by the new scoped memory access changes. The culprit is a signature mismatch between hpp and cpp function definition.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1224

From mcimadamore at openjdk.java.net  Mon Nov 16 13:05:30 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 16 Nov 2020 13:05:30 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v25]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <WBtn6kr1fgUqHDw8IlEe_8sIaQEqmpugpRbl6VzjE3Q=.34c765af-75c2-4816-b239-30957a45d4fb@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix signature mismatch on aarch64

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/000f75d5..3999a188

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=24
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=23-24

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From aefimov at openjdk.java.net  Mon Nov 16 13:35:05 2020
From: aefimov at openjdk.java.net (Aleksei Efimov)
Date: Mon, 16 Nov 2020 13:35:05 GMT
Subject: RFR: 8256037: [TESTBUG]
 com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails due to the hard coded
 threshold is small
In-Reply-To: <QuPW3Afb2RpucHhJT9NQDsmHo977-Y378EuBgcg_-B0=.07b9b5f2-8faf-434b-9e98-72a80734976f@github.com>
References: <QuPW3Afb2RpucHhJT9NQDsmHo977-Y378EuBgcg_-B0=.07b9b5f2-8faf-434b-9e98-72a80734976f@github.com>
Message-ID: <LS25XTpiuOfodcTl0Odx9mNAxN9hKcfPjrMkq2u5QhQ=.2845ed51-7c18-4e01-9ad4-12e06e76559e@github.com>

On Mon, 9 Nov 2020 09:19:44 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> May I get reviews for this change?
> 
> com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails occasionally on some of our testing platforms.
> The reason is that the hard coded Threshold (1000 ms) [1] is a little smaller than that (e.g., 1026 ms) on our platforms.
> 
> The fix just increases the threshold from 1000 ms to 3000 ms.
> Any comments?
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java#L49

Hi @DamonFool,
Change looks good to me since 3 seconds is less than 15 seconds of the full timeout.

The full timeout interval which is mentioned in the test summary is 15 s:
4 retries with initial timeout set to 1s: 1 + 2 + 4 + 8 = 15 s

-------------

Marked as reviewed by aefimov (Committer).

PR: https://git.openjdk.java.net/jdk/pull/1116

From vromero at openjdk.java.net  Mon Nov 16 13:36:13 2020
From: vromero at openjdk.java.net (Vicente Romero)
Date: Mon, 16 Nov 2020 13:36:13 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
Message-ID: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>

Please review the code for the second iteration of sealed classes. In this iteration we are:

- Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies.
- Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface

-------------

Commit messages:
 - 8246778: Compiler implementation for Sealed Classes (Second Preview)

Changes: https://git.openjdk.java.net/jdk/pull/1227/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
  Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1227/head:pull/1227

PR: https://git.openjdk.java.net/jdk/pull/1227

From alanb at openjdk.java.net  Mon Nov 16 13:52:06 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 16 Nov 2020 13:52:06 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
Message-ID: <X7lXs0tULkwp6dM67oHD8HBn_z5HaGbePo30unGhDbc=.566b1f26-9888-4e1b-9cce-4ac5be762259@github.com>

On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review the code for the second iteration of sealed classes. In this iteration we are:
> 
> - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
> - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
> - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
> - adding code to make sure that annotations can't be sealed
> - improving some tests
> 
> TIA
> 
> Related specs:
> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)

src/java.base/share/classes/java/lang/Package.java line 227:

> 225:      * This method reports on a distinct concept of sealing from
> 226:      * {@link Class#isSealed() Class::isSealed}.
> 227:      *

This API note will be very confusing to readers. I think the javadoc will need to be fleshed out and probably will need to link to a section the Package class description that defines the legacy concept of sealing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1227

From mcimadamore at openjdk.java.net  Mon Nov 16 14:01:04 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 16 Nov 2020 14:01:04 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
Message-ID: <zAzRRkn9tXvuua8s5NnBE9zs409-pHY6WCW9y9uwiEo=.9a24bee1-a3a7-4da4-81bb-a332848a5ba3@github.com>

On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review the code for the second iteration of sealed classes. In this iteration we are:
> 
> - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
> - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
> - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
> - adding code to make sure that annotations can't be sealed
> - improving some tests
> 
> TIA
> 
> Related specs:
> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)

I left some comments re. the changes in cast conversion routine

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1659:

> 1657:             result = isCastable.visit(t,s);
> 1658:         }
> 1659:         if ((t.tsym.isSealed() || s.tsym.isSealed())) {

It would probably be better to only run this extra check if `result == true`, to minimize compatibility impact.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 1672:

> 1670:             }
> 1671:             // if both are classes or both are interfaces, shortcut
> 1672:             if (ts.isInterface() == ss.isInterface()) {

What happens with code like this?

interface A permits B { }
non-sealed interface B extends A { }
interface C { }

class D implements C, B { } // this is a valid witness for both A and C, but A and C are unrelated with subtyping

class Test {
  void m(A a, C c) {
     a = (A)c;
  }
}```
Note that, w/o sealed types, the above snippet compiles ok - e.g. casting C to A is not going to give problems (as there could be a common subtype D <: A, C).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1227

From Marius at volkhart.com  Mon Nov 16 14:16:24 2020
From: Marius at volkhart.com (Marius Volkhart)
Date: Mon, 16 Nov 2020 15:16:24 +0100
Subject: Fwd: Fix: javax.xml.XMLEventReader produces incorrect START_DOCUMENT
 event
In-Reply-To: <CAEi2yB_hd9ieug7WadpwrSgzyKz+ZsdwqD2OdQ6Fnw-8aG6p5Q@mail.gmail.com>
References: <CAEi2yB_hd9ieug7WadpwrSgzyKz+ZsdwqD2OdQ6Fnw-8aG6p5Q@mail.gmail.com>
Message-ID: <CAEi2yB8Kd4TYPd=wqWU1KWyFRygHY3w2+pDdt3BjS5yPt5euvA@mail.gmail.com>

Hello,

I've submitted a PR https://github.com/openjdk/jdk/pull/1056 for what I
believe to be a bug I found in the javax.xml module. An issue for this
behavior does not exist in the bug tracker, and I do not have a OpenJDK
account so I can't open an issue.

The default implementation of javax.xml.stream.XMLEventReader produces a
StartDocument event that always indicates that the "standalone" attribute
was set in the original document.

The root cause of this is that the
com.sun.xml.internal.stream.events.XMLEventAllocatorImpl always set the
"standalone" attribute, rather than asking streamReader.standaloneSet()
before setting the property of the StartDocumentEvent being created.

--
Cheers,
Marius Volkhart

From herrick at openjdk.java.net  Mon Nov 16 15:20:10 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 16 Nov 2020 15:20:10 GMT
Subject: RFR: JDK-8255055: Create two phase test for case with different names,
 =?UTF-8?B?YW5k4oCm?=
Message-ID: <zoptCE9lKZ7D837MlSOcBNzsLtMkBH0yey6wDct8b2c=.aef04c82-1e5e-4f5d-b8f6-afc76774d1cb@github.com>

? fix linux DTI

-------------

Commit messages:
 - JDK-8255055: Create two phase test for case with different names, and fix linux DTI

Changes: https://git.openjdk.java.net/jdk/pull/1229/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1229&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255055
  Stats: 37 lines in 6 files changed: 22 ins; 3 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1229.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1229/head:pull/1229

PR: https://git.openjdk.java.net/jdk/pull/1229

From herrick at openjdk.java.net  Mon Nov 16 15:20:10 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 16 Nov 2020 15:20:10 GMT
Subject: RFR: JDK-8255055: Create two phase test for case with different
 names, =?UTF-8?B?YW5k4oCm?=
In-Reply-To: <zoptCE9lKZ7D837MlSOcBNzsLtMkBH0yey6wDct8b2c=.aef04c82-1e5e-4f5d-b8f6-afc76774d1cb@github.com>
References: <zoptCE9lKZ7D837MlSOcBNzsLtMkBH0yey6wDct8b2c=.aef04c82-1e5e-4f5d-b8f6-afc76774d1cb@github.com>
Message-ID: <R8vRWkmBQ-pa808t-zQPimAhemj8i_Kx5G9PzBFatuQ=.6df29449-db1e-4dc8-9852-c8d5791f9984@github.com>

On Mon, 16 Nov 2020 15:15:02 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> ? fix linux DTI

Creating test for case of app-image created with one name, then used to create installer with different name.
Fixing Linux desktop integrations for this case

-------------

PR: https://git.openjdk.java.net/jdk/pull/1229

From mcimadamore at openjdk.java.net  Mon Nov 16 16:45:31 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 16 Nov 2020 16:45:31 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v26]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <pIsenyXjQivcxiLfuUXLhdrZpNA3SvyFja9oY-JrW6U=.f49212f6-d1d9-4b07-8d8d-4257fce57998@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix aarch64 test failure

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/3999a188..a836cc32

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=25
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=24-25

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From rkennke at openjdk.java.net  Mon Nov 16 17:34:09 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 16 Nov 2020 17:34:09 GMT
Subject: RFR: 8256370: Add asserts to Reference.getInactive()
Message-ID: <-QVwpOcOTp5Gb7Sjq04ihTxP5h0nMHCh307WqkEjE-M=.83b69e68-19e6-4a10-8bd3-010d2c008140@github.com>

A follow-up to JDK-8256106, this is adding two asserts to check that the API is used as it should be, i.e. only on inactive FinalReferences. Also, in Finalizer, where getInactive() is used, there is a null-check. The GC must never clean the referent, and Java code doesn't clean it either, it would be a bug if we ever see null there. I think it's better to fail there (with assert or NPE) when that happens instead of silently accepting it.

Testing:
 - [x] tier1
 - [x] tier2

-------------

Commit messages:
 - 8256370: Add asserts to Reference.getInactive()

Changes: https://git.openjdk.java.net/jdk/pull/1231/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1231&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256370
  Stats: 4 lines in 2 files changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1231.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1231/head:pull/1231

PR: https://git.openjdk.java.net/jdk/pull/1231

From naoto at openjdk.java.net  Mon Nov 16 18:28:46 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 16 Nov 2020 18:28:46 GMT
Subject: RFR: 8247781: Day periods support [v15]
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <kSGUXySY-J6uFgJ3Q_xnD0ZeOsSrLgwh2IeCoO5sdqs=.e1db5d63-db2f-4186-8132-16b6c46ebbb8@github.com>

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 18 additional commits since the last revision:

 - Merge branch 'master' into dayperiod
 - Re-worded the spec of appendDayPeriodText, refactored calculation of minute-of-day.
 - Addressed the following comments:
   - https://github.com/openjdk/jdk/pull/938#discussion_r522185469
   - https://github.com/openjdk/jdk/pull/938#discussion_r522187931
   - https://github.com/openjdk/jdk/pull/938#discussion_r522203757
   - https://github.com/openjdk/jdk/pull/938#discussion_r522211444
   - https://github.com/openjdk/jdk/pull/938#discussion_r522244221
   - https://github.com/openjdk/jdk/pull/938#discussion_r522262379
   - https://github.com/openjdk/jdk/pull/938#discussion_r522266836
 - Added a test case for user defined temporal field resolution with day period.
 - Clarified 24:00 for "midnight" type in the spec. Some clean up.
 - Addressing https://github.com/openjdk/jdk/pull/938#discussion_r519061476
 - Fixed a comment.
 - Addressed the following comments:
   - https://github.com/openjdk/jdk/pull/938#discussion_r518431077
   - https://github.com/openjdk/jdk/pull/938#discussion_r518616570
   - https://github.com/openjdk/jdk/pull/938#discussion_r518439782
 - Fixed typo/grammatical error.
 - Merge branch 'master' into dayperiod
 - ... and 8 more: https://git.openjdk.java.net/jdk/compare/0278aec9...e5db226c

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/938/files
  - new: https://git.openjdk.java.net/jdk/pull/938/files/1aa3134f..e5db226c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=14
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=938&range=13-14

  Stats: 74639 lines in 1037 files changed: 41843 ins; 21966 del; 10830 mod
  Patch: https://git.openjdk.java.net/jdk/pull/938.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/938/head:pull/938

PR: https://git.openjdk.java.net/jdk/pull/938

From mchung at openjdk.java.net  Mon Nov 16 18:33:07 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 16 Nov 2020 18:33:07 GMT
Subject: RFR: 8256370: Add asserts to Reference.getInactive()
In-Reply-To: <-QVwpOcOTp5Gb7Sjq04ihTxP5h0nMHCh307WqkEjE-M=.83b69e68-19e6-4a10-8bd3-010d2c008140@github.com>
References: <-QVwpOcOTp5Gb7Sjq04ihTxP5h0nMHCh307WqkEjE-M=.83b69e68-19e6-4a10-8bd3-010d2c008140@github.com>
Message-ID: <FqR4moRH9Y3KtU7P8UUxA1Gi2VDJqnY4W2b4OgkF0kg=.9bfe984e-3c84-4ea2-95a7-4e88bfba9d55@github.com>

On Mon, 16 Nov 2020 17:29:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> A follow-up to JDK-8256106, this is adding two asserts to check that the API is used as it should be, i.e. only on inactive FinalReferences. Also, in Finalizer, where getInactive() is used, there is a null-check. The GC must never clean the referent, and Java code doesn't clean it either, it would be a bug if we ever see null there. I think it's better to fail there (with assert or NPE) when that happens instead of silently accepting it.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2

Thanks for adding this asserts.  If there is any reason to use `getInactive` by other references in the future, we could remove these asserts at that time.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1231

From mcimadamore at openjdk.java.net  Mon Nov 16 18:52:27 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 16 Nov 2020 18:52:27 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v27]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <bkh8rxGJ-D8BP20v9f8fg9i2Y-QIJ2Eha2kSaToJrpQ=.c38dd3d5-dd41-4414-856b-f8046d39a412@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add `final` modifier on NativeLibraries.defaultLookup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/634/files
  - new: https://git.openjdk.java.net/jdk/pull/634/files/a836cc32..a71d51a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=26
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=25-26

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From rhalade at openjdk.java.net  Mon Nov 16 18:52:29 2020
From: rhalade at openjdk.java.net (Rajan Halade)
Date: Mon, 16 Nov 2020 18:52:29 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v26]
In-Reply-To: <pIsenyXjQivcxiLfuUXLhdrZpNA3SvyFja9oY-JrW6U=.f49212f6-d1d9-4b07-8d8d-4257fce57998@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <pIsenyXjQivcxiLfuUXLhdrZpNA3SvyFja9oY-JrW6U=.f49212f6-d1d9-4b07-8d8d-4257fce57998@github.com>
Message-ID: <_MAO7-ELT_n5RxduwWzN7gJ23wpv06mQZftEFwtNWYs=.579b699a-8424-4eac-9b30-b37607e1ba32@github.com>

On Mon, 16 Nov 2020 16:45:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix aarch64 test failure

src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 387:

> 385:     }
> 386: 
> 387:     public static NativeLibrary defaultLibrary = new NativeLibraryImpl(Object.class, "<default>", true, true) {

This field can be final.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From asemenyuk at openjdk.java.net  Mon Nov 16 19:05:02 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 16 Nov 2020 19:05:02 GMT
Subject: RFR: JDK-8255055: Create two phase test for case with different
 names, and fix linux DTI
In-Reply-To: <zoptCE9lKZ7D837MlSOcBNzsLtMkBH0yey6wDct8b2c=.aef04c82-1e5e-4f5d-b8f6-afc76774d1cb@github.com>
References: <zoptCE9lKZ7D837MlSOcBNzsLtMkBH0yey6wDct8b2c=.aef04c82-1e5e-4f5d-b8f6-afc76774d1cb@github.com>
Message-ID: <oX7UnHZVocLN3yKL9tE_ei7vOBZ915HRmCSalYIe3gc=.26010242-e5f3-4264-b52b-1d0f54941b6e@github.com>

On Mon, 16 Nov 2020 15:15:02 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> ? fix linux DTI

Changes requested by asemenyuk (Committer).

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 484:

> 482:         return TKit.getCurrentDefaultAppName();
> 483:     }
> 484: 

I don't like the idea of introducing this method. Two reasons:
- it adds confusion because we already have name()
- name() is not returning app name any more for the case of two phase jpackage usage as app name is now supposed to be returned by getApplicationName()
- TKit.getCurrentDefaultAppName() should be used only to set the default app name when jpackage default command line is configured by the test.

I suggest instead update name() method. Test is "--app-image" is on the command line, if it is, extract app name of xml file with app image info. This will eliminate need for another method in JPackageCommand interface and make name() method return accurate result without relying on the current usage scenarios of "--app-image" parameter in tests.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1229

From asemenyuk at openjdk.java.net  Mon Nov 16 19:11:00 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 16 Nov 2020 19:11:00 GMT
Subject: RFR: JDK-8255055: Create two phase test for case with different
 names, and fix linux DTI
In-Reply-To: <oX7UnHZVocLN3yKL9tE_ei7vOBZ915HRmCSalYIe3gc=.26010242-e5f3-4264-b52b-1d0f54941b6e@github.com>
References: <zoptCE9lKZ7D837MlSOcBNzsLtMkBH0yey6wDct8b2c=.aef04c82-1e5e-4f5d-b8f6-afc76774d1cb@github.com>
 <oX7UnHZVocLN3yKL9tE_ei7vOBZ915HRmCSalYIe3gc=.26010242-e5f3-4264-b52b-1d0f54941b6e@github.com>
Message-ID: <Znr9hoKSs5-gIVH_gO_UJMeOoAM8VyLtyCX0DuVmGjc=.e66c58d9-10bd-4665-9c58-3967a27be183@github.com>

On Mon, 16 Nov 2020 19:01:57 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> ? fix linux DTI
>
> Changes requested by asemenyuk (Committer).

In these two scenarios what would be the name of the installer:
1. phase 1: --name Foo; phase 2: --name Bar --app-image <path_to_image_from_phase_1>
2. phase 1: --name Foo; phase 2: --app-image <path_to_image_from_phase_1>

Do we have tests for these two scenarios?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1229

From herrick at openjdk.java.net  Mon Nov 16 20:15:07 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 16 Nov 2020 20:15:07 GMT
Subject: RFR: JDK-8255055: Create two phase test for case with different
 names, and fix linux DTI
In-Reply-To: <oX7UnHZVocLN3yKL9tE_ei7vOBZ915HRmCSalYIe3gc=.26010242-e5f3-4264-b52b-1d0f54941b6e@github.com>
References: <zoptCE9lKZ7D837MlSOcBNzsLtMkBH0yey6wDct8b2c=.aef04c82-1e5e-4f5d-b8f6-afc76774d1cb@github.com>
 <oX7UnHZVocLN3yKL9tE_ei7vOBZ915HRmCSalYIe3gc=.26010242-e5f3-4264-b52b-1d0f54941b6e@github.com>
Message-ID: <KBDLJJ5t1wnJyKzjreI5ovOTHCbCAlT3TNSTXjxGitY=.690dc49b-dc45-4b2e-a044-f1c9fb552e24@github.com>

On Mon, 16 Nov 2020 19:01:49 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> ? fix linux DTI
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 484:
> 
>> 482:         return TKit.getCurrentDefaultAppName();
>> 483:     }
>> 484: 
> 
> I don't like the idea of introducing this method. Two reasons:
> - it adds confusion because we already have name()
> - name() is not returning app name any more for the case of two phase jpackage usage as app name is now supposed to be returned by getApplicationName()
> - TKit.getCurrentDefaultAppName() should be used only to set the default app name when jpackage default command line is configured by the test.
> 
> I suggest instead update name() method. Test is "--app-image" is on the command line, if it is, extract app name of xml file with app image info. This will eliminate need for another method in JPackageCommand interface and make name() method return accurate result without relying on the current usage scenarios of "--app-image" parameter in tests.

I can easily agree that changing to actually extract name from AppImageFile is a better way to go, but just changing name() to return the main app name, ignores other cases where name is referring to the installer name.
Actually, the problem is that on linux and Windows (doesn't matter on mac) the default install directory is based on the installer name , not the app name so that on windows with app name "hello" and installer name "helloSetup" we will be default install to "C:\Program Files\helloSetup\hello.exe", and similar  (the param WINDOWS_INSTALL_DIR defaults to APP_NAME)
Similar problem on linux where it uses PACKAGE_NAME which is derived from APP_NAME
If we fix that we can just fix name() as you suggest.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1229

From herrick at openjdk.java.net  Mon Nov 16 21:25:02 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 16 Nov 2020 21:25:02 GMT
Subject: RFR: JDK-8255055: Create two phase test for case with different
 names, and fix linux DTI
In-Reply-To: <Znr9hoKSs5-gIVH_gO_UJMeOoAM8VyLtyCX0DuVmGjc=.e66c58d9-10bd-4665-9c58-3967a27be183@github.com>
References: <zoptCE9lKZ7D837MlSOcBNzsLtMkBH0yey6wDct8b2c=.aef04c82-1e5e-4f5d-b8f6-afc76774d1cb@github.com>
 <oX7UnHZVocLN3yKL9tE_ei7vOBZ915HRmCSalYIe3gc=.26010242-e5f3-4264-b52b-1d0f54941b6e@github.com>
 <Znr9hoKSs5-gIVH_gO_UJMeOoAM8VyLtyCX0DuVmGjc=.e66c58d9-10bd-4665-9c58-3967a27be183@github.com>
Message-ID: <2iz-5U-pbfFHGtuJqECEi4YR8V22cCQunpDhY9_U434=.e0a94f24-ed04-4cc7-8251-3e771fa83e53@github.com>

On Mon, 16 Nov 2020 19:07:55 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Changes requested by asemenyuk (Committer).
>
> In these two scenarios what would be the name of the installer:
> 1. phase 1: --name Foo; phase 2: --name Bar --app-image <path_to_image_from_phase_1>
> 2. phase 1: --name Foo; phase 2: --app-image <path_to_image_from_phase_1>
> 
> Do we have tests for these two scenarios?

In scenario 1, the installer would be Bar-1.0.{exe, msi, pkg ...}
The change in test above tests this.
Scenario 2 would be an error currently, since all jpackage commands require a "--name" argument, however, it would be reasonable to modify restriction to require either a name or an app-image, extracting the name from the app-image in this case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1229

From clanger at openjdk.java.net  Mon Nov 16 22:33:11 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Mon, 16 Nov 2020 22:33:11 GMT
Subject: RFR: 8256427: Test com/sun/jndi/dns/ConfigTests/PortUnreachable.java
 does not work on AIX
Message-ID: <uU8ZuNpWhgp4lo26_qVGDC2nINRe17UqlTtPQACDegk=.434b84e1-2b2a-4913-820b-0b2839281d97@github.com>

The test com/sun/jndi/dns/ConfigTests/PortUnreachable.java is not working on AIX.

It tests that when a DNS server is unreachable it fails quickly with a PortUnreachableException due to ICMP Destination Unreachable packets received and not having to wait for the full timeout interval.
Unfortunately, on AIX such ICMP packets are not received, so the only exception cause will be the timeout. Hence, this test can't work on AIX, so it should not be executed there.

At SAP, we had this test excluded for a long time already in our private exclude list for AIX. I suggest this test update to be the final solution.

-------------

Commit messages:
 - Test jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX

Changes: https://git.openjdk.java.net/jdk/pull/1241/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1241&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256427
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1241.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1241/head:pull/1241

PR: https://git.openjdk.java.net/jdk/pull/1241

From amenkov at openjdk.java.net  Mon Nov 16 23:05:10 2020
From: amenkov at openjdk.java.net (Alex Menkov)
Date: Mon, 16 Nov 2020 23:05:10 GMT
Subject: RFR: 8255934: JConsole 14 and greater fails to connect to older JVM
Message-ID: <FIUpgXjddyOgyoPNK_2Y-qmwyd8jL5ukwzuwd4KP-Qo=.e280bf75-f6f7-4837-8bfe-98e82368ca55@github.com>

OperatingSystemMXBean was changed in jdk14 (see JDK-8226575):
New methods getTotalMemorySize and getFreeMemorySize were added, old getTotalPhysicalMemorySize and getFreePhysicalMemorySize were deprecated.

The fix adds fallbacks for the values (i.e. if new methods fail, jconsole calls old methods)

-------------

Commit messages:
 - Adds fallback getters

Changes: https://git.openjdk.java.net/jdk/pull/1243/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1243&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255934
  Stats: 22 lines in 1 file changed: 20 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1243.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1243/head:pull/1243

PR: https://git.openjdk.java.net/jdk/pull/1243

From naoto at openjdk.java.net  Mon Nov 16 23:16:19 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 16 Nov 2020 23:16:19 GMT
Subject: Integrated: 8247781: Day periods support
In-Reply-To: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
References: <chJsGtV64V07VPfbS9ToIqyemD5yI49zl83b-RcN9kY=.fb529f5c-217f-4eaa-af15-e52d9fa701d2@github.com>
Message-ID: <btm7bKHuGPB0LohMNbwUg1GAophPreljC2K-9v1VR-k=.78ca8cc0-206b-4038-a927-3afe5e364b8b@github.com>

On Thu, 29 Oct 2020 15:59:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes for the subject issue. This is to enhance the java.time package to support day periods, such as "in the morning", defined in CLDR. It will add a new pattern character 'B' and its supporting builder method. The motivation and its spec are in this CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254629
> 
> Naoto

This pull request has now been integrated.

Changeset: bf84dac4
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bf84dac4
Stats:     1243 lines in 20 files changed: 1039 ins; 87 del; 117 mod

8247781: Day periods support

Reviewed-by: scolebourne, rriggs, joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/938

From mchung at openjdk.java.net  Tue Nov 17 00:29:03 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 17 Nov 2020 00:29:03 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <X7lXs0tULkwp6dM67oHD8HBn_z5HaGbePo30unGhDbc=.566b1f26-9888-4e1b-9cce-4ac5be762259@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <X7lXs0tULkwp6dM67oHD8HBn_z5HaGbePo30unGhDbc=.566b1f26-9888-4e1b-9cce-4ac5be762259@github.com>
Message-ID: <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com>

On Mon, 16 Nov 2020 13:49:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>> 
>> - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>> - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>> - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>> - adding code to make sure that annotations can't be sealed
>> - improving some tests
>> 
>> TIA
>> 
>> Related specs:
>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>
> src/java.base/share/classes/java/lang/Package.java line 227:
> 
>> 225:      * This method reports on a distinct concept of sealing from
>> 226:      * {@link Class#isSealed() Class::isSealed}.
>> 227:      *
> 
> This API note will be very confusing to readers. I think the javadoc will need to be fleshed out and probably will need to link to a section the Package class description that defines the legacy concept of sealing.

I agree.  This @apiNote needs more clarification to help the readers to understand the context here.    One thing we could do in the Package class description to add a "Package Sealing" section that can also explain that it has no relationship to "sealed classes".

-------------

PR: https://git.openjdk.java.net/jdk/pull/1227

From almatvee at openjdk.java.net  Tue Nov 17 01:36:21 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 17 Nov 2020 01:36:21 GMT
Subject: RFR: 8255947: [macos] Signed macOS jpackage app doesn't filter
 spurious '-psn' argument [v3]
In-Reply-To: <gA_HFoOHfdrbfrRXQG6Jvn7M_tfns2G7WvzUIS_afg0=.ea64b8e8-1afd-4884-99b4-cb84333dbbf3@github.com>
References: <gA_HFoOHfdrbfrRXQG6Jvn7M_tfns2G7WvzUIS_afg0=.ea64b8e8-1afd-4884-99b4-cb84333dbbf3@github.com>
Message-ID: <--UgyCr3n2bnCYEaSxz7j5UfGdfcC9Lcky-e26R1EC8=.36a42916-61d9-429a-a46e-5eb68c40643a@github.com>

> This is regression from JDK-8242302 and for some reason removing -psn argument code was removed during refactoring. Fixed be adding removing -psn argument back. Also, test was added to test this functionality.

Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:

  8255947: [macos] Signed macOS jpackage app doesn't filter spurious '-psn' argument [v3]

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1154/files
  - new: https://git.openjdk.java.net/jdk/pull/1154/files/7df8d225..e196262e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1154&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1154&range=01-02

  Stats: 25 lines in 1 file changed: 4 ins; 3 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1154.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1154/head:pull/1154

PR: https://git.openjdk.java.net/jdk/pull/1154

From jiefu at openjdk.java.net  Tue Nov 17 01:39:02 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 17 Nov 2020 01:39:02 GMT
Subject: Integrated: 8256037: [TESTBUG]
 com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails due to the hard coded
 threshold is small
In-Reply-To: <QuPW3Afb2RpucHhJT9NQDsmHo977-Y378EuBgcg_-B0=.07b9b5f2-8faf-434b-9e98-72a80734976f@github.com>
References: <QuPW3Afb2RpucHhJT9NQDsmHo977-Y378EuBgcg_-B0=.07b9b5f2-8faf-434b-9e98-72a80734976f@github.com>
Message-ID: <wQbq4j2JfRDU3pYoJbn1PwrgFkCp9NXKzXjsArQJKBc=.c3dc45e3-375d-42db-8c6d-8e0fad664177@github.com>

On Mon, 9 Nov 2020 09:19:44 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> May I get reviews for this change?
> 
> com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails occasionally on some of our testing platforms.
> The reason is that the hard coded Threshold (1000 ms) [1] is a little smaller than that (e.g., 1026 ms) on our platforms.
> 
> The fix just increases the threshold from 1000 ms to 3000 ms.
> Any comments?
> 
> Thanks.
> Best regards,
> Jie
> 
> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java#L49

This pull request has now been integrated.

Changeset: eabf3bac
Author:    Jie Fu <jiefu at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/eabf3bac
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8256037: [TESTBUG] com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails due to the hard coded threshold is small

Reviewed-by: shade, aefimov

-------------

PR: https://git.openjdk.java.net/jdk/pull/1116

From jiefu at openjdk.java.net  Tue Nov 17 01:39:01 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 17 Nov 2020 01:39:01 GMT
Subject: RFR: 8256037: [TESTBUG]
 com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails due to the hard coded
 threshold is small
In-Reply-To: <LS25XTpiuOfodcTl0Odx9mNAxN9hKcfPjrMkq2u5QhQ=.2845ed51-7c18-4e01-9ad4-12e06e76559e@github.com>
References: <QuPW3Afb2RpucHhJT9NQDsmHo977-Y378EuBgcg_-B0=.07b9b5f2-8faf-434b-9e98-72a80734976f@github.com>
 <LS25XTpiuOfodcTl0Odx9mNAxN9hKcfPjrMkq2u5QhQ=.2845ed51-7c18-4e01-9ad4-12e06e76559e@github.com>
Message-ID: <jyaJMKvvbn4-wz4hi7H0vSonHMSsUg3LR5eeVi9Wz4k=.d637c39f-0d7f-40e1-9947-8dd929e67046@github.com>

On Mon, 16 Nov 2020 13:32:16 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> Hi all,
>> 
>> May I get reviews for this change?
>> 
>> com/sun/jndi/dns/ConfigTests/PortUnreachable.java fails occasionally on some of our testing platforms.
>> The reason is that the hard coded Threshold (1000 ms) [1] is a little smaller than that (e.g., 1026 ms) on our platforms.
>> 
>> The fix just increases the threshold from 1000 ms to 3000 ms.
>> Any comments?
>> 
>> Thanks.
>> Best regards,
>> Jie
>> 
>> [1] https://github.com/openjdk/jdk/blob/master/test/jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java#L49
>
> Hi @DamonFool,
> Change looks good to me since 3 seconds is less than 15 seconds of the full timeout.
> 
> The full timeout interval which is mentioned in the test summary is 15 s:
> 4 retries with initial timeout set to 1s: 1 + 2 + 4 + 8 = 15 s

Thanks @AlekseiEfimov for your review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1116

From asemenyuk at openjdk.java.net  Tue Nov 17 01:47:11 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 17 Nov 2020 01:47:11 GMT
Subject: RFR: 8255947: [macos] Signed macOS jpackage app doesn't filter
 spurious '-psn' argument [v3]
In-Reply-To: <--UgyCr3n2bnCYEaSxz7j5UfGdfcC9Lcky-e26R1EC8=.36a42916-61d9-429a-a46e-5eb68c40643a@github.com>
References: <gA_HFoOHfdrbfrRXQG6Jvn7M_tfns2G7WvzUIS_afg0=.ea64b8e8-1afd-4884-99b4-cb84333dbbf3@github.com>
 <--UgyCr3n2bnCYEaSxz7j5UfGdfcC9Lcky-e26R1EC8=.36a42916-61d9-429a-a46e-5eb68c40643a@github.com>
Message-ID: <d8sr-gHGfDRVuWaKZx3tMzfTtJDaawolBjf9FU4PeAk=.63960cea-2cee-4ed7-93d7-57d2863e6698@github.com>

On Tue, 17 Nov 2020 01:36:21 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> This is regression from JDK-8242302 and for some reason removing -psn argument code was removed during refactoring. Fixed be adding removing -psn argument back. Also, test was added to test this functionality.
>
> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8255947: [macos] Signed macOS jpackage app doesn't filter spurious '-psn' argument [v3]

Marked as reviewed by asemenyuk (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1154

From asemenyuk at openjdk.java.net  Tue Nov 17 02:01:05 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 17 Nov 2020 02:01:05 GMT
Subject: RFR: JDK-8255055: Create two phase test for case with different
 names, and fix linux DTI
In-Reply-To: <KBDLJJ5t1wnJyKzjreI5ovOTHCbCAlT3TNSTXjxGitY=.690dc49b-dc45-4b2e-a044-f1c9fb552e24@github.com>
References: <zoptCE9lKZ7D837MlSOcBNzsLtMkBH0yey6wDct8b2c=.aef04c82-1e5e-4f5d-b8f6-afc76774d1cb@github.com>
 <oX7UnHZVocLN3yKL9tE_ei7vOBZ915HRmCSalYIe3gc=.26010242-e5f3-4264-b52b-1d0f54941b6e@github.com>
 <KBDLJJ5t1wnJyKzjreI5ovOTHCbCAlT3TNSTXjxGitY=.690dc49b-dc45-4b2e-a044-f1c9fb552e24@github.com>
Message-ID: <lA3-EUGsFd_BBhOf-PzAVdmjbvqVkR7YfaoUuicEKso=.f69bf834-2556-43c9-8398-1c6171e5f0ff@github.com>

On Mon, 16 Nov 2020 20:12:37 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 484:
>> 
>>> 482:         return TKit.getCurrentDefaultAppName();
>>> 483:     }
>>> 484: 
>> 
>> I don't like the idea of introducing this method. Two reasons:
>> - it adds confusion because we already have name()
>> - name() is not returning app name any more for the case of two phase jpackage usage as app name is now supposed to be returned by getApplicationName()
>> - TKit.getCurrentDefaultAppName() should be used only to set the default app name when jpackage default command line is configured by the test.
>> 
>> I suggest instead update name() method. Test is "--app-image" is on the command line, if it is, extract app name of xml file with app image info. This will eliminate need for another method in JPackageCommand interface and make name() method return accurate result without relying on the current usage scenarios of "--app-image" parameter in tests.
>
> I can easily agree that changing to actually extract name from AppImageFile is a better way to go, but just changing name() to return the main app name, ignores other cases where name is referring to the installer name.
> Actually, the problem is that on linux and Windows (doesn't matter on mac) the default install directory is based on the installer name , not the app name so that on windows with app name "hello" and installer name "helloSetup" we will be default install to "C:\Program Files\helloSetup\hello.exe", and similar  (the param WINDOWS_INSTALL_DIR defaults to APP_NAME)
> Similar problem on linux where it uses PACKAGE_NAME which is derived from APP_NAME
> If we fix that we can just fix name() as you suggest.

I think we should have consistent behavior on all platforms for install dir name.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1229

From almatvee at openjdk.java.net  Tue Nov 17 02:01:07 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 17 Nov 2020 02:01:07 GMT
Subject: Integrated: 8255947: [macos] Signed macOS jpackage app doesn't filter
 spurious '-psn' argument
In-Reply-To: <gA_HFoOHfdrbfrRXQG6Jvn7M_tfns2G7WvzUIS_afg0=.ea64b8e8-1afd-4884-99b4-cb84333dbbf3@github.com>
References: <gA_HFoOHfdrbfrRXQG6Jvn7M_tfns2G7WvzUIS_afg0=.ea64b8e8-1afd-4884-99b4-cb84333dbbf3@github.com>
Message-ID: <EAJNOkuUgzX8XfURbloSyt_sA0f4E5vtFuSftzswRaA=.35e48d1e-a847-4f91-83eb-70668c21412a@github.com>

On Wed, 11 Nov 2020 04:28:02 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> This is regression from JDK-8242302 and for some reason removing -psn argument code was removed during refactoring. Fixed be adding removing -psn argument back. Also, test was added to test this functionality.

This pull request has now been integrated.

Changeset: c35e1a28
Author:    Alexander Matveev <almatvee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/c35e1a28
Stats:     113 lines in 5 files changed: 100 ins; 10 del; 3 mod

8255947: [macos] Signed macOS jpackage app doesn't filter spurious '-psn' argument

Reviewed-by: herrick, asemenyuk

-------------

PR: https://git.openjdk.java.net/jdk/pull/1154

From asemenyuk at openjdk.java.net  Tue Nov 17 02:04:06 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Tue, 17 Nov 2020 02:04:06 GMT
Subject: RFR: JDK-8255055: Create two phase test for case with different
 names, and fix linux DTI
In-Reply-To: <2iz-5U-pbfFHGtuJqECEi4YR8V22cCQunpDhY9_U434=.e0a94f24-ed04-4cc7-8251-3e771fa83e53@github.com>
References: <zoptCE9lKZ7D837MlSOcBNzsLtMkBH0yey6wDct8b2c=.aef04c82-1e5e-4f5d-b8f6-afc76774d1cb@github.com>
 <oX7UnHZVocLN3yKL9tE_ei7vOBZ915HRmCSalYIe3gc=.26010242-e5f3-4264-b52b-1d0f54941b6e@github.com>
 <Znr9hoKSs5-gIVH_gO_UJMeOoAM8VyLtyCX0DuVmGjc=.e66c58d9-10bd-4665-9c58-3967a27be183@github.com>
 <2iz-5U-pbfFHGtuJqECEi4YR8V22cCQunpDhY9_U434=.e0a94f24-ed04-4cc7-8251-3e771fa83e53@github.com>
Message-ID: <tF4sorswYo1o0DDfJPBfWBcgj8LNEQn5k3b4rdWtPY8=.fea65639-c00e-4c7b-b571-3d343fdbe507@github.com>

On Mon, 16 Nov 2020 21:22:21 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> In these two scenarios what would be the name of the installer:
>> 1. phase 1: --name Foo; phase 2: --name Bar --app-image <path_to_image_from_phase_1>
>> 2. phase 1: --name Foo; phase 2: --app-image <path_to_image_from_phase_1>
>> 
>> Do we have tests for these two scenarios?
>
> In scenario 1, the installer would be Bar-1.0.{exe, msi, pkg ...}
> The change in test above tests this.
> Scenario 2 would be an error currently, since all jpackage commands require a "--name" argument, however, it would be reasonable to modify restriction to require either a name or an app-image, extracting the name from the app-image in this case.

I think we need to define the behavior we want from two phase jpackage runs first and create tests after that. I agree it would be good to extract name from app image if it is not specified explicitly when building an installer

-------------

PR: https://git.openjdk.java.net/jdk/pull/1229

From mchung at openjdk.java.net  Tue Nov 17 02:07:06 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 17 Nov 2020 02:07:06 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
Message-ID: <Cb_cEhs4LxIUbtSKvPn5n3V5cImRB_bioYSQHHvTxHE=.8f18e946-ec20-4465-a709-f644a974ab71@github.com>

On Mon, 16 Nov 2020 13:30:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Please review the code for the second iteration of sealed classes. In this iteration we are:
> 
> - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
> - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
> - renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
> - adding code to make sure that annotations can't be sealed
> - improving some tests
> 
> TIA
> 
> Related specs:
> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)

src/java.base/share/classes/java/lang/Class.java line 4381:

> 4379:      */
> 4380:     @jdk.internal.PreviewFeature(feature=jdk.internal.PreviewFeature.Feature.SEALED_CLASSES, essentialAPI=false)
> 4381:     public Class<?>[] getPermittedSubclasses() {

What happens if a permitted subclass is not found?   I see that `getPermittedSubclasses0` ignores the entry if the class is not found.    Should that be specified?

Have you considered whether security package access is needed (now that this method returns `Class` objects the caller may not have access to)? This needs to be discussed with the security team.    If someone gets a hold of a sealed class (e.g. `obj.getClass()`), this method could leak other `Class` objects.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1227

From jiefu at openjdk.java.net  Tue Nov 17 03:37:03 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 17 Nov 2020 03:37:03 GMT
Subject: RFR: 8256427: Test
 com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX
In-Reply-To: <uU8ZuNpWhgp4lo26_qVGDC2nINRe17UqlTtPQACDegk=.434b84e1-2b2a-4913-820b-0b2839281d97@github.com>
References: <uU8ZuNpWhgp4lo26_qVGDC2nINRe17UqlTtPQACDegk=.434b84e1-2b2a-4913-820b-0b2839281d97@github.com>
Message-ID: <ua4huq-8wEQHkIvhqOPTqwCtthXUNQEaVsxV-KX5FVM=.9b763a2d-5f0e-4ead-8fec-08d115e0fe3a@github.com>

On Mon, 16 Nov 2020 22:28:08 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The test com/sun/jndi/dns/ConfigTests/PortUnreachable.java is not working on AIX.
> 
> It tests that when a DNS server is unreachable it fails quickly with a PortUnreachableException due to ICMP Destination Unreachable packets received and not having to wait for the full timeout interval.
> Unfortunately, on AIX such ICMP packets are not received, so the only exception cause will be the timeout. Hence, this test can't work on AIX, so it should not be executed there.
> 
> At SAP, we had this test excluded for a long time already in our private exclude list for AIX. I suggest this test update to be the final solution.

test/jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java line 2:

> 1: /*
> 2:  * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved.

The copyright year had been updated in https://github.com/openjdk/jdk/pull/1116
Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1241

From clanger at openjdk.java.net  Tue Nov 17 05:02:07 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 17 Nov 2020 05:02:07 GMT
Subject: RFR: 8256427: Test
 com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX [v2]
In-Reply-To: <uU8ZuNpWhgp4lo26_qVGDC2nINRe17UqlTtPQACDegk=.434b84e1-2b2a-4913-820b-0b2839281d97@github.com>
References: <uU8ZuNpWhgp4lo26_qVGDC2nINRe17UqlTtPQACDegk=.434b84e1-2b2a-4913-820b-0b2839281d97@github.com>
Message-ID: <JME0Vjq8gyb4qyNFXumXXiAKMC2QxR6JFy0mgQHHuS0=.79eeb48c-e887-4f64-aa49-6c6f37cefc9b@github.com>

> The test com/sun/jndi/dns/ConfigTests/PortUnreachable.java is not working on AIX.
> 
> It tests that when a DNS server is unreachable it fails quickly with a PortUnreachableException due to ICMP Destination Unreachable packets received and not having to wait for the full timeout interval.
> Unfortunately, on AIX such ICMP packets are not received, so the only exception cause will be the timeout. Hence, this test can't work on AIX, so it should not be executed there.
> 
> At SAP, we had this test excluded for a long time already in our private exclude list for AIX. I suggest this test update to be the final solution.

Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:

  Test jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1241/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1241&range=01
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1241.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1241/head:pull/1241

PR: https://git.openjdk.java.net/jdk/pull/1241

From clanger at openjdk.java.net  Tue Nov 17 05:15:05 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Tue, 17 Nov 2020 05:15:05 GMT
Subject: RFR: 8256427: Test
 com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX [v2]
In-Reply-To: <ua4huq-8wEQHkIvhqOPTqwCtthXUNQEaVsxV-KX5FVM=.9b763a2d-5f0e-4ead-8fec-08d115e0fe3a@github.com>
References: <uU8ZuNpWhgp4lo26_qVGDC2nINRe17UqlTtPQACDegk=.434b84e1-2b2a-4913-820b-0b2839281d97@github.com>
 <ua4huq-8wEQHkIvhqOPTqwCtthXUNQEaVsxV-KX5FVM=.9b763a2d-5f0e-4ead-8fec-08d115e0fe3a@github.com>
Message-ID: <l112u8yTCGcveJGWlAp5THDCjSbEJajwDCfRoA5sBwE=.82f68142-fceb-45cc-9129-3069a52f1e02@github.com>

On Tue, 17 Nov 2020 03:33:58 GMT, Jie Fu <jiefu at openjdk.org> wrote:

>> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   Test jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX
>
> test/jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2002, 2018, Oracle and/or its affiliates. All rights reserved.
> 
> The copyright year had been updated in https://github.com/openjdk/jdk/pull/1116
> Thanks.

Thanks, I've updated my change with a force-push since there were no reviews yet.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1241

From jiefu at openjdk.java.net  Tue Nov 17 05:21:10 2020
From: jiefu at openjdk.java.net (Jie Fu)
Date: Tue, 17 Nov 2020 05:21:10 GMT
Subject: RFR: 8256427: Test
 com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX [v2]
In-Reply-To: <JME0Vjq8gyb4qyNFXumXXiAKMC2QxR6JFy0mgQHHuS0=.79eeb48c-e887-4f64-aa49-6c6f37cefc9b@github.com>
References: <uU8ZuNpWhgp4lo26_qVGDC2nINRe17UqlTtPQACDegk=.434b84e1-2b2a-4913-820b-0b2839281d97@github.com>
 <JME0Vjq8gyb4qyNFXumXXiAKMC2QxR6JFy0mgQHHuS0=.79eeb48c-e887-4f64-aa49-6c6f37cefc9b@github.com>
Message-ID: <vO4nXDlWY33tbS09z2SCgIqPcUWID2IYZMj4flEVzZs=.1f7e92f9-d2a0-4f34-b65e-398a5d9a47ab@github.com>

On Tue, 17 Nov 2020 05:02:07 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> The test com/sun/jndi/dns/ConfigTests/PortUnreachable.java is not working on AIX.
>> 
>> It tests that when a DNS server is unreachable it fails quickly with a PortUnreachableException due to ICMP Destination Unreachable packets received and not having to wait for the full timeout interval.
>> Unfortunately, on AIX such ICMP packets are not received, so the only exception cause will be the timeout. Hence, this test can't work on AIX, so it should not be executed there.
>> 
>> At SAP, we had this test excluded for a long time already in our private exclude list for AIX. I suggest this test update to be the final solution.
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Test jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX

LGTM

-------------

Marked as reviewed by jiefu (Committer).

PR: https://git.openjdk.java.net/jdk/pull/1241

From roland at openjdk.java.net  Tue Nov 17 08:33:20 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 17 Nov 2020 08:33:20 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v7]
In-Reply-To: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
Message-ID: <kOpcaootjDKodGDK4i_usJwPQZ3e7heVWE6zqn8tpkQ=.f0591dbb-d097-490c-8c84-d3a377d0bfec@github.com>

> This change add 3 new methods in Objects:
> 
> public static long checkIndex(long index, long length)
> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
> public static long checkFromIndexSize(long fromIndex, long size, long length)
> 
> This mirrors the int utility methods that were added by JDK-8135248
> with the same motivations.
> 
> As is the case with the int checkIndex(), the long checkIndex() method
> is JIT compiled as an intrinsic. It allows the JIT to compile
> checkIndex to an unsigned comparison and properly recognize it as
> a range check that then becomes a candidate for the existing range check
> optimizations. This has proven to be important for panama's
> MemorySegment API and a prototype of this change (with some extra c2
> improvements) showed that panama micro benchmark results improve
> significantly.
> 
> This change includes:
> 
> - the API change
> - the C2 intrinsic
> - tests for the API and the C2 intrinsic
> 
> This is a joint work with Paul who reviewed and reworked the API change
> and filled the CSR.

Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8255150
 - Merge branch 'master' into JDK-8255150
 - Merge branch 'master' into JDK-8255150
 - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8255150
 - exclude compiler test when run with -Xcomp
 - CastLL should define carry_depency
 - intrinsic comments
 - Jorn's comments
 - Update headers and add intrinsic to Graal test ignore list
 - move compiler test and add bug to test
 - ... and 17 more: https://git.openjdk.java.net/jdk/compare/4553fa0b...feb32943

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1003/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1003&range=06
  Stats: 897 lines in 30 files changed: 846 ins; 4 del; 47 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1003.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1003/head:pull/1003

PR: https://git.openjdk.java.net/jdk/pull/1003

From dlong at openjdk.java.net  Tue Nov 17 08:43:09 2020
From: dlong at openjdk.java.net (Dean Long)
Date: Tue, 17 Nov 2020 08:43:09 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v7]
In-Reply-To: <kOpcaootjDKodGDK4i_usJwPQZ3e7heVWE6zqn8tpkQ=.f0591dbb-d097-490c-8c84-d3a377d0bfec@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
 <kOpcaootjDKodGDK4i_usJwPQZ3e7heVWE6zqn8tpkQ=.f0591dbb-d097-490c-8c84-d3a377d0bfec@github.com>
Message-ID: <OsggjPRCVLURip9cVcvDFtJZWanm5tclSUMITJAjSxY=.5d593cd3-ee00-414b-add9-ce5bd3989709@github.com>

On Tue, 17 Nov 2020 08:33:20 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This change add 3 new methods in Objects:
>> 
>> public static long checkIndex(long index, long length)
>> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
>> public static long checkFromIndexSize(long fromIndex, long size, long length)
>> 
>> This mirrors the int utility methods that were added by JDK-8135248
>> with the same motivations.
>> 
>> As is the case with the int checkIndex(), the long checkIndex() method
>> is JIT compiled as an intrinsic. It allows the JIT to compile
>> checkIndex to an unsigned comparison and properly recognize it as
>> a range check that then becomes a candidate for the existing range check
>> optimizations. This has proven to be important for panama's
>> MemorySegment API and a prototype of this change (with some extra c2
>> improvements) showed that panama micro benchmark results improve
>> significantly.
>> 
>> This change includes:
>> 
>> - the API change
>> - the C2 intrinsic
>> - tests for the API and the C2 intrinsic
>> 
>> This is a joint work with Paul who reviewed and reworked the API change
>> and filled the CSR.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8255150
>  - Merge branch 'master' into JDK-8255150
>  - Merge branch 'master' into JDK-8255150
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8255150
>  - exclude compiler test when run with -Xcomp
>  - CastLL should define carry_depency
>  - intrinsic comments
>  - Jorn's comments
>  - Update headers and add intrinsic to Graal test ignore list
>  - move compiler test and add bug to test
>  - ... and 17 more: https://git.openjdk.java.net/jdk/compare/4553fa0b...feb32943

Marked as reviewed by dlong (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1003

From ngasson at openjdk.java.net  Tue Nov 17 09:12:13 2020
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 17 Nov 2020 09:12:13 GMT
Subject: RFR: 8256435: [TESTBUG] java/foreign/TestHandshake.java fails with
 direct buffer memory OOM
Message-ID: <n0zEzhAVNoLyOMxaquudae8RmzPFsLuX2g56GQY57Fw=.7fed7240-8e67-41c5-aa82-5049f2727066@github.com>

I ran this test on a machine with 224 logical CPUs and it fails with:

  ITERATION 3
  test TestHandshake.testHandshake("SegmentMismatchAccessor", TestHandshake$$Lambda$57/0x00000001000e7968 at 37c4b344): failure
  java.lang.OutOfMemoryError: Cannot reserve 1000000 bytes of direct buffer memory (allocated: 536008192, limit: 536870912)

SegmentMismatchAccessor allocates a 1MB native segment for each CPU on
each iteration. This can quickly reach the allocation limit if there is
no intervening GC. Explicitly close the segment after each iteration to
release the memory.

-------------

Commit messages:
 - 8256435: [TESTBUG] java/foreign/TestHandshake.java fails with direct buffer memory OOM

Changes: https://git.openjdk.java.net/jdk/pull/1254/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1254&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256435
  Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1254.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1254/head:pull/1254

PR: https://git.openjdk.java.net/jdk/pull/1254

From ngasson at openjdk.java.net  Tue Nov 17 09:17:07 2020
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Tue, 17 Nov 2020 09:17:07 GMT
Subject: RFR: 8256435: [TESTBUG] java/foreign/TestHandshake.java fails
 with direct buffer memory OOM
In-Reply-To: <n0zEzhAVNoLyOMxaquudae8RmzPFsLuX2g56GQY57Fw=.7fed7240-8e67-41c5-aa82-5049f2727066@github.com>
References: <n0zEzhAVNoLyOMxaquudae8RmzPFsLuX2g56GQY57Fw=.7fed7240-8e67-41c5-aa82-5049f2727066@github.com>
Message-ID: <WCjt_BGVUTs2PxKRzFdmW9H2hsf-CutB4fQZ4zCvd5s=.929eb9f2-f4dd-425a-aaf3-6f9d809af5d4@github.com>

On Tue, 17 Nov 2020 09:07:03 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> I ran this test on a machine with 224 logical CPUs and it fails with:
> 
>   ITERATION 3
>   test TestHandshake.testHandshake("SegmentMismatchAccessor", TestHandshake$$Lambda$57/0x00000001000e7968 at 37c4b344): failure
>   java.lang.OutOfMemoryError: Cannot reserve 1000000 bytes of direct buffer memory (allocated: 536008192, limit: 536870912)
> 
> SegmentMismatchAccessor allocates a 1MB native segment for each CPU on
> each iteration. This can quickly reach the allocation limit if there is
> no intervening GC. Explicitly close the segment after each iteration to
> release the memory.

@mcimadamore I'm not sure whether I should submit this here or panama-foreign, but the fix applies to jdk master.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1254

From jfranck at openjdk.java.net  Tue Nov 17 10:04:02 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Tue, 17 Nov 2020 10:04:02 GMT
Subject: RFR: 8202471: (ann) Cannot read type annotations on generic
 receiver type's type variables [v7]
In-Reply-To: <xHKztYOh77LVM_GQ0CDFoGsPEWOB5q9eoxS00tgAaZ4=.93beeee6-b982-485d-afec-a6383d98608a@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
 <PiDCNijbUz7bmcEbfNDrcWIIE3R3qs9BzAfH-glf-Lg=.7081b9c8-73e0-49fc-9265-83258a63c97a@github.com>
 <61cSEEF8zzcgmd-BB4Hb5xHykupW5Zyw5u6iwC3tDlg=.45cf55d5-fd5d-445f-a589-26e7f8b0a1d6@github.com>
 <ArUjScpwlTZz5HBMZk8xmZLz-X28MZmLr7dT2UKBQlI=.80500db5-68c5-4d88-94db-3e7302529455@github.com>
 <xHKztYOh77LVM_GQ0CDFoGsPEWOB5q9eoxS00tgAaZ4=.93beeee6-b982-485d-afec-a6383d98608a@github.com>
Message-ID: <A3ypBU1fRh3qeBXCvh3LVLoCSGsjMvaIWJg0v4QoTx8=.c6a57dc0-1fab-4606-bad8-efb563b76770@github.com>

On Mon, 16 Nov 2020 11:51:32 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

>> I think it would be good to rebase on top of a recent jdk upstream before merging.
>
> Rebased on HEAD/master.

Tier 1-3 looks good, go ahead and / integrate and I'll sponsor

-------------

PR: https://git.openjdk.java.net/jdk/pull/851

From jvernee at openjdk.java.net  Tue Nov 17 10:11:06 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 17 Nov 2020 10:11:06 GMT
Subject: RFR: 8255150: Add utility methods to check long indexes and
 ranges [v7]
In-Reply-To: <kOpcaootjDKodGDK4i_usJwPQZ3e7heVWE6zqn8tpkQ=.f0591dbb-d097-490c-8c84-d3a377d0bfec@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
 <kOpcaootjDKodGDK4i_usJwPQZ3e7heVWE6zqn8tpkQ=.f0591dbb-d097-490c-8c84-d3a377d0bfec@github.com>
Message-ID: <H_xD8q46cO6wp20uGPNwm_FE6QliELI4NNhbuxufQuM=.f1cb4012-6a0e-4c3c-b7c7-8714408adbf8@github.com>

On Tue, 17 Nov 2020 08:33:20 GMT, Roland Westrelin <roland at openjdk.org> wrote:

>> This change add 3 new methods in Objects:
>> 
>> public static long checkIndex(long index, long length)
>> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
>> public static long checkFromIndexSize(long fromIndex, long size, long length)
>> 
>> This mirrors the int utility methods that were added by JDK-8135248
>> with the same motivations.
>> 
>> As is the case with the int checkIndex(), the long checkIndex() method
>> is JIT compiled as an intrinsic. It allows the JIT to compile
>> checkIndex to an unsigned comparison and properly recognize it as
>> a range check that then becomes a candidate for the existing range check
>> optimizations. This has proven to be important for panama's
>> MemorySegment API and a prototype of this change (with some extra c2
>> improvements) showed that panama micro benchmark results improve
>> significantly.
>> 
>> This change includes:
>> 
>> - the API change
>> - the C2 intrinsic
>> - tests for the API and the C2 intrinsic
>> 
>> This is a joint work with Paul who reviewed and reworked the API change
>> and filled the CSR.
>
> Roland Westrelin has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8255150
>  - Merge branch 'master' into JDK-8255150
>  - Merge branch 'master' into JDK-8255150
>  - Merge branch 'master' of https://git.openjdk.java.net/jdk into JDK-8255150
>  - exclude compiler test when run with -Xcomp
>  - CastLL should define carry_depency
>  - intrinsic comments
>  - Jorn's comments
>  - Update headers and add intrinsic to Graal test ignore list
>  - move compiler test and add bug to test
>  - ... and 17 more: https://git.openjdk.java.net/jdk/compare/4553fa0b...feb32943

Marked as reviewed by jvernee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1003

From roland at openjdk.java.net  Tue Nov 17 10:41:07 2020
From: roland at openjdk.java.net (Roland Westrelin)
Date: Tue, 17 Nov 2020 10:41:07 GMT
Subject: Integrated: 8255150: Add utility methods to check long indexes and
 ranges
In-Reply-To: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
References: <cI0NlUNAwj9A-iL9D78OBpu-3GiqAvo2y4Jl5M28sf4=.c7b0adff-9bc7-4ddc-8477-59116efeb722@github.com>
Message-ID: <HPhIV9SKNMYhU_MPAdrRhcIQUZRqhFUXy_wP-BIdiJ4=.a62f7170-4f6c-4d4d-9135-f2a32a9a727a@github.com>

On Mon, 2 Nov 2020 10:47:18 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> This change add 3 new methods in Objects:
> 
> public static long checkIndex(long index, long length)
> public static long checkFromToIndex(long fromIndex, long toIndex, long length)
> public static long checkFromIndexSize(long fromIndex, long size, long length)
> 
> This mirrors the int utility methods that were added by JDK-8135248
> with the same motivations.
> 
> As is the case with the int checkIndex(), the long checkIndex() method
> is JIT compiled as an intrinsic. It allows the JIT to compile
> checkIndex to an unsigned comparison and properly recognize it as
> a range check that then becomes a candidate for the existing range check
> optimizations. This has proven to be important for panama's
> MemorySegment API and a prototype of this change (with some extra c2
> improvements) showed that panama micro benchmark results improve
> significantly.
> 
> This change includes:
> 
> - the API change
> - the C2 intrinsic
> - tests for the API and the C2 intrinsic
> 
> This is a joint work with Paul who reviewed and reworked the API change
> and filled the CSR.

This pull request has now been integrated.

Changeset: a7422ac2
Author:    Roland Westrelin <roland at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a7422ac2
Stats:     897 lines in 30 files changed: 846 ins; 4 del; 47 mod

8255150: Add utility methods to check long indexes and ranges

Co-authored-by: Paul Sandoz <psandoz at openjdk.org>
Reviewed-by: jvernee, dlong, vlivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/1003

From github.com+20868526+mikeedgar at openjdk.java.net  Tue Nov 17 11:12:19 2020
From: github.com+20868526+mikeedgar at openjdk.java.net (Michael Edgar)
Date: Tue, 17 Nov 2020 11:12:19 GMT
Subject: RFR: 8255918: XMLStreamFilterImpl constructor consumes
 XMLStreamException
Message-ID: <iSippPtr8k1kNkgjscwDHi7J1qO_ewdPV3XDSCwcoSM=.de2a5f09-8454-462c-bdfa-66ca822a3a6c@github.com>

Allow `XMLStreamException` to be thrown to the application when a filtered `XMLStreamReader` encounters an `XMLStreamException` advancing the wrapped `XMLStreamReader`.

Note, this PR includes a method signature change (constructor of `com.sun.org.apache.xerces.internal.impl.XMLStreamFilterImpl`).

-------------

Commit messages:
 - 8255918: Throw XMLStreamExceptions from XMLStreamFilterImpl constructor

Changes: https://git.openjdk.java.net/jdk/pull/1209/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1209&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255918
  Stats: 100 lines in 2 files changed: 88 ins; 7 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1209.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1209/head:pull/1209

PR: https://git.openjdk.java.net/jdk/pull/1209

From mcimadamore at openjdk.java.net  Tue Nov 17 11:15:13 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 17 Nov 2020 11:15:13 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v26]
In-Reply-To: <_MAO7-ELT_n5RxduwWzN7gJ23wpv06mQZftEFwtNWYs=.579b699a-8424-4eac-9b30-b37607e1ba32@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <pIsenyXjQivcxiLfuUXLhdrZpNA3SvyFja9oY-JrW6U=.f49212f6-d1d9-4b07-8d8d-4257fce57998@github.com>
 <_MAO7-ELT_n5RxduwWzN7gJ23wpv06mQZftEFwtNWYs=.579b699a-8424-4eac-9b30-b37607e1ba32@github.com>
Message-ID: <i9uxhKPUcFHVTwfkZJs4c_rDWPmMInRr-SNiyaEeuXg=.9e54f730-26d1-4958-b548-24d90e0ae429@github.com>

On Mon, 16 Nov 2020 18:44:55 GMT, Rajan Halade <rhalade at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix aarch64 test failure
>
> src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java line 387:
> 
>> 385:     }
>> 386: 
>> 387:     public static NativeLibrary defaultLibrary = new NativeLibraryImpl(Object.class, "<default>", true, true) {
> 
> This field can be final.

Thanks - I already made this change in the latest revision.

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From winterhalter at openjdk.java.net  Tue Nov 17 11:27:03 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Tue, 17 Nov 2020 11:27:03 GMT
Subject: Integrated: 8202471: (ann) Cannot read type annotations on generic
 receiver type's type variables
In-Reply-To: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
References: <WJVy8_XXMJf5UOCifoPHUc06qVaU2MKlT_oosLaiqwg=.c2b16a91-64ce-4468-991c-a51ffd6b3202@github.com>
Message-ID: <CCg4hE5PQJoSt1xQHLhxCRCKyJANW_Me_GNZwyuw9sQ=.56f46f18-0c28-4f64-bc93-480c826338e7@github.com>

On Sat, 24 Oct 2020 21:44:22 GMT, Rafael Winterhalter <winterhalter at openjdk.org> wrote:

> A method's or constructor's owner type might carry annotations on its potential type parameters but is never represented as parameterized type what makes these parameters inaccessible at runtime, despite the presence of parameter type annotations.

This pull request has now been integrated.

Changeset: 53a31889
Author:    Rafael Winterhalter <winterhalter at openjdk.org>
Committer: Joel Borggr?n-Franck <jfranck at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/53a31889
Stats:     242 lines in 7 files changed: 235 ins; 0 del; 7 mod

8202471: (ann) Cannot read type annotations on generic receiver type's type variables

Reviewed-by: jfranck

-------------

PR: https://git.openjdk.java.net/jdk/pull/851

From mcimadamore at openjdk.java.net  Tue Nov 17 11:49:26 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 17 Nov 2020 11:49:26 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v28]
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <inO41H3BnOw6gl33yBAiVNs3DTh_sFWGmHbbRoovhPs=.d2ce516d-6a47-41fc-9411-2f326ea75550@github.com>

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 95 commits:

 - Merge branch 'master' into 8254231_linker
 - Add `final` modifier on NativeLibraries.defaultLookup
 - Fix aarch64 test failure
 - Fix signature mismatch on aarch64
 - Merge pull request #9 from JornVernee/Windows_Warnings
   
   Fix warnings on MSVC
 - Fix warnings on MSVC
 - Merge pull request #8 from JornVernee/Vlad_Comments
   
   Address More Review comments
 - - Don't print anything in nmehtod debug output for native invoker if there are none.
   - Use memcpy to copy native stubs to nmethod data
 - Simplify print code
 - Merge branch '8254231_linker' into Vlad_Comments
 - ... and 85 more: https://git.openjdk.java.net/jdk/compare/a7422ac2...40bd5df1

-------------

Changes: https://git.openjdk.java.net/jdk/pull/634/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=634&range=27
  Stats: 67469 lines in 212 files changed: 67290 ins; 79 del; 100 mod
  Patch: https://git.openjdk.java.net/jdk/pull/634.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/634/head:pull/634

PR: https://git.openjdk.java.net/jdk/pull/634

From mcimadamore at openjdk.java.net  Tue Nov 17 12:15:09 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 17 Nov 2020 12:15:09 GMT
Subject: RFR: 8256435: [TESTBUG] java/foreign/TestHandshake.java fails
 with direct buffer memory OOM
In-Reply-To: <n0zEzhAVNoLyOMxaquudae8RmzPFsLuX2g56GQY57Fw=.7fed7240-8e67-41c5-aa82-5049f2727066@github.com>
References: <n0zEzhAVNoLyOMxaquudae8RmzPFsLuX2g56GQY57Fw=.7fed7240-8e67-41c5-aa82-5049f2727066@github.com>
Message-ID: <yS5Ik5cmO1n9qLUhDxQL7ScnycfyfIJL_0IlTiSnTx4=.9c7c224c-5312-4260-b415-c803e245f419@github.com>

On Tue, 17 Nov 2020 09:07:03 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> I ran this test on a machine with 224 logical CPUs and it fails with:
> 
>   ITERATION 3
>   test TestHandshake.testHandshake("SegmentMismatchAccessor", TestHandshake$$Lambda$57/0x00000001000e7968 at 37c4b344): failure
>   java.lang.OutOfMemoryError: Cannot reserve 1000000 bytes of direct buffer memory (allocated: 536008192, limit: 536870912)
> 
> SegmentMismatchAccessor allocates a 1MB native segment for each CPU on
> each iteration. This can quickly reach the allocation limit if there is
> no intervening GC. Explicitly close the segment after each iteration to
> release the memory.

Whoops - good catch!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1254

From herrick at openjdk.java.net  Tue Nov 17 13:22:04 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 17 Nov 2020 13:22:04 GMT
Subject: RFR: JDK-8255055: Create two phase test for case with different
 names, and fix linux DTI
In-Reply-To: <tF4sorswYo1o0DDfJPBfWBcgj8LNEQn5k3b4rdWtPY8=.fea65639-c00e-4c7b-b571-3d343fdbe507@github.com>
References: <zoptCE9lKZ7D837MlSOcBNzsLtMkBH0yey6wDct8b2c=.aef04c82-1e5e-4f5d-b8f6-afc76774d1cb@github.com>
 <oX7UnHZVocLN3yKL9tE_ei7vOBZ915HRmCSalYIe3gc=.26010242-e5f3-4264-b52b-1d0f54941b6e@github.com>
 <Znr9hoKSs5-gIVH_gO_UJMeOoAM8VyLtyCX0DuVmGjc=.e66c58d9-10bd-4665-9c58-3967a27be183@github.com>
 <2iz-5U-pbfFHGtuJqECEi4YR8V22cCQunpDhY9_U434=.e0a94f24-ed04-4cc7-8251-3e771fa83e53@github.com>
 <tF4sorswYo1o0DDfJPBfWBcgj8LNEQn5k3b4rdWtPY8=.fea65639-c00e-4c7b-b571-3d343fdbe507@github.com>
Message-ID: <FTMIXP7zDWYkaREkXUuHd-_WogKxarBT9U1QX373rJ4=.f2b86234-eed2-4971-86f4-c354e26c32d5@github.com>

On Tue, 17 Nov 2020 02:01:32 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> In scenario 1, the installer would be Bar-1.0.{exe, msi, pkg ...}
>> The change in test above tests this.
>> Scenario 2 would be an error currently, since all jpackage commands require a "--name" argument, however, it would be reasonable to modify restriction to require either a name or an app-image, extracting the name from the app-image in this case.
>
> I think we need to define the behavior we want from two phase jpackage runs first and create tests after that. I agree it would be good to extract name from app image if it is not specified explicitly when building an installer

I see that further changes are needed in jpackage code to properly handle all cases of installer name vs application name.
I will open a new bug to fix all such cases, and include test cases
I will then close this bug as dupe of that, and I am closing this pull request

-------------

PR: https://git.openjdk.java.net/jdk/pull/1229

From herrick at openjdk.java.net  Tue Nov 17 13:22:07 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 17 Nov 2020 13:22:07 GMT
Subject: Withdrawn: JDK-8255055: Create two phase test for case with different
 names, and fix linux DTI
In-Reply-To: <zoptCE9lKZ7D837MlSOcBNzsLtMkBH0yey6wDct8b2c=.aef04c82-1e5e-4f5d-b8f6-afc76774d1cb@github.com>
References: <zoptCE9lKZ7D837MlSOcBNzsLtMkBH0yey6wDct8b2c=.aef04c82-1e5e-4f5d-b8f6-afc76774d1cb@github.com>
Message-ID: <wKoEONdZY8tIY516q6Kn1vRMBfSjQ5iCfnfZ_b-QwlA=.377e64da-6df1-425b-a20a-d3a271686dc3@github.com>

On Mon, 16 Nov 2020 15:15:02 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> ? fix linux DTI

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1229

From mcimadamore at openjdk.java.net  Tue Nov 17 14:59:07 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 17 Nov 2020 14:59:07 GMT
Subject: RFR: 8256477: Specialize heap memory segment implementations
Message-ID: <D2lmkIk6L4CK-cFq8ulq7Sa8b4LTuF2yIsTQn0vIa6w=.a087badb-f398-4bb7-9899-39ba5c083d15@github.com>

The current memory segment implementation defines a hierarchy with 3 concrete classes: one for heap segments, one for native segments and one for mapped segments.

Since there can be many kinds of heap segments (e.g. created from a byte[] or from a float[]) the current implementation is prone to type profile pollution problems: if enough heap segments are created (of different kinds), the JIT compiler will give up on speculating on the heap segment kind, which will then result in poor performances.

This issue can be reproduced in one of the existing benchmark, by adding some initialization code which is enough to pollute the types profiles. When that happens, performance numbers look like the following:

Benchmark                             (polluteProfile)  Mode  Cnt  Score   Error  Units
LoopOverNonConstantHeap.segment_loop             false  avgt   10  0.285 ? 0.003  ms/op
LoopOverNonConstantHeap.segment_loop              true  avgt   10  5.540 ? 0.143  ms/op

(Thanks to Vlad for coming up for the exact incantation which leads to profile pollution :-) )

The solution is to create a sharp subclass for each heap segment case. With this, C2 has always a sharp Unsafe *base* to work with, and performances are stable regardless of profile pollution attempts.

This patch also tweaks the benchmark for heap segments so that it checks it with and without profile pollution.

-------------

Commit messages:
 - Tweak code so that specialized classes define their own factories
 - make base() method abstract in HeapMemorySegmentImpl
 - Create specialized subclasses for all the heap segment cases

Changes: https://git.openjdk.java.net/jdk/pull/1259/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1259&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256477
  Stats: 187 lines in 4 files changed: 140 ins; 4 del; 43 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1259.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1259/head:pull/1259

PR: https://git.openjdk.java.net/jdk/pull/1259

From rkennke at openjdk.java.net  Tue Nov 17 15:50:02 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Tue, 17 Nov 2020 15:50:02 GMT
Subject: Integrated: 8256370: Add asserts to Reference.getInactive()
In-Reply-To: <-QVwpOcOTp5Gb7Sjq04ihTxP5h0nMHCh307WqkEjE-M=.83b69e68-19e6-4a10-8bd3-010d2c008140@github.com>
References: <-QVwpOcOTp5Gb7Sjq04ihTxP5h0nMHCh307WqkEjE-M=.83b69e68-19e6-4a10-8bd3-010d2c008140@github.com>
Message-ID: <qizKnBT-weMim-BBzO4ShjCWn6hgKXA-1SAxKwror9E=.02a558c0-e3d9-4d23-856a-bdf44e903738@github.com>

On Mon, 16 Nov 2020 17:29:20 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

> A follow-up to JDK-8256106, this is adding two asserts to check that the API is used as it should be, i.e. only on inactive FinalReferences. Also, in Finalizer, where getInactive() is used, there is a null-check. The GC must never clean the referent, and Java code doesn't clean it either, it would be a bug if we ever see null there. I think it's better to fail there (with assert or NPE) when that happens instead of silently accepting it.
> 
> Testing:
>  - [x] tier1
>  - [x] tier2

This pull request has now been integrated.

Changeset: f2a9d02d
Author:    Roman Kennke <rkennke at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/f2a9d02d
Stats:     4 lines in 2 files changed: 3 ins; 0 del; 1 mod

8256370: Add asserts to Reference.getInactive()

Reviewed-by: mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/1231

From jvernee at openjdk.java.net  Tue Nov 17 16:10:04 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 17 Nov 2020 16:10:04 GMT
Subject: RFR: 8256477: Specialize heap memory segment implementations
In-Reply-To: <D2lmkIk6L4CK-cFq8ulq7Sa8b4LTuF2yIsTQn0vIa6w=.a087badb-f398-4bb7-9899-39ba5c083d15@github.com>
References: <D2lmkIk6L4CK-cFq8ulq7Sa8b4LTuF2yIsTQn0vIa6w=.a087badb-f398-4bb7-9899-39ba5c083d15@github.com>
Message-ID: <PaxSWiaxTluMEPGnfHe2DxR3GKXlhfycOi8sZJfLWfk=.ed374a17-ecb8-40bc-9d53-54062fdb5aba@github.com>

On Tue, 17 Nov 2020 14:55:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The current memory segment implementation defines a hierarchy with 3 concrete classes: one for heap segments, one for native segments and one for mapped segments.
> 
> Since there can be many kinds of heap segments (e.g. created from a byte[] or from a float[]) the current implementation is prone to type profile pollution problems: if enough heap segments are created (of different kinds), the JIT compiler will give up on speculating on the heap segment kind, which will then result in poor performances.
> 
> This issue can be reproduced in one of the existing benchmark, by adding some initialization code which is enough to pollute the types profiles. When that happens, performance numbers look like the following:
> 
> Benchmark                             (polluteProfile)  Mode  Cnt  Score   Error  Units
> LoopOverNonConstantHeap.segment_loop             false  avgt   10  0.285 ? 0.003  ms/op
> LoopOverNonConstantHeap.segment_loop              true  avgt   10  5.540 ? 0.143  ms/op
> 
> (Thanks to Vlad for coming up for the exact incantation which leads to profile pollution :-) )
> 
> The solution is to create a sharp subclass for each heap segment case. With this, C2 has always a sharp Unsafe *base* to work with, and performances are stable regardless of profile pollution attempts.
> 
> This patch also tweaks the benchmark for heap segments so that it checks it with and without profile pollution.

Marked as reviewed by jvernee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1259

From jvernee at openjdk.java.net  Tue Nov 17 18:38:08 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 17 Nov 2020 18:38:08 GMT
Subject: RFR: 8256189: Exact VarHandle tests should test withInvokeBehavior()
 works as expected
Message-ID: <0BvFTYxsdMgM5e4M2t6Ok475WQasE7Ni2BbTM6y6AUc=.6eb77e51-e37f-4182-9423-4d763d3c5cf0@github.com>

This PR sharpens the testing done by test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java after @mcimadamore reported that the test was not catching an issue with memory access var handles; namely that the implementation of withInvokeBehavior was incorrect.

After some debugging it turned out that the test never actually tested:
(1) going back to invoke behavior from a var handle with invoke exact behavior
(2) the memory access handle implementation of withInvoke(Exact)Behavior, due to memory handles always being adapted.

The patch adds testing for (1), and adds a flag to jdk.internal.foreign.Utils to turn off the adaptation, so that we can test the 'naked' memory access var handles as well for (2).

I've also tried to reduce some of the code duplication by creating the higher order doTest function, that does most of the testing (besides setting up var handles and test values).

-------------

Commit messages:
 - Fix memory handles test to use un-adapted var handles, so we can test the invoke exact behaviour on 'naked' memory handles
 - - Reduce VarHandleTestExact code duplication

Changes: https://git.openjdk.java.net/jdk/pull/1267/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1267&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256189
  Stats: 173 lines in 3 files changed: 48 ins; 80 del; 45 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1267.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1267/head:pull/1267

PR: https://git.openjdk.java.net/jdk/pull/1267

From nlisker at gmail.com  Tue Nov 17 09:46:43 2020
From: nlisker at gmail.com (Nir Lisker)
Date: Tue, 17 Nov 2020 11:46:43 +0200
Subject: 'Find' method for Iterable
In-Reply-To: <CAO5-QM0XE9bXf3j=qOPwfNgE=yZEQrXiXYJGUs_NNvce00HYQA@mail.gmail.com>
References: <CA+0ynh9wguU9b4ZQnOz=ySeSa9sovYzeeQ=rAa8fPJCpo=gXag@mail.gmail.com>
 <219103610.2532126.1600289966746.JavaMail.zimbra@u-pem.fr>
 <e4abaa1c-2d82-4ceb-a046-f914cb6056af@oracle.com>
 <CA+0ynh-54KbmQrshE4cJdJ8Q=MCBEUbN3cnW7=J=6Xbr1g5HmQ@mail.gmail.com>
 <CA+0ynh9n9+_4+AQkLoiD8vvKCgdCV3YCuC0QsA=eHtN+-e9hZQ@mail.gmail.com>
 <CAO5-QM0XE9bXf3j=qOPwfNgE=yZEQrXiXYJGUs_NNvce00HYQA@mail.gmail.com>
Message-ID: <CA+0ynh8e7aZN0-LT88MjkA2yGBhodtycahHqa4==+xuYwnCTOA@mail.gmail.com>

I think that the discussion is still at the level of if it's an acceptable
addition and not yet at where to implement it. I gave my reasoning in
response to Stuart's points as to what I think is acceptable and what
isn't. Whether the java.lang package has special status is a bit ahead of
where we are now.

On Wed, Nov 11, 2020 at 7:22 PM Justin Dekeyser <justin.dekeyser at gmail.com>
wrote:

> Hello all,
>
> Were those downsides seriously considered and strongly argued against? :
>
> (1) Iterable belongs to java.lang so, at least from how it is usually
> approached, it's a feature at the very level of the language, not a
> util feature like Collection. Adding a find on it, is it really
> relevant, or should it be concerned with the simple idea of unlocking
> the enhanced-for loop syntax?
>
> (2) For the find() method to stop on any Iterable, the Iterable should
> have finite size. This mean the size() method can be implemented too,
> by this move:
> ```java
> default int size() {
>    int[] dummy = { 0 };
>    Predicate<T> falsy = $ -> { dummy[0] += 1; return false; }
>    find(falsy);
>    return dummy[0];
> }
> ```
> At the very moment an Iterable<T> also has a size(), a Collection<T>
> implementation can be provided (since the altering methods add/remove
> are optional in this spec). So , long story short:
>
> Adding a find() method on Iterable<T> with a contract that it stops
> (stops, and not just linear search time), makes it a Collection. It
> really looks like a nonsense. Or maybe you're going to relax the "this
> method is guaranteed to stop" from the spec? Is it then still
> relevant?
>
> Note: This (2) problem is not a problem for now, because all the utils
> that turns Iterable<T> to a collection like stuff, or a Stream, are
> actually features *on those latter* classes. Hence it's not a concern
> of Iterable<T> itself.
> The problem with (1) is really a communication problem: nothing is
> made in the Java documentation to clearly indicate whether or not
> Iterable should be used businesswise, or is it only for
> syntax-enhancement. (The same problem goes for AutoCloseable: you'll
> really find two schools out of there.)
>
> (3) To my opinion, most people are using Iterable either from a
> collection (where the .stream().filter(p).findAny() makes the job.
> It's not perfect but it's quite clear and flexible) or with a
> ResultSet, where the SQL procedure could/should be used anyway. The
> other cases look so exotic (but I might be wrong) that I really wonder
> how a find method on a Iterable (and not Collection) stuff can be felt
> so useful and language fundamental, that it should be in the java.lang
> package.
>
> Best regards,
>
> Justin Dekeyser
>
> On Tue, Nov 10, 2020 at 7:02 PM Nir Lisker <nlisker at gmail.com> wrote:
> >
> > Did this discussion get lost?
> >
> > On Sun, Sep 20, 2020 at 1:27 AM Nir Lisker <nlisker at gmail.com> wrote:
> >
> > > While it might not be difficult to add a find() method to Iterable, why
> > >> limit it to
> > >> the find operation, and what about all the other operations available
> on
> > >> Stream?
> > >
> > >
> > > Good question. I would say it's a matter of how much it is used and
> what
> > > it takes to implement it. The find operation is a lot more common than
> > > reduce from what I observe, for example, so I wouldn't suggest reduce
> to be
> > > added..A map(Function<T,R>) operation would require creating a new
> > > collection/iterable internally, and that can be messy (you could
> > > preemptively create and pass your own, but then I doubt the worthiness
> of
> > > it). forEach already exists. I just don't see anything enticing.
> > >
> > > Maybe what's necessary is a way to convert an Iterable to a Stream.
> > >
> > >
> > > Most Iterables are Collections and arrays, and these are easy to
> convert,
> > > so I'm not sure if that really helps. Besides,the idea is to avoid
> Stream,
> > > as I've mentioned, due to the cumbersomeness and the overhead of
> creating a
> > > stream. If I need to do
> > >
> > > iterable.stream().filter(person -> person.id ==
> 123456).findAny/First()
> > >
> > > then I didn't really solve my problem.
> > >
> > > On the other hand, your examples use a list. The List interface already
> > >> has methods
> > >> indexOf/lastIndexOf which search the list for a particular object
> that's
> > >> compared
> > >> using equals(). It seems reasonable to consider similar methods that
> take
> > >> a
> > >> predicate instead of an object.
> > >
> > >
> > > I could have used a Set just as well. As for indexOf(Predicate<T>), I
> > > would say that it is useful (but personally, I hardly ever need the
> index
> > > of an object, I need the object itself). Interestingly,
> > > removeIf(Predicate<T>) exists, but remove(Predicate<T>) doesn't. I
> would
> > > think twice before suggesting to add it though.
> > >
> > > Ultimately, you have access to a lot of analytics and codebase scans.
> If
> > > you know which patterns are used a lot more than others it would be a
> good
> > > guide. If there are a lot of iterations in order to find an object, its
> > > index, or to remove it (or something else), perhaps it's worth
> supplying
> > > these methods. After all, forEach(Consumer<T>) exists and it iterates
> while
> > > calling accept(t) - not that different from iterating with test(t).
> > >
> > > P.S. lastIndexOf I find odd in the sense that it's the only method I
> found
> > > that iterates backwards, We don't have, removeLast, removeIfBackwards,
> > > forEachBackwards, a backwards for-each loop, or addLast (the latter is
> > > add(list.size()-1, e); ).
> > >
> > > - Nir
> > >
> > > On Thu, Sep 17, 2020 at 1:32 AM Stuart Marks <stuart.marks at oracle.com>
> > > wrote:
> > >
> > >>
> > >>
> > >> On 9/16/20 1:59 PM, Remi Forax wrote:
> > >> > ----- Mail original -----
> > >> >> De: "Nir Lisker" <nlisker at gmail.com>
> > >> >> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> > >> >> Envoy?: Lundi 14 Septembre 2020 20:56:27
> > >> >> Objet: 'Find' method for Iterable
> > >> >
> > >> >> Hi,
> > >> >>
> > >> >> This has probably been brought up at some point. When we need to
> find
> > >> an
> > >> >> item in a collection based on its properties, we can either do it
> in a
> > >> >> loop, testing each item, or in a stream with filter and
> findFirst/Any.
> > >> >>
> > >> >> I would think that a method in Iterable<T> be useful, along the
> lines
> > >> of:
> > >> >>
> > >> >> public <T> Optional<T> find(Predicate<T> condition) {
> > >> >>     Objects.requireNonNull(condition);
> > >> >>     for (T t : this) {
> > >> >>          if (condition.test(t)) {
> > >> >>              return Optional.of(t);
> > >> >>         }
> > >> >>     }
> > >> >>     return Optional.empty();
> > >> >> }
> > >> >>
> > >> >> With usage:
> > >> >>
> > >> >> list.find(person -> person.id == 123456);
> > >> >>
> > >> >> There are a few issues with the method here such as t being null in
> > >> >> null-friendly collections and the lack of bound generic types, but
> this
> > >> >> example is just used to explain the intention.
> > >> >>
> > >> >> It will be an alternative to
> > >> >>
> > >> >> list.stream().filter(person -> person.id ==
> 123456).findAny/First()
> > >> >> (depending on if the collection is ordered or not)
> > >> >>
> > >> >> which doesn't create a stream, similar to Iterable#forEach vs
> > >> >> Stream#forEach.
> > >> >>
> > >> >> Maybe with pattern matching this would become more appetizing.
> > >> >
> > >> > During the development of Java 8, we first tried to use
> > >> Iterator/Iterable instead of using a novel interface Stream.
> > >> > But a Stream cleanly separate the lazy side effect free API from the
> > >> mutable one (Collection) and can be optimized better by the VM (it's
> a push
> > >> API instead of being a pull API).
> > >> >
> > >> > The other question is why there is no method find() on Collection, i
> > >> believe it's because while find() is ok for any DB API, find() is
> dangerous
> > >> on a Collection because the execution time is linear, so people may
> use it
> > >> instead of using a Map.
> > >>
> > >>
> > >> Hi Nir,
> > >>
> > >> R?mi is correct to point out this distinction between the lazy
> operations
> > >> (which
> > >> appear on Stream) and the eager (and possibly mutating) operations on
> > >> Collections. I
> > >> think we want to preserve this distinction.
> > >>
> > >> While it might not be difficult to add a find() method to Iterable,
> why
> > >> limit it to
> > >> the find operation, and what about all the other operations available
> on
> > >> Stream?
> > >> Maybe what's necessary is a way to convert an Iterable to a Stream. In
> > >> fact, this is
> > >> already possible:
> > >>
> > >>      StreamSupport.stream(iterable.spliterator(), false)
> > >>
> > >> Well, this is mouthful, so maybe there ought to be an easier way to
> > >> convert an
> > >> Iterable to a Stream.
> > >>
> > >> On the other hand, your examples use a list. The List interface
> already
> > >> has methods
> > >> indexOf/lastIndexOf which search the list for a particular object
> that's
> > >> compared
> > >> using equals(). It seems reasonable to consider similar methods that
> take
> > >> a
> > >> predicate instead of an object.
> > >>
> > >> Does either of these sound promising?
> > >>
> > >> s'marks
> > >>
> > >
>

From mcimadamore at openjdk.java.net  Tue Nov 17 19:07:04 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 17 Nov 2020 19:07:04 GMT
Subject: RFR: 8256189: Exact VarHandle tests should test
 withInvokeBehavior() works as expected
In-Reply-To: <0BvFTYxsdMgM5e4M2t6Ok475WQasE7Ni2BbTM6y6AUc=.6eb77e51-e37f-4182-9423-4d763d3c5cf0@github.com>
References: <0BvFTYxsdMgM5e4M2t6Ok475WQasE7Ni2BbTM6y6AUc=.6eb77e51-e37f-4182-9423-4d763d3c5cf0@github.com>
Message-ID: <Yvp2NjkDAQDySEhYQvKSUhM8C8DoGvIjxcb-CWo3rZI=.2ff019a7-c2bd-4343-99da-4960761eef24@github.com>

On Tue, 17 Nov 2020 18:32:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This PR sharpens the testing done by test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java after @mcimadamore reported that the test was not catching an issue with memory access var handles; namely that the implementation of withInvokeBehavior was incorrect.
> 
> After some debugging it turned out that the test never actually tested:
> (1) going back to invoke behavior from a var handle with invoke exact behavior
> (2) the memory access handle implementation of withInvoke(Exact)Behavior, due to memory handles always being adapted.
> 
> The patch adds testing for (1), and adds a flag to jdk.internal.foreign.Utils to turn off the adaptation, so that we can test the 'naked' memory access var handles as well for (2).
> 
> I've also tried to reduce some of the code duplication by creating the higher order doTest function, that does most of the testing (besides setting up var handles and test values).

Looks good -thanks for catching the issue in the memory access var handle template

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1267

From brian.goetz at oracle.com  Tue Nov 17 19:44:17 2020
From: brian.goetz at oracle.com (Brian Goetz)
Date: Tue, 17 Nov 2020 14:44:17 -0500
Subject: 'Find' method for Iterable
In-Reply-To: <54f82257-b5c5-287f-5c99-8b922d597eb3@fiolino.de>
References: <CA+0ynh9wguU9b4ZQnOz=ySeSa9sovYzeeQ=rAa8fPJCpo=gXag@mail.gmail.com>
 <219103610.2532126.1600289966746.JavaMail.zimbra@u-pem.fr>
 <CA+0ynh9eUen9n_knA4bfZCPTu-ZmXbOMTdtuDVfrLi1iw+RekQ@mail.gmail.com>
 <54f82257-b5c5-287f-5c99-8b922d597eb3@fiolino.de>
Message-ID: <75e61d30-a675-bcdc-6475-533bceecdfe7@oracle.com>



On 9/21/2020 4:08 AM, Michael Kuhlmann wrote:
> But after thinking about it, I'm now convinced that it would be a bad 
> idea. Because it extends the scope of this small, tiny Iterable 
> interface to something bigger which it shouldn't be. 

This response captures the essence of the problem.? You may think you 
are asking for "just one more method on Iterable", but really, what you 
are asking for is to turn Iterable into something it is not.? Iterable 
exists not to be "smallest collection", but as the interface to the 
foreach-loop.? Yes, we could have chosen a different design center for 
Iterable (Eclipse Collections did, see RichIterable), but we didn't.? 
Adding this method merely sends the signal that we want to extend 
Iterable to be more than it is, which opens the floodgate to requests 
(and eventually demands) for more methods.

> I can ask about Iterable#forEach - is it there only because it was there to
> begin with? Would it have been a bad idea to add one if we had streams
> already?

While you can make an argument that forEach is excessive, the fact that 
you make this argument illustrates the essential problem with this 
proposal.? Your argument wrt forEach is "If that makes sense, then so 
does find."? If you pull on that string, then this method forms the 
basis of tomorrow's assumption: "You have forEach and find, it is 
unreasonable to not add <my pet method>".

So, Iterable should stay simple.? (The other arguments against it on 
this thread, are also valid, but this is the most important one.)

From igraves at openjdk.java.net  Tue Nov 17 19:58:29 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Tue, 17 Nov 2020 19:58:29 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v9]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <fwG1dzKEe-kw5XW3pmt_O3sniR5cu5zU8cDmvWXYYZw=.b7213dfc-ff31-4e6f-97c8-9ec0ebd3a58e@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Adding test coverage. Tweaking wording in docs.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/5a0effe1..aaa35af2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=07-08

  Stats: 106 lines in 4 files changed: 103 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From jlaskey at openjdk.java.net  Tue Nov 17 20:04:11 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 17 Nov 2020 20:04:11 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
Message-ID: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@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 .

-------------

Commit messages:
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
 - Merge branch 'master' into 8248862
 - Merge branch 'master' into 8248862
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
 - Merge branch 'master' into 8248862
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
 - 8248862; Implement Enhanced Pseudo-Random Number Generators
 - Merge branch 'master' into 8248862
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
 - Merge branch 'master' into 8248862
 - ... and 27 more: https://git.openjdk.java.net/jdk/compare/9efbb463...7469ca58

Changes: https://git.openjdk.java.net/jdk/pull/1273/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1273&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8248862
  Stats: 14875 lines in 31 files changed: 11094 ins; 3704 del; 77 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1273.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1273/head:pull/1273

PR: https://git.openjdk.java.net/jdk/pull/1273

From smarks at openjdk.java.net  Tue Nov 17 20:06:15 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 17 Nov 2020 20:06:15 GMT
Subject: RFR: 8256152: tests fail because of ambiguous method resolution
Message-ID: <2Sc4ZnmZ510_ykvmkkJbICYWTtzt1VH32x_LT6Miaxs=.5f9dd093-8112-4ab2-b323-e0fae0d63bfe@github.com>

Added a cast in the right place, thanks to @jonathan-gibbons.

-------------

Commit messages:
 - 8256152: tests fail because of ambiguous method resolution

Changes: https://git.openjdk.java.net/jdk/pull/1274/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1274&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256152
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1274.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1274/head:pull/1274

PR: https://git.openjdk.java.net/jdk/pull/1274

From smarks at openjdk.java.net  Tue Nov 17 20:08:05 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 17 Nov 2020 20:08:05 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v2]
In-Reply-To: <EKK54iv-Ok1SZ1XEeUTm-Yjofp-lSOaRFpyKixb-xKI=.f6489482-9026-46aa-8a1f-afa8dd9d4d58@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <aBcWsV_NhVd3jaVqcC-TKl38hWXUmEIrSUmsYPPF88g=.2b4b7d94-a3cc-4fc0-a9e7-defa360ee3a0@github.com>
 <zNl6puL1sy_S1JWp3tLiQQf2YrhHvHY3GtGIBjtfz7E=.5eb94743-bfbb-4908-a2af-e9aceb22c9d3@github.com>
 <VeEg7hCJwqiJ8eqvlPLb9Oi6eNx-pgOqTzwshgb01jk=.5169c749-c176-438b-adc2-9e94921aa7c2@github.com>
 <hhibYsPaakZXBiorfc_4a2T6Y0fwkHATDT49wamF5QU=.4b4549f7-863d-4902-a34c-7648d806d4fd@github.com>
 <ItQDJF_yBhjEKceLh1skwy3tYtIY5T_TxOQX0h6nYBI=.0503f471-5876-4448-80b3-968a16f38293@github.com>
 <Y71HRQPKV6Uc-_6PkgZWl97d3bHhu4BmQjE_pL8MEmA=.f6ab9972-7ed4-41fc-8dcf-c5286b0062fb@github.com>
 <EKK54iv-Ok1SZ1XEeUTm-Yjofp-lSOaRFpyKixb-xKI=.f6489482-9026-46aa-8a1f-afa8dd9d4d58@github.com>
Message-ID: <BESZZeK2WVIubLeJFi1BZayJegadJHxwsB-RFio6k7I=.79995b04-49c9-4aa1-a1b9-3382e0bb4d14@github.com>

On Tue, 10 Nov 2020 09:34:56 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> I can see that having a separate IMM_LIST_NULLS type might be necessary to preserve the allows-null/disallows-null behaviour of indexOf and lastIndexOf methods...
>> 
>> NOTE ALSO that ListN.equals(o) and ListN.hashCode() are inherited from AbstractImmutableList:
>> 
>>         @Override
>>         public boolean equals(Object o) {
>>             if (o == this) {
>>                 return true;
>>             }
>> 
>>             if (!(o instanceof List)) {
>>                 return false;
>>             }
>> 
>>             Iterator<?> oit = ((List<?>) o).iterator();
>>             for (int i = 0, s = size(); i < s; i++) {
>>                 if (!oit.hasNext() || !get(i).equals(oit.next())) {
>>                     return false;
>>                 }
>>             }
>>             return !oit.hasNext();
>>         }
>> and
>>         public int hashCode() {
>>             int hash = 1;
>>             for (int i = 0, s = size(); i < s; i++) {
>>                 hash = 31 * hash + get(i).hashCode();
>>             }
>>             return hash;
>>         }
>> 
>> ...which means they will throw NPE when the list contains null. The same goes for SubList.
>
>> @plevart wrote:
>> 
>> > But the question is how does having a separate CollSer.IMM_LIST_NULLS type prevent that from happening?
>> 
>> When a serialized list with IMM_LIST_NULLS is deserialized on an older JDK, it'll throw InvalidObjectException since that tag isn't valid on older JDKs. Obviously this is still an error, but it's a fail-fast approach that avoids letting nulls leak into a data structure where they might cause a problem some arbitrary time later.
>> 
> 
> Yes, but that is JDK16+ vs. JDK15- and not App V1 vs. App V2 thing. If both apps run on JDK16+, there will be no exception.
> 
> What I'm trying to say is that the same problem of injecting unexpected nulls via serialization/deserialization can happen also if App V2 starts using ArrayList to construct the data structure and serialize it while App V1 deserializes it and expects non-null values only. App V1 would already have to guard against null values during deserialization in that case, because possibility of null values in deserialized data structure is nothing new for App V1.

@plevart wrote:
> Yes, but that is JDK16+ vs. JDK15- and not App V1 vs. App V2 thing. If both apps run on JDK16+, there will be no exception.

Sure, the IMM_LIST_NULLS tag only helps with serialization compatibility across JDK releases. There are lots of ways an app can make incompatible changes to the serialized forms of its objects that we have no way of detecting.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1026

From psandoz at openjdk.java.net  Tue Nov 17 20:18:10 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Tue, 17 Nov 2020 20:18:10 GMT
Subject: RFR: 8256152: tests fail because of ambiguous method resolution
In-Reply-To: <2Sc4ZnmZ510_ykvmkkJbICYWTtzt1VH32x_LT6Miaxs=.5f9dd093-8112-4ab2-b323-e0fae0d63bfe@github.com>
References: <2Sc4ZnmZ510_ykvmkkJbICYWTtzt1VH32x_LT6Miaxs=.5f9dd093-8112-4ab2-b323-e0fae0d63bfe@github.com>
Message-ID: <-4tMI0TKJo5603btB4tpzVTag51jUKCa9TFzmd6nsM0=.881eb338-72c5-4d1b-ab75-b98812cadda5@github.com>

On Tue, 17 Nov 2020 20:01:37 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Added a cast in the right place, thanks to @jonathan-gibbons.

test/jdk/java/util/stream/boottest/java.base/java/util/stream/DoubleNodeTest.java line 69:

> 67:         assertEquals(list.size(), array.length);
> 68:         for (int i = 0; i < array.length; i++)
> 69:             assertEquals((Object) array[i], list.get(i));

Can you make it consistent with the other NodeTest implementations e.g.:
    private static void assertEqualsListIntArray(List<Integer> list, int[] array) {
        assertEquals(list.size(), array.length);
        for (int i = 0; i < array.length; i++)
            assertEquals(array[i], (int) list.get(i));
    }
?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1274

From erikj at openjdk.java.net  Tue Nov 17 20:18:08 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Tue, 17 Nov 2020 20:18:08 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
Message-ID: <g4TmJKxtQWJf6USseQWrRNfuqOzqSTmZfmaIv0K6F2U=.6fa29fb4-260d-4264-bd33-940ac8caf412@github.com>

On Tue, 17 Nov 2020 19:58:47 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 .

It looks like you have deleted the doc directory. That can't be right?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From jlaskey at openjdk.java.net  Tue Nov 17 20:43:03 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 17 Nov 2020 20:43:03 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <g4TmJKxtQWJf6USseQWrRNfuqOzqSTmZfmaIv0K6F2U=.6fa29fb4-260d-4264-bd33-940ac8caf412@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
 <g4TmJKxtQWJf6USseQWrRNfuqOzqSTmZfmaIv0K6F2U=.6fa29fb4-260d-4264-bd33-940ac8caf412@github.com>
Message-ID: <O5m2h8xOaLbqqECDVY9LoozbxnGHIycsRKbf1CY7AcM=.63a3be38-8756-4cc9-bb43-10c24c8125f3@github.com>

On Tue, 17 Nov 2020 20:15:34 GMT, Erik Joelsson <erikj 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 .
>
> It looks like you have deleted the doc directory. That can't be right?

@erikj79  That's possible I had an intermediate doc folder before the master doc was added. I though I was careful to resolve conflict by selecting master but it might be that I picked the wrong one. Will try and correct in next round,.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From jlaskey at openjdk.java.net  Tue Nov 17 21:03:18 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 17 Nov 2020 21:03:18 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <g4TmJKxtQWJf6USseQWrRNfuqOzqSTmZfmaIv0K6F2U=.6fa29fb4-260d-4264-bd33-940ac8caf412@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
 <g4TmJKxtQWJf6USseQWrRNfuqOzqSTmZfmaIv0K6F2U=.6fa29fb4-260d-4264-bd33-940ac8caf412@github.com>
Message-ID: <3vhrOZBGrwfQVyPxA_qi7l_gimy0RqkPIRDHR7rm3SE=.79a40273-6ed4-474f-9b1e-30bd6845d303@github.com>

On Tue, 17 Nov 2020 20:15:34 GMT, Erik Joelsson <erikj 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 .
>
> It looks like you have deleted the doc directory. That can't be right?

@erikj79 my local branch seems to have the right sources for doc

@erikj79 https://github.com/JimLaskey/jdk/tree/8248862

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From jlaskey at openjdk.java.net  Tue Nov 17 21:03:18 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 17 Nov 2020 21:03:18 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v2]
In-Reply-To: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
Message-ID: <_AerudoiREbI3Qj9VRi5zoiogsiCWPD17HhkIvTTCaw=.be7f1fa8-3c1c-49ca-90ba-96b010033087@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 .

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  8248862: Implement Enhanced Pseudo-Random Number Generators
  
  Updated RandomGeneratorFactory javadoc.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1273/files
  - new: https://git.openjdk.java.net/jdk/pull/1273/files/7469ca58..b24024bb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1273&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1273&range=00-01

  Stats: 39 lines in 6 files changed: 16 ins; 0 del; 23 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1273.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1273/head:pull/1273

PR: https://git.openjdk.java.net/jdk/pull/1273

From kcr at openjdk.java.net  Tue Nov 17 21:14:06 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 17 Nov 2020 21:14:06 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <3vhrOZBGrwfQVyPxA_qi7l_gimy0RqkPIRDHR7rm3SE=.79a40273-6ed4-474f-9b1e-30bd6845d303@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
 <g4TmJKxtQWJf6USseQWrRNfuqOzqSTmZfmaIv0K6F2U=.6fa29fb4-260d-4264-bd33-940ac8caf412@github.com>
 <3vhrOZBGrwfQVyPxA_qi7l_gimy0RqkPIRDHR7rm3SE=.79a40273-6ed4-474f-9b1e-30bd6845d303@github.com>
Message-ID: <Sldr5bTr6G7Uvm4l0aausdNQvhsgWhI2KPwW8gLlsmM=.5476476b-2398-4438-bfe3-cc4f86e523c6@github.com>

On Tue, 17 Nov 2020 20:56:52 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> my local branch seems to have the right sources for doc

Maybe, but your branch on GitHub does not.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From ihse at openjdk.java.net  Tue Nov 17 21:38:04 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 17 Nov 2020 21:38:04 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <Sldr5bTr6G7Uvm4l0aausdNQvhsgWhI2KPwW8gLlsmM=.5476476b-2398-4438-bfe3-cc4f86e523c6@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
 <g4TmJKxtQWJf6USseQWrRNfuqOzqSTmZfmaIv0K6F2U=.6fa29fb4-260d-4264-bd33-940ac8caf412@github.com>
 <3vhrOZBGrwfQVyPxA_qi7l_gimy0RqkPIRDHR7rm3SE=.79a40273-6ed4-474f-9b1e-30bd6845d303@github.com>
 <Sldr5bTr6G7Uvm4l0aausdNQvhsgWhI2KPwW8gLlsmM=.5476476b-2398-4438-bfe3-cc4f86e523c6@github.com>
Message-ID: <zp6G8KZ78W361H2R6QjlBJSHPiARjt6vFj2_fP9t0MI=.04c10762-a103-4815-b20f-beca44698cf2@github.com>

On Tue, 17 Nov 2020 21:10:48 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @erikj79 my local branch seems to have the right sources for doc
>
>> my local branch seems to have the right sources for doc
> 
> Maybe, but your branch on GitHub does not.

This PR looks seriously messed up:

JimLaskey added 30 commits on Oct 9
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators
515a5a4
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
7c25f2d
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
642022d
@JimLaskey
Merge branch 'master' into 8248862
b537e0f
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
ca90d01
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
ec2941a
@JimLaskey
Merge branch 'master' into 8248862
dbe142c
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
cca6f0f
@JimLaskey
Merge branch 'master' into 8248862
93ee16f
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
84d4704
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
b50f2ee
@JimLaskey
Merge branch 'master' into 8248862
b1d6abe
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
8afe7a2
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
2f99696
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
7c58819
@JimLaskey
Merge branch 'master' into 8248862
655ad08
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
d5860b9
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
3ac78f8
@JimLaskey
Merge branch 'master' into 8248862
e3b6e64
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
8ec7f87
@JimLaskey
Merge branch 'master' into 8248862
ed959f8
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
72195e8
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
84730c3
@JimLaskey
Merge branch 'master' into 8248862
05f0477
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
7dd81ac
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
38f534b
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
f428b61
@JimLaskey
Merge branch 'master' into 8248862
5e33872
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
0bc8e3d
@JimLaskey
Merge branch 'master' into 8248862
679f1b5
JimLaskey added 7 commits 4 days ago
@JimLaskey
8248862; Implement Enhanced Pseudo-Random Number Generators  ?
17972a9
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
4f0338f
@JimLaskey
Merge branch 'master' into 8248862
7c6b9fa
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
c67c729
@JimLaskey
Merge branch 'master' into 8248862
108ea50
@JimLaskey
Merge branch 'master' into 8248862
1b31205
@JimLaskey
8248862: Implement Enhanced Pseudo-Random Number Generators  ?
7469ca5

It might be better if you close this, rebase your actual change on top of a current master, and open a new PR instead.

The only reason this was flagged with the `build` label was due to the incorrect deletion of doc, so if you intend to go on with this PR, please remove the label after you've fixed the doc issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From ihse at openjdk.java.net  Tue Nov 17 21:38:04 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Tue, 17 Nov 2020 21:38:04 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <zp6G8KZ78W361H2R6QjlBJSHPiARjt6vFj2_fP9t0MI=.04c10762-a103-4815-b20f-beca44698cf2@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
 <g4TmJKxtQWJf6USseQWrRNfuqOzqSTmZfmaIv0K6F2U=.6fa29fb4-260d-4264-bd33-940ac8caf412@github.com>
 <3vhrOZBGrwfQVyPxA_qi7l_gimy0RqkPIRDHR7rm3SE=.79a40273-6ed4-474f-9b1e-30bd6845d303@github.com>
 <Sldr5bTr6G7Uvm4l0aausdNQvhsgWhI2KPwW8gLlsmM=.5476476b-2398-4438-bfe3-cc4f86e523c6@github.com>
 <zp6G8KZ78W361H2R6QjlBJSHPiARjt6vFj2_fP9t0MI=.04c10762-a103-4815-b20f-beca44698cf2@github.com>
Message-ID: <R77Skqkjjbhk8lyKrZU1wrI-h0WMPjdhkvvSkzy3gCo=.8a0a7385-f67c-4347-84b6-7eb636d07b83@github.com>

On Tue, 17 Nov 2020 21:33:13 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> my local branch seems to have the right sources for doc
>> 
>> Maybe, but your branch on GitHub does not.
>
> This PR looks seriously messed up:
> 
> JimLaskey added 30 commits on Oct 9
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators
> 515a5a4
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 7c25f2d
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 642022d
> @JimLaskey
> Merge branch 'master' into 8248862
> b537e0f
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> ca90d01
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> ec2941a
> @JimLaskey
> Merge branch 'master' into 8248862
> dbe142c
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> cca6f0f
> @JimLaskey
> Merge branch 'master' into 8248862
> 93ee16f
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 84d4704
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> b50f2ee
> @JimLaskey
> Merge branch 'master' into 8248862
> b1d6abe
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 8afe7a2
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 2f99696
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 7c58819
> @JimLaskey
> Merge branch 'master' into 8248862
> 655ad08
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> d5860b9
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 3ac78f8
> @JimLaskey
> Merge branch 'master' into 8248862
> e3b6e64
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 8ec7f87
> @JimLaskey
> Merge branch 'master' into 8248862
> ed959f8
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 72195e8
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 84730c3
> @JimLaskey
> Merge branch 'master' into 8248862
> 05f0477
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 7dd81ac
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 38f534b
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> f428b61
> @JimLaskey
> Merge branch 'master' into 8248862
> 5e33872
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 0bc8e3d
> @JimLaskey
> Merge branch 'master' into 8248862
> 679f1b5
> JimLaskey added 7 commits 4 days ago
> @JimLaskey
> 8248862; Implement Enhanced Pseudo-Random Number Generators  ?
> 17972a9
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 4f0338f
> @JimLaskey
> Merge branch 'master' into 8248862
> 7c6b9fa
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> c67c729
> @JimLaskey
> Merge branch 'master' into 8248862
> 108ea50
> @JimLaskey
> Merge branch 'master' into 8248862
> 1b31205
> @JimLaskey
> 8248862: Implement Enhanced Pseudo-Random Number Generators  ?
> 7469ca5
> 
> It might be better if you close this, rebase your actual change on top of a current master, and open a new PR instead.
> 
> The only reason this was flagged with the `build` label was due to the incorrect deletion of doc, so if you intend to go on with this PR, please remove the label after you've fixed the doc issue.

Ah, sorry, I see now that I expanded the commit comments that it was not just the same commit applied over and over again, as I assumed, but iterative steps from your branch while developing, that just had the same first line... sorry for the confusion about that.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From rriggs at openjdk.java.net  Tue Nov 17 21:44:08 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 17 Nov 2020 21:44:08 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v9]
In-Reply-To: <fwG1dzKEe-kw5XW3pmt_O3sniR5cu5zU8cDmvWXYYZw=.b7213dfc-ff31-4e6f-97c8-9ec0ebd3a58e@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <fwG1dzKEe-kw5XW3pmt_O3sniR5cu5zU8cDmvWXYYZw=.b7213dfc-ff31-4e6f-97c8-9ec0ebd3a58e@github.com>
Message-ID: <JHaBMuCrcdx78acvU9pxPDmrKVEkkj9KcwxhyyzHY3M=.78b7bc31-429b-46fd-9831-6b24e94037e7@github.com>

On Tue, 17 Nov 2020 19:58:29 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
>> 
>> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
>> 
>> A CSR will be required for this PR.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adding test coverage. Tweaking wording in docs.

test/jdk/java/util/IllegalFormatException/ArgumentIndexException.java line 52:

> 50:             }
> 51:         }
> 52:         throw new RuntimeException("Expected IllegalFormatException for zero argument index.");

The wording of errors around exceptions can be misinterpreted. Did an expected exception occur or not?
If all you saw was the exception without the line of code, would it be unambiguous?

src/java.base/share/classes/java/util/Formatter.java line 2802:

> 2800:                     // skip the trailing '$'
> 2801:                     index = Integer.parseInt(s, start, end - 1, 10);
> 2802:                     if(index <= 0) {

Add a space after 'if' please.

test/jdk/java/util/IllegalFormatException/ArgumentIndexException.java line 1:

> 1: /*

Typically, using the TestNG framework is preferable for new tests.
In addition to a convenient set of Asserts that check and print expected vs actual and message
it includes patterns for testing for expected exceptions.

test/jdk/java/util/IllegalFormatException/ArgumentIndexException.java line 98:

> 96:     }
> 97: 
> 98: }

Add a newline at end-of-file.

src/java.base/share/classes/java/util/IllegalFormatArgumentIndexException.java line 64:

> 62:     public String getMessage() {
> 63:         return String.format("Illegal format argument index = %d", getIndex());
> 64:     }

The exception with a very large negative number isn't going to easy to recognize.
Can the exception message say (for the Integer.MIN_VALUE) that the index is not valid index.
Its probably too much to ask have an indication where in the format string the offending index occurs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/516

From jlaskey at openjdk.java.net  Tue Nov 17 22:02:11 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 17 Nov 2020 22:02:11 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <Sldr5bTr6G7Uvm4l0aausdNQvhsgWhI2KPwW8gLlsmM=.5476476b-2398-4438-bfe3-cc4f86e523c6@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
 <g4TmJKxtQWJf6USseQWrRNfuqOzqSTmZfmaIv0K6F2U=.6fa29fb4-260d-4264-bd33-940ac8caf412@github.com>
 <3vhrOZBGrwfQVyPxA_qi7l_gimy0RqkPIRDHR7rm3SE=.79a40273-6ed4-474f-9b1e-30bd6845d303@github.com>
 <Sldr5bTr6G7Uvm4l0aausdNQvhsgWhI2KPwW8gLlsmM=.5476476b-2398-4438-bfe3-cc4f86e523c6@github.com>
Message-ID: <kxa1VpjBuMt1-GZjPORvoG_Nkqw90oU3UN1m0WB-37I=.abf72823-f83b-43ca-bd0d-360e73bc6010@github.com>

On Tue, 17 Nov 2020 21:10:48 GMT, Kevin Rushforth <kcr at openjdk.org> wrote:

>> @erikj79 my local branch seems to have the right sources for doc
>
>> my local branch seems to have the right sources for doc
> 
> Maybe, but your branch on GitHub does not.

@kevinrushforth What is the recommended approach to remove the doc edit/commit?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From forax at univ-mlv.fr  Tue Nov 17 22:13:40 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 17 Nov 2020 23:13:40 +0100 (CET)
Subject: 'Find' method for Iterable
In-Reply-To: <75e61d30-a675-bcdc-6475-533bceecdfe7@oracle.com>
References: <CA+0ynh9wguU9b4ZQnOz=ySeSa9sovYzeeQ=rAa8fPJCpo=gXag@mail.gmail.com>
 <219103610.2532126.1600289966746.JavaMail.zimbra@u-pem.fr>
 <CA+0ynh9eUen9n_knA4bfZCPTu-ZmXbOMTdtuDVfrLi1iw+RekQ@mail.gmail.com>
 <54f82257-b5c5-287f-5c99-8b922d597eb3@fiolino.de>
 <75e61d30-a675-bcdc-6475-533bceecdfe7@oracle.com>
Message-ID: <1433061660.1868949.1605651220925.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Brian Goetz" <brian.goetz at oracle.com>
> ?: "Michael Kuhlmann" <jdk at fiolino.de>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 17 Novembre 2020 20:44:17
> Objet: Re: 'Find' method for Iterable

> On 9/21/2020 4:08 AM, Michael Kuhlmann wrote:
>> But after thinking about it, I'm now convinced that it would be a bad
>> idea. Because it extends the scope of this small, tiny Iterable
>> interface to something bigger which it shouldn't be.
> 
> This response captures the essence of the problem.? You may think you
> are asking for "just one more method on Iterable", but really, what you
> are asking for is to turn Iterable into something it is not.? Iterable
> exists not to be "smallest collection", but as the interface to the
> foreach-loop.? Yes, we could have chosen a different design center for
> Iterable (Eclipse Collections did, see RichIterable), but we didn't.
> Adding this method merely sends the signal that we want to extend
> Iterable to be more than it is, which opens the floodgate to requests
> (and eventually demands) for more methods.
> 
>> I can ask about Iterable#forEach - is it there only because it was there to
>> begin with? Would it have been a bad idea to add one if we had streams
>> already?
> 
> While you can make an argument that forEach is excessive, the fact that
> you make this argument illustrates the essential problem with this
> proposal.? Your argument wrt forEach is "If that makes sense, then so
> does find."? If you pull on that string, then this method forms the
> basis of tomorrow's assumption: "You have forEach and find, it is
> unreasonable to not add <my pet method>".

There is a good reason to have forEach,
Iterable in the interface of things that can be iterated, and in Java, there are two ways to do an iteration,
the internal iteration, where you ask the class to do the iteration for you using forEach and
the external iterator, where you ask for an Iterator and use it to iterate outside of the class.

In term of API design, it is push vs pull, using forEach, the element are is pushed to the Consumer while using an Iterator.next() allow you to pull the element.

Usually, forEach() is faster but it takes a Consumer, so you are limited by the limitation of the lambda (you can not mutate the local variables of the enclosing scope).
Using an Iterator is also more powerful because you can compose them.

> 
> So, Iterable should stay simple.? (The other arguments against it on
> this thread, are also valid, but this is the most important one.)

Yep.

R?mi

From jlaskey at openjdk.java.net  Tue Nov 17 22:15:03 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 17 Nov 2020 22:15:03 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <kxa1VpjBuMt1-GZjPORvoG_Nkqw90oU3UN1m0WB-37I=.abf72823-f83b-43ca-bd0d-360e73bc6010@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
 <g4TmJKxtQWJf6USseQWrRNfuqOzqSTmZfmaIv0K6F2U=.6fa29fb4-260d-4264-bd33-940ac8caf412@github.com>
 <3vhrOZBGrwfQVyPxA_qi7l_gimy0RqkPIRDHR7rm3SE=.79a40273-6ed4-474f-9b1e-30bd6845d303@github.com>
 <Sldr5bTr6G7Uvm4l0aausdNQvhsgWhI2KPwW8gLlsmM=.5476476b-2398-4438-bfe3-cc4f86e523c6@github.com>
 <kxa1VpjBuMt1-GZjPORvoG_Nkqw90oU3UN1m0WB-37I=.abf72823-f83b-43ca-bd0d-360e73bc6010@github.com>
Message-ID: <HsvNwRXZubVY_Tr9Nl64Qg7GNv7A1FKOGJviBLnyci0=.17d31b0d-b2b5-4d63-ac58-f3d63d072762@github.com>

On Tue, 17 Nov 2020 21:59:04 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>>> my local branch seems to have the right sources for doc
>> 
>> Maybe, but your branch on GitHub does not.
>
> @kevinrushforth What is the recommended approach to remove the doc edit/commit?

javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From jlaskey at openjdk.java.net  Tue Nov 17 22:21:18 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 17 Nov 2020 22:21:18 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
Message-ID: <6h9eeR6HFk03eD3DCtXjJo9Wg81zWH1090paXb-Yp1k=.da9e5ecd-377a-488f-a2f6-b43876af6f60@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 .

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:

 - Merge branch 'master' into 8248862
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Update package-info.java
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Updated RandomGeneratorFactory javadoc.
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Updated documentation for RandomGeneratorFactory.
 - Merge branch 'master' into 8248862
 - Merge branch 'master' into 8248862
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Move RandomGeneratorProperty
 - Merge branch 'master' into 8248862
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Clear up javadoc
 - 8248862; Implement Enhanced Pseudo-Random Number Generators
   
   remove RandomGeneratorProperty from API
 - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1273/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1273&range=02
  Stats: 14891 lines in 31 files changed: 11110 ins; 3704 del; 77 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1273.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1273/head:pull/1273

PR: https://git.openjdk.java.net/jdk/pull/1273

From kcr at openjdk.java.net  Tue Nov 17 22:54:06 2020
From: kcr at openjdk.java.net (Kevin Rushforth)
Date: Tue, 17 Nov 2020 22:54:06 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <HsvNwRXZubVY_Tr9Nl64Qg7GNv7A1FKOGJviBLnyci0=.17d31b0d-b2b5-4d63-ac58-f3d63d072762@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
 <g4TmJKxtQWJf6USseQWrRNfuqOzqSTmZfmaIv0K6F2U=.6fa29fb4-260d-4264-bd33-940ac8caf412@github.com>
 <3vhrOZBGrwfQVyPxA_qi7l_gimy0RqkPIRDHR7rm3SE=.79a40273-6ed4-474f-9b1e-30bd6845d303@github.com>
 <Sldr5bTr6G7Uvm4l0aausdNQvhsgWhI2KPwW8gLlsmM=.5476476b-2398-4438-bfe3-cc4f86e523c6@github.com>
 <kxa1VpjBuMt1-GZjPORvoG_Nkqw90oU3UN1m0WB-37I=.abf72823-f83b-43ca-bd0d-360e73bc6010@github.com>
 <HsvNwRXZubVY_Tr9Nl64Qg7GNv7A1FKOGJviBLnyci0=.17d31b0d-b2b5-4d63-ac58-f3d63d072762@github.com>
Message-ID: <EgWQhcFNXKJLwL0YE3nXJJm4TX3L_QBZz7HwJbW3sS0=.acdb6d1b-93a7-40c2-9705-595d14ff79d3@github.com>

On Tue, 17 Nov 2020 22:12:19 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> @kevinrushforth What is the recommended approach to remove the doc edit/commit?
>
> javadoc can be found at http://cr.openjdk.java.net/~jlaskey/prng/doc/api/java.base/java/util/random/package-summary.html

Presuming your master branch is in sync with the upstream jdk repo, something like the following:

git checkout master -- doc
git add doc
git commit -m "restore doc files"

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From forax at univ-mlv.fr  Tue Nov 17 23:18:16 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 18 Nov 2020 00:18:16 +0100 (CET)
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number
 Generators [v3]
In-Reply-To: <6h9eeR6HFk03eD3DCtXjJo9Wg81zWH1090paXb-Yp1k=.da9e5ecd-377a-488f-a2f6-b43876af6f60@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
 <6h9eeR6HFk03eD3DCtXjJo9Wg81zWH1090paXb-Yp1k=.da9e5ecd-377a-488f-a2f6-b43876af6f60@github.com>
Message-ID: <676865722.1878668.1605655096153.JavaMail.zimbra@u-pem.fr>

An honest question,
why do we need so many interfaces for the different categories of RandomGenerator ?

My fear is that we are encoding the state of our knowledge of the different kinds of random generators now so it will not be pretty in the future when new categories of random generator are discovered/invented.
If we can take example of the past to predict the future, 20 years ago, what should have been the hierarchy at that time.
Is it not reasonable to think that we will need new kinds of random generator in the future ?

I wonder if it's not better to have one interface and several optional methods like we have with the collections, it means that we are loosing the possibilities to precisely type a method that only works with a precise type of generator but it will be more future proof.

R?mi

----- Mail original -----
> De: "Jim Laskey" <jlaskey at openjdk.java.net>
> ?: "build-dev" <build-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>,
> security-dev at openjdk.java.net
> Envoy?: Mardi 17 Novembre 2020 23:21:18
> Objet: Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

>> 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 .
> 
> Jim Laskey has updated the pull request with a new target base due to a merge or
> a rebase. The pull request now contains 40 commits:
> 
> - Merge branch 'master' into 8248862
> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>   
>   Update package-info.java
> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>   
>   Updated RandomGeneratorFactory javadoc.
> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>   
>   Updated documentation for RandomGeneratorFactory.
> - Merge branch 'master' into 8248862
> - Merge branch 'master' into 8248862
> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>   
>   Move RandomGeneratorProperty
> - Merge branch 'master' into 8248862
> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>   
>   Clear up javadoc
> - 8248862; Implement Enhanced Pseudo-Random Number Generators
>   
>   remove RandomGeneratorProperty from API
> - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68
> 
> -------------
> 
> Changes: https://git.openjdk.java.net/jdk/pull/1273/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1273&range=02
>  Stats: 14891 lines in 31 files changed: 11110 ins; 3704 del; 77 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/1273.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1273/head:pull/1273
> 
> PR: https://git.openjdk.java.net/jdk/pull/1273

From naoto at openjdk.java.net  Tue Nov 17 23:28:21 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Tue, 17 Nov 2020 23:28:21 GMT
Subject: RFR: 8251317: Support for CLDR version 38
Message-ID: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>

Hi,

Please review the changes for upgrading the CLDR data to version 38. The vast majority of the changes are simply the changes in CLDR upstream, and others are mainly test changes due to the locale data change.

-------------

Commit messages:
 - Updated the version in `cldr.md` files
 - Merge branch 'master' into cldr
 - 8251317: Support for CLDR version 38

Changes: https://git.openjdk.java.net/jdk/pull/1279/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1279&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8251317
  Stats: 57338 lines in 209 files changed: 41958 ins; 4932 del; 10448 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1279.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1279/head:pull/1279

PR: https://git.openjdk.java.net/jdk/pull/1279

From smarks at openjdk.java.net  Tue Nov 17 23:34:23 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 17 Nov 2020 23:34:23 GMT
Subject: RFR: 8256152: tests fail because of ambiguous method resolution
 [v2]
In-Reply-To: <2Sc4ZnmZ510_ykvmkkJbICYWTtzt1VH32x_LT6Miaxs=.5f9dd093-8112-4ab2-b323-e0fae0d63bfe@github.com>
References: <2Sc4ZnmZ510_ykvmkkJbICYWTtzt1VH32x_LT6Miaxs=.5f9dd093-8112-4ab2-b323-e0fae0d63bfe@github.com>
Message-ID: <4bI308aqoWpHVIrtzu07AQPQLUanzXNCw1FwTCUgcFU=.e014743a-8510-4a60-887e-57a2aa8aea53@github.com>

> Added a cast in the right place, thanks to @jonathan-gibbons.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  cast to double instead of Object

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1274/files
  - new: https://git.openjdk.java.net/jdk/pull/1274/files/4a401ed2..6875beb1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1274&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1274&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1274.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1274/head:pull/1274

PR: https://git.openjdk.java.net/jdk/pull/1274

From mchung at openjdk.java.net  Tue Nov 17 23:44:16 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 17 Nov 2020 23:44:16 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v3]
In-Reply-To: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
Message-ID: <r1L4Kn4pSNVwUmazTAoHaxoNrUJhq8jZqCLi5rG2n6c=.73fa9813-881d-4378-a156-c61c0582fb8f@github.com>

> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects
> be shared between a hidden class and other classes.  A hidden class can load
> these live objects as dynamically-computed constants via this API.
> 
> Specdiff
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
> 
> With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass`
> will be deprecated for removal.  Existing libraries should replace their
> calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass`
> or `Lookup::defineHiddenClassWithClassData`.
> 
> This patch also updates the implementation of lambda meta factory and
> `MemoryAccessVarHandleGenerator` to use class data.   No performance difference
> observed in the jdk.incubator.foreign microbenchmarks.   A side note: 
> `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of 
> JDK-8254162 but it helps validating the class data support.
> 
> Background
> ----------
> 
> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
> "Constant-pool patching" in the "Risks and Assumption" section.
> 
> A VM-anonymous class can be defined with its constant-pool entries already
> resolved to concrete values. This allows critical constants to be shared
> between a VM-anonymous class and the language runtime that defines it, and
> between multiple VM-anonymous classes. For example, a language runtime will
> often have `MethodHandle` objects in its address space that would be useful
> to newly-defined VM-anonymous classes. Instead of the runtime serializing
> the objects to constant-pool entries in VM-anonymous classes and then
> generating bytecode in those classes to laboriously `ldc` the entries,
> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
> to its live objects. The relevant constant-pool entries in the newly-defined
> VM-anonymous class are pre-linked to those objects, improving performance
> and reducing footprint. In addition, this allows VM-anonymous classes to
> refer to each other: Constant-pool entries in a class file are based on names.
> They thus cannot refer to nameless VM-anonymous classes. A language runtime can,
> however, easily track the live Class objects for its VM-anonymous classes and
> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's
> constant pool entries to other VM-anonymous classes.
> 
> This extends the hidden classes to allow live objects to be injected
> in a hidden class and loaded them via condy.
> 
> Details
> -------
> 
> A new `Lookup::defineHiddenClassWithClassData` API takes additional
> `classData` argument compared to `Lookup::defineHiddenClass`.
> Class data can be method handles, lookup objects, arbitrary user objects
> or collections of all of the above.
> 
> This method behaves as if calling `Lookup::defineHiddenClass` to define
> a hidden class with a private static unnamed field that is initialized
> with `classData` at the first instruction of the class initializer.
> 
> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
> is a bootstrap method to load the class data of the given lookup's lookup class.
> The hidden class will be initialized when `classData` method is called if
> the hidden class has not been initialized.
> 
> For a class data containing more than one single element, libraries can
> create their convenience method to load a single live object via condy.
> We can reconsider if such a convenience method is needed in the future.
> 
> Frameworks sometimes want to dynamically create a hidden class (HC) and add it
> it the lookup class nest and have HC to carry secrets hidden from that nest.
> In this case, frameworks should not to use private static finals (in the HCs
> they spin) to hold secrets because a nestmate of HC may obtain access to
> such a private static final and observe the framework's secret.  It should use
> condy.  In addition, we need to differentiate if a lookup object is created from
> the original lookup class or created from teleporting e.g. `Lookup::in`
> and `MethodHandles::privateLookupIn`.
> 
> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
> object is created by `MethodHandles::lookup` or by bootstrap method invocation.
> The operations only apply to a Lookup object with original access are:
>    - create method handles for caller-sensitve methods
>    - obtain class data associated with the lookup class
> 
> No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which
> ignores the ORIGINAL bit.
> 
> 
> Compatibility Risks
> -------------------
> 
> `Lookup::lookupModes` includes a new `ORIGINAL` bit.  Most lookup operations
> ignore this original bit except creating method handles for caller-sensitive methods
> that expects the lookup from the original lookup class.  Existing code  compares
> the return value of `lookupModes` to be a fixed value may be impacted.   However
> existing client has no need to expect a fixed value of lookup modes.
> The incompatibility risk of this spec change is low.

Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into class-data
 - add classDataAt and require name be ConstantDescs.DEFAULT_NAME (which indicates no name is needed)
 - per Jorn's feedback
 - Merge
 - fix incorrect merge
 - more clean up
 - merge
 - Keep classDataAt package-private
 - Merge branch 'master' of https://github.com/openjdk/jdk into class-data
 - MethodHandles::hasFullPrivilegeAccess and Lookup::toString ignores ORIGINAL bit
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/f7517386...153740eb

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1171/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1171&range=02
  Stats: 952 lines in 14 files changed: 821 ins; 29 del; 102 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1171.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1171/head:pull/1171

PR: https://git.openjdk.java.net/jdk/pull/1171

From smarks at openjdk.java.net  Tue Nov 17 23:57:13 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 17 Nov 2020 23:57:13 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v9]
In-Reply-To: <JHaBMuCrcdx78acvU9pxPDmrKVEkkj9KcwxhyyzHY3M=.78b7bc31-429b-46fd-9831-6b24e94037e7@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <fwG1dzKEe-kw5XW3pmt_O3sniR5cu5zU8cDmvWXYYZw=.b7213dfc-ff31-4e6f-97c8-9ec0ebd3a58e@github.com>
 <JHaBMuCrcdx78acvU9pxPDmrKVEkkj9KcwxhyyzHY3M=.78b7bc31-429b-46fd-9831-6b24e94037e7@github.com>
Message-ID: <e-MqQvukifDsDfskjs9XmOJ7k8TX2zpBv_Q4qZjxDq4=.9c44c76e-a050-4d3d-b303-6f06ef77b38e@github.com>

On Tue, 17 Nov 2020 21:21:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adding test coverage. Tweaking wording in docs.
>
> test/jdk/java/util/IllegalFormatException/ArgumentIndexException.java line 1:
> 
>> 1: /*
> 
> Typically, using the TestNG framework is preferable for new tests.
> In addition to a convenient set of Asserts that check and print expected vs actual and message
> it includes patterns for testing for expected exceptions.

Yes, these tests are amenable to TestNG's `assertThrows` method. That might be all you need; we generally aren't too concerned about the exact content and formatting of the exception's message. However, if you want to make additional assertions over the thrown exception, it can be obtained using `expectThrows` instead of `assertThrows`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/516

From mchung at openjdk.java.net  Wed Nov 18 00:50:22 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 18 Nov 2020 00:50:22 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v4]
In-Reply-To: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
Message-ID: <tKPyoN5O290X_W3n2DF1jvunO0YBoyNnoT5jXjmsNc0=.ecc67352-e2ef-4408-9ac1-e5e90a345424@github.com>

> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects
> be shared between a hidden class and other classes.  A hidden class can load
> these live objects as dynamically-computed constants via this API.
> 
> Specdiff
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
> 
> With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass`
> will be deprecated for removal.  Existing libraries should replace their
> calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass`
> or `Lookup::defineHiddenClassWithClassData`.
> 
> This patch also updates the implementation of lambda meta factory and
> `MemoryAccessVarHandleGenerator` to use class data.   No performance difference
> observed in the jdk.incubator.foreign microbenchmarks.   A side note: 
> `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of 
> JDK-8254162 but it helps validating the class data support.
> 
> Background
> ----------
> 
> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
> "Constant-pool patching" in the "Risks and Assumption" section.
> 
> A VM-anonymous class can be defined with its constant-pool entries already
> resolved to concrete values. This allows critical constants to be shared
> between a VM-anonymous class and the language runtime that defines it, and
> between multiple VM-anonymous classes. For example, a language runtime will
> often have `MethodHandle` objects in its address space that would be useful
> to newly-defined VM-anonymous classes. Instead of the runtime serializing
> the objects to constant-pool entries in VM-anonymous classes and then
> generating bytecode in those classes to laboriously `ldc` the entries,
> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
> to its live objects. The relevant constant-pool entries in the newly-defined
> VM-anonymous class are pre-linked to those objects, improving performance
> and reducing footprint. In addition, this allows VM-anonymous classes to
> refer to each other: Constant-pool entries in a class file are based on names.
> They thus cannot refer to nameless VM-anonymous classes. A language runtime can,
> however, easily track the live Class objects for its VM-anonymous classes and
> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's
> constant pool entries to other VM-anonymous classes.
> 
> This extends the hidden classes to allow live objects to be injected
> in a hidden class and loaded them via condy.
> 
> Details
> -------
> 
> A new `Lookup::defineHiddenClassWithClassData` API takes additional
> `classData` argument compared to `Lookup::defineHiddenClass`.
> Class data can be method handles, lookup objects, arbitrary user objects
> or collections of all of the above.
> 
> This method behaves as if calling `Lookup::defineHiddenClass` to define
> a hidden class with a private static unnamed field that is initialized
> with `classData` at the first instruction of the class initializer.
> 
> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)`
> is a bootstrap method to load the class data of the given lookup's lookup class.
> The hidden class will be initialized when `classData` method is called if
> the hidden class has not been initialized.
> 
> For a class data containing more than one single element, libraries can
> create their convenience method to load a single live object via condy.
> We can reconsider if such a convenience method is needed in the future.
> 
> Frameworks sometimes want to dynamically create a hidden class (HC) and add it
> it the lookup class nest and have HC to carry secrets hidden from that nest.
> In this case, frameworks should not to use private static finals (in the HCs
> they spin) to hold secrets because a nestmate of HC may obtain access to
> such a private static final and observe the framework's secret.  It should use
> condy.  In addition, we need to differentiate if a lookup object is created from
> the original lookup class or created from teleporting e.g. `Lookup::in`
> and `MethodHandles::privateLookupIn`.
> 
> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
> object is created by `MethodHandles::lookup` or by bootstrap method invocation.
> The operations only apply to a Lookup object with original access are:
>    - create method handles for caller-sensitve methods
>    - obtain class data associated with the lookup class
> 
> No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which
> ignores the ORIGINAL bit.
> 
> 
> Compatibility Risks
> -------------------
> 
> `Lookup::lookupModes` includes a new `ORIGINAL` bit.  Most lookup operations
> ignore this original bit except creating method handles for caller-sensitive methods
> that expects the lookup from the original lookup class.  Existing code  compares
> the return value of `lookupModes` to be a fixed value may be impacted.   However
> existing client has no need to expect a fixed value of lookup modes.
> The incompatibility risk of this spec change is low.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Fix the name passed to condy calling classData

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1171/files
  - new: https://git.openjdk.java.net/jdk/pull/1171/files/153740eb..f1f36738

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1171&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1171&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1171.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1171/head:pull/1171

PR: https://git.openjdk.java.net/jdk/pull/1171

From psandoz at openjdk.java.net  Wed Nov 18 00:54:18 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 18 Nov 2020 00:54:18 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <6h9eeR6HFk03eD3DCtXjJo9Wg81zWH1090paXb-Yp1k=.da9e5ecd-377a-488f-a2f6-b43876af6f60@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
 <6h9eeR6HFk03eD3DCtXjJo9Wg81zWH1090paXb-Yp1k=.da9e5ecd-377a-488f-a2f6-b43876af6f60@github.com>
Message-ID: <2I2HK8tDFSLtPqs0JFLKLgh3QmMTkM1HKuvKQNmsfIg=.a383a449-18e3-413a-a6ba-91dc80fde86a@github.com>

On Tue, 17 Nov 2020 22:21:18 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 .
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:
> 
>  - Merge branch 'master' into 8248862
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>    
>    Update package-info.java
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>    
>    Updated RandomGeneratorFactory javadoc.
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>    
>    Updated documentation for RandomGeneratorFactory.
>  - Merge branch 'master' into 8248862
>  - Merge branch 'master' into 8248862
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>    
>    Move RandomGeneratorProperty
>  - Merge branch 'master' into 8248862
>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>    
>    Clear up javadoc
>  - 8248862; Implement Enhanced Pseudo-Random Number Generators
>    
>    remove RandomGeneratorProperty from API
>  - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68

I am unsure if the intent is also to support external libraries providing `RandomGenerator` implementations. Currently there is an implicit contract for properties (reflectively invoking a method returning a map with a set of entries with known keys). Since the service provider implementation is the `RandomGenerator` itself, rather than `RandomGeneratorFactory` it is harder expose the meta-data with a clearer contract.

src/java.base/share/classes/java/util/Random.java line 592:

> 590: 
> 591:     @Override
> 592:     public Spliterator.OfInt makeIntsSpliterator(long index, long fence, int origin, int bound) {

Unsure if this and the other two methods are intended to be public or not, since they are at the end of the class and override methods of a module private class. In principle there is nothing wrong with such `Spliterator` factories, but wonder if they are really needed given the `Stream` returning methods. The arrangement of classes makes it awkward to hide these methods.

src/java.base/share/classes/java/util/SplittableRandom.java line 171:

> 169:      * RandomGenerator properties.
> 170:      */
> 171:     static Map<RandomGeneratorProperty, Object> getProperties() {

With records exiting preview in 16 this map of properties could i think be represented as a record instance, with better type safety, where `RandomSupport.RandomGeneratorProperty` enum values become typed fields declared on the record class. Something to consider after integration perhaps?

src/java.base/share/classes/java/util/SplittableRandom.java line 211:

> 209:      * http://zimbry.blogspot.com/2011/09/better-bit-mixing-improving-on.html
> 210:      */
> 211:     private static long mix64(long z) {

Usages be replaced with calls to `RandomSupport.mixStafford13`?

src/java.base/share/classes/module-info.java line 250:

> 248:     exports jdk.internal.util.xml.impl to
> 249:         jdk.jfr;
> 250:     exports jdk.internal.util.random;

Unqualified export, should this be `to jdk.random`?

src/jdk.random/share/classes/module-info.java line 50:

> 48:  */
> 49: module jdk.random {
> 50:     uses java.util.random.RandomGenerator;

Are these `uses` declarations needed? `ServiceLoader` is not used by this module, and `RandomSupport` is not a service interface.

src/jdk.random/share/classes/module-info.java line 53:

> 51:     uses RandomSupport;
> 52: 
> 53:     exports jdk.random to

Why is this needed?

src/java.base/share/classes/java/util/random/package-info.java line 50:

> 48:  * given its name.
> 49:  *
> 50:  * <p> The principal supporting class is {@link RandomGenertatorFactor}. This

s/RandomGenertatorFactor/RandomGenertatorFactory

src/java.base/share/classes/java/util/random/package-info.java line 140:

> 138:  *
> 139:  * <p> For applications with no special requirements,
> 140:  * "L64X128MixRandom" has a good balance among speed, space,

The documentation assumes that the `jdk.random` module is present in the JDK image. Perhaps we need to spit the specifics to `jdk.random`?

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1211:

> 1209:                         Udiff = -Udiff;
> 1210:                         U2 = U1;
> 1211:                         U1 -= Udiff;

Updated `U1` never used (recommend running the code through a checker e.g. use IntelliJ)

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 331:

> 329:         }
> 330:         // Finally, we need to make sure the last z words are not all zero.
> 331:         search: {

Nice! a rarely used feature :-)

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1157:

> 1155:         /*
> 1156:          * The tables themselves, as well as a number of associated parameters, are
> 1157:          * defined in class java.util.DoubleZigguratTables, which is automatically

`DoubleZigguratTables` is an inner class of `RandomSupport`

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 2895:

> 2893:      * distribution: 0.0330
> 2894:      */
> 2895:     static class DoubleZigguratTables {

make `final`

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 167:

> 165:      * Return the properties map for the specified provider.
> 166:      *
> 167:      * @param provider  provider to locate.

Method has no such parameter

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 173:

> 171:     @SuppressWarnings("unchecked")
> 172:     private Map<RandomGeneratorProperty, Object> getProperties() {
> 173:         if (properties == null) {

`properties` needs to be marked volatile, and it needs to be assigned at line 182 or line 184.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 148:

> 146:      */
> 147:     private static Map<String, Provider<? extends RandomGenerator>> getFactoryMap() {
> 148:         if (factoryMap == null) {

`factoryMap` needs to be marked volatile when using the double checked locking idiom.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 320:

> 318:                         }
> 319:                     }
> 320:                 }

Add an `assert` statement that `ctor`, `ctorLong` and `ctorBytes` are all non-null?

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 331:

> 329:      */
> 330:     private void ensureConstructors() {
> 331:         if (ctor == null) {

This check occurs outside of the synchronized block, field may need to be marked volatile. Unsure about the other dependent fields. Might need to store values from loop in `getConstructors` in locals and then assign in appropriate order, assigning the volatile field last.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From naoto at openjdk.java.net  Wed Nov 18 02:07:01 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 18 Nov 2020 02:07:01 GMT
Subject: RFR: 8251317: Support for CLDR version 38
In-Reply-To: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
References: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
Message-ID: <Vi38PG7PPjWFSSw0L0hI_KErgM19ncMx4tRMIGROEyc=.200b59de-f342-49f2-a8d3-c5d4e8ef696b@github.com>

On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes for upgrading the CLDR data to version 38. The vast majority of the changes are simply the changes in CLDR upstream, and others are mainly test changes due to the locale data change.

Looks like the generated webrev is empty, possibly due to this issue (https://bugs.openjdk.java.net/browse/SKARA-732). Here is the one manually generated:
https://cr.openjdk.java.net/~naoto/cldr/webrev.00/

-------------

PR: https://git.openjdk.java.net/jdk/pull/1279

From ngasson at openjdk.java.net  Wed Nov 18 02:11:07 2020
From: ngasson at openjdk.java.net (Nick Gasson)
Date: Wed, 18 Nov 2020 02:11:07 GMT
Subject: Integrated: 8256435: [TESTBUG] java/foreign/TestHandshake.java fails
 with direct buffer memory OOM
In-Reply-To: <n0zEzhAVNoLyOMxaquudae8RmzPFsLuX2g56GQY57Fw=.7fed7240-8e67-41c5-aa82-5049f2727066@github.com>
References: <n0zEzhAVNoLyOMxaquudae8RmzPFsLuX2g56GQY57Fw=.7fed7240-8e67-41c5-aa82-5049f2727066@github.com>
Message-ID: <ir3YTY33KwL_xpXonk1JnRCxhuqQZaTwrfXQ5q_GjdE=.9de81387-662c-481a-9d3b-200aa72c3d2b@github.com>

On Tue, 17 Nov 2020 09:07:03 GMT, Nick Gasson <ngasson at openjdk.org> wrote:

> I ran this test on a machine with 224 logical CPUs and it fails with:
> 
>   ITERATION 3
>   test TestHandshake.testHandshake("SegmentMismatchAccessor", TestHandshake$$Lambda$57/0x00000001000e7968 at 37c4b344): failure
>   java.lang.OutOfMemoryError: Cannot reserve 1000000 bytes of direct buffer memory (allocated: 536008192, limit: 536870912)
> 
> SegmentMismatchAccessor allocates a 1MB native segment for each CPU on
> each iteration. This can quickly reach the allocation limit if there is
> no intervening GC. Explicitly close the segment after each iteration to
> release the memory.

This pull request has now been integrated.

Changeset: 26a1ec1b
Author:    Nick Gasson <ngasson at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/26a1ec1b
Stats:     9 lines in 1 file changed: 8 ins; 0 del; 1 mod

8256435: [TESTBUG] java/foreign/TestHandshake.java fails with direct buffer memory OOM

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.java.net/jdk/pull/1254

From david.holmes at oracle.com  Wed Nov 18 05:31:11 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 18 Nov 2020 15:31:11 +1000
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
Message-ID: <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>

Hi Vincente,

On 16/11/2020 11:36 pm, Vicente Romero wrote:
> Please review the code for the second iteration of sealed classes. In this iteration we are:
> 
> - Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies.
> - Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface

The major change here seems to be that getPermittedSubclasses() now 
returns actual Class objects instead of ClassDesc. My recollection from 
earlier discussions here was that the use of ClassDesc was very 
deliberate as the permitted subclasses may not actually exist and there 
may be security concerns with returning them!

Cheers,
David
-----

> -------------
> 
> Commit messages:
>   - 8246778: Compiler implementation for Sealed Classes (Second Preview)
> 
> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>    Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/1227/head:pull/1227
> 
> PR: https://git.openjdk.java.net/jdk/pull/1227
> 

From mbaesken at openjdk.java.net  Wed Nov 18 07:49:10 2020
From: mbaesken at openjdk.java.net (Matthias Baesken)
Date: Wed, 18 Nov 2020 07:49:10 GMT
Subject: RFR: 8256427: Test
 com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX [v2]
In-Reply-To: <JME0Vjq8gyb4qyNFXumXXiAKMC2QxR6JFy0mgQHHuS0=.79eeb48c-e887-4f64-aa49-6c6f37cefc9b@github.com>
References: <uU8ZuNpWhgp4lo26_qVGDC2nINRe17UqlTtPQACDegk=.434b84e1-2b2a-4913-820b-0b2839281d97@github.com>
 <JME0Vjq8gyb4qyNFXumXXiAKMC2QxR6JFy0mgQHHuS0=.79eeb48c-e887-4f64-aa49-6c6f37cefc9b@github.com>
Message-ID: <iwX7kZ5UvPHL9zH03dRdWzfT7n4HxjIjiuI-ZEOKjUE=.a5e7703a-a116-40a9-b7b0-d177f5b71b63@github.com>

On Tue, 17 Nov 2020 05:02:07 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> The test com/sun/jndi/dns/ConfigTests/PortUnreachable.java is not working on AIX.
>> 
>> It tests that when a DNS server is unreachable it fails quickly with a PortUnreachableException due to ICMP Destination Unreachable packets received and not having to wait for the full timeout interval.
>> Unfortunately, on AIX such ICMP packets are not received, so the only exception cause will be the timeout. Hence, this test can't work on AIX, so it should not be executed there.
>> 
>> At SAP, we had this test excluded for a long time already in our private exclude list for AIX. I suggest this test update to be the final solution.
>
> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
> 
>   Test jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX

looks good, thanks for doing the change.

-------------

Marked as reviewed by mbaesken (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1241

From chegar at openjdk.java.net  Wed Nov 18 09:16:05 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 18 Nov 2020 09:16:05 GMT
Subject: RFR: 8256477: Specialize heap memory segment implementations
In-Reply-To: <D2lmkIk6L4CK-cFq8ulq7Sa8b4LTuF2yIsTQn0vIa6w=.a087badb-f398-4bb7-9899-39ba5c083d15@github.com>
References: <D2lmkIk6L4CK-cFq8ulq7Sa8b4LTuF2yIsTQn0vIa6w=.a087badb-f398-4bb7-9899-39ba5c083d15@github.com>
Message-ID: <BfCh-DM-MilVdCA_mAc9N4YXteooixdZTCCF2rFowqQ=.9511dd12-bd79-49bd-892a-4625ba7f3cde@github.com>

On Tue, 17 Nov 2020 14:55:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The current memory segment implementation defines a hierarchy with 3 concrete classes: one for heap segments, one for native segments and one for mapped segments.
> 
> Since there can be many kinds of heap segments (e.g. created from a byte[] or from a float[]) the current implementation is prone to type profile pollution problems: if enough heap segments are created (of different kinds), the JIT compiler will give up on speculating on the heap segment kind, which will then result in poor performances.
> 
> This issue can be reproduced in one of the existing benchmark, by adding some initialization code which is enough to pollute the types profiles. When that happens, performance numbers look like the following:
> 
> Benchmark                             (polluteProfile)  Mode  Cnt  Score   Error  Units
> LoopOverNonConstantHeap.segment_loop             false  avgt   10  0.285 ? 0.003  ms/op
> LoopOverNonConstantHeap.segment_loop              true  avgt   10  5.540 ? 0.143  ms/op
> 
> (Thanks to Vlad for coming up for the exact incantation which leads to profile pollution :-) )
> 
> The solution is to create a sharp subclass for each heap segment case. With this, C2 has always a sharp Unsafe *base* to work with, and performances are stable regardless of profile pollution attempts.
> 
> This patch also tweaks the benchmark for heap segments so that it checks it with and without profile pollution.

Marked as reviewed by chegar (Reviewer).

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/HeapMemorySegmentImpl.java line 44:

> 42:  * sharp type information, as well as sharp null-check information. For this reason, many concrete subclasses
> 43:  * of {@link HeapMemorySegmentImpl} are defined (e.g. {@link OfFloat}, so that each subclass can override the
> 44:  * {@link HeapMemorySegmentImpl#base()} method so that it returns an array ogf the correct (sharp) type.

minor typo "ogf" -> "of"

-------------

PR: https://git.openjdk.java.net/jdk/pull/1259

From chegar at openjdk.java.net  Wed Nov 18 09:34:03 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 18 Nov 2020 09:34:03 GMT
Subject: RFR: 8256189: Exact VarHandle tests should test
 withInvokeBehavior() works as expected
In-Reply-To: <0BvFTYxsdMgM5e4M2t6Ok475WQasE7Ni2BbTM6y6AUc=.6eb77e51-e37f-4182-9423-4d763d3c5cf0@github.com>
References: <0BvFTYxsdMgM5e4M2t6Ok475WQasE7Ni2BbTM6y6AUc=.6eb77e51-e37f-4182-9423-4d763d3c5cf0@github.com>
Message-ID: <cUuJc2TXz6rSDFrcvds_xNwZbNstFS-bI_rAz30S0sY=.0ba40489-5575-48e1-81fa-4fe0b5d14957@github.com>

On Tue, 17 Nov 2020 18:32:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This PR sharpens the testing done by test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java after @mcimadamore reported that the test was not catching an issue with memory access var handles; namely that the implementation of withInvokeBehavior was incorrect.
> 
> After some debugging it turned out that the test never actually tested:
> (1) going back to invoke behavior from a var handle with invoke exact behavior
> (2) the memory access handle implementation of withInvoke(Exact)Behavior, due to memory handles always being adapted.
> 
> The patch adds testing for (1), and adds a flag to jdk.internal.foreign.Utils to turn off the adaptation, so that we can test the 'naked' memory access var handles as well for (2).
> 
> I've also tried to reduce some of the code duplication by creating the higher order doTest function, that does most of the testing (besides setting up var handles and test values).

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1267

From mcimadamore at openjdk.java.net  Wed Nov 18 10:08:20 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 18 Nov 2020 10:08:20 GMT
Subject: RFR: 8256477: Specialize heap memory segment implementations [v2]
In-Reply-To: <D2lmkIk6L4CK-cFq8ulq7Sa8b4LTuF2yIsTQn0vIa6w=.a087badb-f398-4bb7-9899-39ba5c083d15@github.com>
References: <D2lmkIk6L4CK-cFq8ulq7Sa8b4LTuF2yIsTQn0vIa6w=.a087badb-f398-4bb7-9899-39ba5c083d15@github.com>
Message-ID: <pKkmGwuyoxjReiuLjXZhV3oI_yXR7zT7AzQcj78KeGY=.8e0d107f-3b90-49cd-978e-f9616d3e7a14@github.com>

> The current memory segment implementation defines a hierarchy with 3 concrete classes: one for heap segments, one for native segments and one for mapped segments.
> 
> Since there can be many kinds of heap segments (e.g. created from a byte[] or from a float[]) the current implementation is prone to type profile pollution problems: if enough heap segments are created (of different kinds), the JIT compiler will give up on speculating on the heap segment kind, which will then result in poor performances.
> 
> This issue can be reproduced in one of the existing benchmark, by adding some initialization code which is enough to pollute the types profiles. When that happens, performance numbers look like the following:
> 
> Benchmark                             (polluteProfile)  Mode  Cnt  Score   Error  Units
> LoopOverNonConstantHeap.segment_loop             false  avgt   10  0.285 ? 0.003  ms/op
> LoopOverNonConstantHeap.segment_loop              true  avgt   10  5.540 ? 0.143  ms/op
> 
> (Thanks to Vlad for coming up for the exact incantation which leads to profile pollution :-) )
> 
> The solution is to create a sharp subclass for each heap segment case. With this, C2 has always a sharp Unsafe *base* to work with, and performances are stable regardless of profile pollution attempts.
> 
> This patch also tweaks the benchmark for heap segments so that it checks it with and without profile pollution.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1259/files
  - new: https://git.openjdk.java.net/jdk/pull/1259/files/2366b69e..e892bc75

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1259&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1259&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1259.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1259/head:pull/1259

PR: https://git.openjdk.java.net/jdk/pull/1259

From mcimadamore at openjdk.java.net  Wed Nov 18 10:26:04 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 18 Nov 2020 10:26:04 GMT
Subject: Integrated: 8256477: Specialize heap memory segment implementations
In-Reply-To: <D2lmkIk6L4CK-cFq8ulq7Sa8b4LTuF2yIsTQn0vIa6w=.a087badb-f398-4bb7-9899-39ba5c083d15@github.com>
References: <D2lmkIk6L4CK-cFq8ulq7Sa8b4LTuF2yIsTQn0vIa6w=.a087badb-f398-4bb7-9899-39ba5c083d15@github.com>
Message-ID: <Porffc9yxRdGKHnJRI3McCm2jR_myyd_TMUEr8VV_w8=.fe2ec269-5dcb-4442-b009-bf84b529348e@github.com>

On Tue, 17 Nov 2020 14:55:07 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The current memory segment implementation defines a hierarchy with 3 concrete classes: one for heap segments, one for native segments and one for mapped segments.
> 
> Since there can be many kinds of heap segments (e.g. created from a byte[] or from a float[]) the current implementation is prone to type profile pollution problems: if enough heap segments are created (of different kinds), the JIT compiler will give up on speculating on the heap segment kind, which will then result in poor performances.
> 
> This issue can be reproduced in one of the existing benchmark, by adding some initialization code which is enough to pollute the types profiles. When that happens, performance numbers look like the following:
> 
> Benchmark                             (polluteProfile)  Mode  Cnt  Score   Error  Units
> LoopOverNonConstantHeap.segment_loop             false  avgt   10  0.285 ? 0.003  ms/op
> LoopOverNonConstantHeap.segment_loop              true  avgt   10  5.540 ? 0.143  ms/op
> 
> (Thanks to Vlad for coming up for the exact incantation which leads to profile pollution :-) )
> 
> The solution is to create a sharp subclass for each heap segment case. With this, C2 has always a sharp Unsafe *base* to work with, and performances are stable regardless of profile pollution attempts.
> 
> This patch also tweaks the benchmark for heap segments so that it checks it with and without profile pollution.

This pull request has now been integrated.

Changeset: d2ddf074
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/d2ddf074
Stats:     187 lines in 4 files changed: 140 ins; 4 del; 43 mod

8256477: Specialize heap memory segment implementations

Reviewed-by: jvernee, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/1259

From sundar at openjdk.java.net  Wed Nov 18 10:31:06 2020
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Wed, 18 Nov 2020 10:31:06 GMT
Subject: RFR: 8256477: Specialize heap memory segment implementations [v2]
In-Reply-To: <pKkmGwuyoxjReiuLjXZhV3oI_yXR7zT7AzQcj78KeGY=.8e0d107f-3b90-49cd-978e-f9616d3e7a14@github.com>
References: <D2lmkIk6L4CK-cFq8ulq7Sa8b4LTuF2yIsTQn0vIa6w=.a087badb-f398-4bb7-9899-39ba5c083d15@github.com>
 <pKkmGwuyoxjReiuLjXZhV3oI_yXR7zT7AzQcj78KeGY=.8e0d107f-3b90-49cd-978e-f9616d3e7a14@github.com>
Message-ID: <FOuhEwB43u2vs8g1XbDGT_6im_4RNp3UIWWq5MOjNaw=.cb202ff0-c29f-4f37-87b1-b558bacef7ea@github.com>

On Wed, 18 Nov 2020 10:08:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The current memory segment implementation defines a hierarchy with 3 concrete classes: one for heap segments, one for native segments and one for mapped segments.
>> 
>> Since there can be many kinds of heap segments (e.g. created from a byte[] or from a float[]) the current implementation is prone to type profile pollution problems: if enough heap segments are created (of different kinds), the JIT compiler will give up on speculating on the heap segment kind, which will then result in poor performances.
>> 
>> This issue can be reproduced in one of the existing benchmark, by adding some initialization code which is enough to pollute the types profiles. When that happens, performance numbers look like the following:
>> 
>> Benchmark                             (polluteProfile)  Mode  Cnt  Score   Error  Units
>> LoopOverNonConstantHeap.segment_loop             false  avgt   10  0.285 ? 0.003  ms/op
>> LoopOverNonConstantHeap.segment_loop              true  avgt   10  5.540 ? 0.143  ms/op
>> 
>> (Thanks to Vlad for coming up for the exact incantation which leads to profile pollution :-) )
>> 
>> The solution is to create a sharp subclass for each heap segment case. With this, C2 has always a sharp Unsafe *base* to work with, and performances are stable regardless of profile pollution attempts.
>> 
>> This patch also tweaks the benchmark for heap segments so that it checks it with and without profile pollution.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

Marked as reviewed by sundar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1259

From peter.levart at gmail.com  Wed Nov 18 11:24:15 2020
From: peter.levart at gmail.com (Peter Levart)
Date: Wed, 18 Nov 2020 12:24:15 +0100
Subject: RFR: 8180352: Add Stream.toList() method [v2]
In-Reply-To: <BESZZeK2WVIubLeJFi1BZayJegadJHxwsB-RFio6k7I=.79995b04-49c9-4aa1-a1b9-3382e0bb4d14@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <aBcWsV_NhVd3jaVqcC-TKl38hWXUmEIrSUmsYPPF88g=.2b4b7d94-a3cc-4fc0-a9e7-defa360ee3a0@github.com>
 <zNl6puL1sy_S1JWp3tLiQQf2YrhHvHY3GtGIBjtfz7E=.5eb94743-bfbb-4908-a2af-e9aceb22c9d3@github.com>
 <VeEg7hCJwqiJ8eqvlPLb9Oi6eNx-pgOqTzwshgb01jk=.5169c749-c176-438b-adc2-9e94921aa7c2@github.com>
 <hhibYsPaakZXBiorfc_4a2T6Y0fwkHATDT49wamF5QU=.4b4549f7-863d-4902-a34c-7648d806d4fd@github.com>
 <ItQDJF_yBhjEKceLh1skwy3tYtIY5T_TxOQX0h6nYBI=.0503f471-5876-4448-80b3-968a16f38293@github.com>
 <Y71HRQPKV6Uc-_6PkgZWl97d3bHhu4BmQjE_pL8MEmA=.f6ab9972-7ed4-41fc-8dcf-c5286b0062fb@github.com>
 <EKK54iv-Ok1SZ1XEeUTm-Yjofp-lSOaRFpyKixb-xKI=.f6489482-9026-46aa-8a1f-afa8dd9d4d58@github.com>
 <BESZZeK2WVIubLeJFi1BZayJegadJHxwsB-RFio6k7I=.79995b04-49c9-4aa1-a1b9-3382e0bb4d14@github.com>
Message-ID: <cc38043b-2107-a470-a0a8-7c7e141ca0c6@gmail.com>


On 11/17/20 9:08 PM, Stuart Marks wrote:
> @plevart wrote:
>> Yes, but that is JDK16+ vs. JDK15- and not App V1 vs. App V2 thing. If both apps run on JDK16+, there will be no exception.
> Sure, the IMM_LIST_NULLS tag only helps with serialization compatibility across JDK releases.


I would say it goes the other way - it worsens the serialization 
compatibility. You are introducing a serialization format that is 
incompatible with older JDK releases. OTOH the problem of introducing 
nulls into List(s) in serializable data structures already exists 
because serializable List implementations that allow nulls already 
exist, so by introducing another one that is able to be deserialized on 
older JDK would not worsen the situation.


>   There are lots of ways an app can make incompatible changes to the serialized forms of its objects that we have no way of detecting.


So why bother with making the result of serialized stream.toList() not 
de-serializable on older JDK(s)? By making a favor to a hypothetical app 
that runs on older JDK and does not expect nulls in Lists of a data 
structure, you are also preventing an app that allows nulls in similar 
data structure from deserializing the datastructure on older JDK when 
the serialized form was produced with serializing stream.toList() on 
newer JDK.

But I see that the new? IMM_LIST_NULLS type is needed for one other 
thing - the immutable list implementation of that type has different 
behavior of indexOf and lastIndexOf methods (it doesn't throw NPE when 
null is passed to those methods) so this behavior has to be preserved in 
the deserialized instance and there is not way to achieve that on old 
JDK with existing serialization format, so there has to be an 
incompatible change in the serialization format for that matter.

Peter



From fw at deneb.enyo.de  Wed Nov 18 11:55:02 2020
From: fw at deneb.enyo.de (Florian Weimer)
Date: Wed, 18 Nov 2020 12:55:02 +0100
Subject: RFR: 8180352: Add Stream.toList() method [v2]
In-Reply-To: <cc38043b-2107-a470-a0a8-7c7e141ca0c6@gmail.com> (Peter Levart's
 message of "Wed, 18 Nov 2020 12:24:15 +0100")
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <aBcWsV_NhVd3jaVqcC-TKl38hWXUmEIrSUmsYPPF88g=.2b4b7d94-a3cc-4fc0-a9e7-defa360ee3a0@github.com>
 <zNl6puL1sy_S1JWp3tLiQQf2YrhHvHY3GtGIBjtfz7E=.5eb94743-bfbb-4908-a2af-e9aceb22c9d3@github.com>
 <VeEg7hCJwqiJ8eqvlPLb9Oi6eNx-pgOqTzwshgb01jk=.5169c749-c176-438b-adc2-9e94921aa7c2@github.com>
 <hhibYsPaakZXBiorfc_4a2T6Y0fwkHATDT49wamF5QU=.4b4549f7-863d-4902-a34c-7648d806d4fd@github.com>
 <ItQDJF_yBhjEKceLh1skwy3tYtIY5T_TxOQX0h6nYBI=.0503f471-5876-4448-80b3-968a16f38293@github.com>
 <Y71HRQPKV6Uc-_6PkgZWl97d3bHhu4BmQjE_pL8MEmA=.f6ab9972-7ed4-41fc-8dcf-c5286b0062fb@github.com>
 <EKK54iv-Ok1SZ1XEeUTm-Yjofp-lSOaRFpyKixb-xKI=.f6489482-9026-46aa-8a1f-afa8dd9d4d58@github.com>
 <BESZZeK2WVIubLeJFi1BZayJegadJHxwsB-RFio6k7I=.79995b04-49c9-4aa1-a1b9-3382e0bb4d14@github.com>
 <cc38043b-2107-a470-a0a8-7c7e141ca0c6@gmail.com>
Message-ID: <877dqiyj55.fsf@mid.deneb.enyo.de>

* Peter Levart:

> But I see that the new? IMM_LIST_NULLS type is needed for one other 
> thing - the immutable list implementation of that type has different 
> behavior of indexOf and lastIndexOf methods (it doesn't throw NPE when 
> null is passed to those methods) so this behavior has to be preserved in 
> the deserialized instance and there is not way to achieve that on old 
> JDK with existing serialization format, so there has to be an 
> incompatible change in the serialization format for that matter.

I think it's also needed for an efficient null element check in
List::copyOf.  I have a hunch that with the posted implementation, it
would incorrectly produce an immutable list that contains null
elements.

From forax at univ-mlv.fr  Wed Nov 18 12:14:58 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 18 Nov 2020 13:14:58 +0100 (CET)
Subject: RFR: 8180352: Add Stream.toList() method [v2]
In-Reply-To: <877dqiyj55.fsf@mid.deneb.enyo.de>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <hhibYsPaakZXBiorfc_4a2T6Y0fwkHATDT49wamF5QU=.4b4549f7-863d-4902-a34c-7648d806d4fd@github.com>
 <ItQDJF_yBhjEKceLh1skwy3tYtIY5T_TxOQX0h6nYBI=.0503f471-5876-4448-80b3-968a16f38293@github.com>
 <Y71HRQPKV6Uc-_6PkgZWl97d3bHhu4BmQjE_pL8MEmA=.f6ab9972-7ed4-41fc-8dcf-c5286b0062fb@github.com>
 <EKK54iv-Ok1SZ1XEeUTm-Yjofp-lSOaRFpyKixb-xKI=.f6489482-9026-46aa-8a1f-afa8dd9d4d58@github.com>
 <BESZZeK2WVIubLeJFi1BZayJegadJHxwsB-RFio6k7I=.79995b04-49c9-4aa1-a1b9-3382e0bb4d14@github.com>
 <cc38043b-2107-a470-a0a8-7c7e141ca0c6@gmail.com>
 <877dqiyj55.fsf@mid.deneb.enyo.de>
Message-ID: <388900241.2270108.1605701698831.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Florian Weimer" <fw at deneb.enyo.de>
> ?: "Peter Levart" <peter.levart at gmail.com>
> Cc: "Stuart Marks" <smarks at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mercredi 18 Novembre 2020 12:55:02
> Objet: Re: RFR: 8180352: Add Stream.toList() method [v2]

> * Peter Levart:
> 
>> But I see that the new? IMM_LIST_NULLS type is needed for one other
>> thing - the immutable list implementation of that type has different
>> behavior of indexOf and lastIndexOf methods (it doesn't throw NPE when
>> null is passed to those methods) so this behavior has to be preserved in
>> the deserialized instance and there is not way to achieve that on old
>> JDK with existing serialization format, so there has to be an
>> incompatible change in the serialization format for that matter.
> 
> I think it's also needed for an efficient null element check in
> List::copyOf.  I have a hunch that with the posted implementation, it
> would incorrectly produce an immutable list that contains null
> elements.

yes !

R?mi

From jlaskey at openjdk.java.net  Wed Nov 18 13:21:11 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 18 Nov 2020 13:21:11 GMT
Subject: Withdrawn: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
Message-ID: <0ehbQoBJaglOxi_fA4XXjjVbL4iXPwj8wz-W9aoW6I8=.5a76bd44-9a20-4e29-b9d9-5f21548df415@github.com>

On Tue, 17 Nov 2020 19:58:47 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 .

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From jlaskey at openjdk.java.net  Wed Nov 18 13:21:10 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 18 Nov 2020 13:21:10 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <2I2HK8tDFSLtPqs0JFLKLgh3QmMTkM1HKuvKQNmsfIg=.a383a449-18e3-413a-a6ba-91dc80fde86a@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>
Message-ID: <I21iHk0o_E19xgFXNA4DkmfU4rx29l10Nb47w5GMjjY=.5600fa62-ded1-4286-90fb-ccf32801ce7b@github.com>

On Wed, 18 Nov 2020 00:51:43 GMT, Paul Sandoz <psandoz 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 40 commits:
>> 
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Update package-info.java
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Updated RandomGeneratorFactory javadoc.
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Updated documentation for RandomGeneratorFactory.
>>  - Merge branch 'master' into 8248862
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Move RandomGeneratorProperty
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Clear up javadoc
>>  - 8248862; Implement Enhanced Pseudo-Random Number Generators
>>    
>>    remove RandomGeneratorProperty from API
>>  - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68
>
> I am unsure if the intent is also to support external libraries providing `RandomGenerator` implementations. Currently there is an implicit contract for properties (reflectively invoking a method returning a map with a set of entries with known keys). Since the service provider implementation is the `RandomGenerator` itself, rather than `RandomGeneratorFactory` it is harder expose the meta-data with a clearer contract.

Need rebase

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From erikj at openjdk.java.net  Wed Nov 18 13:36:07 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Wed, 18 Nov 2020 13:36:07 GMT
Subject: RFR: 8251317: Support for CLDR version 38
In-Reply-To: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
References: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
Message-ID: <6y-uJZl6ZqCrkPzq84kdwWndQbhVLGWbl5k9Hl0lv4A=.a843d0d5-e2be-41e2-be22-86021da9f00f@github.com>

On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes for upgrading the CLDR data to version 38. The vast majority of the changes are simply the changes in CLDR upstream, and others are mainly test changes due to the locale data change.

Looks fine from a build point of view.

-------------

Marked as reviewed by erikj (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1279

From jlaskey at openjdk.java.net  Wed Nov 18 13:48:04 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 18 Nov 2020 13:48:04 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <I21iHk0o_E19xgFXNA4DkmfU4rx29l10Nb47w5GMjjY=.5600fa62-ded1-4286-90fb-ccf32801ce7b@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>
Message-ID: <5IW2VsaVaqCMqkD6qkNxdWpL1qJM8daN1yf9a-Ivxk8=.d15e95c1-183d-4d50-98ff-e112beadf602@github.com>

On Wed, 18 Nov 2020 13:18:30 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> I am unsure if the intent is also to support external libraries providing `RandomGenerator` implementations. Currently there is an implicit contract for properties (reflectively invoking a method returning a map with a set of entries with known keys). Since the service provider implementation is the `RandomGenerator` itself, rather than `RandomGeneratorFactory` it is harder expose the meta-data with a clearer contract.
>
> Need rebase

Created new PR because of forced push: https://github.com/openjdk/jdk/pull/1292

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From jlaskey at openjdk.java.net  Wed Nov 18 13:52:56 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 18 Nov 2020 13:52:56 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
Message-ID: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@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

-------------

Commit messages:
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
 - 8248862; Implement Enhanced Pseudo-Random Number Generators
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
 - ... and 15 more: https://git.openjdk.java.net/jdk/compare/f7517386...2b3e4ed7

Changes: https://git.openjdk.java.net/jdk/pull/1292/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8248862
  Stats: 13319 lines in 25 files changed: 11110 ins; 2132 del; 77 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 prappo at openjdk.java.net  Wed Nov 18 14:19:06 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 18 Nov 2020 14:19:06 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
 <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
Message-ID: <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>

On Wed, 21 Oct 2020 00:11:42 GMT, John Lin <github.com+1290376+johnlinp at openjdk.org> wrote:

>> Hi Jon, 
>> 
>> Can you explain what this change is about: e.g. something like:
>> 
>>> Updates the documentation of `Map::compute` to match its default implementation:
>>> The documentation of the default implementation of `Map::compute` was both wrong and confusing. 
>>> This change updates the documentation to match the behaviour of the implementation.
>> 
>> because now I am confused. I believe what you are trying to do is what I have written above. Can you confirm?
>> This will need a CSR.
>> 
>> And are you going to withdraw https://github.com/openjdk/jdk/pull/451 now?
>> 
>> best regards,
>> -- daniel
>
> @dfuch May I ask how can I create a CSR? I checked https://wiki.openjdk.java.net/display/csr/CSR+FAQs and it says:
> 
>> 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 at https://bugs.openjdk.java.net/ yet. Therefore, I don't see the "More" button on https://bugs.openjdk.java.net/browse/JDK-8247402. Could you please tell me how do I proceed? Thank you.

@johnlinp, you cannot create a CSR by yourself at the moment. Someone else will have to do that for you. Might as well be me. So here's my proposal: come up with the meat, then I'll help you with the paperwork. 

For starters, have a look at existing CSRs (you don't need a JBS account for that). For example, https://bugs.openjdk.java.net/issues/?jql=issuetype%3DCSR%20and%20Subcomponent%3Djava.util%3Acollections%20

Fill in an informal CSR template inline in this thread, and we'll proceed from that point. Is that okay?

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From psandoz at openjdk.java.net  Wed Nov 18 15:53:11 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 18 Nov 2020 15:53:11 GMT
Subject: RFR: 8256152: tests fail because of ambiguous method resolution
 [v2]
In-Reply-To: <4bI308aqoWpHVIrtzu07AQPQLUanzXNCw1FwTCUgcFU=.e014743a-8510-4a60-887e-57a2aa8aea53@github.com>
References: <2Sc4ZnmZ510_ykvmkkJbICYWTtzt1VH32x_LT6Miaxs=.5f9dd093-8112-4ab2-b323-e0fae0d63bfe@github.com>
 <4bI308aqoWpHVIrtzu07AQPQLUanzXNCw1FwTCUgcFU=.e014743a-8510-4a60-887e-57a2aa8aea53@github.com>
Message-ID: <BV_dLoTyI-aMwFU0HBLCYr7sQjUnOE3CLkbm4OrdSo8=.88c91940-fad4-463b-ac9b-624ce8ce179d@github.com>

On Tue, 17 Nov 2020 23:34:23 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Added a cast in the right place, thanks to @jonathan-gibbons.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cast to double instead of Object

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1274

From psandoz at openjdk.java.net  Wed Nov 18 17:29:07 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 18 Nov 2020 17:29:07 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v4]
In-Reply-To: <tKPyoN5O290X_W3n2DF1jvunO0YBoyNnoT5jXjmsNc0=.ecc67352-e2ef-4408-9ac1-e5e90a345424@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <tKPyoN5O290X_W3n2DF1jvunO0YBoyNnoT5jXjmsNc0=.ecc67352-e2ef-4408-9ac1-e5e90a345424@github.com>
Message-ID: <YjOh_XiWJao12sjdgOQx6zzogtNczB3QHC476jvE2DI=.04874bb8-94c7-436e-85a8-3cda8e39c029@github.com>

On Wed, 18 Nov 2020 00:50:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects
>> be shared between a hidden class and other classes.  A hidden class can load
>> these live objects as dynamically-computed constants via this API.
>> 
>> Specdiff
>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
>> 
>> With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass`
>> will be deprecated for removal.  Existing libraries should replace their
>> calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass`
>> or `Lookup::defineHiddenClassWithClassData`.
>> 
>> This patch also updates the implementation of lambda meta factory and
>> `MemoryAccessVarHandleGenerator` to use class data.   No performance difference
>> observed in the jdk.incubator.foreign microbenchmarks.   A side note: 
>> `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of 
>> JDK-8254162 but it helps validating the class data support.
>> 
>> Background
>> ----------
>> 
>> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
>> "Constant-pool patching" in the "Risks and Assumption" section.
>> 
>> A VM-anonymous class can be defined with its constant-pool entries already
>> resolved to concrete values. This allows critical constants to be shared
>> between a VM-anonymous class and the language runtime that defines it, and
>> between multiple VM-anonymous classes. For example, a language runtime will
>> often have `MethodHandle` objects in its address space that would be useful
>> to newly-defined VM-anonymous classes. Instead of the runtime serializing
>> the objects to constant-pool entries in VM-anonymous classes and then
>> generating bytecode in those classes to laboriously `ldc` the entries,
>> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
>> to its live objects. The relevant constant-pool entries in the newly-defined
>> VM-anonymous class are pre-linked to those objects, improving performance
>> and reducing footprint. In addition, this allows VM-anonymous classes to
>> refer to each other: Constant-pool entries in a class file are based on names.
>> They thus cannot refer to nameless VM-anonymous classes. A language runtime can,
>> however, easily track the live Class objects for its VM-anonymous classes and
>> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's
>> constant pool entries to other VM-anonymous classes.
>> 
>> This extends the hidden classes to allow live objects to be injected
>> in a hidden class and loaded them via condy.
>> 
>> Details
>> -------
>> 
>> A new `Lookup::defineHiddenClassWithClassData` API takes additional
>> `classData` argument compared to `Lookup::defineHiddenClass`.
>> Class data can be method handles, lookup objects, arbitrary user objects
>> or collections of all of the above.
>> 
>> This method behaves as if calling `Lookup::defineHiddenClass` to define
>> a hidden class with a private static unnamed field that is initialized
>> with `classData` at the first instruction of the class initializer.
>> 
>> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)` and
>> `MethodHandles::classDataAt(Lookup lookup, String name, Class<?> type, int index)`
>> are the bootstrap methods to load the class data of the given lookup's lookup class.
>> The hidden class will be initialized when `classData` method is called if
>> the hidden class has not been initialized.
>> 
>> For a class data containing more than one single element, libraries can
>> create their convenience method to load a single live object via condy.
>> 
>> Frameworks sometimes want to dynamically create a hidden class (HC) and add it
>> it the lookup class nest and have HC to carry secrets hidden from that nest.
>> In this case, frameworks should not to use private static finals (in the HCs
>> they spin) to hold secrets because a nestmate of HC may obtain access to
>> such a private static final and observe the framework's secret.  It should use
>> condy.  In addition, we need to differentiate if a lookup object is created from
>> the original lookup class or created from teleporting e.g. `Lookup::in`
>> and `MethodHandles::privateLookupIn`.
>> 
>> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
>> object is created by `MethodHandles::lookup` or by bootstrap method invocation.
>> The operations only apply to a Lookup object with original access are:
>>    - create method handles for caller-sensitve methods
>>    - obtain class data associated with the lookup class
>> 
>> No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which
>> ignores the ORIGINAL bit.
>> 
>> 
>> Compatibility Risks
>> -------------------
>> 
>> `Lookup::lookupModes` includes a new `ORIGINAL` bit.  Most lookup operations
>> ignore this original bit except creating method handles for caller-sensitive methods
>> that expects the lookup from the original lookup class.  Existing code  compares
>> the return value of `lookupModes` to be a fixed value may be impacted.   However
>> existing client has no need to expect a fixed value of lookup modes.
>> The incompatibility risk of this spec change is low.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the name passed to condy calling classData

IIUC `classData` can be used for an original lookup that is not produced by the result of `defineHiddenClassWithClassData`, but in such cases the class data will always be null.

Since `defineHiddenClassWithClassData` rejects null values for class data, we could detect such usage and throw in the bootstrap methods. That would require a special constant assignment for hidden classes with no class data. Probably not worth it.

Recommend an API note.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 342:

> 340:          } catch (ClassCastException e) {
> 341:              throw e;
> 342:          } catch (Throwable e) {

The following might be more appropriate so, in general, errors and runtime exceptions are not explicitly wrapped:

        try {
            return BootstrapMethodInvoker.widenAndCast(classdata, type);
        }
        catch (RuntimeException | Error e) {
            throw e;
        }
        catch (Throwable e) {
            throw new InternalError("Unexpected exception", e);
        }

same applies to `classDataAt` and `ConstantBootstraps.explicitCast`. Refinement of the runtime exceptions is also possible, but i think the key thing here is to let errors pass through and any possibly expected runtime exceptions will get wrapped in `BootstrapMethodError`.

test/jdk/java/lang/invoke/MethodHandles/classData/ClassDataTest.java line 77:

> 75:      */
> 76:     @Test
> 77:     public void noClassData() throws Throwable {

`throws Throwable` needed on this and other method declarations?

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1171

From rriggs at openjdk.java.net  Wed Nov 18 17:39:06 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 18 Nov 2020 17:39:06 GMT
Subject: RFR: 8256480: Refactor ObjectInputStream field reader implementation
Message-ID: <57N_l5oDQywDYUYK-EH1Odb00ipNZxHTNg_NSzfx2Ww=.d11b14a5-8b9c-421e-a92d-cac8462b0f8e@github.com>

ObjectInputStream has nearly identical but separate implementations to read values from the stream.
Both implementations read primitive and object values from the stream and return an object holding the values.
OIS.readFields() uses the internal class GetFieldImpl while OIS.defaultReadObject and reading records uses the internal class FieldValues.
The behavioral difference between the two is whether dependencies are tracked in the object handle table or not. 

The classes are merged, retaining the internal FieldValues name and the behavior to track dependencies or not. 
The constructor is passed the class descriptor and flag to track or not; it reads and saves the values from the stream.
The callers are updated to call the merge FieldValues methods.

There is no change in behavior; all current tests pass.

-------------

Commit messages:
 - 8256480: Refactor ObjectInputStream field reader implementation

Changes: https://git.openjdk.java.net/jdk/pull/1296/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1296&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256480
  Stats: 157 lines in 1 file changed: 26 ins; 78 del; 53 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1296.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1296/head:pull/1296

PR: https://git.openjdk.java.net/jdk/pull/1296

From mchung at openjdk.java.net  Wed Nov 18 18:17:04 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 18 Nov 2020 18:17:04 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v4]
In-Reply-To: <YjOh_XiWJao12sjdgOQx6zzogtNczB3QHC476jvE2DI=.04874bb8-94c7-436e-85a8-3cda8e39c029@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <tKPyoN5O290X_W3n2DF1jvunO0YBoyNnoT5jXjmsNc0=.ecc67352-e2ef-4408-9ac1-e5e90a345424@github.com>
 <YjOh_XiWJao12sjdgOQx6zzogtNczB3QHC476jvE2DI=.04874bb8-94c7-436e-85a8-3cda8e39c029@github.com>
Message-ID: <-QlcrtVKibr-DZTIJegWDQ0mfQkPXmSaiKsmlzVLjqQ=.f6a7d0b3-791d-4716-b01e-fcd6ac8ee1fb@github.com>

On Wed, 18 Nov 2020 16:51:47 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the name passed to condy calling classData
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 342:
> 
>> 340:          } catch (ClassCastException e) {
>> 341:              throw e;
>> 342:          } catch (Throwable e) {
> 
> The following might be more appropriate so, in general, errors and runtime exceptions are not explicitly wrapped:
> 
>         try {
>             return BootstrapMethodInvoker.widenAndCast(classdata, type);
>         }
>         catch (RuntimeException | Error e) {
>             throw e;
>         }
>         catch (Throwable e) {
>             throw new InternalError("Unexpected exception", e);
>         }
> 
> same applies to `classDataAt` and `ConstantBootstraps.explicitCast`. Refinement of the runtime exceptions is also possible, but i think the key thing here is to let errors pass through and any possibly expected runtime exceptions will get wrapped in `BootstrapMethodError`.

Yes a good refinement.

diff --git a/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java b/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
index 71cae83e160..27d74284dc6 100644
--- a/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
+++ b/src/java.base/share/classes/java/lang/invoke/ConstantBootstraps.java
@@ -413,8 +413,8 @@ public final class ConstantBootstraps {
         MethodHandle conv = MethodHandles.explicitCastArguments(id, mt);
         try {
             return conv.invoke(value);
-        } catch (ClassCastException e) {
-            throw e; // specified, let CCE through
+        } catch (RuntimeException|Error e) {
+            throw e; // let specified CCE and other runtime exceptions/errors through
         } catch (Throwable throwable) {
             throw new InternalError(throwable); // Not specified, throw InternalError
         }
diff --git a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
index cd9bdbaf5a3..368948ab5a8 100644
--- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
+++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
@@ -337,8 +342,8 @@ public class MethodHandles {
 
          try {
              return BootstrapMethodInvoker.widenAndCast(classdata, type);
-         } catch (ClassCastException e) {
-             throw e;
+         } catch (RuntimeException|Error e) {
+             throw e; // let CCE and other runtime exceptions through
          } catch (Throwable e) {
              throw new InternalError(e);
          }
@@ -409,8 +414,8 @@ public class MethodHandles {
         try {
             Object element = classdata.get(index);
             return BootstrapMethodInvoker.widenAndCast(element, type);
-        } catch (ClassCastException|NullPointerException|IndexOutOfBoundsException e) {
-            throw e;
+        } catch (RuntimeException|Error e) {
+            throw e; // let specified exceptions and other runtime exceptions/errors through
         } catch (Throwable e) {
             throw new InternalError(e);
         }

> test/jdk/java/lang/invoke/MethodHandles/classData/ClassDataTest.java line 77:
> 
>> 75:      */
>> 76:     @Test
>> 77:     public void noClassData() throws Throwable {
> 
> `throws Throwable` needed on this and other method declarations?

`noClassData` only needs `IllegalACcessException`.   `assertClassData` throws Throwable because it unwraps from `InvocationTargetException`.  I can take a pass to clean this up further.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1171

From mchung at openjdk.java.net  Wed Nov 18 18:20:03 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 18 Nov 2020 18:20:03 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v4]
In-Reply-To: <YjOh_XiWJao12sjdgOQx6zzogtNczB3QHC476jvE2DI=.04874bb8-94c7-436e-85a8-3cda8e39c029@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <tKPyoN5O290X_W3n2DF1jvunO0YBoyNnoT5jXjmsNc0=.ecc67352-e2ef-4408-9ac1-e5e90a345424@github.com>
 <YjOh_XiWJao12sjdgOQx6zzogtNczB3QHC476jvE2DI=.04874bb8-94c7-436e-85a8-3cda8e39c029@github.com>
Message-ID: <Shr4We-l7-KU0sNLp9SSB-5u35BZPopz2pk0ovYG-mU=.6e10030e-2610-46af-b1c6-03cefe343dce@github.com>

On Wed, 18 Nov 2020 17:26:02 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> IIUC classData can be used for an original lookup that is not produced by the result of defineHiddenClassWithClassData, but in such cases the class data will always be null.

Yes that's the case.  I see some clarification would help.    I added the following in the spec of `classData` and `classDataAt`:

     * <p> A hidden class created by {@link Lookup#defineHiddenClass(byte[], boolean, Lookup.ClassOption...)
     * Lookup::defineHiddenClass} and non-hidden classes have no class data.
     * {@code null} is returned if this method is called on the lookup object
     * on these classes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1171

From mchung at openjdk.java.net  Wed Nov 18 18:34:06 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 18 Nov 2020 18:34:06 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v4]
In-Reply-To: <YjOh_XiWJao12sjdgOQx6zzogtNczB3QHC476jvE2DI=.04874bb8-94c7-436e-85a8-3cda8e39c029@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <tKPyoN5O290X_W3n2DF1jvunO0YBoyNnoT5jXjmsNc0=.ecc67352-e2ef-4408-9ac1-e5e90a345424@github.com>
 <YjOh_XiWJao12sjdgOQx6zzogtNczB3QHC476jvE2DI=.04874bb8-94c7-436e-85a8-3cda8e39c029@github.com>
Message-ID: <7ugTtHpCoaQMyT3cvKs2rUEfZOhCNPqyuea-Kia3eAo=.e73fdca6-447e-411c-9ec4-a6f52b96a3e1@github.com>

On Wed, 18 Nov 2020 17:26:02 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the name passed to condy calling classData
>
> IIUC `classData` can be used for an original lookup that is not produced by the result of `defineHiddenClassWithClassData`, but in such cases the class data will always be null.
> 
> Since `defineHiddenClassWithClassData` rejects null values for class data, we could detect such usage and throw in the bootstrap methods. That would require a special constant assignment for hidden classes with no class data. Probably not worth it.
> 
> Recommend an API note.

@PaulSandoz @JornVernee can you please review CSR:
    https://bugs.openjdk.java.net/browse/JDK-8256214

-------------

PR: https://git.openjdk.java.net/jdk/pull/1171

From jvernee at openjdk.java.net  Wed Nov 18 19:05:01 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 18 Nov 2020 19:05:01 GMT
Subject: Integrated: 8256189: Exact VarHandle tests should test
 withInvokeBehavior() works as expected
In-Reply-To: <0BvFTYxsdMgM5e4M2t6Ok475WQasE7Ni2BbTM6y6AUc=.6eb77e51-e37f-4182-9423-4d763d3c5cf0@github.com>
References: <0BvFTYxsdMgM5e4M2t6Ok475WQasE7Ni2BbTM6y6AUc=.6eb77e51-e37f-4182-9423-4d763d3c5cf0@github.com>
Message-ID: <nInSED3_fUagjF_vAMyibzRfJM4bH59cSBm61AX3YTA=.1cfb0730-a0a0-4b65-befd-2337b521719d@github.com>

On Tue, 17 Nov 2020 18:32:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This PR sharpens the testing done by test/jdk/java/lang/invoke/VarHandles/VarHandleTestExact.java after @mcimadamore reported that the test was not catching an issue with memory access var handles; namely that the implementation of withInvokeBehavior was incorrect.
> 
> After some debugging it turned out that the test never actually tested:
> (1) going back to invoke behavior from a var handle with invoke exact behavior
> (2) the memory access handle implementation of withInvoke(Exact)Behavior, due to memory handles always being adapted.
> 
> The patch adds testing for (1), and adds a flag to jdk.internal.foreign.Utils to turn off the adaptation, so that we can test the 'naked' memory access var handles as well for (2).
> 
> I've also tried to reduce some of the code duplication by creating the higher order doTest function, that does most of the testing (besides setting up var handles and test values).

This pull request has now been integrated.

Changeset: 03e84ef7
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/03e84ef7
Stats:     173 lines in 3 files changed: 48 ins; 80 del; 45 mod

8256189: Exact VarHandle tests should test withInvokeBehavior() works as expected

Reviewed-by: mcimadamore, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/1267

From igraves at openjdk.java.net  Wed Nov 18 20:57:26 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 18 Nov 2020 20:57:26 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v10]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <wPcbmJQ-jTBVVir2z0FukqAQAZZ7kQPD0iFWn3gX2UI=.f8c8a18d-2e5f-405f-88cd-9fd3445b6a6c@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Docfixes, exception messages, formatting and moving tests to testng

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/aaa35af2..03d55944

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=08-09

  Stats: 177 lines in 5 files changed: 77 ins; 98 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From bchristi at openjdk.java.net  Wed Nov 18 21:18:05 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Wed, 18 Nov 2020 21:18:05 GMT
Subject: RFR: 8251317: Support for CLDR version 38
In-Reply-To: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
References: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
Message-ID: <tHh3uXWWKnFpSW9uWupt9WjkolM-6U353JO1Fk9L4vo=.a1621452-c4c5-49eb-9e7b-68a8cdff00d4@github.com>

On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes for upgrading the CLDR data to version 38. The vast majority of the changes are simply the changes in CLDR upstream, and others are mainly test changes due to the locale data change.

Changes seem fine to me.

-------------

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1279

From github.com+1290376+johnlinp at openjdk.java.net  Wed Nov 18 21:32:05 2020
From: github.com+1290376+johnlinp at openjdk.java.net (John Lin)
Date: Wed, 18 Nov 2020 21:32:05 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
 <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
 <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
Message-ID: <JPS91QuDPRSVTP9YOXfLkK2VfAzlWtDOm5Dp_GJexNA=.395cf9b1-5e79-4624-b9fb-1eead9fcd582@github.com>

On Wed, 18 Nov 2020 14:16:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> @dfuch May I ask how can I create a CSR? I checked https://wiki.openjdk.java.net/display/csr/CSR+FAQs and it says:
>> 
>>> 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 at https://bugs.openjdk.java.net/ yet. Therefore, I don't see the "More" button on https://bugs.openjdk.java.net/browse/JDK-8247402. Could you please tell me how do I proceed? Thank you.
>
> @johnlinp, you cannot create a CSR by yourself at the moment. Someone else will have to do that for you. Might as well be me. So here's my proposal: come up with the meat, then I'll help you with the paperwork. 
> 
> For starters, have a look at existing CSRs (you don't need a JBS account for that). For example, https://bugs.openjdk.java.net/issues/?jql=issuetype%3DCSR%20and%20Subcomponent%3Djava.util%3Acollections%20
> 
> Fill in an informal CSR template inline in this thread, and we'll proceed from that point. Is that okay?

@pavelrappo Thank you for your kind help and great proposal. I'll write up a draft CSR in this thread.

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From asemenyuk at openjdk.java.net  Wed Nov 18 22:02:16 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Wed, 18 Nov 2020 22:02:16 GMT
Subject: RFR: 8227400: Adjust jib profiles to make 3rd party tools for
 creating installers available on Mach5 test machines
Message-ID: <_GZPUzt_Q7AQdwekL4jTnkXUx8XmgaQA7iA_fa8L7Jo=.5c33486c-3220-4364-9586-e9be3b66f424@github.com>

Fix test failures. They didn't fail in Mach5 test runs as WiX was not available on test machines and these tests were not executed.

-------------

Commit messages:
 - 8227400: Adjust jib profiles to make 3rd party tools for creating installers available on Mach5 test machines

Changes: https://git.openjdk.java.net/jdk/pull/1298/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1298&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8227400
  Stats: 21 lines in 4 files changed: 16 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1298.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1298/head:pull/1298

PR: https://git.openjdk.java.net/jdk/pull/1298

From smarks at openjdk.java.net  Wed Nov 18 22:04:08 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 18 Nov 2020 22:04:08 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v2]
In-Reply-To: <BESZZeK2WVIubLeJFi1BZayJegadJHxwsB-RFio6k7I=.79995b04-49c9-4aa1-a1b9-3382e0bb4d14@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <aBcWsV_NhVd3jaVqcC-TKl38hWXUmEIrSUmsYPPF88g=.2b4b7d94-a3cc-4fc0-a9e7-defa360ee3a0@github.com>
 <zNl6puL1sy_S1JWp3tLiQQf2YrhHvHY3GtGIBjtfz7E=.5eb94743-bfbb-4908-a2af-e9aceb22c9d3@github.com>
 <VeEg7hCJwqiJ8eqvlPLb9Oi6eNx-pgOqTzwshgb01jk=.5169c749-c176-438b-adc2-9e94921aa7c2@github.com>
 <hhibYsPaakZXBiorfc_4a2T6Y0fwkHATDT49wamF5QU=.4b4549f7-863d-4902-a34c-7648d806d4fd@github.com>
 <ItQDJF_yBhjEKceLh1skwy3tYtIY5T_TxOQX0h6nYBI=.0503f471-5876-4448-80b3-968a16f38293@github.com>
 <Y71HRQPKV6Uc-_6PkgZWl97d3bHhu4BmQjE_pL8MEmA=.f6ab9972-7ed4-41fc-8dcf-c5286b0062fb@github.com>
 <EKK54iv-Ok1SZ1XEeUTm-Yjofp-lSOaRFpyKixb-xKI=.f6489482-9026-46aa-8a1f-afa8dd9d4d58@github.com>
 <BESZZeK2WVIubLeJFi1BZayJegadJHxwsB-RFio6k7I=.79995b04-49c9-4aa1-a1b9-3382e0bb4d14@github.com>
Message-ID: <WqtH3VNsrndMRBMJXFiDCcgKCzBYjDU-2XzmAXcZyYI=.9ef452d7-52ef-4d3b-b977-9f468b953c50@github.com>

On Tue, 17 Nov 2020 20:04:58 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>>> @plevart wrote:
>>> 
>>> > But the question is how does having a separate CollSer.IMM_LIST_NULLS type prevent that from happening?
>>> 
>>> When a serialized list with IMM_LIST_NULLS is deserialized on an older JDK, it'll throw InvalidObjectException since that tag isn't valid on older JDKs. Obviously this is still an error, but it's a fail-fast approach that avoids letting nulls leak into a data structure where they might cause a problem some arbitrary time later.
>>> 
>> 
>> Yes, but that is JDK16+ vs. JDK15- and not App V1 vs. App V2 thing. If both apps run on JDK16+, there will be no exception.
>> 
>> What I'm trying to say is that the same problem of injecting unexpected nulls via serialization/deserialization can happen also if App V2 starts using ArrayList to construct the data structure and serialize it while App V1 deserializes it and expects non-null values only. App V1 would already have to guard against null values during deserialization in that case, because possibility of null values in deserialized data structure is nothing new for App V1.
>
> @plevart wrote:
>> Yes, but that is JDK16+ vs. JDK15- and not App V1 vs. App V2 thing. If both apps run on JDK16+, there will be no exception.
> 
> Sure, the IMM_LIST_NULLS tag only helps with serialization compatibility across JDK releases. There are lots of ways an app can make incompatible changes to the serialized forms of its objects that we have no way of detecting.

>> Sure, the IMM_LIST_NULLS tag only helps with serialization compatibility across JDK releases.

> I would say it goes the other way - it worsens the serialization
compatibility.

OK, I was imprecise. The IMM_LIST_NULLS tag has an effect only on serialization across JDK releases, not changes to the application's serialization format using the same JDK release, or even on many changes to the app's serialization format across JDK releases. By "helps with serialization compatibility" I meant that this new serialized form helps the general issue of serialization compatibility (really, incompatibility) by failing fast in certain cases, instead of possibly allowing polluted data to leak into the receiving application and causing some arbitrary exception later during the run.

But as you noted last, this is a different kind of object, and it has different behavior, so it needs a different encoding in the serialized form.

I'll update this PR shortly with changes to fix null handling and other issues.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1026

From clanger at openjdk.java.net  Wed Nov 18 22:04:10 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Wed, 18 Nov 2020 22:04:10 GMT
Subject: RFR: 8256427: Test
 com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX [v2]
In-Reply-To: <iwX7kZ5UvPHL9zH03dRdWzfT7n4HxjIjiuI-ZEOKjUE=.a5e7703a-a116-40a9-b7b0-d177f5b71b63@github.com>
References: <uU8ZuNpWhgp4lo26_qVGDC2nINRe17UqlTtPQACDegk=.434b84e1-2b2a-4913-820b-0b2839281d97@github.com>
 <JME0Vjq8gyb4qyNFXumXXiAKMC2QxR6JFy0mgQHHuS0=.79eeb48c-e887-4f64-aa49-6c6f37cefc9b@github.com>
 <iwX7kZ5UvPHL9zH03dRdWzfT7n4HxjIjiuI-ZEOKjUE=.a5e7703a-a116-40a9-b7b0-d177f5b71b63@github.com>
Message-ID: <h9-VvtZ_DsjikJi1EaqNWqmJY6Ble386eUgbKeyA61Q=.35a4ccce-4d03-4a59-9589-92dbae9be331@github.com>

On Wed, 18 Nov 2020 07:46:33 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Christoph Langer has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   Test jdk/com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX
>
> looks good, thanks for doing the change.

Thanks for the reviews!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1241

From clanger at openjdk.java.net  Wed Nov 18 22:04:11 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Wed, 18 Nov 2020 22:04:11 GMT
Subject: Integrated: 8256427: Test
 com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX
In-Reply-To: <uU8ZuNpWhgp4lo26_qVGDC2nINRe17UqlTtPQACDegk=.434b84e1-2b2a-4913-820b-0b2839281d97@github.com>
References: <uU8ZuNpWhgp4lo26_qVGDC2nINRe17UqlTtPQACDegk=.434b84e1-2b2a-4913-820b-0b2839281d97@github.com>
Message-ID: <vgweJ5vcTY02Ga3aey-y4rARLKWiRIURXvty0iS2AHE=.2ccd8ae2-517f-4711-8074-d6316997552a@github.com>

On Mon, 16 Nov 2020 22:28:08 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> The test com/sun/jndi/dns/ConfigTests/PortUnreachable.java is not working on AIX.
> 
> It tests that when a DNS server is unreachable it fails quickly with a PortUnreachableException due to ICMP Destination Unreachable packets received and not having to wait for the full timeout interval.
> Unfortunately, on AIX such ICMP packets are not received, so the only exception cause will be the timeout. Hence, this test can't work on AIX, so it should not be executed there.
> 
> At SAP, we had this test excluded for a long time already in our private exclude list for AIX. I suggest this test update to be the final solution.

This pull request has now been integrated.

Changeset: 5912df24
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5912df24
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8256427: Test com/sun/jndi/dns/ConfigTests/PortUnreachable.java does not work on AIX

Reviewed-by: jiefu, mbaesken

-------------

PR: https://git.openjdk.java.net/jdk/pull/1241

From hchao at openjdk.java.net  Wed Nov 18 22:05:12 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Wed, 18 Nov 2020 22:05:12 GMT
Subject: RFR: 8253299: Manifest bytes are read twice when verifying a signed
 JAR
Message-ID: <K2o1WH3ajvU5EwPLzo9Qc8jUSRmY5oM3c_VABTC7cBg=.0778a27f-d992-4f93-883c-8ca3a3d22b34@github.com>

Small change to retrieve the raw bytes of manifest during verifying signed JAR.

-------------

Commit messages:
 - 8253299: Manifest bytes are read twice when verifying a signed JAR

Changes: https://git.openjdk.java.net/jdk/pull/1299/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1299&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253299
  Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1299.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1299/head:pull/1299

PR: https://git.openjdk.java.net/jdk/pull/1299

From smarks at openjdk.java.net  Wed Nov 18 22:07:05 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 18 Nov 2020 22:07:05 GMT
Subject: Integrated: 8256152: tests fail because of ambiguous method resolution
In-Reply-To: <2Sc4ZnmZ510_ykvmkkJbICYWTtzt1VH32x_LT6Miaxs=.5f9dd093-8112-4ab2-b323-e0fae0d63bfe@github.com>
References: <2Sc4ZnmZ510_ykvmkkJbICYWTtzt1VH32x_LT6Miaxs=.5f9dd093-8112-4ab2-b323-e0fae0d63bfe@github.com>
Message-ID: <uhIT2OakqKJzWXurFejQimquYC_3N0e9hSBwE0vMt0g=.62a9e5ae-b0ad-476f-8b44-616b0d5ad009@github.com>

On Tue, 17 Nov 2020 20:01:37 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> Added a cast in the right place, thanks to @jonathan-gibbons.

This pull request has now been integrated.

Changeset: 646c2002
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/646c2002
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8256152: tests fail because of ambiguous method resolution

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.java.net/jdk/pull/1274

From igraves at openjdk.java.net  Wed Nov 18 22:09:21 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 18 Nov 2020 22:09:21 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v11]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <ZSEP18ohoQXkkjsifdw0ukalzVO06Es6Vg0LzzJ5b_c=.71ba4c7e-c7fb-4929-a644-379c09d7476c@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Exception message tweak

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/03d55944..36e8d3a3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=09-10

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From smarks at openjdk.java.net  Wed Nov 18 22:20:26 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 18 Nov 2020 22:20:26 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v3]
In-Reply-To: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
Message-ID: <Mr9vpzMowscNpOjJ52oOlJO50L8x6drIxHb44rVpb1k=.80331bd0-ab10-4658-a5de-d6939251ba25@github.com>

> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
> 
> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
> 
> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
> 
> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Adjust List.copyOf to null-check and copy allowNulls lists.
  Fix equals, hashCode, indexOf, lastIndexOf to handle nulls properly.
  Add MOAT tests for new lists; add equals and hashCode tests.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1026/files
  - new: https://git.openjdk.java.net/jdk/pull/1026/files/cf849755..15beacd2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1026&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1026&range=01-02

  Stats: 136 lines in 3 files changed: 104 ins; 22 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1026/head:pull/1026

PR: https://git.openjdk.java.net/jdk/pull/1026

From herrick at openjdk.java.net  Wed Nov 18 22:22:13 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Wed, 18 Nov 2020 22:22:13 GMT
Subject: RFR: JDK-8256475: Fix Behavior when Installer name differs from
 =?UTF-8?B?YXBwbGljYXRpb+KApg==?=
Message-ID: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>

?n name.

-------------

Commit messages:
 - JDK-8256475: Fix Behavior when Installer name differs from application name.

Changes: https://git.openjdk.java.net/jdk/pull/1300/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1300&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256475
  Stats: 207 lines in 18 files changed: 167 ins; 13 del; 27 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1300.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1300/head:pull/1300

PR: https://git.openjdk.java.net/jdk/pull/1300

From rriggs at openjdk.java.net  Wed Nov 18 22:34:06 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 18 Nov 2020 22:34:06 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v11]
In-Reply-To: <ZSEP18ohoQXkkjsifdw0ukalzVO06Es6Vg0LzzJ5b_c=.71ba4c7e-c7fb-4929-a644-379c09d7476c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <ZSEP18ohoQXkkjsifdw0ukalzVO06Es6Vg0LzzJ5b_c=.71ba4c7e-c7fb-4929-a644-379c09d7476c@github.com>
Message-ID: <bUPA8A5EWW7sQIdyCIQjVa-D6x5HwvjbQAp3IEf0_yE=.ca045fa9-3416-4b36-babe-743ae033780f@github.com>

On Wed, 18 Nov 2020 22:09:21 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
>> 
>> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
>> 
>> A CSR will be required for this PR.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exception message tweak

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/java/util/IllegalFormatArgumentIndexException.java line 66:

> 64: 
> 65:         if (index == Integer.MIN_VALUE) {
> 66:            return "Format argument index: (unrepresentable as int)";

Perhaps "(not representable as int)" is more readable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/516

From igraves at openjdk.java.net  Wed Nov 18 22:52:07 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 18 Nov 2020 22:52:07 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v11]
In-Reply-To: <bUPA8A5EWW7sQIdyCIQjVa-D6x5HwvjbQAp3IEf0_yE=.ca045fa9-3416-4b36-babe-743ae033780f@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <ZSEP18ohoQXkkjsifdw0ukalzVO06Es6Vg0LzzJ5b_c=.71ba4c7e-c7fb-4929-a644-379c09d7476c@github.com>
 <bUPA8A5EWW7sQIdyCIQjVa-D6x5HwvjbQAp3IEf0_yE=.ca045fa9-3416-4b36-babe-743ae033780f@github.com>
Message-ID: <ZP0_b9SkUkTnKI67GftkX5rGAuoE6_DM94y_GxfExwQ=.dbee8707-178d-4a7a-a2ee-285fe7b14db8@github.com>

On Wed, 18 Nov 2020 22:30:21 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Exception message tweak
>
> src/java.base/share/classes/java/util/IllegalFormatArgumentIndexException.java line 66:
> 
>> 64: 
>> 65:         if (index == Integer.MIN_VALUE) {
>> 66:            return "Format argument index: (unrepresentable as int)";
> 
> Perhaps "(not representable as int)" is more readable.

After reading it a few times, I agree.

-------------

PR: https://git.openjdk.java.net/jdk/pull/516

From igraves at openjdk.java.net  Wed Nov 18 22:57:19 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Wed, 18 Nov 2020 22:57:19 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v12]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <Jj6fTAhZBZIaJck5RK7i42sMaJnNKVdSNM6S57NUqUc=.817616d8-0984-4607-865c-c3bbfb4491d3@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  'unrepresentable' to 'not representable'

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/36e8d3a3..223282d4

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=10-11

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From rriggs at openjdk.java.net  Wed Nov 18 23:54:11 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 18 Nov 2020 23:54:11 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v12]
In-Reply-To: <Jj6fTAhZBZIaJck5RK7i42sMaJnNKVdSNM6S57NUqUc=.817616d8-0984-4607-865c-c3bbfb4491d3@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <Jj6fTAhZBZIaJck5RK7i42sMaJnNKVdSNM6S57NUqUc=.817616d8-0984-4607-865c-c3bbfb4491d3@github.com>
Message-ID: <EaNWdLa41Iw5eENmtgFHJEtO2uvLuoTUm6bYg-xGTcM=.8fed1135-0aac-4544-bf5c-c99fc1c6a29c@github.com>

On Wed, 18 Nov 2020 22:57:19 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
>> 
>> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
>> 
>> A CSR will be required for this PR.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   'unrepresentable' to 'not representable'

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/516

From redestad at openjdk.java.net  Thu Nov 19 00:12:04 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 19 Nov 2020 00:12:04 GMT
Subject: RFR: 8253299: Manifest bytes are read twice when verifying a
 signed JAR
In-Reply-To: <K2o1WH3ajvU5EwPLzo9Qc8jUSRmY5oM3c_VABTC7cBg=.0778a27f-d992-4f93-883c-8ca3a3d22b34@github.com>
References: <K2o1WH3ajvU5EwPLzo9Qc8jUSRmY5oM3c_VABTC7cBg=.0778a27f-d992-4f93-883c-8ca3a3d22b34@github.com>
Message-ID: <Vu3j6nyxwNlEru0gYc1Kv5OPehck3WAHHA-99L5FrbQ=.96bf75d3-4048-4353-9d20-d64bb7701451@github.com>

On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Small change to retrieve the raw bytes of manifest during verifying signed JAR.

This seems like a good optimization.

I think comparing the manifest name case insensitively might be preferable - e.g. using String.equalsIgnoreCase - but if the worst that can happen is that a non-conventionally cased is read twice then I think what you have here is good.

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1299

From brent.christian at oracle.com  Thu Nov 19 00:24:52 2020
From: brent.christian at oracle.com (Brent Christian)
Date: Wed, 18 Nov 2020 16:24:52 -0800
Subject: RFR: 8256480: Refactor ObjectInputStream field reader
 implementation
In-Reply-To: <57N_l5oDQywDYUYK-EH1Odb00ipNZxHTNg_NSzfx2Ww=.d11b14a5-8b9c-421e-a92d-cac8462b0f8e@github.com>
References: <57N_l5oDQywDYUYK-EH1Odb00ipNZxHTNg_NSzfx2Ww=.d11b14a5-8b9c-421e-a92d-cac8462b0f8e@github.com>
Message-ID: <698715fe-3425-89fd-ab6f-b5cfea80aec9@oracle.com>

Hi, Roger.

The change looks good.  I just noticed a couple small things:

2324             for (int i = 0; i < slots.length-1; i++) {
2325                 new FieldValues(slots[i].desc, true);

The slots[i].hasData check is no longer performed here.

2561             primValues = new byte[desc.getPrimDataSize()];
2562             objValues = new Object[desc.getNumObjFields()];

In defaultReadFields(), the arrays would remain null in the case of a 0 
from getPrimDataSize() or getNumObjFields().  In the new code, 0-length 
arrays are created.

Thanks,
-Brent

On 11/18/20 9:39 AM, Roger Riggs wrote:
> ObjectInputStream has nearly identical but separate implementations to read values from the stream.
> Both implementations read primitive and object values from the stream and return an object holding the values.
> OIS.readFields() uses the internal class GetFieldImpl while OIS.defaultReadObject and reading records uses the internal class FieldValues.
> The behavioral difference between the two is whether dependencies are tracked in the object handle table or not.
> 
> The classes are merged, retaining the internal FieldValues name and the behavior to track dependencies or not.
> The constructor is passed the class descriptor and flag to track or not; it reads and saves the values from the stream.
> The callers are updated to call the merge FieldValues methods.
> 
> There is no change in behavior; all current tests pass.
> 
> -------------
> 
> Commit messages:
>   - 8256480: Refactor ObjectInputStream field reader implementation
> 
> Changes: https://git.openjdk.java.net/jdk/pull/1296/files
>   Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1296&range=00
>    Issue: https://bugs.openjdk.java.net/browse/JDK-8256480
>    Stats: 157 lines in 1 file changed: 26 ins; 78 del; 53 mod
>    Patch: https://git.openjdk.java.net/jdk/pull/1296.diff
>    Fetch: git fetch https://git.openjdk.java.net/jdk pull/1296/head:pull/1296
> 
> PR: https://git.openjdk.java.net/jdk/pull/1296
> 

From ccheung at openjdk.java.net  Thu Nov 19 00:41:13 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 19 Nov 2020 00:41:13 GMT
Subject: RFR: 8256487: Handle disableEagerInitialization for archived lambda
 proxy classes
Message-ID: <H0u1_kznNSlnjVxMeZDprieQlaPLVo9tR_md-eMCzk8=.2bff07f5-39c6-47a9-a9ce-6092823e610f@github.com>

Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set.

This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically:

- remove the above workaround;

- capture the setting of the property in the archive header during CDS dump time;

- during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header.
If the values don't match, the archived lambda proxy class won't be used.

Tests:

- [x] ran all cds tests locally on linux-x64

- [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64

- [x] mach5 tiers 1,2,3 (in progress)

-------------

Commit messages:
 - Merge branch 'master' into 8256487-disableEagerInit
 - 8256487: Handle disableEagerInitialization for archived lambda proxy classes

Changes: https://git.openjdk.java.net/jdk/pull/1301/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1301&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256487
  Stats: 263 lines in 15 files changed: 246 ins; 0 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1301.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1301/head:pull/1301

PR: https://git.openjdk.java.net/jdk/pull/1301

From smarks at openjdk.java.net  Thu Nov 19 00:42:05 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 19 Nov 2020 00:42:05 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v12]
In-Reply-To: <Jj6fTAhZBZIaJck5RK7i42sMaJnNKVdSNM6S57NUqUc=.817616d8-0984-4607-865c-c3bbfb4491d3@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <Jj6fTAhZBZIaJck5RK7i42sMaJnNKVdSNM6S57NUqUc=.817616d8-0984-4607-865c-c3bbfb4491d3@github.com>
Message-ID: <MhhKG6zR1D8bKDbkRkWVPDF2mQSqy7yzzBGugCICyMg=.a70133fe-2911-435e-84d7-b49ae786a9a1@github.com>

On Wed, 18 Nov 2020 22:57:19 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
>> 
>> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
>> 
>> A CSR will be required for this PR.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   'unrepresentable' to 'not representable'

Marked as reviewed by smarks (Reviewer).

test/jdk/java/util/IllegalFormatException/TestFormatSpecifierBounds.java line 48:

> 46:             String r = String.format("%2147483648$s", "A", "B");
> 47:         });
> 48:         //assertEquals(e.getMessage(), "Illegal format argument index = " + Integer.MIN_VALUE);

Extraneous comment?

-------------

PR: https://git.openjdk.java.net/jdk/pull/516

From redestad at openjdk.java.net  Thu Nov 19 00:54:02 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 19 Nov 2020 00:54:02 GMT
Subject: RFR: 8256487: Handle disableEagerInitialization for archived
 lambda proxy classes
In-Reply-To: <H0u1_kznNSlnjVxMeZDprieQlaPLVo9tR_md-eMCzk8=.2bff07f5-39c6-47a9-a9ce-6092823e610f@github.com>
References: <H0u1_kznNSlnjVxMeZDprieQlaPLVo9tR_md-eMCzk8=.2bff07f5-39c6-47a9-a9ce-6092823e610f@github.com>
Message-ID: <aNddz6pf9Cs5D0M4dooQIy1Ucu8p8wDSl7kniMVr9Zo=.d0c0bf0a-9906-4c26-922d-662e5aa3462a@github.com>

On Wed, 18 Nov 2020 23:58:25 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set.
> 
> This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically:
> 
> - remove the above workaround;
> 
> - capture the setting of the property in the archive header during CDS dump time;
> 
> - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header.
> If the values don't match, the archived lambda proxy class won't be used.
> 
> Tests:
> 
> - [x] ran all cds tests locally on linux-x64
> 
> - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64
> 
> - [x] mach5 tiers 1,2,3 (in progress)

I'm not sure if this is a good idea, TBH. The disableEagerInitialization setting is for native-image pre-generation purposes and the less CDS cares about it, the better. I'd prefer it if there's no trace of the property in hotspot sources.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1301

From igraves at openjdk.java.net  Thu Nov 19 00:58:21 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 19 Nov 2020 00:58:21 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v13]
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <5IpbSrdcuKa4kWC2OEozS7TkcDl_UrQ23ypTugtXWvw=.5e8f3c17-337d-4e73-8901-3480b852763c@github.com>

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

Ian Graves has updated the pull request incrementally with one additional commit since the last revision:

  Comment cleanup

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/516/files
  - new: https://git.openjdk.java.net/jdk/pull/516/files/223282d4..78fc8176

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=12
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=516&range=11-12

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/516.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/516/head:pull/516

PR: https://git.openjdk.java.net/jdk/pull/516

From igraves at openjdk.java.net  Thu Nov 19 00:58:22 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 19 Nov 2020 00:58:22 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v12]
In-Reply-To: <MhhKG6zR1D8bKDbkRkWVPDF2mQSqy7yzzBGugCICyMg=.a70133fe-2911-435e-84d7-b49ae786a9a1@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <Jj6fTAhZBZIaJck5RK7i42sMaJnNKVdSNM6S57NUqUc=.817616d8-0984-4607-865c-c3bbfb4491d3@github.com>
 <MhhKG6zR1D8bKDbkRkWVPDF2mQSqy7yzzBGugCICyMg=.a70133fe-2911-435e-84d7-b49ae786a9a1@github.com>
Message-ID: <A1yptvYVd54saLXVfpc_EjmqbWHTovTUEL_Q9fKKO7E=.48ff913a-dce1-4c82-bcf2-51a3834ebe8f@github.com>

On Thu, 19 Nov 2020 00:38:49 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   'unrepresentable' to 'not representable'
>
> test/jdk/java/util/IllegalFormatException/TestFormatSpecifierBounds.java line 48:
> 
>> 46:             String r = String.format("%2147483648$s", "A", "B");
>> 47:         });
>> 48:         //assertEquals(e.getMessage(), "Illegal format argument index = " + Integer.MIN_VALUE);
> 
> Extraneous comment?

So it would seem!

-------------

PR: https://git.openjdk.java.net/jdk/pull/516

From psandoz at openjdk.java.net  Thu Nov 19 01:14:09 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 19 Nov 2020 01:14:09 GMT
Subject: RFR: 8256581: Refactor vector conversion tests
Message-ID: <u9WOXnJu8Mj8ePWiElv4At4GnQt6PBjq3Hmxlni7KhE=.bf8b984f-69bd-4318-87d6-3af253e67021@github.com>

Refactor the vector conversions tests to improve performance and reduce explicit test methods (using data providers).

-------------

Commit messages:
 - 8256581: Refactor vector conversion tests

Changes: https://git.openjdk.java.net/jdk/pull/1302/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1302&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256581
  Stats: 37231 lines in 6 files changed: 212 ins; 36768 del; 251 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1302/head:pull/1302

PR: https://git.openjdk.java.net/jdk/pull/1302

From almatvee at openjdk.java.net  Thu Nov 19 01:15:02 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 19 Nov 2020 01:15:02 GMT
Subject: RFR: 8227400: Adjust jib profiles to make 3rd party tools for
 creating installers available on Mach5 test machines
In-Reply-To: <_GZPUzt_Q7AQdwekL4jTnkXUx8XmgaQA7iA_fa8L7Jo=.5c33486c-3220-4364-9586-e9be3b66f424@github.com>
References: <_GZPUzt_Q7AQdwekL4jTnkXUx8XmgaQA7iA_fa8L7Jo=.5c33486c-3220-4364-9586-e9be3b66f424@github.com>
Message-ID: <1zcRhX7xx4JPKOhIcKC_w_TIMryvd0LwmPTnIijoWfU=.5d7e59b7-1dee-4dd5-855f-ebf6bfb9772f@github.com>

On Wed, 18 Nov 2020 21:57:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix test failures. They didn't fail in Mach5 test runs as WiX was not available on test machines and these tests were not executed.

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1298

From almatvee at openjdk.java.net  Thu Nov 19 01:25:06 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 19 Nov 2020 01:25:06 GMT
Subject: RFR: JDK-8256475: Fix Behavior when Installer name differs from
 =?UTF-8?B?YXBwbGljYXRpb+KApg==?=
In-Reply-To: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
References: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
Message-ID: <g7wVr2MeXeHjxOfOFengz5HFJPJlh9gqLA1bdFSt0bo=.3c272377-cf21-4932-be22-8da0364d1725@github.com>

On Wed, 18 Nov 2020 22:17:07 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> ?n name.

src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinMsiBundler.java line 312:

> 310:         Path appDir;
> 311:         if (appName == null) {
> 312:             // this can only happen when no name is given and using forign app-image

forign -> foreign

test/jdk/tools/jpackage/share/MultiNameTwoPhaseTest.java line 34:

> 32: 
> 33: /**
> 34:  */

Needs description for test.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1300

From lancea at openjdk.java.net  Thu Nov 19 01:25:04 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 19 Nov 2020 01:25:04 GMT
Subject: RFR: 8253299: Manifest bytes are read twice when verifying a
 signed JAR
In-Reply-To: <K2o1WH3ajvU5EwPLzo9Qc8jUSRmY5oM3c_VABTC7cBg=.0778a27f-d992-4f93-883c-8ca3a3d22b34@github.com>
References: <K2o1WH3ajvU5EwPLzo9Qc8jUSRmY5oM3c_VABTC7cBg=.0778a27f-d992-4f93-883c-8ca3a3d22b34@github.com>
Message-ID: <6vja1mKMTZeMwBvOj8JPIUY7CzUKl-xzVx35_6Bp84Y=.55639475-6a09-4dc4-8cc5-03c72b874fc7@github.com>

On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Small change to retrieve the raw bytes of manifest during verifying signed JAR.

The changes looks good.  I am assuming that we do not need an additional test for this and if so, please add a noreg label such as noreg-trivial to the bug

-------------

PR: https://git.openjdk.java.net/jdk/pull/1299

From poonam at openjdk.java.net  Thu Nov 19 01:27:10 2020
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 19 Nov 2020 01:27:10 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to UncheckedIOException
 while initializing cgroupv1 subsystem
Message-ID: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>

Hi,

Please review this simple change that catches UncheckedIOException that can occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the system, or if there is an interrupt while these are being read.

Testing: Tier1, Tier2 and Tier3.

Thanks,
Poonam

-------------

Commit messages:
 - 8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem

Changes: https://git.openjdk.java.net/jdk/pull/1303/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1303&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255908
  Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1303.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1303/head:pull/1303

PR: https://git.openjdk.java.net/jdk/pull/1303

From joehw at openjdk.java.net  Thu Nov 19 01:42:08 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Thu, 19 Nov 2020 01:42:08 GMT
Subject: RFR: 8251317: Support for CLDR version 38
In-Reply-To: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
References: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
Message-ID: <i2kgDC11e8F9RUZ4dOPkIibZ5leKg1Fb95WqfhJ8Py0=.9cbbf365-4e3b-4f18-8eb2-7cc31f2678f3@github.com>

On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes for upgrading the CLDR data to version 38. The vast majority of the changes are simply the changes in CLDR upstream, and others are mainly test changes due to the locale data change.

Looks good to me.

-------------

Marked as reviewed by joehw (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1279

From ccheung at openjdk.java.net  Thu Nov 19 02:12:02 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Thu, 19 Nov 2020 02:12:02 GMT
Subject: RFR: 8256487: Handle disableEagerInitialization for archived
 lambda proxy classes
In-Reply-To: <aNddz6pf9Cs5D0M4dooQIy1Ucu8p8wDSl7kniMVr9Zo=.d0c0bf0a-9906-4c26-922d-662e5aa3462a@github.com>
References: <H0u1_kznNSlnjVxMeZDprieQlaPLVo9tR_md-eMCzk8=.2bff07f5-39c6-47a9-a9ce-6092823e610f@github.com>
 <aNddz6pf9Cs5D0M4dooQIy1Ucu8p8wDSl7kniMVr9Zo=.d0c0bf0a-9906-4c26-922d-662e5aa3462a@github.com>
Message-ID: <2HAKrvsORLsNHOY10PyQ395snpigQ7t0ZhAKUVIoPlk=.0540d08a-e46a-4e80-9719-4f16acc943d2@github.com>

On Thu, 19 Nov 2020 00:50:52 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set.
>> 
>> This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically:
>> 
>> - remove the above workaround;
>> 
>> - capture the setting of the property in the archive header during CDS dump time;
>> 
>> - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header.
>> If the values don't match, the archived lambda proxy class won't be used.
>> 
>> Tests:
>> 
>> - [x] ran all cds tests locally on linux-x64
>> 
>> - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64
>> 
>> - [x] mach5 tiers 1,2,3 (in progress)
>
> I'm not sure if this is a good idea, TBH. The disableEagerInitialization setting is for native-image pre-generation purposes and the less CDS cares about it, the better. I'd prefer it if there's no trace of the property in hotspot sources.

Hi Claes,

Thanks for taking a look.

So should I keep the following `!initialize` check in LambdaProxyClassArchive?
109         if (!loadedByBuiltinLoader(caller) || !initialize ||
110             !CDS.isSharingEnabled() || isSerializable || markerInterfaces.length > 0 || additionalBridges.length > 0)
111             return null;
If we keep the above code, I think we don't need to pass the `initialize` to `findFromArchive` and eventually to `JVM_LookupLambdaProxyClassFromArchive`.

Let me know if the above is what you have in mind?

thanks,
Calvin

-------------

PR: https://git.openjdk.java.net/jdk/pull/1301

From smarks at openjdk.java.net  Thu Nov 19 03:49:11 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 19 Nov 2020 03:49:11 GMT
Subject: RFR: 8037384: Fix wording in Javadoc of java.io.Serializable
Message-ID: <j51neqpaI-7jIch45IbUQPgl9jpbAETXuTNOviNlNDs=.334da5a4-f082-46bd-aedc-56c2f18358a1@github.com>

8231547: Serializable class doc should link to serialization specification

Rewrite a couple confusing sentences in the Serializable class doc. This does affect normative text, but the edits are primarily to focus and clarify the text, not to make any semantic changes. Thus, a CSR request shouldn't be required for this change.

Also add and adjust some links and link markup to the Java Object Serialization Specification.

-------------

Commit messages:
 - 8037384: Fix wording in Javadoc of java.io.Serializable

Changes: https://git.openjdk.java.net/jdk/pull/1306/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1306&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8037384
  Stats: 27 lines in 5 files changed: 5 ins; 1 del; 21 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1306.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1306/head:pull/1306

PR: https://git.openjdk.java.net/jdk/pull/1306

From sviswanathan at openjdk.java.net  Thu Nov 19 04:05:13 2020
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 19 Nov 2020 04:05:13 GMT
Subject: RFR: 8256585: Remove in-place conversion vector operators from Vector
 API
Message-ID: <DbLEmx1uzM8W8p9NVSgbFlAiYsKrcNAPL_BSj-K0zVI=.0b0e9229-db39-48ef-b904-e3db4bce71cc@github.com>

Remove partially implemented in-place conversion vector operators from Vector API:
   ofNarrowing, ofWidening, INPLACE_XXX

-------------

Commit messages:
 - 8256585: Remove in-place conversion vector operators from Vector API

Changes: https://git.openjdk.java.net/jdk/pull/1305/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1305&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256585
  Stats: 121 lines in 1 file changed: 0 ins; 118 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1305.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1305/head:pull/1305

PR: https://git.openjdk.java.net/jdk/pull/1305

From jvernee at openjdk.java.net  Thu Nov 19 11:11:03 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 19 Nov 2020 11:11:03 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v4]
In-Reply-To: <tKPyoN5O290X_W3n2DF1jvunO0YBoyNnoT5jXjmsNc0=.ecc67352-e2ef-4408-9ac1-e5e90a345424@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <tKPyoN5O290X_W3n2DF1jvunO0YBoyNnoT5jXjmsNc0=.ecc67352-e2ef-4408-9ac1-e5e90a345424@github.com>
Message-ID: <K9VUz-ZEbZvwn9hVtg-BpsxJBsDxf1hKTSyvhFgdxrA=.4f06ae1e-c5e6-4231-ae86-1a0ba69c3431@github.com>

On Wed, 18 Nov 2020 00:50:22 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects
>> be shared between a hidden class and other classes.  A hidden class can load
>> these live objects as dynamically-computed constants via this API.
>> 
>> Specdiff
>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
>> 
>> With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass`
>> will be deprecated for removal.  Existing libraries should replace their
>> calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass`
>> or `Lookup::defineHiddenClassWithClassData`.
>> 
>> This patch also updates the implementation of lambda meta factory and
>> `MemoryAccessVarHandleGenerator` to use class data.   No performance difference
>> observed in the jdk.incubator.foreign microbenchmarks.   A side note: 
>> `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of 
>> JDK-8254162 but it helps validating the class data support.
>> 
>> Background
>> ----------
>> 
>> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
>> "Constant-pool patching" in the "Risks and Assumption" section.
>> 
>> A VM-anonymous class can be defined with its constant-pool entries already
>> resolved to concrete values. This allows critical constants to be shared
>> between a VM-anonymous class and the language runtime that defines it, and
>> between multiple VM-anonymous classes. For example, a language runtime will
>> often have `MethodHandle` objects in its address space that would be useful
>> to newly-defined VM-anonymous classes. Instead of the runtime serializing
>> the objects to constant-pool entries in VM-anonymous classes and then
>> generating bytecode in those classes to laboriously `ldc` the entries,
>> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
>> to its live objects. The relevant constant-pool entries in the newly-defined
>> VM-anonymous class are pre-linked to those objects, improving performance
>> and reducing footprint. In addition, this allows VM-anonymous classes to
>> refer to each other: Constant-pool entries in a class file are based on names.
>> They thus cannot refer to nameless VM-anonymous classes. A language runtime can,
>> however, easily track the live Class objects for its VM-anonymous classes and
>> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's
>> constant pool entries to other VM-anonymous classes.
>> 
>> This extends the hidden classes to allow live objects to be injected
>> in a hidden class and loaded them via condy.
>> 
>> Details
>> -------
>> 
>> A new `Lookup::defineHiddenClassWithClassData` API takes additional
>> `classData` argument compared to `Lookup::defineHiddenClass`.
>> Class data can be method handles, lookup objects, arbitrary user objects
>> or collections of all of the above.
>> 
>> This method behaves as if calling `Lookup::defineHiddenClass` to define
>> a hidden class with a private static unnamed field that is initialized
>> with `classData` at the first instruction of the class initializer.
>> 
>> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)` and
>> `MethodHandles::classDataAt(Lookup lookup, String name, Class<?> type, int index)`
>> are the bootstrap methods to load the class data of the given lookup's lookup class.
>> The hidden class will be initialized when `classData` method is called if
>> the hidden class has not been initialized.
>> 
>> For a class data containing more than one single element, libraries can
>> create their convenience method to load a single live object via condy.
>> 
>> Frameworks sometimes want to dynamically create a hidden class (HC) and add it
>> it the lookup class nest and have HC to carry secrets hidden from that nest.
>> In this case, frameworks should not to use private static finals (in the HCs
>> they spin) to hold secrets because a nestmate of HC may obtain access to
>> such a private static final and observe the framework's secret.  It should use
>> condy.  In addition, we need to differentiate if a lookup object is created from
>> the original lookup class or created from teleporting e.g. `Lookup::in`
>> and `MethodHandles::privateLookupIn`.
>> 
>> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
>> object is created by `MethodHandles::lookup` or by bootstrap method invocation.
>> The operations only apply to a Lookup object with original access are:
>>    - create method handles for caller-sensitve methods
>>    - obtain class data associated with the lookup class
>> 
>> No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which
>> ignores the ORIGINAL bit.
>> 
>> 
>> Compatibility Risks
>> -------------------
>> 
>> `Lookup::lookupModes` includes a new `ORIGINAL` bit.  Most lookup operations
>> ignore this original bit except creating method handles for caller-sensitive methods
>> that expects the lookup from the original lookup class.  Existing code  compares
>> the return value of `lookupModes` to be a fixed value may be impacted.   However
>> existing client has no need to expect a fixed value of lookup modes.
>> The incompatibility risk of this spec change is low.
>
> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix the name passed to condy calling classData

Left 2 minor comments on the new additions in line.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2148:

> 2146:          * (unlike private static fields that are accessible to nestmates).
> 2147:          * Care should be taken w.r.t. mutability for example when passing
> 2148:          * an array or other mutable structure through the class data.

I don't think it's necessarily clear _why_/_how_ care should be taken from this text. I suggest:
Suggestion:

         * Care should be taken w.r.t. mutability for example when passing
         * an array or other mutable structure through the class data. Such
         * a constant should not be mutated, as downstream consumers of
         * this constant, such as other constants, are not guaranteed to see
         * the updated value, depending on the timing of their resolution.

src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2150:

> 2148:          * an array or other mutable structure through the class data.
> 2149:          * If you use a {@code List}, it is a good practice to make it unmodifiable
> 2150:          * for example via {@link List#of List::of}.

Formal language.
Suggestion:

         * If a {@code List} is used, it is a good practice to make it unmodifiable
         * for example via {@link List#of List::of}.

-------------

Marked as reviewed by jvernee (Committer).

PR: https://git.openjdk.java.net/jdk/pull/1171

From herrick at openjdk.java.net  Thu Nov 19 13:56:03 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 19 Nov 2020 13:56:03 GMT
Subject: RFR: 8227400: Adjust jib profiles to make 3rd party tools for
 creating installers available on Mach5 test machines
In-Reply-To: <_GZPUzt_Q7AQdwekL4jTnkXUx8XmgaQA7iA_fa8L7Jo=.5c33486c-3220-4364-9586-e9be3b66f424@github.com>
References: <_GZPUzt_Q7AQdwekL4jTnkXUx8XmgaQA7iA_fa8L7Jo=.5c33486c-3220-4364-9586-e9be3b66f424@github.com>
Message-ID: <nU6dmhg3wmV8jacbYfyeu6vfd6R7HTE1Ab-7wY2VyF0=.2f2e19dd-f659-4a4e-840e-ac5a9571acbc@github.com>

On Wed, 18 Nov 2020 21:57:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix test failures. They didn't fail in Mach5 test runs as WiX was not available on test machines and these tests were not executed.

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1298

From shade at openjdk.java.net  Thu Nov 19 14:40:04 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 19 Nov 2020 14:40:04 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem
In-Reply-To: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
Message-ID: <My0OMR31GHOnby6dlgs2TxmIXBiifyzA8B-W42bSDyk=.19db1d9a-1d24-4819-b333-8916ced95dd8@github.com>

On Thu, 19 Nov 2020 01:22:01 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> Hi,
> 
> Please review this simple change that catches UncheckedIOException that can occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the system, or if there is an interrupt while these are being read.
> 
> Testing: Tier1, Tier2 and Tier3.
> 
> Thanks,
> Poonam

Changes requested by shade (Reviewer).

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java line 79:

> 77:                  .forEach(entry -> createSubSystemController(subsystem, entry));
> 78: 
> 79:         } catch (UncheckedIOException e) {

I am confused. `CgroupUtil.readFilePrivileged` unwraps `UncheckedIOException`, why this catch clause is needed? Is this because the cause might be `UncheckedIOException` itself? Might be easier to rewrap `UncheckedIOException` to just `IOException` in `CgroupUtil`.

src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java line 50:

> 48:             throw new InternalError(e.getCause());
> 49:         } catch (UncheckedIOException e) {
> 50:             throw e.getCause();

There are other reader methods in the same file, should this block be added to them as well?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1303

From ccleary at openjdk.java.net  Thu Nov 19 14:55:10 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Thu, 19 Nov 2020 14:55:10 GMT
Subject: RFR: 8256183: InputStream.skipNBytes is missing @since 12
Message-ID: <sOJHtr9tnZp1n5StjYHRlpgvP3q3mNq9G-6bZarJL7s=.67302c78-5e9f-4b7f-b3be-d9a165a09684@github.com>

InputStream.skipNBytes is missing `@since 12` tag which was not added during the review of [JDK-6516099](https://bugs.openjdk.java.net/browse/JDK-6516099).

This small fix adds the `@since` tag to InputStream.skipNBytes

-------------

Commit messages:
 - 8256183: InputStream.skipNBytes is missing @since 12

Changes: https://git.openjdk.java.net/jdk/pull/1314/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1314&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256183
  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1314.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1314/head:pull/1314

PR: https://git.openjdk.java.net/jdk/pull/1314

From ccleary at openjdk.java.net  Thu Nov 19 14:56:10 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Thu, 19 Nov 2020 14:56:10 GMT
Subject: RFR: 8256154: Some TestNG tests require default constructors
Message-ID: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>

In TestNG 7, it is a requirement that TestNG is able to create a Test object using a default constructor. 

This simple fix addresses two such classes so that this requirement is satisfied by inserting default construtors. Example: `public GetPackages() { ... }`

test/jdk/java/lang/Package/GetPackages.java
test/jdk/java/lang/StackWalker/Basic.java

-------------

Commit messages:
 - 8256154: Some TestNG tests require default constructors

Changes: https://git.openjdk.java.net/jdk/pull/1317/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1317&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256154
  Stats: 13 lines in 2 files changed: 11 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1317.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1317/head:pull/1317

PR: https://git.openjdk.java.net/jdk/pull/1317

From poonam at openjdk.java.net  Thu Nov 19 15:04:05 2020
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 19 Nov 2020 15:04:05 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem
In-Reply-To: <My0OMR31GHOnby6dlgs2TxmIXBiifyzA8B-W42bSDyk=.19db1d9a-1d24-4819-b333-8916ced95dd8@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
 <My0OMR31GHOnby6dlgs2TxmIXBiifyzA8B-W42bSDyk=.19db1d9a-1d24-4819-b333-8916ced95dd8@github.com>
Message-ID: <-8nFRuUb3mu0qHNPDJjBNN1LTxOkum4PO1kuEI-DIqU=.f37ed25c-ff43-4e88-8a80-46395a86d91f@github.com>

On Thu, 19 Nov 2020 14:36:27 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this simple change that catches UncheckedIOException that can occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the system, or if there is an interrupt while these are being read.
>> 
>> Testing: Tier1, Tier2 and Tier3.
>> 
>> Thanks,
>> Poonam
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java line 79:
> 
>> 77:                  .forEach(entry -> createSubSystemController(subsystem, entry));
>> 78: 
>> 79:         } catch (UncheckedIOException e) {
> 
> I am confused. `CgroupUtil.readFilePrivileged` unwraps `UncheckedIOException`, why this catch clause is needed? Is this because the cause might be `UncheckedIOException` itself? Might be easier to rewrap `UncheckedIOException` to just `IOException` in `CgroupUtil`.

It is there to catch the UncheckedIOException that could get thrown while processing each line and entry. Example of this exception encountered with JDK 8u.

Caused by: java.io.UncheckedIOException:
java.nio.channels.ClosedByInterruptException
at java.io.BufferedReader$1.hasNext(BufferedReader.java:574)
at java.util.Iterator.forEachRemaining(Iterator.java:115)
at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
at jdk.internal.platform.cgroupv1.Metrics.initContainerSubSystems(Metrics.java:81)
at jdk.internal.platform.cgroupv1.Metrics.<clinit>(Metrics.java:51)... 41 more

Caused by: java.nio.channels.ClosedByInterruptException
at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:164)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:65)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109)
at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
at java.io.InputStreamReader.read(InputStreamReader.java:184)
at java.io.BufferedReader.fill(BufferedReader.java:161)
at java.io.BufferedReader.readLine(BufferedReader.java:324)
at java.io.BufferedReader.readLine(BufferedReader.java:389)
at java.io.BufferedReader$1.hasNext(BufferedReader.java:571)

-------------

PR: https://git.openjdk.java.net/jdk/pull/1303

From dfuchs at openjdk.java.net  Thu Nov 19 15:04:05 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 19 Nov 2020 15:04:05 GMT
Subject: RFR: 8256183: InputStream.skipNBytes is missing @since 12
In-Reply-To: <sOJHtr9tnZp1n5StjYHRlpgvP3q3mNq9G-6bZarJL7s=.67302c78-5e9f-4b7f-b3be-d9a165a09684@github.com>
References: <sOJHtr9tnZp1n5StjYHRlpgvP3q3mNq9G-6bZarJL7s=.67302c78-5e9f-4b7f-b3be-d9a165a09684@github.com>
Message-ID: <-X3cC3Ms4ToSDc1eax8xm_mRp8k2-zGiMo0fgCQTx9E=.5d6e529c-491d-40ab-a213-ac9eceb225b3@github.com>

On Thu, 19 Nov 2020 12:35:04 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> InputStream.skipNBytes is missing `@since 12` tag which was not added during the review of [JDK-6516099](https://bugs.openjdk.java.net/browse/JDK-6516099).
> 
> This small fix adds the `@since` tag to InputStream.skipNBytes

Marked as reviewed by dfuchs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1314

From dfuchs at openjdk.java.net  Thu Nov 19 15:12:01 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 19 Nov 2020 15:12:01 GMT
Subject: RFR: 8256154: Some TestNG tests require default constructors
In-Reply-To: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
References: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
Message-ID: <j38LRrH7R81qppkPHFD0Wx4cnV71OACVDf0zcgV1ikA=.a0911f00-6e28-4ddd-9d0b-18ef735d4f75@github.com>

On Thu, 19 Nov 2020 13:50:30 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> In TestNG 7, it is a requirement that TestNG is able to create a Test object using a default constructor. 
> 
> This simple fix addresses two such classes so that this requirement is satisfied by inserting default construtors. Example: `public GetPackages() { ... }`
> 
> test/jdk/java/lang/Package/GetPackages.java
> test/jdk/java/lang/StackWalker/Basic.java

Hi Conor,

Were you able to verify that the two tests passed properly (and non trivially) with both the current version of TestNG as well as the new version?

best regards,

-- daniel

-------------

PR: https://git.openjdk.java.net/jdk/pull/1317

From lancea at openjdk.java.net  Thu Nov 19 15:48:03 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 19 Nov 2020 15:48:03 GMT
Subject: RFR: 8256183: InputStream.skipNBytes is missing @since 12
In-Reply-To: <sOJHtr9tnZp1n5StjYHRlpgvP3q3mNq9G-6bZarJL7s=.67302c78-5e9f-4b7f-b3be-d9a165a09684@github.com>
References: <sOJHtr9tnZp1n5StjYHRlpgvP3q3mNq9G-6bZarJL7s=.67302c78-5e9f-4b7f-b3be-d9a165a09684@github.com>
Message-ID: <CnyZ-6CBrwpPMs7k77NAHPDqUAbbxtNqUPYcjuO_8lk=.3dff4f12-fc17-457f-993f-fd571c182dca@github.com>

On Thu, 19 Nov 2020 12:35:04 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> InputStream.skipNBytes is missing `@since 12` tag which was not added during the review of [JDK-6516099](https://bugs.openjdk.java.net/browse/JDK-6516099).
> 
> This small fix adds the `@since` tag to InputStream.skipNBytes

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1314

From lancea at openjdk.java.net  Thu Nov 19 16:07:06 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 19 Nov 2020 16:07:06 GMT
Subject: RFR: 8256154: Some TestNG tests require default constructors
In-Reply-To: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
References: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
Message-ID: <a9qdJkFWZEQJ0119IvnStmBuu3VFDjmGm2ndTGFlL1I=.a11cbaba-fdc6-4cee-9677-e5aceba3803e@github.com>

On Thu, 19 Nov 2020 13:50:30 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> In TestNG 7, it is a requirement that TestNG is able to create a Test object using a default constructor. 
> 
> This simple fix addresses two such classes so that this requirement is satisfied by inserting default construtors. Example: `public GetPackages() { ... }`
> 
> test/jdk/java/lang/Package/GetPackages.java
> test/jdk/java/lang/StackWalker/Basic.java

test/jdk/java/lang/StackWalker/Basic.java line 116:

> 114:     /** For TestNG */
> 115:     public Basic() {
> 116:         depth = 0;

Is the assignment really ended here?  I only see:

Basic test = new Basic(depth[0]);

So I would assume you would be fine with an empty constructor?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1317

From Roger.Riggs at oracle.com  Thu Nov 19 16:10:01 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 19 Nov 2020 11:10:01 -0500
Subject: RFR: 8256480: Refactor ObjectInputStream field reader
 implementation
In-Reply-To: <698715fe-3425-89fd-ab6f-b5cfea80aec9@oracle.com>
References: <57N_l5oDQywDYUYK-EH1Odb00ipNZxHTNg_NSzfx2Ww=.d11b14a5-8b9c-421e-a92d-cac8462b0f8e@github.com>
 <698715fe-3425-89fd-ab6f-b5cfea80aec9@oracle.com>
Message-ID: <56bbb9a9-c717-082f-6078-739210c2b8a0@oracle.com>

Hi Brent,

Thanks for the review

On 11/18/20 7:24 PM, Brent Christian wrote:
> Hi, Roger.
>
> The change looks good.? I just noticed a couple small things:
>
> 2324???????????? for (int i = 0; i < slots.length-1; i++) {
> 2325???????????????? new FieldValues(slots[i].desc, true);
>
> The slots[i].hasData check is no longer performed here.

I'll restore that optimization; Without the optimization a FieldValues 
object would be created
with neither primitive or object values only to be discarded.
>
> 2561???????????? primValues = new byte[desc.getPrimDataSize()];
> 2562???????????? objValues = new Object[desc.getNumObjFields()];
>
> In defaultReadFields(), the arrays would remain null in the case of a 
> 0 from getPrimDataSize() or getNumObjFields().? In the new code, 
> 0-length arrays are created.
True, the implementations differ on this point.
Retaining the zero length arrays might be slightly safer (no null checks 
required)
but there should be no references to the arrays in either case and 
allocating new arrays
is a bit of a waste.

I'll restore the unused = null datapaths; and re-test.
It will also slightly streamline the case where are there are no 
primitives or no objects.

Thanks, Roger

>
> Thanks,
> -Brent
>
> On 11/18/20 9:39 AM, Roger Riggs wrote:
>> ObjectInputStream has nearly identical but separate implementations 
>> to read values from the stream.
>> Both implementations read primitive and object values from the stream 
>> and return an object holding the values.
>> OIS.readFields() uses the internal class GetFieldImpl while 
>> OIS.defaultReadObject and reading records uses the internal class 
>> FieldValues.
>> The behavioral difference between the two is whether dependencies are 
>> tracked in the object handle table or not.
>>
>> The classes are merged, retaining the internal FieldValues name and 
>> the behavior to track dependencies or not.
>> The constructor is passed the class descriptor and flag to track or 
>> not; it reads and saves the values from the stream.
>> The callers are updated to call the merge FieldValues methods.
>>
>> There is no change in behavior; all current tests pass.
>>
>> -------------
>>
>> Commit messages:
>> ? - 8256480: Refactor ObjectInputStream field reader implementation
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/1296/files
>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1296&range=00
>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8256480
>> ?? Stats: 157 lines in 1 file changed: 26 ins; 78 del; 53 mod
>> ?? Patch: https://git.openjdk.java.net/jdk/pull/1296.diff
>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk 
>> pull/1296/head:pull/1296
>>
>> PR: https://git.openjdk.java.net/jdk/pull/1296
>>


From redestad at openjdk.java.net  Thu Nov 19 16:12:10 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Thu, 19 Nov 2020 16:12:10 GMT
Subject: RFR: 8256487: Handle disableEagerInitialization for archived
 lambda proxy classes
In-Reply-To: <2HAKrvsORLsNHOY10PyQ395snpigQ7t0ZhAKUVIoPlk=.0540d08a-e46a-4e80-9719-4f16acc943d2@github.com>
References: <H0u1_kznNSlnjVxMeZDprieQlaPLVo9tR_md-eMCzk8=.2bff07f5-39c6-47a9-a9ce-6092823e610f@github.com>
 <aNddz6pf9Cs5D0M4dooQIy1Ucu8p8wDSl7kniMVr9Zo=.d0c0bf0a-9906-4c26-922d-662e5aa3462a@github.com>
 <2HAKrvsORLsNHOY10PyQ395snpigQ7t0ZhAKUVIoPlk=.0540d08a-e46a-4e80-9719-4f16acc943d2@github.com>
Message-ID: <oqRXPyUXaTyJk12PhLQ7JYOfx_lCe-y047tFuVb_rKk=.14a27fb3-4f8d-4dc9-808b-d5e497f2b5cd@github.com>

On Thu, 19 Nov 2020 02:08:52 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

>> I'm not sure if this is a good idea, TBH. The disableEagerInitialization setting is for native-image pre-generation purposes and the less CDS cares about it, the better. I'd prefer it if there's no trace of the property in hotspot sources.
>
> Hi Claes,
> 
> Thanks for taking a look.
> 
> So should I keep the following `!initialize` check in LambdaProxyClassArchive?
> 109         if (!loadedByBuiltinLoader(caller) || !initialize ||
> 110             !CDS.isSharingEnabled() || isSerializable || markerInterfaces.length > 0 || additionalBridges.length > 0)
> 111             return null;
> If we keep the above code, I think we don't need to pass the `initialize` to `findFromArchive` and eventually to `JVM_LookupLambdaProxyClassFromArchive`.
> 
> Let me know if the above is what you have in mind?
> 
> thanks,
> Calvin

Right, I'd drop that argument - I would go further and suggest making calls to both `LambdaProxyClassArchive.register` and `LambdaProxyClassArchive.find` conditional on `disableEagerInitialization` being `false` to avoid any accidental mix-up and reduce complexity of these orthogonal features/concerns.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1301

From vlivanov at openjdk.java.net  Thu Nov 19 16:12:11 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 19 Nov 2020 16:12:11 GMT
Subject: RFR: 8256581: Refactor vector conversion tests
In-Reply-To: <u9WOXnJu8Mj8ePWiElv4At4GnQt6PBjq3Hmxlni7KhE=.bf8b984f-69bd-4318-87d6-3af253e67021@github.com>
References: <u9WOXnJu8Mj8ePWiElv4At4GnQt6PBjq3Hmxlni7KhE=.bf8b984f-69bd-4318-87d6-3af253e67021@github.com>
Message-ID: <YbWq91g74Rn0dvr9bDaVw1Oo6V1BqgEA5q_8b9laEck=.2e2088c7-53d5-4f8f-aff2-2c44187db295@github.com>

On Thu, 19 Nov 2020 01:07:12 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Refactor the vector conversions tests to improve performance and reduce explicit test methods (using data providers).

> +463, -37,019 

Impressive improvement, Paul! :-)

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1302

From dfuchs at openjdk.java.net  Thu Nov 19 16:39:06 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 19 Nov 2020 16:39:06 GMT
Subject: RFR: 8256154: Some TestNG tests require default constructors
In-Reply-To: <a9qdJkFWZEQJ0119IvnStmBuu3VFDjmGm2ndTGFlL1I=.a11cbaba-fdc6-4cee-9677-e5aceba3803e@github.com>
References: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
 <a9qdJkFWZEQJ0119IvnStmBuu3VFDjmGm2ndTGFlL1I=.a11cbaba-fdc6-4cee-9677-e5aceba3803e@github.com>
Message-ID: <l9_jB3QgFlof8hGMnFuVAq8j6Iq3s2NGhVuavSx2ZKc=.d007de65-3a00-4862-a9f1-5b55632f1877@github.com>

On Thu, 19 Nov 2020 15:56:59 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> In TestNG 7, it is a requirement that TestNG is able to create a Test object using a default constructor. 
>> 
>> This simple fix addresses two such classes so that this requirement is satisfied by inserting default construtors. Example: `public GetPackages() { ... }`
>> 
>> test/jdk/java/lang/Package/GetPackages.java
>> test/jdk/java/lang/StackWalker/Basic.java
>
> test/jdk/java/lang/StackWalker/Basic.java line 116:
> 
>> 114:     /** For TestNG */
>> 115:     public Basic() {
>> 116:         depth = 0;
> 
> Is the assignment really ended here?  I only see:
> 
> Basic test = new Basic(depth[0]);
> 
> So I would assume you would be fine with an empty constructor?

`depth` is `final`, so it needs to be assigned. but this could be replaced with `this(0)`

-------------

PR: https://git.openjdk.java.net/jdk/pull/1317

From poonam at openjdk.java.net  Thu Nov 19 16:44:12 2020
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 19 Nov 2020 16:44:12 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem
In-Reply-To: <My0OMR31GHOnby6dlgs2TxmIXBiifyzA8B-W42bSDyk=.19db1d9a-1d24-4819-b333-8916ced95dd8@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
 <My0OMR31GHOnby6dlgs2TxmIXBiifyzA8B-W42bSDyk=.19db1d9a-1d24-4819-b333-8916ced95dd8@github.com>
Message-ID: <xjaeJkbuftz8O2-tY8HCSFJqBbC4wXAELRnCfMmGugk=.30899b7a-4f62-448a-b5fb-6c1beb6d7489@github.com>

On Thu, 19 Nov 2020 14:36:53 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this simple change that catches UncheckedIOException that can occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the system, or if there is an interrupt while these are being read.
>> 
>> Testing: Tier1, Tier2 and Tier3.
>> 
>> Thanks,
>> Poonam
>
> src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java line 50:
> 
>> 48:             throw new InternalError(e.getCause());
>> 49:         } catch (UncheckedIOException e) {
>> 50:             throw e.getCause();
> 
> There are other reader methods in the same file, should this block be added to them as well?

This change takes care of the case when reading of files /proc/self/cgroup or /proc/self/mountinfo might fail due to some reason that can cause the initialization of cgroupv1 subsystem (initSubSystem) to fail. Looking at the usages of other reader methods, I think it makes sense to catch UncheckedIOException there as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1303

From lancea at openjdk.java.net  Thu Nov 19 16:48:06 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 19 Nov 2020 16:48:06 GMT
Subject: RFR: 8256154: Some TestNG tests require default constructors
In-Reply-To: <l9_jB3QgFlof8hGMnFuVAq8j6Iq3s2NGhVuavSx2ZKc=.d007de65-3a00-4862-a9f1-5b55632f1877@github.com>
References: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
 <a9qdJkFWZEQJ0119IvnStmBuu3VFDjmGm2ndTGFlL1I=.a11cbaba-fdc6-4cee-9677-e5aceba3803e@github.com>
 <l9_jB3QgFlof8hGMnFuVAq8j6Iq3s2NGhVuavSx2ZKc=.d007de65-3a00-4862-a9f1-5b55632f1877@github.com>
Message-ID: <Qp2XdY9vs_jdrRcH2cFmC9jYxTWpCWHJWPeb2nytpd0=.d316f2b3-25a8-4400-b160-bd8f7ee863ad@github.com>

On Thu, 19 Nov 2020 16:36:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> test/jdk/java/lang/StackWalker/Basic.java line 116:
>> 
>>> 114:     /** For TestNG */
>>> 115:     public Basic() {
>>> 116:         depth = 0;
>> 
>> Is the assignment really ended here?  I only see:
>> 
>> Basic test = new Basic(depth[0]);
>> 
>> So I would assume you would be fine with an empty constructor?
>
> `depth` is `final`, so it needs to be assigned. but this could be replaced with `this(0)`

Ah, missed the final on depth :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/1317

From herrick at openjdk.java.net  Thu Nov 19 16:49:23 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 19 Nov 2020 16:49:23 GMT
Subject: RFR: JDK-8256475: Fix Behavior when Installer name differs from
 =?UTF-8?B?YXBwbGljYXRpb+KApg==?= [v2]
In-Reply-To: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
References: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
Message-ID: <zMLv98wYmRbKiK03yMbdd_A0LFT9TwxK07CRARwrKBw=.c2d1f1dc-b0d0-456b-ab69-3bfc6b550015@github.com>

> ?n name.

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 69 additional commits since the last revision:

 - JDK-8256475: Fix Behavior when Installer name differs from application name.
 - Merge branch 'master' into JDK-8256475
 - 8221554: aarch64 cross-modifying code
   
   Reviewed-by: rehn, aph
 - 8255978: [windows] os::release_memory may not release the full range
   
   Reviewed-by: iklam, minqi
 - 8256375: AArch64: aarch64-asmtest.py may generate undefined register r18
   
   Reviewed-by: aph
 - 8252304: Seed an HttpRequest.Builder from an existing HttpRequest
   
   Co-authored-by: Chris Hegarty <chegar at openjdk.org>
   Reviewed-by: chegar, dfuchs, michaelm
 - 8256499: Zero: enable Epsilon GC
   
   Reviewed-by: rkennke, ihse
 - 8256552: Let ReplayCompiles set UseDebuggerErgo
   
   Reviewed-by: vlivanov, redestad
 - 8256172: Clean up CDS handling of i2i_entry
   
   Reviewed-by: minqi, ccheung
 - 8256178: Add RAII object for file lock
   
   Reviewed-by: dholmes, coleenp
 - ... and 59 more: https://git.openjdk.java.net/jdk/compare/f9b55367...2e044b91

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1300/files
  - new: https://git.openjdk.java.net/jdk/pull/1300/files/63b6631c..2e044b91

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1300&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1300&range=00-01

  Stats: 8778 lines in 311 files changed: 5399 ins; 1776 del; 1603 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1300.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1300/head:pull/1300

PR: https://git.openjdk.java.net/jdk/pull/1300

From mr at openjdk.java.net  Thu Nov 19 16:55:12 2020
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 19 Nov 2020 16:55:12 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals
 by Default
Message-ID: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>

Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396).
Alan Bateman is the original author; I?ve credited him in the commit metadata.
Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64.

-------------

Commit messages:
 - 8256299: Implement JEP 396: Strongly Encapsulate JDK Internals by Default

Changes: https://git.openjdk.java.net/jdk/pull/1324/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256299
  Stats: 161 lines in 6 files changed: 22 ins; 76 del; 63 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1324.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1324/head:pull/1324

PR: https://git.openjdk.java.net/jdk/pull/1324

From rriggs at openjdk.java.net  Thu Nov 19 16:56:06 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 19 Nov 2020 16:56:06 GMT
Subject: RFR: 8037384: Fix wording in Javadoc of java.io.Serializable
In-Reply-To: <j51neqpaI-7jIch45IbUQPgl9jpbAETXuTNOviNlNDs=.334da5a4-f082-46bd-aedc-56c2f18358a1@github.com>
References: <j51neqpaI-7jIch45IbUQPgl9jpbAETXuTNOviNlNDs=.334da5a4-f082-46bd-aedc-56c2f18358a1@github.com>
Message-ID: <KkXAI6iyif1vlmvLQbKttvZHEAa-PG5wfS3IcJdC_mY=.1399b871-5b25-40f7-8f18-720092015696@github.com>

On Thu, 19 Nov 2020 03:44:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> 8231547: Serializable class doc should link to serialization specification
> 
> Rewrite a couple confusing sentences in the Serializable class doc. This does affect normative text, but the edits are primarily to focus and clarify the text, not to make any semantic changes. Thus, a CSR request shouldn't be required for this change.
> 
> Also add and adjust some links and link markup to the Java Object Serialization Specification.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1306

From psandoz at openjdk.java.net  Thu Nov 19 17:01:04 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 19 Nov 2020 17:01:04 GMT
Subject: Integrated: 8256581: Refactor vector conversion tests
In-Reply-To: <u9WOXnJu8Mj8ePWiElv4At4GnQt6PBjq3Hmxlni7KhE=.bf8b984f-69bd-4318-87d6-3af253e67021@github.com>
References: <u9WOXnJu8Mj8ePWiElv4At4GnQt6PBjq3Hmxlni7KhE=.bf8b984f-69bd-4318-87d6-3af253e67021@github.com>
Message-ID: <dvCUrpljPvstsXT1PneWpqnC7AVWM95CQwTbrsGF_Ow=.af0df5ba-fe29-4f2c-b9bb-d7f6cd1a3c81@github.com>

On Thu, 19 Nov 2020 01:07:12 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Refactor the vector conversions tests to improve performance and reduce explicit test methods (using data providers).

This pull request has now been integrated.

Changeset: 580f22cc
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/580f22cc
Stats:     37231 lines in 6 files changed: 212 ins; 36768 del; 251 mod

8256581: Refactor vector conversion tests

Reviewed-by: vlivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/1302

From poonam at openjdk.java.net  Thu Nov 19 17:04:15 2020
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 19 Nov 2020 17:04:15 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem [v2]
In-Reply-To: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
Message-ID: <AyKrgbhx7vaTZAPxkWFm2v09xkgwNvI7k0uXOPQ491s=.ae331a7d-f4bd-43ff-8cb4-fca8b4c85231@github.com>

> Hi,
> 
> Please review this simple change that catches UncheckedIOException that can occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the system, or if there is an interrupt while these are being read.
> 
> Testing: Tier1, Tier2 and Tier3.
> 
> Thanks,
> Poonam

Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:

  Added UncheckedIOException catch blocks for cgroupv2 subsystem, and also for the rest of reader methods in CgroupUtil.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1303/files
  - new: https://git.openjdk.java.net/jdk/pull/1303/files/6c14c814..80799f29

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1303&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1303&range=00-01

  Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1303.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1303/head:pull/1303

PR: https://git.openjdk.java.net/jdk/pull/1303

From poonam at openjdk.java.net  Thu Nov 19 17:04:16 2020
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 19 Nov 2020 17:04:16 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem [v2]
In-Reply-To: <xjaeJkbuftz8O2-tY8HCSFJqBbC4wXAELRnCfMmGugk=.30899b7a-4f62-448a-b5fb-6c1beb6d7489@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
 <My0OMR31GHOnby6dlgs2TxmIXBiifyzA8B-W42bSDyk=.19db1d9a-1d24-4819-b333-8916ced95dd8@github.com>
 <xjaeJkbuftz8O2-tY8HCSFJqBbC4wXAELRnCfMmGugk=.30899b7a-4f62-448a-b5fb-6c1beb6d7489@github.com>
Message-ID: <R-bASiKOzhJLtfpuSHoiZr0HJgeOw9xMZP_yFyBdj6k=.491659a0-fcf1-4265-a48c-8ca061874590@github.com>

On Thu, 19 Nov 2020 16:41:07 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/CgroupUtil.java line 50:
>> 
>>> 48:             throw new InternalError(e.getCause());
>>> 49:         } catch (UncheckedIOException e) {
>>> 50:             throw e.getCause();
>> 
>> There are other reader methods in the same file, should this block be added to them as well?
>
> This change takes care of the case when reading of files /proc/self/cgroup or /proc/self/mountinfo might fail due to some reason that can cause the initialization of cgroupv1 subsystem (initSubSystem) to fail. Looking at the usages of other reader methods, I think it makes sense to catch UncheckedIOException there as well.

Updated the code changes, and added the catch blocks for the rest of the reader methods and also for the cgroupv2 subsystem.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1303

From alanb at openjdk.java.net  Thu Nov 19 17:07:05 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 19 Nov 2020 17:07:05 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default
In-Reply-To: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
Message-ID: <esG9vCl54Nz3gH6DqCIeJ4WpNpGnHgbofAYVdJCZfoE=.d3698a95-4d14-436b-8b1a-637c820cbcfb@github.com>

On Thu, 19 Nov 2020 16:49:30 GMT, Mark Reinhold <mr at openjdk.org> wrote:

> Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396).
> Alan Bateman is the original author; I?ve credited him in the commit metadata.
> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64.

test/lib-test/jdk/test/lib/hexdump/ASN1FormatterTest.java line 42:

> 40:  * @test
> 41:  * @summary ASN.1 formatting
> 42:  * @modules java.base/sun.security.util:open

Roger has since fixed the test via JDK-8255394 so it no longer requires this package to be open.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1324

From alanb at openjdk.java.net  Thu Nov 19 17:11:03 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 19 Nov 2020 17:11:03 GMT
Subject: RFR: 8253299: Manifest bytes are read twice when verifying a
 signed JAR
In-Reply-To: <K2o1WH3ajvU5EwPLzo9Qc8jUSRmY5oM3c_VABTC7cBg=.0778a27f-d992-4f93-883c-8ca3a3d22b34@github.com>
References: <K2o1WH3ajvU5EwPLzo9Qc8jUSRmY5oM3c_VABTC7cBg=.0778a27f-d992-4f93-883c-8ca3a3d22b34@github.com>
Message-ID: <5imglAfMavky8vzTpaXeov_LHVm_enaMB4zZaLmRbbU=.0241bc35-4f30-4323-be86-e12d7e6036d0@github.com>

On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Small change to retrieve the raw bytes of manifest during verifying signed JAR.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1299

From lancea at openjdk.java.net  Thu Nov 19 17:15:03 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 19 Nov 2020 17:15:03 GMT
Subject: RFR: 8253299: Manifest bytes are read twice when verifying a
 signed JAR
In-Reply-To: <K2o1WH3ajvU5EwPLzo9Qc8jUSRmY5oM3c_VABTC7cBg=.0778a27f-d992-4f93-883c-8ca3a3d22b34@github.com>
References: <K2o1WH3ajvU5EwPLzo9Qc8jUSRmY5oM3c_VABTC7cBg=.0778a27f-d992-4f93-883c-8ca3a3d22b34@github.com>
Message-ID: <zc8TkVOH1srIloPWCHAJWB6qrSxQmFhOAsDwae4JGYY=.82d943c8-ff0a-431a-aeae-e70499512a86@github.com>

On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Small change to retrieve the raw bytes of manifest during verifying signed JAR.

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1299

From chegar at openjdk.java.net  Thu Nov 19 17:14:05 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 19 Nov 2020 17:14:05 GMT
Subject: RFR: 8037384: Fix wording in Javadoc of java.io.Serializable
In-Reply-To: <j51neqpaI-7jIch45IbUQPgl9jpbAETXuTNOviNlNDs=.334da5a4-f082-46bd-aedc-56c2f18358a1@github.com>
References: <j51neqpaI-7jIch45IbUQPgl9jpbAETXuTNOviNlNDs=.334da5a4-f082-46bd-aedc-56c2f18358a1@github.com>
Message-ID: <ev_u8Y_HvkNzzjdGNLybtMGdAsQDLdISLOWPWKc3vD8=.211c9d61-cd29-4088-ae2a-8d934892da13@github.com>

On Thu, 19 Nov 2020 03:44:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> 8231547: Serializable class doc should link to serialization specification
> 
> Rewrite a couple confusing sentences in the Serializable class doc. This does affect normative text, but the edits are primarily to focus and clarify the text, not to make any semantic changes. Thus, a CSR request shouldn't be required for this change.
> 
> Also add and adjust some links and link markup to the Java Object Serialization Specification.

src/java.base/share/classes/java/io/Serializable.java line 48:

> 46:  * It is possible for subtypes of non-serializable classes to be serialized
> 47:  * and deserialized. During serialization, no data will be written for the
> 48:  * fields of non-serializable classes. During deserialization, the fields of

" fields of non-serializable classes" - this strictly means " fields of non-serializable SUPERclasses", right?

src/java.base/share/classes/java/io/Serializable.java line 49:

> 47:  * and deserialized. During serialization, no data will be written for the
> 48:  * fields of non-serializable classes. During deserialization, the fields of
> 49:  * non-serializable classes will be initialized using the no-arg constructor of

non-serializable SUPERclasses ..

src/java.base/share/classes/java/io/Serializable.java line 50:

> 48:  * fields of non-serializable classes. During deserialization, the fields of
> 49:  * non-serializable classes will be initialized using the no-arg constructor of
> 50:  * the class. This constructor must be accessible to the subclass that is being

.. of the first non-serializable superclass.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1306

From lancea at openjdk.java.net  Thu Nov 19 17:15:04 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 19 Nov 2020 17:15:04 GMT
Subject: RFR: 8253299: Manifest bytes are read twice when verifying a
 signed JAR
In-Reply-To: <5imglAfMavky8vzTpaXeov_LHVm_enaMB4zZaLmRbbU=.0241bc35-4f30-4323-be86-e12d7e6036d0@github.com>
References: <K2o1WH3ajvU5EwPLzo9Qc8jUSRmY5oM3c_VABTC7cBg=.0778a27f-d992-4f93-883c-8ca3a3d22b34@github.com>
 <5imglAfMavky8vzTpaXeov_LHVm_enaMB4zZaLmRbbU=.0241bc35-4f30-4323-be86-e12d7e6036d0@github.com>
Message-ID: <ZT6zrNvoBJncMxtnsR3Y3-VMeeNNNClqLwPzHR1U2XU=.dc94a1ac-86aa-4ea9-95a2-f79d14e365ce@github.com>

On Thu, 19 Nov 2020 17:08:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Small change to retrieve the raw bytes of manifest during verifying signed JAR.
>
> Marked as reviewed by alanb (Reviewer).

I can sponsor once you integrate

-------------

PR: https://git.openjdk.java.net/jdk/pull/1299

From mr at openjdk.java.net  Thu Nov 19 17:16:22 2020
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 19 Nov 2020 17:16:22 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v2]
In-Reply-To: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
Message-ID: <X-tT29dRiWaS394o3ilVhJdV0xKsZ_kwqOHhLs3wwW8=.76df07ec-25c5-44bf-a160-2a88a3cb6adf@github.com>

> Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396).
> Alan Bateman is the original author; I?ve credited him in the commit metadata.
> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64.

Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary @module :open from ASN1FormatterTest.java

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1324/files
  - new: https://git.openjdk.java.net/jdk/pull/1324/files/4c0e8887..baf34a19

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1324.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1324/head:pull/1324

PR: https://git.openjdk.java.net/jdk/pull/1324

From mr at openjdk.java.net  Thu Nov 19 17:16:23 2020
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 19 Nov 2020 17:16:23 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v2]
In-Reply-To: <esG9vCl54Nz3gH6DqCIeJ4WpNpGnHgbofAYVdJCZfoE=.d3698a95-4d14-436b-8b1a-637c820cbcfb@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
 <esG9vCl54Nz3gH6DqCIeJ4WpNpGnHgbofAYVdJCZfoE=.d3698a95-4d14-436b-8b1a-637c820cbcfb@github.com>
Message-ID: <W9-XQpJBcUGYgfXuA0oVDiYLbp3_SlzYsQV9M9M7iJ0=.be5c083a-557a-4a09-93fa-cfdf6798ece5@github.com>

On Thu, 19 Nov 2020 17:03:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary @module :open from ASN1FormatterTest.java
>
> test/lib-test/jdk/test/lib/hexdump/ASN1FormatterTest.java line 42:
> 
>> 40:  * @test
>> 41:  * @summary ASN.1 formatting
>> 42:  * @modules java.base/sun.security.util:open
> 
> Roger has since fixed the test via JDK-8255394 so it no longer requires this package to be open.

Thanks! I've removed that :open.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1324

From psandoz at openjdk.java.net  Thu Nov 19 17:21:05 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 19 Nov 2020 17:21:05 GMT
Subject: RFR: 8256585: Remove in-place conversion vector operators from
 Vector API
In-Reply-To: <DbLEmx1uzM8W8p9NVSgbFlAiYsKrcNAPL_BSj-K0zVI=.0b0e9229-db39-48ef-b904-e3db4bce71cc@github.com>
References: <DbLEmx1uzM8W8p9NVSgbFlAiYsKrcNAPL_BSj-K0zVI=.0b0e9229-db39-48ef-b904-e3db4bce71cc@github.com>
Message-ID: <r8oVNrwuVyDgbLaJFUXYWs_bK1b5QYZgk6jI5rIkTbg=.abe03f63-f073-4f3b-a885-9eaba6f0819d@github.com>

On Thu, 19 Nov 2020 03:26:20 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Remove partially implemented in-place conversion vector operators from Vector API:
>    ofNarrowing, ofWidening, INPLACE_XXX

The documentation `Vector.convert` and `Vector.convertShape` needs to be updated to remove specification of in-place conversions, as does the class documentation on `Vector`. A search for the term `in-place` should find the relevant locations.

-------------

Changes requested by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1305

From hchao at openjdk.java.net  Thu Nov 19 17:27:04 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 19 Nov 2020 17:27:04 GMT
Subject: RFR: 8253299: Manifest bytes are read twice when verifying a
 signed JAR
In-Reply-To: <zc8TkVOH1srIloPWCHAJWB6qrSxQmFhOAsDwae4JGYY=.82d943c8-ff0a-431a-aeae-e70499512a86@github.com>
References: <K2o1WH3ajvU5EwPLzo9Qc8jUSRmY5oM3c_VABTC7cBg=.0778a27f-d992-4f93-883c-8ca3a3d22b34@github.com>
 <zc8TkVOH1srIloPWCHAJWB6qrSxQmFhOAsDwae4JGYY=.82d943c8-ff0a-431a-aeae-e70499512a86@github.com>
Message-ID: <VDCXvPcRIhvD-LTnwMwOgmk33lJ5meyiVEuwP3wdZoQ=.22a46e12-82d4-4272-ab15-f6f4197dfa26@github.com>

On Thu, 19 Nov 2020 17:13:00 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Small change to retrieve the raw bytes of manifest during verifying signed JAR.
>
> Marked as reviewed by lancea (Reviewer).

Thank you all for the review. I added the noreg-trivial label to the bug.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1299

From hchao at openjdk.java.net  Thu Nov 19 17:27:04 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 19 Nov 2020 17:27:04 GMT
Subject: RFR: 8253299: Manifest bytes are read twice when verifying a
 signed JAR
In-Reply-To: <VDCXvPcRIhvD-LTnwMwOgmk33lJ5meyiVEuwP3wdZoQ=.22a46e12-82d4-4272-ab15-f6f4197dfa26@github.com>
References: <K2o1WH3ajvU5EwPLzo9Qc8jUSRmY5oM3c_VABTC7cBg=.0778a27f-d992-4f93-883c-8ca3a3d22b34@github.com>
 <zc8TkVOH1srIloPWCHAJWB6qrSxQmFhOAsDwae4JGYY=.82d943c8-ff0a-431a-aeae-e70499512a86@github.com>
 <VDCXvPcRIhvD-LTnwMwOgmk33lJ5meyiVEuwP3wdZoQ=.22a46e12-82d4-4272-ab15-f6f4197dfa26@github.com>
Message-ID: <yQjLcyrYxtP2jTqW_pRWtgpGXJkeEZVDxIRQi5aNu3k=.6863f692-2a1e-44b5-8583-36e8ae0dec0f@github.com>

On Thu, 19 Nov 2020 17:20:58 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

>> Marked as reviewed by lancea (Reviewer).
>
> Thank you all for the review. I added the noreg-trivial label to the bug.

Lance, I've entered /integrate. Thank you for sponsoring this!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1299

From hchao at openjdk.java.net  Thu Nov 19 17:27:05 2020
From: hchao at openjdk.java.net (Hai-May Chao)
Date: Thu, 19 Nov 2020 17:27:05 GMT
Subject: Integrated: 8253299: Manifest bytes are read twice when verifying a
 signed JAR
In-Reply-To: <K2o1WH3ajvU5EwPLzo9Qc8jUSRmY5oM3c_VABTC7cBg=.0778a27f-d992-4f93-883c-8ca3a3d22b34@github.com>
References: <K2o1WH3ajvU5EwPLzo9Qc8jUSRmY5oM3c_VABTC7cBg=.0778a27f-d992-4f93-883c-8ca3a3d22b34@github.com>
Message-ID: <BGAEcZxcZ1KM35rAI5p671qUkdUA5TW9N7UM2B4zKys=.ab00faf6-206d-460c-b427-b60a2bbb2503@github.com>

On Wed, 18 Nov 2020 21:59:01 GMT, Hai-May Chao <hchao at openjdk.org> wrote:

> Small change to retrieve the raw bytes of manifest during verifying signed JAR.

This pull request has now been integrated.

Changeset: 9bb82232
Author:    Hai-May Chao <hchao at openjdk.org>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9bb82232
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8253299: Manifest bytes are read twice when verifying a signed JAR

Reviewed-by: redestad, lancea, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1299

From asemenyuk at openjdk.java.net  Thu Nov 19 17:28:08 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 19 Nov 2020 17:28:08 GMT
Subject: Integrated: 8227400: Adjust jib profiles to make 3rd party tools for
 creating installers available on Mach5 test machines
In-Reply-To: <_GZPUzt_Q7AQdwekL4jTnkXUx8XmgaQA7iA_fa8L7Jo=.5c33486c-3220-4364-9586-e9be3b66f424@github.com>
References: <_GZPUzt_Q7AQdwekL4jTnkXUx8XmgaQA7iA_fa8L7Jo=.5c33486c-3220-4364-9586-e9be3b66f424@github.com>
Message-ID: <R3ApZGeUnWyu-Q-Jm3AM7g0dlg0QU4KAHhV59SiGbUc=.9dc175aa-91b1-4359-ad2f-b931a93e64ad@github.com>

On Wed, 18 Nov 2020 21:57:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix test failures. They didn't fail in Mach5 test runs as WiX was not available on test machines and these tests were not executed.

This pull request has now been integrated.

Changeset: 1718abae
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/1718abae
Stats:     21 lines in 4 files changed: 16 ins; 0 del; 5 mod

8227400: Adjust jib profiles to make 3rd party tools for creating installers available on Mach5 test machines

Reviewed-by: almatvee, herrick

-------------

PR: https://git.openjdk.java.net/jdk/pull/1298

From asemenyuk at openjdk.java.net  Thu Nov 19 17:30:13 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 19 Nov 2020 17:30:13 GMT
Subject: RFR: JDK-8256475: Fix Behavior when Installer name differs from
 =?UTF-8?B?YXBwbGljYXRpb+KApg==?= [v2]
In-Reply-To: <zMLv98wYmRbKiK03yMbdd_A0LFT9TwxK07CRARwrKBw=.c2d1f1dc-b0d0-456b-ab69-3bfc6b550015@github.com>
References: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
 <zMLv98wYmRbKiK03yMbdd_A0LFT9TwxK07CRARwrKBw=.c2d1f1dc-b0d0-456b-ab69-3bfc6b550015@github.com>
Message-ID: <2wmzSw-fDUvpPQuL_KxZhKMzFB4uwhUC5qjjSgO0U7c=.4f8ffc78-91f8-4999-b550-3d5326c76594@github.com>

On Thu, 19 Nov 2020 16:49:23 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> ?n name.
>
> 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 69 additional commits since the last revision:
> 
>  - JDK-8256475: Fix Behavior when Installer name differs from application name.
>  - Merge branch 'master' into JDK-8256475
>  - 8221554: aarch64 cross-modifying code
>    
>    Reviewed-by: rehn, aph
>  - 8255978: [windows] os::release_memory may not release the full range
>    
>    Reviewed-by: iklam, minqi
>  - 8256375: AArch64: aarch64-asmtest.py may generate undefined register r18
>    
>    Reviewed-by: aph
>  - 8252304: Seed an HttpRequest.Builder from an existing HttpRequest
>    
>    Co-authored-by: Chris Hegarty <chegar at openjdk.org>
>    Reviewed-by: chegar, dfuchs, michaelm
>  - 8256499: Zero: enable Epsilon GC
>    
>    Reviewed-by: rkennke, ihse
>  - 8256552: Let ReplayCompiles set UseDebuggerErgo
>    
>    Reviewed-by: vlivanov, redestad
>  - 8256172: Clean up CDS handling of i2i_entry
>    
>    Reviewed-by: minqi, ccheung
>  - 8256178: Add RAII object for file lock
>    
>    Reviewed-by: dholmes, coleenp
>  - ... and 59 more: https://git.openjdk.java.net/jdk/compare/64b64ac9...2e044b91

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 218:

> 216:     }
> 217: 
> 218:     public String installerName() {

I'd suggest to insert `verifyIsOfType(PackageType.NATIVE);` call at the beginning of the function body. This will help to catch situations if installerName() is called on jpackage command building app image by accident.

test/jdk/tools/jpackage/share/MultiNameTwoPhaseTest.java line 37:

> 35: 
> 36: /*
> 37:  * @test

Without ` * @requires jpackage.test.SQETest == null` this test will be used to create test artifacts for SQE. I don't think we need any manual testing here. Especially for five test scenarios. I think automated testing should be sufficient.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1300

From naoto at openjdk.java.net  Thu Nov 19 17:53:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 19 Nov 2020 17:53:11 GMT
Subject: RFR: 8211449" Correction to the spec of implicit negative subpattern
 in DecimalFormat
Message-ID: <zDGgqJ2V2cOPay8etM9RAh_Gis8gGRB81tS0OqJdqww=.52352e36-16c9-4754-bbf5-7a3065f6560b@github.com>

Hi,

Please review this doc only fix to the class description of `DecimalFormat` class. `localized minus sign` has never been (and should never be) used in the implicit negative subpattern. Actual implementation correctly uses ascii minus sign for that purpose, so there won't be any compatibility issues.

-------------

Commit messages:
 - 8211449: Correction to the spec of implicit negative subpattern in DecimalFormat

Changes: https://git.openjdk.java.net/jdk/pull/1325/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1325&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8211449
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1325.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1325/head:pull/1325

PR: https://git.openjdk.java.net/jdk/pull/1325

From shade at openjdk.java.net  Thu Nov 19 18:00:14 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 19 Nov 2020 18:00:14 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem [v2]
In-Reply-To: <AyKrgbhx7vaTZAPxkWFm2v09xkgwNvI7k0uXOPQ491s=.ae331a7d-f4bd-43ff-8cb4-fca8b4c85231@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
 <AyKrgbhx7vaTZAPxkWFm2v09xkgwNvI7k0uXOPQ491s=.ae331a7d-f4bd-43ff-8cb4-fca8b4c85231@github.com>
Message-ID: <KV-xx-gH_9o5jKti8kX3Z5qR9kq8c1pjmxduyD7W_rU=.836f5ce5-4035-4f62-a612-ed8012339ea5@github.com>

On Thu, 19 Nov 2020 17:04:15 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this simple change that catches UncheckedIOException that can occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the system, or if there is an interrupt while these are being read.
>> 
>> Testing: Tier1, Tier2 and Tier3.
>> 
>> Thanks,
>> Poonam
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added UncheckedIOException catch blocks for cgroupv2 subsystem, and also for the rest of reader methods in CgroupUtil.java

This looks good to me. @jerboaa might want to take a look.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1303

From shade at openjdk.java.net  Thu Nov 19 18:00:16 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Thu, 19 Nov 2020 18:00:16 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem [v2]
In-Reply-To: <-8nFRuUb3mu0qHNPDJjBNN1LTxOkum4PO1kuEI-DIqU=.f37ed25c-ff43-4e88-8a80-46395a86d91f@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
 <My0OMR31GHOnby6dlgs2TxmIXBiifyzA8B-W42bSDyk=.19db1d9a-1d24-4819-b333-8916ced95dd8@github.com>
 <-8nFRuUb3mu0qHNPDJjBNN1LTxOkum4PO1kuEI-DIqU=.f37ed25c-ff43-4e88-8a80-46395a86d91f@github.com>
Message-ID: <r_-UG17oyggtAUEInbq-2aa6mS2bCnmkQOUtiPvf3lI=.4521ee4a-5a63-46c4-bfdc-65d472d41b9f@github.com>

On Thu, 19 Nov 2020 15:00:54 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1Subsystem.java line 79:
>> 
>>> 77:                  .forEach(entry -> createSubSystemController(subsystem, entry));
>>> 78: 
>>> 79:         } catch (UncheckedIOException e) {
>> 
>> I am confused. `CgroupUtil.readFilePrivileged` unwraps `UncheckedIOException`, why this catch clause is needed? Is this because the cause might be `UncheckedIOException` itself? Might be easier to rewrap `UncheckedIOException` to just `IOException` in `CgroupUtil`.
>
> It is there to catch the UncheckedIOException that could get thrown while processing each line and entry. Example of this exception encountered with JDK 8u.
> 
> Caused by: java.io.UncheckedIOException:
> java.nio.channels.ClosedByInterruptException
> at java.io.BufferedReader$1.hasNext(BufferedReader.java:574)
> at java.util.Iterator.forEachRemaining(Iterator.java:115)
> at java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:482)
> at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:472)
> at java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:151)
> at java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:174)
> at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:418)
> at jdk.internal.platform.cgroupv1.Metrics.initContainerSubSystems(Metrics.java:81)
> at jdk.internal.platform.cgroupv1.Metrics.<clinit>(Metrics.java:51)... 41 more
> 
> Caused by: java.nio.channels.ClosedByInterruptException
> at java.nio.channels.spi.AbstractInterruptibleChannel.end(AbstractInterruptibleChannel.java:202)
> at sun.nio.ch.FileChannelImpl.read(FileChannelImpl.java:164)
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:65)
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:109)
> at sun.nio.ch.ChannelInputStream.read(ChannelInputStream.java:103)
> at sun.nio.cs.StreamDecoder.readBytes(StreamDecoder.java:284)
> at sun.nio.cs.StreamDecoder.implRead(StreamDecoder.java:326)
> at sun.nio.cs.StreamDecoder.read(StreamDecoder.java:178)
> at java.io.InputStreamReader.read(InputStreamReader.java:184)
> at java.io.BufferedReader.fill(BufferedReader.java:161)
> at java.io.BufferedReader.readLine(BufferedReader.java:324)
> at java.io.BufferedReader.readLine(BufferedReader.java:389)
> at java.io.BufferedReader$1.hasNext(BufferedReader.java:571)

Got it, thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1303

From bpb at openjdk.java.net  Thu Nov 19 18:02:09 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 19 Nov 2020 18:02:09 GMT
Subject: RFR: 8256183: InputStream.skipNBytes is missing @since 12
In-Reply-To: <sOJHtr9tnZp1n5StjYHRlpgvP3q3mNq9G-6bZarJL7s=.67302c78-5e9f-4b7f-b3be-d9a165a09684@github.com>
References: <sOJHtr9tnZp1n5StjYHRlpgvP3q3mNq9G-6bZarJL7s=.67302c78-5e9f-4b7f-b3be-d9a165a09684@github.com>
Message-ID: <nWt1QhB9-ErLzkEXXRbOiUuvywOvX_xKCHj0zjWQRcs=.a284cca6-f08e-42ac-9cbd-8acdfaca4be5@github.com>

On Thu, 19 Nov 2020 12:35:04 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> InputStream.skipNBytes is missing `@since 12` tag which was not added during the review of [JDK-6516099](https://bugs.openjdk.java.net/browse/JDK-6516099).
> 
> This small fix adds the `@since` tag to InputStream.skipNBytes

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1314

From bpb at openjdk.java.net  Thu Nov 19 18:04:04 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 19 Nov 2020 18:04:04 GMT
Subject: RFR: 8211449: Correction to the spec of implicit negative
 subpattern in DecimalFormat
In-Reply-To: <zDGgqJ2V2cOPay8etM9RAh_Gis8gGRB81tS0OqJdqww=.52352e36-16c9-4754-bbf5-7a3065f6560b@github.com>
References: <zDGgqJ2V2cOPay8etM9RAh_Gis8gGRB81tS0OqJdqww=.52352e36-16c9-4754-bbf5-7a3065f6560b@github.com>
Message-ID: <zvYxvBG0y4S-k4LlKASVtCvbfvggMZ5h-WAgMIqAM2k=.d74b98c7-d1ca-4d2e-86ae-ced4bdfd23de@github.com>

On Thu, 19 Nov 2020 17:15:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this doc only fix to the class description of `DecimalFormat` class. `localized minus sign` has never been (and should never be) used in the implicit negative subpattern. Actual implementation correctly uses ascii minus sign for that purpose, so there won't be any compatibility issues.

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1325

From iris at openjdk.java.net  Thu Nov 19 18:18:06 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Thu, 19 Nov 2020 18:18:06 GMT
Subject: RFR: 8037384: Fix wording in Javadoc of java.io.Serializable
In-Reply-To: <j51neqpaI-7jIch45IbUQPgl9jpbAETXuTNOviNlNDs=.334da5a4-f082-46bd-aedc-56c2f18358a1@github.com>
References: <j51neqpaI-7jIch45IbUQPgl9jpbAETXuTNOviNlNDs=.334da5a4-f082-46bd-aedc-56c2f18358a1@github.com>
Message-ID: <oa_sWKlItRki5-1eXd7dJQo7dwh6DAd6rLmSuXKsgSM=.a578523b-1a74-4462-bed4-ab48e238363d@github.com>

On Thu, 19 Nov 2020 03:44:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> 8231547: Serializable class doc should link to serialization specification
> 
> Rewrite a couple confusing sentences in the Serializable class doc. This does affect normative text, but the edits are primarily to focus and clarify the text, not to make any semantic changes. Thus, a CSR request shouldn't be required for this change.
> 
> Also add and adjust some links and link markup to the Java Object Serialization Specification.

Adjusted references look good.

-------------

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1306

From lancea at openjdk.java.net  Thu Nov 19 18:20:06 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 19 Nov 2020 18:20:06 GMT
Subject: RFR: 8211449: Correction to the spec of implicit negative
 subpattern in DecimalFormat
In-Reply-To: <zDGgqJ2V2cOPay8etM9RAh_Gis8gGRB81tS0OqJdqww=.52352e36-16c9-4754-bbf5-7a3065f6560b@github.com>
References: <zDGgqJ2V2cOPay8etM9RAh_Gis8gGRB81tS0OqJdqww=.52352e36-16c9-4754-bbf5-7a3065f6560b@github.com>
Message-ID: <t_wSasdp0vEZLYtTdFJjtJ4d0vDN3zLm2DNBb_T5aBk=.8a5ba0c4-3e88-49a1-828e-fbe9cae1dd8d@github.com>

On Thu, 19 Nov 2020 17:15:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this doc only fix to the class description of `DecimalFormat` class. `localized minus sign` has never been (and should never be) used in the implicit negative subpattern. Actual implementation correctly uses ascii minus sign for that purpose, so there won't be any compatibility issues.

Looks fine, pending CSR approval :-)

-------------

PR: https://git.openjdk.java.net/jdk/pull/1325

From herrick at openjdk.java.net  Thu Nov 19 19:08:21 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 19 Nov 2020 19:08:21 GMT
Subject: RFR: JDK-8256475: Fix Behavior when Installer name differs from
 =?UTF-8?B?YXBwbGljYXRpb+KApg==?= [v3]
In-Reply-To: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
References: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
Message-ID: <FaL4LI0NOXV-o9Q9wm_08o-H0abwr2yKwfUNA3F-BwQ=.735f9bc3-d8bd-4a0f-b128-5bf1f0787a62@github.com>

> ?n name.

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8256475: Fix Behavior when Installer name differs from application name.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1300/files
  - new: https://git.openjdk.java.net/jdk/pull/1300/files/2e044b91..f7f910b8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1300&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1300&range=01-02

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1300.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1300/head:pull/1300

PR: https://git.openjdk.java.net/jdk/pull/1300

From bobv at openjdk.java.net  Thu Nov 19 19:32:07 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Thu, 19 Nov 2020 19:32:07 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem [v2]
In-Reply-To: <KV-xx-gH_9o5jKti8kX3Z5qR9kq8c1pjmxduyD7W_rU=.836f5ce5-4035-4f62-a612-ed8012339ea5@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
 <AyKrgbhx7vaTZAPxkWFm2v09xkgwNvI7k0uXOPQ491s=.ae331a7d-f4bd-43ff-8cb4-fca8b4c85231@github.com>
 <KV-xx-gH_9o5jKti8kX3Z5qR9kq8c1pjmxduyD7W_rU=.836f5ce5-4035-4f62-a612-ed8012339ea5@github.com>
Message-ID: <YI9W6wtEOdwI8YS7Ikve5_Tf_QUIewsT7shhBqR9qrc=.84c805aa-8df1-46ec-9636-a6f9da0f5348@github.com>

On Thu, 19 Nov 2020 17:56:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added UncheckedIOException catch blocks for cgroupv2 subsystem, and also for the rest of reader methods in CgroupUtil.java
>
> This looks good to me. @jerboaa might want to take a look.

Shouldn't you add a check in src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java:sumTokensIOStat ?

What about getLongEntry in src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java?  There are streams operations occuring there as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1303

From bpb at openjdk.java.net  Thu Nov 19 19:36:10 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 19 Nov 2020 19:36:10 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently
Message-ID: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>

Please review this modification of `java.io.InputStream.skipNBytes(long)` to improve its performance when `skip(long)` skips fewer than the requested number of bytes. In the current implementation, `skip(long)` is invoked once and, if not enough bytes have been skipped, then `read()` is invoked for each of the remaining bytes to be skipped. The proposed implementation instead repeatedly invokes `skip(long)` until the requested number of bytes has been skipped, or an error condition is encountered. For cases where `skip(long)` skips fewer bytes than the number requested, the new version was measured to be up to more than one thousand times faster than the old version. When `skip(long)` actually skips the requested number of bytes, the performance difference is insignificant.

-------------

Commit messages:
 - 8246739: InputStream.skipNBytes could be implemented more efficiently

Changes: https://git.openjdk.java.net/jdk/pull/1329/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1329&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8246739
  Stats: 11 lines in 1 file changed: 2 ins; 3 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1329.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1329/head:pull/1329

PR: https://git.openjdk.java.net/jdk/pull/1329

From minqi at openjdk.java.net  Thu Nov 19 19:46:08 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 19 Nov 2020 19:46:08 GMT
Subject: RFR: 8256487: Handle disableEagerInitialization for archived
 lambda proxy classes
In-Reply-To: <H0u1_kznNSlnjVxMeZDprieQlaPLVo9tR_md-eMCzk8=.2bff07f5-39c6-47a9-a9ce-6092823e610f@github.com>
References: <H0u1_kznNSlnjVxMeZDprieQlaPLVo9tR_md-eMCzk8=.2bff07f5-39c6-47a9-a9ce-6092823e610f@github.com>
Message-ID: <TKCeZIMtAVMfv4DkQBJz7E5k6KDh9dnOmisA2OAXz_4=.4a373048-9b72-4f1f-867d-f7cf0f6a7049@github.com>

On Wed, 18 Nov 2020 23:58:25 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set.
> 
> This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically:
> 
> - remove the above workaround;
> 
> - capture the setting of the property in the archive header during CDS dump time;
> 
> - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header.
> If the values don't match, the archived lambda proxy class won't be used.
> 
> Tests:
> 
> - [x] ran all cds tests locally on linux-x64
> 
> - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64
> 
> - [x] mach5 tiers 1,2,3 (in progress)

src/hotspot/share/memory/metaspaceShared.cpp line 76:

> 74: #endif
> 75: 
> 76: #include <string.h>

This include is strange, usually we do not include std head file in .cpp file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1301

From sviswanathan at openjdk.java.net  Thu Nov 19 19:47:15 2020
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 19 Nov 2020 19:47:15 GMT
Subject: RFR: 8256585: Remove in-place conversion vector operators from
 Vector API [v2]
In-Reply-To: <DbLEmx1uzM8W8p9NVSgbFlAiYsKrcNAPL_BSj-K0zVI=.0b0e9229-db39-48ef-b904-e3db4bce71cc@github.com>
References: <DbLEmx1uzM8W8p9NVSgbFlAiYsKrcNAPL_BSj-K0zVI=.0b0e9229-db39-48ef-b904-e3db4bce71cc@github.com>
Message-ID: <CTAzB4TybFnwzgeByQjAK-IkEK4-idhpoAImVsLWVzQ=.83dc8817-fd69-4932-a251-aadb8df7f7d7@github.com>

> Remove partially implemented in-place conversion vector operators from Vector API:
>    ofNarrowing, ofWidening, INPLACE_XXX

Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:

  Update documentation

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1305/files
  - new: https://git.openjdk.java.net/jdk/pull/1305/files/73122deb..db9d37de

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1305&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1305&range=00-01

  Stats: 12 lines in 1 file changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1305.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1305/head:pull/1305

PR: https://git.openjdk.java.net/jdk/pull/1305

From sviswanathan at openjdk.java.net  Thu Nov 19 19:50:03 2020
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Thu, 19 Nov 2020 19:50:03 GMT
Subject: RFR: 8256585: Remove in-place conversion vector operators from
 Vector API [v2]
In-Reply-To: <r8oVNrwuVyDgbLaJFUXYWs_bK1b5QYZgk6jI5rIkTbg=.abe03f63-f073-4f3b-a885-9eaba6f0819d@github.com>
References: <DbLEmx1uzM8W8p9NVSgbFlAiYsKrcNAPL_BSj-K0zVI=.0b0e9229-db39-48ef-b904-e3db4bce71cc@github.com>
 <r8oVNrwuVyDgbLaJFUXYWs_bK1b5QYZgk6jI5rIkTbg=.abe03f63-f073-4f3b-a885-9eaba6f0819d@github.com>
Message-ID: <YT2TmULcnZXNA114n5Gj2g0mhqKlN_wKOYbJPSfFcdI=.8b50e08c-db60-4180-8165-c36e37fddbc6@github.com>

On Thu, 19 Nov 2020 17:18:12 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

>> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update documentation
>
> The documentation `Vector.convert` and `Vector.convertShape` needs to be updated to remove specification of in-place conversions, as does the class documentation on `Vector`. A search for the term `in-place` should find the relevant locations.

Updated documentation to reflect removal of widening and contracting in-place conversions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1305

From mchung at openjdk.java.net  Thu Nov 19 19:55:09 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 19 Nov 2020 19:55:09 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v2]
In-Reply-To: <X-tT29dRiWaS394o3ilVhJdV0xKsZ_kwqOHhLs3wwW8=.76df07ec-25c5-44bf-a160-2a88a3cb6adf@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
 <X-tT29dRiWaS394o3ilVhJdV0xKsZ_kwqOHhLs3wwW8=.76df07ec-25c5-44bf-a160-2a88a3cb6adf@github.com>
Message-ID: <Q8qFNQxNBe6tNbPE2QJlfjVR4mY51e-1VvxyhAX9ISw=.926f5fe3-d4a2-44f5-a73f-59afd7370bb9@github.com>

On Thu, 19 Nov 2020 17:16:22 GMT, Mark Reinhold <mr at openjdk.org> wrote:

>> Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396).
>> Alan Bateman is the original author; I?ve credited him in the commit metadata.
>> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64.
>
> Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary @module :open from ASN1FormatterTest.java

Marked as reviewed by mchung (Reviewer).

test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java line 387:

> 385:                 "--illegal-access=permit");
> 386:     }
> 387: 

I see `setAccessibleNonPublicMemberExportedPackage` test case testing with `--add-exports` and `--add-opens` and `Add-Opens` in JAR file manifest but not testing with `Add-Exports`.

Is it worth to include the `Add-Exports` test case?

Other than this, looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1324

From minqi at openjdk.java.net  Thu Nov 19 19:57:04 2020
From: minqi at openjdk.java.net (Yumin Qi)
Date: Thu, 19 Nov 2020 19:57:04 GMT
Subject: RFR: 8256487: Handle disableEagerInitialization for archived
 lambda proxy classes
In-Reply-To: <H0u1_kznNSlnjVxMeZDprieQlaPLVo9tR_md-eMCzk8=.2bff07f5-39c6-47a9-a9ce-6092823e610f@github.com>
References: <H0u1_kznNSlnjVxMeZDprieQlaPLVo9tR_md-eMCzk8=.2bff07f5-39c6-47a9-a9ce-6092823e610f@github.com>
Message-ID: <FGZKGvkE9R8Vly95a2BCls5jo853Zm_A5B3BGZyLLdQ=.6f4634d4-fbdf-48ff-b921-869f5367b736@github.com>

On Wed, 18 Nov 2020 23:58:25 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set.
> 
> This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically:
> 
> - remove the above workaround;
> 
> - capture the setting of the property in the archive header during CDS dump time;
> 
> - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header.
> If the values don't match, the archived lambda proxy class won't be used.
> 
> Tests:
> 
> - [x] ran all cds tests locally on linux-x64
> 
> - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64
> 
> - [x] mach5 tiers 1,2,3 (in progress)

src/hotspot/share/memory/metaspaceShared.cpp line 1821:

> 1819: }
> 1820: 
> 1821: void MetaspaceShared::set_disable_eager_init(const char* value) {

strcasecmp is not platform dependent, why not use it for all? It does not need <string.h> included.

test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaEagerInit.java line 35:

> 33:  * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds
> 34:  * @compile ../../../../../../jdk/java/lang/invoke/lambda/LambdaEagerInitTest.java
> 35:  * @build sun.hotspot.WhiteBox

Do we need WB here?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1301

From naoto at openjdk.java.net  Thu Nov 19 20:01:04 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 19 Nov 2020 20:01:04 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently
In-Reply-To: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
Message-ID: <oxBfxopG2NwxZr32Jrlo2bpAOQ5uHZs8hHr66Z3BYqs=.2f8e71f0-48d3-4125-b58e-fe1d4aeb28cc@github.com>

On Thu, 19 Nov 2020 19:29:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this modification of `java.io.InputStream.skipNBytes(long)` to improve its performance when `skip(long)` skips fewer than the requested number of bytes. In the current implementation, `skip(long)` is invoked once and, if not enough bytes have been skipped, then `read()` is invoked for each of the remaining bytes to be skipped. The proposed implementation instead repeatedly invokes `skip(long)` until the requested number of bytes has been skipped, or an error condition is encountered. For cases where `skip(long)` skips fewer bytes than the number requested, the new version was measured to be up to more than one thousand times faster than the old version. When `skip(long)` actually skips the requested number of bytes, the performance difference is insignificant.

The code looks good. Should we also change the @implSpec, as it specifically describes how it works, i.e., calling no-arg read(), but the new impl calls read() with buffer.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1329

From serb at openjdk.java.net  Thu Nov 19 20:01:05 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Thu, 19 Nov 2020 20:01:05 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently
In-Reply-To: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
Message-ID: <pxcneXYEiCJ_b1p6mk20_Muo_o_O9DRvQJznRo9vKm4=.ef0bd01b-66a1-4942-a4af-037764ebfc2d@github.com>

On Thu, 19 Nov 2020 19:29:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this modification of `java.io.InputStream.skipNBytes(long)` to improve its performance when `skip(long)` skips fewer than the requested number of bytes. In the current implementation, `skip(long)` is invoked once and, if not enough bytes have been skipped, then `read()` is invoked for each of the remaining bytes to be skipped. The proposed implementation instead repeatedly invokes `skip(long)` until the requested number of bytes has been skipped, or an error condition is encountered. For cases where `skip(long)` skips fewer bytes than the number requested, the new version was measured to be up to more than one thousand times faster than the old version. When `skip(long)` actually skips the requested number of bytes, the performance difference is insignificant.

src/java.base/share/classes/java/io/InputStream.java line 596:

> 594:      * @see        java.io.InputStream#skip(long)
> 595:      */
> 596:     public void skipNBytes(long n) throws IOException {

Not related to this change, but looks like `@since` is missing.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1329

From bpb at openjdk.java.net  Thu Nov 19 20:01:07 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 19 Nov 2020 20:01:07 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently
In-Reply-To: <pxcneXYEiCJ_b1p6mk20_Muo_o_O9DRvQJznRo9vKm4=.ef0bd01b-66a1-4942-a4af-037764ebfc2d@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
 <pxcneXYEiCJ_b1p6mk20_Muo_o_O9DRvQJznRo9vKm4=.ef0bd01b-66a1-4942-a4af-037764ebfc2d@github.com>
Message-ID: <MxF2WhD14uFxPZN-LDqI9gMQ-iPItkAhYqi4eI6VsX0=.853d585e-488a-4631-9b2c-81f198a813ee@github.com>

On Thu, 19 Nov 2020 19:52:05 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Please review this modification of `java.io.InputStream.skipNBytes(long)` to improve its performance when `skip(long)` skips fewer than the requested number of bytes. In the current implementation, `skip(long)` is invoked once and, if not enough bytes have been skipped, then `read()` is invoked for each of the remaining bytes to be skipped. The proposed implementation instead repeatedly invokes `skip(long)` until the requested number of bytes has been skipped, or an error condition is encountered. For cases where `skip(long)` skips fewer bytes than the number requested, the new version was measured to be up to more than one thousand times faster than the old version. When `skip(long)` actually skips the requested number of bytes, the performance difference is insignificant.
>
> src/java.base/share/classes/java/io/InputStream.java line 596:
> 
>> 594:      * @see        java.io.InputStream#skip(long)
>> 595:      */
>> 596:     public void skipNBytes(long n) throws IOException {
> 
> Not related to this change, but looks like `@since` is missing.

https://bugs.openjdk.java.net/browse/JDK-8256183

-------------

PR: https://git.openjdk.java.net/jdk/pull/1329

From bpb at openjdk.java.net  Thu Nov 19 20:04:06 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 19 Nov 2020 20:04:06 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently
In-Reply-To: <oxBfxopG2NwxZr32Jrlo2bpAOQ5uHZs8hHr66Z3BYqs=.2f8e71f0-48d3-4125-b58e-fe1d4aeb28cc@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
 <oxBfxopG2NwxZr32Jrlo2bpAOQ5uHZs8hHr66Z3BYqs=.2f8e71f0-48d3-4125-b58e-fe1d4aeb28cc@github.com>
Message-ID: <dLioIRpOePxWytV8wHdngMLBBjjrCpc39mQdSUeOJY0=.c66fa718-2690-4363-b5b2-48ce11b523e8@github.com>

On Thu, 19 Nov 2020 19:58:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code looks good. Should we also change the @implSpec, as it specifically describes how it works, i.e., calling no-arg read(), but the new impl calls read() with buffer.

Good catch. Yes, the `@implSpec` should be updated. I was too focused on the code and performance test and missed that. I'll update that and file a CSR. Thanks.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1329

From bpb at openjdk.java.net  Thu Nov 19 20:20:17 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 19 Nov 2020 20:20:17 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently [v2]
In-Reply-To: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
Message-ID: <L2ZJDD2MxcN4n2bgzpupNVer8cBbCImp8P35KfEZRk4=.b92861d5-b700-4760-bbb8-f020208c8aa6@github.com>

> Please review this modification of `java.io.InputStream.skipNBytes(long)` to improve its performance when `skip(long)` skips fewer than the requested number of bytes. In the current implementation, `skip(long)` is invoked once and, if not enough bytes have been skipped, then `read()` is invoked for each of the remaining bytes to be skipped. The proposed implementation instead repeatedly invokes `skip(long)` until the requested number of bytes has been skipped, or an error condition is encountered. For cases where `skip(long)` skips fewer bytes than the number requested, the new version was measured to be up to more than one thousand times faster than the old version. When `skip(long)` actually skips the requested number of bytes, the performance difference is insignificant.

Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:

 - 8246739: InputStream.skipNBytes could be implemented more efficiently
 - 8246739: InputStream.skipNBytes could be implemented more efficiently

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1329/files
  - new: https://git.openjdk.java.net/jdk/pull/1329/files/331f3fcc..f59d7a35

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1329&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1329&range=00-01

  Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1329.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1329/head:pull/1329

PR: https://git.openjdk.java.net/jdk/pull/1329

From smarks at openjdk.java.net  Thu Nov 19 20:21:05 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 19 Nov 2020 20:21:05 GMT
Subject: RFR: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly [v13]
In-Reply-To: <5IpbSrdcuKa4kWC2OEozS7TkcDl_UrQ23ypTugtXWvw=.5e8f3c17-337d-4e73-8901-3480b852763c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
 <5IpbSrdcuKa4kWC2OEozS7TkcDl_UrQ23ypTugtXWvw=.5e8f3c17-337d-4e73-8901-3480b852763c@github.com>
Message-ID: <_3RAvXY8Ua9Bs_WM9tnoTrv8viowc2JoxGp8p0afA3I=.2afe8051-5db6-4c1c-9f43-04a50507f48a@github.com>

On Thu, 19 Nov 2020 00:58:21 GMT, Ian Graves <igraves at openjdk.org> wrote:

>> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
>> 
>> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
>> 
>> A CSR will be required for this PR.
>
> Ian Graves has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comment cleanup

Marked as reviewed by smarks (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/516

From igraves at openjdk.java.net  Thu Nov 19 20:24:04 2020
From: igraves at openjdk.java.net (Ian Graves)
Date: Thu, 19 Nov 2020 20:24:04 GMT
Subject: Integrated: 8253459: Formatter treats index,
 width and precision > Integer.MAX_VALUE incorrectly
In-Reply-To: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
References: <3aYgWcp1IVMM0vQT5UMLSnc2JA1uK9cbtRe283RF37g=.fc2049ef-cdbe-4948-a24b-fdb88cc87a1c@github.com>
Message-ID: <B79WPkolbTjgP7hxCCqsKfb8nR0k_Dhvlbx7Royr1ug=.a1680f96-e51f-4850-8a79-b8df92150400@github.com>

On Mon, 5 Oct 2020 22:23:56 GMT, Ian Graves <igraves at openjdk.org> wrote:

> The `java.util.Formatter` format specifies support for field widths, argument indexes, or precision lengths of a field that relate to the variadic arguments supplied to the formatter. These numbers are specified by integers, sometimes negative. For argument index, it's specified in the documentation that the highest allowed argument is limited by the largest possible index of an array (ie the largest possible variadic index), but for the other two it's not defined. Moreover, what happens when a number field in a string is too large or too small to be represented by a 32-bit integer type is not defined.
> 
> This fix adds documentation to specify what error behavior occurs during these cases. Additionally it adds an additional exception type to throw when an invalid argument index is observed.
> 
> A CSR will be required for this PR.

This pull request has now been integrated.

Changeset: 080c707a
Author:    Ian Graves <igraves at openjdk.org>
Committer: Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/080c707a
Stats:     175 lines in 5 files changed: 167 ins; 0 del; 8 mod

8253459: Formatter treats index, width and precision > Integer.MAX_VALUE incorrectly

Reviewed-by: rriggs, smarks

-------------

PR: https://git.openjdk.java.net/jdk/pull/516

From rriggs at openjdk.java.net  Thu Nov 19 20:32:17 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 19 Nov 2020 20:32:17 GMT
Subject: RFR: 8256480: Refactor ObjectInputStream field reader
 implementation [v2]
In-Reply-To: <57N_l5oDQywDYUYK-EH1Odb00ipNZxHTNg_NSzfx2Ww=.d11b14a5-8b9c-421e-a92d-cac8462b0f8e@github.com>
References: <57N_l5oDQywDYUYK-EH1Odb00ipNZxHTNg_NSzfx2Ww=.d11b14a5-8b9c-421e-a92d-cac8462b0f8e@github.com>
Message-ID: <jErR-1aeFunUfrgXvSxBEH1NWJlIAWM9F0r0FI7nCh4=.b268c661-55c5-4c9f-a5ed-9cf04d8f926c@github.com>

> ObjectInputStream has nearly identical but separate implementations to read values from the stream.
> Both implementations read primitive and object values from the stream and return an object holding the values.
> OIS.readFields() uses the internal class GetFieldImpl while OIS.defaultReadObject and reading records uses the internal class FieldValues.
> The behavioral difference between the two is whether dependencies are tracked in the object handle table or not. 
> 
> The classes are merged, retaining the internal FieldValues name and the behavior to track dependencies or not. 
> The constructor is passed the class descriptor and flag to track or not; it reads and saves the values from the stream.
> The callers are updated to call the merge FieldValues methods.
> 
> There is no change in behavior; all current tests pass.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Improvements as per review comments

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1296/files
  - new: https://git.openjdk.java.net/jdk/pull/1296/files/aa736f6b..a06f2f53

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1296&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1296&range=00-01

  Stats: 14 lines in 1 file changed: 8 ins; 4 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1296.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1296/head:pull/1296

PR: https://git.openjdk.java.net/jdk/pull/1296

From herrick at openjdk.java.net  Thu Nov 19 20:45:23 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 19 Nov 2020 20:45:23 GMT
Subject: RFR: JDK-8256475: Fix Behavior when Installer name differs from
 =?UTF-8?B?YXBwbGljYXRpb+KApg==?= [v4]
In-Reply-To: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
References: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
Message-ID: <25b-I2aVPI49KXdos4hcWbUtza3gOoMjrxAd49ca_P4=.ee575d41-5cf4-407f-add1-cdfbe220bdaa@github.com>

> ?n name.

Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8256475: Fix Behavior when Installer name differs from application name.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1300/files
  - new: https://git.openjdk.java.net/jdk/pull/1300/files/f7f910b8..1d9e5aee

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1300&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1300&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1300.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1300/head:pull/1300

PR: https://git.openjdk.java.net/jdk/pull/1300

From rriggs at openjdk.java.net  Thu Nov 19 20:46:06 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Thu, 19 Nov 2020 20:46:06 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently [v2]
In-Reply-To: <L2ZJDD2MxcN4n2bgzpupNVer8cBbCImp8P35KfEZRk4=.b92861d5-b700-4760-bbb8-f020208c8aa6@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
 <L2ZJDD2MxcN4n2bgzpupNVer8cBbCImp8P35KfEZRk4=.b92861d5-b700-4760-bbb8-f020208c8aa6@github.com>
Message-ID: <ErJ-Z0wwjD4NNYcTJO6SbuImAL5VFmc97LmdiwXiI-s=.d11edfdd-0646-4b95-9282-e4d9e26d04ff@github.com>

On Thu, 19 Nov 2020 20:20:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this modification of `java.io.InputStream.skipNBytes(long)` to improve its performance when `skip(long)` skips fewer than the requested number of bytes. In the current implementation, `skip(long)` is invoked once and, if not enough bytes have been skipped, then `read()` is invoked for each of the remaining bytes to be skipped. The proposed implementation instead repeatedly invokes `skip(long)` until the requested number of bytes has been skipped, or an error condition is encountered. For cases where `skip(long)` skips fewer bytes than the number requested, the new version was measured to be up to more than one thousand times faster than the old version. When `skip(long)` actually skips the requested number of bytes, the performance difference is insignificant.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8246739: InputStream.skipNBytes could be implemented more efficiently
>  - 8246739: InputStream.skipNBytes could be implemented more efficiently

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1329

From poonam at openjdk.java.net  Thu Nov 19 20:49:16 2020
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 19 Nov 2020 20:49:16 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem [v3]
In-Reply-To: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
Message-ID: <85FtEQ4pR0Y6nbxnbUOvLMCKBi_fkua5rWV0nGZ4ih0=.f7019fa1-38d1-4209-94d4-fa9a488ac16a@github.com>

> Hi,
> 
> Please review this simple change that catches UncheckedIOException that can occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the system, or if there is an interrupt while these are being read.
> 
> Testing: Tier1, Tier2 and Tier3.
> 
> Thanks,
> Poonam

Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:

  Added UnchedkedIOException catch blocks for sumTokensIOStat and getLongEntry methods

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1303/files
  - new: https://git.openjdk.java.net/jdk/pull/1303/files/80799f29..8e39e8fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1303&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1303&range=01-02

  Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1303.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1303/head:pull/1303

PR: https://git.openjdk.java.net/jdk/pull/1303

From poonam at openjdk.java.net  Thu Nov 19 20:52:07 2020
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Thu, 19 Nov 2020 20:52:07 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem [v2]
In-Reply-To: <YI9W6wtEOdwI8YS7Ikve5_Tf_QUIewsT7shhBqR9qrc=.84c805aa-8df1-46ec-9636-a6f9da0f5348@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
 <AyKrgbhx7vaTZAPxkWFm2v09xkgwNvI7k0uXOPQ491s=.ae331a7d-f4bd-43ff-8cb4-fca8b4c85231@github.com>
 <KV-xx-gH_9o5jKti8kX3Z5qR9kq8c1pjmxduyD7W_rU=.836f5ce5-4035-4f62-a612-ed8012339ea5@github.com>
 <YI9W6wtEOdwI8YS7Ikve5_Tf_QUIewsT7shhBqR9qrc=.84c805aa-8df1-46ec-9636-a6f9da0f5348@github.com>
Message-ID: <gUh25m7EYRuSkBpXS0ucGKLlMgeJ1yYSiDpEWk5MlnQ=.e716cb66-8c6a-49d3-976a-1a3e03fb0b77@github.com>

On Thu, 19 Nov 2020 19:29:25 GMT, Bob Vandette <bobv at openjdk.org> wrote:

>> This looks good to me. @jerboaa might want to take a look.
>
> Shouldn't you add a check in src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java:sumTokensIOStat ?
> 
> What about getLongEntry in src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java?  There are streams operations occuring there as well.

@bobvandette sumTokensIOStat() and getLongEntry() should also have the catch blocks, and I have added those. Please review the latest commit.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1303

From mchung at openjdk.java.net  Thu Nov 19 21:06:04 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Thu, 19 Nov 2020 21:06:04 GMT
Subject: RFR: 8256487: Handle disableEagerInitialization for archived
 lambda proxy classes
In-Reply-To: <oqRXPyUXaTyJk12PhLQ7JYOfx_lCe-y047tFuVb_rKk=.14a27fb3-4f8d-4dc9-808b-d5e497f2b5cd@github.com>
References: <H0u1_kznNSlnjVxMeZDprieQlaPLVo9tR_md-eMCzk8=.2bff07f5-39c6-47a9-a9ce-6092823e610f@github.com>
 <aNddz6pf9Cs5D0M4dooQIy1Ucu8p8wDSl7kniMVr9Zo=.d0c0bf0a-9906-4c26-922d-662e5aa3462a@github.com>
 <2HAKrvsORLsNHOY10PyQ395snpigQ7t0ZhAKUVIoPlk=.0540d08a-e46a-4e80-9719-4f16acc943d2@github.com>
 <oqRXPyUXaTyJk12PhLQ7JYOfx_lCe-y047tFuVb_rKk=.14a27fb3-4f8d-4dc9-808b-d5e497f2b5cd@github.com>
Message-ID: <GM9AY2Y2PSuQwvnvJMORNTgMeXN2NVtLHoxkwuICqy8=.686b2a80-93f4-4687-bb36-43e6b4040cfd@github.com>

On Thu, 19 Nov 2020 16:09:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Hi Claes,
>> 
>> Thanks for taking a look.
>> 
>> So should I keep the following `!initialize` check in LambdaProxyClassArchive?
>> 109         if (!loadedByBuiltinLoader(caller) || !initialize ||
>> 110             !CDS.isSharingEnabled() || isSerializable || markerInterfaces.length > 0 || additionalBridges.length > 0)
>> 111             return null;
>> If we keep the above code, I think we don't need to pass the `initialize` to `findFromArchive` and eventually to `JVM_LookupLambdaProxyClassFromArchive`.
>> 
>> Let me know if the above is what you have in mind?
>> 
>> thanks,
>> Calvin
>
> Right, I'd drop that argument - I would go further and suggest making calls to both `LambdaProxyClassArchive.register` and `LambdaProxyClassArchive.find` conditional on `disableEagerInitialization` being `false` to avoid any accidental mix-up and reduce complexity of these orthogonal features/concerns.

I agree with Claes that this is a wrong move to archive lambda proxies even if `disableEagerInitialization` is set.   A simple fix would be:

private Class<?> spinInnerClass() throws LambdaConversionException {
      if (!disableEagerInitialization) {
          if (LambdaProxyClassArchive.isDumpArchive()) {
              ...
          }
          // load from CDS archive if present
          Class<?> archiveClass = LambdaProxyClassArchive.find(targetClass,
                                                           samMethodName,
                                                           invokedType,
                                                           samMethodType,
                                                           implMethod,
                                                           instantiatedMethodType,
                                                           isSerializable,
                                                           markerInterfaces,
                                                           additionalBridges,
                                                           true);
           if (archiveClass != null)  return archiveClass;
      }
      return generateInnerClass();
}

-------------

PR: https://git.openjdk.java.net/jdk/pull/1301

From brian.burkhalter at oracle.com  Thu Nov 19 21:14:54 2020
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Thu, 19 Nov 2020 13:14:54 -0800
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently
In-Reply-To: <dLioIRpOePxWytV8wHdngMLBBjjrCpc39mQdSUeOJY0=.c66fa718-2690-4363-b5b2-48ce11b523e8@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
 <oxBfxopG2NwxZr32Jrlo2bpAOQ5uHZs8hHr66Z3BYqs=.2f8e71f0-48d3-4125-b58e-fe1d4aeb28cc@github.com>
 <dLioIRpOePxWytV8wHdngMLBBjjrCpc39mQdSUeOJY0=.c66fa718-2690-4363-b5b2-48ce11b523e8@github.com>
Message-ID: <7EBEC191-AC79-47CF-B72B-BFD04DCF8210@oracle.com>


> On Nov 19, 2020, at 12:04 PM, Brian Burkhalter <bpb at openjdk.java.net> wrote:
> 
> On Thu, 19 Nov 2020 19:58:16 GMT, Naoto Sato <naoto at openjdk.org <mailto:naoto at openjdk.org>> wrote:
> 
>> The code looks good. Should we also change the @implSpec, as it specifically describes how it works, i.e., calling no-arg read(), but the new impl calls read() with buffer.
> 
> Good catch. Yes, the `@implSpec` should be updated. I was too focused on the code and performance test and missed that. I'll update that and file a CSR. Thanks.

CSR filed [1]

Thanks,

Brian

[1] https://bugs.openjdk.java.net/browse/JDK-8256698

From psandoz at openjdk.java.net  Thu Nov 19 21:25:06 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Thu, 19 Nov 2020 21:25:06 GMT
Subject: RFR: 8256585: Remove in-place conversion vector operators from
 Vector API [v2]
In-Reply-To: <CTAzB4TybFnwzgeByQjAK-IkEK4-idhpoAImVsLWVzQ=.83dc8817-fd69-4932-a251-aadb8df7f7d7@github.com>
References: <DbLEmx1uzM8W8p9NVSgbFlAiYsKrcNAPL_BSj-K0zVI=.0b0e9229-db39-48ef-b904-e3db4bce71cc@github.com>
 <CTAzB4TybFnwzgeByQjAK-IkEK4-idhpoAImVsLWVzQ=.83dc8817-fd69-4932-a251-aadb8df7f7d7@github.com>
Message-ID: <XDBGpInt6oFFVEDIg3TXAbdIZA5xx4l2W08iaDAGNG8=.ba75a8a9-2536-4747-a096-65b0faa0bf4e@github.com>

On Thu, 19 Nov 2020 19:47:15 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Remove partially implemented in-place conversion vector operators from Vector API:
>>    ofNarrowing, ofWidening, INPLACE_XXX
>
> Sandhya Viswanathan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update documentation

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1305

From lancea at openjdk.java.net  Thu Nov 19 21:30:10 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Thu, 19 Nov 2020 21:30:10 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently [v2]
In-Reply-To: <L2ZJDD2MxcN4n2bgzpupNVer8cBbCImp8P35KfEZRk4=.b92861d5-b700-4760-bbb8-f020208c8aa6@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
 <L2ZJDD2MxcN4n2bgzpupNVer8cBbCImp8P35KfEZRk4=.b92861d5-b700-4760-bbb8-f020208c8aa6@github.com>
Message-ID: <0DUxvXdkAlFbBItYSQ8r2j86XAzPUebprhGtwkRBSO0=.b269d947-bf0e-4f14-b740-aab13d549d96@github.com>

On Thu, 19 Nov 2020 20:20:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this modification of `java.io.InputStream.skipNBytes(long)` to improve its performance when `skip(long)` skips fewer than the requested number of bytes. In the current implementation, `skip(long)` is invoked once and, if not enough bytes have been skipped, then `read()` is invoked for each of the remaining bytes to be skipped. The proposed implementation instead repeatedly invokes `skip(long)` until the requested number of bytes has been skipped, or an error condition is encountered. For cases where `skip(long)` skips fewer bytes than the number requested, the new version was measured to be up to more than one thousand times faster than the old version. When `skip(long)` actually skips the requested number of bytes, the performance difference is insignificant.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8246739: InputStream.skipNBytes could be implemented more efficiently
>  - 8246739: InputStream.skipNBytes could be implemented more efficiently

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1329

From naoto at openjdk.java.net  Thu Nov 19 21:44:07 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 19 Nov 2020 21:44:07 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently [v2]
In-Reply-To: <L2ZJDD2MxcN4n2bgzpupNVer8cBbCImp8P35KfEZRk4=.b92861d5-b700-4760-bbb8-f020208c8aa6@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
 <L2ZJDD2MxcN4n2bgzpupNVer8cBbCImp8P35KfEZRk4=.b92861d5-b700-4760-bbb8-f020208c8aa6@github.com>
Message-ID: <6SZHee-zJQfWj5rIrTbNyv_CUAzHnjEnjyN5sJPWv44=.5afedcda-f84a-466c-98d4-3a38d35bf6ed@github.com>

On Thu, 19 Nov 2020 20:20:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this modification of `java.io.InputStream.skipNBytes(long)` to improve its performance when `skip(long)` skips fewer than the requested number of bytes. In the current implementation, `skip(long)` is invoked once and, if not enough bytes have been skipped, then `read()` is invoked for each of the remaining bytes to be skipped. The proposed implementation instead repeatedly invokes `skip(long)` until the requested number of bytes has been skipped, or an error condition is encountered. For cases where `skip(long)` skips fewer bytes than the number requested, the new version was measured to be up to more than one thousand times faster than the old version. When `skip(long)` actually skips the requested number of bytes, the performance difference is insignificant.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8246739: InputStream.skipNBytes could be implemented more efficiently
>  - 8246739: InputStream.skipNBytes could be implemented more efficiently

Marked as reviewed by naoto (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1329

From naoto at openjdk.java.net  Thu Nov 19 21:49:06 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 19 Nov 2020 21:49:06 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently [v2]
In-Reply-To: <6SZHee-zJQfWj5rIrTbNyv_CUAzHnjEnjyN5sJPWv44=.5afedcda-f84a-466c-98d4-3a38d35bf6ed@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
 <L2ZJDD2MxcN4n2bgzpupNVer8cBbCImp8P35KfEZRk4=.b92861d5-b700-4760-bbb8-f020208c8aa6@github.com>
 <6SZHee-zJQfWj5rIrTbNyv_CUAzHnjEnjyN5sJPWv44=.5afedcda-f84a-466c-98d4-3a38d35bf6ed@github.com>
Message-ID: <yu6WSQ8ArWXUidMeVVyU8bOaFfMVS9Agst_A2XUdBt0=.3c763e0e-9423-41a8-8967-c228a8b43c84@github.com>

On Thu, 19 Nov 2020 21:41:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8246739: InputStream.skipNBytes could be implemented more efficiently
>>  - 8246739: InputStream.skipNBytes could be implemented more efficiently
>
> Marked as reviewed by naoto (Reviewer).

> CSR filed [1]
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8256698

Looks good. Reviewed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1329

From asemenyuk at openjdk.java.net  Thu Nov 19 21:58:10 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 19 Nov 2020 21:58:10 GMT
Subject: RFR: JDK-8256475: Fix Behavior when Installer name differs from
 =?UTF-8?B?YXBwbGljYXRpb+KApg==?= [v4]
In-Reply-To: <25b-I2aVPI49KXdos4hcWbUtza3gOoMjrxAd49ca_P4=.ee575d41-5cf4-407f-add1-cdfbe220bdaa@github.com>
References: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
 <25b-I2aVPI49KXdos4hcWbUtza3gOoMjrxAd49ca_P4=.ee575d41-5cf4-407f-add1-cdfbe220bdaa@github.com>
Message-ID: <yztm_nTT_m7VyJazzoZh4E626DP3OhoQ4H2dhapXsMM=.45dc8354-a532-4973-b46a-eae2ad1c05eb@github.com>

On Thu, 19 Nov 2020 20:45:23 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> ?n name.
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8256475: Fix Behavior when Installer name differs from application name.

Marked as reviewed by asemenyuk (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1300

From asemenyuk at openjdk.java.net  Thu Nov 19 22:17:14 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 19 Nov 2020 22:17:14 GMT
Subject: RFR: 8235304: JPackage Windows test should be added to set Publisher
Message-ID: <rSNe02yhqWuRXN6CWRJzEu2UHiKnjEGGjX-Qp3I6SAM=.d1b583db-8f05-4e24-898f-e6c84d820e09@github.com>

8235304: JPackage Windows test should be added to set Publisher

-------------

Commit messages:
 - 8235304: JPackage Windows test should be added to set Publisher
 - 8227400: Adjust jib profiles to make 3rd party tools for creating installers available on Mach5 test machines

Changes: https://git.openjdk.java.net/jdk/pull/1331/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1331&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8235304
  Stats: 128 lines in 5 files changed: 123 ins; 0 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1331.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1331/head:pull/1331

PR: https://git.openjdk.java.net/jdk/pull/1331

From asemenyuk at openjdk.java.net  Thu Nov 19 22:26:20 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Thu, 19 Nov 2020 22:26:20 GMT
Subject: RFR: 8235304: JPackage Windows test should be added to set
 Publisher [v2]
In-Reply-To: <rSNe02yhqWuRXN6CWRJzEu2UHiKnjEGGjX-Qp3I6SAM=.d1b583db-8f05-4e24-898f-e6c84d820e09@github.com>
References: <rSNe02yhqWuRXN6CWRJzEu2UHiKnjEGGjX-Qp3I6SAM=.d1b583db-8f05-4e24-898f-e6c84d820e09@github.com>
Message-ID: <urUnIf31HFwXrmnqzHCdiEvaTuCD6Np81mXIYNYfVJw=.6d593ad6-30ef-49dc-a9c2-825284611fec@github.com>

> 8235304: JPackage Windows test should be added to set Publisher

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 four additional commits since the last revision:

 - Merge branch 'JDK-8235304' of https://github.com/alexeysemenyukoracle/jdk into JDK-8235304
 - 8235304: JPackage Windows test should be added to set Publisher
 - 8227400: Adjust jib profiles to make 3rd party tools for creating installers available on Mach5 test machines
 - 8235304: JPackage Windows test should be added to set Publisher

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1331/files
  - new: https://git.openjdk.java.net/jdk/pull/1331/files/d8a2afa2..dd9e4ea1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1331&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1331&range=00-01

  Stats: 45989 lines in 294 files changed: 5480 ins; 38908 del; 1601 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1331.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1331/head:pull/1331

PR: https://git.openjdk.java.net/jdk/pull/1331

From naoto at openjdk.java.net  Thu Nov 19 22:44:08 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 19 Nov 2020 22:44:08 GMT
Subject: Integrated: 8251317: Support for CLDR version 38
In-Reply-To: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
References: <bhL0TKgaEXZcVR4azrUgEMU3HXnYCLiwetVEDFh0I60=.58ec77fa-593c-4fc3-8d48-6d0676f01e3b@github.com>
Message-ID: <XOsM_z2kJgv9AVfq7GxgMaP2QoDvLoq756kKpIx2O8o=.8939805d-e5e3-4159-979e-22c8b31db052@github.com>

On Tue, 17 Nov 2020 23:19:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes for upgrading the CLDR data to version 38. The vast majority of the changes are simply the changes in CLDR upstream, and others are mainly test changes due to the locale data change.

This pull request has now been integrated.

Changeset: 68138893
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/68138893
Stats:     57338 lines in 209 files changed: 41958 ins; 4932 del; 10448 mod

8251317: Support for CLDR version 38

Reviewed-by: erikj, bchristi, joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/1279

From herrick at openjdk.java.net  Thu Nov 19 22:54:05 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Thu, 19 Nov 2020 22:54:05 GMT
Subject: RFR: 8235304: JPackage Windows test should be added to set
 Publisher [v2]
In-Reply-To: <urUnIf31HFwXrmnqzHCdiEvaTuCD6Np81mXIYNYfVJw=.6d593ad6-30ef-49dc-a9c2-825284611fec@github.com>
References: <rSNe02yhqWuRXN6CWRJzEu2UHiKnjEGGjX-Qp3I6SAM=.d1b583db-8f05-4e24-898f-e6c84d820e09@github.com>
 <urUnIf31HFwXrmnqzHCdiEvaTuCD6Np81mXIYNYfVJw=.6d593ad6-30ef-49dc-a9c2-825284611fec@github.com>
Message-ID: <GIzPe6qLwJUHwYfsOZCAdimsTBBLnaruvPa6SSH4RhQ=.770b0978-ff90-445b-9685-1756802495c1@github.com>

On Thu, 19 Nov 2020 22:26:20 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> 8235304: JPackage Windows test should be added to set Publisher
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'JDK-8235304' of https://github.com/alexeysemenyukoracle/jdk into JDK-8235304
>  - 8235304: JPackage Windows test should be added to set Publisher
>  - 8227400: Adjust jib profiles to make 3rd party tools for creating installers available on Mach5 test machines
>  - 8235304: JPackage Windows test should be added to set Publisher

looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1331

From mr at openjdk.java.net  Thu Nov 19 23:08:22 2020
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 19 Nov 2020 23:08:22 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v3]
In-Reply-To: <Q8qFNQxNBe6tNbPE2QJlfjVR4mY51e-1VvxyhAX9ISw=.926f5fe3-d4a2-44f5-a73f-59afd7370bb9@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
 <X-tT29dRiWaS394o3ilVhJdV0xKsZ_kwqOHhLs3wwW8=.76df07ec-25c5-44bf-a160-2a88a3cb6adf@github.com>
 <Q8qFNQxNBe6tNbPE2QJlfjVR4mY51e-1VvxyhAX9ISw=.926f5fe3-d4a2-44f5-a73f-59afd7370bb9@github.com>
Message-ID: <rabnopFhJQjJDpDOBnVw8CW9rNXxG4QylLQ8ViA-ZaA=.f9b25d70-a303-4781-95d7-94c7fb238f53@github.com>

On Thu, 19 Nov 2020 19:51:59 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test
>
> test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java line 387:
> 
>> 385:                 "--illegal-access=permit");
>> 386:     }
>> 387: 
> 
> I see `setAccessibleNonPublicMemberExportedPackage` test case testing with `--add-exports` and `--add-opens` and `Add-Opens` in JAR file manifest but not testing with `Add-Exports`.
> 
> Is it worth to include the `Add-Exports` test case?
> 
> Other than this, looks good.

Good point -- case added.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1324

From mr at openjdk.java.net  Thu Nov 19 23:08:21 2020
From: mr at openjdk.java.net (Mark Reinhold)
Date: Thu, 19 Nov 2020 23:08:21 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v3]
In-Reply-To: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
Message-ID: <zhD05EEvIGCkvHzhsUn1ede4QL3Dc4WO3EgZTUcjCwg=.509629ea-e5bf-4599-96a5-a5c9e64560ff@github.com>

> Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396).
> Alan Bateman is the original author; I?ve credited him in the commit metadata.
> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64.

Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision:

  Add "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1324/files
  - new: https://git.openjdk.java.net/jdk/pull/1324/files/baf34a19..a57e6065

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=01-02

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1324.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1324/head:pull/1324

PR: https://git.openjdk.java.net/jdk/pull/1324

From almatvee at openjdk.java.net  Thu Nov 19 23:35:04 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Thu, 19 Nov 2020 23:35:04 GMT
Subject: RFR: JDK-8256475: Fix Behavior when Installer name differs from
 =?UTF-8?B?YXBwbGljYXRpb+KApg==?= [v4]
In-Reply-To: <25b-I2aVPI49KXdos4hcWbUtza3gOoMjrxAd49ca_P4=.ee575d41-5cf4-407f-add1-cdfbe220bdaa@github.com>
References: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
 <25b-I2aVPI49KXdos4hcWbUtza3gOoMjrxAd49ca_P4=.ee575d41-5cf4-407f-add1-cdfbe220bdaa@github.com>
Message-ID: <nqArmaMcxW3kEhjhKLzI_tC6v5grcxbbwNM4jQ_n4U0=.644fe28f-1f44-459e-b193-e9d86ac7c34f@github.com>

On Thu, 19 Nov 2020 20:45:23 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> ?n name.
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8256475: Fix Behavior when Installer name differs from application name.

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1300

From smarks at openjdk.java.net  Thu Nov 19 23:36:20 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 19 Nov 2020 23:36:20 GMT
Subject: RFR: 8037384: Fix wording in Javadoc of java.io.Serializable [v2]
In-Reply-To: <j51neqpaI-7jIch45IbUQPgl9jpbAETXuTNOviNlNDs=.334da5a4-f082-46bd-aedc-56c2f18358a1@github.com>
References: <j51neqpaI-7jIch45IbUQPgl9jpbAETXuTNOviNlNDs=.334da5a4-f082-46bd-aedc-56c2f18358a1@github.com>
Message-ID: <esaAlafgnMr5Q3L4-vnNs0U56B-8aFWRSL7dOhM_jpQ=.6aba9fc7-a506-4166-9ac6-edadfa0655e4@github.com>

> 8231547: Serializable class doc should link to serialization specification
> 
> Rewrite a couple confusing sentences in the Serializable class doc. This does affect normative text, but the edits are primarily to focus and clarify the text, not to make any semantic changes. Thus, a CSR request shouldn't be required for this change.
> 
> Also add and adjust some links and link markup to the Java Object Serialization Specification.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  non-serializable classes => non-serializable superclasses

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1306/files
  - new: https://git.openjdk.java.net/jdk/pull/1306/files/ce7e6d6c..54c17ba6

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1306&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1306&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1306.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1306/head:pull/1306

PR: https://git.openjdk.java.net/jdk/pull/1306

From smarks at openjdk.java.net  Thu Nov 19 23:36:21 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Thu, 19 Nov 2020 23:36:21 GMT
Subject: RFR: 8037384: Fix wording in Javadoc of java.io.Serializable [v2]
In-Reply-To: <ev_u8Y_HvkNzzjdGNLybtMGdAsQDLdISLOWPWKc3vD8=.211c9d61-cd29-4088-ae2a-8d934892da13@github.com>
References: <j51neqpaI-7jIch45IbUQPgl9jpbAETXuTNOviNlNDs=.334da5a4-f082-46bd-aedc-56c2f18358a1@github.com>
 <ev_u8Y_HvkNzzjdGNLybtMGdAsQDLdISLOWPWKc3vD8=.211c9d61-cd29-4088-ae2a-8d934892da13@github.com>
Message-ID: <BPY0S99JioQDJANPkOQPR8qDeCmiTs1TBv35HCLRYVc=.0d9e9162-eee1-4c19-964b-c31f08e44ed5@github.com>

On Thu, 19 Nov 2020 17:11:04 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   non-serializable classes => non-serializable superclasses
>
> src/java.base/share/classes/java/io/Serializable.java line 50:
> 
>> 48:  * fields of non-serializable classes. During deserialization, the fields of
>> 49:  * non-serializable classes will be initialized using the no-arg constructor of
>> 50:  * the class. This constructor must be accessible to the subclass that is being
> 
> .. of the first non-serializable superclass.

I updated these to say "superclasses" plus a bit of other minor adjustment.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1306

From almatvee at openjdk.java.net  Fri Nov 20 00:54:07 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Fri, 20 Nov 2020 00:54:07 GMT
Subject: RFR: 8235304: JPackage Windows test should be added to set
 Publisher [v2]
In-Reply-To: <urUnIf31HFwXrmnqzHCdiEvaTuCD6Np81mXIYNYfVJw=.6d593ad6-30ef-49dc-a9c2-825284611fec@github.com>
References: <rSNe02yhqWuRXN6CWRJzEu2UHiKnjEGGjX-Qp3I6SAM=.d1b583db-8f05-4e24-898f-e6c84d820e09@github.com>
 <urUnIf31HFwXrmnqzHCdiEvaTuCD6Np81mXIYNYfVJw=.6d593ad6-30ef-49dc-a9c2-825284611fec@github.com>
Message-ID: <BGmqeCPJaIbF49NHcfkU0tYckqvYxA0EpGhv07RdB8Y=.9c5422ee-3644-4bb9-b49f-a50114583a97@github.com>

On Thu, 19 Nov 2020 22:26:20 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> 8235304: JPackage Windows test should be added to set Publisher
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'JDK-8235304' of https://github.com/alexeysemenyukoracle/jdk into JDK-8235304
>  - 8235304: JPackage Windows test should be added to set Publisher
>  - 8227400: Adjust jib profiles to make 3rd party tools for creating installers available on Mach5 test machines
>  - 8235304: JPackage Windows test should be added to set Publisher

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1331

From mchung at openjdk.java.net  Fri Nov 20 03:21:18 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 20 Nov 2020 03:21:18 GMT
Subject: RFR: 8159746: (proxy) Support for default methods [v5]
In-Reply-To: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
Message-ID: <nDwQScf9xwB0zjE7jvoVKOrz6nLfKvFgmZkT7XsCdlI=.8b582489-309f-4a27-aede-901bbd6b9bed@github.com>

> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke
> the given default method on the given proxy instance.
> 
> The implementation looks up a method handle for `invokespecial` instruction
> as if called from with the proxy class as the caller, equivalent to calling
> `X.super::m` where `X` is a proxy interface of the proxy class and
> `X.super::m` will resolve to the specified default method.
> 
> The implementation will call a private static `proxyClassLookup(Lookup caller)`
> method of the proxy class to obtain its private Lookup.  This private method
> in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class
> with full privilege access to use, or else `IllegalAccessException` will be
> thrown.
> 
> This patch also proposes to define a proxy class in an unnamed module to
> a dynamic module to strengthen encapsulation such that they are only
> unconditionally exported from a named module but not open for deep reflective
> access.  This only applies to the case if all the proxy interfaces are public
> and in a package that is exported or open.
> 
> One dynamic module is created for each class loader that defines proxies.
> The change changes the dynamic module to contain another package (same
> name as the module) that is unconditionally exported and is opened to
> `java.base` only.
> 
> There is no change to the package and module of the proxy class for
> the following cases:
> 
> - if at least one proxy interface is non-public, then the proxy class is defined
>   in the package and module of the non-public interfaces
> - if at least one proxy is in a package that is non-exported and non-open,
>   if all proxy interfaces are public, then the proxy class is defined in
>   a non-exported, non-open package of a dynamic module.
> 
> The spec change is that a proxy class used to be defined in an unnamed
> module, i.e. in a exported and open package, is defined in an unconditionally
> exported but non-open package.  Programs that assume it to be open unconditionally
> will be affected and cannot do deep reflection on such proxy classes.
> 
> Peter Levart contributed an initial prototype [1] (thanks Peter).  I think
> the exceptions could be simplified as more checking should be done prior to
> the invocation of the method handle like checking the types of the arguments
> with the method type.  This approach avoids defining a public API
> `protected Proxy::$$proxyClassLookup$$` method.  Instead it defines a
> private static method that is restricted for Proxy class to use (by
> taking a caller parameter to ensure it's a private lookup on Proxy class).
> 
> javadoc/specdiff:
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/
> 
> [1]  http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Clean up the patch.  Rename to

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/313/files
  - new: https://git.openjdk.java.net/jdk/pull/313/files/8e0248a1..8352a20b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=03-04

  Stats: 351 lines in 9 files changed: 141 ins; 78 del; 132 mod
  Patch: https://git.openjdk.java.net/jdk/pull/313.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/313/head:pull/313

PR: https://git.openjdk.java.net/jdk/pull/313

From mchung at openjdk.java.net  Fri Nov 20 03:31:04 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 20 Nov 2020 03:31:04 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v3]
In-Reply-To: <rabnopFhJQjJDpDOBnVw8CW9rNXxG4QylLQ8ViA-ZaA=.f9b25d70-a303-4781-95d7-94c7fb238f53@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
 <X-tT29dRiWaS394o3ilVhJdV0xKsZ_kwqOHhLs3wwW8=.76df07ec-25c5-44bf-a160-2a88a3cb6adf@github.com>
 <Q8qFNQxNBe6tNbPE2QJlfjVR4mY51e-1VvxyhAX9ISw=.926f5fe3-d4a2-44f5-a73f-59afd7370bb9@github.com>
 <rabnopFhJQjJDpDOBnVw8CW9rNXxG4QylLQ8ViA-ZaA=.f9b25d70-a303-4781-95d7-94c7fb238f53@github.com>
Message-ID: <mG_LH28GwHsbnZaAiZg6w8JhG4Q0dzYh3OJ_BVTKk9E=.adcaa4b3-4f8c-45c5-a6df-29b4e2594504@github.com>

On Thu, 19 Nov 2020 23:03:54 GMT, Mark Reinhold <mr at openjdk.org> wrote:

>> test/jdk/tools/launcher/modules/illegalaccess/IllegalAccessTest.java line 387:
>> 
>>> 385:                 "--illegal-access=permit");
>>> 386:     }
>>> 387: 
>> 
>> I see `setAccessibleNonPublicMemberExportedPackage` test case testing with `--add-exports` and `--add-opens` and `Add-Opens` in JAR file manifest but not testing with `Add-Exports`.
>> 
>> Is it worth to include the `Add-Exports` test case?
>> 
>> Other than this, looks good.
>
> Good point -- case added.

Looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1324

From ccheung at openjdk.java.net  Fri Nov 20 04:45:06 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 20 Nov 2020 04:45:06 GMT
Subject: RFR: 8256487: Handle disableEagerInitialization for archived
 lambda proxy classes
In-Reply-To: <TKCeZIMtAVMfv4DkQBJz7E5k6KDh9dnOmisA2OAXz_4=.4a373048-9b72-4f1f-867d-f7cf0f6a7049@github.com>
References: <H0u1_kznNSlnjVxMeZDprieQlaPLVo9tR_md-eMCzk8=.2bff07f5-39c6-47a9-a9ce-6092823e610f@github.com>
 <TKCeZIMtAVMfv4DkQBJz7E5k6KDh9dnOmisA2OAXz_4=.4a373048-9b72-4f1f-867d-f7cf0f6a7049@github.com>
Message-ID: <afZeW8g5kVZqaq71z3tRdZtazc3sJbVgoXxsBCchQp0=.8d4904bf-6c38-4817-a966-d7b9942776d1@github.com>

On Thu, 19 Nov 2020 19:42:51 GMT, Yumin Qi <minqi at openjdk.org> wrote:

>> Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set.
>> 
>> This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically:
>> 
>> - remove the above workaround;
>> 
>> - capture the setting of the property in the archive header during CDS dump time;
>> 
>> - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header.
>> If the values don't match, the archived lambda proxy class won't be used.
>> 
>> Tests:
>> 
>> - [x] ran all cds tests locally on linux-x64
>> 
>> - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64
>> 
>> - [x] mach5 tiers 1,2,3 (in progress)
>
> src/hotspot/share/memory/metaspaceShared.cpp line 76:
> 
>> 74: #endif
>> 75: 
>> 76: #include <string.h>
> 
> This include is strange, usually we do not include std head file in .cpp file.

The include is needed for strcasecmp and _stricmp.
If you do a grep like `find . -name "*.cpp" | xargs grep "#include <"`, you'll find many .cpp files include std header files.

> src/hotspot/share/memory/metaspaceShared.cpp line 1821:
> 
>> 1819: }
>> 1820: 
>> 1821: void MetaspaceShared::set_disable_eager_init(const char* value) {
> 
> strcasecmp is not platform dependent, why not use it for all? It does not need <string.h> included.

According to https://en.wikipedia.org/wiki/C_string_handling, strcasecmp is for POSIX, BSD, stricmp is for Windows.

> test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/LambdaEagerInit.java line 35:
> 
>> 33:  * @library /test/lib /test/hotspot/jtreg/runtime/cds/appcds
>> 34:  * @compile ../../../../../../jdk/java/lang/invoke/lambda/LambdaEagerInitTest.java
>> 35:  * @build sun.hotspot.WhiteBox
> 
> Do we need WB here?

Our current design is that every test under the `dynamicArchive` dir extends `DynamicArchiveTestBase` which depends on `sun.hotspot.WhiteBox`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1301

From ccheung at openjdk.java.net  Fri Nov 20 04:50:04 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 20 Nov 2020 04:50:04 GMT
Subject: Withdrawn: 8256487: Handle disableEagerInitialization for archived
 lambda proxy classes
In-Reply-To: <H0u1_kznNSlnjVxMeZDprieQlaPLVo9tR_md-eMCzk8=.2bff07f5-39c6-47a9-a9ce-6092823e610f@github.com>
References: <H0u1_kznNSlnjVxMeZDprieQlaPLVo9tR_md-eMCzk8=.2bff07f5-39c6-47a9-a9ce-6092823e610f@github.com>
Message-ID: <oDZd09xvA9QOBieTOV35zf5ti9gc2LF8IsMvUdMNhUw=.6c94a091-b60d-4e6e-ae92-4f24fd450061@github.com>

On Wed, 18 Nov 2020 23:58:25 GMT, Calvin Cheung <ccheung at openjdk.org> wrote:

> Before this change, the setting of the `jdk.internal.lambda.disableEagerInitialization` property was not captured during dumping of lambda proxy classes. There's a workaround in `LambdaProxyClassArchive.find`, it won't call `findFromArchive` if the above property is set.
> 
> This change adds handling of the `jdk.internal.lambda.disableEagerInitialization` property, specifically:
> 
> - remove the above workaround;
> 
> - capture the setting of the property in the archive header during CDS dump time;
> 
> - during runtime when finding an archived lambda proxy class, the setting of the property will be compared with the stored value in the archive header.
> If the values don't match, the archived lambda proxy class won't be used.
> 
> Tests:
> 
> - [x] ran all cds tests locally on linux-x64
> 
> - [x] ran the `hotspot_appcds_dynamic` test group with `-Dtest.dynamic.cds.archive=true` on linux-x64
> 
> - [x] mach5 tiers 1,2,3 (in progress)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1301

From ccheung at openjdk.java.net  Fri Nov 20 04:50:02 2020
From: ccheung at openjdk.java.net (Calvin Cheung)
Date: Fri, 20 Nov 2020 04:50:02 GMT
Subject: RFR: 8256487: Handle disableEagerInitialization for archived
 lambda proxy classes
In-Reply-To: <oqRXPyUXaTyJk12PhLQ7JYOfx_lCe-y047tFuVb_rKk=.14a27fb3-4f8d-4dc9-808b-d5e497f2b5cd@github.com>
References: <H0u1_kznNSlnjVxMeZDprieQlaPLVo9tR_md-eMCzk8=.2bff07f5-39c6-47a9-a9ce-6092823e610f@github.com>
 <aNddz6pf9Cs5D0M4dooQIy1Ucu8p8wDSl7kniMVr9Zo=.d0c0bf0a-9906-4c26-922d-662e5aa3462a@github.com>
 <2HAKrvsORLsNHOY10PyQ395snpigQ7t0ZhAKUVIoPlk=.0540d08a-e46a-4e80-9719-4f16acc943d2@github.com>
 <oqRXPyUXaTyJk12PhLQ7JYOfx_lCe-y047tFuVb_rKk=.14a27fb3-4f8d-4dc9-808b-d5e497f2b5cd@github.com>
Message-ID: <i7OJm2f0JCnycbRzjNWuqKh9EyAKX1ZMFs5P7Ctr3ds=.85a4c3d8-32cc-4c6f-aa50-ae4c899148e5@github.com>

On Thu, 19 Nov 2020 16:09:41 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Hi Claes,
>> 
>> Thanks for taking a look.
>> 
>> So should I keep the following `!initialize` check in LambdaProxyClassArchive?
>> 109         if (!loadedByBuiltinLoader(caller) || !initialize ||
>> 110             !CDS.isSharingEnabled() || isSerializable || markerInterfaces.length > 0 || additionalBridges.length > 0)
>> 111             return null;
>> If we keep the above code, I think we don't need to pass the `initialize` to `findFromArchive` and eventually to `JVM_LookupLambdaProxyClassFromArchive`.
>> 
>> Let me know if the above is what you have in mind?
>> 
>> thanks,
>> Calvin
>
> Right, I'd drop that argument - I would go further and suggest making calls to both `LambdaProxyClassArchive.register` and `LambdaProxyClassArchive.find` conditional on `disableEagerInitialization` being `false` to avoid any accidental mix-up and reduce complexity of these orthogonal features/concerns.

Closing this pull request. I'll file another bug to address suggestions from @cl4es and @mlchung.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1301

From dholmes at openjdk.java.net  Fri Nov 20 07:36:07 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 20 Nov 2020 07:36:07 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v3]
In-Reply-To: <zhD05EEvIGCkvHzhsUn1ede4QL3Dc4WO3EgZTUcjCwg=.509629ea-e5bf-4599-96a5-a5c9e64560ff@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
 <zhD05EEvIGCkvHzhsUn1ede4QL3Dc4WO3EgZTUcjCwg=.509629ea-e5bf-4599-96a5-a5c9e64560ff@github.com>
Message-ID: <VGOnpWw8cEUBKBRPnAL7nwUus5yuXbkGueAoxB_kpkw=.3ef4ffbc-e835-41b9-b092-ecc17def4c51@github.com>

On Thu, 19 Nov 2020 23:08:21 GMT, Mark Reinhold <mr at openjdk.org> wrote:

>> Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396).
>> Alan Bateman is the original author; I?ve credited him in the commit metadata.
>> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64.
>
> Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test

The hostpot change is trivially fine.

I'm somewhat surprised by the extent of the other changes given the basic change here is to deprecate the option and change its default. I literally expected to see only 2 simple changes to the functional code: the deprecation warning and the changing of the default value.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1324

From serb at openjdk.java.net  Fri Nov 20 07:46:15 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 20 Nov 2020 07:46:15 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?=
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>

On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From alanb at openjdk.java.net  Fri Nov 20 07:46:15 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 07:46:15 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?=
Message-ID: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>

This change terminally deprecates the following methods defined by java.lang.ThreadGroup 

- stop 
- destroy 
- isDestroyed 
- setDaemon 
- isDaemon 

The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 

The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.

CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

-------------

Commit messages:
 - Update jshell class
 - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Changes: https://git.openjdk.java.net/jdk/pull/1318/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1318&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256643
  Stats: 31 lines in 4 files changed: 28 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1318.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1318/head:pull/1318

PR: https://git.openjdk.java.net/jdk/pull/1318

From serb at openjdk.java.net  Fri Nov 20 07:46:15 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 20 Nov 2020 07:46:15 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?=
In-Reply-To: <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
Message-ID: <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>

On Thu, 19 Nov 2020 18:51:50 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Marked as reviewed by serb (Reviewer).

The changes in the awt are trivial and look fine.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From alanb at openjdk.java.net  Fri Nov 20 08:04:04 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 08:04:04 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v3]
In-Reply-To: <VGOnpWw8cEUBKBRPnAL7nwUus5yuXbkGueAoxB_kpkw=.3ef4ffbc-e835-41b9-b092-ecc17def4c51@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
 <zhD05EEvIGCkvHzhsUn1ede4QL3Dc4WO3EgZTUcjCwg=.509629ea-e5bf-4599-96a5-a5c9e64560ff@github.com>
 <VGOnpWw8cEUBKBRPnAL7nwUus5yuXbkGueAoxB_kpkw=.3ef4ffbc-e835-41b9-b092-ecc17def4c51@github.com>
Message-ID: <B6D_ew-XGq22FGdNd73BmquT2WcsHOl7ZzOoHZYbF0M=.689abf6c-ba32-40ec-9661-321602111bdd@github.com>

On Fri, 20 Nov 2020 07:33:50 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I'm somewhat surprised by the extent of the other changes given the basic change here is to deprecate the option and change its default. I literally expected to see only 2 simple changes to the functional code: the deprecation warning and the changing of the default value.

There are interactions with the archiving of the module graph and boot layer. Here's one of the mails from the review of JDK-8244778 that has more context:
https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068159.html
The summary is that, as a short term measure until JEP 396 showed up, we agreed to have the maps to support exporting and opening packages for illegal reflective acces archived with the boot layer. Switching the default allows it goes away.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1324

From sgehwolf at openjdk.java.net  Fri Nov 20 09:13:02 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 20 Nov 2020 09:13:02 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem [v2]
In-Reply-To: <gUh25m7EYRuSkBpXS0ucGKLlMgeJ1yYSiDpEWk5MlnQ=.e716cb66-8c6a-49d3-976a-1a3e03fb0b77@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
 <AyKrgbhx7vaTZAPxkWFm2v09xkgwNvI7k0uXOPQ491s=.ae331a7d-f4bd-43ff-8cb4-fca8b4c85231@github.com>
 <KV-xx-gH_9o5jKti8kX3Z5qR9kq8c1pjmxduyD7W_rU=.836f5ce5-4035-4f62-a612-ed8012339ea5@github.com>
 <YI9W6wtEOdwI8YS7Ikve5_Tf_QUIewsT7shhBqR9qrc=.84c805aa-8df1-46ec-9636-a6f9da0f5348@github.com>
 <gUh25m7EYRuSkBpXS0ucGKLlMgeJ1yYSiDpEWk5MlnQ=.e716cb66-8c6a-49d3-976a-1a3e03fb0b77@github.com>
Message-ID: <4Ej8vwGXepZmH6u30ourL3hvE1E8t4FSUK56L6LW7mM=.0e5ad12e-ac5e-406c-b18f-3f15dc7f5375@github.com>

On Thu, 19 Nov 2020 20:49:07 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> Shouldn't you add a check in src/java.base/linux/classes/jdk/internal/platform/cgroupv2/CgroupV2Subsystem.java:sumTokensIOStat ?
>> 
>> What about getLongEntry in src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemController.java?  There are streams operations occuring there as well.
>
> @bobvandette sumTokensIOStat() and getLongEntry() should also have the catch blocks, and I have added those. Please review the latest commit.

@poonamparhar Wouldn't we be able to reproduce this by a test? E.g. `test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java` It should already be checking some of this with `mountInfoFileNotFound()` and `cgroupsFileNotFound()`. Thoughts?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1303

From chegar at openjdk.java.net  Fri Nov 20 09:25:06 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 20 Nov 2020 09:25:06 GMT
Subject: RFR: 8037384: Fix wording in Javadoc of java.io.Serializable [v2]
In-Reply-To: <esaAlafgnMr5Q3L4-vnNs0U56B-8aFWRSL7dOhM_jpQ=.6aba9fc7-a506-4166-9ac6-edadfa0655e4@github.com>
References: <j51neqpaI-7jIch45IbUQPgl9jpbAETXuTNOviNlNDs=.334da5a4-f082-46bd-aedc-56c2f18358a1@github.com>
 <esaAlafgnMr5Q3L4-vnNs0U56B-8aFWRSL7dOhM_jpQ=.6aba9fc7-a506-4166-9ac6-edadfa0655e4@github.com>
Message-ID: <naPBzodmT4IId8W_De9qP8DPWJvhkKgfUKiu_Q6gzyw=.1f224f55-0805-4971-8833-e30121d86ff6@github.com>

On Thu, 19 Nov 2020 23:36:20 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> 8231547: Serializable class doc should link to serialization specification
>> 
>> Rewrite a couple confusing sentences in the Serializable class doc. This does affect normative text, but the edits are primarily to focus and clarify the text, not to make any semantic changes. Thus, a CSR request shouldn't be required for this change.
>> 
>> Also add and adjust some links and link markup to the Java Object Serialization Specification.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   non-serializable classes => non-serializable superclasses

LGTM.

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1306

From david.holmes at oracle.com  Fri Nov 20 09:29:39 2020
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 20 Nov 2020 19:29:39 +1000
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v3]
In-Reply-To: <B6D_ew-XGq22FGdNd73BmquT2WcsHOl7ZzOoHZYbF0M=.689abf6c-ba32-40ec-9661-321602111bdd@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
 <zhD05EEvIGCkvHzhsUn1ede4QL3Dc4WO3EgZTUcjCwg=.509629ea-e5bf-4599-96a5-a5c9e64560ff@github.com>
 <VGOnpWw8cEUBKBRPnAL7nwUus5yuXbkGueAoxB_kpkw=.3ef4ffbc-e835-41b9-b092-ecc17def4c51@github.com>
 <B6D_ew-XGq22FGdNd73BmquT2WcsHOl7ZzOoHZYbF0M=.689abf6c-ba32-40ec-9661-321602111bdd@github.com>
Message-ID: <c327268c-70d2-b4fe-0701-8d1a0b00fcd8@oracle.com>

Hi Alan,

On 20/11/2020 6:04 pm, Alan Bateman wrote:
> On Fri, 20 Nov 2020 07:33:50 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>> I'm somewhat surprised by the extent of the other changes given the basic change here is to deprecate the option and change its default. I literally expected to see only 2 simple changes to the functional code: the deprecation warning and the changing of the default value.
> 
> There are interactions with the archiving of the module graph and boot layer. Here's one of the mails from the review of JDK-8244778 that has more context:
> https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-August/068159.html
> The summary is that, as a short term measure until JEP 396 showed up, we agreed to have the maps to support exporting and opening packages for illegal reflective acces archived with the boot layer. Switching the default allows it goes away.

Thanks for the information. I don't understand enough to know why this 
is the case.

Cheers,
David

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1324
> 

From sgehwolf at openjdk.java.net  Fri Nov 20 09:31:04 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 20 Nov 2020 09:31:04 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem [v3]
In-Reply-To: <85FtEQ4pR0Y6nbxnbUOvLMCKBi_fkua5rWV0nGZ4ih0=.f7019fa1-38d1-4209-94d4-fa9a488ac16a@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
 <85FtEQ4pR0Y6nbxnbUOvLMCKBi_fkua5rWV0nGZ4ih0=.f7019fa1-38d1-4209-94d4-fa9a488ac16a@github.com>
Message-ID: <Z168APCzt9KgpJD-CQy_WW6Z5152MkDmMJCovDxBMGc=.f2771fd7-fc63-4bdd-90c9-a679056a77f6@github.com>

On Thu, 19 Nov 2020 20:49:16 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this simple change that catches UncheckedIOException that can occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the system, or if there is an interrupt while these are being read.
>> 
>> Testing: Tier1, Tier2 and Tier3.
>> 
>> Thanks,
>> Poonam
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added UnchedkedIOException catch blocks for sumTokensIOStat and getLongEntry methods

This seems OK. Ideally, I'd like for this to be tested. If it's interrupts it's going to be difficult. Missing files should be easy enough to test.

Aside: We really need to streamline file reading. We have too many of them unnecessarily all over the place. [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) should fix that. I'll prioritize it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1303

From ccleary at openjdk.java.net  Fri Nov 20 09:36:05 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 20 Nov 2020 09:36:05 GMT
Subject: RFR: 8256154: Some TestNG tests require default constructors
In-Reply-To: <j38LRrH7R81qppkPHFD0Wx4cnV71OACVDf0zcgV1ikA=.a0911f00-6e28-4ddd-9d0b-18ef735d4f75@github.com>
References: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
 <j38LRrH7R81qppkPHFD0Wx4cnV71OACVDf0zcgV1ikA=.a0911f00-6e28-4ddd-9d0b-18ef735d4f75@github.com>
Message-ID: <Wd52F5nIBASkdsinWgnKXY2G-2vEh_3t8278VX3bpTA=.21034638-335f-4da0-a7bc-d2104c49a711@github.com>

On Thu, 19 Nov 2020 15:09:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi Conor,
> 
> Were you able to verify that the two tests passed properly (and non trivially) with both the current version of TestNG as well as the new version?
> 
> best regards,
> 
> -- daniel

Hi Daniel,

Yes, I was able to verify that the tests do indeed fail with TestNG 7.1

7.1 is the version that is currently specified with the latest Jtreg build, see L54 in https://github.com/openjdk/jtreg/blob/master/make/build-support/version-numbers

Tests failed across Mac, Linux and Windows platforms with `org.testng.TestNGException: An error occurred while instantiating class SomeTestClass. Check to make sure it can be instantiated
` 

However when modified as in this PR, they pass.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1317

From ccleary at openjdk.java.net  Fri Nov 20 09:41:04 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 20 Nov 2020 09:41:04 GMT
Subject: RFR: 8256154: Some TestNG tests require default constructors
In-Reply-To: <Qp2XdY9vs_jdrRcH2cFmC9jYxTWpCWHJWPeb2nytpd0=.d316f2b3-25a8-4400-b160-bd8f7ee863ad@github.com>
References: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
 <a9qdJkFWZEQJ0119IvnStmBuu3VFDjmGm2ndTGFlL1I=.a11cbaba-fdc6-4cee-9677-e5aceba3803e@github.com>
 <l9_jB3QgFlof8hGMnFuVAq8j6Iq3s2NGhVuavSx2ZKc=.d007de65-3a00-4862-a9f1-5b55632f1877@github.com>
 <Qp2XdY9vs_jdrRcH2cFmC9jYxTWpCWHJWPeb2nytpd0=.d316f2b3-25a8-4400-b160-bd8f7ee863ad@github.com>
Message-ID: <wK9Xbe8aV_W4R3ZHJIL4eYLs8LjZpjYKmpqwHIu9wjQ=.1b9083e0-8c86-4ae2-b468-0270a213be10@github.com>

On Thu, 19 Nov 2020 16:44:52 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> `depth` is `final`, so it needs to be assigned. but this could be replaced with `this(0)`
>
> Ah, missed the final on depth :-)

Any particular strengths associated with `this(0)` as opposed to the actual assignment? Aside from the brevity it provides of course. Happy to modify the PR to include it

-------------

PR: https://git.openjdk.java.net/jdk/pull/1317

From github.com+74766043+sergus13 at openjdk.java.net  Fri Nov 20 10:06:08 2020
From: github.com+74766043+sergus13 at openjdk.java.net (sergus13)
Date: Fri, 20 Nov 2020 10:06:08 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently [v2]
In-Reply-To: <L2ZJDD2MxcN4n2bgzpupNVer8cBbCImp8P35KfEZRk4=.b92861d5-b700-4760-bbb8-f020208c8aa6@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
 <L2ZJDD2MxcN4n2bgzpupNVer8cBbCImp8P35KfEZRk4=.b92861d5-b700-4760-bbb8-f020208c8aa6@github.com>
Message-ID: <SW93lnQhIPCOmg4rmtIEAt0PS-IyoT-UGNOS9lsf_34=.1d153e7c-145e-4b35-a053-6f2799985bce@github.com>

On Thu, 19 Nov 2020 20:20:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this modification of `java.io.InputStream.skipNBytes(long)` to improve its performance when `skip(long)` skips fewer than the requested number of bytes. In the current implementation, `skip(long)` is invoked once and, if not enough bytes have been skipped, then `read()` is invoked for each of the remaining bytes to be skipped. The proposed implementation instead repeatedly invokes `skip(long)` until the requested number of bytes has been skipped, or an error condition is encountered. For cases where `skip(long)` skips fewer bytes than the number requested, the new version was measured to be up to more than one thousand times faster than the old version. When `skip(long)` actually skips the requested number of bytes, the performance difference is insignificant.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8246739: InputStream.skipNBytes could be implemented more efficiently
>  - 8246739: InputStream.skipNBytes could be implemented more efficiently

src/java.base/share/classes/java/io/InputStream.java line 607:

> 605:                 if (read() < 0) {
> 606:                     throw new EOFException();
> 607:                 }

Shouldn't we decrement "n" in case "read" returns non-negative value?

                if (read() < 0) {
                    throw new EOFException();
                } else {
                    n--;
                }
`

-------------

PR: https://git.openjdk.java.net/jdk/pull/1329

From github.com+74766043+sergus13 at openjdk.java.net  Fri Nov 20 10:06:10 2020
From: github.com+74766043+sergus13 at openjdk.java.net (sergus13)
Date: Fri, 20 Nov 2020 10:06:10 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently [v2]
In-Reply-To: <SW93lnQhIPCOmg4rmtIEAt0PS-IyoT-UGNOS9lsf_34=.1d153e7c-145e-4b35-a053-6f2799985bce@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
 <L2ZJDD2MxcN4n2bgzpupNVer8cBbCImp8P35KfEZRk4=.b92861d5-b700-4760-bbb8-f020208c8aa6@github.com>
 <SW93lnQhIPCOmg4rmtIEAt0PS-IyoT-UGNOS9lsf_34=.1d153e7c-145e-4b35-a053-6f2799985bce@github.com>
Message-ID: <NbBBSmv3utXdkBGBSOV1DTxRC44bHy5Q-asnIne2PEA=.1f48c0c7-caa0-4858-828b-4a4a1ac20dc8@github.com>

On Fri, 20 Nov 2020 09:56:16 GMT, sergus13 <github.com+74766043+sergus13 at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8246739: InputStream.skipNBytes could be implemented more efficiently
>>  - 8246739: InputStream.skipNBytes could be implemented more efficiently
>
> src/java.base/share/classes/java/io/InputStream.java line 607:
> 
>> 605:                 if (read() < 0) {
>> 606:                     throw new EOFException();
>> 607:                 }
> 
> Shouldn't we decrement "n" in case "read" returns non-negative value?
> 
>                 if (read() < 0) {
>                     throw new EOFException();
>                 } else {
>                     n--;
>                 }
> `

One more notice here. Wouldn't it be better to compare value returned by read method with -1 (as it was before)?
Since documentation of read method says:
_Returns:
    the next byte of data, or -1 if the end of the stream is reached._

`
            if (read() != -1) {
                throw new EOFException();
            } else {
                n--;
            }
`

-------------

PR: https://git.openjdk.java.net/jdk/pull/1329

From plevart at openjdk.java.net  Fri Nov 20 10:58:04 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 20 Nov 2020 10:58:04 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <LrmZFLofpx4ewPC-GKlK9Z3xjIi4PrFLpOUL8qz6SJg=.ce86cf0c-c579-4d26-b68f-29b656ab78d3@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
 <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
 <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
 <3_3xp4MbiLH-_9zyTkLVKZKP3ds0AftAVtbWo8tYeFs=.483fa478-0e33-495d-a545-b2339ecee592@github.com>
 <X93bQ76ydubQKGZAlD4ub43vTBHXjwnXQx--UN5xgus=.5e2ddf9d-86a5-4c34-b53a-65daff1d43df@github.com>
 <mthe4gxs2yOuXitvRF4Cwzbk4LLamGCDlx
 TaQJdRo_g=.edaa421c-e144-4466-a07f-251da9357364@github.com>
 <LrmZFLofpx4ewPC-GKlK9Z3xjIi4PrFLpOUL8qz6SJg=.ce86cf0c-c579-4d26-b68f-29b656ab78d3@github.com>
Message-ID: <Xj3UDUQX-_oljQZ4TvbAcCeCKTL7Dz2PVsidXRQjywY=.921b1537-b302-4e88-9f91-c0b8c2d6c28f@github.com>

On Wed, 28 Oct 2020 20:13:19 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Hi Remi,
>> 
>> I appreciate your proposal to modernize Proxy API.   There are several requests for this enhancement to support default methods in Proxy.   Defining a new `java.lang.invoke.Proxy` is a much bigger project that I can't tell when the existing users of `java.lang.reflect.Proxy` will be able to get this default method invocation support.  
>> 
>> I do agree that this API design has many challenges caused by what you listed above.   Well, I believe we are very close to have a consensus:
>> 1. New `newProxyInstance` factory method takes a handler factory doing the access check
>> 2. Update `getInvocationHandler` to throw `InaccessibleInvocationHandlerException` if access denied to get an invocation handler associated with the proxy instance
>> 
>> If this needs more time, I think I will consider to shelf this RFE and come back to it later (and consider your proposal as well).
>
> The trick is that if we know that a class like java.lang.invoke.Proxy may exist,
> it means that instead of distorting the j.l.r.Proxy API to increase of few percents the performance when calling a default method, you can come with a simpler design in term of API that just add an API point to call a default method.
> 
> Better performance becoming on the the goals of java.lang.invoke.Proxy.

Hi Mandy,
I re-ran the benchmark on your latest version (the static API) and I get similar results as you:

Benchmark               Mode  Cnt   Score   Error  Units
ProxyBench.implClass    avgt    5   3.745 ? 0.033  ns/op
ProxyBench.implProxy    avgt    5  29.826 ? 0.183  ns/op
ProxyBench.ppImplClass  avgt    5   3.683 ? 0.009  ns/op
ProxyBench.ppImplProxy  avgt    5  29.124 ? 0.535  ns/op

I also tried a variant where the access check in the invokeDefault static method in not pre-screened with checking of the interface modifiers and package export status but relies on Method.checkAccess cache:

        // access check
        Class<?> caller = Reflection.getCallerClass();
        int modifiers = method.getModifiers();
        method.checkAccess(caller, intf, proxyClass, modifiers);

... and the results are not worse, even marginally better:

Benchmark               Mode  Cnt   Score   Error  Units
ProxyBench.implClass    avgt    5   3.724 ? 0.012  ns/op
ProxyBench.implProxy    avgt    5  29.138 ? 0.271  ns/op
ProxyBench.ppImplClass  avgt    5   3.744 ? 0.009  ns/op
ProxyBench.ppImplProxy  avgt    5  28.961 ? 0.182  ns/op

I think this looks reasonably good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From plevart at openjdk.java.net  Fri Nov 20 11:21:03 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 20 Nov 2020 11:21:03 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <Xj3UDUQX-_oljQZ4TvbAcCeCKTL7Dz2PVsidXRQjywY=.921b1537-b302-4e88-9f91-c0b8c2d6c28f@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
 <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
 <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
 <3_3xp4MbiLH-_9zyTkLVKZKP3ds0AftAVtbWo8tYeFs=.483fa478-0e33-495d-a545-b2339ecee592@github.com>
 <X93bQ76ydubQKGZAlD4ub43vTBHXjwnXQx--UN5xgus=.5e2ddf9d-86a5-4c34-b53a-65daff1d43df@github.com>
 <mthe4gxs2yOuXitvRF4Cwzbk4LLamGCDlx
 TaQJdRo_g=.edaa421c-e144-4466-a07f-251da9357364@github.com>
 <LrmZFLofpx4ewPC-GKlK9Z3xjIi4PrFLpOUL8qz6SJg=.ce86cf0c-c579-4d26-b68f-29b656ab78d3@github.com>
 <Xj3UDUQX-_oljQZ4TvbAcCeCKTL7Dz2PVsidXRQjywY=.921b1537-b302-4e88-9f91-c0b8c2d6c28f@github.com>
Message-ID: <tpLs_qejlYlXcAeQNbsooyUHtIhKfzT9cLEyIymJM6E=.873923fa-bbaa-4a76-a9c1-a70ce8f98dfa@github.com>

On Fri, 20 Nov 2020 10:55:21 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> The trick is that if we know that a class like java.lang.invoke.Proxy may exist,
>> it means that instead of distorting the j.l.r.Proxy API to increase of few percents the performance when calling a default method, you can come with a simpler design in term of API that just add an API point to call a default method.
>> 
>> Better performance becoming on the the goals of java.lang.invoke.Proxy.
>
> Hi Mandy,
> I re-ran the benchmark on your latest version (the static API) and I get similar results as you:
> 
> Benchmark               Mode  Cnt   Score   Error  Units
> ProxyBench.implClass    avgt    5   3.745 ? 0.033  ns/op
> ProxyBench.implProxy    avgt    5  29.826 ? 0.183  ns/op
> ProxyBench.ppImplClass  avgt    5   3.683 ? 0.009  ns/op
> ProxyBench.ppImplProxy  avgt    5  29.124 ? 0.535  ns/op
> 
> I also tried a variant where the access check in the invokeDefault static method is not pre-screened with checking of the interface modifiers and package export status but relies on Method.checkAccess cache alone:
> 
>         // access check
>         Class<?> caller = Reflection.getCallerClass();
>         int modifiers = method.getModifiers();
>         method.checkAccess(caller, intf, proxyClass, modifiers);
> 
> ... and the results are not worse, even marginally better:
> 
> Benchmark               Mode  Cnt   Score   Error  Units
> ProxyBench.implClass    avgt    5   3.724 ? 0.012  ns/op
> ProxyBench.implProxy    avgt    5  29.138 ? 0.271  ns/op
> ProxyBench.ppImplClass  avgt    5   3.744 ? 0.009  ns/op
> ProxyBench.ppImplProxy  avgt    5  28.961 ? 0.182  ns/op
> 
> I think this looks reasonably good.

In my previous attempts when I was modifying the ProxyGenerator I noticed that generated proxy fields holding Method objects are just "static" but could be "static final". If they were "static final", JIT could constant-fold the Method instances. If this was combined with marking some fields in Method as @Stable, this could improve optimization of code a bit further. I did this with the following patch:

Index: src/java.base/share/classes/java/lang/reflect/InvocationHandler.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- src/java.base/share/classes/java/lang/reflect/InvocationHandler.java	(revision 8352a20bf54a085a97d3f703b5dab482d3f9eccc)
+++ src/java.base/share/classes/java/lang/reflect/InvocationHandler.java	(date 1605869089804)
@@ -271,15 +271,10 @@
             throw new IllegalArgumentException(""" + method + "" is not a default method");
         }
         Class<?> intf = method.getDeclaringClass();
-        // access check if it is a non-public proxy interface or not unconditionally exported
-        if (!Modifier.isPublic(intf.getModifiers()) ||
-                !intf.getModule().isExported(intf.getPackageName())) {
-            // throw IAE if the caller class has no access to the default method
-            // same access check to Method::invoke on the default method
-            int modifiers = method.getModifiers();
-            Class<?> caller = Reflection.getCallerClass();
-            method.checkAccess(caller, intf, proxyClass, modifiers);
-        }
+        // access check
+        Class<?> caller = Reflection.getCallerClass();
+        int modifiers = method.getModifiers();
+        method.checkAccess(caller, intf, proxyClass, modifiers);
 
         MethodHandle mh = Proxy.defaultMethodHandle(proxyClass, method);
         // invoke the super method
Index: src/java.base/share/classes/java/lang/reflect/Method.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- src/java.base/share/classes/java/lang/reflect/Method.java	(revision 8352a20bf54a085a97d3f703b5dab482d3f9eccc)
+++ src/java.base/share/classes/java/lang/reflect/Method.java	(date 1605870445135)
@@ -31,6 +31,7 @@
 import jdk.internal.reflect.Reflection;
 import jdk.internal.vm.annotation.ForceInline;
 import jdk.internal.vm.annotation.IntrinsicCandidate;
+import jdk.internal.vm.annotation.Stable;
 import sun.reflect.annotation.ExceptionProxy;
 import sun.reflect.annotation.TypeNotPresentExceptionProxy;
 import sun.reflect.generics.repository.MethodRepository;
@@ -66,7 +67,7 @@
  * @since 1.1
  */
 public final class Method extends Executable {
-    private Class<?>            clazz;
+    @Stable private Class<?>    clazz;
     private int                 slot;
     // This is guaranteed to be interned by the VM in the 1.4
     // reflection implementation
@@ -74,7 +75,7 @@
     private Class<?>            returnType;
     private Class<?>[]          parameterTypes;
     private Class<?>[]          exceptionTypes;
-    private int                 modifiers;
+    @Stable private int         modifiers;
     // Generics and annotations support
     private transient String              signature;
     // generic info repository; lazily initialized
Index: src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java	(revision 8352a20bf54a085a97d3f703b5dab482d3f9eccc)
+++ src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java	(date 1605870027579)
@@ -490,7 +490,7 @@
         for (List<ProxyMethod> sigmethods : proxyMethods.values()) {
             for (ProxyMethod pm : sigmethods) {
                 // add static field for the Method object
-                visitField(Modifier.PRIVATE | Modifier.STATIC, pm.methodFieldName,
+                visitField(Modifier.PRIVATE | Modifier.STATIC | Modifier.FINAL, pm.methodFieldName,
                         LJLR_METHOD, null, null);
 
                 // Generate code for proxy method

...and this makes the following results:

Benchmark               Mode  Cnt   Score   Error  Units
ProxyBench.implClass    avgt    5   3.766 ? 0.040  ns/op
ProxyBench.implProxy    avgt    5  26.847 ? 0.626  ns/op
ProxyBench.ppImplClass  avgt    5   3.700 ? 0.017  ns/op
ProxyBench.ppImplProxy  avgt    5  26.322 ? 0.048  ns/op

But this can be changed as a follow-up patch that also takes care of Constructor and Field.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From github.com+74766043+sergus13 at openjdk.java.net  Fri Nov 20 11:47:11 2020
From: github.com+74766043+sergus13 at openjdk.java.net (sergus13)
Date: Fri, 20 Nov 2020 11:47:11 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently [v2]
In-Reply-To: <L2ZJDD2MxcN4n2bgzpupNVer8cBbCImp8P35KfEZRk4=.b92861d5-b700-4760-bbb8-f020208c8aa6@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
 <L2ZJDD2MxcN4n2bgzpupNVer8cBbCImp8P35KfEZRk4=.b92861d5-b700-4760-bbb8-f020208c8aa6@github.com>
Message-ID: <--HOexGX8-_Sc7boGjeJ0T1u6N8X51SG7bERCEf7eZM=.c480bae4-741e-4eb4-85b2-b5865bed9847@github.com>

On Thu, 19 Nov 2020 20:20:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review this modification of `java.io.InputStream.skipNBytes(long)` to improve its performance when `skip(long)` skips fewer than the requested number of bytes. In the current implementation, `skip(long)` is invoked once and, if not enough bytes have been skipped, then `read()` is invoked for each of the remaining bytes to be skipped. The proposed implementation instead repeatedly invokes `skip(long)` until the requested number of bytes has been skipped, or an error condition is encountered. For cases where `skip(long)` skips fewer bytes than the number requested, the new version was measured to be up to more than one thousand times faster than the old version. When `skip(long)` actually skips the requested number of bytes, the performance difference is insignificant.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8246739: InputStream.skipNBytes could be implemented more efficiently
>  - 8246739: InputStream.skipNBytes could be implemented more efficiently

src/java.base/share/classes/java/io/InputStream.java line 605:

> 603:             } else if (ns == 0) { // no bytes skipped
> 604:                 // read one byte to check for EOS
> 605:                 if (read() < 0) {

Wouldn't it be better to compare return value with -1 (as it was before)?
Since the documentation of read method says:
_Returns:
    the next byte of data, or **-1 if the end of the stream is reached**._

-------------

PR: https://git.openjdk.java.net/jdk/pull/1329

From alanb at openjdk.java.net  Fri Nov 20 13:11:05 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 13:11:05 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v3]
In-Reply-To: <mG_LH28GwHsbnZaAiZg6w8JhG4Q0dzYh3OJ_BVTKk9E=.adcaa4b3-4f8c-45c5-a6df-29b4e2594504@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
 <X-tT29dRiWaS394o3ilVhJdV0xKsZ_kwqOHhLs3wwW8=.76df07ec-25c5-44bf-a160-2a88a3cb6adf@github.com>
 <Q8qFNQxNBe6tNbPE2QJlfjVR4mY51e-1VvxyhAX9ISw=.926f5fe3-d4a2-44f5-a73f-59afd7370bb9@github.com>
 <rabnopFhJQjJDpDOBnVw8CW9rNXxG4QylLQ8ViA-ZaA=.f9b25d70-a303-4781-95d7-94c7fb238f53@github.com>
 <mG_LH28GwHsbnZaAiZg6w8JhG4Q0dzYh3OJ_BVTKk9E=.adcaa4b3-4f8c-45c5-a6df-29b4e2594504@github.com>
Message-ID: <w6idTrBiUy8FDPXKT1fj531pbZjCfa-Y_391HeB0GTE=.50c9e124-63a7-4b15-bef5-bc69db7aaf30@github.com>

On Fri, 20 Nov 2020 03:27:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Good point -- case added.
>
> Looks good.

testWithAddExportsInManifest create an executable JAR with "Add-Exports: java.base/sun.security.x509" in the manifest. It runs it twice, once without any options, the second with --illegal-access=permit, and checks there are no warnings in both cases. To test attempted deep reflection here would need the equivalent of setAccessibleNonPublicMemberNonExportedPackage that tries to access some privates in sun.security.x509. It's okay to use setAccessibleNonPublicMemberNonExportedPackage to test that privates in sun.nio.ch aren't accessible but it's not connected to the Add-Exports attribute in the JAR file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1324

From redestad at openjdk.java.net  Fri Nov 20 13:41:03 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 20 Nov 2020 13:41:03 GMT
Subject: RFR: 8229845: Decrease memory consumption of BigInteger.toString()
In-Reply-To: <qkFujixJVxpi0TiGRI-qlXz1vBvSw559crPPQdneNKI=.acc233b6-4b0f-42f5-9b54-37d5da85a7be@github.com>
References: <QcssqDSre9zJ5L6fYGesmxienoFDYDebNM2fJUMe_bw=.3236bd5c-5900-4c0b-9e00-21a7bf24b9b4@github.com>
 <qkFujixJVxpi0TiGRI-qlXz1vBvSw559crPPQdneNKI=.acc233b6-4b0f-42f5-9b54-37d5da85a7be@github.com>
Message-ID: <dSXDGqE6NSvRT6DoiW8kIYxpYQsIwXNS9x2sl0OonX4=.8b4f3a36-40e7-4b35-a183-3d86955bf20b@github.com>

On Fri, 23 Oct 2020 08:19:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Please review this proposed fix. The review was initially in this thread
>> 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061914.html
>> 
>> under the old Hg SCM. The changes proposed here are derived from the final (.05) patch in the previous review which was posted in
>> 
>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062012.html.
>
> LGTM.
> 
> A microbenchmark or something that summarizes the improvement and can verify that we don't regress on some variant would've been nice.

What's the hold-up on this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/819

From mullan at openjdk.java.net  Fri Nov 20 14:10:05 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 20 Nov 2020 14:10:05 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?=
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <knW1V0OnHSYpmU66-hNTgSAr0HMTg1QaDF5fwV9A9sQ=.97d035ce-42a3-4103-ab8f-35c200b4ac48@github.com>

On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

src/java.base/share/classes/java/lang/ThreadGroup.java line 191:

> 189:      * @deprecated Destroying a thread group and its subgroups is not an atomic
> 190:      *             operation and is inherently racy with respect to threads that
> 191:      *             have been created but not have started. The concept of daemon

"a daemon group" sounds better to me.

src/java.base/share/classes/java/lang/ThreadGroup.java line 208:

> 206:      * @deprecated Destroying a thread group and its subgroups is not an atomic
> 207:      *             operation and is inherently racy with respect to threads that
> 208:      *             have been created but not have started. The ability to explicitly

"have not started"

src/java.base/share/classes/java/lang/ThreadGroup.java line 237:

> 235:      * @deprecated Destroying a thread group and its subgroups is not an atomic
> 236:      *             operation and is inherently racy with respect to threads that
> 237:      *             have been created but not have started. The concept of daemon

same comment as above - "a daemon group"

src/java.base/share/classes/java/lang/ThreadGroup.java line 790:

> 788:      * @deprecated Destroying a thread group and its subgroups is not an atomic
> 789:      *             operation and is inherently racy with respect to threads that
> 790:      *             have been created but not have started. The ability to explicitly

"have not started"

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From mullan at openjdk.java.net  Fri Nov 20 14:10:01 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 20 Nov 2020 14:10:01 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?=
In-Reply-To: <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
 <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>
Message-ID: <S51-ecuyQ54MBq01TepG1IMNwWcSMWC9uiT_f4ZQESU=.bf2f83e8-5db9-4873-9882-c97b7a244946@github.com>

On Thu, 19 Nov 2020 18:53:09 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Marked as reviewed by serb (Reviewer).
>
> The changes in the awt are trivial and look fine.

I think it would be useful in the javadoc of the RuntimePermission targets (stopThread, etc) to add a note/link that the corresponding method that the permission applies to is terminally deprecated. Something as simple as "Note that the Thread.stop() method is terminally deprecated and will be deprecated in a future release."

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From alanb at openjdk.java.net  Fri Nov 20 14:45:07 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 14:45:07 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?=
In-Reply-To: <knW1V0OnHSYpmU66-hNTgSAr0HMTg1QaDF5fwV9A9sQ=.97d035ce-42a3-4103-ab8f-35c200b4ac48@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <knW1V0OnHSYpmU66-hNTgSAr0HMTg1QaDF5fwV9A9sQ=.97d035ce-42a3-4103-ab8f-35c200b4ac48@github.com>
Message-ID: <KAvIXZnGXNYBRq6b5pHas8eRZVibi1SqrFFI-sLBJVE=.ae7983a5-9847-4674-9c3b-6799995f510f@github.com>

On Fri, 20 Nov 2020 14:05:09 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> src/java.base/share/classes/java/lang/ThreadGroup.java line 191:
> 
>> 189:      * @deprecated Destroying a thread group and its subgroups is not an atomic
>> 190:      *             operation and is inherently racy with respect to threads that
>> 191:      *             have been created but not have started. The concept of daemon
> 
> "a daemon group" sounds better to me.

The existing spec uses "daemon thread group" so I'd prefer to stick with that.

> src/java.base/share/classes/java/lang/ThreadGroup.java line 208:
> 
>> 206:      * @deprecated Destroying a thread group and its subgroups is not an atomic
>> 207:      *             operation and is inherently racy with respect to threads that
>> 208:      *             have been created but not have started. The ability to explicitly
> 
> "have not started"

Thanks, there's a typo there.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From alanb at openjdk.java.net  Fri Nov 20 14:52:07 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 14:52:07 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?=
In-Reply-To: <S51-ecuyQ54MBq01TepG1IMNwWcSMWC9uiT_f4ZQESU=.bf2f83e8-5db9-4873-9882-c97b7a244946@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
 <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>
 <S51-ecuyQ54MBq01TepG1IMNwWcSMWC9uiT_f4ZQESU=.bf2f83e8-5db9-4873-9882-c97b7a244946@github.com>
Message-ID: <RmLft_qv51ThYdWa5EleLBhHRK4i_DnhzLMsZX9jS48=.bca371ab-52bc-473b-9fbf-b8add5895e24@github.com>

On Fri, 20 Nov 2020 14:03:20 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> I think it would be useful in the javadoc of the RuntimePermission targets (stopThread, etc) to add a note/link that the corresponding method that the permission applies to is terminally deprecated. Something as simple as "Note that the Thread.stop() method is terminally deprecated and will be removed in a future release."

We haven't changed Thread.stop here, I would like to get that done too but as separate issue because it will require wider discussion. The main thing for now is the prep work before proposing to shove ThreadGroup to the side.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From vlivanov at openjdk.java.net  Fri Nov 20 15:00:18 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Fri, 20 Nov 2020 15:00:18 GMT
Subject: RFR: 8254231: Implementation of Foreign Linker API (Incubator)
 [v28]
In-Reply-To: <inO41H3BnOw6gl33yBAiVNs3DTh_sFWGmHbbRoovhPs=.d2ce516d-6a47-41fc-9411-2f326ea75550@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
 <inO41H3BnOw6gl33yBAiVNs3DTh_sFWGmHbbRoovhPs=.d2ce516d-6a47-41fc-9411-2f326ea75550@github.com>
Message-ID: <QLMFHXVoo5zEL4WhOhp6Mj7Cwcmauat6sv0i7u9-S4Q=.c71bd693-2e2b-4c39-aca4-8b245348454e@github.com>

On Tue, 17 Nov 2020 11:49:26 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
>> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
>> 
>> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
>> 
>> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
>> 
>> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
>> 
>> Thanks
>> Maurizio
>> 
>> Webrev:
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
>> 
>> Javadoc:
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
>> 
>> Specdiff (relative to [3]):
>> 
>> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
>> 
>> CSR:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8254232
>> 
>> 
>> 
>> ### API Changes
>> 
>> The API changes are actually rather slim:
>> 
>> * `LibraryLookup`
>>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
>> * `FunctionDescriptor`
>>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
>> * `CLinker`
>>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
>> * `NativeScope`
>>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
>> * `MemorySegment`
>>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
>> 
>> ### Safety
>> 
>> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
>> 
>> ### Implementation changes
>> 
>> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
>> 
>> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
>> 
>> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
>> 
>> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
>> 
>> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
>> 
>> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
>> 
>> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
>> 
>> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
>> 
>> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
>> 
>> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
>> 
>> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
>> 
>> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
>> 
>> Again, for more readings on the internals of the foreign linker support, please refer to [5].
>> 
>> #### Test changes
>> 
>> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
>> 
>> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
>> 
>> [1] - https://openjdk.java.net/jeps/389
>> [2] - https://openjdk.java.net/jeps/393
>> [3] - https://git.openjdk.java.net/jdk/pull/548
>> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
>> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 95 commits:
> 
>  - Merge branch 'master' into 8254231_linker
>  - Add `final` modifier on NativeLibraries.defaultLookup
>  - Fix aarch64 test failure
>  - Fix signature mismatch on aarch64
>  - Merge pull request #9 from JornVernee/Windows_Warnings
>    
>    Fix warnings on MSVC
>  - Fix warnings on MSVC
>  - Merge pull request #8 from JornVernee/Vlad_Comments
>    
>    Address More Review comments
>  - - Don't print anything in nmehtod debug output for native invoker if there are none.
>    - Use memcpy to copy native stubs to nmethod data
>  - Simplify print code
>  - Merge branch '8254231_linker' into Vlad_Comments
>  - ... and 85 more: https://git.openjdk.java.net/jdk/compare/a7422ac2...40bd5df1

Compiler changes look good.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/634

From alanb at openjdk.java.net  Fri Nov 20 15:08:27 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 15:08:27 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Fixed typo in @deprecated text
 - Merge
 - Update jshell class
 - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1318/files
  - new: https://git.openjdk.java.net/jdk/pull/1318/files/c661861a..ca656ba1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1318&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1318&range=00-01

  Stats: 99634 lines in 382 files changed: 45266 ins; 43186 del; 11182 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1318.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1318/head:pull/1318

PR: https://git.openjdk.java.net/jdk/pull/1318

From poonam at openjdk.java.net  Fri Nov 20 15:13:03 2020
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Fri, 20 Nov 2020 15:13:03 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem [v3]
In-Reply-To: <Z168APCzt9KgpJD-CQy_WW6Z5152MkDmMJCovDxBMGc=.f2771fd7-fc63-4bdd-90c9-a679056a77f6@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
 <85FtEQ4pR0Y6nbxnbUOvLMCKBi_fkua5rWV0nGZ4ih0=.f7019fa1-38d1-4209-94d4-fa9a488ac16a@github.com>
 <Z168APCzt9KgpJD-CQy_WW6Z5152MkDmMJCovDxBMGc=.f2771fd7-fc63-4bdd-90c9-a679056a77f6@github.com>
Message-ID: <_qrTRIU0lAHjBsBYFPX-iyYVOhkrIjgChMxBiW2L5HY=.8397ccc1-b245-47bb-823f-bfb81e0fe6d7@github.com>

On Fri, 20 Nov 2020 09:27:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added UnchedkedIOException catch blocks for sumTokensIOStat and getLongEntry methods
>
> This seems OK. Ideally, I'd like for this to be tested. If it's interrupts it's going to be difficult. Missing files should be easy enough to test.
> 
> Aside: We really need to streamline file reading. We have too many of them unnecessarily all over the place. [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) should fix that. I'll prioritize it.

@jerboaa Thanks for the review. As for the missing files, looks like mountInfoFileNotFound() and cgroupsFileNotFound() should be testing it. 

This issue is being faced by a customer and they encountered failures due to interrupts during reading. These changes have been verified by them.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1303

From mullan at openjdk.java.net  Fri Nov 20 15:23:06 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 20 Nov 2020 15:23:06 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <RmLft_qv51ThYdWa5EleLBhHRK4i_DnhzLMsZX9jS48=.bca371ab-52bc-473b-9fbf-b8add5895e24@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <OEpB4UP0XDo5jYzWqNKoyPVzv9VcQvzdQCjF9S9w7j8=.8c7c2ce9-a9f8-4acb-b1f6-a2ceb0f0d25c@github.com>
 <_RP0iviwL3M-gRNDjdm_5I97T3V0SH1bMdrq4in4l6M=.ee1ab82e-9e1c-4d27-94c6-7c17eccbd51c@github.com>
 <S51-ecuyQ54MBq01TepG1IMNwWcSMWC9uiT_f4ZQESU=.bf2f83e8-5db9-4873-9882-c97b7a244946@github.com>
 <RmLft_qv51ThYdWa5EleLBhHRK4i_DnhzLMsZX9jS48=.bca371ab-52bc-473b-9fbf-b8add5895e24@github.com>
Message-ID: <6PdDak1NVV78CaUuKR8Xl6wVwSvVcCZyPHYcE8LytmY=.3831f142-9fc4-44bf-b0c1-ac45d20b7716@github.com>

On Fri, 20 Nov 2020 14:49:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > I think it would be useful in the javadoc of the RuntimePermission targets (stopThread, etc) to add a note/link that the corresponding method that the permission applies to is terminally deprecated. Something as simple as "Note that the Thread.stop() method is terminally deprecated and will be removed in a future release."
> 
> We haven't changed Thread.stop here, I would like to get that done too but as separate issue because it will require wider discussion. The main thing for now is the prep work before proposing to shove ThreadGroup to the side.

Ok, but then how about putting a similar note in the javadoc for the RuntimePermission "modifyThreadGroup" target?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From rriggs at openjdk.java.net  Fri Nov 20 15:30:06 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 20 Nov 2020 15:30:06 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
Message-ID: <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>

On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/java/lang/ThreadGroup.java line 194:

> 192:      *             thread group that is automatically destroyed will be removed
> 193:      *             in a future release.
> 194:      */

I would switch the order of the sentences.  Put the action first and the rationale second. $.02
(in all the @ deprecated javadoc).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From sgehwolf at openjdk.java.net  Fri Nov 20 15:53:08 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 20 Nov 2020 15:53:08 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem [v3]
In-Reply-To: <Z168APCzt9KgpJD-CQy_WW6Z5152MkDmMJCovDxBMGc=.f2771fd7-fc63-4bdd-90c9-a679056a77f6@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
 <85FtEQ4pR0Y6nbxnbUOvLMCKBi_fkua5rWV0nGZ4ih0=.f7019fa1-38d1-4209-94d4-fa9a488ac16a@github.com>
 <Z168APCzt9KgpJD-CQy_WW6Z5152MkDmMJCovDxBMGc=.f2771fd7-fc63-4bdd-90c9-a679056a77f6@github.com>
Message-ID: <wJLsHcF4cEZ_1o0A-qD9RkIxzQli8zCK5FyYOjx1mPs=.37c30b1a-60d0-4cf0-8a6f-c3383df3ac51@github.com>

On Fri, 20 Nov 2020 09:27:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added UnchedkedIOException catch blocks for sumTokensIOStat and getLongEntry methods
>
> This seems OK. Ideally, I'd like for this to be tested. If it's interrupts it's going to be difficult. Missing files should be easy enough to test.
> 
> Aside: We really need to streamline file reading. We have too many of them unnecessarily all over the place. [JDK-8254001](https://bugs.openjdk.java.net/browse/JDK-8254001) should fix that. I'll prioritize it.

> @jerboaa Thanks for the review. As for the missing files, looks like mountInfoFileNotFound() and cgroupsFileNotFound() should be testing it.
> 
> This issue is being faced by a customer and they encountered failures due to interrupts during reading. These changes have been verified by them.

Thanks. That's OK. Preference would be to have an automated test for this issue, but this seems difficult in this case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1303

From alanb at openjdk.java.net  Fri Nov 20 15:53:10 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 15:53:10 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>
Message-ID: <f4NAmy4mSHMpUvmLiLgYu0fyPKdOhfs7JTVwearn3n4=.7358afe5-60ce-44b2-b78a-fa32d879f2b8@github.com>

On Fri, 20 Nov 2020 15:27:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Fixed typo in @deprecated text
>>  - Merge
>>  - Update jshell class
>>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon
>
> Marked as reviewed by rriggs (Reviewer).

> Ok, but then how about putting a similar note in the javadoc for the RuntimePermission "modifyThreadGroup" target?

The "modifyThread" and "modifyThreadGroup" permission targets list methods that have been terminally deprecated for some time, are you looking for both permission targets to be updated? I could imagine doing an overall here, also re-visiting SecurityManager checkAccess(ThreadGroup) but it feels like it's beyond the scope of the deprecation proposed here and would be better off being left to when we eventually degrade and/or remove these methods.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From sgehwolf at openjdk.java.net  Fri Nov 20 15:56:09 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Fri, 20 Nov 2020 15:56:09 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem [v3]
In-Reply-To: <85FtEQ4pR0Y6nbxnbUOvLMCKBi_fkua5rWV0nGZ4ih0=.f7019fa1-38d1-4209-94d4-fa9a488ac16a@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
 <85FtEQ4pR0Y6nbxnbUOvLMCKBi_fkua5rWV0nGZ4ih0=.f7019fa1-38d1-4209-94d4-fa9a488ac16a@github.com>
Message-ID: <dTyekwbTZma8X7VbYXVeLTFBMUb7HFmI9q38icg36-Y=.a26f5bc7-9210-406d-a091-c86098524be6@github.com>

On Thu, 19 Nov 2020 20:49:16 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this simple change that catches UncheckedIOException that can occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the system, or if there is an interrupt while these are being read.
>> 
>> Testing: Tier1, Tier2 and Tier3.
>> 
>> Thanks,
>> Poonam
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added UnchedkedIOException catch blocks for sumTokensIOStat and getLongEntry methods

Marked as reviewed by sgehwolf (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1303

From mullan at openjdk.java.net  Fri Nov 20 16:08:03 2020
From: mullan at openjdk.java.net (Sean Mullan)
Date: Fri, 20 Nov 2020 16:08:03 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <f4NAmy4mSHMpUvmLiLgYu0fyPKdOhfs7JTVwearn3n4=.7358afe5-60ce-44b2-b78a-fa32d879f2b8@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>
 <f4NAmy4mSHMpUvmLiLgYu0fyPKdOhfs7JTVwearn3n4=.7358afe5-60ce-44b2-b78a-fa32d879f2b8@github.com>
Message-ID: <zNb8XgYqE_s32lKNQORnUGoh6nKBHaHLMq96y7WFBH4=.8398dd8d-2783-4c18-ae69-e4f90eed3171@github.com>

On Fri, 20 Nov 2020 15:50:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Ok, but then how about putting a similar note in the javadoc for the RuntimePermission "modifyThreadGroup" target?
> 
> The "modifyThread" and "modifyThreadGroup" permission targets list methods that have been terminally deprecated for some time, are you looking for both permission targets to be updated? I could imagine doing an overall here, also re-visiting SecurityManager checkAccess(ThreadGroup) but it feels like it's beyond the scope of the deprecation proposed here and would be better off being left to when we eventually degrade and/or remove these methods.

Ok, I see there is a broader context for my comment. I think then it makes sense to open a separate issue to specify these various RuntimePermission targets that are associated with deprecated APIs. In my mind, these permission targets are standard targets and should also be "deprecated" even if there is no annotation that can formally indicate that. For comparison, SecurityPermission puts these in a separate table in the class summary: https://download.java.net/java/early_access/jdk16/docs/api/java.base/java/security/SecurityPermission.html
If you agree, I can file an issue.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From herrick at openjdk.java.net  Fri Nov 20 16:22:06 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Fri, 20 Nov 2020 16:22:06 GMT
Subject: RFR: 8235304: JPackage Windows test should be added to set
 Publisher [v2]
In-Reply-To: <urUnIf31HFwXrmnqzHCdiEvaTuCD6Np81mXIYNYfVJw=.6d593ad6-30ef-49dc-a9c2-825284611fec@github.com>
References: <rSNe02yhqWuRXN6CWRJzEu2UHiKnjEGGjX-Qp3I6SAM=.d1b583db-8f05-4e24-898f-e6c84d820e09@github.com>
 <urUnIf31HFwXrmnqzHCdiEvaTuCD6Np81mXIYNYfVJw=.6d593ad6-30ef-49dc-a9c2-825284611fec@github.com>
Message-ID: <9mTOnpeLnRYCGLXzf4Mv-rTMPe3YsH-20_2tDazihnE=.20209ea3-0359-43f0-91a6-c84d8e65fc7c@github.com>

On Thu, 19 Nov 2020 22:26:20 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> 8235304: JPackage Windows test should be added to set Publisher
>
> 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 four additional commits since the last revision:
> 
>  - Merge branch 'JDK-8235304' of https://github.com/alexeysemenyukoracle/jdk into JDK-8235304
>  - 8235304: JPackage Windows test should be added to set Publisher
>  - 8227400: Adjust jib profiles to make 3rd party tools for creating installers available on Mach5 test machines
>  - 8235304: JPackage Windows test should be added to set Publisher

Marked as reviewed by herrick (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1331

From bpb at openjdk.java.net  Fri Nov 20 16:27:05 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 20 Nov 2020 16:27:05 GMT
Subject: Integrated: 8229845: Decrease memory consumption of
 BigInteger.toString()
In-Reply-To: <QcssqDSre9zJ5L6fYGesmxienoFDYDebNM2fJUMe_bw=.3236bd5c-5900-4c0b-9e00-21a7bf24b9b4@github.com>
References: <QcssqDSre9zJ5L6fYGesmxienoFDYDebNM2fJUMe_bw=.3236bd5c-5900-4c0b-9e00-21a7bf24b9b4@github.com>
Message-ID: <beCePHg5ODccJRddG8-dTxzv9EW0R1DlysT9g2A6wsM=.8a2cc0f8-fede-48f6-a0d2-bb24e3b4d758@github.com>

On Thu, 22 Oct 2020 20:56:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Please review this proposed fix. The review was initially in this thread
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/061914.html
> 
> under the old Hg SCM. The changes proposed here are derived from the final (.05) patch in the previous review which was posted in
> 
> http://mail.openjdk.java.net/pipermail/core-libs-dev/2019-August/062012.html.

This pull request has now been integrated.

Changeset: 2ae3e51f
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2ae3e51f
Stats:     115 lines in 2 files changed: 57 ins; 21 del; 37 mod

8229845: Decrease memory consumption of BigInteger.toString()

Reviewed-by: redestad

-------------

PR: https://git.openjdk.java.net/jdk/pull/819

From bobv at openjdk.java.net  Fri Nov 20 16:37:04 2020
From: bobv at openjdk.java.net (Bob Vandette)
Date: Fri, 20 Nov 2020 16:37:04 GMT
Subject: RFR: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem [v3]
In-Reply-To: <85FtEQ4pR0Y6nbxnbUOvLMCKBi_fkua5rWV0nGZ4ih0=.f7019fa1-38d1-4209-94d4-fa9a488ac16a@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
 <85FtEQ4pR0Y6nbxnbUOvLMCKBi_fkua5rWV0nGZ4ih0=.f7019fa1-38d1-4209-94d4-fa9a488ac16a@github.com>
Message-ID: <k7ckzVwiGOS8jhB1T3oGwiYNCjnIfgimjYboPZuR2p0=.a60c406b-8ea9-4150-8e13-5366b0711df4@github.com>

On Thu, 19 Nov 2020 20:49:16 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

>> Hi,
>> 
>> Please review this simple change that catches UncheckedIOException that can occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the system, or if there is an interrupt while these are being read.
>> 
>> Testing: Tier1, Tier2 and Tier3.
>> 
>> Thanks,
>> Poonam
>
> Poonam Bajaj has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added UnchedkedIOException catch blocks for sumTokensIOStat and getLongEntry methods

Marked as reviewed by bobv (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1303

From asemenyuk at openjdk.java.net  Fri Nov 20 16:42:10 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Fri, 20 Nov 2020 16:42:10 GMT
Subject: Integrated: 8235304: JPackage Windows test should be added to set
 Publisher
In-Reply-To: <rSNe02yhqWuRXN6CWRJzEu2UHiKnjEGGjX-Qp3I6SAM=.d1b583db-8f05-4e24-898f-e6c84d820e09@github.com>
References: <rSNe02yhqWuRXN6CWRJzEu2UHiKnjEGGjX-Qp3I6SAM=.d1b583db-8f05-4e24-898f-e6c84d820e09@github.com>
Message-ID: <qod7Xtii3dWGDVYUR0lBlJQ46uK00ZXybqd7LKFoNOQ=.22f8e744-3dc3-45a3-81a6-a82f638d7ffb@github.com>

On Thu, 19 Nov 2020 22:00:01 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> 8235304: JPackage Windows test should be added to set Publisher

This pull request has now been integrated.

Changeset: 11bfdc57
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/11bfdc57
Stats:     107 lines in 1 file changed: 107 ins; 0 del; 0 mod

8235304: JPackage Windows test should be added to set Publisher

Reviewed-by: herrick, almatvee

-------------

PR: https://git.openjdk.java.net/jdk/pull/1331

From bpb at openjdk.java.net  Fri Nov 20 16:52:09 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 20 Nov 2020 16:52:09 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently [v2]
In-Reply-To: <--HOexGX8-_Sc7boGjeJ0T1u6N8X51SG7bERCEf7eZM=.c480bae4-741e-4eb4-85b2-b5865bed9847@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
 <L2ZJDD2MxcN4n2bgzpupNVer8cBbCImp8P35KfEZRk4=.b92861d5-b700-4760-bbb8-f020208c8aa6@github.com>
 <--HOexGX8-_Sc7boGjeJ0T1u6N8X51SG7bERCEf7eZM=.c480bae4-741e-4eb4-85b2-b5865bed9847@github.com>
Message-ID: <6wf2A3Uskp9uX0tTpjrRiO93v8hlIZH-3AAnvL4CEa8=.aad8296b-0999-47ab-8578-6e3f6d76553a@github.com>

On Fri, 20 Nov 2020 11:43:11 GMT, sergus13 <github.com+74766043+sergus13 at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8246739: InputStream.skipNBytes could be implemented more efficiently
>>  - 8246739: InputStream.skipNBytes could be implemented more efficiently
>
> src/java.base/share/classes/java/io/InputStream.java line 605:
> 
>> 603:             } else if (ns == 0) { // no bytes skipped
>> 604:                 // read one byte to check for EOS
>> 605:                 if (read() < 0) {
> 
> Wouldn't it be better to compare return value with -1 (as it was before)?
> Since the documentation of read method says:
> _Returns:
>     the next byte of data, or **-1 if the end of the stream is reached**._

Indeed that would match the letter of the specification of `read()` but I don't think it would make any practical difference.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1329

From alanb at openjdk.java.net  Fri Nov 20 17:03:04 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 20 Nov 2020 17:03:04 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <zNb8XgYqE_s32lKNQORnUGoh6nKBHaHLMq96y7WFBH4=.8398dd8d-2783-4c18-ae69-e4f90eed3171@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <F34EKW5I8GbRhzXZi719lQ8HKQ1Zw-pztK8xnqq_1Wo=.4925ab34-f769-47fc-9373-a9a9144a6a66@github.com>
 <f4NAmy4mSHMpUvmLiLgYu0fyPKdOhfs7JTVwearn3n4=.7358afe5-60ce-44b2-b78a-fa32d879f2b8@github.com>
 <zNb8XgYqE_s32lKNQORnUGoh6nKBHaHLMq96y7WFBH4=.8398dd8d-2783-4c18-ae69-e4f90eed3171@github.com>
Message-ID: <CIzjSKmsDowUN8Fug1JXYQX-8jjtG-Tq_3rgkoth4gg=.7ef98fa1-64a9-4757-b2dd-ecfab998da1c@github.com>

On Fri, 20 Nov 2020 16:05:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> If you agree, I can file an issue.

Yes, make sense to separate this out, esp. permission targets such as "stopThread" where all usages are in deprecated methods. However, I don't expect "modifyThreadGroup" would be deprecated, at least not yet, because there are usages in several methods that are not deprecated.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From bpb at openjdk.java.net  Fri Nov 20 17:12:20 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 20 Nov 2020 17:12:20 GMT
Subject: RFR: 8246739: InputStream.skipNBytes could be implemented more
 efficiently [v3]
In-Reply-To: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
References: <KJp9Bckd-Fhel9cK5U5escC3ZNlt8kLsITUrn_HUg50=.6f0d689f-e1d9-4de1-ad6c-ddbaffc8ba99@github.com>
Message-ID: <pg_heIVemD0DhqJG-tLOoIg3f8dyCkmFvr_p9YDOzjQ=.76de5e67-fa44-44c2-83ad-06b60b5170b4@github.com>

> Please review this modification of `java.io.InputStream.skipNBytes(long)` to improve its performance when `skip(long)` skips fewer than the requested number of bytes. In the current implementation, `skip(long)` is invoked once and, if not enough bytes have been skipped, then `read()` is invoked for each of the remaining bytes to be skipped. The proposed implementation instead repeatedly invokes `skip(long)` until the requested number of bytes has been skipped, or an error condition is encountered. For cases where `skip(long)` skips fewer bytes than the number requested, the new version was measured to be up to more than one thousand times faster than the old version. When `skip(long)` actually skips the requested number of bytes, the performance difference is insignificant.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8246739: InputStream.skipNBytes could be implemented more efficiently

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1329/files
  - new: https://git.openjdk.java.net/jdk/pull/1329/files/f59d7a35..60fe0953

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1329&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1329&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1329.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1329/head:pull/1329

PR: https://git.openjdk.java.net/jdk/pull/1329

From naoto at openjdk.java.net  Fri Nov 20 17:13:04 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 20 Nov 2020 17:13:04 GMT
Subject: Integrated: 8211449: Correction to the spec of implicit negative
 subpattern in DecimalFormat
In-Reply-To: <zDGgqJ2V2cOPay8etM9RAh_Gis8gGRB81tS0OqJdqww=.52352e36-16c9-4754-bbf5-7a3065f6560b@github.com>
References: <zDGgqJ2V2cOPay8etM9RAh_Gis8gGRB81tS0OqJdqww=.52352e36-16c9-4754-bbf5-7a3065f6560b@github.com>
Message-ID: <8fTrEiipobLTkkVHLQM0BsfQLJYZ9-sW2Rv36NHBnpY=.c40adcfc-aa8f-4772-9cd3-0d01d5a9d14e@github.com>

On Thu, 19 Nov 2020 17:15:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this doc only fix to the class description of `DecimalFormat` class. `localized minus sign` has never been (and should never be) used in the implicit negative subpattern. Actual implementation correctly uses ascii minus sign for that purpose, so there won't be any compatibility issues.

This pull request has now been integrated.

Changeset: 2c3a2bed
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/2c3a2bed
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8211449: Correction to the spec of implicit negative subpattern in DecimalFormat

Reviewed-by: bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1325

From serb at openjdk.java.net  Fri Nov 20 17:58:10 2020
From: serb at openjdk.java.net (Sergey Bylokhov)
Date: Fri, 20 Nov 2020 17:58:10 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
Message-ID: <sV1eWm3ZqFAQ0yM8ZplcYHqeMx_OK67VcDDVP4Y7rjg=.1124de6a-5992-4937-a849-06d4a3ea8e3b@github.com>

On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Marked as reviewed by serb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From naoto at openjdk.java.net  Fri Nov 20 18:01:14 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 20 Nov 2020 18:01:14 GMT
Subject: RFR: 8247432: Update IANA Language Subtag Registry to Version
 2020-09-29
Message-ID: <eATYqJ38ckiQ1oLj3YvsIjp84ZCEchfVw-4usoIrACc=.fdf34a23-e455-474d-9f86-b361c4b6ed8c@github.com>

Hi,

Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK.

-------------

Commit messages:
 - LSR 2020-09-29
 - LSR 2020-07-17

Changes: https://git.openjdk.java.net/jdk/pull/1357/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1357&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8247432
  Stats: 52 lines in 2 files changed: 44 ins; 5 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1357.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1357/head:pull/1357

PR: https://git.openjdk.java.net/jdk/pull/1357

From dfuchs at openjdk.java.net  Fri Nov 20 18:11:10 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 20 Nov 2020 18:11:10 GMT
Subject: RFR: 8256154: Some TestNG tests require default constructors
In-Reply-To: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
References: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
Message-ID: <3WN0NtBcsv2PoY4rdHhPbHUSoJJ5r_XXd6jT3AHDJAo=.7eb893ac-7e31-4c77-abec-3c9a85f5cbe7@github.com>

On Thu, 19 Nov 2020 13:50:30 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> In TestNG 7, it is a requirement that TestNG is able to create a Test object using a default constructor. 
> 
> This simple fix addresses two such classes so that this requirement is satisfied by inserting default construtors. Example: `public GetPackages() { ... }`
> 
> test/jdk/java/lang/Package/GetPackages.java
> test/jdk/java/lang/StackWalker/Basic.java

Thanks Conor! LGTM then.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1317

From dfuchs at openjdk.java.net  Fri Nov 20 18:14:06 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Fri, 20 Nov 2020 18:14:06 GMT
Subject: RFR: 8256154: Some TestNG tests require default constructors
In-Reply-To: <wK9Xbe8aV_W4R3ZHJIL4eYLs8LjZpjYKmpqwHIu9wjQ=.1b9083e0-8c86-4ae2-b468-0270a213be10@github.com>
References: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
 <a9qdJkFWZEQJ0119IvnStmBuu3VFDjmGm2ndTGFlL1I=.a11cbaba-fdc6-4cee-9677-e5aceba3803e@github.com>
 <l9_jB3QgFlof8hGMnFuVAq8j6Iq3s2NGhVuavSx2ZKc=.d007de65-3a00-4862-a9f1-5b55632f1877@github.com>
 <Qp2XdY9vs_jdrRcH2cFmC9jYxTWpCWHJWPeb2nytpd0=.d316f2b3-25a8-4400-b160-bd8f7ee863ad@github.com>
 <wK9Xbe8aV_W4R3ZHJIL4eYLs8LjZpjYKmpqwHIu9wjQ=.1b9083e0-8c86-4ae2-b468-0270a213be10@github.com>
Message-ID: <De04iYRsGczzQTQhkjgoCwjc0exCakjjWv9fZS8gFfw=.45a713e5-31be-451a-bd75-6476d75d3091@github.com>

On Fri, 20 Nov 2020 09:37:19 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

>> Ah, missed the final on depth :-)
>
> Any particular strengths associated with `this(0)` as opposed to the actual assignment? Aside from the brevity it provides of course. Happy to modify the PR to include it

My personal preference is to chain constructors whenever possible, ideally ending up in a single constructor that all other constructors call. This way the initialization logic is in a single place - instead of being duplicated all over.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1317

From smarks at openjdk.java.net  Fri Nov 20 18:30:04 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 20 Nov 2020 18:30:04 GMT
Subject: Integrated: 8037384: Fix wording in Javadoc of java.io.Serializable
In-Reply-To: <j51neqpaI-7jIch45IbUQPgl9jpbAETXuTNOviNlNDs=.334da5a4-f082-46bd-aedc-56c2f18358a1@github.com>
References: <j51neqpaI-7jIch45IbUQPgl9jpbAETXuTNOviNlNDs=.334da5a4-f082-46bd-aedc-56c2f18358a1@github.com>
Message-ID: <zefjPgmS0HbiTNjuiPrbPwv1AvzAwC3LYPXStIaI3RA=.466f3d90-65c1-45d3-82db-6767feb113c2@github.com>

On Thu, 19 Nov 2020 03:44:10 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> 8231547: Serializable class doc should link to serialization specification
> 
> Rewrite a couple confusing sentences in the Serializable class doc. This does affect normative text, but the edits are primarily to focus and clarify the text, not to make any semantic changes. Thus, a CSR request shouldn't be required for this change.
> 
> Also add and adjust some links and link markup to the Java Object Serialization Specification.

This pull request has now been integrated.

Changeset: cc0ed401
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cc0ed401
Stats:     27 lines in 5 files changed: 5 ins; 1 del; 21 mod

8037384: Fix wording in Javadoc of java.io.Serializable
8231547: Serializable class doc should link to serialization specification

Reviewed-by: rriggs, iris, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/1306

From poonam at openjdk.java.net  Fri Nov 20 18:43:03 2020
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Fri, 20 Nov 2020 18:43:03 GMT
Subject: Integrated: 8255908: ExceptionInInitializerError due to
 UncheckedIOException while initializing cgroupv1 subsystem
In-Reply-To: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
References: <ZCeCpeKCBAVk-VIjhH8CsMmb5AYe_4r6-FQ4GK6rRig=.e266df84-7ab6-4450-9818-3abf84816f49@github.com>
Message-ID: <Liyd46GncUAh6fnQ03d0LRJ_8D3eR8Vx1s1pLO1UL4k=.0f0d5c09-de68-4bb4-b7a7-76506a471da9@github.com>

On Thu, 19 Nov 2020 01:22:01 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> Hi,
> 
> Please review this simple change that catches UncheckedIOException that can occur if /proc/self/cgroup or /proc/self/mountinfo files don't exist on the system, or if there is an interrupt while these are being read.
> 
> Testing: Tier1, Tier2 and Tier3.
> 
> Thanks,
> Poonam

This pull request has now been integrated.

Changeset: 8d9cf48e
Author:    Poonam Bajaj <poonam at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8d9cf48e
Stats:     23 lines in 4 files changed: 21 ins; 0 del; 2 mod

8255908: ExceptionInInitializerError due to UncheckedIOException while initializing cgroupv1 subsystem

Reviewed-by: shade, sgehwolf, bobv

-------------

PR: https://git.openjdk.java.net/jdk/pull/1303

From bpb at openjdk.java.net  Fri Nov 20 18:48:04 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 20 Nov 2020 18:48:04 GMT
Subject: RFR: 8256154: Some TestNG tests require default constructors
In-Reply-To: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
References: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
Message-ID: <8RsLo3pjEy6uWxQA9PkchasiA8bvrSr6zxUEHyU7PHg=.9f035559-4661-4cf7-aa9e-81e2ed540da3@github.com>

On Thu, 19 Nov 2020 13:50:30 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> In TestNG 7, it is a requirement that TestNG is able to create a Test object using a default constructor. 
> 
> This simple fix addresses two such classes so that this requirement is satisfied by inserting default construtors. Example: `public GetPackages() { ... }`
> 
> test/jdk/java/lang/Package/GetPackages.java
> test/jdk/java/lang/StackWalker/Basic.java

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1317

From mchung at openjdk.java.net  Fri Nov 20 19:09:19 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 20 Nov 2020 19:09:19 GMT
Subject: RFR: 8159746: (proxy) Support for default methods [v6]
In-Reply-To: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
Message-ID: <pmM7Q2o6gbSV0g9d5pkzZEeMKaFnk-osF2pDQaQTfCA=.0309dac9-dea5-4818-8283-8276df209362@github.com>

> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke
> the given default method on the given proxy instance.
> 
> The implementation looks up a method handle for `invokespecial` instruction
> as if called from with the proxy class as the caller, equivalent to calling
> `X.super::m` where `X` is a proxy interface of the proxy class and
> `X.super::m` will resolve to the specified default method.
> 
> The implementation will call a private static `proxyClassLookup(Lookup caller)`
> method of the proxy class to obtain its private Lookup.  This private method
> in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class
> with full privilege access to use, or else `IllegalAccessException` will be
> thrown.
> 
> This patch also proposes to define a proxy class in an unnamed module to
> a dynamic module to strengthen encapsulation such that they are only
> unconditionally exported from a named module but not open for deep reflective
> access.  This only applies to the case if all the proxy interfaces are public
> and in a package that is exported or open.
> 
> One dynamic module is created for each class loader that defines proxies.
> The change changes the dynamic module to contain another package (same
> name as the module) that is unconditionally exported and is opened to
> `java.base` only.
> 
> There is no change to the package and module of the proxy class for
> the following cases:
> 
> - if at least one proxy interface is non-public, then the proxy class is defined
>   in the package and module of the non-public interfaces
> - if at least one proxy is in a package that is non-exported and non-open,
>   if all proxy interfaces are public, then the proxy class is defined in
>   a non-exported, non-open package of a dynamic module.
> 
> The spec change is that a proxy class used to be defined in an unnamed
> module, i.e. in a exported and open package, is defined in an unconditionally
> exported but non-open package.  Programs that assume it to be open unconditionally
> will be affected and cannot do deep reflection on such proxy classes.
> 
> Peter Levart contributed an initial prototype [1] (thanks Peter).  I think
> the exceptions could be simplified as more checking should be done prior to
> the invocation of the method handle like checking the types of the arguments
> with the method type.  This approach avoids defining a public API
> `protected Proxy::$$proxyClassLookup$$` method.  Instead it defines a
> private static method that is restricted for Proxy class to use (by
> taking a caller parameter to ensure it's a private lookup on Proxy class).
> 
> javadoc/specdiff:
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/
> 
> [1]  http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Performance improvement contributed by plevart

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/313/files
  - new: https://git.openjdk.java.net/jdk/pull/313/files/8352a20b..d443f10e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=04-05

  Stats: 24 lines in 4 files changed: 7 ins; 8 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/313.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/313/head:pull/313

PR: https://git.openjdk.java.net/jdk/pull/313

From mchung at openjdk.java.net  Fri Nov 20 19:15:07 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 20 Nov 2020 19:15:07 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <tpLs_qejlYlXcAeQNbsooyUHtIhKfzT9cLEyIymJM6E=.873923fa-bbaa-4a76-a9c1-a70ce8f98dfa@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
 <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
 <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
 <3_3xp4MbiLH-_9zyTkLVKZKP3ds0AftAVtbWo8tYeFs=.483fa478-0e33-495d-a545-b2339ecee592@github.com>
 <X93bQ76ydubQKGZAlD4ub43vTBHXjwnXQx--UN5xgus=.5e2ddf9d-86a5-4c34-b53a-65daff1d43df@github.com>
 <mthe4gxs2yOuXitvRF4Cwzbk4LLamGCDlx
 TaQJdRo_g=.edaa421c-e144-4466-a07f-251da9357364@github.com>
 <LrmZFLofpx4ewPC-GKlK9Z3xjIi4PrFLpOUL8qz6SJg=.ce86cf0c-c579-4d26-b68f-29b656ab78d3@github.com>
 <Xj3UDUQX-_oljQZ4TvbAcCeCKTL7Dz2PVsidXRQjywY=.921b1537-b302-4e88-9f91-c0b8c2d6c28f@github.com>
 <tpLs_qejlYlXcAeQNbsooyUHtIhKfzT9cLEyIymJM6E=.873923fa-bbaa-4a76-a9c1-a70ce8f98dfa@github.com>
Message-ID: <Xj3I8gMkBmlyEccP6tATEvT-70n7dpDioSM8tAHRzyI=.62f16c04-f719-4e4c-89e0-0040743f0fbc@github.com>

On Fri, 20 Nov 2020 11:18:32 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Hi Mandy,
>> I re-ran the benchmark on your latest version (the static API) and I get similar results as you:
>> 
>> Benchmark               Mode  Cnt   Score   Error  Units
>> ProxyBench.implClass    avgt    5   3.745 ? 0.033  ns/op
>> ProxyBench.implProxy    avgt    5  29.826 ? 0.183  ns/op
>> ProxyBench.ppImplClass  avgt    5   3.683 ? 0.009  ns/op
>> ProxyBench.ppImplProxy  avgt    5  29.124 ? 0.535  ns/op
>> 
>> I also tried a variant where the access check in the invokeDefault static method is not pre-screened with checking of the interface modifiers and package export status but relies on Method.checkAccess cache alone:
>> 
>>         // access check
>>         Class<?> caller = Reflection.getCallerClass();
>>         int modifiers = method.getModifiers();
>>         method.checkAccess(caller, intf, proxyClass, modifiers);
>> 
>> ... and the results are not worse, even marginally better:
>> 
>> Benchmark               Mode  Cnt   Score   Error  Units
>> ProxyBench.implClass    avgt    5   3.724 ? 0.012  ns/op
>> ProxyBench.implProxy    avgt    5  29.138 ? 0.271  ns/op
>> ProxyBench.ppImplClass  avgt    5   3.744 ? 0.009  ns/op
>> ProxyBench.ppImplProxy  avgt    5  28.961 ? 0.182  ns/op
>> 
>> I think this looks reasonably good.
>
> In my previous attempts when I was modifying the ProxyGenerator I noticed that generated proxy fields holding Method objects are just "static" but could be "static final". If they were "static final", JIT could constant-fold the Method instances. If this was combined with marking some fields in Method as @Stable, this could improve optimization of code a bit further. I did this with the following patch:
> 
> Index: src/java.base/share/classes/java/lang/reflect/InvocationHandler.java
> IDEA additional info:
> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> <+>UTF-8
> ===================================================================
> --- src/java.base/share/classes/java/lang/reflect/InvocationHandler.java	(revision 8352a20bf54a085a97d3f703b5dab482d3f9eccc)
> +++ src/java.base/share/classes/java/lang/reflect/InvocationHandler.java	(date 1605869089804)
> @@ -271,15 +271,10 @@
>              throw new IllegalArgumentException(""" + method + "" is not a default method");
>          }
>          Class<?> intf = method.getDeclaringClass();
> -        // access check if it is a non-public proxy interface or not unconditionally exported
> -        if (!Modifier.isPublic(intf.getModifiers()) ||
> -                !intf.getModule().isExported(intf.getPackageName())) {
> -            // throw IAE if the caller class has no access to the default method
> -            // same access check to Method::invoke on the default method
> -            int modifiers = method.getModifiers();
> -            Class<?> caller = Reflection.getCallerClass();
> -            method.checkAccess(caller, intf, proxyClass, modifiers);
> -        }
> +        // access check
> +        Class<?> caller = Reflection.getCallerClass();
> +        int modifiers = method.getModifiers();
> +        method.checkAccess(caller, intf, proxyClass, modifiers);
>  
>          MethodHandle mh = Proxy.defaultMethodHandle(proxyClass, method);
>          // invoke the super method
> Index: src/java.base/share/classes/java/lang/reflect/Method.java
> IDEA additional info:
> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> <+>UTF-8
> ===================================================================
> --- src/java.base/share/classes/java/lang/reflect/Method.java	(revision 8352a20bf54a085a97d3f703b5dab482d3f9eccc)
> +++ src/java.base/share/classes/java/lang/reflect/Method.java	(date 1605870445135)
> @@ -31,6 +31,7 @@
>  import jdk.internal.reflect.Reflection;
>  import jdk.internal.vm.annotation.ForceInline;
>  import jdk.internal.vm.annotation.IntrinsicCandidate;
> +import jdk.internal.vm.annotation.Stable;
>  import sun.reflect.annotation.ExceptionProxy;
>  import sun.reflect.annotation.TypeNotPresentExceptionProxy;
>  import sun.reflect.generics.repository.MethodRepository;
> @@ -66,7 +67,7 @@
>   * @since 1.1
>   */
>  public final class Method extends Executable {
> -    private Class<?>            clazz;
> +    @Stable private Class<?>    clazz;
>      private int                 slot;
>      // This is guaranteed to be interned by the VM in the 1.4
>      // reflection implementation
> @@ -74,7 +75,7 @@
>      private Class<?>            returnType;
>      private Class<?>[]          parameterTypes;
>      private Class<?>[]          exceptionTypes;
> -    private int                 modifiers;
> +    @Stable private int         modifiers;
>      // Generics and annotations support
>      private transient String              signature;
>      // generic info repository; lazily initialized
> Index: src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
> IDEA additional info:
> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
> <+>UTF-8
> ===================================================================
> --- src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java	(revision 8352a20bf54a085a97d3f703b5dab482d3f9eccc)
> +++ src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java	(date 1605870027579)
> @@ -490,7 +490,7 @@
>          for (List<ProxyMethod> sigmethods : proxyMethods.values()) {
>              for (ProxyMethod pm : sigmethods) {
>                  // add static field for the Method object
> -                visitField(Modifier.PRIVATE | Modifier.STATIC, pm.methodFieldName,
> +                visitField(Modifier.PRIVATE | Modifier.STATIC | Modifier.FINAL, pm.methodFieldName,
>                          LJLR_METHOD, null, null);
>  
>                  // Generate code for proxy method
> 
> ...and this makes the following results:
> 
> Benchmark               Mode  Cnt   Score   Error  Units
> ProxyBench.implClass    avgt    5   3.766 ? 0.040  ns/op
> ProxyBench.implProxy    avgt    5  26.847 ? 0.626  ns/op
> ProxyBench.ppImplClass  avgt    5   3.700 ? 0.017  ns/op
> ProxyBench.ppImplProxy  avgt    5  26.322 ? 0.048  ns/op
> 
> But this can be changed as a follow-up patch that also takes care of Constructor and Field.

@plevart I'm okay with this slight performance improvement.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From iris at openjdk.java.net  Fri Nov 20 19:28:10 2020
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 20 Nov 2020 19:28:10 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
Message-ID: <eWF-EAOrTnAd5-66ObnEMDFMfWb5IEETjlTPHmQqFSE=.eaf8ffbd-c78b-432d-b75d-48cbf9fc0d27@github.com>

On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From mchung at openjdk.java.net  Fri Nov 20 19:55:09 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 20 Nov 2020 19:55:09 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <Xj3I8gMkBmlyEccP6tATEvT-70n7dpDioSM8tAHRzyI=.62f16c04-f719-4e4c-89e0-0040743f0fbc@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
 <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
 <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
 <3_3xp4MbiLH-_9zyTkLVKZKP3ds0AftAVtbWo8tYeFs=.483fa478-0e33-495d-a545-b2339ecee592@github.com>
 <X93bQ76ydubQKGZAlD4ub43vTBHXjwnXQx--UN5xgus=.5e2ddf9d-86a5-4c34-b53a-65daff1d43df@github.com>
 <mthe4gxs2yOuXitvRF4Cwzbk4LLamGCDlx
 TaQJdRo_g=.edaa421c-e144-4466-a07f-251da9357364@github.com>
 <LrmZFLofpx4ewPC-GKlK9Z3xjIi4PrFLpOUL8qz6SJg=.ce86cf0c-c579-4d26-b68f-29b656ab78d3@github.com>
 <Xj3UDUQX-_oljQZ4TvbAcCeCKTL7Dz2PVsidXRQjywY=.921b1537-b302-4e88-9f91-c0b8c2d6c28f@github.com>
 <tpLs_qejlYlXcAeQNbsooyUHtIhKfzT9cLEyIymJM6E=.873923fa-bbaa-4a76-a9c1-a70ce8f98dfa@github.com>
 <Xj3I8gMkBmlyEccP6tATEvT-70n7dpDioSM8tAHRzyI=.62f16c04-f719-4e4c-89e0-0040743f0fbc@github.com>
Message-ID: <1sMJ4tsGr88JeeluDvtTS0fSGgIvyrGbWk2uVsCzZU0=.d8aef781-9beb-4e7a-b029-699200628543@github.com>

On Fri, 20 Nov 2020 19:11:54 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> In my previous attempts when I was modifying the ProxyGenerator I noticed that generated proxy fields holding Method objects are just "static" but could be "static final". If they were "static final", JIT could constant-fold the Method instances. If this was combined with marking some fields in Method as @Stable, this could improve optimization of code a bit further. I did this with the following patch:
>> 
>> Index: src/java.base/share/classes/java/lang/reflect/InvocationHandler.java
>> IDEA additional info:
>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
>> <+>UTF-8
>> ===================================================================
>> --- src/java.base/share/classes/java/lang/reflect/InvocationHandler.java	(revision 8352a20bf54a085a97d3f703b5dab482d3f9eccc)
>> +++ src/java.base/share/classes/java/lang/reflect/InvocationHandler.java	(date 1605869089804)
>> @@ -271,15 +271,10 @@
>>              throw new IllegalArgumentException(""" + method + "" is not a default method");
>>          }
>>          Class<?> intf = method.getDeclaringClass();
>> -        // access check if it is a non-public proxy interface or not unconditionally exported
>> -        if (!Modifier.isPublic(intf.getModifiers()) ||
>> -                !intf.getModule().isExported(intf.getPackageName())) {
>> -            // throw IAE if the caller class has no access to the default method
>> -            // same access check to Method::invoke on the default method
>> -            int modifiers = method.getModifiers();
>> -            Class<?> caller = Reflection.getCallerClass();
>> -            method.checkAccess(caller, intf, proxyClass, modifiers);
>> -        }
>> +        // access check
>> +        Class<?> caller = Reflection.getCallerClass();
>> +        int modifiers = method.getModifiers();
>> +        method.checkAccess(caller, intf, proxyClass, modifiers);
>>  
>>          MethodHandle mh = Proxy.defaultMethodHandle(proxyClass, method);
>>          // invoke the super method
>> Index: src/java.base/share/classes/java/lang/reflect/Method.java
>> IDEA additional info:
>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
>> <+>UTF-8
>> ===================================================================
>> --- src/java.base/share/classes/java/lang/reflect/Method.java	(revision 8352a20bf54a085a97d3f703b5dab482d3f9eccc)
>> +++ src/java.base/share/classes/java/lang/reflect/Method.java	(date 1605870445135)
>> @@ -31,6 +31,7 @@
>>  import jdk.internal.reflect.Reflection;
>>  import jdk.internal.vm.annotation.ForceInline;
>>  import jdk.internal.vm.annotation.IntrinsicCandidate;
>> +import jdk.internal.vm.annotation.Stable;
>>  import sun.reflect.annotation.ExceptionProxy;
>>  import sun.reflect.annotation.TypeNotPresentExceptionProxy;
>>  import sun.reflect.generics.repository.MethodRepository;
>> @@ -66,7 +67,7 @@
>>   * @since 1.1
>>   */
>>  public final class Method extends Executable {
>> -    private Class<?>            clazz;
>> +    @Stable private Class<?>    clazz;
>>      private int                 slot;
>>      // This is guaranteed to be interned by the VM in the 1.4
>>      // reflection implementation
>> @@ -74,7 +75,7 @@
>>      private Class<?>            returnType;
>>      private Class<?>[]          parameterTypes;
>>      private Class<?>[]          exceptionTypes;
>> -    private int                 modifiers;
>> +    @Stable private int         modifiers;
>>      // Generics and annotations support
>>      private transient String              signature;
>>      // generic info repository; lazily initialized
>> Index: src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java
>> IDEA additional info:
>> Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
>> <+>UTF-8
>> ===================================================================
>> --- src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java	(revision 8352a20bf54a085a97d3f703b5dab482d3f9eccc)
>> +++ src/java.base/share/classes/java/lang/reflect/ProxyGenerator.java	(date 1605870027579)
>> @@ -490,7 +490,7 @@
>>          for (List<ProxyMethod> sigmethods : proxyMethods.values()) {
>>              for (ProxyMethod pm : sigmethods) {
>>                  // add static field for the Method object
>> -                visitField(Modifier.PRIVATE | Modifier.STATIC, pm.methodFieldName,
>> +                visitField(Modifier.PRIVATE | Modifier.STATIC | Modifier.FINAL, pm.methodFieldName,
>>                          LJLR_METHOD, null, null);
>>  
>>                  // Generate code for proxy method
>> 
>> ...and this makes the following results:
>> 
>> Benchmark               Mode  Cnt   Score   Error  Units
>> ProxyBench.implClass    avgt    5   3.766 ? 0.040  ns/op
>> ProxyBench.implProxy    avgt    5  26.847 ? 0.626  ns/op
>> ProxyBench.ppImplClass  avgt    5   3.700 ? 0.017  ns/op
>> ProxyBench.ppImplProxy  avgt    5  26.322 ? 0.048  ns/op
>> 
>> But this can be changed as a follow-up patch that also takes care of Constructor and Field.
>
> @plevart I'm okay with this slight performance improvement.

I have a fresh look at the different options we have explored (lots of challenges in finding the right API with security, usability and performance issues to consider).   I agree with Remi that we should keep the design and API simple and makes it easier to invoke default methods with today's Proxy API.    We can design a better Proxy API in the future.   

The options we have explored are:
1. static `InvocationHandler::invokeDefault` method
2. abstract `DelegatingInvocationHandler` class with a protected `invokeDefault` method
3. a new `newProxyInstance` factory method taking a function that produces an invocation handler with the ability to invoke a default method via a `superHandler`

(1) is very simple API but caller-sensitive.  No other API change.   Access check done at default method invocation time (which is consistent with the core reflection `Method::invoke`).    It shares the caller class caching in `Method::checkAccess` which helps the performance.     The performance overhead is slightly higher than (2) & (3) which does access check at proxy creation time.

(2) is simple and I like that the `invokeDefault` can be enforced to be invoked only by the proxy's invocation handler.   However this requires more API changes (including `newProxyInstance`, `getInvocationHandler`, and new unchecked exception type).   (3) is clever but a bit over-rotated (how Alan describes it) to allow it to be expressed in a lambda expression.  If an invocation handler wants to save `superHandler`, it can't assign it to a final field in lambda and would need to workaround it writing to an array element.

I will go with option (1) -  static `invokeDefault` method [1] unless there is any objection. 

Here is the specdiff:
  http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/

[1] http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/java.base/java/lang/reflect/InvocationHandler.html#invokeDefault(java.lang.Object,java.lang.reflect.Method,java.lang.Object...)

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From mchung at openjdk.java.net  Fri Nov 20 20:03:07 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 20 Nov 2020 20:03:07 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
Message-ID: <KNTRfhuv-SQDYNpXgSzY4X2w3M06la8mU-4nAvHDQfo=.e36dd3eb-2df4-4529-afb6-7094fdb2ee6b@github.com>

On Fri, 20 Nov 2020 15:08:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From github.com+828220+forax at openjdk.java.net  Fri Nov 20 20:09:07 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Fri, 20 Nov 2020 20:09:07 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <1sMJ4tsGr88JeeluDvtTS0fSGgIvyrGbWk2uVsCzZU0=.d8aef781-9beb-4e7a-b029-699200628543@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
 <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
 <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
 <3_3xp4MbiLH-_9zyTkLVKZKP3ds0AftAVtbWo8tYeFs=.483fa478-0e33-495d-a545-b2339ecee592@github.com>
 <X93bQ76ydubQKGZAlD4ub43vTBHXjwnXQx--UN5xgus=.5e2ddf9d-86a5-4c34-b53a-65daff1d43df@github.com>
 <mthe4gxs2yOuXitvRF4Cwzbk4LLamGCDlx
 TaQJdRo_g=.edaa421c-e144-4466-a07f-251da9357364@github.com>
 <LrmZFLofpx4ewPC-GKlK9Z3xjIi4PrFLpOUL8qz6SJg=.ce86cf0c-c579-4d26-b68f-29b656ab78d3@github.com>
 <Xj3UDUQX-_oljQZ4TvbAcCeCKTL7Dz2PVsidXRQjywY=.921b1537-b302-4e88-9f91-c0b8c2d6c28f@github.com>
 <tpLs_qejlYlXcAeQNbsooyUHtIhKfzT9cLEyIymJM6E=.873923fa-bbaa-4a76-a9c1-a70ce8f98dfa@github.com>
 <Xj3I8gMkBmlyEccP6tATEvT-70n7dpDioSM8tAHRzyI=.62f16c04-f719-4e4c-89e0-0040743f0fbc@github.com>
 <1sMJ4tsGr88JeeluDvtTS0fSGgIvyrGbWk2uVsCzZU0=.d8aef781-9beb-4e7a-b029-699200628543@github.com>
Message-ID: <28mwUCcNsME5czLEhXQ4dCuzHhqQfT-6djtjo8Bh4vc=.5dacf38e-380d-4ccf-8583-709f9808b3c1@github.com>

On Fri, 20 Nov 2020 19:51:57 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> @plevart I'm okay with this slight performance improvement.
>
> I have a fresh look at the different options we have explored (lots of challenges in finding the right API with security, usability and performance issues to consider).   I agree with Remi that we should keep the design and API simple and makes it easier to invoke default methods with today's Proxy API.    We can design a better Proxy API in the future.   
> 
> The options we have explored are:
> 1. static `InvocationHandler::invokeDefault` method
> 2. abstract `DelegatingInvocationHandler` class with a protected `invokeDefault` method
> 3. a new `newProxyInstance` factory method taking a function that produces an invocation handler with the ability to invoke a default method via a `superHandler`
> 
> (1) is very simple API but caller-sensitive.  No other API change.   Access check done at default method invocation time (which is consistent with the core reflection `Method::invoke`).    It shares the caller class caching in `Method::checkAccess` which helps the performance.     The performance overhead is slightly higher than (2) & (3) which does access check at proxy creation time.
> 
> (2) is simple and I like that the `invokeDefault` can be enforced to be invoked only by the proxy's invocation handler.   However this requires more API changes (including `newProxyInstance`, `getInvocationHandler`, and new unchecked exception type).   (3) is clever but a bit over-rotated (how Alan describes it) to allow it to be expressed in a lambda expression.  If an invocation handler wants to save `superHandler`, it can't assign it to a final field in lambda and would need to workaround it writing to an array element.
> 
> I will go with option (1) -  static `invokeDefault` method [1] unless there is any objection. 
> 
> Here is the specdiff:
>   http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/
> 
> [1] http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/java.base/java/lang/reflect/InvocationHandler.html#invokeDefault(java.lang.Object,java.lang.reflect.Method,java.lang.Object...)

Hi Mandy,
thanks for taking the time to explore all the different options,

The solution 1 is fine for me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From ccleary at openjdk.java.net  Fri Nov 20 20:15:07 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Fri, 20 Nov 2020 20:15:07 GMT
Subject: Integrated: 8256183: InputStream.skipNBytes is missing @since 12
In-Reply-To: <sOJHtr9tnZp1n5StjYHRlpgvP3q3mNq9G-6bZarJL7s=.67302c78-5e9f-4b7f-b3be-d9a165a09684@github.com>
References: <sOJHtr9tnZp1n5StjYHRlpgvP3q3mNq9G-6bZarJL7s=.67302c78-5e9f-4b7f-b3be-d9a165a09684@github.com>
Message-ID: <GYZvKr7-psuvxbfQ3TEqP2xPlpHJcca37a1jAHzB1Kc=.56e01405-e318-4741-8857-16529be5f44f@github.com>

On Thu, 19 Nov 2020 12:35:04 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> InputStream.skipNBytes is missing `@since 12` tag which was not added during the review of [JDK-6516099](https://bugs.openjdk.java.net/browse/JDK-6516099).
> 
> This small fix adds the `@since` tag to InputStream.skipNBytes

This pull request has now been integrated.

Changeset: be6c8936
Author:    Conor Cleary <ccleary at openjdk.org>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/be6c8936
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8256183: InputStream.skipNBytes is missing @since 12

Reviewed-by: dfuchs, lancea, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1314

From smarks at openjdk.java.net  Fri Nov 20 20:15:08 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Fri, 20 Nov 2020 20:15:08 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <KNTRfhuv-SQDYNpXgSzY4X2w3M06la8mU-4nAvHDQfo=.e36dd3eb-2df4-4529-afb6-7094fdb2ee6b@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <KNTRfhuv-SQDYNpXgSzY4X2w3M06la8mU-4nAvHDQfo=.e36dd3eb-2df4-4529-afb6-7094fdb2ee6b@github.com>
Message-ID: <C5wgUmALPM359dZJVMr_pvM2Ij1mVORRJti2Oby28qg=.bce3ef94-229d-4e4d-9bde-5f2276c83732@github.com>

On Fri, 20 Nov 2020 19:59:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Fixed typo in @deprecated text
>>  - Merge
>>  - Update jshell class
>>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon
>
> Marked as reviewed by mchung (Reviewer).

I think the current deprecation wording is actually too specific regarding the raciness between TG destruction and created-but-not-started threads. That's just one of the flaws of thread groups. In fact, I think there are enough weirdnesses and race conditions around all destruction-related operations of thread groups that the whole concept is fundamentally flawed. We should just say that. How about this:

> ThreadGroup's destruction mechanisms are fundamentally flawed. Therefore, the ThreadGroup methods destroy(), isDestroyed(), setDaemon(), and isDaemon(), which relate to ThreadGroup destruction, have been deprecated and may be removed from a future version of the system.

I think there are too many subtle details to include a justification here about why TG destruction is fundamentally flawed, so we just have to assert that. Unfortunately the writeups in the JEP and CSR are in draft state so we can't link to them. Maybe when the JEP is published we can add a link to it from here later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From mchung at openjdk.java.net  Fri Nov 20 20:17:04 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 20 Nov 2020 20:17:04 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <28mwUCcNsME5czLEhXQ4dCuzHhqQfT-6djtjo8Bh4vc=.5dacf38e-380d-4ccf-8583-709f9808b3c1@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
 <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
 <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
 <3_3xp4MbiLH-_9zyTkLVKZKP3ds0AftAVtbWo8tYeFs=.483fa478-0e33-495d-a545-b2339ecee592@github.com>
 <X93bQ76ydubQKGZAlD4ub43vTBHXjwnXQx--UN5xgus=.5e2ddf9d-86a5-4c34-b53a-65daff1d43df@github.com>
 <mthe4gxs2yOuXitvRF4Cwzbk4LLamGCDlx
 TaQJdRo_g=.edaa421c-e144-4466-a07f-251da9357364@github.com>
 <LrmZFLofpx4ewPC-GKlK9Z3xjIi4PrFLpOUL8qz6SJg=.ce86cf0c-c579-4d26-b68f-29b656ab78d3@github.com>
 <Xj3UDUQX-_oljQZ4TvbAcCeCKTL7Dz2PVsidXRQjywY=.921b1537-b302-4e88-9f91-c0b8c2d6c28f@github.com>
 <tpLs_qejlYlXcAeQNbsooyUHtIhKfzT9cLEyIymJM6E=.873923fa-bbaa-4a76-a9c1-a70ce8f98dfa@github.com>
 <Xj3I8gMkBmlyEccP6tATEvT-70n7dpDioSM8tAHRzyI=.62f16c04-f719-4e4c-89e0-0040743f0fbc@github.com>
 <1sMJ4tsGr88JeeluDvtTS0fSGgIvyrGbWk2uVsCzZU0=.d8aef781-9beb-4e7a-b029-699200628543@github.com>
 <28mwUCcNsME5czLEhXQ4dCuzHhqQfT-6djtjo8Bh4vc=.5dacf38e-380d-4ccf-8583-709f9808b3c1@github.com>
Message-ID: <GQrqnFn-p6qoMXJsyw55n0aD6Yi0poBCFEEQzlAcst8=.c818f8b2-21fc-4b7d-95e9-bc12a86f9517@github.com>

On Fri, 20 Nov 2020 20:06:38 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> I have a fresh look at the different options we have explored (lots of challenges in finding the right API with security, usability and performance issues to consider).   I agree with Remi that we should keep the design and API simple and makes it easier to invoke default methods with today's Proxy API.    We can design a better Proxy API in the future.   
>> 
>> The options we have explored are:
>> 1. static `InvocationHandler::invokeDefault` method
>> 2. abstract `DelegatingInvocationHandler` class with a protected `invokeDefault` method
>> 3. a new `newProxyInstance` factory method taking a function that produces an invocation handler with the ability to invoke a default method via a `superHandler`
>> 
>> (1) is very simple API but caller-sensitive.  No other API change.   Access check done at default method invocation time (which is consistent with the core reflection `Method::invoke`).    It shares the caller class caching in `Method::checkAccess` which helps the performance.     The performance overhead is slightly higher than (2) & (3) which does access check at proxy creation time.
>> 
>> (2) is simple and I like that the `invokeDefault` can be enforced to be invoked only by the proxy's invocation handler.   However this requires more API changes (including `newProxyInstance`, `getInvocationHandler`, and new unchecked exception type).   (3) is clever but a bit over-rotated (how Alan describes it) to allow it to be expressed in a lambda expression.  If an invocation handler wants to save `superHandler`, it can't assign it to a final field in lambda and would need to workaround it writing to an array element.
>> 
>> I will go with option (1) -  static `invokeDefault` method [1] unless there is any objection. 
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8253870
>> 
>> Here is the specdiff:
>>   http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/
>> 
>> [1] http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/java.base/java/lang/reflect/InvocationHandler.html#invokeDefault(java.lang.Object,java.lang.reflect.Method,java.lang.Object...)
>
> Hi Mandy,
> thanks for taking the time to explore all the different options,
> 
> The solution 1 is fine for me.

Thanks Remi.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From mchung at openjdk.java.net  Fri Nov 20 20:26:13 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Fri, 20 Nov 2020 20:26:13 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v4]
In-Reply-To: <K9VUz-ZEbZvwn9hVtg-BpsxJBsDxf1hKTSyvhFgdxrA=.4f06ae1e-c5e6-4231-ae86-1a0ba69c3431@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <tKPyoN5O290X_W3n2DF1jvunO0YBoyNnoT5jXjmsNc0=.ecc67352-e2ef-4408-9ac1-e5e90a345424@github.com>
 <K9VUz-ZEbZvwn9hVtg-BpsxJBsDxf1hKTSyvhFgdxrA=.4f06ae1e-c5e6-4231-ae86-1a0ba69c3431@github.com>
Message-ID: <k7GPFD1XzIxPE3xSA02aHGvHe-CAMleQ9pyoir3U-34=.2e5b37c4-cc8b-42eb-86b5-ab34438cfee4@github.com>

On Thu, 19 Nov 2020 10:59:30 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the name passed to condy calling classData
>
> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2148:
> 
>> 2146:          * (unlike private static fields that are accessible to nestmates).
>> 2147:          * Care should be taken w.r.t. mutability for example when passing
>> 2148:          * an array or other mutable structure through the class data.
> 
> I don't think it's necessarily clear _why_/_how_ care should be taken from this text. I suggest:
> Suggestion:
> 
>          * Care should be taken w.r.t. mutability for example when passing
>          * an array or other mutable structure through the class data. Such
>          * a constant should not be mutated, as downstream consumers of
>          * this constant, such as other constants, are not guaranteed to see
>          * the updated value, depending on the timing of their resolution.

What about:

--- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
+++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
@@ -2156,8 +2156,10 @@ public class MethodHandles {
          * (unlike private static fields that are accessible to nestmates).
          * Care should be taken w.r.t. mutability for example when passing
          * an array or other mutable structure through the class data.
-         * If you use a {@code List}, it is a good practice to make it unmodifiable
-         * for example via {@link List#of List::of}.
+         * Changing any value stored at the class data at runtime may lead to
+         * unpredictable behavior.
+         * If the class data is a {@code List}, it is a good practice to make it
+         * unmodifiable for example via {@link List#of List::of}.
          *
          * @param bytes     the class bytes
          * @param classData pre-initialized class data

-------------

PR: https://git.openjdk.java.net/jdk/pull/1171

From jvernee at openjdk.java.net  Fri Nov 20 20:33:06 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 20 Nov 2020 20:33:06 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v4]
In-Reply-To: <k7GPFD1XzIxPE3xSA02aHGvHe-CAMleQ9pyoir3U-34=.2e5b37c4-cc8b-42eb-86b5-ab34438cfee4@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <tKPyoN5O290X_W3n2DF1jvunO0YBoyNnoT5jXjmsNc0=.ecc67352-e2ef-4408-9ac1-e5e90a345424@github.com>
 <K9VUz-ZEbZvwn9hVtg-BpsxJBsDxf1hKTSyvhFgdxrA=.4f06ae1e-c5e6-4231-ae86-1a0ba69c3431@github.com>
 <k7GPFD1XzIxPE3xSA02aHGvHe-CAMleQ9pyoir3U-34=.2e5b37c4-cc8b-42eb-86b5-ab34438cfee4@github.com>
Message-ID: <AYbhWL3pXQFHd0HuxEQ4FBkyCMl-3qCILtYWzAO4YDE=.d33f4d02-8e8f-43c8-97bf-b33010fdafd5@github.com>

On Fri, 20 Nov 2020 20:23:27 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/MethodHandles.java line 2148:
>> 
>>> 2146:          * (unlike private static fields that are accessible to nestmates).
>>> 2147:          * Care should be taken w.r.t. mutability for example when passing
>>> 2148:          * an array or other mutable structure through the class data.
>> 
>> I don't think it's necessarily clear _why_/_how_ care should be taken from this text. I suggest:
>> Suggestion:
>> 
>>          * Care should be taken w.r.t. mutability for example when passing
>>          * an array or other mutable structure through the class data. Such
>>          * a constant should not be mutated, as downstream consumers of
>>          * this constant, such as other constants, are not guaranteed to see
>>          * the updated value, depending on the timing of their resolution.
>
> What about:
> 
> --- a/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> +++ b/src/java.base/share/classes/java/lang/invoke/MethodHandles.java
> @@ -2156,8 +2156,10 @@ public class MethodHandles {
>           * (unlike private static fields that are accessible to nestmates).
>           * Care should be taken w.r.t. mutability for example when passing
>           * an array or other mutable structure through the class data.
> -         * If you use a {@code List}, it is a good practice to make it unmodifiable
> -         * for example via {@link List#of List::of}.
> +         * Changing any value stored at the class data at runtime may lead to
> +         * unpredictable behavior.
> +         * If the class data is a {@code List}, it is a good practice to make it
> +         * unmodifiable for example via {@link List#of List::of}.
>           *
>           * @param bytes     the class bytes
>           * @param classData pre-initialized class data

Looks good!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1171

From plevart at openjdk.java.net  Fri Nov 20 21:26:04 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Fri, 20 Nov 2020 21:26:04 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <GQrqnFn-p6qoMXJsyw55n0aD6Yi0poBCFEEQzlAcst8=.c818f8b2-21fc-4b7d-95e9-bc12a86f9517@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
 <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
 <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
 <3_3xp4MbiLH-_9zyTkLVKZKP3ds0AftAVtbWo8tYeFs=.483fa478-0e33-495d-a545-b2339ecee592@github.com>
 <X93bQ76ydubQKGZAlD4ub43vTBHXjwnXQx--UN5xgus=.5e2ddf9d-86a5-4c34-b53a-65daff1d43df@github.com>
 <mthe4gxs2yOuXitvRF4Cwzbk4LLamGCDlx
 TaQJdRo_g=.edaa421c-e144-4466-a07f-251da9357364@github.com>
 <LrmZFLofpx4ewPC-GKlK9Z3xjIi4PrFLpOUL8qz6SJg=.ce86cf0c-c579-4d26-b68f-29b656ab78d3@github.com>
 <Xj3UDUQX-_oljQZ4TvbAcCeCKTL7Dz2PVsidXRQjywY=.921b1537-b302-4e88-9f91-c0b8c2d6c28f@github.com>
 <tpLs_qejlYlXcAeQNbsooyUHtIhKfzT9cLEyIymJM6E=.873923fa-bbaa-4a76-a9c1-a70ce8f98dfa@github.com>
 <Xj3I8gMkBmlyEccP6tATEvT-70n7dpDioSM8tAHRzyI=.62f16c04-f719-4e4c-89e0-0040743f0fbc@github.com>
 <1sMJ4tsGr88JeeluDvtTS0fSGgIvyrGbWk2uVsCzZU0=.d8aef781-9beb-4e7a-b029-699200628543@github.com>
 <28mwUCcNsME5czLEhXQ4dCuzHhqQfT-6djtjo8Bh4vc=.5dacf38e-380d-4ccf-8583-709f9808b3c1@github.com>
 <GQrqnFn-p6qoMXJsyw55n0aD6Yi0poBCFEEQzlAcst8=.c818f8b2-21fc-4b7d-95e9-bc12a86f9517@github.com>
Message-ID: <OthdPyDJ9rNhiFdACaswoG6lCFhkU-2itkzSZiA1diQ=.3cc883ac-30b7-49a8-9cf1-4165bc57c153@github.com>

On Fri, 20 Nov 2020 20:14:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Hi Mandy,
>> thanks for taking the time to explore all the different options,
>> 
>> The solution 1 is fine for me.
>
> Thanks Remi.

I agree solution 1 is the best after all things considered.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From joehw at openjdk.java.net  Fri Nov 20 21:48:05 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Fri, 20 Nov 2020 21:48:05 GMT
Subject: RFR: 8247432: Update IANA Language Subtag Registry to Version
 2020-09-29
In-Reply-To: <eATYqJ38ckiQ1oLj3YvsIjp84ZCEchfVw-4usoIrACc=.fdf34a23-e455-474d-9f86-b361c4b6ed8c@github.com>
References: <eATYqJ38ckiQ1oLj3YvsIjp84ZCEchfVw-4usoIrACc=.fdf34a23-e455-474d-9f86-b361c4b6ed8c@github.com>
Message-ID: <LpGv3NViw_6283T43Ef-TKbWG1WtEduzXFWhHq36nSk=.b7251d5f-5a79-4f52-994d-d7c7fd6013e9@github.com>

On Fri, 20 Nov 2020 17:55:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1357

From bchristi at openjdk.java.net  Fri Nov 20 23:01:05 2020
From: bchristi at openjdk.java.net (Brent Christian)
Date: Fri, 20 Nov 2020 23:01:05 GMT
Subject: RFR: 8256480: Refactor ObjectInputStream field reader
 implementation [v2]
In-Reply-To: <jErR-1aeFunUfrgXvSxBEH1NWJlIAWM9F0r0FI7nCh4=.b268c661-55c5-4c9f-a5ed-9cf04d8f926c@github.com>
References: <57N_l5oDQywDYUYK-EH1Odb00ipNZxHTNg_NSzfx2Ww=.d11b14a5-8b9c-421e-a92d-cac8462b0f8e@github.com>
 <jErR-1aeFunUfrgXvSxBEH1NWJlIAWM9F0r0FI7nCh4=.b268c661-55c5-4c9f-a5ed-9cf04d8f926c@github.com>
Message-ID: <gCH97HEwYcKpOwwLILKZSjVBn4r6axJDcJvlPqlf_Xc=.9393fa5a-2a5b-4de7-b352-46214b25a109@github.com>

On Thu, 19 Nov 2020 20:32:17 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> ObjectInputStream has nearly identical but separate implementations to read values from the stream.
>> Both implementations read primitive and object values from the stream and return an object holding the values.
>> OIS.readFields() uses the internal class GetFieldImpl while OIS.defaultReadObject and reading records uses the internal class FieldValues.
>> The behavioral difference between the two is whether dependencies are tracked in the object handle table or not. 
>> 
>> The classes are merged, retaining the internal FieldValues name and the behavior to track dependencies or not. 
>> The constructor is passed the class descriptor and flag to track or not; it reads and saves the values from the stream.
>> The callers are updated to call the merge FieldValues methods.
>> 
>> There is no change in behavior; all current tests pass.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Improvements as per review comments

The changes look fine.

-------------

Marked as reviewed by bchristi (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1296

From github.com+1472572+rogermb at openjdk.java.net  Fri Nov 20 23:44:04 2020
From: github.com+1472572+rogermb at openjdk.java.net (Roger Baumgartner)
Date: Fri, 20 Nov 2020 23:44:04 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <zbIcDJfP9fQjax6Po7skY376oKgX2gjSTYJ38nEcdjc=.51414f9e-ff04-4ae0-8398-53182d2c0787@github.com>

On Wed, 18 Nov 2020 13:45:12 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

src/java.base/share/classes/java/util/random/package-info.java line 149:

> 147:  *
> 148:  * <p> For an application running in a 32-bit hardware environment and using
> 149:  * only one thread or a small number of threads, may be a good choice.

I think the name of the suitable algorithm is missing here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From mchung at openjdk.java.net  Sat Nov 21 00:39:23 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Sat, 21 Nov 2020 00:39:23 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v5]
In-Reply-To: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
Message-ID: <zJd-CmYkGv8JsHMoHzHXrKw4M-kulbd_jYlCCH0l7EQ=.5dd965d6-cb3d-471d-a9e1-c615855ba8dc@github.com>

> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects
> be shared between a hidden class and other classes.  A hidden class can load
> these live objects as dynamically-computed constants via this API.
> 
> Specdiff
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
> 
> With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass`
> will be deprecated for removal.  Existing libraries should replace their
> calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass`
> or `Lookup::defineHiddenClassWithClassData`.
> 
> This patch also updates the implementation of lambda meta factory and
> `MemoryAccessVarHandleGenerator` to use class data.   No performance difference
> observed in the jdk.incubator.foreign microbenchmarks.   A side note: 
> `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of 
> JDK-8254162 but it helps validating the class data support.
> 
> Background
> ----------
> 
> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
> "Constant-pool patching" in the "Risks and Assumption" section.
> 
> A VM-anonymous class can be defined with its constant-pool entries already
> resolved to concrete values. This allows critical constants to be shared
> between a VM-anonymous class and the language runtime that defines it, and
> between multiple VM-anonymous classes. For example, a language runtime will
> often have `MethodHandle` objects in its address space that would be useful
> to newly-defined VM-anonymous classes. Instead of the runtime serializing
> the objects to constant-pool entries in VM-anonymous classes and then
> generating bytecode in those classes to laboriously `ldc` the entries,
> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
> to its live objects. The relevant constant-pool entries in the newly-defined
> VM-anonymous class are pre-linked to those objects, improving performance
> and reducing footprint. In addition, this allows VM-anonymous classes to
> refer to each other: Constant-pool entries in a class file are based on names.
> They thus cannot refer to nameless VM-anonymous classes. A language runtime can,
> however, easily track the live Class objects for its VM-anonymous classes and
> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's
> constant pool entries to other VM-anonymous classes.
> 
> This extends the hidden classes to allow live objects to be injected
> in a hidden class and loaded them via condy.
> 
> Details
> -------
> 
> A new `Lookup::defineHiddenClassWithClassData` API takes additional
> `classData` argument compared to `Lookup::defineHiddenClass`.
> Class data can be method handles, lookup objects, arbitrary user objects
> or collections of all of the above.
> 
> This method behaves as if calling `Lookup::defineHiddenClass` to define
> a hidden class with a private static unnamed field that is initialized
> with `classData` at the first instruction of the class initializer.
> 
> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)` and
> `MethodHandles::classDataAt(Lookup lookup, String name, Class<?> type, int index)`
> are the bootstrap methods to load the class data of the given lookup's lookup class.
> The hidden class will be initialized when `classData` method is called if
> the hidden class has not been initialized.
> 
> For a class data containing more than one single element, libraries can
> create their convenience method to load a single live object via condy.
> 
> Frameworks sometimes want to dynamically create a hidden class (HC) and add it
> it the lookup class nest and have HC to carry secrets hidden from that nest.
> In this case, frameworks should not to use private static finals (in the HCs
> they spin) to hold secrets because a nestmate of HC may obtain access to
> such a private static final and observe the framework's secret.  It should use
> condy.  In addition, we need to differentiate if a lookup object is created from
> the original lookup class or created from teleporting e.g. `Lookup::in`
> and `MethodHandles::privateLookupIn`.
> 
> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
> object is created by `MethodHandles::lookup` or by bootstrap method invocation.
> The operations only apply to a Lookup object with original access are:
>    - create method handles for caller-sensitve methods
>    - obtain class data associated with the lookup class
> 
> No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which
> ignores the ORIGINAL bit.
> 
> 
> Compatibility Risks
> -------------------
> 
> `Lookup::lookupModes` includes a new `ORIGINAL` bit.  Most lookup operations
> ignore this original bit except creating method handles for caller-sensitive methods
> that expects the lookup from the original lookup class.  Existing code  compares
> the return value of `lookupModes` to be a fixed value may be impacted.   However
> existing client has no need to expect a fixed value of lookup modes.
> The incompatibility risk of this spec change is low.

Mandy Chung has updated the pull request incrementally with three additional commits since the last revision:

 - slight tweak of api note
 - Fix revealDirect to check for original access.
 - Incorporate Paul's feedback

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1171/files
  - new: https://git.openjdk.java.net/jdk/pull/1171/files/f1f36738..9a008ae5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1171&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1171&range=03-04

  Stats: 155 lines in 5 files changed: 47 ins; 37 del; 71 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1171.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1171/head:pull/1171

PR: https://git.openjdk.java.net/jdk/pull/1171

From github.com+1290376+johnlinp at openjdk.java.net  Sat Nov 21 09:24:16 2020
From: github.com+1290376+johnlinp at openjdk.java.net (John Lin)
Date: Sat, 21 Nov 2020 09:24:16 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
 <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
 <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
Message-ID: <TFCxfLxB7_iDyPbbSXJtWZZm4HOW_n4R66vMnNEzYvI=.1659cc00-17c8-4999-bbb7-b5c7516599b7@github.com>

On Wed, 18 Nov 2020 14:16:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> @dfuch May I ask how can I create a CSR? I checked https://wiki.openjdk.java.net/display/csr/CSR+FAQs and it says:
>> 
>>> 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 at https://bugs.openjdk.java.net/ yet. Therefore, I don't see the "More" button on https://bugs.openjdk.java.net/browse/JDK-8247402. Could you please tell me how do I proceed? Thank you.
>
> @johnlinp, you cannot create a CSR by yourself at the moment. Someone else will have to do that for you. Might as well be me. So here's my proposal: come up with the meat, then I'll help you with the paperwork. 
> 
> For starters, have a look at existing CSRs (you don't need a JBS account for that). For example, https://bugs.openjdk.java.net/issues/?jql=issuetype%3DCSR%20and%20Subcomponent%3Djava.util%3Acollections%20
> 
> Fill in an informal CSR template inline in this thread, and we'll proceed from that point. Is that okay?

@pavelrappo Please see my proposed CSR below. Thank you.

# Map::compute should have a clearer implementation requirement.

## Summary

java.util.Map::compute should have a clearer implementation requirement in its documentation.

## Problem

The documentation of the implementation requirements for Map::compute has the following problems:
1. It lacks of return statements for most of the if-else cases.
1. The indents are 3 spaces, while the convention is 4 spaces.
1. The if-else is overly complicated and can be simplified.

## Solution

Rewrite the documentation of Map::compute to match its default implementation.

## Specification

diff --git a/src/java.base/share/classes/java/util/Map.java b/src/java.base/share/classes/java/util/Map.java
index b1de34b42a5..c3118a90581 100644
--- a/src/java.base/share/classes/java/util/Map.java
+++ b/src/java.base/share/classes/java/util/Map.java
@@ -1113,17 +1113,12 @@ public interface Map<K, V> {
      * <pre> {@code
      * V oldValue = map.get(key);
      * V newValue = remappingFunction.apply(key, oldValue);
-     * if (oldValue != null) {
-     *    if (newValue != null)
-     *       map.put(key, newValue);
-     *    else
-     *       map.remove(key);
-     * } else {
-     *    if (newValue != null)
-     *       map.put(key, newValue);
-     *    else
-     *       return null;
+     * if (newValue != null) {
+     *     map.put(key, newValue);
+     * } else if (oldValue != null) {
+     *     map.remove(key);
      * }
+     * return newValue;
      * }</pre>
      *
      * <p>The default implementation makes no guarantees about detecting if the

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From github.com+828220+forax at openjdk.java.net  Sat Nov 21 11:02:16 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 21 Nov 2020 11:02:16 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v3]
In-Reply-To: <4CY9WKRujRFgx526Z2joGTNdI4OGIJUI9omHgMnhReg=.8bf6e1d5-8ba9-4f7c-80bf-8adde581a9f6@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <bUKuBU0ScUvhnCa-rUjJDUCPUfcPmS-OqMXyTSBsUeU=.2430a5a0-076e-4f16-9d1d-0dfa49faa99d@github.com>
 <4CY9WKRujRFgx526Z2joGTNdI4OGIJUI9omHgMnhReg=.8bf6e1d5-8ba9-4f7c-80bf-8adde581a9f6@github.com>
Message-ID: <WAgg3Ghp9_8_QnvxMD-7hIsfjOiGXDd6dpq-MsEZxdA=.a337bd69-516a-4622-9999-797f0a2abd3f@github.com>

On Thu, 5 Nov 2020 17:26:48 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/ImmutableCollections.java line 199:
>> 
>>> 197:      * safely reused as the List's internal storage, avoiding a defensive copy. Declared
>>> 198:      * with Object... instead of E... as the parameter type so that varargs calls don't
>>> 199:      * accidentally create an array of type other than Object[].
>> 
>> Why would that be a problem? If the resulting list is immutable, then the actual array type doesn't really matter, right?
>
> It's an implementation invariant that the internal array be Object[]. Having it be something other than Object[] can lead to subtle bugs. See [JDK-6260652](https://bugs.openjdk.java.net/browse/JDK-6260652) for example.

you can still calls the varargs with an already created array
listFromTrustedArray(new String[] { "foo" });

I think at least an assert is missing
assert input.getClass() == Object.class;

-------------

PR: https://git.openjdk.java.net/jdk/pull/1026

From github.com+828220+forax at openjdk.java.net  Sat Nov 21 11:05:25 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 21 Nov 2020 11:05:25 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v3]
In-Reply-To: <Mr9vpzMowscNpOjJ52oOlJO50L8x6drIxHb44rVpb1k=.80331bd0-ab10-4658-a5de-d6939251ba25@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <Mr9vpzMowscNpOjJ52oOlJO50L8x6drIxHb44rVpb1k=.80331bd0-ab10-4658-a5de-d6939251ba25@github.com>
Message-ID: <xpK6ZtSDaf5quZvll3MPVaCkJU3EMyGVszEBfp0ZoXM=.ddde0a41-eb9b-4f62-9e92-d2e363f81b31@github.com>

On Wed, 18 Nov 2020 22:20:26 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
>> 
>> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
>> 
>> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
>> 
>> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust List.copyOf to null-check and copy allowNulls lists.
>   Fix equals, hashCode, indexOf, lastIndexOf to handle nulls properly.
>   Add MOAT tests for new lists; add equals and hashCode tests.

src/java.base/share/classes/java/util/ImmutableCollections.java line 222:

> 220:             default:
> 221:                 return (List<E>) new ListN<>(input, false);
> 222:         }

Using a switch expression + arrow (->) here will allow you too factor the cast, even if it disappear in the generated bytecode, I think it makes the code more readable

-------------

PR: https://git.openjdk.java.net/jdk/pull/1026

From github.com+828220+forax at openjdk.java.net  Sat Nov 21 11:26:20 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Sat, 21 Nov 2020 11:26:20 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v3]
In-Reply-To: <zUyJi1Y8IGbR3Hv50ZWy1OS0oqFycWzHLP7iVECLTec=.2b79a385-c78d-46b3-9b4b-2d5d7bc2d071@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <3N2Oa4dVVDShlyR-w1G8jWG7mNPL5utzKFdm0QWkM3Y=.0cee9962-8dfb-40f3-b9ae-e50ea8377ed3@github.com>
 <zUyJi1Y8IGbR3Hv50ZWy1OS0oqFycWzHLP7iVECLTec=.2b79a385-c78d-46b3-9b4b-2d5d7bc2d071@github.com>
Message-ID: <nYmGmOTAId25YFeWQ0PJkB7j658prrjepUr8q9k7kUI=.ba169da0-e72b-4a16-9639-9c301b3d58bc@github.com>

On Wed, 4 Nov 2020 09:21:12 GMT, Tagir F. Valeev <tvaleev at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/stream/Stream.java line 1192:
>> 
>>> 1190:     @SuppressWarnings("unchecked")
>>> 1191:     default List<T> toList() {
>>> 1192:         return (List<T>) Collections.unmodifiableList(new ArrayList<>(Arrays.asList(this.toArray())));
>> 
>> Why can't we return `listFromTrustedArrayNullsAllowed` here as in `ReferencePipeline`?
>> Or at least, we should avoid unnecessary copying of arrays. See [how this is done](https://github.com/amaembo/streamex/blob/master/src/main/java/one/util/streamex/AbstractStreamEx.java#L1313) in StreamEx.
>
> `listFromTrustedArrayNullsAllowed` is clearly not an option, as it will produce shared-secret leaking (see [JDK-8254090](https://bugs.openjdk.java.net/browse/JDK-8254090) for a similar case). StreamEx solution is dirty as it relies on the implementation detail. I believe, OpenJDK team is not very interested in providing optimal implementations for third-party stream implementations, as third-party implementations will likely update by themselves when necessary. At least, my suggestion to make the default `mapMulti` implementation better was declined.

This implementation duplicates the array twice, once in this.toArray() and once in the constructor of ArrayList that calls toArray() on Collections.ArrayList.

I'm sure there is a better way

-------------

PR: https://git.openjdk.java.net/jdk/pull/1026

From forax at univ-mlv.fr  Sat Nov 21 12:03:59 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 21 Nov 2020 13:03:59 +0100 (CET)
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <24865095.1772546.1605960239461.JavaMail.zimbra@u-pem.fr>

Ok, i've taking the time to read some literature about random generators because for me the Mersenne Twister was still the king.

The current API proposed as clearly two levels, you have the user level and the implementation level, at least the implementation level should seen as a SPI 

RandomGenerator is the user facing API, for me it should be the sole interface exposed by the API, the others (leap, arbitrary leap and split) should be optional methods.

In term of factory methods, we should have user driven methods:
- getDefaultGenerator() that currently returns a L64X128MixRandom and can be changed in the future
- getFastGenerator() that currently returns a Xoroshiro128PlusPlus and can be changed in the future
- getDefault[Splitable|Leapable|etc]Generator that returns a default generator with the methods splits|leaps|etc defined
- of / getByName that returns a specific generator by its name (but mov ed in a SPI class)

The example in the documentation should use getDefaultGenerator() and not of() to avoid the problem all the programming languages currently have by having over-specified that the default generator is a Mersenne Twister.

All methods that returns a stream of the available implementations should be moved in the SPI package.

R?mi 

---
An honest question,
why do we need so many interfaces for the different categories of RandomGenerator ?

My fear is that we are encoding the state of our knowledge of the different kinds of random generators now so it will not be pretty in the future when new categories of random generator are discovered/invented.
If we can take example of the past to predict the future, 20 years ago, what should have been the hierarchy at that time.
Is it not reasonable to think that we will need new kinds of random generator in the future ?

I wonder if it's not better to have one interface and several optional methods like we have with the collections, it means that we are loosing the possibilities to precisely type a method that only works with a precise type of generator but it will be more future proof.

R?mi

----- Mail original -----
> De: "Jim Laskey" <jlaskey at openjdk.java.net>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "security-dev" <security-dev at openjdk.java.net>
> Envoy?: Mercredi 18 Novembre 2020 14:52:56
> Objet: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

> 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
> 
> -------------
> 
> Commit messages:
> - 8248862: Implement Enhanced Pseudo-Random Number Generators
> - 8248862: Implement Enhanced Pseudo-Random Number Generators
> - 8248862: Implement Enhanced Pseudo-Random Number Generators
> - 8248862: Implement Enhanced Pseudo-Random Number Generators
> - 8248862: Implement Enhanced Pseudo-Random Number Generators
> - 8248862; Implement Enhanced Pseudo-Random Number Generators
> - 8248862: Implement Enhanced Pseudo-Random Number Generators
> - 8248862: Implement Enhanced Pseudo-Random Number Generators
> - 8248862: Implement Enhanced Pseudo-Random Number Generators
> - 8248862: Implement Enhanced Pseudo-Random Number Generators
> - ... and 15 more: https://git.openjdk.java.net/jdk/compare/f7517386...2b3e4ed7
> 
> Changes: https://git.openjdk.java.net/jdk/pull/1292/files
> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=00
>  Issue: https://bugs.openjdk.java.net/browse/JDK-8248862
>  Stats: 13319 lines in 25 files changed: 11110 ins; 2132 del; 77 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 herrick at openjdk.java.net  Sat Nov 21 14:05:24 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Sat, 21 Nov 2020 14:05:24 GMT
Subject: RFR: JDK-8256475: Fix Behavior when Installer name differs from
 =?UTF-8?B?YXBwbGljYXRpb+KApg==?= [v4]
In-Reply-To: <nqArmaMcxW3kEhjhKLzI_tC6v5grcxbbwNM4jQ_n4U0=.644fe28f-1f44-459e-b193-e9d86ac7c34f@github.com>
References: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
 <25b-I2aVPI49KXdos4hcWbUtza3gOoMjrxAd49ca_P4=.ee575d41-5cf4-407f-add1-cdfbe220bdaa@github.com>
 <nqArmaMcxW3kEhjhKLzI_tC6v5grcxbbwNM4jQ_n4U0=.644fe28f-1f44-459e-b193-e9d86ac7c34f@github.com>
Message-ID: <DdDoz6gkKNVsCzaGLWHT1BP5cJv4aFzO9sVxyGfaHCE=.2ba170fa-979f-4547-9aa4-c57631112684@github.com>

On Thu, 19 Nov 2020 23:32:22 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8256475: Fix Behavior when Installer name differs from application name.
>
> Marked as reviewed by almatvee (Committer).

@azuev-java - can you review as well ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1300

From clanger at openjdk.java.net  Sat Nov 21 23:24:47 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Sat, 21 Nov 2020 23:24:47 GMT
Subject: RFR: 8256818: SSLSocket that is never bound or connected leaks
 socket resources
In-Reply-To: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>
References: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>
Message-ID: <SbLXcfqiOkPX6uhR_UkhC3v1RgK2hPVJ8Yb72J4T6KM=.e2557d56-1588-4e78-9fd4-3a5ec62a0744@github.com>

On Sat, 21 Nov 2020 08:32:17 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to leaking socket resources after JDK-8224829.
> 
> The close method calls duplexCloseOutput() and duplexCloseInput(). In case of an exception in any of these methods, the call to closeSocket() is bypassed, and the underlying Socket may not be closed.
> 
> This manifests in a real life leak after JDK-8224829 has introduced a call to getSoLinger() on the path of duplexCloseOutput -> closeNotify. If socket impl / OS socket hadn't been created yet it is done at that place. But then after duplexCloseOutput eventually fails with a SocketException since the socket wasn't connected, closing fails to call Socket::close().
> 
> This problem can be reproduced by this code:
> 		        SSLSocket sslSocket = (SSLSocket)SSLSocketFactory.getDefault().createSocket();
> 		        sslSocket.getSSLParameters();
> 		        sslSocket.close();
> 
> This is what happens when SSLContext.getDefault().getDefaultSSLParameters() is called, with close() being eventually called by the finalizer.
> 
> I'll open this PR as draft for now to start discussion. I'll create a testcase to reproduce the issue and add it soon.
> 
> I propose to modify the close method such that duplexClose is only done on a connected/bound socket. Maybe it even suffices to only do it when connected.
> 
> Secondly, I'm proposing to improve exception handling a bit. So in case there's an IOException on the path of duplexClose, it is caught and logged. But the real close moves to the finally block since it should be done unconditionally.

I changed the check for when to do duplexClose to only do it when socket isConnected().

I also added a testcase which should work on all platforms. For windows I borrowed some functionality introduced lately with test java/lang/ProcessBuilder/checkHandles/CheckHandles.java which I moved to the test library for that reason.

Now it's ready to review.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1363

From clanger at openjdk.java.net  Sat Nov 21 23:24:47 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Sat, 21 Nov 2020 23:24:47 GMT
Subject: RFR: 8256818: SSLSocket that is never bound or connected leaks socket
 resources
Message-ID: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>

There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to leaking socket resources after JDK-8224829.

The close method calls duplexCloseOutput() and duplexCloseInput(). In case of an exception in any of these methods, the call to closeSocket() is bypassed, and the underlying Socket may not be closed.

This manifests in a real life leak after JDK-8224829 has introduced a call to getSoLinger() on the path of duplexCloseOutput -> closeNotify. If socket impl / OS socket hadn't been created yet it is done at that place. But then after duplexCloseOutput eventually fails with a SocketException since the socket wasn't connected, closing fails to call Socket::close().

This problem can be reproduced by this code:
		        SSLSocket sslSocket = (SSLSocket)SSLSocketFactory.getDefault().createSocket();
		        sslSocket.getSSLParameters();
		        sslSocket.close();

This is what happens when SSLContext.getDefault().getDefaultSSLParameters() is called, with close() being eventually called by the finalizer.

I'll open this PR as draft for now to start discussion. I'll create a testcase to reproduce the issue and add it soon.

I propose to modify the close method such that duplexClose is only done on a connected/bound socket. Maybe it even suffices to only do it when connected.

Secondly, I'm proposing to improve exception handling a bit. So in case there's an IOException on the path of duplexClose, it is caught and logged. But the real close moves to the finally block since it should be done unconditionally.

-------------

Commit messages:
 - Add testcase for socket leak
 - Only duplexClose when socket isConnected()
 - 8256818: SSLSocket that is never bound or connected leaks socket resources

Changes: https://git.openjdk.java.net/jdk/pull/1363/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1363&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256818
  Stats: 130 lines in 5 files changed: 98 ins; 15 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1363.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1363/head:pull/1363

PR: https://git.openjdk.java.net/jdk/pull/1363

From clanger at openjdk.java.net  Sun Nov 22 10:45:44 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Sun, 22 Nov 2020 10:45:44 GMT
Subject: RFR: 8256818: SSLSocket that is never bound or connected leaks
 socket resources [v2]
In-Reply-To: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>
References: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>
Message-ID: <ssKjVa-fc_Oe8eK-Rc8z8zz3q7NuN-egry0z5LgOG3g=.93b0e24b-8da6-49ca-bf1b-acf8eea42eec@github.com>

> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to leaking socket resources after JDK-8224829.
> 
> The close method calls duplexCloseOutput() and duplexCloseInput(). In case of an exception in any of these methods, the call to closeSocket() is bypassed, and the underlying Socket may not be closed.
> 
> This manifests in a real life leak after JDK-8224829 has introduced a call to getSoLinger() on the path of duplexCloseOutput -> closeNotify. If socket impl / OS socket hadn't been created yet it is done at that place. But then after duplexCloseOutput eventually fails with a SocketException since the socket wasn't connected, closing fails to call Socket::close().
> 
> This problem can be reproduced by this code:
> 		        SSLSocket sslSocket = (SSLSocket)SSLSocketFactory.getDefault().createSocket();
> 		        sslSocket.getSSLParameters();
> 		        sslSocket.close();
> 
> This is what happens when SSLContext.getDefault().getDefaultSSLParameters() is called, with close() being eventually called by the finalizer.
> 
> I'll open this PR as draft for now to start discussion. I'll create a testcase to reproduce the issue and add it soon.
> 
> I propose to modify the close method such that duplexClose is only done on a connected/bound socket. Maybe it even suffices to only do it when connected.
> 
> Secondly, I'm proposing to improve exception handling a bit. So in case there's an IOException on the path of duplexClose, it is caught and logged. But the real close moves to the finally block since it should be done unconditionally.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Simplify the test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1363/files
  - new: https://git.openjdk.java.net/jdk/pull/1363/files/c1663d93..34a1a218

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1363&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1363&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1363.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1363/head:pull/1363

PR: https://git.openjdk.java.net/jdk/pull/1363

From alanb at openjdk.java.net  Sun Nov 22 16:00:45 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 22 Nov 2020 16:00:45 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v3]
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <vDmkugOG_EATqtXaLA73yTD04IAtIVOT92_cixJfTqM=.d2f05630-f0ea-4f5a-be38-5742dd4aea00@github.com>

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Tweak wording of @deprecated message to make it more general
 - Merge
 - Fixed typo in @deprecated text
 - Merge
 - Update jshell class
 - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1318/files
  - new: https://git.openjdk.java.net/jdk/pull/1318/files/ca656ba1..38d951b9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1318&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1318&range=01-02

  Stats: 1688 lines in 57 files changed: 885 ins; 381 del; 422 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1318.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1318/head:pull/1318

PR: https://git.openjdk.java.net/jdk/pull/1318

From alanb at openjdk.java.net  Sun Nov 22 16:05:24 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 22 Nov 2020 16:05:24 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v2]
In-Reply-To: <C5wgUmALPM359dZJVMr_pvM2Ij1mVORRJti2Oby28qg=.bce3ef94-229d-4e4d-9bde-5f2276c83732@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <RRVLRjoHWVYwwijsMK9vhFLMUBlHqc1xl74HitS7PCw=.1c81d763-43ac-4bea-ba15-c10e15672410@github.com>
 <KNTRfhuv-SQDYNpXgSzY4X2w3M06la8mU-4nAvHDQfo=.e36dd3eb-2df4-4529-afb6-7094fdb2ee6b@github.com>
 <C5wgUmALPM359dZJVMr_pvM2Ij1mVORRJti2Oby28qg=.bce3ef94-229d-4e4d-9bde-5f2276c83732@github.com>
Message-ID: <jTvzKn7GriuFfNKgxLnz0bSa-AWRI0tmIIuPz3l692E=.057ca93b-33fc-42ad-8ede-3103d2a716f1@github.com>

On Fri, 20 Nov 2020 20:12:31 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Marked as reviewed by mchung (Reviewer).
>
> I think the current deprecation wording is actually too specific regarding the raciness between TG destruction and created-but-not-started threads. That's just one of the flaws of thread groups. In fact, I think there are enough weirdnesses and race conditions around all destruction-related operations of thread groups that the whole concept is fundamentally flawed. We should just say that. How about this:
> 
>> ThreadGroup's destruction mechanisms are fundamentally flawed. Therefore, the ThreadGroup methods destroy(), isDestroyed(), setDaemon(), and isDaemon(), which relate to ThreadGroup destruction, have been deprecated and may be removed from a future version of the system.
> 
> I think there are too many subtle details to include a justification here about why TG destruction is fundamentally flawed, so we just have to assert that. Unfortunately the writeups in the JEP and CSR are in draft state so we can't link to them. Maybe when the JEP is published we can add a link to it from here later.

Okay, I think I agree that the first sentence needs to be a bit more general so I've re-worded it. I used "inherently" rather than "fundamentally" to be consistent with the other deprecation text in Thread/ThreadGroup. If you are okay with the updated text then I'll transfer it to the CSR.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From alanb at openjdk.java.net  Sun Nov 22 16:07:26 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Sun, 22 Nov 2020 16:07:26 GMT
Subject: RFR: 8159746: (proxy) Support for default methods
In-Reply-To: <OthdPyDJ9rNhiFdACaswoG6lCFhkU-2itkzSZiA1diQ=.3cc883ac-30b7-49a8-9cf1-4165bc57c153@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <U-6RiCpFVIrhLztPN6opiPcpFtxValDzU-K7WWFZM-4=.6bc8aaa4-636a-4664-b380-4c4af00513bd@github.com>
 <-cLIJ8pFHtnNoJMHV3aXI7XMJWp4Jrutc8Xn5PG0OK8=.d2cd87ab-3592-4524-ad85-05444c43689b@github.com>
 <r0UK2qjnmgeTNDDSWaSLPAj3QRgx_4YB82ielllO7jM=.fa615bc0-db49-4a74-b842-793f8f5209bb@github.com>
 <1T8kXDZN1bhHr4c8v4SQsImeBySCqTfX-u3_jzvyocA=.b4957400-9a33-4b6e-8475-329642a5888c@github.com>
 <XIux-dY0JXHRafHk48kVNXId9r-HSceNSytBojDxelY=.872e74cb-b064-406e-b71f-13c90ec7fbbc@github.com>
 <j4t2vT0SnwnU7lhKRlXtk967d-K6nA0EqHrqNbba7W0=.dc05dba6-bf7e-4606-8a02-9c2bad4b3b58@github.com>
 <fmVtPcBdgMuZOPm2qx3Q3znVZM7JgQPkhPAVLtwkOhE=.2d8b8447-cfae-4cb3-9a7c-6567a881231f@github.com>
 <GSeWP29fAIUFSk0CYsC557w52CuLqeUWwHNK9maltwI=.3d5f002e-6b74-4a57-a5d8-244d27da9dde@github.com>
 <GF8iEOkMUEL2dYB0HytFIc9gyeeUJ_KP0ImlqFsul2Y=.894afc05-9310-43e1-a308-8f7d71dc572b@github.com>
 <HvtDex3cmiv7XeTMITOroYfu74amSGQavQ_
 BAmVzmXw=.223be989-7c20-4ba4-ac0d-013d2b75a8cb@github.com>
 <IqRiLphFPBpGiKAnMJXqxjie9YeZ03rcE-qG1s92BLw=.d4fd5e92-5067-40df-8a0b-1dfd3d6e23af@github.com>
 <Y0hE51G3YefI6NY1O_E6VoZSKwxE78S1hv6fEatmOG8=.0a2c686c-d9ad-418c-8c1b-49addb8a54b1@github.com>
 <QrNk57L2PWQhJjzYiGTsvYyGIPAfK7bP_kANtTR-2uM=.3e5ce990-f8ea-4751-8147-27a8a9dad40d@github.com>
 <9JNNUzfV3PSvKtSg2a_zyYJmgEn3sZL9cb5sfqemk2o=.f1ef7fb7-bdd5-44ed-98c8-59213e9094f9@github.com>
 <zWGhaC8YB5I0XgffiR7o_YT5gSp9Gbj8Drtt23brl-c=.1e59f0e4-bbe3-4fb2-94dc-c55fc862f091@github.com>
 <LljojgqBhEi6tFptsbmu1jS-Xx7lYEXm9tRkkPqDGzE=.3d7d6a37-1042-4539-88d1-9f4cf5378128@github.com>
 <Gn33ydZNxqOpWUrmYiWJadMF0mukI2MR85EtgrV4D1I=.958521f2-1167-4a68-b513-e10bba37ae18@github.com>
 <NMXKaHql9XjndqPgyoN1Lasa9H8ugl8-ltD1j2XiT9Y=.3ff8871e-0f9d-40ea-8f35-e804a9afcbd5@github.com>
 <yzFe02HJ2qt5tT8tY9ZOofnKld93x1PM5U7AToTABJs=.439c213b-94b9-488f-bb6d-a835a86c527f@github.com>
 <BoATjx7PPcLpINJVC5HM77UKMriIUqnnhcBowkJRlvM=.1221e3e1-ed27-4618-8365-dcd903d27f60@
 github.com>
 <yN0JJE9mBkqz9Ijbw4FYinv08tcnxiZHAGyarXBF9CY=.50429cb9-181a-447e-90a0-e0a0a836812e@github.com>
 <CoqZRJ39DVdNI9wzS372aAG3ZIB7hrIrndaO5VrsmBA=.f78629d2-3409-44c1-9e66-7951bbd630e6@github.com>
 <W6qIb_NPGRUpQd_obRiIumwbXSTDheSdg-qnkc3cZ90=.f1f46290-3b7c-4e88-994f-5d19e0134256@github.com>
 <nALY_XHf4_MGKZHIzpIRbqLEG22ySg0NZ8mQbun7up0=.69d14612-31a4-4533-924c-01768ed50be1@github.com>
 <dWu0mcInZ8duRgGoQRfdgKXASYodtIhqgoejf-weUek=.eec68bf3-1a34-4f4b-82ca-6be48caeff1c@github.com>
 <S-gpV6ntV3fkkjzvU8PYpAWAJVWpvdykReMXyRVwd9U=.0893dd0d-55d0-49c1-9bb9-883005fed496@github.com>
 <VE9aWCMrcLW5QIl0wRpGppb0gObfI0cfbg0DnuKRfSs=.e398df44-4b64-465a-9697-8b4d2ed1652d@github.com>
 <50_1vC3yErplQgnnTNJHpF-d0ibuMKtRa9kg3jGKymc=.978abc22-8b04-49ed-b950-7bafe2b1931a@github.com>
 <3_3xp4MbiLH-_9zyTkLVKZKP3ds0AftAVtbWo8tYeFs=.483fa478-0e33-495d-a545-b2339ecee592@github.com>
 <X93bQ76ydubQKGZAlD4ub43vTBHXjwnXQx--UN5xgus=.5e2ddf9d-86a5-4c34-b53a-65daff1d43df@github.com>
 <mthe4gxs2yOuXitvRF4Cwzbk4LLamGCDlx
 TaQJdRo_g=.edaa421c-e144-4466-a07f-251da9357364@github.com>
 <LrmZFLofpx4ewPC-GKlK9Z3xjIi4PrFLpOUL8qz6SJg=.ce86cf0c-c579-4d26-b68f-29b656ab78d3@github.com>
 <Xj3UDUQX-_oljQZ4TvbAcCeCKTL7Dz2PVsidXRQjywY=.921b1537-b302-4e88-9f91-c0b8c2d6c28f@github.com>
 <tpLs_qejlYlXcAeQNbsooyUHtIhKfzT9cLEyIymJM6E=.873923fa-bbaa-4a76-a9c1-a70ce8f98dfa@github.com>
 <Xj3I8gMkBmlyEccP6tATEvT-70n7dpDioSM8tAHRzyI=.62f16c04-f719-4e4c-89e0-0040743f0fbc@github.com>
 <1sMJ4tsGr88JeeluDvtTS0fSGgIvyrGbWk2uVsCzZU0=.d8aef781-9beb-4e7a-b029-699200628543@github.com>
 <28mwUCcNsME5czLEhXQ4dCuzHhqQfT-6djtjo8Bh4vc=.5dacf38e-380d-4ccf-8583-709f9808b3c1@github.com>
 <GQrqnFn-p6qoMXJsyw55n0aD6Yi0poBCFEEQzlAcst8=.c818f8b2-21fc-4b7d-95e9-bc12a86f9517@github.com>
 <OthdPyDJ9rNhiFdACaswoG6lCFhkU-2itkzSZiA1diQ=.3cc883ac-30b7-49a8-9cf1-4165bc57c153@github.com>
Message-ID: <dAZpUDEzApsmPxrvvYAIJz4Vi6dsnHW7tdh8BIIqZPk=.2939af11-0f4b-405a-8637-ab3f6850c763@github.com>

On Fri, 20 Nov 2020 21:23:35 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> Thanks Remi.
>
> I agree solution 1 is the best after all things considered.

I"m also okay with with option 1, which is essentially the original proposal exception that it defines the method on InnovocationHandler instead of Proxy. Thanks Mandy and Peter for the prototypes, options, and iterations.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From clanger at openjdk.java.net  Sun Nov 22 18:27:56 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Sun, 22 Nov 2020 18:27:56 GMT
Subject: RFR: 8256818: SSLSocket that is never bound or connected leaks
 socket resources [v3]
In-Reply-To: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>
References: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>
Message-ID: <4_PBT9hcenuv1E6ksPKKd0K9jMLdWQNADguEHvOmdYk=.006c5b9f-ed94-4ad9-b4aa-f63de2b03dd9@github.com>

> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to leaking socket resources after JDK-8224829.
> 
> The close method calls duplexCloseOutput() and duplexCloseInput(). In case of an exception in any of these methods, the call to closeSocket() is bypassed, and the underlying Socket may not be closed.
> 
> This manifests in a real life leak after JDK-8224829 has introduced a call to getSoLinger() on the path of duplexCloseOutput -> closeNotify. If socket impl / OS socket hadn't been created yet it is done at that place. But then after duplexCloseOutput eventually fails with a SocketException since the socket wasn't connected, closing fails to call Socket::close().
> 
> This problem can be reproduced by this code:
> 		        SSLSocket sslSocket = (SSLSocket)SSLSocketFactory.getDefault().createSocket();
> 		        sslSocket.getSSLParameters();
> 		        sslSocket.close();
> 
> This is what happens when SSLContext.getDefault().getDefaultSSLParameters() is called, with close() being eventually called by the finalizer.
> 
> I'll open this PR as draft for now to start discussion. I'll create a testcase to reproduce the issue and add it soon.
> 
> I propose to modify the close method such that duplexClose is only done on a connected/bound socket. Maybe it even suffices to only do it when connected.
> 
> Secondly, I'm proposing to improve exception handling a bit. So in case there's an IOException on the path of duplexClose, it is caught and logged. But the real close moves to the finally block since it should be done unconditionally.

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Small test improvement

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1363/files
  - new: https://git.openjdk.java.net/jdk/pull/1363/files/34a1a218..e280436b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1363&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1363&range=01-02

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1363.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1363/head:pull/1363

PR: https://git.openjdk.java.net/jdk/pull/1363

From kbarrett at openjdk.java.net  Sun Nov 22 22:19:51 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Sun, 22 Nov 2020 22:19:51 GMT
Subject: RFR: 8256370: Add asserts to Reference.getInactive()
In-Reply-To: <FqR4moRH9Y3KtU7P8UUxA1Gi2VDJqnY4W2b4OgkF0kg=.9bfe984e-3c84-4ea2-95a7-4e88bfba9d55@github.com>
References: <-QVwpOcOTp5Gb7Sjq04ihTxP5h0nMHCh307WqkEjE-M=.83b69e68-19e6-4a10-8bd3-010d2c008140@github.com>
 <FqR4moRH9Y3KtU7P8UUxA1Gi2VDJqnY4W2b4OgkF0kg=.9bfe984e-3c84-4ea2-95a7-4e88bfba9d55@github.com>
Message-ID: <XQ56pY_DemIe8Fq029A_XLUyoDyBpWBFDD71s-dQUrU=.81a2079d-eea6-4e08-a64e-d9c4e42df579@github.com>

On Mon, 16 Nov 2020 18:30:38 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> A follow-up to JDK-8256106, this is adding two asserts to check that the API is used as it should be, i.e. only on inactive FinalReferences. Also, in Finalizer, where getInactive() is used, there is a null-check. The GC must never clean the referent, and Java code doesn't clean it either, it would be a bug if we ever see null there. I think it's better to fail there (with assert or NPE) when that happens instead of silently accepting it.
>> 
>> Testing:
>>  - [x] tier1
>>  - [x] tier2
>
> Thanks for adding this asserts.  If there is any reason to use `getInactive` by other references in the future, we could remove these asserts at that time.

I didn't notice this before it was integrated.

The test for inactive isn't right; rather than `next == this` it
should be `next != null`.  This becomes apparent once
FinalizerHistogram is fixed to call getInactive() rather than get().

I noticed this while working on JDK-8256517, where I ran into some
similar issues.  I will address these problems as part of that change.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1231

From kbarrett at openjdk.java.net  Mon Nov 23 02:41:27 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Mon, 23 Nov 2020 02:41:27 GMT
Subject: RFR: 8256517: (ref) Reference.clear during reference processing may
 lose notification
Message-ID: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>

Please review this change to Reference.clear() to address several issues.

(JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
field to null may extend the lifetime of the referent value.

(JDK-8240696) For GCs with concurrent reference processing, clearing the
referent field during reference processing may discard the expected
notification.

Both of these are addressed by introducing a private native helper function
for clearing the referent, rather than using an ordinary in-Java field
assignment. Tests have been added for both of these issues. This required
adding a new breakpoint in reference processing for ZGC.

Of course, finalization adds some complexity to the problem.  We deal with
that by having FinalReference override clear.  The implementation is
provided by a new package-private method in Reference.  (There are a number
of alternatives, all of them clumsy; finalization is annoying that way.)

While dealing with FinalReference clearing it was noted that the recent
JDK-8256106 and JDK-8256370 have some problems. FinalizerHistogram was not
updated to call the new Reference.getInactive(), instead still calling get()
on FinalReferences, with the JDK-8256106 problems. Fixing that showed the
assertion for inactive FinalReference added by JDK-8256370 used the wrong
test.

Rather than tracking down and changing all get() and clear() calls on final
references and changing them to use getInactive and a new similar clear
function, I've changed FinalReference to override get and clear, which call
the helper functions in Reference. I've also renamed getInactive to be more
explanatory and less convenient to call directly, and similarly named the
helper for clear. This means that get/clear should never be called on an
active FinalReference. That's already never done, and would have problems
if it were.

Testing:
mach5 tier1-6
Local (linux-x64) tier1 using Shenandoah.
New TestReferenceClearDuringMarking fails for G1 without these changes.
New TestReferenceClearDuringReferenceProcessing fails for ZGC without these changes.

-------------

Commit messages:
 - add private native Reference::clear0
 - test clear during marking
 - test clear during reference processing

Changes: https://git.openjdk.java.net/jdk/pull/1376/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1376&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256517
  Stats: 304 lines in 13 files changed: 279 ins; 16 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1376/head:pull/1376

PR: https://git.openjdk.java.net/jdk/pull/1376

From chegar at openjdk.java.net  Mon Nov 23 10:26:00 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 23 Nov 2020 10:26:00 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v4]
In-Reply-To: <K9VUz-ZEbZvwn9hVtg-BpsxJBsDxf1hKTSyvhFgdxrA=.4f06ae1e-c5e6-4231-ae86-1a0ba69c3431@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <tKPyoN5O290X_W3n2DF1jvunO0YBoyNnoT5jXjmsNc0=.ecc67352-e2ef-4408-9ac1-e5e90a345424@github.com>
 <K9VUz-ZEbZvwn9hVtg-BpsxJBsDxf1hKTSyvhFgdxrA=.4f06ae1e-c5e6-4231-ae86-1a0ba69c3431@github.com>
Message-ID: <4UhMfpMR51CIIMA1Sl6ZQOEtvwgkdFHujTEUmxR0YQE=.96094f68-b698-469b-b20f-143d237ced02@github.com>

On Thu, 19 Nov 2020 11:08:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix the name passed to condy calling classData
>
> Left 2 minor comments on the new additions in line.

It is my understanding that `Lookup` object returned from defineHiddenClass[WithClassData] features the ORIGINAL access lookup mode, right? I cannot find a normative statement to confirm this. If it is the case, then it would be good to clarify this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1171

From rkennke at openjdk.java.net  Mon Nov 23 10:31:57 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 23 Nov 2020 10:31:57 GMT
Subject: RFR: 8256370: Add asserts to Reference.getInactive()
In-Reply-To: <XQ56pY_DemIe8Fq029A_XLUyoDyBpWBFDD71s-dQUrU=.81a2079d-eea6-4e08-a64e-d9c4e42df579@github.com>
References: <-QVwpOcOTp5Gb7Sjq04ihTxP5h0nMHCh307WqkEjE-M=.83b69e68-19e6-4a10-8bd3-010d2c008140@github.com>
 <FqR4moRH9Y3KtU7P8UUxA1Gi2VDJqnY4W2b4OgkF0kg=.9bfe984e-3c84-4ea2-95a7-4e88bfba9d55@github.com>
 <XQ56pY_DemIe8Fq029A_XLUyoDyBpWBFDD71s-dQUrU=.81a2079d-eea6-4e08-a64e-d9c4e42df579@github.com>
Message-ID: <7Vr9Plzqeg6G-BkFZ4OaVzaJiB491vh_BZtwiRKRnrY=.59f0209e-850f-4c1b-bed0-ec8f904e9fe6@github.com>

On Sun, 22 Nov 2020 22:15:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> I didn't notice this before it was integrated.
> 
> The test for inactive isn't right; rather than `next == this` it
> should be `next != null`. This becomes apparent once
> FinalizerHistogram is fixed to call getInactive() rather than get().
> 
> I noticed this while working on JDK-8256517, where I ran into some
> similar issues. I will address these problems as part of that change.

Oh ok. Thanks for taking care of it!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1231

From mcimadamore at openjdk.java.net  Mon Nov 23 11:04:09 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 23 Nov 2020 11:04:09 GMT
Subject: Integrated: 8254231: Implementation of Foreign Linker API (Incubator)
In-Reply-To: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
References: <mIByVl0V6gxbGVP8z021rptVd3Ky7lbznN6ODaNGwDU=.44357025-f251-436c-8fa0-c2c130768111@github.com>
Message-ID: <XFxwk5llQGu-jMpqORk4ZUIUDLNdl70WAj17KJCxRwE=.2f39565e-11da-42d8-87af-42ece8ef45f9@github.com>

On Tue, 13 Oct 2020 13:08:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch contains the changes associated with the first incubation round of the foreign linker access API incubation
> (see JEP 389 [1]). This work is meant to sit on top of the foreign memory access support (see JEP 393 [2] and associated pull request [3]).
> 
> The main goal of this API is to provide a way to call native functions from Java code without the need of intermediate JNI glue code. In order to do this, native calls are modeled through the MethodHandle API. I suggest reading the writeup [4] I put together few weeks ago, which illustrates what the foreign linker support is, and how it should be used by clients.
> 
> Disclaimer: the pull request mechanism isn't great at managing *dependent* reviews. For this reasons, I'm attaching a webrev which contains only the differences between this PR and the memory access PR. I will be periodically uploading new webrevs, as new iterations come out, to try and make the life of reviewers as simple as possible.
> 
> A big thank to Jorn Vernee and Vladimir Ivanov - they are the main architects of all the hotspot changes you see here, and without their help, the foreign linker support wouldn't be what it is today. As usual, a big thank to Paul Sandoz, who provided many insights (often by trying the bits first hand).
> 
> Thanks
> Maurizio
> 
> Webrev:
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/webrev
> 
> Javadoc:
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/javadoc/jdk/incubator/foreign/package-summary.html
> 
> Specdiff (relative to [3]):
> 
> http://cr.openjdk.java.net/~mcimadamore/8254231_v1/specdiff_delta/overview-summary.html
> 
> CSR:
> 
> https://bugs.openjdk.java.net/browse/JDK-8254232
> 
> 
> 
> ### API Changes
> 
> The API changes are actually rather slim:
> 
> * `LibraryLookup`
>   * This class allows clients to lookup symbols in native libraries; the interface is fairly simple; you can load a library by name, or absolute path, and then lookup symbols on that library.
> * `FunctionDescriptor`
>   * This is an abstraction that is very similar, in spirit, to `MethodType`; it is, at its core, an aggregate of memory layouts for the function arguments/return type. A function descriptor is used to describe the signature of a native function.
> * `CLinker`
>   * This is the real star of the show. A `CLinker` has two main methods: `downcallHandle` and `upcallStub`; the first takes a native symbol (as obtained from `LibraryLookup`), a `MethodType` and a `FunctionDescriptor` and returns a `MethodHandle` instance which can be used to call the target native symbol. The second takes an existing method handle, and a `FunctionDescriptor` and returns a new `MemorySegment` corresponding to a code stub allocated by the VM which acts as a trampoline from native code to the user-provided method handle. This is very useful for implementing upcalls.
>    * This class also contains the various layout constants that should be used by clients when describing native signatures (e.g. `C_LONG` and friends); these layouts contain additional ABI classfication information (in the form of layout attributes) which is used by the runtime to *infer* how Java arguments should be shuffled for the native call to take place.
>   * Finally, this class provides some helper functions e.g. so that clients can convert Java strings into C strings and back.
> * `NativeScope`
>   * This is an helper class which allows clients to group together logically related allocations; that is, rather than allocating separate memory segments using separate *try-with-resource* constructs, a `NativeScope` allows clients to use a _single_ block, and allocate all the required segments there. This is not only an usability boost, but also a performance boost, since not all allocation requests will be turned into `malloc` calls.
> * `MemorySegment`
>   * Only one method added here - namely `handoff(NativeScope)` which allows a segment to be transferred onto an existing native scope.
> 
> ### Safety
> 
> The foreign linker API is intrinsically unsafe; many things can go wrong when requesting a native method handle. For instance, the description of the native signature might be wrong (e.g. have too many arguments) - and the runtime has, in the general case, no way to detect such mismatches. For these reasons, obtaining a `CLinker` instance is a *restricted* operation, which can be enabled by specifying the usual JDK property `-Dforeign.restricted=permit` (as it's the case for other restricted method in the foreign memory API).
> 
> ### Implementation changes
> 
> The Java changes associated with `LibraryLookup` are relative straightforward; the only interesting thing to note here is that library loading does _not_ depend on class loaders, so `LibraryLookup` is not subject to the same restrictions which apply to JNI library loading (e.g. same library cannot be loaded by different classloaders).
> 
> As for `NativeScope` the changes are again relatively straightforward; it is an API which sits neatly on top of the foreign meory access API, providing some kind of allocation service which shares the same underlying memory segment(s), and turns an allocation request into a segment slice, which is a much less expensive operation. `NativeScope` comes in two variants: there are native scopes for which the allocation size is known a priori, and native scopes which can grow - these two schemes are implemented by two separate subclasses of `AbstractNativeScopeImpl`.
> 
> Of course the bulk of the changes are to support the `CLinker` downcall/upcall routines. These changes cut pretty deep into the JVM; I'll briefly summarize the goal of some of this changes - for further details, Jorn has put together a detailed writeup which explains the rationale behind the VM support, with some references to the code [5].
> 
> The main idea behind foreign linker is to infer, given a Java method type (expressed as a `MethodType` instance) and the description of the signature of a native function (expressed as a `FunctionDescriptor` instance) a _recipe_ that can be used to turn a Java call into the corresponding native call targeting the requested native function.
> 
> This inference scheme can be defined in a pretty straightforward fashion by looking at the various ABI specifications (for instance, see [6] for the SysV ABI, which is the one used on Linux/Mac). The various `CallArranger` classes, of which we have a flavor for each supported platform, do exactly that kind of inference.
> 
> For the inference process to work, we need to attach extra information to memory layouts; it is no longer sufficient to know e.g. that a layout is 32/64 bits - we need to know whether it is meant to represent a floating point value, or an integral value; this knowledge is required because floating points are passed in different registers by most ABIs. For this reason, `CLinker` offers a set of pre-baked, platform-dependent layout constants which contain the required classification attributes (e.g. a `Clinker.TypeKind` enum value). The runtime extracts this attribute, and performs classification accordingly.
> 
> A native call is decomposed into a sequence of basic, primitive operations, called `Binding` (see the great javadoc on the `Binding.java` class for more info). There are many such bindings - for instance the `Move` binding is used to move a value into a specific machine register/stack slot. So, the main job of the various `CallingArranger` classes is to determine, given a Java `MethodType` and `FunctionDescriptor` what is the set of bindings associated with the downcall/upcall.
> 
> At the heart of the foreign linker support is the `ProgrammableInvoker` class. This class effectively generates a `MethodHandle` which follows the steps described by the various bindings obtained by `CallArranger`. There are actually various strategies to interpret these bindings - listed below:
> 
> * basic intepreted mode; in this mode, all bindings are interpreted using a stack-based machine written in Java (see `BindingInterpreter`), except for the `Move` bindings. For these bindings, the move is implemented by allocating a *buffer* (whose size is ABI specific) and by moving all the lowered values into positions within this buffer. The buffer is then passed to a piece of assembly code inside the VM which takes values from the buffer and moves them in their expected registers/stack slots (note that each position in the buffer corresponds to a different register). This is the most general invocation mode, the more "customizable" one, but also the slowest - since for every call there is some extra allocation which takes place.
> 
> * specialized interpreted mode; same as before, but instead of interpreting the bindings with a stack-based interpreter, we generate a method handle chain which effectively interprets all the bindings (again, except `Move` ones).
> 
> * intrinsified mode; this is typically used in combination with the specialized interpreted mode described above (although it can also be used with the Java-based binding interpreter). The goal here is to remove the buffer allocation and copy by introducing an additional JVM intrinsic. If a native call recipe is constant (e.g. the set of bindings is constant, which is probably the case if the native method handle is stored in a `static`, `final` field), then the VM can generate specialized assembly code which interprets the `Move` binding without the need to go for an intermediate buffer. This gives us back performances that are on par with JNI.
> 
> For upcalls, the support is not (yet) as advanced, and only the basic interpreted mode is available there. We plan to add support for intrinsified modes there as well, which should considerably boost perfomances (probably well beyond what JNI can offer at the moment, since the upcall support in JNI is not very well optimized).
> 
> Again, for more readings on the internals of the foreign linker support, please refer to [5].
> 
> #### Test changes
> 
> Many new tests have been added to validate the foreign linker support; we have high level tests (see `StdLibTest`) which aim at testing the linker from the perspective of code that clients could write. But we also have deeper combinatorial tests (see `TestUpcall` and `TestDowncall`) which are meant to stress every corner of the ABI implementation. There are also some great tests (see the `callarranger` folder) which test the various `CallArranger`s for all the possible platforms; these tests adopt more of a white-box approach - that is, instead of treating the linker machinery as a black box and verify that the support works by checking that the native call returned the results we expected, these tests aims at checking that the set of bindings generated by the call arranger is correct. This also mean that we can test the classification logic for Windows, Mac and Linux regardless of the platform we're executing on.
> 
> Some additional microbenchmarks have been added to compare the performances of downcall/upcall with JNI.
> 
> [1] - https://openjdk.java.net/jeps/389
> [2] - https://openjdk.java.net/jeps/393
> [3] - https://git.openjdk.java.net/jdk/pull/548
> [4] - https://github.com/openjdk/panama-foreign/blob/foreign-jextract/doc/panama_ffi.md
> [5] - http://cr.openjdk.java.net/~jvernee/docs/Foreign-abi%20downcall%20intrinsics%20technical%20description.html

This pull request has now been integrated.

Changeset: 0fb31dbf
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/0fb31dbf
Stats:     67469 lines in 212 files changed: 67290 ins; 79 del; 100 mod

8254231: Implementation of Foreign Linker API (Incubator)

Reviewed-by: coleenp, ihse, dholmes, vlivanov

-------------

PR: https://git.openjdk.java.net/jdk/pull/634

From ccleary at openjdk.java.net  Mon Nov 23 11:52:59 2020
From: ccleary at openjdk.java.net (Conor Cleary)
Date: Mon, 23 Nov 2020 11:52:59 GMT
Subject: Integrated: 8256154: Some TestNG tests require default constructors
In-Reply-To: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
References: <TH8W6Le8YKDXFufbJ84vLSYbYruvc3AUi0CaIs4O78Q=.dd9e9db4-c88c-4349-a77e-7ccfe108930d@github.com>
Message-ID: <5_3WGKXCRBaYc9mVpOsCE09l_sMnHBxMhrkKL6lC6Kg=.b104aa8b-7900-41b8-9ee3-f4b395366f29@github.com>

On Thu, 19 Nov 2020 13:50:30 GMT, Conor Cleary <ccleary at openjdk.org> wrote:

> In TestNG 7, it is a requirement that TestNG is able to create a Test object using a default constructor. 
> 
> This simple fix addresses two such classes so that this requirement is satisfied by inserting default construtors. Example: `public GetPackages() { ... }`
> 
> test/jdk/java/lang/Package/GetPackages.java
> test/jdk/java/lang/StackWalker/Basic.java

This pull request has now been integrated.

Changeset: 5ed70448
Author:    Conor Cleary <ccleary at openjdk.org>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/5ed70448
Stats:     13 lines in 2 files changed: 11 ins; 0 del; 2 mod

8256154: Some TestNG tests require default constructors

Reviewed-by: dfuchs, bpb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1317

From pliden at openjdk.java.net  Mon Nov 23 12:52:56 2020
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 23 Nov 2020 12:52:56 GMT
Subject: RFR: 8256517: (ref) Reference.clear during reference processing
 may lose notification
In-Reply-To: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
References: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
Message-ID: <ul7I2y7Wz9BR5j9rAOQqwL-H-xYEAHOD1_Zr4oZlPp8=.91a31ce0-b032-4099-b24e-95f273c7d0b5@github.com>

On Mon, 23 Nov 2020 01:43:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to Reference.clear() to address several issues.
> 
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
> 
> (JDK-8240696) For GCs with concurrent reference processing, clearing the
> referent field during reference processing may discard the expected
> notification.
> 
> Both of these are addressed by introducing a private native helper function
> for clearing the referent, rather than using an ordinary in-Java field
> assignment. Tests have been added for both of these issues. This required
> adding a new breakpoint in reference processing for ZGC.
> 
> Of course, finalization adds some complexity to the problem.  We deal with
> that by having FinalReference override clear.  The implementation is
> provided by a new package-private method in Reference.  (There are a number
> of alternatives, all of them clumsy; finalization is annoying that way.)
> 
> While dealing with FinalReference clearing it was noted that the recent
> JDK-8256106 and JDK-8256370 have some problems. FinalizerHistogram was not
> updated to call the new Reference.getInactive(), instead still calling get()
> on FinalReferences, with the JDK-8256106 problems. Fixing that showed the
> assertion for inactive FinalReference added by JDK-8256370 used the wrong
> test.
> 
> Rather than tracking down and changing all get() and clear() calls on final
> references and changing them to use getInactive and a new similar clear
> function, I've changed FinalReference to override get and clear, which call
> the helper functions in Reference. I've also renamed getInactive to be more
> explanatory and less convenient to call directly, and similarly named the
> helper for clear. This means that get/clear should never be called on an
> active FinalReference. That's already never done, and would have problems
> if it were.
> 
> Testing:
> mach5 tier1-6
> Local (linux-x64) tier1 using Shenandoah.
> New TestReferenceClearDuringMarking fails for G1 without these changes.
> New TestReferenceClearDuringReferenceProcessing fails for ZGC without these changes.

Looks good. Just want to request that you also remove the following comment in zReferenceProcessor.cpp, as it's no longer true.

--- a/src/hotspot/share/gc/z/zReferenceProcessor.cpp
+++ b/src/hotspot/share/gc/z/zReferenceProcessor.cpp
@@ -184,12 +184,6 @@ bool ZReferenceProcessor::should_discover(oop reference, ReferenceType type) con
 }
 
 bool ZReferenceProcessor::should_drop(oop reference, ReferenceType type) const {
-  // This check is racing with a call to Reference.clear() from the application.
-  // If the application clears the reference after this check it will still end
-  // up on the pending list, and there's nothing we can do about that without
-  // changing the Reference.clear() API. This check is also racing with a call
-  // to Reference.enqueue() from the application, which is unproblematic, since
-  // the application wants the reference to be enqueued anyway.
   const oop referent = reference_referent(reference);
   if (referent == NULL) {
     // Reference has been cleared, by a call to Reference.enqueue()

-------------

Changes requested by pliden (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1376

From jvernee at openjdk.java.net  Mon Nov 23 13:12:08 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 23 Nov 2020 13:12:08 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
Message-ID: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>

JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.

Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.

However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.

Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.

Testing: `make images` on Linux and Windows x86_32 platforms.

-------------

Commit messages:
 - Remove UnsupportedPlatform test
 - Remove unneeded cast
 - Remove Stuff that makes the jdk_foreign tests pass
 - fix test warnings
 - - Fix 32-bit build errors and tests

Changes: https://git.openjdk.java.net/jdk/pull/1266/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256486
  Stats: 95 lines in 11 files changed: 55 ins; 26 del; 14 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1266.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266

PR: https://git.openjdk.java.net/jdk/pull/1266

From james.laskey at oracle.com  Mon Nov 23 13:27:31 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Mon, 23 Nov 2020 09:27:31 -0400
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <676865722.1878668.1605655096153.JavaMail.zimbra@u-pem.fr>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
 <6h9eeR6HFk03eD3DCtXjJo9Wg81zWH1090paXb-Yp1k=.da9e5ecd-377a-488f-a2f6-b43876af6f60@github.com>
 <676865722.1878668.1605655096153.JavaMail.zimbra@u-pem.fr>
Message-ID: <740D04D2-6FCB-44B7-BC57-6347B27171B5@oracle.com>

[Sorry it took so long. Have been on break.]

From Guy:

Thanks for the forward.  Here are my thoughts:

Good question from R?mi.

If we consider PRNGs to have started at about the time of von Neumann, circa 1946, then I would say that we have been inventing a new category about once every 25 years or so: jumpable, multi-level jumpable, cryptographically secure, splittable.  Twenty years ago we would just have one or more levels of jumping/leaping.  I think SecureRandom appeared in 2002 (in J2SE 1.4), and the first version of SplittableRandom was in 2014.

So I could be wrong, but I really don?t expect to have to add any more interfaces in the next decade or two.  I think we will get more benefit from the better type checking than we would get with optional methods.

?Guy


> On Nov 17, 2020, at 7:18 PM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> An honest question,
> why do we need so many interfaces for the different categories of RandomGenerator ?
> 
> My fear is that we are encoding the state of our knowledge of the different kinds of random generators now so it will not be pretty in the future when new categories of random generator are discovered/invented.
> If we can take example of the past to predict the future, 20 years ago, what should have been the hierarchy at that time.
> Is it not reasonable to think that we will need new kinds of random generator in the future ?
> 
> I wonder if it's not better to have one interface and several optional methods like we have with the collections, it means that we are loosing the possibilities to precisely type a method that only works with a precise type of generator but it will be more future proof.
> 
> R?mi
> 
> ----- Mail original -----
>> De: "Jim Laskey" <jlaskey at openjdk.java.net>
>> ?: "build-dev" <build-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>,
>> security-dev at openjdk.java.net
>> Envoy?: Mardi 17 Novembre 2020 23:21:18
>> Objet: Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]
> 
>>> 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 .
>> 
>> Jim Laskey has updated the pull request with a new target base due to a merge or
>> a rebase. The pull request now contains 40 commits:
>> 
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> 
>>  Update package-info.java
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> 
>>  Updated RandomGeneratorFactory javadoc.
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> 
>>  Updated documentation for RandomGeneratorFactory.
>> - Merge branch 'master' into 8248862
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> 
>>  Move RandomGeneratorProperty
>> - Merge branch 'master' into 8248862
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> 
>>  Clear up javadoc
>> - 8248862; Implement Enhanced Pseudo-Random Number Generators
>> 
>>  remove RandomGeneratorProperty from API
>> - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68
>> 
>> -------------
>> 
>> Changes: https://git.openjdk.java.net/jdk/pull/1273/files
>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1273&range=02
>> Stats: 14891 lines in 31 files changed: 11110 ins; 3704 del; 77 mod
>> Patch: https://git.openjdk.java.net/jdk/pull/1273.diff
>> Fetch: git fetch https://git.openjdk.java.net/jdk pull/1273/head:pull/1273
>> 
>> PR: https://git.openjdk.java.net/jdk/pull/1273


From james.laskey at oracle.com  Mon Nov 23 13:58:50 2020
From: james.laskey at oracle.com (Jim Laskey)
Date: Mon, 23 Nov 2020 09:58:50 -0400
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <24865095.1772546.1605960239461.JavaMail.zimbra@u-pem.fr>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <24865095.1772546.1605960239461.JavaMail.zimbra@u-pem.fr>
Message-ID: <20FD1D00-E00C-4320-821E-3CE4F0747A37@oracle.com>

R?mi,

> On Nov 21, 2020, at 8:03 AM, Remi Forax <forax at univ-mlv.fr> wrote:
> 
> Ok, i've taking the time to read some literature about random generators because for me the Mersenne Twister was still the king.
> 
> The current API proposed as clearly two levels, you have the user level and the implementation level, at least the implementation level should seen as a SPI 

Yes, We agree. It was decided that we work on the SPI separately from the original JEP. IMHO the implementation issues are too complex for a single JEP. So, the goal is to release the user level now, and refine the SPI at a later date. Only RandomGenerator (with descendant interfaces) and RandomGeneratorFactory will be public facing in the first release.


> 
> RandomGenerator is the user facing API, for me it should be the sole interface exposed by the API, the others (leap, arbitrary leap and split) should be optional methods.

Fair enough, but if your task requires leapable, you might be disappointed when you get an UnsupportedOperationException invoking leap. I personally like the "to the quick" ability of using LeapableGenerator for narrowing down the search.

    LeapableGenerator leapable = LeapableGenerator.all().findFirst().orElseThrow();

Open for discussion.

> 
> In term of factory methods, we should have user driven methods:
> - getDefaultGenerator() that currently returns a L64X128MixRandom and can be changed in the future
> - getFastGenerator() that currently returns a Xoroshiro128PlusPlus and can be changed in the future
> - getDefault[Splitable|Leapable|etc]Generator that returns a default generator with the methods splits|leaps|etc defined
> - of / getByName that returns a specific generator by its name (but mov ed in a SPI class)

I'm concerned that the "can be changed in the future" aspect of your default methods will create a false reliance. We sort of have default now with the java.util.Random class. If we were to change the underpinnings of Random all heck would break loose. We already ran into that aspect during testing - tests that relied on sequences from fixed seeds.

We try to discourage the use of 'of', but there is a class of user (machine learning for example) that wants to be able to specify exactly. Often, choosing a specific fast prng for testing and then a more sophisticated one for production. The main purpose for RandomGenerator is swapability.


> 
> The example in the documentation should use getDefaultGenerator() and not of() to avoid the problem all the programming languages currently have by having over-specified that the default generator is a Mersenne Twister.

I have a problem with this as well. It would make it difficult to deprecate java.util.Random. 

> 
> All methods that returns a stream of the available implementations should be moved in the SPI package.

Open for discussion.


> 
> R?mi 
> 


Cheers,

-- Jim





> ---
> An honest question,
> why do we need so many interfaces for the different categories of RandomGenerator ?
> 
> My fear is that we are encoding the state of our knowledge of the different kinds of random generators now so it will not be pretty in the future when new categories of random generator are discovered/invented.
> If we can take example of the past to predict the future, 20 years ago, what should have been the hierarchy at that time.
> Is it not reasonable to think that we will need new kinds of random generator in the future ?
> 
> I wonder if it's not better to have one interface and several optional methods like we have with the collections, it means that we are loosing the possibilities to precisely type a method that only works with a precise type of generator but it will be more future proof.
> 
> R?mi
> 
> ----- Mail original -----
>> De: "Jim Laskey" <jlaskey at openjdk.java.net>
>> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>, "security-dev" <security-dev at openjdk.java.net>
>> Envoy?: Mercredi 18 Novembre 2020 14:52:56
>> Objet: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
> 
>> 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
>> 
>> -------------
>> 
>> Commit messages:
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862; Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>> - ... and 15 more: https://git.openjdk.java.net/jdk/compare/f7517386...2b3e4ed7
>> 
>> Changes: https://git.openjdk.java.net/jdk/pull/1292/files
>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=00
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8248862
>> Stats: 13319 lines in 25 files changed: 11110 ins; 2132 del; 77 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+74766043+sergus13 at openjdk.java.net  Mon Nov 23 14:12:03 2020
From: github.com+74766043+sergus13 at openjdk.java.net (sergus13)
Date: Mon, 23 Nov 2020 14:12:03 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v3]
In-Reply-To: <nYmGmOTAId25YFeWQ0PJkB7j658prrjepUr8q9k7kUI=.ba169da0-e72b-4a16-9639-9c301b3d58bc@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <3N2Oa4dVVDShlyR-w1G8jWG7mNPL5utzKFdm0QWkM3Y=.0cee9962-8dfb-40f3-b9ae-e50ea8377ed3@github.com>
 <zUyJi1Y8IGbR3Hv50ZWy1OS0oqFycWzHLP7iVECLTec=.2b79a385-c78d-46b3-9b4b-2d5d7bc2d071@github.com>
 <nYmGmOTAId25YFeWQ0PJkB7j658prrjepUr8q9k7kUI=.ba169da0-e72b-4a16-9639-9c301b3d58bc@github.com>
Message-ID: <Oxn7CirvPu4wJ2jdOQzjOT_KHZB6uZAcuHHQSdrQrWA=.07c41bdd-9fed-4cfc-bfec-3c0076266ffc@github.com>

On Sat, 21 Nov 2020 11:22:55 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> `listFromTrustedArrayNullsAllowed` is clearly not an option, as it will produce shared-secret leaking (see [JDK-8254090](https://bugs.openjdk.java.net/browse/JDK-8254090) for a similar case). StreamEx solution is dirty as it relies on the implementation detail. I believe, OpenJDK team is not very interested in providing optimal implementations for third-party stream implementations, as third-party implementations will likely update by themselves when necessary. At least, my suggestion to make the default `mapMulti` implementation better was declined.
>
> This implementation duplicates the array twice, once in this.toArray() and once in the constructor of ArrayList that calls toArray() on Collections.ArrayList.
> 
> I'm sure there is a better way

In `ReferencePipeline` class we have:

    @Override
    public final Object[] toArray() {
        return toArray(Object[]::new);
    }

    @Override
    @SuppressWarnings("unchecked")
    public final <A> A[] toArray(IntFunction<A[]> generator) {
        ...
        @SuppressWarnings("rawtypes")
        IntFunction rawGenerator = (IntFunction) generator;
        return (A[]) Nodes.flatten(evaluateToArrayNode(rawGenerator), rawGenerator)
                              .asArray(rawGenerator);
    }


In `Nodes` class we have:


    public static <T> Node<T> flatten(Node<T> node, IntFunction<T[]> generator) {
        if (node.getChildCount() > 0) {
            ... 
            T[] array = generator.apply((int) size);
            new ToArrayTask.OfRef<>(node, array, 0).invoke();
            return node(array);
        } else {
            return node;
        }
    }



It looks like it is required to implement `toList` method in a similar way in order to avoid array copy. i.e. there will be `IntFunction<List<T>> generator` which will generate 'ArrayList' with specified size and the list's `add` method will be called to add elements to the list.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1026

From prappo at openjdk.java.net  Mon Nov 23 14:37:56 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 23 Nov 2020 14:37:56 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <TFCxfLxB7_iDyPbbSXJtWZZm4HOW_n4R66vMnNEzYvI=.1659cc00-17c8-4999-bbb7-b5c7516599b7@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
 <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
 <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
 <TFCxfLxB7_iDyPbbSXJtWZZm4HOW_n4R66vMnNEzYvI=.1659cc00-17c8-4999-bbb7-b5c7516599b7@github.com>
Message-ID: <pvwIoAweUPTqGrO7Hxx5VxCbdlEI6-S83rLfRyNmySo=.106ee077-43e3-48a7-8a05-181986e5606b@github.com>

On Sat, 21 Nov 2020 09:21:06 GMT, John Lin <github.com+1290376+johnlinp at openjdk.org> wrote:

>> @johnlinp, you cannot create a CSR by yourself at the moment. Someone else will have to do that for you. Might as well be me. So here's my proposal: come up with the meat, then I'll help you with the paperwork. 
>> 
>> For starters, have a look at existing CSRs (you don't need a JBS account for that). For example, https://bugs.openjdk.java.net/issues/?jql=issuetype%3DCSR%20and%20Subcomponent%3Djava.util%3Acollections%20
>> 
>> Fill in an informal CSR template inline in this thread, and we'll proceed from that point. Is that okay?
>
> @pavelrappo Please see my proposed CSR below. Thank you.
> 
> # Map::compute should have a clearer implementation requirement.
> 
> ## Summary
> 
> java.util.Map::compute should have a clearer implementation requirement in its documentation.
> 
> ## Problem
> 
> The documentation of the implementation requirements for Map::compute has the following problems:
> 1. It lacks of return statements for most of the if-else cases.
> 1. The indents are 3 spaces, while the convention is 4 spaces.
> 1. The if-else is overly complicated and can be simplified.
> 
> ## Solution
> 
> Rewrite the documentation of Map::compute to match its default implementation.
> 
> ## Specification
> 
> diff --git a/src/java.base/share/classes/java/util/Map.java b/src/java.base/share/classes/java/util/Map.java
> index b1de34b42a5..c3118a90581 100644
> --- a/src/java.base/share/classes/java/util/Map.java
> +++ b/src/java.base/share/classes/java/util/Map.java
> @@ -1113,17 +1113,12 @@ public interface Map<K, V> {
>       * <pre> {@code
>       * V oldValue = map.get(key);
>       * V newValue = remappingFunction.apply(key, oldValue);
> -     * if (oldValue != null) {
> -     *    if (newValue != null)
> -     *       map.put(key, newValue);
> -     *    else
> -     *       map.remove(key);
> -     * } else {
> -     *    if (newValue != null)
> -     *       map.put(key, newValue);
> -     *    else
> -     *       return null;
> +     * if (newValue != null) {
> +     *     map.put(key, newValue);
> +     * } else if (oldValue != null) {
> +     *     map.remove(key);
>       * }
> +     * return newValue;
>       * }</pre>
>       *
>       * <p>The default implementation makes no guarantees about detecting if the

The proposed CSR has a few problems that we need to resolve.
1. The **Specification** pseudo-code behaves differently from both the old pseudo-code and the actual implementation when `newValue == null && oldValue == null` and `map.containsKey(key) == true`.
2. The content of the **Solution** section seems irrelevant: aside from a couple of missing `return` statements the current pseudo-code is fine. We are after something else, aren't we? The bottom line is we should state the solution more clearly.
3. The **Summary** section differs from that of the JDK-8247402.

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From jvernee at openjdk.java.net  Mon Nov 23 14:45:58 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 23 Nov 2020 14:45:58 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
In-Reply-To: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
Message-ID: <HgI3GJcewYgv-uEE4J66mgI1jrfWcQz_J98qbMlTGDE=.6424ebda-8213-4f76-9add-1e0fd6465217@github.com>

On Tue, 17 Nov 2020 17:19:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
> 
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
> 
> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
> 
> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
> 
> Testing: `make images` on Linux and Windows x86_32 platforms.

Filed https://bugs.openjdk.java.net/browse/JDK-8256862 to fix the test failures separately.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From jlaskey at openjdk.java.net  Mon Nov 23 15:01:13 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 23 Nov 2020 15:01:13 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <2I2HK8tDFSLtPqs0JFLKLgh3QmMTkM1HKuvKQNmsfIg=.a383a449-18e3-413a-a6ba-91dc80fde86a@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>
Message-ID: <RaTqPVpSVGALeEnXKGD9TWHcYnUZMhe7ATCY9Pjk584=.5332943c-53ba-4bcc-8c08-1fe459065a43@github.com>

On Tue, 17 Nov 2020 21:22:28 GMT, Paul Sandoz <psandoz 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 40 commits:
>> 
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Update package-info.java
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Updated RandomGeneratorFactory javadoc.
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Updated documentation for RandomGeneratorFactory.
>>  - Merge branch 'master' into 8248862
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Move RandomGeneratorProperty
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Clear up javadoc
>>  - 8248862; Implement Enhanced Pseudo-Random Number Generators
>>    
>>    remove RandomGeneratorProperty from API
>>  - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68
>
> src/java.base/share/classes/java/util/Random.java line 592:
> 
>> 590: 
>> 591:     @Override
>> 592:     public Spliterator.OfInt makeIntsSpliterator(long index, long fence, int origin, int bound) {
> 
> Unsure if this and the other two methods are intended to be public or not, since they are at the end of the class and override methods of a module private class. In principle there is nothing wrong with such `Spliterator` factories, but wonder if they are really needed given the `Stream` returning methods. The arrangement of classes makes it awkward to hide these methods.

Re the properties general comment: I moved properties to RandomSupport based on the notion that the SPI work with come later.

Re makeIntsSpliterator: These methods aren't exposed in the java.util.Random API  I guess no harm done. The only solution I can think of is to create an intermediate implementor, but that leaves the methods exposed as well.

> src/java.base/share/classes/java/util/SplittableRandom.java line 171:
> 
>> 169:      * RandomGenerator properties.
>> 170:      */
>> 171:     static Map<RandomGeneratorProperty, Object> getProperties() {
> 
> With records exiting preview in 16 this map of properties could i think be represented as a record instance, with better type safety, where `RandomSupport.RandomGeneratorProperty` enum values become typed fields declared on the record class. Something to consider after integration perhaps?

Yes.

> src/java.base/share/classes/java/util/SplittableRandom.java line 211:
> 
>> 209:      * http://zimbry.blogspot.com/2011/09/better-bit-mixing-improving-on.html
>> 210:      */
>> 211:     private static long mix64(long z) {
> 
> Usages be replaced with calls to `RandomSupport.mixStafford13`?

We were careful to not change the sequences (from fixed seed) generated by existing prngs. This was an edge case.

> src/java.base/share/classes/module-info.java line 250:
> 
>> 248:     exports jdk.internal.util.xml.impl to
>> 249:         jdk.jfr;
>> 250:     exports jdk.internal.util.random;
> 
> Unqualified export, should this be `to jdk.random`?

I guess you are right. Until we have a defined SPI we should restrict.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From rkennke at openjdk.java.net  Mon Nov 23 15:03:57 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 23 Nov 2020 15:03:57 GMT
Subject: RFR: 8256517: (ref) Reference.clear during reference processing
 may lose notification
In-Reply-To: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
References: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
Message-ID: <CThImLjLQN0BvRpbLyUGVS8gdnhw5-5w6rjQ3aow0hA=.58756e8b-b854-4e72-b584-bd6654bfe27e@github.com>

On Mon, 23 Nov 2020 01:43:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to Reference.clear() to address several issues.
> 
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
> 
> (JDK-8240696) For GCs with concurrent reference processing, clearing the
> referent field during reference processing may discard the expected
> notification.
> 
> Both of these are addressed by introducing a private native helper function
> for clearing the referent, rather than using an ordinary in-Java field
> assignment. Tests have been added for both of these issues. This required
> adding a new breakpoint in reference processing for ZGC.
> 
> Of course, finalization adds some complexity to the problem.  We deal with
> that by having FinalReference override clear.  The implementation is
> provided by a new package-private method in Reference.  (There are a number
> of alternatives, all of them clumsy; finalization is annoying that way.)
> 
> While dealing with FinalReference clearing it was noted that the recent
> JDK-8256106 and JDK-8256370 have some problems. FinalizerHistogram was not
> updated to call the new Reference.getInactive(), instead still calling get()
> on FinalReferences, with the JDK-8256106 problems. Fixing that showed the
> assertion for inactive FinalReference added by JDK-8256370 used the wrong
> test.
> 
> Rather than tracking down and changing all get() and clear() calls on final
> references and changing them to use getInactive and a new similar clear
> function, I've changed FinalReference to override get and clear, which call
> the helper functions in Reference. I've also renamed getInactive to be more
> explanatory and less convenient to call directly, and similarly named the
> helper for clear. This means that get/clear should never be called on an
> active FinalReference. That's already never done, and would have problems
> if it were.
> 
> Testing:
> mach5 tier1-6
> Local (linux-x64) tier1 using Shenandoah.
> New TestReferenceClearDuringMarking fails for G1 without these changes.
> New TestReferenceClearDuringReferenceProcessing fails for ZGC without these changes.

Looks good, except one small nit in one of the test configs.

test/hotspot/jtreg/gc/TestReferenceClearDuringReferenceProcessing.java line 28:

> 26: /* @test
> 27:  * @bug 8256517
> 28:  * @requires vm.gc.Z

Please add | vm.gc.Shenandoah here.

-------------

Changes requested by rkennke (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1376

From mcimadamore at openjdk.java.net  Mon Nov 23 15:19:10 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 23 Nov 2020 15:19:10 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing NPE
 checks
Message-ID: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>

Both the Foreign Memory Access and the Foreign Linker APIs leave something to be desired when it comes to handling NPEs - first, most of the API javadoc is oblivious to NPEs being thrown. Secondly, not all API method implementations add expicit NPE checks - with the result of NPE often being thrown very deep in the call chain - if at all. Third, test for API coverage of nulls is ad-hoc.

This patch rectifies all these issues. To increase coverage for null injected into APIs, this patch introduces a new framework for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.

I've also added, as part of this patch, a test to cover the statics in MemoryAccess which were not covered throughly.

-------------

Commit messages:
 - Add NPE checks in foreign ABI
 - Merge branch 'master' into npe-fixes
 - Fix memory access NPEs cont'd
 - Fix memory access NPEs
 - Merge branch 'master' into npe-fixes
 - make base() method abstract in HeapMemorySegmentImpl
 - Create specialized subclasses for all the heap segment cases

Changes: https://git.openjdk.java.net/jdk/pull/1388/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1388&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256865
  Stats: 1111 lines in 32 files changed: 939 ins; 137 del; 35 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1388.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1388/head:pull/1388

PR: https://git.openjdk.java.net/jdk/pull/1388

From jlaskey at openjdk.java.net  Mon Nov 23 15:20:13 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 23 Nov 2020 15:20:13 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <2I2HK8tDFSLtPqs0JFLKLgh3QmMTkM1HKuvKQNmsfIg=.a383a449-18e3-413a-a6ba-91dc80fde86a@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>
Message-ID: <JKlKh1JraPtO-HyMQiL174Md72SD7XCtxhLD8EVjvZo=.198f4ee0-269b-4c23-accb-fbb23f9e5c11@github.com>

On Tue, 17 Nov 2020 23:46:12 GMT, Paul Sandoz <psandoz 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 40 commits:
>> 
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Update package-info.java
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Updated RandomGeneratorFactory javadoc.
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Updated documentation for RandomGeneratorFactory.
>>  - Merge branch 'master' into 8248862
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Move RandomGeneratorProperty
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Clear up javadoc
>>  - 8248862; Implement Enhanced Pseudo-Random Number Generators
>>    
>>    remove RandomGeneratorProperty from API
>>  - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68
>
> src/jdk.random/share/classes/module-info.java line 53:
> 
>> 51:     uses RandomSupport;
>> 52: 
>> 53:     exports jdk.random to
> 
> Why is this needed?

Removing

> src/java.base/share/classes/java/util/random/package-info.java line 50:
> 
>> 48:  * given its name.
>> 49:  *
>> 50:  * <p> The principal supporting class is {@link RandomGenertatorFactor}. This
> 
> s/RandomGenertatorFactor/RandomGenertatorFactory

fixing

> src/java.base/share/classes/java/util/random/package-info.java line 140:
> 
>> 138:  *
>> 139:  * <p> For applications with no special requirements,
>> 140:  * "L64X128MixRandom" has a good balance among speed, space,
> 
> The documentation assumes that the `jdk.random` module is present in the JDK image. Perhaps we need to spit the specifics to `jdk.random`?

But jdk.random isn't really a public API.

> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1211:
> 
>> 1209:                         Udiff = -Udiff;
>> 1210:                         U2 = U1;
>> 1211:                         U1 -= Udiff;
> 
> Updated `U1` never used (recommend running the code through a checker e.g. use IntelliJ)

I noticed that before. I think it's a symmetry thing - will check with Guy.

> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 1157:
> 
>> 1155:         /*
>> 1156:          * The tables themselves, as well as a number of associated parameters, are
>> 1157:          * defined in class java.util.DoubleZigguratTables, which is automatically
> 
> `DoubleZigguratTables` is an inner class of `RandomSupport`

Late change fixing.

> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 2895:
> 
>> 2893:      * distribution: 0.0330
>> 2894:      */
>> 2895:     static class DoubleZigguratTables {
> 
> make `final`

fixing

> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 167:
> 
>> 165:      * Return the properties map for the specified provider.
>> 166:      *
>> 167:      * @param provider  provider to locate.
> 
> Method has no such parameter

Fixing

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From jlaskey at openjdk.java.net  Mon Nov 23 15:20:01 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 23 Nov 2020 15:20:01 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <RaTqPVpSVGALeEnXKGD9TWHcYnUZMhe7ATCY9Pjk584=.5332943c-53ba-4bcc-8c08-1fe459065a43@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>
 <RaTqPVpSVGALeEnXKGD9TWHcYnUZMhe7ATCY9Pjk584=.5332943c-53ba-4bcc-8c08-1fe459065a43@github.com>
Message-ID: <ZMXCclT87WR9cLUau8YRu8hqInD2o-BvNvSyUoiUfyU=.7f6ce44d-7662-4853-ba57-fa0395cd831b@github.com>

On Mon, 23 Nov 2020 14:57:59 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/module-info.java line 250:
>> 
>>> 248:     exports jdk.internal.util.xml.impl to
>>> 249:         jdk.jfr;
>>> 250:     exports jdk.internal.util.random;
>> 
>> Unqualified export, should this be `to jdk.random`?
>
> I guess you are right. Until we have a defined SPI we should restrict.

On the other hand:

public class Random extends AbstractSpliteratorGenerator
                            ^
error: warnings found and -Werror specified

public final class SplittableRandom extends AbstractSplittableGenerator {

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From mcimadamore at openjdk.java.net  Mon Nov 23 15:24:00 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 23 Nov 2020 15:24:00 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks
In-Reply-To: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
Message-ID: <banOK-4LIYwQl63MUpNadcQKhf5UWaAfeIaUnesIzps=.df04ca9d-855e-4a11-8bca-aed8faff7b0c@github.com>

On Mon, 23 Nov 2020 15:11:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Both the Foreign Memory Access and the Foreign Linker APIs leave something to be desired when it comes to handling NPEs - first, most of the API javadoc is oblivious to NPEs being thrown. Secondly, not all API method implementations add expicit NPE checks - with the result of NPE often being thrown very deep in the call chain - if at all. Third, test for API coverage of nulls is ad-hoc.
> 
> This patch rectifies all these issues. To increase coverage for null injected into APIs, this patch introduces a new framework for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> I've also added, as part of this patch, a test to cover the statics in MemoryAccess which were not covered throughly.

CSR: https://bugs.openjdk.java.net/browse/JDK-8256866
specdiff: http://cr.openjdk.java.net/~mcimadamore/8256865_v1/specdiff_out/overview-summary.html
javadoc: http://cr.openjdk.java.net/~mcimadamore/8256865_v1/javadoc

-------------

PR: https://git.openjdk.java.net/jdk/pull/1388

From jlaskey at openjdk.java.net  Mon Nov 23 15:24:09 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 23 Nov 2020 15:24:09 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <2I2HK8tDFSLtPqs0JFLKLgh3QmMTkM1HKuvKQNmsfIg=.a383a449-18e3-413a-a6ba-91dc80fde86a@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>
Message-ID: <NNI1cWhdXBUmeLxOGQWIIkr3sXBNFoYadfpXL14CqYA=.e7cd49fa-086f-4b93-8310-61ce48410fc1@github.com>

On Wed, 18 Nov 2020 00:29:36 GMT, Paul Sandoz <psandoz 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 40 commits:
>> 
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Update package-info.java
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Updated RandomGeneratorFactory javadoc.
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Updated documentation for RandomGeneratorFactory.
>>  - Merge branch 'master' into 8248862
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Move RandomGeneratorProperty
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Clear up javadoc
>>  - 8248862; Implement Enhanced Pseudo-Random Number Generators
>>    
>>    remove RandomGeneratorProperty from API
>>  - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 173:
> 
>> 171:     @SuppressWarnings("unchecked")
>> 172:     private Map<RandomGeneratorProperty, Object> getProperties() {
>> 173:         if (properties == null) {
> 
> `properties` needs to be marked volatile, and it needs to be assigned at line 182 or line 184.

One of them foggy days.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From jlaskey at openjdk.java.net  Mon Nov 23 15:36:58 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 23 Nov 2020 15:36:58 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <zbIcDJfP9fQjax6Po7skY376oKgX2gjSTYJ38nEcdjc=.51414f9e-ff04-4ae0-8398-53182d2c0787@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <zbIcDJfP9fQjax6Po7skY376oKgX2gjSTYJ38nEcdjc=.51414f9e-ff04-4ae0-8398-53182d2c0787@github.com>
Message-ID: <ke3PpZKzvBc_nFo4rwvE7cCamN7E2mN1YlDOjpTemls=.58708533-e528-49ac-9b58-c676308e6c07@github.com>

On Fri, 20 Nov 2020 23:30:03 GMT, Roger Baumgartner <github.com+1472572+rogermb 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
>
> src/java.base/share/classes/java/util/random/package-info.java line 149:
> 
>> 147:  *
>> 148:  * <p> For an application running in a 32-bit hardware environment and using
>> 149:  * only one thread or a small number of threads, may be a good choice.
> 
> I think the name of the suitable algorithm is missing here.

Yes - "L32X64MixRandom". Thank you.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From jlaskey at openjdk.java.net  Mon Nov 23 15:53:00 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Mon, 23 Nov 2020 15:53:00 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v2]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <Mn4rvA5tX1QI7TpE5tBDT1Pofh1N12iGkZ-EqqI67so=.c2adb14d-ccc0-40bb-9997-f5995c15567c@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 changes
  
  @PaulSandoz and @rogermb

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/2b3e4ed7..9d6d1a94

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=00-01

  Stats: 18 lines in 4 files changed: 2 ins; 5 del; 11 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 sgehwolf at openjdk.java.net  Mon Nov 23 15:55:10 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 23 Nov 2020 15:55:10 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection
In-Reply-To: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
Message-ID: <Ynmw17EfEzNeUK5w2ABmHkXqqXo98GTcYTnZFGoAYIk=.1079ee11-c9e7-443f-b74b-d94838206a2a@github.com>

On Mon, 23 Nov 2020 15:46:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This is an enhancement which solves two issues:
> 
> 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot).
> 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place.
> 
> * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass.

@poonamparhar Perhaps you want to take a look at this in the context of not regressing JDK-8255908? Thanks!

src/java.base/linux/classes/jdk/internal/platform/CgroupSubsystemFactory.java line 268:

> 266:                                 info.setMountPoint(mountPath);
> 267:                                 info.setMountRoot(mountRoot);
> 268:                             }

This is the actual fix of JDK-8253435 for the Java side.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1393

From sgehwolf at openjdk.java.net  Mon Nov 23 15:55:09 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 23 Nov 2020 15:55:09 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files for
 version detection
Message-ID: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>

This is an enhancement which solves two issues:

1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot).
2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place.

* [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass.

-------------

Commit messages:
 - 8254001: [Metrics] Enhance parsing of cgroup interface files for version detection

Changes: https://git.openjdk.java.net/jdk/pull/1393/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1393&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254001
  Stats: 537 lines in 5 files changed: 268 ins; 193 del; 76 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1393.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1393/head:pull/1393

PR: https://git.openjdk.java.net/jdk/pull/1393

From sgehwolf at openjdk.java.net  Mon Nov 23 16:01:58 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 23 Nov 2020 16:01:58 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection
In-Reply-To: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
Message-ID: <K6FUysFH_ye1-MPclt-sqsQKkPZgOumtuFfto4mZ1_Y=.1fd6960d-c494-499a-9bd6-68d46d5dd7d8@github.com>

On Mon, 23 Nov 2020 15:46:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> This is an enhancement which solves two issues:
> 
> 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot).
> 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place.
> 
> * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass.

test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java line 238:

> 236:         assertFalse("Join controller combination expected as cgroups v1", res.isCgroupV2());
> 237:         CgroupInfo memoryInfo = res.getInfos().get("memory");
> 238:         assertEquals("/user.slice/user-1000.slice/session-3.scope", memoryInfo.getCgroupPath());

The gist of the Java equivalent of JDK-8253939 (which fixed this for Hotspot). I.e. a regression test for JDK-8217766 and JDK-8254854.

test/jdk/jdk/internal/platform/cgroup/TestCgroupSubsystemFactory.java line 267:

> 265:         assertFalse("Duplicate cpusets should not influence detection heuristic", res.isCgroupV2());
> 266:         CgroupInfo cpuSetInfo = res.getInfos().get("cpuset");
> 267:         assertEquals("/sys/fs/cgroup/cpuset", cpuSetInfo.getMountPoint());

We can now assert the proper mount point is being used for multiple cpuset mounts.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1393

From naoto at openjdk.java.net  Mon Nov 23 16:44:56 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 23 Nov 2020 16:44:56 GMT
Subject: Integrated: 8247432: Update IANA Language Subtag Registry to Version
 2020-09-29
In-Reply-To: <eATYqJ38ckiQ1oLj3YvsIjp84ZCEchfVw-4usoIrACc=.fdf34a23-e455-474d-9f86-b361c4b6ed8c@github.com>
References: <eATYqJ38ckiQ1oLj3YvsIjp84ZCEchfVw-4usoIrACc=.fdf34a23-e455-474d-9f86-b361c4b6ed8c@github.com>
Message-ID: <D3q7Jjy1mGbLqrzYPKOJghxb2BX-ZAcb_u18OENi0xU=.1ead8912-1605-49f2-a331-ae6de30d5bc4@github.com>

On Fri, 20 Nov 2020 17:55:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review the changes to the subject issue. This is to incorporate the latest language subtag registry definition into the JDK.

This pull request has now been integrated.

Changeset: ae0ca743
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ae0ca743
Stats:     52 lines in 2 files changed: 44 ins; 5 del; 3 mod

8247432: Update IANA Language Subtag Registry to Version 2020-09-29

Reviewed-by: joehw

-------------

PR: https://git.openjdk.java.net/jdk/pull/1357

From mchung at openjdk.java.net  Mon Nov 23 17:50:57 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 23 Nov 2020 17:50:57 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v4]
In-Reply-To: <4UhMfpMR51CIIMA1Sl6ZQOEtvwgkdFHujTEUmxR0YQE=.96094f68-b698-469b-b20f-143d237ced02@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <tKPyoN5O290X_W3n2DF1jvunO0YBoyNnoT5jXjmsNc0=.ecc67352-e2ef-4408-9ac1-e5e90a345424@github.com>
 <K9VUz-ZEbZvwn9hVtg-BpsxJBsDxf1hKTSyvhFgdxrA=.4f06ae1e-c5e6-4231-ae86-1a0ba69c3431@github.com>
 <4UhMfpMR51CIIMA1Sl6ZQOEtvwgkdFHujTEUmxR0YQE=.96094f68-b698-469b-b20f-143d237ced02@github.com>
Message-ID: <WqR_knixoUiJMUUdXYbCB5ooA1-HfVT30ZllY1WUdkI=.224ffe9e-ee05-4c43-baab-33c3cdb508ed@github.com>

On Mon, 23 Nov 2020 10:23:25 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> It is my understanding that `Lookup` object returned from defineHiddenClass[WithClassData] features the ORIGINAL access lookup mode, right? I cannot find a normative statement to confirm this. If it is the case, then it would be good to clarify this.

Yes with ORIGINAL access.   I updated `@return` for both `defineHiddenClass` and `defineHiddenClassWithClassData` as follows:

-         * @return the {@code Lookup} object on the hidden class
+         * @return the {@code Lookup} object on the hidden class with
+         * {@linkplain #ORIGINAL original} and
+         * {@linkplain Lookup#hasFullPrivilegeAccess() full privilege} access

-------------

PR: https://git.openjdk.java.net/jdk/pull/1171

From jvernee at openjdk.java.net  Mon Nov 23 18:13:56 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 23 Nov 2020 18:13:56 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks
In-Reply-To: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
Message-ID: <Pn2HG31gVguHDxURxy8Q67UpAKhQB_T85XkCBLuAINk=.4a0a12fa-7c79-4edc-bc0e-37f8c5d7602f@github.com>

On Mon, 23 Nov 2020 15:11:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Both the Foreign Memory Access and the Foreign Linker APIs leave something to be desired when it comes to handling NPEs - first, most of the API javadoc is oblivious to NPEs being thrown. Secondly, not all API method implementations add expicit NPE checks - with the result of NPE often being thrown very deep in the call chain - if at all. Third, test for API coverage of nulls is ad-hoc.
> 
> This patch rectifies all these issues. To increase coverage for null injected into APIs, this patch introduces a new framework for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> I've also added, as part of this patch, a test to cover the statics in MemoryAccess which were not covered throughly.

Already looked at this in panama-foreign, but found one minor issue.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java line 152:

> 150:      * @return the new function descriptor.
> 151:      * @throws NullPointerException if either {@code addedLayouts == null}, or any of the
> 152:      * layouts in {@code addedLayouts} is null. at throws NullPointerException if any of the new argument layouts is null.

Spurious `@throws` tag here

-------------

Marked as reviewed by jvernee (Committer).

PR: https://git.openjdk.java.net/jdk/pull/1388

From mcimadamore at openjdk.java.net  Mon Nov 23 18:22:14 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 23 Nov 2020 18:22:14 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks [v2]
In-Reply-To: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
Message-ID: <IIqvoh6QQKNC_z78X3X3dhccSBl84cnDjWechUuUf-E=.6159de5c-b255-42f1-811b-03c605d01aa3@github.com>

> Both the Foreign Memory Access and the Foreign Linker APIs leave something to be desired when it comes to handling NPEs - first, most of the API javadoc is oblivious to NPEs being thrown. Secondly, not all API method implementations add expicit NPE checks - with the result of NPE often being thrown very deep in the call chain - if at all. Third, test for API coverage of nulls is ad-hoc.
> 
> This patch rectifies all these issues. To increase coverage for null injected into APIs, this patch introduces a new framework for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> I've also added, as part of this patch, a test to cover the statics in MemoryAccess which were not covered throughly.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix cut/paste error in FunctionDescriptor

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1388/files
  - new: https://git.openjdk.java.net/jdk/pull/1388/files/80ffde44..4565f777

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1388&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1388&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1388.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1388/head:pull/1388

PR: https://git.openjdk.java.net/jdk/pull/1388

From mcimadamore at openjdk.java.net  Mon Nov 23 18:22:15 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Mon, 23 Nov 2020 18:22:15 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks [v2]
In-Reply-To: <Pn2HG31gVguHDxURxy8Q67UpAKhQB_T85XkCBLuAINk=.4a0a12fa-7c79-4edc-bc0e-37f8c5d7602f@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
 <Pn2HG31gVguHDxURxy8Q67UpAKhQB_T85XkCBLuAINk=.4a0a12fa-7c79-4edc-bc0e-37f8c5d7602f@github.com>
Message-ID: <UQFncid0vXx4fC9wECiBW1sLeu0tPeuE-IC5o5CRLIY=.1382adad-3dc0-49e2-bdd6-0fd7c00901ac@github.com>

On Mon, 23 Nov 2020 17:58:22 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix cut/paste error in FunctionDescriptor
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/FunctionDescriptor.java line 152:
> 
>> 150:      * @return the new function descriptor.
>> 151:      * @throws NullPointerException if either {@code addedLayouts == null}, or any of the
>> 152:      * layouts in {@code addedLayouts} is null. at throws NullPointerException if any of the new argument layouts is null.
> 
> Spurious `@throws` tag here

Good catch

-------------

PR: https://git.openjdk.java.net/jdk/pull/1388

From sviswanathan at openjdk.java.net  Mon Nov 23 18:51:57 2020
From: sviswanathan at openjdk.java.net (Sandhya Viswanathan)
Date: Mon, 23 Nov 2020 18:51:57 GMT
Subject: Integrated: 8256585: Remove in-place conversion vector operators from
 Vector API
In-Reply-To: <DbLEmx1uzM8W8p9NVSgbFlAiYsKrcNAPL_BSj-K0zVI=.0b0e9229-db39-48ef-b904-e3db4bce71cc@github.com>
References: <DbLEmx1uzM8W8p9NVSgbFlAiYsKrcNAPL_BSj-K0zVI=.0b0e9229-db39-48ef-b904-e3db4bce71cc@github.com>
Message-ID: <zsO-VZefvXP1GAipMZDOHU2UCsBxXn9Z1ycrL3nHOa0=.2be53999-3e86-424c-b1fb-7e43e09e5f78@github.com>

On Thu, 19 Nov 2020 03:26:20 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

> Remove partially implemented in-place conversion vector operators from Vector API:
>    ofNarrowing, ofWidening, INPLACE_XXX

This pull request has now been integrated.

Changeset: 9de5d091
Author:    Sandhya Viswanathan <sviswanathan at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9de5d091
Stats:     133 lines in 2 files changed: 0 ins; 130 del; 3 mod

8256585: Remove in-place conversion vector operators from Vector API

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.java.net/jdk/pull/1305

From jvernee at openjdk.java.net  Mon Nov 23 18:58:15 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 23 Nov 2020 18:58:15 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v2]
In-Reply-To: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
Message-ID: <2SRn2T5HZSmC1xnRvJc42Z8wtfwxJdzep2gR_LyrgC0=.7b89023f-3f2e-45f9-853e-af73bb04b47f@github.com>

> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
> 
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
> 
> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
> 
> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
> 
> Testing: `make images` on Linux and Windows x86_32 platforms.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into Linker_32bit-fixes_New-Master
 - - Add negative test for 32-bit platform.
   - Added note to CLinker about failure to initialize on unsupported platforms
 - Remove UnsupportedPlatform test
 - Remove unneeded cast
 - Remove Stuff that makes the jdk_foreign tests pass
 - fix test warnings
 - - Fix 32-bit build errors and tests
   - Add negative test for 32-bit platform.
   - Change CABI to fail more lazily when running on an unsupported platform.
   - Change CLinker layouts to be null on unsupported platforms, instead of failing when initializing the class
   - Added note to CLinker about failure to initialize on unsupported platforms

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1266/files
  - new: https://git.openjdk.java.net/jdk/pull/1266/files/f0fed210..df5e65c1

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=00-01

  Stats: 1085 lines in 51 files changed: 903 ins; 125 del; 57 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1266.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266

PR: https://git.openjdk.java.net/jdk/pull/1266

From pliden at openjdk.java.net  Mon Nov 23 19:20:59 2020
From: pliden at openjdk.java.net (Per Liden)
Date: Mon, 23 Nov 2020 19:20:59 GMT
Subject: RFR: 8256517: (ref) Reference.clear during reference processing
 may lose notification
In-Reply-To: <CThImLjLQN0BvRpbLyUGVS8gdnhw5-5w6rjQ3aow0hA=.58756e8b-b854-4e72-b584-bd6654bfe27e@github.com>
References: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
 <CThImLjLQN0BvRpbLyUGVS8gdnhw5-5w6rjQ3aow0hA=.58756e8b-b854-4e72-b584-bd6654bfe27e@github.com>
Message-ID: <rfCOaqTi1O564eSDFu6aVslbRWzdECqh11C1i7_HPnk=.cca5c47f-5e1c-44cd-911a-a8d80416f94c@github.com>

On Mon, 23 Nov 2020 15:00:08 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Please review this change to Reference.clear() to address several issues.
>> 
>> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
>> field to null may extend the lifetime of the referent value.
>> 
>> (JDK-8240696) For GCs with concurrent reference processing, clearing the
>> referent field during reference processing may discard the expected
>> notification.
>> 
>> Both of these are addressed by introducing a private native helper function
>> for clearing the referent, rather than using an ordinary in-Java field
>> assignment. Tests have been added for both of these issues. This required
>> adding a new breakpoint in reference processing for ZGC.
>> 
>> Of course, finalization adds some complexity to the problem.  We deal with
>> that by having FinalReference override clear.  The implementation is
>> provided by a new package-private method in Reference.  (There are a number
>> of alternatives, all of them clumsy; finalization is annoying that way.)
>> 
>> While dealing with FinalReference clearing it was noted that the recent
>> JDK-8256106 and JDK-8256370 have some problems. FinalizerHistogram was not
>> updated to call the new Reference.getInactive(), instead still calling get()
>> on FinalReferences, with the JDK-8256106 problems. Fixing that showed the
>> assertion for inactive FinalReference added by JDK-8256370 used the wrong
>> test.
>> 
>> Rather than tracking down and changing all get() and clear() calls on final
>> references and changing them to use getInactive and a new similar clear
>> function, I've changed FinalReference to override get and clear, which call
>> the helper functions in Reference. I've also renamed getInactive to be more
>> explanatory and less convenient to call directly, and similarly named the
>> helper for clear. This means that get/clear should never be called on an
>> active FinalReference. That's already never done, and would have problems
>> if it were.
>> 
>> Testing:
>> mach5 tier1-6
>> Local (linux-x64) tier1 using Shenandoah.
>> New TestReferenceClearDuringMarking fails for G1 without these changes.
>> New TestReferenceClearDuringReferenceProcessing fails for ZGC without these changes.
>
> test/hotspot/jtreg/gc/TestReferenceClearDuringReferenceProcessing.java line 28:
> 
>> 26: /* @test
>> 27:  * @bug 8256517
>> 28:  * @requires vm.gc.Z
> 
> Please add | vm.gc.Shenandoah here.

Note that for this test to be useful, the GC needs to support concurrent GC breakpoints, which Shenandoah doesn't do.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1376

From naoto at openjdk.java.net  Mon Nov 23 19:30:11 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 23 Nov 2020 19:30:11 GMT
Subject: RFR: 8256839: JavaDoc for java.time.Period.negated() method
Message-ID: <BdYfJv6d5JUWxyD7QVRRtyFYrCSqAl16YHTYRNU77_w=.3055d463-3855-441a-a174-b63b823d7180@github.com>

Hi,

Please review this simple doc fix. Thanks.

-------------

Commit messages:
 - 8256839: JavaDoc for java.time.Period.negated() method

Changes: https://git.openjdk.java.net/jdk/pull/1399/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1399&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256839
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1399.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1399/head:pull/1399

PR: https://git.openjdk.java.net/jdk/pull/1399

From shade at openjdk.java.net  Mon Nov 23 19:31:59 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Mon, 23 Nov 2020 19:31:59 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v2]
In-Reply-To: <2SRn2T5HZSmC1xnRvJc42Z8wtfwxJdzep2gR_LyrgC0=.7b89023f-3f2e-45f9-853e-af73bb04b47f@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <2SRn2T5HZSmC1xnRvJc42Z8wtfwxJdzep2gR_LyrgC0=.7b89023f-3f2e-45f9-853e-af73bb04b47f@github.com>
Message-ID: <3Qmhyjvnm2vDo4vg4LH0Pxn3c1UdZFwvxEiGCUYgEsQ=.c4e5e91b-6e90-445f-bf57-bce4bf95b301@github.com>

On Mon, 23 Nov 2020 18:58:15 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
>> 
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
>> 
>> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
>> 
>> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
>> 
>> Testing: `make images` on Linux and Windows x86_32 platforms.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into Linker_32bit-fixes_New-Master
>  - - Add negative test for 32-bit platform.
>    - Added note to CLinker about failure to initialize on unsupported platforms
>  - Remove UnsupportedPlatform test
>  - Remove unneeded cast
>  - Remove Stuff that makes the jdk_foreign tests pass
>  - fix test warnings
>  - - Fix 32-bit build errors and tests
>    - Add negative test for 32-bit platform.
>    - Change CABI to fail more lazily when running on an unsupported platform.
>    - Change CLinker layouts to be null on unsupported platforms, instead of failing when initializing the class
>    - Added note to CLinker about failure to initialize on unsupported platforms

Some minor comments before looking more closely.

src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp line 132:

> 130:   __ ret(0);
> 131: #else
> 132:   __ hlt(); // NYI

"Not Implemented Yet" is "NIY". But then there is a macro you can use here: `Unimplemented()`.

src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/PlatformLayouts.java line 144:

> 142:          * The {@code T*} native type.
> 143:          */
> 144:         public static final ValueLayout C_POINTER = ofPointer(LITTLE_ENDIAN, 64);

I somewhat get the change in `Win64()` and `AArch64()`, but why here at `SysV()`? Surely x86_32 is the platform with 32-bit pointers?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From poonam at openjdk.java.net  Mon Nov 23 19:41:57 2020
From: poonam at openjdk.java.net (Poonam Bajaj)
Date: Mon, 23 Nov 2020 19:41:57 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection
In-Reply-To: <Ynmw17EfEzNeUK5w2ABmHkXqqXo98GTcYTnZFGoAYIk=.1079ee11-c9e7-443f-b74b-d94838206a2a@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <Ynmw17EfEzNeUK5w2ABmHkXqqXo98GTcYTnZFGoAYIk=.1079ee11-c9e7-443f-b74b-d94838206a2a@github.com>
Message-ID: <eFFokFwfdmu0YTyAhvPJ7xBFo0ypjHw3MyC_9-aTS6g=.80ad5876-3ae3-4ca3-96b5-08db53ed6627@github.com>

On Mon, 23 Nov 2020 15:50:18 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> This is an enhancement which solves two issues:
>> 
>> 1. Multiple reads of relevant cgroup interface files. Now interface files are only read once per file (just like Hotspot).
>> 2. Proxies creation of the impl specific subsystem via `determineType()` as before, but now reads all relevant interface files: `/proc/cgroups`, `/proc/self/mountinfo` and `/proc/self/cgroup`. Once read it passes the parsed information to the impl specific subsystem classes for instantiation. This allows for more flexibility of testing as interface files can be mocked and, thus, more cases can be tested that way without having access to these specific systems. For example, proper regression tests for JDK-8217766 and JDK-8253435 have been added now with this in place.
>> 
>> * [x] Tested on Linux x86_64 on cgroups v1 and cgroups v2. Container tests pass.
>
> @poonamparhar Perhaps you want to take a look at this in the context of not regressing JDK-8255908? Thanks!

With respect to JDK-8255908, the changes look good to me.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1393

From rriggs at openjdk.java.net  Mon Nov 23 19:46:02 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 23 Nov 2020 19:46:02 GMT
Subject: RFR: 8256839: JavaDoc for java.time.Period.negated() method
In-Reply-To: <BdYfJv6d5JUWxyD7QVRRtyFYrCSqAl16YHTYRNU77_w=.3055d463-3855-441a-a174-b63b823d7180@github.com>
References: <BdYfJv6d5JUWxyD7QVRRtyFYrCSqAl16YHTYRNU77_w=.3055d463-3855-441a-a174-b63b823d7180@github.com>
Message-ID: <THTK6Cj-1gjH_ybCxsox0IuTZlVLMiatM43c4p73-YE=.f38331cb-210a-468a-a97e-8d6bd01b6385@github.com>

On Mon, 23 Nov 2020 19:24:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple doc fix. Thanks.

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1399

From lancea at openjdk.java.net  Mon Nov 23 19:52:00 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 23 Nov 2020 19:52:00 GMT
Subject: RFR: 8256839: JavaDoc for java.time.Period.negated() method
In-Reply-To: <BdYfJv6d5JUWxyD7QVRRtyFYrCSqAl16YHTYRNU77_w=.3055d463-3855-441a-a174-b63b823d7180@github.com>
References: <BdYfJv6d5JUWxyD7QVRRtyFYrCSqAl16YHTYRNU77_w=.3055d463-3855-441a-a174-b63b823d7180@github.com>
Message-ID: <z5gDgg2tlK7LAHQOoNmd9L-U8lGsp4Fjv3VkjskWMaI=.326fc3d0-b6e5-40ca-af56-7f07d0ca945c@github.com>

On Mon, 23 Nov 2020 19:24:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple doc fix. Thanks.

Looks fine and this is validated via test/jdk/java/time/tck/java/time/TCKPeriod.java,

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1399

From sgehwolf at openjdk.java.net  Mon Nov 23 20:00:59 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 23 Nov 2020 20:00:59 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection
In-Reply-To: <COWzygAauFzmvgYYP6DVjIg0MH6EDyIMx0ZzeTRHol0=.8a01079b-6e40-4b1b-bb75-e693f89d8871@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <Ynmw17EfEzNeUK5w2ABmHkXqqXo98GTcYTnZFGoAYIk=.1079ee11-c9e7-443f-b74b-d94838206a2a@github.com>
 <eFFokFwfdmu0YTyAhvPJ7xBFo0ypjHw3MyC_9-aTS6g=.80ad5876-3ae3-4ca3-96b5-08db53ed6627@github.com>
 <COWzygAauFzmvgYYP6DVjIg0MH6EDyIMx0ZzeTRHol0=.8a01079b-6e40-4b1b-bb75-e693f89d8871@github.com>
Message-ID: <iT7Ltrm52E9skv98tAKIYPB1ZCaXw8ep-YSegjEnhxc=.68635047-f51c-4c60-9731-0da103e56a39@github.com>

On Mon, 23 Nov 2020 19:56:56 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> With respect to JDK-8255908, the changes look good to me.
>
>> With respect to JDK-8255908, the changes look good to me.
> 
> Thanks!

@bobvandette Please review when you've got some cycles to spare. Much appreciated!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1393

From sgehwolf at openjdk.java.net  Mon Nov 23 20:00:58 2020
From: sgehwolf at openjdk.java.net (Severin Gehwolf)
Date: Mon, 23 Nov 2020 20:00:58 GMT
Subject: RFR: 8254001: [Metrics] Enhance parsing of cgroup interface files
 for version detection
In-Reply-To: <eFFokFwfdmu0YTyAhvPJ7xBFo0ypjHw3MyC_9-aTS6g=.80ad5876-3ae3-4ca3-96b5-08db53ed6627@github.com>
References: <52vN8j9B_6s6amMHb8b_1QKyhwjCvThIz5T17aNix28=.31113ef4-61d0-4525-a3df-9aa20d408935@github.com>
 <Ynmw17EfEzNeUK5w2ABmHkXqqXo98GTcYTnZFGoAYIk=.1079ee11-c9e7-443f-b74b-d94838206a2a@github.com>
 <eFFokFwfdmu0YTyAhvPJ7xBFo0ypjHw3MyC_9-aTS6g=.80ad5876-3ae3-4ca3-96b5-08db53ed6627@github.com>
Message-ID: <COWzygAauFzmvgYYP6DVjIg0MH6EDyIMx0ZzeTRHol0=.8a01079b-6e40-4b1b-bb75-e693f89d8871@github.com>

On Mon, 23 Nov 2020 19:39:18 GMT, Poonam Bajaj <poonam at openjdk.org> wrote:

> With respect to JDK-8255908, the changes look good to me.

Thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1393

From jvernee at openjdk.java.net  Mon Nov 23 20:02:15 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 23 Nov 2020 20:02:15 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v2]
In-Reply-To: <3Qmhyjvnm2vDo4vg4LH0Pxn3c1UdZFwvxEiGCUYgEsQ=.c4e5e91b-6e90-445f-bf57-bce4bf95b301@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <2SRn2T5HZSmC1xnRvJc42Z8wtfwxJdzep2gR_LyrgC0=.7b89023f-3f2e-45f9-853e-af73bb04b47f@github.com>
 <3Qmhyjvnm2vDo4vg4LH0Pxn3c1UdZFwvxEiGCUYgEsQ=.c4e5e91b-6e90-445f-bf57-bce4bf95b301@github.com>
Message-ID: <tPwBBEyQ8SIayRdw2OsocxYyc1OXzgNS8sKbWfGdUKU=.4bf0e8f2-3e7a-4b96-b715-181ca2963580@github.com>

On Mon, 23 Nov 2020 19:25:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into Linker_32bit-fixes_New-Master
>>  - - Add negative test for 32-bit platform.
>>    - Added note to CLinker about failure to initialize on unsupported platforms
>>  - Remove UnsupportedPlatform test
>>  - Remove unneeded cast
>>  - Remove Stuff that makes the jdk_foreign tests pass
>>  - fix test warnings
>>  - - Fix 32-bit build errors and tests
>>    - Add negative test for 32-bit platform.
>>    - Change CABI to fail more lazily when running on an unsupported platform.
>>    - Change CLinker layouts to be null on unsupported platforms, instead of failing when initializing the class
>>    - Added note to CLinker about failure to initialize on unsupported platforms
>
> src/jdk.incubator.foreign/share/classes/jdk/internal/foreign/PlatformLayouts.java line 144:
> 
>> 142:          * The {@code T*} native type.
>> 143:          */
>> 144:         public static final ValueLayout C_POINTER = ofPointer(LITTLE_ENDIAN, 64);
> 
> I somewhat get the change in `Win64()` and `AArch64()`, but why here at `SysV()`? Surely x86_32 is the platform with 32-bit pointers?

SysV here is the 64-bit SysV ABI, not 32. Perhaps this needs to be disambiguated yet, but we can cross that bridge when adding 32-bit support.

Any way, I pushed the wrong thing here. This is supposed to go in another PR. Will fix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From jvernee at openjdk.java.net  Mon Nov 23 20:02:13 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 23 Nov 2020 20:02:13 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v3]
In-Reply-To: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
Message-ID: <GoKHJUzOIPavsgbzSKZrtw9_61RMsflPrkK2dWNHAzs=.8a0438b8-aece-442e-8cc4-a0c71c55a5fb@github.com>

> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
> 
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
> 
> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
> 
> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
> 
> Testing: `make images` on Linux and Windows x86_32 platforms.

Jorn Vernee 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:

  Merge branch 'master' into Linker_32bit-fixes_Simpler

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1266/files
  - new: https://git.openjdk.java.net/jdk/pull/1266/files/df5e65c1..9dcbb58c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=01-02

  Stats: 94 lines in 20 files changed: 0 ins; 83 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1266.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266

PR: https://git.openjdk.java.net/jdk/pull/1266

From jvernee at openjdk.java.net  Mon Nov 23 20:07:08 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 23 Nov 2020 20:07:08 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v3]
In-Reply-To: <3Qmhyjvnm2vDo4vg4LH0Pxn3c1UdZFwvxEiGCUYgEsQ=.c4e5e91b-6e90-445f-bf57-bce4bf95b301@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <2SRn2T5HZSmC1xnRvJc42Z8wtfwxJdzep2gR_LyrgC0=.7b89023f-3f2e-45f9-853e-af73bb04b47f@github.com>
 <3Qmhyjvnm2vDo4vg4LH0Pxn3c1UdZFwvxEiGCUYgEsQ=.c4e5e91b-6e90-445f-bf57-bce4bf95b301@github.com>
Message-ID: <NOgz-2ElIZOXL0rz4RkdunrycVovRtaIGR4mkdeqQGY=.50dcabf0-d69e-4365-a035-31d8fdca3aad@github.com>

On Mon, 23 Nov 2020 13:19:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Jorn Vernee 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.
>
> src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp line 132:
> 
>> 130:   __ ret(0);
>> 131: #else
>> 132:   __ hlt(); // NYI
> 
> "Not Implemented Yet" is "NIY". But then there is a macro you can use here: `Unimplemented()`.

Was going for "Not Yet Implemented" (this seems to be more common in existing code)

I'll change it to use `Unimplemented();`

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From joehw at openjdk.java.net  Mon Nov 23 20:16:02 2020
From: joehw at openjdk.java.net (Joe Wang)
Date: Mon, 23 Nov 2020 20:16:02 GMT
Subject: RFR: 8256839: JavaDoc for java.time.Period.negated() method
In-Reply-To: <BdYfJv6d5JUWxyD7QVRRtyFYrCSqAl16YHTYRNU77_w=.3055d463-3855-441a-a174-b63b823d7180@github.com>
References: <BdYfJv6d5JUWxyD7QVRRtyFYrCSqAl16YHTYRNU77_w=.3055d463-3855-441a-a174-b63b823d7180@github.com>
Message-ID: <6-0ANwl3C0Pua7uKJaLRmKfbm1bWvyWQ8QHGqeeBRkw=.e835dfd4-a4bf-40fb-84eb-87a869a610ca@github.com>

On Mon, 23 Nov 2020 19:24:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple doc fix. Thanks.

Marked as reviewed by joehw (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1399

From herrick at openjdk.java.net  Mon Nov 23 20:22:09 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Mon, 23 Nov 2020 20:22:09 GMT
Subject: RFR: JDK-8256801: tools/jpackage/share/FileAssociationsTest.java#id0
 failed unpack.bat with "Exit code: 1603"
Message-ID: <zU5XvnAxrcywVrCzbiIN4vqoBlpWUB88xK4rMNBo_OM=.8c2e7c66-9040-4102-af67-9da3e5c84506@github.com>

When executing msiexec (possibly from batch script) retry on exitCode 1603 as well as 1618

-------------

Commit messages:
 - JDK-8256801: tools/jpackage/share/FileAssociationsTest.java#id0 failed unpack.bat with "Exit code: 1603"

Changes: https://git.openjdk.java.net/jdk/pull/1400/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1400&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256801
  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1400.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1400/head:pull/1400

PR: https://git.openjdk.java.net/jdk/pull/1400

From harold.seigel at oracle.com  Mon Nov 23 20:27:21 2020
From: harold.seigel at oracle.com (Harold Seigel)
Date: Mon, 23 Nov 2020 15:27:21 -0500
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>
Message-ID: <bc550458-fea3-d543-1cd9-78f7192fe8ec@oracle.com>

Hi David,

Thanks for looking at this.

The intent was for method Class.permittedSubclasses() to be implemented 
similarly to Class.getNestMembers().? Are you suggesting that a security 
manager check be added to permittedSubclasses() similar to the security 
manager check in getNestMembers()?

Thanks, Harold

On 11/18/2020 12:31 AM, David Holmes wrote:
> Hi Vincente,
>
> On 16/11/2020 11:36 pm, Vicente Romero wrote:
>> Please review the code for the second iteration of sealed classes. In 
>> this iteration we are:
>>
>> - Enhancing narrowing reference conversion to allow for stricter 
>> checking of cast conversions with respect to sealed type hierarchies.
>> - Also local classes are not considered when determining implicitly 
>> declared permitted direct subclasses of a sealed class or sealed 
>> interface
>
> The major change here seems to be that getPermittedSubclasses() now 
> returns actual Class objects instead of ClassDesc. My recollection 
> from earlier discussions here was that the use of ClassDesc was very 
> deliberate as the permitted subclasses may not actually exist and 
> there may be security concerns with returning them!
>
> Cheers,
> David
> -----
>
>> -------------
>>
>> Commit messages:
>> ? - 8246778: Compiler implementation for Sealed Classes (Second Preview)
>>
>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>> ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>> ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk 
>> pull/1227/head:pull/1227
>>
>> PR: https://git.openjdk.java.net/jdk/pull/1227
>>

From jvernee at openjdk.java.net  Mon Nov 23 20:36:11 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Mon, 23 Nov 2020 20:36:11 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v4]
In-Reply-To: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
Message-ID: <e_SXwbSkjWisuw2ebXg_tnyGN7xt4Cyh916GslGsbpw=.9f7fbb48-ff95-4b64-b928-477bbc1a4063@github.com>

> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
> 
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
> 
> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
> 
> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
> 
> Testing: `make images` on Linux and Windows x86_32 platforms.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Use the Unimplemented() macro instead of hlt()

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1266/files
  - new: https://git.openjdk.java.net/jdk/pull/1266/files/9dcbb58c..4f0c6ef9

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=02-03

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1266.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266

PR: https://git.openjdk.java.net/jdk/pull/1266

From rkennke at openjdk.java.net  Mon Nov 23 20:39:01 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 23 Nov 2020 20:39:01 GMT
Subject: RFR: 8256517: (ref) Reference.clear during reference processing
 may lose notification
In-Reply-To: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
References: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
Message-ID: <4C7DyAgcXsSq3YEzbbwWeLaIbWwOyEriG8_4QrWNZ80=.4b75553f-7eaf-4d8b-9b47-007fc0609ba7@github.com>

On Mon, 23 Nov 2020 01:43:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to Reference.clear() to address several issues.
> 
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
> 
> (JDK-8240696) For GCs with concurrent reference processing, clearing the
> referent field during reference processing may discard the expected
> notification.
> 
> Both of these are addressed by introducing a private native helper function
> for clearing the referent, rather than using an ordinary in-Java field
> assignment. Tests have been added for both of these issues. This required
> adding a new breakpoint in reference processing for ZGC.
> 
> Of course, finalization adds some complexity to the problem.  We deal with
> that by having FinalReference override clear.  The implementation is
> provided by a new package-private method in Reference.  (There are a number
> of alternatives, all of them clumsy; finalization is annoying that way.)
> 
> While dealing with FinalReference clearing it was noted that the recent
> JDK-8256106 and JDK-8256370 have some problems. FinalizerHistogram was not
> updated to call the new Reference.getInactive(), instead still calling get()
> on FinalReferences, with the JDK-8256106 problems. Fixing that showed the
> assertion for inactive FinalReference added by JDK-8256370 used the wrong
> test.
> 
> Rather than tracking down and changing all get() and clear() calls on final
> references and changing them to use getInactive and a new similar clear
> function, I've changed FinalReference to override get and clear, which call
> the helper functions in Reference. I've also renamed getInactive to be more
> explanatory and less convenient to call directly, and similarly named the
> helper for clear. This means that get/clear should never be called on an
> active FinalReference. That's already never done, and would have problems
> if it were.
> 
> Testing:
> mach5 tier1-6
> Local (linux-x64) tier1 using Shenandoah.
> New TestReferenceClearDuringMarking fails for G1 without these changes.
> New TestReferenceClearDuringReferenceProcessing fails for ZGC without these changes.

Looks good! Thanks!

-------------

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1376

From rkennke at openjdk.java.net  Mon Nov 23 20:39:03 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Mon, 23 Nov 2020 20:39:03 GMT
Subject: RFR: 8256517: (ref) Reference.clear during reference processing
 may lose notification
In-Reply-To: <rfCOaqTi1O564eSDFu6aVslbRWzdECqh11C1i7_HPnk=.cca5c47f-5e1c-44cd-911a-a8d80416f94c@github.com>
References: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
 <CThImLjLQN0BvRpbLyUGVS8gdnhw5-5w6rjQ3aow0hA=.58756e8b-b854-4e72-b584-bd6654bfe27e@github.com>
 <rfCOaqTi1O564eSDFu6aVslbRWzdECqh11C1i7_HPnk=.cca5c47f-5e1c-44cd-911a-a8d80416f94c@github.com>
Message-ID: <2BmKewSdmP4lGhembmuF4d2hQbVtJFrW0Cv_XRVdD3U=.492b7c6a-c38e-4159-8c29-656073502176@github.com>

On Mon, 23 Nov 2020 19:18:05 GMT, Per Liden <pliden at openjdk.org> wrote:

>> test/hotspot/jtreg/gc/TestReferenceClearDuringReferenceProcessing.java line 28:
>> 
>>> 26: /* @test
>>> 27:  * @bug 8256517
>>> 28:  * @requires vm.gc.Z
>> 
>> Please add | vm.gc.Shenandoah here.
>
> Note that for this test to be useful, the GC needs to support concurrent GC breakpoints, which Shenandoah doesn't do.

Ok, right. Nevermind then!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1376

From mchung at openjdk.java.net  Mon Nov 23 20:58:54 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 23 Nov 2020 20:58:54 GMT
Subject: RFR: 8256517: (ref) Reference.clear during reference processing
 may lose notification
In-Reply-To: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
References: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
Message-ID: <rCdF5_yJMqfQBQxKGrT78oTduzMlwDtpOk6sc6i9D0Y=.a51726e3-f0a0-4842-8112-57bef0ec42c0@github.com>

On Mon, 23 Nov 2020 01:43:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to Reference.clear() to address several issues.
> 
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
> 
> (JDK-8240696) For GCs with concurrent reference processing, clearing the
> referent field during reference processing may discard the expected
> notification.
> 
> Both of these are addressed by introducing a private native helper function
> for clearing the referent, rather than using an ordinary in-Java field
> assignment. Tests have been added for both of these issues. This required
> adding a new breakpoint in reference processing for ZGC.
> 
> Of course, finalization adds some complexity to the problem.  We deal with
> that by having FinalReference override clear.  The implementation is
> provided by a new package-private method in Reference.  (There are a number
> of alternatives, all of them clumsy; finalization is annoying that way.)
> 
> While dealing with FinalReference clearing it was noted that the recent
> JDK-8256106 and JDK-8256370 have some problems. FinalizerHistogram was not
> updated to call the new Reference.getInactive(), instead still calling get()
> on FinalReferences, with the JDK-8256106 problems. Fixing that showed the
> assertion for inactive FinalReference added by JDK-8256370 used the wrong
> test.
> 
> Rather than tracking down and changing all get() and clear() calls on final
> references and changing them to use getInactive and a new similar clear
> function, I've changed FinalReference to override get and clear, which call
> the helper functions in Reference. I've also renamed getInactive to be more
> explanatory and less convenient to call directly, and similarly named the
> helper for clear. This means that get/clear should never be called on an
> active FinalReference. That's already never done, and would have problems
> if it were.
> 
> Testing:
> mach5 tier1-6
> Local (linux-x64) tier1 using Shenandoah.
> New TestReferenceClearDuringMarking fails for G1 without these changes.
> New TestReferenceClearDuringReferenceProcessing fails for ZGC without these changes.

Looks good.  Thanks for correcting `assert next != null`  inactive FinalReference check.

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1376

From scolebourne at openjdk.java.net  Mon Nov 23 21:00:00 2020
From: scolebourne at openjdk.java.net (Stephen Colebourne)
Date: Mon, 23 Nov 2020 21:00:00 GMT
Subject: RFR: 8256839: JavaDoc for java.time.Period.negated() method
In-Reply-To: <BdYfJv6d5JUWxyD7QVRRtyFYrCSqAl16YHTYRNU77_w=.3055d463-3855-441a-a174-b63b823d7180@github.com>
References: <BdYfJv6d5JUWxyD7QVRRtyFYrCSqAl16YHTYRNU77_w=.3055d463-3855-441a-a174-b63b823d7180@github.com>
Message-ID: <d8DC81bWX66McXx6Jd5x9N7BxhFo02nIv7AkqPf8TlA=.9a2edcc4-aa55-44be-82cd-fc4007bb001e@github.com>

On Mon, 23 Nov 2020 19:24:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple doc fix. Thanks.

Marked as reviewed by scolebourne (Author).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1399

From mchung at openjdk.java.net  Mon Nov 23 21:01:00 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 23 Nov 2020 21:01:00 GMT
Subject: RFR: 8256370: Add asserts to Reference.getInactive()
In-Reply-To: <XQ56pY_DemIe8Fq029A_XLUyoDyBpWBFDD71s-dQUrU=.81a2079d-eea6-4e08-a64e-d9c4e42df579@github.com>
References: <-QVwpOcOTp5Gb7Sjq04ihTxP5h0nMHCh307WqkEjE-M=.83b69e68-19e6-4a10-8bd3-010d2c008140@github.com>
 <FqR4moRH9Y3KtU7P8UUxA1Gi2VDJqnY4W2b4OgkF0kg=.9bfe984e-3c84-4ea2-95a7-4e88bfba9d55@github.com>
 <XQ56pY_DemIe8Fq029A_XLUyoDyBpWBFDD71s-dQUrU=.81a2079d-eea6-4e08-a64e-d9c4e42df579@github.com>
Message-ID: <CwyYYDySV_tF9u_Z6yI0AXm1txtJvoSRt63s-sjg5qI=.5740a242-34bc-4e7f-ac88-5f41fecc8015@github.com>

On Sun, 22 Nov 2020 22:15:20 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Thanks for adding this asserts.  If there is any reason to use `getInactive` by other references in the future, we could remove these asserts at that time.
>
> I didn't notice this before it was integrated.
> 
> The test for inactive isn't right; rather than `next == this` it
> should be `next != null`.  This becomes apparent once
> FinalizerHistogram is fixed to call getInactive() rather than get().
> 
> I noticed this while working on JDK-8256517, where I ran into some
> similar issues.  I will address these problems as part of that change.

@kimbarrett  thanks for correcting this inactive FinalReference assert.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1231

From asemenyuk at openjdk.java.net  Mon Nov 23 22:05:02 2020
From: asemenyuk at openjdk.java.net (Alexey Semenyuk)
Date: Mon, 23 Nov 2020 22:05:02 GMT
Subject: RFR: JDK-8256801:
 tools/jpackage/share/FileAssociationsTest.java#id0 failed unpack.bat with
 "Exit code: 1603"
In-Reply-To: <zU5XvnAxrcywVrCzbiIN4vqoBlpWUB88xK4rMNBo_OM=.8c2e7c66-9040-4102-af67-9da3e5c84506@github.com>
References: <zU5XvnAxrcywVrCzbiIN4vqoBlpWUB88xK4rMNBo_OM=.8c2e7c66-9040-4102-af67-9da3e5c84506@github.com>
Message-ID: <pUB89C6pHsvA8JhpLFSdh_1gCJ_dI2ESg6lyFNyqvS8=.52bc6a12-0fc0-4ba6-8118-62fbbc717f64@github.com>

On Mon, 23 Nov 2020 20:16:58 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> When executing msiexec (possibly from batch script) retry on exitCode 1603 as well as 1618

Marked as reviewed by asemenyuk (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1400

From naoto at openjdk.java.net  Mon Nov 23 22:20:58 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 23 Nov 2020 22:20:58 GMT
Subject: Integrated: 8256839: JavaDoc for java.time.Period.negated() method
In-Reply-To: <BdYfJv6d5JUWxyD7QVRRtyFYrCSqAl16YHTYRNU77_w=.3055d463-3855-441a-a174-b63b823d7180@github.com>
References: <BdYfJv6d5JUWxyD7QVRRtyFYrCSqAl16YHTYRNU77_w=.3055d463-3855-441a-a174-b63b823d7180@github.com>
Message-ID: <l1yvQlMOlXkqhBCnN1x8CB2Unov6LfexhMsPnEWLI0o=.e2e06773-7d8c-477e-be73-e4a0ffc36459@github.com>

On Mon, 23 Nov 2020 19:24:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi,
> 
> Please review this simple doc fix. Thanks.

This pull request has now been integrated.

Changeset: b3497f9b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b3497f9b
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8256839: JavaDoc for java.time.Period.negated() method

Reviewed-by: rriggs, lancea, joehw, scolebourne

-------------

PR: https://git.openjdk.java.net/jdk/pull/1399

From mr at openjdk.java.net  Mon Nov 23 23:06:13 2020
From: mr at openjdk.java.net (Mark Reinhold)
Date: Mon, 23 Nov 2020 23:06:13 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v4]
In-Reply-To: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
Message-ID: <5LdSUcXZ92UZSYCj-x2EHaIoSPlQBaNNwGh0P4ysMFk=.65abff58-68fe-47a6-923d-5ddce18f33e8@github.com>

> Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396).
> Alan Bateman is the original author; I?ve credited him in the commit metadata.
> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64.

Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision:

  Fix "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1324/files
  - new: https://git.openjdk.java.net/jdk/pull/1324/files/a57e6065..6a4d4792

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=02-03

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1324.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1324/head:pull/1324

PR: https://git.openjdk.java.net/jdk/pull/1324

From mr at openjdk.java.net  Mon Nov 23 23:14:11 2020
From: mr at openjdk.java.net (Mark Reinhold)
Date: Mon, 23 Nov 2020 23:14:11 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v5]
In-Reply-To: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
Message-ID: <91KldHNqIOZI9hHedlD3QKW-EtpnRVP_116OqwUqmc4=.9d1f189d-2dda-42cb-b9d2-8b4d48ae279e@github.com>

> Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396).
> Alan Bateman is the original author; I?ve credited him in the commit metadata.
> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64.

Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision:

  Revert: Fix "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test
  
  This reverts commit 6a4d4792261f54b014336d1907b0040b15fdb467.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1324/files
  - new: https://git.openjdk.java.net/jdk/pull/1324/files/6a4d4792..1a7ab4e0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=03-04

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1324.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1324/head:pull/1324

PR: https://git.openjdk.java.net/jdk/pull/1324

From almatvee at openjdk.java.net  Tue Nov 24 00:30:56 2020
From: almatvee at openjdk.java.net (Alexander Matveev)
Date: Tue, 24 Nov 2020 00:30:56 GMT
Subject: RFR: JDK-8256801:
 tools/jpackage/share/FileAssociationsTest.java#id0 failed unpack.bat with
 "Exit code: 1603"
In-Reply-To: <zU5XvnAxrcywVrCzbiIN4vqoBlpWUB88xK4rMNBo_OM=.8c2e7c66-9040-4102-af67-9da3e5c84506@github.com>
References: <zU5XvnAxrcywVrCzbiIN4vqoBlpWUB88xK4rMNBo_OM=.8c2e7c66-9040-4102-af67-9da3e5c84506@github.com>
Message-ID: <vLQqI7l5nzyWWnbiBMjsvLIdtFV_DZnFNkW1fmvaKBM=.9650cbbd-b9f4-4f9d-ab72-88630c76419f@github.com>

On Mon, 23 Nov 2020 20:16:58 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> When executing msiexec (possibly from batch script) retry on exitCode 1603 as well as 1618

Marked as reviewed by almatvee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1400

From david.holmes at oracle.com  Tue Nov 24 01:04:55 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Nov 2020 11:04:55 +1000
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <bc550458-fea3-d543-1cd9-78f7192fe8ec@oracle.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>
 <bc550458-fea3-d543-1cd9-78f7192fe8ec@oracle.com>
Message-ID: <96418b57-12fe-208e-c642-b04efeedca24@oracle.com>

Hi Harold,

On 24/11/2020 6:27 am, Harold Seigel wrote:
> Hi David,
> 
> Thanks for looking at this.
> 
> The intent was for method Class.permittedSubclasses() to be implemented 
> similarly to Class.getNestMembers().? Are you suggesting that a security 
> manager check be added to permittedSubclasses() similar to the security 
> manager check in getNestMembers()?

No I'm suggesting the change to the API is plain wrong. :) Please see 
discussion in the CSR.

Cheers,
David

> Thanks, Harold
> 
> On 11/18/2020 12:31 AM, David Holmes wrote:
>> Hi Vincente,
>>
>> On 16/11/2020 11:36 pm, Vicente Romero wrote:
>>> Please review the code for the second iteration of sealed classes. In 
>>> this iteration we are:
>>>
>>> - Enhancing narrowing reference conversion to allow for stricter 
>>> checking of cast conversions with respect to sealed type hierarchies.
>>> - Also local classes are not considered when determining implicitly 
>>> declared permitted direct subclasses of a sealed class or sealed 
>>> interface
>>
>> The major change here seems to be that getPermittedSubclasses() now 
>> returns actual Class objects instead of ClassDesc. My recollection 
>> from earlier discussions here was that the use of ClassDesc was very 
>> deliberate as the permitted subclasses may not actually exist and 
>> there may be security concerns with returning them!
>>
>> Cheers,
>> David
>> -----
>>
>>> -------------
>>>
>>> Commit messages:
>>> ? - 8246778: Compiler implementation for Sealed Classes (Second Preview)
>>>
>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>>> ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>>> ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk 
>>> pull/1227/head:pull/1227
>>>
>>> PR: https://git.openjdk.java.net/jdk/pull/1227
>>>

From dholmes at openjdk.java.net  Tue Nov 24 01:19:58 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 24 Nov 2020 01:19:58 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v4]
In-Reply-To: <e_SXwbSkjWisuw2ebXg_tnyGN7xt4Cyh916GslGsbpw=.9f7fbb48-ff95-4b64-b928-477bbc1a4063@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <e_SXwbSkjWisuw2ebXg_tnyGN7xt4Cyh916GslGsbpw=.9f7fbb48-ff95-4b64-b928-477bbc1a4063@github.com>
Message-ID: <tKvsXc464T-GR0s0RP4emxENx2TDxW-8BX9_zU59iCo=.b3933400-9bfe-425a-95fb-3b659b7da8f9@github.com>

On Mon, 23 Nov 2020 20:36:11 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
>> 
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
>> 
>> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
>> 
>> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
>> 
>> Testing: `make images` on Linux and Windows x86_32 platforms.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the Unimplemented() macro instead of hlt()

Hi Jorn,

Sorry but I don't agree with the addition of JNI_ENTRY_CPP_NOENV. I think there is a flaw in the way these methods are exposed/structured. See comment below.

Thanks,
David

src/hotspot/share/prims/universalUpcallHandler.cpp line 36:

> 34: extern struct JavaVM_ main_vm;
> 35: 
> 36: JNI_ENTRY_CPP_NOENV(void, ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff))

I do not like this. I think you have a design flaw here. We should not be directly calling member functions like this from other native code! The entry point should be a simple C-linkage function that is a normal JNI_ENTRY (assuming it actually should be a JNI_ENTRY and not JVM_ENTRY?) and that can then call the true target.

-------------

Changes requested by dholmes (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1266

From kizune at openjdk.java.net  Tue Nov 24 01:27:58 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 24 Nov 2020 01:27:58 GMT
Subject: RFR: JDK-8256801:
 tools/jpackage/share/FileAssociationsTest.java#id0 failed unpack.bat with
 "Exit code: 1603"
In-Reply-To: <zU5XvnAxrcywVrCzbiIN4vqoBlpWUB88xK4rMNBo_OM=.8c2e7c66-9040-4102-af67-9da3e5c84506@github.com>
References: <zU5XvnAxrcywVrCzbiIN4vqoBlpWUB88xK4rMNBo_OM=.8c2e7c66-9040-4102-af67-9da3e5c84506@github.com>
Message-ID: <3sGUEid9RKRn7J-bE9LSjaph0U5DxId4ybbIpJTjcRs=.e31e1831-e61b-4979-968f-c9c757cfd6f8@github.com>

On Mon, 23 Nov 2020 20:16:58 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> When executing msiexec (possibly from batch script) retry on exitCode 1603 as well as 1618

Looks fine.

-------------

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1400

From prappo at openjdk.java.net  Tue Nov 24 02:21:56 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Tue, 24 Nov 2020 02:21:56 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <pvwIoAweUPTqGrO7Hxx5VxCbdlEI6-S83rLfRyNmySo=.106ee077-43e3-48a7-8a05-181986e5606b@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
 <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
 <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
 <TFCxfLxB7_iDyPbbSXJtWZZm4HOW_n4R66vMnNEzYvI=.1659cc00-17c8-4999-bbb7-b5c7516599b7@github.com>
 <pvwIoAweUPTqGrO7Hxx5VxCbdlEI6-S83rLfRyNmySo=.106ee077-43e3-48a7-8a05-181986e5606b@github.com>
Message-ID: <BV5JY8q6TzUEtFvidfqWgj09YEYZVvKYPrZgnlrqgQ0=.fc07a453-fafe-4fe6-95f5-4c7613818eff@github.com>

On Mon, 23 Nov 2020 14:35:37 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> The proposed CSR has a few problems that we need to resolve.
> 
> 1. The **Specification** pseudo-code behaves differently from both the old pseudo-code and the actual implementation when `newValue == null && oldValue == null` and `map.containsKey(key) == true`.
> 2. The content of the **Solution** section seems irrelevant: aside from a couple of missing `return` statements the current pseudo-code is fine. We are after something else, aren't we? The bottom line is we should state the solution more clearly.
> 3. The **Summary** section differs from that of the JDK-8247402.

I read my previous reply and realized that it is confusing and contains a factual error; so let me straighten it out in this new reply rather than edit that previous one.

1. The proposed pseudo-code behaves exactly the same way as the existing pseudo-code modulo the missing `return` statements. (For some reason, I previously wrote that the proposed pseudo-code behaves differently from the existing pseudo-code.)
2. Both the proposed pseudo-code and the existing pseudo-code deviate from the documented behaviour (written in prose) and the actual implementation. The deviation happens when `newValue == null && (oldValue = map.get(key)) == null` and `map.containsKey(key) == true`. (That part was correct.)

Now, here's what I should have said in my previous reply. If the CSR intends to solve (2) then both the proposed pseudo-code and the **Problem** section must be updated; otherwise the **Solution** section must be updated. Put differently, either fix the diff and add one more item to that problem list, or change the solution. Otherwise the solution does not match the problem leaving the CSR in a contradictory state.

I hope this all makes sense now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From dholmes at openjdk.java.net  Tue Nov 24 02:27:56 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 24 Nov 2020 02:27:56 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks [v2]
In-Reply-To: <Pn2HG31gVguHDxURxy8Q67UpAKhQB_T85XkCBLuAINk=.4a0a12fa-7c79-4edc-bc0e-37f8c5d7602f@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
 <Pn2HG31gVguHDxURxy8Q67UpAKhQB_T85XkCBLuAINk=.4a0a12fa-7c79-4edc-bc0e-37f8c5d7602f@github.com>
Message-ID: <KoDM0sLH9mqBj-_HTQL299BW1grJZyQihCJtdv0RMco=.13f2e167-780a-49c6-9e45-f11444868941@github.com>

On Mon, 23 Nov 2020 18:10:47 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix cut/paste error in FunctionDescriptor
>
> Already looked at this in panama-foreign, but found one minor issue.

Just an observation but there are precedents for just placing a generic statement in the package and/or class javadoc:

"Unless specified otherwise any method that is passed a null reference will throw NullPointerException"

rather than adding @throws NPE all over the place.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1388

From kbarrett at openjdk.java.net  Tue Nov 24 03:05:19 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 24 Nov 2020 03:05:19 GMT
Subject: RFR: 8256517: (ref) Reference.clear during reference processing
 may lose notification [v2]
In-Reply-To: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
References: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
Message-ID: <kJFH7o0SkO-Nc5oIMgX4aAQWIP4zBhCIq2ZNOWZpI1c=.d5911114-ca07-4e7d-88b3-bf2df7e22cce@github.com>

> Please review this change to Reference.clear() to address several issues.
> 
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
> 
> (JDK-8240696) For GCs with concurrent reference processing, clearing the
> referent field during reference processing may discard the expected
> notification.
> 
> Both of these are addressed by introducing a private native helper function
> for clearing the referent, rather than using an ordinary in-Java field
> assignment. Tests have been added for both of these issues. This required
> adding a new breakpoint in reference processing for ZGC.
> 
> Of course, finalization adds some complexity to the problem.  We deal with
> that by having FinalReference override clear.  The implementation is
> provided by a new package-private method in Reference.  (There are a number
> of alternatives, all of them clumsy; finalization is annoying that way.)
> 
> While dealing with FinalReference clearing it was noted that the recent
> JDK-8256106 and JDK-8256370 have some problems. FinalizerHistogram was not
> updated to call the new Reference.getInactive(), instead still calling get()
> on FinalReferences, with the JDK-8256106 problems. Fixing that showed the
> assertion for inactive FinalReference added by JDK-8256370 used the wrong
> test.
> 
> Rather than tracking down and changing all get() and clear() calls on final
> references and changing them to use getInactive and a new similar clear
> function, I've changed FinalReference to override get and clear, which call
> the helper functions in Reference. I've also renamed getInactive to be more
> explanatory and less convenient to call directly, and similarly named the
> helper for clear. This means that get/clear should never be called on an
> active FinalReference. That's already never done, and would have problems
> if it were.
> 
> Testing:
> mach5 tier1-6
> Local (linux-x64) tier1 using Shenandoah.
> New TestReferenceClearDuringMarking fails for G1 without these changes.
> New TestReferenceClearDuringReferenceProcessing fails for ZGC without these changes.

Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:

 - new tests need ref in oldgen too
 - remove obsolete comment about races with clear and enqueue

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1376/files
  - new: https://git.openjdk.java.net/jdk/pull/1376/files/46e5b1f6..c19efd70

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1376&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1376&range=00-01

  Stats: 17 lines in 3 files changed: 7 ins; 6 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1376/head:pull/1376

PR: https://git.openjdk.java.net/jdk/pull/1376

From kbarrett at openjdk.java.net  Tue Nov 24 03:05:19 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 24 Nov 2020 03:05:19 GMT
Subject: RFR: 8256517: (ref) Reference.clear during reference processing
 may lose notification [v2]
In-Reply-To: <ul7I2y7Wz9BR5j9rAOQqwL-H-xYEAHOD1_Zr4oZlPp8=.91a31ce0-b032-4099-b24e-95f273c7d0b5@github.com>
References: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
 <ul7I2y7Wz9BR5j9rAOQqwL-H-xYEAHOD1_Zr4oZlPp8=.91a31ce0-b032-4099-b24e-95f273c7d0b5@github.com>
Message-ID: <OnRCxbtIju9V9yAMn--ftrYLLikSBMUu_8NzFcXXro0=.22eb2f0a-4b0b-4f68-8d34-23a78b6c1594@github.com>

On Mon, 23 Nov 2020 12:50:31 GMT, Per Liden <pliden at openjdk.org> wrote:

> Looks good. Just want to request that you also remove the following comment in zReferenceProcessor.cpp, as it's no longer true.
> 
> ```
> --- a/src/hotspot/share/gc/z/zReferenceProcessor.cpp
> +++ b/src/hotspot/share/gc/z/zReferenceProcessor.cpp
> @@ -184,12 +184,6 @@ bool ZReferenceProcessor::should_discover(oop reference, ReferenceType type) con
>  }
>  
>  bool ZReferenceProcessor::should_drop(oop reference, ReferenceType type) const {
> -  // This check is racing with a call to Reference.clear() from the application.
> -  // If the application clears the reference after this check it will still end
> -  // up on the pending list, and there's nothing we can do about that without
> -  // changing the Reference.clear() API. This check is also racing with a call
> -  // to Reference.enqueue() from the application, which is unproblematic, since
> -  // the application wants the reference to be enqueued anyway.
>    const oop referent = reference_referent(reference);
>    if (referent == NULL) {
>      // Reference has been cleared, by a call to Reference.enqueue()
> ```

Done.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1376

From kbarrett at openjdk.java.net  Tue Nov 24 03:05:19 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Tue, 24 Nov 2020 03:05:19 GMT
Subject: RFR: 8256517: (ref) Reference.clear during reference processing
 may lose notification [v2]
In-Reply-To: <OnRCxbtIju9V9yAMn--ftrYLLikSBMUu_8NzFcXXro0=.22eb2f0a-4b0b-4f68-8d34-23a78b6c1594@github.com>
References: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
 <ul7I2y7Wz9BR5j9rAOQqwL-H-xYEAHOD1_Zr4oZlPp8=.91a31ce0-b032-4099-b24e-95f273c7d0b5@github.com>
 <OnRCxbtIju9V9yAMn--ftrYLLikSBMUu_8NzFcXXro0=.22eb2f0a-4b0b-4f68-8d34-23a78b6c1594@github.com>
Message-ID: <m5lbqmKvjGQABdh8GKPbPYeueWycRN3zp9yJn2oc6n8=.de01a70d-9cee-4a40-9a9a-59244a60ac0f@github.com>

On Tue, 24 Nov 2020 02:59:50 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Looks good. Just want to request that you also remove the following comment in zReferenceProcessor.cpp, as it's no longer true.
>> 
>> --- a/src/hotspot/share/gc/z/zReferenceProcessor.cpp
>> +++ b/src/hotspot/share/gc/z/zReferenceProcessor.cpp
>> @@ -184,12 +184,6 @@ bool ZReferenceProcessor::should_discover(oop reference, ReferenceType type) con
>>  }
>>  
>>  bool ZReferenceProcessor::should_drop(oop reference, ReferenceType type) const {
>> -  // This check is racing with a call to Reference.clear() from the application.
>> -  // If the application clears the reference after this check it will still end
>> -  // up on the pending list, and there's nothing we can do about that without
>> -  // changing the Reference.clear() API. This check is also racing with a call
>> -  // to Reference.enqueue() from the application, which is unproblematic, since
>> -  // the application wants the reference to be enqueued anyway.
>>    const oop referent = reference_referent(reference);
>>    if (referent == NULL) {
>>      // Reference has been cleared, by a call to Reference.enqueue()
>
>> Looks good. Just want to request that you also remove the following comment in zReferenceProcessor.cpp, as it's no longer true.
>> 
>> ```
>> --- a/src/hotspot/share/gc/z/zReferenceProcessor.cpp
>> +++ b/src/hotspot/share/gc/z/zReferenceProcessor.cpp
>> @@ -184,12 +184,6 @@ bool ZReferenceProcessor::should_discover(oop reference, ReferenceType type) con
>>  }
>>  
>>  bool ZReferenceProcessor::should_drop(oop reference, ReferenceType type) const {
>> -  // This check is racing with a call to Reference.clear() from the application.
>> -  // If the application clears the reference after this check it will still end
>> -  // up on the pending list, and there's nothing we can do about that without
>> -  // changing the Reference.clear() API. This check is also racing with a call
>> -  // to Reference.enqueue() from the application, which is unproblematic, since
>> -  // the application wants the reference to be enqueued anyway.
>>    const oop referent = reference_referent(reference);
>>    if (referent == NULL) {
>>      // Reference has been cleared, by a call to Reference.enqueue()
>> ```
> 
> Done.

I realized there was a theoretical problem with the new tests; they
should also be ensuring the Reference objects are in oldgen.  That's
fixed in the latest push.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1376

From kizune at openjdk.java.net  Tue Nov 24 03:40:59 2020
From: kizune at openjdk.java.net (Alexander Zuev)
Date: Tue, 24 Nov 2020 03:40:59 GMT
Subject: RFR: JDK-8256475: Fix Behavior when Installer name differs from
 =?UTF-8?B?YXBwbGljYXRpb+KApg==?= [v4]
In-Reply-To: <25b-I2aVPI49KXdos4hcWbUtza3gOoMjrxAd49ca_P4=.ee575d41-5cf4-407f-add1-cdfbe220bdaa@github.com>
References: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
 <25b-I2aVPI49KXdos4hcWbUtza3gOoMjrxAd49ca_P4=.ee575d41-5cf4-407f-add1-cdfbe220bdaa@github.com>
Message-ID: <_cGN0GOe3e_i20J4Phx1QfVL01ZhOX1mFmwDY6CVN5I=.ac3e7ce8-697f-4f4c-bd8f-a75991536007@github.com>

On Thu, 19 Nov 2020 20:45:23 GMT, Andy Herrick <herrick at openjdk.org> wrote:

>> ?n name.
>
> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8256475: Fix Behavior when Installer name differs from application name.

Looks good.

src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties line 75:

> 73: error.jlink.failed=jlink \u5931\u8D25\uFF0C\u51FA\u73B0 {0}
> 74: error.blocked.option=\u4E0D\u5141\u8BB8\u5728 --jlink-options \u4E2D\u4F7F\u7528 jlink \u9009\u9879 [{0}]
> 75: error.no.name=Name not specified with --name and cannot infer one from app-image

Do we need to submit a follow-up bug for localization team that we have new non-localized messages in the region specific properties file? I see that foreign app image warning is still not localized.

-------------

Marked as reviewed by kizune (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1300

From smarks at openjdk.java.net  Tue Nov 24 03:48:58 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 24 Nov 2020 03:48:58 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v3]
In-Reply-To: <Oxn7CirvPu4wJ2jdOQzjOT_KHZB6uZAcuHHQSdrQrWA=.07c41bdd-9fed-4cfc-bfec-3c0076266ffc@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <3N2Oa4dVVDShlyR-w1G8jWG7mNPL5utzKFdm0QWkM3Y=.0cee9962-8dfb-40f3-b9ae-e50ea8377ed3@github.com>
 <zUyJi1Y8IGbR3Hv50ZWy1OS0oqFycWzHLP7iVECLTec=.2b79a385-c78d-46b3-9b4b-2d5d7bc2d071@github.com>
 <nYmGmOTAId25YFeWQ0PJkB7j658prrjepUr8q9k7kUI=.ba169da0-e72b-4a16-9639-9c301b3d58bc@github.com>
 <Oxn7CirvPu4wJ2jdOQzjOT_KHZB6uZAcuHHQSdrQrWA=.07c41bdd-9fed-4cfc-bfec-3c0076266ffc@github.com>
Message-ID: <5Z9HS6uHE3BQxPEpqsWtEsRZIXOM6NUdPN2BRs6lx0Y=.14a9075a-289a-44c8-8902-2cca976225fd@github.com>

On Mon, 23 Nov 2020 14:06:02 GMT, sergus13 <github.com+74766043+sergus13 at openjdk.org> wrote:

>> This implementation duplicates the array twice, once in this.toArray() and once in the constructor of ArrayList that calls toArray() on Collections.ArrayList.
>> 
>> I'm sure there is a better way
>
> In `ReferencePipeline` class we have:
> 
>     @Override
>     public final Object[] toArray() {
>         return toArray(Object[]::new);
>     }
> 
>     @Override
>     @SuppressWarnings("unchecked")
>     public final <A> A[] toArray(IntFunction<A[]> generator) {
>         ...
>         @SuppressWarnings("rawtypes")
>         IntFunction rawGenerator = (IntFunction) generator;
>         return (A[]) Nodes.flatten(evaluateToArrayNode(rawGenerator), rawGenerator)
>                               .asArray(rawGenerator);
>     }
> 
> 
> In `Nodes` class we have:
> 
> 
>     public static <T> Node<T> flatten(Node<T> node, IntFunction<T[]> generator) {
>         if (node.getChildCount() > 0) {
>             ... 
>             T[] array = generator.apply((int) size);
>             new ToArrayTask.OfRef<>(node, array, 0).invoke();
>             return node(array);
>         } else {
>             return node;
>         }
>     }
> 
> 
> 
> It looks like it is required to implement `toList` method in a similar way in order to avoid array copy. i.e. there will be `IntFunction<List<T>> generator` which will generate 'ArrayList' with specified size and the list's `add` method will be called to add elements to the list.

This is the default implementation in the Stream interface, which is overridden by an implementation in the ReferencePipeline class, so it will rarely be used in normal operation. The ReferencePipeline version (part of this changeset) is based on toArray() and avoids any copying. I'm thus not inclined to add new interfaces in order to support this default implementation.

As written it's true that the default implementation does perform apparently redundant copies, but we can't be assured that toArray() actually returns a freshly created array. Thus, we wrap it using Arrays.asList and then copy it using the ArrayList constructor. This is unfortunate but necessary to avoid situations where someone could hold a reference to the internal array of a List, allowing modification of a List that's supposed to be unmodifiable.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1026

From smarks at openjdk.java.net  Tue Nov 24 03:54:00 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 24 Nov 2020 03:54:00 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v3]
In-Reply-To: <WAgg3Ghp9_8_QnvxMD-7hIsfjOiGXDd6dpq-MsEZxdA=.a337bd69-516a-4622-9999-797f0a2abd3f@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <bUKuBU0ScUvhnCa-rUjJDUCPUfcPmS-OqMXyTSBsUeU=.2430a5a0-076e-4f16-9d1d-0dfa49faa99d@github.com>
 <4CY9WKRujRFgx526Z2joGTNdI4OGIJUI9omHgMnhReg=.8bf6e1d5-8ba9-4f7c-80bf-8adde581a9f6@github.com>
 <WAgg3Ghp9_8_QnvxMD-7hIsfjOiGXDd6dpq-MsEZxdA=.a337bd69-516a-4622-9999-797f0a2abd3f@github.com>
Message-ID: <Kq_IPjOYqLqZeHMr9SlKzE5LxPK1ccwqkSxvgTvHoQA=.685a1837-8c52-4dd9-b429-b8b72f670662@github.com>

On Sat, 21 Nov 2020 10:58:49 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> It's an implementation invariant that the internal array be Object[]. Having it be something other than Object[] can lead to subtle bugs. See [JDK-6260652](https://bugs.openjdk.java.net/browse/JDK-6260652) for example.
>
> you can still calls the varargs with an already created array
> listFromTrustedArray(new String[] { "foo" });
> 
> I think at least an assert is missing
> assert input.getClass() == Object.class;

If the parameter were of type `E...`, then a call such as `listFromTrustedArray("foo", "bar")` would result in a `String[]`. The idea is to avoid accidents such as the one that caused JDK-6260652, and not prevent deliberate passing of an array of the wrong type, though this is an internal interface so it's unlikely to occur. Still, a stronger comment and an assert might be worthwhile.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1026

From smarks at openjdk.java.net  Tue Nov 24 03:54:03 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 24 Nov 2020 03:54:03 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v3]
In-Reply-To: <xpK6ZtSDaf5quZvll3MPVaCkJU3EMyGVszEBfp0ZoXM=.ddde0a41-eb9b-4f62-9e92-d2e363f81b31@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <Mr9vpzMowscNpOjJ52oOlJO50L8x6drIxHb44rVpb1k=.80331bd0-ab10-4658-a5de-d6939251ba25@github.com>
 <xpK6ZtSDaf5quZvll3MPVaCkJU3EMyGVszEBfp0ZoXM=.ddde0a41-eb9b-4f62-9e92-d2e363f81b31@github.com>
Message-ID: <qGd1jWbSucV6U-QVfs7KtE8fuKPwgISUAuhPf64WZV4=.5fb1cc6d-387c-42ca-867d-a59cc018891b@github.com>

On Sat, 21 Nov 2020 11:02:27 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust List.copyOf to null-check and copy allowNulls lists.
>>   Fix equals, hashCode, indexOf, lastIndexOf to handle nulls properly.
>>   Add MOAT tests for new lists; add equals and hashCode tests.
>
> src/java.base/share/classes/java/util/ImmutableCollections.java line 222:
> 
>> 220:             default:
>> 221:                 return (List<E>) new ListN<>(input, false);
>> 222:         }
> 
> Using a switch expression + arrow (->) here will allow you too factor the cast, even if it disappear in the generated bytecode, I think it makes the code more readable

Heh yes, I haven't gotten used to using those yet!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1026

From sundar at openjdk.java.net  Tue Nov 24 05:30:57 2020
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Tue, 24 Nov 2020 05:30:57 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks [v2]
In-Reply-To: <IIqvoh6QQKNC_z78X3X3dhccSBl84cnDjWechUuUf-E=.6159de5c-b255-42f1-811b-03c605d01aa3@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
 <IIqvoh6QQKNC_z78X3X3dhccSBl84cnDjWechUuUf-E=.6159de5c-b255-42f1-811b-03c605d01aa3@github.com>
Message-ID: <Pz8sxNEtYzhKWbFPh-Hnu3_AgDw8n565FxOBYWE1FSQ=.d7e33d78-e3d7-4d83-b2c0-45fe9f3f34f6@github.com>

On Mon, 23 Nov 2020 18:22:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Both the Foreign Memory Access and the Foreign Linker APIs leave something to be desired when it comes to handling NPEs - first, most of the API javadoc is oblivious to NPEs being thrown. Secondly, not all API method implementations add expicit NPE checks - with the result of NPE often being thrown very deep in the call chain - if at all. Third, test for API coverage of nulls is ad-hoc.
>> 
>> This patch rectifies all these issues. To increase coverage for null injected into APIs, this patch introduces a new framework for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
>> 
>> I've also added, as part of this patch, a test to cover the statics in MemoryAccess which were not covered throughly.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix cut/paste error in FunctionDescriptor

Unused imports in TestLayouts.java?

-------------

Marked as reviewed by sundar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1388

From dholmes at openjdk.java.net  Tue Nov 24 06:15:58 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Tue, 24 Nov 2020 06:15:58 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v4]
In-Reply-To: <tKvsXc464T-GR0s0RP4emxENx2TDxW-8BX9_zU59iCo=.b3933400-9bfe-425a-95fb-3b659b7da8f9@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <e_SXwbSkjWisuw2ebXg_tnyGN7xt4Cyh916GslGsbpw=.9f7fbb48-ff95-4b64-b928-477bbc1a4063@github.com>
 <tKvsXc464T-GR0s0RP4emxENx2TDxW-8BX9_zU59iCo=.b3933400-9bfe-425a-95fb-3b659b7da8f9@github.com>
Message-ID: <szmJ4UCEhWIGnsgftI0aR9597EbXeOVCGB5-5yCxrdE=.503b2ff5-92f2-46bd-a3fb-4ab296a4f81d@github.com>

On Tue, 24 Nov 2020 01:14:20 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use the Unimplemented() macro instead of hlt()
>
> src/hotspot/share/prims/universalUpcallHandler.cpp line 36:
> 
>> 34: extern struct JavaVM_ main_vm;
>> 35: 
>> 36: JNI_ENTRY_CPP_NOENV(void, ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff))
> 
> I do not like this. I think you have a design flaw here. We should not be directly calling member functions like this from other native code! The entry point should be a simple C-linkage function that is a normal JNI_ENTRY (assuming it actually should be a JNI_ENTRY and not JVM_ENTRY?) and that can then call the true target.

Looking closer at this and the potential call-chain I don't think this is really either a JNI_ENTRY nor a JVM_ENTRY as we would normally define them. The upcall_stub seems to allow a thread to "tunnel" its way into the VM for a Java call, rather than going through the normal exported interfaces (i.e. JNI). I suspect that earlier in the review process it was requested that this be made some kind of ENTRY but I'm really not sure that fits at all. It may be cleaner, simpler and clearer to just declare a non-exported method that use `ThreadInVMFromNative` directly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From smarks at openjdk.java.net  Tue Nov 24 07:10:14 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 24 Nov 2020 07:10:14 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v4]
In-Reply-To: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
Message-ID: <ZrxAmREv9K_IaU4r6GjlkW4g363el_x9tukTBmqujNk=.c49835b8-18bf-4a1e-b3c5-a76f8dffaaa0@github.com>

> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
> 
> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
> 
> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
> 
> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Add comment and assert regarding array class; use switch expression.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1026/files
  - new: https://git.openjdk.java.net/jdk/pull/1026/files/15beacd2..bd890ae5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1026&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1026&range=02-03

  Stats: 20 lines in 1 file changed: 4 ins; 4 del; 12 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1026.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1026/head:pull/1026

PR: https://git.openjdk.java.net/jdk/pull/1026

From pliden at openjdk.java.net  Tue Nov 24 07:48:04 2020
From: pliden at openjdk.java.net (Per Liden)
Date: Tue, 24 Nov 2020 07:48:04 GMT
Subject: RFR: 8256517: (ref) Reference.clear during reference processing
 may lose notification [v2]
In-Reply-To: <kJFH7o0SkO-Nc5oIMgX4aAQWIP4zBhCIq2ZNOWZpI1c=.d5911114-ca07-4e7d-88b3-bf2df7e22cce@github.com>
References: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
 <kJFH7o0SkO-Nc5oIMgX4aAQWIP4zBhCIq2ZNOWZpI1c=.d5911114-ca07-4e7d-88b3-bf2df7e22cce@github.com>
Message-ID: <uwjrzqZJnhzEW6JDxi7j0Ia57lck-ZLIie_90XFjbE8=.0e9ce256-a882-4abb-9afc-80a50891dc3a@github.com>

On Tue, 24 Nov 2020 03:05:19 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Please review this change to Reference.clear() to address several issues.
>> 
>> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
>> field to null may extend the lifetime of the referent value.
>> 
>> (JDK-8240696) For GCs with concurrent reference processing, clearing the
>> referent field during reference processing may discard the expected
>> notification.
>> 
>> Both of these are addressed by introducing a private native helper function
>> for clearing the referent, rather than using an ordinary in-Java field
>> assignment. Tests have been added for both of these issues. This required
>> adding a new breakpoint in reference processing for ZGC.
>> 
>> Of course, finalization adds some complexity to the problem.  We deal with
>> that by having FinalReference override clear.  The implementation is
>> provided by a new package-private method in Reference.  (There are a number
>> of alternatives, all of them clumsy; finalization is annoying that way.)
>> 
>> While dealing with FinalReference clearing it was noted that the recent
>> JDK-8256106 and JDK-8256370 have some problems. FinalizerHistogram was not
>> updated to call the new Reference.getInactive(), instead still calling get()
>> on FinalReferences, with the JDK-8256106 problems. Fixing that showed the
>> assertion for inactive FinalReference added by JDK-8256370 used the wrong
>> test.
>> 
>> Rather than tracking down and changing all get() and clear() calls on final
>> references and changing them to use getInactive and a new similar clear
>> function, I've changed FinalReference to override get and clear, which call
>> the helper functions in Reference. I've also renamed getInactive to be more
>> explanatory and less convenient to call directly, and similarly named the
>> helper for clear. This means that get/clear should never be called on an
>> active FinalReference. That's already never done, and would have problems
>> if it were.
>> 
>> Testing:
>> mach5 tier1-6
>> Local (linux-x64) tier1 using Shenandoah.
>> New TestReferenceClearDuringMarking fails for G1 without these changes.
>> New TestReferenceClearDuringReferenceProcessing fails for ZGC without these changes.
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - new tests need ref in oldgen too
>  - remove obsolete comment about races with clear and enqueue

Looks good!

-------------

Marked as reviewed by pliden (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1376

From chegar at openjdk.java.net  Tue Nov 24 09:37:00 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 24 Nov 2020 09:37:00 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks [v2]
In-Reply-To: <IIqvoh6QQKNC_z78X3X3dhccSBl84cnDjWechUuUf-E=.6159de5c-b255-42f1-811b-03c605d01aa3@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
 <IIqvoh6QQKNC_z78X3X3dhccSBl84cnDjWechUuUf-E=.6159de5c-b255-42f1-811b-03c605d01aa3@github.com>
Message-ID: <1IOerFa7b3SayGj8WYO37zkS64NCGRuFIDZKK16nu0s=.e91f2bea-8005-471b-a0e4-f11d51c1aceb@github.com>

On Mon, 23 Nov 2020 18:22:14 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Both the Foreign Memory Access and the Foreign Linker APIs leave something to be desired when it comes to handling NPEs - first, most of the API javadoc is oblivious to NPEs being thrown. Secondly, not all API method implementations add expicit NPE checks - with the result of NPE often being thrown very deep in the call chain - if at all. Third, test for API coverage of nulls is ad-hoc.
>> 
>> This patch rectifies all these issues. To increase coverage for null injected into APIs, this patch introduces a new framework for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
>> 
>> I've also added, as part of this patch, a test to cover the statics in MemoryAccess which were not covered throughly.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix cut/paste error in FunctionDescriptor

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1388

From forax at univ-mlv.fr  Tue Nov 24 09:45:14 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Tue, 24 Nov 2020 10:45:14 +0100 (CET)
Subject: RFR: 8246778: Compiler implementation for Sealed Classes
 (Second Preview)
In-Reply-To: <96418b57-12fe-208e-c642-b04efeedca24@oracle.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>
 <bc550458-fea3-d543-1cd9-78f7192fe8ec@oracle.com>
 <96418b57-12fe-208e-c642-b04efeedca24@oracle.com>
Message-ID: <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "David Holmes" <david.holmes at oracle.com>
> ?: "Harold David Seigel" <harold.seigel at oracle.com>, "Vicente Romero" <vromero at openjdk.java.net>, "compiler-dev"
> <compiler-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev"
> <hotspot-dev at openjdk.java.net>
> Envoy?: Mardi 24 Novembre 2020 02:04:55
> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

> Hi Harold,
> 
> On 24/11/2020 6:27 am, Harold Seigel wrote:
>> Hi David,
>> 
>> Thanks for looking at this.
>> 
>> The intent was for method Class.permittedSubclasses() to be implemented
>> similarly to Class.getNestMembers().? Are you suggesting that a security
>> manager check be added to permittedSubclasses() similar to the security
>> manager check in getNestMembers()?
> 
> No I'm suggesting the change to the API is plain wrong. :) Please see
> discussion in the CSR.

Given that the CSR is closed, i will answer here.
There are two issues with the previous implementation of permittedSubclasses, first it's the only method that using method desc which means that people has to be aware on another non trivial concept (object that describes constant pool constant) to understand how to use the method then i've tested this API with my students, all but one what able to correctly derives the Class from a ClassDesc, so instead of asking every users of permittedSubclasses to go through the oops of getting Class from a ClassDesc, i think we can agree that it's better to move the burden from the user to the JDK implementors.

> 
> Cheers,
> David

regards,
R?mi

> 
>> Thanks, Harold
>> 
>> On 11/18/2020 12:31 AM, David Holmes wrote:
>>> Hi Vincente,
>>>
>>> On 16/11/2020 11:36 pm, Vicente Romero wrote:
>>>> Please review the code for the second iteration of sealed classes. In
>>>> this iteration we are:
>>>>
>>>> - Enhancing narrowing reference conversion to allow for stricter
>>>> checking of cast conversions with respect to sealed type hierarchies.
>>>> - Also local classes are not considered when determining implicitly
>>>> declared permitted direct subclasses of a sealed class or sealed
>>>> interface
>>>
>>> The major change here seems to be that getPermittedSubclasses() now
>>> returns actual Class objects instead of ClassDesc. My recollection
>>> from earlier discussions here was that the use of ClassDesc was very
>>> deliberate as the permitted subclasses may not actually exist and
>>> there may be security concerns with returning them!
>>>
>>> Cheers,
>>> David
>>> -----
>>>
>>>> -------------
>>>>
>>>> Commit messages:
>>>> ? - 8246778: Compiler implementation for Sealed Classes (Second Preview)
>>>>
>>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>>>> ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>>>> ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>>>> ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>>>> ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>>>> ?? Fetch: git fetch https://git.openjdk.java.net/jdk
>>>> pull/1227/head:pull/1227
>>>>
>>>> PR: https://git.openjdk.java.net/jdk/pull/1227

From chegar at openjdk.java.net  Tue Nov 24 09:50:00 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 24 Nov 2020 09:50:00 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v5]
In-Reply-To: <zJd-CmYkGv8JsHMoHzHXrKw4M-kulbd_jYlCCH0l7EQ=.5dd965d6-cb3d-471d-a9e1-c615855ba8dc@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <zJd-CmYkGv8JsHMoHzHXrKw4M-kulbd_jYlCCH0l7EQ=.5dd965d6-cb3d-471d-a9e1-c615855ba8dc@github.com>
Message-ID: <sFCyxtYxCf7DFRmaDPYZU_CvuDnuMMFxaX9eRPAVtyw=.4d54dc3a-848f-42ab-a1f3-2d2958071fc1@github.com>

On Sat, 21 Nov 2020 00:39:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects
>> be shared between a hidden class and other classes.  A hidden class can load
>> these live objects as dynamically-computed constants via this API.
>> 
>> Specdiff
>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
>> 
>> With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass`
>> will be deprecated for removal.  Existing libraries should replace their
>> calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass`
>> or `Lookup::defineHiddenClassWithClassData`.
>> 
>> This patch also updates the implementation of lambda meta factory and
>> `MemoryAccessVarHandleGenerator` to use class data.   No performance difference
>> observed in the jdk.incubator.foreign microbenchmarks.   A side note: 
>> `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of 
>> JDK-8254162 but it helps validating the class data support.
>> 
>> Background
>> ----------
>> 
>> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
>> "Constant-pool patching" in the "Risks and Assumption" section.
>> 
>> A VM-anonymous class can be defined with its constant-pool entries already
>> resolved to concrete values. This allows critical constants to be shared
>> between a VM-anonymous class and the language runtime that defines it, and
>> between multiple VM-anonymous classes. For example, a language runtime will
>> often have `MethodHandle` objects in its address space that would be useful
>> to newly-defined VM-anonymous classes. Instead of the runtime serializing
>> the objects to constant-pool entries in VM-anonymous classes and then
>> generating bytecode in those classes to laboriously `ldc` the entries,
>> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
>> to its live objects. The relevant constant-pool entries in the newly-defined
>> VM-anonymous class are pre-linked to those objects, improving performance
>> and reducing footprint. In addition, this allows VM-anonymous classes to
>> refer to each other: Constant-pool entries in a class file are based on names.
>> They thus cannot refer to nameless VM-anonymous classes. A language runtime can,
>> however, easily track the live Class objects for its VM-anonymous classes and
>> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's
>> constant pool entries to other VM-anonymous classes.
>> 
>> This extends the hidden classes to allow live objects to be injected
>> in a hidden class and loaded them via condy.
>> 
>> Details
>> -------
>> 
>> A new `Lookup::defineHiddenClassWithClassData` API takes additional
>> `classData` argument compared to `Lookup::defineHiddenClass`.
>> Class data can be method handles, lookup objects, arbitrary user objects
>> or collections of all of the above.
>> 
>> This method behaves as if calling `Lookup::defineHiddenClass` to define
>> a hidden class with a private static unnamed field that is initialized
>> with `classData` at the first instruction of the class initializer.
>> 
>> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)` and
>> `MethodHandles::classDataAt(Lookup lookup, String name, Class<?> type, int index)`
>> are the bootstrap methods to load the class data of the given lookup's lookup class.
>> The hidden class will be initialized when `classData` method is called if
>> the hidden class has not been initialized.
>> 
>> For a class data containing more than one single element, libraries can
>> create their convenience method to load a single live object via condy.
>> 
>> Frameworks sometimes want to dynamically create a hidden class (HC) and add it
>> it the lookup class nest and have HC to carry secrets hidden from that nest.
>> In this case, frameworks should not to use private static finals (in the HCs
>> they spin) to hold secrets because a nestmate of HC may obtain access to
>> such a private static final and observe the framework's secret.  It should use
>> condy.  In addition, we need to differentiate if a lookup object is created from
>> the original lookup class or created from teleporting e.g. `Lookup::in`
>> and `MethodHandles::privateLookupIn`.
>> 
>> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
>> object is created by `MethodHandles::lookup` or by bootstrap method invocation.
>> The operations only apply to a Lookup object with original access are:
>>    - create method handles for caller-sensitve methods
>>    - obtain class data associated with the lookup class
>> 
>> No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which
>> ignores the ORIGINAL bit.
>> 
>> 
>> Compatibility Risks
>> -------------------
>> 
>> `Lookup::lookupModes` includes a new `ORIGINAL` bit.  Most lookup operations
>> ignore this original bit except creating method handles for caller-sensitive methods
>> that expects the lookup from the original lookup class.  Existing code  compares
>> the return value of `lookupModes` to be a fixed value may be impacted.   However
>> existing client has no need to expect a fixed value of lookup modes.
>> The incompatibility risk of this spec change is low.
>
> Mandy Chung has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - slight tweak of api note
>  - Fix revealDirect to check for original access.
>  - Incorporate Paul's feedback

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1171

From chegar at openjdk.java.net  Tue Nov 24 09:50:01 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 24 Nov 2020 09:50:01 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v4]
In-Reply-To: <WqR_knixoUiJMUUdXYbCB5ooA1-HfVT30ZllY1WUdkI=.224ffe9e-ee05-4c43-baab-33c3cdb508ed@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
 <tKPyoN5O290X_W3n2DF1jvunO0YBoyNnoT5jXjmsNc0=.ecc67352-e2ef-4408-9ac1-e5e90a345424@github.com>
 <K9VUz-ZEbZvwn9hVtg-BpsxJBsDxf1hKTSyvhFgdxrA=.4f06ae1e-c5e6-4231-ae86-1a0ba69c3431@github.com>
 <4UhMfpMR51CIIMA1Sl6ZQOEtvwgkdFHujTEUmxR0YQE=.96094f68-b698-469b-b20f-143d237ced02@github.com>
 <WqR_knixoUiJMUUdXYbCB5ooA1-HfVT30ZllY1WUdkI=.224ffe9e-ee05-4c43-baab-33c3cdb508ed@github.com>
Message-ID: <WYYpCFvX46FAMMrUFZwTPwLUcrOPnCDBYok5AHDi3EI=.b45ffde2-0e44-4821-93a7-ee3847029b17@github.com>

On Mon, 23 Nov 2020 17:48:31 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > It is my understanding that `Lookup` object returned from defineHiddenClass[WithClassData] features the ORIGINAL access lookup mode, right? I cannot find a normative statement to confirm this. If it is the case, then it would be good to clarify this.
> 
> Yes with ORIGINAL access. I updated `@return` for both `defineHiddenClass` and `defineHiddenClassWithClassData` as follows:
> 
> ```
> -         * @return the {@code Lookup} object on the hidden class
> +         * @return the {@code Lookup} object on the hidden class with
> +         * {@linkplain #ORIGINAL original} and
> +         * {@linkplain Lookup#hasFullPrivilegeAccess() full privilege} access
> ```

Thank you. This addresses my concern.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1171

From chegar at openjdk.java.net  Tue Nov 24 10:18:03 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Tue, 24 Nov 2020 10:18:03 GMT
Subject: RFR: 8255904: Remove superfluous use of reflection in Class::isRecord
Message-ID: <G4d8RjYyOlsZcfOmgiz5uz0-Zr8E6crIv0OaCQd-DmU=.a787c6ab-a2f1-43cd-acd6-d585a9327dcd@github.com>

Minor cleanup - Reflective access to j.l.Record is no longer required since it became standard.

-------------

Commit messages:
 - 8255904: Remove superfluous use of reflection in Class::isRecord

Changes: https://git.openjdk.java.net/jdk/pull/1406/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1406&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255904
  Stats: 11 lines in 1 file changed: 0 ins; 10 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1406.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1406/head:pull/1406

PR: https://git.openjdk.java.net/jdk/pull/1406

From redestad at openjdk.java.net  Tue Nov 24 10:29:56 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 24 Nov 2020 10:29:56 GMT
Subject: RFR: 8255904: Remove superfluous use of reflection in
 Class::isRecord
In-Reply-To: <G4d8RjYyOlsZcfOmgiz5uz0-Zr8E6crIv0OaCQd-DmU=.a787c6ab-a2f1-43cd-acd6-d585a9327dcd@github.com>
References: <G4d8RjYyOlsZcfOmgiz5uz0-Zr8E6crIv0OaCQd-DmU=.a787c6ab-a2f1-43cd-acd6-d585a9327dcd@github.com>
Message-ID: <HIelPyQR06d8snTvlayro7YyPwdcHMt3Pzm3MW_bvqw=.2d85f0d8-23f4-491f-8f60-698819fa3598@github.com>

On Tue, 24 Nov 2020 10:12:23 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Minor cleanup - Reflective access to j.l.Record is no longer required since it became standard.

Looks good!

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1406

From shade at openjdk.java.net  Tue Nov 24 10:32:59 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 24 Nov 2020 10:32:59 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v4]
In-Reply-To: <e_SXwbSkjWisuw2ebXg_tnyGN7xt4Cyh916GslGsbpw=.9f7fbb48-ff95-4b64-b928-477bbc1a4063@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <e_SXwbSkjWisuw2ebXg_tnyGN7xt4Cyh916GslGsbpw=.9f7fbb48-ff95-4b64-b928-477bbc1a4063@github.com>
Message-ID: <YYSO4XY3WrE4dLqybvTA0TBLkqQLyc2PemcNR3OQvLI=.48b9f57e-6124-4d64-bcec-93a327c107e2@github.com>

On Mon, 23 Nov 2020 20:36:11 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
>> 
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
>> 
>> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
>> 
>> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
>> 
>> Testing: `make images` on Linux and Windows x86_32 platforms.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use the Unimplemented() macro instead of hlt()

I have a few minor comments, in addition to what David is saying about `JNI_ENTRY_CPP_NOENV`.

src/hotspot/cpu/x86/macroAssembler_x86.cpp line 497:

> 495: void MacroAssembler::reset_last_Java_frame(bool clear_fp) {
> 496:   reset_last_Java_frame(r15_thread, clear_fp);
> 497: }

I see that before the Foreign Linker integration, this method was between `MacroAssembler::pushptr` and `MacroAssembler::set_last_Java_frame`. Please move it back there.

-------------

Changes requested by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1266

From alanb at openjdk.java.net  Tue Nov 24 10:34:57 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 Nov 2020 10:34:57 GMT
Subject: RFR: 8255904: Remove superfluous use of reflection in
 Class::isRecord
In-Reply-To: <G4d8RjYyOlsZcfOmgiz5uz0-Zr8E6crIv0OaCQd-DmU=.a787c6ab-a2f1-43cd-acd6-d585a9327dcd@github.com>
References: <G4d8RjYyOlsZcfOmgiz5uz0-Zr8E6crIv0OaCQd-DmU=.a787c6ab-a2f1-43cd-acd6-d585a9327dcd@github.com>
Message-ID: <n_2D7dRWU_Si5TdIi0gZyHSQhw2YerOf_BdmJD6O-TI=.05d87c20-8f0e-45fa-8cdb-dabcca516fe8@github.com>

On Tue, 24 Nov 2020 10:12:23 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Minor cleanup - Reflective access to j.l.Record is no longer required since it became standard.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1406

From jvernee at openjdk.java.net  Tue Nov 24 11:38:59 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 24 Nov 2020 11:38:59 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v4]
In-Reply-To: <szmJ4UCEhWIGnsgftI0aR9597EbXeOVCGB5-5yCxrdE=.503b2ff5-92f2-46bd-a3fb-4ab296a4f81d@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <e_SXwbSkjWisuw2ebXg_tnyGN7xt4Cyh916GslGsbpw=.9f7fbb48-ff95-4b64-b928-477bbc1a4063@github.com>
 <tKvsXc464T-GR0s0RP4emxENx2TDxW-8BX9_zU59iCo=.b3933400-9bfe-425a-95fb-3b659b7da8f9@github.com>
 <szmJ4UCEhWIGnsgftI0aR9597EbXeOVCGB5-5yCxrdE=.503b2ff5-92f2-46bd-a3fb-4ab296a4f81d@github.com>
Message-ID: <DjfrrM17I3RWuXmz5NQRhK1XahV5NBtBoHlk866Nn0w=.23087ed2-9e26-4596-84be-be1828fd2b50@github.com>

On Tue, 24 Nov 2020 06:12:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/prims/universalUpcallHandler.cpp line 36:
>> 
>>> 34: extern struct JavaVM_ main_vm;
>>> 35: 
>>> 36: JNI_ENTRY_CPP_NOENV(void, ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff))
>> 
>> I do not like this. I think you have a design flaw here. We should not be directly calling member functions like this from other native code! The entry point should be a simple C-linkage function that is a normal JNI_ENTRY (assuming it actually should be a JNI_ENTRY and not JVM_ENTRY?) and that can then call the true target.
>
> Looking closer at this and the potential call-chain I don't think this is really either a JNI_ENTRY nor a JVM_ENTRY as we would normally define them. The upcall_stub seems to allow a thread to "tunnel" its way into the VM for a Java call, rather than going through the normal exported interfaces (i.e. JNI). I suspect that earlier in the review process it was requested that this be made some kind of ENTRY but I'm really not sure that fits at all. It may be cleaner, simpler and clearer to just declare a non-exported method that use `ThreadInVMFromNative` directly.

Ok, that seems like a good idea to me as well.

Since this code is different from normal JNI/JVM entries, I'd rather add things like exception marks or vm entry traces as needed manually, than relying on the existing macros, so that the need for each item can be re-evaluated and explained in this context.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From alanb at openjdk.java.net  Tue Nov 24 11:39:02 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 Nov 2020 11:39:02 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v5]
In-Reply-To: <91KldHNqIOZI9hHedlD3QKW-EtpnRVP_116OqwUqmc4=.9d1f189d-2dda-42cb-b9d2-8b4d48ae279e@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
 <91KldHNqIOZI9hHedlD3QKW-EtpnRVP_116OqwUqmc4=.9d1f189d-2dda-42cb-b9d2-8b4d48ae279e@github.com>
Message-ID: <ACEFwRTuJB2b6UwvFkBa7N4VHP-I_EcD95ZbFO7wJyc=.3412482c-a8d4-4f64-9977-f32a9b28806a@github.com>

On Mon, 23 Nov 2020 23:14:11 GMT, Mark Reinhold <mr at openjdk.org> wrote:

>> Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396).
>> Alan Bateman is the original author; I?ve credited him in the commit metadata.
>> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64.
>
> Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert: Fix "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test
>   
>   This reverts commit 6a4d4792261f54b014336d1907b0040b15fdb467.

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1324

From david.holmes at oracle.com  Tue Nov 24 12:16:39 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Nov 2020 22:16:39 +1000
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>
 <bc550458-fea3-d543-1cd9-78f7192fe8ec@oracle.com>
 <96418b57-12fe-208e-c642-b04efeedca24@oracle.com>
 <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr>
Message-ID: <d428aa49-7a8c-bf14-8294-62239965d998@oracle.com>

Hi Remi,

On 24/11/2020 7:45 pm, Remi Forax wrote:
> ----- Mail original -----
>> De: "David Holmes" <david.holmes at oracle.com>
>> ?: "Harold David Seigel" <harold.seigel at oracle.com>, "Vicente Romero" <vromero at openjdk.java.net>, "compiler-dev"
>> <compiler-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev"
>> <hotspot-dev at openjdk.java.net>
>> Envoy?: Mardi 24 Novembre 2020 02:04:55
>> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)
> 
>> Hi Harold,
>>
>> On 24/11/2020 6:27 am, Harold Seigel wrote:
>>> Hi David,
>>>
>>> Thanks for looking at this.
>>>
>>> The intent was for method Class.permittedSubclasses() to be implemented
>>> similarly to Class.getNestMembers().? Are you suggesting that a security
>>> manager check be added to permittedSubclasses() similar to the security
>>> manager check in getNestMembers()?
>>
>> No I'm suggesting the change to the API is plain wrong. :) Please see
>> discussion in the CSR.
> 
> Given that the CSR is closed, i will answer here.
> There are two issues with the previous implementation of permittedSubclasses, first it's the only method that using method desc which means that people has to be aware on another non trivial concept (object that describes constant pool constant) to understand how to use the method then i've tested this API with my students, all but one what able to correctly derives the Class from a ClassDesc, so instead of asking every users of permittedSubclasses to go through the oops of getting Class from a ClassDesc, i think we can agree that it's better to move the burden from the user to the JDK implementors.

Why is the objective to get the Class objects? What purpose does that 
serve? The original API provided a descriptor for the contents of the 
permittedSubclasses attribute. I find it totally bizarre to have an API 
whose role is now to attempt to load all the subclasses of a sealed class.

YMMV.

David

>>
>> Cheers,
>> David
> 
> regards,
> R?mi
> 
>>
>>> Thanks, Harold
>>>
>>> On 11/18/2020 12:31 AM, David Holmes wrote:
>>>> Hi Vincente,
>>>>
>>>> On 16/11/2020 11:36 pm, Vicente Romero wrote:
>>>>> Please review the code for the second iteration of sealed classes. In
>>>>> this iteration we are:
>>>>>
>>>>> - Enhancing narrowing reference conversion to allow for stricter
>>>>> checking of cast conversions with respect to sealed type hierarchies.
>>>>> - Also local classes are not considered when determining implicitly
>>>>> declared permitted direct subclasses of a sealed class or sealed
>>>>> interface
>>>>
>>>> The major change here seems to be that getPermittedSubclasses() now
>>>> returns actual Class objects instead of ClassDesc. My recollection
>>>> from earlier discussions here was that the use of ClassDesc was very
>>>> deliberate as the permitted subclasses may not actually exist and
>>>> there may be security concerns with returning them!
>>>>
>>>> Cheers,
>>>> David
>>>> -----
>>>>
>>>>> -------------
>>>>>
>>>>> Commit messages:
>>>>>  ? - 8246778: Compiler implementation for Sealed Classes (Second Preview)
>>>>>
>>>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>>>>>  ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>>>>>  ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>>>>>  ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>>>>>  ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>>>>>  ?? Fetch: git fetch https://git.openjdk.java.net/jdk
>>>>> pull/1227/head:pull/1227
>>>>>
>>>>> PR: https://git.openjdk.java.net/jdk/pull/1227

From david.holmes at oracle.com  Tue Nov 24 12:35:21 2020
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 24 Nov 2020 22:35:21 +1000
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v4]
In-Reply-To: <DjfrrM17I3RWuXmz5NQRhK1XahV5NBtBoHlk866Nn0w=.23087ed2-9e26-4596-84be-be1828fd2b50@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <e_SXwbSkjWisuw2ebXg_tnyGN7xt4Cyh916GslGsbpw=.9f7fbb48-ff95-4b64-b928-477bbc1a4063@github.com>
 <tKvsXc464T-GR0s0RP4emxENx2TDxW-8BX9_zU59iCo=.b3933400-9bfe-425a-95fb-3b659b7da8f9@github.com>
 <szmJ4UCEhWIGnsgftI0aR9597EbXeOVCGB5-5yCxrdE=.503b2ff5-92f2-46bd-a3fb-4ab296a4f81d@github.com>
 <DjfrrM17I3RWuXmz5NQRhK1XahV5NBtBoHlk866Nn0w=.23087ed2-9e26-4596-84be-be1828fd2b50@github.com>
Message-ID: <826e0618-b8bc-9deb-c580-898d16ff8006@oracle.com>

On 24/11/2020 9:38 pm, Jorn Vernee wrote:
> On Tue, 24 Nov 2020 06:12:55 GMT, David Holmes <dholmes at openjdk.org> wrote:
> 
>>> src/hotspot/share/prims/universalUpcallHandler.cpp line 36:
>>>
>>>> 34: extern struct JavaVM_ main_vm;
>>>> 35:
>>>> 36: JNI_ENTRY_CPP_NOENV(void, ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff))
>>>
>>> I do not like this. I think you have a design flaw here. We should not be directly calling member functions like this from other native code! The entry point should be a simple C-linkage function that is a normal JNI_ENTRY (assuming it actually should be a JNI_ENTRY and not JVM_ENTRY?) and that can then call the true target.
>>
>> Looking closer at this and the potential call-chain I don't think this is really either a JNI_ENTRY nor a JVM_ENTRY as we would normally define them. The upcall_stub seems to allow a thread to "tunnel" its way into the VM for a Java call, rather than going through the normal exported interfaces (i.e. JNI). I suspect that earlier in the review process it was requested that this be made some kind of ENTRY but I'm really not sure that fits at all. It may be cleaner, simpler and clearer to just declare a non-exported method that use `ThreadInVMFromNative` directly.
> 
> Ok, that seems like a good idea to me as well.
> 
> Since this code is different from normal JNI/JVM entries, I'd rather add things like exception marks or vm entry traces as needed manually, than relying on the existing macros, so that the need for each item can be re-evaluated and explained in this context.

Glad you mentioned ExceptionMark! Exactly what is the design philosophy 
with respect to exceptions from the called Java method in this API? At 
present they are simply ignored. If the thread were then to make JNI 
calls that could break rules about not being able to call most JNI 
methods with a pending exception. If it makes another upcall does that 
immediately "abort" with the pending exception? If we have a case where 
the thread auto-detaches what happens then? Will it trigger the Thread 
uncaughtExceptionHandler?

David
-----

> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1266
> 

From jorn.vernee at oracle.com  Tue Nov 24 12:58:33 2020
From: jorn.vernee at oracle.com (Jorn Vernee)
Date: Tue, 24 Nov 2020 13:58:33 +0100
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v4]
In-Reply-To: <826e0618-b8bc-9deb-c580-898d16ff8006@oracle.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <e_SXwbSkjWisuw2ebXg_tnyGN7xt4Cyh916GslGsbpw=.9f7fbb48-ff95-4b64-b928-477bbc1a4063@github.com>
 <tKvsXc464T-GR0s0RP4emxENx2TDxW-8BX9_zU59iCo=.b3933400-9bfe-425a-95fb-3b659b7da8f9@github.com>
 <szmJ4UCEhWIGnsgftI0aR9597EbXeOVCGB5-5yCxrdE=.503b2ff5-92f2-46bd-a3fb-4ab296a4f81d@github.com>
 <DjfrrM17I3RWuXmz5NQRhK1XahV5NBtBoHlk866Nn0w=.23087ed2-9e26-4596-84be-be1828fd2b50@github.com>
 <826e0618-b8bc-9deb-c580-898d16ff8006@oracle.com>
Message-ID: <f8925d4b-9e2c-1fa5-8aa5-2ef7ea26bd27@oracle.com>

The main assumption is that calling code is fully foreign, and that it 
does not know how to Java handle exceptions at all.

So, if an exception is thrown at this point, we should probably just 
crash, and make it the callee's responsibility to handle exception if 
they need/want to.

Looking at this now, I think I'll switch the upcall itself to use CATCH, 
and then see what we can do on the Java side to crash in a more friendly 
way if there is an active exception when we return from the upcall (such 
as invoking the default uncaught exception handler).

How does that sound?

Jorn

On 24/11/2020 13:35, David Holmes wrote:
> On 24/11/2020 9:38 pm, Jorn Vernee wrote:
>> On Tue, 24 Nov 2020 06:12:55 GMT, David Holmes <dholmes at openjdk.org> 
>> wrote:
>>
>>>> src/hotspot/share/prims/universalUpcallHandler.cpp line 36:
>>>>
>>>>> 34: extern struct JavaVM_ main_vm;
>>>>> 35:
>>>>> 36: JNI_ENTRY_CPP_NOENV(void, 
>>>>> ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff))
>>>>
>>>> I do not like this. I think you have a design flaw here. We should 
>>>> not be directly calling member functions like this from other 
>>>> native code! The entry point should be a simple C-linkage function 
>>>> that is a normal JNI_ENTRY (assuming it actually should be a 
>>>> JNI_ENTRY and not JVM_ENTRY?) and that can then call the true target.
>>>
>>> Looking closer at this and the potential call-chain I don't think 
>>> this is really either a JNI_ENTRY nor a JVM_ENTRY as we would 
>>> normally define them. The upcall_stub seems to allow a thread to 
>>> "tunnel" its way into the VM for a Java call, rather than going 
>>> through the normal exported interfaces (i.e. JNI). I suspect that 
>>> earlier in the review process it was requested that this be made 
>>> some kind of ENTRY but I'm really not sure that fits at all. It may 
>>> be cleaner, simpler and clearer to just declare a non-exported 
>>> method that use `ThreadInVMFromNative` directly.
>>
>> Ok, that seems like a good idea to me as well.
>>
>> Since this code is different from normal JNI/JVM entries, I'd rather 
>> add things like exception marks or vm entry traces as needed 
>> manually, than relying on the existing macros, so that the need for 
>> each item can be re-evaluated and explained in this context.
>
> Glad you mentioned ExceptionMark! Exactly what is the design 
> philosophy with respect to exceptions from the called Java method in 
> this API? At present they are simply ignored. If the thread were then 
> to make JNI calls that could break rules about not being able to call 
> most JNI methods with a pending exception. If it makes another upcall 
> does that immediately "abort" with the pending exception? If we have a 
> case where the thread auto-detaches what happens then? Will it trigger 
> the Thread uncaughtExceptionHandler?
>
> David
> -----
>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/1266
>>

From jvernee at openjdk.java.net  Tue Nov 24 13:21:08 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 24 Nov 2020 13:21:08 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v5]
In-Reply-To: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
Message-ID: <xf_PsOwuLms3n8xuwqPWCJozgUMhrGRPASs1-qFZe3E=.a3af93dc-4ec5-470b-abed-c5f45dd6911d@github.com>

> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
> 
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
> 
> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
> 
> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
> 
> Testing: `make images` on Linux and Windows x86_32 platforms.

Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:

 - Remove JNI_ENTRY_CPP_NOENV
 - - Move reset_last_Java_frame

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1266/files
  - new: https://git.openjdk.java.net/jdk/pull/1266/files/4f0c6ef9..6ea9b3e3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=03-04

  Stats: 26 lines in 3 files changed: 6 ins; 13 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1266.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266

PR: https://git.openjdk.java.net/jdk/pull/1266

From mcimadamore at openjdk.java.net  Tue Nov 24 13:21:09 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 Nov 2020 13:21:09 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v4]
In-Reply-To: <YYSO4XY3WrE4dLqybvTA0TBLkqQLyc2PemcNR3OQvLI=.48b9f57e-6124-4d64-bcec-93a327c107e2@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <e_SXwbSkjWisuw2ebXg_tnyGN7xt4Cyh916GslGsbpw=.9f7fbb48-ff95-4b64-b928-477bbc1a4063@github.com>
 <YYSO4XY3WrE4dLqybvTA0TBLkqQLyc2PemcNR3OQvLI=.48b9f57e-6124-4d64-bcec-93a327c107e2@github.com>
Message-ID: <a7Byiz44WC6pskvSoFK-r9Z2rQtmK-KQ3epGWFtY96s=.eaf32bc1-b713-48b5-8acc-2e8f2b46ca41@github.com>

On Tue, 24 Nov 2020 10:30:33 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use the Unimplemented() macro instead of hlt()
>
> I have a few minor comments, in addition to what David is saying about `JNI_ENTRY_CPP_NOENV`.

> Glad you mentioned ExceptionMark! Exactly what is the design philosophy
> with respect to exceptions from the called Java method in this API? At
> present they are simply ignored. If the thread were then to make JNI
> calls that could break rules about not being able to call most JNI
> methods with a pending exception. If it makes another upcall does that
> immediately "abort" with the pending exception? If we have a case where
> the thread auto-detaches what happens then? Will it trigger the Thread
> uncaughtExceptionHandler?

This is a very good point David - if an exception is issued during an upcall, there's not a lot we can do on native side to recover. We have plans here (Jorn suggested to just wrap the upcall method handle in a "catch-all" which catches all exceptions and then just exits the VM). But, at the same time, I'd like to "steer" the discussion in this PR towards the stated goal of the PR - namely, fix build issues in x86.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From jvernee at openjdk.java.net  Tue Nov 24 13:35:17 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 24 Nov 2020 13:35:17 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v6]
In-Reply-To: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
Message-ID: <8t9K2ZBTJu1RRsWncao3E7LHxKYnOvfwC2GigKsel1g=.970833fb-2560-4a13-9984-9082c4b40157@github.com>

> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
> 
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
> 
> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
> 
> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
> 
> Testing: `make images` on Linux and Windows x86_32 platforms.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge branch 'master' into Linker_32bit-fixes_Simpler
 - Remove JNI_ENTRY_CPP_NOENV
 - - Move reset_last_Java_frame
 - Use the Unimplemented() macro instead of hlt()
 - Merge branch 'master' into Linker_32bit-fixes_Simpler
 - Remove UnsupportedPlatform test
 - Remove unneeded cast
 - Remove Stuff that makes the jdk_foreign tests pass
 - fix test warnings
 - - Fix 32-bit build errors and tests
   - Add negative test for 32-bit platform.
   - Change CABI to fail more lazily when running on an unsupported platform.
   - Change CLinker layouts to be null on unsupported platforms, instead of failing when initializing the class
   - Added note to CLinker about failure to initialize on unsupported platforms

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1266/files
  - new: https://git.openjdk.java.net/jdk/pull/1266/files/6ea9b3e3..960021ba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=04-05

  Stats: 2931 lines in 100 files changed: 1501 ins; 855 del; 575 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1266.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266

PR: https://git.openjdk.java.net/jdk/pull/1266

From shade at openjdk.java.net  Tue Nov 24 13:35:18 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Tue, 24 Nov 2020 13:35:18 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v5]
In-Reply-To: <xf_PsOwuLms3n8xuwqPWCJozgUMhrGRPASs1-qFZe3E=.a3af93dc-4ec5-470b-abed-c5f45dd6911d@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <xf_PsOwuLms3n8xuwqPWCJozgUMhrGRPASs1-qFZe3E=.a3af93dc-4ec5-470b-abed-c5f45dd6911d@github.com>
Message-ID: <SS5bJOgrhfpaIMvG19YY3vzMwDl711wZBsw_T_XFp30=.f6bb784e-771f-4ce1-9961-eafa2481454a@github.com>

On Tue, 24 Nov 2020 13:21:08 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
>> 
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
>> 
>> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
>> 
>> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
>> 
>> Testing: `make images` on Linux and Windows x86_32 platforms.
>
> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove JNI_ENTRY_CPP_NOENV
>  - - Move reset_last_Java_frame

This looks fine to me. PIty to see `CATCH` on the exception recovery path, but that seems okay for the incubating code.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1266

From forax at univ-mlv.fr  Tue Nov 24 13:56:22 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 24 Nov 2020 14:56:22 +0100 (CET)
Subject: RFR: 8246778: Compiler implementation for Sealed Classes
 (Second Preview)
In-Reply-To: <d428aa49-7a8c-bf14-8294-62239965d998@oracle.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>
 <bc550458-fea3-d543-1cd9-78f7192fe8ec@oracle.com>
 <96418b57-12fe-208e-c642-b04efeedca24@oracle.com>
 <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr>
 <d428aa49-7a8c-bf14-8294-62239965d998@oracle.com>
Message-ID: <555245742.1403793.1606226182119.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "David Holmes" <david.holmes at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Harold David Seigel" <harold.seigel at oracle.com>, "Vicente Romero" <vromero at openjdk.java.net>, "compiler-dev"
> <compiler-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev"
> <hotspot-dev at openjdk.java.net>
> Envoy?: Mardi 24 Novembre 2020 13:16:39
> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

> Hi Remi,
> 
> On 24/11/2020 7:45 pm, Remi Forax wrote:
>> ----- Mail original -----
>>> De: "David Holmes" <david.holmes at oracle.com>
>>> ?: "Harold David Seigel" <harold.seigel at oracle.com>, "Vicente Romero"
>>> <vromero at openjdk.java.net>, "compiler-dev"
>>> <compiler-dev at openjdk.java.net>, "core-libs-dev"
>>> <core-libs-dev at openjdk.java.net>, "hotspot-dev"
>>> <hotspot-dev at openjdk.java.net>
>>> Envoy?: Mardi 24 Novembre 2020 02:04:55
>>> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second
>>> Preview)
>> 
>>> Hi Harold,
>>>
>>> On 24/11/2020 6:27 am, Harold Seigel wrote:
>>>> Hi David,
>>>>
>>>> Thanks for looking at this.
>>>>
>>>> The intent was for method Class.permittedSubclasses() to be implemented
>>>> similarly to Class.getNestMembers().? Are you suggesting that a security
>>>> manager check be added to permittedSubclasses() similar to the security
>>>> manager check in getNestMembers()?
>>>
>>> No I'm suggesting the change to the API is plain wrong. :) Please see
>>> discussion in the CSR.
>> 
>> Given that the CSR is closed, i will answer here.
>> There are two issues with the previous implementation of permittedSubclasses,
>> first it's the only method that using method desc which means that people has
>> to be aware on another non trivial concept (object that describes constant pool
>> constant) to understand how to use the method then i've tested this API with my
>> students, all but one what able to correctly derives the Class from a
>> ClassDesc, so instead of asking every users of permittedSubclasses to go
>> through the oops of getting Class from a ClassDesc, i think we can agree that
>> it's better to move the burden from the user to the JDK implementors.
> 
> Why is the objective to get the Class objects? What purpose does that
> serve?

The whole idea of the reflection is to provide the runtime view of Java the language.
Even if such thing does not exist.

> The original API provided a descriptor for the contents of the
> permittedSubclasses attribute. I find it totally bizarre to have an API
> whose role is now to attempt to load all the subclasses of a sealed class.

It's as bizarre as Class.getClasses() loading all the member classes.

You are discovering that the reflection API is bizarre, and it is :)
It's not the view of the JVM, it's the view of Java at runtime, whatever it means.

> 
> YMMV.
> 
> David

R?mi

[1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Class.html#getClasses()

> 
>>>
>>> Cheers,
>>> David
>> 
>> regards,
>> R?mi
>> 
>>>
>>>> Thanks, Harold
>>>>
>>>> On 11/18/2020 12:31 AM, David Holmes wrote:
>>>>> Hi Vincente,
>>>>>
>>>>> On 16/11/2020 11:36 pm, Vicente Romero wrote:
>>>>>> Please review the code for the second iteration of sealed classes. In
>>>>>> this iteration we are:
>>>>>>
>>>>>> - Enhancing narrowing reference conversion to allow for stricter
>>>>>> checking of cast conversions with respect to sealed type hierarchies.
>>>>>> - Also local classes are not considered when determining implicitly
>>>>>> declared permitted direct subclasses of a sealed class or sealed
>>>>>> interface
>>>>>
>>>>> The major change here seems to be that getPermittedSubclasses() now
>>>>> returns actual Class objects instead of ClassDesc. My recollection
>>>>> from earlier discussions here was that the use of ClassDesc was very
>>>>> deliberate as the permitted subclasses may not actually exist and
>>>>> there may be security concerns with returning them!
>>>>>
>>>>> Cheers,
>>>>> David
>>>>> -----
>>>>>
>>>>>> -------------
>>>>>>
>>>>>> Commit messages:
>>>>>>  ? - 8246778: Compiler implementation for Sealed Classes (Second Preview)
>>>>>>
>>>>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>>>>>>  ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>>>>>>  ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>>>>>>  ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>>>>>>  ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>>>>>>  ?? Fetch: git fetch https://git.openjdk.java.net/jdk
>>>>>> pull/1227/head:pull/1227
>>>>>>
> >>>>> PR: https://git.openjdk.java.net/jdk/pull/1227

From jvernee at openjdk.java.net  Tue Nov 24 14:01:57 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Tue, 24 Nov 2020 14:01:57 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v5]
In-Reply-To: <SS5bJOgrhfpaIMvG19YY3vzMwDl711wZBsw_T_XFp30=.f6bb784e-771f-4ce1-9961-eafa2481454a@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <xf_PsOwuLms3n8xuwqPWCJozgUMhrGRPASs1-qFZe3E=.a3af93dc-4ec5-470b-abed-c5f45dd6911d@github.com>
 <SS5bJOgrhfpaIMvG19YY3vzMwDl711wZBsw_T_XFp30=.f6bb784e-771f-4ce1-9961-eafa2481454a@github.com>
Message-ID: <STtxW0KZ0tymb7kJoLVhlSGwemzFgxEXCGL3zWCp5gE=.720634c8-aa83-47d9-8a9f-044ac9d3caf4@github.com>

On Tue, 24 Nov 2020 13:31:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove JNI_ENTRY_CPP_NOENV
>>  - - Move reset_last_Java_frame
>
> This looks fine to me. PIty to see `CATCH` on the exception recovery path, but that seems okay for the incubating code.

Discussing this with Maurizio as well; FWIW, after we change the Java code that gets called, to handle all exceptions, the CATCH should never trigger. It will just be there as a sanity check.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From herrick at openjdk.java.net  Tue Nov 24 14:54:00 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 24 Nov 2020 14:54:00 GMT
Subject: RFR: JDK-8256475: Fix Behavior when Installer name differs from
 application name. [v4]
In-Reply-To: <_cGN0GOe3e_i20J4Phx1QfVL01ZhOX1mFmwDY6CVN5I=.ac3e7ce8-697f-4f4c-bd8f-a75991536007@github.com>
References: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
 <25b-I2aVPI49KXdos4hcWbUtza3gOoMjrxAd49ca_P4=.ee575d41-5cf4-407f-add1-cdfbe220bdaa@github.com>
 <_cGN0GOe3e_i20J4Phx1QfVL01ZhOX1mFmwDY6CVN5I=.ac3e7ce8-697f-4f4c-bd8f-a75991536007@github.com>
Message-ID: <XtclbiUx-ffdR3gbjdD1VpMFKguvoHBNWR_M9NL-kCs=.52f1ab26-9b31-4a74-9724-16c22e10a2b3@github.com>

On Tue, 24 Nov 2020 03:38:01 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> Andy Herrick has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8256475: Fix Behavior when Installer name differs from application name.
>
> src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources_zh_CN.properties line 75:
> 
>> 73: error.jlink.failed=jlink \u5931\u8D25\uFF0C\u51FA\u73B0 {0}
>> 74: error.blocked.option=\u4E0D\u5141\u8BB8\u5728 --jlink-options \u4E2D\u4F7F\u7528 jlink \u9009\u9879 [{0}]
>> 75: error.no.name=Name not specified with --name and cannot infer one from app-image
> 
> Do we need to submit a follow-up bug for localization team that we have new non-localized messages in the region specific properties file? I see that foreign app image warning is still not localized.

Localization team will translate all changed messages together without individual follow-up bugs, as long as changed before the "localization freeze"

-------------

PR: https://git.openjdk.java.net/jdk/pull/1300

From herrick at openjdk.java.net  Tue Nov 24 14:58:59 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 24 Nov 2020 14:58:59 GMT
Subject: Integrated: JDK-8256475: Fix Behavior when Installer name differs
 from application name.
In-Reply-To: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
References: <CZiWuy8fdvLLwfdqdZSCftE-phMs7s4tvq_NFOxhj9o=.daee3965-e5c2-4846-a3b7-4755ba531bb9@github.com>
Message-ID: <w76ag_v1NUf9bJ8sjTVrbNbnul9w1ax0oKQS8JT-Y4Q=.08839ecc-4c1f-449d-8110-eee5bdf901e3@github.com>

On Wed, 18 Nov 2020 22:17:07 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> ?n name.

This pull request has now been integrated.

Changeset: 303631e3
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/303631e3
Stats:     216 lines in 18 files changed: 176 ins; 13 del; 27 mod

8256475: Fix Behavior when Installer name differs from application name.

Reviewed-by: asemenyuk, almatvee, kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/1300

From herrick at openjdk.java.net  Tue Nov 24 15:01:59 2020
From: herrick at openjdk.java.net (Andy Herrick)
Date: Tue, 24 Nov 2020 15:01:59 GMT
Subject: Integrated: JDK-8256801:
 tools/jpackage/share/FileAssociationsTest.java#id0 failed unpack.bat with
 "Exit code: 1603"
In-Reply-To: <zU5XvnAxrcywVrCzbiIN4vqoBlpWUB88xK4rMNBo_OM=.8c2e7c66-9040-4102-af67-9da3e5c84506@github.com>
References: <zU5XvnAxrcywVrCzbiIN4vqoBlpWUB88xK4rMNBo_OM=.8c2e7c66-9040-4102-af67-9da3e5c84506@github.com>
Message-ID: <fhbjg3LTZvUmu7j_tORjuhmq_pJMjbH83iCuP7wt9oQ=.07fe0b52-5a26-4957-ae21-b8a0b1ac47d3@github.com>

On Mon, 23 Nov 2020 20:16:58 GMT, Andy Herrick <herrick at openjdk.org> wrote:

> When executing msiexec (possibly from batch script) retry on exitCode 1603 as well as 1618

This pull request has now been integrated.

Changeset: ff6df15b
Author:    Andy Herrick <herrick at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/ff6df15b
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8256801: tools/jpackage/share/FileAssociationsTest.java#id0 failed unpack.bat with "Exit code: 1603"

Reviewed-by: asemenyuk, almatvee, kizune

-------------

PR: https://git.openjdk.java.net/jdk/pull/1400

From mcimadamore at openjdk.java.net  Tue Nov 24 15:10:10 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 Nov 2020 15:10:10 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks [v3]
In-Reply-To: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
Message-ID: <9d9pHGcQQtFnDcAx2gdi5NKjN3OQCisUXlhEe-ecpXc=.f0434820-db00-4195-ad18-b35c6f9a7291@github.com>

> Both the Foreign Memory Access and the Foreign Linker APIs leave something to be desired when it comes to handling NPEs - first, most of the API javadoc is oblivious to NPEs being thrown. Secondly, not all API method implementations add expicit NPE checks - with the result of NPE often being thrown very deep in the call chain - if at all. Third, test for API coverage of nulls is ad-hoc.
> 
> This patch rectifies all these issues. To increase coverage for null injected into APIs, this patch introduces a new framework for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> I've also added, as part of this patch, a test to cover the statics in MemoryAccess which were not covered throughly.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix unused import

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1388/files
  - new: https://git.openjdk.java.net/jdk/pull/1388/files/4565f777..54d5e148

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1388&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1388&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1388.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1388/head:pull/1388

PR: https://git.openjdk.java.net/jdk/pull/1388

From mcimadamore at openjdk.java.net  Tue Nov 24 15:41:10 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 Nov 2020 15:41:10 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks [v4]
In-Reply-To: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
Message-ID: <ueaYWzzjPqrYKJS4OMak6VBbvDOci8PtCUwTWrCx-wI=.337f4a47-9c7f-420d-82b4-5eeeb240511a@github.com>

> Both the Foreign Memory Access and the Foreign Linker APIs leave something to be desired when it comes to handling NPEs - first, most of the API javadoc is oblivious to NPEs being thrown. Secondly, not all API method implementations add expicit NPE checks - with the result of NPE often being thrown very deep in the call chain - if at all. Third, test for API coverage of nulls is ad-hoc.
> 
> This patch rectifies all these issues. To increase coverage for null injected into APIs, this patch introduces a new framework for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> I've also added, as part of this patch, a test to cover the statics in MemoryAccess which were not covered throughly.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Add coarser-grained statements abut NPE handling at the class level.
  Add test support for LibraryLookup.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1388/files
  - new: https://git.openjdk.java.net/jdk/pull/1388/files/54d5e148..bbdff9fb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1388&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1388&range=02-03

  Stats: 241 lines in 16 files changed: 54 ins; 185 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1388.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1388/head:pull/1388

PR: https://git.openjdk.java.net/jdk/pull/1388

From mcimadamore at openjdk.java.net  Tue Nov 24 15:41:11 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 Nov 2020 15:41:11 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks [v2]
In-Reply-To: <1IOerFa7b3SayGj8WYO37zkS64NCGRuFIDZKK16nu0s=.e91f2bea-8005-471b-a0e4-f11d51c1aceb@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
 <IIqvoh6QQKNC_z78X3X3dhccSBl84cnDjWechUuUf-E=.6159de5c-b255-42f1-811b-03c605d01aa3@github.com>
 <1IOerFa7b3SayGj8WYO37zkS64NCGRuFIDZKK16nu0s=.e91f2bea-8005-471b-a0e4-f11d51c1aceb@github.com>
Message-ID: <s_lwefIem504sBG8ew5OlhQkV4WwXk2m0gm2jtHNwGs=.a02d6acd-db64-4c17-847d-407da00dc557@github.com>

On Tue, 24 Nov 2020 09:34:09 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix cut/paste error in FunctionDescriptor
>
> Marked as reviewed by chegar (Reviewer).

Following @dholmes-ora  suggestion and also @jddarcy (in CSR review), I've uploaded a new iteration which instead of adding a `@throws` tag at every method, adds a general statement on each class which gets the treatment. I think specifying at package-level seems a bit too loose, so I went for per-class basis.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1388

From mcimadamore at openjdk.java.net  Tue Nov 24 15:49:11 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 Nov 2020 15:49:11 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks [v5]
In-Reply-To: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
Message-ID: <2xoHdwl4a-UZ_RcsaSKU7Ovsy70dhPgF39IEIj2VQvc=.e4d08726-bded-4e27-952b-3bf035af2f32@github.com>

> Both the Foreign Memory Access and the Foreign Linker APIs leave something to be desired when it comes to handling NPEs - first, most of the API javadoc is oblivious to NPEs being thrown. Secondly, not all API method implementations add expicit NPE checks - with the result of NPE often being thrown very deep in the call chain - if at all. Third, test for API coverage of nulls is ad-hoc.
> 
> This patch rectifies all these issues. To increase coverage for null injected into APIs, this patch introduces a new framework for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> I've also added, as part of this patch, a test to cover the statics in MemoryAccess which were not covered throughly.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix spurious typos caused by bulk removal of @throws tag

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1388/files
  - new: https://git.openjdk.java.net/jdk/pull/1388/files/bbdff9fb..19a77d9f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1388&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1388&range=03-04

  Stats: 11 lines in 4 files changed: 0 ins; 10 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1388.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1388/head:pull/1388

PR: https://git.openjdk.java.net/jdk/pull/1388

From mcimadamore at openjdk.java.net  Tue Nov 24 15:54:11 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 Nov 2020 15:54:11 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks [v6]
In-Reply-To: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
Message-ID: <rcuaXF2ZKzcZqd_UFfFmCcpIyXd_2XeO_M8L0Z0iVpE=.305b2834-c8bf-49b7-b2b9-446a199bd1d1@github.com>

> Both the Foreign Memory Access and the Foreign Linker APIs leave something to be desired when it comes to handling NPEs - first, most of the API javadoc is oblivious to NPEs being thrown. Secondly, not all API method implementations add expicit NPE checks - with the result of NPE often being thrown very deep in the call chain - if at all. Third, test for API coverage of nulls is ad-hoc.
> 
> This patch rectifies all these issues. To increase coverage for null injected into APIs, this patch introduces a new framework for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> I've also added, as part of this patch, a test to cover the statics in MemoryAccess which were not covered throughly.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix use of star import in LibrariesHelper

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1388/files
  - new: https://git.openjdk.java.net/jdk/pull/1388/files/19a77d9f..6c25c739

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1388&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1388&range=04-05

  Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1388.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1388/head:pull/1388

PR: https://git.openjdk.java.net/jdk/pull/1388

From jfranck at openjdk.java.net  Tue Nov 24 16:00:12 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Tue, 24 Nov 2020 16:00:12 GMT
Subject: RFR: 8256693: getAnnotatedReceiverType parameterizes types too eagerly
Message-ID: <zs785BGvPByMHgja-uOZKD-NFsZn_iHcXa6lyb3YmAE=.7f512858-303b-429a-bd4d-704305bdd024@github.com>

The fix for JDK-8256693 too often produces a ParameterizedType as the result of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary when this type or any of its transitive owner types has type parameters, but should be avoided if this isn't the case.

This implementation recursively creates a chain of ParameterizedTypes starting from the outermost type that has type parameters.

-------------

Commit messages:
 - 8256693: getAnnotatedReceiverType parameterizes types too eagerly

Changes: https://git.openjdk.java.net/jdk/pull/1414/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1414&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256693
  Stats: 112 lines in 3 files changed: 87 ins; 20 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1414.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1414/head:pull/1414

PR: https://git.openjdk.java.net/jdk/pull/1414

From jfranck at openjdk.java.net  Tue Nov 24 16:00:13 2020
From: jfranck at openjdk.java.net (Joel =?UTF-8?B?Qm9yZ2dyw6luLUZyYW5jaw==?=)
Date: Tue, 24 Nov 2020 16:00:13 GMT
Subject: RFR: 8256693: getAnnotatedReceiverType parameterizes types too
 eagerly
In-Reply-To: <zs785BGvPByMHgja-uOZKD-NFsZn_iHcXa6lyb3YmAE=.7f512858-303b-429a-bd4d-704305bdd024@github.com>
References: <zs785BGvPByMHgja-uOZKD-NFsZn_iHcXa6lyb3YmAE=.7f512858-303b-429a-bd4d-704305bdd024@github.com>
Message-ID: <c812KhJUpMp2O477vXOQYZym1r-ASXI8A8AfVWSIvwc=.f2941183-bb4f-46a3-aedf-a153d370b882@github.com>

On Tue, 24 Nov 2020 15:54:47 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

> The fix for JDK-8256693 too often produces a ParameterizedType as the result of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary when this type or any of its transitive owner types has type parameters, but should be avoided if this isn't the case.
> 
> This implementation recursively creates a chain of ParameterizedTypes starting from the outermost type that has type parameters.

@raphw can you take a look at this?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1414

From mcimadamore at openjdk.java.net  Tue Nov 24 16:01:15 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 Nov 2020 16:01:15 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks [v7]
In-Reply-To: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
Message-ID: <QkyOFcQuVvhS1IYK5690pFjWBI2coK3theDV1WUJxU0=.f53ae4b6-0224-4599-baec-9ba75aa7ff9b@github.com>

> Both the Foreign Memory Access and the Foreign Linker APIs leave something to be desired when it comes to handling NPEs - first, most of the API javadoc is oblivious to NPEs being thrown. Secondly, not all API method implementations add expicit NPE checks - with the result of NPE often being thrown very deep in the call chain - if at all. Third, test for API coverage of nulls is ad-hoc.
> 
> This patch rectifies all these issues. To increase coverage for null injected into APIs, this patch introduces a new framework for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> I've also added, as part of this patch, a test to cover the statics in MemoryAccess which were not covered throughly.

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Fix another typo caused by bulk replace

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1388/files
  - new: https://git.openjdk.java.net/jdk/pull/1388/files/6c25c739..40c2d20e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1388&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1388&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1388.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1388/head:pull/1388

PR: https://git.openjdk.java.net/jdk/pull/1388

From mcimadamore at openjdk.java.net  Tue Nov 24 16:03:58 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 24 Nov 2020 16:03:58 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks [v2]
In-Reply-To: <s_lwefIem504sBG8ew5OlhQkV4WwXk2m0gm2jtHNwGs=.a02d6acd-db64-4c17-847d-407da00dc557@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
 <IIqvoh6QQKNC_z78X3X3dhccSBl84cnDjWechUuUf-E=.6159de5c-b255-42f1-811b-03c605d01aa3@github.com>
 <1IOerFa7b3SayGj8WYO37zkS64NCGRuFIDZKK16nu0s=.e91f2bea-8005-471b-a0e4-f11d51c1aceb@github.com>
 <s_lwefIem504sBG8ew5OlhQkV4WwXk2m0gm2jtHNwGs=.a02d6acd-db64-4c17-847d-407da00dc557@github.com>
Message-ID: <5juAFe7nkVo_BCE0SOlIcA-E2LugDXcw__FIYxUsv_A=.841ff257-4c24-4bd2-9ceb-3cbee2f02f9c@github.com>

On Tue, 24 Nov 2020 15:38:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Marked as reviewed by chegar (Reviewer).
>
> Following @dholmes-ora  suggestion and also @jddarcy (in CSR review), I've uploaded a new iteration which instead of adding a `@throws` tag at every method, adds a general statement on each class which gets the treatment. I think specifying at package-level seems a bit too loose, so I went for per-class basis.

specdiff: http://cr.openjdk.java.net/~mcimadamore/8256865_v2/specdiff_out/overview-summary.html
javadoc: http://cr.openjdk.java.net/~mcimadamore/8256865_v2/javadoc

-------------

PR: https://git.openjdk.java.net/jdk/pull/1388

From rriggs at openjdk.java.net  Tue Nov 24 17:06:56 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Tue, 24 Nov 2020 17:06:56 GMT
Subject: Integrated: 8256480: Refactor ObjectInputStream field reader
 implementation
In-Reply-To: <57N_l5oDQywDYUYK-EH1Odb00ipNZxHTNg_NSzfx2Ww=.d11b14a5-8b9c-421e-a92d-cac8462b0f8e@github.com>
References: <57N_l5oDQywDYUYK-EH1Odb00ipNZxHTNg_NSzfx2Ww=.d11b14a5-8b9c-421e-a92d-cac8462b0f8e@github.com>
Message-ID: <MzBf_iKKGEn_kHuggCnFCc9hSNhaEC7xs1aemf1Ia9I=.a2dd5bf3-1760-48c9-ac7f-883194e24b98@github.com>

On Wed, 18 Nov 2020 17:32:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> ObjectInputStream has nearly identical but separate implementations to read values from the stream.
> Both implementations read primitive and object values from the stream and return an object holding the values.
> OIS.readFields() uses the internal class GetFieldImpl while OIS.defaultReadObject and reading records uses the internal class FieldValues.
> The behavioral difference between the two is whether dependencies are tracked in the object handle table or not. 
> 
> The classes are merged, retaining the internal FieldValues name and the behavior to track dependencies or not. 
> The constructor is passed the class descriptor and flag to track or not; it reads and saves the values from the stream.
> The callers are updated to call the merge FieldValues methods.
> 
> There is no change in behavior; all current tests pass.

This pull request has now been integrated.

Changeset: bd14274b
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/bd14274b
Stats:     157 lines in 1 file changed: 28 ins; 76 del; 53 mod

8256480: Refactor ObjectInputStream field reader implementation

Reviewed-by: bchristi

-------------

PR: https://git.openjdk.java.net/jdk/pull/1296

From mchung at openjdk.java.net  Tue Nov 24 18:48:07 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 24 Nov 2020 18:48:07 GMT
Subject: RFR: 8256993: Clarify Package::isSealed javadoc about package sealing
 vs sealed class or interface
Message-ID: <AiM8bDunBZDBnRtw3AZlzAFfTh2QjrPITS0ddAHwNs8=.ea384187-33cf-4047-9169-82be7a2a89f2@github.com>

This adds API note in `Package::isSealed` javadoc to clarify package sealing vs sealed class or interface.   Since it's spec clarification, CSR is not strictly needed.

-------------

Commit messages:
 - make it api Note
 - 8256993: Clarify Package::isSealed javadoc about package sealing vs sealed class or interface

Changes: https://git.openjdk.java.net/jdk/pull/1419/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1419&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256993
  Stats: 16 lines in 1 file changed: 15 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1419.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1419/head:pull/1419

PR: https://git.openjdk.java.net/jdk/pull/1419

From mchung at openjdk.java.net  Tue Nov 24 18:49:12 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 24 Nov 2020 18:49:12 GMT
Subject: RFR: 8230501: Class data support for hidden classes [v6]
In-Reply-To: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
References: <v2Qa_UUySQ9XeDWh7Aa6bVvmPZbfQCpQtiKJojNVq1w=.b06b2278-b314-4078-bfac-f79133c978a9@github.com>
Message-ID: <DBqIVzzVAi0TP6cycQGKI7PiYGAMWZBVEwmAuCo-MOo=.fa67c535-3f1f-48c3-b942-1e5867879997@github.com>

> Provide the `Lookup::defineHiddenClassWithClassData` API that allows live objects
> be shared between a hidden class and other classes.  A hidden class can load
> these live objects as dynamically-computed constants via this API.
> 
> Specdiff
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8230501/specdiff/overview-summary.html
> 
> With this class data support and hidden classes, `sun.misc.Unsafe::defineAnonymousClass`
> will be deprecated for removal.  Existing libraries should replace their
> calls to `sun.misc.Unsafe::defineAnonymousClass` with `Lookup::defineHiddenClass`
> or `Lookup::defineHiddenClassWithClassData`.
> 
> This patch also updates the implementation of lambda meta factory and
> `MemoryAccessVarHandleGenerator` to use class data.   No performance difference
> observed in the jdk.incubator.foreign microbenchmarks.   A side note: 
> `MemoryAccessVarHandleGenerator` is removed in the upcoming integration of 
> JDK-8254162 but it helps validating the class data support.
> 
> Background
> ----------
> 
> This is an enhancement following up JEP 371: Hidden Classes w.r.t.
> "Constant-pool patching" in the "Risks and Assumption" section.
> 
> A VM-anonymous class can be defined with its constant-pool entries already
> resolved to concrete values. This allows critical constants to be shared
> between a VM-anonymous class and the language runtime that defines it, and
> between multiple VM-anonymous classes. For example, a language runtime will
> often have `MethodHandle` objects in its address space that would be useful
> to newly-defined VM-anonymous classes. Instead of the runtime serializing
> the objects to constant-pool entries in VM-anonymous classes and then
> generating bytecode in those classes to laboriously `ldc` the entries,
> the runtime can simply supply `Unsafe::defineAnonymousClass` with references
> to its live objects. The relevant constant-pool entries in the newly-defined
> VM-anonymous class are pre-linked to those objects, improving performance
> and reducing footprint. In addition, this allows VM-anonymous classes to
> refer to each other: Constant-pool entries in a class file are based on names.
> They thus cannot refer to nameless VM-anonymous classes. A language runtime can,
> however, easily track the live Class objects for its VM-anonymous classes and
> supply them to `Unsafe::defineAnonymousClass`, thus pre-linking the new class's
> constant pool entries to other VM-anonymous classes.
> 
> This extends the hidden classes to allow live objects to be injected
> in a hidden class and loaded them via condy.
> 
> Details
> -------
> 
> A new `Lookup::defineHiddenClassWithClassData` API takes additional
> `classData` argument compared to `Lookup::defineHiddenClass`.
> Class data can be method handles, lookup objects, arbitrary user objects
> or collections of all of the above.
> 
> This method behaves as if calling `Lookup::defineHiddenClass` to define
> a hidden class with a private static unnamed field that is initialized
> with `classData` at the first instruction of the class initializer.
> 
> `MethodHandles::classData(Lookup lookup, String name, Class<?> type)` and
> `MethodHandles::classDataAt(Lookup lookup, String name, Class<?> type, int index)`
> are the bootstrap methods to load the class data of the given lookup's lookup class.
> The hidden class will be initialized when `classData` method is called if
> the hidden class has not been initialized.
> 
> For a class data containing more than one single element, libraries can
> create their convenience method to load a single live object via condy.
> 
> Frameworks sometimes want to dynamically create a hidden class (HC) and add it
> it the lookup class nest and have HC to carry secrets hidden from that nest.
> In this case, frameworks should not to use private static finals (in the HCs
> they spin) to hold secrets because a nestmate of HC may obtain access to
> such a private static final and observe the framework's secret.  It should use
> condy.  In addition, we need to differentiate if a lookup object is created from
> the original lookup class or created from teleporting e.g. `Lookup::in`
> and `MethodHandles::privateLookupIn`.
> 
> This proposes to add a new `ORIGINAL` bit that is only set if the lookup
> object is created by `MethodHandles::lookup` or by bootstrap method invocation.
> The operations only apply to a Lookup object with original access are:
>    - create method handles for caller-sensitve methods
>    - obtain class data associated with the lookup class
> 
> No change to `Lookup::hasFullPrivilegeAccess` and `Lookup::toString` which
> ignores the ORIGINAL bit.
> 
> 
> Compatibility Risks
> -------------------
> 
> `Lookup::lookupModes` includes a new `ORIGINAL` bit.  Most lookup operations
> ignore this original bit except creating method handles for caller-sensitive methods
> that expects the lookup from the original lookup class.  Existing code  compares
> the return value of `lookupModes` to be a fixed value may be impacted.   However
> existing client has no need to expect a fixed value of lookup modes.
> The incompatibility risk of this spec change is low.

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  clarify lookup modes of the returned Lookup object

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1171/files
  - new: https://git.openjdk.java.net/jdk/pull/1171/files/9a008ae5..2e645c76

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1171&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1171&range=04-05

  Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1171.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1171/head:pull/1171

PR: https://git.openjdk.java.net/jdk/pull/1171

From alanb at openjdk.java.net  Tue Nov 24 19:10:57 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 24 Nov 2020 19:10:57 GMT
Subject: RFR: 8256993: Clarify Package::isSealed javadoc about package
 sealing vs sealed class or interface
In-Reply-To: <AiM8bDunBZDBnRtw3AZlzAFfTh2QjrPITS0ddAHwNs8=.ea384187-33cf-4047-9169-82be7a2a89f2@github.com>
References: <AiM8bDunBZDBnRtw3AZlzAFfTh2QjrPITS0ddAHwNs8=.ea384187-33cf-4047-9169-82be7a2a89f2@github.com>
Message-ID: <OjEKNV8e_28E4nQZKpfqyLjwQo_n1WBQ0l0UFvI9zpM=.bfdea50d-2511-407d-b7d0-7550c0d13a8b@github.com>

On Tue, 24 Nov 2020 18:43:02 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This adds API note in `Package::isSealed` javadoc to clarify package sealing vs sealed class or interface.   Since it's spec clarification, CSR is not strictly needed.

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/java/lang/Package.java line 248:

> 246:      * See the {@link Package Package} class specification for details
> 247:      * how a {@code Package} is defined as sealed package.
> 248:      *

The API note and link to the section in the JAR file spec is good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1419

From smarks at openjdk.java.net  Tue Nov 24 20:03:03 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Tue, 24 Nov 2020 20:03:03 GMT
Subject: RFR: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 =?UTF-8?B?aXNEZXN0cm95ZWQs4oCm?= [v3]
In-Reply-To: <vDmkugOG_EATqtXaLA73yTD04IAtIVOT92_cixJfTqM=.d2f05630-f0ea-4f5a-be38-5742dd4aea00@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
 <vDmkugOG_EATqtXaLA73yTD04IAtIVOT92_cixJfTqM=.d2f05630-f0ea-4f5a-be38-5742dd4aea00@github.com>
Message-ID: <fv7k_Hj3Wkkx0xIayMan4G8DTJNXfVa_rFipU6jVydo=.1a82f547-ea9c-4a88-a97b-77e2f81f01da@github.com>

On Sun, 22 Nov 2020 16:00:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
>> 
>> - stop 
>> - destroy 
>> - isDestroyed 
>> - setDaemon 
>> - isDaemon 
>> 
>> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
>> 
>> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
>> 
>> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Tweak wording of @deprecated message to make it more general
>  - Merge
>  - Fixed typo in @deprecated text
>  - Merge
>  - Update jshell class
>  - 8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

I'm ok with the wording "inherently flawed."

-------------

Marked as reviewed by smarks (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1318

From mchung at openjdk.java.net  Tue Nov 24 21:21:56 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 24 Nov 2020 21:21:56 GMT
Subject: Integrated: 8256993: Clarify Package::isSealed javadoc about package
 sealing vs sealed class or interface
In-Reply-To: <AiM8bDunBZDBnRtw3AZlzAFfTh2QjrPITS0ddAHwNs8=.ea384187-33cf-4047-9169-82be7a2a89f2@github.com>
References: <AiM8bDunBZDBnRtw3AZlzAFfTh2QjrPITS0ddAHwNs8=.ea384187-33cf-4047-9169-82be7a2a89f2@github.com>
Message-ID: <OHaMJj-rxUJ2upeV1aT_3xcZkrb4sD6KvGP66cEFRSk=.cf828e79-da73-4483-8007-21b790e57bf6@github.com>

On Tue, 24 Nov 2020 18:43:02 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> This adds API note in `Package::isSealed` javadoc to clarify package sealing vs sealed class or interface.   Since it's spec clarification, CSR is not strictly needed.

This pull request has now been integrated.

Changeset: 3c230b8a
Author:    Mandy Chung <mchung at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/3c230b8a
Stats:     16 lines in 1 file changed: 15 ins; 0 del; 1 mod

8256993: Clarify Package::isSealed javadoc about package sealing vs sealed class or interface

Reviewed-by: alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1419

From redestad at openjdk.java.net  Tue Nov 24 22:13:03 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Tue, 24 Nov 2020 22:13:03 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String
In-Reply-To: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
Message-ID: <unhiwinV15NKzB-HsrVaX5XyoVCIADKaclSu7jOZid8=.7eb3107c-f7f1-4e6d-b010-dfc963db9e15@github.com>

On Tue, 29 Sep 2020 14:28:52 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> Original mail: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
> 
> Hello,
> 
> while working with `StringBuilder.insert()` I've spotted that its delegate `AbstractStringBuilder.insert()` is missing
> a fast-path for the most frequent case when its argument is `String`.
> 
> Previously they did similart optimization for `StirngBuilder.append(CharSequence, int, int)`,
> see https://bugs.openjdk.java.net/browse/JDK-8224986
> 
> I'd like to contribute a trivial patch that brings improvement for the case when SB's content is Latin1
> and inserted String is Latin1 as well.
> 
> To measure improvement I've used simple benchmark:
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class StringBuilderInsertBenchmark {
> 
>   @Benchmark
>   public StringBuilder insert(Data data) {
>     String string = data.string;
>     return new StringBuilder().append("ABC").insert(1, string, 1, data.length + 1);
>   }
> 
>   @State(Scope.Thread)
>   public static class Data {
>     String string;
> 
>     @Param({"true", "false"})
>     private boolean latin;
> 
>     @Param({"8", "64", "128", "1024"})
>     private int length;
> 
>     @Setup
>     public void setup() {
>       String alphabet = latin
>         ? "abcdefghijklmnopqrstuvwxyz"        // English
>         : "????????????????????????????????"; // Russian
> 
>       string = new RandomStringGenerator().randomString(alphabet, length + 2);
>     }
>   }
> }
> 
> public final class RandomStringGenerator {
> 
>   public String randomString(String alphabet, int length) {
>     char[] chars = alphabet.toCharArray();
> 
>     ThreadLocalRandom random = ThreadLocalRandom.current();
> 
>     char[] array = new char[length];
>     for (int i = 0; i < length; i++) {
>       array[i] = chars[random.nextInt(chars.length)];
>     }
> 
>     return new String(array);
>   }
> }
> Which gives
> 
>             (latin)  (length)       original       patched    Units
> insert         true         8    24.2 ?  0.1   22.2 ?  0.0    ns/op
> insert         true        64    53.8 ?  0.2   36.1 ?  0.1    ns/op
> insert         true       128    80.9 ?  0.2   44.6 ?  0.0    ns/op
> insert         true      1024   365.4 ?  0.5  109.8 ?  3.9    ns/op
> 
> insert        false         8    33.5 ?  0.5   32.3 ?  0.2    ns/op
> insert        false        64    73.2 ?  0.3   73.2 ?  0.2    ns/op
> insert        false       128   103.9 ?  0.6  103.3 ?  0.1    ns/op
> insert        false      1024   576.5 ?  4.8  569.5 ?  2.0    ns/op
> Patch is attached. As of tests tier1 and tier2 are ok.
> 
> With best regards,
> Sergey Tsypanov

Hi Sergey, I see Roger filed an RFE for this: [JDK-8254082](https://bugs.openjdk.java.net/browse/JDK-8254082). To move the PR along, you need to add "8254082: " as a prefix to the PR summary. Then all checks should clear and this will move to the RFR stage.

-------------

PR: https://git.openjdk.java.net/jdk/pull/402

From github.com+10835776+stsypanov at openjdk.java.net  Tue Nov 24 22:13:04 2020
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, 24 Nov 2020 22:13:04 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String
In-Reply-To: <unhiwinV15NKzB-HsrVaX5XyoVCIADKaclSu7jOZid8=.7eb3107c-f7f1-4e6d-b010-dfc963db9e15@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
 <unhiwinV15NKzB-HsrVaX5XyoVCIADKaclSu7jOZid8=.7eb3107c-f7f1-4e6d-b010-dfc963db9e15@github.com>
Message-ID: <O41b7ROVXetbLijMewlEZ1szETJEh6_Xd6zeW12EJDU=.759ab944-8795-4ddd-a1c0-21f50513ba62@github.com>

On Tue, 24 Nov 2020 09:58:19 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Original mail: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
>> 
>> Hello,
>> 
>> while working with `StringBuilder.insert()` I've spotted that its delegate `AbstractStringBuilder.insert()` is missing
>> a fast-path for the most frequent case when its argument is `String`.
>> 
>> Previously they did similart optimization for `StirngBuilder.append(CharSequence, int, int)`,
>> see https://bugs.openjdk.java.net/browse/JDK-8224986
>> 
>> I'd like to contribute a trivial patch that brings improvement for the case when SB's content is Latin1
>> and inserted String is Latin1 as well.
>> 
>> To measure improvement I've used simple benchmark:
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>> public class StringBuilderInsertBenchmark {
>> 
>>   @Benchmark
>>   public StringBuilder insert(Data data) {
>>     String string = data.string;
>>     return new StringBuilder().append("ABC").insert(1, string, 1, data.length + 1);
>>   }
>> 
>>   @State(Scope.Thread)
>>   public static class Data {
>>     String string;
>> 
>>     @Param({"true", "false"})
>>     private boolean latin;
>> 
>>     @Param({"8", "64", "128", "1024"})
>>     private int length;
>> 
>>     @Setup
>>     public void setup() {
>>       String alphabet = latin
>>         ? "abcdefghijklmnopqrstuvwxyz"        // English
>>         : "????????????????????????????????"; // Russian
>> 
>>       string = new RandomStringGenerator().randomString(alphabet, length + 2);
>>     }
>>   }
>> }
>> 
>> public final class RandomStringGenerator {
>> 
>>   public String randomString(String alphabet, int length) {
>>     char[] chars = alphabet.toCharArray();
>> 
>>     ThreadLocalRandom random = ThreadLocalRandom.current();
>> 
>>     char[] array = new char[length];
>>     for (int i = 0; i < length; i++) {
>>       array[i] = chars[random.nextInt(chars.length)];
>>     }
>> 
>>     return new String(array);
>>   }
>> }
>> Which gives
>> 
>>             (latin)  (length)       original       patched    Units
>> insert         true         8    24.2 ?  0.1   22.2 ?  0.0    ns/op
>> insert         true        64    53.8 ?  0.2   36.1 ?  0.1    ns/op
>> insert         true       128    80.9 ?  0.2   44.6 ?  0.0    ns/op
>> insert         true      1024   365.4 ?  0.5  109.8 ?  3.9    ns/op
>> 
>> insert        false         8    33.5 ?  0.5   32.3 ?  0.2    ns/op
>> insert        false        64    73.2 ?  0.3   73.2 ?  0.2    ns/op
>> insert        false       128   103.9 ?  0.6  103.3 ?  0.1    ns/op
>> insert        false      1024   576.5 ?  4.8  569.5 ?  2.0    ns/op
>> Patch is attached. As of tests tier1 and tier2 are ok.
>> 
>> With best regards,
>> Sergey Tsypanov
>
> Hi Sergey, I see Roger filed an RFE for this: [JDK-8254082](https://bugs.openjdk.java.net/browse/JDK-8254082). To move the PR along, you need to add "8254082: " as a prefix to the PR summary. Then all checks should clear and this will move to the RFR stage.

@cl4es thanks for pointing this out, done!

-------------

PR: https://git.openjdk.java.net/jdk/pull/402

From forax at univ-mlv.fr  Tue Nov 24 22:13:28 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 24 Nov 2020 23:13:28 +0100 (CET)
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
In-Reply-To: <20FD1D00-E00C-4320-821E-3CE4F0747A37@oracle.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <24865095.1772546.1605960239461.JavaMail.zimbra@u-pem.fr>
 <20FD1D00-E00C-4320-821E-3CE4F0747A37@oracle.com>
Message-ID: <1599201024.1756644.1606256008304.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Jim Laskey" <james.laskey at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Jim Laskey" <jlaskey at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "security-dev"
> <security-dev at openjdk.java.net>
> Envoy?: Lundi 23 Novembre 2020 14:58:50
> Objet: Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators

> R?mi,

Hi Jim,

> 
>> On Nov 21, 2020, at 8:03 AM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> Ok, i've taking the time to read some literature about random generators because
>> for me the Mersenne Twister was still the king.
>> 
>> The current API proposed as clearly two levels, you have the user level and the
>> implementation level, at least the implementation level should seen as a SPI
> 
> Yes, We agree. It was decided that we work on the SPI separately from the
> original JEP. IMHO the implementation issues are too complex for a single JEP.
> So, the goal is to release the user level now, and refine the SPI at a later
> date. Only RandomGenerator (with descendant interfaces) and
> RandomGeneratorFactory will be public facing in the first release.
> 
> 
>> 
>> RandomGenerator is the user facing API, for me it should be the sole interface
>> exposed by the API, the others (leap, arbitrary leap and split) should be
>> optional methods.
> 
> Fair enough, but if your task requires leapable, you might be disappointed when
> you get an UnsupportedOperationException invoking leap. I personally like the
> "to the quick" ability of using LeapableGenerator for narrowing down the
> search.
> 
>    LeapableGenerator leapable = LeapableGenerator.all().findFirst().orElseThrow();
> 
> Open for discussion.

For me, it's not different from
   RandomGenerator leapable = RandomGenerator.getLeapableGenerator();

The question is: does this generator will be used directly or will it be sent through several layers of API,
because if it travels a lot, then a specific interface is better, otherwise a generic interface is better because it's easier to use from a user perspective and easier to maintain because you encode less knowledge.

> 
>> 
>> In term of factory methods, we should have user driven methods:
>> - getDefaultGenerator() that currently returns a L64X128MixRandom and can be
>> changed in the future
>> - getFastGenerator() that currently returns a Xoroshiro128PlusPlus and can be
>> changed in the future
>> - getDefault[Splitable|Leapable|etc]Generator that returns a default generator
>> with the methods splits|leaps|etc defined
>> - of / getByName that returns a specific generator by its name (but mov ed in a
>> SPI class)
> 
> I'm concerned that the "can be changed in the future" aspect of your default
> methods will create a false reliance. We sort of have default now with the
> java.util.Random class. If we were to change the underpinnings of Random all
> heck would break loose. We already ran into that aspect during testing - tests
> that relied on sequences from fixed seeds.

The incantation all().findFirst() has the exact same issue.

I believe that the fact that there are several defaults shield you a little because it's understood that those default will change from time to time.

> 
> We try to discourage the use of 'of', but there is a class of user (machine
> learning for example) that wants to be able to specify exactly. Often, choosing
> a specific fast prng for testing and then a more sophisticated one for
> production. The main purpose for RandomGenerator is swapability.


If of() is part of the SPI, i think it's fine, because you are explicitly asking for an implementation.
There is still the question about what implementations is provided for a specific jdk.

> 
> 
>> 
>> The example in the documentation should use getDefaultGenerator() and not of()
>> to avoid the problem all the programming languages currently have by having
>> over-specified that the default generator is a Mersenne Twister.
> 
> I have a problem with this as well. It would make it difficult to deprecate
> java.util.Random.

As i said above, not really because you are not asking for a specific implementation here but for a good default.
In practice, it will depends if the implementation is changed enough in the next releases of the JDK or not. 

> 
>> 
>> All methods that returns a stream of the available implementations should be
>> moved in the SPI package.
> 
> Open for discussion.

R?mi

From github.com+10835776+stsypanov at openjdk.java.net  Tue Nov 24 22:13:03 2020
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, 24 Nov 2020 22:13:03 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String
Message-ID: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>

Original mail: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html

Hello,

while working with `StringBuilder.insert()` I've spotted that its delegate `AbstractStringBuilder.insert()` is missing
a fast-path for the most frequent case when its argument is `String`.

Previously they did similart optimization for `StirngBuilder.append(CharSequence, int, int)`,
see https://bugs.openjdk.java.net/browse/JDK-8224986

I'd like to contribute a trivial patch that brings improvement for the case when SB's content is Latin1
and inserted String is Latin1 as well.

To measure improvement I've used simple benchmark:
@BenchmarkMode(Mode.AverageTime)
@OutputTimeUnit(TimeUnit.NANOSECONDS)
@Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
public class StringBuilderInsertBenchmark {

  @Benchmark
  public StringBuilder insert(Data data) {
    String string = data.string;
    return new StringBuilder().append("ABC").insert(1, string, 1, data.length + 1);
  }

  @State(Scope.Thread)
  public static class Data {
    String string;

    @Param({"true", "false"})
    private boolean latin;

    @Param({"8", "64", "128", "1024"})
    private int length;

    @Setup
    public void setup() {
      String alphabet = latin
        ? "abcdefghijklmnopqrstuvwxyz"        // English
        : "????????????????????????????????"; // Russian

      string = new RandomStringGenerator().randomString(alphabet, length + 2);
    }
  }
}

public final class RandomStringGenerator {

  public String randomString(String alphabet, int length) {
    char[] chars = alphabet.toCharArray();

    ThreadLocalRandom random = ThreadLocalRandom.current();

    char[] array = new char[length];
    for (int i = 0; i < length; i++) {
      array[i] = chars[random.nextInt(chars.length)];
    }

    return new String(array);
  }
}
Which gives

            (latin)  (length)       original       patched    Units
insert         true         8    24.2 ?  0.1   22.2 ?  0.0    ns/op
insert         true        64    53.8 ?  0.2   36.1 ?  0.1    ns/op
insert         true       128    80.9 ?  0.2   44.6 ?  0.0    ns/op
insert         true      1024   365.4 ?  0.5  109.8 ?  3.9    ns/op

insert        false         8    33.5 ?  0.5   32.3 ?  0.2    ns/op
insert        false        64    73.2 ?  0.3   73.2 ?  0.2    ns/op
insert        false       128   103.9 ?  0.6  103.3 ?  0.1    ns/op
insert        false      1024   576.5 ?  4.8  569.5 ?  2.0    ns/op
Patch is attached. As of tests tier1 and tier2 are ok.

With best regards,
Sergey Tsypanov

-------------

Commit messages:
 - 8254082: Add fast-path for String into AbstractStringBuilder.insert(int, CharSequence, int, int)

Changes: https://git.openjdk.java.net/jdk/pull/402/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=402&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8254082
  Stats: 23 lines in 1 file changed: 13 ins; 4 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/402/head:pull/402

PR: https://git.openjdk.java.net/jdk/pull/402

From forax at univ-mlv.fr  Tue Nov 24 22:27:12 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Tue, 24 Nov 2020 23:27:12 +0100 (CET)
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number
 Generators [v3]
In-Reply-To: <740D04D2-6FCB-44B7-BC57-6347B27171B5@oracle.com>
References: <17ZVd3Hqa05Hm2lbHEiXi38RXG__C09KL0QLBqxsb0g=.ef1bca7a-8ec3-4cae-b457-680e739887ea@github.com>
 <6h9eeR6HFk03eD3DCtXjJo9Wg81zWH1090paXb-Yp1k=.da9e5ecd-377a-488f-a2f6-b43876af6f60@github.com>
 <676865722.1878668.1605655096153.JavaMail.zimbra@u-pem.fr>
 <740D04D2-6FCB-44B7-BC57-6347B27171B5@oracle.com>
Message-ID: <1437905904.1759938.1606256832889.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Jim Laskey" <james.laskey at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Jim Laskey" <jlaskey at openjdk.java.net>, "build-dev" <build-dev at openjdk.java.net>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>, "security-dev" <security-dev at openjdk.java.net>
> Envoy?: Lundi 23 Novembre 2020 14:27:31
> Objet: Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]

> [Sorry it took so long. Have been on break.]
> 
> From Guy:
> 
> Thanks for the forward.  Here are my thoughts:
> 
> Good question from R?mi.
> 
> If we consider PRNGs to have started at about the time of von Neumann, circa
> 1946, then I would say that we have been inventing a new category about once
> every 25 years or so: jumpable, multi-level jumpable, cryptographically secure,
> splittable.  Twenty years ago we would just have one or more levels of
> jumping/leaping.  I think SecureRandom appeared in 2002 (in J2SE 1.4), and the
> first version of SplittableRandom was in 2014.

I not an expert on PRNG, so i trust you on this.

> 
> So I could be wrong, but I really don?t expect to have to add any more
> interfaces in the next decade or two.  I think we will get more benefit from
> the better type checking than we would get with optional methods.

Again, from my armchair, i see why a SplitableRandomGenerator may make sense (but i'm a big fan of spliterators to my students utter despair), less for the other subtypes of RandomGenerator and as i said to Jim,
i don't see those generators to be taken as parameters of methods a lot so if this assumption is true, optional methods make more sense.

> 
> ?Guy

R?mi

> 
> 
>> On Nov 17, 2020, at 7:18 PM, Remi Forax <forax at univ-mlv.fr> wrote:
>> 
>> An honest question,
>> why do we need so many interfaces for the different categories of
>> RandomGenerator ?
>> 
>> My fear is that we are encoding the state of our knowledge of the different
>> kinds of random generators now so it will not be pretty in the future when new
>> categories of random generator are discovered/invented.
>> If we can take example of the past to predict the future, 20 years ago, what
>> should have been the hierarchy at that time.
>> Is it not reasonable to think that we will need new kinds of random generator in
>> the future ?
>> 
>> I wonder if it's not better to have one interface and several optional methods
>> like we have with the collections, it means that we are loosing the
>> possibilities to precisely type a method that only works with a precise type of
>> generator but it will be more future proof.
>> 
>> R?mi
>> 
>> ----- Mail original -----
>>> De: "Jim Laskey" <jlaskey at openjdk.java.net>
>>> ?: "build-dev" <build-dev at openjdk.java.net>, "core-libs-dev"
>>> <core-libs-dev at openjdk.java.net>,
>>> security-dev at openjdk.java.net
>>> Envoy?: Mardi 17 Novembre 2020 23:21:18
>>> Objet: Re: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators [v3]
>> 
>>>> 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 .
>>> 
>>> Jim Laskey has updated the pull request with a new target base due to a merge or
>>> a rebase. The pull request now contains 40 commits:
>>> 
>>> - Merge branch 'master' into 8248862
>>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>> 
>>>  Update package-info.java
>>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>> 
>>>  Updated RandomGeneratorFactory javadoc.
>>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>> 
>>>  Updated documentation for RandomGeneratorFactory.
>>> - Merge branch 'master' into 8248862
>>> - Merge branch 'master' into 8248862
>>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>> 
>>>  Move RandomGeneratorProperty
>>> - Merge branch 'master' into 8248862
>>> - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>> 
>>>  Clear up javadoc
>>> - 8248862; Implement Enhanced Pseudo-Random Number Generators
>>> 
>>>  remove RandomGeneratorProperty from API
>>> - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68
>>> 
>>> -------------
>>> 
>>> Changes: https://git.openjdk.java.net/jdk/pull/1273/files
>>> Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1273&range=02
>>> Stats: 14891 lines in 31 files changed: 11110 ins; 3704 del; 77 mod
>>> Patch: https://git.openjdk.java.net/jdk/pull/1273.diff
>>> Fetch: git fetch https://git.openjdk.java.net/jdk pull/1273/head:pull/1273
>>> 
> >> PR: https://git.openjdk.java.net/jdk/pull/1273

From jlaskey at openjdk.java.net  Tue Nov 24 22:31:08 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Tue, 24 Nov 2020 22:31:08 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <2I2HK8tDFSLtPqs0JFLKLgh3QmMTkM1HKuvKQNmsfIg=.a383a449-18e3-413a-a6ba-91dc80fde86a@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>
Message-ID: <eo6HiVnvF25OZsv90M2d0YiLn-eXT8Iq8Jx69SDmS1Q=.cc980149-58d5-4481-aaa3-52c19e48a770@github.com>

On Wed, 18 Nov 2020 00:30:53 GMT, Paul Sandoz <psandoz 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 40 commits:
>> 
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Update package-info.java
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Updated RandomGeneratorFactory javadoc.
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Updated documentation for RandomGeneratorFactory.
>>  - Merge branch 'master' into 8248862
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Move RandomGeneratorProperty
>>  - Merge branch 'master' into 8248862
>>  - 8248862: Implement Enhanced Pseudo-Random Number Generators
>>    
>>    Clear up javadoc
>>  - 8248862; Implement Enhanced Pseudo-Random Number Generators
>>    
>>    remove RandomGeneratorProperty from API
>>  - ... and 30 more: https://git.openjdk.java.net/jdk/compare/f7517386...6fe94c68
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 148:
> 
>> 146:      */
>> 147:     private static Map<String, Provider<? extends RandomGenerator>> getFactoryMap() {
>> 148:         if (factoryMap == null) {
> 
> `factoryMap` needs to be marked volatile when using the double checked locking idiom.

fixing

> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 320:
> 
>> 318:                         }
>> 319:                     }
>> 320:                 }
> 
> Add an `assert` statement that `ctor`, `ctorLong` and `ctorBytes` are all non-null?

Only `ctor` is required but yes.

> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 331:
> 
>> 329:      */
>> 330:     private void ensureConstructors() {
>> 331:         if (ctor == null) {
> 
> This check occurs outside of the synchronized block, field may need to be marked volatile. Unsure about the other dependent fields. Might need to store values from loop in `getConstructors` in locals and then assign in appropriate order, assigning the volatile field last.

okay

-------------

PR: https://git.openjdk.java.net/jdk/pull/1273

From david.holmes at oracle.com  Tue Nov 24 22:49:25 2020
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 25 Nov 2020 08:49:25 +1000
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <555245742.1403793.1606226182119.JavaMail.zimbra@u-pem.fr>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <618aa897-18fd-fd70-1f0a-506e0e5a74d8@oracle.com>
 <bc550458-fea3-d543-1cd9-78f7192fe8ec@oracle.com>
 <96418b57-12fe-208e-c642-b04efeedca24@oracle.com>
 <353454426.1152629.1606211114626.JavaMail.zimbra@u-pem.fr>
 <d428aa49-7a8c-bf14-8294-62239965d998@oracle.com>
 <555245742.1403793.1606226182119.JavaMail.zimbra@u-pem.fr>
Message-ID: <d6e01885-9db7-0958-b8b7-45595e8f9cdc@oracle.com>

On 24/11/2020 11:56 pm, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "David Holmes" <david.holmes at oracle.com>
>> ?: "Remi Forax" <forax at univ-mlv.fr>
>> Cc: "Harold David Seigel" <harold.seigel at oracle.com>, "Vicente Romero" <vromero at openjdk.java.net>, "compiler-dev"
>> <compiler-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev"
>> <hotspot-dev at openjdk.java.net>
>> Envoy?: Mardi 24 Novembre 2020 13:16:39
>> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)
> 
>> Hi Remi,
>>
>> On 24/11/2020 7:45 pm, Remi Forax wrote:
>>> ----- Mail original -----
>>>> De: "David Holmes" <david.holmes at oracle.com>
>>>> ?: "Harold David Seigel" <harold.seigel at oracle.com>, "Vicente Romero"
>>>> <vromero at openjdk.java.net>, "compiler-dev"
>>>> <compiler-dev at openjdk.java.net>, "core-libs-dev"
>>>> <core-libs-dev at openjdk.java.net>, "hotspot-dev"
>>>> <hotspot-dev at openjdk.java.net>
>>>> Envoy?: Mardi 24 Novembre 2020 02:04:55
>>>> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second
>>>> Preview)
>>>
>>>> Hi Harold,
>>>>
>>>> On 24/11/2020 6:27 am, Harold Seigel wrote:
>>>>> Hi David,
>>>>>
>>>>> Thanks for looking at this.
>>>>>
>>>>> The intent was for method Class.permittedSubclasses() to be implemented
>>>>> similarly to Class.getNestMembers().? Are you suggesting that a security
>>>>> manager check be added to permittedSubclasses() similar to the security
>>>>> manager check in getNestMembers()?
>>>>
>>>> No I'm suggesting the change to the API is plain wrong. :) Please see
>>>> discussion in the CSR.
>>>
>>> Given that the CSR is closed, i will answer here.
>>> There are two issues with the previous implementation of permittedSubclasses,
>>> first it's the only method that using method desc which means that people has
>>> to be aware on another non trivial concept (object that describes constant pool
>>> constant) to understand how to use the method then i've tested this API with my
>>> students, all but one what able to correctly derives the Class from a
>>> ClassDesc, so instead of asking every users of permittedSubclasses to go
>>> through the oops of getting Class from a ClassDesc, i think we can agree that
>>> it's better to move the burden from the user to the JDK implementors.
>>
>> Why is the objective to get the Class objects? What purpose does that
>> serve?
> 
> The whole idea of the reflection is to provide the runtime view of Java the language.
> Even if such thing does not exist.

And providing some kind of descriptor for an attribute fulfills that 
role. Nothing says it has to produce Class objects.

>> The original API provided a descriptor for the contents of the
>> permittedSubclasses attribute. I find it totally bizarre to have an API
>> whose role is now to attempt to load all the subclasses of a sealed class.
> 
> It's as bizarre as Class.getClasses() loading all the member classes.

Not at all. Nested types are considered to be part of the same 
implementation as the outer type. They are intimately related and all 
part of the same accessibility domain.

Loading subtypes that likely exist outside of the current package (else 
why would you need to be using sealed types) is a completely different 
matter.

> You are discovering that the reflection API is bizarre, and it is :)

I don't find it that bizarre.

> It's not the view of the JVM, it's the view of Java at runtime, whatever it means.

It means whatever we implement it to mean. So if we implement it in 
bizarre ways then it will be perceived as bizarre.

David
-----

>>
>> YMMV.
>>
>> David
> 
> R?mi
> 
> [1] https://docs.oracle.com/en/java/javase/15/docs/api/java.base/java/lang/Class.html#getClasses()
> 
>>
>>>>
>>>> Cheers,
>>>> David
>>>
>>> regards,
>>> R?mi
>>>
>>>>
>>>>> Thanks, Harold
>>>>>
>>>>> On 11/18/2020 12:31 AM, David Holmes wrote:
>>>>>> Hi Vincente,
>>>>>>
>>>>>> On 16/11/2020 11:36 pm, Vicente Romero wrote:
>>>>>>> Please review the code for the second iteration of sealed classes. In
>>>>>>> this iteration we are:
>>>>>>>
>>>>>>> - Enhancing narrowing reference conversion to allow for stricter
>>>>>>> checking of cast conversions with respect to sealed type hierarchies.
>>>>>>> - Also local classes are not considered when determining implicitly
>>>>>>> declared permitted direct subclasses of a sealed class or sealed
>>>>>>> interface
>>>>>>
>>>>>> The major change here seems to be that getPermittedSubclasses() now
>>>>>> returns actual Class objects instead of ClassDesc. My recollection
>>>>>> from earlier discussions here was that the use of ClassDesc was very
>>>>>> deliberate as the permitted subclasses may not actually exist and
>>>>>> there may be security concerns with returning them!
>>>>>>
>>>>>> Cheers,
>>>>>> David
>>>>>> -----
>>>>>>
>>>>>>> -------------
>>>>>>>
>>>>>>> Commit messages:
>>>>>>>   ? - 8246778: Compiler implementation for Sealed Classes (Second Preview)
>>>>>>>
>>>>>>> Changes: https://git.openjdk.java.net/jdk/pull/1227/files
>>>>>>>   ? Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1227&range=00
>>>>>>>   ?? Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
>>>>>>>   ?? Stats: 589 lines in 12 files changed: 508 ins; 18 del; 63 mod
>>>>>>>   ?? Patch: https://git.openjdk.java.net/jdk/pull/1227.diff
>>>>>>>   ?? Fetch: git fetch https://git.openjdk.java.net/jdk
>>>>>>> pull/1227/head:pull/1227
>>>>>>>
>>>>>>> PR: https://git.openjdk.java.net/jdk/pull/1227

From mchung at openjdk.java.net  Tue Nov 24 23:02:53 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Tue, 24 Nov 2020 23:02:53 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <X7lXs0tULkwp6dM67oHD8HBn_z5HaGbePo30unGhDbc=.566b1f26-9888-4e1b-9cce-4ac5be762259@github.com>
 <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com>
Message-ID: <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com>

On Tue, 17 Nov 2020 00:25:51 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/Package.java line 227:
>> 
>>> 225:      * This method reports on a distinct concept of sealing from
>>> 226:      * {@link Class#isSealed() Class::isSealed}.
>>> 227:      *
>> 
>> This API note will be very confusing to readers. I think the javadoc will need to be fleshed out and probably will need to link to a section the Package class description that defines the legacy concept of sealing.
>
> I agree.  This @apiNote needs more clarification to help the readers to understand the context here.    One thing we could do in the Package class description to add a "Package Sealing" section that can also explain that it has no relationship to "sealed classes".

I added an API note in `Package::isSealed` [1] to clarify sealed package vs sealed class or interface.

The API note you added in `Class::isSealed` can be clarified in a similar fashion like: "Sealed class or interface has no relationship with {@linkplain Package#isSealed package sealing}".

[1] https://github.com/openjdk/jdk/commit/3c230b8a

-------------

PR: https://git.openjdk.java.net/jdk/pull/1227

From forax at univ-mlv.fr  Tue Nov 24 23:18:55 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 25 Nov 2020 00:18:55 +0100 (CET)
Subject: RFR: 8246778: Compiler implementation for Sealed Classes
 (Second Preview)
In-Reply-To: <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <X7lXs0tULkwp6dM67oHD8HBn_z5HaGbePo30unGhDbc=.566b1f26-9888-4e1b-9cce-4ac5be762259@github.com>
 <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com>
 <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com>
Message-ID: <1050079243.1769685.1606259935502.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Mandy Chung" <mchung at openjdk.java.net>
> ?: "compiler-dev" <compiler-dev at openjdk.java.net>, "core-libs-dev" <core-libs-dev at openjdk.java.net>, "hotspot-dev"
> <hotspot-dev at openjdk.java.net>
> Envoy?: Mercredi 25 Novembre 2020 00:02:53
> Objet: Re: RFR: 8246778: Compiler implementation for Sealed Classes (Second Preview)

> On Tue, 17 Nov 2020 00:25:51 GMT, Mandy Chung <mchung at openjdk.org> wrote:
> 
>>> src/java.base/share/classes/java/lang/Package.java line 227:
>>> 
>>>> 225:      * This method reports on a distinct concept of sealing from
>>>> 226:      * {@link Class#isSealed() Class::isSealed}.
>>>> 227:      *
>>> 
>>> This API note will be very confusing to readers. I think the javadoc will need
>>> to be fleshed out and probably will need to link to a section the Package class
>>> description that defines the legacy concept of sealing.
>>
>> I agree.  This @apiNote needs more clarification to help the readers to
>> understand the context here.    One thing we could do in the Package class
>> description to add a "Package Sealing" section that can also explain that it
>> has no relationship to "sealed classes".
> 
> I added an API note in `Package::isSealed` [1] to clarify sealed package vs
> sealed class or interface.
> 
> The API note you added in `Class::isSealed` can be clarified in a similar
> fashion like: "Sealed class or interface has no relationship with {@linkplain
> Package#isSealed package sealing}".

Hi Mandy,
given that almost nobody knows about sealed packages, i'm not sure that adding a reference to Package::isSealed in Class::isSealed actually helps, it might be confusing.

> 
> [1] https://github.com/openjdk/jdk/commit/3c230b8a
> 
> -------------
> 
> PR: https://git.openjdk.java.net/jdk/pull/1227

From mandy.chung at oracle.com  Tue Nov 24 23:43:48 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 24 Nov 2020 15:43:48 -0800
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <1050079243.1769685.1606259935502.JavaMail.zimbra@u-pem.fr>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <X7lXs0tULkwp6dM67oHD8HBn_z5HaGbePo30unGhDbc=.566b1f26-9888-4e1b-9cce-4ac5be762259@github.com>
 <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com>
 <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com>
 <1050079243.1769685.1606259935502.JavaMail.zimbra@u-pem.fr>
Message-ID: <398de591-4914-a70d-191b-989dcb1a430d@oracle.com>



On 11/24/20 3:18 PM, Remi Forax wrote:
>
> Hi Mandy,
> given that almost nobody knows about sealed packages, i'm not sure that adding a reference to Package::isSealed in Class::isSealed actually helps, it might be confusing.
>

It's even better if the API note in `Class::isSealed` from PR is removed:
 ???? * This method reports on a distinct concept of sealing from
 ???? * {@link Package#isSealed() Package::isSealed}.

I'm good with that.?? Alan and I saw the proposed API note and just feel 
it adds more confusion than helping (My comment is meant to be on 
Class::isSealed but now I realized the comment is on Package::isSealed.? 
sorry for the confusion.)

Mandy

From dholmes at openjdk.java.net  Wed Nov 25 00:05:00 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Wed, 25 Nov 2020 00:05:00 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v6]
In-Reply-To: <8t9K2ZBTJu1RRsWncao3E7LHxKYnOvfwC2GigKsel1g=.970833fb-2560-4a13-9984-9082c4b40157@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <8t9K2ZBTJu1RRsWncao3E7LHxKYnOvfwC2GigKsel1g=.970833fb-2560-4a13-9984-9082c4b40157@github.com>
Message-ID: <FXDo44eJPhXSPyP_w_YAPPxF0lNW6Z3bqybOD2XSKa8=.d7cb0d1c-b0fe-4b2c-8b10-641711b6d0e7@github.com>

On Tue, 24 Nov 2020 13:35:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
>> 
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
>> 
>> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
>> 
>> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
>> 
>> Testing: `make images` on Linux and Windows x86_32 platforms.
>
> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into Linker_32bit-fixes_Simpler
>  - Remove JNI_ENTRY_CPP_NOENV
>  - - Move reset_last_Java_frame
>  - Use the Unimplemented() macro instead of hlt()
>  - Merge branch 'master' into Linker_32bit-fixes_Simpler
>  - Remove UnsupportedPlatform test
>  - Remove unneeded cast
>  - Remove Stuff that makes the jdk_foreign tests pass
>  - fix test warnings
>  - - Fix 32-bit build errors and tests
>    - Add negative test for 32-bit platform.
>    - Change CABI to fail more lazily when running on an unsupported platform.
>    - Change CLinker layouts to be null on unsupported platforms, instead of failing when initializing the class
>    - Added note to CLinker about failure to initialize on unsupported platforms

The VM "entry" changes seem better now. Thanks.

The use of CATCH as a safety-net is also good.

src/hotspot/share/prims/universalUpcallHandler.cpp line 37:

> 35: 
> 36: void ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff) {
> 37:   JavaThread* THREAD = JavaThread::current();

You could pass the current thread in rather than re-manifesting it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From kbarrett at openjdk.java.net  Wed Nov 25 03:21:58 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 25 Nov 2020 03:21:58 GMT
Subject: RFR: 8256517: (ref) Reference.clear during reference processing
 may lose notification [v2]
In-Reply-To: <4C7DyAgcXsSq3YEzbbwWeLaIbWwOyEriG8_4QrWNZ80=.4b75553f-7eaf-4d8b-9b47-007fc0609ba7@github.com>
References: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
 <4C7DyAgcXsSq3YEzbbwWeLaIbWwOyEriG8_4QrWNZ80=.4b75553f-7eaf-4d8b-9b47-007fc0609ba7@github.com>
Message-ID: <UsEMrtooSrl_sXzDOTB6htj9dxhjZ0tcVrtOdXycbuU=.b9cf68b9-9d08-499f-86d3-89a11c8de2a1@github.com>

On Mon, 23 Nov 2020 20:36:57 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - new tests need ref in oldgen too
>>  - remove obsolete comment about races with clear and enqueue
>
> Looks good! Thanks!

Thanks @rkennke, @pliden, @mlchung for reviews.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1376

From kvn at openjdk.java.net  Wed Nov 25 03:37:08 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 25 Nov 2020 03:37:08 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
Message-ID: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>

JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.

Initial patch was prepared by @fisk.

Tested hs-tier1-4. Added new compiler tests to test intrinsics.

Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.

-------------

Commit messages:
 - 8256999: Add C2 intrinsic for Reference.refersTo and PhantomReference::refersTo

Changes: https://git.openjdk.java.net/jdk/pull/1425/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1425&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256999
  Stats: 381 lines in 16 files changed: 242 ins; 61 del; 78 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1425/head:pull/1425

PR: https://git.openjdk.java.net/jdk/pull/1425

From kbarrett at openjdk.java.net  Wed Nov 25 03:39:20 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 25 Nov 2020 03:39:20 GMT
Subject: Integrated: 8256517: (ref) Reference.clear during reference
 processing may lose notification
In-Reply-To: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
References: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
Message-ID: <glNs8iee78fMuq3Ol0V3SJ18hR1q3qPnwmey3nd1vWk=.cfa1f882-e0ce-416c-8bd2-d52d8365c3d1@github.com>

On Mon, 23 Nov 2020 01:43:39 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> Please review this change to Reference.clear() to address several issues.
> 
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
> 
> (JDK-8240696) For GCs with concurrent reference processing, clearing the
> referent field during reference processing may discard the expected
> notification.
> 
> Both of these are addressed by introducing a private native helper function
> for clearing the referent, rather than using an ordinary in-Java field
> assignment. Tests have been added for both of these issues. This required
> adding a new breakpoint in reference processing for ZGC.
> 
> Of course, finalization adds some complexity to the problem.  We deal with
> that by having FinalReference override clear.  The implementation is
> provided by a new package-private method in Reference.  (There are a number
> of alternatives, all of them clumsy; finalization is annoying that way.)
> 
> While dealing with FinalReference clearing it was noted that the recent
> JDK-8256106 and JDK-8256370 have some problems. FinalizerHistogram was not
> updated to call the new Reference.getInactive(), instead still calling get()
> on FinalReferences, with the JDK-8256106 problems. Fixing that showed the
> assertion for inactive FinalReference added by JDK-8256370 used the wrong
> test.
> 
> Rather than tracking down and changing all get() and clear() calls on final
> references and changing them to use getInactive and a new similar clear
> function, I've changed FinalReference to override get and clear, which call
> the helper functions in Reference. I've also renamed getInactive to be more
> explanatory and less convenient to call directly, and similarly named the
> helper for clear. This means that get/clear should never be called on an
> active FinalReference. That's already never done, and would have problems
> if it were.
> 
> Testing:
> mach5 tier1-6
> Local (linux-x64) tier1 using Shenandoah.
> New TestReferenceClearDuringMarking fails for G1 without these changes.
> New TestReferenceClearDuringReferenceProcessing fails for ZGC without these changes.

This pull request has now been integrated.

Changeset: 66943fef
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/66943fef
Stats:     317 lines in 14 files changed: 286 ins; 22 del; 9 mod

8256517: (ref) Reference.clear during reference processing may lose notification
8240696: (ref) Reference.clear may extend the lifetime of the referent

Use private native helper to implement Reference.clear.

Reviewed-by: pliden, rkennke, mchung

-------------

PR: https://git.openjdk.java.net/jdk/pull/1376

From kbarrett at openjdk.java.net  Wed Nov 25 03:39:17 2020
From: kbarrett at openjdk.java.net (Kim Barrett)
Date: Wed, 25 Nov 2020 03:39:17 GMT
Subject: RFR: 8256517: (ref) Reference.clear during reference processing
 may lose notification [v3]
In-Reply-To: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
References: <UVC9IQn5uMPpbc8Yy3-576nrsdthf09qi09ReEdfK-0=.5b2df838-55a7-4a86-8ed0-715247a4d7cf@github.com>
Message-ID: <Pmr5sssPvByE296ZnMOvj2X1GK0kyevLc6iCA9V52FY=.db7accc3-fcf7-4aa7-b6dc-f8a27ff2e4d8@github.com>

> Please review this change to Reference.clear() to address several issues.
> 
> (JDK-8240696) For GCs using a SATB barrier, simply assigning the referent
> field to null may extend the lifetime of the referent value.
> 
> (JDK-8240696) For GCs with concurrent reference processing, clearing the
> referent field during reference processing may discard the expected
> notification.
> 
> Both of these are addressed by introducing a private native helper function
> for clearing the referent, rather than using an ordinary in-Java field
> assignment. Tests have been added for both of these issues. This required
> adding a new breakpoint in reference processing for ZGC.
> 
> Of course, finalization adds some complexity to the problem.  We deal with
> that by having FinalReference override clear.  The implementation is
> provided by a new package-private method in Reference.  (There are a number
> of alternatives, all of them clumsy; finalization is annoying that way.)
> 
> While dealing with FinalReference clearing it was noted that the recent
> JDK-8256106 and JDK-8256370 have some problems. FinalizerHistogram was not
> updated to call the new Reference.getInactive(), instead still calling get()
> on FinalReferences, with the JDK-8256106 problems. Fixing that showed the
> assertion for inactive FinalReference added by JDK-8256370 used the wrong
> test.
> 
> Rather than tracking down and changing all get() and clear() calls on final
> references and changing them to use getInactive and a new similar clear
> function, I've changed FinalReference to override get and clear, which call
> the helper functions in Reference. I've also renamed getInactive to be more
> explanatory and less convenient to call directly, and similarly named the
> helper for clear. This means that get/clear should never be called on an
> active FinalReference. That's already never done, and would have problems
> if it were.
> 
> Testing:
> mach5 tier1-6
> Local (linux-x64) tier1 using Shenandoah.
> New TestReferenceClearDuringMarking fails for G1 without these changes.
> New TestReferenceClearDuringReferenceProcessing fails for ZGC without these changes.

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 six additional commits since the last revision:

 - Merge branch 'master' into java_clear
 - new tests need ref in oldgen too
 - remove obsolete comment about races with clear and enqueue
 - add private native Reference::clear0
 - test clear during marking
 - test clear during reference processing

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1376/files
  - new: https://git.openjdk.java.net/jdk/pull/1376/files/c19efd70..dfa51fb3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1376&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1376&range=01-02

  Stats: 74214 lines in 450 files changed: 70893 ins; 2086 del; 1235 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1376.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1376/head:pull/1376

PR: https://git.openjdk.java.net/jdk/pull/1376

From smarks at openjdk.java.net  Wed Nov 25 06:21:55 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 25 Nov 2020 06:21:55 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <BV5JY8q6TzUEtFvidfqWgj09YEYZVvKYPrZgnlrqgQ0=.fc07a453-fafe-4fe6-95f5-4c7613818eff@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
 <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
 <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
 <TFCxfLxB7_iDyPbbSXJtWZZm4HOW_n4R66vMnNEzYvI=.1659cc00-17c8-4999-bbb7-b5c7516599b7@github.com>
 <pvwIoAweUPTqGrO7Hxx5VxCbdlEI6-S83rLfRyNmySo=.106ee077-43e3-48a7-8a05-181986e5606b@github.com>
 <BV5JY8q6TzUEtFvidfqWgj09YEYZVvKYPrZgnlrqgQ0=.fc07a453-fafe-4fe6-95f5-4c7613818eff@github.com>
Message-ID: <s2nlMsXWZrXzqbsEp4FwssS7ChjkXB-YZpChXpLTVcU=.52de8d3b-b5e5-4f38-9182-9c75fb5e52b1@github.com>

On Tue, 24 Nov 2020 02:19:34 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> 2. Both the proposed pseudo-code and the existing pseudo-code deviate from the documented behaviour (written in prose) and the actual implementation.

Let me clarify something. The "documented behavior" is actually the API specification, the contract that applies to Map.compute and all its implementations. The pseudo-code is part of the "implementation requirements" section, whose primary responsibility is to specify what the default implementation actually does. (Of course, that implementation should also conform to the API spec.)

We've established that the pseudo-code -- either the existing or proposed version -- differs from the default implementation's actual behavior. It's thus failed its primary responsibility, and therefore that's the problem that needs to be fixed. I think it's pointless to clean up the pseudo-code if the result is still incorrect.

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From stuart.marks at oracle.com  Wed Nov 25 06:26:09 2020
From: stuart.marks at oracle.com (Stuart Marks)
Date: Tue, 24 Nov 2020 22:26:09 -0800
Subject: RFR: 8180352: Add Stream.toList() method [v2]
In-Reply-To: <877dqiyj55.fsf@mid.deneb.enyo.de>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <aBcWsV_NhVd3jaVqcC-TKl38hWXUmEIrSUmsYPPF88g=.2b4b7d94-a3cc-4fc0-a9e7-defa360ee3a0@github.com>
 <zNl6puL1sy_S1JWp3tLiQQf2YrhHvHY3GtGIBjtfz7E=.5eb94743-bfbb-4908-a2af-e9aceb22c9d3@github.com>
 <VeEg7hCJwqiJ8eqvlPLb9Oi6eNx-pgOqTzwshgb01jk=.5169c749-c176-438b-adc2-9e94921aa7c2@github.com>
 <hhibYsPaakZXBiorfc_4a2T6Y0fwkHATDT49wamF5QU=.4b4549f7-863d-4902-a34c-7648d806d4fd@github.com>
 <ItQDJF_yBhjEKceLh1skwy3tYtIY5T_TxOQX0h6nYBI=.0503f471-5876-4448-80b3-968a16f38293@github.com>
 <Y71HRQPKV6Uc-_6PkgZWl97d3bHhu4BmQjE_pL8MEmA=.f6ab9972-7ed4-41fc-8dcf-c5286b0062fb@github.com>
 <EKK54iv-Ok1SZ1XEeUTm-Yjofp-lSOaRFpyKixb-xKI=.f6489482-9026-46aa-8a1f-afa8dd9d4d58@github.com>
 <BESZZeK2WVIubLeJFi1BZayJegadJHxwsB-RFio6k7I=.79995b04-49c9-4aa1-a1b9-3382e0bb4d14@github.com>
 <cc38043b-2107-a470-a0a8-7c7e141ca0c6@gmail.com>
 <877dqiyj55.fsf@mid.deneb.enyo.de>
Message-ID: <3e0cb7ca-969b-cf59-f3b6-70e39e499910@oracle.com>



On 11/18/20 3:55 AM, Florian Weimer wrote:
> I think it's also needed for an efficient null element check in
> List::copyOf.  I have a hunch that with the posted implementation, it
> would incorrectly produce an immutable list that contains null
> elements.

(Sorry for the delay; oddly, this comment didn't make it into the PR.)

Yes, there was a bug in List::copyOf in that it would pass through a list containing 
nulls, a clear violation of its spec. I fixed this in my second-most recent commit 
on this PR.

s'marks


From shade at openjdk.java.net  Wed Nov 25 08:01:03 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 25 Nov 2020 08:01:03 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
Message-ID: <pspRmZwTOM4regwd75Q_BmGyycgXq6T2PcVy3cJb4UI=.f21fefa8-ffc8-44c1-9de9-a4de40ae6796@github.com>

On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
> 
> Initial patch was prepared by @fisk.
> 
> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
> 
> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.

src/hotspot/share/opto/c2compiler.cpp line 476:

> 474:     if (UseCompressedOops && UseShenandoahGC) return false;
> 475: #endif
> 476:     break;

Is this intended to disable the intrinsic on all non-64-bit platforms? Is that only for Shenandoah 64-bit? I wonder if it should just be:

  case vmIntrinsics::_PhantomReference_refersTo0:
    if (UseCompressedOops && UseShenandoahGC) return false;
    break;

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From vlivanov at openjdk.java.net  Wed Nov 25 08:21:57 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 25 Nov 2020 08:21:57 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <pspRmZwTOM4regwd75Q_BmGyycgXq6T2PcVy3cJb4UI=.f21fefa8-ffc8-44c1-9de9-a4de40ae6796@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <pspRmZwTOM4regwd75Q_BmGyycgXq6T2PcVy3cJb4UI=.f21fefa8-ffc8-44c1-9de9-a4de40ae6796@github.com>
Message-ID: <pqmsF7Mx61UWgVx3CFnQ4Ig1izW62Q57HjGLsGi9gxU=.1c99d0d0-9f2a-4cd5-9424-ffefe0402bd7@github.com>

On Wed, 25 Nov 2020 07:58:42 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
>> 
>> Initial patch was prepared by @fisk.
>> 
>> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
>> 
>> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.
>
> src/hotspot/share/opto/c2compiler.cpp line 476:
> 
>> 474:     if (UseCompressedOops && UseShenandoahGC) return false;
>> 475: #endif
>> 476:     break;
> 
> Is this intended to disable the intrinsic on all non-64-bit platforms? Is that only for Shenandoah 64-bit? I wonder if it should just be:
> 
>   case vmIntrinsics::_PhantomReference_refersTo0:
>     if (UseCompressedOops && UseShenandoahGC) return false;
>     break;

Considering `UseCompressedOops` doesn't make much sense in 32-bit mode and is set to `false`, it seems `#ifdef` can be just dropped.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From shade at openjdk.java.net  Wed Nov 25 08:27:56 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 25 Nov 2020 08:27:56 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
Message-ID: <r5u1cVRGvUzUo8HHz-MWNt5kJcYQ038r1Oj3tsuERVw=.28bac5f9-77b4-415d-b3d9-3ae971e560a2@github.com>

On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
> 
> Initial patch was prepared by @fisk.
> 
> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
> 
> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.

I just pulled the fresh master, applied this patch on top, enabled `_PhantomReference_refersTo0` in `c2compiler.cpp`, and ran `CONF=linux-x86_64-server-fastdebug make images run-test TEST=tier1 TEST_VM_OPTS="-XX:+UseShenandoahGC"` without problems. 

@vnkozlov, what Shenandoah failure did you see? Attention @rkennke.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From alanb at openjdk.java.net  Wed Nov 25 08:28:59 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 25 Nov 2020 08:28:59 GMT
Subject: Integrated: 8256643: Terminally deprecate ThreadGroup stop, destroy,
 isDestroyed, setDaemon and isDaemon
In-Reply-To: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
References: <9IRiJufCczallYyF4reOXvwK9qPsgQI6feaOwMVE560=.3dfc789b-b1bd-4f6a-b9fe-ec47e12a793e@github.com>
Message-ID: <eZag_nwpvxIv6r1yW69IhT8Vrqu9WkUqEe4ArPvy8OE=.4d84b65f-ca2c-4f6c-af3d-93623fb41b06@github.com>

On Thu, 19 Nov 2020 14:24:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change terminally deprecates the following methods defined by java.lang.ThreadGroup 
> 
> - stop 
> - destroy 
> - isDestroyed 
> - setDaemon 
> - isDaemon 
> 
> The stop method has been deprecated since=1.2 because it is inherently unsafe. It is time to terminally deprecate this method so it can be removed in a future release. Thread.stop will be examined in a separate issue. 
> 
> The destroy, isDestroyed, setDaemon, isDaemon methods support the mechanism to explicitly or automatically destroy a thread group. As detailed in JDK-8252885, the mechanism to destroy thread groups is flawed and racy. Furthermore, this mechanism inhibits efforts to drop the reference from a thread group to its threads (so that thread creation, starting and termination do not need to coordinate with their thread group). These methods should be terminally deprecated so they can be degraded in a future release and eventually removed.
> 
> CSR with more information:  https://bugs.openjdk.java.net/browse/JDK-8256644

This pull request has now been integrated.

Changeset: 79e57ace
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/79e57ace
Stats:     26 lines in 4 files changed: 23 ins; 0 del; 3 mod

8256643: Terminally deprecate ThreadGroup stop, destroy, isDestroyed, setDaemon and isDaemon

Reviewed-by: serb, rriggs, iris, mchung, smarks

-------------

PR: https://git.openjdk.java.net/jdk/pull/1318

From github.com+10835776+stsypanov at openjdk.java.net  Wed Nov 25 08:58:21 2020
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, 25 Nov 2020 08:58:21 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v2]
In-Reply-To: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
Message-ID: <3zKgT0YPjVDG852x1gQVRuv9rQ0lNatZWgzo-lRAHls=.c7d49a6a-2d3d-47f7-92ce-994dd69a4925@github.com>

> Original mail: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
> 
> Hello,
> 
> while working with `StringBuilder.insert()` I've spotted that its delegate `AbstractStringBuilder.insert()` is missing
> a fast-path for the most frequent case when its argument is `String`.
> 
> Previously they did similart optimization for `StirngBuilder.append(CharSequence, int, int)`,
> see https://bugs.openjdk.java.net/browse/JDK-8224986
> 
> I'd like to contribute a trivial patch that brings improvement for the case when SB's content is Latin1
> and inserted String is Latin1 as well.
> 
> To measure improvement I've used simple benchmark:
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class StringBuilderInsertBenchmark {
> 
>   @Benchmark
>   public StringBuilder insert(Data data) {
>     String string = data.string;
>     return new StringBuilder().append("ABC").insert(1, string, 1, data.length + 1);
>   }
> 
>   @State(Scope.Thread)
>   public static class Data {
>     String string;
> 
>     @Param({"true", "false"})
>     private boolean latin;
> 
>     @Param({"8", "64", "128", "1024"})
>     private int length;
> 
>     @Setup
>     public void setup() {
>       String alphabet = latin
>         ? "abcdefghijklmnopqrstuvwxyz"        // English
>         : "????????????????????????????????"; // Russian
> 
>       string = new RandomStringGenerator().randomString(alphabet, length + 2);
>     }
>   }
> }
> 
> public final class RandomStringGenerator {
> 
>   public String randomString(String alphabet, int length) {
>     char[] chars = alphabet.toCharArray();
> 
>     ThreadLocalRandom random = ThreadLocalRandom.current();
> 
>     char[] array = new char[length];
>     for (int i = 0; i < length; i++) {
>       array[i] = chars[random.nextInt(chars.length)];
>     }
> 
>     return new String(array);
>   }
> }
> Which gives
> 
>             (latin)  (length)       original       patched    Units
> insert         true         8    24.2 ?  0.1   22.2 ?  0.0    ns/op
> insert         true        64    53.8 ?  0.2   36.1 ?  0.1    ns/op
> insert         true       128    80.9 ?  0.2   44.6 ?  0.0    ns/op
> insert         true      1024   365.4 ?  0.5  109.8 ?  3.9    ns/op
> 
> insert        false         8    33.5 ?  0.5   32.3 ?  0.2    ns/op
> insert        false        64    73.2 ?  0.3   73.2 ?  0.2    ns/op
> insert        false       128   103.9 ?  0.6  103.3 ?  0.1    ns/op
> insert        false      1024   576.5 ?  4.8  569.5 ?  2.0    ns/op
> Patch is attached. As of tests tier1 and tier2 are ok.
> 
> With best regards,
> Sergey Tsypanov

?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into asb
 - 8254082: Add fast-path for String into AbstractStringBuilder.insert(int, CharSequence, int, int)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/402/files
  - new: https://git.openjdk.java.net/jdk/pull/402/files/128cce75..f7e7b4fe

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=402&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=402&range=00-01

  Stats: 556828 lines in 5364 files changed: 448654 ins; 76031 del; 32143 mod
  Patch: https://git.openjdk.java.net/jdk/pull/402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/402/head:pull/402

PR: https://git.openjdk.java.net/jdk/pull/402

From vlivanov at openjdk.java.net  Wed Nov 25 09:03:00 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 25 Nov 2020 09:03:00 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
Message-ID: <ssQOmnlQu04qaYJ59KeBoFbDw0euJik6v-zQfIAI-6Y=.3614f99b-28ac-42e0-981e-bd832ddc7963@github.com>

On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
> 
> Initial patch was prepared by @fisk.
> 
> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
> 
> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.

src/hotspot/cpu/x86/gc/z/z_x86_64.ad line 123:

> 121: 
> 122:   ins_encode %{
> 123:     if (barrier_data() != 0) { // barrier could be elided by ZBarrierSetC2::analyze_dominating_barriers()

Maybe keep a bit reserved for `ZLoadBarrierElided` to just map it to `0`? The former is preferred because it keeps the info that there was a barrier data attached in the first place.

src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 623:

> 621:   // Also we need to add memory barrier to prevent commoning reads
> 622:   // from this field across safepoint since GC can change its value.
> 623:   bool need_read_barrier = (((on_weak || on_phantom) && !no_keepalive) ||

There's a slight change: `in_heap && (on_weak || ...)` turns into `(on_weak ...) || (in_heap ...)`. It will introduce  a read barrier for `!in_heap && on_weak` case. Does it occur in practice?

Another one: `on_weak` turns into ((on_weak ...) && !no_keepalive). 
My interpretation is no read barrier needed when `NO_KEEPALIVE` flag is used and currently a redundant barrier is issued. 

Maybe replace `!no_keepalive` with just `keep_alive`? The former is harder to parse.

The check grows bigger and bigger. Maybe it's time to split it?

Turn `on_weak || on_phantom` into `!is_strong`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From chegar at openjdk.java.net  Wed Nov 25 09:03:58 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 25 Nov 2020 09:03:58 GMT
Subject: Integrated: 8255904: Remove superfluous use of reflection in
 Class::isRecord
In-Reply-To: <G4d8RjYyOlsZcfOmgiz5uz0-Zr8E6crIv0OaCQd-DmU=.a787c6ab-a2f1-43cd-acd6-d585a9327dcd@github.com>
References: <G4d8RjYyOlsZcfOmgiz5uz0-Zr8E6crIv0OaCQd-DmU=.a787c6ab-a2f1-43cd-acd6-d585a9327dcd@github.com>
Message-ID: <MMegSL6K5i0zPFb2D0h4DBf1_FLH5u8tQy6enU8gmgs=.8987ec0f-7b0b-4b34-b300-96facce4f232@github.com>

On Tue, 24 Nov 2020 10:12:23 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> Minor cleanup - Reflective access to j.l.Record is no longer required since it became standard.

This pull request has now been integrated.

Changeset: cdb41ba1
Author:    Chris Hegarty <chegar at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/cdb41ba1
Stats:     11 lines in 1 file changed: 0 ins; 10 del; 1 mod

8255904: Remove superfluous use of reflection in Class::isRecord

Reviewed-by: redestad, alanb

-------------

PR: https://git.openjdk.java.net/jdk/pull/1406

From chegar at openjdk.java.net  Wed Nov 25 09:40:58 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 25 Nov 2020 09:40:58 GMT
Subject: RFR: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks [v7]
In-Reply-To: <QkyOFcQuVvhS1IYK5690pFjWBI2coK3theDV1WUJxU0=.f53ae4b6-0224-4599-baec-9ba75aa7ff9b@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
 <QkyOFcQuVvhS1IYK5690pFjWBI2coK3theDV1WUJxU0=.f53ae4b6-0224-4599-baec-9ba75aa7ff9b@github.com>
Message-ID: <tqg3u67kkvtwvqwtA9q2c4Hinu_RvROYx5LfuT3Qhe0=.6ebbf1ad-9de9-43cc-b8f7-997da6143dd6@github.com>

On Tue, 24 Nov 2020 16:01:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Both the Foreign Memory Access and the Foreign Linker APIs leave something to be desired when it comes to handling NPEs - first, most of the API javadoc is oblivious to NPEs being thrown. Secondly, not all API method implementations add expicit NPE checks - with the result of NPE often being thrown very deep in the call chain - if at all. Third, test for API coverage of nulls is ad-hoc.
>> 
>> This patch rectifies all these issues. To increase coverage for null injected into APIs, this patch introduces a new framework for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
>> 
>> I've also added, as part of this patch, a test to cover the statics in MemoryAccess which were not covered throughly.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix another typo caused by bulk replace

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1388

From eosterlund at openjdk.java.net  Wed Nov 25 09:49:57 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 25 Nov 2020 09:49:57 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <ssQOmnlQu04qaYJ59KeBoFbDw0euJik6v-zQfIAI-6Y=.3614f99b-28ac-42e0-981e-bd832ddc7963@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <ssQOmnlQu04qaYJ59KeBoFbDw0euJik6v-zQfIAI-6Y=.3614f99b-28ac-42e0-981e-bd832ddc7963@github.com>
Message-ID: <sXTEsyp2rmnjflwD931rs9r1S8oExGm3N7YTTj0O5Uo=.e802d936-a753-4fe7-bec5-c6a24d82a45f@github.com>

On Wed, 25 Nov 2020 08:30:46 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
>> 
>> Initial patch was prepared by @fisk.
>> 
>> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
>> 
>> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.
>
> src/hotspot/cpu/x86/gc/z/z_x86_64.ad line 123:
> 
>> 121: 
>> 122:   ins_encode %{
>> 123:     if (barrier_data() != 0) { // barrier could be elided by ZBarrierSetC2::analyze_dominating_barriers()
> 
> Maybe keep a bit reserved for `ZLoadBarrierElided` to just map it to `0`? The former is preferred because it keeps the info that there was a barrier data attached in the first place.

The information that there was a barrier attached, is implicit in the ins_encode block due to it being run at all. In other words, since we matched the mach node to our ZGC access instead of a normal access, we already know that there was barrier data attached, and that we no longer have such barrier data.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From vlivanov at openjdk.java.net  Wed Nov 25 10:03:56 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 25 Nov 2020 10:03:56 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <sXTEsyp2rmnjflwD931rs9r1S8oExGm3N7YTTj0O5Uo=.e802d936-a753-4fe7-bec5-c6a24d82a45f@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <ssQOmnlQu04qaYJ59KeBoFbDw0euJik6v-zQfIAI-6Y=.3614f99b-28ac-42e0-981e-bd832ddc7963@github.com>
 <sXTEsyp2rmnjflwD931rs9r1S8oExGm3N7YTTj0O5Uo=.e802d936-a753-4fe7-bec5-c6a24d82a45f@github.com>
Message-ID: <eii_10yXpbYt_nO7dGdFZwrST-VIHDA4daqP18j7vsQ=.9f0d0b90-cd00-40d9-b0d1-5f3ab1b835f9@github.com>

On Wed, 25 Nov 2020 09:47:19 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/cpu/x86/gc/z/z_x86_64.ad line 123:
>> 
>>> 121: 
>>> 122:   ins_encode %{
>>> 123:     if (barrier_data() != 0) { // barrier could be elided by ZBarrierSetC2::analyze_dominating_barriers()
>> 
>> Maybe keep a bit reserved for `ZLoadBarrierElided` to just map it to `0`? The former is preferred because it keeps the info that there was a barrier data attached in the first place.
>
> The information that there was a barrier attached, is implicit in the ins_encode block due to it being run at all. In other words, since we matched the mach node to our ZGC access instead of a normal access, we already know that there was barrier data attached, and that we no longer have such barrier data.

Ok, makes sense. What do you think about making `ZLoadBarrierElided = 0` then?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From redestad at openjdk.java.net  Wed Nov 25 10:18:07 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 25 Nov 2020 10:18:07 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v2]
In-Reply-To: <3zKgT0YPjVDG852x1gQVRuv9rQ0lNatZWgzo-lRAHls=.c7d49a6a-2d3d-47f7-92ce-994dd69a4925@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
 <3zKgT0YPjVDG852x1gQVRuv9rQ0lNatZWgzo-lRAHls=.c7d49a6a-2d3d-47f7-92ce-994dd69a4925@github.com>
Message-ID: <qM_l2Qxc2C7m4BhuoG5AHytx-4mUuSfzd7L8MhCoc5s=.ea17f97f-503f-4cdc-925b-fb9c0f0b43fc@github.com>

On Wed, 25 Nov 2020 08:58:21 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Original mail: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
>> 
>> Hello,
>> 
>> while working with `StringBuilder.insert()` I've spotted that its delegate `AbstractStringBuilder.insert()` is missing
>> a fast-path for the most frequent case when its argument is `String`.
>> 
>> Previously they did similart optimization for `StirngBuilder.append(CharSequence, int, int)`,
>> see https://bugs.openjdk.java.net/browse/JDK-8224986
>> 
>> I'd like to contribute a trivial patch that brings improvement for the case when SB's content is Latin1
>> and inserted String is Latin1 as well.
>> 
>> To measure improvement I've used simple benchmark:
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>> public class StringBuilderInsertBenchmark {
>> 
>>   @Benchmark
>>   public StringBuilder insert(Data data) {
>>     String string = data.string;
>>     return new StringBuilder().append("ABC").insert(1, string, 1, data.length + 1);
>>   }
>> 
>>   @State(Scope.Thread)
>>   public static class Data {
>>     String string;
>> 
>>     @Param({"true", "false"})
>>     private boolean latin;
>> 
>>     @Param({"8", "64", "128", "1024"})
>>     private int length;
>> 
>>     @Setup
>>     public void setup() {
>>       String alphabet = latin
>>         ? "abcdefghijklmnopqrstuvwxyz"        // English
>>         : "????????????????????????????????"; // Russian
>> 
>>       string = new RandomStringGenerator().randomString(alphabet, length + 2);
>>     }
>>   }
>> }
>> 
>> public final class RandomStringGenerator {
>> 
>>   public String randomString(String alphabet, int length) {
>>     char[] chars = alphabet.toCharArray();
>> 
>>     ThreadLocalRandom random = ThreadLocalRandom.current();
>> 
>>     char[] array = new char[length];
>>     for (int i = 0; i < length; i++) {
>>       array[i] = chars[random.nextInt(chars.length)];
>>     }
>> 
>>     return new String(array);
>>   }
>> }
>> Which gives
>> 
>>             (latin)  (length)       original       patched    Units
>> insert         true         8    24.2 ?  0.1   22.2 ?  0.0    ns/op
>> insert         true        64    53.8 ?  0.2   36.1 ?  0.1    ns/op
>> insert         true       128    80.9 ?  0.2   44.6 ?  0.0    ns/op
>> insert         true      1024   365.4 ?  0.5  109.8 ?  3.9    ns/op
>> 
>> insert        false         8    33.5 ?  0.5   32.3 ?  0.2    ns/op
>> insert        false        64    73.2 ?  0.3   73.2 ?  0.2    ns/op
>> insert        false       128   103.9 ?  0.6  103.3 ?  0.1    ns/op
>> insert        false      1024   576.5 ?  4.8  569.5 ?  2.0    ns/op
>> Patch is attached. As of tests tier1 and tier2 are ok.
>> 
>> With best regards,
>> Sergey Tsypanov
>
> ?????? ??????? has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into asb
>  - 8254082: Add fast-path for String into AbstractStringBuilder.insert(int, CharSequence, int, int)

Hi Sergey,

this is interesting! I think `StringBuilder.insert` wasn't given much love in JEP 254 since it's likely (much?) less commonly used than `append`. It'd of course be nice to get it up to speed.

Looking at your patch and existing code I think there might be ways to improve this further and get an improvement on most non-latin1 cases too. Possibly cleaning things up a bit, too.

(`putCharsAt(int, String, int, int)` should probably be called `putStringAt`?)

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1716:

> 1714:     }
> 1715: 
> 1716:     private void putCharsAt(int index, String s, int off, int end) {

Comparing this with `putStringAt(int index, String str)` below I think begs for some consolidation here. I think we either should add a `getBytes(value, index, coder, length)`, or - perhaps preferably? - factor out the package private `String.getBytes` and implement it here in ASB using `s.value()`

src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1721:

> 1719:             return;
> 1720:         }
> 1721:         inflate();

Like in `String.getBytes(byte[], int, byte)` I think we could do an `arraycopy` if both are `false` too, just need to carefully adjust the `index` et.c. In fact the only case that can't use an `arraycopy` in the end is when `s.isLatin1()` and the current sb is already inflated (that's what the `StringLatin1.inflate` branch does in `getBytes`). 

I think if you consolidate/merge this with the logic in `String.getBytes(byte[], int, byte)` as suggested you'll end up with a sizeable improvement on non-latin1 cases too.

-------------

Changes requested by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/402

From jvernee at openjdk.java.net  Wed Nov 25 10:41:02 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 Nov 2020 10:41:02 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v6]
In-Reply-To: <FXDo44eJPhXSPyP_w_YAPPxF0lNW6Z3bqybOD2XSKa8=.d7cb0d1c-b0fe-4b2c-8b10-641711b6d0e7@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <8t9K2ZBTJu1RRsWncao3E7LHxKYnOvfwC2GigKsel1g=.970833fb-2560-4a13-9984-9082c4b40157@github.com>
 <FXDo44eJPhXSPyP_w_YAPPxF0lNW6Z3bqybOD2XSKa8=.d7cb0d1c-b0fe-4b2c-8b10-641711b6d0e7@github.com>
Message-ID: <YSJiAtxznlOx2_ci8_cwrNoc4bfWui-RfxiENv_PiP4=.5b6280de-69e8-4698-83dc-7ec628bbcd8d@github.com>

On Tue, 24 Nov 2020 23:59:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into Linker_32bit-fixes_Simpler
>>  - Remove JNI_ENTRY_CPP_NOENV
>>  - - Move reset_last_Java_frame
>>  - Use the Unimplemented() macro instead of hlt()
>>  - Merge branch 'master' into Linker_32bit-fixes_Simpler
>>  - Remove UnsupportedPlatform test
>>  - Remove unneeded cast
>>  - Remove Stuff that makes the jdk_foreign tests pass
>>  - fix test warnings
>>  - - Fix 32-bit build errors and tests
>>    - Add negative test for 32-bit platform.
>>    - Change CABI to fail more lazily when running on an unsupported platform.
>>    - Change CLinker layouts to be null on unsupported platforms, instead of failing when initializing the class
>>    - Added note to CLinker about failure to initialize on unsupported platforms
>
> src/hotspot/share/prims/universalUpcallHandler.cpp line 37:
> 
>> 35: 
>> 36: void ProgrammableUpcallHandler::upcall_helper(jobject rec, address buff) {
>> 37:   JavaThread* THREAD = JavaThread::current();
> 
> You could pass the current thread in rather than re-manifesting it.

Ah, of course. Will fix

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From mcimadamore at openjdk.java.net  Wed Nov 25 10:52:00 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 25 Nov 2020 10:52:00 GMT
Subject: Integrated: 8256865: Foreign Memory Access and Linker API are missing
 NPE checks
In-Reply-To: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
References: <47ZWNnG6fBMEF_Q4j_FVvfoR7tCHbsB9A0CcWV9wy6I=.e474824d-df97-42c7-b6da-88d487d162f3@github.com>
Message-ID: <ZvnGhO1IdPCuaE66Oe0wzA_AzpRD15lKtN5T0dJG1wI=.1addaf9c-9842-4b7f-a67f-649c17a5927b@github.com>

On Mon, 23 Nov 2020 15:11:49 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Both the Foreign Memory Access and the Foreign Linker APIs leave something to be desired when it comes to handling NPEs - first, most of the API javadoc is oblivious to NPEs being thrown. Secondly, not all API method implementations add expicit NPE checks - with the result of NPE often being thrown very deep in the call chain - if at all. Third, test for API coverage of nulls is ad-hoc.
> 
> This patch rectifies all these issues. To increase coverage for null injected into APIs, this patch introduces a new framework for testing an API in bulk, so that all methods are reflectively called with some values replaced with nulls, so that all combinations are tried.
> 
> I've also added, as part of this patch, a test to cover the statics in MemoryAccess which were not covered throughly.

This pull request has now been integrated.

Changeset: 9aeadbb0
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/9aeadbb0
Stats:     1021 lines in 36 files changed: 826 ins; 164 del; 31 mod

8256865: Foreign Memory Access and Linker API are missing NPE checks

Reviewed-by: jvernee, sundar, chegar

-------------

PR: https://git.openjdk.java.net/jdk/pull/1388

From pliden at openjdk.java.net  Wed Nov 25 11:07:59 2020
From: pliden at openjdk.java.net (Per Liden)
Date: Wed, 25 Nov 2020 11:07:59 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
Message-ID: <Z6gSbC7GtNrYToHiF695feYPQt687ouR7mMeyXtRbIU=.279b01f6-3ab4-4933-a3a3-d1fdd8fb6a9a@github.com>

On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
> 
> Initial patch was prepared by @fisk.
> 
> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
> 
> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.

src/hotspot/share/opto/library_call.cpp line 5525:

> 5523: Node* LibraryCallKit::load_field_from_object(Node* fromObj, const char* fieldName, const char* fieldTypeString,
> 5524:                                              DecoratorSet decorators = IN_HEAP, bool is_exact = false, bool is_static = false,
> 5525:                                              ciInstanceKlass* fromKls = NULL) {

It looks like the `is_exact` argument here can be removed, as all call-sites use the default value, which is `false`, and the only use of it in the function is this assert, which will never fail.
assert(!is_exact || tinst->klass_is_exact(), "klass not exact");

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From pliden at openjdk.java.net  Wed Nov 25 11:11:56 2020
From: pliden at openjdk.java.net (Per Liden)
Date: Wed, 25 Nov 2020 11:11:56 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
Message-ID: <19RAO8WaSz5jtGP-k8aNoHtNkWjVBFaa-QU97qHKmGc=.faf01bfc-7a71-45ee-b7e3-37aa2cc194d0@github.com>

On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
> 
> Initial patch was prepared by @fisk.
> 
> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
> 
> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.

ZGC changes look good!

-------------

Marked as reviewed by pliden (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1425

From jvernee at openjdk.java.net  Wed Nov 25 12:09:07 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 Nov 2020 12:09:07 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v7]
In-Reply-To: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
Message-ID: <Y24gSOMDZcZ8R4Wne89gp0pywJJLbe-zvRrzHc2J03k=.d29fb26f-7e3a-4531-bae3-d7eea4ae9d15@github.com>

> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
> 
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
> 
> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
> 
> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
> 
> Testing: `make images` on Linux and Windows x86_32 platforms.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Pass in thread instead of rematerializing it.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1266/files
  - new: https://git.openjdk.java.net/jdk/pull/1266/files/960021ba..c76286cd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=05-06

  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1266.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266

PR: https://git.openjdk.java.net/jdk/pull/1266

From vlivanov at openjdk.java.net  Wed Nov 25 12:19:01 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 25 Nov 2020 12:19:01 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v7]
In-Reply-To: <Y24gSOMDZcZ8R4Wne89gp0pywJJLbe-zvRrzHc2J03k=.d29fb26f-7e3a-4531-bae3-d7eea4ae9d15@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <Y24gSOMDZcZ8R4Wne89gp0pywJJLbe-zvRrzHc2J03k=.d29fb26f-7e3a-4531-bae3-d7eea4ae9d15@github.com>
Message-ID: <KVDzFwqYxwqkcNRHDRTcTIoe8Qz8kpIzm7G0AZo4sAg=.cb4b0483-20ff-4a2c-a851-bfc531635653@github.com>

On Wed, 25 Nov 2020 12:09:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
>> 
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
>> 
>> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
>> 
>> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
>> 
>> Testing: `make images` on Linux and Windows x86_32 platforms.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pass in thread instead of rematerializing it.

src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp line 33:

> 31: 
> 32: void ProgrammableInvoker::Generator::generate() {
> 33: #ifdef _LP64

Instead of introducing ifdefs, I'd prefer to see `universalNativeInvoker_x86.cpp` split into `universalNativeInvoker_x86_64.cpp` (current code) and `universalNativeInvoker_x86_32.cpp` (populated with dummy impelmentations).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From jvernee at openjdk.java.net  Wed Nov 25 12:31:59 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 Nov 2020 12:31:59 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v7]
In-Reply-To: <KVDzFwqYxwqkcNRHDRTcTIoe8Qz8kpIzm7G0AZo4sAg=.cb4b0483-20ff-4a2c-a851-bfc531635653@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <Y24gSOMDZcZ8R4Wne89gp0pywJJLbe-zvRrzHc2J03k=.d29fb26f-7e3a-4531-bae3-d7eea4ae9d15@github.com>
 <KVDzFwqYxwqkcNRHDRTcTIoe8Qz8kpIzm7G0AZo4sAg=.cb4b0483-20ff-4a2c-a851-bfc531635653@github.com>
Message-ID: <XVjQlfFp1LX5rXTdC6jseiTp0PwbVS6nBCgGM7lvExI=.d6012abb-b022-4208-b1af-dc52772785a9@github.com>

On Wed, 25 Nov 2020 12:16:01 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Pass in thread instead of rematerializing it.
>
> src/hotspot/cpu/x86/universalNativeInvoker_x86.cpp line 33:
> 
>> 31: 
>> 32: void ProgrammableInvoker::Generator::generate() {
>> 33: #ifdef _LP64
> 
> Instead of introducing ifdefs, I'd prefer to see `universalNativeInvoker_x86.cpp` split into `universalNativeInvoker_x86_64.cpp` (current code) and `universalNativeInvoker_x86_32.cpp` (populated with dummy impelmentations).

Yeah, makes sense. The old code had ifdefs, but splitting seems cleaner to me as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From jlahoda at openjdk.java.net  Wed Nov 25 12:43:59 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Wed, 25 Nov 2020 12:43:59 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com>
References: <zzcYXdqCn_Yqa41-F42wFVr3NWD5c1-_qrFtB9R_tmc=.3f017425-7178-44a7-ba82-599ac6da306a@github.com>
 <X7lXs0tULkwp6dM67oHD8HBn_z5HaGbePo30unGhDbc=.566b1f26-9888-4e1b-9cce-4ac5be762259@github.com>
 <3hcm-LPJG34kftsIY2_tgDJiPwuplmron5EQkJ4NT5s=.88ff5bc4-a2d8-4273-a958-e271aacd3358@github.com>
 <9wJGqoEIqSX2DDUO5Y8qxv3lvU5QhCgwox5wzApcXwM=.b7cd85fc-018f-4a70-93fb-32218b1babe5@github.com>
Message-ID: <o8euUFO4RVWh0WHVzhNfzLMWX79bYp4ZFnQYOtGhv1g=.57bdc5a7-a31c-4597-87ae-0369f5bbe036@github.com>

On Tue, 24 Nov 2020 23:00:05 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I agree.  This @apiNote needs more clarification to help the readers to understand the context here.    One thing we could do in the Package class description to add a "Package Sealing" section that can also explain that it has no relationship to "sealed classes".
>
> I added an API note in `Package::isSealed` [1] to clarify sealed package vs sealed class or interface.
> 
> The API note you added in `Class::isSealed` can be clarified in a similar fashion like: "Sealed class or interface has no relationship with {@linkplain Package#isSealed package sealing}".
> 
> [1] https://github.com/openjdk/jdk/commit/3c230b8a

Thanks for that update, Mandy! I've tweaked the API note as per your recommendation. I'll publish a fixed PR later, reflecting the other review comments as well.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1227

From chegar at openjdk.java.net  Wed Nov 25 12:50:01 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 25 Nov 2020 12:50:01 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark
Message-ID: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>

The ByteBuffers micro benchmark seems to be a little dated. 

It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 

This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 

1. Remove allocation from the individual benchmarks - it just creates noise. 
2. Consolidate per-thread shared heap and direct buffers. 
3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.

-------------

Commit messages:
 - Initial changes

Changes: https://git.openjdk.java.net/jdk/pull/1430/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257074
  Stats: 69 lines in 1 file changed: 22 ins; 14 del; 33 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1430.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1430/head:pull/1430

PR: https://git.openjdk.java.net/jdk/pull/1430

From jvernee at openjdk.java.net  Wed Nov 25 13:04:18 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 Nov 2020 13:04:18 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v8]
In-Reply-To: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
Message-ID: <NdxRHUaMTisROpBPbz54zi2pUSEE4tXl2sqy8FGmY3g=.476aa6dd-01d7-41fe-9f30-5a5e8e30029b@github.com>

> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
> 
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
> 
> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
> 
> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
> 
> Testing: `make images` on Linux and Windows x86_32 platforms.

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Split out 32-bit impl from native invoker and upcall handler

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1266/files
  - new: https://git.openjdk.java.net/jdk/pull/1266/files/c76286cd..b0edea8d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=06-07

  Stats: 72 lines in 4 files changed: 64 ins; 8 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1266.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266

PR: https://git.openjdk.java.net/jdk/pull/1266

From jlaskey at openjdk.java.net  Wed Nov 25 13:09:03 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 25 Nov 2020 13:09:03 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@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:

  8248862: Implement Enhanced Pseudo-Random Number Generators
  
  Changes to RandomGeneratorFactory requested by @PaulSandoz

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/9d6d1a94..802fa530

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=01-02

  Stats: 54 lines in 1 file changed: 23 ins; 7 del; 24 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 redestad at openjdk.java.net  Wed Nov 25 13:14:56 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Wed, 25 Nov 2020 13:14:56 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark
In-Reply-To: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
Message-ID: <yk4MuZpqsQoq09q_R7vz6Krt-x93O8T829nJlW0R-4I=.b677d091-11e9-4b64-8e83-ad04b650cfbe@github.com>

On Wed, 25 Nov 2020 12:41:40 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> The ByteBuffers micro benchmark seems to be a little dated. 
> 
> It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 
> 
> This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 
> 
> 1. Remove allocation from the individual benchmarks - it just creates noise. 
> 2. Consolidate per-thread shared heap and direct buffers. 
> 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
> 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.

Overall a reasonable clean-up.

I do wonder if there's some value to at least some of these noisy, allocating variants, though. Could be interesting to zoom in on code where we allocate transient, small buffers, e.g. when encoding/decoding strings. But perhaps that needs to be designed differently and focus on a specific use case.

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1430

From forax at univ-mlv.fr  Wed Nov 25 13:15:13 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Wed, 25 Nov 2020 14:15:13 +0100 (CET)
Subject: RFR: 8180352: Add Stream.toList() method [v4]
In-Reply-To: <ZrxAmREv9K_IaU4r6GjlkW4g363el_x9tukTBmqujNk=.c49835b8-18bf-4a1e-b3c5-a76f8dffaaa0@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <ZrxAmREv9K_IaU4r6GjlkW4g363el_x9tukTBmqujNk=.c49835b8-18bf-4a1e-b3c5-a76f8dffaaa0@github.com>
Message-ID: <478737514.2160840.1606310113526.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "Stuart Marks" <smarks at openjdk.java.net>
> ?: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Mardi 24 Novembre 2020 08:10:14
> Objet: Re: RFR: 8180352: Add Stream.toList() method [v4]

>> This change introduces a new terminal operation on Stream. This looks like a
>> convenience method for Stream.collect(Collectors.toList()) or
>> Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this
>> method directly on Stream enables it to do what can't easily by done by a
>> Collector. In particular, it allows the stream to deposit results directly into
>> a destination array (even in parallel) and have this array be wrapped in an
>> unmodifiable List without copying.
>> 
>> In the past we've kept most things from the Collections Framework as
>> implementations of Collector, not directly on Stream, whereas only fundamental
>> things (like toArray) appear directly on Stream. This is true of most
>> Collections, but it does seem that List is special. It can be a thin wrapper
>> around an array; it can handle generics better than arrays; and unlike an
>> array, it can be made unmodifiable (shallowly immutable); and it can be
>> value-based. See John Rose's comments in the bug report:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
>> 
>> This operation is null-tolerant, which matches the rest of Streams. This isn't
>> specified, though; a general statement about null handling in Streams is
>> probably warranted at some point.
>> 
>> Finally, this method is indeed quite convenient (if the caller can deal with
>> what this operation returns), as collecting into a List is the most common
>> stream terminal operation.
> 
> Stuart Marks has updated the pull request incrementally with one additional
> commit since the last revision:
> 
>  Add comment and assert regarding array class; use switch expression.
> 
> -------------

Hi Stuart,
This version is Ok for me.

I still think that using a null friendly List is a mistake, but you, Brian and John all think it's not an issue, so let's go with it.

> 
> Changes:
>  - all: https://git.openjdk.java.net/jdk/pull/1026/files
>  - new: https://git.openjdk.java.net/jdk/pull/1026/files/15beacd2..bd890ae5
> 
> Webrevs:
> - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1026&range=03
> - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1026&range=02-03
> 
>  Stats: 20 lines in 1 file changed: 4 ins; 4 del; 12 mod
>  Patch: https://git.openjdk.java.net/jdk/pull/1026.diff
>  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1026/head:pull/1026
> 
> PR: https://git.openjdk.java.net/jdk/pull/1026

From dfuchs at openjdk.java.net  Wed Nov 25 13:25:59 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 25 Nov 2020 13:25:59 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark
In-Reply-To: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
Message-ID: <cMishAxXDasFrQKhVQEICviT3pWSrWtf_LD00BTQRP0=.ba18d468-6172-4393-ae93-12af180555ee@github.com>

On Wed, 25 Nov 2020 12:41:40 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> The ByteBuffers micro benchmark seems to be a little dated. 
> 
> It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 
> 
> This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 
> 
> 1. Remove allocation from the individual benchmarks - it just creates noise. 
> 2. Consolidate per-thread shared heap and direct buffers. 
> 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
> 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.

I am not an expert in JMH microbenchmarks but the proposed changes look reasonable to me.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1430

From github.com+828220+forax at openjdk.java.net  Wed Nov 25 13:30:05 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 25 Nov 2020 13:30:05 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
Message-ID: <bc9zU1z9OG-lrEdOv4imfNqGRRiEtPafdgbhqBr-hmw=.da169e2a-8498-4dd4-97fe-378ae40f51f9@github.com>

On Wed, 25 Nov 2020 13:09:03 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:
> 
>   8248862: Implement Enhanced Pseudo-Random Number Generators
>   
>   Changes to RandomGeneratorFactory requested by @PaulSandoz

src/java.base/share/classes/java/security/SecureRandom.java line 223:

> 221:                 Map.entry(RandomGeneratorProperty.IS_HARDWARE, false)
> 222:         );
> 223:     }

Using Map.of() instead of Map.ofEntries() should simplify the code

src/java.base/share/classes/java/util/Random.java line 129:

> 127:                 Map.entry(RandomGeneratorProperty.IS_HARDWARE, false)
> 128:         );
> 129:     }

Using Map.of() should simplify the code

src/java.base/share/classes/java/util/SplittableRandom.java line 181:

> 179:                 Map.entry(RandomGeneratorProperty.IS_HARDWARE, false)
> 180:         );
> 181:     }

Using Map.of() should simplify the code

src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 169:

> 167:                 Map.entry(RandomGeneratorProperty.IS_STOCHASTIC, false),
> 168:                 Map.entry(RandomGeneratorProperty.IS_HARDWARE, false)
> 169:         );

Using Map.of() should simplify the code

src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 433:

> 431:     private static final class ThreadLocalRandomProxy extends Random {
> 432:         @java.io.Serial
> 433:         static final long serialVersionUID = 0L;

should be private

src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 444:

> 442:     }
> 443: 
> 444:     private static final AbstractSpliteratorGenerator proxy = new ThreadLocalRandomProxy();

should be declared inside ThreadLocalRandomProxy, so the value is only initialized when proxy() is called

src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 453:

> 451:      * @return a {@code RandomGenerator} object that uses {@code ThreadLocalRandom}
> 452:      */
> 453:     public static RandomGenerator proxy() {

proxy is a generic name, is there a better name here ?

src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 459:

> 457:     // Methods required by class AbstractSpliteratorGenerator
> 458:     public Spliterator.OfInt makeIntsSpliterator(long index, long fence, int origin, int bound) {
> 459:         return new RandomIntsSpliterator(proxy, index, fence, origin, bound);

should use proxy()

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From github.com+828220+forax at openjdk.java.net  Wed Nov 25 13:35:02 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 25 Nov 2020 13:35:02 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
Message-ID: <M0bnRytaaTuOAQy6-YuEnUH_P-Fxt6lwClr2TpGtTU8=.547b886c-50e9-4d7e-962e-7a2986eedcff@github.com>

On Wed, 25 Nov 2020 13:09:03 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:
> 
>   8248862: Implement Enhanced Pseudo-Random Number Generators
>   
>   Changes to RandomGeneratorFactory requested by @PaulSandoz

src/java.base/share/classes/java/util/random/RandomGenerator.java line 745:

> 743:      * if the period is unknown.
> 744:      */
> 745:     BigInteger UNKNOWN_PERIOD = BigInteger.ZERO;

move those 3 values into RandomGeneratorFactory ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From jvernee at openjdk.java.net  Wed Nov 25 13:36:03 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 Nov 2020 13:36:03 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark
In-Reply-To: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
Message-ID: <waKTIzjop1VihKHg6pAOO5roHuGHAHPVXPx870tprxk=.e0ee4043-7a45-421d-84f8-555bd3b4226e@github.com>

On Wed, 25 Nov 2020 12:41:40 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> The ByteBuffers micro benchmark seems to be a little dated. 
> 
> It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 
> 
> This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 
> 
> 1. Remove allocation from the individual benchmarks - it just creates noise. 
> 2. Consolidate per-thread shared heap and direct buffers. 
> 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
> 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.

Marked as reviewed by jvernee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1430

From chegar at openjdk.java.net  Wed Nov 25 13:36:04 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 25 Nov 2020 13:36:04 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark
In-Reply-To: <yk4MuZpqsQoq09q_R7vz6Krt-x93O8T829nJlW0R-4I=.b677d091-11e9-4b64-8e83-ad04b650cfbe@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
 <yk4MuZpqsQoq09q_R7vz6Krt-x93O8T829nJlW0R-4I=.b677d091-11e9-4b64-8e83-ad04b650cfbe@github.com>
Message-ID: <dB7U5Onu5f3lmd2r0VqqngaBYDdHuaxtVxzBOstpdb8=.7a7fca74-6d64-457d-aecc-5efbedf588a4@github.com>

On Wed, 25 Nov 2020 13:12:34 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> I do wonder if there's some value to at least some of these noisy, allocating variants, though. Could be interesting to zoom in on code where we allocate transient, small buffers, e.g. when encoding/decoding strings. But perhaps that needs to be designed differently and focus on a specific use case.

Yes, that is an interest case, but largely orthogonal to the primary use-case for this particular micro benchmark (or maybe; the primary use-case that I want to use this benchmark for ;-) ). It appears to me that the primary purpose is to evaluate the memory access operations, so I want to keep buffer allocation out of the picture.  Of course, we could decide to just create a new benchmark, but then I'm not sure what we'd use the old one for.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1430

From mcimadamore at openjdk.java.net  Wed Nov 25 13:41:00 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 25 Nov 2020 13:41:00 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark
In-Reply-To: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
Message-ID: <GjsMdKG5TePkOeS85xZBZSTVaX0vKvldPdnN0ozAI7w=.2987a4c0-13f7-4cdb-b503-238e4e9a3e31@github.com>

On Wed, 25 Nov 2020 12:41:40 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

> The ByteBuffers micro benchmark seems to be a little dated. 
> 
> It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 
> 
> This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 
> 
> 1. Remove allocation from the individual benchmarks - it just creates noise. 
> 2. Consolidate per-thread shared heap and direct buffers. 
> 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
> 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.

Looks like a good cleanup. I agree that mixing access and instantiation is not good from a benchmark perspective - although, given that direct buffers have a rather convoluted allocation process, I guess it would be useful, in the long term, to track performances of that too (this can be done by coupling direct buffer allocation with calls to Unsafe::invokeCleaner, so that the benchmark is not affected by the GC activity).

Also, given a carrier e.g. `float` there are at least two ways to get a float from a byte array:

* ByteBuffer::getFloat (both direct/heap)
* FloatBuffer::get() (both direct/heap)

The benchmark here focuses on the first bullet, but I think at some point we should also cover the remaining axis, so that, for each carrier, we really do at least 4 tests. Of course if you take into account swappiness for non-byte carriers, you get an extra variant for direct buffers as well, as you wanna test native endian vs. non-native endian.

So many possibilities :-)

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1430

From github.com+828220+forax at openjdk.java.net  Wed Nov 25 13:41:04 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 25 Nov 2020 13:41:04 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
Message-ID: <eEfD_8hmcNpV7AbwcDNt06UYvEMvEL5Nls2ANG6GeMw=.4983954f-9044-4e58-a77b-9d3636c7d09c@github.com>

On Wed, 25 Nov 2020 13:09:03 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:
> 
>   8248862: Implement Enhanced Pseudo-Random Number Generators
>   
>   Changes to RandomGeneratorFactory requested by @PaulSandoz

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 88:

> 86:  * <pre>{@code
> 87:  *     RandomGeneratorFactory<RandomGenerator> best = RandomGenerator.all()
> 88:  *         .sorted((f, g) -> Integer.compare(g.stateBits(), f.stateBits()))

use Comparator.comparingInt(RandomGenerator::stateBits) instead of the lambda

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 116:

> 114:      * Map of properties for provider.
> 115:      */
> 116:     private volatile Map<RandomGeneratorProperty, Object> properties = null;

`= null` is useless here

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 106:

> 104:      * Map of provider classes.
> 105:      */
> 106:     private static volatile Map<String, Provider<? extends RandomGenerator>> factoryMap;

should be FACTORY_MAP given that it's a static field

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From chegar at openjdk.java.net  Wed Nov 25 13:49:06 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 25 Nov 2020 13:49:06 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark
In-Reply-To: <GjsMdKG5TePkOeS85xZBZSTVaX0vKvldPdnN0ozAI7w=.2987a4c0-13f7-4cdb-b503-238e4e9a3e31@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
 <GjsMdKG5TePkOeS85xZBZSTVaX0vKvldPdnN0ozAI7w=.2987a4c0-13f7-4cdb-b503-238e4e9a3e31@github.com>
Message-ID: <nqDgktJPaPfsKa8lMzwMcxf_64YCW_1-25or3oDr-ic=.4f350908-e8e3-427a-a3aa-c0ebb7da6a4a@github.com>

On Wed, 25 Nov 2020 13:37:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Looks like a good cleanup. I agree that mixing access and instantiation is not good from a benchmark perspective - although, given that direct buffers have a rather convoluted allocation process, I guess it would be useful, in the long term, to track performances of that too (this can be done by coupling direct buffer allocation with calls to Unsafe::invokeCleaner, so that the benchmark is not affected by the GC activity).

I'll see if I can write a test for this.

> Also, given a carrier e.g. `float` there are at least two ways to get a float from a byte array:
> 
> * ByteBuffer::getFloat (both direct/heap)
> * FloatBuffer::get() (both direct/heap)
> 
> The benchmark here focuses on the first bullet, but I think at some point we should also cover the remaining axis, so that, for each carrier, we really do at least 4 tests. Of course if you take into account swappiness for non-byte carriers, you get an extra variant for direct buffers as well, as you wanna test native endian vs. non-native endian.

Yes, good observation - I had similar thoughts. Let me check if we could easily integrate some of these variants. What I'm trying to end up with is a comprehensive(ish) set of test scenarios that can be used to analyse performance ( of which views and endianness are important).

It may be reasonable for this particular benchmark to include views, etc, with appropriately named benchmark methods, so that one can easily run a subset, e.g. "org.openjdk.bench.java.nio.ByteBuffers.test(Direct)?(BulkPut|SinglePutByte)", when trying to "zoom in" on a specific code path.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1430

From github.com+828220+forax at openjdk.java.net  Wed Nov 25 13:54:05 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 25 Nov 2020 13:54:05 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
Message-ID: <_I5a2hVdcTFOW9m0hiZevWblT1ws6XTyTEiIVqobG5E=.2aa95467-1461-4445-9af8-c8ffe856e47e@github.com>

On Wed, 25 Nov 2020 13:09:03 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:
> 
>   8248862: Implement Enhanced Pseudo-Random Number Generators
>   
>   Changes to RandomGeneratorFactory requested by @PaulSandoz

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 151:

> 149:         if (fm == null) {
> 150:             synchronized (RandomGeneratorFactory.class) {
> 151:                 if (RandomGeneratorFactory.factoryMap == null) {

if `RandomGeneratorFactory.factoryMap` is not null, it returns null because the value is not stored in fm.

Please use the class holder idiom (cf Effective Java)  instead of using the double-check locking pattern.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 157:

> 155:                             .stream()
> 156:                             .filter(p -> !p.type().isInterface())
> 157:                             .collect(Collectors.toMap(p -> p.type().getSimpleName().toUpperCase(),

toUpperCase() depends on the Locale !

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 175:

> 173:         if (props == null) {
> 174:             synchronized (provider) {
> 175:                 if (properties == null) {

same issue with the double check locking

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 177:

> 175:                 if (properties == null) {
> 176:                     try {
> 177:                         Method getProperties = provider.type().getDeclaredMethod("getProperties");

Is it not a better way than using reflection here ?

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 180:

> 178:                         PrivilegedExceptionAction<Map<RandomGeneratorProperty, Object>> getAction = () -> {
> 179:                             getProperties.setAccessible(true);
> 180:                             return (Map<RandomGeneratorProperty, Object>)getProperties.invoke(null);

Given that we have no control over the fact that the method properties() doesn't return a Map of something else, this unsafe cast seems dangerous (from the type system POV).

Having a type representing a reified version of the Map may be a better idea

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From jlaskey at openjdk.java.net  Wed Nov 25 13:54:07 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 25 Nov 2020 13:54:07 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <bc9zU1z9OG-lrEdOv4imfNqGRRiEtPafdgbhqBr-hmw=.da169e2a-8498-4dd4-97fe-378ae40f51f9@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <bc9zU1z9OG-lrEdOv4imfNqGRRiEtPafdgbhqBr-hmw=.da169e2a-8498-4dd4-97fe-378ae40f51f9@github.com>
Message-ID: <J7z6VnCOqYu8Cmh-h2iPuL5QBw-bZ0VfXVw5RFlrWTU=.683cdc1f-49b9-409a-bd09-5b71c32e2e49@github.com>

On Wed, 25 Nov 2020 13:24:37 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8248862: Implement Enhanced Pseudo-Random Number Generators
>>   
>>   Changes to RandomGeneratorFactory requested by @PaulSandoz
>
> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 433:
> 
>> 431:     private static final class ThreadLocalRandomProxy extends Random {
>> 432:         @java.io.Serial
>> 433:         static final long serialVersionUID = 0L;
> 
> should be private

(instance?) agree

> src/java.base/share/classes/java/security/SecureRandom.java line 223:
> 
>> 221:                 Map.entry(RandomGeneratorProperty.IS_HARDWARE, false)
>> 222:         );
>> 223:     }
> 
> Using Map.of() instead of Map.ofEntries() should simplify the code

I had assumed  Map.ofEntries() was more efficient but it seems it in turn uses MapN as well. Will change these cases.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From jlaskey at openjdk.java.net  Wed Nov 25 14:04:08 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 25 Nov 2020 14:04:08 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <M0bnRytaaTuOAQy6-YuEnUH_P-Fxt6lwClr2TpGtTU8=.547b886c-50e9-4d7e-962e-7a2986eedcff@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <M0bnRytaaTuOAQy6-YuEnUH_P-Fxt6lwClr2TpGtTU8=.547b886c-50e9-4d7e-962e-7a2986eedcff@github.com>
Message-ID: <6GrCVkOLBO0i67Fuw_NPXWzZ49D0fsfLpHNI_NZRHDg=.97fda7db-4d50-4fa2-8062-c2f10396d589@github.com>

On Wed, 25 Nov 2020 13:31:52 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8248862: Implement Enhanced Pseudo-Random Number Generators
>>   
>>   Changes to RandomGeneratorFactory requested by @PaulSandoz
>
> src/java.base/share/classes/java/util/random/RandomGenerator.java line 745:
> 
>> 743:      * if the period is unknown.
>> 744:      */
>> 745:     BigInteger UNKNOWN_PERIOD = BigInteger.ZERO;
> 
> move those 3 values into RandomGeneratorFactory ?

Will ponder on this one. I tend to agree with you since they are most likely to be used for filtering factories RandomGeneratorFactory querying was a later development. period() originally was a RandomGenerator query, but got moved when more queries were added. This will require a CSR and will come later.

> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 444:
> 
>> 442:     }
>> 443: 
>> 444:     private static final AbstractSpliteratorGenerator proxy = new ThreadLocalRandomProxy();
> 
> should be declared inside ThreadLocalRandomProxy, so the value is only initialized when proxy() is called

agree

> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 453:
> 
>> 451:      * @return a {@code RandomGenerator} object that uses {@code ThreadLocalRandom}
>> 452:      */
>> 453:     public static RandomGenerator proxy() {
> 
> proxy is a generic name, is there a better name here ?

will investigate

> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 459:
> 
>> 457:     // Methods required by class AbstractSpliteratorGenerator
>> 458:     public Spliterator.OfInt makeIntsSpliterator(long index, long fence, int origin, int bound) {
>> 459:         return new RandomIntsSpliterator(proxy, index, fence, origin, bound);
> 
> should use proxy()

will investigate

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From github.com+828220+forax at openjdk.java.net  Wed Nov 25 14:04:02 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 25 Nov 2020 14:04:02 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
Message-ID: <3qYZQ8Bnkp26ReuTglCIHf6SZ7RFEIQty9sBsNDJhxk=.e2036b7c-abf7-4c55-8fc6-23dee9c4dc72@github.com>

On Wed, 25 Nov 2020 13:09:03 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:
> 
>   8248862: Implement Enhanced Pseudo-Random Number Generators
>   
>   Changes to RandomGeneratorFactory requested by @PaulSandoz

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 235:

> 233:             throws IllegalArgumentException {
> 234:         Map<String, Provider<? extends RandomGenerator>> fm = getFactoryMap();
> 235:         Provider<? extends RandomGenerator> provider = fm.get(name.toUpperCase());

again use of toUpperCase() instead of toUpperCase(Locale)

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 250:

> 248:      * @return Stream of matching Providers.
> 249:      */
> 250:     static <T extends RandomGenerator> Stream<RandomGeneratorFactory<T>> all(Class<? extends RandomGenerator> category) {

this signature is weird, T is not used in the parameter, so in case return any type of Stream<RandomGeneratorFactory<T>> from a type POV, should it be
` <T extends RandomGenerator> Stream<RandomGeneratorFactory<T>> all(Class<? extends T> category)` instead ?

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 269:

> 267:      * @throws IllegalArgumentException when either the name or category is null
> 268:      */
> 269:     static <T> T of(String name, Class<? extends RandomGenerator> category)

Same issue as above, T is not used as a constraint

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 288:

> 286:      * @throws IllegalArgumentException when either the name or category is null
> 287:      */
> 288:     static <T extends RandomGenerator> RandomGeneratorFactory<T> factoryOf(String name, Class<? extends RandomGenerator> category)

Same as above

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 300:

> 298:      */
> 299:     @SuppressWarnings("unchecked")
> 300:     private void getConstructors(Class<? extends RandomGenerator> randomGeneratorClass) {

method name get but do side effects

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From plevart at openjdk.java.net  Wed Nov 25 14:10:03 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 25 Nov 2020 14:10:03 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v4]
In-Reply-To: <5Z9HS6uHE3BQxPEpqsWtEsRZIXOM6NUdPN2BRs6lx0Y=.14a9075a-289a-44c8-8902-2cca976225fd@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <3N2Oa4dVVDShlyR-w1G8jWG7mNPL5utzKFdm0QWkM3Y=.0cee9962-8dfb-40f3-b9ae-e50ea8377ed3@github.com>
 <zUyJi1Y8IGbR3Hv50ZWy1OS0oqFycWzHLP7iVECLTec=.2b79a385-c78d-46b3-9b4b-2d5d7bc2d071@github.com>
 <nYmGmOTAId25YFeWQ0PJkB7j658prrjepUr8q9k7kUI=.ba169da0-e72b-4a16-9639-9c301b3d58bc@github.com>
 <Oxn7CirvPu4wJ2jdOQzjOT_KHZB6uZAcuHHQSdrQrWA=.07c41bdd-9fed-4cfc-bfec-3c0076266ffc@github.com>
 <5Z9HS6uHE3BQxPEpqsWtEsRZIXOM6NUdPN2BRs6lx0Y=.14a9075a-289a-44c8-8902-2cca976225fd@github.com>
Message-ID: <J3Ed-nWa30Jz5DtGKSOTu6bA69OBaF5rcJL1-D3ZSiY=.95ceb273-92de-441e-aa82-5046e32a17b8@github.com>

On Tue, 24 Nov 2020 03:46:38 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> In `ReferencePipeline` class we have:
>> 
>>     @Override
>>     public final Object[] toArray() {
>>         return toArray(Object[]::new);
>>     }
>> 
>>     @Override
>>     @SuppressWarnings("unchecked")
>>     public final <A> A[] toArray(IntFunction<A[]> generator) {
>>         ...
>>         @SuppressWarnings("rawtypes")
>>         IntFunction rawGenerator = (IntFunction) generator;
>>         return (A[]) Nodes.flatten(evaluateToArrayNode(rawGenerator), rawGenerator)
>>                               .asArray(rawGenerator);
>>     }
>> 
>> 
>> In `Nodes` class we have:
>> 
>> 
>>     public static <T> Node<T> flatten(Node<T> node, IntFunction<T[]> generator) {
>>         if (node.getChildCount() > 0) {
>>             ... 
>>             T[] array = generator.apply((int) size);
>>             new ToArrayTask.OfRef<>(node, array, 0).invoke();
>>             return node(array);
>>         } else {
>>             return node;
>>         }
>>     }
>> 
>> 
>> 
>> It looks like it is required to implement `toList` method in a similar way in order to avoid array copy. i.e. there will be `IntFunction<List<T>> generator` which will generate 'ArrayList' with specified size and the list's `add` method will be called to add elements to the list.
>
> This is the default implementation in the Stream interface, which is overridden by an implementation in the ReferencePipeline class, so it will rarely be used in normal operation. The ReferencePipeline version (part of this changeset) is based on toArray() and avoids any copying. I'm thus not inclined to add new interfaces in order to support this default implementation.
> 
> As written it's true that the default implementation does perform apparently redundant copies, but we can't be assured that toArray() actually returns a freshly created array. Thus, we wrap it using Arrays.asList and then copy it using the ArrayList constructor. This is unfortunate but necessary to avoid situations where someone could hold a reference to the internal array of a List, allowing modification of a List that's supposed to be unmodifiable.

An alternative with similar performance would be to do a Stream.toArray() and then copy that array into new Object[] and then wrap that copy with listFromTrustedArrayNullsAllowed(). The difference would be in the serialization format of the resulting List and maybe also in the access performance of resulting List (no indirection via the unmodifiableList wrapper and different type for JIT to speculate about). So if we want the resulting List to behave exactly the same in both implementations of toList(), then this alternative might be preferable. WDYT?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1026

From github.com+828220+forax at openjdk.java.net  Wed Nov 25 14:16:05 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 25 Nov 2020 14:16:05 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
Message-ID: <TTJDYGNjz8D1miykGB3imf4k_Hm2W_nWLRA4HfDpImQ=.a4715d2d-d5ed-4d29-985d-ab28a056f9ce@github.com>

On Wed, 25 Nov 2020 13:09:03 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:
> 
>   8248862: Implement Enhanced Pseudo-Random Number Generators
>   
>   Changes to RandomGeneratorFactory requested by @PaulSandoz

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 335:

> 333:                         ctorBytes = tmpCtorBytes;
> 334:                         ctorLong = tmpCtorLong;
> 335:                         ctor = tmpCtor;

This one is a volatile write, so the idea is that ctorBytes and ctorLong does not need to be volatile too, which i think is not true if there is a code somewhere that uses ctorBytes or ctorLong without reading ctor.
This code is too smart for me, i'm pretty sure it is wrong too on non TSO cpu.

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 480:

> 478:         } catch (Exception ex) {
> 479:             // Should never happen.
> 480:             throw new IllegalStateException("Random algorithm " + name() + " is missing a default constructor");

chain the exception ...

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 497:

> 495:             ensureConstructors();
> 496:             return ctorLong.newInstance(seed);
> 497:         } catch (Exception ex) {

this one is very dubious because the result in an exception is thrown is a random generator with the wrong seed

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 517:

> 515:             ensureConstructors();
> 516:             return ctorBytes.newInstance((Object)seed);
> 517:         } catch (Exception ex) {

same as above

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From github.com+828220+forax at openjdk.java.net  Wed Nov 25 14:19:02 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 25 Nov 2020 14:19:02 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
Message-ID: <LRBogL2R7DxnUrcUem3ewE17aRuljl4UlEZS3dW7Mko=.d61114e3-2f10-469a-8cc4-5e8561d2e687@github.com>

On Wed, 25 Nov 2020 13:09:03 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:
> 
>   8248862: Implement Enhanced Pseudo-Random Number Generators
>   
>   Changes to RandomGeneratorFactory requested by @PaulSandoz

src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 46:

> 44: import java.util.stream.Stream;
> 45: import jdk.internal.util.random.RandomSupport.RandomGeneratorProperty;
> 46: 

Instead of calling a method properties to create a Map, it's usually far easier to use an annotation,
annotation values supports less runtime type so BigInteger is not supported but using a String instead should be OK.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From vsharma at openjdk.java.net  Wed Nov 25 14:33:58 2020
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Wed, 25 Nov 2020 14:33:58 GMT
Subject: RFR: JDK-8253936 Replace <code>...</code> with {@code ...} for
 java.sql [v2]
In-Reply-To: <MBfAaQ9Kxqy4D1Il0qH7198245SVKLLZJuvkim5_Yhs=.1e8ae75b-7ba4-4144-ae14-3a40fcde9d38@github.com>
References: <zr8HOhlJbmboYIC-rVP0S3Mj5FeXOI4lzlUXvL2XMoc=.f173b3a1-f879-458c-9450-c432cecb6d6f@github.com>
 <oHk3etlLv_g3kGgBAhDDxKEtnxdkc7OI-GYr80DT7bg=.8b95b585-5e91-4c7d-84f1-173f70eab910@github.com>
 <MBfAaQ9Kxqy4D1Il0qH7198245SVKLLZJuvkim5_Yhs=.1e8ae75b-7ba4-4144-ae14-3a40fcde9d38@github.com>
Message-ID: <Y4bz0ljF3Aq6omGb0UWyO5V3xCk-DSefP3O82YYSzbQ=.7fade04f-05fd-41ba-89c7-ad865951829c@github.com>

On Wed, 4 Nov 2020 19:29:34 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Vipin Sharma has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated copyright year and other issues reporrted in review
>
> Marked as reviewed by lancea (Reviewer).

I think all steps are completed for this PR, please help sponsoring this.

-------------

PR: https://git.openjdk.java.net/jdk/pull/707

From eosterlund at openjdk.java.net  Wed Nov 25 15:09:59 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 25 Nov 2020 15:09:59 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <eii_10yXpbYt_nO7dGdFZwrST-VIHDA4daqP18j7vsQ=.9f0d0b90-cd00-40d9-b0d1-5f3ab1b835f9@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <ssQOmnlQu04qaYJ59KeBoFbDw0euJik6v-zQfIAI-6Y=.3614f99b-28ac-42e0-981e-bd832ddc7963@github.com>
 <sXTEsyp2rmnjflwD931rs9r1S8oExGm3N7YTTj0O5Uo=.e802d936-a753-4fe7-bec5-c6a24d82a45f@github.com>
 <eii_10yXpbYt_nO7dGdFZwrST-VIHDA4daqP18j7vsQ=.9f0d0b90-cd00-40d9-b0d1-5f3ab1b835f9@github.com>
Message-ID: <36Kj4FuE21c-OU5VhIWXbBvHqRTh5T3TrQSs7J1LJqw=.ea8ac32f-6646-4125-b11c-d3263134faf0@github.com>

On Wed, 25 Nov 2020 10:01:15 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> The information that there was a barrier attached, is implicit in the ins_encode block due to it being run at all. In other words, since we matched the mach node to our ZGC access instead of a normal access, we already know that there was barrier data attached, and that we no longer have such barrier data.
>
> Ok, makes sense. What do you think about making `ZLoadBarrierElided = 0` then?

I'm okay with that. I don't have a strong preference.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From alanb at openjdk.java.net  Wed Nov 25 15:14:09 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 25 Nov 2020 15:14:09 GMT
Subject: RFR: 8253751: Dependencies of automatic modules are not propagated
 through module layers
Message-ID: <n98SGqqXdl4g8mQ4BAIfRhcIgjQZPcn-qQUdrTTKqc8=.48ffe4f9-5b67-48fc-871d-ad0328493dfd@github.com>

This is a corner case that arises when creating a Configuration for a child module layer. If an explicit module in the child configuration reads an automatic module in a parent configuration then it should read all automatic modules in the parent configurations. Unfortunately, this read edge wasn't created for the case that the child layer does not contain any automatic modules.

-------------

Commit messages:
 - Merge
 - Merge
 - Add @bug to test
 - Fixed typo in comment
 - Merge
 - Merge
 - If module reads automatic module in parent configuration then reads all automatic modules

Changes: https://git.openjdk.java.net/jdk/pull/1391/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1391&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8253751
  Stats: 86 lines in 2 files changed: 76 ins; 5 del; 5 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1391.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1391/head:pull/1391

PR: https://git.openjdk.java.net/jdk/pull/1391

From eosterlund at openjdk.java.net  Wed Nov 25 15:16:02 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 25 Nov 2020 15:16:02 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <ssQOmnlQu04qaYJ59KeBoFbDw0euJik6v-zQfIAI-6Y=.3614f99b-28ac-42e0-981e-bd832ddc7963@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <ssQOmnlQu04qaYJ59KeBoFbDw0euJik6v-zQfIAI-6Y=.3614f99b-28ac-42e0-981e-bd832ddc7963@github.com>
Message-ID: <2cJwK-GzCQ5fcT333q5GZPSlz5t7ghs4Bg5YGzCOwjA=.a577266a-6730-4cde-9b46-5953e800ef9e@github.com>

On Wed, 25 Nov 2020 08:43:04 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
>> 
>> Initial patch was prepared by @fisk.
>> 
>> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
>> 
>> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.
>
> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 623:
> 
>> 621:   // Also we need to add memory barrier to prevent commoning reads
>> 622:   // from this field across safepoint since GC can change its value.
>> 623:   bool need_read_barrier = (((on_weak || on_phantom) && !no_keepalive) ||
> 
> There's a slight change: `in_heap && (on_weak || ...)` turns into `(on_weak ...) || (in_heap ...)`. It will introduce  a read barrier for `!in_heap && on_weak` case. Does it occur in practice?
> 
> Another one: `on_weak` turns into ((on_weak ...) && !no_keepalive). 
> My interpretation is no read barrier needed when `NO_KEEPALIVE` flag is used and currently a redundant barrier is issued. 
> 
> Maybe replace `!no_keepalive` with just `keep_alive`? The former is harder to parse.
> 
> The check grows bigger and bigger. Maybe it's time to split it?
> 
> Turn `on_weak || on_phantom` into `!is_strong`?

I don't think we have any !in_heap && on_weak loads today. But if we did, they would indeed need read barriers.
We need read barrier if the the reference isn't provably strong... unless it's an AS_NO_KEEPALIVE access. That also reflects why the variable is called no_keepalive instead of keepalive; it is to reflect the shared decorator name used all over the place. I don't mind inverting it though, but personally found it easier to read when the names match our decorators.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From jlaskey at openjdk.java.net  Wed Nov 25 15:46:00 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 25 Nov 2020 15:46:00 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <6GrCVkOLBO0i67Fuw_NPXWzZ49D0fsfLpHNI_NZRHDg=.97fda7db-4d50-4fa2-8062-c2f10396d589@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <M0bnRytaaTuOAQy6-YuEnUH_P-Fxt6lwClr2TpGtTU8=.547b886c-50e9-4d7e-962e-7a2986eedcff@github.com>
 <6GrCVkOLBO0i67Fuw_NPXWzZ49D0fsfLpHNI_NZRHDg=.97fda7db-4d50-4fa2-8062-c2f10396d589@github.com>
Message-ID: <n86RqLcHxXHwtBHZ3zd9-zq9LS8NID4GAvKTy6-tqXs=.02703ae2-6624-45fa-9c85-2233da1b15c7@github.com>

On Wed, 25 Nov 2020 13:55:52 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 453:
>> 
>>> 451:      * @return a {@code RandomGenerator} object that uses {@code ThreadLocalRandom}
>>> 452:      */
>>> 453:     public static RandomGenerator proxy() {
>> 
>> proxy is a generic name, is there a better name here ?
>
> will investigate

agree

>> src/java.base/share/classes/java/util/concurrent/ThreadLocalRandom.java line 459:
>> 
>>> 457:     // Methods required by class AbstractSpliteratorGenerator
>>> 458:     public Spliterator.OfInt makeIntsSpliterator(long index, long fence, int origin, int bound) {
>>> 459:         return new RandomIntsSpliterator(proxy, index, fence, origin, bound);
>> 
>> should use proxy()
>
> will investigate

Needed to use ThreadLocalRandomProxy.proxy otherwise a cast would be required.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From jlaskey at openjdk.java.net  Wed Nov 25 16:03:04 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 25 Nov 2020 16:03:04 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <eEfD_8hmcNpV7AbwcDNt06UYvEMvEL5Nls2ANG6GeMw=.4983954f-9044-4e58-a77b-9d3636c7d09c@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <eEfD_8hmcNpV7AbwcDNt06UYvEMvEL5Nls2ANG6GeMw=.4983954f-9044-4e58-a77b-9d3636c7d09c@github.com>
Message-ID: <K8uDaN2A6snfGYW0qaFgygHWCan0UY_ZIrlpSNitRs0=.80541689-e340-486d-a3e4-00b684333198@github.com>

On Wed, 25 Nov 2020 13:37:02 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8248862: Implement Enhanced Pseudo-Random Number Generators
>>   
>>   Changes to RandomGeneratorFactory requested by @PaulSandoz
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 88:
> 
>> 86:  * <pre>{@code
>> 87:  *     RandomGeneratorFactory<RandomGenerator> best = RandomGenerator.all()
>> 88:  *         .sorted((f, g) -> Integer.compare(g.stateBits(), f.stateBits()))
> 
> use Comparator.comparingInt(RandomGenerator::stateBits) instead of the lambda

Not sure that `.sorted(Comparator.comparingInt(RandomGeneratorFactory<RandomGenerator>::stateBits).reversed())` is simpler than  `.sorted((f, g) -> Integer.compare(g.stateBits(), f.stateBits()))`.

> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 116:
> 
>> 114:      * Map of properties for provider.
>> 115:      */
>> 116:     private volatile Map<RandomGeneratorProperty, Object> properties = null;
> 
> `= null` is useless here

agree

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From vsharma at openjdk.java.net  Wed Nov 25 16:05:01 2020
From: vsharma at openjdk.java.net (Vipin Sharma)
Date: Wed, 25 Nov 2020 16:05:01 GMT
Subject: Integrated: JDK-8253936 Replace <code>...</code> with {@code ...} for
 java.sql
In-Reply-To: <zr8HOhlJbmboYIC-rVP0S3Mj5FeXOI4lzlUXvL2XMoc=.f173b3a1-f879-458c-9450-c432cecb6d6f@github.com>
References: <zr8HOhlJbmboYIC-rVP0S3Mj5FeXOI4lzlUXvL2XMoc=.f173b3a1-f879-458c-9450-c432cecb6d6f@github.com>
Message-ID: <U7tNNcPygVIm4u2HBQrFSzhALwL2iJS14_PT7uHmhW8=.583ef294-58ea-47a5-858b-d532c93ed523@github.com>

On Fri, 16 Oct 2020 19:38:45 GMT, Vipin Sharma <vsharma at openjdk.org> wrote:

> <code>...</code> is replaced with {@code ...} in java.sql classes.
> Please review and sponsor this change.

This pull request has now been integrated.

Changeset: dee79d60
Author:    Vipin Sharma <vsharma at openjdk.org>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/dee79d60
Stats:     4698 lines in 58 files changed: 0 ins; 0 del; 4698 mod

8253936: Replace <code>...</code> with {@code ...} for java.sql

Reviewed-by: lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/707

From github.com+828220+forax at openjdk.java.net  Wed Nov 25 16:26:03 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 25 Nov 2020 16:26:03 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <n86RqLcHxXHwtBHZ3zd9-zq9LS8NID4GAvKTy6-tqXs=.02703ae2-6624-45fa-9c85-2233da1b15c7@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <M0bnRytaaTuOAQy6-YuEnUH_P-Fxt6lwClr2TpGtTU8=.547b886c-50e9-4d7e-962e-7a2986eedcff@github.com>
 <6GrCVkOLBO0i67Fuw_NPXWzZ49D0fsfLpHNI_NZRHDg=.97fda7db-4d50-4fa2-8062-c2f10396d589@github.com>
 <n86RqLcHxXHwtBHZ3zd9-zq9LS8NID4GAvKTy6-tqXs=.02703ae2-6624-45fa-9c85-2233da1b15c7@github.com>
Message-ID: <MsOlimXJyF2THyYTudxqmFFOaG-f-W0IFpYy2aJXwyk=.b297a082-a205-4324-8f28-3d42f2805635@github.com>

On Wed, 25 Nov 2020 15:43:39 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> will investigate
>
> Needed to use ThreadLocalRandomProxy.proxy otherwise a cast would be required.

yes, right !

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From jlaskey at openjdk.java.net  Wed Nov 25 16:26:02 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 25 Nov 2020 16:26:02 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <eEfD_8hmcNpV7AbwcDNt06UYvEMvEL5Nls2ANG6GeMw=.4983954f-9044-4e58-a77b-9d3636c7d09c@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <eEfD_8hmcNpV7AbwcDNt06UYvEMvEL5Nls2ANG6GeMw=.4983954f-9044-4e58-a77b-9d3636c7d09c@github.com>
Message-ID: <p0tr1oZbMe6qlj4MPZKqiqWIBKtEgORqxyJHWOVIFn0=.f8b5e2ed-2304-476e-8e4c-1ad35bd7e80d@github.com>

On Wed, 25 Nov 2020 13:38:59 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8248862: Implement Enhanced Pseudo-Random Number Generators
>>   
>>   Changes to RandomGeneratorFactory requested by @PaulSandoz
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 106:
> 
>> 104:      * Map of provider classes.
>> 105:      */
>> 106:     private static volatile Map<String, Provider<? extends RandomGenerator>> factoryMap;
> 
> should be FACTORY_MAP given that it's a static field

will fall out of using  class holder idiom

> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 151:
> 
>> 149:         if (fm == null) {
>> 150:             synchronized (RandomGeneratorFactory.class) {
>> 151:                 if (RandomGeneratorFactory.factoryMap == null) {
> 
> if `RandomGeneratorFactory.factoryMap` is not null, it returns null because the value is not stored in fm.
> 
> Please use the class holder idiom (cf Effective Java)  instead of using the double-check locking pattern.

? set in 148 and 152, but  class holder idiom +1

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From github.com+828220+forax at openjdk.java.net  Wed Nov 25 16:28:58 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 25 Nov 2020 16:28:58 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <K8uDaN2A6snfGYW0qaFgygHWCan0UY_ZIrlpSNitRs0=.80541689-e340-486d-a3e4-00b684333198@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <eEfD_8hmcNpV7AbwcDNt06UYvEMvEL5Nls2ANG6GeMw=.4983954f-9044-4e58-a77b-9d3636c7d09c@github.com>
 <K8uDaN2A6snfGYW0qaFgygHWCan0UY_ZIrlpSNitRs0=.80541689-e340-486d-a3e4-00b684333198@github.com>
Message-ID: <4scjt1TdYV9Z6bN6YheIELaKERWLpvqE_fyR9bMNPEE=.c986e3d1-6a62-42c2-b087-4e7d47850ffb@github.com>

On Wed, 25 Nov 2020 15:59:01 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 88:
>> 
>>> 86:  * <pre>{@code
>>> 87:  *     RandomGeneratorFactory<RandomGenerator> best = RandomGenerator.all()
>>> 88:  *         .sorted((f, g) -> Integer.compare(g.stateBits(), f.stateBits()))
>> 
>> use Comparator.comparingInt(RandomGenerator::stateBits) instead of the lambda
>
> Not sure that `.sorted(Comparator.comparingInt(RandomGeneratorFactory<RandomGenerator>::stateBits).reversed())` is simpler than  `.sorted((f, g) -> Integer.compare(g.stateBits(), f.stateBits()))`.

At least, it's more clear that it's reversed, i've initially miss the fact that f and g are swapped.
And :: is able to do inference so, i believe it can be written
  `.sorted(Comparator.comparingInt(RandomGeneratorFactory::stateBits).reversed())`

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From github.com+828220+forax at openjdk.java.net  Wed Nov 25 16:32:03 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 25 Nov 2020 16:32:03 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <p0tr1oZbMe6qlj4MPZKqiqWIBKtEgORqxyJHWOVIFn0=.f8b5e2ed-2304-476e-8e4c-1ad35bd7e80d@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <eEfD_8hmcNpV7AbwcDNt06UYvEMvEL5Nls2ANG6GeMw=.4983954f-9044-4e58-a77b-9d3636c7d09c@github.com>
 <p0tr1oZbMe6qlj4MPZKqiqWIBKtEgORqxyJHWOVIFn0=.f8b5e2ed-2304-476e-8e4c-1ad35bd7e80d@github.com>
Message-ID: <_2MGrO5lSf9qR4OHLxci2tlDMjJlvAKu6m-n7XYPJO0=.84e85b82-8670-4c78-8842-04dace3a3d55@github.com>

On Wed, 25 Nov 2020 16:22:34 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 151:
>> 
>>> 149:         if (fm == null) {
>>> 150:             synchronized (RandomGeneratorFactory.class) {
>>> 151:                 if (RandomGeneratorFactory.factoryMap == null) {
>> 
>> if `RandomGeneratorFactory.factoryMap` is not null, it returns null because the value is not stored in fm.
>> 
>> Please use the class holder idiom (cf Effective Java)  instead of using the double-check locking pattern.
>
> ? set in 148 and 152, but  class holder idiom +1

If the second `RandomGeneratorFactory.factoryMap` return a non null value ...

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From jvernee at openjdk.java.net  Wed Nov 25 16:33:01 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 Nov 2020 16:33:01 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v6]
In-Reply-To: <FXDo44eJPhXSPyP_w_YAPPxF0lNW6Z3bqybOD2XSKa8=.d7cb0d1c-b0fe-4b2c-8b10-641711b6d0e7@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <8t9K2ZBTJu1RRsWncao3E7LHxKYnOvfwC2GigKsel1g=.970833fb-2560-4a13-9984-9082c4b40157@github.com>
 <FXDo44eJPhXSPyP_w_YAPPxF0lNW6Z3bqybOD2XSKa8=.d7cb0d1c-b0fe-4b2c-8b10-641711b6d0e7@github.com>
Message-ID: <ojvYVWGOk-3jc81xqt4pgXZyLO7x6zT9atUL18gmG1Q=.64a663cb-049e-41e6-96bb-7c4dd9a93a13@github.com>

On Wed, 25 Nov 2020 00:01:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into Linker_32bit-fixes_Simpler
>>  - Remove JNI_ENTRY_CPP_NOENV
>>  - - Move reset_last_Java_frame
>>  - Use the Unimplemented() macro instead of hlt()
>>  - Merge branch 'master' into Linker_32bit-fixes_Simpler
>>  - Remove UnsupportedPlatform test
>>  - Remove unneeded cast
>>  - Remove Stuff that makes the jdk_foreign tests pass
>>  - fix test warnings
>>  - - Fix 32-bit build errors and tests
>>    - Add negative test for 32-bit platform.
>>    - Change CABI to fail more lazily when running on an unsupported platform.
>>    - Change CLinker layouts to be null on unsupported platforms, instead of failing when initializing the class
>>    - Added note to CLinker about failure to initialize on unsupported platforms
>
> The VM "entry" changes seem better now. Thanks.
> 
> The use of CATCH as a safety-net is also good.

I've applied open comments. Please let me know if this is ok to merge.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From prappo at openjdk.java.net  Wed Nov 25 16:35:59 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 Nov 2020 16:35:59 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <s2nlMsXWZrXzqbsEp4FwssS7ChjkXB-YZpChXpLTVcU=.52de8d3b-b5e5-4f38-9182-9c75fb5e52b1@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
 <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
 <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
 <TFCxfLxB7_iDyPbbSXJtWZZm4HOW_n4R66vMnNEzYvI=.1659cc00-17c8-4999-bbb7-b5c7516599b7@github.com>
 <pvwIoAweUPTqGrO7Hxx5VxCbdlEI6-S83rLfRyNmySo=.106ee077-43e3-48a7-8a05-181986e5606b@github.com>
 <BV5JY8q6TzUEtFvidfqWgj09YEYZVvKYPrZgnlrqgQ0=.fc07a453-fafe-4fe6-95f5-4c7613818eff@github.com>
 <s2nlMsXWZrXzqbsEp4FwssS7ChjkXB-YZpChXpLTVcU=.52de8d3b-b5e5-4f38-9182-9c75fb5e52b1@github.com>
Message-ID: <vc_4vd3n6PJ_l0h-8rqF4JOjPyWlFB263Pe35_FHH2Q=.40b49d77-b2d6-4917-b86d-e76232b3df5e@github.com>

On Wed, 25 Nov 2020 06:19:04 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>>> The proposed CSR has a few problems that we need to resolve.
>>> 
>>> 1. The **Specification** pseudo-code behaves differently from both the old pseudo-code and the actual implementation when `newValue == null && oldValue == null` and `map.containsKey(key) == true`.
>>> 2. The content of the **Solution** section seems irrelevant: aside from a couple of missing `return` statements the current pseudo-code is fine. We are after something else, aren't we? The bottom line is we should state the solution more clearly.
>>> 3. The **Summary** section differs from that of the JDK-8247402.
>> 
>> I read my previous reply and realized that it is confusing and contains a factual error; so let me straighten it out in this new reply rather than edit that previous one.
>> 
>> 1. The proposed pseudo-code behaves exactly the same way as the existing pseudo-code modulo the missing `return` statements. (For some reason, I previously wrote that the proposed pseudo-code behaves differently from the existing pseudo-code.)
>> 2. Both the proposed pseudo-code and the existing pseudo-code deviate from the documented behaviour (written in prose) and the actual implementation. The deviation happens when `newValue == null && (oldValue = map.get(key)) == null` and `map.containsKey(key) == true`. (That part was correct.)
>> 
>> Now, here's what I should have said in my previous reply. If the CSR intends to solve (2) then both the proposed pseudo-code and the **Problem** section must be updated; otherwise the **Solution** section must be updated. Put differently, either fix the diff and add one more item to that problem list, or change the solution. Otherwise the solution does not match the problem leaving the CSR in a contradictory state.
>> 
>> I hope this all makes sense now.
>
>> 2. Both the proposed pseudo-code and the existing pseudo-code deviate from the documented behaviour (written in prose) and the actual implementation.
> 
> Let me clarify something. The "documented behavior" is actually the API specification, the contract that applies to Map.compute and all its implementations. The pseudo-code is part of the "implementation requirements" section, whose primary responsibility is to specify what the default implementation actually does. (Of course, that implementation should also conform to the API spec.)
> 
> We've established that the pseudo-code -- either the existing or proposed version -- differs from the default implementation's actual behavior. It's thus failed its primary responsibility, and therefore that's the problem that needs to be fixed. I think it's pointless to clean up the pseudo-code if the result is still incorrect.

@stuart-marks I thought about it before reading your reply. And since I hadn't come to a definite conclusion, I worded my response to @johnlinp as a choice.

Although in this particular case it's easy to fix the discrepancy, I think it raises a general question which applies to all (pseudo-) code snippets in normative parts of API specifications:

**What is the required level of fidelity particular (pseudo-) code has to have?**

It's such a huge topic for discussion, that I don't even know where to begin; certainly, not in this PR thread. Perhaps we should start a dedicated (non-RFR/PR) thread on one of the OpenJDK mailing lists to host that discussion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From prappo at openjdk.java.net  Wed Nov 25 16:41:57 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Wed, 25 Nov 2020 16:41:57 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <TFCxfLxB7_iDyPbbSXJtWZZm4HOW_n4R66vMnNEzYvI=.1659cc00-17c8-4999-bbb7-b5c7516599b7@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
 <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
 <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
 <TFCxfLxB7_iDyPbbSXJtWZZm4HOW_n4R66vMnNEzYvI=.1659cc00-17c8-4999-bbb7-b5c7516599b7@github.com>
Message-ID: <m03pV9naVWuHcK_vDJPmbc475it1Z0rtCATTwsIOp3s=.ee0b9cf3-1bd3-4351-a40d-f19bd20850bd@github.com>

On Sat, 21 Nov 2020 09:21:06 GMT, John Lin <github.com+1290376+johnlinp at openjdk.org> wrote:

>> @johnlinp, you cannot create a CSR by yourself at the moment. Someone else will have to do that for you. Might as well be me. So here's my proposal: come up with the meat, then I'll help you with the paperwork. 
>> 
>> For starters, have a look at existing CSRs (you don't need a JBS account for that). For example, https://bugs.openjdk.java.net/issues/?jql=issuetype%3DCSR%20and%20Subcomponent%3Djava.util%3Acollections%20
>> 
>> Fill in an informal CSR template inline in this thread, and we'll proceed from that point. Is that okay?
>
> @pavelrappo Please see my proposed CSR below. Thank you.
> 
> # Map::compute should have a clearer implementation requirement.
> 
> ## Summary
> 
> java.util.Map::compute should have a clearer implementation requirement in its documentation.
> 
> ## Problem
> 
> The documentation of the implementation requirements for Map::compute has the following problems:
> 1. It lacks of return statements for most of the if-else cases.
> 1. The indents are 3 spaces, while the convention is 4 spaces.
> 1. The if-else is overly complicated and can be simplified.
> 
> ## Solution
> 
> Rewrite the documentation of Map::compute to match its default implementation.
> 
> ## Specification
> 
> diff --git a/src/java.base/share/classes/java/util/Map.java b/src/java.base/share/classes/java/util/Map.java
> index b1de34b42a5..c3118a90581 100644
> --- a/src/java.base/share/classes/java/util/Map.java
> +++ b/src/java.base/share/classes/java/util/Map.java
> @@ -1113,17 +1113,12 @@ public interface Map<K, V> {
>       * <pre> {@code
>       * V oldValue = map.get(key);
>       * V newValue = remappingFunction.apply(key, oldValue);
> -     * if (oldValue != null) {
> -     *    if (newValue != null)
> -     *       map.put(key, newValue);
> -     *    else
> -     *       map.remove(key);
> -     * } else {
> -     *    if (newValue != null)
> -     *       map.put(key, newValue);
> -     *    else
> -     *       return null;
> +     * if (newValue != null) {
> +     *     map.put(key, newValue);
> +     * } else if (oldValue != null) {
> +     *     map.remove(key);
>       * }
> +     * return newValue;
>       * }</pre>
>       *
>       * <p>The default implementation makes no guarantees about detecting if the

@johnlinp In any case, you'd also need to update the surrounding prose; we need to remove this:
 returning the current value or {@code null} if absent:```

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From shade at openjdk.java.net  Wed Nov 25 17:07:57 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 25 Nov 2020 17:07:57 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v6]
In-Reply-To: <ojvYVWGOk-3jc81xqt4pgXZyLO7x6zT9atUL18gmG1Q=.64a663cb-049e-41e6-96bb-7c4dd9a93a13@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <8t9K2ZBTJu1RRsWncao3E7LHxKYnOvfwC2GigKsel1g=.970833fb-2560-4a13-9984-9082c4b40157@github.com>
 <FXDo44eJPhXSPyP_w_YAPPxF0lNW6Z3bqybOD2XSKa8=.d7cb0d1c-b0fe-4b2c-8b10-641711b6d0e7@github.com>
 <ojvYVWGOk-3jc81xqt4pgXZyLO7x6zT9atUL18gmG1Q=.64a663cb-049e-41e6-96bb-7c4dd9a93a13@github.com>
Message-ID: <LGfu1GZgfijJUEL_eYHgc_48YxqGlQ_WzdoGn97TzcQ=.39a99ca2-2883-4be3-ac99-b286d8a6821e@github.com>

On Wed, 25 Nov 2020 16:30:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> The VM "entry" changes seem better now. Thanks.
>> 
>> The use of CATCH as a safety-net is also good.
>
> I've applied open comments. Please let me know if this is ok to merge.

Still looks fine to me. Merge from master to get the fixes for GH actions failures, #1427

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From jvernee at openjdk.java.net  Wed Nov 25 17:14:08 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 Nov 2020 17:14:08 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v9]
In-Reply-To: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
Message-ID: <bpA6dTCysMPKj7QTyD-ywLpmYhNGhzp__J496luVuUI=.0edb94d5-db06-49e5-83f9-2345006f715c@github.com>

> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
> 
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
> 
> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
> 
> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
> 
> Testing: `make images` on Linux and Windows x86_32 platforms.

Jorn Vernee has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Merge branch 'master' into Linker_32bit-fixes_New-Master
 - Split out 32-bit impl from native invoker and upcall handler
 - Pass in thread instead of rematerializing it.
 - Merge branch 'master' into Linker_32bit-fixes_Simpler
 - Remove JNI_ENTRY_CPP_NOENV
 - - Move reset_last_Java_frame
 - Use the Unimplemented() macro instead of hlt()
 - Merge branch 'master' into Linker_32bit-fixes_Simpler
 - Remove UnsupportedPlatform test
 - Remove unneeded cast
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/461c5fc6...5e664033

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1266/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1266&range=08
  Stats: 88 lines in 12 files changed: 45 ins; 27 del; 16 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1266.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1266/head:pull/1266

PR: https://git.openjdk.java.net/jdk/pull/1266

From jlaskey at openjdk.java.net  Wed Nov 25 17:15:05 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 25 Nov 2020 17:15:05 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <_I5a2hVdcTFOW9m0hiZevWblT1ws6XTyTEiIVqobG5E=.2aa95467-1461-4445-9af8-c8ffe856e47e@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <_I5a2hVdcTFOW9m0hiZevWblT1ws6XTyTEiIVqobG5E=.2aa95467-1461-4445-9af8-c8ffe856e47e@github.com>
Message-ID: <f__djLlpmmbB7VMVyw8T75F8a6ykBPP2KoWg6JDEb-0=.9f56d91e-dac4-4530-ac42-307c4a8c58ff@github.com>

On Wed, 25 Nov 2020 13:45:46 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8248862: Implement Enhanced Pseudo-Random Number Generators
>>   
>>   Changes to RandomGeneratorFactory requested by @PaulSandoz
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 157:
> 
>> 155:                             .stream()
>> 156:                             .filter(p -> !p.type().isInterface())
>> 157:                             .collect(Collectors.toMap(p -> p.type().getSimpleName().toUpperCase(),
> 
> toUpperCase() depends on the Locale !

It was a lame thing to do anyway - removed

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From plevart at openjdk.java.net  Wed Nov 25 17:17:57 2020
From: plevart at openjdk.java.net (Peter Levart)
Date: Wed, 25 Nov 2020 17:17:57 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v4]
In-Reply-To: <J3Ed-nWa30Jz5DtGKSOTu6bA69OBaF5rcJL1-D3ZSiY=.95ceb273-92de-441e-aa82-5046e32a17b8@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <3N2Oa4dVVDShlyR-w1G8jWG7mNPL5utzKFdm0QWkM3Y=.0cee9962-8dfb-40f3-b9ae-e50ea8377ed3@github.com>
 <zUyJi1Y8IGbR3Hv50ZWy1OS0oqFycWzHLP7iVECLTec=.2b79a385-c78d-46b3-9b4b-2d5d7bc2d071@github.com>
 <nYmGmOTAId25YFeWQ0PJkB7j658prrjepUr8q9k7kUI=.ba169da0-e72b-4a16-9639-9c301b3d58bc@github.com>
 <Oxn7CirvPu4wJ2jdOQzjOT_KHZB6uZAcuHHQSdrQrWA=.07c41bdd-9fed-4cfc-bfec-3c0076266ffc@github.com>
 <5Z9HS6uHE3BQxPEpqsWtEsRZIXOM6NUdPN2BRs6lx0Y=.14a9075a-289a-44c8-8902-2cca976225fd@github.com>
 <J3Ed-nWa30Jz5DtGKSOTu6bA69OBaF5rcJL1-D3ZSiY=.95ceb273-92de-441e-aa82-5046e32a17b8@github.com>
Message-ID: <r9Cg-BheUapolt4t-O_9E-oHCEAXYglKWggy0JGsStc=.16bcd50e-e3a0-47af-9010-e4f957992fde@github.com>

On Wed, 25 Nov 2020 14:07:07 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> This is the default implementation in the Stream interface, which is overridden by an implementation in the ReferencePipeline class, so it will rarely be used in normal operation. The ReferencePipeline version (part of this changeset) is based on toArray() and avoids any copying. I'm thus not inclined to add new interfaces in order to support this default implementation.
>> 
>> As written it's true that the default implementation does perform apparently redundant copies, but we can't be assured that toArray() actually returns a freshly created array. Thus, we wrap it using Arrays.asList and then copy it using the ArrayList constructor. This is unfortunate but necessary to avoid situations where someone could hold a reference to the internal array of a List, allowing modification of a List that's supposed to be unmodifiable.
>
> An alternative with similar performance would be to do a Stream.toArray() and then copy that array into new Object[] and then wrap that copy with listFromTrustedArrayNullsAllowed(). The difference would be in the serialization format of the resulting List and maybe also in the access performance of resulting List (no indirection via the unmodifiableList wrapper and different type for JIT to speculate about). So if we want the resulting List to behave exactly the same in both implementations of toList(), then this alternative might be preferable. WDYT?

Such alternative might also be faster using intrisified array copying method (here measuring just copying overhead):

Benchmark              (len)  Mode  Cnt       Score      Error  Units
ToListBench.toList1       10  avgt   10      14.213 ?    0.061  ns/op
ToListBench.toList1     1000  avgt   10     541.883 ?    3.845  ns/op
ToListBench.toList1  1000000  avgt   10  753223.523 ? 4656.664  ns/op
ToListBench.toList2       10  avgt   10       8.810 ?    0.052  ns/op
ToListBench.toList2     1000  avgt   10     264.748 ?    0.807  ns/op
ToListBench.toList2  1000000  avgt   10  349518.502 ? 3242.061  ns/op

https://gist.github.com/plevart/974b67b65210f8dd122773f481c0a603

-------------

PR: https://git.openjdk.java.net/jdk/pull/1026

From vlivanov at openjdk.java.net  Wed Nov 25 17:32:58 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Wed, 25 Nov 2020 17:32:58 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v6]
In-Reply-To: <LGfu1GZgfijJUEL_eYHgc_48YxqGlQ_WzdoGn97TzcQ=.39a99ca2-2883-4be3-ac99-b286d8a6821e@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <8t9K2ZBTJu1RRsWncao3E7LHxKYnOvfwC2GigKsel1g=.970833fb-2560-4a13-9984-9082c4b40157@github.com>
 <FXDo44eJPhXSPyP_w_YAPPxF0lNW6Z3bqybOD2XSKa8=.d7cb0d1c-b0fe-4b2c-8b10-641711b6d0e7@github.com>
 <ojvYVWGOk-3jc81xqt4pgXZyLO7x6zT9atUL18gmG1Q=.64a663cb-049e-41e6-96bb-7c4dd9a93a13@github.com>
 <LGfu1GZgfijJUEL_eYHgc_48YxqGlQ_WzdoGn97TzcQ=.39a99ca2-2883-4be3-ac99-b286d8a6821e@github.com>
Message-ID: <A_67RK6iuxSjFvPL4VsfHRPn7pzyLUuvuIzdg5XH0ik=.8d90a3d7-5367-4028-a964-ba5c7ac83128@github.com>

On Wed, 25 Nov 2020 17:05:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I've applied open comments. Please let me know if this is ok to merge.
>
> Still looks fine to me. Merge from master to get the fixes for GH actions failures, #1427

Thanks, Jorn. The split looks good.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From kvn at openjdk.java.net  Wed Nov 25 17:43:59 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 25 Nov 2020 17:43:59 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <36Kj4FuE21c-OU5VhIWXbBvHqRTh5T3TrQSs7J1LJqw=.ea8ac32f-6646-4125-b11c-d3263134faf0@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <ssQOmnlQu04qaYJ59KeBoFbDw0euJik6v-zQfIAI-6Y=.3614f99b-28ac-42e0-981e-bd832ddc7963@github.com>
 <sXTEsyp2rmnjflwD931rs9r1S8oExGm3N7YTTj0O5Uo=.e802d936-a753-4fe7-bec5-c6a24d82a45f@github.com>
 <eii_10yXpbYt_nO7dGdFZwrST-VIHDA4daqP18j7vsQ=.9f0d0b90-cd00-40d9-b0d1-5f3ab1b835f9@github.com>
 <36Kj4FuE21c-OU5VhIWXbBvHqRTh5T3TrQSs7J1LJqw=.ea8ac32f-6646-4125-b11c-d3263134faf0@github.com>
Message-ID: <u26-mcaAvEpGmjNTthw2UwL9hB_1wLVoopWjMYH7TRU=.e1f63901-4ca8-4f14-89cc-f411dd980ae7@github.com>

On Wed, 25 Nov 2020 15:07:21 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> Ok, makes sense. What do you think about making `ZLoadBarrierElided = 0` then?
>
> I'm okay with that. I don't have a strong preference.

I also prefer to have ZLoadBarrierElided = 0. I will add it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From kvn at openjdk.java.net  Wed Nov 25 17:43:58 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 25 Nov 2020 17:43:58 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <pqmsF7Mx61UWgVx3CFnQ4Ig1izW62Q57HjGLsGi9gxU=.1c99d0d0-9f2a-4cd5-9424-ffefe0402bd7@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <pspRmZwTOM4regwd75Q_BmGyycgXq6T2PcVy3cJb4UI=.f21fefa8-ffc8-44c1-9de9-a4de40ae6796@github.com>
 <pqmsF7Mx61UWgVx3CFnQ4Ig1izW62Q57HjGLsGi9gxU=.1c99d0d0-9f2a-4cd5-9424-ffefe0402bd7@github.com>
Message-ID: <V_dEkCX15vyytjQWg80_QVHlDj7EMNeJ4_-7_6vlU9k=.43975876-29e2-4ba4-a259-c36a2561a602@github.com>

On Wed, 25 Nov 2020 08:18:23 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> src/hotspot/share/opto/c2compiler.cpp line 476:
>> 
>>> 474:     if (UseCompressedOops && UseShenandoahGC) return false;
>>> 475: #endif
>>> 476:     break;
>> 
>> Is this intended to disable the intrinsic on all non-64-bit platforms? Is that only for Shenandoah 64-bit? I wonder if it should just be:
>> 
>>   case vmIntrinsics::_PhantomReference_refersTo0:
>>     if (UseCompressedOops && UseShenandoahGC) return false;
>>     break;
>
> Considering `UseCompressedOops` doesn't make much sense in 32-bit mode and is set to `false`, it seems `#ifdef` can be just dropped.

You are right. I thought flag UseCompressedOops is defined only in 64-bit  VM.
@shipilev, #ifdef was placed incorrectly - it should be after `case:`. But as you both pointed, it is not needed. I will remove it.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From kvn at openjdk.java.net  Wed Nov 25 17:44:01 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 25 Nov 2020 17:44:01 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <Z6gSbC7GtNrYToHiF695feYPQt687ouR7mMeyXtRbIU=.279b01f6-3ab4-4933-a3a3-d1fdd8fb6a9a@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <Z6gSbC7GtNrYToHiF695feYPQt687ouR7mMeyXtRbIU=.279b01f6-3ab4-4933-a3a3-d1fdd8fb6a9a@github.com>
Message-ID: <GzrjeWMV7OttkGfokC7eJ07OpdpANzMW2R4BUWp-OOA=.24664073-03ef-4c0b-8d0e-0de6c990ab70@github.com>

On Wed, 25 Nov 2020 11:05:39 GMT, Per Liden <pliden at openjdk.org> wrote:

>> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
>> 
>> Initial patch was prepared by @fisk.
>> 
>> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
>> 
>> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.
>
> src/hotspot/share/opto/library_call.cpp line 5525:
> 
>> 5523: Node* LibraryCallKit::load_field_from_object(Node* fromObj, const char* fieldName, const char* fieldTypeString,
>> 5524:                                              DecoratorSet decorators = IN_HEAP, bool is_exact = false, bool is_static = false,
>> 5525:                                              ciInstanceKlass* fromKls = NULL) {
> 
> It looks like the `is_exact` argument here can be removed, as all call-sites use the default value, which is `false`, and the only use of it in the function is this assert, which will never fail.
> assert(!is_exact || tinst->klass_is_exact(), "klass not exact");

Good suggestion.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From kvn at openjdk.java.net  Wed Nov 25 17:51:59 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 25 Nov 2020 17:51:59 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <19RAO8WaSz5jtGP-k8aNoHtNkWjVBFaa-QU97qHKmGc=.faf01bfc-7a71-45ee-b7e3-37aa2cc194d0@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <19RAO8WaSz5jtGP-k8aNoHtNkWjVBFaa-QU97qHKmGc=.faf01bfc-7a71-45ee-b7e3-37aa2cc194d0@github.com>
Message-ID: <Rs1J7EfhWAcfA5GzuJCJnX24MNNdEr1Et8mAPUutVMk=.ae473190-a72b-4964-b052-e87332d65fa9@github.com>

On Wed, 25 Nov 2020 11:09:05 GMT, Per Liden <pliden at openjdk.org> wrote:

>> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
>> 
>> Initial patch was prepared by @fisk.
>> 
>> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
>> 
>> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.
>
> ZGC changes look good!

> I just pulled the fresh master, applied this patch on top, enabled `_PhantomReference_refersTo0` in `c2compiler.cpp`, and ran `CONF=linux-x86_64-server-fastdebug make images run-test TEST=tier1 TEST_VM_OPTS="-XX:+UseShenandoahGC"` without problems.
> 
> @vnkozlov, what Shenandoah failure did you see? Attention @rkennke.

@shipilev 2 new tests added by JDK-8188055 does not trigger C2 compilation.
You need to run my new test to trigger problem I see:

java -Xbatch -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:+UseShenandoahGC TestReferenceRefersTo.java

#  Internal Error (/open/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp:999), pid=2498681, tid=2498694
#  assert(!is_narrow) failed: phantom access cannot be narrow
#
# JRE version: Java(TM) SE Runtime Environment (16.0) (fastdebug build 16-internal+0-2020-11-24)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 16-internal+0-2020-11-24, mixed mode, sharing, compressed oops, shenandoah gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1862090]  ShenandoahBarrierC2Support::call_lrb_stub(Node*&, Node*&, Node*, Node*&, Node*, unsigned long, PhaseIdealLoop*)+0x7e0

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From kvn at openjdk.java.net  Wed Nov 25 18:11:00 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 25 Nov 2020 18:11:00 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <2cJwK-GzCQ5fcT333q5GZPSlz5t7ghs4Bg5YGzCOwjA=.a577266a-6730-4cde-9b46-5953e800ef9e@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <ssQOmnlQu04qaYJ59KeBoFbDw0euJik6v-zQfIAI-6Y=.3614f99b-28ac-42e0-981e-bd832ddc7963@github.com>
 <2cJwK-GzCQ5fcT333q5GZPSlz5t7ghs4Bg5YGzCOwjA=.a577266a-6730-4cde-9b46-5953e800ef9e@github.com>
Message-ID: <YYWYze2QzeCKmEq_rRCJxIqn3_fEtIau2JWgJNtW-uE=.fdd56d6c-52f7-4042-b8bd-02eb7a39e34d@github.com>

On Wed, 25 Nov 2020 15:13:11 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/c2/g1BarrierSetC2.cpp line 623:
>> 
>>> 621:   // Also we need to add memory barrier to prevent commoning reads
>>> 622:   // from this field across safepoint since GC can change its value.
>>> 623:   bool need_read_barrier = (((on_weak || on_phantom) && !no_keepalive) ||
>> 
>> There's a slight change: `in_heap && (on_weak || ...)` turns into `(on_weak ...) || (in_heap ...)`. It will introduce  a read barrier for `!in_heap && on_weak` case. Does it occur in practice?
>> 
>> Another one: `on_weak` turns into ((on_weak ...) && !no_keepalive). 
>> My interpretation is no read barrier needed when `NO_KEEPALIVE` flag is used and currently a redundant barrier is issued. 
>> 
>> Maybe replace `!no_keepalive` with just `keep_alive`? The former is harder to parse.
>> 
>> The check grows bigger and bigger. Maybe it's time to split it?
>> 
>> Turn `on_weak || on_phantom` into `!is_strong`?
>
> I don't think we have any !in_heap && on_weak loads today. But if we did, they would indeed need read barriers.
> We need read barrier if the the reference isn't provably strong... unless it's an AS_NO_KEEPALIVE access. That also reflects why the variable is called no_keepalive instead of keepalive; it is to reflect the shared decorator name used all over the place. I don't mind inverting it though, but personally found it easier to read when the names match our decorators.

>From this conversation the only change I can do is 'Turn (on_weak || on_phantom) into !on_strong'.
@fisk Is this correct? I am concern that it will include `unknown` decorator too.
I agree with Erik to keep !no_keepalive because he prefer it and this is code supported by GC group.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From jvernee at openjdk.java.net  Wed Nov 25 18:13:00 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 Nov 2020 18:13:00 GMT
Subject: Integrated: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
In-Reply-To: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
Message-ID: <RofIdmPZmFFB_puSmGl9DH4ZFLGy0vhXyUwoKF-bL2E=.233288c0-089d-4070-87be-51414079eb8e@github.com>

On Tue, 17 Nov 2020 17:19:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
> 
> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
> 
> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
> 
> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
> 
> Testing: `make images` on Linux and Windows x86_32 platforms.

This pull request has now been integrated.

Changeset: 7c73fff3
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/7c73fff3
Stats:     88 lines in 12 files changed: 45 ins; 27 del; 16 mod

8256486: Linux/Windows-x86 builds broken after JDK-8254231

Reviewed-by: shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From jvernee at openjdk.java.net  Wed Nov 25 18:18:09 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 Nov 2020 18:18:09 GMT
Subject: RFR: 8256862: Several java/foreign tests fail on x86_32 platforms
Message-ID: <a8o0qUQOUKj4jXMh4w-6STR-QDjBgwbbInH0D3Rdo8Q=.9ab0359f-5fa0-47d1-ad97-a236063442b0@github.com>

This patch fixes several failures on x86_32 of java/foreign tests.

This is mostly done by disabling the failing tests, but the impl of CLinker is also adjusted ton properly detect 32 bit platforms as unsupported.

CLinker is specified to fail in the initializer on unsupported platforms, and a test is added to verify this as well.

Note that this adds requires clauses to the failing tests that explicitly enumerate all available platforms, so this should fix the test failures on other platforms as well.

https://bugs.openjdk.java.net/browse/JDK-8256757 is filed for the remaining failure in TestStringLatin1IndexOfChar.

CSR link: https://bugs.openjdk.java.net/browse/JDK-8256863

-------------

Commit messages:
 - Enumerate supported platforms specifically in requires tags
 - Clarify CLinker statement about unsupported platforms
 - - Add negative test for 32-bit platform.

Changes: https://git.openjdk.java.net/jdk/pull/1386/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1386&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256862
  Stats: 94 lines in 20 files changed: 83 ins; 0 del; 11 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1386.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1386/head:pull/1386

PR: https://git.openjdk.java.net/jdk/pull/1386

From eosterlund at openjdk.java.net  Wed Nov 25 18:36:54 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Wed, 25 Nov 2020 18:36:54 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <YYWYze2QzeCKmEq_rRCJxIqn3_fEtIau2JWgJNtW-uE=.fdd56d6c-52f7-4042-b8bd-02eb7a39e34d@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <ssQOmnlQu04qaYJ59KeBoFbDw0euJik6v-zQfIAI-6Y=.3614f99b-28ac-42e0-981e-bd832ddc7963@github.com>
 <2cJwK-GzCQ5fcT333q5GZPSlz5t7ghs4Bg5YGzCOwjA=.a577266a-6730-4cde-9b46-5953e800ef9e@github.com>
 <YYWYze2QzeCKmEq_rRCJxIqn3_fEtIau2JWgJNtW-uE=.fdd56d6c-52f7-4042-b8bd-02eb7a39e34d@github.com>
Message-ID: <Atf_e_uIFUV7C0gMzsVLXMGUL_iXFgwYu0uFlKaTXuE=.5261d72f-fc9e-4990-a0f9-b5e644990a89@github.com>

On Wed, 25 Nov 2020 18:07:34 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> I don't think we have any !in_heap && on_weak loads today. But if we did, they would indeed need read barriers.
>> We need read barrier if the the reference isn't provably strong... unless it's an AS_NO_KEEPALIVE access. That also reflects why the variable is called no_keepalive instead of keepalive; it is to reflect the shared decorator name used all over the place. I don't mind inverting it though, but personally found it easier to read when the names match our decorators.
>
> From this conversation the only change I can do is 'Turn (on_weak || on_phantom) into !on_strong'.
> @fisk Is this correct? I am concern that it will include `unknown` decorator too.
> I agree with Erik to keep !no_keepalive because he prefer it and this is code supported by GC group.

Well if on_weak || on_phantom then it is provably a weak access. But I think the absence of the strong decorator does not prove it is weak, as it could have an unknown strength (via unsafe), in which case we need some extra logic to see if we can prove that an unknown strength access can't be weak.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From smarks at openjdk.java.net  Wed Nov 25 19:08:03 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 25 Nov 2020 19:08:03 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <m03pV9naVWuHcK_vDJPmbc475it1Z0rtCATTwsIOp3s=.ee0b9cf3-1bd3-4351-a40d-f19bd20850bd@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
 <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
 <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
 <TFCxfLxB7_iDyPbbSXJtWZZm4HOW_n4R66vMnNEzYvI=.1659cc00-17c8-4999-bbb7-b5c7516599b7@github.com>
 <m03pV9naVWuHcK_vDJPmbc475it1Z0rtCATTwsIOp3s=.ee0b9cf3-1bd3-4351-a40d-f19bd20850bd@github.com>
Message-ID: <cFfnvRrX6Flsj8XZcYxTWD_adHXBwqKEGaGnrOD4OUM=.c4dca349-abe3-455a-b686-3a39036e1eec@github.com>

On Wed, 25 Nov 2020 16:39:20 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> @pavelrappo Please see my proposed CSR below. Thank you.
>> 
>> # Map::compute should have a clearer implementation requirement.
>> 
>> ## Summary
>> 
>> java.util.Map::compute should have a clearer implementation requirement in its documentation.
>> 
>> ## Problem
>> 
>> The documentation of the implementation requirements for Map::compute has the following problems:
>> 1. It lacks of return statements for most of the if-else cases.
>> 1. The indents are 3 spaces, while the convention is 4 spaces.
>> 1. The if-else is overly complicated and can be simplified.
>> 
>> ## Solution
>> 
>> Rewrite the documentation of Map::compute to match its default implementation.
>> 
>> ## Specification
>> 
>> diff --git a/src/java.base/share/classes/java/util/Map.java b/src/java.base/share/classes/java/util/Map.java
>> index b1de34b42a5..c3118a90581 100644
>> --- a/src/java.base/share/classes/java/util/Map.java
>> +++ b/src/java.base/share/classes/java/util/Map.java
>> @@ -1113,17 +1113,12 @@ public interface Map<K, V> {
>>       * <pre> {@code
>>       * V oldValue = map.get(key);
>>       * V newValue = remappingFunction.apply(key, oldValue);
>> -     * if (oldValue != null) {
>> -     *    if (newValue != null)
>> -     *       map.put(key, newValue);
>> -     *    else
>> -     *       map.remove(key);
>> -     * } else {
>> -     *    if (newValue != null)
>> -     *       map.put(key, newValue);
>> -     *    else
>> -     *       return null;
>> +     * if (newValue != null) {
>> +     *     map.put(key, newValue);
>> +     * } else if (oldValue != null) {
>> +     *     map.remove(key);
>>       * }
>> +     * return newValue;
>>       * }</pre>
>>       *
>>       * <p>The default implementation makes no guarantees about detecting if the
>
> @johnlinp In any case, you'd also need to update the surrounding prose; we need to remove this:
>  returning the current value or {@code null} if absent:```

@pavelrappo 

> What is the required level of fidelity particular (pseudo-) code has to have?

It's potentially a large discussion, one that could be had in the context of my JEP draft http://openjdk.java.net/jeps/8068562 . However, speaking practically, it's possible to focus the discussion fairly concisely: the main responsibility of the `@implSpec` ("Implementation Requirements") section is to give implementors of subclasses enough information to decide whether to inherit the implementation or to override it, and if they override it, what behavior they can expect if they were to call `super.compute`.

In this case, a null-value-tolerating Map implementation needs to know that the default implementation calls `remove` in the particular case that you mentioned. A concurrent Map implementation will also need to know that the default implementation calls `get(key)` and `containsKey(key)` at different times, potentially leading to a race condition. Both of these inform the override vs. inherit decision.

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From jlaskey at openjdk.java.net  Wed Nov 25 19:21:02 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 25 Nov 2020 19:21:02 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <3qYZQ8Bnkp26ReuTglCIHf6SZ7RFEIQty9sBsNDJhxk=.e2036b7c-abf7-4c55-8fc6-23dee9c4dc72@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <3qYZQ8Bnkp26ReuTglCIHf6SZ7RFEIQty9sBsNDJhxk=.e2036b7c-abf7-4c55-8fc6-23dee9c4dc72@github.com>
Message-ID: <dyR9D6ARFeV12XZxZ0IFNUwGwdZvHk7TdB-c6tpWfpE=.0bf34de8-165e-46b6-83fb-2a2bb89fecde@github.com>

On Wed, 25 Nov 2020 13:54:47 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8248862: Implement Enhanced Pseudo-Random Number Generators
>>   
>>   Changes to RandomGeneratorFactory requested by @PaulSandoz
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 235:
> 
>> 233:             throws IllegalArgumentException {
>> 234:         Map<String, Provider<? extends RandomGenerator>> fm = getFactoryMap();
>> 235:         Provider<? extends RandomGenerator> provider = fm.get(name.toUpperCase());
> 
> again use of toUpperCase() instead of toUpperCase(Locale)

removed

> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 250:
> 
>> 248:      * @return Stream of matching Providers.
>> 249:      */
>> 250:     static <T extends RandomGenerator> Stream<RandomGeneratorFactory<T>> all(Class<? extends RandomGenerator> category) {
> 
> this signature is weird, T is not used in the parameter, so in case return any type of Stream<RandomGeneratorFactory<T>> from a type POV, should it be
> ` <T extends RandomGenerator> Stream<RandomGeneratorFactory<T>> all(Class<? extends T> category)` instead ?

agree

> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 269:
> 
>> 267:      * @throws IllegalArgumentException when either the name or category is null
>> 268:      */
>> 269:     static <T> T of(String name, Class<? extends RandomGenerator> category)
> 
> Same issue as above, T is not used as a constraint

agree

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From psandoz at openjdk.java.net  Wed Nov 25 19:23:59 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Wed, 25 Nov 2020 19:23:59 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v4]
In-Reply-To: <ZrxAmREv9K_IaU4r6GjlkW4g363el_x9tukTBmqujNk=.c49835b8-18bf-4a1e-b3c5-a76f8dffaaa0@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <ZrxAmREv9K_IaU4r6GjlkW4g363el_x9tukTBmqujNk=.c49835b8-18bf-4a1e-b3c5-a76f8dffaaa0@github.com>
Message-ID: <9RkzJkvDIoYiC0Oo12q8FDXV4XS6nXAqNzwYkS9hquk=.db116b0e-b139-434a-9eb2-0e2e1f8eef32@github.com>

On Tue, 24 Nov 2020 07:10:14 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
>> 
>> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
>> 
>> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
>> 
>> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment and assert regarding array class; use switch expression.

Recommend you review the problem list of this source file in IntelliJ, which shows some potential cleanups. This can be done as a follow on PR if appropriate, as can any improvements to the default implementation.

src/java.base/share/classes/java/util/ImmutableCollections.java line 163:

> 161:      *
> 162:      * @param <E> the List's element type
> 163:      * @param input the input array

Rogue parameter declaration.

-------------

Marked as reviewed by psandoz (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1026

From jlaskey at openjdk.java.net  Wed Nov 25 19:48:56 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 25 Nov 2020 19:48:56 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v4]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <gWr7-Luxnit0GrjY5fSt2_5oMBM373N3c1V9Nk7Q_Ak=.22f12c85-66d1-433b-aec3-629212e25638@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:

 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Fix extends
 - 8248862: Implement Enhanced Pseudo-Random Number Generators
   
   Use Map.of instead of Map.ofEntries

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/802fa530..ee8f87c3

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=02-03

  Stats: 169 lines in 15 files changed: 23 ins; 17 del; 129 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  Wed Nov 25 19:51:00 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Wed, 25 Nov 2020 19:51:00 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <4scjt1TdYV9Z6bN6YheIELaKERWLpvqE_fyR9bMNPEE=.c986e3d1-6a62-42c2-b087-4e7d47850ffb@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <eEfD_8hmcNpV7AbwcDNt06UYvEMvEL5Nls2ANG6GeMw=.4983954f-9044-4e58-a77b-9d3636c7d09c@github.com>
 <K8uDaN2A6snfGYW0qaFgygHWCan0UY_ZIrlpSNitRs0=.80541689-e340-486d-a3e4-00b684333198@github.com>
 <4scjt1TdYV9Z6bN6YheIELaKERWLpvqE_fyR9bMNPEE=.c986e3d1-6a62-42c2-b087-4e7d47850ffb@github.com>
Message-ID: <lQpruAWh3yhAGWNzCkYqZWp4sXxCEhblMXkaezfxV5E=.8e4beb4f-c5e9-4a15-92b4-25e0db98149d@github.com>

On Wed, 25 Nov 2020 16:26:12 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Not sure that `.sorted(Comparator.comparingInt(RandomGeneratorFactory<RandomGenerator>::stateBits).reversed())` is simpler than  `.sorted((f, g) -> Integer.compare(g.stateBits(), f.stateBits()))`.
>
> At least, it's more clear that it's reversed, i've initially miss the fact that f and g are swapped.
> And :: is able to do inference so, i believe it can be written
>   `.sorted(Comparator.comparingInt(RandomGeneratorFactory::stateBits).reversed())`

Unfortunately it couldn't be inferred

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From kvn at openjdk.java.net  Wed Nov 25 19:52:02 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 25 Nov 2020 19:52:02 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <Atf_e_uIFUV7C0gMzsVLXMGUL_iXFgwYu0uFlKaTXuE=.5261d72f-fc9e-4990-a0f9-b5e644990a89@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <ssQOmnlQu04qaYJ59KeBoFbDw0euJik6v-zQfIAI-6Y=.3614f99b-28ac-42e0-981e-bd832ddc7963@github.com>
 <2cJwK-GzCQ5fcT333q5GZPSlz5t7ghs4Bg5YGzCOwjA=.a577266a-6730-4cde-9b46-5953e800ef9e@github.com>
 <YYWYze2QzeCKmEq_rRCJxIqn3_fEtIau2JWgJNtW-uE=.fdd56d6c-52f7-4042-b8bd-02eb7a39e34d@github.com>
 <Atf_e_uIFUV7C0gMzsVLXMGUL_iXFgwYu0uFlKaTXuE=.5261d72f-fc9e-4990-a0f9-b5e644990a89@github.com>
Message-ID: <_LdM7ZnWXBn1K37mrFdWSjD3DCJEFTzVP8wuda0kJgA=.374b94f4-80ac-4a0e-8496-1c0005a5d29a@github.com>

On Wed, 25 Nov 2020 18:34:28 GMT, Erik ?sterlund <eosterlund at openjdk.org> wrote:

>> From this conversation the only change I can do is 'Turn (on_weak || on_phantom) into !on_strong'.
>> @fisk Is this correct? I am concern that it will include `unknown` decorator too.
>> I agree with Erik to keep !no_keepalive because he prefer it and this is code supported by GC group.
>
> Well if on_weak || on_phantom then it is provably a weak access. But I think the absence of the strong decorator does not prove it is weak, as it could have an unknown strength (via unsafe), in which case we need some extra logic to see if we can prove that an unknown strength access can't be weak.

Okay. I will leave changes as it is.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From shade at openjdk.java.net  Wed Nov 25 19:51:59 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 25 Nov 2020 19:51:59 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <Rs1J7EfhWAcfA5GzuJCJnX24MNNdEr1Et8mAPUutVMk=.ae473190-a72b-4964-b052-e87332d65fa9@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <19RAO8WaSz5jtGP-k8aNoHtNkWjVBFaa-QU97qHKmGc=.faf01bfc-7a71-45ee-b7e3-37aa2cc194d0@github.com>
 <Rs1J7EfhWAcfA5GzuJCJnX24MNNdEr1Et8mAPUutVMk=.ae473190-a72b-4964-b052-e87332d65fa9@github.com>
Message-ID: <drgWO7MuhVVTBPBsYwOLJppAApZUt6u1GFNyffZ8wfM=.89cf04d2-9ef4-4f4a-b7be-ba934d9873ab@github.com>

On Wed, 25 Nov 2020 17:48:54 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> @shipilev 2 new tests added by JDK-8188055 does not trigger C2 compilation.

That sounds like a testbug to me! Since this PR adds C2 intrinsics, I thought it is expected that new tests trigger it in default test configs...

> You need to run my new test to trigger problem I see:
> 
> ```
> java -Xbatch -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:+UseShenandoahGC TestReferenceRefersTo.java
> 
> #  Internal Error (/open/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp:999), pid=2498681, tid=2498694
> #  assert(!is_narrow) failed: phantom access cannot be narrow
> #

Right. So new intrinsic introduces the "phantom" access from C2 intrinsic code, and it can be narrow. Shenandoah did not handle that path, because no existing code shapes were exercising it, and it was considered dead. Since it is not dead now, we can simply implement that part like this: http://cr.openjdk.java.net/~shade/shenandoah/8256999-shenandoah-fix.patch.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From shade at openjdk.java.net  Wed Nov 25 19:54:58 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Wed, 25 Nov 2020 19:54:58 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <drgWO7MuhVVTBPBsYwOLJppAApZUt6u1GFNyffZ8wfM=.89cf04d2-9ef4-4f4a-b7be-ba934d9873ab@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <19RAO8WaSz5jtGP-k8aNoHtNkWjVBFaa-QU97qHKmGc=.faf01bfc-7a71-45ee-b7e3-37aa2cc194d0@github.com>
 <Rs1J7EfhWAcfA5GzuJCJnX24MNNdEr1Et8mAPUutVMk=.ae473190-a72b-4964-b052-e87332d65fa9@github.com>
 <drgWO7MuhVVTBPBsYwOLJppAApZUt6u1GFNyffZ8wfM=.89cf04d2-9ef4-4f4a-b7be-ba934d9873ab@github.com>
Message-ID: <EK5-gGLklwL_i0m22wkPFW7qWqPL9D9DZ7tBdkHpGRM=.59e5cac1-6f71-4fe3-8cbc-686c4b979596@github.com>

On Wed, 25 Nov 2020 19:48:40 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>>> I just pulled the fresh master, applied this patch on top, enabled `_PhantomReference_refersTo0` in `c2compiler.cpp`, and ran `CONF=linux-x86_64-server-fastdebug make images run-test TEST=tier1 TEST_VM_OPTS="-XX:+UseShenandoahGC"` without problems.
>>> 
>>> @vnkozlov, what Shenandoah failure did you see? Attention @rkennke.
>> 
>> @shipilev 2 new tests added by JDK-8188055 does not trigger C2 compilation.
>> You need to run my new test to trigger problem I see:
>> 
>> java -Xbatch -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:+UseShenandoahGC TestReferenceRefersTo.java
>> 
>> #  Internal Error (/open/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp:999), pid=2498681, tid=2498694
>> #  assert(!is_narrow) failed: phantom access cannot be narrow
>> #
>> # JRE version: Java(TM) SE Runtime Environment (16.0) (fastdebug build 16-internal+0-2020-11-24)
>> # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 16-internal+0-2020-11-24, mixed mode, sharing, compressed oops, shenandoah gc, linux-amd64)
>> # Problematic frame:
>> # V  [libjvm.so+0x1862090]  ShenandoahBarrierC2Support::call_lrb_stub(Node*&, Node*&, Node*, Node*&, Node*, unsigned long, PhaseIdealLoop*)+0x7e0
>
>> @shipilev 2 new tests added by JDK-8188055 does not trigger C2 compilation.
> 
> That sounds like a testbug to me! Since this PR adds C2 intrinsics, I thought it is expected that new tests trigger it in default test configs...
> 
>> You need to run my new test to trigger problem I see:
>> 
>> ```
>> java -Xbatch -XX:-TieredCompilation -XX:CICompilerCount=1 -XX:+UseShenandoahGC TestReferenceRefersTo.java
>> 
>> #  Internal Error (/open/src/hotspot/share/gc/shenandoah/c2/shenandoahSupport.cpp:999), pid=2498681, tid=2498694
>> #  assert(!is_narrow) failed: phantom access cannot be narrow
>> #
> 
> Right. So new intrinsic introduces the "phantom" access from C2 intrinsic code, and it can be narrow. Shenandoah did not handle that path, because no existing code shapes were exercising it, and it was considered dead. Since it is not dead now, we can simply implement that part like this: http://cr.openjdk.java.net/~shade/shenandoah/8256999-shenandoah-fix.patch.

Your PR have also been bitten by #1427, merge from master to get it fixed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From kvn at openjdk.java.net  Wed Nov 25 19:58:55 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 25 Nov 2020 19:58:55 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <EK5-gGLklwL_i0m22wkPFW7qWqPL9D9DZ7tBdkHpGRM=.59e5cac1-6f71-4fe3-8cbc-686c4b979596@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <19RAO8WaSz5jtGP-k8aNoHtNkWjVBFaa-QU97qHKmGc=.faf01bfc-7a71-45ee-b7e3-37aa2cc194d0@github.com>
 <Rs1J7EfhWAcfA5GzuJCJnX24MNNdEr1Et8mAPUutVMk=.ae473190-a72b-4964-b052-e87332d65fa9@github.com>
 <drgWO7MuhVVTBPBsYwOLJppAApZUt6u1GFNyffZ8wfM=.89cf04d2-9ef4-4f4a-b7be-ba934d9873ab@github.com>
 <EK5-gGLklwL_i0m22wkPFW7qWqPL9D9DZ7tBdkHpGRM=.59e5cac1-6f71-4fe3-8cbc-686c4b979596@github.com>
Message-ID: <eiRnL0Bpm7HdWIuwXYtzVz_ma_I9i32OpO5sZMrFR9c=.7b300eb9-d490-41fe-b423-0f7d6d8f9c00@github.com>

On Wed, 25 Nov 2020 19:52:21 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Your PR have also been bitten by #1427, merge from master to get it fixed.

Thanks! I will apply your patch and merge from master latest changes.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From dfuchs at openjdk.java.net  Wed Nov 25 20:18:01 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 25 Nov 2020 20:18:01 GMT
Subject: RFR: 8255277: randomDelay in DrainDeadlockT and LoggingDeadlock do
 not randomly delay
Message-ID: <CWOVEhFqjjiXyejRbItcUl9B-Y94dQ8gQ5kP4AjrcgA=.07e983f8-b682-45f7-b4d8-9c78df498a4b@github.com>

Hi,

Please find here an almost trivial fix for:
8255277: randomDelay in DrainDeadlockT and LoggingDeadlock do not randomly delay

The two tests are changed from using Math.random() to using the jdk test lib RandomFactory, which prints its seed in the log file and allows for better reproducibility in case of failures.

best regards,

-- daniel

-------------

Commit messages:
 - 8255277: randomDelay in DrainDeadlockT and LoggingDeadlock do not randomly delay

Changes: https://git.openjdk.java.net/jdk/pull/1441/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1441&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8255277
  Stats: 17 lines in 2 files changed: 13 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1441.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1441/head:pull/1441

PR: https://git.openjdk.java.net/jdk/pull/1441

From dfuchs at openjdk.java.net  Wed Nov 25 20:24:56 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Wed, 25 Nov 2020 20:24:56 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <cFfnvRrX6Flsj8XZcYxTWD_adHXBwqKEGaGnrOD4OUM=.c4dca349-abe3-455a-b686-3a39036e1eec@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
 <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
 <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
 <TFCxfLxB7_iDyPbbSXJtWZZm4HOW_n4R66vMnNEzYvI=.1659cc00-17c8-4999-bbb7-b5c7516599b7@github.com>
 <m03pV9naVWuHcK_vDJPmbc475it1Z0rtCATTwsIOp3s=.ee0b9cf3-1bd3-4351-a40d-f19bd20850bd@github.com>
 <cFfnvRrX6Flsj8XZcYxTWD_adHXBwqKEGaGnrOD4OUM=.c4dca349-abe3-455a-b686-3a39036e1eec@github.com>
Message-ID: <cHf3AFx0fpIAKquwIO0lfVZ7-e9w_qMqBPt5I763_9g=.b2432a97-f14f-4b42-b525-028bcfea9c9f@github.com>

On Wed, 25 Nov 2020 19:05:19 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> @johnlinp In any case, you'd also need to update the surrounding prose; we need to remove this:
>>  returning the current value or {@code null} if absent:```
>
> @pavelrappo 
> 
>> What is the required level of fidelity particular (pseudo-) code has to have?
> 
> It's potentially a large discussion, one that could be had in the context of my JEP draft http://openjdk.java.net/jeps/8068562 . However, speaking practically, it's possible to focus the discussion fairly concisely: the main responsibility of the `@implSpec` ("Implementation Requirements") section is to give implementors of subclasses enough information to decide whether to inherit the implementation or to override it, and if they override it, what behavior they can expect if they were to call `super.compute`.
> 
> In this case, a null-value-tolerating Map implementation needs to know that the default implementation calls `remove` in the particular case that you mentioned. A concurrent Map implementation will also need to know that the default implementation calls `get(key)` and `containsKey(key)` at different times, potentially leading to a race condition. Both of these inform the override vs. inherit decision.

@stuart-marks 

> Both of these inform the override vs. inherit decision.

So in this case - fixing the specification to match the default implementation seems to be the right call - as existing implementations that do not override are more probably depending on the current default behavior.

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From isipka at openjdk.java.net  Wed Nov 25 20:35:04 2020
From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Wed, 25 Nov 2020 20:35:04 GMT
Subject: RFR: 8256894: define test groups
Message-ID: <rwh0Swv_VjVGaqDDZykaerZmD9IbB6Ix6MMEu1cIflg=.dbb2920b-8687-481f-b90a-937672374100@github.com>

Defined new test groups as defined in ticket. @fguallini

-------------

Commit messages:
 - 8256894: removing manual tests from corelibs tests
 - 8256894: define test groups

Changes: https://git.openjdk.java.net/jdk/pull/1416/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1416&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256894
  Stats: 52 lines in 1 file changed: 51 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1416.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1416/head:pull/1416

PR: https://git.openjdk.java.net/jdk/pull/1416

From alanb at openjdk.java.net  Wed Nov 25 20:35:04 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 25 Nov 2020 20:35:04 GMT
Subject: RFR: 8256894: define test groups
In-Reply-To: <rwh0Swv_VjVGaqDDZykaerZmD9IbB6Ix6MMEu1cIflg=.dbb2920b-8687-481f-b90a-937672374100@github.com>
References: <rwh0Swv_VjVGaqDDZykaerZmD9IbB6Ix6MMEu1cIflg=.dbb2920b-8687-481f-b90a-937672374100@github.com>
Message-ID: <gwdmcgPWl0tIFTbqkeP_Y4amAqWJ_mX3VDaXpZ6QmVM=.0e59a139-6d46-491d-9a7b-1a7803622d29@github.com>

On Tue, 24 Nov 2020 16:13:59 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> Defined new test groups as defined in ticket. @fguallini

test/jdk/TEST.groups line 327:

> 325:     :core_tools \
> 326:     :jdk_other \
> 327:     :jdk_core_manual

Please don't add manual tests to jdk_core.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1416

From isipka at openjdk.java.net  Wed Nov 25 20:35:05 2020
From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Wed, 25 Nov 2020 20:35:05 GMT
Subject: RFR: 8256894: define test groups
In-Reply-To: <gwdmcgPWl0tIFTbqkeP_Y4amAqWJ_mX3VDaXpZ6QmVM=.0e59a139-6d46-491d-9a7b-1a7803622d29@github.com>
References: <rwh0Swv_VjVGaqDDZykaerZmD9IbB6Ix6MMEu1cIflg=.dbb2920b-8687-481f-b90a-937672374100@github.com>
 <gwdmcgPWl0tIFTbqkeP_Y4amAqWJ_mX3VDaXpZ6QmVM=.0e59a139-6d46-491d-9a7b-1a7803622d29@github.com>
Message-ID: <nbKqHC6IBCjR6PwCEBFpJT8JJ3FKMNZjs5eWx2A9dmw=.c42c95dd-60cd-4fbf-bb01-738cf3f4d499@github.com>

On Wed, 25 Nov 2020 11:19:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Defined new test groups as defined in ticket. @fguallini
>
> test/jdk/TEST.groups line 327:
> 
>> 325:     :core_tools \
>> 326:     :jdk_other \
>> 327:     :jdk_core_manual
> 
> Please don't add manual tests to jdk_core.

Removed.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1416

From lancea at openjdk.java.net  Wed Nov 25 20:38:57 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Wed, 25 Nov 2020 20:38:57 GMT
Subject: RFR: 8255277: randomDelay in DrainDeadlockT and LoggingDeadlock
 do not randomly delay
In-Reply-To: <CWOVEhFqjjiXyejRbItcUl9B-Y94dQ8gQ5kP4AjrcgA=.07e983f8-b682-45f7-b4d8-9c78df498a4b@github.com>
References: <CWOVEhFqjjiXyejRbItcUl9B-Y94dQ8gQ5kP4AjrcgA=.07e983f8-b682-45f7-b4d8-9c78df498a4b@github.com>
Message-ID: <DSnq4W1uJNL_nwFpZhFYkZj3Vpo9SRRsVjhVBVByaY0=.f187e731-fec7-467b-9a08-97a8361ba162@github.com>

On Wed, 25 Nov 2020 20:13:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here an almost trivial fix for:
> 8255277: randomDelay in DrainDeadlockT and LoggingDeadlock do not randomly delay
> 
> The two tests are changed from using Math.random() to using the jdk test lib RandomFactory, which prints its seed in the log file and allows for better reproducibility in case of failures.
> 
> best regards,
> 
> -- daniel

looks good

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1441

From github.com+828220+forax at openjdk.java.net  Wed Nov 25 20:43:01 2020
From: github.com+828220+forax at openjdk.java.net (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Wed, 25 Nov 2020 20:43:01 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <lQpruAWh3yhAGWNzCkYqZWp4sXxCEhblMXkaezfxV5E=.8e4beb4f-c5e9-4a15-92b4-25e0db98149d@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <eEfD_8hmcNpV7AbwcDNt06UYvEMvEL5Nls2ANG6GeMw=.4983954f-9044-4e58-a77b-9d3636c7d09c@github.com>
 <K8uDaN2A6snfGYW0qaFgygHWCan0UY_ZIrlpSNitRs0=.80541689-e340-486d-a3e4-00b684333198@github.com>
 <4scjt1TdYV9Z6bN6YheIELaKERWLpvqE_fyR9bMNPEE=.c986e3d1-6a62-42c2-b087-4e7d47850ffb@github.com>
 <lQpruAWh3yhAGWNzCkYqZWp4sXxCEhblMXkaezfxV5E=.8e4beb4f-c5e9-4a15-92b4-25e0db98149d@github.com>
Message-ID: <CkxwINz4S5rNbqtsjB--PlAI6xj0oBOZWVbmuTSU1Og=.fc6c0e5f-b7b7-4c7b-8cee-711e0c218092@github.com>

On Wed, 25 Nov 2020 19:48:32 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> At least, it's more clear that it's reversed, i've initially miss the fact that f and g are swapped.
>> And :: is able to do inference so, i believe it can be written
>>   `.sorted(Comparator.comparingInt(RandomGeneratorFactory::stateBits).reversed())`
>
> Unfortunately it couldn't be inferred

It's because you have added reverse() as a postfix operation so the inference can not flow backward as it should,
using Collections.reverseOrder() should fix that
`.sorted(Collections.reverseOrder(Comparator.comparingInt(RandomGeneratorFactory::stateBits)))`

using some import statics for reverseOrder and comparintInt make the code readable but given it's in the doc, we are out of luck here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From jvernee at openjdk.java.net  Wed Nov 25 22:00:13 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 25 Nov 2020 22:00:13 GMT
Subject: RFR: 8256862: Several java/foreign tests fail on x86_32 platforms
 [v2]
In-Reply-To: <a8o0qUQOUKj4jXMh4w-6STR-QDjBgwbbInH0D3Rdo8Q=.9ab0359f-5fa0-47d1-ad97-a236063442b0@github.com>
References: <a8o0qUQOUKj4jXMh4w-6STR-QDjBgwbbInH0D3Rdo8Q=.9ab0359f-5fa0-47d1-ad97-a236063442b0@github.com>
Message-ID: <apojR2tm3mXHv0ITbK71-iiSaePHJxpwCGLiZnzvjkM=.d48ace90-947e-49be-9d97-ec05cb2d83f5@github.com>

> This patch fixes several failures on x86_32 of java/foreign tests.
> 
> This is mostly done by disabling the failing tests, but the impl of CLinker is also adjusted ton properly detect 32 bit platforms as unsupported.
> 
> CLinker is specified to fail in the initializer on unsupported platforms, and a test is added to verify this as well.
> 
> Note that this adds requires clauses to the failing tests that explicitly enumerate all available platforms, so this should fix the test failures on other platforms as well.
> 
> https://bugs.openjdk.java.net/browse/JDK-8256757 is filed for the remaining failure in TestStringLatin1IndexOfChar.
> 
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8256863

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Exclude TestNulls as well

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1386/files
  - new: https://git.openjdk.java.net/jdk/pull/1386/files/bb3f4497..0ea11786

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1386&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1386&range=00-01

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1386.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1386/head:pull/1386

PR: https://git.openjdk.java.net/jdk/pull/1386

From mchung at openjdk.java.net  Wed Nov 25 22:13:56 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 25 Nov 2020 22:13:56 GMT
Subject: RFR: 8253751: Dependencies of automatic modules are not
 propagated through module layers
In-Reply-To: <n98SGqqXdl4g8mQ4BAIfRhcIgjQZPcn-qQUdrTTKqc8=.48ffe4f9-5b67-48fc-871d-ad0328493dfd@github.com>
References: <n98SGqqXdl4g8mQ4BAIfRhcIgjQZPcn-qQUdrTTKqc8=.48ffe4f9-5b67-48fc-871d-ad0328493dfd@github.com>
Message-ID: <EZj3hyIRaPbTGtHZ_vc9SvmFjsv7zdK_wFFjCP52kkU=.79444a5a-be26-4d3b-8dcd-b88308e43405@github.com>

On Mon, 23 Nov 2020 15:27:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This is a corner case that arises when creating a Configuration for a child module layer. If an explicit module in the child configuration reads an automatic module in a parent configuration then it should read all automatic modules in the parent configurations. Unfortunately, this read edge wasn't created for the case that the child layer does not contain any automatic modules.

Looks good.

src/java.base/share/classes/java/lang/module/Resolver.java line 580:

> 578:                     if (m2.descriptor().isAutomatic()) {
> 579:                         m2.reads()
> 580:                                 .stream()

Nit: not sure if this formatting is intentional or you meant `m2.reads().stream()` in one line (which I like better).

-------------

Marked as reviewed by mchung (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1391

From mchung at openjdk.java.net  Wed Nov 25 22:24:40 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Wed, 25 Nov 2020 22:24:40 GMT
Subject: RFR: 8159746: (proxy) Support for default methods [v7]
In-Reply-To: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
Message-ID: <7eMyBIGJbWmpHYlp1PbgHN01WpMHPoMzQVQlYObzszY=.ca82cb0a-3579-4fad-9ad3-160d03c5d5c2@github.com>

> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke
> the given default method on the given proxy instance.
> 
> The implementation looks up a method handle for `invokespecial` instruction
> as if called from with the proxy class as the caller, equivalent to calling
> `X.super::m` where `X` is a proxy interface of the proxy class and
> `X.super::m` will resolve to the specified default method.
> 
> The implementation will call a private static `proxyClassLookup(Lookup caller)`
> method of the proxy class to obtain its private Lookup.  This private method
> in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class
> with full privilege access to use, or else `IllegalAccessException` will be
> thrown.
> 
> This patch also proposes to define a proxy class in an unnamed module to
> a dynamic module to strengthen encapsulation such that they are only
> unconditionally exported from a named module but not open for deep reflective
> access.  This only applies to the case if all the proxy interfaces are public
> and in a package that is exported or open.
> 
> One dynamic module is created for each class loader that defines proxies.
> The change changes the dynamic module to contain another package (same
> name as the module) that is unconditionally exported and is opened to
> `java.base` only.
> 
> There is no change to the package and module of the proxy class for
> the following cases:
> 
> - if at least one proxy interface is non-public, then the proxy class is defined
>   in the package and module of the non-public interfaces
> - if at least one proxy is in a package that is non-exported and non-open,
>   if all proxy interfaces are public, then the proxy class is defined in
>   a non-exported, non-open package of a dynamic module.
> 
> The spec change is that a proxy class used to be defined in an unnamed
> module, i.e. in a exported and open package, is defined in an unconditionally
> exported but non-open package.  Programs that assume it to be open unconditionally
> will be affected and cannot do deep reflection on such proxy classes.
> 
> Peter Levart contributed an initial prototype [1] (thanks Peter).  I think
> the exceptions could be simplified as more checking should be done prior to
> the invocation of the method handle like checking the types of the arguments
> with the method type.  This approach avoids defining a public API
> `protected Proxy::$$proxyClassLookup$$` method.  Instead it defines a
> private static method that is restricted for Proxy class to use (by
> taking a caller parameter to ensure it's a private lookup on Proxy class).
> 
> javadoc/specdiff:
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/
> 
> [1]  http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html

Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
 - update copyright header
 - clean up DefaultMethodProxy test
 - Performance improvement contributed by plevart
 - Clean up the patch.  Rename to
 - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
 - move invokeDefaultMethod to InvocationHandler and throw IAE if access check fails
 - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
 - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
 - minor tweak to the spec wording and impl
 - ... and 15 more: https://git.openjdk.java.net/jdk/compare/1d5cd890...d72d627f

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/313/files
  - new: https://git.openjdk.java.net/jdk/pull/313/files/d443f10e..d72d627f

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=05-06

  Stats: 393702 lines in 3591 files changed: 248962 ins; 107506 del; 37234 mod
  Patch: https://git.openjdk.java.net/jdk/pull/313.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/313/head:pull/313

PR: https://git.openjdk.java.net/jdk/pull/313

From rriggs at openjdk.java.net  Wed Nov 25 22:51:44 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 25 Nov 2020 22:51:44 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> 
> Review comments and suggestions welcome.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:

 - Clarified that suffix() and prefix() methods do not return null, instead the empty string is returned.
 - Merge branch 'master' into 8251989-hex-formatter
 - Merge branch 'master' into 8251989-hex-formatter
 - Merge branch 'master' into 8251989-hex-formatter
 - The HexFormat API indexing model for array and string ranges is changed
   to describe the range using 'fromIndex (inclusive)' and 'toIndex (exclusive)'.
   
   Initially, it was specified as 'index' and 'length'. However, both byte arrays
   and strings used in the HexFormat API typically use fromIndex and toIndex
   to describe ranges.  Using the same indexing model can prevent mistakes.
   
   The change affects the methods and corresponding tests:
   
       formatHex(byte[] bytes, int fromIndex, int toIndex)
       formatHex(A out, byte[] bytes, int fromIndex, int toIndex)
       parseHex(char[] chars, int fromIndex, int toIndex)
       parseHex(CharSequence string, int fromIndex, int toIndex)
       fromHexDigits(CharSequence string, int fromIndex, int toIndex)
       fromHexDigitsToLong(CharSequence string, int fromIndex, int toIndex)
 - - Added @see and @link references to Integer.toHexString and Long.toHexString
   - Clarified parsing is case insensistive in various parse and fromXXX methods
   - Source level cleanup based on review comments
   - Expanded some javadoc tag text to make it more descriptive
   - Consistent use of 'hexadecimal' vs 'hex'
 - Review comment updates to class javadoc
 - Review comment updates, in the example code, and to describe the characters used to convert to hexadecimal
 - Correct length of StringBuilder in formatHex;
   Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]
 - Merge branch 'master' into 8251989-hex-formatter
 - ... and 9 more: https://git.openjdk.java.net/jdk/compare/8444acfa...b19d2827

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/482/files
  - new: https://git.openjdk.java.net/jdk/pull/482/files/2aeab7d7..b19d2827

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=08-09

  Stats: 384227 lines in 3445 files changed: 245788 ins; 106656 del; 31783 mod
  Patch: https://git.openjdk.java.net/jdk/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482

PR: https://git.openjdk.java.net/jdk/pull/482

From kvn at openjdk.java.net  Wed Nov 25 23:35:14 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Wed, 25 Nov 2020 23:35:14 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo [v2]
In-Reply-To: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
Message-ID: <lRizv2JGrdsVw9AZ01ORWRlupCj4EkoGQ2phRMNUQEc=.9dd769f2-a3ae-4673-89cf-1959f984225c@github.com>

> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
> 
> Initial patch was prepared by @fisk.
> 
> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
> 
> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.

Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8256999
 - Added ZLoadBarrierElided = 0 definition.
   Removed is_exact argument in load_field_from_object().
   Added Shenandoah support for narrow phantom accesses.
 - 8256999: Add C2 intrinsic for Reference.refersTo and PhantomReference::refersTo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1425/files
  - new: https://git.openjdk.java.net/jdk/pull/1425/files/7bfec378..08bdd307

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1425&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1425&range=00-01

  Stats: 8771 lines in 206 files changed: 2656 ins; 872 del; 5243 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1425/head:pull/1425

PR: https://git.openjdk.java.net/jdk/pull/1425

From mr at openjdk.java.net  Wed Nov 25 23:50:14 2020
From: mr at openjdk.java.net (Mark Reinhold)
Date: Wed, 25 Nov 2020 23:50:14 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v6]
In-Reply-To: <w6idTrBiUy8FDPXKT1fj531pbZjCfa-Y_391HeB0GTE=.50c9e124-63a7-4b15-bef5-bc69db7aaf30@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
 <X-tT29dRiWaS394o3ilVhJdV0xKsZ_kwqOHhLs3wwW8=.76df07ec-25c5-44bf-a160-2a88a3cb6adf@github.com>
 <Q8qFNQxNBe6tNbPE2QJlfjVR4mY51e-1VvxyhAX9ISw=.926f5fe3-d4a2-44f5-a73f-59afd7370bb9@github.com>
 <rabnopFhJQjJDpDOBnVw8CW9rNXxG4QylLQ8ViA-ZaA=.f9b25d70-a303-4781-95d7-94c7fb238f53@github.com>
 <mG_LH28GwHsbnZaAiZg6w8JhG4Q0dzYh3OJ_BVTKk9E=.adcaa4b3-4f8c-45c5-a6df-29b4e2594504@github.com>
 <w6idTrBiUy8FDPXKT1fj531pbZjCfa-Y_391HeB0GTE=.50c9e124-63a7-4b15-bef5-bc69db7aaf30@github.com>
Message-ID: <0b3G2kuAXY2BpvNt5c6jYGJZvZZj-GWk6007iXMYOEo=.2a26649c-9b3f-4b6f-9576-02a4fee84911@github.com>

On Fri, 20 Nov 2020 13:08:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Looks good.
>
> testWithAddExportsInManifest create an executable JAR with "Add-Exports: java.base/sun.security.x509" in the manifest. It runs it twice, once without any options, the second with --illegal-access=permit, and checks there are no warnings in both cases. To test attempted deep reflection here would need the equivalent of setAccessibleNonPublicMemberNonExportedPackage that tries to access some privates in sun.security.x509. It's okay to use setAccessibleNonPublicMemberNonExportedPackage to test that privates in sun.nio.ch aren't accessible but it's not connected to the Add-Exports attribute in the JAR file.

Thanks for pointing that out. I fixed it by arranging for the `Add-Exports` test to export both `sun.security.x509` and `sun.nio.ch`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1324

From mr at openjdk.java.net  Wed Nov 25 23:50:14 2020
From: mr at openjdk.java.net (Mark Reinhold)
Date: Wed, 25 Nov 2020 23:50:14 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v6]
In-Reply-To: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
Message-ID: <kl8PcCsrzM-QxfdqsKNF7oZKLWGRfRmrQ1echZlttks=.7cf2d6ee-6459-469c-be0e-2445538ad375@github.com>

> Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396).
> Alan Bateman is the original author; I?ve credited him in the commit metadata.
> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64.

Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision:

  Fix "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test (v2)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1324/files
  - new: https://git.openjdk.java.net/jdk/pull/1324/files/1a7ab4e0..0c9654a0

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1324&range=04-05

  Stats: 5 lines in 1 file changed: 1 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1324.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1324/head:pull/1324

PR: https://git.openjdk.java.net/jdk/pull/1324

From naoto at openjdk.java.net  Thu Nov 26 00:14:20 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Thu, 26 Nov 2020 00:14:20 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
Message-ID: <2nUVJ9EKuqnoGTq1ZPCazHnmbIFAmLAJXjiCTY2dGeU=.130cb5a7-a189-4483-8832-74c67cdd39e1@github.com>

On Wed, 25 Nov 2020 22:51:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> 
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
> 
>  - Clarified that suffix() and prefix() methods do not return null, instead the empty string is returned.
>  - Merge branch 'master' into 8251989-hex-formatter
>  - Merge branch 'master' into 8251989-hex-formatter
>  - Merge branch 'master' into 8251989-hex-formatter
>  - The HexFormat API indexing model for array and string ranges is changed
>    to describe the range using 'fromIndex (inclusive)' and 'toIndex (exclusive)'.
>    
>    Initially, it was specified as 'index' and 'length'. However, both byte arrays
>    and strings used in the HexFormat API typically use fromIndex and toIndex
>    to describe ranges.  Using the same indexing model can prevent mistakes.
>    
>    The change affects the methods and corresponding tests:
>    
>        formatHex(byte[] bytes, int fromIndex, int toIndex)
>        formatHex(A out, byte[] bytes, int fromIndex, int toIndex)
>        parseHex(char[] chars, int fromIndex, int toIndex)
>        parseHex(CharSequence string, int fromIndex, int toIndex)
>        fromHexDigits(CharSequence string, int fromIndex, int toIndex)
>        fromHexDigitsToLong(CharSequence string, int fromIndex, int toIndex)
>  - - Added @see and @link references to Integer.toHexString and Long.toHexString
>    - Clarified parsing is case insensistive in various parse and fromXXX methods
>    - Source level cleanup based on review comments
>    - Expanded some javadoc tag text to make it more descriptive
>    - Consistent use of 'hexadecimal' vs 'hex'
>  - Review comment updates to class javadoc
>  - Review comment updates, in the example code, and to describe the characters used to convert to hexadecimal
>  - Correct length of StringBuilder in formatHex;
>    Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]
>  - Merge branch 'master' into 8251989-hex-formatter
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/d1f1e8b7...b19d2827

Hi Roger,
Other than these few comments, there are some files that need copyright year updates.

src/java.base/share/classes/java/util/HexFormat.java line 42:

> 40:  * <p>
> 41:  * There are two factories of {@code HexFormat} with preset parameters {@link #of()} and
> 42:  * {@link #ofDelimiter(String) of(delimiter)}. For other parameter combinations

Is that `ofDelimiter(delimiter)` ?

src/java.base/share/classes/java/util/HexFormat.java line 408:

> 406:      * @param fromIndex the initial index of the range, inclusive
> 407:      * @param toIndex the final index of the range, exclusive.
> 408:      * @return a String formatting or null for non-single byte formatting

`non-single byte delimiter`?

src/java.base/share/classes/java/util/HexFormat.java line 853:

> 851:      */
> 852:     public int fromHexDigit(int ch) {
> 853:         int value = Character.digit(ch, 16);

Do we need to limit parsing the hex digit for only [0-9a-fA-F]? This would return `0` for other digits, say `fullwidth digit zero` (U+FF10)

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From darcy at openjdk.java.net  Thu Nov 26 01:28:20 2020
From: darcy at openjdk.java.net (Joe Darcy)
Date: Thu, 26 Nov 2020 01:28:20 GMT
Subject: RFR: 8159746: (proxy) Support for default methods [v7]
In-Reply-To: <7eMyBIGJbWmpHYlp1PbgHN01WpMHPoMzQVQlYObzszY=.ca82cb0a-3579-4fad-9ad3-160d03c5d5c2@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <7eMyBIGJbWmpHYlp1PbgHN01WpMHPoMzQVQlYObzszY=.ca82cb0a-3579-4fad-9ad3-160d03c5d5c2@github.com>
Message-ID: <CW6xmS0ihoZSEBF98C1ahKCInElzr2C53iqyUy7ouOQ=.bbc79bb6-44da-462e-bdb1-869e9cdbcd43@github.com>

On Wed, 25 Nov 2020 22:24:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke
>> the given default method on the given proxy instance.
>> 
>> The implementation looks up a method handle for `invokespecial` instruction
>> as if called from with the proxy class as the caller, equivalent to calling
>> `X.super::m` where `X` is a proxy interface of the proxy class and
>> `X.super::m` will resolve to the specified default method.
>> 
>> The implementation will call a private static `proxyClassLookup(Lookup caller)`
>> method of the proxy class to obtain its private Lookup.  This private method
>> in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class
>> with full privilege access to use, or else `IllegalAccessException` will be
>> thrown.
>> 
>> This patch also proposes to define a proxy class in an unnamed module to
>> a dynamic module to strengthen encapsulation such that they are only
>> unconditionally exported from a named module but not open for deep reflective
>> access.  This only applies to the case if all the proxy interfaces are public
>> and in a package that is exported or open.
>> 
>> One dynamic module is created for each class loader that defines proxies.
>> The change changes the dynamic module to contain another package (same
>> name as the module) that is unconditionally exported and is opened to
>> `java.base` only.
>> 
>> There is no change to the package and module of the proxy class for
>> the following cases:
>> 
>> - if at least one proxy interface is non-public, then the proxy class is defined
>>   in the package and module of the non-public interfaces
>> - if at least one proxy is in a package that is non-exported and non-open,
>>   if all proxy interfaces are public, then the proxy class is defined in
>>   a non-exported, non-open package of a dynamic module.
>> 
>> The spec change is that a proxy class used to be defined in an unnamed
>> module, i.e. in a exported and open package, is defined in an unconditionally
>> exported but non-open package.  Programs that assume it to be open unconditionally
>> will be affected and cannot do deep reflection on such proxy classes.
>> 
>> Peter Levart contributed an initial prototype [1] (thanks Peter).  I think
>> the exceptions could be simplified as more checking should be done prior to
>> the invocation of the method handle like checking the types of the arguments
>> with the method type.  This approach avoids defining a public API
>> `protected Proxy::$$proxyClassLookup$$` method.  Instead it defines a
>> private static method that is restricted for Proxy class to use (by
>> taking a caller parameter to ensure it's a private lookup on Proxy class).
>> 
>> javadoc/specdiff:
>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/
>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/
>> 
>> [1]  http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html
>
> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>  - update copyright header
>  - clean up DefaultMethodProxy test
>  - Performance improvement contributed by plevart
>  - Clean up the patch.  Rename to
>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>  - move invokeDefaultMethod to InvocationHandler and throw IAE if access check fails
>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>  - minor tweak to the spec wording and impl
>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/0d685bc0...d72d627f

Marked as reviewed by darcy (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From sundar at openjdk.java.net  Thu Nov 26 03:11:58 2020
From: sundar at openjdk.java.net (Athijegannathan Sundararajan)
Date: Thu, 26 Nov 2020 03:11:58 GMT
Subject: RFR: 8256862: Several java/foreign tests fail on x86_32 platforms
 [v2]
In-Reply-To: <apojR2tm3mXHv0ITbK71-iiSaePHJxpwCGLiZnzvjkM=.d48ace90-947e-49be-9d97-ec05cb2d83f5@github.com>
References: <a8o0qUQOUKj4jXMh4w-6STR-QDjBgwbbInH0D3Rdo8Q=.9ab0359f-5fa0-47d1-ad97-a236063442b0@github.com>
 <apojR2tm3mXHv0ITbK71-iiSaePHJxpwCGLiZnzvjkM=.d48ace90-947e-49be-9d97-ec05cb2d83f5@github.com>
Message-ID: <AHRDPXFNHUzzd7SZCWgH2Cd2bMiNsK7jr0DaikrQSXE=.bedd0a0d-bd51-429e-a2a5-1a2533dbaf2e@github.com>

On Wed, 25 Nov 2020 22:00:13 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This patch fixes several failures on x86_32 of java/foreign tests.
>> 
>> This is mostly done by disabling the failing tests, but the impl of CLinker is also adjusted ton properly detect 32 bit platforms as unsupported.
>> 
>> CLinker is specified to fail in the initializer on unsupported platforms, and a test is added to verify this as well.
>> 
>> Note that this adds requires clauses to the failing tests that explicitly enumerate all available platforms, so this should fix the test failures on other platforms as well.
>> 
>> https://bugs.openjdk.java.net/browse/JDK-8256757 is filed for the remaining failure in TestStringLatin1IndexOfChar.
>> 
>> CSR link: https://bugs.openjdk.java.net/browse/JDK-8256863
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Exclude TestNulls as well

Marked as reviewed by sundar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1386

From alanb at openjdk.java.net  Thu Nov 26 07:34:00 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 26 Nov 2020 07:34:00 GMT
Subject: RFR: 8256299: Implement JEP 396: Strongly Encapsulate JDK
 Internals by Default [v6]
In-Reply-To: <kl8PcCsrzM-QxfdqsKNF7oZKLWGRfRmrQ1echZlttks=.7cf2d6ee-6459-469c-be0e-2445538ad375@github.com>
References: <Sxuua4Kt5dcQdpf22kOxON9WysKGaDz9gPXF-sDmHIM=.1f472641-6c5c-4a89-bd2e-06f5f0f32842@github.com>
 <kl8PcCsrzM-QxfdqsKNF7oZKLWGRfRmrQ1echZlttks=.7cf2d6ee-6459-469c-be0e-2445538ad375@github.com>
Message-ID: <dlOuUBJoitXuQMSyWCHHwVih6bFV7ZQ_Bcs1Rv3bTlM=.0fd0b253-db3c-45ee-bdd3-a11d92a77efc@github.com>

On Wed, 25 Nov 2020 23:50:14 GMT, Mark Reinhold <mr at openjdk.org> wrote:

>> Please review this implementation of JEP 396 (https://openjdk.java.net/jeps/396).
>> Alan Bateman is the original author; I?ve credited him in the commit metadata.
>> Passes tiers 1-3 on {linux,macos,windows}-x64 and linux-aarch64.
>
> Mark Reinhold has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix "Add-Exports" case for the setAccessibleNonPublicMemberNonExportedPackage test (v2)

Marked as reviewed by alanb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1324

From alanb at openjdk.java.net  Thu Nov 26 09:38:15 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 26 Nov 2020 09:38:15 GMT
Subject: RFR: 8253751: Dependencies of automatic modules are not
 propagated through module layers [v2]
In-Reply-To: <n98SGqqXdl4g8mQ4BAIfRhcIgjQZPcn-qQUdrTTKqc8=.48ffe4f9-5b67-48fc-871d-ad0328493dfd@github.com>
References: <n98SGqqXdl4g8mQ4BAIfRhcIgjQZPcn-qQUdrTTKqc8=.48ffe4f9-5b67-48fc-871d-ad0328493dfd@github.com>
Message-ID: <f8QNvduqal_fTz06wetFrr67aUhMWGNNyleKBmB2oNA=.48604b3e-0445-4ec6-b2f0-c91fd9f701eb@github.com>

> This is a corner case that arises when creating a Configuration for a child module layer. If an explicit module in the child configuration reads an automatic module in a parent configuration then it should read all automatic modules in the parent configurations. Unfortunately, this read edge wasn't created for the case that the child layer does not contain any automatic modules.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:

 - Formatting nit
 - Merge
 - Merge
 - Merge
 - Add @bug to test
 - Fixed typo in comment
 - Merge
 - Merge
 - If module reads automatic module in parent configuration then reads all automatic modules

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1391/files
  - new: https://git.openjdk.java.net/jdk/pull/1391/files/ec3c872f..1c5aa8cd

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1391&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1391&range=00-01

  Stats: 5201 lines in 88 files changed: 379 ins; 63 del; 4759 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1391.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1391/head:pull/1391

PR: https://git.openjdk.java.net/jdk/pull/1391

From jvernee at openjdk.java.net  Thu Nov 26 11:23:57 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 26 Nov 2020 11:23:57 GMT
Subject: Integrated: 8256862: Several java/foreign tests fail on x86_32
 platforms
In-Reply-To: <a8o0qUQOUKj4jXMh4w-6STR-QDjBgwbbInH0D3Rdo8Q=.9ab0359f-5fa0-47d1-ad97-a236063442b0@github.com>
References: <a8o0qUQOUKj4jXMh4w-6STR-QDjBgwbbInH0D3Rdo8Q=.9ab0359f-5fa0-47d1-ad97-a236063442b0@github.com>
Message-ID: <_DSJI9Lpb77aeSVcLdp3Nk2GAn0t8v1ir2B7IB8GJ2I=.3bee8106-9c79-425a-8151-9eaa4d7d43dd@github.com>

On Mon, 23 Nov 2020 14:54:21 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This patch fixes several failures on x86_32 of java/foreign tests.
> 
> This is mostly done by disabling the failing tests, but the impl of CLinker is also adjusted ton properly detect 32 bit platforms as unsupported.
> 
> CLinker is specified to fail in the initializer on unsupported platforms, and a test is added to verify this as well.
> 
> Note that this adds requires clauses to the failing tests that explicitly enumerate all available platforms, so this should fix the test failures on other platforms as well.
> 
> https://bugs.openjdk.java.net/browse/JDK-8256757 is filed for the remaining failure in TestStringLatin1IndexOfChar.
> 
> CSR link: https://bugs.openjdk.java.net/browse/JDK-8256863

This pull request has now been integrated.

Changeset: 734d3c3b
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/734d3c3b
Stats:     95 lines in 21 files changed: 84 ins; 0 del; 11 mod

8256862: Several java/foreign tests fail on x86_32 platforms

Reviewed-by: sundar

-------------

PR: https://git.openjdk.java.net/jdk/pull/1386

From vlivanov at openjdk.java.net  Thu Nov 26 11:33:58 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 26 Nov 2020 11:33:58 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo [v2]
In-Reply-To: <lRizv2JGrdsVw9AZ01ORWRlupCj4EkoGQ2phRMNUQEc=.9dd769f2-a3ae-4673-89cf-1959f984225c@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <lRizv2JGrdsVw9AZ01ORWRlupCj4EkoGQ2phRMNUQEc=.9dd769f2-a3ae-4673-89cf-1959f984225c@github.com>
Message-ID: <yHVzVgrZavafxaWMHuZosSesJQiOwvFddAxrDRv7V7M=.41edbc53-bcd7-450b-84ae-8ae5bd778350@github.com>

On Wed, 25 Nov 2020 23:35:14 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
>> 
>> Initial patch was prepared by @fisk.
>> 
>> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
>> 
>> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.
>
> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8256999
>  - Added ZLoadBarrierElided = 0 definition.
>    Removed is_exact argument in load_field_from_object().
>    Added Shenandoah support for narrow phantom accesses.
>  - 8256999: Add C2 intrinsic for Reference.refersTo and PhantomReference::refersTo

Marked as reviewed by vlivanov (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From rkennke at openjdk.java.net  Thu Nov 26 13:53:59 2020
From: rkennke at openjdk.java.net (Roman Kennke)
Date: Thu, 26 Nov 2020 13:53:59 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo [v2]
In-Reply-To: <lRizv2JGrdsVw9AZ01ORWRlupCj4EkoGQ2phRMNUQEc=.9dd769f2-a3ae-4673-89cf-1959f984225c@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <lRizv2JGrdsVw9AZ01ORWRlupCj4EkoGQ2phRMNUQEc=.9dd769f2-a3ae-4673-89cf-1959f984225c@github.com>
Message-ID: <pg7lETjxXQK3qQ8EoVvimXfB00tTIeHEqPsg0OLRK2c=.28d436a8-0911-4f82-9518-6d45075eb837@github.com>

On Wed, 25 Nov 2020 23:35:14 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
>> 
>> Initial patch was prepared by @fisk.
>> 
>> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
>> 
>> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.
>
> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8256999
>  - Added ZLoadBarrierElided = 0 definition.
>    Removed is_exact argument in load_field_from_object().
>    Added Shenandoah support for narrow phantom accesses.
>  - 8256999: Add C2 intrinsic for Reference.refersTo and PhantomReference::refersTo

Shenandoah parts look good to me! Thanks!

-------------

Marked as reviewed by rkennke (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1425

From chegar at openjdk.java.net  Thu Nov 26 14:34:12 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 26 Nov 2020 14:34:12 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v2]
In-Reply-To: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
Message-ID: <cERsvKxn2J3L6GJ6EDnZmHf9tOOc1WBHAHiVM_K4K8s=.732f97f1-7f36-48a8-939b-6e169cd2a799@github.com>

> The ByteBuffers micro benchmark seems to be a little dated. 
> 
> It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 
> 
> This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 
> 
> 1. Remove allocation from the individual benchmarks - it just creates noise. 
> 2. Consolidate per-thread shared heap and direct buffers. 
> 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
> 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.

Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:

  Add additional carrier views and endianness variants.
  
  A large number of variants are now covered. The individual benchmarks conform to the following convention:
    test(Direct|Heap)(Bulk|Single)(Get|Put)(Byte|Char|Short|Int|Long|Float|Double)(View)?(Swap)?
  
  This allows to easily run a subset of particular interest. For example:
    Direct only :- "org.openjdk.bench.java.nio.ByteBuffers.testDirect.*"
    Char only   :- "org.openjdk.bench.java.nio.ByteBuffers.test.*Char.*"
    Bulk only   :- "org.openjdk.bench.java.nio.ByteBuffers.test.*Bulk.*"
    Put with Int or Long carrier :-
       test(Direct|Heap)(Single)(Put)(Int|Long)(View)?(Swap)?"
  
  Running all variants together is likely not all that useful, since there will be a lot of data.
  
  The param sizes are changed so as to better allow for wider carrier views.
  
  There are a lot of individual benchmark methods, but their implementation is trivial, and largely mechanical.
  
  Question: where do folk stand on having a `main` method in a benchmark - as a standalone-run sanity? I found this useful to assert the validity of the benchmark code. It can be commented out if it could somehow affect the benchmark runs.
  
  ( I omitted read-only views, since they less interesting, and we already have a lot of variants )

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1430/files
  - new: https://git.openjdk.java.net/jdk/pull/1430/files/5e91e63e..84dabc30

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=00-01

  Stats: 1022 lines in 1 file changed: 995 ins; 1 del; 26 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1430.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1430/head:pull/1430

PR: https://git.openjdk.java.net/jdk/pull/1430

From chegar at openjdk.java.net  Thu Nov 26 14:38:17 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Thu, 26 Nov 2020 14:38:17 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v3]
In-Reply-To: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
Message-ID: <qJp0PaBhsqQX4uAVW4qo6FSrCE7GVr1HJgpM-KSvrIo=.952cb0c1-521e-4886-8e55-2d94a194379c@github.com>

> The ByteBuffers micro benchmark seems to be a little dated. 
> 
> It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 
> 
> This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 
> 
> 1. Remove allocation from the individual benchmarks - it just creates noise. 
> 2. Consolidate per-thread shared heap and direct buffers. 
> 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
> 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.

Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:

  whitespace

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1430/files
  - new: https://git.openjdk.java.net/jdk/pull/1430/files/84dabc30..814e1819

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1430.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1430/head:pull/1430

PR: https://git.openjdk.java.net/jdk/pull/1430

From dfuchs at openjdk.java.net  Thu Nov 26 14:53:55 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 26 Nov 2020 14:53:55 GMT
Subject: Integrated: 8255277: randomDelay in DrainDeadlockT and
 LoggingDeadlock do not randomly delay
In-Reply-To: <CWOVEhFqjjiXyejRbItcUl9B-Y94dQ8gQ5kP4AjrcgA=.07e983f8-b682-45f7-b4d8-9c78df498a4b@github.com>
References: <CWOVEhFqjjiXyejRbItcUl9B-Y94dQ8gQ5kP4AjrcgA=.07e983f8-b682-45f7-b4d8-9c78df498a4b@github.com>
Message-ID: <I2NFEKcsC3cnkv2slTyRFpwHvmUAtbgIPI6Rd_jbmOo=.b0c89b7d-08b7-424a-bee9-afe7626d09ae@github.com>

On Wed, 25 Nov 2020 20:13:48 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi,
> 
> Please find here an almost trivial fix for:
> 8255277: randomDelay in DrainDeadlockT and LoggingDeadlock do not randomly delay
> 
> The two tests are changed from using Math.random() to using the jdk test lib RandomFactory, which prints its seed in the log file and allows for better reproducibility in case of failures.
> 
> best regards,
> 
> -- daniel

This pull request has now been integrated.

Changeset: a93841ac
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a93841ac
Stats:     17 lines in 2 files changed: 13 ins; 0 del; 4 mod

8255277: randomDelay in DrainDeadlockT and LoggingDeadlock do not randomly delay

Reviewed-by: lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/1441

From jlaskey at openjdk.java.net  Thu Nov 26 15:36:03 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 26 Nov 2020 15:36:03 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <TTJDYGNjz8D1miykGB3imf4k_Hm2W_nWLRA4HfDpImQ=.a4715d2d-d5ed-4d29-985d-ab28a056f9ce@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <TTJDYGNjz8D1miykGB3imf4k_Hm2W_nWLRA4HfDpImQ=.a4715d2d-d5ed-4d29-985d-ab28a056f9ce@github.com>
Message-ID: <E6Z548JbuLbWXe30dBwk43qxfz3NEPK3Ju_BhO3cyIs=.3c612f8d-0694-4ff6-91c0-f3fb48d9d418@github.com>

On Wed, 25 Nov 2020 14:10:17 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8248862: Implement Enhanced Pseudo-Random Number Generators
>>   
>>   Changes to RandomGeneratorFactory requested by @PaulSandoz
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 497:
> 
>> 495:             ensureConstructors();
>> 496:             return ctorLong.newInstance(seed);
>> 497:         } catch (Exception ex) {
> 
> this one is very dubious because the result in an exception is thrown is a random generator with the wrong seed

This is explained in the docs.

> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 480:
> 
>> 478:         } catch (Exception ex) {
>> 479:             // Should never happen.
>> 480:             throw new IllegalStateException("Random algorithm " + name() + " is missing a default constructor");
> 
> chain the exception ...

agree

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From jlaskey at openjdk.java.net  Thu Nov 26 15:36:01 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 26 Nov 2020 15:36:01 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v5]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <oyFiP1QJwXAwg-4bvN6R9MjWrVmIE_6EipcjjudRn-g=.12bd592e-32ff-411a-b88e-19facb52daf1@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:

  8248862: Implement Enhanced Pseudo-Random Number Generators
  
  Override AbstractSplittableGenerator

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/ee8f87c3..a6851940

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=03-04

  Stats: 165 lines in 3 files changed: 164 ins; 0 del; 1 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  Thu Nov 26 15:44:01 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 26 Nov 2020 15:44:01 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v3]
In-Reply-To: <LRBogL2R7DxnUrcUem3ewE17aRuljl4UlEZS3dW7Mko=.d61114e3-2f10-469a-8cc4-5e8561d2e687@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
 <O2UThjpWW3qIGMwTn8MbRaOCSOE5nc-kRsPssn1ouLE=.9d120753-2c6b-4478-9a39-5fd288be3ff0@github.com>
 <LRBogL2R7DxnUrcUem3ewE17aRuljl4UlEZS3dW7Mko=.d61114e3-2f10-469a-8cc4-5e8561d2e687@github.com>
Message-ID: <XR2JLadsxF5N2joFIw8aUe0E6ngyje_AmYEWLX_Loss=.624e9180-4d9a-4196-984d-30134023f1bc@github.com>

On Wed, 25 Nov 2020 14:16:20 GMT, R?mi Forax <github.com+828220+forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8248862: Implement Enhanced Pseudo-Random Number Generators
>>   
>>   Changes to RandomGeneratorFactory requested by @PaulSandoz
>
> src/java.base/share/classes/java/util/random/RandomGeneratorFactory.java line 46:
> 
>> 44: import java.util.stream.Stream;
>> 45: import jdk.internal.util.random.RandomSupport.RandomGeneratorProperty;
>> 46: 
> 
> Instead of calling a method properties to create a Map, it's usually far easier to use an annotation,
> annotation values supports less runtime type so BigInteger is not supported but using a String instead should be OK.

I kind of like the idea - not sure how expressive a BigInteger string is though. I might be able to express as <i, j, k>  BigInteger.ONE.shiftLeft(i).subtract(j).shiftLeft(k). Will ponder.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1292

From jlaskey at openjdk.java.net  Thu Nov 26 15:48:57 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 26 Nov 2020 15:48:57 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v6]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <RDLZpW-MD3pcnmv-E4JgU6fm2WiE6tb3WebyYJNCAmQ=.dcfd218c-f786-4ebf-ba27-07b5c018d082@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:

  8248862: Implement Enhanced Pseudo-Random Number Generators
  
  Propagate exception

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/a6851940..ca29ff74

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=05
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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+1059453+fleshgrinder at openjdk.java.net  Thu Nov 26 16:02:03 2020
From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger)
Date: Thu, 26 Nov 2020 16:02:03 GMT
Subject: RFR: 8207329: Add NIL Constant to UUID
Message-ID: <20Yg2C96fn72CooUiXZmbU6bQXRqLG6ghaTJtCglbPw=.ee410df0-40c7-43f9-9fa6-f6babbf00300@github.com>

Adds a constant for the special NIL UUID where all bits are zero to `java.util.UUID`. The [8207329](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8207329) mentions the usage of it to avoid `null`, it for sure is also very handy in testing where a UUID is required and we do not care about its actual value. Using a random UUID stresses the PRNG for no good reason.

-------------

Commit messages:
 - 8207329: Add NIL Constant to UUID

Changes: https://git.openjdk.java.net/jdk/pull/1460/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1460&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8207329
  Stats: 18 lines in 2 files changed: 17 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1460.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1460/head:pull/1460

PR: https://git.openjdk.java.net/jdk/pull/1460

From vlivanov at openjdk.java.net  Thu Nov 26 17:02:03 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 26 Nov 2020 17:02:03 GMT
Subject: RFR: 8257164: Share LambdaForms for VH linkers/invokers.
Message-ID: <ZTi7JmIqKWVIB5qAHg21Hgu5JuWzJ-nIxYE4JgXMaII=.12f143de-3bad-48fd-badc-878813817518@github.com>

Introduce sharing of `LambdaForms` for `VarHandle` linkers and invokers.
It reduces the number of LambdaForms needed at runtime.

Testing: tier1-4

-------------

Commit messages:
 - Share LambdaForms for VH linkers/invokers.

Changes: https://git.openjdk.java.net/jdk/pull/1455/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1455&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257164
  Stats: 48 lines in 3 files changed: 21 ins; 10 del; 17 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1455.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1455/head:pull/1455

PR: https://git.openjdk.java.net/jdk/pull/1455

From github.com+1059453+fleshgrinder at openjdk.java.net  Thu Nov 26 17:08:04 2020
From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger)
Date: Thu, 26 Nov 2020 17:08:04 GMT
Subject: RFR: 8170432: Class java.util.UUID & @Override
Message-ID: <4Snu6mJxW5hJjDupsOO0VvQHyKcVhXt2y7YAQHJ37YE=.535f2e20-3f3b-4cd3-a05e-3bd1293e5548@github.com>

Adds `@Override` annotation to all methods in `java.util.UUID` that implement methods from the implemented interfaces.

-------------

Commit messages:
 - 8170432: Class java.util.UUID & @Override

Changes: https://git.openjdk.java.net/jdk/pull/1463/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1463&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8170432
  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1463.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1463/head:pull/1463

PR: https://git.openjdk.java.net/jdk/pull/1463

From jlaskey at openjdk.java.net  Thu Nov 26 18:19:02 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Thu, 26 Nov 2020 18:19:02 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v7]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <CKLRPka8JQ6hONLQzkycqlQvxiEdxAav28a85mS9Akw=.60329c34-e9af-4f85-beff-3cb4b39cee19@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:

  8248862: Implement Enhanced Pseudo-Random Number Generators
  
  Cleanups from Chris H.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/ca29ff74..a8cc0795

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=06
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=05-06

  Stats: 13 lines in 1 file changed: 4 ins; 3 del; 6 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+1059453+fleshgrinder at openjdk.java.net  Thu Nov 26 18:30:02 2020
From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger)
Date: Thu, 26 Nov 2020 18:30:02 GMT
Subject: RFR: 5023614: UUID needs methods to get most/leastSigBits and write
 to DataOutput
Message-ID: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com>

Made byte constructor public and changed the length assertion to an `IllegalArgumentException`, added a `getBytes` method that allows users to retrieve the raw bytes of the UUID, and created a new private constructor with an optimized construction for byte arrays that can set the version as desired and the variant to RFC 4122. Also changed the existing static factory methods to use the new constructor and removed the duplicate code from them where the variant and version is being set.

Report [5023614](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5023614) asks for more than what I provided and with different names. However, I believe that there is no value in providing methods to deal with `DataInput` and `DataOutput` because they would only encapsulate single method calls that the caller can directly write as well (e.g. `output.write(uuid.getBytes())` vs `uuid.write(output)`). Hence, I consider this change to satisfy the feature request.

-------------

Commit messages:
 - 5023614: UUID needs methods to get most/leastSigBits and write to DataOutput

Changes: https://git.openjdk.java.net/jdk/pull/1465/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1465&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-5023614
  Stats: 115 lines in 2 files changed: 91 ins; 14 del; 10 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1465/head:pull/1465

PR: https://git.openjdk.java.net/jdk/pull/1465

From mcimadamore at openjdk.java.net  Thu Nov 26 18:34:03 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Thu, 26 Nov 2020 18:34:03 GMT
Subject: RFR: 8257186: Size of heap segments is not computed correctlyFix
 overflow in size computation for heap segments
Message-ID: <WYuRpdGnLvga-Y4K1Zae3yBb97eotVJY2Q-6doQrPhI=.3e1cf6ee-1565-4ad4-8001-d1e32ce29002@github.com>

There is a subtle bug in the heap segment factories: the byte size is computed using an int multiplication instead of a long multiplication. Because of that, it is possible to observe overflow when creating segments out of arrays whose carrier has a byte size greater than one.

-------------

Commit messages:
 - Fix overflow in size computation for heap segments

Changes: https://git.openjdk.java.net/jdk/pull/1466/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1466&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257186
  Stats: 29 lines in 2 files changed: 21 ins; 0 del; 8 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1466.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1466/head:pull/1466

PR: https://git.openjdk.java.net/jdk/pull/1466

From github.com+1059453+fleshgrinder at openjdk.java.net  Thu Nov 26 18:57:03 2020
From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger)
Date: Thu, 26 Nov 2020 18:57:03 GMT
Subject: RFR: 6594730: UUID.getVersion() is only meaningful for Leach-Salz
 variant
Message-ID: <NfEhSpKiiOh0bt2ociNETgE8wpvJDbxna_y5dwKY4_k=.cd887be7-2684-4508-9f04-a706af928f1e@github.com>

6594730: UUID.getVersion() is only meaningful for Leach-Salz variant

-------------

Commit messages:
 - 6594730: UUID.getVersion() is only meaningful for Leach-Salz variant

Changes: https://git.openjdk.java.net/jdk/pull/1467/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1467&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-6594730
  Stats: 16 lines in 2 files changed: 14 ins; 0 del; 2 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1467.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1467/head:pull/1467

PR: https://git.openjdk.java.net/jdk/pull/1467

From github.com+1059453+fleshgrinder at openjdk.java.net  Thu Nov 26 19:03:07 2020
From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger)
Date: Thu, 26 Nov 2020 19:03:07 GMT
Subject: RFR: 5023614: UUID needs methods to get most/leastSigBits and
 write to DataOutput [v2]
In-Reply-To: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com>
References: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com>
Message-ID: <WpxYw9aQm5zAjR0scgzvxKMWhhgB7SqDykLGkBEEIYI=.ef9c42f2-dfa8-495b-ba4a-03387b7e6a7b@github.com>

> Made byte constructor public and changed the length assertion to an `IllegalArgumentException`, added a `getBytes` method that allows users to retrieve the raw bytes of the UUID, and created a new private constructor with an optimized construction for byte arrays that can set the version as desired and the variant to RFC 4122. Also changed the existing static factory methods to use the new constructor and removed the duplicate code from them where the variant and version is being set.
> 
> Report [5023614](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5023614) asks for more than what I provided and with different names. However, I believe that there is no value in providing methods to deal with `DataInput` and `DataOutput` because they would only encapsulate single method calls that the caller can directly write as well (e.g. `output.write(uuid.getBytes())` vs `uuid.write(output)`). Hence, I consider this change to satisfy the feature request.

Richard Fussenegger 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:

  5023614: UUID needs methods to get most/leastSigBits and write to DataOutput
  
  Made byte constructor public and changed the length assertion to an `IllegalArgumentException`, added a `getBytes` method that allows users to retrieve the raw bytes of the UUID, and created a new private constructor with an optimized construction for byte arrays that can set the version as desired and the variant to RFC 4122. Also changed the existing static factory methods to use the new constructor and removed the duplicate code from them where the variant and version is being set. Report [5023614](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5023614) asks for more than what I provided and with different names. However, I believe that there is no value in providing methods to deal with `DataInput` and `DataOutput` because they would only encapsulate single method calls that the caller can directly write as well (e.g. `output.write(uuid.getBytes())` vs `uuid.write(output)`). Hence, I consider this change to satisfy the feature request.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1465/files
  - new: https://git.openjdk.java.net/jdk/pull/1465/files/fb46f74b..6813023d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1465&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1465&range=00-01

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1465/head:pull/1465

PR: https://git.openjdk.java.net/jdk/pull/1465

From alanb at openjdk.java.net  Thu Nov 26 19:03:08 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 26 Nov 2020 19:03:08 GMT
Subject: RFR: 5023614: UUID needs methods to get most/leastSigBits and
 write to DataOutput [v2]
In-Reply-To: <WpxYw9aQm5zAjR0scgzvxKMWhhgB7SqDykLGkBEEIYI=.ef9c42f2-dfa8-495b-ba4a-03387b7e6a7b@github.com>
References: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com>
 <WpxYw9aQm5zAjR0scgzvxKMWhhgB7SqDykLGkBEEIYI=.ef9c42f2-dfa8-495b-ba4a-03387b7e6a7b@github.com>
Message-ID: <xky6EB8mGrS1f2RpJGb8n2b_NlmKEZw3UqP17CG7UM8=.4e5f39a3-ab1a-4c95-8def-10e38eec0d04@github.com>

On Thu, 26 Nov 2020 18:59:57 GMT, Richard Fussenegger <github.com+1059453+Fleshgrinder at openjdk.org> wrote:

>> Made byte constructor public and changed the length assertion to an `IllegalArgumentException`, added a `getBytes` method that allows users to retrieve the raw bytes of the UUID, and created a new private constructor with an optimized construction for byte arrays that can set the version as desired and the variant to RFC 4122. Also changed the existing static factory methods to use the new constructor and removed the duplicate code from them where the variant and version is being set.
>> 
>> Report [5023614](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5023614) asks for more than what I provided and with different names. However, I believe that there is no value in providing methods to deal with `DataInput` and `DataOutput` because they would only encapsulate single method calls that the caller can directly write as well (e.g. `output.write(uuid.getBytes())` vs `uuid.write(output)`). Hence, I consider this change to satisfy the feature request.
>
> Richard Fussenegger 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:
> 
>   5023614: UUID needs methods to get most/leastSigBits and write to DataOutput
>   
>   Made byte constructor public and changed the length assertion to an `IllegalArgumentException`, added a `getBytes` method that allows users to retrieve the raw bytes of the UUID, and created a new private constructor with an optimized construction for byte arrays that can set the version as desired and the variant to RFC 4122. Also changed the existing static factory methods to use the new constructor and removed the duplicate code from them where the variant and version is being set. Report [5023614](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5023614) asks for more than what I provided and with different names. However, I believe that there is no value in providing methods to deal with `DataInput` and `DataOutput` because they would only encapsulate single method calls that the caller can directly write as well (e.g. `output.write(uuid.getBytes())` vs `uuid.write(output)`). Hence, I consider this change to satisfy the feature request.

src/java.base/share/classes/java/util/UUID.java line 151:

> 149:      * @throws IllegalArgumentException if {@code bytes} is not of length 16.
> 150:      * @since 16
> 151:      */

I think you need to agreement first on whether to add this API. Maybe there is a case for a new factory method rather than a constructor? Are there any concerns with creating UUIDs with random bytes.

If it goes ahead then I assume the the javadoc will need a bit of work to specify how the byte[] is mapped to the 128-bit value.

You might need to tweak a few other things like the javadoc styles and coding style to get it consistent with the existing code. That's for later.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1465

From dfuchs at openjdk.java.net  Thu Nov 26 19:04:02 2020
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 26 Nov 2020 19:04:02 GMT
Subject: RFR: 8170432: Class java.util.UUID & @Override
In-Reply-To: <4Snu6mJxW5hJjDupsOO0VvQHyKcVhXt2y7YAQHJ37YE=.535f2e20-3f3b-4cd3-a05e-3bd1293e5548@github.com>
References: <4Snu6mJxW5hJjDupsOO0VvQHyKcVhXt2y7YAQHJ37YE=.535f2e20-3f3b-4cd3-a05e-3bd1293e5548@github.com>
Message-ID: <sqg1FiMapqluM4wh81MWO5aZYkVeY_BxrNYfxzHdjeo=.a22dfa3a-da6c-4fbc-b597-e02079097291@github.com>

On Thu, 26 Nov 2020 17:01:59 GMT, Richard Fussenegger <github.com+1059453+Fleshgrinder at openjdk.org> wrote:

> Adds `@Override` annotation to all methods in `java.util.UUID` that implement methods from the implemented interfaces.

Hi,

This looks reasonable to me.

best regards,

-- daniel

-------------

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1463

From github.com+1059453+fleshgrinder at openjdk.java.net  Thu Nov 26 19:12:57 2020
From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger)
Date: Thu, 26 Nov 2020 19:12:57 GMT
Subject: RFR: 5023614: UUID needs methods to get most/leastSigBits and
 write to DataOutput [v2]
In-Reply-To: <xky6EB8mGrS1f2RpJGb8n2b_NlmKEZw3UqP17CG7UM8=.4e5f39a3-ab1a-4c95-8def-10e38eec0d04@github.com>
References: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com>
 <WpxYw9aQm5zAjR0scgzvxKMWhhgB7SqDykLGkBEEIYI=.ef9c42f2-dfa8-495b-ba4a-03387b7e6a7b@github.com>
 <xky6EB8mGrS1f2RpJGb8n2b_NlmKEZw3UqP17CG7UM8=.4e5f39a3-ab1a-4c95-8def-10e38eec0d04@github.com>
Message-ID: <2EG8nsujV7af7O-NZDulOcsilrMn2ZsjhJxJISfOsoQ=.3ffe5e3e-e78d-4f5e-b6bf-73d58636168a@github.com>

On Thu, 26 Nov 2020 18:53:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Richard Fussenegger 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.
>
> src/java.base/share/classes/java/util/UUID.java line 151:
> 
>> 149:      * @throws IllegalArgumentException if {@code bytes} is not of length 16.
>> 150:      * @since 16
>> 151:      */
> 
> I think you need to agreement first on whether to add this API. Maybe there is a case for a new factory method rather than a constructor? Are there any concerns with creating UUIDs with random bytes.
> 
> If it goes ahead then I assume the the javadoc will need a bit of work to specify how the byte[] is mapped to the 128-bit value.
> 
> You might need to tweak a few other things like the javadoc styles and coding style to get it consistent with the existing code. That's for later.

Hey @AlanBateman ?? I figured that most of the PRs I just created for UUID will require a CSR but I what couldn't figure out is/was how _I_ can create a CSR.

1. Constructor or factory, I would be fine with both and happily change the impl.
1. We de-facto already allow the construction from random data through the `UUID(long, long)` constructor.
1. No problem either.
1. I had a look at the whole (well, sampling) JDK and various documents ([super, super, like 1999 old documents](https://www.oracle.com/java/technologies/javase/codeconventions-introduction.html)) and loaded the Oracle code style in IntelliJ. However, all I get is inconsistent. The existing files in the JDK are inconsistent. The UUID file is inconsistent in itself. The IntelliJ Oracle style is different too? I'm happy to change any line but would prefer it if there is some guidance with what is expected because I cannot figure it out on my own. ??

-------------

PR: https://git.openjdk.java.net/jdk/pull/1465

From jvernee at openjdk.java.net  Thu Nov 26 19:30:02 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Thu, 26 Nov 2020 19:30:02 GMT
Subject: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout which
 returns a offset-computing method handle
Message-ID: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>

This upstreams the patch from: https://github.com/openjdk/panama-foreign/pull/396

There were only some minor merge conflicts due to imports and some tests being replaced by java/foreign/TestNulls. All tests still pass, no other changes were needed.

-------------

Commit messages:
 - Add a method to MemoryLayout which returns a offset-computing method handle

Changes: https://git.openjdk.java.net/jdk/pull/1468/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1468&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257184
  Stats: 312 lines in 4 files changed: 255 ins; 7 del; 50 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1468.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1468/head:pull/1468

PR: https://git.openjdk.java.net/jdk/pull/1468

From ihse at openjdk.java.net  Thu Nov 26 21:03:01 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Thu, 26 Nov 2020 21:03:01 GMT
Subject: RFR: 8256541: Sort out what version of awk is used in the build system
Message-ID: <aLi_MW67IJzuS2nkWq2d1iy6tiJA-Ogx1xyzx_ANlEY=.91de1d8b-eb7b-4d36-a16a-dbf225e4d3c3@github.com>

For historical reasons, there exists a variety of different implementations of awk: awk (the original implementation), gawk (the GNU version), nawk (new awk, iirc) and the lesser known mawk. 

Things are complicated by the fact that the original awk is seldom used, but instead gawk or nawk is typically symlinked to be named "awk". 

In terms of functionality there are very few differences. The original awk is most limited, while nawk and gawk is mostly replaceable. 

So the conditions for this is somewhat messy, but we manage impressively to mess it up even further. :-) 

We set up the following definitions: 
`BASIC_REQUIRE_PROGS(NAWK, [nawk gawk awk])`
`BASIC_REQUIRE_SPECIAL(AWK, [AC_PROG_AWK])`
and `AC_PROG_AWK`, according to the documentation, "[c]heck for gawk, mawk, nawk, and awk, in that order". 

So, if you have nawk and awk (but no other) installed, both NAWK and AWK will be set to nawk. If you have only awk, both will be set to awk. The difference is if you have gawk installed, then NAWK will be nawk and AWK will be gawk. 

As an example, on my mac, I only have the original awk, so both AWK and NAWK will be awk. 

On my ubuntu box, things are even more confused. I have: 
$ ls -l /usr/bin/*awk 
lrwxrwxrwx 1 root root 21 Feb 6 10:36 awk -> /etc/alternatives/awk* 
-rwxr-xr-x 1 root root 658072 Feb 11 2018 gawk* 
-rwxr-xr-x 1 root root 3189 Feb 11 2018 igawk* 
-rwxr-xr-x 1 root root 125416 Apr 3 2018 mawk* 
lrwxrwxrwx 1 root root 22 Feb 6 10:37 nawk -> /etc/alternatives/nawk* 

$ ls -l /etc/alternatives/*awk 
lrwxrwxrwx 1 root root 13 Feb 10 10:56 /etc/alternatives/awk -> /usr/bin/gawk* 
lrwxrwxrwx 1 root root 13 Feb 10 10:56 /etc/alternatives/nawk -> /usr/bin/gawk* 

So awk, nawk and gawk all executes the same binary, i.e. gawk. Only mawk is different. So on that machine, AWK would be gawk and NAWK would be nawk, but both will execute gawk. 

I propose that we remove NAWK, and only use AWK, but we should stop using AC_PROG_AWK and define it in an order that is transparent to us. I recommend [gawk nawk awk], since on Linux systems nawk (as we've seen) is likely to be gawk under disguise anyway, so it's better to be clear about that. 

This reasoning assumes that the awk scripts we write are portable enough to be executed by any awk. If we run into any problem with this, we might have to restrict the variation of awks we support.

To make this work properly, I also needed to get rid of the awk launched by fixpath in CompileCommand. (This only worked. since AWK was not evolved to a full path by `AC_PROG_AWK`, but was only `awk`(or whatever). Otherwise this could not work with fixpath, so it was very much a hack to begin with...

-------------

Commit messages:
 - Remove instance of awk in CompileCommand
 - 8256541: Sort out what version of awk is used in the build system

Changes: https://git.openjdk.java.net/jdk/pull/1470/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1470&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256541
  Stats: 35 lines in 15 files changed: 4 ins; 9 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1470.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1470/head:pull/1470

PR: https://git.openjdk.java.net/jdk/pull/1470

From vlivanov at openjdk.java.net  Thu Nov 26 21:59:03 2020
From: vlivanov at openjdk.java.net (Vladimir Ivanov)
Date: Thu, 26 Nov 2020 21:59:03 GMT
Subject: RFR: 8257189: Handle concurrent updates of MH.form better
Message-ID: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com>

Concurrent updates may lead to redundant LambdaForms created and unnecessary class loading when those are compiled. 

Most notably, it severely affects MethodHandle customization: when a MethodHandle is called from multiple threads, every thread starts customization which takes enough time for other threads to join, but only one of those customizations will be picked.

Coordination between threads requesting the updates and letting a single thread proceed avoids the aforementioned problem. Moreover, there's no need to wait until the update in-flight is over: all other threads (except the one performing the update) can just proceed with the invocation using the existing MH.form. 

Testing:
- manually monitored the behavior on a stress test from [JDK-8252049](https://bugs.openjdk.java.net/browse/JDK-8252049)
- tier1-4

-------------

Commit messages:
 - Improve concurrent LF customization

Changes: https://git.openjdk.java.net/jdk/pull/1472/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1472&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8257189
  Stats: 90 lines in 5 files changed: 38 ins; 20 del; 32 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1472.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1472/head:pull/1472

PR: https://git.openjdk.java.net/jdk/pull/1472

From jvernee at openjdk.java.net  Fri Nov 27 00:28:55 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 27 Nov 2020 00:28:55 GMT
Subject: RFR: 8257186: Size of heap segments is not computed correctlyFix
 overflow in size computation for heap segments
In-Reply-To: <WYuRpdGnLvga-Y4K1Zae3yBb97eotVJY2Q-6doQrPhI=.3e1cf6ee-1565-4ad4-8001-d1e32ce29002@github.com>
References: <WYuRpdGnLvga-Y4K1Zae3yBb97eotVJY2Q-6doQrPhI=.3e1cf6ee-1565-4ad4-8001-d1e32ce29002@github.com>
Message-ID: <6P5PK7GnMBdBnzqABQ6GZR7y3AiECAzgdPVWbQw1X9Q=.15dd02fb-0b63-48a5-bea0-4096ecea873d@github.com>

On Thu, 26 Nov 2020 18:29:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> There is a subtle bug in the heap segment factories: the byte size is computed using an int multiplication instead of a long multiplication. Because of that, it is possible to observe overflow when creating segments out of arrays whose carrier has a byte size greater than one.

Marked as reviewed by jvernee (Committer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1466

From dholmes at openjdk.java.net  Fri Nov 27 02:08:59 2020
From: dholmes at openjdk.java.net (David Holmes)
Date: Fri, 27 Nov 2020 02:08:59 GMT
Subject: RFR: 8256486: Linux/Windows-x86 builds broken after JDK-8254231
 [v7]
In-Reply-To: <Y24gSOMDZcZ8R4Wne89gp0pywJJLbe-zvRrzHc2J03k=.d29fb26f-7e3a-4531-bae3-d7eea4ae9d15@github.com>
References: <MPC8XS0ZGjowt_KM3ppxHzqK1WumKKoLhN6J7sHBx6o=.34f55bf1-b3c2-4e02-b340-1fda6eb9de1e@github.com>
 <Y24gSOMDZcZ8R4Wne89gp0pywJJLbe-zvRrzHc2J03k=.d29fb26f-7e3a-4531-bae3-d7eea4ae9d15@github.com>
Message-ID: <bfmJ5kIoTUJG-Q5s77zIvIfACBLn9TzTDhCsC8BZp9o=.a69d4263-3948-4b66-8c2b-d64440857998@github.com>

On Wed, 25 Nov 2020 12:09:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> JDK-8254231 breaks the Linux and Windows x86 (32-bit) builds. This contains the needed changes to get it working again.
>> 
>> Perhaps the most interesting change is adding the `JNI_ENTRY_CPP_NOENV` macro. Using just JNI_ENTRY was causing a linkage failure, due to the declaration of the function in the class not having the same linkage specifiers. It looks like we can't just specify C linkage for class member functions.
>> 
>> However, in this case C linkage is not required, so I've added the new macro which doesn't have `extern "C"`. I've also dropped the `JNIEnv*` parameter, since it was not being used, but causing extra work for the caller.
>> 
>> Other than that, it's just about adding default definitions for missing functions, and moving around some code in MacroAssembler to be in the correct `#ifdef` blocks.
>> 
>> Testing: `make images` on Linux and Windows x86_32 platforms.
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pass in thread instead of rematerializing it.

src/hotspot/share/prims/universalUpcallHandler.cpp line 37:

> 35: 
> 36: void ProgrammableUpcallHandler::upcall_helper(JavaThread* thread, jobject rec, address buff) {
> 37:   JavaThread* THREAD = thread;

You could have just named the parameter THREAD.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1266

From chegar at openjdk.java.net  Fri Nov 27 09:09:02 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 27 Nov 2020 09:09:02 GMT
Subject: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout
 which returns a offset-computing method handle
In-Reply-To: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>
References: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>
Message-ID: <tE-LZ2XrOWjIV5bT21y8vkUQc9t_Q0G-UXRZLEJ6K1I=.76e3be97-9181-499a-8745-37c006197cee@github.com>

On Thu, 26 Nov 2020 19:24:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This upstreams the patch from: https://github.com/openjdk/panama-foreign/pull/396
> 
> There were only some minor merge conflicts due to imports and some tests being replaced by java/foreign/TestNulls. All tests still pass, no other changes were needed.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8257187

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java line 379:

> 377:      * multiple sequence element indices (see {@link PathElement#sequenceElement(long, long)}).
> 378:      * @throws UnsupportedOperationException if one of the layouts traversed by the layout path has unspecified size.
> 379:      * @throws NullPointerException if either {@code elements == null}, or if any of the elements

Given the recent class-level note about null handling, then this explicit at NullPointerException tag can probably be dropped.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1468

From chegar at openjdk.java.net  Fri Nov 27 09:14:59 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 27 Nov 2020 09:14:59 GMT
Subject: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout
 which returns a offset-computing method handle
In-Reply-To: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>
References: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>
Message-ID: <wquBf5Y4nZVvClILlrrrLUBzcq9-P83jSQczSdxnCGI=.4089f94b-ab72-4e1e-8873-8e8dee103def@github.com>

On Thu, 26 Nov 2020 19:24:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This upstreams the patch from: https://github.com/openjdk/panama-foreign/pull/396
> 
> There were only some minor merge conflicts due to imports and some tests being replaced by java/foreign/TestNulls. All tests still pass, no other changes were needed.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8257187

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java line 433:

> 431:      * multiple sequence element indices (see {@link PathElement#sequenceElement(long, long)}).
> 432:      * @throws UnsupportedOperationException if one of the layouts traversed by the layout path has unspecified size.
> 433:      * @throws NullPointerException if either {@code elements == null}, or if any of the elements

Given the recent class-level note about null handling, then this explicit at NullPointerException tag can probably be dropped.

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java line 423:

> 421:      * arguments, whereas {@code c_1}, {@code c_2}, ... {@code c_m} and {@code s_0}, {@code s_1}, ... {@code s_n} are
> 422:      * <em>static</em> stride constants which are derived from the layout path.
> 423:      *

Would it be worth adding a simple example that demonstrates how this particular MH can be used, e.g.
with a sequence layout of say 10 Java ints ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1468

From chegar at openjdk.java.net  Fri Nov 27 09:16:58 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 27 Nov 2020 09:16:58 GMT
Subject: RFR: 8257186: Size of heap segments is not computed correctlyFix
 overflow in size computation for heap segments
In-Reply-To: <WYuRpdGnLvga-Y4K1Zae3yBb97eotVJY2Q-6doQrPhI=.3e1cf6ee-1565-4ad4-8001-d1e32ce29002@github.com>
References: <WYuRpdGnLvga-Y4K1Zae3yBb97eotVJY2Q-6doQrPhI=.3e1cf6ee-1565-4ad4-8001-d1e32ce29002@github.com>
Message-ID: <TDfVrEhRgSGMcEJ7Y7jSZ7-nc--d1D0qE2khDSQegDw=.b4ca06db-8ab8-4c75-9a66-5856b4a08025@github.com>

On Thu, 26 Nov 2020 18:29:42 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> There is a subtle bug in the heap segment factories: the byte size is computed using an int multiplication instead of a long multiplication. Because of that, it is possible to observe overflow when creating segments out of arrays whose carrier has a byte size greater than one.

Marked as reviewed by chegar (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1466

From chegar at openjdk.java.net  Fri Nov 27 09:36:15 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 27 Nov 2020 09:36:15 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
Message-ID: <Tb-ywtW1oSQgE5j2Oj6OAl8Qaq_l-JX2uW8Twjp_fxo=.b252bd5f-60db-4b19-8b0e-321c9007f0db@github.com>

On Wed, 25 Nov 2020 22:51:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> 
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
> 
>  - Clarified that suffix() and prefix() methods do not return null, instead the empty string is returned.
>  - Merge branch 'master' into 8251989-hex-formatter
>  - Merge branch 'master' into 8251989-hex-formatter
>  - Merge branch 'master' into 8251989-hex-formatter
>  - The HexFormat API indexing model for array and string ranges is changed
>    to describe the range using 'fromIndex (inclusive)' and 'toIndex (exclusive)'.
>    
>    Initially, it was specified as 'index' and 'length'. However, both byte arrays
>    and strings used in the HexFormat API typically use fromIndex and toIndex
>    to describe ranges.  Using the same indexing model can prevent mistakes.
>    
>    The change affects the methods and corresponding tests:
>    
>        formatHex(byte[] bytes, int fromIndex, int toIndex)
>        formatHex(A out, byte[] bytes, int fromIndex, int toIndex)
>        parseHex(char[] chars, int fromIndex, int toIndex)
>        parseHex(CharSequence string, int fromIndex, int toIndex)
>        fromHexDigits(CharSequence string, int fromIndex, int toIndex)
>        fromHexDigitsToLong(CharSequence string, int fromIndex, int toIndex)
>  - - Added @see and @link references to Integer.toHexString and Long.toHexString
>    - Clarified parsing is case insensistive in various parse and fromXXX methods
>    - Source level cleanup based on review comments
>    - Expanded some javadoc tag text to make it more descriptive
>    - Consistent use of 'hexadecimal' vs 'hex'
>  - Review comment updates to class javadoc
>  - Review comment updates, in the example code, and to describe the characters used to convert to hexadecimal
>  - Correct length of StringBuilder in formatHex;
>    Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]
>  - Merge branch 'master' into 8251989-hex-formatter
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/5386ae35...b19d2827

src/java.base/share/classes/java/util/HexFormat.java line 255:

> 253: 
> 254:     /**
> 255:      * Returns the delimiter between hexadecimal values in a formatted byte array.

"... in a formatted byte array", I find this wording a little hard to follow. The delimiter, prefix, suffix apply to *formatted hexadecimal strings*.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From chegar at openjdk.java.net  Fri Nov 27 10:49:21 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 27 Nov 2020 10:49:21 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
Message-ID: <syZl_FvX-peawrEAraEjVOWcgZPbLT3cvepCqQdf480=.b0dc1357-bf83-43fe-b0de-b3356d45994c@github.com>

On Wed, 25 Nov 2020 22:51:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> 
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
> 
>  - Clarified that suffix() and prefix() methods do not return null, instead the empty string is returned.
>  - Merge branch 'master' into 8251989-hex-formatter
>  - Merge branch 'master' into 8251989-hex-formatter
>  - Merge branch 'master' into 8251989-hex-formatter
>  - The HexFormat API indexing model for array and string ranges is changed
>    to describe the range using 'fromIndex (inclusive)' and 'toIndex (exclusive)'.
>    
>    Initially, it was specified as 'index' and 'length'. However, both byte arrays
>    and strings used in the HexFormat API typically use fromIndex and toIndex
>    to describe ranges.  Using the same indexing model can prevent mistakes.
>    
>    The change affects the methods and corresponding tests:
>    
>        formatHex(byte[] bytes, int fromIndex, int toIndex)
>        formatHex(A out, byte[] bytes, int fromIndex, int toIndex)
>        parseHex(char[] chars, int fromIndex, int toIndex)
>        parseHex(CharSequence string, int fromIndex, int toIndex)
>        fromHexDigits(CharSequence string, int fromIndex, int toIndex)
>        fromHexDigitsToLong(CharSequence string, int fromIndex, int toIndex)
>  - - Added @see and @link references to Integer.toHexString and Long.toHexString
>    - Clarified parsing is case insensistive in various parse and fromXXX methods
>    - Source level cleanup based on review comments
>    - Expanded some javadoc tag text to make it more descriptive
>    - Consistent use of 'hexadecimal' vs 'hex'
>  - Review comment updates to class javadoc
>  - Review comment updates, in the example code, and to describe the characters used to convert to hexadecimal
>  - Correct length of StringBuilder in formatHex;
>    Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]
>  - Merge branch 'master' into 8251989-hex-formatter
>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/55be0a99...b19d2827

Changes requested by chegar (Reviewer).

src/java.base/share/classes/java/util/HexFormat.java line 71:

> 69:  * <p>
> 70:  * For formatted hexadecimal string to byte array conversions the
> 71:  * {@code parseHex} methods include {@link #parseHex(CharSequence) parseHex(string)} and

parseHex(string) -> parseHex(CharSequence)

src/java.base/share/classes/java/util/HexFormat.java line 467:

> 465: 
> 466:     /**
> 467:      * Returns a byte array containing hexadecimal values parsed from a range of the string.

string -> charSequence. And flow through at param tag and param name.

src/java.base/share/classes/java/util/HexFormat.java line 448:

> 446: 
> 447:     /**
> 448:      * Returns a byte array containing hexadecimal values parsed from the string.

string -> charSequence. And flow through at param tag and param name.

src/java.base/share/classes/java/util/HexFormat.java line 528:

> 526:      * a range of the character array.
> 527:      *
> 528:      * Each byte value is parsed as the prefix, two case insensitive hexadecimal characters,

Each *char* value ...

src/java.base/share/classes/java/util/HexFormat.java line 538:

> 536:      * @param toIndex the final index of the range, exclusive.
> 537:      * @return a byte array with the values parsed from the character array range
> 538:      * @throws IllegalArgumentException if the prefix or suffix is not present for each byte value,

... for each *char* value ...  OR ... for each pair of char values?

src/java.base/share/classes/java/util/HexFormat.java line 617:

> 615:      * Returns the two hexadecimal characters for the {@code byte} value.
> 616:      * Each nibble (4 bits) from most significant to least significant of the value
> 617:      * is formatted as if by {@link #toLowHexDigit(int) toLowHexDigit(nibble)}.

It might be more straightforward to frame this in terms of toLowHexDigit and toHighHexDigit (rather than only toLowHexDigit).  `nibble`- should the param name for to(Low|High)HexDigit be named `nibble` ?

src/java.base/share/classes/java/util/HexFormat.java line 860:

> 858: 
> 859:     /**
> 860:      * Returns a value parsed from two hexadecimal characters in a string.

sting -> charsequence   ( same comment more generally, anywhere a charsequence is referred to as a string )

src/java.base/share/classes/java/util/HexFormat.java line 47:

> 45:  * or choice of {@link #withUpperCase()} or {@link #withLowerCase()} parameters.
> 46:  * <p>
> 47:  * For primitive to hexadecimal string conversions the {@code toHexDigits}

It took me a little while to grok the naming convention being used here. It might be helpful to ensure that all the terms are clearly defined and used consistently throughout. 

"hexadecimal string"  - consists of just 0-9, a-f, A-F  (i.e. no delimiter, prefix, suffix)
"formatted hexadecimal string" - consists of hexadecimal string, and prefix, delimiter, suffix.

The `parseXXX` and `formatXXX` are logically related - and operate on "formatted hexadecimal strings"

The `toXXX` and `fromXXX` are logically related - one is kind of the inverse of the other. And these operate (even when accepting/producing chars) on "hexadecimal strings" - ignoring almost all properties of the HexFormat, except the toXXX cares about upper/lower case. Does `fromXXX` care about upper/lower ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From mcimadamore at openjdk.java.net  Fri Nov 27 10:50:56 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 27 Nov 2020 10:50:56 GMT
Subject: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout
 which returns a offset-computing method handle
In-Reply-To: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>
References: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>
Message-ID: <w6PeWOE4DjaNcNNihIUEVTDCTRA_hpih7192EEdVwQs=.9549e013-3527-42c3-bfb7-30b7090c2347@github.com>

On Thu, 26 Nov 2020 19:24:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> This upstreams the patch from: https://github.com/openjdk/panama-foreign/pull/396
> 
> There were only some minor merge conflicts due to imports and some tests being replaced by java/foreign/TestNulls. All tests still pass, no other changes were needed.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8257187

Looks good

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1468

From mcimadamore at openjdk.java.net  Fri Nov 27 10:50:58 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 27 Nov 2020 10:50:58 GMT
Subject: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout
 which returns a offset-computing method handle
In-Reply-To: <wquBf5Y4nZVvClILlrrrLUBzcq9-P83jSQczSdxnCGI=.4089f94b-ab72-4e1e-8873-8e8dee103def@github.com>
References: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>
 <wquBf5Y4nZVvClILlrrrLUBzcq9-P83jSQczSdxnCGI=.4089f94b-ab72-4e1e-8873-8e8dee103def@github.com>
Message-ID: <ambjbErjkJHuTsp9nCNdEVS1sp01c2MTP5yrv0mreyc=.b0f20808-26e3-465d-a3e3-834e03ed8c53@github.com>

On Fri, 27 Nov 2020 09:11:30 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> This upstreams the patch from: https://github.com/openjdk/panama-foreign/pull/396
>> 
>> There were only some minor merge conflicts due to imports and some tests being replaced by java/foreign/TestNulls. All tests still pass, no other changes were needed.
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8257187
>
> src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java line 423:
> 
>> 421:      * arguments, whereas {@code c_1}, {@code c_2}, ... {@code c_m} and {@code s_0}, {@code s_1}, ... {@code s_n} are
>> 422:      * <em>static</em> stride constants which are derived from the layout path.
>> 423:      *
> 
> Would it be worth adding a simple example that demonstrates how this particular MH can be used, e.g.
> with a sequence layout of say 10 Java ints ?

Good idea - note though that we have a section in the toplevel javadoc which describes a complex layout and how to get info out of it using the various methods in this API (including MemoryLayout::varHandle). Perhaps that would be a good place where to add the example, rather than in the method javadoc?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1468

From chegar at openjdk.java.net  Fri Nov 27 12:31:12 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 27 Nov 2020 12:31:12 GMT
Subject: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout
 which returns a offset-computing method handle [v2]
In-Reply-To: <nvNa1xOAPUg1NqUdKF1tHdW4SPyjdAukEodQuwTKsbE=.b9200f23-225a-4f87-b3b7-4298bac74283@github.com>
References: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>
 <nvNa1xOAPUg1NqUdKF1tHdW4SPyjdAukEodQuwTKsbE=.b9200f23-225a-4f87-b3b7-4298bac74283@github.com>
Message-ID: <AzuolalQosNaX1Er_0vUVexV7s7Tm4a_Xzbd2z3u1Wk=.ae2c8831-5aed-44ba-8586-be54bef80c80@github.com>

On Fri, 27 Nov 2020 12:28:01 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This upstreams the patch from: https://github.com/openjdk/panama-foreign/pull/396
>> 
>> There were only some minor merge conflicts due to imports and some tests being replaced by java/foreign/TestNulls. All tests still pass, no other changes were needed.
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8257187
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments:
>   - remove explicit @throws NPE tags
>   - add example to class doc

Thanks for considering the comments. Looks good to me.

-------------

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1468

From jvernee at openjdk.java.net  Fri Nov 27 12:31:12 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 27 Nov 2020 12:31:12 GMT
Subject: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout
 which returns a offset-computing method handle [v2]
In-Reply-To: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>
References: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>
Message-ID: <nvNa1xOAPUg1NqUdKF1tHdW4SPyjdAukEodQuwTKsbE=.b9200f23-225a-4f87-b3b7-4298bac74283@github.com>

> This upstreams the patch from: https://github.com/openjdk/panama-foreign/pull/396
> 
> There were only some minor merge conflicts due to imports and some tests being replaced by java/foreign/TestNulls. All tests still pass, no other changes were needed.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8257187

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments:
  - remove explicit @throws NPE tags
  - add example to class doc

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1468/files
  - new: https://git.openjdk.java.net/jdk/pull/1468/files/1557fe64..4b632628

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1468&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1468&range=00-01

  Stats: 17 lines in 1 file changed: 13 ins; 4 del; 0 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1468.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1468/head:pull/1468

PR: https://git.openjdk.java.net/jdk/pull/1468

From jvernee at openjdk.java.net  Fri Nov 27 12:31:13 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 27 Nov 2020 12:31:13 GMT
Subject: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout
 which returns a offset-computing method handle [v2]
In-Reply-To: <w6PeWOE4DjaNcNNihIUEVTDCTRA_hpih7192EEdVwQs=.9549e013-3527-42c3-bfb7-30b7090c2347@github.com>
References: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>
 <w6PeWOE4DjaNcNNihIUEVTDCTRA_hpih7192EEdVwQs=.9549e013-3527-42c3-bfb7-30b7090c2347@github.com>
Message-ID: <1FXsgMcJVvC3C1PAxajn3ilzmlbTYSEP-g_qWBLwUWg=.cd57422e-1713-40ba-8812-29d6ca7844c9@github.com>

On Fri, 27 Nov 2020 10:48:31 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments:
>>   - remove explicit @throws NPE tags
>>   - add example to class doc
>
> Looks good

All good suggestions. I've implemented them now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1468

From sirinath1978m at gmail.com  Fri Nov 27 12:35:42 2020
From: sirinath1978m at gmail.com (Suminda Sirinath Salpitikorala Dharmasena)
Date: Fri, 27 Nov 2020 18:05:42 +0530
Subject: @Contended and @IntrinsicCandidate for user code
Message-ID: <CAAfFNYHeE-HpECNTyObqpy_bx-OLjTXBcrg1DiTUszP83EaPcw@mail.gmail.com>

Hello,

Can @Contended and @IntrinsicCandidate annotations be moved out of internal
so user code can use it? This can start by perhaps ironing out any
issues that might prevent it from being made accessible for user code.

Suminda

From dawid.weiss at gmail.com  Fri Nov 27 12:37:50 2020
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Fri, 27 Nov 2020 13:37:50 +0100
Subject: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data
 field of exactly 5 bytes)
In-Reply-To: <CAM21Rt_8WWsTm-DrY=stscEuiWXF1-JJkv83wZoReJB7ZD-Kjw@mail.gmail.com>
References: <CAM21Rt8KeWyQvjE7-5pfyXYJXO3yGgGfKpBtueOV8qgNFMa+jQ@mail.gmail.com>
 <17F644E3-E5E0-403E-B568-FCB89C8BD9BB@ORACLE.COM>
 <CAM21Rt-ANpHbDO-kjSHguDzSTGS-WhGwHsbxcHav1wFVvDQ2EQ@mail.gmail.com>
 <CAM21Rt_8WWsTm-DrY=stscEuiWXF1-JJkv83wZoReJB7ZD-Kjw@mail.gmail.com>
Message-ID: <CAM21Rt9tHhGf7+eKfrrLbPwP8jShZytF6Qh_3OS4yxVg=02hWQ@mail.gmail.com>

Just for the archives - I'm not sure if this ended up being filed to
the bug system - the repro below demonstrates the bug on all JDKs up
to the newest one.

# create a single random file of 250 megabytes
head -c 250M < /dev/urandom > rnd.bin
# create a bunch of hardlinks to the same file.
for i in `seq -w 1 25`; do ln rnd.bin rnd-$i.bin; done
# create a zip archive exceeding 4gb (in stored mode so that it's faster)
zip -0 archive.zip rnd*.bin
# show the content of the archive - for all entries beyond 4gb this should
# show extra data blocks like below (note the order of extra data
blocks - this is important).
#
#  The central-directory extra field contains:
# - A subfield with ID 0x5455 (universal time) and 5 data bytes.
#   The local extra field has UTC/GMT modification/access times.
# - A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
#   01 04 ea 03 00 00 04 ea 03 00 00.
# - A subfield with ID 0x0001 (PKWARE 64-bit sizes) and 8 data bytes:
 #  a4 06 a0 86 01 00 00 00.
#
zipinfo -v archive.zip

# Bug repro code:
cat > Test.java <<EOF
import java.io.*;
import java.nio.*;
import java.nio.file.*;
import java.nio.file.attribute.*;

public class Test {
  public static void main(String[]args) throws IOException {
    try (FileSystem fs = FileSystems.newFileSystem(Paths.get("archive.zip"))) {
      for (Path root : fs.getRootDirectories()) {
        Files.walkFileTree(root, new SimpleFileVisitor<>() {
          public FileVisitResult visitFile(Path file,
BasicFileAttributes attrs) throws IOException {
            return FileVisitResult.CONTINUE;
          }
        });
      }
    }
  }
}
EOF
# and run it.
java Test.java

The above ends with:

Exception in thread "main" java.util.zip.ZipException: loc: wrong sig ->841cd111
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readExtra(ZipFileSystem.java:2899)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readCEN(ZipFileSystem.java:2600)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.<init>(ZipFileSystem.java:2536)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.getFileAttributes(ZipFileSystem.java:532)
        at jdk.zipfs/jdk.nio.zipfs.ZipPath.readAttributes(ZipPath.java:767)
        at jdk.zipfs/jdk.nio.zipfs.ZipPath.readAttributes(ZipPath.java:777)
        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.readAttributes(ZipFileSystemProvider.java:276)
        at java.base/java.nio.file.Files.readAttributes(Files.java:1843)
        at java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:219)
        at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:276)
        at java.base/java.nio.file.FileTreeWalker.next(FileTreeWalker.java:373)
        at java.base/java.nio.file.Files.walkFileTree(Files.java:2840)
        at java.base/java.nio.file.Files.walkFileTree(Files.java:2876)
        at Test.main(Test.java:10)

The fix is relatively simple I think - the current code assumes entry
offset is < 4GB when parsing extra data for
ID 0x5455. This should be evaluated lazily after all extra data blocks
are parsed to ensure the file offset is correctly
updated based on block ID 0x0001, regardless of its ordering within
other extra data blocks.



On Fri, Oct 23, 2020 at 9:12 AM Dawid Weiss <dawid.weiss at gmail.com> wrote:
>
>
> This looks like a legitimate bug to me (the zip file system implementation is sensitive to the order of extra parameters and may throw an unexpected error
> on zip64 archives exceeding 4 gigabytes). I can't file a Jira issue - no permissions - but I think it'd be worth adding one?
>
> Dawid
>
> On Wed, Oct 21, 2020 at 8:36 PM Dawid Weiss <dawid.weiss at gmail.com> wrote:
>>
>> Hi Lance,
>>
>> Yes, this is exactly the point where the problem is in JDK code. It's directly
>> related to the zip entry beyond max int offset. The code tries to read data
>> from a local zip entry header at locoff, here:
>>
>> if (zipfs.readFullyAt(buf, 0, buf.length , locoff)
>>
>> but the locoff is set to ~0 as per the spec for files exceeding
>> 4 gigabytes, which says:
>>
>>    4.4.16 relative offset of local header: (4 bytes)
>>
>>        This is the offset from the start of the first disk on
>>        which this file appears, to where the local header SHOULD
>>        be found.  If an archive is in ZIP64 format and the value
>>        in this field is 0xFFFFFFFF, the size will be in the
>>        corresponding 8 byte zip64 extended information extra field.
>>
>> A proper fix would be to read the local header from zip64 extra data
>> first. I don't know how this interferes with the rest of the code though -
>> didn't have enough time to look at it. As it stands, zip entries
>> beyond 4GB cause
>> an unchecked exception while attribute-scanning. This simple snippet
>> is enough to demonstrate it, given a ZIP entry beyond 4GB range:
>>
>> try (FileSystem fs =
>> FileSystems.newFileSystem(Paths.get("zipWithEntryBeyond4Gb.zip"))) {
>>   for (Path root : fs.getRootDirectories()) {
>>     Files.walkFileTree(root, new SimpleFileVisitor<>() {
>>       @Override
>>       public FileVisitResult visitFile(Path file, BasicFileAttributes
>> attrs) throws IOException {
>>         return FileVisitResult.CONTINUE;
>>       }
>>     });
>>   }
>> }
>>
>> The walkFileTree method is key here as it attempts to harvest
>> attributes (why we use it is another story -- this saves a lot of time
>> on large, network-mounted regular directories when you're collecting
>> file metadata).
>>
>>
>> Dawid
>>
>>
>> On Wed, Oct 21, 2020 at 6:39 PM Lance Andersen
>> <LANCE.ANDERSEN at oracle.com> wrote:
>> >
>> > Hi David,
>> >
>> > From  a quick look at ZipFileSystem this appears to be an optimization to avoid looking at the LOC extended Timestamp Extra field
>> >
>> > If a Info-ZIP Extended Timestamp (0x5455)is found then:
>> >
>> >   If the "zipinfo-time" entry was set  to ?false? in the Map specified when creating the Zip FileSystem,
>> >
>> > FileSystems.newFileSystem(zipFile, Map.of("zipinfo-time", "false")
>> >
>> > and the  data size of the CEN extended Timestamp is 5 (flag + mod time)
>> >
>> > The modified time is used from the CEN Extended Timestamp extra field
>> >
>> > Otherwise get the modified time, creation time, and access time from the LOC Extended Timestamp extra field.
>> >
>> >
>> > ?????
>> >
>> >  Extended Timestamp Extra Field:
>> >
>> >           ==============================
>> >
>> >           The following is the layout of the extended-timestamp extra block.
>> >           (Last Revision 19970118)
>> >
>> >           Local-header version:
>> >
>> >           Value         Size        Description
>> >           -----         ----        -----------
>> >   (time)  0x5455        Short       tag for this extra block type ("UT")
>> >           TSize         Short       total data size for this block
>> >           Flags         Byte        info bits
>> >           (ModTime)     Long        time of last modification (UTC/GMT)
>> >           (AcTime)      Long        time of last access (UTC/GMT)
>> >           (CrTime)      Long        time of original creation (UTC/GMT)
>> >
>> >           Central-header version:
>> >
>> >           Value         Size        Description
>> >           -----         ----        -----------
>> >   (time)  0x5455        Short       tag for this extra block type ("UT")
>> >           TSize         Short       total data size for this block
>> >           Flags         Byte        info bits (refers to local header!)
>> >           (ModTime)     Long        time of last modification (UTC/GMT)
>> >
>> >           The central-header extra field contains the modification time only,
>> >           or no timestamp at all.  TSize is used to flag its presence or
>> >           absence.  But note:
>> >
>> >               If "Flags" indicates that Modtime is present in the local header
>> >               field, it MUST be present in the central header field, too!
>> >               This correspondence is required because the modification time
>> >               value may be used to support trans-timezone freshening and
>> >               updating operations with zip archives.
>> >
>> >           The time values are in standard Unix signed-long format, indicating
>> >           the number of seconds since 1 January 1970 00:00:00.  The times
>> >           are relative to Coordinated Universal Time (UTC), also sometimes
>> >           referred to as Greenwich Mean Time (GMT).  To convert to local time,
>> >           the software must know the local timezone offset from UTC/GMT.
>> >
>> >           The lower three bits of Flags in both headers indicate which time-
>> >           stamps are present in the LOCAL extra field:
>> >
>> >                 bit 0           if set, modification time is present
>> >                 bit 1           if set, access time is present
>> >                 bit 2           if set, creation time is present
>> >                 bits 3-7        reserved for additional timestamps; not set
>> >
>> >           Those times that are present will appear in the order indicated, but
>> >           any combination of times may be omitted.  (Creation time may be
>> >           present without access time, for example.)  TSize should equal
>> >           (1 + 4*(number of set bits in Flags)), as the block is currently
>> >           defined.  Other timestamps may be added in the future.
>> >
>> >
>> > --------------
>> >
>> > It's hard to comment on why you received the error that you did but it is possible the tool that was used for writing the entry  did something unexpected.
>> >
>> > Out of curiosity, have you tried using ZipFile/ZipEntry to access the entry?
>> >
>> >
>> > Best,
>> > Lance
>> >
>> >
>> > On Oct 21, 2020, at 4:55 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
>> >
>> > Hello,
>> >
>> > We've encountered a seemingly valid ZIP file (zipinfo -v shows all its
>> > entries are intact) that causes a runtime exception when scanning its
>> > contents with ZipFileSystem. The exception indicates an invalid
>> > signature when parsing EXTID_EXTT. I don't quite understand this
>> > comment in the code:
>> >
>> > case EXTID_EXTT:
>> >    // spec says the Extened timestamp in cen only has mtime
>> >    // need to read the loc to get the extra a/ctime, if flag
>> >    // "zipinfo-time" is not specified to false;
>> >    // there is performance cost (move up to loc and read) to
>> >    // access the loc table foreach entry;
>> >    if (zipfs.noExtt) {
>> >        if (sz == 5)
>> >            mtime = unixToJavaTime(LG(extra, pos + 1));
>> >         break;
>> >    }
>> > ...
>> >
>> > but this ZIP file has the extra data block of exactly 5 bytes, as
>> > indicated by zipinfo:
>> >
>> > Central directory entry #6:
>> > ---------------------------
>> > ...
>> >  file system or operating system of origin:      Unix
>> >  version of encoding software:                   3.0
>> >  minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
>> >  minimum software version required to extract:   2.0
>> >  compression method:                             deflated
>> > ...
>> >  extended local header:                          no
>> >  file last modified on (DOS date/time):          2018 Mar 1 04:56:20
>> >  file last modified on (UT extra field modtime): 2018 Mar 1 05:56:19 local
>> >  file last modified on (UT extra field modtime): 2018 Mar 1 04:56:19 UTC
>> > ...
>> >  Unix file attributes (100000 octal):            ----------
>> >  MS-DOS file attributes (01 hex):                read-only
>> >
>> >  The central-directory extra field contains:
>> >  - A subfield with ID 0x5455 (universal time) and 5 data bytes.
>> >    The local extra field has UTC/GMT modification/access times.
>> >
>> > The above conditional block checking for length == 5 would have worked
>> > in ZipFileSystem but it's surrounded by a condition over an
>> > externally-provided property - zipfs.noExtt is only set to true if:
>> >
>> > this.noExtt = "false".equals(env.get("zipinfo-time"));
>> >
>> > I can't share this particular ZIP file with you and I don't know how
>> > it was created but it seems like that "zipinfo-time" flag could be
>> > omitted if the length of the extra data field is exactly 5?
>> >
>> > Dawid
>> >
>> >
>> >
>> > Best
>> > Lance
>> > ------------------
>> >
>> >
>> >
>> > 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
>> >
>> >
>> >
>> >

From redestad at openjdk.java.net  Fri Nov 27 14:48:58 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 27 Nov 2020 14:48:58 GMT
Subject: RFR: 8257189: Handle concurrent updates of MH.form better
In-Reply-To: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com>
References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com>
Message-ID: <ujT5iwIGAs5P7-3rZ8mjOSF1G8ZtaC-AsACmKD4SyL0=.cd65f664-3d85-4611-8231-a1a33feaf8e2@github.com>

On Thu, 26 Nov 2020 21:23:16 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Concurrent updates may lead to redundant LambdaForms created and unnecessary class loading when those are compiled. 
> 
> Most notably, it severely affects MethodHandle customization: when a MethodHandle is called from multiple threads, every thread starts customization which takes enough time for other threads to join, but only one of those customizations will be picked.
> 
> Coordination between threads requesting the updates and letting a single thread proceed avoids the aforementioned problem. Moreover, there's no need to wait until the update in-flight is over: all other threads (except the one performing the update) can just proceed with the invocation using the existing MH.form. 
> 
> Testing:
> - manually monitored the behavior on a stress test from [JDK-8252049](https://bugs.openjdk.java.net/browse/JDK-8252049)
> - tier1-4

Looks good to me! 

A couple of trivial nits inline..

src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 459:

> 457:     // asTypeCache is not private so that invokers can easily fetch it
> 458: 
> 459:     /*non-public*/

Remove `/*non-public*/`

src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1769:

> 1767:      */
> 1768:     /*non-public*/
> 1769:     void updateForm(Function<LambdaForm,LambdaForm> updater) {

`Function<LambdaForm, LambdaForm>`

src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 1754:

> 1752:         updateForm(new Function<>() {
> 1753:                 public LambdaForm apply(LambdaForm oldForm) {
> 1754:                     return oldForm.customize(mh);

I think you can drop line 1751 and write this as `return oldForm.customize(MethodHandle.this);`. Simpler and might avoid an additional, implicit capture.

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1472

From redestad at openjdk.java.net  Fri Nov 27 14:52:53 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 27 Nov 2020 14:52:53 GMT
Subject: RFR: 8257164: Share LambdaForms for VH linkers/invokers.
In-Reply-To: <ZTi7JmIqKWVIB5qAHg21Hgu5JuWzJ-nIxYE4JgXMaII=.12f143de-3bad-48fd-badc-878813817518@github.com>
References: <ZTi7JmIqKWVIB5qAHg21Hgu5JuWzJ-nIxYE4JgXMaII=.12f143de-3bad-48fd-badc-878813817518@github.com>
Message-ID: <lecfL49IRwKzVaT-pKPk8NH-tR8NapX9M5N-6ySPYzo=.0f76e72c-f1eb-45bf-983f-6857e1606883@github.com>

On Thu, 26 Nov 2020 13:13:43 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Introduce sharing of `LambdaForms` for `VarHandle` linkers and invokers.
> It reduces the number of LambdaForms needed at runtime.
> 
> Testing: tier1-4

LGTM!

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1455

From jlaskey at openjdk.java.net  Fri Nov 27 15:03:04 2020
From: jlaskey at openjdk.java.net (Jim Laskey)
Date: Fri, 27 Nov 2020 15:03:04 GMT
Subject: RFR: 8248862: Implement Enhanced Pseudo-Random Number Generators
 [v8]
In-Reply-To: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
References: <nrd79Kjy67yZSHtEl7gJQaGIlbcS35xW94IiS_DEQjM=.2dded5ae-2b6d-4337-a0a8-414fd2a90c03@github.com>
Message-ID: <nscLYQupENsvUTPAYPV88elInif59cOV4xpeBMG9DNk=.3af24a19-9b61-4809-9b76-3e8b5379b9d8@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:

  8248862: Implement Enhanced Pseudo-Random Number Generators
  
  Added coverage testing

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1292/files
  - new: https://git.openjdk.java.net/jdk/pull/1292/files/a8cc0795..f7b697ec

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1292&range=06-07

  Stats: 168 lines in 3 files changed: 166 ins; 2 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 jlahoda at openjdk.java.net  Fri Nov 27 15:45:12 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 27 Nov 2020 15:45:12 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol generator
 CreateSymbols
Message-ID: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>

Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
-updating and moving tests into test/langtools, so that it is easier to run them.
-fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
-fixing the -Xprint annotation processor to print record component annotations.

Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

-------------

Commit messages:
 - Update CreateSymbolsTest.java
 - Cleaning TODO.
 - Cleaning TODO.
 - Adding test verifying javac can read Record attribute properly.
 - Cleanup.
 - JDK-8256950: Add record attribute support to symbol generator CreateSymbols

Changes: https://git.openjdk.java.net/jdk/pull/1480/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8256950
  Stats: 1910 lines in 12 files changed: 1147 ins; 745 del; 18 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1480.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480

PR: https://git.openjdk.java.net/jdk/pull/1480

From clanger at openjdk.java.net  Fri Nov 27 15:48:54 2020
From: clanger at openjdk.java.net (Christoph Langer)
Date: Fri, 27 Nov 2020 15:48:54 GMT
Subject: RFR: 8256818: SSLSocket that is never bound or connected leaks
 socket resources
In-Reply-To: <SbLXcfqiOkPX6uhR_UkhC3v1RgK2hPVJ8Yb72J4T6KM=.e2557d56-1588-4e78-9fd4-3a5ec62a0744@github.com>
References: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>
 <SbLXcfqiOkPX6uhR_UkhC3v1RgK2hPVJ8Yb72J4T6KM=.e2557d56-1588-4e78-9fd4-3a5ec62a0744@github.com>
Message-ID: <awrboe7gcFWDdBA9trNuIA_sqM8_6KIa-a_mJv6S6hU=.08f41194-1e72-4c63-9020-e253fb55098a@github.com>

On Sat, 21 Nov 2020 23:21:15 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> There is a flaw in sun.security.ssl.SSLSocketImpl::close() which leads to leaking socket resources after JDK-8224829.
>> 
>> The close method calls duplexCloseOutput() and duplexCloseInput(). In case of an exception in any of these methods, the call to closeSocket() is bypassed, and the underlying Socket may not be closed.
>> 
>> This manifests in a real life leak after JDK-8224829 has introduced a call to getSoLinger() on the path of duplexCloseOutput -> closeNotify. If socket impl / OS socket hadn't been created yet it is done at that place. But then after duplexCloseOutput eventually fails with a SocketException since the socket wasn't connected, closing fails to call Socket::close().
>> 
>> This problem can be reproduced by this code:
>> 		        SSLSocket sslSocket = (SSLSocket)SSLSocketFactory.getDefault().createSocket();
>> 		        sslSocket.getSSLParameters();
>> 		        sslSocket.close();
>> 
>> This is what happens when SSLContext.getDefault().getDefaultSSLParameters() is called, with close() being eventually called by the finalizer.
>> 
>> I'll open this PR as draft for now to start discussion. I'll create a testcase to reproduce the issue and add it soon.
>> 
>> I propose to modify the close method such that duplexClose is only done on a connected/bound socket. Maybe it even suffices to only do it when connected.
>> 
>> Secondly, I'm proposing to improve exception handling a bit. So in case there's an IOException on the path of duplexClose, it is caught and logged. But the real close moves to the finally block since it should be done unconditionally.
>
> I changed the check for when to do duplexClose to only do it when socket isConnected().
> 
> I also added a testcase which should work on all platforms. For windows I borrowed some functionality introduced lately with test java/lang/ProcessBuilder/checkHandles/CheckHandles.java which I moved to the test library for that reason.
> 
> Now it's ready to review.

Ping... Any takers? comments? reviews?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1363

From xuelei at openjdk.java.net  Fri Nov 27 16:17:55 2020
From: xuelei at openjdk.java.net (Xue-Lei Andrew Fan)
Date: Fri, 27 Nov 2020 16:17:55 GMT
Subject: RFR: 8256818: SSLSocket that is never bound or connected leaks
 socket resources
In-Reply-To: <awrboe7gcFWDdBA9trNuIA_sqM8_6KIa-a_mJv6S6hU=.08f41194-1e72-4c63-9020-e253fb55098a@github.com>
References: <f6uwC_y0UJk-5WGWhyWjSrtiNsoiyGH2HNn4naVVVis=.ef030385-09c6-4639-8dfc-23cff63b57f7@github.com>
 <SbLXcfqiOkPX6uhR_UkhC3v1RgK2hPVJ8Yb72J4T6KM=.e2557d56-1588-4e78-9fd4-3a5ec62a0744@github.com>
 <awrboe7gcFWDdBA9trNuIA_sqM8_6KIa-a_mJv6S6hU=.08f41194-1e72-4c63-9020-e253fb55098a@github.com>
Message-ID: <tijIgeqA5XnIf4E5txdayt5iZJjoGB-V6A4E_StHO0s=.a65c999c-94be-4a99-a3ce-a212a42c6e04@github.com>

On Fri, 27 Nov 2020 15:46:08 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> I changed the check for when to do duplexClose to only do it when socket isConnected().
>> 
>> I also added a testcase which should work on all platforms. For windows I borrowed some functionality introduced lately with test java/lang/ProcessBuilder/checkHandles/CheckHandles.java which I moved to the test library for that reason.
>> 
>> Now it's ready to review.
>
> Ping... Any takers? comments? reviews?

I will have a look at this update.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1363

From rriggs at openjdk.java.net  Fri Nov 27 16:54:11 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 27 Nov 2020 16:54:11 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <Tb-ywtW1oSQgE5j2Oj6OAl8Qaq_l-JX2uW8Twjp_fxo=.b252bd5f-60db-4b19-8b0e-321c9007f0db@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
 <Tb-ywtW1oSQgE5j2Oj6OAl8Qaq_l-JX2uW8Twjp_fxo=.b252bd5f-60db-4b19-8b0e-321c9007f0db@github.com>
Message-ID: <vlH-u1Yz4QEKKGMLz4FqWp7lLON1YJZnxEQNDHLsfvM=.cf162798-dbde-46de-aada-6f3275792aae@github.com>

On Fri, 27 Nov 2020 09:33:26 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
>> 
>>  - Clarified that suffix() and prefix() methods do not return null, instead the empty string is returned.
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - The HexFormat API indexing model for array and string ranges is changed
>>    to describe the range using 'fromIndex (inclusive)' and 'toIndex (exclusive)'.
>>    
>>    Initially, it was specified as 'index' and 'length'. However, both byte arrays
>>    and strings used in the HexFormat API typically use fromIndex and toIndex
>>    to describe ranges.  Using the same indexing model can prevent mistakes.
>>    
>>    The change affects the methods and corresponding tests:
>>    
>>        formatHex(byte[] bytes, int fromIndex, int toIndex)
>>        formatHex(A out, byte[] bytes, int fromIndex, int toIndex)
>>        parseHex(char[] chars, int fromIndex, int toIndex)
>>        parseHex(CharSequence string, int fromIndex, int toIndex)
>>        fromHexDigits(CharSequence string, int fromIndex, int toIndex)
>>        fromHexDigitsToLong(CharSequence string, int fromIndex, int toIndex)
>>  - - Added @see and @link references to Integer.toHexString and Long.toHexString
>>    - Clarified parsing is case insensistive in various parse and fromXXX methods
>>    - Source level cleanup based on review comments
>>    - Expanded some javadoc tag text to make it more descriptive
>>    - Consistent use of 'hexadecimal' vs 'hex'
>>  - Review comment updates to class javadoc
>>  - Review comment updates, in the example code, and to describe the characters used to convert to hexadecimal
>>  - Correct length of StringBuilder in formatHex;
>>    Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/3650d38b...b19d2827
>
> src/java.base/share/classes/java/util/HexFormat.java line 255:
> 
>> 253: 
>> 254:     /**
>> 255:      * Returns the delimiter between hexadecimal values in a formatted byte array.
> 
> "... in a formatted byte array", I find this wording a little hard to follow. The delimiter, prefix, suffix apply to *formatted hexadecimal strings*.

It is the byte array that is formatted, the result is a hexadecimal string.
It helps make a stronger distinction between the byte array functions and the primitive functions.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From chegar at openjdk.java.net  Fri Nov 27 17:04:01 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Fri, 27 Nov 2020 17:04:01 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <vlH-u1Yz4QEKKGMLz4FqWp7lLON1YJZnxEQNDHLsfvM=.cf162798-dbde-46de-aada-6f3275792aae@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
 <Tb-ywtW1oSQgE5j2Oj6OAl8Qaq_l-JX2uW8Twjp_fxo=.b252bd5f-60db-4b19-8b0e-321c9007f0db@github.com>
 <vlH-u1Yz4QEKKGMLz4FqWp7lLON1YJZnxEQNDHLsfvM=.cf162798-dbde-46de-aada-6f3275792aae@github.com>
Message-ID: <gkoOxMeupYf0bSuIIPHSpxDSfehq1iRms7hEc0-liIs=.24fd1465-e336-48b5-8a17-854e956f4aa2@github.com>

On Fri, 27 Nov 2020 16:51:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> It is the byte array that is formatted, the result is a hexadecimal string.

I don't understand. How is the byte array formatter?   Do we have "formatted byte arrays" and "unformatted byte arrays"?  Are they formatted somehow with prefix, delimiter, suffix ?

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Fri Nov 27 17:04:12 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 27 Nov 2020 17:04:12 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <2nUVJ9EKuqnoGTq1ZPCazHnmbIFAmLAJXjiCTY2dGeU=.130cb5a7-a189-4483-8832-74c67cdd39e1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
 <2nUVJ9EKuqnoGTq1ZPCazHnmbIFAmLAJXjiCTY2dGeU=.130cb5a7-a189-4483-8832-74c67cdd39e1@github.com>
Message-ID: <lqjOSgRCHdfPvSscZjNkzrj-vNdZkAWiiynksfBhQUs=.418f185a-9cf3-4a12-9506-5de6a152e6f5@github.com>

On Thu, 26 Nov 2020 00:08:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
>> 
>>  - Clarified that suffix() and prefix() methods do not return null, instead the empty string is returned.
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - The HexFormat API indexing model for array and string ranges is changed
>>    to describe the range using 'fromIndex (inclusive)' and 'toIndex (exclusive)'.
>>    
>>    Initially, it was specified as 'index' and 'length'. However, both byte arrays
>>    and strings used in the HexFormat API typically use fromIndex and toIndex
>>    to describe ranges.  Using the same indexing model can prevent mistakes.
>>    
>>    The change affects the methods and corresponding tests:
>>    
>>        formatHex(byte[] bytes, int fromIndex, int toIndex)
>>        formatHex(A out, byte[] bytes, int fromIndex, int toIndex)
>>        parseHex(char[] chars, int fromIndex, int toIndex)
>>        parseHex(CharSequence string, int fromIndex, int toIndex)
>>        fromHexDigits(CharSequence string, int fromIndex, int toIndex)
>>        fromHexDigitsToLong(CharSequence string, int fromIndex, int toIndex)
>>  - - Added @see and @link references to Integer.toHexString and Long.toHexString
>>    - Clarified parsing is case insensistive in various parse and fromXXX methods
>>    - Source level cleanup based on review comments
>>    - Expanded some javadoc tag text to make it more descriptive
>>    - Consistent use of 'hexadecimal' vs 'hex'
>>  - Review comment updates to class javadoc
>>  - Review comment updates, in the example code, and to describe the characters used to convert to hexadecimal
>>  - Correct length of StringBuilder in formatHex;
>>    Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/4d7a7098...b19d2827
>
> src/java.base/share/classes/java/util/HexFormat.java line 853:
> 
>> 851:      */
>> 852:     public int fromHexDigit(int ch) {
>> 853:         int value = Character.digit(ch, 16);
> 
> Do we need to limit parsing the hex digit for only [0-9a-fA-F]? This would return `0` for other digits, say `fullwidth digit zero` (U+FF10)

The normal and conventional characters for hex encoding are limited to the ASCII/Latin1 range.
I don't know of any use case that would take advantage of non-ASCII characters.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Fri Nov 27 17:04:21 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 27 Nov 2020 17:04:21 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <syZl_FvX-peawrEAraEjVOWcgZPbLT3cvepCqQdf480=.b0dc1357-bf83-43fe-b0de-b3356d45994c@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
 <syZl_FvX-peawrEAraEjVOWcgZPbLT3cvepCqQdf480=.b0dc1357-bf83-43fe-b0de-b3356d45994c@github.com>
Message-ID: <df5d4LLwmIr8RMi4MME9EvmNThsJEYWYRUcDBr19sgU=.878f23f1-6566-4eca-acff-c13aaed49ca9@github.com>

On Fri, 27 Nov 2020 09:40:10 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
>> 
>>  - Clarified that suffix() and prefix() methods do not return null, instead the empty string is returned.
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - The HexFormat API indexing model for array and string ranges is changed
>>    to describe the range using 'fromIndex (inclusive)' and 'toIndex (exclusive)'.
>>    
>>    Initially, it was specified as 'index' and 'length'. However, both byte arrays
>>    and strings used in the HexFormat API typically use fromIndex and toIndex
>>    to describe ranges.  Using the same indexing model can prevent mistakes.
>>    
>>    The change affects the methods and corresponding tests:
>>    
>>        formatHex(byte[] bytes, int fromIndex, int toIndex)
>>        formatHex(A out, byte[] bytes, int fromIndex, int toIndex)
>>        parseHex(char[] chars, int fromIndex, int toIndex)
>>        parseHex(CharSequence string, int fromIndex, int toIndex)
>>        fromHexDigits(CharSequence string, int fromIndex, int toIndex)
>>        fromHexDigitsToLong(CharSequence string, int fromIndex, int toIndex)
>>  - - Added @see and @link references to Integer.toHexString and Long.toHexString
>>    - Clarified parsing is case insensistive in various parse and fromXXX methods
>>    - Source level cleanup based on review comments
>>    - Expanded some javadoc tag text to make it more descriptive
>>    - Consistent use of 'hexadecimal' vs 'hex'
>>  - Review comment updates to class javadoc
>>  - Review comment updates, in the example code, and to describe the characters used to convert to hexadecimal
>>  - Correct length of StringBuilder in formatHex;
>>    Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/9f01b66b...b19d2827
>
> src/java.base/share/classes/java/util/HexFormat.java line 71:
> 
>> 69:  * <p>
>> 70:  * For formatted hexadecimal string to byte array conversions the
>> 71:  * {@code parseHex} methods include {@link #parseHex(CharSequence) parseHex(string)} and
> 
> parseHex(string) -> parseHex(CharSequence)

The use of 'string' was intentional to make it easier to read and easier to understand the applicability.
In almost all cases the arguments will be String. The method signatures use CharSequence to enable other cases without needing to convert.

> src/java.base/share/classes/java/util/HexFormat.java line 528:
> 
>> 526:      * a range of the character array.
>> 527:      *
>> 528:      * Each byte value is parsed as the prefix, two case insensitive hexadecimal characters,
> 
> Each *char* value ...

The value being parsed is a byte, constructed from the input consisting of prefix, two hex characters, and the suffix.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From jlahoda at openjdk.java.net  Fri Nov 27 17:06:03 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Fri, 27 Nov 2020 17:06:03 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
Message-ID: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>

This pull request replaces https://github.com/openjdk/jdk/pull/1227.

>From the original PR:

> Please review the code for the second iteration of sealed classes. In this iteration we are:
> 
>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
> 
>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
> 
>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
> 
>     * adding code to make sure that annotations can't be sealed
> 
>     * improving some tests
> 
> 
> TIA
> 
> Related specs:
> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)

This PR strives to reflect the review comments from 1227:
 * adjustments to javadoc of j.l.Class methods
 * package access checks in Class.getPermittedSubclasses()
 * fixed to the narrowing conversion/castability as pointed out by Maurizio

-------------

Commit messages:
 - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
 - Improving getPermittedSubclasses() javadoc.
 - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
 - Removing unnecessary file.
 - Tweaking javadoc.
 - Reflecting review comments w.r.t. narrowing conversion.
 - Improving checks in getPermittedSubclasses()
 - Merging master into JDK-8246778
 - Adding checkPackageAccess to Class.getPermittedSubclasses().
 - 8246778: Compiler implementation for Sealed Classes (Second Preview)

Changes: https://git.openjdk.java.net/jdk/pull/1483/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8246778
  Stats: 915 lines in 12 files changed: 834 ins; 9 del; 72 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1483.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1483/head:pull/1483

PR: https://git.openjdk.java.net/jdk/pull/1483

From rriggs at openjdk.java.net  Fri Nov 27 17:12:10 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 27 Nov 2020 17:12:10 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <syZl_FvX-peawrEAraEjVOWcgZPbLT3cvepCqQdf480=.b0dc1357-bf83-43fe-b0de-b3356d45994c@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
 <syZl_FvX-peawrEAraEjVOWcgZPbLT3cvepCqQdf480=.b0dc1357-bf83-43fe-b0de-b3356d45994c@github.com>
Message-ID: <jEI3e6RLs0wh1EU2n2X9O0y0TKi6x0HRoa7dDcXEUqY=.08b20f3b-9ab6-4db0-966f-d8e9fc942d7a@github.com>

On Fri, 27 Nov 2020 09:54:07 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
>> 
>>  - Clarified that suffix() and prefix() methods do not return null, instead the empty string is returned.
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - The HexFormat API indexing model for array and string ranges is changed
>>    to describe the range using 'fromIndex (inclusive)' and 'toIndex (exclusive)'.
>>    
>>    Initially, it was specified as 'index' and 'length'. However, both byte arrays
>>    and strings used in the HexFormat API typically use fromIndex and toIndex
>>    to describe ranges.  Using the same indexing model can prevent mistakes.
>>    
>>    The change affects the methods and corresponding tests:
>>    
>>        formatHex(byte[] bytes, int fromIndex, int toIndex)
>>        formatHex(A out, byte[] bytes, int fromIndex, int toIndex)
>>        parseHex(char[] chars, int fromIndex, int toIndex)
>>        parseHex(CharSequence string, int fromIndex, int toIndex)
>>        fromHexDigits(CharSequence string, int fromIndex, int toIndex)
>>        fromHexDigitsToLong(CharSequence string, int fromIndex, int toIndex)
>>  - - Added @see and @link references to Integer.toHexString and Long.toHexString
>>    - Clarified parsing is case insensistive in various parse and fromXXX methods
>>    - Source level cleanup based on review comments
>>    - Expanded some javadoc tag text to make it more descriptive
>>    - Consistent use of 'hexadecimal' vs 'hex'
>>  - Review comment updates to class javadoc
>>  - Review comment updates, in the example code, and to describe the characters used to convert to hexadecimal
>>  - Correct length of StringBuilder in formatHex;
>>    Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/706644aa...b19d2827
>
> src/java.base/share/classes/java/util/HexFormat.java line 617:
> 
>> 615:      * Returns the two hexadecimal characters for the {@code byte} value.
>> 616:      * Each nibble (4 bits) from most significant to least significant of the value
>> 617:      * is formatted as if by {@link #toLowHexDigit(int) toLowHexDigit(nibble)}.
> 
> It might be more straightforward to frame this in terms of toLowHexDigit and toHighHexDigit (rather than only toLowHexDigit).  `nibble`- should the param name for to(Low|High)HexDigit be named `nibble` ?

The description as `from most to least significant` is used to be consistent across all of the `toHexDigits` methods regardless of whether the argument is a `byte`, `short`, `int`, or `long`.  

The `toLowDigit` and `toHighDigit` methods extract a nibble from the corresponding bits of the parameter value.  
The type of the argument is 'int' to make it easier to pass without needing to cast it to a byte.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Fri Nov 27 17:29:09 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 27 Nov 2020 17:29:09 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <syZl_FvX-peawrEAraEjVOWcgZPbLT3cvepCqQdf480=.b0dc1357-bf83-43fe-b0de-b3356d45994c@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
 <syZl_FvX-peawrEAraEjVOWcgZPbLT3cvepCqQdf480=.b0dc1357-bf83-43fe-b0de-b3356d45994c@github.com>
Message-ID: <1CkFXw1RRxr0h8J43IuA3RUIbN-E-5mgcZKSKnTJMSA=.55a97177-e8ff-4af8-a76d-60f176335ca9@github.com>

On Fri, 27 Nov 2020 10:46:09 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
>> 
>>  - Clarified that suffix() and prefix() methods do not return null, instead the empty string is returned.
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - The HexFormat API indexing model for array and string ranges is changed
>>    to describe the range using 'fromIndex (inclusive)' and 'toIndex (exclusive)'.
>>    
>>    Initially, it was specified as 'index' and 'length'. However, both byte arrays
>>    and strings used in the HexFormat API typically use fromIndex and toIndex
>>    to describe ranges.  Using the same indexing model can prevent mistakes.
>>    
>>    The change affects the methods and corresponding tests:
>>    
>>        formatHex(byte[] bytes, int fromIndex, int toIndex)
>>        formatHex(A out, byte[] bytes, int fromIndex, int toIndex)
>>        parseHex(char[] chars, int fromIndex, int toIndex)
>>        parseHex(CharSequence string, int fromIndex, int toIndex)
>>        fromHexDigits(CharSequence string, int fromIndex, int toIndex)
>>        fromHexDigitsToLong(CharSequence string, int fromIndex, int toIndex)
>>  - - Added @see and @link references to Integer.toHexString and Long.toHexString
>>    - Clarified parsing is case insensistive in various parse and fromXXX methods
>>    - Source level cleanup based on review comments
>>    - Expanded some javadoc tag text to make it more descriptive
>>    - Consistent use of 'hexadecimal' vs 'hex'
>>  - Review comment updates to class javadoc
>>  - Review comment updates, in the example code, and to describe the characters used to convert to hexadecimal
>>  - Correct length of StringBuilder in formatHex;
>>    Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/dcf4db97...b19d2827
>
> src/java.base/share/classes/java/util/HexFormat.java line 47:
> 
>> 45:  * or choice of {@link #withUpperCase()} or {@link #withLowerCase()} parameters.
>> 46:  * <p>
>> 47:  * For primitive to hexadecimal string conversions the {@code toHexDigits}
> 
> It took me a little while to grok the naming convention being used here. It might be helpful to ensure that all the terms are clearly defined and used consistently throughout. 
> 
> "hexadecimal string"  - consists of just 0-9, a-f, A-F  (i.e. no delimiter, prefix, suffix)
> "formatted hexadecimal string" - consists of hexadecimal string, and prefix, delimiter, suffix.
> 
> The `parseXXX` and `formatXXX` are logically related - and operate on "formatted hexadecimal strings"
> 
> The `toXXX` and `fromXXX` are logically related - one is kind of the inverse of the other. And these operate (even when accepting/producing chars) on "hexadecimal strings" - ignoring almost all properties of the HexFormat, except the toXXX cares about upper/lower case. Does `fromXXX` care about upper/lower ?

Yes, naming is important and there are two dimensions in the api that are significant.  
Primitives vs byte arrays, and decoding and encoding.
         Primitives   ByteArrays
encode:   toXXX         format 
decode:   fromXXX       parse
Both fromXXX or parseXXX accept either upper or lower case.

The class javadoc and each method specifies whether it uses the prefix, suffix, delimiter, and upper/lower case choice.

The choice of 'formatted byte array' was used to make a strong distinction between formatting of byte arrays vs converting primitives with limited/no formatting.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Fri Nov 27 17:33:12 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 27 Nov 2020 17:33:12 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <2nUVJ9EKuqnoGTq1ZPCazHnmbIFAmLAJXjiCTY2dGeU=.130cb5a7-a189-4483-8832-74c67cdd39e1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
 <2nUVJ9EKuqnoGTq1ZPCazHnmbIFAmLAJXjiCTY2dGeU=.130cb5a7-a189-4483-8832-74c67cdd39e1@github.com>
Message-ID: <9_c7OjnPXqEaHKdocKBHnOI517YjN_N7VIcUOnttXxs=.019cf408-1ea9-4b96-89b6-1e8f499e47e8@github.com>

On Wed, 25 Nov 2020 23:36:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 19 additional commits since the last revision:
>> 
>>  - Clarified that suffix() and prefix() methods do not return null, instead the empty string is returned.
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - The HexFormat API indexing model for array and string ranges is changed
>>    to describe the range using 'fromIndex (inclusive)' and 'toIndex (exclusive)'.
>>    
>>    Initially, it was specified as 'index' and 'length'. However, both byte arrays
>>    and strings used in the HexFormat API typically use fromIndex and toIndex
>>    to describe ranges.  Using the same indexing model can prevent mistakes.
>>    
>>    The change affects the methods and corresponding tests:
>>    
>>        formatHex(byte[] bytes, int fromIndex, int toIndex)
>>        formatHex(A out, byte[] bytes, int fromIndex, int toIndex)
>>        parseHex(char[] chars, int fromIndex, int toIndex)
>>        parseHex(CharSequence string, int fromIndex, int toIndex)
>>        fromHexDigits(CharSequence string, int fromIndex, int toIndex)
>>        fromHexDigitsToLong(CharSequence string, int fromIndex, int toIndex)
>>  - - Added @see and @link references to Integer.toHexString and Long.toHexString
>>    - Clarified parsing is case insensistive in various parse and fromXXX methods
>>    - Source level cleanup based on review comments
>>    - Expanded some javadoc tag text to make it more descriptive
>>    - Consistent use of 'hexadecimal' vs 'hex'
>>  - Review comment updates to class javadoc
>>  - Review comment updates, in the example code, and to describe the characters used to convert to hexadecimal
>>  - Correct length of StringBuilder in formatHex;
>>    Correct bug in formatHex(char[], 2, 3) and add test for subranges of char[]
>>  - Merge branch 'master' into 8251989-hex-formatter
>>  - ... and 9 more: https://git.openjdk.java.net/jdk/compare/feacc538...b19d2827
>
> src/java.base/share/classes/java/util/HexFormat.java line 408:
> 
>> 406:      * @param fromIndex the initial index of the range, inclusive
>> 407:      * @param toIndex the final index of the range, exclusive.
>> 408:      * @return a String formatting or null for non-single byte formatting
> 
> `non-single byte delimiter`?

yes

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Fri Nov 27 17:48:01 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 27 Nov 2020 17:48:01 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <gkoOxMeupYf0bSuIIPHSpxDSfehq1iRms7hEc0-liIs=.24fd1465-e336-48b5-8a17-854e956f4aa2@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
 <Tb-ywtW1oSQgE5j2Oj6OAl8Qaq_l-JX2uW8Twjp_fxo=.b252bd5f-60db-4b19-8b0e-321c9007f0db@github.com>
 <vlH-u1Yz4QEKKGMLz4FqWp7lLON1YJZnxEQNDHLsfvM=.cf162798-dbde-46de-aada-6f3275792aae@github.com>
 <gkoOxMeupYf0bSuIIPHSpxDSfehq1iRms7hEc0-liIs=.24fd1465-e336-48b5-8a17-854e956f4aa2@github.com>
Message-ID: <IOF26b1cqwzcqPCJ60dGb6SJ2BPtyWQ5JCUqG5Ax89E=.ad6edf26-2713-4dbd-ad8f-7d414b1912e4@github.com>

On Fri, 27 Nov 2020 16:56:37 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> It is the byte array that is formatted, the result is a hexadecimal string.
>> It helps make a stronger distinction between the byte array functions and the primitive functions.
>
>> It is the byte array that is formatted, the result is a hexadecimal string.
> 
> I don't understand. How is the byte array formatter?   Do we have "formatted byte arrays" and "unformatted byte arrays"?  Are they formatted somehow with prefix, delimiter, suffix ?

The question is how to describe the resulting string. 
You are correct that the class javadoc starts off using the terms "hexadecimal string" and "formatted hexadecimal string" but does not follow through.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From rriggs at openjdk.java.net  Fri Nov 27 17:57:54 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 27 Nov 2020 17:57:54 GMT
Subject: RFR: 8207329: Add NIL Constant to UUID
In-Reply-To: <20Yg2C96fn72CooUiXZmbU6bQXRqLG6ghaTJtCglbPw=.ee410df0-40c7-43f9-9fa6-f6babbf00300@github.com>
References: <20Yg2C96fn72CooUiXZmbU6bQXRqLG6ghaTJtCglbPw=.ee410df0-40c7-43f9-9fa6-f6babbf00300@github.com>
Message-ID: <o-85INaomOnVG0LdDGFYIFB3xpAnNkMWDDh2_wY89X0=.d2b84f50-0b96-4fea-bcac-20ef7b0a5af0@github.com>

On Thu, 26 Nov 2020 15:54:46 GMT, Richard Fussenegger <github.com+1059453+Fleshgrinder at openjdk.org> wrote:

> Adds a constant for the special NIL UUID where all bits are zero to `java.util.UUID`. The [8207329](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8207329) mentions the usage of it to avoid `null`, it for sure is also very handy in testing where a UUID is required and we do not care about its actual value. Using a random UUID stresses the PRNG for no good reason.

The bug report does not make a strong case for adding a NIL constant to the UUID API.
It would add (a small amount) to both footprint and startup time with very limited benefit.
Any application needing a placeholder can do so itself and all existing applications take care of their own needs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1460

From mcimadamore at openjdk.java.net  Fri Nov 27 17:57:57 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 27 Nov 2020 17:57:57 GMT
Subject: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout
 which returns a offset-computing method handle [v2]
In-Reply-To: <nvNa1xOAPUg1NqUdKF1tHdW4SPyjdAukEodQuwTKsbE=.b9200f23-225a-4f87-b3b7-4298bac74283@github.com>
References: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>
 <nvNa1xOAPUg1NqUdKF1tHdW4SPyjdAukEodQuwTKsbE=.b9200f23-225a-4f87-b3b7-4298bac74283@github.com>
Message-ID: <HTf5t-9dRHPeK7Yrt7QGMkvyxt1DFlOQRt8VG5_AMrA=.906920a3-a258-404c-acd1-f5201b1d4af7@github.com>

On Fri, 27 Nov 2020 12:31:12 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> This upstreams the patch from: https://github.com/openjdk/panama-foreign/pull/396
>> 
>> There were only some minor merge conflicts due to imports and some tests being replaced by java/foreign/TestNulls. All tests still pass, no other changes were needed.
>> 
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8257187
>
> Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments:
>   - remove explicit @throws NPE tags
>   - add example to class doc

Very nice

src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java line 177:

> 175:  * access coordinate.
> 176:  *
> 177:  * <p>A layout path with free dimensions can also be used to create an offset computing method handle, using the

Suggestion:

 * <p>A layout path with free dimensions can also be used to create an offset-computing method handle, using the

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1468

From mcimadamore at openjdk.java.net  Fri Nov 27 18:04:00 2020
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 27 Nov 2020 18:04:00 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v3]
In-Reply-To: <qJp0PaBhsqQX4uAVW4qo6FSrCE7GVr1HJgpM-KSvrIo=.952cb0c1-521e-4886-8e55-2d94a194379c@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
 <qJp0PaBhsqQX4uAVW4qo6FSrCE7GVr1HJgpM-KSvrIo=.952cb0c1-521e-4886-8e55-2d94a194379c@github.com>
Message-ID: <3-P6Lc_CwEXGZIbLdnywWBTqtVbWxq08nA4HsdLp5jk=.b91cac90-ef2f-49bc-93c3-666fc8af192a@github.com>

On Thu, 26 Nov 2020 14:38:17 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> The ByteBuffers micro benchmark seems to be a little dated. 
>> 
>> It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 
>> 
>> This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 
>> 
>> 1. Remove allocation from the individual benchmarks - it just creates noise. 
>> 2. Consolidate per-thread shared heap and direct buffers. 
>> 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
>> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
>> 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.
>
> Chris Hegarty has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace

Looks a great improvements. Two comments:

* the names always mention the "Single" word, when in fact all benchmark involve some kind of a loop. I'd suggest making that more  explicit, both in the benchmark method and in the helpers.

* I see that you added  support for views - but note that, for heap buffers there are two different kind of views (!!). E.g. I believe that:

ByteBuffer.allocate(size * 4).asFloatBuffer()
returns a buffer of a different class than:

FloatBuffer.allocate(size);
I think you are only testing the former?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1430

From github.com+1059453+fleshgrinder at openjdk.java.net  Fri Nov 27 18:45:58 2020
From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger)
Date: Fri, 27 Nov 2020 18:45:58 GMT
Subject: RFR: 8207329: Add NIL Constant to UUID
In-Reply-To: <o-85INaomOnVG0LdDGFYIFB3xpAnNkMWDDh2_wY89X0=.d2b84f50-0b96-4fea-bcac-20ef7b0a5af0@github.com>
References: <20Yg2C96fn72CooUiXZmbU6bQXRqLG6ghaTJtCglbPw=.ee410df0-40c7-43f9-9fa6-f6babbf00300@github.com>
 <o-85INaomOnVG0LdDGFYIFB3xpAnNkMWDDh2_wY89X0=.d2b84f50-0b96-4fea-bcac-20ef7b0a5af0@github.com>
Message-ID: <o9c80NkEIMVwxZXdZE0i4urujHV-wWqkvM9Fni1tfmk=.76b5a837-1641-4d76-b651-829d05c80c46@github.com>

On Fri, 27 Nov 2020 17:55:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Adds a constant for the special NIL UUID where all bits are zero to `java.util.UUID`. The [8207329](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8207329) mentions the usage of it to avoid `null`, it for sure is also very handy in testing where a UUID is required and we do not care about its actual value. Using a random UUID stresses the PRNG for no good reason.
>
> The bug report does not make a strong case for adding a NIL constant to the UUID API.
> It would add (a small amount) to both footprint and startup time with very limited benefit.
> Any application needing a placeholder can do so itself and all existing applications take care of their own needs.

For me it's mostly useful in tests but we cannot ship test only code. We could fix the issues you mention through lazy initialization, or we simply close the PR and ticket and state that the construction via `new UUID(0, 0)` is already simple enough.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1460

From jvernee at openjdk.java.net  Fri Nov 27 18:57:08 2020
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Fri, 27 Nov 2020 18:57:08 GMT
Subject: RFR: 8257184: Upstream 8252504: Add a method to MemoryLayout
 which returns a offset-computing method handle [v3]
In-Reply-To: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>
References: <_5bNeNy8yuc9m_RT5NdDFCJN5TrLLgNkhXqT9J4pD04=.16ecc40a-3ce8-4d19-8fc8-a541a934c667@github.com>
Message-ID: <T2Jl7YXg-gP2k0ZkrZcKEqequv83pWGeqG2QzQiE6yI=.bbed84dd-455f-41bf-b1ab-292a8e99abaf@github.com>

> This upstreams the patch from: https://github.com/openjdk/panama-foreign/pull/396
> 
> There were only some minor merge conflicts due to imports and some tests being replaced by java/foreign/TestNulls. All tests still pass, no other changes were needed.
> 
> CSR: https://bugs.openjdk.java.net/browse/JDK-8257187

Jorn Vernee has updated the pull request incrementally with one additional commit since the last revision:

  Update src/jdk.incubator.foreign/share/classes/jdk/incubator/foreign/MemoryLayout.java
  
  Co-authored-by: Maurizio Cimadamore <54672762+mcimadamore at users.noreply.github.com>

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1468/files
  - new: https://git.openjdk.java.net/jdk/pull/1468/files/4b632628..c597f900

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1468&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1468&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1468.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1468/head:pull/1468

PR: https://git.openjdk.java.net/jdk/pull/1468

From kvn at openjdk.java.net  Fri Nov 27 19:05:00 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Fri, 27 Nov 2020 19:05:00 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo [v2]
In-Reply-To: <pg7lETjxXQK3qQ8EoVvimXfB00tTIeHEqPsg0OLRK2c=.28d436a8-0911-4f82-9518-6d45075eb837@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <lRizv2JGrdsVw9AZ01ORWRlupCj4EkoGQ2phRMNUQEc=.9dd769f2-a3ae-4673-89cf-1959f984225c@github.com>
 <pg7lETjxXQK3qQ8EoVvimXfB00tTIeHEqPsg0OLRK2c=.28d436a8-0911-4f82-9518-6d45075eb837@github.com>
Message-ID: <SOohAnwuR42x60H8-f6ZAo_iNnZxbNCo2CdPQEiKrEU=.4b82aa52-80c9-4373-88bf-06bfcbb26c81@github.com>

On Thu, 26 Nov 2020 13:51:05 GMT, Roman Kennke <rkennke at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8256999
>>  - Added ZLoadBarrierElided = 0 definition.
>>    Removed is_exact argument in load_field_from_object().
>>    Added Shenandoah support for narrow phantom accesses.
>>  - 8256999: Add C2 intrinsic for Reference.refersTo and PhantomReference::refersTo
>
> Shenandoah parts look good to me! Thanks!

@fisk and @shipilev are you fine with updated version?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From chris.hegarty at oracle.com  Fri Nov 27 19:22:00 2020
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Fri, 27 Nov 2020 19:22:00 +0000
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v3]
In-Reply-To: <3-P6Lc_CwEXGZIbLdnywWBTqtVbWxq08nA4HsdLp5jk=.b91cac90-ef2f-49bc-93c3-666fc8af192a@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
 <qJp0PaBhsqQX4uAVW4qo6FSrCE7GVr1HJgpM-KSvrIo=.952cb0c1-521e-4886-8e55-2d94a194379c@github.com>
 <3-P6Lc_CwEXGZIbLdnywWBTqtVbWxq08nA4HsdLp5jk=.b91cac90-ef2f-49bc-93c3-666fc8af192a@github.com>
Message-ID: <E1987292-1108-4D85-89DE-6E8873153ABB@oracle.com>

Maurizio,

> On 27 Nov 2020, at 18:04, Maurizio Cimadamore <mcimadamore at openjdk.java.net> wrote:
> 
> ...
> Looks a great improvements. Two comments:
> 
> * the names always mention the "Single" word, when in fact all benchmark involve some kind of a loop. I'd suggest making that more  explicit, both in the benchmark method and in the helpers.

Yeah, I dislike (the preexisting) ?Single? too. How about ?Loop? - so we have [Bulk|Loop] ?

> * I see that you added  support for views - but note that, for heap buffers there are two different kind of views (!!). E.g. I believe that:
> 
> ByteBuffer.allocate(size * 4).asFloatBuffer()
> returns a buffer of a different class than:
> 
> FloatBuffer.allocate(size);
> I think you are only testing the former?

Correct.  I did consider the latter, but then thought that this micro had enough scenarios.  Let me take another look and see how much more scenarios it adds.

-Chris.



From lancea at openjdk.java.net  Fri Nov 27 19:32:59 2020
From: lancea at openjdk.java.net (Lance Andersen)
Date: Fri, 27 Nov 2020 19:32:59 GMT
Subject: RFR: 8170432: Class java.util.UUID & @Override
In-Reply-To: <4Snu6mJxW5hJjDupsOO0VvQHyKcVhXt2y7YAQHJ37YE=.535f2e20-3f3b-4cd3-a05e-3bd1293e5548@github.com>
References: <4Snu6mJxW5hJjDupsOO0VvQHyKcVhXt2y7YAQHJ37YE=.535f2e20-3f3b-4cd3-a05e-3bd1293e5548@github.com>
Message-ID: <XSmQ5hdkT5Irvj-AC1SmneMmDOAilcFWzcpGugVPI40=.c254710c-2984-488b-a798-f7d5c12663ec@github.com>

On Thu, 26 Nov 2020 17:01:59 GMT, Richard Fussenegger <github.com+1059453+Fleshgrinder at openjdk.org> wrote:

> Adds `@Override` annotation to all methods in `java.util.UUID` that implement methods from the implemented interfaces.

Looks fine.  It appears you need a sponsor so I can do that once you integrate

-------------

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1463

From isipka at openjdk.java.net  Fri Nov 27 19:33:19 2020
From: isipka at openjdk.java.net (Ivan =?UTF-8?B?xaBpcGth?=)
Date: Fri, 27 Nov 2020 19:33:19 GMT
Subject: RFR: 8166026: refactor shell tests to java
Message-ID: <H2UZy1486X04VxMmEPt1dG78BSsv6F-qqhUNWMcpW4g=.08c502e1-d13c-4fa2-8174-1227072f7d63@github.com>

@iignatev  could you please review? Thank you.

note to self:
jtreg test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java

-------------

Commit messages:
 - 8166026: removing tab character
 - 8166026: refactor shell tests to java

Changes: https://git.openjdk.java.net/jdk/pull/1484/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1484&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8166026
  Stats: 1002 lines in 12 files changed: 496 ins; 505 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1484.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1484/head:pull/1484

PR: https://git.openjdk.java.net/jdk/pull/1484

From github.com+1059453+fleshgrinder at openjdk.java.net  Fri Nov 27 19:32:59 2020
From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger)
Date: Fri, 27 Nov 2020 19:32:59 GMT
Subject: Integrated: 8170432: Class java.util.UUID & @Override
In-Reply-To: <4Snu6mJxW5hJjDupsOO0VvQHyKcVhXt2y7YAQHJ37YE=.535f2e20-3f3b-4cd3-a05e-3bd1293e5548@github.com>
References: <4Snu6mJxW5hJjDupsOO0VvQHyKcVhXt2y7YAQHJ37YE=.535f2e20-3f3b-4cd3-a05e-3bd1293e5548@github.com>
Message-ID: <bx2wAn6fF3tTz-LKXALAk9s51cj7r54B7UXX0csC1JY=.5f98d8ba-4b83-4e95-b492-2ea417f86007@github.com>

On Thu, 26 Nov 2020 17:01:59 GMT, Richard Fussenegger <github.com+1059453+Fleshgrinder at openjdk.org> wrote:

> Adds `@Override` annotation to all methods in `java.util.UUID` that implement methods from the implemented interfaces.

This pull request has now been integrated.

Changeset: b4cba15a
Author:    Fleshgrinder <fleshgrinder at users.noreply.github.com>
Committer: Lance Andersen <lancea at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/b4cba15a
Stats:     4 lines in 1 file changed: 4 ins; 0 del; 0 mod

8170432: Class java.util.UUID & @Override

Reviewed-by: dfuchs, lancea

-------------

PR: https://git.openjdk.java.net/jdk/pull/1463

From LANCE.ANDERSEN at ORACLE.COM  Fri Nov 27 19:37:41 2020
From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen)
Date: Fri, 27 Nov 2020 14:37:41 -0500
Subject: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data
 field of exactly 5 bytes)
In-Reply-To: <CAM21Rt9tHhGf7+eKfrrLbPwP8jShZytF6Qh_3OS4yxVg=02hWQ@mail.gmail.com>
References: <CAM21Rt8KeWyQvjE7-5pfyXYJXO3yGgGfKpBtueOV8qgNFMa+jQ@mail.gmail.com>
 <17F644E3-E5E0-403E-B568-FCB89C8BD9BB@ORACLE.COM>
 <CAM21Rt-ANpHbDO-kjSHguDzSTGS-WhGwHsbxcHav1wFVvDQ2EQ@mail.gmail.com>
 <CAM21Rt_8WWsTm-DrY=stscEuiWXF1-JJkv83wZoReJB7ZD-Kjw@mail.gmail.com>
 <CAM21Rt9tHhGf7+eKfrrLbPwP8jShZytF6Qh_3OS4yxVg=02hWQ@mail.gmail.com>
Message-ID: <DB63C62D-0D4C-42F4-8C7A-D732DFB8FB0C@ORACLE.COM>

Hi Dawid,

If you believe you have a a fix, please submit a patch along with a JTREG test case.  Ideally the test case would create zip file as part of the test.

Best
Lance

> On Nov 27, 2020, at 7:37 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
> 
> Just for the archives - I'm not sure if this ended up being filed to
> the bug system - the repro below demonstrates the bug on all JDKs up
> to the newest one.
> 
> # create a single random file of 250 megabytes
> head -c 250M < /dev/urandom > rnd.bin
> # create a bunch of hardlinks to the same file.
> for i in `seq -w 1 25`; do ln rnd.bin rnd-$i.bin; done
> # create a zip archive exceeding 4gb (in stored mode so that it's faster)
> zip -0 archive.zip rnd*.bin
> # show the content of the archive - for all entries beyond 4gb this should
> # show extra data blocks like below (note the order of extra data
> blocks - this is important).
> #
> #  The central-directory extra field contains:
> # - A subfield with ID 0x5455 (universal time) and 5 data bytes.
> #   The local extra field has UTC/GMT modification/access times.
> # - A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
> #   01 04 ea 03 00 00 04 ea 03 00 00.
> # - A subfield with ID 0x0001 (PKWARE 64-bit sizes) and 8 data bytes:
> #  a4 06 a0 86 01 00 00 00.
> #
> zipinfo -v archive.zip
> 
> # Bug repro code:
> cat > Test.java <<EOF
> import java.io.*;
> import java.nio.*;
> import java.nio.file.*;
> import java.nio.file.attribute.*;
> 
> public class Test {
>  public static void main(String[]args) throws IOException {
>    try (FileSystem fs = FileSystems.newFileSystem(Paths.get("archive.zip"))) {
>      for (Path root : fs.getRootDirectories()) {
>        Files.walkFileTree(root, new SimpleFileVisitor<>() {
>          public FileVisitResult visitFile(Path file,
> BasicFileAttributes attrs) throws IOException {
>            return FileVisitResult.CONTINUE;
>          }
>        });
>      }
>    }
>  }
> }
> EOF
> # and run it.
> java Test.java
> 
> The above ends with:
> 
> Exception in thread "main" java.util.zip.ZipException: loc: wrong sig ->841cd111
>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readExtra(ZipFileSystem.java:2899)
>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readCEN(ZipFileSystem.java:2600)
>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.<init>(ZipFileSystem.java:2536)
>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.getFileAttributes(ZipFileSystem.java:532)
>        at jdk.zipfs/jdk.nio.zipfs.ZipPath.readAttributes(ZipPath.java:767)
>        at jdk.zipfs/jdk.nio.zipfs.ZipPath.readAttributes(ZipPath.java:777)
>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.readAttributes(ZipFileSystemProvider.java:276)
>        at java.base/java.nio.file.Files.readAttributes(Files.java:1843)
>        at java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:219)
>        at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:276)
>        at java.base/java.nio.file.FileTreeWalker.next(FileTreeWalker.java:373)
>        at java.base/java.nio.file.Files.walkFileTree(Files.java:2840)
>        at java.base/java.nio.file.Files.walkFileTree(Files.java:2876)
>        at Test.main(Test.java:10)
> 
> The fix is relatively simple I think - the current code assumes entry
> offset is < 4GB when parsing extra data for
> ID 0x5455. This should be evaluated lazily after all extra data blocks
> are parsed to ensure the file offset is correctly
> updated based on block ID 0x0001, regardless of its ordering within
> other extra data blocks.
> 
> 
> 
> On Fri, Oct 23, 2020 at 9:12 AM Dawid Weiss <dawid.weiss at gmail.com> wrote:
>> 
>> 
>> This looks like a legitimate bug to me (the zip file system implementation is sensitive to the order of extra parameters and may throw an unexpected error
>> on zip64 archives exceeding 4 gigabytes). I can't file a Jira issue - no permissions - but I think it'd be worth adding one?
>> 
>> Dawid
>> 
>> On Wed, Oct 21, 2020 at 8:36 PM Dawid Weiss <dawid.weiss at gmail.com> wrote:
>>> 
>>> Hi Lance,
>>> 
>>> Yes, this is exactly the point where the problem is in JDK code. It's directly
>>> related to the zip entry beyond max int offset. The code tries to read data
>>> from a local zip entry header at locoff, here:
>>> 
>>> if (zipfs.readFullyAt(buf, 0, buf.length , locoff)
>>> 
>>> but the locoff is set to ~0 as per the spec for files exceeding
>>> 4 gigabytes, which says:
>>> 
>>>   4.4.16 relative offset of local header: (4 bytes)
>>> 
>>>       This is the offset from the start of the first disk on
>>>       which this file appears, to where the local header SHOULD
>>>       be found.  If an archive is in ZIP64 format and the value
>>>       in this field is 0xFFFFFFFF, the size will be in the
>>>       corresponding 8 byte zip64 extended information extra field.
>>> 
>>> A proper fix would be to read the local header from zip64 extra data
>>> first. I don't know how this interferes with the rest of the code though -
>>> didn't have enough time to look at it. As it stands, zip entries
>>> beyond 4GB cause
>>> an unchecked exception while attribute-scanning. This simple snippet
>>> is enough to demonstrate it, given a ZIP entry beyond 4GB range:
>>> 
>>> try (FileSystem fs =
>>> FileSystems.newFileSystem(Paths.get("zipWithEntryBeyond4Gb.zip"))) {
>>>  for (Path root : fs.getRootDirectories()) {
>>>    Files.walkFileTree(root, new SimpleFileVisitor<>() {
>>>      @Override
>>>      public FileVisitResult visitFile(Path file, BasicFileAttributes
>>> attrs) throws IOException {
>>>        return FileVisitResult.CONTINUE;
>>>      }
>>>    });
>>>  }
>>> }
>>> 
>>> The walkFileTree method is key here as it attempts to harvest
>>> attributes (why we use it is another story -- this saves a lot of time
>>> on large, network-mounted regular directories when you're collecting
>>> file metadata).
>>> 
>>> 
>>> Dawid
>>> 
>>> 
>>> On Wed, Oct 21, 2020 at 6:39 PM Lance Andersen
>>> <LANCE.ANDERSEN at oracle.com> wrote:
>>>> 
>>>> Hi David,
>>>> 
>>>> From  a quick look at ZipFileSystem this appears to be an optimization to avoid looking at the LOC extended Timestamp Extra field
>>>> 
>>>> If a Info-ZIP Extended Timestamp (0x5455)is found then:
>>>> 
>>>>  If the "zipinfo-time" entry was set  to ?false? in the Map specified when creating the Zip FileSystem,
>>>> 
>>>> FileSystems.newFileSystem(zipFile, Map.of("zipinfo-time", "false")
>>>> 
>>>> and the  data size of the CEN extended Timestamp is 5 (flag + mod time)
>>>> 
>>>> The modified time is used from the CEN Extended Timestamp extra field
>>>> 
>>>> Otherwise get the modified time, creation time, and access time from the LOC Extended Timestamp extra field.
>>>> 
>>>> 
>>>> ?????
>>>> 
>>>> Extended Timestamp Extra Field:
>>>> 
>>>>          ==============================
>>>> 
>>>>          The following is the layout of the extended-timestamp extra block.
>>>>          (Last Revision 19970118)
>>>> 
>>>>          Local-header version:
>>>> 
>>>>          Value         Size        Description
>>>>          -----         ----        -----------
>>>>  (time)  0x5455        Short       tag for this extra block type ("UT")
>>>>          TSize         Short       total data size for this block
>>>>          Flags         Byte        info bits
>>>>          (ModTime)     Long        time of last modification (UTC/GMT)
>>>>          (AcTime)      Long        time of last access (UTC/GMT)
>>>>          (CrTime)      Long        time of original creation (UTC/GMT)
>>>> 
>>>>          Central-header version:
>>>> 
>>>>          Value         Size        Description
>>>>          -----         ----        -----------
>>>>  (time)  0x5455        Short       tag for this extra block type ("UT")
>>>>          TSize         Short       total data size for this block
>>>>          Flags         Byte        info bits (refers to local header!)
>>>>          (ModTime)     Long        time of last modification (UTC/GMT)
>>>> 
>>>>          The central-header extra field contains the modification time only,
>>>>          or no timestamp at all.  TSize is used to flag its presence or
>>>>          absence.  But note:
>>>> 
>>>>              If "Flags" indicates that Modtime is present in the local header
>>>>              field, it MUST be present in the central header field, too!
>>>>              This correspondence is required because the modification time
>>>>              value may be used to support trans-timezone freshening and
>>>>              updating operations with zip archives.
>>>> 
>>>>          The time values are in standard Unix signed-long format, indicating
>>>>          the number of seconds since 1 January 1970 00:00:00.  The times
>>>>          are relative to Coordinated Universal Time (UTC), also sometimes
>>>>          referred to as Greenwich Mean Time (GMT).  To convert to local time,
>>>>          the software must know the local timezone offset from UTC/GMT.
>>>> 
>>>>          The lower three bits of Flags in both headers indicate which time-
>>>>          stamps are present in the LOCAL extra field:
>>>> 
>>>>                bit 0           if set, modification time is present
>>>>                bit 1           if set, access time is present
>>>>                bit 2           if set, creation time is present
>>>>                bits 3-7        reserved for additional timestamps; not set
>>>> 
>>>>          Those times that are present will appear in the order indicated, but
>>>>          any combination of times may be omitted.  (Creation time may be
>>>>          present without access time, for example.)  TSize should equal
>>>>          (1 + 4*(number of set bits in Flags)), as the block is currently
>>>>          defined.  Other timestamps may be added in the future.
>>>> 
>>>> 
>>>> --------------
>>>> 
>>>> It's hard to comment on why you received the error that you did but it is possible the tool that was used for writing the entry  did something unexpected.
>>>> 
>>>> Out of curiosity, have you tried using ZipFile/ZipEntry to access the entry?
>>>> 
>>>> 
>>>> Best,
>>>> Lance
>>>> 
>>>> 
>>>> On Oct 21, 2020, at 4:55 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> We've encountered a seemingly valid ZIP file (zipinfo -v shows all its
>>>> entries are intact) that causes a runtime exception when scanning its
>>>> contents with ZipFileSystem. The exception indicates an invalid
>>>> signature when parsing EXTID_EXTT. I don't quite understand this
>>>> comment in the code:
>>>> 
>>>> case EXTID_EXTT:
>>>>   // spec says the Extened timestamp in cen only has mtime
>>>>   // need to read the loc to get the extra a/ctime, if flag
>>>>   // "zipinfo-time" is not specified to false;
>>>>   // there is performance cost (move up to loc and read) to
>>>>   // access the loc table foreach entry;
>>>>   if (zipfs.noExtt) {
>>>>       if (sz == 5)
>>>>           mtime = unixToJavaTime(LG(extra, pos + 1));
>>>>        break;
>>>>   }
>>>> ...
>>>> 
>>>> but this ZIP file has the extra data block of exactly 5 bytes, as
>>>> indicated by zipinfo:
>>>> 
>>>> Central directory entry #6:
>>>> ---------------------------
>>>> ...
>>>> file system or operating system of origin:      Unix
>>>> version of encoding software:                   3.0
>>>> minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
>>>> minimum software version required to extract:   2.0
>>>> compression method:                             deflated
>>>> ...
>>>> extended local header:                          no
>>>> file last modified on (DOS date/time):          2018 Mar 1 04:56:20
>>>> file last modified on (UT extra field modtime): 2018 Mar 1 05:56:19 local
>>>> file last modified on (UT extra field modtime): 2018 Mar 1 04:56:19 UTC
>>>> ...
>>>> Unix file attributes (100000 octal):            ----------
>>>> MS-DOS file attributes (01 hex):                read-only
>>>> 
>>>> The central-directory extra field contains:
>>>> - A subfield with ID 0x5455 (universal time) and 5 data bytes.
>>>>   The local extra field has UTC/GMT modification/access times.
>>>> 
>>>> The above conditional block checking for length == 5 would have worked
>>>> in ZipFileSystem but it's surrounded by a condition over an
>>>> externally-provided property - zipfs.noExtt is only set to true if:
>>>> 
>>>> this.noExtt = "false".equals(env.get("zipinfo-time"));
>>>> 
>>>> I can't share this particular ZIP file with you and I don't know how
>>>> it was created but it seems like that "zipinfo-time" flag could be
>>>> omitted if the length of the extra data field is exactly 5?
>>>> 
>>>> Dawid
>>>> 
>>>> 
>>>> 
>>>> Best
>>>> Lance
>>>> ------------------
>>>> 
>>>> 
>>>> 
>>>> 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
>>>> 
>>>> 
>>>> 
>>>> 


Best
Lance
------------------




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





From github.com+10835776+stsypanov at openjdk.java.net  Fri Nov 27 20:26:17 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 27 Nov 2020 20:26:17 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v3]
In-Reply-To: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
Message-ID: <lR8p1rPo3hY4aZkiB_NPzBkDMhienlbQ5DXEJGq-PMo=.659157be-4bcb-4bd0-ac91-cb1a3234cb43@github.com>

> Original mail: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
> 
> Hello,
> 
> while working with `StringBuilder.insert()` I've spotted that its delegate `AbstractStringBuilder.insert()` is missing
> a fast-path for the most frequent case when its argument is `String`.
> 
> Previously they did similart optimization for `StirngBuilder.append(CharSequence, int, int)`,
> see https://bugs.openjdk.java.net/browse/JDK-8224986
> 
> I'd like to contribute a trivial patch that brings improvement for the case when SB's content is Latin1
> and inserted String is Latin1 as well.
> 
> To measure improvement I've used simple benchmark:
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class StringBuilderInsertBenchmark {
> 
>   @Benchmark
>   public StringBuilder insert(Data data) {
>     String string = data.string;
>     return new StringBuilder().append("ABC").insert(1, string, 1, data.length + 1);
>   }
> 
>   @State(Scope.Thread)
>   public static class Data {
>     String string;
> 
>     @Param({"true", "false"})
>     private boolean latin;
> 
>     @Param({"8", "64", "128", "1024"})
>     private int length;
> 
>     @Setup
>     public void setup() {
>       String alphabet = latin
>         ? "abcdefghijklmnopqrstuvwxyz"        // English
>         : "????????????????????????????????"; // Russian
> 
>       string = new RandomStringGenerator().randomString(alphabet, length + 2);
>     }
>   }
> }
> 
> public final class RandomStringGenerator {
> 
>   public String randomString(String alphabet, int length) {
>     char[] chars = alphabet.toCharArray();
> 
>     ThreadLocalRandom random = ThreadLocalRandom.current();
> 
>     char[] array = new char[length];
>     for (int i = 0; i < length; i++) {
>       array[i] = chars[random.nextInt(chars.length)];
>     }
> 
>     return new String(array);
>   }
> }
> Which gives
> 
>             (latin)  (length)       original       patched    Units
> insert         true         8    24.2 ?  0.1   22.2 ?  0.0    ns/op
> insert         true        64    53.8 ?  0.2   36.1 ?  0.1    ns/op
> insert         true       128    80.9 ?  0.2   44.6 ?  0.0    ns/op
> insert         true      1024   365.4 ?  0.5  109.8 ?  3.9    ns/op
> 
> insert        false         8    33.5 ?  0.5   32.3 ?  0.2    ns/op
> insert        false        64    73.2 ?  0.3   73.2 ?  0.2    ns/op
> insert        false       128   103.9 ?  0.6  103.3 ?  0.1    ns/op
> insert        false      1024   576.5 ?  4.8  569.5 ?  2.0    ns/op
> Patch is attached. As of tests tier1 and tier2 are ok.
> 
> With best regards,
> Sergey Tsypanov

?????? ??????? has updated the pull request with a new target base 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:

 - 8254082: Consolidate putStringAt() methods
 - Merge branch 'master' into asb
 - Merge branch 'master' into asb
 - 8254082: Add fast-path for String into AbstractStringBuilder.insert(int, CharSequence, int, int)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/402/files
  - new: https://git.openjdk.java.net/jdk/pull/402/files/f7e7b4fe..d4d98d63

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=402&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=402&range=01-02

  Stats: 182543 lines in 981 files changed: 119101 ins; 45414 del; 18028 mod
  Patch: https://git.openjdk.java.net/jdk/pull/402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/402/head:pull/402

PR: https://git.openjdk.java.net/jdk/pull/402

From github.com+10835776+stsypanov at openjdk.java.net  Fri Nov 27 20:31:01 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 27 Nov 2020 20:31:01 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v2]
In-Reply-To: <qM_l2Qxc2C7m4BhuoG5AHytx-4mUuSfzd7L8MhCoc5s=.ea17f97f-503f-4cdc-925b-fb9c0f0b43fc@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
 <3zKgT0YPjVDG852x1gQVRuv9rQ0lNatZWgzo-lRAHls=.c7d49a6a-2d3d-47f7-92ce-994dd69a4925@github.com>
 <qM_l2Qxc2C7m4BhuoG5AHytx-4mUuSfzd7L8MhCoc5s=.ea17f97f-503f-4cdc-925b-fb9c0f0b43fc@github.com>
Message-ID: <crYjVf6orDnkIGTNigAUmcf2y-T9KgPLQAIlfZIcf8M=.9bb0ffa1-505d-4af8-a2b6-07f4b91ad760@github.com>

On Wed, 25 Nov 2020 09:52:28 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 two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into asb
>>  - 8254082: Add fast-path for String into AbstractStringBuilder.insert(int, CharSequence, int, int)
>
> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1716:
> 
>> 1714:     }
>> 1715: 
>> 1716:     private void putCharsAt(int index, String s, int off, int end) {
> 
> Comparing this with `putStringAt(int index, String str)` below I think begs for some consolidation here. I think we either should add a `getBytes(value, index, coder, length)`, or - perhaps preferably? - factor out the package private `String.getBytes` and implement it here in ASB using `s.value()`

I've renamed `putCharsAt` -> `putStringAt`.

As of factoring out `String.getBytes` I believe we cannot do it, as it's referenced also from `StringConcatHelper`. Instead I suggest jusy to declare an overloaded method `getBytes(value, index, coder, length)`.

> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1721:
> 
>> 1719:             return;
>> 1720:         }
>> 1721:         inflate();
> 
> Like in `String.getBytes(byte[], int, byte)` I think we could do an `arraycopy` if both are `false` too, just need to carefully adjust the `index` et.c. In fact the only case that can't use an `arraycopy` in the end is when `s.isLatin1()` and the current sb is already inflated (that's what the `StringLatin1.inflate` branch does in `getBytes`). 
> 
> I think if you consolidate/merge this with the logic in `String.getBytes(byte[], int, byte)` as suggested you'll end up with a sizeable improvement on non-latin1 cases too.

Done

-------------

PR: https://git.openjdk.java.net/jdk/pull/402

From redestad at openjdk.java.net  Fri Nov 27 20:39:56 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 27 Nov 2020 20:39:56 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v2]
In-Reply-To: <crYjVf6orDnkIGTNigAUmcf2y-T9KgPLQAIlfZIcf8M=.9bb0ffa1-505d-4af8-a2b6-07f4b91ad760@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
 <3zKgT0YPjVDG852x1gQVRuv9rQ0lNatZWgzo-lRAHls=.c7d49a6a-2d3d-47f7-92ce-994dd69a4925@github.com>
 <qM_l2Qxc2C7m4BhuoG5AHytx-4mUuSfzd7L8MhCoc5s=.ea17f97f-503f-4cdc-925b-fb9c0f0b43fc@github.com>
 <crYjVf6orDnkIGTNigAUmcf2y-T9KgPLQAIlfZIcf8M=.9bb0ffa1-505d-4af8-a2b6-07f4b91ad760@github.com>
Message-ID: <V9I7djvEyYy4IpGVNDru-6NJkIZ45KlZpu4ILCgIGFY=.791a3e15-b4e4-4c4d-89d8-96915b0b1c79@github.com>

On Fri, 27 Nov 2020 20:28:17 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 1721:
>> 
>>> 1719:             return;
>>> 1720:         }
>>> 1721:         inflate();
>> 
>> Like in `String.getBytes(byte[], int, byte)` I think we could do an `arraycopy` if both are `false` too, just need to carefully adjust the `index` et.c. In fact the only case that can't use an `arraycopy` in the end is when `s.isLatin1()` and the current sb is already inflated (that's what the `StringLatin1.inflate` branch does in `getBytes`). 
>> 
>> I think if you consolidate/merge this with the logic in `String.getBytes(byte[], int, byte)` as suggested you'll end up with a sizeable improvement on non-latin1 cases too.
>
> Done

Nice! 

Did this help the non-latin1 case in your microbenchmark?

-------------

PR: https://git.openjdk.java.net/jdk/pull/402

From rriggs at openjdk.java.net  Fri Nov 27 20:48:36 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 27 Nov 2020 20:48:36 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v11]
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <Z5QvIsOf19DIfQU7qR2OQct05zLgxr72djHotDyUvx0=.bbfac8d4-e133-4a56-9baf-caa677c0c07d@github.com>

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> 
> Review comments and suggestions welcome.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:

 - Merge branch 'master' into 8251989-hex-formatter
 - Addressed review comments on use of formatted hexadecimal strings, updated copyrights, etc.
 - Clarified that suffix() and prefix() methods do not return null, instead the empty string is returned.
 - Merge branch 'master' into 8251989-hex-formatter
 - Merge branch 'master' into 8251989-hex-formatter
 - Merge branch 'master' into 8251989-hex-formatter
 - The HexFormat API indexing model for array and string ranges is changed
   to describe the range using 'fromIndex (inclusive)' and 'toIndex (exclusive)'.
   
   Initially, it was specified as 'index' and 'length'. However, both byte arrays
   and strings used in the HexFormat API typically use fromIndex and toIndex
   to describe ranges.  Using the same indexing model can prevent mistakes.
   
   The change affects the methods and corresponding tests:
   
       formatHex(byte[] bytes, int fromIndex, int toIndex)
       formatHex(A out, byte[] bytes, int fromIndex, int toIndex)
       parseHex(char[] chars, int fromIndex, int toIndex)
       parseHex(CharSequence string, int fromIndex, int toIndex)
       fromHexDigits(CharSequence string, int fromIndex, int toIndex)
       fromHexDigitsToLong(CharSequence string, int fromIndex, int toIndex)
 - - Added @see and @link references to Integer.toHexString and Long.toHexString
   - Clarified parsing is case insensistive in various parse and fromXXX methods
   - Source level cleanup based on review comments
   - Expanded some javadoc tag text to make it more descriptive
   - Consistent use of 'hexadecimal' vs 'hex'
 - Review comment updates to class javadoc
 - Review comment updates, in the example code, and to describe the characters used to convert to hexadecimal
 - ... and 11 more: https://git.openjdk.java.net/jdk/compare/6e562b1b...29f9bf7b

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/482/files
  - new: https://git.openjdk.java.net/jdk/pull/482/files/b19d2827..29f9bf7b

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=10
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=09-10

  Stats: 11696 lines in 333 files changed: 4100 ins; 1568 del; 6028 mod
  Patch: https://git.openjdk.java.net/jdk/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482

PR: https://git.openjdk.java.net/jdk/pull/482

From redestad at openjdk.java.net  Fri Nov 27 21:14:01 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Fri, 27 Nov 2020 21:14:01 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v3]
In-Reply-To: <lR8p1rPo3hY4aZkiB_NPzBkDMhienlbQ5DXEJGq-PMo=.659157be-4bcb-4bd0-ac91-cb1a3234cb43@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
 <lR8p1rPo3hY4aZkiB_NPzBkDMhienlbQ5DXEJGq-PMo=.659157be-4bcb-4bd0-ac91-cb1a3234cb43@github.com>
Message-ID: <UHKiLiCTk7rxbAwrDCraS8NHJQdZQOUvPFcXB7q-VFQ=.c75111cb-7c17-45b0-9955-b38e04ac6c30@github.com>

On Fri, 27 Nov 2020 20:26:17 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Original mail: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
>> 
>> Hello,
>> 
>> while working with `StringBuilder.insert()` I've spotted that its delegate `AbstractStringBuilder.insert()` is missing
>> a fast-path for the most frequent case when its argument is `String`.
>> 
>> Previously they did similart optimization for `StirngBuilder.append(CharSequence, int, int)`,
>> see https://bugs.openjdk.java.net/browse/JDK-8224986
>> 
>> I'd like to contribute a trivial patch that brings improvement for the case when SB's content is Latin1
>> and inserted String is Latin1 as well.
>> 
>> To measure improvement I've used simple benchmark:
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>> public class StringBuilderInsertBenchmark {
>> 
>>   @Benchmark
>>   public StringBuilder insert(Data data) {
>>     String string = data.string;
>>     return new StringBuilder().append("ABC").insert(1, string, 1, data.length + 1);
>>   }
>> 
>>   @State(Scope.Thread)
>>   public static class Data {
>>     String string;
>> 
>>     @Param({"true", "false"})
>>     private boolean latin;
>> 
>>     @Param({"8", "64", "128", "1024"})
>>     private int length;
>> 
>>     @Setup
>>     public void setup() {
>>       String alphabet = latin
>>         ? "abcdefghijklmnopqrstuvwxyz"        // English
>>         : "????????????????????????????????"; // Russian
>> 
>>       string = new RandomStringGenerator().randomString(alphabet, length + 2);
>>     }
>>   }
>> }
>> 
>> public final class RandomStringGenerator {
>> 
>>   public String randomString(String alphabet, int length) {
>>     char[] chars = alphabet.toCharArray();
>> 
>>     ThreadLocalRandom random = ThreadLocalRandom.current();
>> 
>>     char[] array = new char[length];
>>     for (int i = 0; i < length; i++) {
>>       array[i] = chars[random.nextInt(chars.length)];
>>     }
>> 
>>     return new String(array);
>>   }
>> }
>> Which gives
>> 
>>             (latin)  (length)       original       patched    Units
>> insert         true         8    24.2 ?  0.1   22.2 ?  0.0    ns/op
>> insert         true        64    53.8 ?  0.2   36.1 ?  0.1    ns/op
>> insert         true       128    80.9 ?  0.2   44.6 ?  0.0    ns/op
>> insert         true      1024   365.4 ?  0.5  109.8 ?  3.9    ns/op
>> 
>> insert        false         8    33.5 ?  0.5   32.3 ?  0.2    ns/op
>> insert        false        64    73.2 ?  0.3   73.2 ?  0.2    ns/op
>> insert        false       128   103.9 ?  0.6  103.3 ?  0.1    ns/op
>> insert        false      1024   576.5 ?  4.8  569.5 ?  2.0    ns/op
>> Patch is attached. As of tests tier1 and tier2 are ok.
>> 
>> With best regards,
>> Sergey Tsypanov
>
> ?????? ??????? has updated the pull request with a new target base 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:
> 
>  - 8254082: Consolidate putStringAt() methods
>  - Merge branch 'master' into asb
>  - Merge branch 'master' into asb
>  - 8254082: Add fast-path for String into AbstractStringBuilder.insert(int, CharSequence, int, int)

src/java.base/share/classes/java/lang/String.java line 3620:

> 3618:     void getBytes(byte[] dst, int srcPos, int dstBegin, byte coder, int length) {
> 3619:         if (coder() == coder) {
> 3620:             System.arraycopy(value, srcPos, dst, dstBegin << coder, length);

Would it be more consistent and easier to follow if we took the length in chars, not in bytes, and adjusted it here with the coder? JITs should do short work of the need to adjust by calling `length()` in `getBytes(byte[], int, byte)` above.

If we're worried about unexpected performance effects we can separate these two `getBytes` methods to independent methods rather than delegate from one to the other.

-------------

PR: https://git.openjdk.java.net/jdk/pull/402

From github.com+34924738+mahendrachhipa at openjdk.java.net  Fri Nov 27 21:47:02 2020
From: github.com+34924738+mahendrachhipa at openjdk.java.net (Mahendra Chhipa)
Date: Fri, 27 Nov 2020 21:47:02 GMT
Subject: RFR: JDK-8249836 java/io/IOException/LastErrorString.java should have
 bug-id as 1st word in @ignore
Message-ID: <tbepWCBf9z-ht6SdCVIzrPa6ZODUIBUd1UG7V8cTq28=.22cf697d-ecab-4cc7-b9b4-309c32eda64f@github.com>

?id as 1st word in @ignore

https://bugs.openjdk.java.net/browse/JDK-8249836

-------------

Commit messages:
 - JDK-8249836 ava/io/IOException/LastErrorString.java should have
 - JDK-8249836 java/io/IOException/LastErrorString.java should have bug-id as 1st word in @ignore
 - JDK-8249836 java/io/IOException/LastErrorString.java should have

Changes: https://git.openjdk.java.net/jdk/pull/1482/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1482&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8249836
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1482/head:pull/1482

PR: https://git.openjdk.java.net/jdk/pull/1482

From github.com+10835776+stsypanov at openjdk.java.net  Fri Nov 27 21:50:57 2020
From: github.com+10835776+stsypanov at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Fri, 27 Nov 2020 21:50:57 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v2]
In-Reply-To: <V9I7djvEyYy4IpGVNDru-6NJkIZ45KlZpu4ILCgIGFY=.791a3e15-b4e4-4c4d-89d8-96915b0b1c79@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
 <3zKgT0YPjVDG852x1gQVRuv9rQ0lNatZWgzo-lRAHls=.c7d49a6a-2d3d-47f7-92ce-994dd69a4925@github.com>
 <qM_l2Qxc2C7m4BhuoG5AHytx-4mUuSfzd7L8MhCoc5s=.ea17f97f-503f-4cdc-925b-fb9c0f0b43fc@github.com>
 <crYjVf6orDnkIGTNigAUmcf2y-T9KgPLQAIlfZIcf8M=.9bb0ffa1-505d-4af8-a2b6-07f4b91ad760@github.com>
 <V9I7djvEyYy4IpGVNDru-6NJkIZ45KlZpu4ILCgIGFY=.791a3e15-b4e4-4c4d-89d8-96915b0b1c79@github.com>
Message-ID: <4X1WWuJdPS12bdtoMcpCcw10B41A34255tpFW2fIkv0=.f6a41982-37ae-483d-bbe1-d12cc491d2f6@github.com>

On Fri, 27 Nov 2020 20:36:55 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Done
>
> Nice! 
> 
> Did this help the non-latin1 case in your microbenchmark?

Yes, now it's significantly faster on longer strings
            (latin)  (length)    Score     Error   Units
insert         true         8   22.970 ?   0.291   ns/op
insert         true        64   37.636 ?   0.613   ns/op
insert         true       128   45.412 ?   0.876   ns/op
insert         true      1024  134.511 ?  16.446   ns/op

insert        false         8   35.429 ?   2.410   ns/op
insert        false        64   60.654 ?   1.673   ns/op
insert        false       128   80.743 ?   4.798   ns/op
insert        false      1024  368.987 ?  19.309   ns/op

-------------

PR: https://git.openjdk.java.net/jdk/pull/402

From winterhalter at openjdk.java.net  Fri Nov 27 22:39:56 2020
From: winterhalter at openjdk.java.net (Rafael Winterhalter)
Date: Fri, 27 Nov 2020 22:39:56 GMT
Subject: RFR: 8256693: getAnnotatedReceiverType parameterizes types too
 eagerly
In-Reply-To: <c812KhJUpMp2O477vXOQYZym1r-ASXI8A8AfVWSIvwc=.f2941183-bb4f-46a3-aedf-a153d370b882@github.com>
References: <zs785BGvPByMHgja-uOZKD-NFsZn_iHcXa6lyb3YmAE=.7f512858-303b-429a-bd4d-704305bdd024@github.com>
 <c812KhJUpMp2O477vXOQYZym1r-ASXI8A8AfVWSIvwc=.f2941183-bb4f-46a3-aedf-a153d370b882@github.com>
Message-ID: <E7KD9RvwXQGwf61Ef46GOctnrUGzHWhmyYmjpNR27Fk=.39883b24-c980-4889-bdc3-b250727fc45f@github.com>

On Tue, 24 Nov 2020 15:56:05 GMT, Joel Borggr?n-Franck <jfranck at openjdk.org> wrote:

>> The fix for JDK-8256693 too often produces a ParameterizedType as the result of getAnnotatedReceiverType().getType() . A ParameterizedType is necessary when this type or any of its transitive owner types has type parameters, but should be avoided if this isn't the case.
>> 
>> This implementation recursively creates a chain of ParameterizedTypes starting from the outermost type that has type parameters.
>
> @raphw can you take a look at this?

I just ran it a bit and this seems right to me. I just had an error reported in relation to this and I think this is fixed by your changes, too. (https://github.com/raphw/byte-buddy/issues/983)

-------------

PR: https://git.openjdk.java.net/jdk/pull/1414

From naoto at openjdk.java.net  Fri Nov 27 22:43:01 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 27 Nov 2020 22:43:01 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <lqjOSgRCHdfPvSscZjNkzrj-vNdZkAWiiynksfBhQUs=.418f185a-9cf3-4a12-9506-5de6a152e6f5@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
 <2nUVJ9EKuqnoGTq1ZPCazHnmbIFAmLAJXjiCTY2dGeU=.130cb5a7-a189-4483-8832-74c67cdd39e1@github.com>
 <lqjOSgRCHdfPvSscZjNkzrj-vNdZkAWiiynksfBhQUs=.418f185a-9cf3-4a12-9506-5de6a152e6f5@github.com>
Message-ID: <YzWYkeHTDWOKFOCQlmPQUuKz4Qgz74ZSyB2Zfrn526U=.0fd2f014-22bc-4a95-a679-e9d262a42afc@github.com>

On Fri, 27 Nov 2020 16:57:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/HexFormat.java line 853:
>> 
>>> 851:      */
>>> 852:     public int fromHexDigit(int ch) {
>>> 853:         int value = Character.digit(ch, 16);
>> 
>> Do we need to limit parsing the hex digit for only [0-9a-fA-F]? This would return `0` for other digits, say `fullwidth digit zero` (U+FF10)
>
> The normal and conventional characters for hex encoding are limited to the ASCII/Latin1 range.
> I don't know of any use case that would take advantage of non-ASCII characters.

My point is that probably we should define `hexadecimal string` more clearly. In the class description, that exclusively means [0-9a-fA-F] in the context of formatting, but in the parsing, it allows non-ASCII digits. e.g.,
HexFormat.of().parseHex("\uff10\uff11")
Succeeds. I would like consistency here.

-------------

PR: https://git.openjdk.java.net/jdk/pull/482

From github.com+1290376+johnlinp at openjdk.java.net  Sat Nov 28 08:16:56 2020
From: github.com+1290376+johnlinp at openjdk.java.net (John Lin)
Date: Sat, 28 Nov 2020 08:16:56 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <cHf3AFx0fpIAKquwIO0lfVZ7-e9w_qMqBPt5I763_9g=.b2432a97-f14f-4b42-b525-028bcfea9c9f@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
 <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
 <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
 <TFCxfLxB7_iDyPbbSXJtWZZm4HOW_n4R66vMnNEzYvI=.1659cc00-17c8-4999-bbb7-b5c7516599b7@github.com>
 <m03pV9naVWuHcK_vDJPmbc475it1Z0rtCATTwsIOp3s=.ee0b9cf3-1bd3-4351-a40d-f19bd20850bd@github.com>
 <cFfnvRrX6Flsj8XZcYxTWD_adHXBwqKEGaGnrOD4OUM=.c4dca349-abe3-455a-b686-3a39036e1eec@github.com>
 <cHf3AFx0fpIAKquwIO0lfVZ7-e9w_qMqBPt5I763_9g=.b2432a97-f14f-4b42-b525-028bcfea9c9f@github.com>
Message-ID: <iramI7ZUUT3x9XKHzggmgEbO0v82pSAbt34Ckgin6Rs=.1ac9faf0-aec8-4f52-bd1b-8057c4de5f1e@github.com>

On Wed, 25 Nov 2020 20:22:21 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> @pavelrappo 
>> 
>>> What is the required level of fidelity particular (pseudo-) code has to have?
>> 
>> It's potentially a large discussion, one that could be had in the context of my JEP draft http://openjdk.java.net/jeps/8068562 . However, speaking practically, it's possible to focus the discussion fairly concisely: the main responsibility of the `@implSpec` ("Implementation Requirements") section is to give implementors of subclasses enough information to decide whether to inherit the implementation or to override it, and if they override it, what behavior they can expect if they were to call `super.compute`.
>> 
>> In this case, a null-value-tolerating Map implementation needs to know that the default implementation calls `remove` in the particular case that you mentioned. A concurrent Map implementation will also need to know that the default implementation calls `get(key)` and `containsKey(key)` at different times, potentially leading to a race condition. Both of these inform the override vs. inherit decision.
>
> @stuart-marks 
> 
>> Both of these inform the override vs. inherit decision.
> 
> So in this case - fixing the specification to match the default implementation seems to be the right call - as existing implementations that do not override are more probably depending on the current default behavior.

Thank you all for giving me great advice. Sounds like the conclusion is to update the documentation to match the default implementation. I'll update this PR and propose a new CSR accordingly.

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From github.com+1290376+johnlinp at openjdk.java.net  Sat Nov 28 08:35:20 2020
From: github.com+1290376+johnlinp at openjdk.java.net (John Lin)
Date: Sat, 28 Nov 2020 08:35:20 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements [v2]
In-Reply-To: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
Message-ID: <o08-K-MocwqVFt3-JJIUvR9kuDMRaNDUjJ2E1SpVaAA=.ab3fabba-e9b9-42a4-a166-e9ec2db183ab@github.com>

> This is from the mailing list: http://mail.openjdk.java.net/pipermail/core-libs-dev/2020-June/067190.html
> 
> ---------
> ### Progress
> - [x] Change must not contain extraneous whitespace
> - [x] Commit message must refer to an issue
> - [ ] Change must be properly reviewed
> 
> ### Testing
> 
> |     | Linux x64 | Windows x64 | macOS x64 |
> | --- | ----- | ----- | ----- |
> | Build | ?? (5/5 passed) | ?? (2/2 passed) | ?? (2/2 passed) |
> | Test (tier1) | ?? (9/9 passed) | ?? (9/9 passed) | ?? (9/9 passed) |
> 
> 
> 
> ### Download
> `$ git fetch https://git.openjdk.java.net/jdk pull/714/head:pull/714`
> `$ git checkout pull/714`

John Lin has updated the pull request with a new target base 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:

  8247402: Documentation for Map::compute contains confusing implementation requirements

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/714/files
  - new: https://git.openjdk.java.net/jdk/pull/714/files/d058e798..d16a35b8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=714&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=714&range=00-01

  Stats: 394209 lines in 3620 files changed: 249166 ins; 107447 del; 37596 mod
  Patch: https://git.openjdk.java.net/jdk/pull/714.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/714/head:pull/714

PR: https://git.openjdk.java.net/jdk/pull/714

From github.com+1290376+johnlinp at openjdk.java.net  Sat Nov 28 08:45:54 2020
From: github.com+1290376+johnlinp at openjdk.java.net (John Lin)
Date: Sat, 28 Nov 2020 08:45:54 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <m03pV9naVWuHcK_vDJPmbc475it1Z0rtCATTwsIOp3s=.ee0b9cf3-1bd3-4351-a40d-f19bd20850bd@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
 <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
 <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
 <TFCxfLxB7_iDyPbbSXJtWZZm4HOW_n4R66vMnNEzYvI=.1659cc00-17c8-4999-bbb7-b5c7516599b7@github.com>
 <m03pV9naVWuHcK_vDJPmbc475it1Z0rtCATTwsIOp3s=.ee0b9cf3-1bd3-4351-a40d-f19bd20850bd@github.com>
Message-ID: <1dB5tA98aqSqjaSJOUP56CCBB6SrKFl1jMJ6mq3Hxt4=.d2eeb855-f1d2-42d8-b031-b699d07058f6@github.com>

On Wed, 25 Nov 2020 16:39:20 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> @pavelrappo Please see my proposed CSR below. Thank you.
>> 
>> # Map::compute should have a clearer implementation requirement.
>> 
>> ## Summary
>> 
>> java.util.Map::compute should have a clearer implementation requirement in its documentation.
>> 
>> ## Problem
>> 
>> The documentation of the implementation requirements for Map::compute has the following problems:
>> 1. It lacks of return statements for most of the if-else cases.
>> 1. The indents are 3 spaces, while the convention is 4 spaces.
>> 1. The if-else is overly complicated and can be simplified.
>> 
>> ## Solution
>> 
>> Rewrite the documentation of Map::compute to match its default implementation.
>> 
>> ## Specification
>> 
>> diff --git a/src/java.base/share/classes/java/util/Map.java b/src/java.base/share/classes/java/util/Map.java
>> index b1de34b42a5..c3118a90581 100644
>> --- a/src/java.base/share/classes/java/util/Map.java
>> +++ b/src/java.base/share/classes/java/util/Map.java
>> @@ -1113,17 +1113,12 @@ public interface Map<K, V> {
>>       * <pre> {@code
>>       * V oldValue = map.get(key);
>>       * V newValue = remappingFunction.apply(key, oldValue);
>> -     * if (oldValue != null) {
>> -     *    if (newValue != null)
>> -     *       map.put(key, newValue);
>> -     *    else
>> -     *       map.remove(key);
>> -     * } else {
>> -     *    if (newValue != null)
>> -     *       map.put(key, newValue);
>> -     *    else
>> -     *       return null;
>> +     * if (newValue != null) {
>> +     *     map.put(key, newValue);
>> +     * } else if (oldValue != null) {
>> +     *     map.remove(key);
>>       * }
>> +     * return newValue;
>>       * }</pre>
>>       *
>>       * <p>The default implementation makes no guarantees about detecting if the
>
> @johnlinp In any case, you'd also need to update the surrounding prose; we need to remove this:
>  returning the current value or {@code null} if absent:```

@pavelrappo Please see my updated CSR below. Thanks.

# Map::compute should have the implementation requirement match its default implementation

## Summary

The implementation requirement of Map::compute does not match its default implementation. Besides, it has some other minor issues. We should fix it.

## Problem

The documentation of the implementation requirements for Map::compute has the following problems:
1. It doesn't match its default implementation.
1. It lacks of the return statements for most of the if-else cases.
1. The indents are 3 spaces, while the convention is 4 spaces.
1. The if-else is overly complicated and can be simplified.
1. The surrounding prose contains incorrect statements.

## Solution

Rewrite the documentation of Map::compute to match its default implementation and solve the above mentioned problems.

## Specification

diff --git a/src/java.base/share/classes/java/util/Map.java b/src/java.base/share/classes/java/util/Map.java
index b1de34b42a5..b30e3979259 100644
--- a/src/java.base/share/classes/java/util/Map.java
+++ b/src/java.base/share/classes/java/util/Map.java
@@ -1107,23 +1107,17 @@ public interface Map<K, V> {
      *
      * @implSpec
      * The default implementation is equivalent to performing the following
-     * steps for this {@code map}, then returning the current value or
-     * {@code null} if absent:
+     * steps for this {@code map}:
      *
      * <pre> {@code
      * V oldValue = map.get(key);
      * V newValue = remappingFunction.apply(key, oldValue);
-     * if (oldValue != null) {
-     *    if (newValue != null)
-     *       map.put(key, newValue);
-     *    else
-     *       map.remove(key);
-     * } else {
-     *    if (newValue != null)
-     *       map.put(key, newValue);
-     *    else
-     *       return null;
+     * if (newValue != null) {
+     *     map.put(key, newValue);
+     * } else if (oldValue != null || map.containsKey(key)) {
+     *     map.remove(key);
      * }
+     * return newValue;
      * }</pre>
      *
      * <p>The default implementation makes no guarantees about detecting if the

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From eosterlund at openjdk.java.net  Sat Nov 28 09:04:03 2020
From: eosterlund at openjdk.java.net (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Sat, 28 Nov 2020 09:04:03 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo [v2]
In-Reply-To: <lRizv2JGrdsVw9AZ01ORWRlupCj4EkoGQ2phRMNUQEc=.9dd769f2-a3ae-4673-89cf-1959f984225c@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <lRizv2JGrdsVw9AZ01ORWRlupCj4EkoGQ2phRMNUQEc=.9dd769f2-a3ae-4673-89cf-1959f984225c@github.com>
Message-ID: <eJl9Z5tz7m2XRNvtXMdLMA9ZVqRQ2nrpuTzaIHXakCg=.c97c75ea-2867-4eea-8792-14a90b5fae8c@github.com>

On Wed, 25 Nov 2020 23:35:14 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
>> 
>> Initial patch was prepared by @fisk.
>> 
>> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
>> 
>> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.
>
> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8256999
>  - Added ZLoadBarrierElided = 0 definition.
>    Removed is_exact argument in load_field_from_object().
>    Added Shenandoah support for narrow phantom accesses.
>  - 8256999: Add C2 intrinsic for Reference.refersTo and PhantomReference::refersTo

Looks good.

-------------

Marked as reviewed by eosterlund (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1425

From shade at openjdk.java.net  Sat Nov 28 09:46:01 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Sat, 28 Nov 2020 09:46:01 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo [v2]
In-Reply-To: <tgxA6KEmUot4HOhNKYT6O5k_DoYjQ_XPE4_8ev09Gik=.85e47193-644f-4f09-921d-32c922d48bae@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <lRizv2JGrdsVw9AZ01ORWRlupCj4EkoGQ2phRMNUQEc=.9dd769f2-a3ae-4673-89cf-1959f984225c@github.com>
 <tgxA6KEmUot4HOhNKYT6O5k_DoYjQ_XPE4_8ev09Gik=.85e47193-644f-4f09-921d-32c922d48bae@github.com>
Message-ID: <yP9dZ_ws9OWKrw0yHvnUABs6pQfCF_JQG5VFLly8mv8=.741dfc53-efc9-4302-9cdb-ed5065682a23@github.com>

On Sat, 28 Nov 2020 09:43:15 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8256999
>>  - Added ZLoadBarrierElided = 0 definition.
>>    Removed is_exact argument in load_field_from_object().
>>    Added Shenandoah support for narrow phantom accesses.
>>  - 8256999: Add C2 intrinsic for Reference.refersTo and PhantomReference::refersTo
>
> Yes, still looks good for me.

You might want to pull from master to get clean `x86_32` test runs.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From shade at openjdk.java.net  Sat Nov 28 09:45:59 2020
From: shade at openjdk.java.net (Aleksey Shipilev)
Date: Sat, 28 Nov 2020 09:45:59 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo [v2]
In-Reply-To: <lRizv2JGrdsVw9AZ01ORWRlupCj4EkoGQ2phRMNUQEc=.9dd769f2-a3ae-4673-89cf-1959f984225c@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
 <lRizv2JGrdsVw9AZ01ORWRlupCj4EkoGQ2phRMNUQEc=.9dd769f2-a3ae-4673-89cf-1959f984225c@github.com>
Message-ID: <tgxA6KEmUot4HOhNKYT6O5k_DoYjQ_XPE4_8ev09Gik=.85e47193-644f-4f09-921d-32c922d48bae@github.com>

On Wed, 25 Nov 2020 23:35:14 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
>> 
>> Initial patch was prepared by @fisk.
>> 
>> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
>> 
>> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.
>
> Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8256999
>  - Added ZLoadBarrierElided = 0 definition.
>    Removed is_exact argument in load_field_from_object().
>    Added Shenandoah support for narrow phantom accesses.
>  - 8256999: Add C2 intrinsic for Reference.refersTo and PhantomReference::refersTo

Yes, still looks good for me.

-------------

Marked as reviewed by shade (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1425

From github.com+1059453+fleshgrinder at openjdk.java.net  Sat Nov 28 10:12:10 2020
From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger)
Date: Sat, 28 Nov 2020 10:12:10 GMT
Subject: RFR: 5023614: UUID needs methods to get most/leastSigBits and
 write to DataOutput [v3]
In-Reply-To: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com>
References: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com>
Message-ID: <iAEAGHn8OGv0fHyvwdA1jQGMMmWifapE-df692ao3ik=.92b80822-7bbc-43ec-a926-525f01f4109e@github.com>

> Made byte constructor public and changed the length assertion to an `IllegalArgumentException`, added a `getBytes` method that allows users to retrieve the raw bytes of the UUID, and created a new private constructor with an optimized construction for byte arrays that can set the version as desired and the variant to RFC 4122. Also changed the existing static factory methods to use the new constructor and removed the duplicate code from them where the variant and version is being set.
> 
> Report [5023614](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5023614) asks for more than what I provided and with different names. However, I believe that there is no value in providing methods to deal with `DataInput` and `DataOutput` because they would only encapsulate single method calls that the caller can directly write as well (e.g. `output.write(uuid.getBytes())` vs `uuid.write(output)`). Hence, I consider this change to satisfy the feature request.

Richard Fussenegger 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:

  5023614: UUID needs methods to get most/leastSigBits and write to DataOutput
  
  Made byte constructor public and changed the length assertion to an `IllegalArgumentException`, added a `getBytes` method that allows users to retrieve the raw bytes of the UUID, and created a new private constructor with an optimized construction for byte arrays that can set the version as desired and the variant to RFC 4122. Also changed the existing static factory methods to use the new constructor and removed the duplicate code from them where the variant and version is being set. Report [5023614](https://bugs.java.com/bugdatabase/view_bug.do?bug_id=5023614) asks for more than what I provided and with different names. However, I believe that there is no value in providing methods to deal with `DataInput` and `DataOutput` because they would only encapsulate single method calls that the caller can directly write as well (e.g. `output.write(uuid.getBytes())` vs `uuid.write(output)`). Hence, I consider this change to satisfy the feature request.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1465/files
  - new: https://git.openjdk.java.net/jdk/pull/1465/files/6813023d..a987234d

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1465&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1465&range=01-02

  Stats: 103 lines in 1 file changed: 62 ins; 22 del; 19 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1465.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1465/head:pull/1465

PR: https://git.openjdk.java.net/jdk/pull/1465

From github.com+1059453+fleshgrinder at openjdk.java.net  Sat Nov 28 10:12:11 2020
From: github.com+1059453+fleshgrinder at openjdk.java.net (Richard Fussenegger)
Date: Sat, 28 Nov 2020 10:12:11 GMT
Subject: RFR: 5023614: UUID needs methods to get most/leastSigBits and
 write to DataOutput [v2]
In-Reply-To: <2EG8nsujV7af7O-NZDulOcsilrMn2ZsjhJxJISfOsoQ=.3ffe5e3e-e78d-4f5e-b6bf-73d58636168a@github.com>
References: <2jx_KKaEEiEbvuAH398iD_noYamG-_50NkL4nCIQwXE=.5da5bc1d-4cf2-4a10-90be-5dfdaaba9e0e@github.com>
 <WpxYw9aQm5zAjR0scgzvxKMWhhgB7SqDykLGkBEEIYI=.ef9c42f2-dfa8-495b-ba4a-03387b7e6a7b@github.com>
 <xky6EB8mGrS1f2RpJGb8n2b_NlmKEZw3UqP17CG7UM8=.4e5f39a3-ab1a-4c95-8def-10e38eec0d04@github.com>
 <2EG8nsujV7af7O-NZDulOcsilrMn2ZsjhJxJISfOsoQ=.3ffe5e3e-e78d-4f5e-b6bf-73d58636168a@github.com>
Message-ID: <zLVZQfgGyiS1HZz5Q30hCR80-5TX7RGEyHTvNBE8JBU=.a2bfe3a2-73c2-4e22-a12c-a4b63a03650f@github.com>

On Thu, 26 Nov 2020 19:08:54 GMT, Richard Fussenegger <github.com+1059453+Fleshgrinder at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/UUID.java line 168:
>> 
>>> 166:     /**
>>> 167:      * Constructs a new {@code UUID} using the specified data.  {@code
>>> 168:      * mostSigBits} is used for the most significant 64 bits of the {@code
>> 
>> I think you need to agreement first on whether to add this API. Maybe there is a case for a new factory method rather than a constructor? Are there any concerns with creating UUIDs with random bytes.
>> 
>> If it goes ahead then I assume the the javadoc will need a bit of work to specify how the byte[] is mapped to the 128-bit value.
>> 
>> You might need to tweak a few other things like the javadoc styles and coding style to get it consistent with the existing code. That's for later.
>
> Hey @AlanBateman ?? I figured that most of the PRs I just created for UUID will require a CSR but I what couldn't figure out is/was how _I_ can create a CSR.
> 
> 1. Constructor or factory, I would be fine with both and happily change the impl.
> 1. We de-facto already allow the construction from random data through the `UUID(long, long)` constructor.
> 1. No problem either.
> 1. I had a look at the whole (well, sampling) JDK and various documents ([super, super, like 1999 old documents](https://www.oracle.com/java/technologies/javase/codeconventions-introduction.html)) and loaded the Oracle code style in IntelliJ. However, all I get is inconsistent. The existing files in the JDK are inconsistent. The UUID file is inconsistent in itself. The IntelliJ Oracle style is different too? I'm happy to change any line but would prefer it if there is some guidance with what is expected because I cannot figure it out on my own. ??

1. Changed it to static factory `valueOf`
2. ?
3. I extended the documentation.
4. I tried to match the existing formatting as good as possible.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1465

From github.com+10835776+stsypanov at openjdk.java.net  Sat Nov 28 14:00:10 2020
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, 28 Nov 2020 14:00:10 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v4]
In-Reply-To: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
Message-ID: <RTZpi5rl2_r1SJlnRC7RqTgBmw6ucHO9Wj7rUlfVb7w=.4409927c-65a4-49c9-b871-d9b98e07a240@github.com>

> Original mail: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
> 
> Hello,
> 
> while working with `StringBuilder.insert()` I've spotted that its delegate `AbstractStringBuilder.insert()` is missing
> a fast-path for the most frequent case when its argument is `String`.
> 
> Previously they did similart optimization for `StirngBuilder.append(CharSequence, int, int)`,
> see https://bugs.openjdk.java.net/browse/JDK-8224986
> 
> I'd like to contribute a trivial patch that brings improvement for the case when SB's content is Latin1
> and inserted String is Latin1 as well.
> 
> To measure improvement I've used simple benchmark:
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class StringBuilderInsertBenchmark {
> 
>   @Benchmark
>   public StringBuilder insert(Data data) {
>     String string = data.string;
>     return new StringBuilder().append("ABC").insert(1, string, 1, data.length + 1);
>   }
> 
>   @State(Scope.Thread)
>   public static class Data {
>     String string;
> 
>     @Param({"true", "false"})
>     private boolean latin;
> 
>     @Param({"8", "64", "128", "1024"})
>     private int length;
> 
>     @Setup
>     public void setup() {
>       String alphabet = latin
>         ? "abcdefghijklmnopqrstuvwxyz"        // English
>         : "????????????????????????????????"; // Russian
> 
>       string = new RandomStringGenerator().randomString(alphabet, length + 2);
>     }
>   }
> }
> 
> public final class RandomStringGenerator {
> 
>   public String randomString(String alphabet, int length) {
>     char[] chars = alphabet.toCharArray();
> 
>     ThreadLocalRandom random = ThreadLocalRandom.current();
> 
>     char[] array = new char[length];
>     for (int i = 0; i < length; i++) {
>       array[i] = chars[random.nextInt(chars.length)];
>     }
> 
>     return new String(array);
>   }
> }
> Which gives
> 
>             (latin)  (length)       original       patched    Units
> insert         true         8    24.2 ?  0.1   22.2 ?  0.0    ns/op
> insert         true        64    53.8 ?  0.2   36.1 ?  0.1    ns/op
> insert         true       128    80.9 ?  0.2   44.6 ?  0.0    ns/op
> insert         true      1024   365.4 ?  0.5  109.8 ?  3.9    ns/op
> 
> insert        false         8    33.5 ?  0.5   32.3 ?  0.2    ns/op
> insert        false        64    73.2 ?  0.3   73.2 ?  0.2    ns/op
> insert        false       128   103.9 ?  0.6  103.3 ?  0.1    ns/op
> insert        false      1024   576.5 ?  4.8  569.5 ?  2.0    ns/op
> Patch is attached. As of tests tier1 and tier2 are ok.
> 
> With best regards,
> Sergey Tsypanov

?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:

  8254082: Consolidate putStringAt() methods: make length represent char count

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/402/files
  - new: https://git.openjdk.java.net/jdk/pull/402/files/d4d98d63..e515ba64

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=402&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=402&range=02-03

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/402/head:pull/402

PR: https://git.openjdk.java.net/jdk/pull/402

From redestad at openjdk.java.net  Sat Nov 28 14:12:57 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sat, 28 Nov 2020 14:12:57 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v4]
In-Reply-To: <RTZpi5rl2_r1SJlnRC7RqTgBmw6ucHO9Wj7rUlfVb7w=.4409927c-65a4-49c9-b871-d9b98e07a240@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
 <RTZpi5rl2_r1SJlnRC7RqTgBmw6ucHO9Wj7rUlfVb7w=.4409927c-65a4-49c9-b871-d9b98e07a240@github.com>
Message-ID: <Zl-X8ZppSpbKzFC8F4V8XTlxG9Xsw_X4LgaOACHEARg=.6e2774fe-ae99-441b-a850-927e7a5d4ce6@github.com>

On Sat, 28 Nov 2020 14:00:10 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>> Original mail: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
>> 
>> Hello,
>> 
>> while working with `StringBuilder.insert()` I've spotted that its delegate `AbstractStringBuilder.insert()` is missing
>> a fast-path for the most frequent case when its argument is `String`.
>> 
>> Previously they did similart optimization for `StirngBuilder.append(CharSequence, int, int)`,
>> see https://bugs.openjdk.java.net/browse/JDK-8224986
>> 
>> I'd like to contribute a trivial patch that brings improvement for the case when SB's content is Latin1
>> and inserted String is Latin1 as well.
>> 
>> To measure improvement I've used simple benchmark:
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
>> public class StringBuilderInsertBenchmark {
>> 
>>   @Benchmark
>>   public StringBuilder insert(Data data) {
>>     String string = data.string;
>>     return new StringBuilder().append("ABC").insert(1, string, 1, data.length + 1);
>>   }
>> 
>>   @State(Scope.Thread)
>>   public static class Data {
>>     String string;
>> 
>>     @Param({"true", "false"})
>>     private boolean latin;
>> 
>>     @Param({"8", "64", "128", "1024"})
>>     private int length;
>> 
>>     @Setup
>>     public void setup() {
>>       String alphabet = latin
>>         ? "abcdefghijklmnopqrstuvwxyz"        // English
>>         : "????????????????????????????????"; // Russian
>> 
>>       string = new RandomStringGenerator().randomString(alphabet, length + 2);
>>     }
>>   }
>> }
>> 
>> public final class RandomStringGenerator {
>> 
>>   public String randomString(String alphabet, int length) {
>>     char[] chars = alphabet.toCharArray();
>> 
>>     ThreadLocalRandom random = ThreadLocalRandom.current();
>> 
>>     char[] array = new char[length];
>>     for (int i = 0; i < length; i++) {
>>       array[i] = chars[random.nextInt(chars.length)];
>>     }
>> 
>>     return new String(array);
>>   }
>> }
>> Which gives
>> 
>>             (latin)  (length)       original       patched    Units
>> insert         true         8    24.2 ?  0.1   22.2 ?  0.0    ns/op
>> insert         true        64    53.8 ?  0.2   36.1 ?  0.1    ns/op
>> insert         true       128    80.9 ?  0.2   44.6 ?  0.0    ns/op
>> insert         true      1024   365.4 ?  0.5  109.8 ?  3.9    ns/op
>> 
>> insert        false         8    33.5 ?  0.5   32.3 ?  0.2    ns/op
>> insert        false        64    73.2 ?  0.3   73.2 ?  0.2    ns/op
>> insert        false       128   103.9 ?  0.6  103.3 ?  0.1    ns/op
>> insert        false      1024   576.5 ?  4.8  569.5 ?  2.0    ns/op
>> Patch is attached. As of tests tier1 and tier2 are ok.
>> 
>> With best regards,
>> Sergey Tsypanov
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8254082: Consolidate putStringAt() methods: make length represent char count

Looks good to me. 

Theoretically the refactored `getBytes(byte[], int, byte)` should have no cost, but could cause some issues in some microbenchmarks that touches this. You mentioned this was used by StringConcatHelper, so could you run the org.openjdk.bench.java.lang.StringConcat micros to check that there are no regressions?

-------------

Marked as reviewed by redestad (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/402

From dawid.weiss at gmail.com  Sat Nov 28 14:34:47 2020
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Sat, 28 Nov 2020 15:34:47 +0100
Subject: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data
 field of exactly 5 bytes)
In-Reply-To: <DB63C62D-0D4C-42F4-8C7A-D732DFB8FB0C@ORACLE.COM>
References: <CAM21Rt8KeWyQvjE7-5pfyXYJXO3yGgGfKpBtueOV8qgNFMa+jQ@mail.gmail.com>
 <17F644E3-E5E0-403E-B568-FCB89C8BD9BB@ORACLE.COM>
 <CAM21Rt-ANpHbDO-kjSHguDzSTGS-WhGwHsbxcHav1wFVvDQ2EQ@mail.gmail.com>
 <CAM21Rt_8WWsTm-DrY=stscEuiWXF1-JJkv83wZoReJB7ZD-Kjw@mail.gmail.com>
 <CAM21Rt9tHhGf7+eKfrrLbPwP8jShZytF6Qh_3OS4yxVg=02hWQ@mail.gmail.com>
 <DB63C62D-0D4C-42F4-8C7A-D732DFB8FB0C@ORACLE.COM>
Message-ID: <CAM21Rt_3pVbOnn5wqt=hSTUALLMUyM2ERsd0x4f7J0NjMt8+Zg@mail.gmail.com>

I know what the problem is and I know what the fix should be (and tried to
convey it) but I don't have a patch. Writing the test case is not a problem
but it'll be a lengthy test on slower drives (has to create a zip file that
exceeds 4gb of disk space). I don't think there is a way to fake the file
system by using a sparse file, sadly. Would this be acceptable? If so then
sure - I can provide a reproducible test case that will fail for the
current implementation.

D.

On Fri, Nov 27, 2020 at 8:37 PM Lance Andersen <LANCE.ANDERSEN at oracle.com>
wrote:

> Hi Dawid,
>
> If you believe you have a a fix, please submit a patch along with a JTREG
> test case.  Ideally the test case would create zip file as part of the test.
>
> Best
> Lance
>
> On Nov 27, 2020, at 7:37 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
>
> Just for the archives - I'm not sure if this ended up being filed to
> the bug system - the repro below demonstrates the bug on all JDKs up
> to the newest one.
>
> # create a single random file of 250 megabytes
> head -c 250M < /dev/urandom > rnd.bin
> # create a bunch of hardlinks to the same file.
> for i in `seq -w 1 25`; do ln rnd.bin rnd-$i.bin; done
> # create a zip archive exceeding 4gb (in stored mode so that it's faster)
> zip -0 archive.zip rnd*.bin
> # show the content of the archive - for all entries beyond 4gb this should
> # show extra data blocks like below (note the order of extra data
> blocks - this is important).
> #
> #  The central-directory extra field contains:
> # - A subfield with ID 0x5455 (universal time) and 5 data bytes.
> #   The local extra field has UTC/GMT modification/access times.
> # - A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
> #   01 04 ea 03 00 00 04 ea 03 00 00.
> # - A subfield with ID 0x0001 (PKWARE 64-bit sizes) and 8 data bytes:
> #  a4 06 a0 86 01 00 00 00.
> #
> zipinfo -v archive.zip
>
> # Bug repro code:
> cat > Test.java <<EOF
> import java.io.*;
> import java.nio.*;
> import java.nio.file.*;
> import java.nio.file.attribute.*;
>
> public class Test {
>  public static void main(String[]args) throws IOException {
>    try (FileSystem fs =
> FileSystems.newFileSystem(Paths.get("archive.zip"))) {
>      for (Path root : fs.getRootDirectories()) {
>        Files.walkFileTree(root, new SimpleFileVisitor<>() {
>          public FileVisitResult visitFile(Path file,
> BasicFileAttributes attrs) throws IOException {
>            return FileVisitResult.CONTINUE;
>          }
>        });
>      }
>    }
>  }
> }
> EOF
> # and run it.
> java Test.java
>
> The above ends with:
>
> Exception in thread "main" java.util.zip.ZipException: loc: wrong sig
> ->841cd111
>        at
> jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readExtra(ZipFileSystem.java:2899)
>        at
> jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readCEN(ZipFileSystem.java:2600)
>        at
> jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.<init>(ZipFileSystem.java:2536)
>        at
> jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.getFileAttributes(ZipFileSystem.java:532)
>        at jdk.zipfs/jdk.nio.zipfs.ZipPath.readAttributes(ZipPath.java:767)
>        at jdk.zipfs/jdk.nio.zipfs.ZipPath.readAttributes(ZipPath.java:777)
>        at
> jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.readAttributes(ZipFileSystemProvider.java:276)
>        at java.base/java.nio.file.Files.readAttributes(Files.java:1843)
>        at
> java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:219)
>        at
> java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:276)
>        at
> java.base/java.nio.file.FileTreeWalker.next(FileTreeWalker.java:373)
>        at java.base/java.nio.file.Files.walkFileTree(Files.java:2840)
>        at java.base/java.nio.file.Files.walkFileTree(Files.java:2876)
>        at Test.main(Test.java:10)
>
> The fix is relatively simple I think - the current code assumes entry
> offset is < 4GB when parsing extra data for
> ID 0x5455. This should be evaluated lazily after all extra data blocks
> are parsed to ensure the file offset is correctly
> updated based on block ID 0x0001, regardless of its ordering within
> other extra data blocks.
>
>
>
> On Fri, Oct 23, 2020 at 9:12 AM Dawid Weiss <dawid.weiss at gmail.com> wrote:
>
>
>
> This looks like a legitimate bug to me (the zip file system implementation
> is sensitive to the order of extra parameters and may throw an unexpected
> error
> on zip64 archives exceeding 4 gigabytes). I can't file a Jira issue - no
> permissions - but I think it'd be worth adding one?
>
> Dawid
>
> On Wed, Oct 21, 2020 at 8:36 PM Dawid Weiss <dawid.weiss at gmail.com> wrote:
>
>
> Hi Lance,
>
> Yes, this is exactly the point where the problem is in JDK code. It's
> directly
> related to the zip entry beyond max int offset. The code tries to read data
> from a local zip entry header at locoff, here:
>
> if (zipfs.readFullyAt(buf, 0, buf.length , locoff)
>
> but the locoff is set to ~0 as per the spec for files exceeding
> 4 gigabytes, which says:
>
>   4.4.16 relative offset of local header: (4 bytes)
>
>       This is the offset from the start of the first disk on
>       which this file appears, to where the local header SHOULD
>       be found.  If an archive is in ZIP64 format and the value
>       in this field is 0xFFFFFFFF, the size will be in the
>       corresponding 8 byte zip64 extended information extra field.
>
> A proper fix would be to read the local header from zip64 extra data
> first. I don't know how this interferes with the rest of the code though -
> didn't have enough time to look at it. As it stands, zip entries
> beyond 4GB cause
> an unchecked exception while attribute-scanning. This simple snippet
> is enough to demonstrate it, given a ZIP entry beyond 4GB range:
>
> try (FileSystem fs =
> FileSystems.newFileSystem(Paths.get("zipWithEntryBeyond4Gb.zip"))) {
>  for (Path root : fs.getRootDirectories()) {
>    Files.walkFileTree(root, new SimpleFileVisitor<>() {
>      @Override
>      public FileVisitResult visitFile(Path file, BasicFileAttributes
> attrs) throws IOException {
>        return FileVisitResult.CONTINUE;
>      }
>    });
>  }
> }
>
> The walkFileTree method is key here as it attempts to harvest
> attributes (why we use it is another story -- this saves a lot of time
> on large, network-mounted regular directories when you're collecting
> file metadata).
>
>
> Dawid
>
>
> On Wed, Oct 21, 2020 at 6:39 PM Lance Andersen
> <LANCE.ANDERSEN at oracle.com> wrote:
>
>
> Hi David,
>
> From  a quick look at ZipFileSystem this appears to be an optimization to
> avoid looking at the LOC extended Timestamp Extra field
>
> If a Info-ZIP Extended Timestamp (0x5455)is found then:
>
>  If the "zipinfo-time" entry was set  to ?false? in the Map specified when
> creating the Zip FileSystem,
>
> FileSystems.newFileSystem(zipFile, Map.of("zipinfo-time", "false")
>
> and the  data size of the CEN extended Timestamp is 5 (flag + mod time)
>
> The modified time is used from the CEN Extended Timestamp extra field
>
> Otherwise get the modified time, creation time, and access time from the
> LOC Extended Timestamp extra field.
>
>
> ?????
>
> Extended Timestamp Extra Field:
>
>          ==============================
>
>          The following is the layout of the extended-timestamp extra block.
>          (Last Revision 19970118)
>
>          Local-header version:
>
>          Value         Size        Description
>          -----         ----        -----------
>  (time)  0x5455        Short       tag for this extra block type ("UT")
>          TSize         Short       total data size for this block
>          Flags         Byte        info bits
>          (ModTime)     Long        time of last modification (UTC/GMT)
>          (AcTime)      Long        time of last access (UTC/GMT)
>          (CrTime)      Long        time of original creation (UTC/GMT)
>
>          Central-header version:
>
>          Value         Size        Description
>          -----         ----        -----------
>  (time)  0x5455        Short       tag for this extra block type ("UT")
>          TSize         Short       total data size for this block
>          Flags         Byte        info bits (refers to local header!)
>          (ModTime)     Long        time of last modification (UTC/GMT)
>
>          The central-header extra field contains the modification time
> only,
>          or no timestamp at all.  TSize is used to flag its presence or
>          absence.  But note:
>
>              If "Flags" indicates that Modtime is present in the local
> header
>              field, it MUST be present in the central header field, too!
>              This correspondence is required because the modification time
>              value may be used to support trans-timezone freshening and
>              updating operations with zip archives.
>
>          The time values are in standard Unix signed-long format,
> indicating
>          the number of seconds since 1 January 1970 00:00:00.  The times
>          are relative to Coordinated Universal Time (UTC), also sometimes
>          referred to as Greenwich Mean Time (GMT).  To convert to local
> time,
>          the software must know the local timezone offset from UTC/GMT.
>
>          The lower three bits of Flags in both headers indicate which time-
>          stamps are present in the LOCAL extra field:
>
>                bit 0           if set, modification time is present
>                bit 1           if set, access time is present
>                bit 2           if set, creation time is present
>                bits 3-7        reserved for additional timestamps; not set
>
>          Those times that are present will appear in the order indicated,
> but
>          any combination of times may be omitted.  (Creation time may be
>          present without access time, for example.)  TSize should equal
>          (1 + 4*(number of set bits in Flags)), as the block is currently
>          defined.  Other timestamps may be added in the future.
>
>
> --------------
>
> It's hard to comment on why you received the error that you did but it is
> possible the tool that was used for writing the entry  did something
> unexpected.
>
> Out of curiosity, have you tried using ZipFile/ZipEntry to access the
> entry?
>
>
> Best,
> Lance
>
>
> On Oct 21, 2020, at 4:55 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
>
> Hello,
>
> We've encountered a seemingly valid ZIP file (zipinfo -v shows all its
> entries are intact) that causes a runtime exception when scanning its
> contents with ZipFileSystem. The exception indicates an invalid
> signature when parsing EXTID_EXTT. I don't quite understand this
> comment in the code:
>
> case EXTID_EXTT:
>   // spec says the Extened timestamp in cen only has mtime
>   // need to read the loc to get the extra a/ctime, if flag
>   // "zipinfo-time" is not specified to false;
>   // there is performance cost (move up to loc and read) to
>   // access the loc table foreach entry;
>   if (zipfs.noExtt) {
>       if (sz == 5)
>           mtime = unixToJavaTime(LG(extra, pos + 1));
>        break;
>   }
> ...
>
> but this ZIP file has the extra data block of exactly 5 bytes, as
> indicated by zipinfo:
>
> Central directory entry #6:
> ---------------------------
> ...
> file system or operating system of origin:      Unix
> version of encoding software:                   3.0
> minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
> minimum software version required to extract:   2.0
> compression method:                             deflated
> ...
> extended local header:                          no
> file last modified on (DOS date/time):          2018 Mar 1 04:56:20
> file last modified on (UT extra field modtime): 2018 Mar 1 05:56:19 local
> file last modified on (UT extra field modtime): 2018 Mar 1 04:56:19 UTC
> ...
> Unix file attributes (100000 octal):            ----------
> MS-DOS file attributes (01 hex):                read-only
>
> The central-directory extra field contains:
> - A subfield with ID 0x5455 (universal time) and 5 data bytes.
>   The local extra field has UTC/GMT modification/access times.
>
> The above conditional block checking for length == 5 would have worked
> in ZipFileSystem but it's surrounded by a condition over an
> externally-provided property - zipfs.noExtt is only set to true if:
>
> this.noExtt = "false".equals(env.get("zipinfo-time"));
>
> I can't share this particular ZIP file with you and I don't know how
> it was created but it seems like that "zipinfo-time" flag could be
> omitted if the length of the extra data field is exactly 5?
>
> Dawid
>
>
>
> Best
> Lance
> ------------------
>
>
>
> 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
>
>
>
>
>
>
> Best
> Lance
> ------------------
>
>
>
> 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
>
>
>
>
>

From github.com+10835776+stsypanov at openjdk.java.net  Sat Nov 28 15:06:59 2020
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, 28 Nov 2020 15:06:59 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v3]
In-Reply-To: <UHKiLiCTk7rxbAwrDCraS8NHJQdZQOUvPFcXB7q-VFQ=.c75111cb-7c17-45b0-9955-b38e04ac6c30@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
 <lR8p1rPo3hY4aZkiB_NPzBkDMhienlbQ5DXEJGq-PMo=.659157be-4bcb-4bd0-ac91-cb1a3234cb43@github.com>
 <UHKiLiCTk7rxbAwrDCraS8NHJQdZQOUvPFcXB7q-VFQ=.c75111cb-7c17-45b0-9955-b38e04ac6c30@github.com>
Message-ID: <EOhMjnyav5PBKpzUdJmscjCo28H_7SmZBUqXSWEYIzA=.33603fb2-a6bf-4c22-9b12-3e3a153d23ac@github.com>

On Fri, 27 Nov 2020 21:04:59 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 four additional commits since the last revision:
>> 
>>  - 8254082: Consolidate putStringAt() methods
>>  - Merge branch 'master' into asb
>>  - Merge branch 'master' into asb
>>  - 8254082: Add fast-path for String into AbstractStringBuilder.insert(int, CharSequence, int, int)
>
> src/java.base/share/classes/java/lang/String.java line 3620:
> 
>> 3618:     void getBytes(byte[] dst, int srcPos, int dstBegin, byte coder, int length) {
>> 3619:         if (coder() == coder) {
>> 3620:             System.arraycopy(value, srcPos, dst, dstBegin << coder, length);
> 
> Would it be more consistent and easier to follow if we took the length in chars, not in bytes, and adjusted it here with the coder? JITs should do short work of the need to adjust by calling `length()` in `getBytes(byte[], int, byte)` above.
> 
> If we're worried about unexpected performance effects we can separate these two `getBytes` methods to independent methods rather than delegate from one to the other.

Done!

-------------

PR: https://git.openjdk.java.net/jdk/pull/402

From github.com+10835776+stsypanov at openjdk.java.net  Sat Nov 28 15:10:55 2020
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, 28 Nov 2020 15:10:55 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v4]
In-Reply-To: <Zl-X8ZppSpbKzFC8F4V8XTlxG9Xsw_X4LgaOACHEARg=.6e2774fe-ae99-441b-a850-927e7a5d4ce6@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
 <RTZpi5rl2_r1SJlnRC7RqTgBmw6ucHO9Wj7rUlfVb7w=.4409927c-65a4-49c9-b871-d9b98e07a240@github.com>
 <Zl-X8ZppSpbKzFC8F4V8XTlxG9Xsw_X4LgaOACHEARg=.6e2774fe-ae99-441b-a850-927e7a5d4ce6@github.com>
Message-ID: <L56d0HDh5VQAWKwmXPNOMYfZESO6YE_GZ9fP68jzNuU=.db58afcb-0b62-4ae9-b629-967e9b80e60b@github.com>

On Sat, 28 Nov 2020 14:10:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8254082: Consolidate putStringAt() methods: make length represent char count
>
> Looks good to me. 
> 
> Theoretically the refactored `getBytes(byte[], int, byte)` should have no cost, but could cause some issues in some microbenchmarks that touches this. You mentioned this was used by StringConcatHelper, so could you run the org.openjdk.bench.java.lang.StringConcat micros to check that there are no regressions?

@cl4es Could you tell me where can I look for a command to run the benchmark?

-------------

PR: https://git.openjdk.java.net/jdk/pull/402

From LANCE.ANDERSEN at ORACLE.COM  Sat Nov 28 15:32:05 2020
From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen)
Date: Sat, 28 Nov 2020 10:32:05 -0500
Subject: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data
 field of exactly 5 bytes)
In-Reply-To: <CAM21Rt_3pVbOnn5wqt=hSTUALLMUyM2ERsd0x4f7J0NjMt8+Zg@mail.gmail.com>
References: <CAM21Rt8KeWyQvjE7-5pfyXYJXO3yGgGfKpBtueOV8qgNFMa+jQ@mail.gmail.com>
 <17F644E3-E5E0-403E-B568-FCB89C8BD9BB@ORACLE.COM>
 <CAM21Rt-ANpHbDO-kjSHguDzSTGS-WhGwHsbxcHav1wFVvDQ2EQ@mail.gmail.com>
 <CAM21Rt_8WWsTm-DrY=stscEuiWXF1-JJkv83wZoReJB7ZD-Kjw@mail.gmail.com>
 <CAM21Rt9tHhGf7+eKfrrLbPwP8jShZytF6Qh_3OS4yxVg=02hWQ@mail.gmail.com>
 <DB63C62D-0D4C-42F4-8C7A-D732DFB8FB0C@ORACLE.COM>
 <CAM21Rt_3pVbOnn5wqt=hSTUALLMUyM2ERsd0x4f7J0NjMt8+Zg@mail.gmail.com>
Message-ID: <4E5D6A9D-4F31-4EA8-9869-8A3F4944780D@ORACLE.COM>

Hi Dawid,

Thank you for the follow up.

> On Nov 28, 2020, at 9:34 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
> 
> 
> I know what the problem is and I know what the fix should be (and tried to convey it) but I don't have a patch.

Given you believe you know what the fix would be,  it would be great to create a patch for ZipFileSystem and see if it addresses the issue and then contribute the fix back to the OpenJDK community :-).


> Writing the test case is not a problem but it'll be a lengthy test on slower drives (has to create a zip file that exceeds 4gb of disk space).

The test case would be configured as a manual test and would look similar to test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java <https://github.com/openjdk/jdk/pull/987#diff-73b401685399c9d59851cda49e9c0d377093086119555708253c8df99649e3c9> which also creates a 4GB zip.

> I don't think there is a way to fake the file system by using a sparse file, sadly. Would this be acceptable? If so then sure - I can provide a reproducible test case that will fail for the current implementation.

The above test runs in a reasonable time so I would expect this test case would as well.

I will look to reproduce the issue over the weekend or early next week and log a bug with what you provided in your earlier email.


Best
Lance
> 
> D.
> 
> On Fri, Nov 27, 2020 at 8:37 PM Lance Andersen <LANCE.ANDERSEN at oracle.com <mailto:LANCE.ANDERSEN at oracle.com>> wrote:
> Hi Dawid,
> 
> If you believe you have a a fix, please submit a patch along with a JTREG test case.  Ideally the test case would create zip file as part of the test.
> 
> Best
> Lance
> 
>> On Nov 27, 2020, at 7:37 AM, Dawid Weiss <dawid.weiss at gmail.com <mailto:dawid.weiss at gmail.com>> wrote:
>> 
>> Just for the archives - I'm not sure if this ended up being filed to
>> the bug system - the repro below demonstrates the bug on all JDKs up
>> to the newest one.
>> 
>> # create a single random file of 250 megabytes
>> head -c 250M < /dev/urandom > rnd.bin
>> # create a bunch of hardlinks to the same file.
>> for i in `seq -w 1 25`; do ln rnd.bin rnd-$i.bin; done
>> # create a zip archive exceeding 4gb (in stored mode so that it's faster)
>> zip -0 archive.zip rnd*.bin
>> # show the content of the archive - for all entries beyond 4gb this should
>> # show extra data blocks like below (note the order of extra data
>> blocks - this is important).
>> #
>> #  The central-directory extra field contains:
>> # - A subfield with ID 0x5455 (universal time) and 5 data bytes.
>> #   The local extra field has UTC/GMT modification/access times.
>> # - A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
>> #   01 04 ea 03 00 00 04 ea 03 00 00.
>> # - A subfield with ID 0x0001 (PKWARE 64-bit sizes) and 8 data bytes:
>> #  a4 06 a0 86 01 00 00 00.
>> #
>> zipinfo -v archive.zip
>> 
>> # Bug repro code:
>> cat > Test.java <<EOF
>> import java.io <https://urldefense.com/v3/__http://java.io__;!!GqivPVa7Brio!KhvWnawkon4E5sVeCpHmwDPJusjNPLMtqPh-ZBleD-U4Dv6tmWKB3cq3sT68yelqdA$>.*;
>> import java.nio.*;
>> import java.nio.file.*;
>> import java.nio.file.attribute.*;
>> 
>> public class Test {
>>  public static void main(String[]args) throws IOException {
>>    try (FileSystem fs = FileSystems.newFileSystem(Paths.get("archive.zip"))) {
>>      for (Path root : fs.getRootDirectories()) {
>>        Files.walkFileTree(root, new SimpleFileVisitor<>() {
>>          public FileVisitResult visitFile(Path file,
>> BasicFileAttributes attrs) throws IOException {
>>            return FileVisitResult.CONTINUE;
>>          }
>>        });
>>      }
>>    }
>>  }
>> }
>> EOF
>> # and run it.
>> java Test.java
>> 
>> The above ends with:
>> 
>> Exception in thread "main" java.util.zip.ZipException: loc: wrong sig ->841cd111
>>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readExtra(ZipFileSystem.java:2899)
>>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readCEN(ZipFileSystem.java:2600)
>>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.<init>(ZipFileSystem.java:2536)
>>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.getFileAttributes(ZipFileSystem.java:532)
>>        at jdk.zipfs/jdk.nio.zipfs.ZipPath.readAttributes(ZipPath.java:767)
>>        at jdk.zipfs/jdk.nio.zipfs.ZipPath.readAttributes(ZipPath.java:777)
>>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.readAttributes(ZipFileSystemProvider.java:276)
>>        at java.base/java.nio.file.Files.readAttributes(Files.java:1843)
>>        at java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:219)
>>        at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:276)
>>        at java.base/java.nio.file.FileTreeWalker.next(FileTreeWalker.java:373)
>>        at java.base/java.nio.file.Files.walkFileTree(Files.java:2840)
>>        at java.base/java.nio.file.Files.walkFileTree(Files.java:2876)
>>        at Test.main(Test.java:10)
>> 
>> The fix is relatively simple I think - the current code assumes entry
>> offset is < 4GB when parsing extra data for
>> ID 0x5455. This should be evaluated lazily after all extra data blocks
>> are parsed to ensure the file offset is correctly
>> updated based on block ID 0x0001, regardless of its ordering within
>> other extra data blocks.
>> 
>> 
>> 
>> On Fri, Oct 23, 2020 at 9:12 AM Dawid Weiss <dawid.weiss at gmail.com <mailto:dawid.weiss at gmail.com>> wrote:
>>> 
>>> 
>>> This looks like a legitimate bug to me (the zip file system implementation is sensitive to the order of extra parameters and may throw an unexpected error
>>> on zip64 archives exceeding 4 gigabytes). I can't file a Jira issue - no permissions - but I think it'd be worth adding one?
>>> 
>>> Dawid
>>> 
>>> On Wed, Oct 21, 2020 at 8:36 PM Dawid Weiss <dawid.weiss at gmail.com <mailto:dawid.weiss at gmail.com>> wrote:
>>>> 
>>>> Hi Lance,
>>>> 
>>>> Yes, this is exactly the point where the problem is in JDK code. It's directly
>>>> related to the zip entry beyond max int offset. The code tries to read data
>>>> from a local zip entry header at locoff, here:
>>>> 
>>>> if (zipfs.readFullyAt(buf, 0, buf.length , locoff)
>>>> 
>>>> but the locoff is set to ~0 as per the spec for files exceeding
>>>> 4 gigabytes, which says:
>>>> 
>>>>   4.4.16 relative offset of local header: (4 bytes)
>>>> 
>>>>       This is the offset from the start of the first disk on
>>>>       which this file appears, to where the local header SHOULD
>>>>       be found.  If an archive is in ZIP64 format and the value
>>>>       in this field is 0xFFFFFFFF, the size will be in the
>>>>       corresponding 8 byte zip64 extended information extra field.
>>>> 
>>>> A proper fix would be to read the local header from zip64 extra data
>>>> first. I don't know how this interferes with the rest of the code though -
>>>> didn't have enough time to look at it. As it stands, zip entries
>>>> beyond 4GB cause
>>>> an unchecked exception while attribute-scanning. This simple snippet
>>>> is enough to demonstrate it, given a ZIP entry beyond 4GB range:
>>>> 
>>>> try (FileSystem fs =
>>>> FileSystems.newFileSystem(Paths.get("zipWithEntryBeyond4Gb.zip"))) {
>>>>  for (Path root : fs.getRootDirectories()) {
>>>>    Files.walkFileTree(root, new SimpleFileVisitor<>() {
>>>>      @Override
>>>>      public FileVisitResult visitFile(Path file, BasicFileAttributes
>>>> attrs) throws IOException {
>>>>        return FileVisitResult.CONTINUE;
>>>>      }
>>>>    });
>>>>  }
>>>> }
>>>> 
>>>> The walkFileTree method is key here as it attempts to harvest
>>>> attributes (why we use it is another story -- this saves a lot of time
>>>> on large, network-mounted regular directories when you're collecting
>>>> file metadata).
>>>> 
>>>> 
>>>> Dawid
>>>> 
>>>> 
>>>> On Wed, Oct 21, 2020 at 6:39 PM Lance Andersen
>>>> <LANCE.ANDERSEN at oracle.com <mailto:LANCE.ANDERSEN at oracle.com>> wrote:
>>>>> 
>>>>> Hi David,
>>>>> 
>>>>> From  a quick look at ZipFileSystem this appears to be an optimization to avoid looking at the LOC extended Timestamp Extra field
>>>>> 
>>>>> If a Info-ZIP Extended Timestamp (0x5455)is found then:
>>>>> 
>>>>>  If the "zipinfo-time" entry was set  to ?false? in the Map specified when creating the Zip FileSystem,
>>>>> 
>>>>> FileSystems.newFileSystem(zipFile, Map.of("zipinfo-time", "false")
>>>>> 
>>>>> and the  data size of the CEN extended Timestamp is 5 (flag + mod time)
>>>>> 
>>>>> The modified time is used from the CEN Extended Timestamp extra field
>>>>> 
>>>>> Otherwise get the modified time, creation time, and access time from the LOC Extended Timestamp extra field.
>>>>> 
>>>>> 
>>>>> ?????
>>>>> 
>>>>> Extended Timestamp Extra Field:
>>>>> 
>>>>>          ==============================
>>>>> 
>>>>>          The following is the layout of the extended-timestamp extra block.
>>>>>          (Last Revision 19970118)
>>>>> 
>>>>>          Local-header version:
>>>>> 
>>>>>          Value         Size        Description
>>>>>          -----         ----        -----------
>>>>>  (time)  0x5455        Short       tag for this extra block type ("UT")
>>>>>          TSize         Short       total data size for this block
>>>>>          Flags         Byte        info bits
>>>>>          (ModTime)     Long        time of last modification (UTC/GMT)
>>>>>          (AcTime)      Long        time of last access (UTC/GMT)
>>>>>          (CrTime)      Long        time of original creation (UTC/GMT)
>>>>> 
>>>>>          Central-header version:
>>>>> 
>>>>>          Value         Size        Description
>>>>>          -----         ----        -----------
>>>>>  (time)  0x5455        Short       tag for this extra block type ("UT")
>>>>>          TSize         Short       total data size for this block
>>>>>          Flags         Byte        info bits (refers to local header!)
>>>>>          (ModTime)     Long        time of last modification (UTC/GMT)
>>>>> 
>>>>>          The central-header extra field contains the modification time only,
>>>>>          or no timestamp at all.  TSize is used to flag its presence or
>>>>>          absence.  But note:
>>>>> 
>>>>>              If "Flags" indicates that Modtime is present in the local header
>>>>>              field, it MUST be present in the central header field, too!
>>>>>              This correspondence is required because the modification time
>>>>>              value may be used to support trans-timezone freshening and
>>>>>              updating operations with zip archives.
>>>>> 
>>>>>          The time values are in standard Unix signed-long format, indicating
>>>>>          the number of seconds since 1 January 1970 00:00:00.  The times
>>>>>          are relative to Coordinated Universal Time (UTC), also sometimes
>>>>>          referred to as Greenwich Mean Time (GMT).  To convert to local time,
>>>>>          the software must know the local timezone offset from UTC/GMT.
>>>>> 
>>>>>          The lower three bits of Flags in both headers indicate which time-
>>>>>          stamps are present in the LOCAL extra field:
>>>>> 
>>>>>                bit 0           if set, modification time is present
>>>>>                bit 1           if set, access time is present
>>>>>                bit 2           if set, creation time is present
>>>>>                bits 3-7        reserved for additional timestamps; not set
>>>>> 
>>>>>          Those times that are present will appear in the order indicated, but
>>>>>          any combination of times may be omitted.  (Creation time may be
>>>>>          present without access time, for example.)  TSize should equal
>>>>>          (1 + 4*(number of set bits in Flags)), as the block is currently
>>>>>          defined.  Other timestamps may be added in the future.
>>>>> 
>>>>> 
>>>>> --------------
>>>>> 
>>>>> It's hard to comment on why you received the error that you did but it is possible the tool that was used for writing the entry  did something unexpected.
>>>>> 
>>>>> Out of curiosity, have you tried using ZipFile/ZipEntry to access the entry?
>>>>> 
>>>>> 
>>>>> Best,
>>>>> Lance
>>>>> 
>>>>> 
>>>>> On Oct 21, 2020, at 4:55 AM, Dawid Weiss <dawid.weiss at gmail.com <mailto:dawid.weiss at gmail.com>> wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> We've encountered a seemingly valid ZIP file (zipinfo -v shows all its
>>>>> entries are intact) that causes a runtime exception when scanning its
>>>>> contents with ZipFileSystem. The exception indicates an invalid
>>>>> signature when parsing EXTID_EXTT. I don't quite understand this
>>>>> comment in the code:
>>>>> 
>>>>> case EXTID_EXTT:
>>>>>   // spec says the Extened timestamp in cen only has mtime
>>>>>   // need to read the loc to get the extra a/ctime, if flag
>>>>>   // "zipinfo-time" is not specified to false;
>>>>>   // there is performance cost (move up to loc and read) to
>>>>>   // access the loc table foreach entry;
>>>>>   if (zipfs.noExtt) {
>>>>>       if (sz == 5)
>>>>>           mtime = unixToJavaTime(LG(extra, pos + 1));
>>>>>        break;
>>>>>   }
>>>>> ...
>>>>> 
>>>>> but this ZIP file has the extra data block of exactly 5 bytes, as
>>>>> indicated by zipinfo:
>>>>> 
>>>>> Central directory entry #6:
>>>>> ---------------------------
>>>>> ...
>>>>> file system or operating system of origin:      Unix
>>>>> version of encoding software:                   3.0
>>>>> minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
>>>>> minimum software version required to extract:   2.0
>>>>> compression method:                             deflated
>>>>> ...
>>>>> extended local header:                          no
>>>>> file last modified on (DOS date/time):          2018 Mar 1 04:56:20
>>>>> file last modified on (UT extra field modtime): 2018 Mar 1 05:56:19 local
>>>>> file last modified on (UT extra field modtime): 2018 Mar 1 04:56:19 UTC
>>>>> ...
>>>>> Unix file attributes (100000 octal):            ----------
>>>>> MS-DOS file attributes (01 hex):                read-only
>>>>> 
>>>>> The central-directory extra field contains:
>>>>> - A subfield with ID 0x5455 (universal time) and 5 data bytes.
>>>>>   The local extra field has UTC/GMT modification/access times.
>>>>> 
>>>>> The above conditional block checking for length == 5 would have worked
>>>>> in ZipFileSystem but it's surrounded by a condition over an
>>>>> externally-provided property - zipfs.noExtt is only set to true if:
>>>>> 
>>>>> this.noExtt = "false".equals(env.get("zipinfo-time"));
>>>>> 
>>>>> I can't share this particular ZIP file with you and I don't know how
>>>>> it was created but it seems like that "zipinfo-time" flag could be
>>>>> omitted if the length of the extra data field is exactly 5?
>>>>> 
>>>>> Dawid
>>>>> 
>>>>> 
>>>>> 
>>>>> Best
>>>>> Lance
>>>>> ------------------
>>>>> 
>>>>> 
>>>>> 
>>>>> 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>
>>>>> 
>>>>> 
>>>>> 
>>>>> 
> 
> 
> Best
> Lance
> ------------------
> 
> <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>

Best
Lance
------------------




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





From redestad at openjdk.java.net  Sat Nov 28 21:47:55 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sat, 28 Nov 2020 21:47:55 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v4]
In-Reply-To: <Zl-X8ZppSpbKzFC8F4V8XTlxG9Xsw_X4LgaOACHEARg=.6e2774fe-ae99-441b-a850-927e7a5d4ce6@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
 <RTZpi5rl2_r1SJlnRC7RqTgBmw6ucHO9Wj7rUlfVb7w=.4409927c-65a4-49c9-b871-d9b98e07a240@github.com>
 <Zl-X8ZppSpbKzFC8F4V8XTlxG9Xsw_X4LgaOACHEARg=.6e2774fe-ae99-441b-a850-927e7a5d4ce6@github.com>
Message-ID: <srFZntIzmB70nVCsWs-EojxUkMA7rIY0emSctczujM8=.5c848b57-4c53-4846-ac2a-e5ed8d8df1a6@github.com>

On Sat, 28 Nov 2020 14:10:10 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8254082: Consolidate putStringAt() methods: make length represent char count
>
> Looks good to me. 
> 
> Theoretically the refactored `getBytes(byte[], int, byte)` should have no cost, but could cause some issues in some microbenchmarks that touches this. You mentioned this was used by StringConcatHelper, so could you run the org.openjdk.bench.java.lang.StringConcat micros to check that there are no regressions?

> @cl4es Could you tell me where I can look for a command to run the benchmark?

See [doc/testing.md](https://github.com/openjdk/jdk/blob/master/doc/testing.md). The [configuration](https://github.com/openjdk/jdk/blob/master/doc/testing.md#configuration) section has a pointer on how to set up and configure the JDK build with JMH, then it should be a simple matter of running `make test TEST=micro:org.openjdk.bench.java.lang.StringConcat`.

-------------

PR: https://git.openjdk.java.net/jdk/pull/402

From github.com+10835776+stsypanov at openjdk.java.net  Sat Nov 28 22:07:54 2020
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, 28 Nov 2020 22:07:54 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v4]
In-Reply-To: <srFZntIzmB70nVCsWs-EojxUkMA7rIY0emSctczujM8=.5c848b57-4c53-4846-ac2a-e5ed8d8df1a6@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
 <RTZpi5rl2_r1SJlnRC7RqTgBmw6ucHO9Wj7rUlfVb7w=.4409927c-65a4-49c9-b871-d9b98e07a240@github.com>
 <Zl-X8ZppSpbKzFC8F4V8XTlxG9Xsw_X4LgaOACHEARg=.6e2774fe-ae99-441b-a850-927e7a5d4ce6@github.com>
 <srFZntIzmB70nVCsWs-EojxUkMA7rIY0emSctczujM8=.5c848b57-4c53-4846-ac2a-e5ed8d8df1a6@github.com>
Message-ID: <BffbV5_PkybRuc4mdcUn0YoZZvraPiKYTbVF7e_vEMA=.0499ced1-9a46-4c12-9134-a14b31794840@github.com>

On Sat, 28 Nov 2020 21:45:25 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Looks good to me. 
>> 
>> Theoretically the refactored `getBytes(byte[], int, byte)` should have no cost, but could cause some issues in some microbenchmarks that touches this. You mentioned this was used by StringConcatHelper, so could you run the org.openjdk.bench.java.lang.StringConcat micros to check that there are no regressions?
>
>> @cl4es Could you tell me where I can look for a command to run the benchmark?
> 
> See [doc/testing.md](https://github.com/openjdk/jdk/blob/master/doc/testing.md). The [configuration](https://github.com/openjdk/jdk/blob/master/doc/testing.md#configuration) section has a pointer on how to set up and configure the JDK build with JMH, then it should be a simple matter of running `make test TEST=micro:org.openjdk.bench.java.lang.StringConcat`.

Here are the results, looks like we have no regression:
Benchmark                               (intValue)  Mode  Cnt         original           patched  Units  Units
StringConcat.concat4String                    4711  avgt   15   27.267 ? 1.231    29.938 ? 1.099  ns/op  ns/op
StringConcat.concat6String                    4711  avgt   15   39.185 ? 1.604    42.759 ? 2.564  ns/op  ns/op
StringConcat.concatConst2String               4711  avgt   15   22.345 ? 1.685    21.913 ? 1.716  ns/op  ns/op
StringConcat.concatConst4String               4711  avgt   15   32.318 ? 4.073    32.847 ? 1.082  ns/op  ns/op
StringConcat.concatConst6Object               4711  avgt   15    9.227 ? 0.146     9.999 ? 0.939  ns/op  ns/op
StringConcat.concatConst6String               4711  avgt   15   46.134 ? 2.729    44.903 ? 1.960  ns/op  ns/op
StringConcat.concatConstBoolByte              4711  avgt   15   13.117 ? 0.725    12.575 ? 0.380  ns/op  ns/op
StringConcat.concatConstInt                   4711  avgt   15   12.230 ? 0.653    11.890 ? 0.556  ns/op  ns/op
StringConcat.concatConstIntConstInt           4711  avgt   15   18.152 ? 1.317    17.722 ? 0.566  ns/op  ns/op
StringConcat.concatConstString                4711  avgt   15   12.644 ? 0.656    13.424 ? 1.400  ns/op  ns/op
StringConcat.concatConstStringConstInt        4711  avgt   15   20.836 ? 0.703    19.975 ? 0.821  ns/op  ns/op
StringConcat.concatEmptyConstInt              4711  avgt   15   10.604 ? 0.443    10.229 ? 0.219  ns/op  ns/op
StringConcat.concatEmptyConstString           4711  avgt   15    4.844 ? 0.174     4.721 ? 0.147  ns/op  ns/op
StringConcat.concatEmptyLeft                  4711  avgt   15    5.386 ? 0.190     5.314 ? 0.104  ns/op  ns/op
StringConcat.concatEmptyRight                 4711  avgt   15    5.352 ? 0.471     5.484 ? 0.354  ns/op  ns/op
StringConcat.concatMethodConstString          4711  avgt   15   11.887 ? 0.560    14.025 ? 1.522  ns/op  ns/op
StringConcat.concatMix4String                 4711  avgt   15  172.425 ? 6.868   169.658 ? 8.440  ns/op  ns/op

-------------

PR: https://git.openjdk.java.net/jdk/pull/402

From kvn at openjdk.java.net  Sat Nov 28 23:30:13 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sat, 28 Nov 2020 23:30:13 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo [v3]
In-Reply-To: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
Message-ID: <amcTT5-ov4DA74W4AXS1ouaeqzyM8kBT3a8irogNkcQ=.e5a52b6a-29a1-44d9-9466-1a5713aaf7be@github.com>

> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
> 
> Initial patch was prepared by @fisk.
> 
> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
> 
> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.

Vladimir Kozlov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-8256999
 - Merge branch 'master' into JDK-8256999
 - Added ZLoadBarrierElided = 0 definition.
   Removed is_exact argument in load_field_from_object().
   Added Shenandoah support for narrow phantom accesses.
 - 8256999: Add C2 intrinsic for Reference.refersTo and PhantomReference::refersTo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1425/files
  - new: https://git.openjdk.java.net/jdk/pull/1425/files/08bdd307..962d54d5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1425&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1425&range=01-02

  Stats: 5258 lines in 151 files changed: 2571 ins; 1881 del; 806 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1425/head:pull/1425

PR: https://git.openjdk.java.net/jdk/pull/1425

From redestad at openjdk.java.net  Sun Nov 29 01:23:56 2020
From: redestad at openjdk.java.net (Claes Redestad)
Date: Sun, 29 Nov 2020 01:23:56 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v4]
In-Reply-To: <BffbV5_PkybRuc4mdcUn0YoZZvraPiKYTbVF7e_vEMA=.0499ced1-9a46-4c12-9134-a14b31794840@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
 <RTZpi5rl2_r1SJlnRC7RqTgBmw6ucHO9Wj7rUlfVb7w=.4409927c-65a4-49c9-b871-d9b98e07a240@github.com>
 <Zl-X8ZppSpbKzFC8F4V8XTlxG9Xsw_X4LgaOACHEARg=.6e2774fe-ae99-441b-a850-927e7a5d4ce6@github.com>
 <srFZntIzmB70nVCsWs-EojxUkMA7rIY0emSctczujM8=.5c848b57-4c53-4846-ac2a-e5ed8d8df1a6@github.com>
 <BffbV5_PkybRuc4mdcUn0YoZZvraPiKYTbVF7e_vEMA=.0499ced1-9a46-4c12-9134-a14b31794840@github.com>
Message-ID: <KOYy4c1CnUfIU3RK0vgfS16Fuw3tKck-Eviq-rF47jI=.6cf77841-14f2-4633-a078-725112d75ea0@github.com>

On Sat, 28 Nov 2020 22:05:01 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

>>> @cl4es Could you tell me where I can look for a command to run the benchmark?
>> 
>> See [doc/testing.md](https://github.com/openjdk/jdk/blob/master/doc/testing.md). The [configuration](https://github.com/openjdk/jdk/blob/master/doc/testing.md#configuration) section has a pointer on how to set up and configure the JDK build with JMH, then it should be a simple matter of running `make test TEST=micro:org.openjdk.bench.java.lang.StringConcat`.
>
> Here are the results, looks like we have no regression:
> Benchmark                               (intValue)  Mode  Cnt         original           patched  Units  Units
> StringConcat.concat4String                    4711  avgt   15   27.267 ? 1.231    29.938 ? 1.099  ns/op  ns/op
> StringConcat.concat6String                    4711  avgt   15   39.185 ? 1.604    42.759 ? 2.564  ns/op  ns/op
> StringConcat.concatConst2String               4711  avgt   15   22.345 ? 1.685    21.913 ? 1.716  ns/op  ns/op
> StringConcat.concatConst4String               4711  avgt   15   32.318 ? 4.073    32.847 ? 1.082  ns/op  ns/op
> StringConcat.concatConst6Object               4711  avgt   15    9.227 ? 0.146     9.999 ? 0.939  ns/op  ns/op
> StringConcat.concatConst6String               4711  avgt   15   46.134 ? 2.729    44.903 ? 1.960  ns/op  ns/op
> StringConcat.concatConstBoolByte              4711  avgt   15   13.117 ? 0.725    12.575 ? 0.380  ns/op  ns/op
> StringConcat.concatConstInt                   4711  avgt   15   12.230 ? 0.653    11.890 ? 0.556  ns/op  ns/op
> StringConcat.concatConstIntConstInt           4711  avgt   15   18.152 ? 1.317    17.722 ? 0.566  ns/op  ns/op
> StringConcat.concatConstString                4711  avgt   15   12.644 ? 0.656    13.424 ? 1.400  ns/op  ns/op
> StringConcat.concatConstStringConstInt        4711  avgt   15   20.836 ? 0.703    19.975 ? 0.821  ns/op  ns/op
> StringConcat.concatEmptyConstInt              4711  avgt   15   10.604 ? 0.443    10.229 ? 0.219  ns/op  ns/op
> StringConcat.concatEmptyConstString           4711  avgt   15    4.844 ? 0.174     4.721 ? 0.147  ns/op  ns/op
> StringConcat.concatEmptyLeft                  4711  avgt   15    5.386 ? 0.190     5.314 ? 0.104  ns/op  ns/op
> StringConcat.concatEmptyRight                 4711  avgt   15    5.352 ? 0.471     5.484 ? 0.354  ns/op  ns/op
> StringConcat.concatMethodConstString          4711  avgt   15   11.887 ? 0.560    14.025 ? 1.522  ns/op  ns/op
> StringConcat.concatMix4String                 4711  avgt   15  172.425 ? 6.868   169.658 ? 8.440  ns/op  ns/op

Right.

I won't insist but I think some of these could warrant some extra runs and analysis of the disassembly just to make sure. E.g. `concatMethodConstString` and `concat6String` has regression with just barely non-overlapping errors. If these regressions persist it could be due the small difference in the code path (one extra call depth for `getBytes(byte[], int, byte)`) causing some difference in compilation order, inlining decision or otherwise. 

If the regression is real, the paranoid workaround would be to restore `String.getBytes(byte[], int, byte)` and not use delegation. A tiny bit of code duplication might be preferable to a surprise regression in code that has seen a lot of tuning work..

-------------

PR: https://git.openjdk.java.net/jdk/pull/402

From forax at univ-mlv.fr  Sun Nov 29 15:34:14 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Sun, 29 Nov 2020 16:34:14 +0100 (CET)
Subject: Lookup.defineAnonymousClass() vs indy
Message-ID: <1701503144.2305514.1606664054054.JavaMail.zimbra@u-pem.fr>

Hi Mandy, hi all,
it seems that when defineAnonymousClass rewrites the currentClass, it doesn't work if there is an invokedynamic in the classfile, so defineHiddenClass fails with a VerifyError when the hidden class is verified.

Here is an example showing the issue
---
import java.io.IOException;
import java.lang.invoke.MethodHandles;

public class HiddenClassWithIndy {
  public void test() {
    var a = new HiddenClassWithIndy();
    Runnable r = () -> System.out.println(a);
  }

  public static void main(String[] args) throws IOException, IllegalAccessException {
    byte[] bytecode;
    try(var input = HiddenClassWithIndy.class.getClassLoader().getResourceAsStream(HiddenClassWithIndy.class.getName().replace('.', '/') + ".class")) {
      if (input == null) {
        throw new AssertionError();
      }
      bytecode = input.readAllBytes();
    }
    var hiddenLookup = MethodHandles.lookup().defineHiddenClass(bytecode, true);
  }
}

---
The error message:
Exception in thread "main" java.lang.VerifyError: Bad type on operand stack
Exception Details:
  Location:
    fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400.test()V @9: invokedynamic
  Reason:
    Type 'fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400' (current frame, stack[0]) is not assignable to 'fr/umlv/transmogrif/HiddenClassWithIndy'
  Current Frame:
    bci: @9
    flags: { }
    locals: { 'fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400', 'fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400' }
    stack: { 'fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400' }
  Bytecode:
    0000000: bb00 0759 b700 094c 2bba 000a 0000 4db1
    0000010:                                        

	at java.base/java.lang.ClassLoader.defineClass0(Native Method)
	at java.base/java.lang.System$2.defineClass(System.java:2193)
	at java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClass(MethodHandles.java:2235)
	at java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClassAsLookup(MethodHandles.java:2216)
	at java.base/java.lang.invoke.MethodHandles$Lookup.defineHiddenClass(MethodHandles.java:1952)
	at fr.umlv.transmogrif.HiddenClassWithIndy.main(HiddenClassWithIndy.java:20)

regards,
R?mi

From kvn at openjdk.java.net  Sun Nov 29 16:52:15 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sun, 29 Nov 2020 16:52:15 GMT
Subject: RFR: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo [v4]
In-Reply-To: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
Message-ID: <u4S6Ff8wqORs8QXge6dHp9L6gEKjQ5XR7cuycqB-4vc=.e7589b4b-a7aa-4c67-ba98-748405f51500@github.com>

> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
> 
> Initial patch was prepared by @fisk.
> 
> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
> 
> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.

Vladimir Kozlov has updated the pull request with a new target base 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 branch 'master' into JDK-8256999
 - Merge branch 'master' into JDK-8256999
 - Merge branch 'master' into JDK-8256999
 - Added ZLoadBarrierElided = 0 definition.
   Removed is_exact argument in load_field_from_object().
   Added Shenandoah support for narrow phantom accesses.
 - 8256999: Add C2 intrinsic for Reference.refersTo and PhantomReference::refersTo

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1425/files
  - new: https://git.openjdk.java.net/jdk/pull/1425/files/962d54d5..0e4596ce

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1425&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1425&range=02-03

  Stats: 115 lines in 5 files changed: 8 ins; 98 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1425.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1425/head:pull/1425

PR: https://git.openjdk.java.net/jdk/pull/1425

From github.com+10835776+stsypanov at openjdk.java.net  Sun Nov 29 17:33:13 2020
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, 29 Nov 2020 17:33:13 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v5]
In-Reply-To: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
Message-ID: <OS0UkgCSho8t_tA_2QgpWsCAkGfZQBZZS_F56_2JV4A=.421d13c7-f3f5-423e-ada3-a7202081adb4@github.com>

> Original mail: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
> 
> Hello,
> 
> while working with `StringBuilder.insert()` I've spotted that its delegate `AbstractStringBuilder.insert()` is missing
> a fast-path for the most frequent case when its argument is `String`.
> 
> Previously they did similart optimization for `StirngBuilder.append(CharSequence, int, int)`,
> see https://bugs.openjdk.java.net/browse/JDK-8224986
> 
> I'd like to contribute a trivial patch that brings improvement for the case when SB's content is Latin1
> and inserted String is Latin1 as well.
> 
> To measure improvement I've used simple benchmark:
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class StringBuilderInsertBenchmark {
> 
>   @Benchmark
>   public StringBuilder insert(Data data) {
>     String string = data.string;
>     return new StringBuilder().append("ABC").insert(1, string, 1, data.length + 1);
>   }
> 
>   @State(Scope.Thread)
>   public static class Data {
>     String string;
> 
>     @Param({"true", "false"})
>     private boolean latin;
> 
>     @Param({"8", "64", "128", "1024"})
>     private int length;
> 
>     @Setup
>     public void setup() {
>       String alphabet = latin
>         ? "abcdefghijklmnopqrstuvwxyz"        // English
>         : "????????????????????????????????"; // Russian
> 
>       string = new RandomStringGenerator().randomString(alphabet, length + 2);
>     }
>   }
> }
> 
> public final class RandomStringGenerator {
> 
>   public String randomString(String alphabet, int length) {
>     char[] chars = alphabet.toCharArray();
> 
>     ThreadLocalRandom random = ThreadLocalRandom.current();
> 
>     char[] array = new char[length];
>     for (int i = 0; i < length; i++) {
>       array[i] = chars[random.nextInt(chars.length)];
>     }
> 
>     return new String(array);
>   }
> }
> Which gives
> 
>             (latin)  (length)       original       patched    Units
> insert         true         8    24.2 ?  0.1   22.2 ?  0.0    ns/op
> insert         true        64    53.8 ?  0.2   36.1 ?  0.1    ns/op
> insert         true       128    80.9 ?  0.2   44.6 ?  0.0    ns/op
> insert         true      1024   365.4 ?  0.5  109.8 ?  3.9    ns/op
> 
> insert        false         8    33.5 ?  0.5   32.3 ?  0.2    ns/op
> insert        false        64    73.2 ?  0.3   73.2 ?  0.2    ns/op
> insert        false       128   103.9 ?  0.6  103.3 ?  0.1    ns/op
> insert        false      1024   576.5 ?  4.8  569.5 ?  2.0    ns/op
> Patch is attached. As of tests tier1 and tier2 are ok.
> 
> With best regards,
> Sergey Tsypanov

?????? ??????? has updated the pull request with a new target base 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:

 - 8254082: restore String.getBytes(byte[], int, byte)
 - Merge branch 'master' into asb
 - 8254082: Consolidate putStringAt() methods: make length represent char count
 - 8254082: Consolidate putStringAt() methods
 - Merge branch 'master' into asb
 - Merge branch 'master' into asb
 - 8254082: Add fast-path for String into AbstractStringBuilder.insert(int, CharSequence, int, int)

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/402/files
  - new: https://git.openjdk.java.net/jdk/pull/402/files/e515ba64..1a1811bb

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=402&range=04
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=402&range=03-04

  Stats: 4439 lines in 91 files changed: 2028 ins; 1788 del; 623 mod
  Patch: https://git.openjdk.java.net/jdk/pull/402.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/402/head:pull/402

PR: https://git.openjdk.java.net/jdk/pull/402

From github.com+10835776+stsypanov at openjdk.java.net  Sun Nov 29 17:33:14 2020
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, 29 Nov 2020 17:33:14 GMT
Subject: RFR: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String [v4]
In-Reply-To: <KOYy4c1CnUfIU3RK0vgfS16Fuw3tKck-Eviq-rF47jI=.6cf77841-14f2-4633-a078-725112d75ea0@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
 <RTZpi5rl2_r1SJlnRC7RqTgBmw6ucHO9Wj7rUlfVb7w=.4409927c-65a4-49c9-b871-d9b98e07a240@github.com>
 <Zl-X8ZppSpbKzFC8F4V8XTlxG9Xsw_X4LgaOACHEARg=.6e2774fe-ae99-441b-a850-927e7a5d4ce6@github.com>
 <srFZntIzmB70nVCsWs-EojxUkMA7rIY0emSctczujM8=.5c848b57-4c53-4846-ac2a-e5ed8d8df1a6@github.com>
 <BffbV5_PkybRuc4mdcUn0YoZZvraPiKYTbVF7e_vEMA=.0499ced1-9a46-4c12-9134-a14b31794840@github.com>
 <KOYy4c1CnUfIU3RK0vgfS16Fuw3tKck-Eviq-rF47jI=.6cf77841-14f2-4633-a078-725112d75ea0@github.com>
Message-ID: <6i0Aq1WljLIEqXLhM9awNpzjG0IlMit241I8GHGBRnM=.c80c8c4c-e442-49e6-ad93-864f0d71f8f1@github.com>

On Sun, 29 Nov 2020 01:21:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Here are the results, looks like we have no regression:
>> Benchmark                               (intValue)  Mode  Cnt         original           patched  Units  Units
>> StringConcat.concat4String                    4711  avgt   15   27.267 ? 1.231    29.938 ? 1.099  ns/op  ns/op
>> StringConcat.concat6String                    4711  avgt   15   39.185 ? 1.604    42.759 ? 2.564  ns/op  ns/op
>> StringConcat.concatConst2String               4711  avgt   15   22.345 ? 1.685    21.913 ? 1.716  ns/op  ns/op
>> StringConcat.concatConst4String               4711  avgt   15   32.318 ? 4.073    32.847 ? 1.082  ns/op  ns/op
>> StringConcat.concatConst6Object               4711  avgt   15    9.227 ? 0.146     9.999 ? 0.939  ns/op  ns/op
>> StringConcat.concatConst6String               4711  avgt   15   46.134 ? 2.729    44.903 ? 1.960  ns/op  ns/op
>> StringConcat.concatConstBoolByte              4711  avgt   15   13.117 ? 0.725    12.575 ? 0.380  ns/op  ns/op
>> StringConcat.concatConstInt                   4711  avgt   15   12.230 ? 0.653    11.890 ? 0.556  ns/op  ns/op
>> StringConcat.concatConstIntConstInt           4711  avgt   15   18.152 ? 1.317    17.722 ? 0.566  ns/op  ns/op
>> StringConcat.concatConstString                4711  avgt   15   12.644 ? 0.656    13.424 ? 1.400  ns/op  ns/op
>> StringConcat.concatConstStringConstInt        4711  avgt   15   20.836 ? 0.703    19.975 ? 0.821  ns/op  ns/op
>> StringConcat.concatEmptyConstInt              4711  avgt   15   10.604 ? 0.443    10.229 ? 0.219  ns/op  ns/op
>> StringConcat.concatEmptyConstString           4711  avgt   15    4.844 ? 0.174     4.721 ? 0.147  ns/op  ns/op
>> StringConcat.concatEmptyLeft                  4711  avgt   15    5.386 ? 0.190     5.314 ? 0.104  ns/op  ns/op
>> StringConcat.concatEmptyRight                 4711  avgt   15    5.352 ? 0.471     5.484 ? 0.354  ns/op  ns/op
>> StringConcat.concatMethodConstString          4711  avgt   15   11.887 ? 0.560    14.025 ? 1.522  ns/op  ns/op
>> StringConcat.concatMix4String                 4711  avgt   15  172.425 ? 6.868   169.658 ? 8.440  ns/op  ns/op
>
> Right.
> 
> I won't insist but I think some of these could warrant some extra runs and analysis of the disassembly just to make sure. E.g. `concatMethodConstString` and `concat6String` has regression with just barely non-overlapping errors. If these regressions persist it could be due the small difference in the code path (one extra call depth for `getBytes(byte[], int, byte)`) causing some difference in compilation order, inlining decision or otherwise. 
> 
> If the regression is real, the paranoid workaround would be to restore `String.getBytes(byte[], int, byte)` and not use delegation. A tiny bit of code duplication might be preferable to a surprise regression in code that has seen a lot of tuning work..

Looks like you are right: delegation caused tiny regression (I've rerun the benchmark in 10 forks) which is missing from the case with no delegation (third column):
Benchmark                               (intValue)  Mode  Cnt         original          patched     no delegate Units
StringConcat.concat4String                    4711  avgt  100   26.400 ? 0.092   28.278 ? 0.046  26.245 ? 0.045 ns/op
StringConcat.concat6String                    4711  avgt  100   37.846 ? 0.219   40.054 ? 0.150  37.857 ? 0.175 ns/op
StringConcat.concatConst2String               4711  avgt  100   18.732 ? 0.125   19.600 ? 0.153  18.598 ? 0.178 ns/op
StringConcat.concatConst4String               4711  avgt  100   29.303 ? 0.165   31.085 ? 0.086  29.246 ? 0.194 ns/op
StringConcat.concatConst6Object               4711  avgt  100    9.107 ? 0.164    8.948 ? 0.010   8.964 ? 0.059 ns/op
StringConcat.concatConst6String               4711  avgt  100   40.441 ? 0.111   41.037 ? 0.052  40.503 ? 0.352 ns/op
StringConcat.concatConstBoolByte              4711  avgt  100   11.934 ? 0.054   12.173 ? 0.197  11.904 ? 0.026 ns/op
StringConcat.concatConstInt                   4711  avgt  100   10.968 ? 0.024   11.041 ? 0.034  10.956 ? 0.006 ns/op
StringConcat.concatConstIntConstInt           4711  avgt  100   16.853 ? 0.070   16.958 ? 0.064  16.932 ? 0.070 ns/op
StringConcat.concatConstString                4711  avgt  100   11.440 ? 0.113   12.049 ? 0.116  11.485 ? 0.116 ns/op
StringConcat.concatConstStringConstInt        4711  avgt  100   18.205 ? 0.068   18.612 ? 0.043  18.146 ? 0.065 ns/op
StringConcat.concatEmptyConstInt              4711  avgt  100    9.733 ? 0.121    9.742 ? 0.250   9.592 ? 0.011 ns/op
StringConcat.concatEmptyConstString           4711  avgt  100    4.601 ? 0.054    4.589 ? 0.030   4.579 ? 0.023 ns/op
StringConcat.concatEmptyLeft                  4711  avgt  100    5.088 ? 0.031    5.109 ? 0.040   5.119 ? 0.059 ns/op
StringConcat.concatEmptyRight                 4711  avgt  100    4.896 ? 0.038    4.876 ? 0.059   4.844 ? 0.025 ns/op
StringConcat.concatMethodConstString          4711  avgt  100   11.561 ? 0.157   12.126 ? 0.148  11.580 ? 0.162 ns/op
StringConcat.concatMix4String                 4711  avgt  100  156.119 ? 0.675  154.814 ? 0.169 155.655 ? 1.741 ns/op
So I've dropped delegation and restored `String.getBytes(byte[], int, byte)`

-------------

PR: https://git.openjdk.java.net/jdk/pull/402

From kvn at openjdk.java.net  Sun Nov 29 20:31:58 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Sun, 29 Nov 2020 20:31:58 GMT
Subject: Integrated: 8256999: Add C2 intrinsic for Reference.refersTo and
 PhantomReference::refersTo
In-Reply-To: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
References: <lfK3_B12A6FMofYIJXvJ2jWlEEd7LcXV_brCr2yctuk=.42dee9ca-0924-44e8-beda-42bbf3e26535@github.com>
Message-ID: <aiRBEGvI3kLeDEWX6C2uMe-P_F3LpY9ijH0XediyOSA=.0b977e6c-ffbd-47a8-96d1-b678d5a1926d@github.com>

On Wed, 25 Nov 2020 03:31:36 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> JDK-8188055 added the function Reference.refersTo. For performance, the supporting native methods Reference.refersTo0 and PhantomReference.refersTo0 should be intrinsified by C2.
> 
> Initial patch was prepared by @fisk.
> 
> Tested hs-tier1-4. Added new compiler tests to test intrinsics.
> 
> Ran new test with Shenandoah. Found only one issue. As result I disable  PhantomReference::refersTo intrinsic for COOP+ Shenandoah combination. Someone from Shenandoah team have to test changes if that is enough.

This pull request has now been integrated.

Changeset: 816e8f83
Author:    Vladimir Kozlov <kvn at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/816e8f83
Stats:     381 lines in 20 files changed: 248 ins; 62 del; 71 mod

8256999: Add C2 intrinsic for Reference.refersTo and PhantomReference::refersTo

Reviewed-by: pliden, vlivanov, rkennke, eosterlund, shade

-------------

PR: https://git.openjdk.java.net/jdk/pull/1425

From dawid.weiss at gmail.com  Sun Nov 29 22:00:32 2020
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Sun, 29 Nov 2020 23:00:32 +0100
Subject: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data
 field of exactly 5 bytes)
In-Reply-To: <4E5D6A9D-4F31-4EA8-9869-8A3F4944780D@ORACLE.COM>
References: <CAM21Rt8KeWyQvjE7-5pfyXYJXO3yGgGfKpBtueOV8qgNFMa+jQ@mail.gmail.com>
 <17F644E3-E5E0-403E-B568-FCB89C8BD9BB@ORACLE.COM>
 <CAM21Rt-ANpHbDO-kjSHguDzSTGS-WhGwHsbxcHav1wFVvDQ2EQ@mail.gmail.com>
 <CAM21Rt_8WWsTm-DrY=stscEuiWXF1-JJkv83wZoReJB7ZD-Kjw@mail.gmail.com>
 <CAM21Rt9tHhGf7+eKfrrLbPwP8jShZytF6Qh_3OS4yxVg=02hWQ@mail.gmail.com>
 <DB63C62D-0D4C-42F4-8C7A-D732DFB8FB0C@ORACLE.COM>
 <CAM21Rt_3pVbOnn5wqt=hSTUALLMUyM2ERsd0x4f7J0NjMt8+Zg@mail.gmail.com>
 <4E5D6A9D-4F31-4EA8-9869-8A3F4944780D@ORACLE.COM>
Message-ID: <CAM21Rt8h0m-m=jWiYK4LoTYDZuChHHWh_p-acZJaHepK_f0Scw@mail.gmail.com>

Hi Lance,

I looked at the test you pointed to... This is exactly the test for the
problem I originally reported on October 21st... The bug has been filed
for this on October 25th (by you) --
https://bugs.openjdk.java.net/browse/JDK-8255380 and the fix is in commit
6606e0909cbda9. Weird.

I think that test is slightly broken in that it passes "zipinfo-time=false"
-- this is exactly the workaround that makes it work everywhere. The
test should *not* have that flag set?

        try (FileSystem fs =
                     FileSystems.newFileSystem(Paths.get(ZIP_FILE_NAME),
Map.of("zipinfo-time", "False"))) {

Anyway, the problem is fixed. I think it'd be good to backport to LTS
releases too.

Dawid

On Sat, Nov 28, 2020 at 4:32 PM Lance Andersen <LANCE.ANDERSEN at oracle.com>
wrote:

> Hi Dawid,
>
> Thank you for the follow up.
>
> On Nov 28, 2020, at 9:34 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
>
>
> I know what the problem is and I know what the fix should be (and tried to
> convey it) but I don't have a patch.
>
>
> Given you believe you know what the fix would be,  it would be great to
> create a patch for ZipFileSystem and see if it addresses the issue and then
> contribute the fix back to the OpenJDK community :-).
>
>
> Writing the test case is not a problem but it'll be a lengthy test on
> slower drives (has to create a zip file that exceeds 4gb of disk space).
>
>
> The test case would be configured as a manual test and would look similar
> to test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java
> <https://github.com/openjdk/jdk/pull/987#diff-73b401685399c9d59851cda49e9c0d377093086119555708253c8df99649e3c9> which
> also creates a 4GB zip.
>
> I don't think there is a way to fake the file system by using a sparse
> file, sadly. Would this be acceptable? If so then sure - I can provide a
> reproducible test case that will fail for the current implementation.
>
>
> The above test runs in a reasonable time so I would expect this test case
> would as well.
>
> I will look to reproduce the issue over the weekend or early next week and
> log a bug with what you provided in your earlier email.
>
>
> Best
> Lance
>
>
> D.
>
> On Fri, Nov 27, 2020 at 8:37 PM Lance Andersen <LANCE.ANDERSEN at oracle.com>
> wrote:
>
>> Hi Dawid,
>>
>> If you believe you have a a fix, please submit a patch along with a JTREG
>> test case.  Ideally the test case would create zip file as part of the test.
>>
>> Best
>> Lance
>>
>> On Nov 27, 2020, at 7:37 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
>>
>> Just for the archives - I'm not sure if this ended up being filed to
>> the bug system - the repro below demonstrates the bug on all JDKs up
>> to the newest one.
>>
>> # create a single random file of 250 megabytes
>> head -c 250M < /dev/urandom > rnd.bin
>> # create a bunch of hardlinks to the same file.
>> for i in `seq -w 1 25`; do ln rnd.bin rnd-$i.bin; done
>> # create a zip archive exceeding 4gb (in stored mode so that it's faster)
>> zip -0 archive.zip rnd*.bin
>> # show the content of the archive - for all entries beyond 4gb this should
>> # show extra data blocks like below (note the order of extra data
>> blocks - this is important).
>> #
>> #  The central-directory extra field contains:
>> # - A subfield with ID 0x5455 (universal time) and 5 data bytes.
>> #   The local extra field has UTC/GMT modification/access times.
>> # - A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
>> #   01 04 ea 03 00 00 04 ea 03 00 00.
>> # - A subfield with ID 0x0001 (PKWARE 64-bit sizes) and 8 data bytes:
>> #  a4 06 a0 86 01 00 00 00.
>> #
>> zipinfo -v archive.zip
>>
>> # Bug repro code:
>> cat > Test.java <<EOF
>> import java.io
>> <https://urldefense.com/v3/__http://java.io__;!!GqivPVa7Brio!KhvWnawkon4E5sVeCpHmwDPJusjNPLMtqPh-ZBleD-U4Dv6tmWKB3cq3sT68yelqdA$>
>> .*;
>> import java.nio.*;
>> import java.nio.file.*;
>> import java.nio.file.attribute.*;
>>
>> public class Test {
>>  public static void main(String[]args) throws IOException {
>>    try (FileSystem fs =
>> FileSystems.newFileSystem(Paths.get("archive.zip"))) {
>>      for (Path root : fs.getRootDirectories()) {
>>        Files.walkFileTree(root, new SimpleFileVisitor<>() {
>>          public FileVisitResult visitFile(Path file,
>> BasicFileAttributes attrs) throws IOException {
>>            return FileVisitResult.CONTINUE;
>>          }
>>        });
>>      }
>>    }
>>  }
>> }
>> EOF
>> # and run it.
>> java Test.java
>>
>> The above ends with:
>>
>> Exception in thread "main" java.util.zip.ZipException: loc: wrong sig
>> ->841cd111
>>        at
>> jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readExtra(ZipFileSystem.java:2899)
>>        at
>> jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readCEN(ZipFileSystem.java:2600)
>>        at
>> jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.<init>(ZipFileSystem.java:2536)
>>        at
>> jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.getFileAttributes(ZipFileSystem.java:532)
>>        at jdk.zipfs/jdk.nio.zipfs.ZipPath.readAttributes(ZipPath.java:767)
>>        at jdk.zipfs/jdk.nio.zipfs.ZipPath.readAttributes(ZipPath.java:777)
>>        at
>> jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.readAttributes(ZipFileSystemProvider.java:276)
>>        at java.base/java.nio.file.Files.readAttributes(Files.java:1843)
>>        at
>> java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:219)
>>        at
>> java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:276)
>>        at
>> java.base/java.nio.file.FileTreeWalker.next(FileTreeWalker.java:373)
>>        at java.base/java.nio.file.Files.walkFileTree(Files.java:2840)
>>        at java.base/java.nio.file.Files.walkFileTree(Files.java:2876)
>>        at Test.main(Test.java:10)
>>
>> The fix is relatively simple I think - the current code assumes entry
>> offset is < 4GB when parsing extra data for
>> ID 0x5455. This should be evaluated lazily after all extra data blocks
>> are parsed to ensure the file offset is correctly
>> updated based on block ID 0x0001, regardless of its ordering within
>> other extra data blocks.
>>
>>
>>
>> On Fri, Oct 23, 2020 at 9:12 AM Dawid Weiss <dawid.weiss at gmail.com>
>> wrote:
>>
>>
>>
>> This looks like a legitimate bug to me (the zip file system
>> implementation is sensitive to the order of extra parameters and may throw
>> an unexpected error
>> on zip64 archives exceeding 4 gigabytes). I can't file a Jira issue - no
>> permissions - but I think it'd be worth adding one?
>>
>> Dawid
>>
>> On Wed, Oct 21, 2020 at 8:36 PM Dawid Weiss <dawid.weiss at gmail.com>
>> wrote:
>>
>>
>> Hi Lance,
>>
>> Yes, this is exactly the point where the problem is in JDK code. It's
>> directly
>> related to the zip entry beyond max int offset. The code tries to read
>> data
>> from a local zip entry header at locoff, here:
>>
>> if (zipfs.readFullyAt(buf, 0, buf.length , locoff)
>>
>> but the locoff is set to ~0 as per the spec for files exceeding
>> 4 gigabytes, which says:
>>
>>   4.4.16 relative offset of local header: (4 bytes)
>>
>>       This is the offset from the start of the first disk on
>>       which this file appears, to where the local header SHOULD
>>       be found.  If an archive is in ZIP64 format and the value
>>       in this field is 0xFFFFFFFF, the size will be in the
>>       corresponding 8 byte zip64 extended information extra field.
>>
>> A proper fix would be to read the local header from zip64 extra data
>> first. I don't know how this interferes with the rest of the code though -
>> didn't have enough time to look at it. As it stands, zip entries
>> beyond 4GB cause
>> an unchecked exception while attribute-scanning. This simple snippet
>> is enough to demonstrate it, given a ZIP entry beyond 4GB range:
>>
>> try (FileSystem fs =
>> FileSystems.newFileSystem(Paths.get("zipWithEntryBeyond4Gb.zip"))) {
>>  for (Path root : fs.getRootDirectories()) {
>>    Files.walkFileTree(root, new SimpleFileVisitor<>() {
>>      @Override
>>      public FileVisitResult visitFile(Path file, BasicFileAttributes
>> attrs) throws IOException {
>>        return FileVisitResult.CONTINUE;
>>      }
>>    });
>>  }
>> }
>>
>> The walkFileTree method is key here as it attempts to harvest
>> attributes (why we use it is another story -- this saves a lot of time
>> on large, network-mounted regular directories when you're collecting
>> file metadata).
>>
>>
>> Dawid
>>
>>
>> On Wed, Oct 21, 2020 at 6:39 PM Lance Andersen
>> <LANCE.ANDERSEN at oracle.com> wrote:
>>
>>
>> Hi David,
>>
>> From  a quick look at ZipFileSystem this appears to be an optimization to
>> avoid looking at the LOC extended Timestamp Extra field
>>
>> If a Info-ZIP Extended Timestamp (0x5455)is found then:
>>
>>  If the "zipinfo-time" entry was set  to ?false? in the Map specified
>> when creating the Zip FileSystem,
>>
>> FileSystems.newFileSystem(zipFile, Map.of("zipinfo-time", "false")
>>
>> and the  data size of the CEN extended Timestamp is 5 (flag + mod time)
>>
>> The modified time is used from the CEN Extended Timestamp extra field
>>
>> Otherwise get the modified time, creation time, and access time from the
>> LOC Extended Timestamp extra field.
>>
>>
>> ?????
>>
>> Extended Timestamp Extra Field:
>>
>>          ==============================
>>
>>          The following is the layout of the extended-timestamp extra
>> block.
>>          (Last Revision 19970118)
>>
>>          Local-header version:
>>
>>          Value         Size        Description
>>          -----         ----        -----------
>>  (time)  0x5455        Short       tag for this extra block type ("UT")
>>          TSize         Short       total data size for this block
>>          Flags         Byte        info bits
>>          (ModTime)     Long        time of last modification (UTC/GMT)
>>          (AcTime)      Long        time of last access (UTC/GMT)
>>          (CrTime)      Long        time of original creation (UTC/GMT)
>>
>>          Central-header version:
>>
>>          Value         Size        Description
>>          -----         ----        -----------
>>  (time)  0x5455        Short       tag for this extra block type ("UT")
>>          TSize         Short       total data size for this block
>>          Flags         Byte        info bits (refers to local header!)
>>          (ModTime)     Long        time of last modification (UTC/GMT)
>>
>>          The central-header extra field contains the modification time
>> only,
>>          or no timestamp at all.  TSize is used to flag its presence or
>>          absence.  But note:
>>
>>              If "Flags" indicates that Modtime is present in the local
>> header
>>              field, it MUST be present in the central header field, too!
>>              This correspondence is required because the modification time
>>              value may be used to support trans-timezone freshening and
>>              updating operations with zip archives.
>>
>>          The time values are in standard Unix signed-long format,
>> indicating
>>          the number of seconds since 1 January 1970 00:00:00.  The times
>>          are relative to Coordinated Universal Time (UTC), also sometimes
>>          referred to as Greenwich Mean Time (GMT).  To convert to local
>> time,
>>          the software must know the local timezone offset from UTC/GMT.
>>
>>          The lower three bits of Flags in both headers indicate which
>> time-
>>          stamps are present in the LOCAL extra field:
>>
>>                bit 0           if set, modification time is present
>>                bit 1           if set, access time is present
>>                bit 2           if set, creation time is present
>>                bits 3-7        reserved for additional timestamps; not set
>>
>>          Those times that are present will appear in the order indicated,
>> but
>>          any combination of times may be omitted.  (Creation time may be
>>          present without access time, for example.)  TSize should equal
>>          (1 + 4*(number of set bits in Flags)), as the block is currently
>>          defined.  Other timestamps may be added in the future.
>>
>>
>> --------------
>>
>> It's hard to comment on why you received the error that you did but it is
>> possible the tool that was used for writing the entry  did something
>> unexpected.
>>
>> Out of curiosity, have you tried using ZipFile/ZipEntry to access the
>> entry?
>>
>>
>> Best,
>> Lance
>>
>>
>> On Oct 21, 2020, at 4:55 AM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
>>
>> Hello,
>>
>> We've encountered a seemingly valid ZIP file (zipinfo -v shows all its
>> entries are intact) that causes a runtime exception when scanning its
>> contents with ZipFileSystem. The exception indicates an invalid
>> signature when parsing EXTID_EXTT. I don't quite understand this
>> comment in the code:
>>
>> case EXTID_EXTT:
>>   // spec says the Extened timestamp in cen only has mtime
>>   // need to read the loc to get the extra a/ctime, if flag
>>   // "zipinfo-time" is not specified to false;
>>   // there is performance cost (move up to loc and read) to
>>   // access the loc table foreach entry;
>>   if (zipfs.noExtt) {
>>       if (sz == 5)
>>           mtime = unixToJavaTime(LG(extra, pos + 1));
>>        break;
>>   }
>> ...
>>
>> but this ZIP file has the extra data block of exactly 5 bytes, as
>> indicated by zipinfo:
>>
>> Central directory entry #6:
>> ---------------------------
>> ...
>> file system or operating system of origin:      Unix
>> version of encoding software:                   3.0
>> minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
>> minimum software version required to extract:   2.0
>> compression method:                             deflated
>> ...
>> extended local header:                          no
>> file last modified on (DOS date/time):          2018 Mar 1 04:56:20
>> file last modified on (UT extra field modtime): 2018 Mar 1 05:56:19 local
>> file last modified on (UT extra field modtime): 2018 Mar 1 04:56:19 UTC
>> ...
>> Unix file attributes (100000 octal):            ----------
>> MS-DOS file attributes (01 hex):                read-only
>>
>> The central-directory extra field contains:
>> - A subfield with ID 0x5455 (universal time) and 5 data bytes.
>>   The local extra field has UTC/GMT modification/access times.
>>
>> The above conditional block checking for length == 5 would have worked
>> in ZipFileSystem but it's surrounded by a condition over an
>> externally-provided property - zipfs.noExtt is only set to true if:
>>
>> this.noExtt = "false".equals(env.get("zipinfo-time"));
>>
>> I can't share this particular ZIP file with you and I don't know how
>> it was created but it seems like that "zipinfo-time" flag could be
>> omitted if the length of the extra data field is exactly 5?
>>
>> Dawid
>>
>>
>>
>> Best
>> Lance
>> ------------------
>>
>>
>>
>> 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
>>
>>
>>
>>
>>
>>
>> Best
>> Lance
>> ------------------
>>
>> <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
>>
>
>
> Best
> Lance
> ------------------
>
>
>
> 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
>
>
>
>
>

From LANCE.ANDERSEN at ORACLE.COM  Sun Nov 29 22:22:15 2020
From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen)
Date: Sun, 29 Nov 2020 17:22:15 -0500
Subject: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data
 field of exactly 5 bytes)
In-Reply-To: <CAM21Rt8h0m-m=jWiYK4LoTYDZuChHHWh_p-acZJaHepK_f0Scw@mail.gmail.com>
References: <CAM21Rt8KeWyQvjE7-5pfyXYJXO3yGgGfKpBtueOV8qgNFMa+jQ@mail.gmail.com>
 <17F644E3-E5E0-403E-B568-FCB89C8BD9BB@ORACLE.COM>
 <CAM21Rt-ANpHbDO-kjSHguDzSTGS-WhGwHsbxcHav1wFVvDQ2EQ@mail.gmail.com>
 <CAM21Rt_8WWsTm-DrY=stscEuiWXF1-JJkv83wZoReJB7ZD-Kjw@mail.gmail.com>
 <CAM21Rt9tHhGf7+eKfrrLbPwP8jShZytF6Qh_3OS4yxVg=02hWQ@mail.gmail.com>
 <DB63C62D-0D4C-42F4-8C7A-D732DFB8FB0C@ORACLE.COM>
 <CAM21Rt_3pVbOnn5wqt=hSTUALLMUyM2ERsd0x4f7J0NjMt8+Zg@mail.gmail.com>
 <4E5D6A9D-4F31-4EA8-9869-8A3F4944780D@ORACLE.COM>
 <CAM21Rt8h0m-m=jWiYK4LoTYDZuChHHWh_p-acZJaHepK_f0Scw@mail.gmail.com>
Message-ID: <6716D065-88A4-4175-8F3E-28401F6333ED@ORACLE.COM>

Hi Dawid

Thank you for getting back to me.

> On Nov 29, 2020, at 5:00 PM, Dawid Weiss <dawid.weiss at gmail.com> wrote:
> 
> 
> Hi Lance,
> 
> I looked at the test you pointed to... This is exactly the test for the problem I originally reported on October 21st... The bug has been filed
> for this on October 25th (by you) -- https://bugs.openjdk.java.net/browse/JDK-8255380 <https://bugs.openjdk.java.net/browse/JDK-8255380> and the fix is in commit 6606e0909cbda9. Weird.
> 
> I think that test is slightly broken in that it passes "zipinfo-time=false" -- this is exactly the workaround that makes it work everywhere. The
> test should *not* have that flag set?

The ZipFileSystem check is case sensitive:

???
this.noExtt = "false".equals(env.get("zipinfo-time"));
????

> 
>         try (FileSystem fs =
>                      FileSystems.newFileSystem(Paths.get(ZIP_FILE_NAME), Map.of("zipinfo-time", "False"))) {
> 

You are right though, it would be clearer if I change it to Map.of(); 

Thank you for pointing that out

Best
Lance
> Anyway, the problem is fixed. I think it'd be good to backport to LTS releases too.
> 
> Dawid
> 
> On Sat, Nov 28, 2020 at 4:32 PM Lance Andersen <LANCE.ANDERSEN at oracle.com <mailto:LANCE.ANDERSEN at oracle.com>> wrote:
> Hi Dawid,
> 
> Thank you for the follow up.
> 
>> On Nov 28, 2020, at 9:34 AM, Dawid Weiss <dawid.weiss at gmail.com <mailto:dawid.weiss at gmail.com>> wrote:
>> 
>> 
>> I know what the problem is and I know what the fix should be (and tried to convey it) but I don't have a patch.
> 
> Given you believe you know what the fix would be,  it would be great to create a patch for ZipFileSystem and see if it addresses the issue and then contribute the fix back to the OpenJDK community :-).
> 
> 
>> Writing the test case is not a problem but it'll be a lengthy test on slower drives (has to create a zip file that exceeds 4gb of disk space).
> 
> The test case would be configured as a manual test and would look similar to test/jdk/jdk/nio/zipfs/TestLocOffsetFromZip64EF.java <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/987*diff-73b401685399c9d59851cda49e9c0d377093086119555708253c8df99649e3c9__;Iw!!GqivPVa7Brio!O7QI8ncxtRbHUjGhW-GmeXZnM3KYdut-r74YfTVxu6etbBcluUHLqDp6DaLsampu2w$> which also creates a 4GB zip.
> 
>> I don't think there is a way to fake the file system by using a sparse file, sadly. Would this be acceptable? If so then sure - I can provide a reproducible test case that will fail for the current implementation.
> 
> The above test runs in a reasonable time so I would expect this test case would as well.
> 
> I will look to reproduce the issue over the weekend or early next week and log a bug with what you provided in your earlier email.
> 
> 
> Best
> Lance
>> 
>> D.
>> 
>> On Fri, Nov 27, 2020 at 8:37 PM Lance Andersen <LANCE.ANDERSEN at oracle.com <mailto:LANCE.ANDERSEN at oracle.com>> wrote:
>> Hi Dawid,
>> 
>> If you believe you have a a fix, please submit a patch along with a JTREG test case.  Ideally the test case would create zip file as part of the test.
>> 
>> Best
>> Lance
>> 
>>> On Nov 27, 2020, at 7:37 AM, Dawid Weiss <dawid.weiss at gmail.com <mailto:dawid.weiss at gmail.com>> wrote:
>>> 
>>> Just for the archives - I'm not sure if this ended up being filed to
>>> the bug system - the repro below demonstrates the bug on all JDKs up
>>> to the newest one.
>>> 
>>> # create a single random file of 250 megabytes
>>> head -c 250M < /dev/urandom > rnd.bin
>>> # create a bunch of hardlinks to the same file.
>>> for i in `seq -w 1 25`; do ln rnd.bin rnd-$i.bin; done
>>> # create a zip archive exceeding 4gb (in stored mode so that it's faster)
>>> zip -0 archive.zip rnd*.bin
>>> # show the content of the archive - for all entries beyond 4gb this should
>>> # show extra data blocks like below (note the order of extra data
>>> blocks - this is important).
>>> #
>>> #  The central-directory extra field contains:
>>> # - A subfield with ID 0x5455 (universal time) and 5 data bytes.
>>> #   The local extra field has UTC/GMT modification/access times.
>>> # - A subfield with ID 0x7875 (Unix UID/GID (any size)) and 11 data bytes:
>>> #   01 04 ea 03 00 00 04 ea 03 00 00.
>>> # - A subfield with ID 0x0001 (PKWARE 64-bit sizes) and 8 data bytes:
>>> #  a4 06 a0 86 01 00 00 00.
>>> #
>>> zipinfo -v archive.zip
>>> 
>>> # Bug repro code:
>>> cat > Test.java <<EOF
>>> import java.io <https://urldefense.com/v3/__http://java.io__;!!GqivPVa7Brio!KhvWnawkon4E5sVeCpHmwDPJusjNPLMtqPh-ZBleD-U4Dv6tmWKB3cq3sT68yelqdA$>.*;
>>> import java.nio.*;
>>> import java.nio.file.*;
>>> import java.nio.file.attribute.*;
>>> 
>>> public class Test {
>>>  public static void main(String[]args) throws IOException {
>>>    try (FileSystem fs = FileSystems.newFileSystem(Paths.get("archive.zip"))) {
>>>      for (Path root : fs.getRootDirectories()) {
>>>        Files.walkFileTree(root, new SimpleFileVisitor<>() {
>>>          public FileVisitResult visitFile(Path file,
>>> BasicFileAttributes attrs) throws IOException {
>>>            return FileVisitResult.CONTINUE;
>>>          }
>>>        });
>>>      }
>>>    }
>>>  }
>>> }
>>> EOF
>>> # and run it.
>>> java Test.java
>>> 
>>> The above ends with:
>>> 
>>> Exception in thread "main" java.util.zip.ZipException: loc: wrong sig ->841cd111
>>>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readExtra(ZipFileSystem.java:2899)
>>>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.readCEN(ZipFileSystem.java:2600)
>>>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem$Entry.<init>(ZipFileSystem.java:2536)
>>>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystem.getFileAttributes(ZipFileSystem.java:532)
>>>        at jdk.zipfs/jdk.nio.zipfs.ZipPath.readAttributes(ZipPath.java:767)
>>>        at jdk.zipfs/jdk.nio.zipfs.ZipPath.readAttributes(ZipPath.java:777)
>>>        at jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.readAttributes(ZipFileSystemProvider.java:276)
>>>        at java.base/java.nio.file.Files.readAttributes(Files.java:1843)
>>>        at java.base/java.nio.file.FileTreeWalker.getAttributes(FileTreeWalker.java:219)
>>>        at java.base/java.nio.file.FileTreeWalker.visit(FileTreeWalker.java:276)
>>>        at java.base/java.nio.file.FileTreeWalker.next(FileTreeWalker.java:373)
>>>        at java.base/java.nio.file.Files.walkFileTree(Files.java:2840)
>>>        at java.base/java.nio.file.Files.walkFileTree(Files.java:2876)
>>>        at Test.main(Test.java:10)
>>> 
>>> The fix is relatively simple I think - the current code assumes entry
>>> offset is < 4GB when parsing extra data for
>>> ID 0x5455. This should be evaluated lazily after all extra data blocks
>>> are parsed to ensure the file offset is correctly
>>> updated based on block ID 0x0001, regardless of its ordering within
>>> other extra data blocks.
>>> 
>>> 
>>> 
>>> On Fri, Oct 23, 2020 at 9:12 AM Dawid Weiss <dawid.weiss at gmail.com <mailto:dawid.weiss at gmail.com>> wrote:
>>>> 
>>>> 
>>>> This looks like a legitimate bug to me (the zip file system implementation is sensitive to the order of extra parameters and may throw an unexpected error
>>>> on zip64 archives exceeding 4 gigabytes). I can't file a Jira issue - no permissions - but I think it'd be worth adding one?
>>>> 
>>>> Dawid
>>>> 
>>>> On Wed, Oct 21, 2020 at 8:36 PM Dawid Weiss <dawid.weiss at gmail.com <mailto:dawid.weiss at gmail.com>> wrote:
>>>>> 
>>>>> Hi Lance,
>>>>> 
>>>>> Yes, this is exactly the point where the problem is in JDK code. It's directly
>>>>> related to the zip entry beyond max int offset. The code tries to read data
>>>>> from a local zip entry header at locoff, here:
>>>>> 
>>>>> if (zipfs.readFullyAt(buf, 0, buf.length , locoff)
>>>>> 
>>>>> but the locoff is set to ~0 as per the spec for files exceeding
>>>>> 4 gigabytes, which says:
>>>>> 
>>>>>   4.4.16 relative offset of local header: (4 bytes)
>>>>> 
>>>>>       This is the offset from the start of the first disk on
>>>>>       which this file appears, to where the local header SHOULD
>>>>>       be found.  If an archive is in ZIP64 format and the value
>>>>>       in this field is 0xFFFFFFFF, the size will be in the
>>>>>       corresponding 8 byte zip64 extended information extra field.
>>>>> 
>>>>> A proper fix would be to read the local header from zip64 extra data
>>>>> first. I don't know how this interferes with the rest of the code though -
>>>>> didn't have enough time to look at it. As it stands, zip entries
>>>>> beyond 4GB cause
>>>>> an unchecked exception while attribute-scanning. This simple snippet
>>>>> is enough to demonstrate it, given a ZIP entry beyond 4GB range:
>>>>> 
>>>>> try (FileSystem fs =
>>>>> FileSystems.newFileSystem(Paths.get("zipWithEntryBeyond4Gb.zip"))) {
>>>>>  for (Path root : fs.getRootDirectories()) {
>>>>>    Files.walkFileTree(root, new SimpleFileVisitor<>() {
>>>>>      @Override
>>>>>      public FileVisitResult visitFile(Path file, BasicFileAttributes
>>>>> attrs) throws IOException {
>>>>>        return FileVisitResult.CONTINUE;
>>>>>      }
>>>>>    });
>>>>>  }
>>>>> }
>>>>> 
>>>>> The walkFileTree method is key here as it attempts to harvest
>>>>> attributes (why we use it is another story -- this saves a lot of time
>>>>> on large, network-mounted regular directories when you're collecting
>>>>> file metadata).
>>>>> 
>>>>> 
>>>>> Dawid
>>>>> 
>>>>> 
>>>>> On Wed, Oct 21, 2020 at 6:39 PM Lance Andersen
>>>>> <LANCE.ANDERSEN at oracle.com <mailto:LANCE.ANDERSEN at oracle.com>> wrote:
>>>>>> 
>>>>>> Hi David,
>>>>>> 
>>>>>> From  a quick look at ZipFileSystem this appears to be an optimization to avoid looking at the LOC extended Timestamp Extra field
>>>>>> 
>>>>>> If a Info-ZIP Extended Timestamp (0x5455)is found then:
>>>>>> 
>>>>>>  If the "zipinfo-time" entry was set  to ?false? in the Map specified when creating the Zip FileSystem,
>>>>>> 
>>>>>> FileSystems.newFileSystem(zipFile, Map.of("zipinfo-time", "false")
>>>>>> 
>>>>>> and the  data size of the CEN extended Timestamp is 5 (flag + mod time)
>>>>>> 
>>>>>> The modified time is used from the CEN Extended Timestamp extra field
>>>>>> 
>>>>>> Otherwise get the modified time, creation time, and access time from the LOC Extended Timestamp extra field.
>>>>>> 
>>>>>> 
>>>>>> ?????
>>>>>> 
>>>>>> Extended Timestamp Extra Field:
>>>>>> 
>>>>>>          ==============================
>>>>>> 
>>>>>>          The following is the layout of the extended-timestamp extra block.
>>>>>>          (Last Revision 19970118)
>>>>>> 
>>>>>>          Local-header version:
>>>>>> 
>>>>>>          Value         Size        Description
>>>>>>          -----         ----        -----------
>>>>>>  (time)  0x5455        Short       tag for this extra block type ("UT")
>>>>>>          TSize         Short       total data size for this block
>>>>>>          Flags         Byte        info bits
>>>>>>          (ModTime)     Long        time of last modification (UTC/GMT)
>>>>>>          (AcTime)      Long        time of last access (UTC/GMT)
>>>>>>          (CrTime)      Long        time of original creation (UTC/GMT)
>>>>>> 
>>>>>>          Central-header version:
>>>>>> 
>>>>>>          Value         Size        Description
>>>>>>          -----         ----        -----------
>>>>>>  (time)  0x5455        Short       tag for this extra block type ("UT")
>>>>>>          TSize         Short       total data size for this block
>>>>>>          Flags         Byte        info bits (refers to local header!)
>>>>>>          (ModTime)     Long        time of last modification (UTC/GMT)
>>>>>> 
>>>>>>          The central-header extra field contains the modification time only,
>>>>>>          or no timestamp at all.  TSize is used to flag its presence or
>>>>>>          absence.  But note:
>>>>>> 
>>>>>>              If "Flags" indicates that Modtime is present in the local header
>>>>>>              field, it MUST be present in the central header field, too!
>>>>>>              This correspondence is required because the modification time
>>>>>>              value may be used to support trans-timezone freshening and
>>>>>>              updating operations with zip archives.
>>>>>> 
>>>>>>          The time values are in standard Unix signed-long format, indicating
>>>>>>          the number of seconds since 1 January 1970 00:00:00.  The times
>>>>>>          are relative to Coordinated Universal Time (UTC), also sometimes
>>>>>>          referred to as Greenwich Mean Time (GMT).  To convert to local time,
>>>>>>          the software must know the local timezone offset from UTC/GMT.
>>>>>> 
>>>>>>          The lower three bits of Flags in both headers indicate which time-
>>>>>>          stamps are present in the LOCAL extra field:
>>>>>> 
>>>>>>                bit 0           if set, modification time is present
>>>>>>                bit 1           if set, access time is present
>>>>>>                bit 2           if set, creation time is present
>>>>>>                bits 3-7        reserved for additional timestamps; not set
>>>>>> 
>>>>>>          Those times that are present will appear in the order indicated, but
>>>>>>          any combination of times may be omitted.  (Creation time may be
>>>>>>          present without access time, for example.)  TSize should equal
>>>>>>          (1 + 4*(number of set bits in Flags)), as the block is currently
>>>>>>          defined.  Other timestamps may be added in the future.
>>>>>> 
>>>>>> 
>>>>>> --------------
>>>>>> 
>>>>>> It's hard to comment on why you received the error that you did but it is possible the tool that was used for writing the entry  did something unexpected.
>>>>>> 
>>>>>> Out of curiosity, have you tried using ZipFile/ZipEntry to access the entry?
>>>>>> 
>>>>>> 
>>>>>> Best,
>>>>>> Lance
>>>>>> 
>>>>>> 
>>>>>> On Oct 21, 2020, at 4:55 AM, Dawid Weiss <dawid.weiss at gmail.com <mailto:dawid.weiss at gmail.com>> wrote:
>>>>>> 
>>>>>> Hello,
>>>>>> 
>>>>>> We've encountered a seemingly valid ZIP file (zipinfo -v shows all its
>>>>>> entries are intact) that causes a runtime exception when scanning its
>>>>>> contents with ZipFileSystem. The exception indicates an invalid
>>>>>> signature when parsing EXTID_EXTT. I don't quite understand this
>>>>>> comment in the code:
>>>>>> 
>>>>>> case EXTID_EXTT:
>>>>>>   // spec says the Extened timestamp in cen only has mtime
>>>>>>   // need to read the loc to get the extra a/ctime, if flag
>>>>>>   // "zipinfo-time" is not specified to false;
>>>>>>   // there is performance cost (move up to loc and read) to
>>>>>>   // access the loc table foreach entry;
>>>>>>   if (zipfs.noExtt) {
>>>>>>       if (sz == 5)
>>>>>>           mtime = unixToJavaTime(LG(extra, pos + 1));
>>>>>>        break;
>>>>>>   }
>>>>>> ...
>>>>>> 
>>>>>> but this ZIP file has the extra data block of exactly 5 bytes, as
>>>>>> indicated by zipinfo:
>>>>>> 
>>>>>> Central directory entry #6:
>>>>>> ---------------------------
>>>>>> ...
>>>>>> file system or operating system of origin:      Unix
>>>>>> version of encoding software:                   3.0
>>>>>> minimum file system compatibility required:     MS-DOS, OS/2 or NT FAT
>>>>>> minimum software version required to extract:   2.0
>>>>>> compression method:                             deflated
>>>>>> ...
>>>>>> extended local header:                          no
>>>>>> file last modified on (DOS date/time):          2018 Mar 1 04:56:20
>>>>>> file last modified on (UT extra field modtime): 2018 Mar 1 05:56:19 local
>>>>>> file last modified on (UT extra field modtime): 2018 Mar 1 04:56:19 UTC
>>>>>> ...
>>>>>> Unix file attributes (100000 octal):            ----------
>>>>>> MS-DOS file attributes (01 hex):                read-only
>>>>>> 
>>>>>> The central-directory extra field contains:
>>>>>> - A subfield with ID 0x5455 (universal time) and 5 data bytes.
>>>>>>   The local extra field has UTC/GMT modification/access times.
>>>>>> 
>>>>>> The above conditional block checking for length == 5 would have worked
>>>>>> in ZipFileSystem but it's surrounded by a condition over an
>>>>>> externally-provided property - zipfs.noExtt is only set to true if:
>>>>>> 
>>>>>> this.noExtt = "false".equals(env.get("zipinfo-time"));
>>>>>> 
>>>>>> I can't share this particular ZIP file with you and I don't know how
>>>>>> it was created but it seems like that "zipinfo-time" flag could be
>>>>>> omitted if the length of the extra data field is exactly 5?
>>>>>> 
>>>>>> Dawid
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Best
>>>>>> Lance
>>>>>> ------------------
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 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>
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>> 
>> 
>> Best
>> Lance
>> ------------------
>> 
>> <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>
> 
> Best
> Lance
> ------------------
> 
> <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>
> 
> 
> 
> 


Best
Lance
------------------




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





From forax at univ-mlv.fr  Mon Nov 30 07:08:13 2020
From: forax at univ-mlv.fr (Remi Forax)
Date: Mon, 30 Nov 2020 08:08:13 +0100 (CET)
Subject: Why having the wrong InnerClasses attribute is an issue for the VM ?
Message-ID: <2086523770.25097.1606720093577.JavaMail.zimbra@u-pem.fr>

I've forgotten a cast in an invokedynamic, hence a call to wrongTargetType,
but in order to create the error message, MethodType.toString(), getSimpleName() is called and it fails because getDeclaringClass() verifies the InnerClasses attribute.

For me InnerClasses was just an attribute for javac not something the VM should take care of,
it seems that the VM strongly verifies this attribute and i wonder what is the reason behind that ?

regards,
R?mi

Exception in thread "main" java.lang.IncompatibleClassChangeError: fr.umlv.transmogrif.ImplMap and fr.umlv.transmogrif.ImplMap$Row/0x0000000801007400 disagree on InnerClasses attribute
        at java.base/java.lang.Class.getDeclaringClass0(Native Method)
        at java.base/java.lang.Class.isTopLevelClass(Class.java:1970)
        at java.base/java.lang.Class.getSimpleBinaryName(Class.java:1955)
        at java.base/java.lang.Class.getSimpleName0(Class.java:1835)
        at java.base/java.lang.Class.getSimpleName(Class.java:1826)
        at java.base/java.lang.Class.getSimpleName0(Class.java:1833)
        at java.base/java.lang.Class.getSimpleName(Class.java:1826)
        at java.base/java.lang.invoke.MethodType.toString(MethodType.java:895)
        at java.base/java.lang.String.valueOf(String.java:3365)
        at java.base/java.lang.StringBuilder.append(StringBuilder.java:169)
        at java.base/java.lang.invoke.MethodHandle.standardString(MethodHandle.java:1611)
        at java.base/java.lang.invoke.MethodHandle.toString(MethodHandle.java:1608)
        at java.base/java.lang.String.valueOf(String.java:3365)
        at java.base/java.lang.invoke.CallSite.wrongTargetType(CallSite.java:203)
        at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:333)
        at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:280)
        at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:270)
        at fr.umlv.transmogrif.ImplMap/0x0000000801003c00.<init>(ImplMap.java:21)
        at fr.umlv.transmogrif.Main.main(Main.java:7)

From david.holmes at oracle.com  Mon Nov 30 07:57:37 2020
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Nov 2020 17:57:37 +1000
Subject: Why having the wrong InnerClasses attribute is an issue for the
 VM ?
In-Reply-To: <2086523770.25097.1606720093577.JavaMail.zimbra@u-pem.fr>
References: <2086523770.25097.1606720093577.JavaMail.zimbra@u-pem.fr>
Message-ID: <9c9d6ecd-a1a3-4e7d-0a53-6f5d29660e27@oracle.com>

On 30/11/2020 5:08 pm, Remi Forax wrote:
> I've forgotten a cast in an invokedynamic, hence a call to wrongTargetType,
> but in order to create the error message, MethodType.toString(), getSimpleName() is called and it fails because getDeclaringClass() verifies the InnerClasses attribute.
> 
> For me InnerClasses was just an attribute for javac not something the VM should take care of,
> it seems that the VM strongly verifies this attribute and i wonder what is the reason behind that ?

 From the VM code - InstanceKlass::compute_enclosing_class:

   // Throws an exception if outer klass has not declared k as an inner 
klass
   // We need evidence that each klass knows about the other, or else
   // the system could allow a spoof of an inner class to gain access 
rights.
   Reflection::check_for_inner_class(outer_klass, this, 
*inner_is_member, CHECK_NULL);

David

> regards,
> R?mi
> 
> Exception in thread "main" java.lang.IncompatibleClassChangeError: fr.umlv.transmogrif.ImplMap and fr.umlv.transmogrif.ImplMap$Row/0x0000000801007400 disagree on InnerClasses attribute
>          at java.base/java.lang.Class.getDeclaringClass0(Native Method)
>          at java.base/java.lang.Class.isTopLevelClass(Class.java:1970)
>          at java.base/java.lang.Class.getSimpleBinaryName(Class.java:1955)
>          at java.base/java.lang.Class.getSimpleName0(Class.java:1835)
>          at java.base/java.lang.Class.getSimpleName(Class.java:1826)
>          at java.base/java.lang.Class.getSimpleName0(Class.java:1833)
>          at java.base/java.lang.Class.getSimpleName(Class.java:1826)
>          at java.base/java.lang.invoke.MethodType.toString(MethodType.java:895)
>          at java.base/java.lang.String.valueOf(String.java:3365)
>          at java.base/java.lang.StringBuilder.append(StringBuilder.java:169)
>          at java.base/java.lang.invoke.MethodHandle.standardString(MethodHandle.java:1611)
>          at java.base/java.lang.invoke.MethodHandle.toString(MethodHandle.java:1608)
>          at java.base/java.lang.String.valueOf(String.java:3365)
>          at java.base/java.lang.invoke.CallSite.wrongTargetType(CallSite.java:203)
>          at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:333)
>          at java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:280)
>          at java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:270)
>          at fr.umlv.transmogrif.ImplMap/0x0000000801003c00.<init>(ImplMap.java:21)
>          at fr.umlv.transmogrif.Main.main(Main.java:7)
> 

From dawid.weiss at gmail.com  Mon Nov 30 07:58:31 2020
From: dawid.weiss at gmail.com (Dawid Weiss)
Date: Mon, 30 Nov 2020 08:58:31 +0100
Subject: "loc: wrong sig" in ZipFileSystem on a valid ZIP file (extra data
 field of exactly 5 bytes)
In-Reply-To: <6716D065-88A4-4175-8F3E-28401F6333ED@ORACLE.COM>
References: <CAM21Rt8KeWyQvjE7-5pfyXYJXO3yGgGfKpBtueOV8qgNFMa+jQ@mail.gmail.com>
 <17F644E3-E5E0-403E-B568-FCB89C8BD9BB@ORACLE.COM>
 <CAM21Rt-ANpHbDO-kjSHguDzSTGS-WhGwHsbxcHav1wFVvDQ2EQ@mail.gmail.com>
 <CAM21Rt_8WWsTm-DrY=stscEuiWXF1-JJkv83wZoReJB7ZD-Kjw@mail.gmail.com>
 <CAM21Rt9tHhGf7+eKfrrLbPwP8jShZytF6Qh_3OS4yxVg=02hWQ@mail.gmail.com>
 <DB63C62D-0D4C-42F4-8C7A-D732DFB8FB0C@ORACLE.COM>
 <CAM21Rt_3pVbOnn5wqt=hSTUALLMUyM2ERsd0x4f7J0NjMt8+Zg@mail.gmail.com>
 <4E5D6A9D-4F31-4EA8-9869-8A3F4944780D@ORACLE.COM>
 <CAM21Rt8h0m-m=jWiYK4LoTYDZuChHHWh_p-acZJaHepK_f0Scw@mail.gmail.com>
 <6716D065-88A4-4175-8F3E-28401F6333ED@ORACLE.COM>
Message-ID: <CAM21Rt8FrTXcrp6Y78dfW3RGuqk0EGv1NN5mSGfdTQ36UNASCA@mail.gmail.com>

> The ZipFileSystem check is case sensitive:
>

Ah, that's not obvious at all... and even if this is an undocumented option
I'd add a comment in the test
or remove it to Map.of() for clarity. That bug entry in Jira doesn't have
"affects" pointing at older releases - I think it should since it affects
a number of them... I'm sorry for not tracking head-of-development closely,
perhaps I'd have caught your patch sooner; I only tested the problem
with binary releases.

Dawid

From alanb at openjdk.java.net  Mon Nov 30 09:58:58 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 30 Nov 2020 09:58:58 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview)
In-Reply-To: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
Message-ID: <Z3AFytvDqAjrVEm6tnmJ5MzgynTJU9e6Kc8-u2K1R0c=.44f7ccbb-eae1-4920-8feb-2a26a27a769d@github.com>

On Fri, 27 Nov 2020 16:57:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
> 
> From the original PR:
> 
>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>> 
>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>> 
>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>> 
>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>> 
>>     * adding code to make sure that annotations can't be sealed
>> 
>>     * improving some tests
>> 
>> 
>> TIA
>> 
>> Related specs:
>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
> 
> This PR strives to reflect the review comments from 1227:
>  * adjustments to javadoc of j.l.Class methods
>  * package access checks in Class.getPermittedSubclasses()
>  * fixed to the narrowing conversion/castability as pointed out by Maurizio

src/java.base/share/classes/java/lang/Class.java line 4420:

> 4418:      * {@linkplain #getClassLoader() the defining class loader} of the current
> 4419:      * {@code Class} object. If a name cannot be converted to the {@code Class}
> 4420:      * instance, it is silently excluded from the result.

I think this paragraph will need a little bit of wordsmithing. The 3rd paragraph of getNestMembers might be useful to examine as it more clearly describes how the method attempts to "obtain" the Class object for each of the class names in the NestMembers attribute and maybe some of that wording could be used instead of using the term "convert".

Minor nit but the prevailing style for the @throws SecurityException is to align the description with the exception, probably best to keep it consistent if you can.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1483

From forax at univ-mlv.fr  Mon Nov 30 10:04:36 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 30 Nov 2020 11:04:36 +0100 (CET)
Subject: Why having the wrong InnerClasses attribute is an issue for the
 VM ?
In-Reply-To: <9c9d6ecd-a1a3-4e7d-0a53-6f5d29660e27@oracle.com>
References: <2086523770.25097.1606720093577.JavaMail.zimbra@u-pem.fr>
 <9c9d6ecd-a1a3-4e7d-0a53-6f5d29660e27@oracle.com>
Message-ID: <370336411.232693.1606730676739.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "David Holmes" <david.holmes at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Lundi 30 Novembre 2020 08:57:37
> Objet: Re: Why having the wrong InnerClasses attribute is an issue for the VM ?

> On 30/11/2020 5:08 pm, Remi Forax wrote:
>> I've forgotten a cast in an invokedynamic, hence a call to wrongTargetType,
>> but in order to create the error message, MethodType.toString(), getSimpleName()
>> is called and it fails because getDeclaringClass() verifies the InnerClasses
>> attribute.
>> 
>> For me InnerClasses was just an attribute for javac not something the VM should
>> take care of,
>> it seems that the VM strongly verifies this attribute and i wonder what is the
>> reason behind that ?
> 
> From the VM code - InstanceKlass::compute_enclosing_class:
> 
>   // Throws an exception if outer klass has not declared k as an inner
> klass
>   // We need evidence that each klass knows about the other, or else
>   // the system could allow a spoof of an inner class to gain access
> rights.
>   Reflection::check_for_inner_class(outer_klass, this,
> *inner_is_member, CHECK_NULL);

I don't understand how to spoof the InnerClasses attribute to gain access given that the access rights are not based on the InnerClasses attribute.

> 
> David

R?mi

> 
>> regards,
>> R?mi
>> 
>> Exception in thread "main" java.lang.IncompatibleClassChangeError:
>> fr.umlv.transmogrif.ImplMap and
>> fr.umlv.transmogrif.ImplMap$Row/0x0000000801007400 disagree on InnerClasses
>> attribute
>>          at java.base/java.lang.Class.getDeclaringClass0(Native Method)
>>          at java.base/java.lang.Class.isTopLevelClass(Class.java:1970)
>>          at java.base/java.lang.Class.getSimpleBinaryName(Class.java:1955)
>>          at java.base/java.lang.Class.getSimpleName0(Class.java:1835)
>>          at java.base/java.lang.Class.getSimpleName(Class.java:1826)
>>          at java.base/java.lang.Class.getSimpleName0(Class.java:1833)
>>          at java.base/java.lang.Class.getSimpleName(Class.java:1826)
>>          at java.base/java.lang.invoke.MethodType.toString(MethodType.java:895)
>>          at java.base/java.lang.String.valueOf(String.java:3365)
>>          at java.base/java.lang.StringBuilder.append(StringBuilder.java:169)
>>          at
>>          java.base/java.lang.invoke.MethodHandle.standardString(MethodHandle.java:1611)
>>          at java.base/java.lang.invoke.MethodHandle.toString(MethodHandle.java:1608)
>>          at java.base/java.lang.String.valueOf(String.java:3365)
>>          at java.base/java.lang.invoke.CallSite.wrongTargetType(CallSite.java:203)
>>          at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:333)
>>          at
>>          java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:280)
>>          at
>>          java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:270)
>>          at fr.umlv.transmogrif.ImplMap/0x0000000801003c00.<init>(ImplMap.java:21)
>>          at fr.umlv.transmogrif.Main.main(Main.java:7)

From chegar at openjdk.java.net  Mon Nov 30 12:20:59 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 30 Nov 2020 12:20:59 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols
In-Reply-To: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
Message-ID: <Nb3T1W85nkapp8K5WaNo83AqYqokU2YfSsK-cmOq3Tw=.4ff787ce-f34d-48ad-829c-4f16da07041c@github.com>

On Fri, 27 Nov 2020 13:21:15 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
> -updating and moving tests into test/langtools, so that it is easier to run them.
> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
> -fixing the -Xprint annotation processor to print record component annotations.
> 
> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 965:

> 963:                            new NestMembers_attribute(attributeString, nestMembers));
> 964:         }
> 965:         if (header.recordComponents != null && !header.recordComponents.isEmpty()) {

I am not sure of the exact logic here, but it is perfectly fine for a record attribute to contain zero components, and for the class to still be considered a "record class". But maybe that is not all that significant here? I just want to call it out so that it is considered.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1480

From david.holmes at oracle.com  Mon Nov 30 12:44:32 2020
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 30 Nov 2020 22:44:32 +1000
Subject: Why having the wrong InnerClasses attribute is an issue for the
 VM ?
In-Reply-To: <370336411.232693.1606730676739.JavaMail.zimbra@u-pem.fr>
References: <2086523770.25097.1606720093577.JavaMail.zimbra@u-pem.fr>
 <9c9d6ecd-a1a3-4e7d-0a53-6f5d29660e27@oracle.com>
 <370336411.232693.1606730676739.JavaMail.zimbra@u-pem.fr>
Message-ID: <3e933ebc-8eb4-810b-91ee-3bb8ce5072f4@oracle.com>

On 30/11/2020 8:04 pm, forax at univ-mlv.fr wrote:
> ----- Mail original -----
>> De: "David Holmes" <david.holmes at oracle.com>
>> ?: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev" <core-libs-dev at openjdk.java.net>
>> Envoy?: Lundi 30 Novembre 2020 08:57:37
>> Objet: Re: Why having the wrong InnerClasses attribute is an issue for the VM ?
> 
>> On 30/11/2020 5:08 pm, Remi Forax wrote:
>>> I've forgotten a cast in an invokedynamic, hence a call to wrongTargetType,
>>> but in order to create the error message, MethodType.toString(), getSimpleName()
>>> is called and it fails because getDeclaringClass() verifies the InnerClasses
>>> attribute.
>>>
>>> For me InnerClasses was just an attribute for javac not something the VM should
>>> take care of,
>>> it seems that the VM strongly verifies this attribute and i wonder what is the
>>> reason behind that ?
>>
>>  From the VM code - InstanceKlass::compute_enclosing_class:
>>
>>    // Throws an exception if outer klass has not declared k as an inner
>> klass
>>    // We need evidence that each klass knows about the other, or else
>>    // the system could allow a spoof of an inner class to gain access
>> rights.
>>    Reflection::check_for_inner_class(outer_klass, this,
>> *inner_is_member, CHECK_NULL);
> 
> I don't understand how to spoof the InnerClasses attribute to gain access given that the access rights are not based on the InnerClasses attribute.

Good point.

That aside though, how do you answer the is_top_level_class question if 
the enclosed and enclosing classes disagree about the relationship?

David
-----

>>
>> David
> 
> R?mi
> 
>>
>>> regards,
>>> R?mi
>>>
>>> Exception in thread "main" java.lang.IncompatibleClassChangeError:
>>> fr.umlv.transmogrif.ImplMap and
>>> fr.umlv.transmogrif.ImplMap$Row/0x0000000801007400 disagree on InnerClasses
>>> attribute
>>>           at java.base/java.lang.Class.getDeclaringClass0(Native Method)
>>>           at java.base/java.lang.Class.isTopLevelClass(Class.java:1970)
>>>           at java.base/java.lang.Class.getSimpleBinaryName(Class.java:1955)
>>>           at java.base/java.lang.Class.getSimpleName0(Class.java:1835)
>>>           at java.base/java.lang.Class.getSimpleName(Class.java:1826)
>>>           at java.base/java.lang.Class.getSimpleName0(Class.java:1833)
>>>           at java.base/java.lang.Class.getSimpleName(Class.java:1826)
>>>           at java.base/java.lang.invoke.MethodType.toString(MethodType.java:895)
>>>           at java.base/java.lang.String.valueOf(String.java:3365)
>>>           at java.base/java.lang.StringBuilder.append(StringBuilder.java:169)
>>>           at
>>>           java.base/java.lang.invoke.MethodHandle.standardString(MethodHandle.java:1611)
>>>           at java.base/java.lang.invoke.MethodHandle.toString(MethodHandle.java:1608)
>>>           at java.base/java.lang.String.valueOf(String.java:3365)
>>>           at java.base/java.lang.invoke.CallSite.wrongTargetType(CallSite.java:203)
>>>           at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:333)
>>>           at
>>>           java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:280)
>>>           at
>>>           java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:270)
>>>           at fr.umlv.transmogrif.ImplMap/0x0000000801003c00.<init>(ImplMap.java:21)
>>>           at fr.umlv.transmogrif.Main.main(Main.java:7)

From forax at univ-mlv.fr  Mon Nov 30 12:53:00 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 30 Nov 2020 13:53:00 +0100 (CET)
Subject: Why having the wrong InnerClasses attribute is an issue for the
 VM ?
In-Reply-To: <3e933ebc-8eb4-810b-91ee-3bb8ce5072f4@oracle.com>
References: <2086523770.25097.1606720093577.JavaMail.zimbra@u-pem.fr>
 <9c9d6ecd-a1a3-4e7d-0a53-6f5d29660e27@oracle.com>
 <370336411.232693.1606730676739.JavaMail.zimbra@u-pem.fr>
 <3e933ebc-8eb4-810b-91ee-3bb8ce5072f4@oracle.com>
Message-ID: <612560003.385795.1606740780268.JavaMail.zimbra@u-pem.fr>

----- Mail original -----
> De: "David Holmes" <david.holmes at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoy?: Lundi 30 Novembre 2020 13:44:32
> Objet: Re: Why having the wrong InnerClasses attribute is an issue for the VM ?

> On 30/11/2020 8:04 pm, forax at univ-mlv.fr wrote:
>> ----- Mail original -----
>>> De: "David Holmes" <david.holmes at oracle.com>
>>> ?: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
>>> <core-libs-dev at openjdk.java.net>
>>> Envoy?: Lundi 30 Novembre 2020 08:57:37
>>> Objet: Re: Why having the wrong InnerClasses attribute is an issue for the VM ?
>> 
>>> On 30/11/2020 5:08 pm, Remi Forax wrote:
>>>> I've forgotten a cast in an invokedynamic, hence a call to wrongTargetType,
>>>> but in order to create the error message, MethodType.toString(), getSimpleName()
>>>> is called and it fails because getDeclaringClass() verifies the InnerClasses
>>>> attribute.
>>>>
>>>> For me InnerClasses was just an attribute for javac not something the VM should
>>>> take care of,
>>>> it seems that the VM strongly verifies this attribute and i wonder what is the
>>>> reason behind that ?
>>>
>>>  From the VM code - InstanceKlass::compute_enclosing_class:
>>>
>>>    // Throws an exception if outer klass has not declared k as an inner
>>> klass
>>>    // We need evidence that each klass knows about the other, or else
>>>    // the system could allow a spoof of an inner class to gain access
>>> rights.
>>>    Reflection::check_for_inner_class(outer_klass, this,
>>> *inner_is_member, CHECK_NULL);
>> 
>> I don't understand how to spoof the InnerClasses attribute to gain access given
>> that the access rights are not based on the InnerClasses attribute.
> 
> Good point.
> 
> That aside though, how do you answer the is_top_level_class question if
> the enclosed and enclosing classes disagree about the relationship?

Good question too,
only by looking to the information stored in the class that can be top_level or not, i suppose. 

> 
> David
> -----
> 

R?mi

>>>
>>> David
>> 
>> R?mi
>> 
>>>
>>>> regards,
>>>> R?mi
>>>>
>>>> Exception in thread "main" java.lang.IncompatibleClassChangeError:
>>>> fr.umlv.transmogrif.ImplMap and
>>>> fr.umlv.transmogrif.ImplMap$Row/0x0000000801007400 disagree on InnerClasses
>>>> attribute
>>>>           at java.base/java.lang.Class.getDeclaringClass0(Native Method)
>>>>           at java.base/java.lang.Class.isTopLevelClass(Class.java:1970)
>>>>           at java.base/java.lang.Class.getSimpleBinaryName(Class.java:1955)
>>>>           at java.base/java.lang.Class.getSimpleName0(Class.java:1835)
>>>>           at java.base/java.lang.Class.getSimpleName(Class.java:1826)
>>>>           at java.base/java.lang.Class.getSimpleName0(Class.java:1833)
>>>>           at java.base/java.lang.Class.getSimpleName(Class.java:1826)
>>>>           at java.base/java.lang.invoke.MethodType.toString(MethodType.java:895)
>>>>           at java.base/java.lang.String.valueOf(String.java:3365)
>>>>           at java.base/java.lang.StringBuilder.append(StringBuilder.java:169)
>>>>           at
>>>>           java.base/java.lang.invoke.MethodHandle.standardString(MethodHandle.java:1611)
>>>>           at java.base/java.lang.invoke.MethodHandle.toString(MethodHandle.java:1608)
>>>>           at java.base/java.lang.String.valueOf(String.java:3365)
>>>>           at java.base/java.lang.invoke.CallSite.wrongTargetType(CallSite.java:203)
>>>>           at java.base/java.lang.invoke.CallSite.makeSite(CallSite.java:333)
>>>>           at
>>>>           java.base/java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(MethodHandleNatives.java:280)
>>>>           at
>>>>           java.base/java.lang.invoke.MethodHandleNatives.linkCallSite(MethodHandleNatives.java:270)
>>>>           at fr.umlv.transmogrif.ImplMap/0x0000000801003c00.<init>(ImplMap.java:21)
> >>>           at fr.umlv.transmogrif.Main.main(Main.java:7)

From chegar at openjdk.java.net  Mon Nov 30 13:39:12 2020
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Mon, 30 Nov 2020 13:39:12 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v4]
In-Reply-To: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
Message-ID: <errcLY0kIB3FnhDO18G3aH0YepgWutAIheDPTkrvPfg=.4fe346ab-5eba-4230-9765-be1095f9f844@github.com>

> The ByteBuffers micro benchmark seems to be a little dated. 
> 
> It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 
> 
> This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 
> 
> 1. Remove allocation from the individual benchmarks - it just creates noise. 
> 2. Consolidate per-thread shared heap and direct buffers. 
> 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
> 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.

Chris Hegarty has updated the pull request incrementally with two additional commits since the last revision:

 - Add explicitly allocated heap carrier buffer tests
 - Replace Single with Loop

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1430/files
  - new: https://git.openjdk.java.net/jdk/pull/1430/files/814e1819..5ee5d8bf

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=03
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1430&range=02-03

  Stats: 407 lines in 1 file changed: 151 ins; 0 del; 256 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1430.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1430/head:pull/1430

PR: https://git.openjdk.java.net/jdk/pull/1430

From prappo at openjdk.java.net  Mon Nov 30 13:55:00 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 30 Nov 2020 13:55:00 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <1dB5tA98aqSqjaSJOUP56CCBB6SrKFl1jMJ6mq3Hxt4=.d2eeb855-f1d2-42d8-b031-b699d07058f6@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
 <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
 <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
 <TFCxfLxB7_iDyPbbSXJtWZZm4HOW_n4R66vMnNEzYvI=.1659cc00-17c8-4999-bbb7-b5c7516599b7@github.com>
 <m03pV9naVWuHcK_vDJPmbc475it1Z0rtCATTwsIOp3s=.ee0b9cf3-1bd3-4351-a40d-f19bd20850bd@github.com>
 <1dB5tA98aqSqjaSJOUP56CCBB6SrKFl1jMJ6mq3Hxt4=.d2eeb855-f1d2-42d8-b031-b699d07058f6@github.com>
Message-ID: <IFVwHeDBKn3R_NH5OQjINXcm6YnU7AczCoqeag6FqMM=.804ae57b-5835-4f2d-904f-d346b36cc4b4@github.com>

On Sat, 28 Nov 2020 08:42:52 GMT, John Lin <github.com+1290376+johnlinp at openjdk.org> wrote:

>> @johnlinp In any case, you'd also need to update the surrounding prose; we need to remove this:
>>  returning the current value or {@code null} if absent:```
>
> @pavelrappo Please see my updated CSR below. Thanks.
> 
> # Map::compute should have the implementation requirement match its default implementation
> 
> ## Summary
> 
> The implementation requirement of Map::compute does not match its default implementation. Besides, it has some other minor issues. We should fix it.
> 
> ## Problem
> 
> The documentation of the implementation requirements for Map::compute has the following problems:
> 1. It doesn't match its default implementation.
> 1. It lacks of the return statements for most of the if-else cases.
> 1. The indents are 3 spaces, while the convention is 4 spaces.
> 1. The if-else is overly complicated and can be simplified.
> 1. The surrounding prose contains incorrect statements.
> 
> ## Solution
> 
> Rewrite the documentation of Map::compute to match its default implementation and solve the above mentioned problems.
> 
> ## Specification
> 
> diff --git a/src/java.base/share/classes/java/util/Map.java b/src/java.base/share/classes/java/util/Map.java
> index b1de34b42a5..b30e3979259 100644
> --- a/src/java.base/share/classes/java/util/Map.java
> +++ b/src/java.base/share/classes/java/util/Map.java
> @@ -1107,23 +1107,17 @@ public interface Map<K, V> {
>       *
>       * @implSpec
>       * The default implementation is equivalent to performing the following
> -     * steps for this {@code map}, then returning the current value or
> -     * {@code null} if absent:
> +     * steps for this {@code map}:
>       *
>       * <pre> {@code
>       * V oldValue = map.get(key);
>       * V newValue = remappingFunction.apply(key, oldValue);
> -     * if (oldValue != null) {
> -     *    if (newValue != null)
> -     *       map.put(key, newValue);
> -     *    else
> -     *       map.remove(key);
> -     * } else {
> -     *    if (newValue != null)
> -     *       map.put(key, newValue);
> -     *    else
> -     *       return null;
> +     * if (newValue != null) {
> +     *     map.put(key, newValue);
> +     * } else if (oldValue != null || map.containsKey(key)) {
> +     *     map.remove(key);
>       * }
> +     * return newValue;
>       * }</pre>
>       *
>       * <p>The default implementation makes no guarantees about detecting if the

@johnlinp, thanks for updating the CSR draft; it is much better now.

@stuart-marks, I think we could further improve this snippet. This `if` statement seems to use an optimization:

if (oldValue != null || map.containsKey(key))

I don't think we should include an optimization into the specification unless that optimization also improves readability. Is this the case here? Could this be better?

if (map.containsKey(key))

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From jlahoda at openjdk.java.net  Mon Nov 30 14:21:16 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 30 Nov 2020 14:21:16 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v2]
In-Reply-To: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
Message-ID: <0IU-_p6RHP0YTRd5q17XiSKjstg63aZBK4GcvliVvTM=.0caf6919-4eb3-4c13-8447-a953e1185153@github.com>

> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
> -updating and moving tests into test/langtools, so that it is easier to run them.
> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
> -fixing the -Xprint annotation processor to print record component annotations.
> 
> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

Jan Lahoda has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8256950' of https://github.com/lahodaj/jdk into JDK-8256950
 - CreateSymbols should support records with no components.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1480/files
  - new: https://git.openjdk.java.net/jdk/pull/1480/files/c3696e72..7ce38709

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=00-01

  Stats: 54 lines in 2 files changed: 51 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1480.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480

PR: https://git.openjdk.java.net/jdk/pull/1480

From jlahoda at openjdk.java.net  Mon Nov 30 14:27:13 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 30 Nov 2020 14:27:13 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v3]
In-Reply-To: <Nb3T1W85nkapp8K5WaNo83AqYqokU2YfSsK-cmOq3Tw=.4ff787ce-f34d-48ad-829c-4f16da07041c@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
 <Nb3T1W85nkapp8K5WaNo83AqYqokU2YfSsK-cmOq3Tw=.4ff787ce-f34d-48ad-829c-4f16da07041c@github.com>
Message-ID: <bGe6Plxy_wMV2aISRvW1XiJoaWu9Wxr2JF_41pn-No8=.2e18b5f7-6f0b-4df0-98fd-bcb074be762e@github.com>

On Mon, 30 Nov 2020 12:17:46 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixing tests on Windows - normalizing line endings.
>
> make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 965:
> 
>> 963:                            new NestMembers_attribute(attributeString, nestMembers));
>> 964:         }
>> 965:         if (header.recordComponents != null && !header.recordComponents.isEmpty()) {
> 
> I am not sure of the exact logic here, but it is perfectly fine for a record attribute to contain zero components, and for the class to still be considered a "record class". But maybe that is not all that significant here? I just want to call it out so that it is considered.

Ah, right - fixed in:
https://github.com/openjdk/jdk/pull/1480/commits/e1ec2b7ff49e1307a348ad58b12e5ed39ebe7224

Thanks for the comment!

-------------

PR: https://git.openjdk.java.net/jdk/pull/1480

From jlahoda at openjdk.java.net  Mon Nov 30 14:27:11 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 30 Nov 2020 14:27:11 GMT
Subject: RFR: JDK-8256950: Add record attribute support to symbol
 generator CreateSymbols [v3]
In-Reply-To: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
References: <MhzeO6nzHkibmGS6oj-WKJwRRk6XycwUTSOGkoQZeCA=.acafda8c-df93-4d79-b162-fab5e34d4389@github.com>
Message-ID: <ZfeGVwwoe17k0ccnpt1oCaxL_SQ2D9OmOXAHn_R7QfU=.dfbbefa0-abd6-4c82-a7d0-ee05706a48ec@github.com>

> Adding support for record classes in the historical data for ct.sym. This includes a few changes not strictly needed for the change:
> -updating and moving tests into test/langtools, so that it is easier to run them.
> -fixing Record attribute reading in javac's ClassReader (used for tests, but seems like the proper thing to do anyway).
> -fixing the -Xprint annotation processor to print record component annotations.
> 
> Changes to jdk.jdeps' classfile library are needed so that the ct.sym creation works.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Fixing tests on Windows - normalizing line endings.

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/1480/files
  - new: https://git.openjdk.java.net/jdk/pull/1480/files/7ce38709..a3f79aba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=1480&range=01-02

  Stats: 6 lines in 2 files changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1480.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1480/head:pull/1480

PR: https://git.openjdk.java.net/jdk/pull/1480

From prappo at openjdk.java.net  Mon Nov 30 15:11:56 2020
From: prappo at openjdk.java.net (Pavel Rappo)
Date: Mon, 30 Nov 2020 15:11:56 GMT
Subject: RFR: 8247402: Documentation for Map::compute contains confusing
 implementation requirements
In-Reply-To: <IFVwHeDBKn3R_NH5OQjINXcm6YnU7AczCoqeag6FqMM=.804ae57b-5835-4f2d-904f-d346b36cc4b4@github.com>
References: <ZQNheDIQUwvUufEkds2N7kkr0kV6No0Cc9qIzX_FY04=.6624b5ff-dad7-4fd1-8677-51da85a5b149@github.com>
 <p-8_7BL98mDBPIliaMq9DIvIe0pzeV_D6aE0js-D2Rc=.3a44e9bc-24a8-4496-9d07-f77191c9b029@github.com>
 <pKnptPtrKVL4BIZV1gAM9EjAIzBlNgc38GRuOkx4dqo=.d8546d8d-68d8-42c9-9c7d-e153a0b4b1f6@github.com>
 <cXi4c8cnu_udIQ3Qeo29_I7hH5zvrri6LxaW-wN1ZEI=.ffb077b1-179b-4082-b0fb-fd3b3d400e93@github.com>
 <-XyT1-ph1l5tjmiP1QWQtsXV87mDFIxVQfnvFduZciY=.0d5370ef-f2ce-455f-906f-77cf1908ae02@github.com>
 <TFCxfLxB7_iDyPbbSXJtWZZm4HOW_n4R66vMnNEzYvI=.1659cc00-17c8-4999-bbb7-b5c7516599b7@github.com>
 <m03pV9naVWuHcK_vDJPmbc475it1Z0rtCATTwsIOp3s=.ee0b9cf3-1bd3-4351-a40d-f19bd20850bd@github.com>
 <1dB5tA98aqSqjaSJOUP56CCBB6SrKFl1jMJ6mq3Hxt4=.d2eeb855-f1d2-42d8-b031-b699d07058f6@github.com>
 <IFVwHeDBKn3R_NH5OQjINXcm6YnU7AczCoqeag6FqMM=.804ae57b-5835-4f2d-904f-d346b36cc4b4@github.com>
Message-ID: <_xofj9Juf4O7Mgi0GTuK81yn_91FD0d2g3Fe6eExBXg=.39a225aa-201d-46e7-8b08-cc6657574f87@github.com>

On Mon, 30 Nov 2020 13:52:17 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> @pavelrappo Please see my updated CSR below. Thanks.
>> 
>> # Map::compute should have the implementation requirement match its default implementation
>> 
>> ## Summary
>> 
>> The implementation requirement of Map::compute does not match its default implementation. Besides, it has some other minor issues. We should fix it.
>> 
>> ## Problem
>> 
>> The documentation of the implementation requirements for Map::compute has the following problems:
>> 1. It doesn't match its default implementation.
>> 1. It lacks of the return statements for most of the if-else cases.
>> 1. The indents are 3 spaces, while the convention is 4 spaces.
>> 1. The if-else is overly complicated and can be simplified.
>> 1. The surrounding prose contains incorrect statements.
>> 
>> ## Solution
>> 
>> Rewrite the documentation of Map::compute to match its default implementation and solve the above mentioned problems.
>> 
>> ## Specification
>> 
>> diff --git a/src/java.base/share/classes/java/util/Map.java b/src/java.base/share/classes/java/util/Map.java
>> index b1de34b42a5..b30e3979259 100644
>> --- a/src/java.base/share/classes/java/util/Map.java
>> +++ b/src/java.base/share/classes/java/util/Map.java
>> @@ -1107,23 +1107,17 @@ public interface Map<K, V> {
>>       *
>>       * @implSpec
>>       * The default implementation is equivalent to performing the following
>> -     * steps for this {@code map}, then returning the current value or
>> -     * {@code null} if absent:
>> +     * steps for this {@code map}:
>>       *
>>       * <pre> {@code
>>       * V oldValue = map.get(key);
>>       * V newValue = remappingFunction.apply(key, oldValue);
>> -     * if (oldValue != null) {
>> -     *    if (newValue != null)
>> -     *       map.put(key, newValue);
>> -     *    else
>> -     *       map.remove(key);
>> -     * } else {
>> -     *    if (newValue != null)
>> -     *       map.put(key, newValue);
>> -     *    else
>> -     *       return null;
>> +     * if (newValue != null) {
>> +     *     map.put(key, newValue);
>> +     * } else if (oldValue != null || map.containsKey(key)) {
>> +     *     map.remove(key);
>>       * }
>> +     * return newValue;
>>       * }</pre>
>>       *
>>       * <p>The default implementation makes no guarantees about detecting if the
>
> @johnlinp, thanks for updating the CSR draft; it is much better now.
> 
> @stuart-marks, I think we could further improve this snippet. This `if` statement seems to use an optimization:
> 
> if (oldValue != null || map.containsKey(key))
> 
> I don't think we should include an optimization into the specification unless that optimization also improves readability. Is this the case here? Could this be better?
> 
> if (map.containsKey(key))

I would even go as far as to rewrite that snippet like this:

if (newValue == null) {
    remove(key);
} else {
    put(key, newValue);
}
return newValue;

This rewrite is possible thanks to the following properties of `Map.remove(Object key)`:

1. A call with an unmapped `key` has no effect.
2. A call with a mapped `key` has the same semantics regardless of the value that this key is mapped to.

In particular, (2) covers `null` values.

To me, this rewrite reads better; however, I understand that readability is subjective and that snippets used in `@implSpec` might be subject to additional requirements.

-------------

PR: https://git.openjdk.java.net/jdk/pull/714

From erikj at openjdk.java.net  Mon Nov 30 15:35:56 2020
From: erikj at openjdk.java.net (Erik Joelsson)
Date: Mon, 30 Nov 2020 15:35:56 GMT
Subject: RFR: 8256541: Sort out what version of awk is used in the build
 system
In-Reply-To: <aLi_MW67IJzuS2nkWq2d1iy6tiJA-Ogx1xyzx_ANlEY=.91de1d8b-eb7b-4d36-a16a-dbf225e4d3c3@github.com>
References: <aLi_MW67IJzuS2nkWq2d1iy6tiJA-Ogx1xyzx_ANlEY=.91de1d8b-eb7b-4d36-a16a-dbf225e4d3c3@github.com>
Message-ID: <Vsz5hkDLdEF4YTyzwgH9VenndL-cbCmQoETI2GWIXBM=.144258f0-e333-497a-ae34-226b4d23fba0@github.com>

On Thu, 26 Nov 2020 20:58:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For historical reasons, there exists a variety of different implementations of awk: awk (the original implementation), gawk (the GNU version), nawk (new awk, iirc) and the lesser known mawk. 
> 
> Things are complicated by the fact that the original awk is seldom used, but instead gawk or nawk is typically symlinked to be named "awk". 
> 
> In terms of functionality there are very few differences. The original awk is most limited, while nawk and gawk is mostly replaceable. 
> 
> So the conditions for this is somewhat messy, but we manage impressively to mess it up even further. :-) 
> 
> We set up the following definitions: 
> `BASIC_REQUIRE_PROGS(NAWK, [nawk gawk awk])`
> `BASIC_REQUIRE_SPECIAL(AWK, [AC_PROG_AWK])`
> and `AC_PROG_AWK`, according to the documentation, "[c]heck for gawk, mawk, nawk, and awk, in that order". 
> 
> So, if you have nawk and awk (but no other) installed, both NAWK and AWK will be set to nawk. If you have only awk, both will be set to awk. The difference is if you have gawk installed, then NAWK will be nawk and AWK will be gawk. 
> 
> As an example, on my mac, I only have the original awk, so both AWK and NAWK will be awk. 
> 
> On my ubuntu box, things are even more confused. I have: 
> $ ls -l /usr/bin/*awk 
> lrwxrwxrwx 1 root root 21 Feb 6 10:36 awk -> /etc/alternatives/awk* 
> -rwxr-xr-x 1 root root 658072 Feb 11 2018 gawk* 
> -rwxr-xr-x 1 root root 3189 Feb 11 2018 igawk* 
> -rwxr-xr-x 1 root root 125416 Apr 3 2018 mawk* 
> lrwxrwxrwx 1 root root 22 Feb 6 10:37 nawk -> /etc/alternatives/nawk* 
> 
> $ ls -l /etc/alternatives/*awk 
> lrwxrwxrwx 1 root root 13 Feb 10 10:56 /etc/alternatives/awk -> /usr/bin/gawk* 
> lrwxrwxrwx 1 root root 13 Feb 10 10:56 /etc/alternatives/nawk -> /usr/bin/gawk* 
> 
> So awk, nawk and gawk all executes the same binary, i.e. gawk. Only mawk is different. So on that machine, AWK would be gawk and NAWK would be nawk, but both will execute gawk. 
> 
> I propose that we remove NAWK, and only use AWK, but we should stop using AC_PROG_AWK and define it in an order that is transparent to us. I recommend [gawk nawk awk], since on Linux systems nawk (as we've seen) is likely to be gawk under disguise anyway, so it's better to be clear about that. 
> 
> This reasoning assumes that the awk scripts we write are portable enough to be executed by any awk. If we run into any problem with this, we might have to restrict the variation of awks we support.
> 
> To make this work properly, I also needed to get rid of the awk launched by fixpath in CompileCommand. (This only worked. since AWK was not evolved to a full path by `AC_PROG_AWK`, but was only `awk`(or whatever). Otherwise this could not work with fixpath, so it was very much a hack to begin with...

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1470

From Roger.Riggs at oracle.com  Mon Nov 30 15:42:13 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 30 Nov 2020 10:42:13 -0500
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <YzWYkeHTDWOKFOCQlmPQUuKz4Qgz74ZSyB2Zfrn526U=.0fd2f014-22bc-4a95-a679-e9d262a42afc@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
 <2nUVJ9EKuqnoGTq1ZPCazHnmbIFAmLAJXjiCTY2dGeU=.130cb5a7-a189-4483-8832-74c67cdd39e1@github.com>
 <lqjOSgRCHdfPvSscZjNkzrj-vNdZkAWiiynksfBhQUs=.418f185a-9cf3-4a12-9506-5de6a152e6f5@github.com>
 <YzWYkeHTDWOKFOCQlmPQUuKz4Qgz74ZSyB2Zfrn526U=.0fd2f014-22bc-4a95-a679-e9d262a42afc@github.com>
Message-ID: <d198ca1e-7c57-8833-9830-ee9d9c9a97be@oracle.com>

Hi Naoto,

There are a couple of ways consistency can be achieved (and with what).

The existing hex conversions from strings to hex all delegate to 
Character.digit(ch, radix) which allows
both digits and letters beyond Latin1. (See Integer.valueOf(string, 
radix), Long.valueOf(string, radix), etc.)
For conversions from primitive to string they support conversion to the 
Latin1 characters "0-9", "a-f".

Making the conversion of strings to and from primitives consistent 
within HexFormat seems attractive
but would diverge from existing conversions and typically the non-Latin1 
digits and letters almost never appear.

There are uses cases (primarily in protocols and RFCs) where the 
hexadecimal characters are
specifed as "0-9", "a-f", and "A-F".? If HexFormat used 
Character.digit(string, radix) it would fail
to detect unexpected or? illegal characters and render HexFormat 
unusable for those use cases.

Though it would diverge from consistency with existing parsing of 
hexadecimal in Character, Integer, Long, etc,
I'll post an update to use the string parsing allowing only Latin1 
hexadecimal characters.

Comments?

Thanks, Roger



On 11/27/20 5:43 PM, Naoto Sato wrote:
> On Fri, 27 Nov 2020 16:57:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:
>
>>> src/java.base/share/classes/java/util/HexFormat.java line 853:
>>>
>>>> 851:      */
>>>> 852:     public int fromHexDigit(int ch) {
>>>> 853:         int value = Character.digit(ch, 16);
>>> Do we need to limit parsing the hex digit for only [0-9a-fA-F]? This would return `0` for other digits, say `fullwidth digit zero` (U+FF10)
>> The normal and conventional characters for hex encoding are limited to the ASCII/Latin1 range.
>> I don't know of any use case that would take advantage of non-ASCII characters.
> My point is that probably we should define `hexadecimal string` more clearly. In the class description, that exclusively means [0-9a-fA-F] in the context of formatting, but in the parsing, it allows non-ASCII digits. e.g.,
> HexFormat.of().parseHex("\uff10\uff11")
> Succeeds. I would like consistency here.
>
> -------------
>
> PR: https://git.openjdk.java.net/jdk/pull/482


From jlahoda at openjdk.java.net  Mon Nov 30 15:59:07 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 30 Nov 2020 15:59:07 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
Message-ID: <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>

> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
> 
> From the original PR:
> 
>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>> 
>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>> 
>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>> 
>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>> 
>>     * adding code to make sure that annotations can't be sealed
>> 
>>     * improving some tests
>> 
>> 
>> TIA
>> 
>> Related specs:
>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
> 
> This PR strives to reflect the review comments from 1227:
>  * adjustments to javadoc of j.l.Class methods
>  * package access checks in Class.getPermittedSubclasses()
>  * fixed to the narrowing conversion/castability as pointed out by Maurizio

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Improving getPermittedSubclasses javadoc.
 - Merge branch 'master' into JDK-8246778
 - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
 - Improving getPermittedSubclasses() javadoc.
 - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
 - Removing unnecessary file.
 - Tweaking javadoc.
 - Reflecting review comments w.r.t. narrowing conversion.
 - Improving checks in getPermittedSubclasses()
 - Merging master into JDK-8246778
 - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179

-------------

Changes: https://git.openjdk.java.net/jdk/pull/1483/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=1483&range=01
  Stats: 918 lines in 12 files changed: 837 ins; 9 del; 72 mod
  Patch: https://git.openjdk.java.net/jdk/pull/1483.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/1483/head:pull/1483

PR: https://git.openjdk.java.net/jdk/pull/1483

From jlahoda at openjdk.java.net  Mon Nov 30 15:59:09 2020
From: jlahoda at openjdk.java.net (Jan Lahoda)
Date: Mon, 30 Nov 2020 15:59:09 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <Z3AFytvDqAjrVEm6tnmJ5MzgynTJU9e6Kc8-u2K1R0c=.44f7ccbb-eae1-4920-8feb-2a26a27a769d@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <Z3AFytvDqAjrVEm6tnmJ5MzgynTJU9e6Kc8-u2K1R0c=.44f7ccbb-eae1-4920-8feb-2a26a27a769d@github.com>
Message-ID: <cxEgg9WpUs9_npjqYljnwDYGRlMcZrY5UkxDtgg8d5c=.3a374ec4-d80a-4c49-994f-75b411c001c1@github.com>

On Mon, 30 Nov 2020 09:55:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Improving getPermittedSubclasses javadoc.
>>  - Merge branch 'master' into JDK-8246778
>>  - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
>>  - Improving getPermittedSubclasses() javadoc.
>>  - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
>>  - Removing unnecessary file.
>>  - Tweaking javadoc.
>>  - Reflecting review comments w.r.t. narrowing conversion.
>>  - Improving checks in getPermittedSubclasses()
>>  - Merging master into JDK-8246778
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179
>
> src/java.base/share/classes/java/lang/Class.java line 4420:
> 
>> 4418:      * {@linkplain #getClassLoader() the defining class loader} of the current
>> 4419:      * {@code Class} object. If a name cannot be converted to the {@code Class}
>> 4420:      * instance, it is silently excluded from the result.
> 
> I think this paragraph will need a little bit of wordsmithing. The 3rd paragraph of getNestMembers might be useful to examine as it more clearly describes how the method attempts to "obtain" the Class object for each of the class names in the NestMembers attribute and maybe some of that wording could be used instead of using the term "convert".
> 
> Minor nit but the prevailing style for the @throws SecurityException is to align the description with the exception, probably best to keep it consistent if you can.

Thanks, I've tried to improve the javadoc here:
https://github.com/openjdk/jdk/pull/1483/commits/4d484179e6e4d64ed460b997d25b4dca5d964016

-------------

PR: https://git.openjdk.java.net/jdk/pull/1483

From ihse at openjdk.java.net  Mon Nov 30 16:37:55 2020
From: ihse at openjdk.java.net (Magnus Ihse Bursie)
Date: Mon, 30 Nov 2020 16:37:55 GMT
Subject: Integrated: 8256541: Sort out what version of awk is used in the
 build system
In-Reply-To: <aLi_MW67IJzuS2nkWq2d1iy6tiJA-Ogx1xyzx_ANlEY=.91de1d8b-eb7b-4d36-a16a-dbf225e4d3c3@github.com>
References: <aLi_MW67IJzuS2nkWq2d1iy6tiJA-Ogx1xyzx_ANlEY=.91de1d8b-eb7b-4d36-a16a-dbf225e4d3c3@github.com>
Message-ID: <W65cKKwxH43ew-S_ob2CvqxHCM0Js0NSRnZ9qOsPMnY=.1cd23a2f-a2a9-44e3-a572-1828430eeab6@github.com>

On Thu, 26 Nov 2020 20:58:38 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> For historical reasons, there exists a variety of different implementations of awk: awk (the original implementation), gawk (the GNU version), nawk (new awk, iirc) and the lesser known mawk. 
> 
> Things are complicated by the fact that the original awk is seldom used, but instead gawk or nawk is typically symlinked to be named "awk". 
> 
> In terms of functionality there are very few differences. The original awk is most limited, while nawk and gawk is mostly replaceable. 
> 
> So the conditions for this is somewhat messy, but we manage impressively to mess it up even further. :-) 
> 
> We set up the following definitions: 
> `BASIC_REQUIRE_PROGS(NAWK, [nawk gawk awk])`
> `BASIC_REQUIRE_SPECIAL(AWK, [AC_PROG_AWK])`
> and `AC_PROG_AWK`, according to the documentation, "[c]heck for gawk, mawk, nawk, and awk, in that order". 
> 
> So, if you have nawk and awk (but no other) installed, both NAWK and AWK will be set to nawk. If you have only awk, both will be set to awk. The difference is if you have gawk installed, then NAWK will be nawk and AWK will be gawk. 
> 
> As an example, on my mac, I only have the original awk, so both AWK and NAWK will be awk. 
> 
> On my ubuntu box, things are even more confused. I have: 
> $ ls -l /usr/bin/*awk 
> lrwxrwxrwx 1 root root 21 Feb 6 10:36 awk -> /etc/alternatives/awk* 
> -rwxr-xr-x 1 root root 658072 Feb 11 2018 gawk* 
> -rwxr-xr-x 1 root root 3189 Feb 11 2018 igawk* 
> -rwxr-xr-x 1 root root 125416 Apr 3 2018 mawk* 
> lrwxrwxrwx 1 root root 22 Feb 6 10:37 nawk -> /etc/alternatives/nawk* 
> 
> $ ls -l /etc/alternatives/*awk 
> lrwxrwxrwx 1 root root 13 Feb 10 10:56 /etc/alternatives/awk -> /usr/bin/gawk* 
> lrwxrwxrwx 1 root root 13 Feb 10 10:56 /etc/alternatives/nawk -> /usr/bin/gawk* 
> 
> So awk, nawk and gawk all executes the same binary, i.e. gawk. Only mawk is different. So on that machine, AWK would be gawk and NAWK would be nawk, but both will execute gawk. 
> 
> I propose that we remove NAWK, and only use AWK, but we should stop using AC_PROG_AWK and define it in an order that is transparent to us. I recommend [gawk nawk awk], since on Linux systems nawk (as we've seen) is likely to be gawk under disguise anyway, so it's better to be clear about that. 
> 
> This reasoning assumes that the awk scripts we write are portable enough to be executed by any awk. If we run into any problem with this, we might have to restrict the variation of awks we support.
> 
> To make this work properly, I also needed to get rid of the awk launched by fixpath in CompileCommand. (This only worked. since AWK was not evolved to a full path by `AC_PROG_AWK`, but was only `awk`(or whatever). Otherwise this could not work with fixpath, so it was very much a hack to begin with...

This pull request has now been integrated.

Changeset: a3e1980c
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/a3e1980c
Stats:     35 lines in 15 files changed: 4 ins; 9 del; 22 mod

8256541: Sort out what version of awk is used in the build system

Reviewed-by: erikj

-------------

PR: https://git.openjdk.java.net/jdk/pull/1470

From alanb at openjdk.java.net  Mon Nov 30 17:32:22 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 30 Nov 2020 17:32:22 GMT
Subject: RFR: 8159746: (proxy) Support for default methods [v7]
In-Reply-To: <7eMyBIGJbWmpHYlp1PbgHN01WpMHPoMzQVQlYObzszY=.ca82cb0a-3579-4fad-9ad3-160d03c5d5c2@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <7eMyBIGJbWmpHYlp1PbgHN01WpMHPoMzQVQlYObzszY=.ca82cb0a-3579-4fad-9ad3-160d03c5d5c2@github.com>
Message-ID: <U-kEY5KOGjyyebcKnlrJcCJ52W3Pa7i4noB1vdy_I5s=.fc8cc929-34af-4c5b-bbe7-8afe0a695613@github.com>

On Wed, 25 Nov 2020 22:24:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke
>> the given default method on the given proxy instance.
>> 
>> The implementation looks up a method handle for `invokespecial` instruction
>> as if called from with the proxy class as the caller, equivalent to calling
>> `X.super::m` where `X` is a proxy interface of the proxy class and
>> `X.super::m` will resolve to the specified default method.
>> 
>> The implementation will call a private static `proxyClassLookup(Lookup caller)`
>> method of the proxy class to obtain its private Lookup.  This private method
>> in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class
>> with full privilege access to use, or else `IllegalAccessException` will be
>> thrown.
>> 
>> This patch also proposes to define a proxy class in an unnamed module to
>> a dynamic module to strengthen encapsulation such that they are only
>> unconditionally exported from a named module but not open for deep reflective
>> access.  This only applies to the case if all the proxy interfaces are public
>> and in a package that is exported or open.
>> 
>> One dynamic module is created for each class loader that defines proxies.
>> The change changes the dynamic module to contain another package (same
>> name as the module) that is unconditionally exported and is opened to
>> `java.base` only.
>> 
>> There is no change to the package and module of the proxy class for
>> the following cases:
>> 
>> - if at least one proxy interface is non-public, then the proxy class is defined
>>   in the package and module of the non-public interfaces
>> - if at least one proxy is in a package that is non-exported and non-open,
>>   if all proxy interfaces are public, then the proxy class is defined in
>>   a non-exported, non-open package of a dynamic module.
>> 
>> The spec change is that a proxy class used to be defined in an unnamed
>> module, i.e. in a exported and open package, is defined in an unconditionally
>> exported but non-open package.  Programs that assume it to be open unconditionally
>> will be affected and cannot do deep reflection on such proxy classes.
>> 
>> Peter Levart contributed an initial prototype [1] (thanks Peter).  I think
>> the exceptions could be simplified as more checking should be done prior to
>> the invocation of the method handle like checking the types of the arguments
>> with the method type.  This approach avoids defining a public API
>> `protected Proxy::$$proxyClassLookup$$` method.  Instead it defines a
>> private static method that is restricted for Proxy class to use (by
>> taking a caller parameter to ensure it's a private lookup on Proxy class).
>> 
>> javadoc/specdiff:
>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/
>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/
>> 
>> [1]  http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html
>
> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>  - update copyright header
>  - clean up DefaultMethodProxy test
>  - Performance improvement contributed by plevart
>  - Clean up the patch.  Rename to
>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>  - move invokeDefaultMethod to InvocationHandler and throw IAE if access check fails
>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>  - minor tweak to the spec wording and impl
>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/5fcea495...d72d627f

src/java.base/share/classes/java/lang/reflect/Proxy.java line 1227:

> 1225:         if (proxyInterfaces.contains(declaringClass))
> 1226:             return declaringClass;
> 1227: 

It might be beneficial for future maintainers if you could include a comment here on the search order.

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From naoto.sato at oracle.com  Mon Nov 30 17:32:28 2020
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 30 Nov 2020 09:32:28 -0800
Subject: RFR: 8251989: Hex formatting and parsing utility [v10]
In-Reply-To: <d198ca1e-7c57-8833-9830-ee9d9c9a97be@oracle.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <ZafekFc2f5e6NXyZMAIWritKoItEI-gYjlPGNC_K2do=.20a2eeda-ce17-43bf-afa2-368332a81a11@github.com>
 <2nUVJ9EKuqnoGTq1ZPCazHnmbIFAmLAJXjiCTY2dGeU=.130cb5a7-a189-4483-8832-74c67cdd39e1@github.com>
 <lqjOSgRCHdfPvSscZjNkzrj-vNdZkAWiiynksfBhQUs=.418f185a-9cf3-4a12-9506-5de6a152e6f5@github.com>
 <YzWYkeHTDWOKFOCQlmPQUuKz4Qgz74ZSyB2Zfrn526U=.0fd2f014-22bc-4a95-a679-e9d262a42afc@github.com>
 <d198ca1e-7c57-8833-9830-ee9d9c9a97be@oracle.com>
Message-ID: <d84ecea3-1a00-b20a-4561-79e40cb2933d@oracle.com>

Hi Roger,

Thanks for your thought and I agree with you. Since this is a utility 
primarily meant for developers, not end users, limiting the "hexadecimal 
string/character" in Latin-1 seems reasonable.

Naoto

On 11/30/20 7:42 AM, Roger Riggs wrote:
> Hi Naoto,
> 
> There are a couple of ways consistency can be achieved (and with what).
> 
> The existing hex conversions from strings to hex all delegate to 
> Character.digit(ch, radix) which allows
> both digits and letters beyond Latin1. (See Integer.valueOf(string, 
> radix), Long.valueOf(string, radix), etc.)
> For conversions from primitive to string they support conversion to the 
> Latin1 characters "0-9", "a-f".
> 
> Making the conversion of strings to and from primitives consistent 
> within HexFormat seems attractive
> but would diverge from existing conversions and typically the non-Latin1 
> digits and letters almost never appear.
> 
> There are uses cases (primarily in protocols and RFCs) where the 
> hexadecimal characters are
> specifed as "0-9", "a-f", and "A-F".? If HexFormat used 
> Character.digit(string, radix) it would fail
> to detect unexpected or? illegal characters and render HexFormat 
> unusable for those use cases.
> 
> Though it would diverge from consistency with existing parsing of 
> hexadecimal in Character, Integer, Long, etc,
> I'll post an update to use the string parsing allowing only Latin1 
> hexadecimal characters.
> 
> Comments?
> 
> Thanks, Roger
> 
> 
> 
> On 11/27/20 5:43 PM, Naoto Sato wrote:
>> On Fri, 27 Nov 2020 16:57:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:
>>
>>>> src/java.base/share/classes/java/util/HexFormat.java line 853:
>>>>
>>>>> 851:????? */
>>>>> 852:???? public int fromHexDigit(int ch) {
>>>>> 853:???????? int value = Character.digit(ch, 16);
>>>> Do we need to limit parsing the hex digit for only [0-9a-fA-F]? This 
>>>> would return `0` for other digits, say `fullwidth digit zero` (U+FF10)
>>> The normal and conventional characters for hex encoding are limited 
>>> to the ASCII/Latin1 range.
>>> I don't know of any use case that would take advantage of non-ASCII 
>>> characters.
>> My point is that probably we should define `hexadecimal string` more 
>> clearly. In the class description, that exclusively means [0-9a-fA-F] 
>> in the context of formatting, but in the parsing, it allows non-ASCII 
>> digits. e.g.,
>> HexFormat.of().parseHex("\uff10\uff11")
>> Succeeds. I would like consistency here.
>>
>> -------------
>>
>> PR: https://git.openjdk.java.net/jdk/pull/482
> 

From alanb at openjdk.java.net  Mon Nov 30 17:42:22 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 30 Nov 2020 17:42:22 GMT
Subject: RFR: 8159746: (proxy) Support for default methods [v7]
In-Reply-To: <7eMyBIGJbWmpHYlp1PbgHN01WpMHPoMzQVQlYObzszY=.ca82cb0a-3579-4fad-9ad3-160d03c5d5c2@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <7eMyBIGJbWmpHYlp1PbgHN01WpMHPoMzQVQlYObzszY=.ca82cb0a-3579-4fad-9ad3-160d03c5d5c2@github.com>
Message-ID: <-_AF5wym5vHAZUZHOsiKEiiNNxxnaOxcJBWEA9jYXkg=.6607870e-8040-4688-ab17-02510ae109ae@github.com>

On Wed, 25 Nov 2020 22:24:40 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke
>> the given default method on the given proxy instance.
>> 
>> The implementation looks up a method handle for `invokespecial` instruction
>> as if called from with the proxy class as the caller, equivalent to calling
>> `X.super::m` where `X` is a proxy interface of the proxy class and
>> `X.super::m` will resolve to the specified default method.
>> 
>> The implementation will call a private static `proxyClassLookup(Lookup caller)`
>> method of the proxy class to obtain its private Lookup.  This private method
>> in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class
>> with full privilege access to use, or else `IllegalAccessException` will be
>> thrown.
>> 
>> This patch also proposes to define a proxy class in an unnamed module to
>> a dynamic module to strengthen encapsulation such that they are only
>> unconditionally exported from a named module but not open for deep reflective
>> access.  This only applies to the case if all the proxy interfaces are public
>> and in a package that is exported or open.
>> 
>> One dynamic module is created for each class loader that defines proxies.
>> The change changes the dynamic module to contain another package (same
>> name as the module) that is unconditionally exported and is opened to
>> `java.base` only.
>> 
>> There is no change to the package and module of the proxy class for
>> the following cases:
>> 
>> - if at least one proxy interface is non-public, then the proxy class is defined
>>   in the package and module of the non-public interfaces
>> - if at least one proxy is in a package that is non-exported and non-open,
>>   if all proxy interfaces are public, then the proxy class is defined in
>>   a non-exported, non-open package of a dynamic module.
>> 
>> The spec change is that a proxy class used to be defined in an unnamed
>> module, i.e. in a exported and open package, is defined in an unconditionally
>> exported but non-open package.  Programs that assume it to be open unconditionally
>> will be affected and cannot do deep reflection on such proxy classes.
>> 
>> Peter Levart contributed an initial prototype [1] (thanks Peter).  I think
>> the exceptions could be simplified as more checking should be done prior to
>> the invocation of the method handle like checking the types of the arguments
>> with the method type.  This approach avoids defining a public API
>> `protected Proxy::$$proxyClassLookup$$` method.  Instead it defines a
>> private static method that is restricted for Proxy class to use (by
>> taking a caller parameter to ensure it's a private lookup on Proxy class).
>> 
>> javadoc/specdiff:
>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/
>> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/
>> 
>> [1]  http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html
>
> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>  - update copyright header
>  - clean up DefaultMethodProxy test
>  - Performance improvement contributed by plevart
>  - Clean up the patch.  Rename to
>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>  - move invokeDefaultMethod to InvocationHandler and throw IAE if access check fails
>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>  - minor tweak to the spec wording and impl
>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/f4321c25...d72d627f

Overall, really good!

src/java.base/share/classes/java/lang/reflect/Proxy.java line 1281:

> 1279:      * @return a lookup for proxy class of this proxy instance
> 1280:      */
> 1281:     private static MethodHandles.Lookup proxyClassLookup(MethodHandles.Lookup caller, Class<?> proxyClass) {

The method description could be a bit clearer. It invokes the proxy's proxyClassLookup method to get a Lookup on the proxy class ("this proxy instance" is just a bit confusing as proxyClassLookup is static).
I guess the caller parameter isn't really needed as it could be crated in proxyClassLookup.

-------------

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/313

From github.com+10835776+stsypanov at openjdk.java.net  Mon Nov 30 17:45:59 2020
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, 30 Nov 2020 17:45:59 GMT
Subject: Integrated: 8254082: AbstractStringBuilder.insert(int dstOffset,
 CharSequence s, int start, int end) is missing fast-path for String
In-Reply-To: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
References: <vnn9sfdklIuyDSxAeeAI2KIbedvuwhfOxSIc4gyQfKY=.0e954b53-dec5-4e3d-bb79-387e06930139@github.com>
Message-ID: <QOyQpHnUYohVUlXUdynVXG1Mdzz9QpgJkMt_h89CmAw=.67995c15-1a7e-4f10-aebf-b23f49ad3ac3@github.com>

On Tue, 29 Sep 2020 14:28:52 GMT, ?????? ??????? <github.com+10835776+stsypanov at openjdk.org> wrote:

> Original mail: https://mail.openjdk.java.net/pipermail/core-libs-dev/2020-September/069197.html
> 
> Hello,
> 
> while working with `StringBuilder.insert()` I've spotted that its delegate `AbstractStringBuilder.insert()` is missing
> a fast-path for the most frequent case when its argument is `String`.
> 
> Previously they did similart optimization for `StirngBuilder.append(CharSequence, int, int)`,
> see https://bugs.openjdk.java.net/browse/JDK-8224986
> 
> I'd like to contribute a trivial patch that brings improvement for the case when SB's content is Latin1
> and inserted String is Latin1 as well.
> 
> To measure improvement I've used simple benchmark:
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> @Fork(jvmArgsAppend = {"-Xms2g", "-Xmx2g"})
> public class StringBuilderInsertBenchmark {
> 
>   @Benchmark
>   public StringBuilder insert(Data data) {
>     String string = data.string;
>     return new StringBuilder().append("ABC").insert(1, string, 1, data.length + 1);
>   }
> 
>   @State(Scope.Thread)
>   public static class Data {
>     String string;
> 
>     @Param({"true", "false"})
>     private boolean latin;
> 
>     @Param({"8", "64", "128", "1024"})
>     private int length;
> 
>     @Setup
>     public void setup() {
>       String alphabet = latin
>         ? "abcdefghijklmnopqrstuvwxyz"        // English
>         : "????????????????????????????????"; // Russian
> 
>       string = new RandomStringGenerator().randomString(alphabet, length + 2);
>     }
>   }
> }
> 
> public final class RandomStringGenerator {
> 
>   public String randomString(String alphabet, int length) {
>     char[] chars = alphabet.toCharArray();
> 
>     ThreadLocalRandom random = ThreadLocalRandom.current();
> 
>     char[] array = new char[length];
>     for (int i = 0; i < length; i++) {
>       array[i] = chars[random.nextInt(chars.length)];
>     }
> 
>     return new String(array);
>   }
> }
> Which gives
> 
>             (latin)  (length)       original       patched    Units
> insert         true         8    24.2 ?  0.1   22.2 ?  0.0    ns/op
> insert         true        64    53.8 ?  0.2   36.1 ?  0.1    ns/op
> insert         true       128    80.9 ?  0.2   44.6 ?  0.0    ns/op
> insert         true      1024   365.4 ?  0.5  109.8 ?  3.9    ns/op
> 
> insert        false         8    33.5 ?  0.5   32.3 ?  0.2    ns/op
> insert        false        64    73.2 ?  0.3   73.2 ?  0.2    ns/op
> insert        false       128   103.9 ?  0.6  103.3 ?  0.1    ns/op
> insert        false      1024   576.5 ?  4.8  569.5 ?  2.0    ns/op
> Patch is attached. As of tests tier1 and tier2 are ok.
> 
> With best regards,
> Sergey Tsypanov

This pull request has now been integrated.

Changeset: 6eb25d7c
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6eb25d7c
Stats:     41 lines in 2 files changed: 28 ins; 4 del; 9 mod

8254082: AbstractStringBuilder.insert(int dstOffset, CharSequence s, int start, int end) is missing fast-path for String

Reviewed-by: redestad

-------------

PR: https://git.openjdk.java.net/jdk/pull/402

From alanb at openjdk.java.net  Mon Nov 30 17:46:04 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 30 Nov 2020 17:46:04 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
Message-ID: <mcAIojzyR_RFcd5Hyu_Cc4JXNEYl4hRCwJBi3znQiI4=.19c71b67-d1bf-40be-9d4b-f1ee72f6832b@github.com>

On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Improving getPermittedSubclasses javadoc.
>  - Merge branch 'master' into JDK-8246778
>  - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
>  - Improving getPermittedSubclasses() javadoc.
>  - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
>  - Removing unnecessary file.
>  - Tweaking javadoc.
>  - Reflecting review comments w.r.t. narrowing conversion.
>  - Improving checks in getPermittedSubclasses()
>  - Merging master into JDK-8246778
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179

src/java.base/share/classes/java/lang/Class.java line 4412:

> 4410:      * The {@code Class} objects which can be obtained using this procedure
> 4411:      * are indicated by elements of the returned array. If a {@code Class} object
> 4412:      * cannot be obtained, it is silently ignored, and not included in the result

Thanks for the update, this reads much better.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1483

From mandy.chung at oracle.com  Mon Nov 30 18:16:25 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 30 Nov 2020 10:16:25 -0800
Subject: Lookup.defineAnonymousClass() vs indy
In-Reply-To: <1701503144.2305514.1606664054054.JavaMail.zimbra@u-pem.fr>
References: <1701503144.2305514.1606664054054.JavaMail.zimbra@u-pem.fr>
Message-ID: <9a1b76e2-a370-b185-4ee3-bcc243ac9ff5@oracle.com>

The implementation method to be invoked for this lambda is a static bridge method
taking this hidden class's instance as the parameter, i.e. a descriptor referencing
a hidden class, which will fail to resolve.


 ?0: #104 REF_invokeStatic java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
     Method arguments:
       #111 ()V
       #112 REF_invokeStatic HiddenClassWithIndy.lambda$test$0:(LHiddenClassWithIndy;)V
       #111 ()V


Now that a hidden class is a nestmate, should/can this bridge method be 
an instance method if this class is defined as a hidden class?

Mandy

On 11/29/20 7:34 AM, Remi Forax wrote:
> Hi Mandy, hi all,
> it seems that when defineAnonymousClass rewrites the currentClass, it doesn't work if there is an invokedynamic in the classfile, so defineHiddenClass fails with a VerifyError when the hidden class is verified.
>
> Here is an example showing the issue
> ---
> import java.io.IOException;
> import java.lang.invoke.MethodHandles;
>
> public class HiddenClassWithIndy {
>    public void test() {
>      var a = new HiddenClassWithIndy();
>      Runnable r = () -> System.out.println(a);
>    }
>
>    public static void main(String[] args) throws IOException, IllegalAccessException {
>      byte[] bytecode;
>      try(var input = HiddenClassWithIndy.class.getClassLoader().getResourceAsStream(HiddenClassWithIndy.class.getName().replace('.', '/') + ".class")) {
>        if (input == null) {
>          throw new AssertionError();
>        }
>        bytecode = input.readAllBytes();
>      }
>      var hiddenLookup = MethodHandles.lookup().defineHiddenClass(bytecode, true);
>    }
> }
>
> ---
> The error message:
> Exception in thread "main" java.lang.VerifyError: Bad type on operand stack
> Exception Details:
>    Location:
>      fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400.test()V @9: invokedynamic
>    Reason:
>      Type 'fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400' (current frame, stack[0]) is not assignable to 'fr/umlv/transmogrif/HiddenClassWithIndy'
>    Current Frame:
>      bci: @9
>      flags: { }
>      locals: { 'fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400', 'fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400' }
>      stack: { 'fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400' }
>    Bytecode:
>      0000000: bb00 0759 b700 094c 2bba 000a 0000 4db1
>      0000010:
>
> 	at java.base/java.lang.ClassLoader.defineClass0(Native Method)
> 	at java.base/java.lang.System$2.defineClass(System.java:2193)
> 	at java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClass(MethodHandles.java:2235)
> 	at java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClassAsLookup(MethodHandles.java:2216)
> 	at java.base/java.lang.invoke.MethodHandles$Lookup.defineHiddenClass(MethodHandles.java:1952)
> 	at fr.umlv.transmogrif.HiddenClassWithIndy.main(HiddenClassWithIndy.java:20)
>
> regards,
> R?mi


From alanb at openjdk.java.net  Mon Nov 30 18:17:01 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 30 Nov 2020 18:17:01 GMT
Subject: RFR: 8253751: Dependencies of automatic modules are not
 propagated through module layers [v2]
In-Reply-To: <EZj3hyIRaPbTGtHZ_vc9SvmFjsv7zdK_wFFjCP52kkU=.79444a5a-be26-4d3b-8dcd-b88308e43405@github.com>
References: <n98SGqqXdl4g8mQ4BAIfRhcIgjQZPcn-qQUdrTTKqc8=.48ffe4f9-5b67-48fc-871d-ad0328493dfd@github.com>
 <EZj3hyIRaPbTGtHZ_vc9SvmFjsv7zdK_wFFjCP52kkU=.79444a5a-be26-4d3b-8dcd-b88308e43405@github.com>
Message-ID: <uo6RMIOWqmheLNFyHio4ss5sRbVBewxCxqTVyDg0Hto=.9acae4c4-caf3-40fa-93bf-0f2b311bc6ba@github.com>

On Wed, 25 Nov 2020 22:09:11 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
>> 
>>  - Formatting nit
>>  - Merge
>>  - Merge
>>  - Merge
>>  - Add @bug to test
>>  - Fixed typo in comment
>>  - Merge
>>  - Merge
>>  - If module reads automatic module in parent configuration then reads all automatic modules
>
> src/java.base/share/classes/java/lang/module/Resolver.java line 580:
> 
>> 578:                     if (m2.descriptor().isAutomatic()) {
>> 579:                         m2.reads()
>> 580:                                 .stream()
> 
> Nit: not sure if this formatting is intentional or you meant `m2.reads().stream()` in one line (which I like better).

Thanks, I suspect I just hit Return and the IDE formatted it. Fixed now.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1391

From rriggs at openjdk.java.net  Mon Nov 30 18:56:02 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 30 Nov 2020 18:56:02 GMT
Subject: RFR: 8166026: refactor shell tests to java
In-Reply-To: <H2UZy1486X04VxMmEPt1dG78BSsv6F-qqhUNWMcpW4g=.08c502e1-d13c-4fa2-8174-1227072f7d63@github.com>
References: <H2UZy1486X04VxMmEPt1dG78BSsv6F-qqhUNWMcpW4g=.08c502e1-d13c-4fa2-8174-1227072f7d63@github.com>
Message-ID: <tL0YmUR_HscX63diNwhhUp5Xe_YlYMBUowABehD7lKY=.1593307c-07e2-4383-a394-6db787dc92df@github.com>

On Fri, 27 Nov 2020 18:50:19 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> @iignatev  could you please review? Thank you.
> 
> note to self:
> jtreg test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java

test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIo.java line 26:

> 24: import static java.lang.ProcessBuilder.Redirect.*;
> 25: 
> 26: class InheritIo {

The rename of the class is unnecessary and less readable. 
The function being tested is inheritIO and the test name should match. (As does the directory it is in).

test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java line 42:

> 40: 
> 41: public class InheritIoTest {
> 42: 

Having two classes and files with similar names is confusing.  TestInhieritIO and InheritIOTest.

Since InheritIO already has subclasses that are the ones being invoked; 
that leaves methods in InheritIO to have the test cases.

test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java line 40:

> 38:  */
> 39: public class UncaughtExceptionsTest {
> 40: 

As with InheritIO, the nested classes that are invoked can be included in a single .java file.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1484

From mchung at openjdk.java.net  Mon Nov 30 19:17:07 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 30 Nov 2020 19:17:07 GMT
Subject: RFR: 8159746: (proxy) Support for default methods [v7]
In-Reply-To: <U-kEY5KOGjyyebcKnlrJcCJ52W3Pa7i4noB1vdy_I5s=.fc8cc929-34af-4c5b-bbe7-8afe0a695613@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <7eMyBIGJbWmpHYlp1PbgHN01WpMHPoMzQVQlYObzszY=.ca82cb0a-3579-4fad-9ad3-160d03c5d5c2@github.com>
 <U-kEY5KOGjyyebcKnlrJcCJ52W3Pa7i4noB1vdy_I5s=.fc8cc929-34af-4c5b-bbe7-8afe0a695613@github.com>
Message-ID: <QYy6T1eg4hj441mFoOwRfgRxTP7_hwyetELnU4ScVSg=.50178c7c-c4c2-4aaa-9f6b-0ef746bb13e6@github.com>

On Mon, 30 Nov 2020 17:28:52 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mandy Chung has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>>  - update copyright header
>>  - clean up DefaultMethodProxy test
>>  - Performance improvement contributed by plevart
>>  - Clean up the patch.  Rename to
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>>  - move invokeDefaultMethod to InvocationHandler and throw IAE if access check fails
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into proxy-default-method
>>  - minor tweak to the spec wording and impl
>>  - ... and 15 more: https://git.openjdk.java.net/jdk/compare/1580f68b...d72d627f
>
> src/java.base/share/classes/java/lang/reflect/Proxy.java line 1227:
> 
>> 1225:         if (proxyInterfaces.contains(declaringClass))
>> 1226:             return declaringClass;
>> 1227: 
> 
> It might be beneficial for future maintainers if you could include a comment here on the search order.

What about:

+        // find the first proxy interface that inherits the default method
+        // i.e. the declaring class of the default method is a superinterface
+        // of the proxy interface

> src/java.base/share/classes/java/lang/reflect/Proxy.java line 1281:
> 
>> 1279:      * @return a lookup for proxy class of this proxy instance
>> 1280:      */
>> 1281:     private static MethodHandles.Lookup proxyClassLookup(MethodHandles.Lookup caller, Class<?> proxyClass) {
> 
> The method description could be a bit clearer. It invokes the proxy's proxyClassLookup method to get a Lookup on the proxy class ("this proxy instance" is just a bit confusing as proxyClassLookup is static).
> I guess the caller parameter isn't really needed as it could be crated in proxyClassLookup.

The caller parameter is just another level of defense.   I updated as:

     /**
-     * Returns a Lookup object for the lookup class which is the class of this
-     * proxy instance.
+     * This method invokes the proxy's proxyClassLookup method to get a
+     * Lookup on the proxy class.
      *
      * @return a lookup for proxy class of this proxy instance
      */

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From alanb at openjdk.java.net  Mon Nov 30 19:24:58 2020
From: alanb at openjdk.java.net (Alan Bateman)
Date: Mon, 30 Nov 2020 19:24:58 GMT
Subject: RFR: 8159746: (proxy) Support for default methods [v7]
In-Reply-To: <QYy6T1eg4hj441mFoOwRfgRxTP7_hwyetELnU4ScVSg=.50178c7c-c4c2-4aaa-9f6b-0ef746bb13e6@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
 <7eMyBIGJbWmpHYlp1PbgHN01WpMHPoMzQVQlYObzszY=.ca82cb0a-3579-4fad-9ad3-160d03c5d5c2@github.com>
 <U-kEY5KOGjyyebcKnlrJcCJ52W3Pa7i4noB1vdy_I5s=.fc8cc929-34af-4c5b-bbe7-8afe0a695613@github.com>
 <QYy6T1eg4hj441mFoOwRfgRxTP7_hwyetELnU4ScVSg=.50178c7c-c4c2-4aaa-9f6b-0ef746bb13e6@github.com>
Message-ID: <79JJS3gF1qLDvcFVpLhlCTfwzT3BQwFjuA4l9dMhZ9Y=.29d7b866-b043-42cb-bdfb-c0fea2550710@github.com>

On Mon, 30 Nov 2020 19:14:08 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/reflect/Proxy.java line 1281:
>> 
>>> 1279:      * @return a lookup for proxy class of this proxy instance
>>> 1280:      */
>>> 1281:     private static MethodHandles.Lookup proxyClassLookup(MethodHandles.Lookup caller, Class<?> proxyClass) {
>> 
>> The method description could be a bit clearer. It invokes the proxy's proxyClassLookup method to get a Lookup on the proxy class ("this proxy instance" is just a bit confusing as proxyClassLookup is static).
>> I guess the caller parameter isn't really needed as it could be crated in proxyClassLookup.
>
> The caller parameter is just another level of defense.   I updated as:
> 
>      /**
> -     * Returns a Lookup object for the lookup class which is the class of this
> -     * proxy instance.
> +     * This method invokes the proxy's proxyClassLookup method to get a
> +     * Lookup on the proxy class.
>       *
>       * @return a lookup for proxy class of this proxy instance
>       */

Much better, thanks!

-------------

PR: https://git.openjdk.java.net/jdk/pull/313

From kvn at openjdk.java.net  Mon Nov 30 19:35:56 2020
From: kvn at openjdk.java.net (Vladimir Kozlov)
Date: Mon, 30 Nov 2020 19:35:56 GMT
Subject: RFR: 8257164: Share LambdaForms for VH linkers/invokers.
In-Reply-To: <ZTi7JmIqKWVIB5qAHg21Hgu5JuWzJ-nIxYE4JgXMaII=.12f143de-3bad-48fd-badc-878813817518@github.com>
References: <ZTi7JmIqKWVIB5qAHg21Hgu5JuWzJ-nIxYE4JgXMaII=.12f143de-3bad-48fd-badc-878813817518@github.com>
Message-ID: <53n9zen0qzgiJdKDxHiVUIOPu_1waGe0pNsuVLpFdt4=.3c3facaf-1ce4-4152-a196-ccec11614d9f@github.com>

On Thu, 26 Nov 2020 13:13:43 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Introduce sharing of `LambdaForms` for `VarHandle` linkers and invokers.
> It reduces the number of LambdaForms needed at runtime.
> 
> Testing: tier1-4

Good.

-------------

Marked as reviewed by kvn (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1455

From psandoz at openjdk.java.net  Mon Nov 30 19:35:58 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 30 Nov 2020 19:35:58 GMT
Subject: RFR: 8257189: Handle concurrent updates of MH.form better
In-Reply-To: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com>
References: <1-iH7fvNLXAo2FzbAihuQV8PbDYiZsIHqZwPIcb6HxE=.d89f60fd-aad6-45bb-8704-363e299f96d8@github.com>
Message-ID: <WT09OVPAZ14hUg6i24GR2-vzqtX6ZDTTV-cQom-WnJ0=.f2535a9d-f14b-4547-a87a-fb30b5e028e6@github.com>

On Thu, 26 Nov 2020 21:23:16 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Concurrent updates may lead to redundant LambdaForms created and unnecessary class loading when those are compiled. 
> 
> Most notably, it severely affects MethodHandle customization: when a MethodHandle is called from multiple threads, every thread starts customization which takes enough time for other threads to join, but only one of those customizations will be picked.
> 
> Coordination between threads requesting the updates and letting a single thread proceed avoids the aforementioned problem. Moreover, there's no need to wait until the update in-flight is over: all other threads (except the one performing the update) can just proceed with the invocation using the existing MH.form. 
> 
> Testing:
> - manually monitored the behavior on a stress test from [JDK-8252049](https://bugs.openjdk.java.net/browse/JDK-8252049)
> - tier1-4

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1472

From mchung at openjdk.java.net  Mon Nov 30 19:36:02 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 30 Nov 2020 19:36:02 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
Message-ID: <1b8GH2EQDJvztsMclvskMZrsYcjnapSyqqGMGcutLTY=.b2ef4f3c-0e0d-43a9-9890-cdfbd12f53e9@github.com>

On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Improving getPermittedSubclasses javadoc.
>  - Merge branch 'master' into JDK-8246778
>  - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
>  - Improving getPermittedSubclasses() javadoc.
>  - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
>  - Removing unnecessary file.
>  - Tweaking javadoc.
>  - Reflecting review comments w.r.t. narrowing conversion.
>  - Improving checks in getPermittedSubclasses()
>  - Merging master into JDK-8246778
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179

src/java.base/share/classes/java/lang/Class.java line 4463:

> 4461:      * @apiNote
> 4462:      * Sealed class or interface has no relationship with
> 4463:      * {@linkplain Package#isSealed package sealing}.

Package sealing is legacy.  Remi suggests to take out this api note which sounds good to me.   

The API note in Package::isSealed has made this clear which has no relationship with sealed class or interface.

src/java.base/share/classes/java/lang/Class.java line 4415:

> 4413:      * array.
> 4414:      *
> 4415:      * @return an array of class objects of the permitted subclasses of this class or interface

Nit: s/class objects/{@code Class} objects/

-------------

PR: https://git.openjdk.java.net/jdk/pull/1483

From smarks at openjdk.java.net  Mon Nov 30 19:41:03 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 30 Nov 2020 19:41:03 GMT
Subject: Integrated: 8180352: Add Stream.toList() method
In-Reply-To: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
Message-ID: <MLOV1XNCkunhZnQ9b9Tqw93aUJY65b0LnmC7ThL09v0=.e1af4ed8-2f39-44fd-a5e2-c55d7fd30e0a@github.com>

On Tue, 3 Nov 2020 01:33:32 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> This change introduces a new terminal operation on Stream. This looks like a convenience method for Stream.collect(Collectors.toList()) or Stream.collect(Collectors.toUnmodifiableList()), but it's not. Having this method directly on Stream enables it to do what can't easily by done by a Collector. In particular, it allows the stream to deposit results directly into a destination array (even in parallel) and have this array be wrapped in an unmodifiable List without copying.
> 
> In the past we've kept most things from the Collections Framework as implementations of Collector, not directly on Stream, whereas only fundamental things (like toArray) appear directly on Stream. This is true of most Collections, but it does seem that List is special. It can be a thin wrapper around an array; it can handle generics better than arrays; and unlike an array, it can be made unmodifiable (shallowly immutable); and it can be value-based. See John Rose's comments in the bug report:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180352?focusedCommentId=14133065&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14133065
> 
> This operation is null-tolerant, which matches the rest of Streams. This isn't specified, though; a general statement about null handling in Streams is probably warranted at some point.
> 
> Finally, this method is indeed quite convenient (if the caller can deal with what this operation returns), as collecting into a List is the most common stream terminal operation.

This pull request has now been integrated.

Changeset: 41dbc139
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/41dbc139
Stats:     445 lines in 8 files changed: 358 ins; 42 del; 45 mod

8180352: Add Stream.toList() method

Reviewed-by: psandoz

-------------

PR: https://git.openjdk.java.net/jdk/pull/1026

From smarks at openjdk.java.net  Mon Nov 30 19:41:00 2020
From: smarks at openjdk.java.net (Stuart Marks)
Date: Mon, 30 Nov 2020 19:41:00 GMT
Subject: RFR: 8180352: Add Stream.toList() method [v4]
In-Reply-To: <r9Cg-BheUapolt4t-O_9E-oHCEAXYglKWggy0JGsStc=.16bcd50e-e3a0-47af-9010-e4f957992fde@github.com>
References: <ZgDsgH0rvnuZf-y40SBgJOlIEQxuQ9FCU2zGeEOVW2w=.9bc9828d-6c3f-4bb0-81f5-6f409d31e34d@github.com>
 <3N2Oa4dVVDShlyR-w1G8jWG7mNPL5utzKFdm0QWkM3Y=.0cee9962-8dfb-40f3-b9ae-e50ea8377ed3@github.com>
 <zUyJi1Y8IGbR3Hv50ZWy1OS0oqFycWzHLP7iVECLTec=.2b79a385-c78d-46b3-9b4b-2d5d7bc2d071@github.com>
 <nYmGmOTAId25YFeWQ0PJkB7j658prrjepUr8q9k7kUI=.ba169da0-e72b-4a16-9639-9c301b3d58bc@github.com>
 <Oxn7CirvPu4wJ2jdOQzjOT_KHZB6uZAcuHHQSdrQrWA=.07c41bdd-9fed-4cfc-bfec-3c0076266ffc@github.com>
 <5Z9HS6uHE3BQxPEpqsWtEsRZIXOM6NUdPN2BRs6lx0Y=.14a9075a-289a-44c8-8902-2cca976225fd@github.com>
 <J3Ed-nWa30Jz5DtGKSOTu6bA69OBaF5rcJL1-D3ZSiY=.95ceb273-92de-441e-aa82-5046e32a17b8@github.com>
 <r9Cg-BheUapolt4t-O_9E-oHCEAXYglKWggy0JGsStc=.16bcd50e-e3a0-47af-9010-e4f957992fde@github.com>
Message-ID: <9JcPL3NoC6dZPaALKKnTjt9oO-qaV2RvYuzzCXrPOBM=.48b39949-fbfa-405d-a201-5549f12124eb@github.com>

On Wed, 25 Nov 2020 17:14:43 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> An alternative with similar performance would be to do a Stream.toArray() and then copy that array into new Object[] and then wrap that copy with listFromTrustedArrayNullsAllowed(). The difference would be in the serialization format of the resulting List and maybe also in the access performance of resulting List (no indirection via the unmodifiableList wrapper and different type for JIT to speculate about). So if we want the resulting List to behave exactly the same in both implementations of toList(), then this alternative might be preferable. WDYT?
>
> Such alternative might also be faster using intrisified array copying method (here measuring just copying overhead):
> 
> Benchmark              (len)  Mode  Cnt       Score      Error  Units
> ToListBench.toList1       10  avgt   10      14.213 ?    0.061  ns/op
> ToListBench.toList1     1000  avgt   10     541.883 ?    3.845  ns/op
> ToListBench.toList1  1000000  avgt   10  753223.523 ? 4656.664  ns/op
> ToListBench.toList2       10  avgt   10       8.810 ?    0.052  ns/op
> ToListBench.toList2     1000  avgt   10     264.748 ?    0.807  ns/op
> ToListBench.toList2  1000000  avgt   10  349518.502 ? 3242.061  ns/op
> 
> https://gist.github.com/plevart/974b67b65210f8dd122773f481c0a603

I don't want to change the default implementation and its specification, for a couple reasons. First, this implementation won't be used in normal operation, as it's overridden by the JDK implementation. (I expect that stream extension libraries will be updated to override it as well.) Second, I'm quite uncomfortable using an internal method from within a default implementation. Right now this method is an agreement between the unmodifiable collections implementation and the ReferencePipeline implementation, and we have complete freedom to change this agreement at any time. If this internal method were used from a default implementation, its behavior would have to be specified in `@implSpec` somehow. Certainly one could write some very vague words for the specification that allow some freedom to make changes, but this has to choose between a better specification and more implementation freedom. I don't see the value in having to make this tradeoff at all.

An extra copy can be avoided via a private agreement between ArrayList and Arrays.asList, which should probably be done in any case.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1026

From psandoz at openjdk.java.net  Mon Nov 30 19:41:53 2020
From: psandoz at openjdk.java.net (Paul Sandoz)
Date: Mon, 30 Nov 2020 19:41:53 GMT
Subject: RFR: 8257164: Share LambdaForms for VH linkers/invokers.
In-Reply-To: <ZTi7JmIqKWVIB5qAHg21Hgu5JuWzJ-nIxYE4JgXMaII=.12f143de-3bad-48fd-badc-878813817518@github.com>
References: <ZTi7JmIqKWVIB5qAHg21Hgu5JuWzJ-nIxYE4JgXMaII=.12f143de-3bad-48fd-badc-878813817518@github.com>
Message-ID: <ZnuR0pz3PnyzL-bpCPL3abNEbUiCOHYA7dw8cLZtrao=.1ed967c0-b9b0-4b24-a7c5-a31267c2a2f8@github.com>

On Thu, 26 Nov 2020 13:13:43 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Introduce sharing of `LambdaForms` for `VarHandle` linkers and invokers.
> It reduces the number of LambdaForms needed at runtime.
> 
> Testing: tier1-4

Marked as reviewed by psandoz (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1455

From mchung at openjdk.java.net  Mon Nov 30 19:48:00 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 30 Nov 2020 19:48:00 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
Message-ID: <Q0QluOtDa_O6rcytLjro7EoDTvIUBgGNaBrTWaibg8M=.15d28b63-7381-404b-8ea2-2d7cc4f178de@github.com>

On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Improving getPermittedSubclasses javadoc.
>  - Merge branch 'master' into JDK-8246778
>  - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
>  - Improving getPermittedSubclasses() javadoc.
>  - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
>  - Removing unnecessary file.
>  - Tweaking javadoc.
>  - Reflecting review comments w.r.t. narrowing conversion.
>  - Improving checks in getPermittedSubclasses()
>  - Merging master into JDK-8246778
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179

src/java.base/share/classes/java/lang/Class.java line 4480:

> 4478:     }
> 4479: 
> 4480:     private native Class<?>[] getPermittedSubclasses0();

Does this JVM method return the permitted subclasses or subinterfaces with the following conditions enforced by JLS:

   - If a sealed class C belongs to a named module, then every class named in the permits clause of the declaration of C must belong to the same module as C
   - If a sealed class C belongs to an unnamed module, then every class named in the permits clause of the declaration of C must belong to the same package as C

Should the library implementation of `Class::getPermittedSubclasses` filter that if not done by `getPermittedSubclasses0`?

If the return array contains only classes as specified above, `checkPackageAccessForClasses` can be simplified.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1483

From forax at univ-mlv.fr  Mon Nov 30 20:25:51 2020
From: forax at univ-mlv.fr (forax at univ-mlv.fr)
Date: Mon, 30 Nov 2020 21:25:51 +0100 (CET)
Subject: Lookup.defineAnonymousClass() vs indy
In-Reply-To: <9a1b76e2-a370-b185-4ee3-bcc243ac9ff5@oracle.com>
References: <1701503144.2305514.1606664054054.JavaMail.zimbra@u-pem.fr>
 <9a1b76e2-a370-b185-4ee3-bcc243ac9ff5@oracle.com>
Message-ID: <158668471.728177.1606767951607.JavaMail.zimbra@u-pem.fr>

> De: "mandy chung" <mandy.chung at oracle.com>
> ?: "Remi Forax" <forax at univ-mlv.fr>, "core-libs-dev"
> <core-libs-dev at openjdk.java.net>
> Envoy?: Lundi 30 Novembre 2020 19:16:25
> Objet: Re: Lookup.defineAnonymousClass() vs indy

> The implementation method to be invoked for this lambda is a static bridge
> method
> taking this hidden class's instance as the parameter, i.e. a descriptor
> referencing
> a hidden class, which will fail to resolve.

>?0: #104 REF_invokeStatic
> ?java/lang/invoke/LambdaMetafactory.metafactory:(Ljava/lang/invoke/MethodHandles$Lookup;Ljava/lang/String;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodType;Ljava/lang/invoke/MethodHandle;Ljava/lang/invoke/MethodType;)Ljava/lang/invoke/CallSite;
>     Method arguments:
>       #111 ()V
>       #112 REF_invokeStatic HiddenClassWithIndy.lambda$test$0:(LHiddenClassWithIndy;)V
>       #111 ()V

> Now that a hidden class is a nestmate, should/can this bridge method be an
> instance method if this class is defined as a hidden class ?
Here the parameter of the lambda bridge is a captured local variable, it feels wrong to me to have s special case if the first captured local variable as the same type as the owning/enclosing class. 
And when you compile a class and generate the lambda bridge method, the compiler has no idea if the class will be used as an hidden class or not. 

The real question is why the descriptor is not rewritten to replace the owning class by the hidden class when lookup.defineHiddenClass is called, i believe this is the behavior of unsafe.defineAnonymousClass. 

> Mandy
R?mi 

> On 11/29/20 7:34 AM, Remi Forax wrote:

>> Hi Mandy, hi all,
>> it seems that when defineAnonymousClass rewrites the currentClass, it doesn't
>> work if there is an invokedynamic in the classfile, so defineHiddenClass fails
>> with a VerifyError when the hidden class is verified.

>> Here is an example showing the issue
>> ---
>> import java.io.IOException;
>> import java.lang.invoke.MethodHandles;

>> public class HiddenClassWithIndy {
>>   public void test() {
>>     var a = new HiddenClassWithIndy();
>>     Runnable r = () -> System.out.println(a);
>>   }

>>  public static void main(String[] args) throws IOException,
>>   IllegalAccessException {
>>     byte[] bytecode;
>>    try(var input =
>>    HiddenClassWithIndy.class.getClassLoader().getResourceAsStream(HiddenClassWithIndy.class.getName().replace('.',
>>     '/') + ".class")) {
>>       if (input == null) {
>>         throw new AssertionError();
>>       }
>>       bytecode = input.readAllBytes();
>>     }
>>     var hiddenLookup = MethodHandles.lookup().defineHiddenClass(bytecode, true);
>>   }
>> }

>> ---
>> The error message:
>> Exception in thread "main" java.lang.VerifyError: Bad type on operand stack
>> Exception Details:
>>   Location:
>>    fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400.test()V @9:
>>     invokedynamic
>>   Reason:
>>    Type 'fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400' (current
>>     frame, stack[0]) is not assignable to 'fr/umlv/transmogrif/HiddenClassWithIndy'
>>   Current Frame:
>>     bci: @9
>>     flags: { }
>>    locals: { 'fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400',
>>     'fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400' }
>>     stack: { 'fr/umlv/transmogrif/HiddenClassWithIndy+0x0000000801002400' }
>>   Bytecode:
>>     0000000: bb00 0759 b700 094c 2bba 000a 0000 4db1
>>     0000010:

>> 	at java.base/java.lang.ClassLoader.defineClass0(Native Method)
>> 	at java.base/java.lang.System$2.defineClass(System.java:2193)
>>	at
>> 	java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClass(MethodHandles.java:2235)
>>	at
>> 	java.base/java.lang.invoke.MethodHandles$Lookup$ClassDefiner.defineClassAsLookup(MethodHandles.java:2216)
>>	at
>> 	java.base/java.lang.invoke.MethodHandles$Lookup.defineHiddenClass(MethodHandles.java:1952)
>> 	at fr.umlv.transmogrif.HiddenClassWithIndy.main(HiddenClassWithIndy.java:20)

>> regards,
>> R?mi

From mandy.chung at oracle.com  Mon Nov 30 20:38:39 2020
From: mandy.chung at oracle.com (Mandy Chung)
Date: Mon, 30 Nov 2020 12:38:39 -0800
Subject: Lookup.defineAnonymousClass() vs indy
In-Reply-To: <158668471.728177.1606767951607.JavaMail.zimbra@u-pem.fr>
References: <1701503144.2305514.1606664054054.JavaMail.zimbra@u-pem.fr>
 <9a1b76e2-a370-b185-4ee3-bcc243ac9ff5@oracle.com>
 <158668471.728177.1606767951607.JavaMail.zimbra@u-pem.fr>
Message-ID: <f1203936-64f3-60fc-2528-a4d39713536e@oracle.com>



On 11/30/20 12:25 PM, forax at univ-mlv.fr wrote:
> The real question is why the descriptor is not rewritten to replace 
> the owning class by the hidden class when lookup.defineHiddenClass is 
> called, i believe this is the behavior of unsafe.defineAnonymousClass.

JVM does not do any magic for hidden classes which is a feature, not a 
bug.?? A hidden class _cannot be named_ in any descriptor.

The only adjustment for hidden classes, compared to normal class, after 
a hidden class C is derived and linked by JVM is that:
(1) During verification, whenever it is necessary to load the class 
named CN, the attempt succeeds, producing class C. No request is made of 
any class loader.
(2) On any attempt to resolve the entry in the run-time constant pool 
indicated by `this_class`, the symbolic reference is considered to be 
resolved to C and resolution always succeeds immediately.


Mandy

From mchung at openjdk.java.net  Mon Nov 30 20:49:02 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 30 Nov 2020 20:49:02 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
Message-ID: <bxzzTy1Ak8k5oJ1WjXPS17gNpz4JGzeV0stkZgOe7Kk=.123245b5-22ed-4477-b0a3-5e1b3d5bcdec@github.com>

On Mon, 30 Nov 2020 15:59:07 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This pull request replaces https://github.com/openjdk/jdk/pull/1227.
>> 
>> From the original PR:
>> 
>>> Please review the code for the second iteration of sealed classes. In this iteration we are:
>>> 
>>>     * Enhancing narrowing reference conversion to allow for stricter checking of cast conversions with respect to sealed type hierarchies
>>> 
>>>     * Also local classes are not considered when determining implicitly declared permitted direct subclasses of a sealed class or sealed interface
>>> 
>>>     * renaming Class::permittedSubclasses to Class::getPermittedSubclasses, still in the same method, the return type has been changed to Class<?>[] instead of the previous ClassDesc[]
>>> 
>>>     * adding code to make sure that annotations can't be sealed
>>> 
>>>     * improving some tests
>>> 
>>> 
>>> TIA
>>> 
>>> Related specs:
>>> [Sealed Classes JSL](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jls.html)
>>> [Sealed Classes JVMS](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/sealed-classes-jvms.html)
>>> [Additional: Contextual Keywords](http://cr.openjdk.java.net/~gbierman/jep397/jep397-20201104/specs/contextual-keywords-jls.html)
>> 
>> This PR strives to reflect the review comments from 1227:
>>  * adjustments to javadoc of j.l.Class methods
>>  * package access checks in Class.getPermittedSubclasses()
>>  * fixed to the narrowing conversion/castability as pointed out by Maurizio
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Improving getPermittedSubclasses javadoc.
>  - Merge branch 'master' into JDK-8246778
>  - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
>  - Improving getPermittedSubclasses() javadoc.
>  - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
>  - Removing unnecessary file.
>  - Tweaking javadoc.
>  - Reflecting review comments w.r.t. narrowing conversion.
>  - Improving checks in getPermittedSubclasses()
>  - Merging master into JDK-8246778
>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179

src/java.base/share/classes/java/lang/Class.java line 3042:

> 3040:             for (Class<?> c : classes) {
> 3041:                 // skip the package access check on a proxy class in default proxy package
> 3042:                 if (!Proxy.isProxyClass(c) || ReflectUtil.isNonPublicProxyClass(c)) {

If a sealed class is in a named module, the permitted subclasses/subinterfaces are in the same module as the sealed class.  If a sealed class is in an unnamed module, it will be in the same runtime package as the sealed class.   A proxy class is dynamically generated and not intended for statically named in `permits` clause of a sealed class`.  It can be in a different module or different package.  So a permitted subclass or interface should never be a proxy class. 

So the package access check for permitted subclasses/subinterfaces can be simplified.  I would suggest this check be inlined in `getPermittedSubclasses` as follows:

      SecurityManager sm = System.getSecurityManager();
        if (subclasses.length > 0 && sm != null) {
            ClassLoader ccl = ClassLoader.getClassLoader(Reflection.getCallerClass());
            ClassLoader cl = getClassLoader0();
            if (ReflectUtil.needsPackageAccessCheck(ccl, cl)) {
                Set<String> packages = new HashSet<>();
                for (Class<?> c : subclasses) {
                    if (Proxy.isProxyClass(c))
                        throw new InternalError("a permitted subclass should not be a proxy class: " + c);
                    String pkg = c.getPackageName();
                    if (!pkg.isEmpty())
                        packages.add(pkg);
                }
                for (String pkg : packages) {
                    sm.checkPackageAccess(pkg);
                }
            }
        }

-------------

PR: https://git.openjdk.java.net/jdk/pull/1483

From mchung at openjdk.java.net  Mon Nov 30 20:55:19 2020
From: mchung at openjdk.java.net (Mandy Chung)
Date: Mon, 30 Nov 2020 20:55:19 GMT
Subject: RFR: 8159746: (proxy) Support for default methods [v8]
In-Reply-To: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
References: <kw2VXh3vTFf1zgfd4biXA41OKffZ5oU7KT23tXAxgUA=.bcf14ffc-4dba-4c9c-8754-184172c5acbd@github.com>
Message-ID: <EO8jVeaqOEO9M_iaMjHGGogQWyRf8jXshftXAQ0Uz5A=.1cc30a33-a1b2-419c-9031-0dbe5c799993@github.com>

> This proposes a new static `Proxy::invokeDefaultMethod` method to invoke
> the given default method on the given proxy instance.
> 
> The implementation looks up a method handle for `invokespecial` instruction
> as if called from with the proxy class as the caller, equivalent to calling
> `X.super::m` where `X` is a proxy interface of the proxy class and
> `X.super::m` will resolve to the specified default method.
> 
> The implementation will call a private static `proxyClassLookup(Lookup caller)`
> method of the proxy class to obtain its private Lookup.  This private method
> in the proxy class only allows a caller Lookup on java.lang.reflect.Proxy class
> with full privilege access to use, or else `IllegalAccessException` will be
> thrown.
> 
> This patch also proposes to define a proxy class in an unnamed module to
> a dynamic module to strengthen encapsulation such that they are only
> unconditionally exported from a named module but not open for deep reflective
> access.  This only applies to the case if all the proxy interfaces are public
> and in a package that is exported or open.
> 
> One dynamic module is created for each class loader that defines proxies.
> The change changes the dynamic module to contain another package (same
> name as the module) that is unconditionally exported and is opened to
> `java.base` only.
> 
> There is no change to the package and module of the proxy class for
> the following cases:
> 
> - if at least one proxy interface is non-public, then the proxy class is defined
>   in the package and module of the non-public interfaces
> - if at least one proxy is in a package that is non-exported and non-open,
>   if all proxy interfaces are public, then the proxy class is defined in
>   a non-exported, non-open package of a dynamic module.
> 
> The spec change is that a proxy class used to be defined in an unnamed
> module, i.e. in a exported and open package, is defined in an unconditionally
> exported but non-open package.  Programs that assume it to be open unconditionally
> will be affected and cannot do deep reflection on such proxy classes.
> 
> Peter Levart contributed an initial prototype [1] (thanks Peter).  I think
> the exceptions could be simplified as more checking should be done prior to
> the invocation of the method handle like checking the types of the arguments
> with the method type.  This approach avoids defining a public API
> `protected Proxy::$$proxyClassLookup$$` method.  Instead it defines a
> private static method that is restricted for Proxy class to use (by
> taking a caller parameter to ensure it's a private lookup on Proxy class).
> 
> javadoc/specdiff:
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/api/
> http://cr.openjdk.java.net/~mchung/jdk16/webrevs/8159746/specdiff/
> 
> [1]  http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-June/041629.html

Mandy Chung has updated the pull request incrementally with one additional commit since the last revision:

  Improve comments per Alan's feedback

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/313/files
  - new: https://git.openjdk.java.net/jdk/pull/313/files/d72d627f..bb23cfa8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=07
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=313&range=06-07

  Stats: 17 lines in 1 file changed: 7 ins; 1 del; 9 mod
  Patch: https://git.openjdk.java.net/jdk/pull/313.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/313/head:pull/313

PR: https://git.openjdk.java.net/jdk/pull/313

From rriggs at openjdk.java.net  Mon Nov 30 20:56:17 2020
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Mon, 30 Nov 2020 20:56:17 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v12]
In-Reply-To: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
Message-ID: <y1I6KuqGRceeUg1GY77XXmyuDES4I2JMrBk4PaqUr4Y=.45b7b10e-afc7-4b6b-801a-9b65313c3901@github.com>

> java.util.HexFormat utility:
> 
>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>  - Immutable and thread safe, a "value-based" class
> 
> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
> 
> Review comments and suggestions welcome.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Clarified hexadecimal characters used in converting from characters to values to be strictly 0-9, a-f, and A-F.
  Added a test to verify isHexDigit and fromHexDigit for the entire range of chars

-------------

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/482/files
  - new: https://git.openjdk.java.net/jdk/pull/482/files/29f9bf7b..a1ce9d7c

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=11
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=482&range=10-11

  Stats: 46 lines in 2 files changed: 24 ins; 0 del; 22 mod
  Patch: https://git.openjdk.java.net/jdk/pull/482.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/482/head:pull/482

PR: https://git.openjdk.java.net/jdk/pull/482

From bpb at openjdk.java.net  Mon Nov 30 20:57:03 2020
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 30 Nov 2020 20:57:03 GMT
Subject: RFR: 8257074 Update the ByteBuffers micro benchmark [v4]
In-Reply-To: <errcLY0kIB3FnhDO18G3aH0YepgWutAIheDPTkrvPfg=.4fe346ab-5eba-4230-9765-be1095f9f844@github.com>
References: <9w1Ut1qQWUq8nY6uSKt6Cp7nizh_eZOxo3FgSUTlExM=.09e6e0c6-e442-46bf-b313-8c6e6544aa8a@github.com>
 <errcLY0kIB3FnhDO18G3aH0YepgWutAIheDPTkrvPfg=.4fe346ab-5eba-4230-9765-be1095f9f844@github.com>
Message-ID: <4QlCNtToXuqjt-0lnwZgVwjkEr04wWmh_AYvQLOq2BA=.38b61f48-c633-488a-a9b0-8137346013c5@github.com>

On Mon, 30 Nov 2020 13:39:12 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> The ByteBuffers micro benchmark seems to be a little dated. 
>> 
>> It should be a useful resource to leverage when analysing the performance impact of any potential implementation changes in the byte buffer classes. More specifically, the impact of such changes on the performance of sharp memory access operations. 
>> 
>> This issue proposes to update the benchmark in the following ways to meet the aforementioned use-case: 
>> 
>> 1. Remove allocation from the individual benchmarks - it just creates noise. 
>> 2. Consolidate per-thread shared heap and direct buffers. 
>> 3. All scenarios now use absolute memory access operations - so no state of the shared buffers is considered. 
>> 4. Provide more reasonable default fork, warmup, etc, out-of-the-box. 
>> 5. There seems to have been an existing bug in the test where the size parameter was not always considered - this is now fixed.
>
> Chris Hegarty has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Add explicitly allocated heap carrier buffer tests
>  - Replace Single with Loop

Marked as reviewed by bpb (Reviewer).

-------------

PR: https://git.openjdk.java.net/jdk/pull/1430

From hseigel at openjdk.java.net  Mon Nov 30 20:59:59 2020
From: hseigel at openjdk.java.net (Harold Seigel)
Date: Mon, 30 Nov 2020 20:59:59 GMT
Subject: RFR: 8246778: Compiler implementation for Sealed Classes (Second
 Preview) [v2]
In-Reply-To: <Q0QluOtDa_O6rcytLjro7EoDTvIUBgGNaBrTWaibg8M=.15d28b63-7381-404b-8ea2-2d7cc4f178de@github.com>
References: <RD0R1-XgGc-sCqpBg8Dbm-jItA744Z2TU2WvOyoPgjA=.54edd61a-203b-493f-80fa-1370153b43cf@github.com>
 <U9FYl1yK5hYpeYTvTkPLsjLxLCsZcZTL0zRhxBz0bTk=.4da411e4-5dac-48b5-8b39-3b47508abe8e@github.com>
 <Q0QluOtDa_O6rcytLjro7EoDTvIUBgGNaBrTWaibg8M=.15d28b63-7381-404b-8ea2-2d7cc4f178de@github.com>
Message-ID: <9cyMSNayyu63LkCt6r1Ltrzzv7TPvcsity5IYimZNa4=.f35daee0-3c52-4844-8354-d4b0507c57ff@github.com>

On Mon, 30 Nov 2020 19:44:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Improving getPermittedSubclasses javadoc.
>>  - Merge branch 'master' into JDK-8246778
>>  - Moving checkPackageAccess from getPermittedSubclasses to a separate method.
>>  - Improving getPermittedSubclasses() javadoc.
>>  - Enhancing the Class.getPermittedSubclasses() test to verify behavior both for sealed classes in named and unnamed modules.
>>  - Removing unnecessary file.
>>  - Tweaking javadoc.
>>  - Reflecting review comments w.r.t. narrowing conversion.
>>  - Improving checks in getPermittedSubclasses()
>>  - Merging master into JDK-8246778
>>  - ... and 2 more: https://git.openjdk.java.net/jdk/compare/6e006223...4d484179
>
> src/java.base/share/classes/java/lang/Class.java line 4480:
> 
>> 4478:     }
>> 4479: 
>> 4480:     private native Class<?>[] getPermittedSubclasses0();
> 
> Does this JVM method return the permitted subclasses or subinterfaces with the following conditions enforced by JLS:
> 
>    - If a sealed class C belongs to a named module, then every class named in the permits clause of the declaration of C must belong to the same module as C
>    - If a sealed class C belongs to an unnamed module, then every class named in the permits clause of the declaration of C must belong to the same package as C
> 
> I didn't check the VM implementation.
> 
> If the return array contains only classes as specified above, `checkPackageAccessForClasses` can be simplified.

The JVM method that returns the permitted subclasses (and interfaces) does not weed out permitted subclasses based on the above module requirements.  It returns all the classes listed in the PermittedSubclasses attribute that it is able to load.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1483

From iignatyev at openjdk.java.net  Mon Nov 30 21:12:56 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 30 Nov 2020 21:12:56 GMT
Subject: RFR: 8256894: define test groups
In-Reply-To: <rwh0Swv_VjVGaqDDZykaerZmD9IbB6Ix6MMEu1cIflg=.dbb2920b-8687-481f-b90a-937672374100@github.com>
References: <rwh0Swv_VjVGaqDDZykaerZmD9IbB6Ix6MMEu1cIflg=.dbb2920b-8687-481f-b90a-937672374100@github.com>
Message-ID: <dSNFN_j4gqDqE8GdjmXwzqpYU7eSjFgpkhNiyAt5gY4=.c05084d3-a778-49c2-b4c6-c5cbe5e4133e@github.com>

On Tue, 24 Nov 2020 16:13:59 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> Defined new test groups as defined in ticket. @fguallini

@frkator, you will need to open a new JBS ticket for this change.

test/jdk/TEST.groups line 326:

> 324:     :jdk_text \
> 325:     :core_tools \
> 326:     :jdk_other 

it would seem you have introduced a trailing space

-------------

Changes requested by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1416

From iignatyev at openjdk.java.net  Mon Nov 30 21:12:58 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 30 Nov 2020 21:12:58 GMT
Subject: RFR: 8256894: define test groups
In-Reply-To: <nbKqHC6IBCjR6PwCEBFpJT8JJ3FKMNZjs5eWx2A9dmw=.c42c95dd-60cd-4fbf-bb01-738cf3f4d499@github.com>
References: <rwh0Swv_VjVGaqDDZykaerZmD9IbB6Ix6MMEu1cIflg=.dbb2920b-8687-481f-b90a-937672374100@github.com>
 <gwdmcgPWl0tIFTbqkeP_Y4amAqWJ_mX3VDaXpZ6QmVM=.0e59a139-6d46-491d-9a7b-1a7803622d29@github.com>
 <nbKqHC6IBCjR6PwCEBFpJT8JJ3FKMNZjs5eWx2A9dmw=.c42c95dd-60cd-4fbf-bb01-738cf3f4d499@github.com>
Message-ID: <dk6ymJFcX9oMq12825SlpJIDowGyqHOyJ99JBCIIVuo=.f7e06bc6-67a6-4bb6-81ac-05a2670b1f20@github.com>

On Wed, 25 Nov 2020 20:31:50 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

>> test/jdk/TEST.groups line 327:
>> 
>>> 325:     :core_tools \
>>> 326:     :jdk_other \
>>> 327:     :jdk_core_manual
>> 
>> Please don't add manual tests to jdk_core.
>
> Removed.

aren't they already a part of `jdk_core` test group? e.g. `java/net/HugeDataTransferTest.java` is in `:jdk_net` (as `jdk_net` includes `java/net` directory), and `:jdk_core` includes `:jdk_net`?

-------------

PR: https://git.openjdk.java.net/jdk/pull/1416

From iignatyev at openjdk.java.net  Mon Nov 30 21:27:59 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 30 Nov 2020 21:27:59 GMT
Subject: RFR: JDK-8249836 java/io/IOException/LastErrorString.java should
 have bug-id as 1st word in @ignore
In-Reply-To: <tbepWCBf9z-ht6SdCVIzrPa6ZODUIBUd1UG7V8cTq28=.22cf697d-ecab-4cc7-b9b4-309c32eda64f@github.com>
References: <tbepWCBf9z-ht6SdCVIzrPa6ZODUIBUd1UG7V8cTq28=.22cf697d-ecab-4cc7-b9b4-309c32eda64f@github.com>
Message-ID: <VsmbgrCxBrmyFIRNHgjnK0Fak4jFPHIFDQkF-s2svUE=.eb445979-7a6b-4713-b7d6-f88026bee8c1@github.com>

On Fri, 27 Nov 2020 16:11:54 GMT, Mahendra Chhipa <github.com+34924738+mahendrachhipa at openjdk.org> wrote:

> ?id as 1st word in @ignore
> 
> https://bugs.openjdk.java.net/browse/JDK-8249836

LGTM

-------------

Marked as reviewed by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1482

From iignatyev at openjdk.java.net  Mon Nov 30 21:40:02 2020
From: iignatyev at openjdk.java.net (Igor Ignatyev)
Date: Mon, 30 Nov 2020 21:40:02 GMT
Subject: RFR: 8166026: refactor shell tests to java
In-Reply-To: <H2UZy1486X04VxMmEPt1dG78BSsv6F-qqhUNWMcpW4g=.08c502e1-d13c-4fa2-8174-1227072f7d63@github.com>
References: <H2UZy1486X04VxMmEPt1dG78BSsv6F-qqhUNWMcpW4g=.08c502e1-d13c-4fa2-8174-1227072f7d63@github.com>
Message-ID: <Fc2-79wIPJbvBHAz-9H8pVCL74260Z3JzVvE_CahPPU=.f3b2e505-7388-43e7-a3cf-4ea36db3bbcb@github.com>

On Fri, 27 Nov 2020 18:50:19 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> @iignatev  could you please review? Thank you.
> 
> note to self:
> jtreg test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java test/jdk/java/lang/SecurityManager/modules/CustomSecurityManagerTest.java test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java

it would be much easier to review if it was 4 separate RFEs/RFRs.

many new files miss a newline at the end.

test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java line 60:

> 58:         outputAnalyzer.shouldHaveExitValue(0);
> 59:         outputAnalyzer.stderrShouldMatch(EXPECTED_RESULT_STDERR);
> 60:         outputAnalyzer.stdoutShouldMatch(EXPECTED_RESULT_STDOUT);

you can chain these methods.

test/jdk/java/lang/ProcessBuilder/InheritIO/InheritIoTest.java line 61:

> 59:         outputAnalyzer.stderrShouldMatch(EXPECTED_RESULT_STDERR);
> 60:         outputAnalyzer.stdoutShouldMatch(EXPECTED_RESULT_STDOUT);
> 61:         assertEquals(outputAnalyzer.getOutput(),EXPECTED_RESULT_STDOUT + EXPECTED_RESULT_STDERR);

I'd rather check stdout and stderr independently, this will also make checks at 59 and 60 redundant.

test/jdk/java/lang/Thread/uncaughtexceptions/UncaughtExceptionsTest.java line 70:

> 68:         outputAnalyzer.shouldHaveExitValue(exitValue);
> 69:         outputAnalyzer.stderrShouldMatch(stdErrMatch);
> 70:         outputAnalyzer.stdoutShouldMatch(stdOutMatch);

why do you use `ShouldMatch` and not `ShouldContain` here?

test/jdk/java/lang/annotation/loaderLeak/LoaderLeakTest.java line 53:

> 51:         Files.createDirectories(REPOSITORY_PATH);
> 52:         List<String> classes = List.of("A.class", "B.class", "C.class");
> 53:         for (String fileName : classes) {

is this really needed for the test to operate correctly? or can we just use _regular_ `TEST_CLASSES` as CP?

-------------

Changes requested by iignatyev (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/1484

From naoto at openjdk.java.net  Mon Nov 30 22:43:05 2020
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 30 Nov 2020 22:43:05 GMT
Subject: RFR: 8251989: Hex formatting and parsing utility [v12]
In-Reply-To: <y1I6KuqGRceeUg1GY77XXmyuDES4I2JMrBk4PaqUr4Y=.45b7b10e-afc7-4b6b-801a-9b65313c3901@github.com>
References: <HSEn47GMS1K3g57mrTZeQk-WZHl3pKGHpX_OOf8VnsU=.740863c2-f9e4-43c4-b500-614aab4078b1@github.com>
 <y1I6KuqGRceeUg1GY77XXmyuDES4I2JMrBk4PaqUr4Y=.45b7b10e-afc7-4b6b-801a-9b65313c3901@github.com>
Message-ID: <AxpT7tm1LW7Ji89-uUCXjif4CQWU0t0A3Ku3bwAMAXg=.644ead9a-c227-435e-8808-baf1343a7c49@github.com>

On Mon, 30 Nov 2020 20:56:17 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> java.util.HexFormat utility:
>> 
>>  - Format and parse hexadecimal strings, with parameters for delimiter, prefix, suffix and upper/lowercase
>>  - Static factories and builder methods to create HexFormat copies with modified parameters.
>>  - Consistent naming of methods for conversion of byte arrays to formatted strings and back: formatHex and parseHex
>>  - Consistent naming of methods for conversion of primitive types: toHexDigits... and fromHexDigits...
>>  - Prefix and suffixes now apply to each formatted value, not the string as a whole
>>  - Using java.util.Appendable as a target for buffered conversions so output to Writers and PrintStreams
>>    like System.out are supported in addition to StringBuilder. (IOExceptions are converted to unchecked exceptions)
>>  - Immutable and thread safe, a "value-based" class
>> 
>> See the [HexFormat javadoc](http://cr.openjdk.java.net/~rriggs/8251989-hex-formatter/java.base/java/util/HexFormat.html) for details.
>> 
>> Review comments and suggestions welcome.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarified hexadecimal characters used in converting from characters to values to be strictly 0-9, a-f, and A-F.
>   Added a test to verify isHexDigit and fromHexDigit for the entire range of chars

Looks good to me.

-------------

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/482